8 Juli 2026

Misahake sinyal saka gangguan ing evaluasi coding

Liwat audit rinci, kita nemokake masalah tugas sing nyebar ing SWE-Bench Pro lan ngira ~30% tugas kasebut rusak.

Lagi dimuat…

Ngukur kapabilitas model kita kanthi akurat iku penting kanggo keputusan penerapan lan keamanan sing sehat, kalebu keputusan miturut Kerangka Kesiapan⁠(mbukak ing jendhela anyar) OpenAI. Saben rilis model, kita nglaporake asil saka macem-macem benchmark eksternal lan internal kanggo nglacak kemajuan model. Nalika evaluasi nduweni cacat sing mengaruhi asil, evaluasi kasebut bisa menehi pemahaman palsu babagan kapabilitas, nyalahgambarke alasan keamanan lan mengaruhi prioritas riset.

Kita mentas wae iki nyelidiki kepiye salah siji benchmark coding sing paling akeh digunakake, SWE-bench Verified, nduweni masalah desain dhasar lan kontaminasi, lan nemokake yen eval kasebut wis ora menehi sinyal sing migunani babagan kapabilitas pangembangan piranti lunak. Nalika iku, kita ngajak komunitas luwih amba kanggo pindhah menyang SWE-Bench Pro.

SWE-Bench Pro⁠(mbukak ing jendhela anyar) dirancang kanggo ningkatake SWE-bench Verified kanthi nguji model ing horizon sing luwih dawa lan tugas coding sing luwih realistis supaya luwih apik nglacak kapabilitas coding agenik. Kaya ing SWE-bench Verified, tugas dijupuk kanthi programatis saka riwayat owah-owahan fitur ing sakumpulan gudang kode publik lan privat. Model diwajibake ngetrapake solusi sing lulus tes anyar kanggo fitur, tanpa ngrusak fungsi sing wis ana. Ing split publik 731 tugas, model tercanggih mundhak saka tingkat lulus 23,3% dadi 80,3% sajrone wolung wulan.

Wiwit kuwi, kita nindakake audit sing padha ing SWE-Bench Pro, kanthi mriksa dataset nganggo pipeline analisis datapoint. Pipeline kasebut mriksa upaya model ing tugas, metadata tugas, lan jejak kegagalan kanggo nandhani cacat evaluasi sing kamungkinan ana. Saben tugas sing ditandhani banjur dibiji liwat pirang-pirang pass investigator-agen lan ditinjau mandiri dening limang insinyur piranti lunak berpengalaman, kanthi beda pendapat dieskalasi kanggo penyelidikan luwih lanjut.

Kita nemokake bukti ana masalah kerusakan ing bagean dataset sing cukup gedhe. Pipeline analisis datapoint kita nandhani 200 (27,4%) tugas rusak, dene kampanye anotasi manungsa nemokake 249 (34,1%).

Masalah kasebut utamane mlebu ing papat kategori:

Tes sing ketat kebangetan¹ meksa rincian implementasi tartamtu sing ora ditemtokake ing prompt, saéngga akeh kiriman sing fungsine bener dadi ora sah.
Prompt kurang rinci² ngilangi syarat sing dipaksa dening tes sing didhelikake lan ora bisa disimpulake kanthi wajar.
Tes cakupan rendah kurang mriksa fitur sing dijaluk, mula perbaikan sing durung lengkap bisa lulus.
Prompt nyasarke ngarahake model menyang prilaku sing salah utawa bertentangan karo sing dijaluk tes.

Temuan kita nuduhake angelé nyusun benchmark sing angel nanging adil, lan saya migunané agen kanggo pamriksan mutu data sing bisa diskalakake. Adhedhasar asil iki, kita ngira ~30% tugas SWE-bench Pro rusak, lan menehi saran supaya pangembang model nliti asil kanthi ati-ati.

Metodologi

Tujuan kita yaiku mesthekake yen kegagalan tugas nggambarake watesan model sing nyata, lan keberhasilan tugas nggambarake solusi lengkap lan sah tumrap syarat prompt. Kanggo mriksa mutu data sing digunakake ing evaluasi, kita nggawe pipeline jaminan mutu kanggo mbiji apa saben datapoint kanthi akurat nggambarake kapabilitas model.

Alur kerja jaminan mutu sing nggabungake panyaringan otomatis lan tinjauan manungsa kanggo mbiji mutu tugas. — Pipeline mutu data wiwitan nandhani masalah kanggo ditinjau. Kita ngesahake nganggo audit luwih jero sing dibantu agen tumrap tugas sing ditandhani, lan kampanye anotasi manungsa bareng insinyur berpengalaman.

Filter otomatis awal mriksa instruksi sing diwenehake marang model, upaya model kanggo ngrampungake tugas, lan tes sing digunakake kanggo menehi biji marang upaya kasebut, supaya bisa nandhani conto sing kamungkinan rusak utawa bermasalah. Filter iki nandhani 286 tugas sing bisa uga rusak. Banjur kita nindakake tinjauan luwih jero marang subset kasebut nganggo rong cara: tinjauan agen sing diawasi manungsa, sing nindakake pamriksan ekstensif nganggo agen penyelidik lan putusan akhir manungsa; lan kampanye anotasi manungsa bareng pangembang piranti lunak berpengalaman.

