Cara Mengurangi Hallucination pada LLM: RAG hingga Verifikasi

Large Language Model atau LLM dapat menghasilkan jawaban yang lancar, terstruktur, dan terlihat meyakinkan. Namun, kelancaran bahasa tidak selalu menunjukkan bahwa informasi tersebut benar.

Model dapat memberikan angka, sitasi, penjelasan, atau kode yang tampak masuk akal meskipun tidak didukung fakta. Kondisi ini disebut hallucination atau halusinasi AI.

Masalah tersebut perlu diperhatikan ketika LLM digunakan untuk riset, chatbot pelanggan, pembuatan konten, coding, pencarian dokumen, dan aplikasi yang terhubung dengan API. Kesalahan yang tidak terdeteksi dapat diteruskan kepada pengguna atau sistem lain.

Sebelum membahasnya lebih jauh, kamu dapat mempelajari terlebih dahulu konsep kecerdasan buatan atau artificial intelligence.

Apa Itu Hallucination pada LLM?

Hallucination pada LLM adalah respons yang terlihat masuk akal, tetapi salah atau tidak memiliki dasar yang dapat diverifikasi.

OpenAI mendefinisikan hallucination sebagai pernyataan yang terdengar masuk akal, tetapi sebenarnya salah. Masalah ini masih menjadi salah satu tantangan mendasar pada model bahasa modern.

Hallucination tidak selalu berbentuk informasi yang sepenuhnya fiktif. Model juga dapat mencampurkan fakta benar dengan detail tambahan yang tidak didukung sumber.

Sebagai contoh, sebuah dokumen hanya menyatakan bahwa layanan memiliki backup otomatis. Namun, model menambahkan bahwa backup disimpan selama 30 hari, padahal dokumen tidak mencantumkan masa retensi.

Secara umum, hallucination dapat berbentuk:

• Factual hallucination: nama, angka, tanggal, atau penjelasan tidak sesuai fakta.
• Citation hallucination: sumber, kutipan, jurnal, atau tautan tidak ada maupun tidak mendukung klaim.
• Grounding hallucination: jawaban tidak sesuai dengan dokumen atau konteks yang diberikan.
• Code hallucination: model membuat package, fungsi, parameter, atau hasil eksekusi yang sebenarnya tidak tersedia.

Mengapa Hallucination Menjadi Masalah?

Masalah utamanya bukan hanya karena LLM dapat salah. Kesalahan tersebut sering disampaikan menggunakan struktur yang rapi dan bahasa yang meyakinkan.

Pengguna yang tidak memahami topik secara mendalam mungkin kesulitan membedakan informasi valid dengan detail yang dibuat oleh model.

Risikonya meningkat ketika output LLM digunakan untuk:

• Menerbitkan artikel atau laporan.
• Memberikan informasi produk dan kebijakan.
• Menentukan tindakan medis, hukum, atau keuangan.
• Menulis dan menjalankan kode.
• Mengirim data ke API atau sistem otomatis lainnya.

Satu jawaban salah juga dapat menyebar ke proses berikutnya. Misalnya, chatbot mengambil harga yang keliru, sistem menghitung diskon berdasarkan harga tersebut, lalu aplikasi mengirim penawaran yang salah kepada pelanggan.

Contoh Masalah Hallucination dalam Penggunaan Nyata

1. Referensi Ilmiah yang Dibuat-buat

Penelitian dalam Scientific Reports meminta GPT-3.5 dan GPT-4 menghasilkan 84 tulisan dengan total 636 referensi.

Hasilnya, 55% referensi dari GPT-3.5 tidak ditemukan atau dibuat-buat. Pada GPT-4, proporsinya lebih rendah, tetapi masih mencapai 18%.

Di antara referensi yang benar-benar ada, 43% referensi GPT-3.5 dan 24% referensi GPT-4 mengandung kesalahan substantif. Kesalahan tersebut mencakup nama penulis, tahun, jurnal, volume, atau nomor halaman.

Output penelitian dikumpulkan pada April 2023. Karena itu, angka tersebut tidak dapat dianggap sebagai tingkat hallucination semua model yang tersedia saat ini.

Namun, temuan ini menunjukkan bahwa format referensi yang terlihat lengkap tidak membuktikan bahwa sumbernya benar. Penulis tetap perlu membuka publikasi asli dan memastikan isinya mendukung klaim yang dibuat.

