Menguji Fitur AI yang Tak Punya Jawaban Tunggal

Pengujian dengan perbandingan teks persis membutuhkan satu jawaban acuan. Model bahasa dapat menghasilkan beberapa parafrasa yang sama-sama benar. Uji perilaku aplikasi yang hasilnya pasti, lalu nilai kualitas jawaban memakai kumpulan kasus yang diberi skor. Simpan hasil acuan dan ambang kelulusan agar perubahan model atau instruksi dapat diperiksa melalui CI, proses pemeriksaan otomatis sebelum kode digabungkan.

Kumpulan kasus itu disebut eval set, dan proses penilaiannya disebut eval. Artikel ini membahas susunan pengujian yang saya gunakan pada produk nyata.

Mengapa perbandingan teks persis tidak cukup?

“Kode 10750 cocok, lihat halaman 768” dan “Halaman 768 menunjuk ke 10750” dapat menyampaikan jawaban yang sama. Pemeriksaan kesamaan teks menolak salah satunya. Sebaliknya, pemeriksaan yang hanya mencari angka 10750 dapat menerima jawaban dengan alasan yang salah.

Nilai temperature 0 juga tidak menjamin keluaran selalu identik. Permintaan ke nama model yang sama dapat diproses oleh revisi atau susunan penyajian berbeda. Pengujian yang mengasumsikan kalimat tetap kemudian dapat gagal tanpa perubahan kualitas yang berarti.

Kesalahan lain lebih sulit terlihat: jawaban rapi, format benar, tetapi isinya salah. Pada Mei 2024, Stanford RegLab menguji 202 pertanyaan hukum melalui protokol yang didaftarkan sebelumnya. Lexis+ AI salah atau salah merujuk pada lebih dari 17% pertanyaan, sedangkan Westlaw AI-Assisted Research sekitar 33%. Angka 58–82% pada chatbot umum berasal dari penelitian terdahulu yang dirangkum dalam PDF Stanford, bukan perbandingan langsung pada seluruh kumpulan pertanyaan yang sama.

Salah merujuk berarti jawaban memiliki sitasi, tetapi sumbernya tidak mendukung klaim tersebut. Memastikan sitasi ada dan dokumennya ditemukan belum memeriksa hubungan antara klaim dan sumber. Teknik pencarian dokumen sebelum menjawab, atau retrieval, membantu menyediakan konteks tanpa menjamin semua jawaban benar.

Perilaku apa yang dapat diuji secara deterministik?

Pisahkan model dari lapisan aplikasi yang memiliki aturan pasti. Pengujian lapisan itu dapat berjalan cepat tanpa memanggil model berbayar.

Bentuk keluaran. Pastikan JSON dapat diuraikan, sesuai skema, dan memiliki kolom wajib.

Penanda pemanggilan alat tidak bocor ke pengguna. Sebagian model menulis pemanggilan alat sebagai teks biasa, daripada melalui kolom terstruktur API. Dalam satu sistem, model menjawab bahwa daftar akan disusun, lalu mencetak penanda internal ke percakapan. Tiga pemeriksaan melindungi jalur ini: pemanggilan yang bocor dapat dipulihkan beserta argumennya; penandanya dibersihkan; dan jawaban normal lewat tanpa perubahan satu byte pun.

Setiap sitasi menunjuk dokumen yang ada. Periksa bahwa semua ID sumber dalam jawaban termasuk dalam korpus. Pemeriksaan ini tidak memerlukan model, tetapi juga tidak membuktikan sumber mendukung klaim.

Mutu pencarian dokumen. Gunakan akurasi peringkat pertama, recall@10, dan mean reciprocal rank (MRR). Tulis kasus acuan berbentuk {query, primary, topN, mustNotInclude}. Daftar mustNotInclude membantu menangkap hasil yang tampak masuk akal tetapi salah: pertanyaan produksi makanan, misalnya, justru menampilkan kode industri mesin pengolahan makanan.

Dalam satu asisten klasifikasi katalog kode usaha publik, 110 kasus pencarian menghasilkan recall@10 1,0 dan MRR 1,0 tanpa pelanggaran daftar larangan. Pengujian itu kemudian mendeteksi aturan skor yang menurunkan kode yang benar. Hasil sempurna pada 110 kasus tersebut tidak membuktikan semua pertanyaan baru akan benar.

