At skelne signal fra støj i kodeevalueringer

Det er vigtigt at måle vores modellers kapaciteter præcist for at træffe solide beslutninger om udrulning og sikkerhed, herunder beslutninger under OpenAIs Preparedness Framework⁠(åbner i et nyt vindue). Ved hver modeludgivelse rapporterer vi resultater for en række eksterne og interne benchmarks for at følge modellernes fremskridt. Når evalueringer har fejl, der påvirker resultaterne, kan de give et falsk billede af kapaciteter, misrepræsentere sikkerhedsvurderinger og påvirke forskningsprioriteter.

Vi undersøgte for nylig, hvordan et af de mest udbredte benchmarks for kodning, SWE-bench Verified, havde grundlæggende design- og kontamineringsproblemer, og fandt, at evalueringen ikke længere gav et meningsfuldt signal om kapaciteter inden for softwareudvikling. Dengang opfordrede vi det bredere community til at skifte til SWE-Bench Pro.

SWE-Bench Pro⁠(åbner i et nyt vindue) blev designet til at forbedre SWE-bench Verified ved at teste modeller over længere tidshorisonter og på mere realistiske kodningsopgaver for bedre at følge kapaciteter inden for agentisk kodning. Som i SWE-bench Verified hentes opgaverne programmatisk fra historikken over funktionsændringer i en række offentlige og private lagre. Modellerne skal implementere en løsning, der består nye tests for en funktion uden at ødelægge eksisterende funktionalitet. På den offentlige del med 731 opgaver forbedrede banebrydende modeller sig fra en beståelsesrate på 23,3 % til 80,3 % på otte måneder.

Vi har siden udført en lignende audit af SWE-Bench Pro, hvor vi gennemgik datasættet ved hjælp af en datapunktanalyse-pipeline. Pipelinen gennemgik modellens forsøg på opgaven, opgavemetadata og fejlspor for at markere sandsynlige evalueringsfejl. Hver markeret opgave blev derefter vurderet gennem flere gennemløb med investigator-agenter og uafhængigt gennemgået af fem erfarne softwareingeniører, hvor uenigheder blev eskaleret til yderligere undersøgelse.

Problemerne faldt primært i fire kategorier:

• For strenge tests¹ håndhæver specifikke implementeringsdetaljer, som ikke er angivet i prompten, og gør mange funktionelt korrekte besvarelser ugyldige.
• Utilstrækkeligt specificerede prompts² udelader krav, som skjulte tests håndhæver, og som ikke med rimelighed kan udledes.
• Tests med lav dækning kontrollerer den efterspurgte funktion for lidt, så ufuldstændige rettelser kan bestå.
• En vildledende prompt leder modellerne mod den forkerte adfærd eller modsiger det, testene kræver.

Vores resultater peger på, hvor svært det er at kuratere benchmarks, der er svære, men fair, og på den voksende nytte af agenter til skalerbare kontroller af datakvalitet. På baggrund af disse resultater anslår vi, at ~30 % af opgaverne i SWE-bench Pro er defekte, og anbefaler, at modeludviklere undersøger resultaterne nøje.

Vores mål er at sikre, at opgavefejl afspejler reelle begrænsninger ved modellen, og at opgavesucceser afspejler fuldstændige og gyldige løsninger på promptens krav. For at kontrollere kvaliteten af de data, der bruges i evalueringen, oprettede vi en kvalitetssikringspipeline til at vurdere, om hvert datapunkt præcist afspejler modellens kapaciteter.

Et indledende automatiseret filter gennemgår de instruktioner, modellen får, modellens forsøg på at løse opgaven og de tests, der bruges til at bedømme disse forsøg, for at markere sandsynligt defekte eller problematiske eksempler. Dette filter markerede 286 potentielt defekte opgaver. Derefter gennemførte vi en dybere gennemgang af denne delmængde på to måder: en menneskeovervåget agentgennemgang, der udfører omfattende kontroller med investigator-agenter og en endelig menneskelig vurdering, samt en menneskelig annoteringskampagne med erfarne softwareudviklere.

