Runner Verifikasi Golden File: Agen Dilarang Jadi Hakim Sendiri
Skor 70/0/0 bikin saya yakin pipeline agen sudah deterministik. Ternyata temperature 0 pun nggak menjamin apa-apa; satu-satunya saksi cuma diff golden.
Ringkasan
Awalnya sempat senyum karena skor 70/0/0, kira pipeline udah deterministik padahal nggak. Skor itu cuma bukti runner verifikasinya bekerja, soalnya temp 0 pun model masih bisa ngeluarin output beda gara-gara batch invariance. Jadi verdict mesti diambil dari diff artefak lawan golden file, bukan dari omongan si agen.
Tadi pagi saya buka dua berkas transcript acceptance test, runner-b4a-1.txt dan runner-b4a-2.txt. Di baris awal ada catatan {"error": "copy-mismatch", "attempts": 3}, lalu deretan PASS R1 sampai R70. Skor akhirnya 70/0/0: tujuh puluh lulus, nol gagal, nol skip. Tebakan pertama saya optimis banget: pipeline agen saya ternyata sudah deterministik, tugas ini kelar. Ternyata saya salah besar.
Skor sempurna itu bukan bukti pipeline saya konsisten. Itu bukti bahwa runner verifikasinya bekerja dengan cara yang benar: membandingkan artefak yang dirakit ulang di sisi kernel, bukan percaya laporan sukses dari agen itu sendiri. Dua hal yang kelihatan mirip, dampaknya jauh berbeda.
Ilusi deterministik di suhu nol
Kebiasaan yang umum: set temperature 0, output dianggap identik setiap jalan. Di tempat lain mungkin iya, tapi untuk model bahasa, fakta di lapangan membatalkan asumsi itu. Tim Thinking Machines mencoba membuat 1000 completion di temperature 0 dengan prompt yang sama, dan yang muncul 80 versi berbeda [6]. Semuanya identik sampai token ke-102, lalu bercabang persis di situ. Akar masalahnya bukan sampling, tapi batch invariance: server menggabungkan request ke batch yang ukurannya berubah-ubah mengikuti beban, dan kernel tidak menjamin hasil sama untuk posisi berbeda dalam batch.
Temuan serupa datang dari peneliti di lembaga keamanan AI Jepang. Mereka menguji harness evaluasi yang memakai LLM sebagai juri, dan temperature nol cuma mengurangi, bukan menghapus, flip lulus-gagal: dari 690 panggilan API, 1 sampai 2 dari 7 kasus borderline tetap tidak bisa direproduksi [7]. Ada dua jebakan tambahan yang mereka catat. Harness yang lupa set temperature bikin provider diam-diam pakai default 1.0. Dan di generasi model terbaru, parameter temperature itu sendiri sudah dihapus, jadi mitigasi lama tinggal sejarah.
Waktu itu saya simpulkan sendiri: kalau begitu, jangan pernah suruh agen menilai pekerjaannya sendiri. Verdict harus datang dari sesuatu yang tidak bisa dia bicarakan.
Mekanisme yang membuat skor itu bisa dipercaya
Lalu apa yang bikin 70/0/0 tadi layak dipercaya? Dua pilar: isolasi, dan pembanding eksternal.
Isolasi soal memastikan tiap uji dapat ruang bersih. Pola bakunya mirip fixture tmp_path di pytest: setiap fungsi uji dapat direktori sementara yang unik [1], jadi tidak ada state bocor antar uji. Saya pernah kena mundur karena cache uji dari run sebelumnya masih nanggung di direktori yang sama; sejak itu isolasi saya anggap syarat, bukan bonus.
Pembanding eksternalnya bahkan lebih kasar: git diff --no-index, yang membandingkan dua berkas di disk tanpa perlu repo [4]. Tidak ada model yang ditanya pendapatnya. PASS atau FAIL murni hasil perbandingan byte terhadap berkas golden yang di-commit. Kalau golden-nya belum ada, uji langsung gagal, bukan sekadar dicatat sebagai perbedaan; prinsip yang sama dipakai pustaka snapshot Syrupy [5]. Pembaruan golden juga tidak pernah otomatis: harus lewat flag eksplisit, supaya setiap perubahan "jawaban benar" kelihatan di review.
Di transcript tadi, pola ini kelihatan di pemeriksaan oracle-nya. R36 memvalidasi chunking: 4 chunk, 2 chunk tabel ikut membawa ulang header barisnya. R40 mengecek penggabungan paragraf tetap verbatim. R40b memastikan permintaan embedding dikirim dengan awalan yang benar. Semuanya artefak deterministik yang bisa dibedakan mentah-mentah, dirakit ulang dari state kernel, bukan dari memori agen.
Prinsip yang sama ditegaskan di dunia evaluasi model. OpenAI menyebut evaluasi berkualitas sebagai salah satu hal paling berdampak untuk pembangun LLM [2], dan resepnya selalu dua komponen: skema data uji di satu sisi, grader di sisi satunya [3]. Intinya bukan potongan komponennya, tapi pemisahannya: yang menentukan lulus atau tidak adalah data dan kriteria yang beku sebelum uji jalan, bukan opini model sesudahnya.
Baris copy-mismatch di awal transcript tadi jadi pengingat yang pas. Cuma menyalin keluaran dari satu tahap ke tahap berikutnya, itu saja sempat meleset tiga kali sebelum berhasil. Penyalinan mentah saja bisa gagal diam-diam, apalagi klaim "semua lulus" tanpa bukti diff di belakangnya.
Satu hal yang saya pegang dari pengalaman ini: biarkan diff berkas yang bicara. Kalau verdict-nya bisa dihasilkan ulang dari artefak, hasil itu berarti. Kalau cuma bisa diucapkan model, itu belum lulus apa-apa.