🤖 AI

Abstain and Validate: A Dual-LLM Policy for Reducing Noise in Agentic Program Repair

Dieses Paper stellt ein Dual-LLM-Policy-Framework vor, das Bug-Abstention und Patch-Validierung kombiniert, um durch das Herausfiltern unwahrscheinlicher zu behebender Bugs und suboptimaler Patches vor der menschlichen Überprüfung das Rauschen signifikant zu reduzieren und die Erfolgsraten in der agentenbasierten automatisierten Programmbereinigung (Automated Program Repair) auf industriellem Niveau zu verbessern.

Ursprüngliche Autoren: José Cambronero, Michele Tufano, Sherry Shi, Renyao Wei, Grant Uy, Runxiang Cheng, Chin-Jung Liu, Shiying Pan, Satish Chandra, Pat Rondon

Veröffentlicht 2026-01-30

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: José Cambronero, Michele Tufano, Sherry Shi, Renyao Wei, Grant Uy, Runxiang Cheng, Chin-Jung Liu, Shiying Pan, Satish Chandra, Pat Rondon

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie hätten einen sehr talentierten, aber etwas übereifrigen Roboter-Assistenten namens „Repair-Bot“. Ihr Job ist es, tausende von kaputten Dingen in einem riesigen Lagerhaus (dem Codebase des Unternehmens) zu reparieren. Repair-Bot ist großartig darin, Dinge zu reparieren, aber er neigt dazu, Fehler zu machen, Zeit zu verschwenden und Korrekturen vorzuschlagen, die eigentlich nicht funktionieren.

Wenn Sie Repair-Bot erlauben würden, Ihnen jedes einzelne Ding zu zeigen, das er zu reparieren versucht, wären Sie überfordert. Sie würden den ganzen Tag damit verbringen, sich kaputte Vorschläge anzusehen, frustriert sein und schließlich aufhören, dem Roboter zu vertrauen.

Dieses Paper stellt ein zweistufiges „Gatekeeper“-System vor, um den Lärm zu stoppen, bevor er Ihren Schreibtisch erreicht. Denken Sie an einen Türsteher in einem Club und einen Qualitätskontrolleur in einer Fabrik.

Das Problem: Zu viel Lärm

In der Welt der Software sind „Bugs“ Fehler im Code. Automatisierte Systeme (genannt Agentic APR) versuchen, diese zu beheben. Aber diese Systeme versuchen oft, Bugs zu beheben, die zu schwer für sie sind, oder sie generieren „Patches“ (Code-Änderungen), die zwar gut aussehen, aber eigentlich falsch sind.

Das Ergebnis: Entwickler verschwenden Zeit mit der Überprüfung schlechter Korrekturen.
Das Ziel: Dem Entwickler nur die Korrekturen zeigen, die wahrscheinlich funktionieren werden.

Die Lösung: Das Zwei-Tore-System

Die Autoren schlagen zwei Policies vor, die wie Filter in einem Trichter wirken.

Tor 1: Die „Bug Abstention“ (Der Türsteher)

Was es tut: Bevor der Roboter überhaupt versucht, einen Bug zu beheben, betrachtet dieses Tor den Bug-Report (die Beschreibung des Problems).
Die Analogie: Stellen Sie sich vor, Sie sind ein Türsteher in einem Club. Sie schauen sich die Person an, die versucht einzutreten (den Bug). Wenn die Person zu verwirrt wirkt, die Beschreibung zu vage ist oder das Problem mit den vorhandenen Werkzeugen unlösbar scheint, sagen Sie: „Tut mir leid, Sie kommen hier nicht rein.“
Wie es funktioniert: Ein KI-Modell liest den Bug-Report und fragt: „Kann unser Roboter das tatsächlich beheben?“ Wenn die Antwort „wahrscheinlich nicht“ lautet, entsagt (abstains) sich das System (weigert sich, es zu versuchen). Es spart die Energie des Roboters und, was noch wichtiger ist, es erspart dem menschlichen Entwickler den Versuch eines gescheiterten Versuchs.
Die Behauptung des Papers: Indem es als Türsteher fungiert, filtert dieses Tor die „unmöglichen“ Bugs heraus. Es erhöht die Erfolgsquote der Bugs, die tatsächlich durchkommen, von etwa 11 % auf 21 % (unter Verwendung spezifischer Richtlinien).

Tor 2: Die „Patch Validation“ (Der Qualitätskontrolleur)

