Reward Hacking ist mit einer Reihe von Risiken verbunden. Im Folgenden finden Sie 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 die Leistung zu steigern, und sich vollständig darauf konzentrieren, während S1 und S3 ignoriert werden.
Abhilfe:
Verringern Sie die Gewichtung des Teilwerts. Möglicherweise sind 2–3 Testläufe erforderlich, um die Gewichtungen zu kalibrieren. Vorläufige Basissimulationen einiger Scoring-Ergebnisse sind hilfreich.
Risiko 2:
Einschränkungsstrafe wird ignoriert. Wenn weiche Einschränkungen Strafen sind ((Obj = Score - w*Penalty)), kann AlphaEvolve feststellen, dass das Ignorieren von Einschränkungen zu höheren Obj führt.
Abhilfe:
Erhöhen Sie die Strafgewichtung erheblich. 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 Punktzahl ungültig“.
Risiko 3:
Ausnutzung von Bewertungsfunktionen. AlphaEvolve findet möglicherweise Eingaben, die dazu führen, dass der Evaluator künstlich hohe Werte zurückgibt (Gleitkomma-Grenzfälle, Testdatenlecks).
Abhilfe:
Deterministische Bewertung mit festen Zufalls-Seeds. Validieren Sie die Gewinner nach dem Test anhand von zurückgehaltenen Daten.
So verhindern Sie das Hacken von Prämien:
Verwenden Sie AST-Prüfungen für verbotene Primitive (sys, os, inspect, eval, exec, getattr, setattr) und geben Sie
Nonezurück, wenn sie gefunden werden.Prüfen Sie, ob der Code außerhalb von
EVOLVE-BLOCKunverändert ist (Text-Diff oder AST).Führen Sie die weiterentwickelte Funktion zweimal mit derselben Eingabe aus und prüfen Sie, ob die Ausgabe identisch ist (um Zufälligkeitshacking zu erkennen).
Prüfen Sie die Auswertungszeit. Wenn es in Mikrosekunden fertig ist, hat es die Antwort wahrscheinlich hartcodiert.
Legen Sie die Bewertungslogik in einer separaten Datei ab, die für das LLM nicht sichtbar ist.