Hvorfor SWE-bench Verified ikke lenger måler banebrytende kodeferdigheter

Siden vi først publiserte SWE-bench Verified i august 2024, har bransjen i stor grad brukt den til å måle fremgangen til modeller på autonome programvareutviklingsoppgaver. Etter lanseringen ga SWE-bench Verified et sterkt signal om fremgang i kapasitet, og ble en standardmåling rapportert i lanseringer av banebrytende modeller. Sporing og prognose for fremdrift for disse funksjonene er også en viktig del av OpenAIs beredskapsrammeverk. Da vi opprinnelig opprettet referansemåling for Verified, forsøkte vi å løse problemer i den opprinnelige evalueringen som gjorde enkelte oppgaver umulige å gjennomføre i SWE-bench-datasett⁠(åpnes i et nytt vindu).

Etter de første sprangene har fremgangen på høyeste nivå for SWE-bench Verified gått saktere, og forbedret⁠(åpnes i et nytt vindu) seg fra 74,9 % til 80,9 % de siste 6 månedene. Dette reiser spørsmålet: reflekterer de gjenværende feilene modellbegrensninger eller egenskaper ved selve datasettet?

I en ny analyse fant vi to store problemer med Verified-settet som indikerer at referansemålingen ikke lenger er egnet til å måle fremgang i autonome funksjonaliteter for programvareutvikling for banebrytende lanseringer på dagens ytelsesnivåer:

1. Tester avviser korrekte løsninger: Vi reviderte et delsett på 27,6 % av datasettet som modeller ofte ikke klarte å løse, og fant at minst 59,4 % av de reviderte problemene har mangelfulle testtilfeller som avviser funksjonelt korrekte innsendelser, til tross for vår beste innsats for å forbedre dette i den innledende opprettelsen av SWE-bench Verified.
2. Opplæring på løsninger: Fordi store banebrytende modeller kan lære informasjon fra opplæringen, er det viktig at de aldri læres opp på problemer og løsninger de evaluerer. Dette er som å dele oppgaver og løsninger til en kommende prøve med elevene før prøven – de memorerer kanskje ikke svaret, men elever som har sett svarene før, vil helt sikkert gjøre det bedre enn de som ikke har svarene. Problemer med SWE-bench hentes fra åpne kildekode-repositorier som mange modellleverandører bruker til opplæringsformål. I analysen vår fant vi at alle banebrytende modeller vi testet, var i stand til å reprodusere den opprinnelige, menneskeskrevne feilrettingen som ble brukt som referensedata, kjent som Gold patch, eller ordrette detaljer fra problemstillingen for enkelte oppgaver. Dette indikerer at alle modellene har sett minst noen av problemene og løsningene under opplæring.

Vi fant også bevis for at modeller som har blitt eksponert for problemene under opplæring, har større sannsynlighet for å lykkes, fordi de har tilleggsinformasjonen som trengs for å bestå de underspesifiserte testene.

Dette betyr at forbedringer på SWE-bench Verified ikke lenger gjenspeiler meningsfulle forbedringer i modellers reelle programvareutviklingsevner. I stedet gjenspeiler de i økende grad hvor mye modellen ble eksponert for referansemålingen under opplæringen. Dette er grunnen til at vi har sluttet å rapportere SWE-bench Verified-poengsummer, og vi anbefaler at andre modellutviklere gjør det samme.

Vi utvikler nye, ukontaminerte evalueringer for å bedre kunne spore kodeferdigheter, og vi mener dette er et viktig område å fokusere på for det bredere forskningsfellesskapet. Inntil vi har løst dette, anbefaler OpenAI å rapportere resultater for SWE-bench Pro.

Den opprinnelige evalueringen av SWE-bench⁠(åpnes i et nytt vindu) ble lansert i 2023. Hvert problem er hentet fra et løst GitHub-problem i ett av 12 Python-lagre med åpen kildekode og koblet sammen med tilsvarende pull request (PR). For å avgjøre om en modellgenerert kodeendring er korrekt, kommer hvert problem med to sett med tester:

• Tester som feiler på den uendrede kodebasen, men består hvis problemet blir riktig rettet
• Regresjonstester som består både før og etter løsningen for å sikre at ikke-relatert funksjonalitet forblir intakt.

Modellen ser ikke testene. Den må produsere en kodeendring som bare er angitt i den opprinnelige problemteksten og tilstanden til lageret før feilrettingen. Modellen består et problem bare hvis alle tester er bestått etter at kodeendringen er benyttet.

Vi fant mange problemer med denne evalueringen som kunne føre til underrapportering av modellenes evner.

