Skilja signal från brus i kodningsutvärderingar

Att mäta våra modellers förmågor korrekt är viktigt för välgrundade beslut om lansering och säkerhet, inklusive beslut enligt OpenAI:s Preparedness Framework⁠(öppnas i ett nytt fönster). Vid varje modellsläpp rapporterar vi resultat för en rad externa och interna riktmärken för att följa modellernas utveckling. När utvärderingar har brister som påverkar resultaten kan de ge en felaktig bild av förmågorna, misstolka säkerhetsfall och påverka forskningsprioriteringar.

Vi undersökte nyligen hur ett av de mest använda riktmärkena för kodning, SWE-bench Verified, hade grundläggande problem med design och kontaminering, och fann att utvärderingen inte längre gav någon meningsfull signal om förmågor inom mjukvaruutveckling. Vid den tidpunkten uppmuntrade vi den bredare communityn att gå över till SWE-Bench Pro.

SWE-Bench Pro⁠(öppnas i ett nytt fönster) utformades för att förbättra SWE-bench Verified genom att testa modeller över längre tidshorisonter och med mer realistiska kodningsuppgifter för att bättre följa förmågor inom agentbaserad kodning. Precis som i SWE-bench Verified hämtas uppgifter programmatiskt från historiken över funktionsändringar i en uppsättning offentliga och privata förvar. Modeller måste implementera en lösning som klarar nya tester för en funktion, utan att bryta befintlig funktionalitet. I den offentliga delmängden med 731 uppgifter förbättrades banbrytande modeller från en godkändgrad på 23,3 % till 80,3 % på åtta månader.

Sedan dess har vi genomfört en liknande granskning av SWE-Bench Pro och gått igenom datauppsättningen med en pipeline för datapunktsanalys. Pipelinen granskade modellförsök på uppgiften, uppgiftsmetadata och felspårningar för att flagga sannolika utvärderingsbrister. Varje flaggad uppgift bedömdes sedan genom flera genomgångar av undersökningsagenter och granskades oberoende av fem erfarna mjukvaruingenjörer, med oenigheter eskalerade för vidare utredning.

Problemen föll främst inom fyra kategorier:

• Alltför strikta tester¹ kräver specifika implementationsdetaljer som inte anges i prompten, vilket ogiltigförklarar många funktionellt korrekta inlämningar.
• Underspecificerade prompter² utelämnar krav som dolda tester upprätthåller och som inte rimligen kan härledas.
• Tester med låg täckning kontrollerar den begärda funktionen för lite, så ofullständiga korrigeringar kan godkännas.
• En vilseledande prompt styr modeller mot fel beteende eller motsäger vad testerna kräver.

Våra resultat visar hur svårt det är att kurera svåra men rättvisa riktmärken och hur agenter blir allt mer användbara för skalbara datakvalitetskontroller. Mot bakgrund av dessa resultat uppskattar vi att cirka 30 % av uppgifterna i SWE-bench Pro är bristfälliga, och rekommenderar att modellutvecklare granskar resultaten noggrant.

Vårt mål är att säkerställa att misslyckanden i uppgifter speglar verkliga modellbegränsningar, och att framgångar i uppgifter speglar fullständiga och giltiga lösningar på promptkraven. För att kontrollera kvaliteten på de data som används i utvärderingen skapade vi en kvalitetssäkringspipeline för att bedöma om varje datapunkt korrekt speglar modellernas förmågor.

Ett inledande automatiserat filter granskar instruktionerna som ges till modellen, modellens försök att lösa uppgiften och de tester som används för att bedöma dessa försök, för att flagga sannolikt bristfälliga eller problematiska exempel. Detta filter flaggade 286 potentiellt bristfälliga uppgifter. Därefter gjorde vi en djupare granskning av den delmängden på två sätt: en människostyrd agentgranskning, som gör omfattande kontroller med undersökningsagenter och en slutlig mänsklig bedömning, samt en mänsklig annoteringskampanj med erfarna mjukvaruutvecklare.

