Tim yang membangun aplikasi berbasis LLM sering melewatkan satu langkah krusial: evaluasi sistematis. Keputusan seperti “prompt baru ini lebih baik” atau “model X lebih cocok” sering dibuat berdasarkan kesan subjektif dari segelintir contoh, bukan pengukuran yang konsisten. Artikel ini melengkapi Panduan Praktis Membangun Aplikasi RAG dan Prompt Engineering Tingkat Lanjut dengan fokus khusus pada metodologi evaluasi.

Mengapa “Kelihatannya Bagus” Tidak Cukup

Manusia cenderung menilai output LLM berdasarkan beberapa contoh yang kebetulan dilihat, yang rentan bias konfirmasi — kita cenderung menguji dengan kasus yang kita duga akan berhasil. Tanpa evaluasi sistematis, perubahan prompt atau model bisa terlihat “lebih baik” padahal sebenarnya menurunkan kualitas untuk kasus yang tidak sempat diuji secara manual.

Tiga Lapisan Evaluasi yang Perlu Dipisahkan

1. Evaluasi Retrieval (khusus aplikasi RAG)

Terpisah dari kualitas jawaban akhir, ukur apakah dokumen yang relevan benar-benar ditemukan:

  • Precision@K — dari K dokumen yang diambil, berapa persen yang benar-benar relevan?
  • Recall@K — dari semua dokumen relevan yang ada, berapa persen yang berhasil diambil dalam top-K?

Tanpa memisahkan ini, sulit membedakan apakah masalah ada di pencarian dokumen atau di pemrosesan LLM.

2. Evaluasi Kebenaran Faktual

Untuk task yang butuh akurasi tinggi, bangun set data uji dengan jawaban yang sudah diverifikasi benar (ground truth), lalu ukur:

  • Tingkat halusinasi — seberapa sering model menghasilkan klaim yang tidak didukung sumber/konteks.
  • Tingkat penolakan yang tepat — untuk pertanyaan yang jawabannya memang tidak ada di data, apakah model mengakui tidak tahu, atau tetap mengarang jawaban?

3. Evaluasi Kualitas Subjektif (dengan Metode Terstruktur)

Untuk aspek yang lebih sulit diukur otomatis (nada bahasa, kejelasan, relevansi), gunakan rubrik penilaian eksplisit dengan skala jelas (misal 1-5) dan kriteria tertulis untuk setiap skor — baik untuk reviewer manusia maupun jika memakai “LLM sebagai juri” (LLM-as-judge).

Menggunakan LLM sebagai Evaluator (LLM-as-Judge)

Teknik ini semakin umum untuk mempercepat evaluasi skala besar: memakai satu LLM untuk menilai output LLM lain berdasarkan rubrik yang jelas. Perlu diwaspadai:

  • Rubrik harus sangat eksplisit — instruksi ambigu menghasilkan penilaian tidak konsisten.
  • Validasi LLM-as-judge dengan sampel yang dinilai manusia — pastikan penilaian otomatis cukup selaras dengan penilaian manusia sebelum bergantung penuh padanya.
  • Waspadai bias posisi dan bias panjang — beberapa LLM cenderung memilih jawaban yang lebih panjang atau yang muncul di posisi tertentu, terlepas dari kualitas sebenarnya.

Membangun Set Evaluasi yang Representatif

Set evaluasi yang baik mencakup:

  • Kasus umum — pertanyaan/task yang paling sering muncul dalam penggunaan nyata.
  • Edge case yang diketahui sulit — pertanyaan ambigu, input yang tidak lengkap, kasus di luar cakupan data.
  • Kasus yang jawabannya seharusnya “tidak tahu” — untuk menguji apakah sistem jujur soal keterbatasannya.
  • Kasus yang pernah gagal sebelumnya — setiap bug yang ditemukan di produksi sebaiknya ditambahkan ke set evaluasi agar regresi bisa terdeteksi otomatis di masa depan.

Kesalahan Umum dalam Evaluasi LLM

  • Set evaluasi terlalu kecil dan tidak representatif — 5 contoh tidak cukup untuk membuat keputusan yang berdampak ke seluruh sistem.
  • Hanya mengevaluasi sekali di awal, tidak berkelanjutan — model dan data terus berubah; evaluasi perlu dijalankan ulang secara rutin, terutama setelah perubahan prompt, model, atau data sumber.
  • Tidak memisahkan evaluasi per komponen — menilai “sistem RAG ini jelek” tanpa tahu apakah masalahnya di retrieval atau generation membuat perbaikan jadi tidak terarah.

Mulai dari yang Sederhana

Anda tidak perlu infrastruktur evaluasi yang rumit untuk memulai — spreadsheet berisi 20-30 kasus uji dengan kolom “input, output aktual, output yang diharapkan, skor” sudah jauh lebih baik dibanding tidak melakukan evaluasi sistematis sama sekali. Kompleksitas bisa ditambahkan bertahap seiring aplikasi berkembang.

Artikel ini melengkapi seri Tutorial & Implementasi Teknis, bersama Panduan Membangun RAG dan Prompt Engineering Tingkat Lanjut.