SWE-bench (benchmark) (SV)
SWE-bench — är ett storskaligt benchmark (uppsättning testuppgifter) för att utvärdera förmågorna hos stora språkmodeller (LLM) inom automatiserad mjukvaruutveckling och felsökning[1]. Det utvecklades av en grupp forskare från Princeton University och andra organisationer och presenterades vid konferensen ICLR 2024[2]. SWE-bench skiljer sig från traditionella kodbenchmarks genom att använda verkliga uppgifter från praktisk utveckling: testuppsättningen innehåller 2294 uppgifter baserade på stängda ärenden (issues) och tillhörande buggfixar (pull requests) från 12 populära öppna Python-repositorier på GitHub[1][3]. Varje uppgift innehåller en beskrivning av problemet (issue) och ger modellen tillgång till källkoden för det aktuella projektet; modellens mål är att generera minimala ändringar i kodbasen (patch) som åtgärdar det angivna problemet[1][3].
Metodik och utvärderingssärdrag
SWE-bench simulerar den verkliga processen för mjukvaruutveckling. För varje uppgift presenteras modellen med texten från det ursprungliga GitHub-ärendet (problembeskrivningen) och en ögonblicksbild av repositoriets kod i versionen före att buggfixen tillämpades[4]. Modellen (eller en agentbaserad modell) behöver analysera källkoden, förstå felens natur eller den begärda ändringen och göra ändringar i de relevanta kodfilerna för att lösa problemet[4][5]. Validering av lösningen är automatiserad: varje uppgift är kopplad till verkliga enhetstester från den pull request som stängde ärendet. Bland dem finns både «misslyckas-till-godkänt»-tester (fail-to-pass, som inte klaras på originalkoden men ska klara sig efter att rätt fix tillämpats) och regressionstester (pass-to-pass, som klaras initialt och ska fortsätta att klara sig efter att ändringar gjorts)[3]. Den patch som modellen föreslår tillämpas på koden, varefter de relevanta testerna körs: om alla fail-to-pass-tester börjar klara sig och pass-to-pass-testerna inte bryts, anses uppgiften vara korrekt löst[3]. Detta utvärderingssätt gör det möjligt att kontrollera inte bara modellens förmåga att generera syntaktiskt korrekt kod, utan också förmågan att faktiskt lösa den ställda uppgiften utan att bryta befintlig funktionalitet. Därtill måste modellen hantera en stor kontext (ett helt kodrepositorie), förstå sambanden mellan komponenter och koordinera ändringar i flera filer samtidigt[1] — allt detta är betydligt svårare än typiska uppgifter om att skriva en funktion utifrån en beskrivning.
I SWE-bench-utvärderingar deltar vanligtvis inte bara LLM själva, utan agentsystem som omger modellen med hjälpverktyg (till exempel för filnavigering, kodexekvering, användning av debugger m.m.)[4][6]. Ett sådant system imiterar den verkliga utvecklingscykeln: modellen kan successivt bläddra igenom filer, köra tester eller skript och stegvis förbättra lösningen tills ett framgångsrikt resultat uppnås[4]. Det är talande att effektiviteten vid lösning av SWE-bench-uppgifter till stor del beror på kvaliteten hos detta «scaffolding» (agentens infrastruktur): samma grundläggande modeller kan uppvisa olika resultat beroende på hur interaktionen med repositoriet och verktygen är organiserad[4][7]. Således fungerar SWE-bench som ett mått på förmågorna hos kombinationen av en modell och dess uppgiftslösningsstrategi, vilket gör utvärderingen mer lik de verkliga arbetsförhållandena för en autonom AI-utvecklare[4][7].
Varianter av uppgiftsuppsättningen
SWE-benchs skapare och gemenskapen presenterade efterhand flera härledda uppsättningar för olika utvärderingsändamål:
- SWE-bench Lite — en förenklad version av benchmark som innehåller ~300 uppgifter[8], utvalda för att minska svårighetsgraden och beräkningskostnaderna för modelltestning. Denna deluppsättning skapades för snabba experiment med modeller och utesluter de mest tidskrävande valideringarna, men behåller ändå representativiteten hos de viktigaste problemen[7]. I praktiken innehåller Lite enklare och kortare buggfixuppgifter, och modellernas resultat på Lite är vanligtvis högre än på den fullständiga uppsättningen, tack vare uteslutning av de svåraste fallen[7].
- SWE-bench Verified — en deluppsättning filtrerad genom manuell granskning, presenterad i augusti 2024 i samarbete med OpenAI[7]. Forskarna anlitade 93 professionella utvecklare för att analysera varje uppgift i det ursprungliga benchmark och uteslöt fall där den ursprungliga problembeskrivningen är alltför otydlig eller det beteende som testerna kräver inte framgår tydligt av uppgiftsbeskrivningen[7]. Uppgifter som i praktiken är omöjliga att lösa på grund av miljöproblem eller felaktiga tester togs också bort[7]. Resultatet blev en uppsättning med 500 uppgifter som garanterat är lösbara och korrekt formulerade[7]. SWE-bench Verified syftar till att ge en mer tillförlitlig utvärdering av modellernas förmågor genom att eliminera fall där till och med en korrekt lösning avvisas på grund av otillräckliga tester eller uppgiftsbeskrivning[7]. Denna uppsättning ersatte de ursprungliga SWE-bench-testuppsättningarna (den fullständiga och Lite) som det primära referensriktmärket för modelljämförelser[7]. Dessutom publicerades tillsammans med Verified uppgifternas svårighetsgradsuppskattningar (till exempel identifierades «lätta» uppgifter, lösbara på <15 minuter av en människa, och «svåra», som kräver >1 timme)[7], samt ett nytt verktygsramverk baserat på Docker för mer stabil och reproducerbar testkörning[7].
- SWE-bench Multimodal — en utvidgning av benchmark presenterad i januari 2025, som innehåller uppgifter där problembeskrivningen inte bara innehåller text utan även visuella element (till exempel gränssnittsbilder, felskärmdumpar m.m.)[8]. Denna uppsättning (517 uppgifter[8]) testar förmågan hos modeller och agenter att förstå och använda visuell information vid lösning av programmeringsuppgifter. Utvärderingen på den multimodala uppsättningen är organiserad på liknande sätt, men kräver att modellen har multimodala förmågor (till exempel igenkänning av text i bilder). Testdelen av SWE-bench Multimodal hålls stängd (dold) för att förhindra att lösningar anpassas till kända svar; utvecklare kan skicka in lösningar till en fjärr-leaderboard för att utvärdera sina modeller på dessa uppgifter[2].
Utöver dessa huvudsakliga varianter har ett ekosystem av verktyg formats kring SWE-bench: SWE-agent — en öppen programvara-«agent»-lösare som uppvisar toppresultat på benchmark-uppgifterna[2]; SWE-smith — ett ramverk för träning av egna utvecklarmodeller; SWE-REX — ett verktyg för utökad extraktion och bearbetning av information från repositorier m.fl. Dessa projekt syftar till att förenkla reproducering av resultat och främja forskning inom området autonoma programmeringssystem.
Modellresultat och framsteg
När SWE-bench först dök upp avslöjades ett stort gap mellan moderna LLM och erfarna programmerares färdigheter. Författarna rapporterade att till och med de kraftfullaste modellerna i början av 2023 klarade bara ett fåtal procent av uppgifterna: till exempel löste modellen Claude 2 från Anthropic färre än 2% av uppgifterna i den fullständiga uppsättningen[1]. En modell som specialtränats av benchmark-skaparna (baserad på LLaMA, kallad SWE-Llama) och proprietära modeller som GPT-4 kunde mestadels bara lösa de enklaste buggarna[1]. Dessa låga initiala värden underströk SWE-benchs svårighetsgrad och fungerade som ett incitament för att utveckla nya angreppssätt.
Under 2024, i takt med att mer avancerade modeller och agentstrukturer dök upp, förbättrades resultaten avsevärt. Forskare från Princeton presenterade SWE-agent-systemet, som kombinerar GPT-4 med kodsökning, planering och andra verktyg; det uppnådde ungefär 12,5% lösta uppgifter på den fullständiga uppsättningen och satte ett nytt riktmärke för akademiska modeller[5]. I mitten av 2024 hade de bästa lösningarna på den officiella SWE-bench-leaderboarden (inklusive proprietära) nått ungefär 20% framgångsrika lösningar på det fullständiga benchmark och upp till 43% på den förenklade Lite-uppsättningen[7]. Denna tillväxt hänger samman med förbättrade modeller (till exempel tillkomsten av GPT-4, Claude 2 och 3) och i synnerhet med utvecklingen av «scaffolding» — externa strategier som gör det möjligt för modellen att effektivt dela upp uppgiften i steg, läsa dokumentation, köra felsökningssessioner m.m.[7].
Efter introduktionen av Verified-uppsättningen i slutet av 2024 (rengjord från felaktiga uppgifter) ökade den uppmätbara prestandan ännu mer. Modellen GPT-4 (varianten GPT-4o) visade omedelbart ungefär 33% framgångsrika lösningar på Verified mot ~16% tidigare på den ursprungliga uppsättningen[7]. De bästa öppna agent-ramverken (till exempel Agentless) fördubblade sitt resultat från ~16% till 32% på Verified[7]. Detta bekräftade antagandet att det ursprungliga benchmark i viss mån underskattade prestandan på grund av förekomsten av olösliga fall[7]. Samtidigt är förbättringen av resultaten på Verified jämfört med Lite inte lika dramatisk (de bästa modellerna nådde redan ~43% på Lite), vilket är logiskt: Lite valde ursprungligen ut enklare exempel, medan Verified tog bort de omöjliga men behöll de svåra uppgifterna[7]. Det är viktigt att notera att resultatökningen vid övergången till Verified skedde inom alla svårighetskategorier, inte bara genom eliminering av de svåraste — det vill säga filtreringen befriade uppsättningen också från dolda olösliga fall bland relativt enkla uppgifter[7].
I början av 2025 uppvisar ledande AI-system redan prestanda nära mänsklig nivå på den verifierade uppgiftsuppsättningen, även om taket på 100% fortfarande är långt borta. I januari 2025 meddelade Anthropic att deras nya modell Claude 3.5 Sonnet i kombination med en förbättrad agent löste 49% av SWE-bench Verified-uppgifterna[4] och tillfälligt tog förstaplatsen. Stora teknikföretag och oberoende team deltar också aktivt i inofficiella tävlingar på detta benchmark. CodeStory-teamet utvecklade till exempel ett flermodellsupplägg med variantsökning («Midwit Agent») som nådde rekordstora 62,2% lösta uppgifter på Verified (data från början av 2025)[5][9]. Det noterades att detta krävde en väsentlig ökning av beräkningsresurserna i inferensfasen (så kallad inference time scaling), genom att köra många lösningsförsök och välja det bästa resultatet[5]. I OpenAI-material nämndes i sin tur ett experimentellt system GPT-03 som vid tillräcklig beräkningsskalning påstås ha överskridit tröskeln på 70% på Verified (inofficiella uppgifter)[5]. Det saknas dock oberoende verifiering av dessa resultat, och ett så högt värde förblir snarare ett riktmärke för framtida forskning än en uppnådd nivå.
Enligt en studie från Microsoft Research (2025) överstiger inte ens de senaste modellerna, när de utrustas med felsökningsverktyg, 50%-gränsen för framgångsrika buggfixar från SWE-bench Lite[6]. I detta test presterade Claude 3.7 Sonnet bäst med ~48,4% lösta uppgifter, medan ett system baserat på GPT-4 (OpenAI o1) löste ungefär 30% och den mer lättviktiga modellen o3-mini bara 22%[6]. Dessa resultat understryker att trots snabba framsteg är dagens AI-system fortfarande sämre än erfarna programmerare: för en människa är lösning av sådana uppgifter (med förståelse för koden) inga svårigheter, medan modellen ofta inte kan använda felsökningsverktyg effektivt eller lider av brist på träningsdata som speglar den flerstegsvisa processen för buggfixning[6].
Begränsningar och framtidsutsikter
SWE-bench har blivit en standardiserad plattform för utvärdering av intelligenta kodagenter, men forskningen har också avslöjat ett antal begränsningar. Huvudproblemet är ofullständig testning: den uppsättning verifieringstester som är kopplad till varje uppgift hämtas från en specifik pull request och inkluderar vanligtvis bara de enhetstester som ändrades vid buggfixningen[3]. Som en analys från en forskargrupp från Zhejiang University och Stuttgarts universitet (Wang et al. 2025) visade kan ignorering av projektets övriga tester dölja felaktigheten hos vissa lösningar[3]. En omgranskning av lösningarna mot den fullständiga testuppsättningen i repositoriet avslöjade att i genomsnitt 7,8% av patchar märkta som framgångsrika i SWE-bench i själva verket inte klarar andra tester i projektet[3]. Detta leder till en överskattning av måttet «lösta uppgifter» med ungefär 4–6 procentenheter[3]. Ett ännu mer subtilt fall är när en genererad patch klarar alla ursprungliga tester men ändå är icke-ekvivalent med utvecklarens lösning och ändrar programmets beteende på ett sätt som inte väntades. Med hjälp av generering av ytterligare testfall (metodiken PatchDiff) fann forskarna att nästan 30% av AI-föreslagna buggfixar beter sig annorlunda än referenspatcharna, och ungefär 11% är entydigt felaktiga, även om de inte upptäcks av befintliga tester[3]. Modellernas verkliga förmågor kan alltså överskattas om man enbart förlitar sig på att ett begränsat antal tester klaras. SWE-benchs skapare erkänner denna sårbarhet och betonar att benchmark med tiden måste utvecklas: testtäckning behöver förbättras, kontroller av frånvaron av oönskade bieffekter behöver läggas till och uppgiftstyperna behöver utökas[7]. Utvecklingen av sådana utvärderingsverktyg är en viktig del av förberedelserna inför tillkomsten av allt mer autonoma och kraftfulla AI-utvecklare, och erfarenheten med SWE-bench visar på behovet av noggrann uppmärksamhet på benchmarkens kvalitet[7].
SWE-bench, som bara är en statisk uppsättning uppgifter, täcker inte absolut alla aspekter av programmering, men har redan blivit en de facto-standard för jämförande analys av kodmodeller[3]. Det används i vetenskapliga arbeten för att demonstrera nya metoder och algoritmer, och av industriella forskargrupper för att utvärdera potentialen hos system avsedda att automatisera programmering[3]. Den ständiga förbättringen av resultaten på SWE-bench under 2023–2025 visar tydligt på den snabba förbättringen av LLM:ers förmågor att lösa praktiska utvecklingsuppgifter. Samtidigt fungerar det som en svårighetsmätare: även när man närmar sig 50–60% lösta uppgifter är modellerna fortfarande långt ifrån att fullt ut ersätta människan, särskilt under förhållanden med begränsad information och behov av subtil förståelse av krav[4][7]. Icke desto mindre stannar inte framstegen upp — tack vare initiativ som SWE-bench ser gemenskapen tydligt sina mål och begränsningar, och fortsätter att röra sig mot skapandet av en fullvärdig AI-utvecklare som autonomt kan förstå och korrigera programkod på en mänsklig experts nivå[4][7].
Externa länkar
- SWE-bench på GitHub
- Officiell SWE-bench-leaderboard
Litteratur
- 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.
Noter
- ↑ 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]