Varje flaggat problem granskas med Codex-baserade undersökningsagenter som fick åtkomst till uppgiftsförvaret och miljön. Det hjälper dem att skilja rimlig tvetydighet i uppgiften, som ofta kan lösas genom att studera närliggande kod och förvarskonventioner, från verklig underspecificering. Agenten kan köra tester, inspektera filer i förvaret och undersöka modellförsök och deras vanliga fellägen på uppgiften. Efter flera oberoende upprepningar av dessa djupare granskningar gick en forskare igenom sammanfattningarna, gjorde en slutlig bedömning och etiketterade de sannolika problemen.

Parallellt genomförde vi en mänsklig annoteringskampanj för den flaggade delmängden. Vi arbetade med erfarna mjukvaruingenjörer som utbildades i riktmärkets mål, problemtaxonomin och gränsfall innan de granskade uppgifter. Varje uppgift granskades av fem ingenjörer.

Granskarna bildade sig en oberoende uppfattning utifrån den synliga problembeskrivningen, testfallen och den korrekta referenslösningen (känd som gold patch) innan de använde pipelineanalysen eller transkriptet som stödjande kontext. Granskarna tilldelade sedan en etikett och en allvarlighetsgrad baserat på konkreta belägg, och eskalerade oenigheter eller fall med låg säkerhet för vidare granskning.

Mänskliga granskare var mer benägna än undersökningsagenterna att markera uppgifter som bristfälliga. Det fanns också viss oenighet om kategorier mellan de två granskningsvägarna, men i ingen flaggad uppgift var ”inte bristfällig” den vanligaste mänskliga etiketten. För de kategorier som agentpipelinen flaggade överlappade granskarnas bedömningar i 74 % av fallen.

Jämfört med agentpipelinen var de mänskliga granskarna också mer benägna att välja flera etiketter för en uppgift, vilket tyder på att de ansåg att uppgifter var bristfälliga på flera sätt eller inte passade tydligt in i en enda kategori. Detta tyder på att pipelinen med agenter plus granskare gav konservativ etikettering: den fångade samma breda fellägen som människor identifierade, men underskattade fall där granskarna såg ytterligare eller överlappande problem. Den största skillnaden gällde tester med låg täckning, som människor valde som det vanligaste problemet för 9,4 % av riktmärket jämfört med 4,1 % från agentpipelinen.

De problem vi har identifierat, tillsammans med liknande fall i SWE-bench Verified, understryker vikten av att granska riktmärken noggrant. Issues och pull requests från öppna förvar skapades ursprungligen för mänskligt samarbete, ofta genom långa diskussioner fram och tillbaka mellan underhållare och bidragsgivare. Därför passar problembeskrivningar, mergad kod och enhetstester inte alltid ihop till rena, isolerade uppgifter för tillförlitlig utvärdering av modeller. I synnerhet kan tester som ingår i pull requests vara alltför strikta eftersom de är skrivna för att validera en specifik ändring, snarare än för att definiera en implementationsoberoende standard för att lösa uppgiften.

Samtidigt är utvärderingsbrister lättare att upptäcka nu än de skulle ha varit för bara en kort tid sedan. När modellernas förmågor förbättras kan vi använda dessa modeller för att granska prompter, tester, patchar, spårningar och gränsfall med mycket större djup och konsekvens, vilket hjälper till att lyfta fram riktmärkesproblem som tidigare var kostsamma eller opraktiska att hitta i stor skala.

Vi hoppas att den bredare utvärderingscommunityn utvecklar nya riktmärken som byggs av erfarna mjukvaruutvecklare specifikt för att testa modellförmågor. Det angreppssättet kan bevara den höga ribba och realism vi vill mäta modellförmågor mot, och möjliggör bättre mänsklig tillsyn genom hela processen. Med tanke på problemen som denna analys har avslöjat drar vi tillbaka vår tidigare rekommendation att införa SWE-Bench Pro.

I slutänden bör en utvärdering ge en meningsfull signal genom riktmärken som är svåra att manipulera, lätta att lita på och verkligen speglar modellförmåga eller alignment. Eftersom dessa resultat informerar OpenAI:s beslut om lansering och säkerhet måste utvärderingarna vi följer vara giltiga och informativa.