2. Jawaban Medis yang Bermasalah atau Tidak Aman

Studi red-teaming dalam npj Digital Medicine mengevaluasi 888 respons dari empat chatbot terhadap 222 pertanyaan medis yang menyerupai pertanyaan pasien.

Sebanyak 16 dokter terlibat dalam proses evaluasi. Bergantung pada chatbot yang diuji, 21,6–43,2% respons dinilai bermasalah.

Persentase respons tidak aman berada pada rentang 5–13,5%. Masalah yang ditemukan meliputi informasi penting yang hilang, kegagalan menggali riwayat pasien, informasi keliru, dan saran yang berpotensi berbahaya.

Hasil tersebut tidak dapat digeneralisasi ke semua model dan seluruh pertanyaan medis. Respons dikumpulkan menggunakan model, waktu, dan konfigurasi tertentu.

Namun, penelitian ini memperlihatkan bahwa jawaban yang terlihat membantu tetap memerlukan pemeriksaan tenaga medis, terutama ketika dapat memengaruhi keselamatan pasien.

3. Package Pemrograman yang Sebenarnya Tidak Ada

Penelitian yang dipresentasikan pada USENIX Security 2025 menganalisis 576.000 sampel kode dari 16 LLM untuk Python dan JavaScript.

Rata-rata minimum package fiktif mencapai 5,2% pada model komersial dan 21,7% pada model open-source. Peneliti juga menemukan 205.474 nama package fiktif yang unik.

Masalah ini tidak hanya menyebabkan instalasi gagal. Apabila penyerang mendaftarkan package menggunakan nama yang sering dibuat oleh LLM, developer dapat tanpa sengaja memasang kode berbahaya.

Setiap dependensi hasil generasi AI perlu diperiksa melalui registry resmi. Kode juga harus melewati proses pengujian dan pemeriksaan keamanan sebelum digunakan pada lingkungan produksi.

Implementasi RAG, vector database, backend API, logging, dan proses evaluasi membutuhkan lingkungan server yang dapat dikonfigurasi. Pelajari bagaimana Cloud VPS mendukung aplikasi AI dan machine learning, lalu gunakan Cloud VPS DomaiNesia untuk menjalankan komponen aplikasi sesuai kebutuhan.

Infrastruktur server tidak menghilangkan hallucination secara langsung. Namun, server yang dapat dikontrol membantu tim membangun pipeline mitigasi, observabilitas, dan verifikasi yang lebih terstruktur.

Mengapa LLM Mengalami Hallucination?

1. LLM Memprediksi Token, Bukan Memeriksa Fakta

Pada tahap pretraining, model mempelajari pola bahasa dengan memprediksi token berikutnya dari kumpulan teks.

Proses tersebut tidak otomatis memberikan label benar atau salah pada setiap pernyataan. Model dapat mempelajari cara menyusun kalimat yang terdengar wajar tanpa memiliki mekanisme bawaan untuk memeriksa seluruh fakta di dalamnya.

OpenAI juga menjelaskan bahwa evaluasi yang hanya memberi nilai pada jawaban benar dapat mendorong model untuk menebak. Ketika jawaban “tidak tahu” selalu mendapat nilai nol, tebakan masih memiliki peluang memperoleh nilai.

Karena itu, model dan sistem evaluasinya perlu dirancang agar dapat menunjukkan ketidakpastian ketika bukti tidak mencukupi.

2. Pengetahuan atau Konteks Tidak Lengkap

Informasi dalam bobot model dapat terbatas, sudah berubah, atau berasal dari sumber yang saling bertentangan. Konteks yang diberikan pengguna juga mungkin tidak mencantumkan detail yang dibutuhkan.

Apabila model tetap diminta memberikan jawaban lengkap, kekosongan tersebut dapat diisi dengan asumsi.

Risiko ini sering muncul pada pertanyaan tentang:

• Harga dan paket layanan.
• Fitur produk.
• Regulasi terbaru.
• Versi perangkat lunak.
• Peristiwa atau data yang terus berubah.

3. Pertanyaan Terlalu Ambigu

Prompt yang tidak menjelaskan produk, versi, periode, tujuan, atau sumber rujukan membuka ruang interpretasi terlalu luas.

