8. juli 2026.

Razdvajanje signala od šuma u evaluacijama kodiranja

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

Učitavanje…

Tačno mjerenje sposobnosti naših modela važno je za utemeljene odluke o implementaciji i sigurnosti, uključujući odluke prema OpenAI-jevom Okvir pripravnosti⁠(otvara se u novom prozoru). Sa svakim izdanjem modela izvještavamo o rezultatima na različitim eksternim i internim referentnim testovima kako bismo pratili napredak modela. Kada evaluacije imaju nedostatke koji utiču na rezultate, mogu dati pogrešnu sliku sposobnosti, pogrešno predstaviti sigurnosne argumente i uticati na istraživačke prioritete.

Nedavno smo istražili kako je jedan od najčešće korištenih referentnih testova za kodiranje, SWE-bench Verified, imao temeljne probleme s dizajnom i kontaminacijom te utvrdili da ta evaluacija više ne pruža smislen signal o sposobnostima razvoja softvera. Tada smo široj zajednici preporučili prelazak 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 testira modele na dužim horizontima i realističnijim zadacima kodiranja kako bi se bolje pratile sposobnosti kodiranja s agentima. Kao i u SWE-bench Verified, zadaci se programski izvode iz historije promjena funkcija u skupu javnih i privatnih repozitorija. Od modela se traži da implementiraju rješenje koje prolazi nove testove za određenu funkciju, a da pritom ne naruši postojeću funkcionalnost. Na javnoj podjeli od 731 zadatka, granični modeli su za osam mjeseci poboljšali stopu prolaznosti s 23,3% na 80,3%.

Od tada smo proveli sličnu reviziju SWE-Bench Pro-a, pregledavajući skup podataka pomoću toka za analizu podatkovnih tačaka. Taj tok je pregledao pokušaje modela na zadatku, metapodatke zadatka i tragove neuspjeha kako bi označio vjerovatne nedostatke evaluacije. Svaki označeni zadatak zatim je procijenjen kroz više prolaza istraživačkih agenata i nezavisno ga je pregledalo pet iskusnih softverskih inženjera, uz eskalaciju neslaganja na dodatnu istragu.

Nalazimo dokaze o problemima koji narušavaju zadatke u značajnom dijelu skupa podataka. Naš tok analize podatkovnih tačaka označio je 200 (27,4%) neispravnih zadataka, dok je kampanja ljudskog anotiranja identificirala 249 (34,1%).

Problemi su se uglavnom svodili na četiri kategorije:

Previše strogi testovi¹ nameću konkretne implementacijske detalje koji nisu navedeni u upitu, čime se poništavaju mnoge funkcionalno tačne predaje.
Nedovoljno specificirani upiti² izostavljaju zahtjeve koje skriveni testovi provode i koji se ne mogu razumno zaključiti.
Testovi s malom pokrivenošću ne provjeravaju dovoljno traženu funkciju, pa nepotpune ispravke mogu proći.
Obmanjujući upit usmjerava modele ka pogrešnom ponašanju ili proturječi onome što testovi zahtijevaju.

Naši nalazi ukazuju na to koliko je teško pripremiti zahtjevne, ali pravedne referentne testove, kao i na sve veću korisnost agenata za skalabilne provjere kvaliteta podataka. U svjetlu ovih rezultata procjenjujemo da je oko 30% zadataka u SWE-bench Pro-u neispravno i savjetujemo developerima modela da pažljivo ispitaju rezultate.

Metodologija

Naš cilj je osigurati da neuspjesi na zadacima odražavaju stvarna ograničenja modela, a uspjesi potpuna i valjana rješenja zahtjeva iz upita. Da bismo provjerili kvalitet podataka korištenih u evaluaciji, kreirali smo tok za osiguranje kvaliteta koji procjenjuje da li svaka podatkovna tačka tačno odražava sposobnosti modela.

Tok rada za osiguranje kvaliteta koji kombinuje automatsku provjeru i ljudski pregled radi procjene kvaliteta zadataka. — Početni tok za kvalitet podataka označava probleme za pregled. Validiramo ih dubljom revizijom označenih zadataka uz pomoć agenta i kampanjom ljudskog anotiranja s iskusnim inženjerima.

Početni automatizirani filter pregledava upute date modelu, pokušaje modela da riješi zadatak i testove korištene za ocjenjivanje tih pokušaja kako bi označio vjerovatno neispravne ili problematične primjere. Ovaj filter je označio 286 potencijalno neispravnih zadataka. Zatim smo proveli dublji pregled tog podskupa na dva načina: pregled agenta pod ljudskim nadzorom, koji provodi opsežne provjere s istraživačkim agentima i završnom ljudskom prosudbom; te kampanju ljudskog anotiranja s iskusnim softverskim developerima.

Pregled agenta pod ljudskim nadzorom

