🤖 AI

Exploration Structure in LLM Agents for Multi-File Change Localization

Dit artikel stelt een niet-lineair, domeingeschikt parallel agentisch exploratieframework voor en evalueert dit voor het lokaliseren van multi-file wijzigingen in software-repositories, waarbij wordt aangetoond dat het lineaire sequentiële benaderingen aanzienlijk overtreft en concurrerende resultaten behaalt ten opzichte van veel grotere modellen op benchmarks zoals SWE-bench Pro.

Oorspronkelijke auteurs: Akeela Darryl Fattha, Kia Ying Chua, Lingxiao Jiang, Laura Wynter

Gepubliceerd 2026-06-11

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Akeela Darryl Fattha, Kia Ying Chua, Lingxiao Jiang, Laura Wynter

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 detective bent die een kapotte machine probeert te repareren. De machine is een enorm softwareproject (zoals een gigantische bibliotheek met code), en iemand heeft een fout (bug) gemeld. Jouw taak is om precies te vinden welke pagina's in de bibliotheek herschreven moeten worden om het probleem op te lossen.

Dit artikel gaat over hoe verschillende "AI-detectives" die pagina's opzoeken. De onderzoekers wilden zien of de manier waarop de detective zoekt belangrijker is dan hoe "slim" de detective is.

Hier is de uitsplitsing van hun studie met eenvoudige analogieën:

Het Probleem: De "Stap-voor-stap-tegen-de-muur"-valstrik

De meeste huidige AI-tools werken als een detective die door een bibliotheek loopt één gang tegelijk. Ze kiezen een plank, lezen een boek, en gaan dan naar de volgende plank.

De Fout: Als de bug eigenlijk een combinatie is van problemen in drie verschillende vleugels van de bibliotheek (bijv. de keuken, de tuin en de zolder), kan een detective die slechts één gang tegelijk doorloopt vast komen te zitten in de keuken, door zijn tijd (of geld) heen raken en nooit de tuin of de zolder controleren.
Het Idee van het Papier: Wat als we, in plaats van te lopen, drie verschillende specialisten zouden sturen om tegelijkertijd de keuken, de tuin en de zolder te controleren?

Het Experiment: De "Ansible" Bibliotheek

De onderzoekers testten dit op een specifiek softwareproject genaamd Ansible (denk aan dit als een zeer grote, georganiseerde bibliotheek). Ze creëerden een test waarbij ze de AI een foutrapport gaven en de AI vroegen om de bestanden te noemen die gerepareerd moesten worden.

Ze vergeleken vier soorten detectives:

De "Boekenwurm" (Plain LLM): Een slimme AI die veel boeken heeft gelezen, maar nog nooit in deze specifieke bibliotheek is geweest. Het moet gokken op basis van geheugen.
De "Solo Ontdekkingsreiziger" (RLM): Een AI die een sleutel tot de bibliotheek en een notitieblok krijgt. Het loopt naar binnen, opent deuren, leest bestanden één voor één en maakt onderweg aantekeningen.
Het "Team van Specialisten" (Domain Agents - Het Nieuwe Idee): Een AI-manager die eerst de secties van de bibliotheek in kaart brengt (Keuken, Tuin, Zolder). Wanneer er een bug binnenkomt, stuurt de manager direct een andere specialist naar elke relevante sectie om parallel te werken.
De "Super-Expert" (Codex): Een zeer grote, dure en krachtige AI-detective die wordt gebruikt als benchmark.

De Belangrijkste Bevindingen

1. Teamwork wint van alleen lopen
De "Team van Specialisten"-aanpak won met een enorme marge, ook al gebruikten ze een kleiner, goedkoper AI-model.

Analogie: Stel je voor dat je probeert een verloren sleutel te vinden in een stadion. De "Solo Ontdekkingsreiziger" loopt het hele stadion alleen af en raakt vermoeid. Het "Team" stuurt mensen naar de tribunes, het veld en de kiosk tegelijkertijd. Zij vinden de sleutel veel sneller en nauwkeuriger.
Resultaat: De team-aanpak vond de juiste bestanden veel beter dan de solo-wandelaar, zelfs toen de solo-wandelaar een groter brein had (een krachtiger AI-model).