Was es tut: Wenn der Roboter tatsächlich versucht, einen Bug zu beheben und einen Patch produziert, prüft dieses Tor das Ergebnis.
Die Analogie: Stellen Sie sich vor, der Roboter hat gerade ein neues Motorteil gebaut. Bevor Sie es einbauen, sieht ein Qualitätskontrolleur den Bauplan. Der Inspektor schaut nicht nur auf das Teil; er schreibt zuerst ein „Rezept“ dafür auf, wie ein perfektes Teil basamentierend auf der Problembeschreibung aussehen sollte. Dann vergleicht er das Teil des Roboters mit diesem Rezept.
Wie es funktioniert:
1. Die KI schreibt eine „Spezifikation“ (einen Satz von Regeln für eine korrekte Korrektur) basierend auf dem Bug-Report.
2. Eine zweite KI betrachtet die tatsächliche Code-Änderung des Roboters und die Spezifikation.
3. Sie vergibt eine Bewertung: „Das sieht gut aus“, „Das sieht schlecht aus“ oder „Ich bin mir nicht sicher“.
4. Wenn die Bewertung zu niedrig ist, wird der Patch abgeleht.
Die Behauptung des Papers: Dieses Tor fängt die Fehler des Roboters ab. Selbst wenn der Roboter versucht, einen Bug zu beheben, kann dieses Tor sagen: „Nein, das ist nicht die richtige Korrektur.“ Dies allein kann die Erfolgsquote der gezeigten Patches auf etwa 29 % steigern.

Die magische Kombination: Der Trichter

Wenn Sie beide Tore zusammen verwenden, wirken sie wie ein hocheffizienter Trichter.

Tor 1 stoppt die unmöglichen Probleme, bevor sie in das System gelangen.
Tor 2 stoppt die schlechten Lösungen, bevor sie das System verlassen.

Die Ergebnisse:

Baseline: Ohne jegliche Tore sehen Entwickler nur 1 von 10 Mal (11 %) eine funktionierende Korrektur.
Mit beiden Toren: Wenn Sie die Tore streng einstellen (nur die allerbesten Kandidaten zeigen), sehen Entwickler 1 von 2 Mal (53 %) eine funktionierende Korrektur.
Der Kompromiss: Sie müssen bereit sein, insgesamt weniger Bugs anzuzeigen. Das System filtert viele Bugs heraus, um sicherzustellen, dass die wenigen, die es doch zeigt, von hoher Qualität sind.

Was ist mit maschinengenerierten Bugs?

Das Paper hat dies auch an Bugs getestet, die automatisch von Computern gefunden wurden (wie „Null Pointer Exceptions“ oder Speicherfehler). Diese Bugs kommen meist mit klaren Anweisungen (wie einem Stack Trace).

Für diese wurde das „Tor 1“ (der Türsteher) nicht benötigt, da der Computer bereits weiß, dass diese behebbar sind.
Dennoch half der „Qualitätskontrolleur“ (Tor 2) dennoch, indem er die Erfolgsquote der akzeptierten Patches signifikant steigerte.

Zusammenfassung

Dieses Paper behauptet nicht, den Roboter besser darin zu machen, Bugs zu beheben. Es behauptet statlich, den Prozess des Zeigens von Korrekturen an Menschen viel intelligenter zu machen. Indem zwei KI-„Gatekeeper“ den Lärm herausfiltern, hören Entwickler auf, Zeit mit schlechten Ideen zu verschwenden, und beginnen, dem automatisierten System wieder zu vertrauen.

Kurz gesagt: Es geht nicht darum, mehr Bugs zu beheben; es geht darum, die richtigen Bugs zu beheben, damit Menschen nicht müde werden, sich die falschen anzusehen.

Technisches Resümee: Abstain und Validate: Eine Dual-LLM-Policy zur Rauschreduzierung in agentischer Programmbereparatur

Problemstellung

Agentische automatisierte Programmbereparatur-Systeme (Automated Program Repair, APR) haben die Fähigkeit demonstriert, komplexe, repository-weite Bugs zu lösen, und dabei hohe Pass@1-Raten auf Benchmarks wie SWE-Bench-Verified erreicht. Die Bereitstellung dieser Systeme in industriellen Umgebungen stellt jedoch eine kritische Herausforderung dar: das „Rauschen“-Problem. Selbst bei sich verbessernden Lösungsraten ist ein erheblicher Teil der generierten Patches unwahrscheinlich von menschlichen Entwicklern akzeptiert zu werden. Das Präsentieren dieser qualitativ minderwertigen oder unlösbaren Patches verschwendet wertvolle Zeit der Entwickler, untergräbt das Vertrauen in automatisierte Werkzeuge und verursacht unnötige Rechenkosten. Das Kernproblem, das hier adressiert wird, ist die Frage, wie Bugs, die ein APR-System wahrscheinlich nicht beheben kann, vor den Reparaturversuchen herauszufiltern, und wie Patches, die unwahrscheinlich korrekt sind, nach der Generierung abzulehnen ist, um das Signal-Rausch-Verhältnis für menschliche Reviewer zu optimieren.

