Hvorfor SWE-bench Verified ikke længere måler banebrydende kodningskapaciteter

Siden vi første gang udgav SWE-bench Verified i august 2024, har branchen bredt anvendt det til at måle modellernes fremskridt inden for autonome softwareudviklingsopgaver. Efter udgivelsen gav SWE-bench Verified et stærkt signal om kapacitetsfremskridt og blev en standardmåling, der rapporteres i udgivelser af banebrydende modeller. Sporing og forudsigelse af fremskridt for disse kapaciteter er også en vigtig del af OpenAI’s Preparedness Framework. Da vi oprindeligt oprettede Verified-benchmarken, forsøgte vi at løse problemer i den oprindelige evaluering, som gjorde visse opgaver umulige at gennemføre i SWE-bench-datasættet⁠(åbner i et nyt vindue).

Efter de første store fremskridt er den seneste udvikling på SWE-bench Verified gået langsommere, med en forbedring⁠(åbner i et nyt vindue) fra 74,9 % til 80,9 % i de sidste 6 måneder. Dette rejser spørgsmålet: Afspejler de resterende fejl modelbegrænsninger eller egenskaber ved selve datasættet?

I en ny analyse fandt vi to væsentlige problemer med det verificerede sæt, der indikerer, at benchmarken ikke længere er egnet til at måle fremskridt inden for autonome softwareudviklingskapaciteter til banebrydende lanceringer på nutidens præstationsniveauer:

1. Tests afviser korrekte løsninger: Vi reviderede en delmængde på 27,6 % af datasættet, som modellerne ofte ikke kunne løse, og fandt, at mindst 59,4 % af de reviderede problemer havde fejlbehæftede testcases, der afviste funktionelt korrekte indsendelser, på trods af vores bedste indsats for at forbedre dette i den indledende oprettelse af SWE-bench Verified.
2. Træning i løsninger: Da store, banebrydende modeller kan lære information fra deres træning, er det vigtigt, at de aldrig trænes i problemer og løsninger, som de evalueres på. Det svarer til at dele problemer og løsninger til en kommende prøve med eleverne inden prøven – de husker måske ikke svarene, men de elever, der har set svarene før, vil helt sikkert klare sig bedre end dem, der ikke har. SWE-bench-problemer stammer fra open source-repositorier, som mange modeludbydere bruger til træningsformål. I vores analyse fandt vi, at alle de banebrydende modeller, vi testede, var i stand til at gengive den originale, menneskeskrevne fejlrettelse, der blev brugt som grundlæggende reference, kendt som gold patch, eller ordrette problembeskrivelser for bestemte opgaver, hvilket indikerer, at alle modellerne har set mindst nogle af problemerne og løsningerne under træningen.

Vi fandt også beviser for, at modeller, der har set problemerne under træningen, har større sandsynlighed for at lykkes, fordi de har yderligere information, der er nødvendig for at bestå de underspecificerede tests.

Dette betyder, at forbedringer på SWE-bench Verified ikke længere afspejler meningsfulde forbedringer i modellernes reelle softwareudviklingskapaciteter. I stedet afspejler de i stigende grad, hvor meget modellen blev eksponeret for benchmarken under træningen. Derfor er vi holdt op med at rapportere SWE-bench Verified-resultater, og vi anbefaler, at andre modeludviklere også gør det.

Vi udvikler nye, ukontaminerede evalueringer for bedre at kunne spore kodningsevner, og vi mener, at dette er et vigtigt område at fokusere på for det bredere forskningsfællesskab. Indtil vi har dem, anbefaler OpenAI at rapportere resultater for SWE-bench Pro.

Den oprindelige SWE-bench⁠(åbner i et nyt vindue)-evaluering blev udgivet i 2023. Hvert problem stammer fra en løst GitHub-problem i et af 12 open source Python-repositorier og er parret med den tilsvarende pull request (PR). For at afgøre, om en modelgenereret kodeændring er korrekt, følger der med hvert problem to sæt tests:

• Test, der fejler på den umodificerede kodebase, men består, hvis problemet rettes korrekt
• Regressionstests, som består både før og efter rettelsen, for at sikre, at urelateret funktionalitet forbliver intakt.

Modellen ser ikke testene. Den skal producere en kodeændring udelukkende ud fra den oprindelige problemtekst og tilstanden af lageret før rettelsen. Den består kun et problem, hvis alle tests består, efter at kodeændringen er anvendt.

Vi fandt mange problemer med den evaluering, som kunne føre til underrapportering af modellernes evner.