• Noen enhetstester var for spesifikke eller feiltilpasset oppgaven, slik at korrekte rettelser kunne bli avvist.
• Mange oppgavebeskrivelser var for lite spesifiserte, noe som kunne føre til flere gyldige tolkninger – mens testene bare dekket én bestemt tolkning.
• Avhengig av oppsettet av miljøet (for eksempel Linux kontra Windows, eller Python-versjonen), kan noen tester feile sporadisk uten reell årsak

Vi utviklet SWE-bench Verified i 2024 for å håndtere disse problemene. Vi jobbet med svært erfarne programvareteknikere for å gjennomgå 1699 SWE-bench-problemer og fjerne problemer som hadde disse feilene. Hvert problem ble vurdert av tre eksperter, uavhengig av hverandre. Denne vurderingsprosessen resulterte i SWE-bench Verified, et nøye utvalgt sett med 500 problemer.

Selv om SWE-bench Verified er en stor forbedring sammenlignet med den opprinnelige versjonen, gjenstår det fortsatt enkelte problemer. Vi gjennomførte en revisjon av problemene med 138 SWE-bench Verified som OpenAI o3 ikke løste konsekvent ved 64 uavhengige kjøringer. Hvert tilfelle ble gjennomgått uavhengig av minst seks erfarne programvareteknikere. Hvis en ekspert flagget et problem, ble det verifisert på nytt av et ekstra team.

Vi fant at 59,4 % av de 138 problemene inneholdt vesentlige problemer i testutforming og/eller problembeskrivelse, noe som gjorde dem ekstremt vanskelige eller umulige å løse selv for den mest kapable modellen eller et menneske. 

• 35,5 % av de reviderte oppgavene har strenge testtilfeller som håndhever spesifikke implementeringsdetaljer, noe som ugyldiggjør mange funksjonelt korrekte innsendelser. Vi kaller dette smale testtilfeller.
• 18,8 % av de reviderte oppgavene har tester som kontrollerer ekstra funksjonalitet som ikke var spesifisert i problembeskrivelsen. Vi kaller dette brede testtilfeller.
• De resterende 5,1 % av oppgavene hadde diverse problemer som ikke var godt nok gruppert ved hjelp av denne taksonomien.

Et illustrerende eksempel på den første feilmodusen er pylint-dev__pylint-4551⁠(åpnes i et nytt vindu), der PR introduserer en ny funksjon, «get_annotation», som en del av den overordnede løsningen. Dette funksjonsnavnet er ikke nevnt i problembeskrivelsen, men importeres direkte av testene. Selv om noen modeller intuitivt kan komme til å lage en slik funksjon, er det ikke strengt nødvendig å implementere en funksjon med dette spesifikke navnet for å løse problemet riktig. Mange gyldige løsninger stryker på testene på grunn av importfeil.

Et eksempel på for brede testsaker er sympy__sympy-18199⁠(åpnes i et nytt vindu). Denne oppgaven stammet fra en PR som tok for seg tre separate problemer med «nthroot_mod»-funksjonen, nærmere bestemt nr. 17373⁠(åpnes i et nytt vindu), nr. 17377⁠(åpnes i et nytt vindu) og nr. 18212⁠(åpnes i et nytt vindu). Beskrivelsen for SWE-bench Verified-oppgaven dekker imidlertid bare det siste problemet nr. 18212⁠(åpnes i et nytt vindu). Dette skaper et misforhold: PR-testene dekker alle tre problemene, mens beskrivelsen bare beskriver ett problem. I våre kjøringer implementerer modeller ofte den beskrevne rettelsen korrekt, og består deretter ikke tester som dekker implementering for de to andre problemene.

SWE-bench Verified og lagrene, (kodebaser og versjonsnotater), er begge åpen kildekoder som er mye brukt og diskutert, noe som gjør det vanskelig for utviklere å unngå kontaminering.

Vi oppdaget først tegn på kontaminering i våre egne modeller. For eksempel, da GPT‑5.2 løste 31 oppgaver vi identifiserte som nesten umulige å løse. I django__django-14725⁠(åpnes i et nytt vindu) krever testene en spesifikk ny parameter «edit_only» som ikke er eksplisitt påkrevd av problemformuleringen. Mens GPT‑5.2 løser problemet, viser den i sin tankerekke at den har informasjon om versjonsnotatene som beskriver endringer i kodebasen, og identifiserer korrekt at «edit_only»-parameteren ble introdusert i Django 4.1.

For å vurdere hvor betydelig kontaminering er i et bredere perspektiv, opprettet vi et automatisert red-teaming-oppsett. For hvert SWE-bench Verified-spørsmål ga vi GPT‑5 i oppgave å teste en GPT‑5.2‑Chat. Claude Opus 4.5 og Gemini 3 Flash Preview for kontaminering. Disse modellene ble valgt for å utelukke resonneringsmodeller, men vi erkjenner at det sannsynligvis er et ikke-trivielt kapabilitetsgap mellom dem.