Methodik

Die Autoren schlagen ein Dual-LLM-Policy-Framework vor, das aus zwei komplementären Phasen besteht: Bug Abstention (Fehlervermeidung) und Patch Validation (Patch-Validierung).

1. Bug Abstention Policy

Diese Policy operiert vor dem Reparaturversuch des Agenten. Sie fungt als Vorfilter, um Bugs auszuschließen, die als unwahrscheinlich durch das System lösbar eingestuft werden.

Input: Nur der Bug-Report (Titel, Beschreibung, Metadaten). Die Policy greift nicht auf den Codebase oder den Verlauf des Agenten zu, um die Effizienz zu wahren.
Mechanismus: Ein LLM sagt die Wahrscheinlichkeit eines erfolgreichen Reparaturversuchs voraus. Die Autoren formalisieren dies als Schätzung der empirischen Erfolgswahrscheinlichkeit ( $\hat{\pi}_b$ ) eines Bugs $b$ .
Repräsentationen: Es wurden zwei Prompting-Strategien evaluiert:
- Instruction Prompting ohne Leitlinien: Basisches Bug-Report-Input.
- Instruction Prompting mit Leitlinien: Ergänzt durch menschlich abgeleitete Kriterien (z. B. „Klares Problem & Aktion“, „Präzise Code-Lokalisierung“), um das LLM bei der Bewertung der Schwierigkeit zu leiten.
Entscheidung: Wenn die vorhergesagte Wahrscheinlichkeit $P_a(b)$ unter einem konfigurierbaren Schwellenwert $\tau$ fällt, sieht das System von einem Reparaturversuch ab („abstain“), was Rechenleistung spart und die Generierung qualitativ minderwertiger Patches verhindert.

2. Patch Validation Policy

Diese Policy operiert nachdem der Agent einen Reparaturverlauf generiert hat. Sie bewertet, ob ein spezifischer Patch eine korrekte Lösung darstellt.

Input: Der Bug-Report, der Verlauf des Agenten (Gedanken und Aktionen), der generierte Patch (Diff) und die Testergebnisse.
Mechanismus: Ein mehrstufiger Ansatz:
1. Deterministische Checks: Build- und Test-Regressionsprüfungen, um Patches mit offensichtlichem Scheitern zu entfernen.
2. Generierung einer Fix-Spezifikation: Ein LLM generiert eine „Fix-Spezifikation“ – einen Satz von Kriterien für eine korrekte Lösung, die ausschließlich auf dem Bug-Report und den Original-Quelldateien basiert (ohne Ground-Truth-Wissen).
3. LLM-Urteil: Ein zweiter LLM-Aufruf bewertet den Versuch des Agenten anhand der generierten Spezifikation, des Patches und der Testergebnisse.
Output: Ein Tripel bestehend aus einem binären Urteil (behoben/nicht behoben), einer Erläuterung in natürlicher Sprache und einem Konfidenzwert, der aus den Token-Level Log-Wahrscheinlichkeiten abgeleitet wird.
Entscheidung: Patches können basierend auf dem binären Urteil oder einem Perzentil-basierten Cutoff des Konfidenzwerts gefiltert werden, was eine anpassbare Strenge ermöglicht.

3. Kombiniertes Framework

Die beiden Policies sind sequenziell zusammengesetzt: Bug Abstention filtert den initialen Bug-Satz, das APR-System versucht Reparaturen an den verbleibenden Bugs, und Patch Validation filtert die resultierenden Patches. Dies erzeugt einen konfigurierbaren Trichter für das Developer-Review.

Evaluierung und Ergebnisse

Die Policies wurden auf drei industriellen Datensätzen aus Googles Codebase evaluiert:

