SWE-Critix: Allgemeine Verifizierer für Trajektorien von Coding-Agenten per Post-Training, mit Urteil über den Erfolg und Begründung, Genauigkeit von 57 % auf 78 %

Die Arbeit 2610.13356 erschien Mitte Oktober 2026 auf arXiv als „SWE-Critix: Post-Training allgemeiner Verifizierer zur Bewertung von Trajektorien von Coding-Agenten“. Das Problem wird schärfer, je fähiger Coding-Agenten werden. Sie schreiben nicht mehr nur ein Snippet: Sie inspizieren Repositories, bearbeiten Dateien, führen Befehle und Tests aus, deuten Rückmeldungen und verfeinern, von der Synthese einzelner Funktionen bis zur Lösung von Issues auf Repository-Ebene und zu langfristiger Softwareentwicklung. Je autonomer sie sind, desto wichtiger ist es, ihre Ausführungstrajektorien zuverlässig zu prüfen, die Schritt-für-Schritt-Aufzeichnung der Aufgabenlösung. In realistischen End-to-End-Aufgaben fehlt aber oft ein fertiger Orakel-Evaluator, der Erfolg definiert. Man braucht einen Verifizierer, der entscheidet, ob der Agent die Aufgabe geschafft hat, und bei Misserfolg sagt, warum.

Die Schwierigkeit liegt in der Trajektorie selbst. Eine kann Hunderte verschränkter Nutzereingaben, Umgebungsrückmeldungen und Modellantworten enthalten, weit schwerer zu prüfen als eine einmalige Antwort. Die Arbeit nennt ein Beispiel, in dem Trajektorien für Aufgaben in LoLBench 53 bis 532 Züge umfassen. Die Autoren ordnen bestehende Arbeiten nach zwei Achsen: Betrachtet ein Verifizierer nur das Endergebnis (etwa den eingereichten Patch) oder auch den Prozess, um unerwünschtes Zwischenverhalten zu erkennen, und wird er mit oder ohne Training gebaut. Trainingsfreie Methoden nutzen allgemeine LLMs oder regelbasierte Richter, trainingsbasierte lernen eigene Kritiker, die sich weiter danach unterscheiden, ob sie nur skalare Belohnungen ausgeben. In dieser Einteilung ist die trainingsbasierte, prozessorientierte allgemeine Verifikation wenig erforscht. SWE-Critix will die Lücke füllen: Gegeben eine Aufgabe und ihre Trajektorie sagt der gelernte Verifizierer voraus, ob sie erfüllt wurde, und erzeugt eine Analyse in natürlicher Sprache, die das Urteil erklärt.

Die Trainingspipeline hat mehrere Schritte. Die Daten stammen aus CoderForge-Preview (im Abstract CodeForge-Preview geschrieben), einem großen offenen Datensatz mit 258.000 Trajektorien (155.000 bestanden, 103.000 gescheitert) zu 51.000 Issues in 1.655 Repositories. Sie wurden mit dem OpenHands-Gerüst und Qwen3-Coder-480B auf drei Aufgabenquellen mit ausführbaren Umgebungen erzeugt. Die Autoren verwerfen jede Trajektorie über 64.000 Token oder ohne eingereichten Patch, etwa weil die Aufgabe unvollständig war, was 16 % der Daten entfernt, und teilen den Rest in SFT-, RL- und Testmenge. Für SFT wählen sie je Issue, das beide Arten hat, eine erfolgreiche und eine gescheiterte Trajektorie; die RL-Menge enthält alle übrigen gescheiterten Trajektorien und zieht erfolgreiche reihum über die Issues, bis die Klassen ausgeglichen sind, um möglichst viele verschiedene Issues abzudecken.

