💬 NLP

Beyond "What to Retrieve": Uncertainty in Retrieval-Augmented Code Generation

Dit artikel introduceert OpenCoder, een onzekerheidsbewust framework dat bronspecifieke onzekerheid schat en benut om heterogene retrieval-bewijslast te filteren en te rangschikken, waardoor de correctheid van repository-niveau codegeneratie wordt verbeterd, terwijl het aantoont dat de voordelen afhankelijk zijn van de specifieke LLM-backend en de interacties tussen de bewijslast.

Oorspronkelijke auteurs: Chandan Kumar Sah, Xiaoli Lian, Li Zhang

Gepubliceerd 2026-07-29

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Chandan Kumar Sah, Xiaoli Lian, Li Zhang

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 complexe LEGO-kasteel probeert te bouwen, maar je hebt slechts één instructieboekje gekregen dat alleen de voordeur behandelt. Je kent de deur, maar het kasteel heeft ramen, een dak en een geheime ondergrondse tunnel nodig. Dit is de dagelijkse strijd voor Kunstmatige Intelligentie (AI) wanneer het probeert computercode te schrijven voor echte projecten. Hoewel AI ongelooflijk goed is geworden in het schrijven van kleine, geïsoleerde stukjes code, raakt het vaak de weg kwijt wanneer het wordt gevraagd om iets te bouwen dat past in een enorme, bestaande software-"buurt". Om dit op te lossen, gebruiken onderzoekers een techniek genaamd Retrieval-Augmented Generation (RAG). Denk aan RAG als het geven van een superkrachtige zoekmachine aan de AI: voordat de AI een enkele regel code schrijft, zoekt hij naar vergelijkbare projecten, controleert hij de regels van de buurt (de specifieke conventies van het project) en vindt hij de juiste hulpmiddelen (API's) om te gebruiken.

Er zit echter een addertje onder het gras. Alleen omdat de zoekmachine veel informatie vindt, betekent dat niet dat die informatie nuttig is. Soms vindt de AI een stuk code dat er vergelijkbaar uitziet, maar dat eigenlijk het project breekt; andere keren vindt hij een hulpmiddel dat niet past bij de specifieke taak. De informatie is aanwezig, maar is ruisachtig, tegenstrijdig of gewoon simpelweg fout. De grote vraag die onderzoekers zich hebben gesteld is: Hoe leren we de AI niet alleen om de juiste informatie te vinden, maar ook om te weten hoeveel hij die moet vertrouwen? Als de AI het verschil niet kan zien tussen een behulpzame aanwijzing en een misleidende rode haring, zal hij een kasteel bouwen dat instort zodra je de deur probeert te openen.

Hier komt een nieuw onderzoek van onderzoekers van de Beihang Universiteit in beeld. Zij introduceren een systeem genaamd OpenCoder, dat fungeert als een sceptische, uiterst georganiseerde projectmanager voor de AI. In plaats van blindelings elke stuk informatie te vertrouwen die de zoekmachine vindt, wijst OpenCoder een "twijfelscore" toe aan elke enkele aanwijzing. Het vraagt zich af: "Hoe onzeker zijn we dat deze API de juiste is?" of "Hoe waarschijnlijk is het dat deze vergelijkbare code botst met ons project?". Door onzekerheid niet als een bug, maar als een nuttig signaal te behandteren, filtert OpenCoder de ruis weg, rangschikt de aanwijzingen op basis van hoe betrouwbaar ze lijken, en weet zelfs wanneer het moet stoppen en zijn eigen fouten moet herstellen.

De onderzoekers testten dit systeem door de AI te vragen code te schrijven voor 32 verschillende realtime taken. Ze ontdekten dat wanneer ze een krachtig AI-model genaamd GPT gebruikten, OpenCoder het succespercentage van de uiteindelijke code aanzienlijk verhoogde van 56,25% (met standaard zoekmethoden) naar 78,13%. Echter, de onderzoekers ontdekten een cruciale nuance: deze verbetering kwam overeen met de prestaties van een controlegroep die standaard zoeken gebruikte maar een "verifieer-en-herstel"-stap toevoegde. Dit suggereert dat hoewel de onzekerheidsfiltering van OpenCoder hielp, de enorme sprong in succes grotendeels werd gedreven door het vermogen van het systeem om fouten te verifiëren en te herstellen, in plaats van alleen door het filteren alleen. De "secret sauce" was niet alleen het vinden van meer informatie; het was het vermogen van het systeem om te zeggen: "Dit specifieke stuk bewijs ziet er wankel uit, dus laten we het negeren," en "Dit andere stuk ziet er solide uit, dus laten we het gebruiken," allemaal terwijl er een vangnet was om fouten op te vangen.

Het verhaal is echter geen simpel "AI wint voor altijd". De onderzoekers merkten zorgvuldig op dat dit succes sterk afhangt van welk AI-brein het werk doet. Toen ze GPT vervingen door een ander model genaamd Gemini, waren de resultaten veel minder duidelijk. De verbeteringen waren niet statistisch significant, wat suggereert dat de "onzekerheidsradar" van OpenCoder anders werkt afhankelijk van de persoonlijkheid van de AI. Bovendien liep het systeem tegen een muur aan wanneer het project te weinig informatie miste. In deze gevallen van onvolledig bewijs presteerde een standaard systeem met verificatie en herstel er daadwerkelijk beter dan OpenCoder. Dit geeft aan dat wanneer de zoekmachine de noodzakelijke hulpmiddelen niet kan vinden om überhaupt te beginnen, de filtermechanismen van OpenCoder soms de weinige beschikbare fragmenten bewijs kunnen onderdrukken, in plaats van de uiteindelijke beslissing te verbeteren.

De studie ontdekte ook iets verrassends over hoe verschillende soorten informatie samenwerken. Je zou denken dat het hebben van "vergelijkbare code", "projectcontext" en "API-kennis" altijd beter is dan het hebben van slechts één van de drie. Maar de onderzoekers vonden dat er geen universele regel is. Soms maakte het toevoegen van "vergelijkbare code" de AI juist in de war, tenzij het gepaard ging met de juiste "projectcontext". Het is alsof je een kaart, een kompas en een GPS hebt: als je alleen de GPS hebt, kun je verdwalen; als je de kaart en het kompas hebt maar geen GPS, kun je prima uit de voeten; maar als je alle drie hebt en ze spreken elkaar tegen, kun je in cirkels gaan lopen. De waarde van elke aanwijzing hangt volledig af van welke andere aanwijzingen aanwezig zijn.

Om dit te laten werken, voert OpenCoder een vijfstappen-dans uit. Ten eerste bouwt het een bibliotheek van alle regels en hulpmiddelen van het project. Ten tweede breekt het de gebruikersaanvraag af in kleine stappen. Derde gaat het op jacht naar aanwijzingen, maar deze keer scoort het ze op basis van hoe "onzeker" ze aanvoelen. Ten slotte genereert het de code, maar houdt het nauwlettend oog op de "onzekerheidsscore" om het gebruik van wankele aanwijzingen te vermijden. En vijf, en misschien wel het belangrijkste, fungeert het als zijn eigen kwaliteitscontroleur. Het draait de code door een reeks tests. Als de code faalt, geeft het niet zomaar op; het identificeert de fout en probeert de code te herstellen op basis van die validatiefeedback.

Uiteindelijk suggereert het artikel dat de toekomst van AI-codering niet alleen gaat over het slimmer maken van de AI of het geven van meer data aan de AI. Het gaat erom de AI te leren bescheiden en kritisch te zijn. Door onzekerheid te behandelen als een instrument om beslissingen te sturen — het filteren van slechte data, het verifiëren van de output en het herstellen van fouten tijdens het proces — kunnen systemen zoals OpenCoder betrouwbaardere software bouwen. Maar zoals de onderzoekers waarschuwen, is dit geen toverstaf die in elke situatie werkt. Het werkt het best wanneer de AI over voldoende goede informatie beschikt en wanneer het specifieke AI-model is afgestemd om de "twijfelscores" correct te begrijpen. Voor nu is OpenCoder een krachtige stap voorwaarts, die bewijst dat weten wat je niet weet soms het belangrijkste deel is van het oplossen van de puzzel.

Technisch overzicht: Voorbij "Wat te ophalen": Onzekerheid in Retrieval-Augmented Code Generation

Probleemstelling

Repository-niveau codegeneratie vereist dat Large Language Models (LLM's) implementaties synthetiseren die rekening houden met cross-file afhankelijkheden, projectconventies en private API's. Hoewel Retrieval-Augmented Generation (RAG) de beperking van parametrische kennis aanpakt door extern repository-bewijs aan te leveren, richten bestaande benaderingen zich primair op het optimaliseren van wat voor informatie wordt opgehaald (bijv. vergelijkbare code, repository-context, API-kennis). Ze negeren grotendeels de inherente onzekerheid die gepaard gaat met dit bewijsmateriaal.

Gevolgen van de opgehaalde bewijslast zijn vaak heterogeen en onbetrouwbaar: vergelijkbare codevoorbeelden kunnen semantisch gerelateerd zijn maar functioneel incompatibel; repository-context kan redundante of conflicterende afhankelijkheden bevatten; en API-kennis kan incompleet of onjuist geschaafd zijn. Huidige methoden optimaliseren de relevantie van de retrieval zonder expliciet te modelleren hoe de onzekerheid in deze bronnen de downstream generatie, verificatie en reparatie beïnvloedt. Bijgevolg kan het combineren van aanvullend bewijs ruis introduceren en fouten in de retrieval propageren, wat leidt tot uitvoerbare code die nog steeds aanzienlijk misbruik van API's of functionele defecten bevat.

Methodologie: OpenCoder

De auteurs introduceren OpenCoder, een onzekerheidsbewust framework dat is ontworpen om onzekerheid te behandelen als een actiegericht controlesignaal in plaats van een post-hoc betrouwbaarheidsscore. Het framework werkt via vijf fasen:

Repository Kennis & Onzekerheidsprofilering: Bouwt een index die drie bronnen van bewijs bevat: projectspecifieke API's ( $A$ ), contextuele repository-code ( $X$ ) en semantisch vergelijkbare codevoorbeelden ( $S$ ).
Query Onzekerheidsdecompositie: Decomponeert de gebruikersquery in implementatiestappen en voorspelt het benodigde bewijs voor elke stap.
Onzekerheidsbewuste Multi-Source Retrieval: Haalt kandidaten op uit $A$ $A$ , $X$ $X$ en $S$ $S$ . Cruciaal is dat OpenCoder een bronspecifieke onzekerheidsscore $u_m(e|q) \in [0,1]$ $u_{m} (e ∣ q) \in [0, 1]$ toekent aan elk opgehaald item, waarbij hogere waarden duiden op een lagere betrouwbaarheid in relevantie, volledigheid of compatibiliteit.
- Bewijs wordt gescoord met een combinatie van cosine similarity ( $r_m$ ), voorspelde bron-intent gewicht ( $w_m$ ) en onzekerheid: $\gamma_m(e|s) = r_m \cdot w_m \cdot \max\{0, 1 - \alpha u_m(e)\}$ .
- Bewijs met een lage betrouwbaarheid wordt gefilterd, en de resterende items worden gededupliceerd en gerangschikt onder een gedeeld contextbudget.
Onzekerheidsgestuurde Codegeneratie: De LLM genereert kandidaat-code geconditioneerd op de query, de gefilterde bewijsmset en de bron-gewijze onzekerheidstrace.
Verificatie & Onzekerheidsmitigatie: Gegenereerde kandidaten ondergaan statische controles en uitvoerbare tests. De eerste passerende kandidaat wordt geselecteerd. Als geen enkele ruwe kandidaat slaagt, identificeert het systeem de "mode" kandidaat (uit de grootste zelfconsistentie-groep) en voert maximaal twee ronden van validatiegestuurde reparatie uit.

Het framework maakt ook gebruik van Target-Aware API Refinement om zelf-gehaalde, redundante of intent-incompatibele API's te verwijderen vóór de generatie.

Belangrijkste Bijdragen

Formulering: Het artikel formuleert repository-niveau codegeneratie als besluitvorming onder onzekerheid over heterogene bewijslast, waarmee het verder gaat dan eenvoudige relevantieranking.
Framework: OpenCoder is een verenigd systeem dat bronspecifieke onzekerheid schat en deze operationaliseert over bewijsfiltering, multi-source integratie, generatie, verificatie en reparatie.
Factoriële Analyse: Door middel van een volledige factoriële analyse van API-kennis, repository-context en vergelijkbare codevoorbeelden, demonstreren de auteurs dat de bruikbaarheid van retrieval interactie-afhankelijk is. Er is geen universele additieve ranking van bronnen; de waarde van een specifieke bron hangt af van het begeleidende bewijs en de LLM-backend.
Gecontroleerde Evaluatie: De auteurs voeren een rigoureuze, gematchte evaluatie uit over GPT en Gemini backends op uitvoerbare repository-niveau taken, waarbij het effect van onzekerheidsbewuste verwerking isoleert van downstream verificatie en reparatie.

Experimentele Resultaten

De evaluatie maakt gebruik van een uitgebreide set van 32 gematchte RepoExec-inline taken en een stresstest op 10 deel-context ExecRepoBench taken.

GPT Prestaties: Op de 32-taken RepoExec-inline set verbeterde OpenCoder de correctheid van de geselecteerde output van 56,25% (Baseline RAG) naar 78,13% (een winst van 21,88 procentpunt, nominale $p = .039$ ). Het kwam echter gelijk te staan met de RAG + Verify/Repair controle (die dezelfde bewijslast gebruikt maar geen onzekerheidsbewuste filtering heeft), wat suggereert dat de winst ten opzichte van Baseline RAG grotendeels wordt gedreven door het verificatie/reparatiebudget in plaats van door onzekerheidsfiltering alleen.
Gemini Prestaties: Voor Gemini waren de verschillen tussen OpenCoder, Baseline RAG en de controle niet statistisch ondersteund. De controle (RAG + Verify/Repair) presteerde het sterkst over de meeste metrieken.
Interactie-effecten: De factoriële analyse (RQ1) onthulde dat geen enkele bewijsbron een statistisch significant marginaal effect had op de prestaties. In plaats daarvan werden significante cross-source interacties waargenomen (bijv. vertoonden repository-context en vergelijkbare codevoorbeelden een positieve interactie voor GPT).
API Retrieval: Target-aware refinement verbeterde de API-set retrieval aanzienlijk, waarbij de macro F1 steeg van 43,4% naar 64,8% voor GPT en naar 59,1% voor Gemini.
Randvoorwaarden: In de context-beperkte ExecRepoBench stresstest presteerde de RAG + Verify/Repair controle aanzienlijk beter dan OpenCoder. Dit geeft aan dat wanneer repository-bewijs incompleet is, onzekerheidsbewuste filtering nuttige alternatieven kan onderdrukken in plaats van ze te verbeteren.

Betekenis en Claims

Het artikel claimt dat onzekerheid het meest nuttig is niet als een geïsoleerde betrouwbaarheidsschatting, maar als een operationeel controlesignaal gekoppeld aan bewijsfusie, uitvoerbare validatie en reparatie.

Backend Afhankelijkheid: De voordelen van OpenCoder zijn afhankelijk van de backend. Hoewel het de selectie van GPT-output aanzienlijk verbeterde ten opzate van plain RAG, toonde het geen statistisch significante voordelen ten opzichte van een verificatie- en reparatiecontrole, noch toonde het duidelijke voordelen voor Gemini.
Volledigheid van Bewijs: De effectiviteit van het framework is afhankelijk van de volledigheid van het repository-bewijs. In scenario's met incompleet bewijs kan het onzekerheidsmechanisme onbedoeld noodzakelijke informatie wegfilteren.
Actiegerichte Controle: De primaire bijdrage is de verschuiving van het optimaliseren van wat er wordt opgehaald naar het modelleren van hoe betrouwbaar het opgehaalde bewijs is, waarbij dat signaal wordt gebruikt om filtering en generatie te sturen.

De auteurs concluderen dat hoewel OpenCoder het potentieel van onzekerheidsbewuste integratie demonstreert, de voordelen afhankelijk zijn van de specifieke LLM-backend en de kwaliteit/volledigheid van het opgehaalde repository-bewijs. Ze benadrukken dat gegenereerde code nog steeds beoordeling door ontwikkelaars en projectspecifieke testen vereist.