Varför SWE-bench Verified inte längre mäter banbrytande kodningsfunktioner

Sedan vi först publicerade SWE-bench Verifierad i augusti 2024 har branschen i stor utsträckning använt det för att mäta framsteg för modeller inom autonoma uppgifter i programvaruutveckling. Efter lanseringen gav SWE-bench Verifierad en stark signal om framsteg i kapacitet och blev ett standardmått som rapporteras i lanseringar av banbrytande modeller. Att hålla koll på och förutse utvecklingen av dessa funktioner är också en viktig del av OpenAI:s Preparedness Framework. När vi först skapade riktmärket Verified försökte vi lösa problem i den ursprungliga utvärderingen som gjorde vissa uppgifter omöjliga att genomföra i SWE-bench datamängder⁠(öppnas i ett nytt fönster).

Efter inledande språng har den toppmoderna utvecklingen på SWE-bench Verifierad saktat in och förbättrats⁠(öppnas i ett nytt fönster) från 74,9 % till 80,9 % under de senaste sex månaderna. Detta väcker frågan: återspeglar de återstående felen modellens begränsningar eller egenskaper hos datamängden i sig?

I en ny analys fann vi två stora problem med Verified-datamängden som tyder på att riktmärket inte längre är lämpligt för att mäta framsteg inom autonoma mjukvaruutvecklingsfunktioner för banbrytande lanseringar på dagens prestandanivåer:

1. Tester underkänner korrekta lösningar: Vi granskade en delmängd på 27,6 % av datamängden som modeller ofta misslyckades med lösningar och fann att minst 59,4 % av de granskade problemen har bristfälliga testfall som underkänner funktionellt korrekta inlämningar, trots våra bästa ansträngningar att förbättra detta när vi skapade SWE-bench Verified i första början.
2. Träning på lösningar: Eftersom stora banbrytande modeller kan lära sig från sin träning är det viktigt att de aldrig tränas på problem och lösningar som de utvärderas på. Detta är ungefär som att dela problem och lösningar för ett kommande prov med eleverna före provet – de kanske inte memorerar svaret, men elever som har sett svaren tidigare kommer definitivt att klara sig bättre än de som inte har det. SWE-bench-problem hämtas från förvar med öppen källkod som många leverantörer av modeller använder för träningsändamål. I vår analys fann vi att alla banbrytande modeller vi testade kunde reproducera den ursprungliga, människoskrivna buggfixen som användes som grundsanningsreferens, en så kallad ”gold patch”, eller ordagranna detaljer i problembeskrivningen för vissa uppgifter, vilket indikerar att samtliga har sett åtminstone några av problemen och lösningarna under träningen.

Vi hittade också belägg för att modeller som har sett problemen under träningen har större sannolikhet att lyckas, eftersom de har ytterligare information som behövs för att klara de underspecificerade testerna.

Detta innebär att förbättringar på SWE-bench Verified inte längre återspeglar meningsfulla förbättringar i modellers verkliga förmåga till programvaruutveckling. I stället återspeglar de i allt högre grad hur mycket modellen exponerades för riktmärket under träningen. Det är därför vi har slutat rapportera SWE-bench Verified-resultat, och vi rekommenderar att andra modellutvecklare gör detsamma.

Vi bygger nya, inte kontaminerade utvärderingar för att bättre kunna följa kodningsförmågor, och vi anser att detta är ett viktigt område att fokusera på för det bredare forskarsamhället. Tills vi har dem på plats rekommenderar OpenAI att rapportera resultat för SWE-bench Pro.

Den ursprungliga SWE-bench⁠(öppnas i ett nytt fönster)-utvärderingen släpptes 2023. Varje problem hämtas från ett löst GitHub-problem i ett av 12 förvar med öppen källkod och paras ihop med motsvarande pull request (PR). För att avgöra om en modellgenererad kodändring är korrekt testas varje problem med två testuppsättningar:

• Tester som misslyckas på den omodifierade kodbasen, men genomförs om problemet åtgärdas korrekt
• Regressionstester som godkänns både före och efter korrigeringen för att säkerställa att orelaterad funktionalitet förblir densamma.

Modellen ser inte testerna. Den måste producera en kodändring med endast den ursprungliga problemtexten och tillståndet för förvaret före åtgärden. Den godkänns bara om alla tester godkänns efter att kodändringen har tillämpats.

Vi hittade många problem med den utvärderingen som skulle kunna leda till en underrapportering av modellernas kapacitet.

