Cara Mengevaluasi Kualitas Jawaban RAG Secara Sistematis

Chatbot dokumenmu sudah jalan, tim mencobanya, dan komentarnya "lumayan, kadang meleset". Lalu bagaimana kamu tahu apakah perubahan berikutnya, entah ganti ukuran chunk, ganti model, atau menambah reranker, benar-benar membuatnya lebih baik?

Jawabannya: berhenti menilai dengan perasaan dan mulai memakai set uji yang tetap. Evaluasi RAG (Retrieval-Augmented Generation) yang sistematis memisahkan dua pertanyaan. Pertama, apakah sistem menemukan potongan dokumen yang tepat? Kedua, apakah jawaban model setia pada potongan itu dan menjawab pertanyaan? Dengan dua angka ini, kamu bisa tahu bagian mana yang perlu diperbaiki.

Kalau konsep RAG masih baru, baca dulu cara kerja chatbot dari dokumen perusahaan.

Kenapa evaluasi RAG perlu dipisah dua?

Jawaban RAG yang salah bisa berasal dari dua tempat yang sangat berbeda. Bisa jadi tahap pencarian (retrieval) mengambil potongan dokumen yang salah, sehingga model menjawab dari bahan yang keliru. Bisa juga potongannya sudah benar, tetapi model menambahkan hal yang tidak ada di dokumen atau salah membaca isinya.

Perbaikannya pun berbeda. Masalah pencarian diatasi lewat chunking, embedding, hybrid search, atau reranking. Masalah jawaban diatasi lewat prompt, pemilihan model, atau aturan "jawab hanya dari konteks". Kalau kamu hanya punya satu nilai "benar atau salah", kamu tidak tahu harus memperbaiki yang mana.

Langkah mengevaluasi RAG

Langkah 1: Susun set pertanyaan uji

Kumpulkan 50 sampai 100 pertanyaan sebagai titik awal yang mewakili pemakaian nyata. Sumber terbaik adalah pertanyaan asli dari pengguna atau tim layanan pelanggan. Campurkan beberapa jenis:

• Pertanyaan yang jawabannya ada di satu bagian dokumen.
• Pertanyaan yang butuh gabungan dua bagian atau lebih.
• Pertanyaan yang memakai istilah berbeda dari dokumen, misalnya "balikin barang" untuk kebijakan retur.
• Pertanyaan yang jawabannya memang tidak ada di dokumen. Sistem yang baik harus menjawab "tidak tahu".

Jumlah di atas bukan angka baku, tetapi set yang terlalu kecil membuat perubahan nilai sulit dibedakan dari kebetulan.

Langkah 2: Tulis jawaban acuan dan sumbernya

Untuk setiap pertanyaan, tulis jawaban acuan singkat dan tandai dokumen atau bagian mana yang menjadi sumbernya. Pekerjaan ini membosankan, tetapi inilah fondasi semua pengukuran. Libatkan orang yang paham isi dokumen, bukan hanya tim teknis.

AI bisa membantu membuat draf pertanyaan dan jawaban dari dokumen, tetapi tetap periksa manual. Set uji yang salah akan membuat semua nilai menyesatkan.

Langkah 3: Ukur kualitas pencarian

Jalankan setiap pertanyaan ke tahap pencarian saja, lalu periksa apakah potongan sumber yang benar ada di hasil teratas. Ukuran yang umum dipakai:

• Hit rate atau recall@k: berapa persen pertanyaan yang potongan benarnya muncul di k hasil teratas, misalnya 5 teratas.
• Peringkat: seberapa tinggi potongan benar muncul. Potongan benar di urutan pertama lebih baik daripada di urutan kelima.

Bila nilai ini rendah, jangan buang waktu memperbaiki prompt. Masalahnya ada di pencarian. Pengaturan potongan dokumen dibahas di embedding dan chunking untuk RAG, sedangkan teknik menaikkan ketepatan pencarian ada di hybrid search dan reranking.

Langkah 4: Ukur kualitas jawaban

Sekarang jalankan pipeline lengkap dan nilai jawabannya. Ada tiga hal yang biasanya diperiksa:

• Kesetiaan (faithfulness): apakah semua klaim di jawaban didukung potongan dokumen yang diambil?
• Relevansi jawaban: apakah jawaban benar-benar menjawab pertanyaan, bukan berputar-putar?
• Kebenaran: apakah jawaban sesuai jawaban acuan?

Penilaian bisa dilakukan manusia, atau oleh model AI lain sebagai penilai (sering disebut LLM-as-a-judge). Pustaka open source seperti Ragas menyediakan metrik siap pakai untuk ini, antara lain Faithfulness, Response Relevancy, Context Precision, dan Context Recall.

Langkah 5: Kalibrasi penilai otomatis

Penilai berbasis AI bisa keliru. Ambil sampel, misalnya 20 sampai 30 jawaban, nilai manual, lalu bandingkan dengan nilai dari penilai otomatis. Kalau sering berbeda, perbaiki instruksi penilai atau ganti modelnya. Setelah cukup cocok, penilai otomatis bisa dipakai untuk menilai seluruh set dengan cepat.

Langkah 6: Jadikan evaluasi rutin

Simpan hasil setiap putaran evaluasi beserta konfigurasi yang dipakai: ukuran chunk, model embedding, model jawaban, versi prompt. Jalankan ulang set uji setiap kali ada perubahan. Dengan begitu, kamu bisa membuktikan bahwa perubahan memang memperbaiki, bukan hanya terasa lebih baik di beberapa pertanyaan yang kebetulan dicoba.

Tambahkan juga pertanyaan baru dari kasus nyata yang gagal. Set uji yang hidup selalu lebih berguna daripada set uji yang dibuat sekali lalu dilupakan.

Membaca hasil evaluasi

Baris ketiga sering terlewat. Jawaban yang kebetulan benar padahal dokumen yang diambil salah adalah tanda bahaya, karena model menjawab dari pengetahuan umum, bukan dari dokumen kamu. Untuk kebijakan internal yang berubah, ini bisa berujung jawaban yang terdengar benar tetapi kedaluwarsa.

Checklist evaluasi RAG:

• Set uji berisi pertanyaan nyata, termasuk yang jawabannya tidak ada di dokumen.
• Setiap pertanyaan punya jawaban acuan dan sumber.
• Nilai pencarian dan nilai jawaban diukur terpisah.
• Penilai otomatis sudah dibandingkan dengan penilaian manual.
• Hasil dan konfigurasi setiap putaran disimpan.