Skille signal fra støy i kodeevalueringer

Det er viktig å måle modellenes kapasiteter nøyaktig for å ta gode beslutninger om utrulling og sikkerhet, inkludert beslutninger under OpenAIs Preparedness Framework⁠(åpnes i et nytt vindu). Ved hver modellutgivelse rapporterer vi resultater fra en rekke eksterne og interne benchmarks for å følge modellfremdriften. Når evalueringer har feil som påvirker resultatene, kan de gi et feilaktig bilde av kapasitetene, forvrenge sikkerhetsvurderinger og påvirke forskningsprioriteringer.

Vi har nylig undersøkt hvordan en av de mest brukte kodebenchmarkene, SWE-bench Verified, hadde grunnleggende design- og kontamineringsproblemer, og fant at evalueringen ikke lenger ga meningsfullt signal om programvareutviklingskapasiteter. Den gangen oppfordret vi det bredere miljøet til å gå over til SWE-Bench Pro.

SWE-Bench Pro⁠(åpnes i et nytt vindu) ble utformet for å forbedre SWE-bench Verified ved å teste modeller over lengre horisonter og med mer realistiske kodeoppgaver, slik at agentisk koding kunne måles bedre. Som i SWE-bench Verified hentes oppgaver programmatisk fra historikken over funksjonsendringer i et sett med offentlige og private lagre. Modeller må implementere en løsning som består nye tester for en funksjon, uten å ødelegge eksisterende funksjonalitet. På den offentlige delen med 731 oppgaver forbedret banebrytende modeller bestått-raten fra 23,3 % til 80,3 % på åtte måneder.

Siden har vi gjennomført en lignende revisjon av SWE-Bench Pro, der vi gjennomgikk datasettet ved hjelp av en analysepipeline for datapunkter. Pipelinen gjennomgikk modellforsøk på oppgaven, oppgavemetadata og feilspor for å flagge sannsynlige evalueringsfeil. Hver flaggede oppgave ble deretter vurdert gjennom flere runder med etterforsker-agenter og uavhengig gjennomgått av fem erfarne programvareingeniører, med uenigheter eskalert for videre undersøkelser.

Problemene falt hovedsakelig i fire kategorier:

• For strenge tester¹ håndhever spesifikke implementasjonsdetaljer som ikke er angitt i prompten, og gjør mange funksjonelt riktige innleveringer ugyldige.
• Underspesifiserte prompter² utelater krav som skjulte tester håndhever, og som ikke rimelig kan utledes.
• Tester med lav dekning sjekker den forespurte funksjonen for dårlig, slik at ufullstendige rettinger kan bestå.
• En villedende prompt leder modeller mot feil atferd eller motsier det testene krever.

Funnene våre peker på hvor vanskelig det er å kuratere benchmarks som er krevende, men rettferdige, og på den økende nytten av agenter for skalerbare kontroller av datakvalitet. I lys av disse resultatene anslår vi at ~30 % av oppgavene i SWE-bench Pro er defekte, og anbefaler at modellutviklere gransker resultatene nøye.

Målet vårt er å sikre at oppgavefeil gjenspeiler reelle modellbegrensninger, og at vellykkede oppgaver gjenspeiler fullstendige og gyldige løsninger på kravene i prompten. For å kontrollere kvaliteten på dataene som brukes i evalueringen, opprettet vi en kvalitetssikringspipeline for å vurdere om hvert datapunkt gjenspeiler modellkapasiteter nøyaktig.

Et første automatisert filter gjennomgår instruksjonene modellen får, modellens forsøk på å løse oppgaven og testene som brukes til å vurdere disse forsøkene, for å flagge sannsynlig defekte eller problematiske eksempler. Dette filteret flagget 286 potensielt defekte oppgaver. Deretter gjennomførte vi en grundigere gjennomgang av dette delsettet på to måter: en menneskestyrt agent-gjennomgang, som utfører omfattende kontroller med etterforsker-agenter og en endelig menneskelig vurdering, og en menneskelig annoteringsrunde med erfarne programvareutviklere.

