🤖 AI

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

Dit artikel introduceert een dual-LLM-beleidskader dat bug-onthouding en patch-validatie combineert om ruis aanzienlijk te verminderen en succespercentages te verbeteren in industriële schaal van agentische Automated Program Repair door onwaarschijnlijke bugs en suboptimale patches te filteren vóór menselijke beoordeling.

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

Gepubliceerd 2026-01-30

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

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

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer getalenteerde, maar lichtelijk overijverige robotassistent hebt genaamd "Repair-Bot". Jouw taak is om duizenden kapotte dingen te repareren in een gigantische loods (de codebase van het bedrijf). Repair-Bot is geweldig in het proberen te repareren van zaken, maar het is ook geneigd tot fouten maken, tijd te verspillen en oplossingen voor te stellen die eigenlijk niet werken.

Als je Repair-Bot alles laat laten zien wat het probeert te repareren, zou je overweldigd raken. Je zou de hele dag bezig zijn met het bekijken van slechte suggesties, gefrustreerd raken en uiteindelijk het vertrouwen in de robot verliezen.

Deze paper introduceert een twee-stappen "Gatekeeper"-systeem om de ruis te stoppen voordat het jouw bureau bereikt. Denk aan een uitsmijter bij een club en een kwaliteitsinspecteur in een fabriek.

Het Probleem: Te Veel Ruis

In de wereld van software zijn "bugs" fouten in de code. Geautomatiseerde systemen (genoemd Agentic APR) proberen deze te repareren. Maar deze systemen proberen vaak bugs te repareren die te moeilijk zijn voor hen, of ze genereren "patches" (codewijzigingen) die er goed uitzien, maar eigenlijk fout zijn.

Het Resultaat: Ontwikkelaars verspillen tijd aan het beoordelen van slechte fixes.
Het Doel: Laat de ontwikkelaar alleen de fixes zien die waarschijnlijk wel werken.

De Oplossing: Het Twee-Poorten Systeem

De auteurs stellen twee policies voor die fungeren als filters in een trechter.

Poort 1: De "Bug Abstention" (De Uitsmijter)

Wat het doet: Voordat de robot zelfs maar een bug probeert te repareren, kijkt deze poort naar het bugrapport (de beschrijving van het probleem).
De Analogie: Stel je voor dat je een uitsmijter bent bij een club. Je kijkt naar de persoon die binnen wil komen (de bug). Als de persoon er te verward uitziet, de beschrijving te vaag is, of het probleem onmogelijk lijkt op te lossen met de middelen die je hebt, zeg je: "Sorry, je kunt niet naar binnen."
Hoe het werkt: Een AI-model leest het bugrapport en vraagt: "Kan onze robot dit daadwerkelijk repareren?" Als het antwoord "waarschijnlijk niet" is, onthoudt het systeem zich (weigert te proberen). Het bespaart de energie van de robot en, belangrijker nog, het bespaart de menselijke ontwikkelaar van een mislukte poging te zien.
De Claim van de Paper: Door te fungeren als een uitsmijter, filtert deze poort de "onmogelijke" bugs eruit. Het verhoogt de succesratio van de bugs die wel doorlaten van ongeveer 11% naar 21% (met behulp van een specifieke set richtlijnen).

Poort 2: De "Patch Validation" (De Kwaliteitsinspecteur)

Wat het doet: Als de robot wél een bug probeert te repareren en een patch produceert, controleert deze poort het resultaat.
De Analogie: Stel je voor dat de robot een nieuw motoronderdeel heeft gebouwd. Voordat je het installeert, kijkt een kwaliteitsinspecteur naar het ontwerp. De inspecteur kijkt niet alleen naar het onderdeel; de inspecteur schrijft eerst een "recept" voor hoe een perfect onderdeel eruit zou moeten zien op basis van de probleembeschrijving. Vervolgens vergelijkt de inspecteur het onderdeel van de robot met dat recept.
Hoe het werkt:
1. De AI schrijft een "specificatie" (een set regels voor een correcte fix) op basis van het bugrapport.
2. Een tweede AI bekijkt de werkelijke codeverandering van de robot en de specificatie.
3. Het geeft een score: "Dit ziet er goed uit," "Dit ziet er slecht uit," of "Ik weet het niet zeker."
4. Als de score te laag is, wordt de patch afgewezen.
De Claim van de Paper: Deze poort vangt de fouten van de robot op. Zelfs als de robot een bug probeert te repareren, kan deze poort zeggen: "Nee, dat is niet de juiste fix." Dit alleen al kan de succesratio van getoonde patches verhogen naar ongeveer 29%.

De Magische Combinatie: De Trechter

Wanneer je beide poorten samen gebruikt, werken ze als een zeer efficiënte trechter.

Poort 1 stopt de onmogelijke problemen voordat ze het systeem binnengaan.
Poort 2 stopt de slechte oplossingen voordat ze het systeem verlaten.

De Resultaten:

