Mit dem Reward Hacking sind eine Reihe von Risiken verbunden. Im Folgenden finden Sie die Risiken und die entsprechenden Strategien zur Risikominderung.
Risiko 1:
Greedy Reward Hacking. Wenn Obj = w1*S1 + w2*S2 + w3*S3, kann AlphaEvolve S2 entdecken, um es zu erhöhen und sich ganz darauf zu konzentrieren, wobei S1 und S3 ignoriert werden.
Abhilfe:
Gewicht der Unterbewertung verringern. Möglicherweise sind 2–3 Testläufe erforderlich, um die Gewichte zu kalibrieren. Vorläufige Baseline-Simulationen einiger Bewertungsergebnisse sind hilfreich.
Risiko 2:
Ignorieren von Einschränkungsstrafen. Wenn weiche Einschränkungen Strafen sind
(Obj = Score - w*Penalty), kann AlphaEvolve feststellen, dass das Ignorieren von Einschränkungen
zu einem höheren Objführt.
Abhilfe:
Gewicht der Strafe erheblich erhöhen. Wenn das Verhalten weiterhin auftritt, fügen Sie der Problembeschreibung explizite Anweisungen hinzu, z. B. „Lösungen, die gegen Einschränkung X verstoßen, sind unabhängig von der Bewertung ungültig“.
Risiko 3:
Ausnutzung der Bewertungsfunktion. AlphaEvolve kann Eingaben finden, die dazu führen, dass der Evaluator künstlich hohe Bewertungen zurückgibt (Grenzfälle mit Gleitkommazahlen, Testdatenlecks).
Abhilfe:
Deterministische Bewertung mit festen Zufallswerten. Gewinner nach dem Test anhand von zurückgehaltenen Daten validieren.
Um Reward Hacking zu verhindern, implementieren Sie die folgenden allgemeinen Techniken:
AST-Prüfungen für verbotene Primitive (sys, os, inspect, eval, exec, getattr, setattr) verwenden und
Nonezurückgeben, wenn sie gefunden werden.Prüfen, ob der Code außerhalb von
EVOLVE-BLOCKunverändert ist (Textunterschied oder AST).Die entwickelte Funktion zweimal mit derselben Eingabe ausführen und prüfen, ob die Ausgabe identisch ist (erfasst Zufalls-Hacking).
Bewertungszeit prüfen. Wenn die Bewertung in Mikrosekunden abgeschlossen ist, wurde die Antwort wahrscheinlich fest codiert.
Bewertungslogik in einer separaten Datei ablegen, die für das LLM nicht sichtbar ist.