Technischer Zusammenfassung: Extrapolatives Gewichts-Averaging enthüllt Fronten von Korrektheit und Effizienz im Code-RL

Problemstellung

Im Reinforcement Learning (RL) für Code-Generierung, insbesondere im wettbewerbsorientierten Programmieren, stehen Modelle vor einem doppelten Ziel: funktionale Korrektheit (Bestehen aller Testfälle) und rechnerische Effizienz (Lösen innerhalb von Zeit- und Speicherlimits). Das Standard-RL-Training kämpft oft damit, diese Ziele in Einklang zu bringen, da die Optimierung auf strenge Effizienz zu Korrektheitsfehlern führen kann, während die Optimierung auf Korrektheit bei kleinen Eingaben ineffiziente Lösungen hervorbringt, die bei größeren Stresstests versagen.

Bestehende Arbeiten zum Modell-Merging (z. B. „Rewarded Soups") haben gezeigt, dass eine lineare Interpolation der Gewichte zwischen Checkpoints, die unter verschiedenen Belohnungszielen trainiert wurden, eine Pareto-Front zwischen diesen Zielen abbilden kann. Es bleibt jedoch unklar, ob extrapolatives Gewichts-Averaging (Durchschnittsbildung von Gewichten mit Koeffizienten außerhalb des Intervalls $[0, 1]$) diese Fronten auf neue, nützliche Checkpoints erweitern kann, ohne zusätzliches Training. Kann Extrapolation also über die Grenzen einzelner RL-Trainingsläufe hinaus navigieren, um Strategien zu entdecken, die weder rein korrekt noch rein effizient sind, sondern komplementär?

Methodik

Experimenteller Aufbau

Die Autoren untersuchen diese Frage unter Verwendung von wettbewerbsorientiertem Programmieren als kontrolliertes Setting, bei dem die Strenge des Verifiers als natürliche experimentelle Achse dient.

• Modelle: Die Experimente werden an Modellen mit 7B und 32B Parametern durchgeführt (Qwen 2.5 7B und CWM-SFT 32B).
• Trainingsumgebung: Drei verschiedene RL-Szenarien werden verwendet:
  1. Reine Reasoning: Generierung in einem einzigen Schritt.
  2. Tool-Nutzung: Mehrstufiges Reasoning mit Python-Tool-Aufrufen.
  3. Agentic Coding: Mehrstufige Interaktion mit einer sandgeboxten Terminalumgebung.
• Sweep der Belohnungsstrenge: Ausgehend von einem gemeinsamen Supervised Fine-Tuning (SFT)-Checkpoint werden unabhängige RL-Läufe auf dem CodeContestsPlus-Datensatz trainiert. Die Belohnungsfunktion ist ein verschachteltes binäres Signal basierend auf Schwellenwerten für die Eingabelänge ($k$):
  • $R_k(y) = 1$, wenn die Lösung alle Tests mit einer Eingabelänge $< 10^k besteht.
  • $R_\infty(y) = 1$, wenn die Lösung alle Tests besteht (vollständiger Satz).
  • Dies erzeugt eine geordnete Familie von Checkpoints von „geringer Abdeckung" (entspannt, kleine Eingaben) bis „hoher Abdeckung" (streng, vollständige Stresstests).

Gewichts-Averaging

Die Kernoperation ist das lineare Gewichts-Averaging zwischen zwei Endpunkten, $\theta_{low}$ (geringe Abdeckung) und $\theta_{high}$ (hohe Abdeckung):
$$\theta_\alpha = \alpha \theta_{high} + (1 - \alpha) \theta_{low}$$

• Interpolation: $\alpha \in [0, 1]$.
• Extrapolation: $\alpha \notin [0, 1]$ (z. B. $\alpha < 0$ oder $\alpha > 1$).

Evaluation

Die Checkpoints werden am LiveCodeBench (LCB)-Benchmark bewertet (zurückgehalten, vollständige Testabdeckung). Die Ergebnisse werden in folgende Kategorien eingeteilt:

1. Korrekt: Bestehen aller Tests.
2. Optimierungsfehler: Bestehen kleinerer Tests, aber Überschreiten der Zeit-/Speichergrenzen bei größeren Tests.
3. Korrektheitsfehler: Versagen aufgrund von Logikfehlern oder Laufzeitexceptionen innerhalb der Grenzen.
4. Formatfehler: Nicht parsbare Ausgabe.

Hauptbeiträge und Ergebnisse

1. Entstehung einer Korrektheit–Effizienz-Front

Die Studie zeigt, dass die Variation der Verifier-Strenge keine einfache Rangfolge der Checkpoints erzeugt. Stattdessen wird bei schwierigen Problemen eine Korrektheit–Effizienz-Front abgebildet:

• Training mit geringer Abdeckung reduziert Korrektheitsfehler, erhöht jedoch Optimierungsfehler (ineffiziente Lösungen).
• Training mit hoher Abdeckung reduziert Optimierungsfehler, erhöht jedoch Korrektheitsfehler (Modelle versuchen effiziente Algorithmen, scheitern aber an der Logik).
• Stabilität der Lösungsrate: Die gesamte Lösungsrate bleibt über die Front hinweg nahezu konstant; der Trade-off liegt primär darin, wie das Modell versagt (Ineffizienz vs. Inkorrektheit), nicht ob es das Problem löst.

2. Interpolation stellt die Front wieder her

Die lineare Interpolation zwischen Endpunkten mit geringer und hoher Abdeckung stellt erfolgreich die Front wieder her, die von den unabhängig trainierten Checkpoints abgebildet wurde. Eine einzige Interpolationsrichtung im Gewichtsraum reicht aus, um den Trade-off zwischen Optimierungs- und Korrektheitsfehlern zu durchlaufen.

3. Extrapolation erweitert die Front

Entscheidend ist, dass extrapolatives Gewichts-Averaging diese Front über die Endpunkte hinaus erweitert, die von einem einzelnen RL-Lauf erreicht wurden:

• Jenseits der RL-Grenzen: Für $\alpha > 1$ und $\alpha < 0$ setzen die extrapolierten Checkpoints dieselbe Trade-off-Kurve fort und erreichen Niveaus von Optimierungs-/Korrektheitsfehler-Verhältnissen, die kein einzelner RL-Checkpoint erreichte.
• Stabilität: Diese Fortsetzung ist über einen breiten Bereich stabil (z. B. $\alpha \in [-0.5, 1.5]$). Extreme Extrapolation ($|\alpha| > 2$) führt zu einer Degradation, die primär auf Formatfehler (Token-Erschöpfung) zurückzuführen ist, nicht auf einen Zusammenbruch der Frontlogik.
• Generalisierung: Dieses Phänomen gilt für alle drei Inferenzszenarien (Reasoning, Tool-Nutzung, Agentic Coding) und beide Modellgrößen (7B, 32B), sofern die Problemschwierigkeit an die Fähigkeiten des Modells angepasst ist.

4. Inferenzzeit-Scaling durch Ensembles

Die Arbeit zeigt, dass extrapolierte Checkpoints komplementäre Strategien sind:

• Problemspezifischer Wechsel: Verschiedene Punkte entlang der extrapolierten Achse lösen unterschiedliche Teilmengen schwieriger Probleme. Während die gesamte Lösungsrate flach bleibt, variieren die spezifisch gelösten Probleme erheblich.
• Ensemble-Gewinne: Durch die Ensemble-Bildung von Checkpoints entlang der erweiterten Front (Interpolation + Extrapolation) verbessern die Autoren die pass@250-Metrik auf LCB/hard um 3,3 % gegenüber dem besten einzelnen Checkpoint bei gleichem Stichprobenbudget.
• Diversität: Der extrapolierte Pool liefert einzigartige Lösungen für Probleme, die von reinen Interpolations-Pools verpasst werden, insbesondere bei den schwierigsten Problemen.

5. Was bewegt die Front?

Die Autoren kontrastieren statisches Reward-Shaping mit failure-conditioned Training:

• Statisches Reward-Shaping: Die Vergabe von Teilpunkten für das Bestehen kleinerer Tests (diskret oder kontinuierlich) hält das Modell auf derselben Front. Es gewichtet lediglich bestehende Ergebnisse neu, ohne neue Informationen einzuführen.
• Failure-Conditioned Training: Die Verwendung von Fehlerkontext (gescheiterter Code + Ausführungsstatistiken) zum Trainieren einer Reparaturstrategie (Online-Fixing) zeigt Potenzial, die Front nach außen zu verschieben, indem sowohl die Reparaturraten als auch die ursprünglichen Bestehensraten verbessert werden. Dies deutet darauf hin, dass reichhaltigere Fehlersignale erforderlich sind, um über den bestehenden Trade-off hinauszukommen.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass verschachtelte Unit-Test-Abdeckung im Code-RL eine Korrektheit–Effizienz-Front induziert, die durch extrapolatives Gewichts-Averaging navigiert, erweitert und ausgenutzt werden kann.

• Neuartigkeit: Sie stellt fest, dass Extrapolation nicht nur eine mathematische Kuriosität ist, sondern eine praktische Methode, um eine „Fortsetzung" der Pareto-Front zu erreichen und diverse Strategien zu generieren, die kein einzelner Trainingslauf produziert.
• Praktischer Nutzen: Extrapolierte Checkpoints dienen als kostengünstiger, trainingsfreier Mechanismus für Inferenzzeit-Scaling, der die Abdeckung gelöster Probleme ohne zusätzlichen RL-Rechenaufwand erweitert.
• Einschränkungen: Die Front wird durch den spezifischen Trade-off zwischen Korrektheit und Effizienz im wettbewerbsorientierten Programmieren induziert. Die Autoren stellen fest, dass die Front selbst zu verschieben (Verbesserung der Pareto-Front) wahrscheinlich Trainingssignale erfordert, die aufzeigen, warum Programme scheitern (z. B. failure-conditioned Training) und nicht nur strengere Tests.

Die Arbeit schlägt ein neues Paradigma für RL im Code vor: Anstatt nach einem einzelnen „optimalen" Checkpoint zu suchen, können Praktiker das Gewichts-Averaging nutzen, um ein Spektrum komplementärer Verhaltensweisen zu erkunden und die Fähigkeiten bestehender Modelle durch einfache arithmetische Operationen an den Gewichten zu erweitern.