SWE-bench: Kunnen taalmodellen echte GitHub-problemen oplossen?

Het CodeAct-artikel hield een overtuigend pleidooi voor Python als het juiste actie-formaat voor LLM-agents. Maar het kiezen van het juiste actie-formaat is slechts de helft van het probleem — je moet ook aantonen dat agents de complexiteit van taken in de echte wereld aankunnen, en niet alleen gecureerde benchmarks. SWE-bench (arXiv:2310.06770), gepubliceerd door Carlos Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press en Karthik Narasimhan van Princeton en gepresenteerd op ICLR 2024, is de paper die het veld dwong deze kloof direct onder ogen te zien.

Het artikel

"SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" bouwt een benchmark van 2.294 taakinstanties die afkomstig zijn van daadwerkelijke samengevoegde pull-requests in 12 populaire Python-repositories — astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy en xarray. Elke instantie presenteert het model een snapshot van de codebase en een beschrijving van een GitHub-issue; het model moet een patch produceren die een specifieke set van voorheen falende tests laat slagen zonder bestaande tests te verbreken. De benchmark is opgebouwd door ongeveer 90.000 PR's te doorzoeken, te filteren op PR's die zowel een gekoppeld issue oplosten als nieuwe tests toevoegden, en vervolgens de overgangen tussen slagen en falen op basis van uitvoering te verifiëren. Deze gedisciplineerde constructie vermijdt het typische benchmarkprobleem van dubbelzinnige of gemakkelijk te manipuleren grondwaarheid.

Belangrijkste ideeën

• Claude 2, het best presterende model bij publicatie, lost slechts 1,96% van de issues op met BM25 sparse retrieval — de realistische implementatie-omgeving waarbij het model zelf relevante bestanden moet vinden.
• Met oracle retrieval — waarbij het model exact de bestanden krijgt die het nodig heeft — verbetert Claude 2 tot 4,80%, wat bevestigt dat het knelpunt deels in de retrieval zit, maar vooral in het bewerken: zelfs met een perfecte context blijven de succespercentages onder de 5%.
• GPT-4 lost 0,00% van de issues op met BM25 retrieval (geëvalueerd op een subset van 25% om budgettaire redenen) en 1,74% met oracle. De daling van oracle naar BM25 voor Claude 2 is ernstig; voor GPT-4 is deze totaal.
• Gegenereerde patches zijn systematisch te kort: de succesvolle patches van Claude 2 zijn gemiddeld 19,6 regels lang, tegenover 74,5 regels voor de gouden menselijke patches. Modellen vinden eenvoudige lokale fixes; mensen schrijven uitgebreide oplossingen die over meerdere bestanden verspreid zijn.
• Meer context schaadt actief. BM25 bij 50k tokens haalt meer oracle-bestanden op dan bij 13k tokens, maar toch dalen de oplossingspercentages vaak. Het "lost in the middle"-effect — waarbij modellen relevante informatie negeren die diep in lange contexten begraven ligt — is hier een reële en gedocumenteerde foutmodus.
• SWE-Llama 13b, getraind op contexten verkregen via oracle retrieval, behaalt 4,00% met oracle, maar slechts 0,70% met BM25. Trainen op perfecte context creëert broze agents die instorten wanneer de retrieval realistisch is.

Wat standhoudt — en wat niet

De constructie van de benchmark is rigoureus. Evaluatie op basis van uitvoering — tests die daadwerkelijk draaien, slagen of falen — is de juiste grondwaarheid voor codewijzigingstaken. Het is objectief, automatiseerbaar en moeilijk te manipuleren. De beslissing om overgangen van falen naar slagen te vereisen (niet alleen het succesvol toepassen van een patch) is bijzonder belangrijk: het voorkomt triviaal correcte patches zoals no-ops of verwijderingen.

