Signaal en ruis scheiden in programmeerevaluaties

Het nauwkeurig meten van de capaciteiten van onze modellen is belangrijk voor verantwoorde beslissingen over implementatie en veiligheid, waaronder beslissingen onder OpenAI's Preparedness Framework⁠(opent in een nieuw venster). Bij elke modelrelease rapporteren we resultaten voor verschillende externe en interne benchmarks om de vooruitgang van modellen te volgen. Wanneer evaluaties fouten bevatten die de resultaten beïnvloeden, kunnen ze een vertekend beeld geven van capaciteiten, waardoor veiligheidsargumenten verkeerd worden voorgesteld en onderzoeksprioriteiten worden beïnvloed.

We hebben onlangs onderzocht hoe een van de meest gebruikte programmeerbenchmarks, SWE-bench Verified, fundamentele ontwerp- en contaminatieproblemen had, en vastgesteld dat de eval geen betekenisvol signaal meer gaf over softwareontwikkelingscapaciteiten. Destijds moedigden we de bredere community aan om over te stappen op SWE-Bench Pro.

SWE-Bench Pro⁠(opent in een nieuw venster) is ontworpen om SWE-bench Verified te verbeteren door modellen te testen over langere horizons en met realistischere programmeertaken, zodat agentic programmeren beter kan worden gevolgd. Net als in SWE-bench Verified worden taken programmatisch gehaald uit de geschiedenis van featurewijzigingen in een reeks publieke en private repositories. Modellen moeten een oplossing implementeren die nieuwe tests voor een feature doorstaat, zonder bestaande functionaliteit te breken. Op de publieke split met 731 taken verbeterden grensverleggende modellen in acht maanden van een slagingspercentage van 23,3% naar 80,3%.

Sindsdien hebben we een vergelijkbare audit uitgevoerd op SWE-Bench Pro, waarbij we de dataset beoordeelden met een datapuntanalysepipeline. De pipeline beoordeelde modelpogingen voor de taak, taakmetadata en faaltraces om waarschijnlijke evaluatiefouten te markeren. Elke gemarkeerde taak werd vervolgens beoordeeld via meerdere rondes met onderzoeker-agents en onafhankelijk beoordeeld door vijf ervaren software-engineers; meningsverschillen werden geëscaleerd voor verder onderzoek.

De problemen vielen voornamelijk in vier categorieën:

• Te strikte tests¹ dwingen specifieke implementatiedetails af die niet in de prompt zijn gespecificeerd, waardoor veel functioneel correcte inzendingen ongeldig worden.
• Onvoldoende gespecificeerde prompts² laten vereisten weg die verborgen tests afdwingen en die niet redelijkerwijs af te leiden zijn.
• Tests met lage dekking controleren de gevraagde feature onvoldoende, waardoor onvolledige fixes kunnen slagen.
• Een misleidende prompt stuurt modellen naar het verkeerde gedrag of is in tegenspraak met wat de tests vereisen.

Onze bevindingen wijzen op de moeilijkheid om lastige maar eerlijke benchmarks samen te stellen, en op het groeiende nut van agents voor schaalbare kwaliteitscontroles van data. In het licht van deze resultaten schatten we dat ongeveer 30% van de SWE-bench Pro-taken defect is, en adviseren we modelontwikkelaars de resultaten zorgvuldig te onderzoeken.

Ons doel is ervoor te zorgen dat taakmislukkingen echte beperkingen van het model weerspiegelen, en taaksuccessen volledige en geldige oplossingen voor de promptvereisten. Om de kwaliteit te controleren van de data die in de evaluatie worden gebruikt, hebben we een kwaliteitsborgingspipeline gebouwd om te beoordelen of elk datapunt modelcapaciteiten nauwkeurig weerspiegelt.

Een eerste geautomatiseerd filter beoordeelt de instructies die aan het model zijn gegeven, de pogingen van het model om de taak op te lossen en de tests waarmee die pogingen worden beoordeeld, om waarschijnlijk defecte of problematische voorbeelden te markeren. Dit filter markeerde 286 mogelijk defecte taken. Vervolgens hebben we die subset op twee manieren grondiger beoordeeld: een door mensen begeleide agentbeoordeling, met uitgebreide controles door onderzoeker-agents en een definitief menselijk oordeel; en een menselijke annotatiecampagne met ervaren softwareontwikkelaars.

