1. Pergeseran Paradigma: Mengapa Kita Butuh Executable Verifiers?

Dalam rekayasa sistem autonomous AI agent tahun 2026, ketergantungan pada LLM-as-a-Judge natural language berbasis teks pasca-eksekusi telah terbukti rapuh. Model evaluator berbasis prompt sering mengalami bias penjilat (sycophancy), rentan terhadap injeksi prompt terselubung, dan gagal menangkap efek samping status sistem (environment side-effects) seperti file mutasi, koneksi socket, atau perubahan skema basis data.

Sebagai gantinya, industri berpindah ke paradigma Executable Verifier Generation: diberikan instruksi tugas dan lingkungan eksekusi, agen AI diinstruksikan untuk menulis kode verifikator deterministik (biasanya script Python atau test suite modular). Verifikator ini harus menjalankan dua fungsi vital:

• Runtime Safety & Task Completion Gate: Menilai apakah pull request atau tindakan agen memuaskan seluruh kontrak kebutuhan sebelum perubahan digabungkan ke staging/production.
• Synthetic Data Quality Filter: Menyaring lintasan (trajectories) bernilai tinggi untuk pelatihan RL (Reinforcement Learning) dan post-training distillation, memisahkan solusi yang benar-benar valid dari tebakan halusinasi yang lolos kebetulan.

Namun, apakah kode verifikator yang dihasilkan oleh model frontier seperti GPT-6-astra, Claude Opus 4.8, GPT-5.6, Kimi K3, hingga GLM-5.2 benar-benar andal? Riset VerifierBench membuktikan bahwa verifikasi otomatis saat ini menyimpan cacat arsitektur tersembunyi yang sangat berbahaya.

Gambar 1: Arsitektur menyeluruh VerifierBench (arXiv:2610.28679). Agen membaca instruksi dan mengeksplorasi environment untuk mensintesis executable verifier. Verifier dievaluasi terhadap 4.993 test cases tersembunyi yang disaring secara ketat melalui protokol 6 lapis Verifier4Verifier (V4V).

2. Taksonomi VerifierBench: 222 Tugas & 4.993 Test Cases Tersembunyi

VerifierBench mengumpulkan 222 tugas terkurasi dari enam benchmark agen terkemuka yang mencakup tiga domain verifikasi:

Setiap tugas dilengkapi dengan rata-rata 22.5 test cases tersembunyi yang dikelompokkan ke dalam 4 kuadran pengujian independen:

• Reference Solution (Gold): Implementasi kanonikal standar yang menyelesaikan tugas secara sempurna.
• Valid Variants: Solusi alternatif yang menggunakan gaya koding berbeda, representasi data berbeda (misal: JSON vs Stringified dict), atau urutan tool-call berbeda namun tetap memenuhi 100% spesifikasi kontrak publik.
• Ordinary Errors: Kesalahan umum seperti perbaikan parsial, regresi tes terdahulu, parameter tipe salah, atau eksekusi yang menghasilkan kode error non-zero.
• Adversarial Attacks: Upaya eksploitasi keamanan, seperti pemalsuan sinyal sukses (mocking test passes), eksfiltrasi environment variables, modifikasi harness, atau pengubahan file test suite untuk meloloskan kode cacat.

3. Audit Verifier4Verifier (V4V): Eksklusi 45 Task Cacat Bawaan

Kontribusi metodologis krusial dari paper ini adalah pengakuan jujur bahwa verifier acuan dari benchmark open-source populer pun sering kali cacat. Jika verifier acuan mengandung bug, memberi nilai pada model agen menjadi sia-sia.

Untuk menjamin kualitas label kebenaran dasar (ground truth), tim peneliti merancang audit 6 lapis bernama Verifier4Verifier (V4V):

4. Ilusi Angka TNR Tinggi: Mengapa Frontier Model Terjebak Hyper-Restriction?

Untuk mengukur akurasi tanpa terdistorsi oleh ketimpangan proporsi data positif vs negatif, VerifierBench menggunakan Normalized Balanced Accuracy ($BA_{ m norm}$):

Skor ini bernilai 0 untuk baseline konstan (selalu PASS atau selalu FAIL) dan bernilai 100 untuk kesepakatan sempurna. Berikut adalah hasil evaluasi 19 model frontier pada harness Pi standar:

Gambar 2: Jurang Pemisah Penerimaan vs Penolakan (Figure 3 arXiv:2610.28679). Seluruh model memiliki True Negative Rate (TNR) jauh melampaui True Positive Rate (TPR). Model tampak sangat cerdas dalam mendeteksi serangan (FPR_h sangat rendah), namun keunggulan semu ini ternyata berasal dari kecenderungan patologis menolak semua solusi.