Der Schlüssel der SFT-Phase ist die Herkunft der Begründungsketten. Ein stärkeres Lehrermodell (GPT-5.5) vergleicht jedes Paar aus Erfolg und Misserfolg und fasst Vorgehen, Fehlermuster und ausschlaggebende Faktoren zusammen; die Ketten werden für Einzelurteile nachbearbeitet und zu SFT-Beispielen zusammengesetzt. Der Paarvergleich wurde gewählt, weil frühere Befunde besagen, dass LLMs paarweise besser urteilen als einzeln. Ausgehend von Qwen3-30B-A3B-Thinking-2507 feinabgestimmt wird mit MindSpeed-LLM auf 128 Huawei-Ascend-910B-NPUs in 16 Knoten, drei Epochen, 975 Iterationen, rund 15 Stunden. Die RL-Phase nutzt die übrigen 91,3 % der Daten mit Unit-Test-Ergebnissen, aber ohne Begründungsketten, mit einer einfachen regelbasierten Ergebnisbelohnung: +1, wenn das vorhergesagte Urteil mit der Wahrheit aus den Unit-Tests übereinstimmt, sonst -1. Verwendet werden VeRL und GRPO mit Gruppengröße 8 auf 128 Ascend-910C-NPUs in 8 Knoten, 3.396 Iterationen je Epoche, rund 533 Stunden.

Die Bewertung ist direkt: Kann das Modell erfolgreiche von gescheiterten Trajektorien unterscheiden? Die Testmenge hat über 43.000 lange Trajektorien, jedes Modell wird je Probe einmal bewertet, mit vLLM Ascend auf einem Knoten mit 16 Ascend-910C-NPUs, und berichtet werden Genauigkeit sowie Precision, Recall und F1 für die positive (erfolgreiche) und negative (gescheiterte) Klasse. Die Ergebnisse zeigen eine klare Abfolge. Das Basis-Qwen3-MoE-Modell neigt stark dazu, Trajektorien als korrekt vorherzusagen, mit einem negativen Recall nahe null in allen Teilmengen, und 9,6 % seiner Antworten halten das geforderte Ausgabeformat nicht ein, sodass Urteile nicht zuverlässig extrahierbar sind. SFT mildert beides: Alle Antworten folgen dem Prompt-Format, und die positive Verzerrung sinkt deutlich. RL hebt dann die Gesamtgenauigkeit von 66 % auf 78 %. SFT behebt vor allem die starke positive Verzerrung, RL stärkt die Unterscheidung, indem es den positiven Recall von 67 % auf 85 % hebt, ohne den negativen Recall wesentlich zu opfern.

Die Autoren benennen die Mängel offen. Erstens liegt die Leistung auf R2E-Gym deutlich unter der auf SWE-Rebench und SWE-Smith, möglicherweise wegen der geringeren Datenmenge. Zweitens erkennt das Modell gescheiterte Trajektorien weiterhin schwächer, mit einem negativen Recall von insgesamt nur 64 %; Fehlermuster sind vielfältiger und ihre Signale feiner. Künftig wollen die Autoren weitere Quellen wie Open-SWE-Traces hinzunehmen, Trajektorien mit anderen Kombinationen aus Modellen und Gerüsten synthetisieren und Klassenverhältnisse wie 2:1, 1:2 und 4:1 jenseits der ausgeglichenen Mischung untersuchen. Zu beachten ist, dass alle Trajektorien aus einem Gerüst und einem Modell stammen, es also keinen Beleg dafür gibt, wie der Verifizierer mit anderen Gerüsten oder Modellen abschneidet. Unsere Einordnung: SWE-Critix zeigt, dass sich begründete Urteile mit einem recht einfachen zweistufigen Rezept lernen lassen, und die Veröffentlichung von Modellen und Trainingscode erlaubt es anderen, es nachzubauen und zu verbessern. Die Grenzen sind deutlich: eine selbst als vorläufig bezeichnete Auswertung, jede Probe nur einmal getestet; 78 % Genauigkeit lassen weiter klare Fehlurteile zu; und bei gescheiterten Trajektorien ist es schwächer, wo in der Praxis ein übersehener Misserfolg meist gefährlicher ist als Fehlalarm. Ein Team, das so einen Verifizierer in seiner Coding-Agenten-Pipeline will, sollte ihn als ergänzendes Signal neben Unit-Tests, Stichproben und unabhängigen Bewertungsumgebungen behandeln und die Klassifikation an den eigenen Trajektorien messen, bevor es über den Einsatzort entscheidet.