Benchmark Agen Peninjau Kode: Cara Mengevaluasi Seorang Peninjau, dan Menjalankan c-CRAB pada Kode Anda Sendiri

Bagaimana Anda tahu apakah agen peninjau kode itu bagus? Untuk sebagian besar sejarah singkat bidang ini, jawabannya adalah "mengukur seberapa dekat komentarnya dengan komentar dari peninjau manusia" — yang terdengar masuk akal sampai Anda benar-benar mencobanya, karena dua peninjau dapat mengangkat masalah yang sama dengan kata-kata yang sama sekali berbeda. Code Review Agent Benchmark — makalahnya adalah arXiv:2603.23448, datanya adalah c-CRAB — adalah upaya serius pertama untuk menilai sebuah tinjauan berdasarkan hasil tindak lanjutnya, bukan berdasarkan frasanya. Tolok ukur ini mengubah 234 komentar peninjau manusia menjadi tes yang dapat dieksekusi, menjalankan empat peninjau yang banyak digunakan pada tes-tes tersebut — PR-Agent, Devin, Claude Code, dan Codex — dan menemukan bahwa keempatnya jika digabungkan lulus 41,5% dari tes-tes tersebut, "hanya sekitar 40%" dengan kata-kata makalah itu sendiri. Halaman ini adalah buku pedoman: cara membaca hasil itu tanpa merusak maknanya, cara menjalankan c-CRAB sendiri, dan apa yang harus dilakukan ketika basis kode Anda tidak termasuk dalam tolok ukur sama sekali.

Angka utama adalah hal yang paling tidak berguna di halaman ini. Hal-hal yang berguna adalah metode dan mode kegagalannya: mengapa setiap skema penilaian sebelumnya mengukur hal yang salah, berapa biaya untuk menilai sebuah review dengan tes yang dapat dieksekusi sebagai gantinya, dan mengapa "agen review hanya menangkap 40% bug" adalah kesalahan pembacaan tiga lapis dari hasil sebenarnya. Semua yang ada di sini adalah pembacaan komunitas terhadap tolok ukur yang dipublikasikan dan pengalaman para praktisi dalam menjalankannya — bukan panduan vendor dari pembuat alat yang terlibat.

Mengapa metrik yang tampak jelas tidak berhasil

Sebelum c-CRAB, evaluasi agen peninjau kode terbagi ke dalam sejumlah kecil keluarga, dan tabel perbandingan milik makalah itu sendiri (Tabel 1) memaparkan garis keturunannya. Yang tertua adalah tumpang tindih teks — BLEU, ROUGE, chrF dan kawan-kawannya, digunakan oleh tolok ukur seperti CodeReviewer dan ContextCRBench. Idenya adalah bahwa komentar agen dianggap baik ketika n-gram-nya cocok dengan milik manusia. Ide ini gagal pada satu jenis kasus yang ada di mana-mana dalam peninjauan kode: cacat yang sama dijelaskan dengan kata-kata yang berbeda.