Hvert markeret problem auditeres med Codex-baserede investigator-agenter, som fik adgang til opgavens lager og miljø. Det hjælper dem med at skelne mellem rimelig opgaveuklarhed, som ofte kan afklares ved at studere nærliggende kode og konventioner i lageret, og reel underspecificering. Agenten kan køre tests, inspicere filer i repoet og undersøge modellens forsøg og deres almindelige fejltilstande på opgaven. Efter flere uafhængige gentagelser af disse dybere audits gennemgik en forsker resuméerne, traf en endelig vurdering og mærkede de sandsynlige problemer.

Sideløbende gennemførte vi en menneskelig annoteringskampagne for den markerede delmængde. Vi arbejdede med erfarne softwareingeniører, som blev oplært i benchmarkets mål, problemtypologien og edge cases, før de gennemgik opgaverne. Hver opgave blev gennemgået af fem ingeniører.

Reviewerene dannede en uafhængig vurdering ud fra den synlige problemformulering, testcases og den korrekte referenceløsning (kendt som gold patch), før de brugte pipelineanalysen eller transskriptionen som understøttende kontekst. Reviewerene tildelte derefter en etiket og en alvorlighedsgrad baseret på konkret evidens og eskalerede uenigheder eller sager med lav sikkerhed til yderligere gennemgang.

Menneskelige reviewere var mere tilbøjelige end investigator-agenterne til at markere opgaver som defekte. Der var også en vis uenighed om kategorier mellem de to gennemgangsspor, men i ingen markeret opgave var “ikke defekt” den mest almindelige menneskelige etiket. For de kategorier, agentpipelinen markerede, overlappede reviewernes vurderinger i 74 % af tilfældene.

Sammenlignet med agentpipelinen var de menneskelige reviewere også mere tilbøjelige til at vælge flere etiketter for en opgave, hvilket indikerer, at de fandt opgaver defekte på flere måder, eller at de ikke passede rent ind i én kategori. Det tyder på, at agent-plus-reviewer-pipelinen gav en konservativ mærkning: Den fangede de samme brede fejltilstande, som mennesker identificerede, men talte for få tilfælde, hvor reviewere så yderligere eller overlappende problemer. Den største forskel var i tests med lav dækning, som mennesker valgte som det mest almindelige problem for 9,4 % af benchmarket sammenlignet med 4,1 % fra agentpipelinen.

De problemer, vi har identificeret, sammen med lignende tilfælde i SWE-bench Verified, understreger vigtigheden af at kontrollere benchmarks grundigt. Issues og pull requests fra open source-lagre blev oprindeligt oprettet til menneskeligt samarbejde, ofte gennem lange frem-og-tilbage-forløb mellem maintainere og bidragydere. Derfor passer problembeskrivelser, flettet kode og unit tests ikke altid sammen som rene, isolerede opgaver til pålidelig evaluering af modeller. Især kan tests, der indgår i pull requests, være for strenge, fordi de er skrevet til at validere en bestemt ændring frem for at definere en implementeringsagnostisk standard for at løse opgaven.

Samtidig er evalueringsfejl lettere at opdage nu, end de ville have været selv for kort tid siden. Efterhånden som modellernes kapaciteter forbedres, kan vi bruge disse modeller til at inspicere prompts, tests, patches, spor og edge cases med langt større dybde og konsistens, hvilket hjælper med at afdække benchmarkproblemer, som tidligere var dyre eller upraktiske at finde i stor skala.

Vi håber, at det bredere evalueringsfællesskab vil udvikle nye benchmarks, der bygges af erfarne softwareudviklere specifikt for at teste modellernes kapaciteter. Den tilgang kan bevare det høje niveau og den realisme, vi ønsker, når vi måler modelkapaciteter, og den muliggør bedre menneskeligt tilsyn gennem hele processen. På grund af de problemer, denne analyse har afdækket, trækker vi vores tidligere anbefaling om at tage SWE-Bench Pro i brug tilbage.

I sidste ende bør en eval give et meningsfuldt signal gennem benchmarks, der er svære at game, nemme at have tillid til og reelt afspejler modellens kapacitet eller alignment. Fordi disse resultater informerer OpenAIs beslutninger om udrulning og sikkerhed, skal de evalueringer, vi følger, være gyldige og informative.