Paghihiwalay ng signal sa ingay sa coding evaluations

Mahalaga ang tumpak na pagsukat sa mga kakayahan ng aming mga modelo para sa matibay na deployment at mga desisyong pangkaligtasan, kabilang ang mga desisyon sa ilalim ng Preparedness Framework⁠(magbubukas sa bagong window) ng OpenAI. Sa bawat release ng modelo, nag-uulat kami ng mga resulta para sa iba’t ibang external at internal benchmark upang subaybayan ang pag-usad ng modelo. Kapag may depektong nakakaapekto sa mga resulta ang mga evaluation, maaari itong magbigay ng maling pagkaunawa sa mga kakayahan, magpakita nang mali ng mga safety case, at makaapekto sa mga priyoridad sa research.

Kamakailan naming inimbestigahan kung paanong ang isa sa mga pinakaginagamit na coding benchmark, ang SWE-bench Verified, ay may mga pangunahing isyu sa disenyo at contamination, at nalaman naming hindi na nagbibigay ang eval ng makabuluhang signal tungkol sa mga kakayahan sa software development. Noong panahong iyon, hinikayat namin ang mas malawak na komunidad na lumipat sa SWE-Bench Pro.

Idinisenyo ang SWE-Bench Pro⁠(magbubukas sa bagong window) upang pahusayin ang SWE-bench Verified sa pamamagitan ng pagsubok sa mga modelo sa mas mahahabang horizon at mas makatotohanang coding task para mas mahusay na masubaybayan ang mga kakayahan sa agentic coding. Tulad sa SWE-bench Verified, programmatically kinukuha ang mga task mula sa kasaysayan ng mga pagbabago sa feature sa isang hanay ng mga pampubliko at pribadong repository. Kailangang magpatupad ang mga modelo ng solusyong pumapasa sa mga bagong test para sa isang feature, nang hindi sinisira ang kasalukuyang functionality. Sa 731-task na public split, tumaas ang pass rate ng mga frontier modelo mula 23.3% hanggang 80.3% sa loob ng walong buwan.

Mula noon, nagsagawa kami ng katulad na audit sa SWE-Bench Pro, na nirepaso ang dataset gamit ang datapoint analysis pipeline. Nirepaso ng pipeline ang mga pagtatangka ng modelo sa task, metadata ng task, at failure traces upang i-flag ang malamang na mga depekto sa evaluation. Pagkatapos, tinasa ang bawat na-flag na task sa pamamagitan ng maraming investigator-agent pass at hiwalay na nirepaso ng limang bihasang software engineer, at inakyat para sa karagdagang imbestigasyon ang mga hindi pagkakasundo.

Pangunahin nang napangkat ang mga isyu sa apat na kategorya:

• Ipinapatupad ng masyadong mahigpit na tests¹ ang mga partikular na detalye ng implementasyon na hindi tinukoy sa prompt, kaya nawawalan ng bisa ang maraming submission na tama ang functionality.
• Inaalis ng mga hindi sapat na prompt² ang mga requirement na ipinapatupad ng mga nakatagong test at hindi makatuwirang mahihinuha.
• Hindi sapat na nasusuri ng low-coverage tests ang hinihinging feature, kaya maaaring pumasa ang hindi kumpletong fix.
• Itinutulak ng nakakalinlang na prompt ang mga modelo sa maling gawi o sumasalungat ito sa hinihingi ng mga test.

Ipinapakita ng aming mga natuklasan ang hirap ng pag-curate ng mahihirap ngunit patas na benchmark at ang lumalaking pakinabang ng mga agent para sa scalable na pagsusuri sa kalidad ng data. Batay sa mga resultang ito, tinataya naming ~30% ng mga task sa SWE-bench Pro ay sira, at ipinapayo namin sa mga developer ng modelo na maingat na suriin ang mga resulta.

Layunin naming tiyaking ang mga pagkabigo sa task ay sumasalamin sa tunay na limitasyon ng modelo, at ang mga tagumpay sa task ay sumasalamin sa kumpleto at wastong solusyon sa mga requirement ng prompt. Upang suriin ang kalidad ng data na ginamit sa evaluation, gumawa kami ng quality assurance pipeline para tasahin kung tumpak na sinasalamin ng bawat datapoint ang mga kakayahan ng modelo.

Nirerepaso ng paunang awtomatikong filter ang mga tagubiling ibinigay sa modelo, ang mga pagtatangka ng modelo na lutasin ang task, at ang mga test na ginamit upang markahan ang mga pagtatangkang ito, para i-flag ang malamang na sira o problematikong halimbawa. Nag-flag ang filter na ito ng 286 na potensyal na sirang task. Pagkatapos ay nagsagawa kami ng mas malalim na review sa subset na iyon sa dalawang paraan: pagsusuri ng agent na pinangangasiwaan ng tao, na nagsasagawa ng malawakang pagsusuri gamit ang mga investigator agent at panghuling paghatol ng tao; at human annotation campaign kasama ang mga bihasang software developer.