Pembatasan aplikasi. Uji batas permintaan, penolakan di luar cakupan, dan penyamaran data pribadi pada jalur yang memiliki aturan pasti. Keputusan berbasis model tetap membutuhkan penilaian tambahan.

Bagaimana menyusun kumpulan kasus yang berguna?

Mulai dengan kasus yang dikurasi berdasarkan kegagalan sistem Anda. Tiga puluh kasus yang relevan dapat lebih berguna daripada tiga ribu contoh sintetis yang tidak menguji risiko sebenarnya. Contoh sintetis tetap dapat menambah cakupan setelah diperiksa.

Setiap kasus memuat pertanyaan, jawaban yang diharapkan, toleransi peringkat, dan jawaban yang dilarang muncul. Uji juga cakupan kumpulannya: misalnya, tiga puluh kasus harus mencakup setidaknya sepuluh kategori. Aturan ini membantu mencegah pengujian hanya mengikuti masalah terakhir yang sedang diperbaiki tim.

Buat kumpulan terpisah untuk pertanyaan yang informasinya belum cukup. Pada sistem tadi, delapan masukan mencakup “saya mau buka usaha”, “bisnis yang paling menguntungkan apa”, pertanyaan pinjaman bank, dan sapaan tanpa konteks. Ukur false confidence rate: frekuensi jawaban pasti ketika sistem seharusnya mengakui kekurangan informasi. Targetnya nol. Hasil acuan pada delapan kasus itu adalah nol jawaban yakin yang tidak berdasar; 37,5% masukan memicu penanda untuk menahan rekomendasi (abstention) pada logika penilaian. Angka ini bukan hasil pengukuran respons klarifikasi dari model.

Kalai dan Nachum berargumen pada September 2025 bahwa penilaian benar atau salah dapat memberi keuntungan pada model yang selalu menebak. Terapkan pelajarannya pada produk: beri penalti lebih besar untuk kesalahan yang disampaikan dengan yakin daripada pengakuan bahwa informasi belum cukup. Mekanisme penolakannya dibahas dalam pembatasan halusinasi LLM.

Mengapa skor sempurna dapat menyesatkan?

Perhatikan penyebut metrik. Jika misgrounding rate didefinisikan sebagai klaim tanpa dukungan dibagi klaim bersitasi, jawaban yang menolak membuat klaim tidak menambah penyebut. Kumpulan pertanyaan sulit dapat menghasilkan banyak penolakan dan skor yang dihitung dari hanya satu klaim.

Pada contoh ini, dua belas kasus sulit dipertahankan untuk menguji respons terhadap ambiguitas. Delapan kasus ringan ditambahkan: pertanyaan satu topik dengan jawaban yang menunjuk satu catatan bersumber lengkap, diperiksa langsung terhadap korpus. Kasus ringan memberi jawaban yang cukup jelas untuk dinilai.

Hasil setelah penyeimbangan: 29 klaim bersitasi, 1 tanpa dukungan, dan 3 dengan dukungan sebagian. Berkas hasil acuan mencatat misgrounding rate 0,045. Logika penilaian memakai 29 klaim bersitasi dikurangi 7 penanda penolakan sebagai penyebut: 1/22, dibulatkan menjadi 0,045. Rasio mentah 1/29 sekitar 0,0345 memakai penyebut berbeda dan tidak boleh disebut sebagai nilai yang tersimpan. Penyebut khusus ini juga mencampurkan jumlah klaim dan penanda penolakan per jawaban; tinjau definisinya sebelum membandingkan sistem lain. Laporkan tiga klaim dengan dukungan sebagian secara terpisah. Tingkat penolakan menjawab (abstention rate) adalah 0,35.

Laporkan jumlah klaim dan kasus bersama nilainya. Penyebut yang terlalu kecil membuat skor sulit ditafsirkan.

Kapan membutuhkan penilai AI?

Gunakan model penilai untuk memeriksa hubungan yang sulit diuji dengan perbandingan sederhana, seperti apakah sebuah klaim didukung oleh kutipan yang dirujuk. Jawaban acuan tidak diperlukan untuk setiap kalimat, tetapi bukti sumber tetap diperlukan.

