Panduan Praktis Menguji Agent dengan RAGAs dan G-Eval

Oleh VOXBLICK

Senin, 13 April 2026 - 07.45 WIB

Panduan Praktis Menguji Agent dengan RAGAs dan G-Eval

Panduan praktis uji agent (Foto oleh Negative Space)

VOXBLICK.COM - Kalau kamu membangun aplikasi agent atau sistem berbasis LLM yang mengambil pengetahuan dari dokumen (misalnya lewat RAG), pekerjaan paling sulit bukan cuma “membuatnya bisa menjawab”. Tantangannya adalah: bagaimana cara memastikan jawabannya benar, relevan, dan tidak berhaluterutama saat agent terus berkembang, prompt berubah, atau sumber pengetahuan bertambah.

Di sinilah RAGAs dan framework berbasis G-Eval jadi sangat berguna. Dengan pendekatan evaluasi yang terstruktur, kamu bisa menguji kualitas pipeline RAG dan output agent secara lebih objektif.

Artikel ini akan memandu kamu secara praktis: mulai dari konsep metrik seperti faithfulness sampai langkah uji coba, desain dataset, hingga cara membaca hasil evaluasi agar keputusan engineering kamu lebih tepat.

Kenapa pengujian agent + RAG itu beda?

Agent biasanya punya beberapa langkah: mengurai pertanyaan, memilih tool atau retriever, membaca konteks, lalu menyusun jawaban. Setiap langkah punya peluang error. Misalnya:

Retrieval bisa mengambil paragraf yang “terlihat relevan” tapi tidak benar-benar mendukung klaim jawaban.
Generation bisa menambahkan detail yang tidak ada di sumber (hallucination).
Grounding bisa lemah: jawaban terdengar meyakinkan, namun tidak konsisten dengan dokumen.
Instruksi agent bisa membuatnya terlalu percaya diri atau mengabaikan batasan.

Karena itu, evaluasi perlu memisahkan dua hal: kualitas retrieval dan kualitas jawaban yang di-grounding-kan. RAGAs dan G-Eval membantu kamu menilai keduanya dengan metrik yang fokus.

Gambaran singkat: RAGAs vs G-Eval

Walau istilahnya terdengar mirip (sama-sama evaluasi LLM), keduanya punya fokus yang berbeda.

RAGAs: biasanya dipakai untuk mengevaluasi sistem RAGmisalnya seberapa baik konteks yang diambil mendukung jawaban. Kamu akan sering melihat metrik seperti faithfulness, answer relevancy, dan metrik lain yang mengukur hubungan antara jawaban dan evidence.
G-Eval: pendekatan evaluasi yang memanfaatkan model evaluator (LLM) dengan kriteria (rubric) yang lebih fleksibel. Kamu bisa menilai kualitas jawaban berdasarkan aspek tertentu, misalnya “apakah jawaban mengikuti instruksi”, “apakah ada kontradiksi”, atau “seberapa baik jawaban mematuhi format”.

Praktiknya, banyak tim menggabungkan keduanya: RAGAs untuk menilai kualitas pipeline RAG secara numerik, lalu G-Eval untuk menilai aspek yang lebih “kontekstual” atau sesuai kebutuhan produk.

Metrik kunci yang perlu kamu pahami (terutama faithfulness)

Kalau kamu hanya mengingat satu hal, ingatlah faithfulness. Faithfulness mengukur apakah jawaban benar-benar didukung oleh konteks/evidence yang diberikan. Jawaban yang “bagus” tapi tidak ground pada dokumen harus dianggap buruk.

Berikut beberapa metrik yang umumnya relevan saat menguji agent dengan RAGAs dan G-Eval:

Faithfulness: klaim dalam jawaban harus selaras dengan dokumen yang menjadi sumber.
Answer Relevancy: jawaban harus menjawab pertanyaan secara langsung, bukan berputar atau terlalu umum.
Context Precision/Recall (konsep retrieval): seberapa tepat potongan konteks yang diambil. (Istilah spesifik bisa berbeda tergantung implementasi, tapi intinya tentang kualitas evidence.)
Instruction Following (sering via G-Eval): apakah jawaban mematuhi format, batasan panjang, atau gaya yang diminta.
Consistency: apakah jawaban tidak bertentangan dengan konteks maupun jawaban internal agent (misalnya tool call vs ringkasan).

Catatan penting: metrik ini bukan sekadar “skor”. Kamu harus menggunakannya untuk menemukan akar masalah. Faithfulness rendah bisa berarti retrieval gagal, prompt terlalu bebas, atau evidence tidak cukup.

Siapkan dataset uji yang “realistis” (bukan cuma contoh bagus)

Evaluasi yang baik dimulai dari dataset. Kamu butuh pertanyaan yang mencerminkan variasi penggunaan nyata. Langkah praktisnya:

Kumpulkan 50–200 pertanyaan dari log (kalau ada) atau dari tim produk/CS.
Kelompokkan skenario: pertanyaan faktual, pertanyaan yang butuh reasoning, pertanyaan “berpotensi jebakan”, dan pertanyaan yang harus menolak (misalnya info tidak ada di dokumen).
Pastikan ada jawaban referensi bila memungkinkan. Jika tidak, minimal sediakan evidence dokumen yang relevan.
Tambahkan kasus adversarial: pertanyaan yang memancing jawaban dari pengetahuan umum padahal dokumen tidak menyebutnya.

Untuk RAGAs, kamu biasanya butuh pasangan question–answer dan contexts (evidence).

Untuk G-Eval, kamu bisa menilai jawaban berdasarkan rubric dengan bantuan evaluator LLM, jadi dataset juga sebaiknya menyertakan konteks dan instruksi yang diberikan ke agent.

