8. srpnja 2026.

Razdvajanje signala od šuma u evaluacijama kodiranja

Detaljnom revizijom nalazimo raširene probleme sa zadacima u SWE-Bench Pro i procjenjujemo da je oko 30 % zadataka neispravno.

Učitavanje…

Točno mjerenje sposobnosti naših modela važno je za donošenje utemeljenih odluka o uvođenju i sigurnosti, uključujući odluke prema OpenAI-jevu Okviru pripravnosti⁠(otvara se u novom prozoru). Sa svakim izdanjem modela izvješćujemo o rezultatima na različitim vanjskim i internim referentnim testovima kako bismo pratili napredak modela. Kada evaluacije imaju manjkavosti koje utječu na rezultate, mogu stvoriti pogrešnu predodžbu o sposobnostima modela, iskriviti sigurnosne argumente i utjecati na istraživačke prioritete.

Nedavno smo istražili temeljne probleme u dizajnu i kontaminaciji jednog od najčešće korištenih referentnih testova za programiranje, SWE-bench Verified, te utvrdili da ta evaluacija više ne pruža smislen signal o sposobnostima razvoja softvera. Tada smo potaknuli širu zajednicu da prijeđe na SWE-Bench Pro.

SWE-Bench Pro⁠(otvara se u novom prozoru) osmišljen je kao poboljšanje u odnosu na SWE-bench Verified tako što modele testira na duljim vremenskim horizontima i realističnijim programerskim zadacima kako bi se bolje pratile sposobnosti agentskog programiranja. Kao i u SWE-bench Verified, zadaci se programski izvode iz povijesti promjena značajki u skupu javnih i privatnih repozitorija. Modeli moraju implementirati rješenje koje prolazi nove testove za određenu značajku, a da pritom ne naruše postojeću funkcionalnost. Na javnom podskupu od 731 zadatka stopa prolaznosti graničnih modela porasla je s 23,3 % na 80,3 % u osam mjeseci.

Otad smo proveli sličnu reviziju SWE-Bench Proa, pregledavši skup podataka pomoću cjevovoda za analizu podatkovnih točaka. Cjevovod je pregledao pokušaje modela da riješe zadatke, metapodatke zadataka i tragove neuspjeha kako bi označio vjerojatne manjkavosti evaluacije. Svaki označeni zadatak zatim je prošao više neovisnih pregleda istraživačkih agenata, a zasebno ga je pregledalo pet iskusnih softverskih inženjera. Slučajevi neslaganja upućeni su na dodatnu istragu.

Pronalazimo dokaze o neispravnostima u znatnom dijelu skupa podataka. Naš cjevovod za analizu podatkovnih točaka označio je 200 (27,4 %) neispravnih zadataka, dok ih je kampanja ljudskog označavanja identificirala 249 (34,1 %).

Problemi su uglavnom spadali u četiri kategorije:

Prestrog testovi¹ nameću određene implementacijske pojedinosti koje nisu navedene u upitu, zbog čega mnoga funkcionalno ispravna rješenja ne prolaze.
Nedovoljno specificirani upiti² izostavljaju zahtjeve koje skriveni testovi zahtijevaju, a nije ih moguće razumno zaključiti.
Testovi niske pokrivenosti nedovoljno provjeravaju traženu značajku, pa nepotpuna rješenja mogu proći.
Obmanjujući upit usmjerava modele prema pogrešnom ponašanju ili proturječi onome što testovi zahtijevaju.

Naši nalazi pokazuju koliko je teško sastaviti zahtjevne, ali pravedne referentne testove te koliko agenti postaju korisni za opsežne provjere kvalitete podataka. S obzirom na te rezultate, procjenjujemo da je oko 30 % zadataka u SWE-bench Pro neispravno te savjetujemo razvojnim timovima koji rade na modelima da pažljivo analiziraju rezultate.

Metodologija

Cilj nam je osigurati da neuspjesi na zadacima odražavaju stvarna ograničenja modela, a uspješno riješeni zadaci potpuna i valjana rješenja svih zahtjeva iz upita. Kako bismo provjerili kvalitetu podataka korištenih u evaluaciji, izradili smo cjevovod za osiguravanje kvalitete kojim procjenjujemo odražava li svaka podatkovna točka točno sposobnosti modela.

Tijek osiguravanja kvalitete koji kombinira automatiziranu provjeru i ljudski pregled radi procjene kvalitete zadataka. — Početni cjevovod za provjeru kvalitete podataka označava probleme za daljnji pregled. Nalaze potvrđujemo detaljnijom revizijom označenih zadataka uz pomoć agenta te kampanjom ljudskog označavanja u kojoj sudjeluju iskusni inženjeri.

Početni automatizirani filtar pregledava upute dane modelu, njegove pokušaje rješavanja zadatka i testove kojima se ti pokušaji ocjenjuju kako bi označio vjerojatno neispravne ili problematične primjere. Filtar je označio 286 potencijalno neispravnih zadataka. Zatim smo taj podskup detaljnije pregledali na dva načina: pregledom uz pomoć agenata pod ljudskim nadzorom, koji obuhvaća opsežne provjere istraživačkih agenata i konačnu ljudsku prosudbu, te kampanjom ljudskog označavanja u kojoj su sudjelovali iskusni softverski programeri.

Pregled uz pomoć agenata pod ljudskim nadzorom