Model penilai juga dapat keliru. Pracetak yang diajukan pada 17 Juni 2026 menguji 21 model dari sembilan penyedia pada tiga tolok ukur, dengan sekitar 541.000 penilaian. Pada MT-Bench, Cohen's kappa, ukuran kesepakatan yang memperhitungkan kebetulan, berada 33–41 poin persentase di bawah kesepakatan mentah. Dua model yang dipakai dalam produksi menunjukkan bias posisi yang kuat. Bias panjang jawaban kecil, di bawah 0,011, dalam rubrik perbandingan berpasangan penelitian tersebut. Peringkat penilai bergeser hingga 14 posisi antar-tolok ukur.

Praktik yang dapat diterapkan:

• Nilai satu klaim per panggilan. Cara ini menghindari pilihan antara jawaban pertama dan kedua, meskipun tidak menghapus semua bias.
• Minta kutipan persis. Penilai harus mengembalikan bagian sumber yang mendukung klaim atau menandainya tanpa dukungan. Periksa bahwa kutipan itu benar-benar ada.
• Gunakan sedikit label. Misalnya: didukung, didukung sebagian, tanpa dukungan, dan tidak ada bukti. Kalibrasikan arti setiap label sebelum mengandalkannya.
• Bandingkan dengan penilaian manusia. Beri label manual pada tiga puluh contoh, ukur kesepakatannya, dan ulangi ketika model penilai berubah.

Perhitungkan biaya: satu panggilan menghasilkan jawaban, kemudian satu panggilan per klaim menilainya. Sediakan mode --dry dengan model tiruan untuk memeriksa sambungan tanpa layanan berbayar, serta --limit N untuk membatasi percobaan berbayar.

Jadikan hasil penilaian syarat kelulusan CI

Simpan hasil acuan dalam JSON: waktu pembuatan, jumlah kasus, metrik, dan ambang kelulusan. Menempatkan ambang di sebelah metrik membuat perubahan kebijakan terlihat saat perbedaan kode ditinjau.

{
  "generatedAt": "2026-06-24T07:04:51.345Z",
  "caseCount": 20,
  "metrics": { "misgroundingRate": 0.045, "unsupported": 1, "abstentionRate": 0.35 },
  "thresholds": { "misgroundingRate": 0.05, "maxFailedRows": 0 }
}

Jalankan pengujian deterministik pada setiap perubahan kode. Jalankan pengujian dengan penilai sesuai jadwal dan saat instruksi model berubah. Opsi --gate mengembalikan status bukan nol ketika ambang tidak terpenuhi, sehingga CI dapat menolak perubahan.

Kelola instruksi model, atau prompt, seperti kode: beri versi, tinjau perubahan, dan ulangi penilaian sebelum penggabungan. Simpan hasil per kasus selain angka agregat. Ketika nilai berubah dari 0,045 ke 0,12, hasil terperinci menunjukkan pertanyaan, klaim, dan kutipan yang bermasalah.

Susunan minimum yang dapat dicoba

1. Pemeriksaan skema dan pembatasan aplikasi pada pengujian biasa.
2. Pemeriksaan khusus untuk cacat format yang pernah terjadi, termasuk penanda alat yang bocor.
3. Dua puluh sampai tiga puluh kasus acuan dengan mustNotInclude dan pemeriksaan cakupan.
4. Kumpulan kasus penolakan terpisah dengan target nol jawaban yakin yang tidak berdasar.
5. Penilai klaim bersitasi, satu klaim per panggilan, dengan --dry dan --limit.
6. Hasil acuan serta ambang yang disimpan dalam repositori, diperiksa CI, dan dilengkapi hasil per kasus.

Pengujian deterministik dapat memeriksa format, validitas ID sumber, dan pembatasan aplikasi. Itu tidak membuktikan semua jawaban benar atau bahwa model tidak pernah menebak. Ukur kesalahan pada kasus yang dipilih, lalu pantau pemakaian nyata. Jika lapisan pencarian masih dirancang, mulai dari RAG untuk data bisnis.

Apa yang perlu diminta sebelum menerima fitur AI?

Siapkan contoh pertanyaan pelanggan, termasuk pertanyaan ambigu dan yang tidak punya jawaban. Sepakati mana yang harus benar, kapan AI perlu bertanya, dan kapan harus mengalihkan ke manusia. Minta hasil per kasus sebelum dan sesudah perubahan model; satu skor rata-rata bisa menyembunyikan kesalahan yang mahal.