8Production LLM Skills

Evaluasi Output LLM

10 jam10 min baca
Tujuan

Setelah ini kamu bisa mengukur kualitas output LLM secara otomatis, tahu kapan model "bagus" dan kapan "jelek", dan punya sistem evaluasi yang bisa dijalankan berulang.

01 — Evaluasi Output LLM

Estimasi: 10 jam Prasyarat: Fase 7 (RAG chatbot sudah jalan) Tujuan: Setelah ini kamu bisa mengukur kualitas output LLM secara otomatis, tahu kapan model "bagus" dan kapan "jelek", dan punya sistem evaluasi yang bisa dijalankan berulang.

Kenapa Materi Ini Penting?

Bayangkan kamu bikin RAG chatbot. User tanya "Apa syarat daftar BPJS?", chatbot jawab sesuatu. Bagaimana kamu tahu jawabannya benar? Kalau cuma 10 pertanyaan, kamu bisa cek manual. Kalau 10.000 user per hari? Mustahil.

Evaluasi otomatis adalah mata kamu saat app sudah di production. Tanpa ini, kamu buta — tidak tahu apakah perubahan prompt membuat output lebih baik atau lebih buruk.

Bagian 1 — Masalah Evaluasi LLM

Kenapa Evaluasi LLM Sulit?

Berbeda dengan ML klasik (akurasi = jawaban benar/salah), output LLM itu teks bebas. Tidak ada satu jawaban benar.

flowchart LR
    subgraph ML_Klasik["ML Klasik"]
        A["Prediksi: kucing"] --> B["Label: kucing"]
        B --> C["✅ Benar"]
    end
    subgraph LLM["LLM"]
        D["Output: 'BPJS bisa didaftar di...'"] --> E["Jawaban ideal?"]
        E --> F["🤔 Benar tapi kurang lengkap?<br/>Benar tapi terlalu panjang?<br/>Sebagian benar?"]
    end

Analogi: Menilai ML klasik seperti menilai ujian pilihan ganda — ada kunci jawaban. Menilai LLM seperti menilai esai — subjektif, multi-dimensi, kontekstual.

Dimensi Evaluasi

Output LLM bisa dinilai dari banyak sudut:

Dimensi Pertanyaan Contoh Buruk
Correctness Apakah faktanya benar? "Jakarta ibukota Thailand"
Relevance Apakah menjawab pertanyaan? Ditanya harga, jawab sejarah
Completeness Apakah cukup lengkap? Cuma jawab setengah
Conciseness Apakah tidak bertele-tele? 500 kata untuk jawaban 1 kalimat
Harmlessness Apakah aman? Kasih saran medis berbahaya
Faithfulness Apakah sesuai konteks yang diberikan? (RAG) Mengarang di luar dokumen
Coherence Apakah logis dan mengalir? Kontradiksi diri sendiri

Tidak semua dimensi penting untuk semua use case. Kamu pilih mana yang relevan.

Bagian 2 — Metode Evaluasi

Metode 1: Human Evaluation (Gold Standard)

Manusia membaca output dan memberi skor.

Kelebihan: Paling akurat, bisa tangkap nuansa. Kekurangan: Lambat, mahal, tidak scalable.

Kapan dipakai: Benchmark awal, spot-check, evaluasi final sebelum launch.

Format umum:

  • Likert scale (1-5) per dimensi
  • A/B comparison ("mana yang lebih baik, A atau B?")
  • Binary ("acceptable / not acceptable")

Metode 2: LLM-as-Judge

Pakai LLM lain untuk menilai output LLM.

Analogi: Seperti peer review di jurnal ilmiah. Bukan sempurna, tapi scalable dan cukup akurat untuk iterasi cepat.

flowchart LR
    Q["User Question"] --> M["Model A<br/>(yang dievaluasi)"]
    M --> O["Output"]
    O --> J["Judge LLM<br/>(GPT-4 / Claude)"]
    Q --> J
    J --> S["Score: 4/5<br/>Reason: ..."]

Contoh prompt untuk judge:

