Di episode #29 kita sudah peta ekosistem framework agent. Tapi ada satu hal yang sering saya lewatkan selama ini: kalau saya ubah prompt sedikit, bagaimana cara tahu hasilnya memang LEBIH BAIK, bukan cuma “kelihatannya oke di satu contoh”? Jawabannya adalah evals — unit test untuk LLM. Hari ini saya catat dasar-dasarnya.
Evals itu apa dan kenapa bukan sekadar “coba-coba di chat”
Selama ini cara saya menguji prompt adalah mengetik beberapa contoh di chat window, hasilnya “lumayan”, lalu saya pakai. Masalahnya: contoh yang saya ingat cenderung yang mudah, dan saya sendiri yang jadi penilai — jadi hasilnya bias. Evals mengubah kebiasaan itu jadi proses: siapkan dataset tes (golden dataset) berisi input + output yang diharapkan, jalankan prompt/model versi baru terhadap seluruh dataset, lalu ukur skornya secara otomatis. Sama persis filosofi unit test di dunia web: satu contoh lolos bukan bukti, 50 contoh dengan skor terukur baru bukti.
Tiga jenis eval yang paling sering saya temui
- Exact match / string comparison — output dicek persis atau via regex. Cocok untuk format terstruktur (JSON, kode pos, kategori). Murah dan deterministik.
- Model-graded eval (LLM-as-judge) — satu model (GPT, Claude, dsb.) menilai output model lain dengan rubrik: “apakah jawaban ini relevan dan lengkap? skor 1–5”. Ini penyelamat untuk task subjektif seperti kualitas ringkasan.
- Human-in-the-loop — sampel kecil dinilai manusia, biasanya dipakai untuk kalibrasi: memastikan LLM-as-judge kita tidak memberi nilai tinggi pada jawaban yang sebenarnya jelek.
Untuk agent, eval-nya bukan cuma “jawaban benar atau tidak”, tapi juga: apakah agent memanggil tool yang tepat, apakah urutan tool-nya masuk akal, apakah ia berhenti dalam batas langkah yang wajar. Ini yang membedakan eval agent dari eval chat biasa — dan di sinilah framework seperti LangChain/LangGraph dari episode #29 mulai terasa butuh teman eval.
Sedikit catatan soal LLM-as-judge: model juri juga punya bias — cenderung memilih jawaban pertama, atau terlalu ramah memberi nilai tinggi. Trik yang saya baca dan coba: balik urutan jawaban yang dinilai (A/B lalu B/A), dan beri rubrik konkret dengan contoh “ini nilai 2, ini nilai 4” supaya juri punya patokan, bukan perasaan.
Benchmark publik vs eval internal
Benchmark publik (MMLU, HumanEval, dst.) berguna saat memilih model awal — tapi saya belajar jangan terlalu percaya angka benchmark untuk kasus saya. Model A bisa unggul di benchmark tapi jelek di data perusahaan saya yang penuh istilah internal. Karena itu, dataset tes HARUS dibangun dari kasus nyata: 30–50 contoh pertanyaan pelanggan, 20 dokumen internal, dst. Angka kecil tapi jujur lebih berharga daripada angka besar hasil kurasi orang lain.
Cara mulai: promptfoo
Alat paling ringan yang saya coba adalah promptfoo — deklaratif, berbasis YAML, jalan lokal, cocok buat programmer yang terbiasa config-driven. Bentuk konfigurasinya kira-kira seperti ini (contoh ilustrasi):
prompts:
- "Ringkas artikel berikut dalam 2 kalimat: {{article}}"
providers:
- openai:gpt-4o-mini
- ollama:llama3.1
tests:
- vars:
article: "..."
assert:
- type: contains
value: "judul"
- type: llm-rubric
value: "Ringkasan maksimal 2 kalimat dan tidak mengarang fakta"Perintah promptfoo eval akan menjalankan semua kombinasi prompt × provider × test, lalu memunculkan tabel skor. Dari situ saya bisa membandingkan dua versi prompt berdampingan — persis seperti membandingkan hasil test suite sebelum dan sesudah refactor.
Yang saya catat untuk praktik sendiri
Pertama, mulai dari 20–30 kasus nyata dulu, jangan menunggu dataset ratusan baris — evaluasi yang jalan hari ini lebih baik daripada rencana dataset sempurna yang tidak pernah dibuat. Kedua, evaluasi otomatis butuh manusia sebagai juri kalibrasi minimal sekali. Ketiga, eval harus ikut CI mentalitas: saya simpan dataset dan skor baseline, jadi setiap perubahan prompt bisa diukur dampaknya, bukan ditebak. Buat saya yang biasa hidup dengan test suite, ini terasa seperti pulang ke rumah.
Komentar Terbaru