Sebagai contoh, pertanyaan “Berapa batas maksimal penyimpanannya?” belum menjelaskan nama produk, paket, jenis penyimpanan, atau periode penggunaan.

Alih-alih meminta klarifikasi, model dapat memilih salah satu interpretasi dan menyampaikannya seolah-olah sebagai fakta.

4. Retrieval Mengambil Dokumen yang Tidak Tepat

Retrieval-Augmented Generation atau RAG membantu model mengambil informasi dari sumber eksternal. Namun, kualitas jawabannya tetap bergantung pada proses retrieval.

Dokumen yang ditemukan dapat:

• Tidak relevan.
• Sudah kedaluwarsa.
• Terpotong pada bagian penting.
• Berasal dari versi produk berbeda.
• Hanya memiliki istilah yang mirip.

RAGTruth mengumpulkan hampir 18.000 respons dari beragam LLM yang menggunakan RAG. Dataset tersebut menunjukkan bahwa model masih dapat menghasilkan klaim yang tidak didukung atau bertentangan dengan konteks yang ditemukan.

Cara Mengurangi Hallucination pada LLM

1. Tentukan Sumber Kebenaran

Tentukan sistem mana yang menjadi sumber resmi untuk setiap jenis informasi.

Harga, status layanan, stok, dan informasi akun sebaiknya diambil dari database sebagai sumber data utama atau API. Sementara itu, prosedur dapat berasal dari dokumentasi resmi yang sudah melalui proses persetujuan.

Jangan menjadikan pengetahuan internal model sebagai sumber utama untuk informasi yang sering berubah.

Apabila aplikasi menggunakan banyak layanan, API Gateway juga dapat digunakan untuk mengatur routing, autentikasi, pembatasan akses, serta monitoring permintaan API.

2. Batasi Jawaban melalui Prompt

Berikan aturan yang jelas agar model hanya menggunakan sumber yang disediakan.

Instruksikan model agar tidak menambahkan angka, nama, ketentuan, atau kesimpulan yang tidak tertulis dalam dokumen.

Contoh instruksi:

Jawab hanya berdasarkan dokumen yang diberikan. Jika informasi tidak tersedia, nyatakan bahwa data belum ditemukan. Jangan menambahkan asumsi, angka, nama, atau ketentuan yang tidak tercantum dalam sumber.

Prompt tersebut lebih spesifik daripada hanya meminta model “jangan melakukan hallucination”.

3. Izinkan Model Tidak Menjawab

Kemampuan menolak, menunjukkan ketidakpastian, atau meminta klarifikasi merupakan bagian penting dari mitigasi.

Anthropic merekomendasikan pemberian izin eksplisit kepada model untuk mengatakan tidak tahu. Dokumentasinya juga menyarankan penggunaan kutipan langsung untuk grounding serta pemeriksaan setiap klaim menggunakan sitasi pendukung.

Jika bukti tidak dapat ditemukan, klaim harus dihapus atau ditarik kembali.

4. Gunakan RAG secara Tepat

RAG menghubungkan LLM dengan knowledge base atau sumber eksternal. Model mengambil dokumen yang relevan sebelum menyusun jawaban sehingga tidak hanya bergantung pada pengetahuan parametriknya.

Dalam implementasi tertentu, vector database dapat digunakan untuk menyimpan embedding dan menjalankan pencarian semantik.

Namun, RAG bukan jaminan kebenaran. Tingkatkan kualitas retrieval melalui:

• Hybrid search yang menggabungkan pencarian semantik dan kata kunci.
• Filter metadata berdasarkan versi, tanggal, produk, atau kategori.
• Reranking dokumen.
• Versioning dokumen.
• Penghapusan sumber yang sudah tidak berlaku.
• Chunking yang mempertahankan judul dan konteks bagian.

5. Periksa Kecukupan Konteks

Sebelum menghasilkan jawaban, sistem perlu menilai apakah dokumen yang ditemukan benar-benar menjawab pertanyaan.

Jika konteks tidak cukup atau sumber saling bertentangan, sistem dapat:

• Melakukan pencarian ulang.
• Meminta informasi tambahan.
• Menampilkan perbedaan antar-sumber.
• Menolak memberikan jawaban pasti.

