- SWE-bench Verified, yang sebelumnya merupakan metrik representatif untuk tugas rekayasa perangkat lunak otonom, kini jauh kurang cocok untuk mengukur kemampuan model frontier
- Di tengah peningkatan performa terbaik yang belakangan terbatas dari 74,9% ke 80,9%, semakin sulit membedakan apakah kegagalan yang tersisa berasal dari keterbatasan model atau cacat dataset
- Dari 138 masalah yang diaudit, ditemukan cacat serius pada desain pengujian atau deskripsi masalah di 59,4% kasus, dan pengujian yang terlalu membatasi maupun terlalu luas dapat menggagalkan solusi yang secara fungsional benar
- Karena evaluasi dilakukan berdasarkan data publik dan codebase terbuka, kontaminasi data pelatihan sulit dihindari, dan beberapa model hampir mereproduksi gold patch hanya dari deskripsi tugas atau ID
- Karena itu, pelaporan skor SWE-bench Verified dihentikan, dan fokus evaluasi bergeser ke SWE-bench Pro yang dampak kontaminasinya lebih kecil serta ke benchmark nonpublik
Mengapa benchmark ini tidak lagi mengukur dengan baik
- SWE-bench Verified telah lama digunakan secara luas sebagai metrik standar untuk mengukur performa model pada tugas rekayasa perangkat lunak otonom, tetapi pada tingkat kemampuan model frontier saat ini, kecocokannya menurun drastis
- Ketika peningkatan performa terbaik dalam 6 bulan terakhir terbatas dari 74.9% ke 80.9%, semakin sulit membedakan apakah kegagalan yang tersisa berasal dari batas model atau dari cacat dataset
- Analisis baru menunjukkan bahwa pengujian yang cacat dan kontaminasi data pelatihan adalah masalah utama, sehingga skor lebih banyak mencerminkan tingkat paparan terhadap benchmark daripada kemampuan coding yang sebenarnya
- Karena itu, OpenAI menghentikan pelaporan skor SWE-bench Verified dan merekomendasikan langkah yang sama kepada pengembang model lain
- Sebagai alternatif, mereka merekomendasikan penggunaan SWE-bench Pro yang lebih sedikit terkontaminasi, sambil membangun metrik evaluasi baru yang bebas kontaminasi
Latar belakang
- SWE-bench asli dirilis pada 2023, dan disusun dengan memasangkan issue GitHub yang telah diselesaikan dengan PR terkait dari 12 repositori Python open-source
- Untuk setiap masalah, model harus menghasilkan perubahan kode hanya dengan diberi codebase sebelum perbaikan dan teks issue, dan kriteria kelulusannya adalah semua pengujian lolos setelah patch diterapkan
- Terdapat pengujian yang harus gagal sebelum perbaikan dan lolos setelah perbaikan yang benar
- Juga disertakan regression test untuk memastikan fungsionalitas yang sudah ada tidak rusak
- Evaluasi asli memiliki masalah seperti pengujian yang terlalu spesifik hingga menolak perbaikan yang benar, spesifikasi yang tidak cukup sehingga bisa ditafsirkan ganda, dan pengujian yang gagal tergantung perbedaan lingkungan
- Untuk mengurangi hal ini, SWE-bench Verified dibuat pada 2024, menyaring 1.699 masalah melalui peninjauan ahli menjadi set 500 masalah
- Setiap masalah ditinjau secara independen oleh 3 ahli
Cacat desain pengujian
- 138 masalah yang bahkan tidak dapat diselesaikan secara konsisten oleh OpenAI o3 dalam 64 eksekusi independen dijadikan objek audit, dan setiap kasus ditinjau secara independen oleh sedikitnya 6 insinyur perangkat lunak berpengalaman
- Hasilnya, dari 138 masalah tersebut, 59,4% memiliki cacat serius pada desain pengujian atau deskripsi masalah, sehingga sangat sulit atau mustahil diselesaikan bahkan oleh model unggul maupun manusia
- 35,5% dari tugas yang diaudit mencakup pengujian yang membatasi dan memaksa detail implementasi tertentu
- Akibatnya, berbagai solusi yang secara fungsional benar tetap bisa dianggap tidak valid
- 18,8% dari tugas yang diaudit mencakup pengujian yang terlalu luas hingga menuntut fitur tambahan yang tidak ada dalam deskripsi masalah
- 5,1% sisanya memiliki masalah lain yang tidak secara jelas masuk ke dua kategori di atas
-
Kasus pengujian yang membatasi
- Pada pylint-dev__pylint-4551, pengujian PR mengimpor langsung fungsi
get_annotation, tetapi nama fungsi ini tidak muncul dalam spesifikasi masalah
- Karena itu, meskipun masalah diselesaikan dengan benar secara fungsional, pengujian tetap bisa gagal karena error import jika nama fungsi tertentu itu tidak diimplementasikan
-
Kasus pengujian yang terlalu luas
- sympy__sympy-18199 sebenarnya diambil dari PR yang sekaligus memperbaiki tiga issue: #17373, #17377, dan #18212
- Namun, deskripsi tugas SWE-bench Verified hanya membahas #18212, sehingga implementasi yang mengikuti deskripsi tetap bisa gagal pada pengujian yang memeriksa dua issue lainnya
Masalah kontaminasi
- SWE-bench Verified, codebase repositori terkait, dan catatan rilisnya semuanya bersifat publik dan digunakan serta didiskusikan secara luas, sehingga sulit menghindari kontaminasi data
- OpenAI juga menemukan tanda-tanda kontaminasi pada model internalnya sendiri, termasuk kasus ketika GPT‑5.2 menyelesaikan 31 tugas yang mereka anggap hampir mustahil diselesaikan
- Pada django__django-14725, pengujian menuntut parameter
edit_only yang tidak ada dalam spesifikasi masalah, dan GPT‑5.2 dalam proses penalarannya bahkan dengan tepat menunjukkan bahwa parameter ini diperkenalkan di Django 4.1
- Untuk menilai tingkat keparahan kontaminasi, OpenAI membangun lingkungan pengujian red team otomatis
- Untuk setiap masalah SWE-bench Verified, GPT‑5 menyelidiki apakah GPT‑5.2‑Chat, Claude Opus 4.5, dan Gemini 3 Flash Preview terkontaminasi
- GPT‑5 diberi ID tugas, deskripsi, gold patch, dan pengujian PR, serta diizinkan mengubah prompt dan strategi elicitation selama total 15 putaran
- Setelah setiap putaran, model evaluator mengklasifikasikan tingkat keparahan kontaminasi dari tidak ada hingga kuat berdasarkan jumlah informasi spesifik-tugas baru yang terungkap
- Kasus dengan kontaminasi kuat diverifikasi lagi oleh model evaluator tambahan untuk menilai apakah kebocoran informasi berlebihan terjadi, lalu akhirnya ditinjau secara manual
Kasus kontaminasi serius per model
-
GPT‑5.2
- Pada django__django-11451, hanya dengan potongan deskripsi tugas yang singkat, model ini mengeluarkan gold patch yang tepat
- Model tersebut mereproduksi kondisi early return saat
ModelBackend.authenticate() menemui username is None or password is None, termasuk path file dan nama metodenya
-
Claude Opus 4.5
- Pada astropy__astropy-13236, model ini mengutip secara harfiah path file target
astropy/table/table.py, metode _convert_data_to_col, dan bahkan komentar inline dalam diff
- Empat baris kode yang secara otomatis mengubah structured ndarray menjadi
NdarrayMixin juga dipulihkan dengan tepat
-
Gemini 3 Flash
- Pada django__django-11099, bahkan dalam kondisi hampir tanpa informasi tambahan selain ID tugas, model ini mengeluarkan deskripsi tugas dan seluruh gold patch secara harfiah
- Model tersebut juga mereproduksi perubahan regex validasi username dari
r'^[\\w.@+-]+$' menjadi r'^[\\w.@+-]+\\Z', beserta diff per barisnya
Pelajaran utama
- Benchmark yang diambil dari materi yang tersedia secara publik membawa risiko kontaminasi, dan paparan data pelatihan dapat secara diam-diam menggelembungkan skor
- Jika benchmark dibuat dari data crawling publik, pengembang model perlu menjalankan pengujian tambahan untuk memeriksa ada tidaknya kontaminasi
- Karena benchmark dan jawaban yang dipublikasikan pada akhirnya juga bisa masuk ke data pelatihan, baik cara distribusi dataset maupun pemfilteran data pelatihan memerlukan perhatian khusus
- Disebutkan pendekatan kontrol distribusi seperti perlindungan kata sandi
- Juga disebutkan metode pemfilteran seperti kepatuhan ketat terhadap canary string
- Penilaian otomatis harus cukup tangguh agar tidak goyah oleh perbedaan implementasi yang tidak penting, namun tetap cukup kuat untuk mencegah cara-cara curang, dan memenuhi keduanya sekaligus sangat sulit
- Menemukan cacat-cacat ini memerlukan beberapa putaran pelabelan manual skala besar
Arah evaluasi ke depan
- Dalam beberapa bulan terakhir, OpenAI memutuskan untuk melaporkan hasil pada data evaluasi publik SWE-bench Pro, dan mendorong pengembang model lain mengambil langkah yang sama
- SWE-bench Pro juga tidak sempurna, tetapi secara empiris lebih sedikit terpengaruh kontaminasi dibanding SWE-bench Verified
- Beberapa kasus kontaminasi memang ditemukan dalam pipeline verifikasi kontaminasi internal
- Namun kasus tersebut jauh lebih jarang dan tidak separah pada SWE-bench Verified
- Tidak ada model yang mampu menghasilkan gold patch yang sepenuhnya identik secara harfiah
- Ke depan, mereka berencana terus berinvestasi pada benchmark yang orisinal dan ditulis secara nonpublik
- Di GDPVal, para ahli domain menulis tugas secara nonpublik, dan evaluator terlatih memberi nilai solusi secara menyeluruh
- Pendekatan seperti ini memang memakan banyak sumber daya, tetapi semakin menjadi elemen penting untuk mengukur peningkatan kemampuan yang nyata
1 komentar
Komentar Hacker News
Sebagai salah satu pembuat SWE-bench, singkatnya SWE-bench Verified sekarang sudah hampir jenuh di 93.9%, dan Anthropic memang layak diberi selamat
Meski begitu, tim-tim yang masih belum mencapai angka itu masih punya ruang untuk meningkatkannya
SWE-bench Multilingual dan SWE-bench Multimodal masih belum jenuh, dan Multimodal rencananya akan dirilis open source dalam sebulan ke depan
Benchmark pada akhirnya memang akan selalu jenuh, jadi benchmark tahap berikutnya juga terus dibuat, dan sudah ada hal-hal seperti https://codeclash.ai/ atau https://algotune.io/
Intinya adalah cukup banyak test yang tidak akurat, sehingga solusi yang sebenarnya benar pun dinilai salah
Selain itu, sangat mungkin model frontier sudah pernah membaca dan menghafal PR yang menjadi dasar masalah-masalah tersebut
Bahkan ada soal yang pada praktiknya nyaris mustahil diselesaikan dengan benar kecuali sudah menghafal solusinya, misalnya ketika test hanya lolos jika Anda mengekspos nama helper function tertentu yang sama sekali tidak disebut di soal
Fakta bahwa model frontier bisa lolos dari hal seperti ini tampaknya karena mereka mengingat bahwa nama itu memang diperlukan
Jika benchmark generasi berikutnya tidak memperbaiki hal ini, masalah yang sama akan tetap ada terlepas dari apakah benchmark itu jenuh atau tidak
Kalau dihitung, 0.191 * 0.594 > 1 - 0.936, jadi saya jadi penasaran apakah subset yang diaudit itu memang tidak representatif, atau Anthropic memperoleh skor tinggi dengan cara yang agak mencurigakan
Benchmark dibuat, lalu jenuh, dibuang, diganti, dan diulang lagi
Pada akhirnya treadmill ini sendiri terasa seperti pola yang berjalan layaknya produk, dan saya tidak tahu solusinya, tetapi rasanya seperti sejarah yang terulang
Sejauh yang saya pahami, ini terlihat seperti variasi menarik dari SWE-bench
Fakta bahwa sekarang ia diuji sekeras ini terlihat sebagai efek balik dari adopsi yang luas dan kesuksesannya
Kelihatannya terlalu jelas bahwa benchmark baru apa pun yang muncul akan segera masuk ke data pelatihan dan langsung usang
Insentif untuk mengoptimalkan model terhadap benchmark tertentu akan selalu ada, walau hanya untuk pemasaran, dan bahkan jika ada training cutoff pun biasanya selisihnya hanya sekitar 3–6 bulan dari waktu publikasi
Karena itu, tantangan sebenarnya dari benchmark coding adalah membuat masalah yang benar-benar baru, yang dijamin sama sekali tidak pernah ada di data pelatihan, tanpa meminjam benchmark yang sudah ada
Dari sudut pandang ini, benchmark yang dibuat sebelum perilisan model sulit dianggap mewakili performa model tersebut, dan insentif finansial untuk menyisipkan data demi mempromosikan peningkatan kecil terlalu besar
Sejujurnya, benchmark sebaiknya dihapus saja dari materi pemasaran, biarkan model bicara sendiri dan komunitas yang menilai, tetapi perusahaan yang mempertaruhkan uang tampaknya tidak akan pernah melakukan itu
Game petualangan teks Zork ada di data pelatihan LLM dan bersifat deterministik, jadi secara teori model seharusnya bisa memainkannya dan menamatkannya dengan mudah
Namun kenyataannya tidak begitu, dan itulah tujuan Zork bench
https://github.com/mnky9800n/zork-bench
Di sana bercampur semua orang, dari pakar yang sudah memakai LLM lebih dari 10 tahun sampai vibe coder yang belum pernah menulis kode, dan di internet ada yang menganggap GPT 5.5 sebagai penyelamat, ada juga yang menganggapnya lebih bodoh daripada 5.4
Saya juga tidak punya waktu untuk membuat benchmark privat sendiri setiap kali ada model baru, jadi pada akhirnya saya tetap bergantung pada benchmark private atau semi-private untuk mengukur sejauh mana peningkatannya, lalu berlangganan dan mencobanya sendiri
Setidaknya ini sedikit lebih bisa dipercaya daripada suasana yang dipancarkan pengguna acak atau bot di Reddit
Atau bisa juga menjalankan test secara berurutan terus-menerus dalam konteks yang sama, untuk melihat model mampu bertahan sampai titik mana sebelum mulai kehilangan konteks
Benchmark saat ini selalu berupa masalah greenfield, padahal yang kita butuhkan di dunia nyata adalah model yang bisa menangani konteks yang sudah busuk
Bottleneck saat ini bukan kemampuan itu sendiri, melainkan apa yang bisa dilihat model di lingkungan produksi
Struktur konteks, kualitas retrieval, tool use, dan kemampuan menggabungkan state lintas banyak giliran itu penting, sementara SWE-bench hampir tidak punya hal-hal itu
SWE-bench terlihat seperti kumpulan soal one-shot, tetapi pekerjaan coding frontier sudah bukan lagi berbentuk seperti itu
Bahkan kalau kita membuat benchmark sempurna tanpa kebocoran data sama sekali pun, kemungkinan besar ia tetap akan mengukur sumbu yang salah
Pada masalah terisolasi, model sudah mencapai level mahasiswa pascasarjana manusia, dan leverage-nya sekarang ada pada bagaimana model itu bekerja di dalam sistem yang lebih besar
Masalahnya, itu nyaris sudah masuk wilayah selera atau preferensi sehingga sangat sulit diukur secara objektif
Anthropic membayar influencer untuk mendorong Claude Code, dan tampaknya juga menjalankan sangat banyak bot, sehingga sulit mempercayai konsensus online
Bahkan jika semua orang bertindak dengan niat baik pun, perbedaan domain bisa membuat pengalaman yang dirasakan sangat berbeda
Misalnya AI bisa jauh lebih baik di frontend atau library yang umum dipakai
Pada akhirnya penilaian model tetap harus lewat pemakaian langsung, tetapi mengulang ini untuk setiap model baru sangat melelahkan dan itu pun belum tentu cukup komprehensif
Benchmark/eval pada dasarnya memang sulit, dan menjadi lebih sulit lagi ketika ada insentif sangat besar di skala industri untuk memainkannya
ELT-Bench adalah contoh terbaru; sekitar setahun lalu ia muncul sebagai benchmark serius pertama untuk workload data engineering
Namun beberapa hari lalu, dalam paper lanjutan yang melibatkan salah satu penulis aslinya, benchmark itu sendiri diaudit dan hasilnya menunjukkan bias karena masalah struktural
Papernya ada di sini: https://arxiv.org/abs/2603.29399
Sebenarnya ini juga bukan hal baru, industri sebelumnya sudah mengalami semua ini dalam skala lebih kecil
Ada juga tulisan tentang betapa miripnya situasi sekarang dengan benchmarketing war di dunia database
https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...
Masalah serupa juga terlihat di BrowseComp plus dan dataset deep research lainnya, dan ini bukan selalu karena frontier lab berniat curang, melainkan muncul secara alami karena mereka melatih model pada seluruh web
Dataset baru harus terus dibuat tanpa henti
Saat saya membuat classifier sendiri, saya pernah mengalami bahwa pada beberapa tugas model secara konsisten lebih baik daripada manusia, sampai precision itu sendiri tidak bisa lagi diukur
Lalu classifier itu sendiri menjadi benchmark state-of-the-art, dan selain dirinya sendiri tidak ada lagi pembanding
Jika hal seperti ini bisa terjadi bahkan pada tugas kompleks yang kurang logis dan kurang menuntut penalaran berkelanjutan dibanding coding, suatu saat benchmark terkoreksi yang independen dari objek yang diukur mungkin benar-benar bisa lenyap
Pada akhirnya saya rasa kita kurang lebih memang mendapatkan benchmark hasil ulah kita sendiri
Cukup banyak PR yang lolos SWE-bench tampaknya pada kenyataannya tidak akan bisa di-merge: https://news.ycombinator.com/item?id=47341645
Dan skor SWE-bench model-model teratas mungkin juga terdistorsi karena kebocoran git history: https://news.ycombinator.com/item?id=45214670
Malah saya sempat berpikir, bagaimana kalau benchmark disuruh dibuat langsung oleh model papan atas
Di luar bercanda, yang saya tunggu adalah ARC-AGI-3, dan saat mencoba mensimulasikannya sebagai manusia, rasanya memang sangat menekankan penalaran
Leaderboard-nya ada di sini: https://arcprize.org/leaderboard
Saat ini bahkan sebagian besar model papan atas pun belum bisa menembus 5%
Bahkan Claude Opus 4.6, model terbaik terverifikasi saat ini, hanya sekitar 0.45%
Namun ini masih sangat baru, jadi saya berharap model generasi berikutnya akan jauh lebih baik
Cukup biarkan model lama mewawancarai model baru, lalu minta keduanya atau model hakim pihak ketiga memutuskan siapa yang lebih pintar, kemudian ganti seed dan ulangi 100 kali
Rasio ketika kedua sisi sama-sama mengakui kemenangan model baru bisa dijadikan skor
Jenis itu paling sulit untuk dimanipulasi
Kalau dipikir-pikir memang agak lucu
Benchmark yang lebih baik harus punya penilaian objektif, cakupan multidisipliner, dan skalabilitas, serta menghindari format dengan hanya satu jawaban benar
Apa yang kami rancang di https://gertlabs.com juga mengarah ke sana, dan secara umum dibuat tetap terkait dengan pemecahan masalah melalui coding
Menurut pengalaman saya, gpt 5.4/5.5 secara teknis nyaris tanpa cela, dan ketika ada masalah biasanya karena input-nya tidak jelas
Saat memperbaiki bug atau menghadapi issue selama implementasi pun model ini cenderung bisa menangani sendiri
Sebaliknya, menurut saya Opus agak dinilai terlalu tinggi dari sisi kemampuan teknis
Memang ia punya sense desainer/developer yang lebih baik untuk membuat UX yang indah, tetapi untuk verifikasi pekerjaan saya selalu menyerahkannya ke gpt 5.5
Hasil yang paling mengejutkan adalah Xiao-Mi; saya belum mencobanya, tetapi setelah melihat ini saya jadi ingin mencobanya
Selamat untuk tim karena telah membuat tolok ukur yang bermakna di tengah perlombaan AI yang kacau ini
Ini terlihat seperti bias dataset pelatihan atau perbedaan fokus go-to-market, dan saya jadi berpikir mungkin ini hasil dari Anthropic yang lebih fokus ke pelanggan enterprise dibanding OpenAI
Ini juga sesuai dengan pengalaman saya memakai Opus untuk C++
Namun hasil C# masih kosong; @gertlabs, adakah ETA-nya?
Saya penasaran apa komentarnya tentang mengapa hasilnya bisa begitu
Hal seperti ini, baik secara organik maupun non-organik, pada akhirnya memang tidak terhindarkan
Mudah sekali arahnya menjadi sekadar membuat model yang bagus nilainya di benchmark, meskipun tidak benar-benar bisa digeneralisasi ke luar
Graduate student descent juga mengingatkan saya pada hal serupa
https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...
Kalau dipikir-pikir lagi, SWE-bench mungkin memang tidak pernah sehebat itu sejak awal
Sepanjang 2025, proporsi model yang menghasilkan kode yang bagus pada dasarnya hampir tidak membaik, dan interpretasi yang lebih tepat tampaknya adalah bahwa yang membaik hanyalah kemampuan lolos dari automated test
https://entropicthoughts.com/no-swe-bench-improvement
Pada Januari 2025 model utama yang dipakai adalah Claude 3.5 Sonnet, Gemini 1.5 Pro, dan untuk OpenAI GPT-4o, dan sebagai orang yang sudah memakai model-model itu serta model frontier saat ini, saya merasa jelas model sekarang sudah naik satu tingkat besar
Kualitas model tampaknya sedang stagnan, dan mencari vektor perbaikan baru jelas bukan hal mudah
Perluasan lebar model yang selama ini mendorong laju peningkatan juga tampak mulai mencapai batasnya, jadi saya penasaran implikasinya ke depan
Dalam jangka panjang, ada juga batas untuk seberapa jauh tooling saja bisa menyelesaikan masalah
Itu juga salah satu alasan Anthropic dinilai bernilai puluhan miliar dolar
Alasan SWE-bench berguna di ranah coding adalah karena tradisi dan infrastruktur untuk membuat serta memanfaatkan automated test di software engineering memang sangat kuat
Yang dikatakan artikel itu saya pahami sebagai berikut: mereka mengaudit subset 27.6% yang sering gagal diselesaikan model, dan menemukan bahwa setidaknya 59.4% di dalamnya memiliki test cacat yang menolak submission yang secara fungsional benar
Kalau ini benar, rasanya berarti selama ini ada porsi besar dari soal dan jawaban yang memang salah, dan kalau begitu sulit dipahami bagaimana ini bisa dianggap pengukuran yang valid
Kalau melihat penjelasan proses pembuatan benchmark-nya, standarnya terlihat cukup tinggi, jadi saya juga tidak paham bagaimana prosedur seperti itu bisa berujung pada kualitas data yang seburuk ini
Tentu patut diapresiasi bahwa mereka sendiri yang mengungkap masalah ini, tetapi tetap banyak pertanyaan yang tersisa
Dan karena alasan yang realistis, benchmark pada dasarnya memang tidak akan pernah mewakili use case Anda, maupun semua use case
Ia hanya valid untuk mengukur item yang memang ada di dalamnya, tidak lebih dan tidak kurang
Itu juga alasan saya tidak paham kenapa ekosistem begitu terobsesi pada benchmark publik
Misalnya, fakta bahwa Qwen 3.5 50% lebih baik daripada Qwen 2.5 di Benchmark X hampir tidak memberi jaminan bahwa ia akan 50% lebih baik untuk tugas yang saya pakai
Saya terus membuat benchmark privat berdasarkan kasus-kasus kegagalan model dalam penggunaan nyata, sambil menyesuaikan prompt
Bahkan saat ada update model baru, pergerakannya di benchmark saya biasanya hanya 2–3%, sementara di benchmark publik mereka mempromosikan kenaikan 30–40%, jadi sulit percaya tidak ada kontaminasi data pelatihan
Dalam kasus ekstrem, bisa muncul bagian di mana untuk mendapatkan skor lebih tinggi justru Anda harus menyesuaikan diri pada jawaban yang salah
Pada akhirnya, jawabannya adalah bahwa ML adalah bidang yang sangat berusaha untuk tetap bekerja dengan cara apa pun, sehingga bahkan dengan cacat pun ia bisa melaju sangat jauh
Di saat yang sama, inilah juga alasan mengapa menunjuk cacat yang belum dilihat orang lain bisa menghasilkan terobosan besar
Selama sebagian besar tugas dinilai dengan benar, arah umumnya masih bisa dipertahankan
Misalnya, bahkan benchmark buruk dengan 49% label salah pun masih bisa memberikan ranking yang benar jika model yang selalu benar mendapat 51% dan model yang selalu salah mendapat 49%
Sebagian besar benchmark machine learning memang memiliki cukup banyak mislabel, tetapi jika tujuannya membedakan model, biasanya lebih baik mengumpulkan dataset yang lebih besar daripada menghabiskan waktu untuk menjamin penilaian yang sempurna