• Vissa enhetstester var alltför specifika eller feljusterade i förhållande till uppgiften så att korrekta åtgärder kunde nekas.
• Många uppgiftsbeskrivningar var underspecificerade, vilket kunde leda till flera giltiga tolkningar – medan testerna bara täckte en specifik.
• Beroende på hur miljön är konfigurerad (till exempel Linux kontra Windows, eller Python-versionen) kan vissa tester misslyckas felaktigt

Vi skapade SWE-bench Verified 2024 för att åtgärda dessa problem. Vi arbetade med erfarna mjukvaruingenjörer för att granska 1 699 SWE-bench-problem och filtrera bort problem som hade dessa fel. Varje problem granskades på ett oberoende sätt av tre experter. Den här granskningsprocessen resulterade i SWE-bench Verifierad, en utvald mängd med 500 problem.

Även om SWE-bench Verifierad är en stor förbättring jämfört med den ursprungliga versionen kvarstår vissa problem. Vi genomförde en granskning av 138 SWE-bench Verified-problem som OpenAI o3 inte löste konsekvent över 64 oberoende körningar. Varje fall granskades oberoende av minst sex erfarna programvaruutvecklare. Om en expert flaggade ett problem verifierades det på nytt av ett ytterligare team.

Vi fann att 59,4 % av de 138 problemen innehöll väsentliga brister i testdesignen och/eller problembeskrivningen, vilket gjorde dem extremt svåra eller omöjliga att lösa även för den mest kapabla modellen eller människan. 

• 35,5 % av de granskade uppgifterna har strikta testfall som upprätthåller specifika implementeringsdetaljer, vilket ogiltigförklarar många funktionellt korrekta inlämningar, vilket vi kallar snäva testfall.
• 18,8 % av de granskade uppgifterna har tester som kontrollerar ytterligare funktionalitet som inte angavs i problembeskrivningen, vilket vi kallar breda testfall.
• De återstående 5,1 % av uppgifterna hade diverse problem som inte var väl grupperade med denna taxonomi.

Ett illustrativt exempel på det första felläget är pylint-dev__pylint-4551⁠(öppnas i ett nytt fönster), där PR:en introducerar en ny funktion `get_annotation` som en del av den övergripande lösningen. Det här funktionsnamnet nämns inte i problembeskrivningen, men importeras direkt av testerna. Även om vissa modeller kan intuitivt skapa en sådan funktion är det inte strikt nödvändigt att implementera en funktion med just det här namnet för att korrekt lösa problemet. Många giltiga lösningar misslyckas på grund av importfel i testerna.

Ett exempel på alltför breda testfall är sympy__sympy-18199⁠(öppnas i ett nytt fönster). Den här uppgiften hämtades från en PR som åtgärdade tre separata problem med funktionen `nthroot_mod`, närmare bestämt #17373⁠(öppnas i ett nytt fönster), #17377⁠(öppnas i ett nytt fönster) och #18212⁠(öppnas i ett nytt fönster). Beskrivningen för SWE-bench Verifierad-uppgiften omfattar dock endast det slutliga problemet #18212⁠(öppnas i ett nytt fönster). Detta skapar en diskrepans: PR-testerna omfattar alla tre problemen, medan beskrivningen bara beskriver ett. I våra körningar implementerar modeller ofta korrekt den beskrivna lösningen och misslyckas sedan med tester som omfattar implementeringen för de andra två problemen.

SWE-bench Verified och förvar (kodbaser och versionsanteckningar) är båda öppen källkod och används och diskuteras i stor utsträckning, vilket gör det svårt för modellutvecklare att undvika kontaminering.

Vi stötte först på tecken på kontaminering i våra egna modeller. Till exempel när GPT‑5.2 löste 31 uppgifter som vi identifierade som nästan omöjliga att lösa. I django__django-14725⁠(öppnas i ett nytt fönster) kräver testerna en specifik ny parameter `edit_only` som inte uttryckligen krävs av problemformuleringen. När GPT‑5.2 löser problemet visar den i sin tankekedja att den har information om versionsanteckningarna som beskriver ändringar i kodbasen och identifierar korrekt att parametern `edit_only` introducerades i Django 4.1.