Ino-audit ang bawat na-flag na problema gamit ang mga Codex-based investigator agent na binigyan ng access sa task repository at environment. Tinutulungan silang makilala ang makatwirang kalabuan ng task, na kadalasang nalulutas sa pag-aaral ng kalapit na code at mga convention ng repository, mula sa tunay na underspecification. Maaaring magpatakbo ng tests ang agent, magsiyasat ng mga file sa repo, at imbestigahan ang mga pagtatangka ng modelo at ang karaniwan nitong failure mode sa task. Pagkatapos ng ilang independent na pag-uulit ng mas malalalim na audit na ito, nirepaso ng isang researcher ang mga buod, gumawa ng panghuling paghatol, at nilagyan ng label ang malamang na mga isyu.

Kasabay nito, nagpatakbo kami ng human annotation campaign sa na-flag na subset. Nakipagtulungan kami sa mga bihasang software engineer na sinanay muna sa mga layunin ng benchmark, taxonomy ng isyu, at edge case bago nagrepaso ng mga task. Nirepaso ng limang engineer ang bawat task.

Bumuo muna ang mga reviewer ng independent na paghatol mula sa nakikitang problem statement, mga test case, at ground-truth reference solution (kilala bilang gold patch) bago gamitin ang pipeline analysis o transcript bilang suportang konteksto. Pagkatapos ay nagtalaga ang mga reviewer ng label at severity rating batay sa konkretong ebidensya, at inakyat para sa karagdagang review ang mga hindi pagkakasundo o kasong mababa ang kumpiyansa.

Mas malamang na markahan ng mga human reviewer ang mga task bilang sira kaysa ng mga investigator agent. Nagkaroon din ng ilang hindi pagkakasundo sa mga kategorya sa pagitan ng dalawang review path, ngunit walang na-flag na task kung saan “hindi sira” ang pinakakaraniwang label ng tao. Sa mga kategoryang na-flag ng agent pipeline, nagtugma ang mga paghatol ng reviewer sa 74% ng mga kaso.

Kung ikukumpara sa agent pipeline, mas malamang ding pumili ang mga human reviewer ng maraming label para sa isang task, na nagpapahiwatig na nakita nilang sira ang mga task sa maraming paraan o hindi malinis na kasya sa iisang kategorya. Ipinapahiwatig nito na nagbunga ng konserbatibong paglalabel ang agent-plus-reviewer pipeline: nakuha nito ang parehong malawak na failure mode na tinukoy ng mga tao, habang kulang ang bilang sa mga kasong nakakita ang mga reviewer ng karagdagang o magkakapatong na isyu. Pinakamalaki ang pagkakaiba sa low-coverage tests, na pinili ng mga tao bilang pinakakaraniwang isyu para sa 9.4% ng benchmark kumpara sa 4.1% mula sa agent pipeline.

Itinatampok ng mga isyung natukoy namin, kasama ng mga katulad na kaso sa SWE-bench Verified, ang kahalagahan ng masusing pagsusuri sa mga benchmark. Orihinal na ginawa ang mga issue at pull request mula sa mga open-source repository para sa kolaborasyon ng tao, madalas sa pamamagitan ng mahahabang palitan sa pagitan ng mga maintainer at contributor. Dahil dito, hindi palaging nagtutugma ang mga paglalarawan ng problema, na-merge na code, at unit test upang makabuo ng malinis at hiwalay na task para mapagkakatiwalaang suriin ang mga modelo. Sa partikular, maaaring maging masyadong mahigpit ang mga test na kasama sa pull request dahil isinulat ang mga ito upang i-validate ang partikular na pagbabago, sa halip na magtakda ng implementation-agnostic na pamantayan sa paglutas ng task.

Kasabay nito, mas madali nang matukoy ngayon ang mga depekto sa evaluation kaysa kahit noong kamakailan lang. Habang umuunlad ang mga kakayahan ng modelo, magagamit natin ang mga modelong iyon upang siyasatin ang mga prompt, test, patch, trace, at edge case nang mas malalim at mas pare-pareho, na tumutulong ilantad ang mga isyu sa benchmark na dati’y magastos o hindi praktikal hanapin sa malaking sukat.

Umaasa kaming bubuo ang mas malawak na evaluation community ng mga bagong benchmark na ginawa ng mga bihasang software developer partikular para subukin ang mga kakayahan ng modelo. Mapananatili ng ganitong lapit ang mataas na pamantayan at realismong gusto naming sukatin sa mga kakayahan ng modelo, at nagbibigay-daan ito sa mas mahusay na human oversight sa buong proseso. Dahil sa mga isyung natuklasan sa pagsusuring ito, binabawi namin ang nauna naming rekomendasyong gamitin ang SWE-Bench Pro.

Sa huli, dapat magbigay ang isang eval ng makabuluhang signal sa pamamagitan ng mga benchmark na mahirap dayain, madaling pagkatiwalaan, at tunay na sumasalamin sa kakayahan o alignment ng modelo. Dahil ipinapaalam ng mga resultang ito ang mga desisyon ng OpenAI sa deployment at kaligtasan, kailangang valid at kapaki-pakinabang ang mga eval na sinusubaybayan namin.