Workflow praktis: uji agent dengan RAGAs

Berikut alur yang bisa kamu lakukan dalam proyek nyata. Kamu bisa menyesuaikan sesuai stack kamu (Python/Node), tapi logikanya sama.

Definisikan pipeline yang ingin diuji: retriever (misalnya vector store), top-k, reranker (jika ada), lalu LLM generation.
Jalankan agent untuk setiap pertanyaan dan simpan:
- jawaban final
- konteks yang diambil (chunks)
- metadata retrieval (misalnya skor similarity, sumber dokumen)
- prompt atau instruksi yang diberikan ke LLM (kalau memungkinkan)
Hitung metrik RAGAs menggunakan dataset yang berisi question, answer, dan contexts.
Audit hasil yang paling buruk: jangan hanya lihat rata-rata. Ambil top 10 pertanyaan dengan faithfulness terendah dan baca evidence vs jawaban.
Lakukan iterasi:
- Jika retrieval gagal: ubah top-k, chunking, embedding model, atau tambahkan reranker.
- Jika generation terlalu bebas: perkuat prompt (misalnya “hanya gunakan evidence”), tambah constraint, atau gunakan “answer with citations”.
- Jika konteks tidak cukup: tingkatkan coverage dokumen atau strategi query expansion.

Tip praktis: simpan hasil tiap iterasi dalam format tabel (question, score, evidence, answer). Dengan begitu kamu bisa membandingkan perubahan model/prompt secara terukur.

Workflow praktis: uji dengan G-Eval (rubric sesuai kebutuhan produk)

G-Eval biasanya paling efektif kalau kamu punya kriteria kualitas yang spesifik dan sulit dirangkum oleh metrik retrieval saja. Misalnya:

Apakah jawaban menyertakan langkah-langkah yang diminta?
Apakah agent menghindari klaim yang tidak ada di evidence?
Apakah jawaban mengikuti format (bullet, tabel, JSON, dsb)?
Apakah jawaban punya tingkat ketepatan istilah (misalnya istilah medis/finansial)?

Langkahnya:

Buat rubric yang jelas. Contoh sederhana:
- Skor 1: banyak klaim tanpa dukungan, format tidak sesuai.
- Skor 3: sebagian klaim didukung, format cukup.
- Skor 5: semua klaim selaras evidence, format rapi, tidak berlebihan.
Masukkan input evaluator: question, contexts, jawaban agent, dan (opsional) instruksi asli.
Jalankan evaluator untuk setiap contoh di dataset.
Analisis distribusi skor: lihat apakah masalahnya sistemik (misalnya format selalu salah) atau sporadis (tergantung jenis pertanyaan).
Perbaiki sesuai temuan: rubric yang tepat akan memandu kamu pada perubahan prompt, tool policy, atau strategi retrieval.

Contoh skenario pengujian yang “mengungkap akar masalah”

Agar pengujian tidak terasa abstrak, gunakan skenario seperti ini:

Skenario 1 (Evidence tidak ada): pertanyaan meminta informasi yang tidak ada di dokumen. Target: agent menolak atau menyatakan tidak ditemukan. Ukur lewat faithfulness (harus rendah jika agent tetap mengarang) dan G-Eval untuk “instruction following / refusal quality”.
Skenario 2 (Evidence ada tapi tidak cukup): dokumen menyebut sebagian, tapi tidak detail. Target: jawaban harus menghindari detail yang tidak disebut. Faithfulness akan turun jika LLM mengisi celah.
Skenario 3 (Dokumen relevan tapi chunk salah): retrieval mengambil bagian yang mirip namun tidak benar. Di sini kamu akan melihat pola: faithfulness rendah meski answer relevancy terlihat lumayan.
Skenario 4 (Format ketat): agent diminta output JSON/step-by-step. G-Eval biasanya lebih sensitif untuk mendeteksi pelanggaran format.

Praktik terbaik saat membaca hasil (biar tidak menipu diri sendiri)

Beberapa kesalahan umum saat evaluasi:

Hanya melihat skor rata-rata. Rata-rata bisa terlihat bagus, tapi kualitas buruk muncul pada kategori tertentu.
Tidak melakukan “case study”. Ambil sampel jawaban buruk dan telusuri: apakah masalah di retrieval, prompt, atau evidence.
Menganggap evaluator selalu benar. Baik RAGAs maupun G-Eval memakai LLM sebagai komponen evaluasi. Gunakan sebagai alat diagnosis, bukan kebenaran absolut.
Tidak mengunci versi. Simpan versi embedding model, reranker, prompt, dan parameter top-k agar eksperimen bisa direproduksi.

Checklist cepat sebelum merilis agent ke user

Skor faithfulness stabil dan tidak turun drastis pada kategori adversarial.
Answer relevancy konsisten (tidak banyak jawaban terlalu umum).
G-Eval rubric untuk format/instruksi menunjukkan kepatuhan yang memadai.
Kasus “tidak ada di dokumen” ditangani dengan benar (refusal/uncertainty sesuai kebijakan).
Hasil evaluasi disimpan per iterasi agar kamu bisa audit perubahan.

Dengan pendekatan RAGAs dan G-Eval, kamu tidak hanya mendapat angka, tapi juga peta masalah: apakah agent gagal karena retrieval, karena grounding lemah, atau karena instruksi tidak diikuti.

Mulai dari dataset yang realistis, ukur metrik kunci seperti faithfulness, lalu gunakan rubric G-Eval untuk aspek produk yang paling penting. Setelah itu, iterasi perbaikan jadi jauh lebih cepatkarena setiap perubahan punya bukti.