Kamu adalah evaluator yang menilai kualitas jawaban AI.

Pertanyaan user: {question}
Konteks yang diberikan: {context}
Jawaban AI: {answer}

Nilai jawaban ini pada skala 1-5 untuk:
1. Correctness (apakah faktanya benar berdasarkan konteks?)
2. Relevance (apakah menjawab pertanyaan?)
3. Completeness (apakah cukup lengkap?)

Format output:
correctness: [1-5]
relevance: [1-5]
completeness: [1-5]
reasoning: [penjelasan singkat]

Tools populer:

  • LangSmith (dari LangChain) — built-in LLM evaluator
  • Ragas — framework evaluasi khusus RAG
  • DeepEval — open source LLM evaluation
  • OpenAI Evals — framework dari OpenAI

Metode 3: Heuristic / Rule-based

Cek otomatis tanpa LLM:

  • Panjang output (terlalu pendek? terlalu panjang?)
  • Mengandung kata terlarang?
  • Format sesuai (JSON valid? ada heading?)
  • Latency (berapa lama response?)
  • Mengandung hallucination markers ("Saya tidak yakin tapi...")

Kelebihan: Sangat cepat, gratis, deterministik. Kekurangan: Hanya tangkap masalah surface-level.

Metode 4: Reference-based Metrics

Bandingkan output dengan "jawaban ideal" yang sudah disiapkan.

Metrik Cara Kerja Cocok Untuk
BLEU Overlap n-gram dengan referensi Translation
ROUGE Recall n-gram dari referensi Summarization
BERTScore Cosine similarity embedding General text
Exact Match Persis sama? Extraction, QA factual

Kekurangan: Butuh dataset referensi. Tidak tangkap variasi jawaban yang sama-sama benar.

Bagian 3 — Evaluasi RAG Secara Spesifik

RAG punya komponen tambahan yang perlu dievaluasi: retrieval quality.

Cara Membaca Diagram:

  • Ungu = stage RAG: question → retriever → context.
  • Cyan = stage generation: context → LLM → answer.
  • Amber atas = metrik yang menilai retrieval (Context Precision, Context Recall).
  • Pink = metrik yang menilai faithfulness (apakah answer grounded di context).
  • Emerald = metrik akhir: Answer Relevancy (apakah answer match question).
  • Garis putus-putus = metrik mengukur stage yang relevan.

Walkthrough Step-by-Step:

  1. Question masuk ke retriever → ambil top-K docs sebagai context.
  2. Context Precision: dari docs yang ter-retrieve, berapa persen yang relevan?
  3. Context Recall: apakah info penting yang dibutuhkan untuk jawab semua ter-retrieve?
  4. Context + question → LLM → answer.
  5. Faithfulness: cek tiap claim di answer, apakah didukung context?
  6. Answer Relevancy: cek semantic similarity antara answer dan question original.
  7. Score 4 metric → identifikasi bottleneck (retrieval atau generation?).

Analogi Sehari-hari: Seperti audit jurnalis. Reporter (retriever) ngasih sumber. Editor cek: sumbernya relevan kah (precision)? Lengkap kah (recall)? Lalu writer (LLM) tulis artikel. Editor cek: klaim di artikel didukung sumber kah (faithfulness)? Artikel jawab pertanyaan judul kah (relevancy)? Tiap stage punya metric sendiri.

Diagram statis Mermaid sebagai fallback:

flowchart TD
    Q["Question"] --> R["Retriever"]
    R --> D["Retrieved Docs"]
    D --> G["Generator (LLM)"]
    G --> A["Answer"]
    
    R -.-> E1["Eval: Retrieval Quality<br/>Apakah docs yang diambil relevan?"]
    G -.-> E2["Eval: Generation Quality<br/>Apakah jawaban faithful ke docs?"]
    A -.-> E3["Eval: End-to-end<br/>Apakah user puas?"]

Metrik RAG (Framework RAGAS)