2. Een detective een sleutel geven kan averechts werken
De onderzoekers dachten dat het de AI zou helpen als ze directe toegang kregen tot het bestandssysteem (de "Solo Ontdeker" met een sleutel). Verrassend genoeg maakte dit de situatie vaak erger.

Analogie: Als je een detective een sleutel geeft tot een gigantisch magazijn, kan hij afgeleid raken door het bekijken van duizenden irrelevante dozen (zoals testbestanden of oude concepten) en vergeten waar hij eigenlijk naar op zoek is. Hij raakt overweldigd door "ruis".
Resultaat: De AI met directe toegang gokte vaak te veel verkeerde bestanden, wat de nauwkeurigheid verlaagde. De "Team"-aanpak was slimmer omdat deze precies wist welke secties gecontroleerd moesten worden en de rommel negeerde.

3. Meer agenten betekenen niet altijd betere resultaten
Ze probeerden het team te dwingen om méér specialisten te raadplegen dan nodig is, puur voor de zekerheid.

Analogie: Het is alsof je de hele brandweer belt om een kleine kaars te blussen. Het blust het vuur niet sneller; het kost alleen maar veel meer geld (computer tokens) en zorgt voor veel verwarring.
Resultaat: "Agressief" zijn met het oproepen van meer agenten hielp niet bij het vinden van de bug; het verspilde alleen maar middelen.

4. De "Documentatie Blinde Vlek"
Ongeacht hoe slim de AI was, ze hadden allemaal moeite met het vinden van documentatiebestanden (de instructiehandleidingen).

Analogie: Als een gebruiker zegt: "De rode knop werkt niet", weet de AI dat hij de rode knop moet repareren. Maar de AI realiseert zich zelden dat ook de instructiehandleiding bijgewerkt moet worden om te vermelden: "De rode knop is nu defect". Het foutrapport vermeldde de handleiding niet, dus negeerde de AI deze.
Resultaat: Dit is een verborgen afhankelijkheid. De AI heeft een regel nodig die zegt: "Als je een knop repareert, moet je ook de handleiding controleren", zelfs als de gebruiker daar niet expliciet om vroeg.

De Conclusie

Het papier concludeert dat hoe een AI een codebase verkent, net zo belangrijk is als hoe slim de AI is.

Een klein, goed georganiseerd team van specialisten (Domain Agents) kan een gigantische, krachtige AI verslaan die doelloos ronddwaalt.
Echter, zelfs de beste AI-teams hebben moeite met "onzichtbare" wijzigingen, zoals het bijwerken van instructiehandleidingen, omdat de foutrapporten hier niet expliciet naar vragen.

Kortom: Structuur wint van brute kracht. Het organiseren van het zoekproces is de sleutel tot het oplossen van complexe softwarebugs.

Technische Samenvatting: Exploratiestructuur in LLM-agenten voor Multi-File Change Localization

Probleemstelling

Software engineering-problemen betreffen zelden wijzigingen in slechts één bestand; het oplossen van een bug vereist vaak aanpassingen in meerdere subsystemen (bijv. CLI, onderliggende bibliotheken, plugins en documentatie). Huidige Large Language Model (LLM) agenten hanteren doorgaans een lineaire, sequentiële exploratiestrategie, waarbij ze per stap één directory of bestand bezoeken. De auteurs postuleren dat deze lineaire aanpak een structurele mismatch vormt voor multi-file wijzigingen die over verschillende subsystemen verspreid zijn. Als een agent zijn stappen- of tokenbudget uitput tijdens het verkennen van het eerste subsysteem, worden daaropvolgende subsystemen die noodzakelijke "gold" bestanden bevatten, mogelijk nooit onderzocht.

Het paper adresseert drie kernonderzoeksvragen:

