Memisahkan sinyal dari derau dalam evaluasi pengodean

Mengukur kemampuan model kami secara akurat penting untuk keputusan deployment dan keselamatan yang baik, termasuk keputusan berdasarkan Kerangka Kerja Kesiapan⁠(terbuka di jendela baru) OpenAI. Pada setiap rilis model, kami melaporkan hasil dari berbagai benchmark eksternal dan internal untuk melacak kemajuan model. Ketika evaluasi memiliki kelemahan yang memengaruhi hasil, evaluasi tersebut dapat memberi pemahaman keliru tentang kemampuan, menyajikan kasus keselamatan secara tidak tepat, dan memengaruhi prioritas riset.

Kami baru-baru ini menyelidiki bagaimana salah satu benchmark pengodean yang paling banyak digunakan, SWE-bench Verified, memiliki masalah mendasar pada desain dan kontaminasi, dan menemukan bahwa eval tersebut tidak lagi memberi sinyal bermakna tentang kemampuan pengembangan perangkat lunak. Saat itu, kami mendorong komunitas luas untuk beralih ke SWE-Bench Pro.

SWE-Bench Pro⁠(terbuka di jendela baru) dirancang untuk memperbaiki SWE-bench Verified dengan menguji model pada horizon yang lebih panjang dan tugas pengodean yang lebih realistis, agar kemampuan pengodean agentik dapat dilacak dengan lebih baik. Seperti pada SWE-bench Verified, tugas diambil secara programatis dari riwayat perubahan fitur di sejumlah repositori publik dan privat. Model diminta mengimplementasikan solusi yang lulus tes baru untuk suatu fitur tanpa merusak fungsionalitas yang sudah ada. Pada split publik berisi 731 tugas, model terdepan meningkat dari tingkat kelulusan 23,3% menjadi 80,3% dalam delapan bulan.

Sejak itu, kami melakukan audit serupa pada SWE-Bench Pro, dengan meninjau dataset menggunakan pipeline analisis titik data. Pipeline tersebut meninjau upaya model pada tugas, metadata tugas, dan trace kegagalan untuk menandai kemungkinan cacat evaluasi. Setiap tugas yang ditandai kemudian dinilai melalui beberapa lintasan investigator-agen dan ditinjau secara independen oleh lima engineer perangkat lunak berpengalaman; ketidaksepakatan dieskalasi untuk penyelidikan lanjutan.

Masalah tersebut terutama terbagi ke dalam empat kategori:

• Tes terlalu ketat¹ memaksakan detail implementasi tertentu yang tidak disebutkan dalam prompt, sehingga banyak pengajuan yang benar secara fungsional menjadi tidak valid.
• Prompt kurang spesifik² menghilangkan persyaratan yang ditegakkan oleh tes tersembunyi dan tidak dapat disimpulkan secara wajar.
• Tes bercakupan rendah kurang memeriksa fitur yang diminta, sehingga perbaikan yang tidak lengkap dapat lolos.
• Prompt menyesatkan mengarahkan model ke perilaku yang salah atau bertentangan dengan yang diwajibkan tes.

Temuan kami menunjukkan sulitnya menyusun benchmark yang sulit tetapi adil, serta makin bergunanya agen untuk pemeriksaan kualitas data yang dapat diskalakan. Berdasarkan hasil ini, kami memperkirakan bahwa ~30% tugas SWE-bench Pro bermasalah, dan menyarankan pengembang model menelaah hasilnya dengan cermat.

Tujuan kami adalah memastikan kegagalan tugas mencerminkan keterbatasan model yang nyata, dan keberhasilan tugas mencerminkan solusi yang lengkap dan valid terhadap persyaratan prompt. Untuk memeriksa kualitas data yang digunakan dalam evaluasi, kami membuat pipeline penjaminan mutu guna menilai apakah tiap titik data secara akurat mencerminkan kemampuan model.

Filter otomatis awal meninjau instruksi yang diberikan kepada model, upaya model menyelesaikan tugas, dan tes yang digunakan untuk menilai upaya tersebut, guna menandai contoh yang kemungkinan rusak atau bermasalah. Filter ini menandai 286 tugas yang berpotensi bermasalah. Kami lalu melakukan tinjauan lebih mendalam atas subset tersebut dengan dua cara: tinjauan agen yang diawasi manusia, yang menjalankan pemeriksaan ekstensif dengan agen investigator dan penilaian akhir manusia; serta kampanye anotasi manusia bersama pengembang perangkat lunak berpengalaman.