Baseline: Zonder enige poorten zien ontwikkelaars slechts 1 op de 10 keer een werkende fix (11%).
Met Beide Poorten: Als je de poorten strikt instelt (alleen de allerbeste kandidaten tonen), zien ontwikkelaars 1 op de 2 keer een werkende fix (53%).
De Afweging: Je moet accepteren dat je minder bugs in totaal laat zien. Het systeem filtert veel bugs eruit om ervoor te zorgen dat de weinige die het wel laat zien, van hoge kwaliteit zijn.

Wat Betreft Machine-gegenereerde Bugs?

De paper heeft dit ook getest op bugs die automatisch door computers zijn gevonden (zoals "Null Pointer Exceptions" of geheugenfouten). Deze bugs komen meestal met duidelijke instructies (zoals een stack trace).

Voor deze gevallen hadden ze de "Uitsmijter" (Poort 1) niet nodig, omdat de computer al weet dat deze oplosbaar zijn.
Echter, de "Kwaliteitsinspecteur" (Poort 2) hielp nog steeds, wat de succesratio van geaccepteerde patches aanzienlijk verhoogde.

Samenvatting

Deze paper beweert niet dat de robot slimmer wordt in het repareren van bugs. In plaats daarvan beweert het dat het proces van het tonen van fixes aan mensen veel slimmer wordt gemaakt. Door twee AI "gatekeepers" te gebruiken om de ruis te filteren, stoppen ontwikkelaars met het verspillen van tijd aan slechte ideeën en beginnen ze weer te vertrouwen op het geautomatiseerde systeem.

Kortom: Het gaat niet om het repareren van meer bugs; het gaat om het repareren van de juiste bugs, zodat mensen niet moe worden van het kijken naar de verkeerde.

Technische Samenvatting: Abstain en Valideer: Een Dual-LLM Beleid voor het Verminderen van Ruis in Agentic Programmaherstel

Probleemstelling

Agentic Automated Program Repair (APR) systemen hebben het vermogen getoond om complexe, repository-niveau bugs op te lossen, waarbij ze hoge pass@1 rates behalen op benchmarks zoals SWE-Bench-Verified. Echter, het inzetten van deze systemen in industriële omgevingen brengt een kritieke uitdaging met zich mee: het "ruis"-probleem. Zelfs met verbeterende resolutiesnelheden is een aanzienlijk deel van de gegenereerde patches onwaarschijnlijk door menselijke ontwikkelaars geaccepteerd te worden. Het presenteren van deze kwalitatief lage of onhandelbare patches verspilt kostbare tijd van ontwikkelaars, ondermijnt het vertrouwen in geautomatiseerde tools en brengt onnodige computationele kosten met zich mee. Het kernprobleem dat wordt aangepakt is hoe men bugs die een APR-systeem waarschijnlijk niet zal kunnen oplossen vóór de herstelpogingen kan filteren, en hoe men patches die onwaarschijnlijk correct zijn na de generatie kan afwijzen, om zo de signaal-ruisverhouding voor menselijke reviewers te optimalen.

Methodologie

De auteurs stellen een dual-LLM beleidsframework voor bestaande uit twee complementaire stadia: Bug Abstention (Bug-onthouding) en Patch Validation (Patch-validatie).

1. Bug Abstention Policy

Dit beleid opereert vóór de repair agent een fix probeert uit te voeren. Het fungeert als een pre-filter om bugs uit te sluiten die onwaarschijnlijk door het systeem opgelost zullen worden.

Input: Alleen de bug report (titel, beschrijving, metadata). Het beleid heeft geen toegang tot de codebase of de trajectorie van de agent om efficiëntie te waarborgen.
Mechanisme: Een LLM voorspelt de waarschijnlijkheid van een succesvolle herstelpoging. De auteurs formaliseren dit als het schatten van de empirische succeswaarschijnlijkheid ( $\hat{\pi}_b$ ) van een bug $b$ .
Representaties: Twee prompt-strategieën werden geëvalueerd:
- Instruction Prompting zonder Richtlijnen: Basis bug report input.
- Instruction Prompting met Richtlijnen: Verrijkt met door mensen afgeleide criteria (bijv. "Duidelijk Probleem & Actie", "Precieze Code Lokalisatie") om de LLM te begeleiden bij de beoordeling van de moeilijkheidsgraad.
Beslissing: Als de voorspelde waarschijnlijkheid $P_a(b)$ onder een configureerbare drempelwaarde $\tau$ valt, onthoudt het systeem zich van een herstelpoging, wat rekenkracht bespaart en de generatie van kwalitatief lage patches voorkomt.

2. Patch Validation Policy

Dit beleid opereert nádat de agent een repair trajectorie heeft gegenereerd. Het beoordeelt of een specifieke patch een correcte fix is.