• Nogle enhedstests var enten for specifikke eller ikke tilpasset opgaven, hvilket kunne føre til, at korrekte rettelser blev afvist.
• Mange opgavebeskrivelser var utilstrækkeligt specificerede, hvilket kunne føre til flere gyldige fortolkninger – mens testene kun dækkede en specifik.
• Afhængigt af opsætningen af miljøet (for eksempel Linux vs Windows eller Python-versionen) kan nogle tests fejle sporadisk.

Vi oprettede SWE-bench Verified i 2024 for at løse disse problemer. Vi arbejdede sammen med erfarne softwareingeniører for at gennemgå 1.699 SWE-bench-problemer og filtrere problemer fra, der havde disse problemer. Hvert problem blev gennemgået af tre eksperter uafhængigt. Denne gennemgangsproces resulterede i SWE-bench Verified, et kurateret sæt af 500 problemer.

Selvom SWE-bench Verified er en stor forbedring i forhold til den oprindelige version, er der stadig tilbageværende problemer. Vi gennemførte en revision af 138 SWE-bench Verified problemer, som OpenAI o3 ikke løste konsekvent i 64 uafhængige kørsler. Hver sag blev gennemgået uafhængigt af mindst seks erfarne softwareingeniører. Hvis en ekspert markerede et problem, blev det verificeret igen af et yderligere team.

Vi fandt, at 59,4 % af de 138 problemer indeholdt væsentlige problemer i testdesignet og/eller problembeskrivelsen, hvilket gjorde dem ekstremt vanskelige eller umulige at løse, selv for den mest kompetente model eller person. 

• 35,5 % af de reviderede opgaver har strenge testcases, der håndhæver specifikke implementeringsdetaljer, hvilket ugyldiggør mange funktionelt korrekte indsendelser, som vi kalder snævre testcases.
• 18,8 % af de reviderede opgaver har tests, der kontrollerer for yderligere funktionalitet, som ikke var specificeret i problembeskrivelsen, hvilket vi kalder brede testtilfælde.
• De resterende 5,1 % af opgaverne havde diverse problemer, som ikke kunne grupperes under denne taksonomi.

Et illustrativt eksempel på den første fejltilstand er pylint-dev__pylint-4551⁠(åbner i et nyt vindue), hvor PR introducerer en ny funktion `get_annotation` som en del af den samlede løsning. Dette funktionsnavn er ikke nævnt i problembeskrivelsen, men importeres direkte af testene. Selvom nogle modeller måske intuitivt vil oprette en sådan funktion, er det ikke strengt nødvendigt at implementere en funktion med dette specifikke navn for at løse problemet korrekt. Mange gyldige løsninger dumper testene på grund af importfejl.

Et eksempel på for brede testcases er sympy__sympy-18199⁠(åbner i et nyt vindue). Denne opgave stammede fra en PR, der adresserede tre forskellige problemer med funktionen `nthroot_mod`, specifikt #17373⁠(åbner i et nyt vindue), #17377⁠(åbner i et nyt vindue) og #18212⁠(åbner i et nyt vindue). Beskrivelsen af SWE-bench Verified-opgaven dækker dog kun det endelige issue #18212⁠(åbner i et nyt vindue). Dette skaber en uoverensstemmelse: PR-testene dækker alle tre problemer, mens beskrivelsen kun beskriver ét. I vores kørsler implementerer modeller ofte korrekt den beskrevne rettelse og fejler derefter tests, der dækker implementeringen af de to andre problemer.

SWE-bench Verified er verificeret, og lagrene (kodebaser og udgivelsesnoter) er begge open source og bredt anvendt og diskuteret, hvilket gør det vanskeligt for modeludviklere at undgå kontaminering.

Vi stødte først på tegn på kontaminering i vores egne modeller. For eksempel, da GPT‑5.2 løste 31 opgaver, som vi havde identificeret som næsten umulige at løse. I django__django-14725⁠(åbner i et nyt vindue) kræver testene en specifik ny parameter `edit_only`, som ikke eksplicit kræves af problemformuleringen. Mens GPT‑5.2 løser problemet, viser det i sin tankegang, at det har oplysninger om release notes, der beskriver ændringer i kodebasen, og identificerer korrekt, at parameteren `edit_only` blev introduceret i Django 4.1.

For at vurdere, hvor alvorlig kontaminering er i et bredere perspektiv, oprettede vi en automatiseret red-teaming-opsætning. For hvert SWE-bench-verificeret spørgsmål bad vi GPT‑5 om at undersøge GPT‑5.2‑Chat, Claude Opus 4.5 og Gemini 3 Flash Preview for forurening. Disse modeller blev valgt for at udelukke ræsonneringsmodeller, men vi erkender, at der sandsynligvis er en ikke ubetydelig forskel i kapacitet mellem dem.