För att bedöma hur betydande kontamineringen är i ett bredare perspektiv skapade vi en automatiserad read teaming-konfiguration. För varje fråga i SWE-bench Verifierad gav vi GPT‑5 i uppdrag att undersöka en GPT‑5.2‑Chat, Claude Opus 4.5 och Gemini 3 Flash Preview för kontaminering. Dessa modeller valdes för att utesluta resonemangsmodeller, men vi medger att det sannolikt finns ett icke obetydligt kapacitetsgap mellan dem.

För att undersöka kontaminering fick GPT‑5 SWE-bench Verifierad-uppgiftens ID, beskrivning, gold patch och PR-tester. Under drygt 15 omgångar lät vi GPT‑5 variera system-/utvecklarprompten, användarprompten och assistentens förifyllnad samt olika eliciteringsstrategier. Efter varje omgång angav en domarmodell hur mycket ny, uppgiftsspecifik information som förekom och varje svar märktes med kontamineringsgrad från ”ingen” till ”stark”. GPT‑5 fick anpassa sin strategi baserat på tidigare omgångar för att iterativt återhämta uppgiftsspecifika detaljer. För varje exempel på stark kontaminering verifierade vi med en annan domare att GPT‑5 inte läckte för mycket information till målmodellen. Slutligen granskade vi manuellt de ”starka” exemplen som utgör transkriptionerna i det här inlägget.

Nedan följer exempel på stark förorening hos olika modelleverantörer.

Med ett kort utdrag från uppgiftsbeskrivningen genererar GPT‑5.2 en exakt gold patch. Tänk på att den känner till det exakta klass- och metodnamnet samt det nya tidiga returvillkoret `if username is None or password is None` som introducerats.

Uppgifts-ID: django__django-11451⁠(öppnas i ett nytt fönster)

Opus kan inte bara återge den exakta funktionella ändringen på 4 rader som PR:en introducerade, tillsammans med det specifika filnamnet och den metod som den berörde, utan citerar också ordagrant inline-kommentaren som var en del av diffen. 

Uppgifts-ID: astropy__astropy-13236⁠(öppnas i ett nytt fönster)

Gemini 3 Flash kan, när den inte får någon ytterligare information om uppgiften utöver ID:t, återge ordagrant detaljer från uppgiftsbeskrivningen och goldpatchen. Detta inkluderar den nya regex-formeln för validering av användarnamn och de exakta radnumren för ändringen.

Uppgifts-ID: django__django-11099⁠(öppnas i ett nytt fönster)

Utifrån denna granskning av SWE-bench Verified ser vi två bredare lärdomar för utformningen av utvärderingar. För det första innebär benchmarktester som hämtats från offentligt tillgängligt material en risk för kontaminering, där exponering för träningsdata i tysthet kan förbättra poängen. Om offentligt genomsökta data används vid konstruktion av riktmärken bör modellutvecklare utföra ytterligare tester för kontaminering. Riktmärken, och till och med deras lösningar, som publiceras offentligt kan hamna i träningsdata. Extra försiktighet bör iakttas både när det gäller hur datamängder publiceras (dvs. lösenordsskydd) och filtrering av träningsdata (dvs. strikt efterlevnad av varningssträngar). 

För det andra är automatiserad poängsättning knepig att få till. Perfekta testfall bör fullt ut verifiera korrekt funktionalitet, vara både oberoende av specifika oviktiga implementeringsdetaljer och även robusta mot genvägslösningar. Dessa problem är i sig komplexa och svåra att lösa. Att upptäcka dessa problem krävde flera omfattande kampanjer för mänsklig märkning. 

Vi har införlivat dessa resultat i våra senaste utvärderingsinsatser. Under de senaste månaderna har vi valt att rapportera resultat från den offentliga splitten av SWE-Bench Pro. Vi rekommenderar att andra modellutvecklare gör detsamma. SWE-bench Pro är inte perfekt, men verkar empiriskt sett drabbas mindre av kontamineringsproblem. Vår kontamineringspipeline hittade några fall av kontaminering, men dessa fall var betydligt mer sällsynta och mindre allvarliga än SWE-bench Verified, och ingen modell kunde producera en komplett ordagrann goldpatch.

Vi kommer att fortsätta investera i originella, privatförfattade riktmärken och be om hjälp från industrin och den akademiska världen att göra detsamma. I GDPVal⁠ skapas uppgifter privat av domänexperter, vilket minskar exponeringsrisken, och lösningar bedöms holistiskt av utbildade granskare. Den här metoden är resurskrävande, men blir allt mer nödvändig för att mäta verkliga förbättringar av förmågor.