SWE-bench (benchmark) (NL)
SWE-bench — dit is een grootschalige benchmark (verzameling testtaken) voor het evalueren van de mogelijkheden van grote taalmodellen (LLM) op het gebied van geautomatiseerde softwareontwikkeling en debugging[1]. Het werd ontwikkeld door een groep onderzoekers van Princeton University en andere organisaties en gepresenteerd op de conferentie ICLR 2024[2]. SWE-bench onderscheidt zich van traditionele codebenchmarks door het gebruik van echte taken uit de ontwikkelingspraktijk: de testset bevat 2294 taken op basis van gesloten issues en bijbehorende oplossingen (pull requests) uit 12 populaire open Python-repositories op GitHub[1][3]. Elke taak bevat een beschrijving van het probleem (issue) en geeft het model toegang tot de broncode van het betreffende project; het doel van het model is om minimale wijzigingen in de codebase (patch) te genereren die het aangegeven probleem oplossen[1][3].
Methodiek en bijzonderheden van de evaluatie
SWE-bench simuleert het echte softwareontwikkelingsproces. Voor elke taak krijgt het model de tekst van het originele GitHub-issue (probleembeschrijving) en een snapshot van de repositorycode in de versie vóór het aanbrengen van de correctie[4]. Het model (of een agent op basis van het model) moet de broncode analyseren, de aard van de fout of de vereiste wijziging begrijpen en de relevante codebestanden aanpassen om het probleem op te lossen[4][5]. Validatie van de oplossing is geautomatiseerd: aan elke taak zijn echte unit-tests gekoppeld uit de pull request die het probleem heeft gesloten. Daartoe behoren zowel «failing-to-passing» tests (fail-to-pass, die niet slagen op de originele code maar moeten slagen na toepassing van de juiste correctie) als regressietests (pass-to-pass, die aanvankelijk slagen en na de wijzigingen moeten blijven slagen)[3]. De door het model voorgestelde patch wordt op de code toegepast, waarna de bijbehorende tests worden uitgevoerd: als alle fail-to-pass tests beginnen te slagen en de pass-to-pass tests niet worden verstoord, wordt de taak als correct opgelost beschouwd[3]. Deze evaluatiebenadering maakt het mogelijk niet alleen de vaardigheid van het model om syntactisch correcte code te genereren te toetsen, maar ook het vermogen om de gestelde taak daadwerkelijk op te lossen zonder bestaande functionaliteit te verstoren. Daarbij moet het model werken met een grote context (een hele coderepository), de onderlinge samenhang tussen componenten begrijpen en wijzigingen in meerdere bestanden tegelijk coördineren[1] — dit alles is aanzienlijk complexer dan typische taken waarbij een functie op basis van een beschrijving moet worden geschreven.
Bij SWE-bench-evaluaties nemen gewoonlijk niet de LLM zelf deel, maar agentsystemen die het model inpakken met hulpgereedschappen (bijvoorbeeld voor navigatie door bestanden, uitvoering van code, gebruik van een debugger, enz.)[4][6]. Zo'n systeem imiteert de echte ontwikkelcyclus: het model kan stapsgewijs bestanden doorbladeren, tests of scripts uitvoeren en de oplossing geleidelijk verbeteren totdat een succesvol resultaat is bereikt[4]. Opmerkelijk is dat de effectiviteit bij het oplossen van SWE-bench-taken grotendeels afhangt van de kwaliteit van deze «scaffolding» (agentinfrastructuur): dezelfde basismodellen kunnen verschillende resultaten laten zien afhankelijk van hoe de interactie met de repository en de gereedschappen is georganiseerd[4][7]. SWE-bench dient dus als maatstaf voor de mogelijkheden van de combinatie van een model en zijn taakoplossingstrategie, waardoor de evaluatie dichter bij de reële werkomstandigheden van een autonome AI-ontwikkelaar komt[4][7].
Varianten van de takenset
De auteurs van SWE-bench en de gemeenschap hebben vervolgens verschillende afgeleide sets gepresenteerd voor uiteenlopende evaluatiedoeleinden:
- SWE-bench Lite — een vereenvoudigde versie van de benchmark met ~300 taken[8], geselecteerd om de complexiteit en rekenkosten van het testen van modellen te verlagen. Deze subset werd gemaakt voor snelle experimenten met modellen en sluit de meest arbeidsintensieve validaties uit, terwijl de representativiteit van de kernproblemen behouden blijft[7]. In wezen bevat Lite eenvoudigere en kortere bugfixingstaken, en de resultaten van modellen op Lite zijn doorgaans hoger dan op de volledige set, doordat de moeilijkste gevallen worden uitgesloten[7].
- SWE-bench Verified — een door handmatige controle gefilterde subset, gepresenteerd in augustus 2024 in samenwerking met OpenAI[7]. De onderzoekers betrokken 93 professionele ontwikkelaars bij de analyse van elke taak in de originele benchmark en sloten gevallen uit waarbij de originele probleembeschrijving te vaag was of het door de tests vereiste gedrag niet expliciet uit de taakomschrijving voortvloeide[7]. Ook werden taken verwijderd die in de praktijk niet op te lossen zijn vanwege omgevingsproblemen of incorrecte tests[7]. Het resultaat is een set van 500 taken die gegarandeerd oplosbaar en correct geformuleerd zijn[7]. SWE-bench Verified is bedoeld om een betrouwbaardere evaluatie van de modelmogelijkheden te bieden door gevallen te elimineren waarbij zelfs een correcte oplossing wordt afgewezen vanwege inadequate tests of taakomschrijving[7]. Deze set verving de originele testsamples van SWE-bench (volledig en Lite) als primaire referentie voor modelvergelijking[7]. Bovendien werden samen met Verified taakmoeilijkheidsscores gepubliceerd (bijvoorbeeld onderscheid tussen «makkelijke» taken die een mens in <15 minuten kan oplossen en «moeilijke» die >1 uur vereisen)[7], en werd een nieuw instrumenteel kader op basis van Docker uitgebracht voor stabielere en reproduceerbare testuitvoering[7].
- SWE-bench Multimodal — een uitbreiding van de benchmark, gepresenteerd in januari 2025, met taken waarbij de probleembeschrijving niet alleen tekst maar ook visuele elementen bevat (bijvoorbeeld afbeeldingen van interfaces, screenshots van fouten, enz.)[8]. Deze set (517 taken[8]) toetst het vermogen van modellen en agents om visuele informatie te begrijpen en te gebruiken bij het oplossen van programmeertaken. De evaluatie op de multimodale set is op vergelijkbare wijze georganiseerd, maar vereist multimodale mogelijkheden van het model (bijvoorbeeld tekstherkenning op afbeeldingen). Het testgedeelte van SWE-bench Multimodal is gesloten (verborgen) gehouden om aanpassing van oplossingen aan bekende antwoorden te voorkomen; ontwikkelaars kunnen oplossingen indienen via een extern leaderboard om hun modellen op deze taken te laten evalueren[2].
Naast deze belangrijkste varianten is rondom SWE-bench een ecosysteem van gereedschappen ontstaan: SWE-agent — een open-source software-«agent»-oplosser die toonaangevende resultaten laat zien op benchmarktaken[2]; SWE-smith — een framework voor het trainen van eigen ontwikkelaarsmodellen; SWE-REX — een gereedschap voor uitgebreide extractie en verwerking van informatie uit repositories, en anderen. Deze projecten zijn gericht op het vereenvoudigen van de reproduceerbaarheid van resultaten en het bevorderen van onderzoek op het gebied van autonome programmeersystemen.
Resultaten en voortgang van modellen
Bij het eerste verschijnen van SWE-bench werd een aanzienlijke kloof zichtbaar tussen hedendaagse LLM en de vaardigheden van ervaren programmeurs. De auteurs meldden dat zelfs de krachtigste modellen van begin 2023 slechts een handvol procenten van de taken oplosten: zo loste het model Claude 2 van Anthropic minder dan 2% van de taken in de volledige set correct op[1]. Het door de benchmarkauteurs speciaal getrainde model (gebaseerd op LLaMA, genaamd SWE-Llama) en propriëtaire modellen zoals GPT-4 konden voornamelijk alleen de eenvoudigste fouten oplossen[1]. Deze lage initiële scores benadrukten de moeilijkheidsgraad van SWE-bench en vormden een stimulans voor de ontwikkeling van nieuwe benaderingen.
In de loop van 2024 verbeterden de resultaten aanzienlijk naarmate geavanceerdere modellen en agentschema's beschikbaar kwamen. Onderzoekers van Princeton presenteerden het SWE-agent-systeem dat GPT-4 combineert met codezoekopdrachten, planning en andere gereedschappen; dit bereikte circa 12,5% opgeloste taken in de volledige set en stelde een nieuwe referentie voor academische modellen[5]. Tegen midden 2024 bereikten de beste oplossingen op het officiële SWE-bench-leaderboard (inclusief propriëtaire) ongeveer 20% succesvolle oplossingen op de volledige benchmark en tot 43% op de vereenvoudigde Lite-set[7]. Deze groei hangt samen met verbeterde modellen (zoals de introductie van GPT-4, Claude 2 en 3) en in het bijzonder met de ontwikkeling van «scaffolding» — externe strategieën die het model in staat stellen taken effectief in stappen op te delen, documentatie te lezen, debugsessies uit te voeren, enz.[7].
Na de introductie van de Verified-set eind 2024 (gezuiverd van incorrecte taken) steeg de gemeten prestatie nog verder. Het model GPT-4 (variant GPT-4o) liet meteen circa 33% succesvolle oplossingen zien op Verified, tegenover ~16% eerder op de originele set[7]. De beste open agent-frameworks (zoals Agentless) verdubbelden hun resultaat van ~16% naar 32% op Verified[7]. Dit bevestigde het vermoeden dat de originele benchmark de scores enigszins onderschatte vanwege de aanwezigheid van niet-oplosbare gevallen[7]. Tegelijkertijd is de verbetering van de resultaten op Verified ten opzichte van Lite minder dramatisch (de beste modellen bereikten al ~43% op Lite), wat logisch is: Lite selecteerde van tevoren eenvoudigere voorbeelden, terwijl Verified de onuitvoerbare verwijderde maar de moeilijke taken behield[7]. Belangrijk is dat de stijging van de scores bij de overgang naar Verified plaatsvond in alle moeilijkheidscategorieën van taken en niet alleen door eliminatie van de moeilijkste — de filtering verwijderde uit de set dus ook verborgen niet-uitvoerbare gevallen onder relatief eenvoudige taken[7].
Bij het begin van 2025 tonen toonaangevende AI-systemen al een prestatie die de menselijke efficiëntie op de geverifieerde takenset benadert, hoewel het plafond van 100% nog ver weg is. In januari 2025 deelde Anthropic mee dat zijn nieuwe model Claude 3.5 Sonnet in combinatie met een verbeterde agent 49% van de SWE-bench Verified-taken oploste[4], waarmee het tijdelijk de eerste plaats innam. Grote technologiebedrijven en onafhankelijke teams nemen ook actief deel aan onofficiële competities op deze benchmark. Zo ontwikkelde het CodeStory-team een multi-model benadering met iteratie over varianten («Midwit Agent»), die een recordscore van 62,2% opgeloste taken op Verified bereikte (gegevens van begin 2025)[5][9]. Hiervoor moest de rekenkracht tijdens de inferentiefase aanzienlijk worden opgeschaald (zogenaamde inference time scaling), waarbij meerdere oplossingsmogelijkheden worden uitgevoerd en het beste resultaat wordt geselecteerd[5]. OpenAI vermeldde op zijn beurt in publicaties een experimenteel systeem GPT-03 dat bij voldoende opschaling van de berekeningen de drempel van 70% op Verified schijnt te hebben overschreden (onofficiële gegevens)[5]. Een onafhankelijke verificatie van deze resultaten ontbreekt echter, en zo'n hoge score blijft eerder een richtpunt voor toekomstig onderzoek dan een bereikte lat.
Volgens onderzoek van Microsoft Research (2025) overschrijden zelfs de nieuwste modellen, uitgerust met debuggergereedschappen, de grens van 50% succesvolle bugfixes uit SWE-bench Lite nog niet[6]. In dit experiment presteerde Claude 3.7 Sonnet het best met ~48,4% opgeloste taken, terwijl het systeem op GPT-4 (OpenAI 01) ongeveer 30% oploste en het lichtere model 03-mini slechts 22%[6]. Deze resultaten onderstrepen dat, ondanks de snelle vooruitgang, hedendaagse AI-systemen nog steeds achterblijven bij ervaren programmeurs: voor een mens vormt het oplossen van dergelijke taken (gegeven begrip van de code) geen grote uitdaging, terwijl een model vaak niet in staat is debuggergereedschappen effectief te gebruiken of lijdt aan een gebrek aan trainingsdata die het meerstappige bugfixingproces weerspiegelen[6].
Beperkingen en vooruitzichten
SWE-bench is een gestandaardiseerd platform geworden voor de evaluatie van intelligente codeagents, maar onderzoek heeft ook een aantal beperkingen aan het licht gebracht. Het belangrijkste probleem is de onvolledigheid van het testen: de verzameling verificatietests bij elke taak is afkomstig uit een specifieke pull request en bevat doorgaans alleen die unit-tests die zijn gewijzigd bij het fixen van de bug[3]. Zoals een analyse van een groep wetenschappers van de Universiteit van Zhejiang en de Universiteit van Stuttgart (Wang et al. 2025) aantoonde, kan het negeren van de overige tests van het project de onjuistheid van sommige oplossingen verhullen[3]. Hercontrole van oplossingen op de volledige testset van de repository onthulde dat gemiddeld 7,8% van de als succesvol gemarkeerde patches in SWE-bench in werkelijkheid andere tests in het project niet doorstaan[3]. Dit leidt tot een overschatting van de metriek «opgeloste taken» met ongeveer 4-6 procentpunten[3]. Een nog subtielere situatie doet zich voor wanneer de gegenereerde patch alle originele tests doorstaat, maar tegelijkertijd niet equivalent is aan de oplossing van de ontwikkelaar en het gedrag van het programma anders wijzigt dan verwacht. Met behulp van het genereren van aanvullende testgevallen (methodiek PatchDiff) stelden onderzoekers vast dat bijna 30% van de door AI voorgestelde correcties zich anders gedraagt dan de referentiepatches, en circa 11% aantoonbaar onjuist is, hoewel dit niet door bestaande tests wordt opgemerkt[3]. De werkelijke mogelijkheden van modellen kunnen dus worden overschat als uitsluitend wordt vertrouwd op het slagen van een beperkte testset. De makers van SWE-bench erkennen deze kwetsbaarheid en benadrukken dat de benchmark in de loop van de tijd moet evolueren: testdekking verbeteren, controles op het ontbreken van ongewenste neveneffecten toevoegen, het scala aan taaktypen uitbreiden[7]. De ontwikkeling van dergelijke evaluatiemiddelen is een belangrijk onderdeel van de voorbereiding op de komst van steeds autonomere en krachtigere AI-ontwikkelaars, en de ervaringen met SWE-bench tonen de noodzaak van zorgvuldige aandacht voor de kwaliteit van benchmarks[7].
SWE-bench, als louter statische takenset, dekt niet absoluut alle aspecten van programmeren af, maar is al uitgegroeid tot een de-facto standaard voor vergelijkende analyse van codemodellen[3]. Het wordt in wetenschappelijke publicaties gebruikt om nieuwe methoden en algoritmen te demonstreren, en door industriële onderzoeksgroepen om het potentieel te evalueren van systemen die zijn bedoeld om programmeren te automatiseren[3]. De constante groei van de resultaten op SWE-bench over de periode 2023-2025 illustreert duidelijk de snelle verbetering van de mogelijkheden van LLM bij het oplossen van praktische ontwikkelingstaken. Tegelijkertijd fungeert het als barometer van complexiteit: zelfs wanneer modellen 50-60% van de taken oplossen, zijn ze nog steeds ver verwijderd van een volwaardige vervanging van de mens, met name in situaties van beperkte informatie en de noodzaak van een fijn begrip van de vereisten[4][7]. Desalniettemin houdt de vooruitgang niet op — dankzij initiatieven als SWE-bench ziet de gemeenschap haar doelen en beperkingen duidelijk, en blijft ze werken aan de totstandkoming van een volwaardige AI-ontwikkelaar die autonoom programmacode kan begrijpen en corrigeren op het niveau van een menselijke expert[4][7].
Verwijzingen
- SWE-bench op GitHub
- Officieel SWE-bench-leaderboard
Literatuur
- Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
- Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
- Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
- Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
- Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
- Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
- Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
- Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
- Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
- Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
- Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
- Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.
Noten
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [1]
- ↑ 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [2]
- ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [3]
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [4]
- ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [5]
- ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [6]
- ↑ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [7]
- ↑ 8.0 8.1 8.2 «SWE-bench Leaderboard». [8]
- ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [9]