Input: De bug report, de trajectorie van de agent (gedachten en acties), de gegenereerde patch (diff), en de testresultaten.
Mechanisme: Een multi-stage aanpak:
1. Deterministische Checks: Build en regressietests om patches met overduidelijke fouten te verwijderen.
2. Fix Specification Generation: Een LLM genereert een "fix specificatie"—een set criteria voor een correcte fix gebaseerd alleen op de bug report en de originele bronbestanden (zonder kennis van de ground-truth).
3. LLM Judgment: Een tweede LLM-aanroep evalueert de poging van de agent tegenover de gegenereerde specificatie, de patch en de testresultaten.
Output: Een triplet bestaande uit een binaire beoordeling (fixed/not fixed), een natuurlijke taal uitleg, en een confidence score afgeleid van token-level log probabilities.
Beslissing: Patches kunnen gefilterd worden op basis van de binaire beoordeling of een percentiel-gebaseerde cutoff van de confidence score, wat een aanpasbare strengheid mogelijk maakt.

3. Gecombineerd Framework

De twee beleidsregels zijn sequentieel samengesteld: Bug Abstention filtert de initiële bug set, het APR-systeem probeert herstellen op de resterende bugs, en Patch Validation filtert de resulterende patches. Dit creëert een configureerbare trechter voor developer review.

Evaluatie en Resultaten

De beleidsregels werden geëvalueerd op drie industriële datasets uit de codebase van Google:

Human-Reported Bugs (174 bugs): Bekende ground-truth fixes en fail-to-pass reproductietests.
Machine-Reported NPE Bugs (198 bugs): Null pointer exceptions uit live deployment met stack traces.
Sanitizer-Reported Bugs (50 bugs): Geheugenfouten en data races met bekende reproductietests.

Belangrijkste Bevindingen:

Human-Reported Bugs:
- Baseline: Het ongefilterde systeem bereikte een fail-to-pass@1 rate van 11,29%.
- Bug Abstention: Gebruikmakend van richtlijnen ( $r_2$ ), steeg de gefilterde fail-to-pass@1 rate naar 21,05%.
- Patch Validation: Gebruikmakend van een strikte percentile-gebaseerde validatie (90ste percentiel), steeg de gefilterde fail-to-pass@1 rate naar 29% (een winst van 15 procentpunt over de baseline).
- Gecombineerd Beleid: De dual-policy aanpak bereikte een gefilterde fail-to-pass@1 van 53% (een winst van 39 procentpunt) met de strengste configuratie (combined-p90), wat de succesrate effectief verhoogde naar 1-op-2 voor de patches die aan developers worden getoond.
Machine-Reported Bugs:
- Patch validatie verbeterde de gefilterde accept@1 rates aanzienlijk voor NPE bugs (van 0,38 naar 0,62) en sanitizer bugs (tot 15 procentpunt boven de baseline).
Trade-offs: De studie benadrukt een trade-off tussen het volume aan geprobeerde bugs en de precisie van de gepresenteerde patches. Strengere filtering (bijv. 90ste percentiel) vermindert drastisch het aantal bugs dat aan developers wordt gepresenteerd (bijv. van 174 naar 12) maar garandeert een veel hogere succesrate voor de resterende bugs.

Belangrijkste Bijdragen

Bug Abstention Policy: Een nieuw pre-repair filtering mechanisme dat LLM's gebruikt om de herstelbaarheid te voorspellen op basis van enkel de bug reports, waardoor zinloze herstelpogingen worden voorkomen.
Patch Validation Policy: Een multi-stage post-repair beoordelingsframework dat gebruikmaakt van "fix specificaties" gegenereerd zonder ground-truth kennis om kandidaat patches te filteren.
Uitgebreide Industriële Evaluatie: Een uitgebreide studie over drie verschillende bug categorieën (human-reported, NPE, en sanitizer) die de complementaire aard van de twee beleidsregels aantoont.
Metrische Innovatie: Introductie van "filtered success@k", een metriek die succesrates evalueert op enkel de subset van bugs en patches die door de beleidsregels zijn toegestaan, wat een realistischer beeld geeft van de developer experience.

Betekenis en Claims

Het artikel beweert dat deze twee-beleid aanpak een praktisch pad biedt naar de betrouwbare, industriële schaalbare inzet van agentic APR-systemen. Door de ruis van onproductieve herstelpogingen aanzienlijk te verminderen, adresseert het framework de kritieke flessenhals van developer vertrouwen en tijdbeheer.

De auteurs benadrukken dat hoewel de algehele bug-resolutiesnelheid kan dalen door agressieve filtering (omdat sommige herstelbare bugs worden afgewezen), de kwaliteit van de gepresenteerde patches drastisch verbetert. In praktische termen transformeert dit de developer experience van het reviewen van een patch met een ~10% kans op succes naar het reviewen van een patch met een ~50% kans op succes (onder strikte instellingen) of ~33% (onder permissieve instellingen). Deze verschuiving wordt geargumenteerd als essentieel voor de adoptie van AI-tools in software engineering, omdat het de output van geautomatiseerde systemen afstemt op de beperkte capaciteit van menselijke reviewers. Het werk claimt niet alle fundamentele moeilijkheden van het repareren van alle bugs op te lossen, maar optimaliseert de interactie tussen agentic systemen en menselijke ontwikkelaars door ervoor te zorgen dat alleen de meest veelbelovende kandidaten de menselijke fase bereiken.