A Rubric-Supervised Critic from Sparse Real-World Outcomes

Diese Arbeit stellt einen Ansatz vor, der mithilfe von „Critic Rubrics" und einem semi-überwachten Lernverfahren aus spärlichen, verrauschten Realwelt-Interaktionen einen Kritiker-Modell entwickelt, das die Leistung von Code-Agenten durch verbessertes Reranking, frühes Stoppen und datengetriebene Kuratierung signifikant steigert.

Das Wesentliche

Stell dir vor, du hast einen sehr talentierten, aber manchmal etwas chaotischen digitalen Assistenten, der dir beim Programmieren hilft. Er schreibt Code, löst Fehler und baut Features.

Das Problem ist: Wie beurteilen wir, ob er wirklich gut arbeitet?

In der akademischen Welt (den „Benchmarks") ist das einfach: Der Assistent schreibt Code, und ein automatischer Test sagt „Ja" oder „Nein". Das ist wie ein Mathe-Test, bei dem man sofort sieht, ob die Lösung stimmt.

Aber im echten Leben ist es viel komplizierter. Hier arbeitet der Assistent mit einem echten Menschen zusammen. Der Mensch sagt: „Nein, das war nicht gemeint", oder „Kannst du das noch etwas ändern?", oder er ignoriert den Code einfach, weil er nicht passt. Der Erfolg ist hier nicht sofort sichtbar, oft erst Wochen später, wenn der Code im System bleibt und niemand ihn löscht. Es ist wie ein langes Gespräch, bei dem das Ende oft unklar ist.

Die Forscher aus diesem Papier haben ein cleveres System entwickelt, um diesen Assistenten trotzdem zu verbessern. Hier ist die Erklärung in einfachen Bildern:

1. Das Problem: Der „stille" Erfolg

Stell dir vor, du trainierst einen Hund.

• Im Labor: Der Hund bringt einen Ball, du sagst „Gut!", und er bekommt einen Leckerbissen. Das ist klar.
• Im echten Leben: Der Hund läuft mit dir im Park. Manchmal bellt er, manchmal schnüffelt er, manchmal rennt er weg. Du sagst ihm nie direkt „Gut" oder „Schlecht". Du merkst es erst, wenn du nach Hause kommst und der Hund müde und zufrieden ist (oder wenn er die Wohnung verwüstet hat).

Die Forscher sagen: „Wir haben zu wenig direkte Belohnungen (Leckerbissen) aus der echten Welt, um den Assistenten zu trainieren."

2. Die Lösung: Der „Kritiker" mit einem Checklisten-Notizblock

Um das zu lösen, haben sie einen Kritiker (eine Art KI-Beobachter) gebaut. Aber dieser Kritiker lernt nicht nur aus dem Endergebnis, sondern aus einem detaillierten Beobachtungsprotokoll, das sie „Critic Rubrics" (Kritiker-Checklisten) nennen.

Stell dir vor, der Kritiker ist ein Filmkritiker, der nicht nur schaut, ob der Film am Ende gut war, sondern sich während des gesamten Films Notizen macht:

• „Hat der Held die Anweisungen des Regisseurs missverstanden?"
• „Hat er sich in einer Endlosschleife wiederholt?"
• „Hat er zu viel getan, was gar nicht gefragt war?"
• „Hat der Zuschauer genervt gewirkt?"

Diese Checkliste enthält 24 verschiedene Verhaltensmerkmale. Das Geniale daran: Man kann diese Merkmale bei jedem einzelnen Schritt beobachten, auch wenn man noch nicht weiß, ob das Endergebnis gut war.

3. Der Trick: Die „Halb-gelehrte" Methode

Normalerweise braucht man für das Training einer KI viele Beispiele mit klaren „Gewonnen/Gewonnen"-Labels. In der echten Welt gibt es diese Labels aber nur selten (vielleicht bei 4 von 100 Fällen).

Die Forscher nutzen einen cleveren Trick:

1. Sie lassen die KI die Checkliste (Rubrics) für alle 100 Fälle ausfüllen (denn das Verhalten ist immer sichtbar).
2. Nur für die 4 Fälle, bei denen sie das Endergebnis kennen, lernen sie auch das Endergebnis.
3. Die KI lernt also: „Wenn ich sehe, dass der Assistent zu viel getan hat (Checkliste) und der Code später gelöscht wurde (Endergebnis), dann ist das ein schlechtes Verhalten."

Dadurch wird aus den 96 „unbekannten" Fällen auch wertvolles Lernmaterial. Die Checkliste füllt die Lücken, die das fehlende Endergebnis hinterlässt.

4. Was bringt das? (Die Vorteile)

Dieser neue Kritiker hilft auf drei Arten:

• Die „Best of K"-Auswahl (Der Jury-Trick):
  Wenn der Assistent 8 verschiedene Lösungsversuche für ein Problem macht, kann der Kritiker sofort sagen: „Versuch 3 sieht vielversprechend aus, Versuch 7 war chaotisch." So muss man nur den besten Versuch auswählen, statt alle durchzuprobieren. Das spart Zeit und Rechenleistung.

  • Ergebnis: Die Erfolgsrate bei echten Aufgaben stieg um fast 16 Punkte.

• Frühes Stoppen (Der „Genug!"-Schalter):
  Wenn der Kritiker sieht, dass der Assistent in eine Sackgasse läuft (z. B. immer wieder denselben Fehler macht), kann er sagen: „Halt! Abbrechen!" Man muss nicht warten, bis der Assistent 10 Minuten lang sinnlos arbeitet.

  • Ergebnis: Man spart 83 % der Rechenzeit, weil man unnötige Versuche sofort abbricht.

• Besseres Training (Der Filter für gute Beispiele):
  Wenn man den Assistenten neu trainieren will, kann man mit dem Kritiker die besten Beispiele aus der echten Welt heraussuchen. Man trainiert ihn nur mit den Fällen, in denen er wirklich gut war, statt mit zufälligen Daten.

  • Ergebnis: Der Assistent wird schlauer und robuster.

Zusammenfassung

Statt nur auf das Endergebnis zu warten (wie ein Lehrer, der erst die Note gibt, wenn der Schüler die Schule verlässt), hat dieses System einen Beobachter eingeführt, der während des gesamten Prozesses auf eine Checkliste schaut.

Dadurch können sie den Assistenten auch dann verbessern, wenn die echten Rückmeldungen der Nutzer selten, spät und unklar sind. Es ist, als würde man einen Sportler nicht nur nach dem Sieg belohnen, sondern ihm auch sagen: „Deine Haltung war gut, aber du hast den Ball zu früh geworfen." So wird er auch ohne den nächsten Sieg besser.

Technische Zusammenfassung

Titel: Ein rubrik-supervidierter Kritiker aus spärlichen realen Ergebnissen

Autoren: Xingyao Wang, Valerie Chen, Heng Ji, Graham Neubig (OpenHands, CMU, UIUC)

---

1. Problemstellung

Aktuelle akademische Benchmarks für Coding-Agenten (z. B. SWE-bench) bewerten den Erfolg primär anhand verifizierbarer, autonomer Aufgabenabschlüsse, wie dem Bestehen von Unit-Tests. In der realen Welt arbeiten Coding-Agenten jedoch in einem Human-in-the-Loop-Setting. Hier sind die Erfolgssignale oft:

• Spärlich (Sparse): Nutzer geben selten direktes Feedback zur Interaktionsqualität.
• Verzögert (Delayed): Feedback erfolgt oft erst am Ende einer Interaktion (z. B. nach dem Mergen eines Pull Requests), nicht während der Ausführung.
• Rauschbehaftet (Noisy): Ein gemergter Pull Request (PR) bedeutet nicht zwingend, dass jede einzelne Agenten-Aktion korrekt war; Nutzer können Änderungen manuell korrigieren oder revertieren.

Dies führt zu einem Credit-Assignment-Problem: Es ist schwer zu bestimmen, welche spezifischen Aktionen des Agenten zu einem Erfolg oder Misserfolg beigetragen haben. Bestehende Evaluatoren, die nur auf Benchmarks trainiert wurden, versagen oft bei der Vorhersage realer Ergebnisse (AUC nahe 0,5, also zufällig).

2. Methodik

Die Autoren schlagen einen Prozess vor, um einen lernbaren „Kritiker" (Critic) zu trainieren, der aus Interaktionsspuren (Traces) Erfolgswahrscheinlichkeiten und Verhaltensmerkmale vorhersagt. Der Ansatz besteht aus drei Hauptkomponenten:

A. Segmentierung von Interaktionen

Statt ganzer Multi-Turn-Konversationen als eine Einheit zu betrachten, werden diese in Segmente zerlegt. Ein Segment ist eine minimale, in sich geschlossene Arbeitseinheit, die mit einer Nutzeranfrage beginnt und mit einer finish-Aktion des Agenten endet.

• Dies ermöglicht eine feinere Granularität für das Lernen, auch wenn das finale Feedback (z. B. PR-Merge) nur auf Ebene der gesamten Konversation vorliegt.

B. Outcome-Proxies (Spärliche Signale)

Um die spärlichen realen Ergebnisse zu nutzen, definieren die Autoren zwei Hierarchie-Ebenen:

1. PR Merge: Ein binäres Signal (gemerged oder nicht), das allen Segmenten einer PR zugewiesen wird. Dies ist grob und verrauscht.
2. Code Survival: Ein feineres, kontinuierliches Signal (0–1), das misst, welcher Anteil des vom Agenten geschriebenen Codes im finalen, gemergten Diff erhalten bleibt. Dies löst das Credit-Assignment-Problem besser, da es spezifische Segmente belohnt oder bestraft, deren Code überlebt hat.

C. Critic Rubrics (Dichte Signale)

Das Kernstück der Methode ist die Einführung von 24 „Critic Rubrics". Dies sind verhaltensbasierte Merkmale, die direkt aus der Interaktionsspur abgeleitet werden können, ohne dass ein externes Erfolgsergebnis bekannt sein muss. Sie umfassen:

• Agenten-Verhaltensprobleme: (z. B. Missverständnis der Absicht, nicht befolgte Anweisungen, unzureichendes Testen, Schleifenverhalten).
• Nutzer-Follow-up-Muster: (z. B. Korrekturen, Frustration, Richtungswechsel, VCS-Anfragen).
• Infrastruktur-Probleme: (z. B. externe Ausfälle vs. vom Agenten verursachte Fehler).

Diese Rubrics werden durch ein großes Sprachmodell (LLM) annotiert und liefern dichte Supervision für 100 % der Segmente, im Gegensatz zu den spärlichen Outcome-Labels (nur ~4–6 %).

D. Semi-supervised Multi-Task Training

Ein Kritiker-Modell (basierend auf Qwen3-4B) wird mit einem semi-superviseden Multi-Task-Lernziel trainiert:

1. Rubric-Vorhersage: Das Modell lernt, die 24 Rubric-Merkmale für alle Segmente vorherzusagen (dichte Supervision).
2. Erfolgsvorhersage: Das Modell lernt gleichzeitig, die Erfolgswahrscheinlichkeit (basierend auf Code Survival oder PR Merge) für die wenigen gelabelten Segmente vorherzusagen (spärliche Supervision).

Durch die gemeinsame Optimierung nutzt das Modell die dichten Rubric-Signale, um robuste Repräsentationen von Fehlern zu lernen, die dann auf die spärlichen Erfolgssignale verallgemeinern.

3. Wichtige Beiträge

1. Critic Rubrics Framework: Eine Taxonomie von 24 verhaltensbasierten Merkmalen, die als dichte, beobachtbare Supervision für das Training von Kritikern dienen und das Problem der Datenknappheit in der realen Welt lösen.
2. Semi-supervisedes Training: Ein Ansatz, der Rubric-Vorhersage und Outcome-Vorhersage kombiniert, um aus 154.000 realen Interaktionssegmenten einen effektiven Kritiker zu trainieren, obwohl nur ein winziger Bruchteil direkte Erfolgslabels hat.
3. Segment-basierte Hierarchie: Eine Methode zur Abbildung von groben PR-Ergebnissen auf feinere Segmente mittels „Code Survival", was eine genauere Kreditvergabe ermöglicht.
4. Open-Source-Release: Veröffentlichung des Kritiker-Modells, der Rubric-Definitionen und des Codes zur Segmentierung.

4. Ergebnisse

Die Experimente zeigen signifikante Verbesserungen gegenüber Baseline-Modellen:

• Transferfähigkeit: Kritiker, die nur auf Benchmarks (SWE-Gym) trainiert wurden, versagen auf realen Daten (AUC 0,45–0,48). Kritiker, die mit realen Daten und Rubrics trainiert wurden, erreichen AUC-Werte von 0,64–0,69.
• Code Survival vs. PR Merge: Training auf „Code Survival" führt zu besseren Ergebnissen als Training auf „PR Merge", da es weniger verrauscht und segment-spezifischer ist.
• Inferenz-Scaling (Best-of-K): Beim Einsatz für das Reranking von 8 Trajektorien (Best@8) auf SWE-bench verbessert der rubrik-supervidierte Kritiker die Erfolgsrate um +15,9 Punkte gegenüber einer zufälligen Auswahl (von 57,9 % auf 73,8 %).
• Early Stopping: Der Kritiker ermöglicht ein effizientes „Early Stopping" von gescheiterten Versuchen. Dies reduziert die benötigten Versuche um 83 % (durchschnittlich 1,35 Versuche statt 8), während die Erfolgsrate um +17,7 Punkte über dem Zufall liegt.
• Robustheit über Backbones: Im Gegensatz zu reinen Erfolgskritikern, die sich an spezifische LLM-Backbones (z. B. Claude Sonnet) anpassen und bei anderen (Claude Opus) schlechter als Zufall abschneiden, generalisieren rubrik-supervidierte Kritiker robust über verschiedene Modelle hinweg.
• Daten-Curation für SFT: Die Auswahl von Trainingsdaten basierend auf den Kritiker-Scores führt zu einer Verbesserung der Fine-Tuning-Ergebnisse (+1,2 % gegenüber zufälliger Auswahl), was zeigt, dass der Kritiker nützliche Trainingsbeispiele identifizieren kann.

5. Bedeutung und Ausblick

Diese Arbeit schließt eine kritische Lücke zwischen akademischen Benchmarks und der Realität von Coding-Agenten.

• Praktische Anwendbarkeit: Die Methode ermöglicht es, Agenten in Produktionsumgebungen zu verbessern, wo keine perfekten Test-Suiten existieren.
• Effizienz: Durch Early Stopping und besseres Reranking wird Rechenzeit massiv gespart.
• Skalierbarkeit: Der Ansatz macht unlabeled Produktionsdaten für das Training nutzbar, indem er verhaltensbasierte Proxy-Signale (Rubrics) als Brücke zu spärlichen Erfolgssignalen nutzt.

Der vorgestellte „Critic" fungiert somit nicht nur als Evaluierungstool, sondern als aktiver Treiber für das Training (durch Datenselektion) und die Inferenz-Optimierung (durch Reranking und Early Stopping) von autonomen Software-Engineering-Agenten.