Svaki označeni problem revidiraju istraživački agenti temeljeni na Codexu, kojima je omogućen pristup repozitoriju i okruženju zadatka. To im pomaže razlikovati opravdanu dvosmislenost zadatka, koja se često može razriješiti proučavanjem okolnog koda i konvencija repozitorija, od stvarne nedovoljne specificiranosti. Agent može pokretati testove, pregledavati datoteke u repozitoriju te analizirati pokušaje modela i njihove uobičajene obrasce neuspjeha pri rješavanju zadatka. Nakon nekoliko neovisnih ponavljanja tih detaljnijih revizija istraživač je pregledao sažetke, donio konačnu prosudbu i označio vjerojatne probleme.

Kampanja ljudskog označavanja

Paralelno smo proveli kampanju ljudskog označavanja za označeni podskup. Surađivali smo s iskusnim softverskim inženjerima koji su prije pregleda zadataka prošli obuku o ciljevima referentnog testa, taksonomiji problema i rubnim slučajevima. Svaki zadatak pregledalo je pet inženjera.

Recenzenti su najprije donijeli neovisnu prosudbu na temelju vidljivog opisa problema, testnih slučajeva i referentnog rješenja koje se smatra točnim, poznatog kao gold patch. Tek su zatim analizu cjevovoda ili zapis koristili kao dodatni kontekst. Na temelju konkretnih dokaza dodijelili su oznaku i ocjenu ozbiljnosti te slučajeve neslaganja ili niske sigurnosti u procjenu uputili na daljnji pregled.

Ljudski recenzenti češće su od istraživačkih agenata označavali zadatke kao neispravne. Između dvaju postupaka pregleda bilo je i određenih neslaganja u pogledu kategorija, ali ni za jedan označeni zadatak „ispravan” nije bio najčešći odabir ljudskih recenzenata. Procjene recenzenata podudarale su se s kategorijama koje je označio cjevovod s agentima u 74 % slučajeva.

U usporedbi s cjevovodom s agentima, ljudski recenzenti češće su jednom zadatku dodjeljivali više oznaka, što znači da su utvrdili više vrsta neispravnosti ili da zadatak nije jasno pripadao samo jednoj kategoriji. To upućuje na to da je cjevovod koji objedinjuje agente i recenzente primjenjivao konzervativan pristup označavanju: obuhvatio je iste opće obrasce neuspjeha koje su utvrdili ljudi, ali nije zabilježio sve slučajeve u kojima su recenzenti pronašli dodatne ili preklapajuće probleme. Najveća razlika odnosila se na testove niske pokrivenosti, koje su ljudi odabrali kao najčešći problem u 9,4 % referentnog testa, u usporedbi s 4,1 % prema cjevovodu s agentima.

Obrasci neuspjeha

U nekoliko je slučajeva upit za zadatak propisivao određenu implementaciju, ali su skriveni testni slučajevi očekivali drukčije ponašanje.

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

Bez problema

1"[space]| Chapter 1 | 1"
2"**[space]| Chapter 1 | 1"
3"[space]| Just title | "

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

Bez problema

1"[space][space]| Chapter 1 | 1"
2"**[space][space]| Chapter 1 | 1"
3"[space][space]| Just title | "

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

Rasprava

Problemi koje smo identificirali, zajedno sa sličnim slučajevima u SWE-bench Verified, naglašavaju važnost rigorozne provjere referentnih testova. Prijave problema i pull requestovi iz repozitorija otvorenog koda izvorno su namijenjeni ljudskoj suradnji, koja često uključuje dugotrajnu komunikaciju između održavatelja i doprinositelja. Zbog toga opisi problema, integrirani kôd i jedinični testovi nisu uvijek usklađeni tako da tvore jasno izdvojene zadatke prikladne za pouzdanu evaluaciju modela. Testovi uključeni u pull requestove mogu biti osobito prestrogi jer su napisani radi provjere određene promjene, a ne radi definiranja standarda za rješavanje zadatka koji ne ovisi o implementaciji

Istodobno, manjkavosti evaluacije danas je lakše otkriti nego što bi to bilo još donedavno. Kako se sposobnosti modela poboljšavaju, te modele možemo koristiti za mnogo detaljniji i dosljedniji pregled upita, testova, zakrpa, tragova i rubnih slučajeva, čime se lakše otkrivaju problemi u referentnim testovima koje je prije bilo skupo ili nepraktično pronalaziti u velikom mjerilu.

Nadamo se da će šira evaluacijska zajednica razviti nove referentne testove koje će iskusni softverski programeri izraditi posebno za testiranje sposobnosti modela. Takav pristup može zadržati željenu razinu zahtjevnosti i realističnosti pri mjerenju sposobnosti modela te omogućiti bolji ljudski nadzor tijekom cijelog procesa. S obzirom na probleme otkrivene ovom analizom, povlačimo svoju raniju preporuku za upotrebu SWE-Bench Proa.

U konačnici, evaluacija bi trebala pružati smislen signal putem referentnih testova koje je teško izigrati, koji ulijevaju povjerenje i koji doista odražavaju sposobnosti ili usklađenost modela. Budući da ti rezultati služe kao temelj za OpenAI-jeve odluke o uvođenju i sigurnosti, evaluacije koje pratimo moraju biti valjane i informativne.