Studi kasus makalah ini adalah contoh paling jelas. Pada sebuah pull request di python-telegram-bot (PR #3514), peninjau manusia dan Codex sama-sama menandai bug ketahanan pengindeksan bersarang yang sama. Tinjauan Codex benar secara perilaku — agen pengkode yang bertindak berdasarkan tinjauan itu menghasilkan perbaikan yang lulus tes yang dapat dieksekusi. Namun metrik teks memberinya skor BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, dan similaritas embedding 54.59. Tidak ada tumpang tindih n-gram, dan tinjauan itu benar. Kekhawatiran yang sama, kata-kata berbeda: metrik string tidak dapat melihatnya. Similaritas embedding adalah peningkatan parsial — 54.59 terhadap kelulusan yang dikonfirmasi masih jauh dari ambang yang dapat digunakan — dan ia mewarisi masalah yang sama dalam bentuk yang lebih lunak.

LLM-as-judge, di mana sebuah model membandingkan tinjauan agen dengan tinjauan manusia dan memberikan suara, memperbaiki masalah kosakata tetapi membawa tiga masalah baru, yang disebut langsung oleh makalah tersebut: bias, ketidakstabilan, dan sensitivitas terhadap desain prompt. Jalankan perbandingan yang sama dua kali dan seorang juri dapat memberikan Anda vonis yang berbeda; susun ulang prompt penilaian dan peringkat akan berubah. Ketika Anda memilih di antara dua peninjau yang terpaut tiga poin pada tolok ukur yang sama, juri dengan varians seperti itu tidak dapat mendukung keputusan — dan skor yang tidak dapat Anda reproduksi bukanlah skor.

Apa yang dibeli oracle yang dapat dieksekusi — dan berapa biayanya

Ide yang mendasari c-CRAB sederhana sekaligus radikal: alih-alih bertanya "apakah ulasan ini terdengar seperti ulasan manusia?", bertanyalah "jika Anda bertindak berdasarkan ulasan tersebut, apakah kode menjadi diperbaiki?". Setiap komentar ulasan manusia yang dipertahankan diubah menjadi tes yang dapat dijalankan yang menangkap masalah yang mendasarinya. Sebuah komentar ulasan dianggap benar jika menindaklanjutinya menghasilkan perbaikan yang benar secara perilaku yang membuat tes lulus — dan setiap instance dilengkapi dengan lingkungan Docker yang dapat dijalankan, sehingga "membuat tes lulus" adalah fakta, bukan penilaian.

Makalah ini mendefinisikan dua jenis pengujian. Tes perilaku "mengimpor dan mengeksekusi kode yang diuji pada saat runtime," memanggil fungsi "dengan input spesifik" dan memeriksa "output atau memverifikasi pengecualian." Tes struktural "memeriksa teks kode sumber, mencocokkan pola, dan memeriksa permukaan API untuk menentukan apakah perubahan kode yang diinginkan telah dilakukan." Pembagian akhir adalah 42 perilaku (17,9%) dan 192 struktural (82,1%) — dan kemiringan itu pantas mendapatkan kalimat yang jujur: sebagian besar oracle ini adalah pencocokan pola pada teks sumber, bukan mengeksekusi kode. Standar emasnya adalah tes perilaku; mayoritas dataset adalah versi pragmatis dari tes tersebut.

Membangun oracle adalah corong empat tahap, dan setiap tahapnya membuang sesuatu:

• Dataset awal — 671 PR, 1,313 komentar review.

• Penyaringan review — 410 PR, 595 komentar. Pengklasifikasi LLM, yang dikalibrasi terhadap set emas berisi 100 komentar beranotasi manual, hanya menyimpan isu yang dapat diverifikasi secara objektif dan membuang umpan balik percakapan atau subjektif.

• Pembangunan lingkungan eksekusi — 410 PRs, 595 komentar. Satu image Docker per PR, dengan resolusi dependensi yang dialihkan ke agen pengodean saat otomatisasi gagal.

• Mengonversi komentar NL menjadi tes — 339 PR, 481 komentar. Dibuat dengan GPT-5.2 dalam loop penyempurnaan yang dipandu eksekusi (hingga tiga percobaan); tes hanya dipertahankan jika gagal pada versi sebelum dan lulus pada versi sesudah.

• Validasi dengan agen pengkodean — 184 PR, 234 komentar (final). Claude Code pada backend Sonnet-4.6 mencoba memperbaiki kode hanya berdasarkan komentar ulasan manusia; kasus di mana ia tidak dapat membuat tes lolos akan dibuang.

Sekitar 27% dari pull request awal bertahan. Nyatakan itu secara gamblang, karena itulah harga jujur dari oracle berbasis tes: jika sebuah komentar tidak cukup dapat ditindaklanjuti untuk menjadi tes yang gagal, atau lingkungan tidak dapat dibangun, atau agen pengodean yang kompeten tidak dapat memperbaiki kode hanya dari komentar tersebut, instance itu dibuang. Itu juga mengapa tolok ukurnya kecil. 184 instance PR dan 234 komentar tervalidasi adalah kumpulan data yang dapat Anda baca, bukan korpus yang dapat membuat Anda tenggelam — dan untuk oracle yang harus menjalankan lingkungan Docker nyata, ukuran yang kecil adalah sebuah fitur.

Sebagai gambaran: rata-rata instance menyentuh 418.1 baris yang dimodifikasi, pengujian rata-rata 31.8 baris, dan ada 1.27 pengujian per instance. Dua annotator setuju 84% dari waktu — pada lebih dari 50 instance sampel — mengenai apakah pengujian yang dihasilkan secara setia menangkap kekhawatiran peninjau manusia.

Satu cacat bibliografis yang akan Anda temui jika membaca sendiri makalahnya: tabel dataset (Tabel 4) mencantumkan 67 repositori, sedangkan bagian Threats to Validity menyebutkan "184 kasus pull request dengan 234 oracle yang dapat diverifikasi di 56 repositori." Makalah memberikan kedua angka tersebut di tempat yang berbeda dan tidak menyelaraskannya. Jangan memilih salah satu favorit dan jangan membuat rata-ratanya — kutip masing-masing sesuai tempat kemunculannya. Perbedaan seperti ini justru merupakan detail yang digunakan pembaca untuk memutuskan apakah sebuah tolok ukur layak mendapatkan waktu mereka.

Untuk uji tuntas atas independensi: makalah tersebut mengungkapkan bahwa salah satu penulis berafiliasi dengan SonarSource, dan menyatakan bahwa temuan tersebut tidak boleh ditafsirkan sebagai "evaluasi kualitas produk di SonarSource." Itu adalah penafian mereka, dikutip, bukan diparafrasekan.

Cara membaca skor pada c-CRAB tanpa salah mengutipnya

Metrik utamanya adalah tingkat kelulusan: per instance, proporsi tes PR tersebut yang lulus, dirata-ratakan pada 184 instance. Berikut tabel hasil lengkap dari makalah tersebut, satu baris per peninjau. Baris manusia merupakan penanda skala, bukan pesaing — manusia menulis oracle, sehingga mereka mendapat skor 100% secara konstruksi.

• Claude Code — 1.336 komentar, 7,3 per PR, keseluruhan 32,1% (perilaku 38,1%, struktural 30,7%).

• Devin — 1.344 komentar, 7,3 per PR, keseluruhan 24,8% (perilaku 31,0%, struktural 23,4%).

• PR-Agent — 524 komentar, 2,8 per PR, keseluruhan 23,1% (perilaku 38,1%, struktural 19,8%).

• Codex — 324 komentar, 1,8 per PR, total 20,1% (perilaku 38,1%, struktural 16,1%).

• Manusia — 234 komentar, 1,3 per PR, 100% secara konstruksi.

Tiga koreksi, karena pernyataan 'hanya sekitar 40%' dalam abstrak adalah angka yang paling banyak disalahkutip dalam percakapan pengembang AI saat ini. Pertama, angka 41,5% — 97 dari 234 tes yang lolos oleh setidaknya satu alat — adalah gabungan dari keempat peninjau: sebuah tes dihitung sekali jika agen mana pun melewatinya. Tidak ada satu agen pun yang mencapai 41,5%; skor tunggal terbaik adalah milik Claude Code dengan 32,1%. Kedua, baris manusia adalah oracle, bukan kontestan; mengulanginya sebagai 'manusia mengalahkan bot' adalah kesalahan kategori. Ketiga, dan yang terpenting: c-CRAB tidak memberikan kredit untuk masalah valid yang tidak pernah diangkat oleh peninjau manusia. Oracle adalah niat peninjauan manusia. Agen yang menemukan bug nyata yang tidak disebutkan siapa pun mendapat skor nol untuk itu. Jadi, pernyataan 'agen peninjau AI hanya menangkap 40% bug' salah dalam tiga hal — itu adalah gabungan, bukan tingkat penangkapan bug, dan itu mengukur kesepakatan dengan peninjau manusia, bukan kebenaran total.

Volume komentar adalah jebakannya.

Angka paling menarik dalam hasil tersebut bukanlah pemenangnya. Claude Code dan Devin masing-masing memposting lebih dari 1.300 komentar — sekitar 7,3 per PR — untuk mencapai 32,1% dan 24,8%. Codex memposting 324 komentar, sekitar 1,8 per PR, dan mencapai 20,1%. Baseline manusia adalah 1,3 komentar per PR. Volume bukanlah cakupan: kira-kira lima kali lipat komentar hanya menghasilkan kurang dari dua kali lipat tingkat kelulusan. Jika Anda memilih peninjau, biaya sebenarnya dari semua komentar tambahan tersebut adalah kelelahan peninjauan manusia — setiap komentar yang diposting agen adalah sebuah penilaian yang harus ditriase oleh seseorang.

Temuan tentang kebermanfaatan ini justru mengarah ke arah sebaliknya, dan ini adalah bagian yang membuat hal ini tidak menjadi sekadar cerita murahan "para bot itu berisik". Para penulis memeriksa secara manual 92 komentar di 6 PR dan menilai 84% (77/92) berguna — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Jadi sebagian besar komentar yang gagal dalam pengujian bukanlah kebisingan; komentar-komentar itu membahas sesuatu yang tidak diangkat oleh peninjau manusia. Ukuran sampelnya kecil — 92 komentar, 6 PR — dan perlu disebutkan bersamaan dengan persentase-persentase tersebut.

Apa yang sebenarnya dibicarakan oleh kedua belah pihak menjelaskan bentuk hasilnya. Peninjau manusia condong ke arah kemudahan pemeliharaan, desain, dan dokumentasi; alat-alat tersebut condong ke arah ketahanan, pengujian, dan penanganan kesalahan. Makalah ini menafsirkan hal ini sebagai argumen untuk kolaborasi manusia-agen, bukan penggantian — dan ini juga merupakan penjelasan terbaik yang tersedia untuk mengapa skor-skor tersebut terlihat rendah. Seorang peninjau yang tajam pada kasus tepi tetapi diam pada desain akan secara sistematis melewatkan kategori-kategori yang ditandai manusia, dan oracle dibangun sepenuhnya dari penanda manusia.

Para praktisi yang telah melalui ini sampai pada tempat yang sama. Sebuah tulisan rinci oleh Daniel Vaughan yang menyebut karya tersebut CR-bench mencapai kesimpulan yang sama dan mengubahnya menjadi alur kerja: biarkan agen melakukan pemeriksaan ketahanan dan kebenaran, pertahankan manusia pada desain, konvensi, dan arsitektur — kategori di mana agen mendapat nilai terburuk — dan arahkan agen dengan instruksi tinjauan yang menyebutkan kategori-kategori lemah tersebut. Peringatan paling berguna baginya bagi siapa pun yang membaca papan peringkat: "kegunaan tidak sama dengan tingkat kelulusan," karena rangkaian pengujian mengharuskan pencocokan perbaikan yang dimaksudkan manusia, dan perbaikan alternatif yang valid gagal dalam pengujian. Jalan dari 20% ke skor yang lebih tinggi secara bermakna, menurut bacaannya, bukanlah peningkatan model — melainkan pekerjaan konfigurasi.

Menjalankan c-CRAB sendiri

Semua di atas adalah membaca hasil orang lain. Paket replikasi membuat tolok ukur dapat dijalankan — ia berada di c-CRAB-Benchmark/dataset di GitHub — dan README jujur tentang apa yang dibutuhkannya.

Persyaratan: code>uv sync/code>; Docker; dan salah satu code>OPENAI_API_KEY/code> atau code>ANTHROPIC_API_KEY/code> (Claude Code juga membaca kredensial dari code>~/.claude/.credentials.json/code>, yang dipasang ke dalam kontainer secara default). Tata letaknya terdiri dari lima direktori: code>pipeline//code> (logika pipeline dan prompt), code>execution//code> (pembangun image Docker dan alat bantu runtime), code>results_preprocessed//code> (subset benchmark yang dirilis), code>results_pipeline_funnel//code> (file JSONL stage0–stage4 dan ringkasan funnel), dan code>raw_results_compressed//code> (output eksperimen mentah). Kelima langkah tersebut, secara berurutan:

1. Bangun lingkungan Docker — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Image pra-bangun juga dipublikasikan di bawah organisasi GitHub packages c-CRAB-Benchmark jika Anda lebih memilih untuk melewati proses pembangunan.

2. Hasilkan tes — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. Kumpulkan ulasan baseline — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. Konfigurasikan kredensial alat eksternal yang sesuai sebelum langkah ini.

4. Jalankan resolusi agen — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. Evaluasi — ulangi sekali per alat: code>uv run run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

Dua hal yang tidak diiklankan oleh README. Menambahkan peninjau kelima berarti mengedit code>run_batch_baselines.py/code> — di situlah tempat prompt peninjauan baseline per alat berada, dan tidak ada antarmuka plugin; README tidak mendokumentasikan titik ekstensi yang lebih baik. Dan repositori tidak menyertakan berkas lisensi eksplisit, jadi jangan menganggap kode tersebut berlisensi MIT atau Apache — makalahnya adalah CC BY 4.0, dan ketentuan kode itu sendiri tidak disebutkan.

Biaya adalah item lain yang tidak diiklankan. Makalah ini tidak mempublikasikan angka token maupun dolar untuk menjalankan pipeline, jadi anggap saja angka biaya apa pun yang Anda lihat dikutip secara daring sebagai tidak terverifikasi. Apa yang tersirat dari strukturnya sudah cukup jelas: satu image Docker per PR di 184 instance, ditambah tahap resolusi agen coding dan tahap evaluasi per alat. Itu bukan pekerjaan seukuran laptop untuk satu sore — siapkan komputasi yang sesungguhnya.

Ketika Anda tidak mampu membeli oracle yang dapat dieksekusi

Posisi jujur sebagian besar tim adalah: tolok ukur itu benar bahwa hakim LLM tidak dapat menilai ulasan, tetapi membangun oracle berbasis tes untuk PR Anda sendiri adalah usaha besar. Perbedaan yang layak digarisbawahi adalah antara hakim LLM sebagai penilai dan hakim LLM sebagai penyaring. Penolakan c-CRAB terhadap hakim sebagai oracle tidak membuat hakim tidak berguna di dalam peninjau — hakim yang mengelompokkan temuan duplikat dan membuang temuan yang lemah masih dapat meningkatkan presisi. Mode kegagalan yang harus dirancang untuk dilawan adalah independensi.

Sebuah penilai yang berjalan pada model milik peninjau itu sendiri akan setuju dengan dirinya sendiri: ia membaca tinjauan tersebut, menganggapnya masuk akal, dan melaporkan keberhasilan tanpa mengubah apa pun. Penilai dari vendor yang berbeda mengurangi persetujuan-diri itu — ia tidak mengubah penilai menjadi sebuah pengujian, tetapi ia menghentikan stempel karet. Kami dapat menunjukkan kepada Anda contoh konkret yang dapat diperiksa dari guardrail yang persis seperti ini karena perangkat uji kami sendiri terbuka: Orca-Code-Reviewdi GitHub dilisensikan di bawah MIT, dan resep peruteannya menyatakan aturan tersebut dengan kata-kata repo itu sendiri — penilai "TIDAK BOLEH MENYEBUT MODEL DEFAULT," karena "pada model milik peninjau itu sendiri, ia setuju dengan dirinya sendiri, sehingga pass menjadi inert namun tetap melaporkan keberhasilan." Action tidak pernah menyebut nama model; reseplah yang memutuskan. Sesuai penyediaan awal, peninjau default adalah deepseek/deepseek-v4-flash-0731, dan sebuah aturan yang cocok dengan code>x-cr-lens: judge/code> header mengirim pass penilai ke z-ai/glm-5.3 — vendor yang berbeda. Itu adalah kesejajaran desain dengan argumen c-CRAB, bukan sebuah hasil: kami tidak berada dalam benchmark dan tidak ada skor c-CRAB untuk peninjau kami. Namun ini adalah mitigasi praktis yang tersedia bagi siapa pun yang tidak dapat membangun oracle yang dapat dieksekusi, dan ini murah ketika penilai dan peninjau dapat berada di penyedia yang berbeda di balik satu kunci — justru untuk itulah router ada. Di OrcaRouter, peninjau dan penilainya hanyalah dua baris dalam DSL perutean, dan Anda membayar harga daftar penyedia dengan markup nol.

Ketika kode Anda tidak termasuk dalam benchmark

184 PR di 56-atau-67 repositori publik bukanlah basis kode Anda, dan memang tidak akan pernah menjadi. Bagian yang dapat ditransfer adalah metodenya, dan Anda bisa menjalankannya pada riwayat Anda sendiri dalam skala yang jauh lebih kecil. Ambil PR yang sudah digabung dan memiliki komentar tinjauan manusia. Untuk sampel komentar tersebut, tulis tes yang gagal sebelum tinjauan ditindaklanjuti dan lulus setelahnya — properti gagal-lalu-lulus itulah inti permainannya. Jalankan peninjau kandidat Anda pada diff pra-tinjauan. Lalu periksa apakah menindaklanjuti komentarnya membuat tes tersebut lulus. Yang Anda dapatkan adalah angka yang dihitung pada kode yang benar-benar Anda rilis, dan itu lebih berharga daripada posisi papan peringkat. Biayanya persis seperti tembok yang dihadapi makalah tersebut: Anda membutuhkan lingkungan per-PR yang dapat direproduksi, karena tes yang hanya lulus di laptop Anda bukanlah oracle.

Anda tidak perlu 234 pengujian. Selusin pengujian yang dipilih dengan cermat pada PR yang benar-benar diperdebatkan tim Anda akan memberi tahu Anda lebih banyak tentang peninjau Anda daripada skor tolok ukur. Dan analisis praktisi paralel tentang keluarga tolok ukur ini blak-blakan soal gerbangnya: presisi pengklasifikasi LLM dalam menentukan apakah sebuah komentar merupakan isu yang valid dan dapat diverifikasi berada di antara 66% dan 85%, jadi perlakukan penyaringan mesin sebagai daftar pendek dan pertahankan langkah adjudikasi manusia sebelum apa pun menjadi pengujian. Tulisan yang sama mencatat bahwa ReviewBench milik LangChain, yang dibangun secara independen dengan ide komentar-ke-pengujian yang sama, paling banter menemukan kembali sekitar 30% isu baseline-nya — dalam kisaran yang sama dengan 20–32% milik c-CRAB — dan menjadi pengingat bahwa selisih papan peringkat satu digit antartool sering kali lebih kecil daripada derau pada pengaturan Anda sendiri.

Jika Anda sama sekali sedang memutuskan alat peninjau mana yang akan dibeli, itu adalah pertanyaan yang berbeda — panduan pembeli agen peninjau kode kami mencakup perbandingan bot vs agen, penetapan harga per kursi vs per token, dan kapan self-hosting lebih unggul — dan setelah Anda memilikinya, biaya operasional dari kerangka peninjauan pada setiap push dijelaskan dalam penjelasan peninjauan kode otomatis kami. Halaman ini hanya tentang pengukuran, dan bagian pendamping dari halaman ini memandu Anda melalui anatomi tolok ukur: corong konstruksi, statistik kumpulan data, dan tabel hasil lengkap.

FAQ

Apakah 41,5% adalah skor terbaik agen?Bukan. 41,5% adalah gabungan dari keempat alat — sebuah tes dihitung sekali jika salah satu dari alat tersebut berhasil melewatinya. Skor tunggal terbaik adalah milik Claude Code, yaitu 32,1%.

Apakah c-CRAB mengukur berapa banyak bug yang ditangkap oleh seorang peninjau? Tidak. Ini mengukur seberapa baik sebuah tinjauan cocok dengan apa yang diangkat oleh peninjau manusia, yang diubah menjadi tes yang dapat dieksekusi. Cacat nyata yang tidak pernah disebutkan manusia mendapat skor nol, betapapun validnya.

Apakah para peninjau manusia "mengalahkan" bot-bot tersebut?Baris 100% manusia adalah oracle itu sendiri — para manusia menulis tes-tesnya — jadi ini adalah penanda skala, bukan pesaing.

Apakah c-CRAB sama dengan CR-bench? Ya. Dataset-nya adalah c-CRAB; beberapa liputan pihak ketiga menyebutnya CR-bench, tetapi hanya ada satu tolok ukur di sini.

Berapa biaya untuk menjalankannya? Makalah ini tidak mencantumkan angka biaya. Satu image Docker per PR di 184 instance, ditambah proses resolusi agen, mengimplikasikan komputasi nyata — bukan sekadar pekerjaan sore berskala laptop.

Intinya

Kontribusi c-CRAB bukanlah leaderboard — melainkan demonstrasi bahwa sebuah tinjauan dapat dinilai dengan menjalankan sarannya, dan bahwa skema kesamaan teks dan penilai-LLM yang ada sebelumnya menilai hal yang salah. Jika Anda hanya mengambil satu hal, jadikan itu koreksi tiga bagian: 41.5% adalah gabungan, baris manusia adalah oracle, dan tolok ukur tidak memberikan kredit untuk cacat yang tidak pernah diangkat oleh manusia. Dan jika Anda menginginkan angka yang dapat Anda tindak lanjuti, metode ini dapat ditransfer — uji gagal-lalu-lulus pada PR gabungan Anda sendiri, langkah adjudikasi manusia, dan, jika Anda tidak dapat membangun oracle yang dapat dieksekusi, setidaknya seorang penilai yang modelnya independen terhadap model peninjau.

Jika Anda lebih suka mengukur seorang peninjau daripada berdebat tentangnya, mulailah dari harness yang dapat Anda baca. OrcaCode Review menjalankan proses review plus hakim verifikasi independen, per token daripada per kursi, dan setiap prompt di dalamnya bersifat publik — sehingga Anda dapat mengarahkannya ke benchmark seperti ini dan mendapatkan angka Anda sendiri, bukan angka kami.