Paradoks Keamanan Semu: Rendahnya FPR_h Bukan Bukti Keandalan

Perhatikan data pada GPT-5.6-sol: model ini memiliki tingkat kelulusan serangan ($FPR_h$) mendekati nol mutlak (0.8%). Dalam kacamata evaluasi keamanan naif, model ini akan dinobatkan sebagai verifier keamanan paling superior di dunia.

Namun, paper ini membuktikan secara matematis bahwa keunggulan ini adalah fatamorgana: verifikator yang dihasilkan oleh GPT-5.6-sol memiliki TPR hanya 56.8%. Bahkan pada tugas berbasis state, verifikatornya menolak 100% seluruh solusi valid yang diuji! Sebuah pintu gerbang yang dilas mati secara permanen memang memiliki tingkat kebocoran maling 0%, tetapi pintu tersebut sepenuhnya tidak berguna karena menghalangi seluruh penghuni rumah yang sah.

Gambar 3: Konsentrasi False Rejection (Figure 5 arXiv:2610.28679). Antara 87.9% hingga 96.0% dari seluruh kasus penolakan solusi valid terkonsentrasi pada verifier bertipe all-reject (verifikator yang menolak seluruh solusi pengujian tanpa satupun yang lolos).

5. Bedah 4 Kasus Nyata: Mengapa Verifier Menolak Solusi yang Sah?

Melalui analisis trace generasi pada model terunggul (GPT-6-astra batch), peneliti menemukan bahwa penolakan salah (false rejection) berakar dari Unjustified Checks: aturan pengecekan tambahan yang dikarang sendiri oleh agen AI yang tidak ada dalam kontrak instruksi publik.

6. Anatomi Confirmatory Self-Testing & Habisnya Budget Komputasi

Jika cacat aturan di atas begitu kentara di dalam kode yang dihasilkan, mengapa fase self-testing agen tidak berhasil menemukannya?

Penelitian ini mengidentifikasi dua patologi sistemik dalam perilaku penalaran agen AI:

Gambar 4: Analisis Kesepakatan Level Test-Case dan Vonis Keputusan (Figure 4 arXiv:2610.28679). Lebih dari 57.1% kegagalan keputusan positif berasal dari vonis eksplisit FAIL oleh verifier, bukan karena crash atau runtime timeout, menegaskan bahwa kegagalan didorong oleh kekeliruan logika verifikasi, bukan stabilitas infrastruktur.

7. Implementasi Produksi: TypeScript Executable Verifier Engine & V4V Audit

Berikut adalah implementasi referensi modul TypeScript kelas produksi yang mengimplementasikan spesifikasi audit 6 lapis Verifier4Verifier (V4V), deteksi otomatis verifikator all-reject, serta penegakan gerbang Anti-Confirmatory Self-Testing:

${VERIFIERBENCH_CODE_SNIPPET.replace(//g, '>')}

8. Panduan Teknis & Mitigasi untuk Rekayasa Agen AI 2026/2027

Bagi tim pengembang yang membangun sistem autonomous agent, CI/CD code generation, atau synthetic data pipeline, riset VerifierBench memberikan panduan taktis yang harus segera diadopsi:

1. Jangan Percaya Metrik Single-Directional Security: Jangan pernah mengevaluasi keamanan atau keandalan agen verifikator hanya berdasarkan kemampuannya menolak serangan. Wajibkan pengukuran berimbang ($BA_{ m norm}$) dengan menyertakan himpunan valid variants yang sengaja memvariasikan sintaksis kode dan representasi data.
2. Haramkan Hardcoded Allowlist Tanpa Spesifikasi Kontrak: Hindari membuat allowlist sempit untuk pemanggilan alat. Secara default, izinkan seluruh query pembacaan (read-only queries) dan hanya terapkan filter blokir mutlak pada tindakan yang memiliki efek samping mutasi destruktif.
3. Wajibkan Verifikasi Nilai Default Opsional: Setiap kali memverifikasi pemanggilan fungsi atau schema JSON, parser wajib menyuntikkan nilai default resmi sebelum membandingkan kecocokan argumen. Menganggap argumen opsional sebagai string kosong adalah sumber false rejection tertinggi pada tugas tool-call.
4. Terapkan Protokol Anti-Confirmatory Self-Testing: Dalam loop sintesis kode verifier, sistem orchestrator tidak boleh mengizinkan agen menyerahkan verifier jika agen hanya menguji satu varian solusi yang ditulisnya sendiri. Harness wajib menyediakan minimal 3 varian solusi berbeda dari seed yang beragam sebelum verifikator dinyatakan layak pakai (deployable).