Agen pendukung menjawab permintaan pengguna untuk menyetel ulang autentikasi dua faktor dengan langkah-langkah yang sebenarnya tidak ada. Responsnya tampak meyakinkan, permintaan HTTP mengembalikan 200 OK, latensi normal, dan setiap grafik pemantauan tetap berwarna hijau.

Agen pendukung berbasis AI mengalami halusinasi jawaban karena pemeriksaan internal yang seharusnya mendeteksi kesalahan tersebut tidak pernah berjalan. Dasbor yang diandalkan oleh para insinyur melaporkan proses yang sempurna, sementara agen tersebut secara diam-diam mengarang solusi.

Mengapa dasbor tradisional melewatkan halusinasi AI

Sebagian besar tumpukan observabilitas (observability stacks) memperlakukan agen AI seperti mikroservis lainnya: satu permintaan masuk (inbound request) dan satu respons keluar (outbound response). Mereka mencatat status HTTP, waktu respons, dan jumlah kesalahan. Mereka tidak mencatat langkah-langkah tersembunyi di dalam permintaan tersebut – pengambilan dokumen eksternal, pemanggilan model bahasa besar (large language models), penggunaan alat bantu, dan logika guard-rail apa pun yang memvalidasi output.

Ketika langkah pengambilan (retrieval) mengembalikan hasil kosong, model sering kali "mengisi celah" tersebut dengan teks yang terdengar masuk akal. Dari sudut pandang sistem pemantauan, panggilan tersebut berhasil karena tidak ada yang rusak (crash) dan kode status tetap 200. Halusinasi tersebut tetap tidak terlihat, dan satu-satunya gejala adalah jawaban yang salah sampai ke pengguna.

Mengubah kotak hitam menjadi pohon yang dapat dibaca

Langkah pertama untuk debugging yang andal adalah berhenti memperlakukan agen sebagai panggilan monolitik dan mulai memvisualisasikan setiap operasi internal sebagai baris tersendiri dalam tabel jejak (trace table). Proses yang umum biasanya terbagi menjadi:

  • Pemanggilan agen tingkat atas
  • Langkah pengambilan (retrieval) yang menarik dokumentasi yang relevan
  • Setiap inferensi model bahasa yang memproses data yang diambil
  • Setiap pemanggilan alat (misalnya, pencarian database, permintaan API)
  • Pemeriksaan guard-rail yang menegakkan faktualitas atau kepatuhan kebijakan

Setiap baris mencatat stempel waktu (timestamp), flag keberhasilan, dan payload yang bergerak melalui langkah tersebut. Dengan struktur ini, eksekusi menjadi sebuah pohon yang dapat diperiksa baris demi baris, alih-alih hanya menebak-nebak dari output akhirnya.

Bug yang lolos

Dalam interaksi pendukung yang salah tersebut, jejaknya (trace) terlihat seperti ini:

  1. Retrieval berjalan tetapi tidak mengembalikan dokumen apa pun.
  2. Langkah berikutnya tetap berlanjut meskipun demikian, dengan mengirimkan konteks kosong ke model.
  3. Model menghasilkan jawaban yang mengisi informasi yang hilang dengan langkah-langkah buatan.
  4. Sistem mengembalikan 200 karena pipeline tidak menemui pengecualian (exception).

Halusinasi tersebut bukanlah cacat pada model bahasa itu sendiri; melainkan kurangnya guard-rail antara tahap pengambilan (retrieval) dan tahap pembuatan (generation). Agen tetap menjawab meskipun tidak memiliki dasar untuk mendasarkan responsnya.

Guard-rail sederhana yang menghentikan halusinasi

Dua perubahan konkret berhasil menghilangkan masalah tersebut:

  • Batalkan jika pengambilan kosong – jika penyimpanan dokumen tidak mengembalikan apa pun, agen harus membalas dengan "Saya tidak dapat menemukan informasi yang Anda butuhkan" alih-alih melanjutkan ke tahap pembuatan.
  • Pemeriksaan grounding – setelah model menghasilkan respons, verifikasi bahwa setiap klaim faktual muncul dalam konten yang diambil. Jika pemeriksaan gagal, tolak jawaban tersebut dan beralih ke respons "tidak dapat menjawab".

Alur kerja praktis untuk debugging yang lebih cepat

  1. Lacak setiap panggilan internal – berikan instrumen pada agen sehingga setiap pengambilan, inferensi model, dan penggunaan alat menuliskan satu baris ke log yang persisten.
  2. Simpan proses yang gagal – simpan jejak lengkap dari interaksi apa pun yang dilaporkan salah oleh pengguna. Menghapusnya untuk menghemat penyimpanan akan menyembunyikan data yang diperlukan untuk menemukan regresi.
  3. Beri tag pada proses dengan informasi versi – sertakan pengenal rilis dan status feature-flag apa pun dalam setiap baris jejak. Ini memungkinkan Anda mengorelasikan bug baru dengan perubahan kode terbaru.
  4. Nilai kualitas, bukan hanya kecepatan – tambahkan metrik yang mengukur seberapa baik jawaban mengikuti instruksi dan tetap berdasar (grounded) pada konten yang diambil. Throughput yang tinggi tidak berarti banyak jika jawabannya salah.
  5. Tinjau kegagalan setiap hari – tinjauan rutin yang singkat terhadap kegagalan yang tersimpan sering kali mengungkap pola (misalnya, jenis kueri tertentu secara konsisten mengembalikan pengambilan kosong) sebelum berdampak pada banyak pengguna.

Dengan mengubah status "hijau" menjadi "terverifikasi", tim dapat mendeteksi halusinasi lebih awal dan menjaga pengalaman pengguna agar tetap tepercaya.

Biaya dari mengabaikan kegagalan internal

Ketika dasbor hanya melaporkan keberhasilan pada lapisan HTTP, organisasi menerapkan agen yang tampak andal tetapi secara rutin memberikan panduan yang salah.

Apa yang harus diperhatikan selanjutnya

Sampai hal-hal tersebut menjadi lumrah, pendekatan paling aman adalah memperlakukan setiap operasi internal sebagai sesuatu yang dapat diamati dan segera melakukan fail fast saat bukti tidak ditemukan.

Poin Penting: Dasbor berwarna hijau memberi tahu Anda bahwa sistem dasarnya berfungsi; hal itu tidak menjamin bahwa jawabannya benar. Dengan menelusuri setiap retrieval, panggilan model, dan pemeriksaan guard-rail, Anda mengubah halusinasi yang tersembunyi menjadi kegagalan yang terlihat yang dapat diperbaiki sebelum sampai ke pengguna.