Google DeepMind mengembangkan FACTS Grounding untuk mengevaluasi apakah respons panjang benar-benar didukung oleh dokumen sekaligus cukup menjawab permintaan pengguna.

Benchmark tersebut memiliki 1.719 contoh dari domain teknologi, keuangan, retail, medis, dan hukum.

6. Wajibkan Sitasi dan Verifikasi Klaim

Setiap klaim penting perlu dihubungkan dengan bagian sumber tertentu.

Setelah respons dibuat, pecah jawaban menjadi klaim yang lebih kecil. Kemudian, periksa apakah setiap klaim memiliki bukti yang benar-benar mendukungnya.

Ketersediaan sitasi belum tentu membuktikan bahwa jawaban valid. Sistem tetap perlu memastikan bahwa:

• Sumber benar-benar ada.
• Isi sumber mendukung klaim.
• Sumber masih berlaku.
• Model tidak menambahkan kesimpulan di luar dokumen.
• Tautan mengarah ke sumber yang dimaksud.

7. Gunakan Validasi Deterministik

Informasi yang dapat diperiksa dengan perangkat lunak tidak perlu divalidasi oleh LLM saja.

Gunakan:

• Registry resmi untuk memeriksa package.
• Compiler dan unit test untuk kode.
• JSON Schema untuk memeriksa struktur data.
• Kalkulator atau fungsi program untuk perhitungan.
• API atau database untuk harga, akun, stok, dan status layanan.

LLM dapat menyusun penjelasan. Namun, data final sebaiknya berasal dari sistem yang memang bertugas menyimpan, menghitung, atau memvalidasi informasi tersebut.

8. Evaluasi dengan Data Penggunaan Nyata

Buat dataset pengujian berdasarkan pertanyaan pengguna, istilah lokal, dokumen internal, dan kasus ketika model seharusnya menolak menjawab.

Beberapa aspek yang perlu diukur meliputi:

• Akurasi retrieval.
• Persentase klaim yang didukung sumber.
• Ketepatan sitasi.
• Jumlah klaim yang tidak dapat diverifikasi.
• Ketepatan model saat menolak menjawab.
• Jumlah kesalahan berisiko tinggi.
• Perubahan kualitas setelah knowledge base diperbarui.

Untuk bidang medis, hukum, keuangan, atau tindakan yang sulit dibatalkan, output tetap perlu diperiksa oleh manusia yang memahami domain terkait.

Apakah Hallucination Dapat Dihilangkan Sepenuhnya?

Hallucination belum dapat dihilangkan sepenuhnya. Teknik grounding dan RAG masih dapat gagal ketika retrieval buruk, konteks tidak cukup, atau model salah menafsirkan dokumen.

Dokumentasi Anthropic juga menegaskan bahwa teknik mitigasi dapat mengurangi hallucination, tetapi tidak menghapusnya seluruhnya. Informasi kritis tetap perlu divalidasi sebelum digunakan untuk mengambil keputusan.

Tujuan yang lebih realistis adalah:

• Mengurangi frekuensi kesalahan.
• Mendeteksi klaim yang tidak didukung.
• Membatasi dampak kesalahan.
• Membuat model mampu menolak ketika bukti tidak tersedia.
• Memastikan keputusan penting tidak bergantung pada output LLM saja.

Model yang lebih besar, temperature rendah, atau server yang lebih kuat tidak dapat menggantikan sumber tepercaya dan proses verifikasi.

Kesimpulan

Hallucination pada LLM adalah informasi salah atau tidak didukung yang dapat terlihat sangat meyakinkan. Dampaknya nyata, mulai dari referensi ilmiah palsu, saran medis yang tidak aman, hingga dependensi kode yang sebenarnya tidak tersedia.

Risiko tersebut dapat dikurangi dengan membatasi sumber, menggunakan RAG secara tepat, meningkatkan retrieval, mengizinkan model tidak menjawab, memeriksa sitasi, menerapkan validasi deterministik, dan melakukan pemeriksaan ahli untuk penggunaan berisiko tinggi.

LLM sebaiknya digunakan untuk membantu menyusun dan mengolah informasi. Kebenaran informasi tetap harus ditentukan oleh sumber tepercaya serta proses verifikasi yang dapat diaudit.