Knowledge assistant perusahaan tidak selalu harus memberi jawaban. Ketika dokumen tidak mendukung kesimpulan, respons yang berguna bisa berupa penjelasan bahwa bukti belum cukup, pertanyaan klarifikasi, atau eskalasi kepada pemilik kebijakan. Evaluasi abstention RAG membantu menguji keputusan tersebut: kapan sistem seharusnya menjawab dan kapan harus menahan jawaban.
Panduan ini ditujukan kepada AI product owner, knowledge owner, dan tim evaluasi. Fokusnya adalah mutu keputusan menjawab, bukan pemilihan model atau pengaturan akses dokumen secara umum. Ukuran serta tahapan yang dibahas merupakan rekomendasi desain evaluasi; tidak ada angka akurasi yang diklaim sebagai hasil Layana.
Arti Abstention dalam Knowledge Assistant
Abstention berarti sistem tidak memberikan kesimpulan substantif karena syarat untuk menjawab belum terpenuhi. Alasannya dapat berupa sumber yang tidak tersedia, bukti bertentangan, pertanyaan yang ambigu, atau kewenangan pengguna yang tidak mencukupi. Responsnya perlu menjelaskan batas tersebut secara proporsional dan memberi langkah lanjut yang aman, tanpa membocorkan isi sumber yang tidak boleh dilihat.
Bedakan abstention dari kegagalan teknis. Konektor yang sedang tidak tersedia bukan bukti bahwa kebijakan tidak ada. Jawaban “tidak ditemukan dalam sumber yang dapat diperiksa saat ini” berbeda makna dari “perusahaan tidak memiliki kebijakan”. Evaluasi perlu mempertahankan perbedaan ini agar pengguna mengetahui apakah perlu memperjelas pertanyaan, menunggu pemulihan, atau menghubungi pemilik dokumen.
Bangun Empat Kelompok Kasus Evaluasi
Pertanyaan yang Dapat Dijawab
Siapkan pertanyaan dengan bukti yang cukup, masih berlaku, dan dapat diakses oleh pengguna uji. Catat jawaban yang dapat diterima serta bagian dokumen pendukungnya. Tujuannya menguji apakah sistem benar-benar menjawab saat seharusnya membantu. Sistem yang selalu menolak akan tampak berhati-hati, tetapi tidak berguna bagi proses bisnis.
Pertanyaan yang Belum Memiliki Bukti
Gunakan pertanyaan yang wajar namun jawabannya tidak tersedia dalam cakupan sumber. Contohnya, dokumen hanya memuat prosedur pengajuan perjalanan, sedangkan pengguna menanyakan batas biaya suatu kategori yang belum ditetapkan di dokumen tersebut. Keluaran yang diharapkan adalah penahanan kesimpulan dan rute klarifikasi, bukan angka yang diturunkan dari kebiasaan industri.
Pertanyaan Ambigu atau Bersumber Konflik
Sertakan dua kebijakan dengan periode berlaku berbeda, ketentuan yang membedakan jenis unit, serta pertanyaan yang tidak menyebut lokasi atau tanggal. Tetapkan kapan klarifikasi lebih tepat daripada penolakan penuh. Jika aturan lama dan baru sama-sama terambil, sistem harus membuktikan versi mana yang relevan atau meminta konteks tambahan.
Pertanyaan di Luar Hak Akses
Uji dengan pengguna yang memang tidak boleh melihat sumber tertentu. Label evaluasi tidak boleh mendorong model menjawab hanya karena evaluator mengetahui dokumennya ada. Pastikan respons tidak mengungkap judul atau rincian sensitif yang semestinya tersembunyi. Topik hak akses lebih luas dibahas dalam evaluasi RAG dan hak akses dokumen; di sini fokusnya adalah perilaku keluaran saat bukti yang sah tidak cukup.
Gunakan Matriks Keputusan yang Transparan
Untuk setiap kasus, catat apakah pertanyaan dapat dijawab dari bukti sah dan apakah sistem memilih menjawab. Dari dua keputusan itu muncul empat hasil: jawaban benar pada kasus yang layak dijawab, abstention benar pada kasus tanpa bukti cukup, jawaban yang seharusnya ditahan, serta penolakan yang sebenarnya tidak perlu. Nilai jawaban tetap diperiksa; keputusan menjawab yang tepat tidak membuktikan isi jawaban benar.
- Jawaban tanpa dukungan: jumlah kasus tidak layak dijawab yang tetap memperoleh kesimpulan substantif, dibagi seluruh kasus tidak layak dijawab.
- Penolakan berlebihan: jumlah kasus layak dijawab yang ditahan, dibagi seluruh kasus layak dijawab.
- Ketepatan rujukan: proporsi pernyataan material yang didukung sumber relevan dan dapat dibuka oleh pengguna terkait.
- Mutu eskalasi: apakah respons menyebut informasi yang kurang serta tujuan klarifikasi yang benar, tanpa menambah janji palsu.
Jika penyebut suatu ukuran nol, hasilnya belum dapat dihitung, bukan nol kesalahan. Laporkan jumlah kasus pada setiap kelompok. Hindari menggabungkan semuanya ke satu skor yang membuat kegagalan berisiko tinggi tertutup oleh banyak pertanyaan mudah. Ambang penerimaan perlu ditetapkan pemilik proses berdasarkan dampak salah jawab dan beban penolakan.
Skenario Ilustratif: Dokumen Ada, Jawaban Belum Tentu Ada
Bayangkan knowledge assistant internal menerima pertanyaan tentang izin suatu pengeluaran. Dokumen yang terambil menjelaskan alur persetujuan, tetapi tidak menyebut batas nominal atau kategori pengeluaran tersebut. Ini ilustrasi, bukan kasus pelanggan Layana. Jawaban yang menyebut angka akan melampaui bukti, walaupun rujukan dokumennya asli.
Respons yang diuji dapat menjelaskan prosedur yang memang tertulis, menahan kesimpulan tentang batas biaya, dan meminta klarifikasi kepada pemilik kebijakan. Evaluator menilai setiap bagian secara terpisah. Dengan demikian, sistem tetap membantu tanpa mengubah informasi prosedural menjadi izin keuangan. Tidak semua kekurangan bukti memerlukan penolakan total terhadap seluruh pertanyaan.
Jangan Menjadikan Confidence Model sebagai Satu-satunya Gerbang
Angka keyakinan yang ditulis model bukan bukti bahwa sumbernya cukup. Tetapkan pemeriksaan lain: keberadaan sumber yang sah, kesesuaian bagian dokumen dengan pertanyaan, status versi, serta apakah kesimpulan melampaui teks. Jika model diminta menilai kecukupan sendiri, uji keputusan itu terhadap label manusia pada data terpisah; jangan menganggapnya otomatis terkalibrasi.
Pisahkan data untuk menyusun petunjuk dan data untuk menilai hasil akhir. Knowledge owner membuat label awal, reviewer kedua menyelesaikan perbedaan yang material, dan tim evaluasi menyimpan alasan keputusan. Ini rekomendasi proses evaluasi, bukan jaminan bahwa kesepakatan reviewer selalu sempurna. Simpan kasus yang belum dapat direkonsiliasi sebagai ketidakpastian yang terlihat.
Tahapan Pilot dan Monitoring Setelah Rilis
Mulai dengan satu kelompok dokumen dan jenis pengguna yang jelas. Kunci versi corpus, prompt, konfigurasi retrieval, serta model yang dipakai selama evaluasi. Jalankan kasus biasa dan kasus batas, lalu review kegagalan. Setelah perbaikan, gunakan sampel lain untuk memastikan sistem tidak sekadar menyesuaikan diri pada daftar pertanyaan latihan.
Ketika penggunaan terbatas dimulai, pantau eskalasi berulang dan penolakan yang ternyata dapat diselesaikan dengan dokumen sah. Perubahan corpus dapat mengubah keputusan abstention meski model tetap sama. Kaitkan review dengan pengelolaan pembaruan knowledge base. Jangan menyalin seluruh percakapan sensitif ke log evaluasi tanpa kebutuhan serta aturan retensi yang disetujui.
NIST AI Risk Management Framework menyediakan rujukan umum pengelolaan risiko AI. Kerangka tersebut bukan sertifikasi atas knowledge assistant. Perusahaan tetap perlu menentukan penanggung jawab, skenario kegagalan yang tidak dapat diterima, serta cara menghentikan atau membatasi layanan jika jawaban tanpa dukungan berulang terjadi.
Siapkan Sampel untuk Evaluasi Abstention RAG
Bawa contoh pertanyaan yang seharusnya dijawab, ditahan, atau diklarifikasi, berikut dokumen sah dan alasan keputusan. Melalui layanan AI dan machine learning Layana, kebutuhan knowledge assistant dapat dibahas bersama rancangan evaluasinya. Diskusikan pemetaan use case dan batas pilot agar mutu penolakan maupun jawaban diuji sebelum penggunaan lebih luas.
Featured image merupakan ilustrasi konseptual pemeriksaan kecukupan sumber, bukan dokumentasi pelanggan atau hasil evaluasi.