Is lineaire exploratie structureel beperkend voor multi-file wijzigingen, of kunnen sterkere modellen dit compenseren via betere stapselectie?
Verbetert het verlenen van ruwe toegang tot het bestandssysteem de lokalisatie betrouwbaar, of introduceert het navigatiefouten en over-voorspelling?
Verbetert het afdwingen van agressieve multi-agent consultatie de recall, of injecteert het ruis van irrelevante subsystemen?

Methodologie

Benchmark Constructie

De studie maakt gebruik van een persistent-sessie benchmark afgeleid van SWE-BENCH PRO, met de focus op de ansible/ansible repository.

Scope: Drie tijdvensters zijn geconstrueerd: mei–november 2020 (de originele gecureerde set), april–september 2025, en januari–mei 2026.
Stabiliteit: Alle instanties in een venster zijn verankerd aan een enkele base commit om een constante repository-status en exploratiekosten te garanderen.
Gold Sets: De auteurs vergelijken tegen de gecureerde SWE-BENCH PRO gold set (handmatig geselecteerde bronbestanden) en een uitgebreide PR-gebaseerde gold set (elk bestand dat door de oplossende Pull Request is aangeraakt, inclusief tests en changelogs).
Metrieken: Primaire metrieken zijn onder meer Micro-F1, de All-Gold rate (fractie van instanties waar alle grondwaarheid-bestanden worden voorspeld), en per-instantie macro F1.

Experimentele Systemen

De auteurs vergelijken vier families van LLM-systemen, waarbij ze exploratiestructuur isoleren van de basismodelcapaciteit door voor de meeste varianten hetzelfde kleine Haiku-klasse model te gebruiken:

Plain LLM (Geen Repository Toegang): Een enkele API-call die uitsluitend vertrouwt op de pre-training kennis van de repository-structuur.
Single-Agent Recursive Language Model (RLM): Een agent met een persistente Python REPL die sequentiële bestandssysteemtoegang mogelijk maakt (bijv. os.listdir, grep). Dit test de effectiviteit van sequentiële exploratie zonder domeinspecialisatie.
Domain-Agent Systeem (Voorgesteld): Een multi-agent architectuur bestaande uit:
- Initialisatie: Een root coordinator verkent de repository om coherente onderhoudsgebieden te identificeren (subsystemen zoals cli/, module_utils/, docs/) en start voor elk een persistente domain agent.
- Query-tijd: De coordinator stuurt relevante domain agents parallel aan om hun toegewezen regio's te verkennen.
- Bounded I/O: Grote bestanden en directory-lijsten worden beheerd in een programmeerbare omgeving; alleen compacte previews of specifieke regelbereiken komen in de LLM-context terecht om token-uitputting te voorkomen.
- Ablaties: Varianten zijn "no-spawn" (registry aanwezig maar geen parallelle dispatch) en "nudged" (afdwingen van agressieve consultatie).
External CLI Baseline: Gebruikt Codex 5.5 High, een veel groter frontier model, om een upper-bound referentie vast te stellen.
BM25 Baseline: Een klassiek lexicaal retrieval systeem dat $K$ varieert van 1 tot 30 om een precisie-recall envelop te genereren.

Belangrijkste Bijdragen en Bevindingen

1. Exploratiestructuur is een Cruciale Factor

De Domain-Agent aanpak, die exploratie langs repository-subsystemen paralleliseert, bereikt de hoogste Micro-F1 onder alle Haiku-klasse modellen met een grote marge.

Op de gecureerde 2020 benchmark bereikt de Domain-Agent (Haiku) een Micro-F1 van 0.447, wat aanzienlijk beter is dan de Plain LLM (Haiku) met 0.199 en de Single-Agent RLM (Haiku) met 0.151.
Het Domain-Agent systeem is competitief met het veel grotere Codex 5.5 High (Micro-F1 0.422 op gecureerd, 0.523 op PR-gebaseerd), ondanks het gebruik van een kleiner model.
Bevinding: Lineaire exploratie (RLM) is structureel beperkend; parallelle, domein-gescoped exploratie is noodzakelijk voor effectieve multi-file lokalisatie.