De resultaten hebben opmerkelijk goed standgehouden. SWE-bench werd gepubliceerd in oktober 2023 en werd al snel de de facto evaluatie voor codeer-agents. De initiële baseline van 1,96% is oprecht informatief, niet willekeurig gekozen. SWE-agent, in 2024 gepubliceerd door een gerelateerde groep, verhoogde het resultaat naar 12,47% door de interface tussen agent en computer opnieuw te ontwerpen — een verbetering van 6x die op zichzelf bevestigt hoeveel de oorspronkelijke baseline liet liggen.

Twee zaken die de paper niet goed afhandelt: Ten eerste is de benchmark alleen in Python. Dat is een praktische noodzaak, maar het creëert een reëel risico op overfitting aan Python-conventies. Ten tweede stelt de paper alleen baselines voor retrieval-augmented generation voor en verwijst expliciet naar toekomstig werk voor op agents gebaseerde benaderingen. Dat uitstel was gepast in 2023, maar betekent dat de paper zelf geen indicatie geeft over welke agent-architecturen helpen.

De "oracle"-instelling is ook een zwakkere bovengrens dan het lijkt. Het bieden van een perfecte bestandscontext lost de lokalisatie van code binnen die bestanden niet op, en het helpt niet bij redeneren over meerdere bestanden en de interacties tussen modules. Claude 2 op 4,8% oracle betekent dat zelfs met de juiste bestanden in de context, het model in 95% van de gevallen faalt. Het probleem is niet primair de retrieval.

Waarom dit belangrijk is voor financiële AI

Beancount is een Python-project dat op GitHub wordt gehost. Een write-back agent voor Beancount is in essentie een agent die taken in de stijl van SWE-bench moet uitvoeren: gegeven een grootboekbestand en een instructie ("voeg deze transactie toe", "corrigeer dit verschil in saldo"), produceer een bewerking die door bean-check komt zonder bestaande asserties te verbreken.

De retrieval-fout is direct analoog aan het lokalisatieprobleem in het grootboek. Wanneer een gebruiker zegt "corrigeer de overschatting in de kantoorbenodigdheden van Q3", moet de agent eerst de relevante boekingen vinden in een bestand dat duizenden regels kan bevatten — dezelfde bestandslokalisatietaak waarbij BM25 faalt voor 40-50% van de SWE-bench-gevallen. De degradatie door "lost in the middle" is evenzeer van toepassing op lange .beancount-bestanden, waar eerdere boekingen net zo waarschijnlijk genegeerd worden.

De asymmetrie in patchlengte is een praktische waarschuwing. Modellen patchen te beperkt. In de boekhouding vertaalt zich dat in het corrigeren van de ene boeking terwijl de tegenboeking wordt gemist, of het bijwerken van de onkostenregel terwijl het lopende saldo verouderd blijft. Een productie-Beancount-agent heeft een validatielaag nodig — bean-check, saldo-asserties of een expliciete reconciliatieronde — die de agent dwingt de volledige consequentie van zijn bewerking te zien, en niet alleen de lokale aannemelijkheid.

De kloof tussen oracle/BM25 is ook een herinnering dat de kwaliteit van de retrieval niet losstaat van de kwaliteit van de agent. Een agent die niet betrouwbaar kan identificeren welke rekeningen of bestanden relevant zijn voor een vraag van de gebruiker, zal falen bij de navigatie door het grootboek nog voordat hij een bewerking probeert.

Wat nu te lezen

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — de directe opvolger; gaat van 1,96% naar 12,47% door de interface tussen agent en computer opnieuw te ontwerpen. De ontwerpprincipes voor bestandsnavigatie en het zoeken naar code zijn direct toepasbaar op de instrumentatie van Beancount-agents.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — ontdoet de agent van zijn complexiteit en laat zien dat een eenvoudige lokalisatie- en reparatiepijplijn zonder extra structuur concurrerend kan zijn; een nuttig tegenwicht voor interface-zware benaderingen.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — pakt het probleem van de lange context direct aan met gelaagd geheugenbeheer; direct relevant voor agents die moeten redeneren over Beancount-grootboeken die meerdere jaren beslaan.