For at undersøge for forurening modtog GPT‑5: SWE-bench Verified-opgavens ID, beskrivelse, gold patch og PR-tests. Over 15 omgange lod vi GPT‑5 variere system-/udviklerprompten, brugerprompten og assistentens forudfyldning samt forskellige fremkaldelsesstrategier. Efter hver runde angav en dommermodel, hvor meget ny opgavespecifik information der var fremkommet, og hvert svar blev angivet med hensyn til forureningsgrad fra "ingen" til "stærk". GPT‑5 fik lov til at tilpasse sin strategi baseret på tidligere ture for iterativt at genskabe opgavespecifikke detaljer. For hvert eksempel på stærk kontaminering verificerede vi sammen med en anden dommer, at GPT‑5 ikke lækkede for mange oplysninger til målmodel. Til sidst gennemgik vi derefter manuelt de “stærke” eksempler, der udgør udskrifterne i dette indlæg.

Nedenfor er eksempler på kraftig kontaminering på tværs af forskellige modeludbydere.

Ud fra et kort uddrag af opgavens beskrivelse genererer GPT‑5.2 det nøjagtige guldstykke. Især kender den det nøjagtige klasse- og metodenavn samt den nye tidlige returneringsbetingelse `if username is None or password is None`, som introduceres.

Opgave-id: django__django-11451⁠(åbner i et nyt vindue)

Opus kan ikke kun huske den nøjagtige 4-linjers funktionelle ændring, som PR introducerede, sammen med det specifikke filnavn og den metode, den berørte, men citerer også ordret den indbyggede kommentar, der var en del af diff'en. 

Opgave-id: astropy__astropy-13236⁠(åbner i et nyt vindue)

Gemini 3 Flash kan, når den ikke får yderligere oplysninger om opgaven ud over ID'et, udskrive ordrette detaljer fra opgavens beskrivelse og gold patch'en. Dette inkluderer den nye regex-formel til validering af brugernavne og de nøjagtige linjenumre for ændringen.

Opgave-id: django__django-11099⁠(åbner i et nyt vindue)

Ud fra denne revision af SWE-bench Verified kan vi drage to bredere konklusioner om evalueringsdesign. For det første indebærer benchmarks fra offentligt tilgængeligt materiale en risiko for forurening, hvor eksponering af træningsdata kan forhøje scoringerne uden at det bemærkes. Hvis offentligt indsamlede data anvendes i benchmarkkonstruktion, bør modeludviklere udføre yderligere tests for forurening. Benchmarks og endda deres løsninger, der offentliggøres, kan ende i træningsdata. Der bør udvises særlig forsigtighed med hensyn til, hvordan datasæt offentliggøres (dvs. adgangskodebeskyttet) og datafiltrering af træningsdata (dvs. nøje overholdelse af kanaristrenge). 

For det andet er det vanskeligt at få automatiseret scoring til at fungere korrekt. Perfekte testcases skal fuldt ud verificere korrekt funktionalitet, være uafhængige af specifikke, uvæsentlige implementeringsdetaljer og samtidig være robuste over for genvejsløsninger. Disse problemer er i sagens natur komplekse og vanskelige at løse. At opdage disse problemer krævede flere omfattende menneskelige mærkningskampagner. 

Vi har inkorporeret disse resultater i vores seneste evalueringsindsats. I de seneste måneder har vi valgt at rapportere resultater fra den offentlige opdeling af SWE-Bench Pro. Vi anbefaler, at andre modeludviklere gør det samme. SWE-bench Pro er ikke perfekt, men empirisk set synes det at lide mindre under kontamineringsproblemer. Vores kontamineringspipeline fandt nogle tilfælde af kontaminering, men disse tilfælde var betydeligt sjældnere og mindre alvorlige end SWE-bench Verified, og ingen model var i stand til at producere en komplet ordret gold patch.

Vi vil fortsætte med at investere i originale, privatudviklede benchmarks og bede om hjælp fra industrien og den akademiske verden til at gøre det samme. I GDPVal⁠ udarbejdes opgaverne privat af eksperter inden for området, hvilket reducerer eksponeringsrisikoen, og løsningerne bedømmes holistisk af uddannede korrekturlæsere. Denne tilgang er ressourcekrævende, men i stigende grad nødvendig for at måle reelle kapacitetsforbedringer.