2. Naïeve Toegang tot het Bestandssysteem Kan Prestaties Verslechteren

In tegenstelling tot de intuïtie dat meer toegang gelijk staat aan betere prestaties, verslechterde het verlenen van ruwe toegang tot het bestandssysteem aan een enkele agent (RLM) de lokalisatie vergeleken met een Plain LLM bij gebruik van hetzelfde Haiku model.

RLM (Haiku): Micro-F1 0.151.
Plain LLM (Haiku): Micro-F1 0.199.
Oorzaak: De RLM had de neiging om testbestanden te over-voorspellen en in irrelevante hiërarchieën te navigeren, waardoor de context-budgetten uitgeput raakten en er fout-positieven ontstonden. De Plain LLM, die vertrouwde op getrainde structurele kennis, was conservatiever en preciezer.

3. Gedwongen Consultatie Helpt Niet

Het dwingen van de coordinator om meer agents te consulteren ("nudged" variant) verbeterde de recall niet meetbaar, maar verhoogde de tokenkosten aanzienlijk (van ~16M naar ~25M tokens).

Ongecontroleerd spawnen introduceerde ruis uit irrelevante subsystemen zonder extra gold files te herstellen.
Conclusie: Adaptieve dispatch (alleen relevante domeinen consulteren) is superieur aan gedwongen, agressieve consultatie.

4. De Documentatie Co-Evolutie Kloof

Een systematische fout werd waargenomen bij alle architecturen (inclusclusief het grote Codex model) met betrekking tot documentatiebestanden (docs/docsite/).

Miss Rate: Documentatiebestanden hadden een geaggregeerde miss rate van 73%, veel hoger dan codebestanden.
Reden: Issue-beschrijvingen beschrijven vaak wijzigingen in de gedrag van de broncode zonder expliciet te vermelden dat de documentatie bijgewerkt moet worden. Dit is een latente afhankelijkheid (logische koppeling) die huidige exploratiebeleid niet kan oplossen omdat het "signaal" ontbreekt in de inputtekst.

5. Generalisatie Over Tijd

De resultaten generaliseren over tijdvensters (2020, 2025, 2026).

De Domain-Agent aanpak presteerde consequent beter dan andere kleine-model baselines.
Op de 2025 en 2026 vensters presteerde de Domain-Agent aanpak zelfs beter dan Codex 5.5 High op de "smalle" (bron-alleen) gold set, hoewel Codex een voordeel behield op de "brede" (PR-gebaseerde) set vanwege de neiging om bredere bestandsets (inclusief tests) te voorspellen.

Betekenis en Claims

Het paper claimt dat exploratiestructuur een tweede-orde factor is die de beperkte modelcapaciteit kan compenseren. Door de agent te herstructureren om exploratie te paralleliseren langs repository-subsystemen en door gebruik te maken van bounded I/O, kan een klein model de prestaties van veel grotere frontier modellen evenaren of zelfs overtreffen bij multi-file lokalisatietaken.

De auteurs zijn echter bescheiden over de beperkingen:

Exploratie is niet voldoende: Geen enkele huidige architectuur kan betrouwbaar documentatiebestanden terugvinden omdat de issue-tekst de nodige aanwijzingen mist. Dit vereist een verandering in het routingbeleid (bijv. het dispatchen van doc-agents op basis van bronwijzigingen) in plaats van betere exploratie.
Toegang is geen panacee: Ruwe toegang tot het bestandssysteem zonder gerichte exploratiestrategieën kan de prestaties actief schaden door prompt-ambiguïteit te vergroten en over-voorspelling te veroorzaken.
Scope: De studie isoleert file localization van patch generation en test execution, wat betekent dat deze bevindingen specifisch van toepassing zijn op de "waar te wijzigen" fase van software engineering.

Het werk stelt vast dat voor multi-file change localization, domein-gescoped parallel spawning een superieur architecturaal patroon is aan lineaire sequentiële exploratie, mits het systeem naïeve bestandssysteemtoegang vermijdt en token-budgetten beheert via bounded I/O.