Metrik Apa yang Diukur Rumus Sederhana
Context Precision Apakah retrieved docs relevan? Relevant docs / Total retrieved
Context Recall Apakah semua info yang dibutuhkan ter-retrieve? Info found / Info needed
Faithfulness Apakah jawaban sesuai context? (tidak hallucinate) Claims supported / Total claims
Answer Relevancy Apakah jawaban menjawab pertanyaan? Semantic similarity Q↔A

Contoh Kode: Evaluasi dengan RAGAS

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)
from datasets import Dataset

# Siapkan data evaluasi
eval_data = {
    "question": ["Apa syarat daftar BPJS?", "Berapa iuran BPJS kelas 1?"],
    "answer": ["Syarat daftar BPJS adalah...", "Iuran BPJS kelas 1 adalah..."],
    "contexts": [["Dokumen tentang BPJS..."], ["Tabel iuran BPJS..."]],
    "ground_truth": ["KTP, KK, dan...", "Rp 150.000 per bulan"],
}

dataset = Dataset.from_dict(eval_data)

# Jalankan evaluasi
result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)

print(result)
# Output: {'faithfulness': 0.85, 'answer_relevancy': 0.92, ...}

Bagian 4 — Membangun Evaluation Pipeline

Langkah Praktis

Cara Membaca Diagram:

  • Ungu kiri = setup awal: test dataset + pilihan metrik.
  • Cyan tengah = run loop: tiap question → RAG → judge.
  • Amber = judge yang memberi score.
  • Pink = output score + analisis.
  • Emerald kanan = improvement → balik ke run (loop iterasi).

Walkthrough Step-by-Step:

  1. Siapkan test dataset 50+ Q&A pairs (question, expected answer, context).
  2. Pilih metrik sesuai use case (faithfulness untuk RAG, dll).
  3. Untuk tiap question, jalankan pipeline → dapat answer.
  4. Judge (LLM/heuristic/human) beri score per metric.
  5. Aggregate score, analisis where it fails (low score → kenapa?).
  6. Improve prompt/retrieval/model → re-run eval.
  7. Loop sampai score memuaskan (atau plateau).

Analogi Sehari-hari: Seperti A/B testing menu restoran. Test dataset = panel taster, metric = parameter (rasa, presentasi, harga), run = sajikan ke panel, judge = panel kasih nilai. Kalau jelek, chef tweak resep, ulang. Tanpa loop ini, kamu tidak tahu apakah resep baru lebih enak.

Diagram statis Mermaid sebagai fallback:

flowchart TD
    A["1. Buat Test Dataset<br/>(50-100 Q&A pairs)"] --> B["2. Pilih Metrik<br/>(sesuai use case)"]
    B --> C["3. Jalankan Evaluasi<br/>(otomatis, setiap perubahan)"]
    C --> D["4. Analisis Hasil<br/>(mana yang jelek? kenapa?)"]
    D --> E["5. Improve<br/>(prompt, retrieval, model)"]
    E --> C

Step 1: Buat Test Dataset

Ini bagian terpenting dan paling sering di-skip.

Kamu butuh minimal 50 pasangan:

  • Question (pertanyaan user)
  • Expected answer (jawaban ideal)
  • Context (dokumen yang seharusnya di-retrieve)

Tips bikin test dataset:

  • Ambil dari pertanyaan user nyata (kalau sudah ada)
  • Minta domain expert tulis 20-30 Q&A
  • Generate sisanya pakai LLM, lalu validasi manual
  • Cover edge cases: pertanyaan ambigu, out-of-scope, adversarial

Step 2: Pilih Metrik

Use Case Metrik Utama
RAG chatbot Faithfulness + Context Precision
Customer support Answer Relevancy + Completeness
Code generation Exact Match + Pass@k (unit test)
Summarization ROUGE + Conciseness
Classification Accuracy + F1

Step 3: Automate

# eval_pipeline.py — jalankan setiap kali ada perubahan prompt/retrieval

import json
from datetime import datetime

