Implementierungsmuster für Bewerter

Beim Entwerfen von Bewertungsmesswerten für ein AlphaEvolve-Bewertungs-Framework müssen die folgenden drei unterschiedlichen Testebenen festgelegt werden.

Ebene 1: Tests zur Lösungsvalidierung

Mit diesen Tests wird vor der vollständigen Ausführung die grundlegende Sicherheit der Codeausführung und die Richtlinienkonformität überprüft.

  • Sicherheit der Ausführung: Prüfen, ob der Code ausgeführt wird. Dazu gehören die Überprüfung der Syntax, die Prüfung der Kompilierungszeit, die Durchführung einer statischen Analyse und die Überprüfung der Infrastrukturkompatibilität.

  • Ausführungsrichtlinie: Festlegen, ob der Code auch dann ausgeführt werden soll, wenn er funktionsfähig ist. Dazu gehören Linting, allgemeine Prüfungen der Codequalität, InfoSec-Überprüfungen, Validierung von Risiken und Compliance sowie Überprüfungen der API-Lieferkette.

Überlegungen:

  • Wenn die Validierung fehlschlägt, einen hohen negativen Wert zurückgeben, z. B. -10000 oder -100000. AlphaEvolve ignoriert diese Programme.

  • Den Fehlertyp und die Logs zur Fehlerbehebung einbeziehen. AlphaEvolve verwendet diese Metadaten zwar nicht als Suchsignal, sie sind aber nützlich für die nachträgliche Analyse von Fehlermodi.

Ebene 2: Tests zur Lösungsüberprüfung

Mit diesen Tests werden die algorithmische Korrektheit und die Einhaltung von Einschränkungen mithilfe von Unit- und Funktionstests überprüft.

  • Funktionale Genauigkeit: Mit Unit- und Funktionstests prüfen, ob sich der Code korrekt verhält.

  • Einhaltung von Einschränkungen: Machbarkeit der Lösung oder Einhaltung von Einschränkungen überprüfen.

  • Minderung von Reward Hacking: Bewertungs-Scores als negative Strafen auf die Fitnessfunktion anwenden, um Reward Hacking zu verhindern. Ein Score von -10000 oder -100000 dient als effektive Strafe.

Überlegungen:

  • Die Anzahl oder den Prozentsatz der bestandenen Tests zurückgeben. Dieser Ansatz liefert ein Gradientensignal. Ein Programm, das 4 von 5 Tests besteht, wird als näher an der richtigen Lösung erkannt als ein Programm, das 0 von 5 Tests besteht.

  • Die Überprüfung als Erfüllung einer weichen Einschränkung behandeln. Auch bei harten Systemeinschränkungen liefert es AlphaEvolve ein besser verwertbares Suchsignal, wenn sie als weiche Strafen ausgedrückt werden, die auf der Nähe zum möglichen Bereich basieren, als wenn nur ein binäres „Bestanden“ oder „Nicht bestanden“ zurückgegeben wird.

Ebene 3: Tests zur Lösungsbewertung (Leistungstests)

Mit diesen Tests werden objektive Leistungsmesswerte gemessen, die vom Typ des Optimierungsziels abhängen.

  • Direkte Messung: Ziele direkt erfassen, wenn die Instrumentierung dies zulässt.

  • Deterministische Schätzungen: Ziele für klassische Operations Research-Stile analytisch berechnen.

  • Out-of-Sample-Validierung: Tests mit Validierungs-Datasets für Anwendungsfälle durchführen, die die Optimierung von Machine-Learning-Pipelines oder die Abstimmung von Agent-Frameworks umfassen.

  • Simulationsbasierte Schätzungen: Markow-Chain-Monte-Carlo-Simulationen (MCMC), Proxy-Funktionen vom Typ der bayesschen Optimierung oder andere modellbasierte Ansätze verwenden.

Überlegungen:

  • Sowohl detaillierte als auch aggregierte Scores zurückgeben.

  • Die Scoreberechnung nicht an das LLM auslagern, sondern deterministisch im Bewertungs-Framework berechnen. AlphaEvolve führt eine Hill-Climbing-Suche anhand dieser vorab berechneten aggregierten Leistungsscores durch.

  • Teilweise Gutschrift liefert ein Gradientensignal, das die Konvergenz der Suche beschleunigt. Ein Programm, das 4 von 5 Tests besteht, sollte beispielsweise einen Score von 0.8 und nicht None erhalten. Wenn None zurückgegeben wird, ignoriert AlphaEvolve das Programm vollständig, wodurch nützliches Feedback verloren geht. Ein Score von 0.8 signalisiert, dass der Kandidat fast richtig ist und ein hohes Optimierungspotenzial hat.