Elk gemarkeerd probleem wordt geaudit met op Codex gebaseerde onderzoeker-agents die toegang kregen tot de taakrepository en -omgeving. Dit helpt hen redelijke taakambiguïteit, die vaak kan worden opgelost door nabije code en repositoryconventies te bestuderen, te onderscheiden van echte onderspecificatie. De agent kan tests uitvoeren, bestanden in de repo inspecteren en modelpogingen en hun veelvoorkomende faalwijzen voor de taak onderzoeken. Na meerdere onafhankelijke herhalingen van deze diepere audits beoordeelde een onderzoeker de samenvattingen, velde een definitief oordeel en labelde de waarschijnlijke problemen.

Parallel daaraan voerden we een menselijke annotatiecampagne uit voor de gemarkeerde subset. We werkten met ervaren software-engineers die vóór het beoordelen van taken waren getraind in de benchmarkdoelen, probleemtaxonomie en randgevallen. Elke taak werd door vijf engineers beoordeeld.

Beoordelaars vormden eerst een onafhankelijk oordeel op basis van de zichtbare probleemstelling, testcases en de ground-truth referentieoplossing (bekend als de gold patch), voordat ze de pipelineanalyse of het transcript als ondersteunende context gebruikten. De beoordelaars kenden vervolgens een label en ernstgraad toe op basis van concreet bewijs, en escaleerden meningsverschillen of gevallen met weinig zekerheid voor verdere beoordeling.

Menselijke beoordelaars markeerden taken vaker als defect dan de onderzoeker-agents. Er was ook enige onenigheid over categorieën tussen de twee beoordelingsroutes, maar bij geen enkele gemarkeerde taak was ‘niet defect’ het meest voorkomende menselijke label. Van de categorieën die de agentpipeline markeerde, kwamen de oordelen van de beoordelaars in 74% van de gevallen overeen.

Vergeleken met de agentpipeline selecteerden de menselijke beoordelaars ook vaker meerdere labels voor een taak, wat aangeeft dat zij vonden dat taken op meerdere manieren defect waren of niet netjes in één categorie pasten. Dit suggereert dat de pipeline met agents en menselijke beoordelaars leidde tot conservatieve labeling: ze legde dezelfde brede faalwijzen vast die mensen identificeerden, maar telde te weinig gevallen waarin beoordelaars aanvullende of overlappende problemen zagen. Het grootste verschil zat in tests met lage dekking, die mensen als het meest voorkomende probleem selecteerden voor 9,4% van de benchmark, tegenover 4,1% vanuit de agentpipeline.

De problemen die we hebben vastgesteld, samen met vergelijkbare gevallen in SWE-bench Verified, onderstrepen hoe belangrijk het is benchmarks grondig te controleren. Issues en pull requests uit open-sourcerepositories zijn oorspronkelijk gemaakt voor menselijke samenwerking, vaak via lange uitwisselingen tussen maintainers en bijdragers. Daardoor sluiten probleembeschrijvingen, gemergede code en unittests niet altijd netjes op elkaar aan om schone, geïsoleerde taken te vormen waarmee modellen betrouwbaar kunnen worden geëvalueerd. Tests in pull requests kunnen met name te strikt zijn, omdat ze zijn geschreven om een specifieke wijziging te valideren, niet om een implementatieonafhankelijke standaard te definiëren voor het oplossen van de taak.

Tegelijk zijn evaluatiefouten nu gemakkelijker te detecteren dan zelfs kort geleden het geval zou zijn geweest. Naarmate modelcapaciteiten verbeteren, kunnen we die modellen gebruiken om prompts, tests, patches, traces en randgevallen veel diepgaander en consistenter te inspecteren, waardoor benchmarkproblemen zichtbaar worden die eerder op schaal kostbaar of onpraktisch te vinden waren.

We hopen dat de bredere evaluatiegemeenschap nieuwe benchmarks zal ontwikkelen die door ervaren softwareontwikkelaars specifiek zijn gebouwd om modelcapaciteiten te testen. Die aanpak kan de hoge lat en het realisme behouden die we willen gebruiken om modelcapaciteiten te meten, en maakt betere menselijke supervisie gedurende het hele proces mogelijk. Gezien de problemen die in deze analyse aan het licht zijn gekomen, trekken we onze eerdere aanbeveling om SWE-Bench Pro te gebruiken in.

Uiteindelijk moet een evaluatie een betekenisvol signaal geven via benchmarks die moeilijk te manipuleren zijn, gemakkelijk te vertrouwen en werkelijk representatief voor de capaciteit of alignment van een model. Omdat deze resultaten de implementatie- en veiligheidsbeslissingen van OpenAI informeren, moeten de evaluaties die we volgen geldig en informatief zijn.