def run_evaluation(test_dataset, rag_pipeline):
    results = []
    for item in test_dataset:
        answer = rag_pipeline.query(item["question"])
        score = evaluate_single(item, answer)
        results.append(score)
    
    avg_scores = {
        "faithfulness": sum(r["faithfulness"] for r in results) / len(results),
        "relevancy": sum(r["relevancy"] for r in results) / len(results),
        "timestamp": datetime.now().isoformat(),
    }
    
    # Simpan history
    with open("eval_history.json", "a") as f:
        f.write(json.dumps(avg_scores) + "\n")
    
    return avg_scores

Step 4: Track Over Time

Setiap kali kamu ubah prompt, model, atau retrieval strategy — jalankan eval. Bandingkan skor sebelum vs sesudah.

Analogi: Seperti unit test untuk kode. Kamu tidak deploy tanpa test pass. Kamu tidak deploy LLM app tanpa eval pass.

Bagian 5 — Tools Evaluasi Populer

Tool Kelebihan Harga
RAGAS Khusus RAG, metrik lengkap 🆓 Open source
LangSmith Integrated dengan LangChain, tracing + eval 🆓 tier / 💰 pro
DeepEval General LLM eval, banyak metrik 🆓 Open source
Promptfoo CLI-based, compare prompts 🆓 Open source
Braintrust Enterprise, logging + eval 💰
Arize Phoenix Observability + eval 🆓 Open source

Rekomendasi untuk Pemula

Mulai dengan:

  1. RAGAS untuk evaluasi RAG
  2. LangSmith untuk tracing (lihat apa yang terjadi di setiap step)
  3. Manual spot-check 10 output per hari

Bagian 6 — Kesalahan Umum dalam Evaluasi

❌ "Saya coba 3 pertanyaan, hasilnya bagus, berarti sudah oke" → 3 pertanyaan bukan evaluasi. Minimal 50, cover edge cases.

❌ "Skor BLEU/ROUGE tinggi = output bagus" → Metrik ini hanya ukur overlap kata. Output bisa overlap tinggi tapi salah secara semantik.

❌ "Pakai GPT-4 sebagai judge pasti akurat" → LLM judge punya bias sendiri (suka jawaban panjang, bias posisi). Kalibrasi dengan human eval.

❌ "Evaluasi sekali cukup" → Evaluasi harus continuous. Setiap perubahan = re-evaluate.

❌ "Metrik tinggi = user puas" → Metrik otomatis ≠ user satisfaction. Selalu combine dengan feedback user nyata.

Cek Pemahaman

  • Kenapa evaluasi LLM lebih sulit dari evaluasi ML klasik?
  • Sebut 4 dimensi evaluasi output LLM
  • Apa itu LLM-as-Judge? Kapan dipakai?
  • Apa beda faithfulness dan relevancy di RAG?
  • Sebut 3 tools evaluasi dan kapan pakai masing-masing
  • Kenapa test dataset minimal 50 Q&A?

Challenge 7B.1

Challenge 1 — Evaluasi Manual (Mudah)

Ambil RAG chatbot dari Fase 7. Tanya 10 pertanyaan berbeda. Untuk setiap jawaban, beri skor 1-5 untuk: correctness, relevance, completeness. Hitung rata-rata.

Challenge 2 — LLM-as-Judge (Sedang)

Buat prompt evaluator (seperti contoh di Bagian 2). Jalankan di 10 output yang sama dari Challenge 1. Bandingkan skor judge dengan skor manual kamu. Seberapa mirip?

Challenge 3 — RAGAS Pipeline (Sedang-Sulit)

Install RAGAS. Buat test dataset 20 Q&A untuk RAG chatbot kamu. Jalankan evaluasi. Catat skor faithfulness dan context precision. Identifikasi 3 pertanyaan dengan skor terendah — kenapa jelek?

Challenge 4 — A/B Prompt Test (Sulit)

Buat 2 versi system prompt untuk RAG chatbot kamu. Jalankan evaluasi yang sama di kedua versi. Mana yang lebih baik? Tulis analisis 200 kata kenapa.

Selanjutnya: 02-guardrails-safety.md — bagaimana menjaga LLM app tetap aman di production.

Next
Guardrails & Safety untuk LLM Apps