Svaki označeni problem revidiraju istraživački agenti zasnovani na Codexu, kojima je omogućen pristup repozitoriju i okruženju zadatka. To im pomaže da razlikuju razumnu dvosmislenost zadatka, koja se često može riješiti proučavanjem obližnjeg koda i konvencija repozitorija, od stvarne nedovoljne specificiranosti. Agent može pokretati testove, pregledati datoteke u repozitoriju i istraživati pokušaje modela te njihove uobičajene obrasce neuspjeha na zadatku. Nakon nekoliko nezavisnih ponavljanja ovih dubljih revizija, istraživač je pregledao sažetke, donio konačnu prosudbu i označio vjerovatne probleme.

Kampanja ljudskog anotiranja

Paralelno smo proveli kampanju ljudskog anotiranja na označenom podskupu. Radili smo s iskusnim softverskim inženjerima koji su prije pregleda zadataka obučeni o ciljevima referentnog testa, taksonomiji problema i rubnim slučajevima. Svaki zadatak pregledalo je pet inženjera.

Recenzenti su formirali nezavisnu prosudbu na osnovu vidljivog opisa problema, testnih slučajeva i referentnog rješenja koje predstavlja stvarnu istinu (poznatog kao zlatna zakrpa), prije nego što su analizu toka ili transkript koristili kao dodatni kontekst. Recenzenti su zatim dodijelili oznaku i ocjenu ozbiljnosti na osnovu konkretnih dokaza, a neslaganja ili slučajeve niske sigurnosti eskalirali su na dodatni pregled.

Ljudski recenzenti su češće od istraživačkih agenata označavali zadatke kao neispravne. Između dva puta pregleda postojala su i određena neslaganja oko kategorija, ali ni za jedan označeni zadatak „nije neispravan” nije bila najčešća ljudska oznaka. Od kategorija koje je označio tok s agentima, prosudbe recenzenata preklapale su se u 74% slučajeva.

U poređenju s tokom s agentima, ljudski recenzenti su također češće birali više oznaka za jedan zadatak, što ukazuje da su smatrali da su zadaci neispravni na više načina ili da se ne uklapaju jasno u jednu kategoriju. To sugerira da je tok s agentima i recenzentima doveo do konzervativnog označavanja: obuhvatio je iste široke obrasce neuspjeha koje su identificirali ljudi, ali je podbrojao slučajeve u kojima su recenzenti vidjeli dodatne ili preklapajuće probleme. Najveća razlika bila je kod testova s malom pokrivenošću, koje su ljudi odabrali kao najčešći problem za 9,4% referentnog testa, u poređenju s 4,1% iz toka s agentima.

Obrasci neuspjeha

U nekoliko slučajeva upit zadatka propisivao je određenu implementaciju, ali su skriveni testni slučajevi očekivali drugač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":

Nijedno

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":

Nijedno

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.

Diskusija

Problemi koje smo identificirali, zajedno sa sličnim slučajevima u SWE-bench Verified, naglašavaju važnost rigorozne provjere referentnih testova. Problemi i pull requestovi iz repozitorija otvorenog koda izvorno su nastali za ljudsku saradnju, često kroz duge razmjene između održavatelja i doprinositelja. Zbog toga se opisi problema, spojeni kod i jedinični testovi ne poklapaju uvijek tako da formiraju čiste, izolirane zadatke za pouzdanu evaluaciju modela. Testovi uključeni u pull requestove posebno mogu biti previše strogi jer su napisani da potvrde konkretnu promjenu, a ne da definiraju standard za rješavanje zadatka neovisan o implementaciji.

Istovremeno, nedostatke evaluacije danas je lakše otkriti nego što bi to bilo čak i donedavno. Kako se sposobnosti modela poboljšavaju, te modele možemo koristiti za pregled upita, testova, zakrpa, tragova i rubnih slučajeva s mnogo većom dubinom i dosljednošću, što pomaže otkriti probleme referentnih testova koje je ranije bilo skupo ili nepraktično pronalaziti u velikom obimu.

Nadamo se da će šira zajednica za evaluaciju razviti nove referentne testove koje će iskusni softverski developeri izraditi posebno za testiranje sposobnosti modela. Takav pristup može sačuvati visok standard i realizam koje želimo koristiti za mjerenje sposobnosti modela, a omogućava i bolji ljudski nadzor tokom cijelog procesa. S obzirom na probleme otkrivene u ovoj analizi, povlačimo našu raniju preporuku za usvajanje SWE-Bench Pro-a.

Na kraju, evaluacija treba pružiti smislen signal kroz referentne testove kojima je teško manipulisati, kojima se lako može vjerovati i koji istinski odražavaju sposobnost ili usklađenost modela. Budući da ovi rezultati utiču na OpenAI-jeve odluke o implementaciji i sigurnosti, evaluacije koje pratimo moraju biti valjane i informativne.