Human-Reported Bugs (174 Bugs): Bekannte Ground-Truth-Fixes und Fail-to-Pass-Reproduktionstests.
Machine-Reported NPE Bugs (198 Bugs): Null Pointer Exceptions aus dem Live-Betrieb mit Stack Traces.
Sanitizer-Reported Bugs (50 Bugs): Speicherfehler und Data Races mit bekannten Reproduktionstests.

Wichtigste Erkenntnisse:

Human-Reported Bugs:
- Baseline: Das ungefilterte System erreichte eine Fail-to-Pass@1-Rate von 11,29 %.
- Bug Abstention: Durch die Verwendung von Leitlinien ( $r_2$ ) stieg die gefilterte Fail-to-Pass@1-Rate auf 21,05 %.
- Patch Validation: Unter Verwendung einer strikten Perzentil-basierten Validierung (90. Perzentil) stieg die gefilterte Fail-to-Pass@1-Rate auf 29 % (ein Gewinn von 15 Prozentpunkten gegenüber der Baseline).
- Kombinierte Policy: Der duale Policy-Ansatz erreichte eine gefilterte Fail-to-Pass@1 von 53 % (ein Gewinn von 39 Prozentpunkten) mit der strengsten Konfiguration (combined-p90), was die Erfolgsrate für die den Entwicklern gezeigten Patches effektiv auf 1-zu-2 steigerte.
Machine-Reported Bugs:
- Die Patch-Validierung verbesserte die gefilterten Accept@1-Raten für NPE-Bugs signifikant (von 0,38 auf 0,62) und für Sanitizer-Bugs (um bis zu 15 Prozentpunkte über der Baseline).
Trade-offs: Die Studie hebt den Zielkonflikt zwischen dem Volumen der versuchten Bugs und der Präzision der Patches hervor. Strengeres Filtern (z. B. 90. Perzentil) reduziert die Anzahl der Entwicklern präsentierten Bugs drastisch (z. B. von 174 auf 12), gewährleistet aber eine wesentlich höhere Erfolgsrate für die verbleibenden Fälle.

Zentrale Beiträge

Bug Abstention Policy: Ein neuartiger Pre-Repair-Filtermechanismus, der LLMs nutzt, um die Reparierbarkeit basierend ausschließlich auf Bug-Reports vorherzusagen und somit aussichtslose Reparaturversuche zu verhindern.
Patch Validation Policy: Ein mehrstufiges Post-Repair-Bewertungsframework, das „Fix-Spezifikationen“ nutzt, die ohne Ground-Truth-Wissen generiert wurden, um Kandidaten-Patches zu filtern.
Umfassende industrielle Evaluierung: Eine umfassende Studie über drei verschiedene Bug-Kategorien (Human-Reported, NPE und Sanitizer), welche die komplementäre Natur der beiden Policies demonstriert.
Metrik-Innovation: Einführung von „filtered success@k“, einer Metrik, die Erfolgsraten nur auf der Teilmenge der durch die Policies erlaubten Bugs und Patches evaluiert und somit ein realistischeres Maß für die Developer Experience bietet.

Bedeutung und Behauptungen

Das Paper behauptet, dass dieser Zwei-Policy-Ansatz einen praktikablen Weg zur zuverlässigen, industriellen Skalierung agentischer APR-Systeme aufzeigt. Durch die signifikante Reduzierung des Rauschens unproduktiver Reparaturversuche adressiert das Framework den kritischen Engpass des Entwicklervertrauens und des Zeitmanagements.

Die Autoren betonen, dass die allgemeine Bug-Lösungsrate aufgrund des aggressiven Filterns zwar sinken mag (da auch lösbare Bugs abgelehnt werden), die Qualität der den Entwicklern präsentierten Patches jedoch dramatisch steigt. In der Praxis transformiert dies die Erfahrung des Entwicklers von der Überprüfung eines Patches mit einer Erfolgschance von etwa ~10 % hin zur Überprüfung eines Patches mit einer Erfolgschance von etwa ~50 % (unter strengen Einstellungen) oder ~33 % (unter permissiven Einstellungen). Dieser Wandel wird als essenziell für die Akzeptanz von KI-Werkzeugen im Software Engineering angesehen, da er den Output automatisierter Systeme mit der begrenzten Kapazität menschlicher Reviewer in Einklang bringt. Die Arbeit beansprucht nicht, die fundamentale Schwierigkeit der Reparatur aller Bugs zu lösen, sondern optimiert die Interaktion zwischen agentischen Systemen und menschlichen Entwicklern, indem sie sicherstellt, dass nur die vielversprechendsten Kandidaten die menschliche Phase erreichen.