Seorang klien pernah bertanya: "Bagaimana Anda tahu kalau AI-nya sudah cukup bagus untuk production?" Jawaban tim mereka: "Kami coba beberapa pertanyaan dan kelihatannya oke."
Ini adalah cara evaluasi yang paling umum dipakai — dan paling tidak reliable. Artikel ini adalah tentang cara yang lebih sistematis dan reproducible.
Mengapa Evaluasi LLM Sulit
Evaluasi model ML tradisional sederhana: bandingkan prediksi dengan label yang benar, hitung accuracy. LLM lebih kompleks karena output bersifat generatif, kualitasnya multidimensi, output bisa berubah antar run, dan tidak mungkin baca ribuan output secara manual.
Tier 1: Deterministic Checks
Paling mudah, paling cepat, paling reliable. Cocok untuk output yang punya struktur jelas:
import json
def evaluate_output(raw_output: str) -> dict:
results = {}
# 1. Valid JSON?
try:
parsed = json.loads(raw_output)
results["valid_json"] = True
except:
return {"valid_json": False, "score": 0}
# 2. Required fields ada?
required = ["category", "priority", "needs_more_info", "response"]
results["has_required_fields"] = all(f in parsed for f in required)
# 3. Nilai enum valid?
results["valid_priority"] = parsed.get("priority") in ["HIGH", "MEDIUM", "LOW"]
# 4. Panjang response masuk akal?
length = len(parsed.get("response", ""))
results["reasonable_length"] = 20 <= length <= 500
results["score"] = sum(v for v in results.values() if isinstance(v, bool)) / 4
return resultsTier 2: LLM-as-Judge
Untuk dimensi kualitatif yang tidak bisa dievaluasi secara deterministik (helpfulness, empati, factual accuracy), gunakan LLM lain sebagai penilai:
JUDGE_PROMPT = """Evaluasi respons customer service berikut.
Keluhan: {complaint}
Respons agent: {response}
Kebijakan relevan: {policy}
Berikan skor 0-10 untuk setiap dimensi:
- accuracy: apakah info faktual benar?
- helpful: apakah membantu customer?
- tone: apakah profesional dan empati?
- actionable: apakah customer tahu langkah selanjutnya?
Jawab HANYA dalam format JSON:
{{"accuracy": X, "helpful": X, "tone": X, "actionable": X, "overall": X}}"""
def llm_judge(complaint, response, policy, judge_llm):
result = judge_llm.invoke(
JUDGE_PROMPT.format(complaint=complaint, response=response, policy=policy)
)
return json.loads(result.content)
# PENTING: gunakan LLM BERBEDA sebagai judge
# Agent pakai Claude → judge pakai GPT-4o, dan sebaliknya
# LLM cenderung menilai outputnya sendiri lebih tinggi (self-serving bias)LLM cenderung menilai output dirinya sendiri lebih tinggi. Kalau agent menggunakan Claude, gunakan GPT-4o sebagai judge — dan sebaliknya. Ini meningkatkan objektivitas evaluasi secara signifikan.
Tier 3: RAGAs untuk RAG Pipeline
Untuk RAG system, library RAGAs menyediakan metrik yang sudah proven dan banyak dipakai di industri:
from ragas import evaluate
from ragas.metrics import (
faithfulness, # jawaban bisa di-trace ke context?
answer_relevancy, # jawaban relevan dengan pertanyaan?
context_precision, # context yang di-retrieve relevan?
context_recall # semua info yang dibutuhkan ada di context?
)
from datasets import Dataset
eval_data = {
"question": ["SLA untuk kerusakan minor?"],
"answer": [rag_answer], # output dari pipeline
"contexts": [[retrieved_chunks]], # dokumen yang di-retrieve
"ground_truth": [expert_answer] # jawaban yang benar
}
result = evaluate(
Dataset.from_dict(eval_data),
metrics=[faithfulness, answer_relevancy, context_precision, context_recall]
)
print(result)
# faithfulness: 0.87, answer_relevancy: 0.91, ...| Metrik | Apa yang Diukur | Target | Tool |
|---|---|---|---|
| JSON validity | Output bisa di-parse sebagai JSON | 100% | Python json module |
| Field completeness | Semua required fields ada | 100% | Python dict check |
| Accuracy (LLM judge) | Informasi faktual benar | > 8.0/10 | GPT-4o / Claude |
| Faithfulness (RAGAs) | Jawaban bisa di-trace ke context | > 0.85 | RAGAs library |
| Answer relevancy | Jawaban relevan dengan pertanyaan | > 0.80 | RAGAs library |
| Context precision | Context yang di-retrieve relevan | > 0.70 | RAGAs library |
Jangan gunakan LLM untuk membuat ground truth answer yang kemudian digunakan untuk mengevaluasi LLM lain. Ini menciptakan circular evaluation yang tidak reliable. Ground truth harus dari subject matter expert — tim customer service, tim legal, atau domain expert yang relevan.
Regression Testing — Jangan Rusak yang Sudah Bagus
Setiap kali ada perubahan pada prompt, embedding, atau chunk strategy, jalankan test suite yang sama. Ini mencegah regresi — kondisi di mana perbaikan untuk satu kasus merusak kasus lain.
Kesimpulan
Evaluasi yang baik tidak harus kompleks untuk mulai. Mulai dari deterministic checks yang berjalan dalam detik, tambahkan LLM-as-judge untuk dimensi kualitatif, dan gunakan RAGAs khusus untuk RAG system.
Tanpa evaluasi yang sistematis, setiap perubahan pada sistem LLM adalah gamble. Dengan evaluasi, itu menjadi engineering yang bisa dipertanggungjawabkan.
Ini adalah episode terakhir dari series AI Systems in Production. Kalau ada topik yang ingin dibahas lebih dalam — DM saya di LinkedIn atau WhatsApp +62 812-1113-0168.