For å undersøke for kontaminering, mottok GPT‑5: SWE-bench Verified-oppgavens ID, beskrivelse, Gold patch og PR-tester. I løpet av 15 runder lot vi GPT‑5 variere system-/utvikler-meldinger, brukermeldinger, assistentens forhåndsutfylling og ulike metoder for innhenting av informasjon. Etter hver runde merket en dommermodell hvor mye ny, oppgavespesifikk informasjon som dukket opp, og hvert svar ble merket for alvorlighetsgrad av kontaminering fra «ingen» til «sterk.» GPT‑5 fikk lov til å tilpasse strategien sin basert på tidligere runder for iterativt å gjenopprette oppgavespesifikke detaljer. For hvert eksempel på sterk kontaminering, verifiserte vi med en annen dommer at GPT‑5 ikke lekket for mye informasjon til målmodellen. Til slutt gikk vi deretter manuelt gjennom de «sterke» eksemplene som utgjør transkripsjonene i dette innlegget.

Du finner eksempler på sterk kontaminering på tvers av forskjellige modellleverandører nedenfor.

Gitt en kort utdrag fra oppgavebeskrivelsen, genererer GPT‑5.2 ut den nøyaktige Gold patch. Den vet spesielt det nøyaktige klasse- og metodenavnet, og den nye, tidlige returbetingelsen «if username is None or password is None» som blir introdusert.

Oppgave-ID: django__django-11451⁠(åpnes i et nytt vindu)

Opus er i stand til ikke bare å gjenkalle den nøyaktige 4-linjers funksjonelle endringen som PR introduserte, i tillegg til det spesifikke filnavnet og metoden den berørte, men siterer også ordrett den innebygde kommentaren som var en del av forskjellen. 

Oppgave-ID: astropy__astropy-13236⁠(åpnes i et nytt vindu)

Når Gemini 3 Flash ikke får mer informasjon om oppgaven enn ID-en, kan den gjengi ordrett detaljer fra oppgavebeskrivelsen og Gold patch. Dette inkluderer den nye formelen for regulært uttrykk for validering av brukernavn og de nøyaktige linjenumrene for endringen.

Oppgave-ID: django__django-11099⁠(åpnes i et nytt vindu)

Fra denne revisjonen av SWE-bench Verified ser vi to bredere lærdommer for utformingen av evalueringer. For det første medfører referansemålinger basert på offentlig tilgjengelig materiale en risiko for kontaminering, der eksponering av opplæringsdata kan føre til kunstig oppblåste resultater. Hvis offentlig indekserte data brukes i utformingen av referansemålinger, bør modellutviklere utføre ytterligere tester for kontaminering. Referansemålinger, og til og med løsningene som legges ut offentlig, kan ende opp i opplæringsdata. Det bør utvises ekstra forsiktighet både for hvordan datasett publiseres (dvs. passordbeskyttet) og datafiltrering for opplæringsdata (dvs. streng overholdelse av canary strings). 

For det andre er automatisert poenggiving vanskelig å få riktig. Perfekte testtilfeller bør fullt ut verifisere korrekt funksjonalitet, ved både å være uavhengig av spesifikke, uviktige implementeringsdetaljer samt være robuste mot snarveisløsninger. Disse problemene er iboende komplekse og vanskelige å løse. For å fange opp disse problemene, krevde det flere omfattende kampanjer med menneskelig merking. 

Vi har innlemmet disse funnene i vårt nylige evalueringsarbeid. De siste månedene har vi valgt å rapportere resultater fra offentlig deling av SWE-Bench Pro. Vi anbefaler at andre modellutviklere gjør det samme. SWE-bench Pro er ikke perfekt, men ser empirisk ut til å ha færre problemer med kontaminering. Kontamineringsprosessen vår fant noen tilfeller av kontaminering, men disse tilfellene var betydelig sjeldnere og mindre alvorlige enn SWE-bench Verified, og ingen modeller var i stand til å produsere en fullstendig ordrett Gold patch.

Vi vil fortsette å investere i originale, privat utformede referansemålinger, og be bransjen og akademia om hjelp til å gjøre det samme. I GDPVal⁠ utformes oppgaver privat av domeneeksperter, noe som reduserer eksponeringsrisikoen, og løsninger vurderes helhetlig av opplærte vurderere. Denne tilnærmingen er ressurskrevende, men stadig mer nødvendig for å måle reelle kapabilitetsforbedringer.