Belajar ML Engineer - Advanced Evaluation & Eval-Driven Dev

#Pendahuluan

Setelah di episode 23 model kalian dioptimalkan, ada pertanyaan yang menuntut jawaban terus-menerus di era LLM: "apakah model yang baru ini lebih baik?" Untuk model klasik, jawabannya mudah — bandingkan accuracy di test set. Tapi untuk LLM yang jawabannya terbuka, penilaian otomatis sulit: tidak ada satu angka yang bisa menangkap "jawaban ini bagus atau tidak".

Karena itu, 2026 menyaksikan kebangkitan eval-driven development: pengembangan model yang didorong oleh evaluasi. Ide-nya sederhana: setiap perubahan (prompt, model, data, parameter) harus melewati eval suite — set pengujian terstandar — dan hanya perubahan yang lolos yang boleh lanjut. Episode ini membangun eval suite yang lengkap: LLM-as-judge, benchmark, regression suite, dan pipeline evaluasinya.

#Mengapa Evaluasi LLM Itu Sulit

Tiga alasan penilaian LLM tidak sesederhana model klasik:

1. Jawaban terbuka: tidak ada satu "label benar"; jawaban bisa valid dengan formulasi berbeda.
2. Kualitas multidimensi: benar secara fakta? relevan? aman? mengikuti instruksi? gaya sesuai?
3. Ground truth mahal: membuat label manual untuk semua kasus tidak scalable.

Dari sinilah LLM-as-judge lahir: memakai LLM yang kuat sebagai penilai otomatis — konsisten, cepat, dan mampu menilai nuansa bahasa.

#LLM-as-Judge

Konsepnya: kirim pasangan (pertanyaan, jawaban) + rubrik penilaian ke LLM judge, dan minta skor atau penilaian biner:

from openai import OpenAI
 
judge = OpenAI(base_url="http://localhost:8000/v1", api_key="x")
 
def grade(question: str, answer: str) -> int:
    prompt = f"""Anda adalah grader. Beri skor 1-5 untuk jawaban ini.
Skor 5 = benar, lengkap, relevan, mengikuti instruksi. Skor 1 = salah.
Pertanyaan: {question}
Jawaban: {answer}
Output: cukup skor angka saja."""
    resp = judge.chat.completions.create(
        model="Qwen/Qwen2.5-14B-Instruct",
        messages=[{"role": "user", "content": prompt}],
        temperature=0,
    )
    return int(resp.choices[0].message.content.strip())

Prinsip penting LLM-as-judge:

• Rubrik eksplisit: judge harus tahu kriteria persis, bukan "nilai saja".
• Comparison-based sering lebih andal: "jawaban mana yang lebih baik?" lebih mudah daripada skor absolut.
• Position bias: ulangi dengan posisi jawaban dibalik untuk netralkan bias urutan.
• Judgement validity: validasi judge terhadap penilaian manusia pada subset — judge yang tidak selaras dengan manusia tidak berguna.

#Benchmark dan Golden Set

Dua jenis data evaluasi yang harus dibedakan:

Golden set internal adalah yang paling penting untuk produksi: ia mencerminkan penggunaan sebenarnya — pertanyaan dari customer, dokumen internal, kasus edge yang dulu salah. Mulai kecil (50-200 item), lalu tumbuhkan terus: setiap insiden di produksi = calon item golden set baru.

# eval/golden.json
[
  {
    "question": "Bagaimana prosedur klaim asuransi jika kartu hilang?",
    "reference": "Lapor ke CS, blokir kartu, ajukan penggantian dalam 14 hari.",
    "source_docs": ["docs/claims-v3.md"]
  }
]

#Regression Suite: Menjaga Kualitas Naik Terus

Tidak cukup mengevaluasi sekali. Regression suite menjawab: "apakah perubahan hari ini menurunkan kualitas yang kemarin sudah bagus?" Prinsip yang sama dengan unit test dalam software engineering: setiap perbaikan disertai test yang menjaga perbaikan itu.

eval/
  golden.json          # kasus inti
  regression.json      # kasus yang pernah gagal → harus selalu lolos
  edge_cases.json      # boundary, input aneh, injection

Alur kerja: model/prompt baru → jalankan seluruh suite → bandingkan dengan baseline → lolos/gagal. Model yang gagal di regression suite ditolak, sekalipun skor rata-ratanya naik — karena regresi pada kasus tertentu sering lebih merusak daripada kenaikan rata-rata.

#RAGAS dan Metrik RAG

Untuk sistem RAG (episode 16), framework RAGAS menyediakan metrik terstandar yang bisa menjadi bagian suite:

• Faithfulness: apakah jawaban hanya bersumber dari konteks (anti-hallucination)?
• Answer relevancy: apakah jawaban menjawab pertanyaan?
• Context precision: apakah konteks yang di-retrieve relevan?
• Context recall: apakah konteks cukup untuk menjawab?

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
 
result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy],
)
print(result)

Metrik RAG memberi angka yang bisa di-tracking antar versi — mengubah perasaan "kayaknya lebih baik" menjadi tren yang bisa diukur.

#Eval Pipeline sebagai Gerbang Produksi

Evaluasi yang baik harus terotomasi dan terintegrasi dengan alur pengembangan — menjadi bagian dari gerbang CI (episode 10) dan eval-driven loop:

Praktik pelaksanaannya:

1. Otomasi: eval suite jalan otomatis di CI tiap perubahan — bukan manual per minggu.
2. Versi hasil: skor eval di-log ke experiment tracker (episode 6) agar tren terlihat.
3. Pemisahan data: golden set yang dipakai untuk memilih model tidak boleh bocor ke training.
4. Uji sebelum deploy: eval suite dijalankan pada model yang akan di-canary (episode 10) — bukan hanya di akhir.

#Common Pitfalls

#Penutup

Pada episode 24 ini, kalian telah membangun mesin evaluasi:

• LLM-as-judge dengan rubrik eksplisit, comparison-based, dan validasi terhadap manusia.
• Benchmark publik + golden set internal — yang terakhir mencerminkan kasus nyata.
• Regression suite yang menjaga kualitas tetap naik antar perubahan.
• RAGAS untuk metrik RAG yang bisa di-track.
• Eval pipeline otomatis sebagai gerbang sebelum produksi.

Di episode 25 selanjutnya kita akan membahas AI Agents & Systems Engineering — arsitektur agent, tool use, dan bagaimana agen AI terhubung ke sistem perusahaan sebagai pengembangan paling besar dari peran MLE di 2026. Sampai jumpa di episode 25!