Hvert flaggede problem revideres med Codex-baserte etterforsker-agenter som fikk tilgang til oppgavens lager og miljø. Dette hjelper dem å skille rimelig oppgaveuklarhet, som ofte kan avklares ved å studere nærliggende kode og konvensjoner i lageret, fra reell underspesifisering. Agenten kan kjøre tester, inspisere filer i repoet og undersøke modellforsøk og deres vanlige feilmoduser på oppgaven. Etter flere uavhengige gjentakelser av disse grundigere revisjonene gjennomgikk en forsker sammendragene, gjorde en endelig vurdering og merket de sannsynlige problemene.

Parallelt gjennomførte vi en menneskelig annoteringsrunde på det flaggede delsettet. Vi samarbeidet med erfarne programvareingeniører som fikk opplæring i benchmarkmålene, problemtaksonomien og grensetilfeller før de gjennomgikk oppgavene. Hver oppgave ble gjennomgått av fem ingeniører.

Vurderere dannet seg en uavhengig vurdering basert på den synlige problembeskrivelsen, testtilfellene og den korrekte referanseløsningen (kjent som gold patch) før de brukte pipelineanalysen eller transkripsjonen som støttende kontekst. Deretter tildelte vurdererne en etikett og alvorlighetsgrad basert på konkrete bevis, og eskalerte uenigheter eller tilfeller med lav sikkerhet for videre gjennomgang.

Menneskelige gjennomgåere var mer tilbøyelige enn etterforsker-agentene til å merke oppgaver som defekte. Det var også noe uenighet om kategorier mellom de to gjennomgangsløpene, men for ingen flagget oppgave var «ikke defekt» den vanligste menneskelige etiketten. For kategoriene agent-pipelinen flagget, overlappet vurderernes vurderinger i 74 % av tilfellene.

Sammenlignet med agent-pipelinen var de menneskelige vurdererne også mer tilbøyelige til å velge flere etiketter for en oppgave, noe som tyder på at de fant oppgaver defekte på flere måter eller at de ikke passet rent inn i én kategori. Dette tyder på at agent-pluss-vurderer-pipelinen ga konservativ merking: Den fanget opp de samme brede feilmodusene som mennesker identifiserte, samtidig som den undertalte tilfeller der vurderere så flere eller overlappende problemer. Den største forskjellen gjaldt tester med lav dekning, som mennesker valgte som det vanligste problemet for 9,4 % av benchmarken, sammenlignet med 4,1 % fra agent-pipelinen.

Problemene vi har identifisert, sammen med lignende tilfeller i SWE-bench Verified, understreker hvor viktig det er å kontrollere benchmarks grundig. Issues og pull requests fra åpne kildekodelagre ble opprinnelig laget for menneskelig samarbeid, ofte gjennom lange dialoger mellom vedlikeholdere og bidragsytere. Derfor passer ikke problembeskrivelser, flettet kode og enhetstester alltid sammen til rene, isolerte oppgaver som kan evaluere modeller pålitelig. Særlig kan tester som inngår i pull requests, være for strenge fordi de er skrevet for å validere en bestemt endring, ikke for å definere en implementasjonsuavhengig standard for å løse oppgaven.

Samtidig er evalueringsfeil lettere å oppdage nå enn de ville vært for bare kort tid siden. Etter hvert som modellkapasiteter forbedres, kan vi bruke disse modellene til å inspisere prompter, tester, patcher, spor og grensetilfeller med langt større dybde og konsistens, noe som bidrar til å avdekke benchmarkproblemer som tidligere var kostbare eller upraktiske å finne i stor skala.

Vi håper det bredere evalueringsmiljøet vil utvikle nye benchmarks bygget av erfarne programvareutviklere spesielt for å teste modellkapasiteter. En slik tilnærming kan bevare den høye terskelen og realismen vi ønsker når vi måler modellkapasiteter, og gir bedre menneskelig tilsyn gjennom hele prosessen. På grunn av problemene som er avdekket i denne analysen, trekker vi tilbake vår tidligere anbefaling om å ta i bruk SWE-Bench Pro.

Til syvende og sist bør en evaluering gi meningsfullt signal gjennom benchmarks som er vanskelige å manipulere, enkle å stole på og faktisk gjenspeiler modellkapasitet eller tilpasning. Fordi disse resultatene ligger til grunn for OpenAIs beslutninger om utrulling og sikkerhet, må evalueringene vi følger, være gyldige og informative.