Setiap masalah yang ditandai diaudit dengan agen investigator berbasis Codex yang diberi akses ke repositori dan lingkungan tugas. Ini membantu mereka membedakan ambiguitas tugas yang wajar, yang sering dapat diselesaikan dengan mempelajari kode sekitar dan konvensi repositori, dari kekurangspesifikan yang sebenarnya. Agen dapat menjalankan tes, memeriksa file dalam repo, serta menyelidiki upaya model dan mode kegagalan umumnya pada tugas tersebut. Setelah beberapa pengulangan independen atas audit mendalam ini, seorang peneliti meninjau ringkasannya, membuat keputusan akhir, dan memberi label pada masalah yang mungkin ada.

Secara paralel, kami menjalankan kampanye anotasi manusia pada subset yang ditandai. Kami bekerja dengan engineer perangkat lunak berpengalaman yang dilatih tentang tujuan benchmark, taksonomi masalah, dan kasus tepi sebelum meninjau tugas. Setiap tugas ditinjau oleh lima engineer.

Peninjau membentuk penilaian independen dari pernyataan masalah yang terlihat, kasus uji, dan solusi referensi ground-truth (dikenal sebagai gold patch) sebelum menggunakan analisis pipeline atau transkrip sebagai konteks pendukung. Peninjau kemudian menetapkan label dan tingkat keparahan berdasarkan bukti konkret, serta mengeskalasi ketidaksepakatan atau kasus dengan keyakinan rendah untuk ditinjau lebih lanjut.

Peninjau manusia lebih mungkin daripada agen investigator untuk menandai tugas sebagai bermasalah. Ada juga sejumlah ketidaksepakatan kategori antara kedua jalur tinjauan, tetapi pada tugas mana pun yang ditandai, “tidak bermasalah” bukanlah label manusia yang paling umum. Dari kategori yang ditandai pipeline agen, penilaian peninjau tumpang tindih dalam 74% kasus.

Dibandingkan pipeline agen, peninjau manusia juga lebih mungkin memilih beberapa label untuk satu tugas, yang menunjukkan bahwa mereka menemukan tugas bermasalah dalam beberapa cara atau tidak pas dimasukkan ke satu kategori saja. Ini menunjukkan pipeline agen-plus-peninjau menghasilkan pelabelan konservatif: pipeline tersebut menangkap mode kegagalan luas yang sama dengan yang diidentifikasi manusia, sambil kurang menghitung kasus ketika peninjau melihat masalah tambahan atau tumpang tindih. Perbedaan terbesar ada pada tes bercakupan rendah, yang dipilih manusia sebagai masalah paling umum untuk 9,4% benchmark, dibandingkan 4,1% dari pipeline agen.

Masalah yang kami identifikasi, bersama kasus serupa di SWE-bench Verified, menyoroti pentingnya memeriksa benchmark secara ketat. Issue dan pull request dari repositori sumber terbuka awalnya dibuat untuk kolaborasi manusia, sering kali melalui diskusi panjang antara maintainer dan kontributor. Akibatnya, deskripsi masalah, kode yang digabungkan, dan unit test tidak selalu selaras membentuk tugas yang bersih dan terisolasi untuk mengevaluasi model secara andal. Secara khusus, tes yang disertakan dalam pull request bisa terlalu ketat karena ditulis untuk memvalidasi perubahan tertentu, bukan untuk mendefinisikan standar yang agnostik terhadap implementasi dalam menyelesaikan tugas.

Pada saat yang sama, cacat evaluasi kini lebih mudah dideteksi dibandingkan bahkan beberapa waktu lalu. Seiring meningkatnya kemampuan model, kita dapat menggunakan model tersebut untuk memeriksa prompt, tes, patch, trace, dan kasus tepi dengan kedalaman serta konsistensi yang jauh lebih besar, membantu memunculkan masalah benchmark yang sebelumnya mahal atau tidak praktis ditemukan dalam skala besar.

Kami berharap komunitas evaluasi yang lebih luas akan mengembangkan benchmark baru yang dibangun oleh pengembang perangkat lunak berpengalaman khusus untuk menguji kemampuan model. Pendekatan itu dapat mempertahankan standar tinggi dan realisme yang ingin kita ukur pada kemampuan model, sekaligus memungkinkan pengawasan manusia yang lebih baik di sepanjang proses. Mengingat masalah yang terungkap dalam analisis ini, kami mencabut rekomendasi sebelumnya untuk mengadopsi SWE-Bench Pro.

Pada akhirnya, sebuah eval harus memberi sinyal bermakna melalui benchmark yang sulit dimanipulasi, mudah dipercaya, dan benar-benar mencerminkan kemampuan atau alignment model. Karena hasil ini menjadi dasar keputusan deployment dan keselamatan OpenAI, eval yang kami lacak harus valid dan informatif.