Tinjauan agen sing diawasi manungsa

Saben masalah sing ditandhani diaudit nganggo agen penyelidik berbasis Codex sing diwenehi akses menyang gudang kode lan lingkungan tugas. Iki mbantu mbedakake ambiguitas tugas sing wajar, sing kerep bisa dirampungake kanthi nyinaoni kode cedhak lan konvensi gudang kode, saka kekurangan rincian sing sejati. Agen bisa mbukak tes, mriksa berkas ing repo, lan nyelidiki upaya model uga mode kegagalan sing umum ing tugas kasebut. Sawise pirang-pirang pengulangan mandiri saka audit luwih jero iki, peneliti mriksa ringkesan, nggawe putusan akhir, lan menehi label marang masalah sing kamungkinan ana.

Kampanye anotasi manungsa

Bebarengan karo iku, kita nindakake kampanye anotasi manungsa ing subset sing ditandhani. Kita kerja bareng insinyur piranti lunak berpengalaman sing wis dilatih babagan tujuan benchmark, taksonomi masalah, lan kasus pinggir sadurunge mriksa tugas. Saben tugas ditinjau dening limang insinyur.

Para paninjau nggawe putusan mandiri saka pernyataan masalah sing katon, kasus tes, lan solusi rujukan ground-truth (dikenal minangka gold patch) sadurunge nggunakake analisis pipeline utawa transkrip minangka konteks pendukung. Banjur para paninjau menehi label lan rating keparahan adhedhasar bukti konkrit, lan nge-eskalasi beda pendapat utawa kasus sing kapercayane rendah kanggo ditinjau luwih lanjut.

Paninjau manungsa luwih cenderung tinimbang agen penyelidik kanggo nandhani tugas minangka rusak. Ana uga sawetara beda pendapat babagan kategori antarane rong jalur tinjauan kasebut, nanging ing tugas sing ditandhani ora ana sing label manungsa paling umumé yaiku “ora rusak”. Saka kategori sing ditandhani pipeline agen, putusan paninjau tumpang tindih ing 74% kasus.

Dibandhingake karo pipeline agen, paninjau manungsa uga luwih cenderung milih pirang-pirang label kanggo siji tugas, nuduhake yen dheweke nemokake tugas rusak kanthi pirang-pirang cara utawa ora pas kanthi rapi ing siji kategori. Iki nuduhake pipeline agen-plus-paninjau ngasilake pelabelan sing konservatif: pipeline kasebut nyekel mode kegagalan umum sing padha karo sing diidentifikasi manungsa, nanging ngitung luwih sithik kasus nalika paninjau weruh masalah tambahan utawa tumpang tindih. Bedane paling gedhe ana ing tes cakupan rendah, sing dipilih manungsa minangka masalah paling umum kanggo 9,4% benchmark, dibandhingake 4,1% saka pipeline agen.

Mode kegagalan

Ing sawetara kasus, prompt tugas nemtokake implementasi tartamtu, nanging kasus tes sing didhelikake ngarepake prilaku sing beda.

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

Ora ana

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

Ora ana

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.

Diskusi

Masalah sing wis kita identifikasi, digandhengake karo kasus sing padha ing SWE-bench Verified, nyorot pentinge mriksa benchmark kanthi ketat. Masalah lan pull request saka gudang kode open-source wiwitane digawe kanggo kolaborasi manungsa, asring liwat rembugan bolak-balik dawa antarane maintainer lan kontributor. Akibate, deskripsi masalah, kode sing digabung, lan unit test ora mesthi selaras kanggo mbentuk tugas sing resik lan terisolasi kanggo ngevaluasi model kanthi andal. Mligine, tes sing kalebu ing pull request bisa ketat kebangetan amarga ditulis kanggo ngesahake owah-owahan tartamtu, dudu kanggo netepake standar sing ora gumantung implementasi kanggo ngrampungake tugas.

Ing wektu sing padha, cacat evaluasi saiki luwih gampang dideteksi tinimbang sanajan mung sawetara wektu kepungkur. Nalika kapabilitas model saya apik, kita bisa nggunakake model kasebut kanggo mriksa prompt, tes, patch, jejak, lan kasus pinggir kanthi luwih jero lan konsisten, mbantu ngangkat masalah benchmark sing biyen larang utawa ora praktis ditemokake ing skala gedhe.

Kita ngarepake komunitas evaluasi sing luwih amba bakal ngembangake benchmark anyar sing dibangun dening pangembang piranti lunak berpengalaman khusus kanggo nguji kapabilitas model. Pendekatan kasebut bisa njaga standar dhuwur lan realisme sing arep kita ukur ing kapabilitas model, lan ngidini pengawasan manungsa sing luwih apik sajrone proses. Amarga masalah sing kabuka ing analisis iki, kita mbatalake rekomendasi sadurunge kanggo nganggo SWE-Bench Pro.

Pungkasane, eval kudu menehi sinyal sing migunani liwat benchmark sing angel dimanipulasi, gampang dipercaya, lan bener-bener nggambarake kapabilitas utawa alignment model. Amarga asil iki dadi dhasar keputusan penerapan lan keamanan OpenAI, eval sing kita lacak kudu sah lan informatif.