Panduan Lengkap Evaluasi LLM: Metrik, Benchmark, dan LLM-as-a-Judge

Model bahasa yang "kelihatannya pintar" saat demo bisa gagal total di produksi. Evaluasi LLM adalah disiplin yang menjawab pertanyaan sederhana tapi sulit: bagaimana kamu tahu modelmu benar-benar bagus, bukan sekadar terdengar meyakinkan? Artikel ini membahas metrik evaluasi LLM, benchmark populer, dan teknik LLM-as-a-judge, plus jebakan yang paling sering membuat angka evaluasi menipu.

Ringkasan: Evaluasi LLM mengukur kemampuan model lewat benchmark standar, penilaian manusia, LLM-as-a-judge, dan pengujian berbasis tugas. Benchmark seperti MMLU-Pro, SWE-bench, dan Humanity's Last Exam memberi angka yang bisa dibandingkan antar model. LLM-as-a-judge mencapai kesepakatan di atas 80% dengan manusia, tapi punya bias posisi, verbosity, dan self-enhancement. Evaluasi yang baik selalu dimulai dari golden dataset milikmu sendiri, bukan dari leaderboard publik.

Apa itu evaluasi LLM?

Evaluasi LLM adalah proses sistematis mengukur seberapa baik sebuah model bahasa menyelesaikan tugas tertentu, memakai dataset uji dan metrik yang terdefinisi. Tanpa evaluasi, kamu hanya punya kesan subjektif, dan kesan subjektif terhadap teks yang fasih hampir selalu terlalu optimistis.

Bedakan evaluasi dengan validasi biasa di machine learning klasik. Di klasifikasi gambar, jawabannya benar atau salah. Di LLM, satu prompt bisa menghasilkan sepuluh jawaban yang semuanya valid tapi berbeda kualitasnya. Evaluasi LLM harus menangani ruang jawaban yang terbuka ini, bukan sekadar mencocokkan string.

Kenapa "kelihatannya bagus" bukan evaluasi

Hampir setiap tim yang membangun produk di atas LLM pernah mengalami pola ini: demo terasa mengagumkan, lalu setelah rilis, pengguna menemukan jawaban yang ngawur, format yang inkonsisten, atau instruksi yang diabaikan. Masalahnya bukan modelnya yang berubah. Tidak ada yang mengukur kualitas secara sistematis sejak awal.

Evaluasi yang buruk biasanya berwujud "vibe check": seseorang mencoba lima prompt, semuanya terlihat oke, lalu disimpulkan modelnya siap. Cara ini gagal karena tiga alasan. Pertama, lima contoh tidak mewakili ribuan variasi input nyata. Kedua, manusia buruk menilai teks panjang secara konsisten: kita terpengaruh gaya bahasa yang percaya diri. Ketiga, tanpa angka dasar, kamu tidak bisa tahu apakah perubahan prompt atau ganti model berikutnya memperbaiki atau merusak.

Evaluasi yang benar mengubah kualitas dari opini menjadi angka yang bisa dilacak dari waktu ke waktu. Angka itu yang memungkinkanmu membandingkan dua model, menguji perubahan prompt, dan menangkap regresi sebelum sampai ke pengguna.

Empat pendekatan evaluasi LLM

Tidak ada satu metode yang cocok untuk semua kasus. Praktiknya, evaluasi LLM memakai empat pendekatan yang saling melengkapi.

1. Static benchmark

Benchmark statis adalah dataset pertanyaan dengan jawaban yang sudah diketahui, dijalankan dengan cara yang sama untuk semua model. MMLU, HumanEval, dan SWE-bench termasuk kategori ini. Kelebihannya: murah, cepat, bisa diulang, dan hasilnya bisa dibandingkan antar model dan antar waktu. Kekurangannya: mengukur kemampuan umum, bukan kemampuan model di tugas spesifik produkmu.

2. Human evaluation

Penilai manusia membaca keluaran model dan memberi skor atau memilih yang terbaik. Ini standar emas untuk kualitas yang subjektif: nada, kreativitas, kebergunaan. Masalahnya: mahal, lambat, dan tidak konsisten antar penilai. Dua penilai manusia yang menilai hal yang sama pun hanya sepakat sebagian besar waktu, bukan selalu.

3. LLM-as-a-judge

Model yang kuat dipakai untuk menilai keluaran model lain, mengikuti rubrik yang kamu tulis. Pendekatan ini lahir dari paper Zheng et al. tahun 2023 dan sekarang dipakai luas karena skalabel: puluhan ribu sampel bisa dinilai dalam hitungan jam dengan biaya kecil. Detail lengkapnya ada di bagian tersendiri di bawah karena teknik ini punya jebakan yang perlu dipahami.

4. Evaluasi berbasis tugas di aplikasi

Alih-alih menilai teks secara abstrak, kamu menguji apakah tugas pengguna selesai. Untuk coding agent: apakah test-nya lolos? Untuk customer service bot: apakah masalah pelanggan terpecahkan menurut skenario uji? Pendekatan ini paling dekat dengan nilai bisnis, tapi membangun skenario ujinya butuh kerja.

Benchmark LLM yang wajib kamu kenal

Benchmark publik adalah bahasa bersama industri untuk membicarakan kemampuan model. Berikut yang paling berpengaruh, dari yang paling mapan sampai yang paling menantang.

MMLU (Hendrycks et al., 2021) adalah benchmark klasik: 57 subjek dari matematika dasar sampai hukum profesional, masing-masing empat opsi jawaban. Masalahnya, model-model frontier sekarang mencetak di atas 90%. Benchmark-nya jenuh dan tidak lagi bisa membedakan model terbaik dari yang "hanya" bagus.

MMLU-Pro (Wang et al., diperkenalkan Juni 2024) menjawab kejenuhan itu: sekitar 12.032 soal yang dikonsolidasikan ke 14 domain, dengan sepuluh opsi jawaban per soal (83% soal punya sepuluh opsi), bukan empat. Tebakan acak turun dari 25% ke 10%, soal-soal trivial dibuang, dan porsi penalaran ditambah. Dampaknya nyata: model yang sama turun 16–33% dibanding skor MMLU-nya.

HumanEval (2021) berisi 164 tugas menulis fungsi Python dari docstring, dinilai dengan unit test. Varian HumanEval+ (EvalPlus, 2023) memperbanyak test case puluhan kali lipat karena test bawaan HumanEval ternyata terlalu longgar, dan banyak solusi salah yang lolos.

SWE-bench (Jimenez et al., Oktober 2023) naik satu level: 2.294 masalah dari issue GitHub nyata di 12 repositori Python populer. Model menerima deskripsi issue dan snapshot repo, lalu harus menghasilkan patch. Penilaiannya memakai test dari pull request asli: test yang tadinya gagal harus lolos (FAIL_TO_PASS) dan test yang sudah lolos tidak boleh rusak (PASS_TO_PASS). Saat paper-nya rilis, model terbaik (Claude 2) hanya menyelesaikan 1,96%. Varian SWE-bench Verified (Agustus 2024) berisi 500 tugas yang divalidasi manusia. Lihat papan peringkatnya di SWE-bench Verified leaderboard.

GPQA (Rein et al., 2023) berisi 448 pertanyaan sains level pascasarjana yang "tahan Google": disusun agar tidak bisa dijawab lewat pencarian biasa. Subset tersulitnya, GPQA Diamond, hanya 198 soal. Ahli PhD menjawab benar sekitar 65%, non-ahli 34%.

Humanity's Last Exam (Center for AI Safety dan Scale AI, dirilis 23 Januari 2025) adalah sekitar 3.000 pertanyaan level ahli di lebih dari 100 bidang, dikurasi dari 70.000 kandidat oleh hampir 1.000 kontributor dari 500 institusi di 50 negara. Saat rilis, model-model terbaik mencetak satu digit — GPT-4o 2,7%, Claude 3.5 Sonnet 4,1% — sementara ahli manusia mencapai sekitar 90%. Benchmark ini dirancang sebagai "ujian terakhir": soal yang bisa dijawab AI saat itu langsung dibuang dari dataset. Baca latar belakangnya di artikel Turing Institute.

Satu catatan penting: angka-angka benchmark bergerak cepat dan leaderboard diperbarui terus. Jangan mengutip skor model dari artikel lama sebagai fakta terkini. Selalu cek sumber primernya.

Metrik evaluasi: dari akurasi sampai pass@k

Benchmark hanyalah dataset. Cara kamu menghitung skor dari dataset itulah metriknya, dan pilihan metrik mengubah kesimpulan.

Akurasi dan exact match

Untuk soal pilihan ganda, akurasi sederhana sudah cukup: persentase jawaban benar. Untuk jawaban bebas yang pendek (misalnya nama kota), exact match memeriksa kesamaan persis dengan kunci jawaban, kadang setelah normalisasi huruf kecil dan tanda baca. Keduanya rapuh untuk teks panjang: dua parafrase yang sama-sama benar bisa dinilai salah.

pass@k untuk kode

Di evaluasi coding, model diminta menghasilkan k solusi per soal; soal dianggap lolos jika satu pun dari k solusi itu lolos semua test. pass@1 mengukur keandalan jawaban pertama, pass@10 mengukur potensi model jika diberi beberapa kesempatan. SWE-bench memakai varian pass@1: patch yang dihasilkan harus membuat test yang relevan lolos.

Win rate dan Elo

Untuk perbandingan berpasangan (model A vs model B, dinilai manusia atau LLM judge), win rate adalah persentase kemenangan. Chatbot Arena memakai sistem Elo yang dipinjam dari catur: setiap model punya rating, menang melawan lawan kuat menaikkan rating lebih banyak daripada menang melawan lawan lemah. Elo menangani perbandingan yang tidak lengkap — tidak semua pasangan model harus bertanding langsung.

Metrik teks klasik: BLEU, ROUGE, BERTScore

BLEU dan ROUGE menghitung tumpang tindih n-gram antara keluaran model dan teks referensi. Mereka murah dan deterministik, tapi berkorelasi lemah dengan penilaian manusia untuk teks terbuka: ringkasan yang bagus dengan pilihan kata berbeda bisa dapat skor rendah. BERTScore memperbaiki ini dengan membandingkan embedding, bukan kata persis. Lebih baik, tapi tetap tidak menangkap hal seperti kepatuhan instruksi atau nada.

Metrik khusus RAG

Pipeline RAG butuh metrik yang memisahkan dua sumber kegagalan: retrieval yang buruk vs generasi yang buruk. Framework seperti Ragas mengukur faithfulness (apakah jawaban didukung konteks yang diambil?), answer relevancy (apakah jawaban menjawab pertanyaan?), context precision, dan context recall (apakah dokumen yang diambil relevan dan lengkap?). Tanpa pemisahan ini, kamu tidak tahu komponen mana yang harus diperbaiki. Kalau kamu membangun RAG, baca dulu panduan lengkap RAG supaya paham arsitekturnya sebelum mengukurnya.

LLM-as-a-judge: cara kerja dan jebakannya

Teknik LLM-as-a-judge diformalkan lewat paper Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" (NeurIPS 2023). Idenya lugas: beri model yang kuat sebuah rubrik (kriteria, skala skor, contoh), lalu minta ia menilai keluaran model lain. Dua mode utama: perbandingan berpasangan (pilih jawaban yang lebih baik dari dua kandidat) dan penilaian tunggal (beri skor langsung untuk satu jawaban).

Temuan sentral paper itu: GPT-4 sebagai juri mencapai kesepakatan di atas 80% dengan preferensi manusia, setara dengan tingkat kesepakatan antar penilai manusia sendiri. Hasil ini yang membuat tekniknya meledak dipakai: evaluasi yang tadinya butuh minggu dan ribuan dolar untuk penilai manusia bisa selesai dalam hitungan jam.

Tapi paper yang sama mendokumentasikan bias-bias juri yang harus kamu tangani:

• Position bias: juri cenderung memilih jawaban yang disajikan pertama. Mitigasi: acak urutan, atau tampilkan kedua urutan dan hitung rata-ratanya.
• Verbosity bias: jawaban yang lebih panjang dinilai lebih baik tanpa memandang kualitas. Mitigasi: instruksikan juri mengabaikan panjang, atau kontrol panjang jawaban sebelum dinilai.
• Self-enhancement bias: juri menilai keluaran dari keluarga modelnya sendiri lebih tinggi. Mitigasi: pakai juri dari keluarga model yang berbeda dengan model yang dinilai, atau pakai beberapa juri.

Teknik lanjutannya, G-Eval (EMNLP 2023), meminta juri menulis langkah evaluasinya sendiri (chain-of-thought) sebelum memberi skor, lalu menghitung skor tertimbang dari probabilitas token, mencapai korelasi Spearman 0,514 dengan penilaian manusia untuk tugas peringkasan, jauh di atas BLEU/ROUGE.

Aturan praktisnya: LLM judge bagus untuk regresi rutin dan perbandingan skala besar, tapi keputusan penting tetap perlu sampel yang divalidasi manusia: rilis model baru, atau klaim kualitas ke pelanggan. Pola yang paling dipakai tim produksi adalah hibrida: juri otomatis menangani volume, manusia menangani kasus yang tidak pasti, baru, atau berdampak tinggi.

Studi kasus: eval harness sederhana untuk chatbot

Teori tanpa praktik tidak berguna. Berikut harness evaluasi minimal untuk chatbot FAQ yang bisa kamu jalankan hari ini, tanpa framework apa pun.

Langkah 1: Kumpulkan 30–50 contoh nyata. Ambil dari log percakapan produksi atau tulis berdasarkan pertanyaan yang paling sering masuk. Tiap contoh berisi prompt dan kata kunci yang harus muncul di jawaban benar.

Langkah 2: Tulis scorer deterministik dulu. Sebelum memakai LLM judge yang mahal, cek hal yang bisa dicek mesin: apakah kata kunci jawabannya muncul? Apakah formatnya sesuai (misalnya JSON valid)?

Langkah 3: Jalankan dan simpan semua keluaran. Setiap run menyimpan prompt, jawaban mentah, dan skor per contoh. Tanpa artefak ini, kamu tidak bisa membandingkan run minggu depan dengan run hari ini.

Langkah 4: Tambah LLM judge untuk kualitas yang tidak bisa dicek mesin. Nada, kelengkapan, dan kepatuhan instruksi dinilai juri mengikuti rubrik.

Langkah 5: Tetapkan ambang dan gagalkan build bila turun. Evaluasi yang tidak memblokir rilis hanya jadi pajangan dashboard.

import json
import statistics
from dataclasses import dataclass

@dataclass
class EvalCase:
    prompt: str
    expected_keywords: list[str]
    category: str = "general"

def call_llm(prompt: str) -> str:
    """Ganti dengan pemanggilan ke model yang kamu evaluasi."""
    raise NotImplementedError("Hubungkan ke API model di sini")

def keyword_score(answer: str, expected: list[str]) -> float:
    lowered = answer.lower()
    hits = sum(1 for kw in expected if kw.lower() in lowered)
    return hits / len(expected) if expected else 0.0

def run_eval(cases: list[EvalCase]) -> dict:
    scores: list[float] = []
    failures: list[dict] = []
    for case in cases:
        answer = call_llm(case.prompt)
        score = keyword_score(answer, case.expected_keywords)
        scores.append(score)
        if score < 1.0:
            failures.append({
                "prompt": case.prompt,
                "answer": answer,
                "score": score,
            })
    total = len(scores)
    return {
        "n": total,
        "mean": statistics.fmean(scores) if scores else 0.0,
        "pass_rate": sum(1 for s in scores if s == 1.0) / total if total else 0.0,
        "failures": failures,
    }

if __name__ == "__main__":
    cases = [
        EvalCase("Jam berapa toko buka hari Senin?", ["09.00", "senin"]),
        EvalCase("Berapa ongkir ke Bandung?", ["15000", "bandung"]),
        EvalCase("Bagaimana cara retur barang?", ["retur", "14 hari"]),
    ]
    report = run_eval(cases)
    summary = {k: v for k, v in report.items() if k != "failures"}
    print(json.dumps(summary, indent=2))
    for f in report["failures"]:
        print("GAGAL:", f["prompt"], "->", f["answer"][:120])

Harness 60 baris ini sudah memberi tiga hal yang "vibe check" tidak punya: angka dasar (baseline), daftar kegagalan yang bisa ditelusuri, dan format yang bisa dijalankan ulang kapan pun. Kalau butuh metrik yang lebih canggih (faithfulness, G-Eval, evaluasi multi-turn), framework seperti DeepEval menyediakan puluhan metrik siap pakai dengan API mirip pytest.

Kesalahan umum dalam evaluasi LLM

Kontaminasi data. Benchmark publik bocor ke data training: model "menghafal" soal, bukan bisa mengerjakannya. Ini salah satu alasan MMLU jenuh: sebagian skor tinggi adalah ingatan, bukan penalaran. Untuk evaluasi internal, jangan pernah memakai soal yang mungkin ada di training set model yang kamu uji.

Goodhart's Law di leaderboard. Begitu sebuah metrik jadi target, ia berhenti jadi ukuran yang baik. Tim mengoptimasi prompt khusus benchmark, memilih decoding yang memaksimalkan skor, atau, dalam kasus ekstrem, melatih langsung di data test. Skor naik, kemampuan nyata tidak.

Sampel terlalu kecil. Benchmark dengan 100 soal punya margin error besar: selisih 3–4% antar model bisa jadi noise statistik belaka. Sebelum mengklaim "model B lebih baik 2%", hitung interval kepercayaannya.

Prompt sensitivity tidak dilaporkan. Cara soal diformat (urutan opsi, contoh few-shot, instruksi sistem) bisa menggeser skor belasan persen. Benchmark yang serius (seperti MMLU-Pro) merancang format untuk mengurangi sensitivitas ini. Kalau kamu membandingkan dua model, pakai prompt yang identik dan laporkan prompt-nya.

Hanya satu angka. Tidak ada metrik tunggal yang menangkap "kualitas". Akurasi 90% tidak memberi tahu apakah 10% kegagalannya adalah salah ketik ringan atau halusinasi berbahaya. Selalu sertakan analisis kegagalan: baca sampel yang gagal, kelompokkan polanya.

Best practice: kapan memakai pendekatan apa

• Memilih model untuk tugas umum → mulai dari benchmark publik yang relevan (MMLU-Pro untuk pengetahuan, SWE-bench untuk coding), lalu uji dengan datamu sendiri.
• Iterasi prompt harian → eval set kecil (30–100 contoh) + scorer deterministik + LLM judge; jalankan tiap ada perubahan, di CI kalau bisa.
• Keputusan rilis besar → tambah human evaluation di sampel yang gagal atau ambigu dari tahap otomatis.
• RAG dan agent → metrik komponen terpisah (retrieval vs generasi; perencanaan vs eksekusi tool).
• Selalu → simpan dataset, prompt, dan hasil tiap run; catat versi model dan tanggalnya.

Dan satu prinsip yang mengikat semuanya: evaluasi yang baik dimulai dari pertanyaan "keputusan apa yang akan diambil dari angka ini?" Kalau tidak ada keputusan yang berubah apa pun hasilnya, evaluasinya tidak perlu dijalankan.

FAQ

Apa bedanya evaluasi LLM dengan testing software biasa?

Testing software biasa memeriksa perilaku deterministik terhadap ekspektasi pasti. LLM bersifat probabilistik dan ruang jawabannya terbuka, jadi evaluasi LLM memakai pendekatan statistik: skor agregat di banyak contoh, bukan lolos/gagal per kasus. Keduanya tetap butuh artefak yang bisa diulang — dataset, prompt, dan hasil tersimpan.

Berapa banyak contoh yang cukup untuk eval set internal?

Untuk iterasi cepat, 30–50 contoh berkualitas sudah memberi sinyal arah (membaik atau memburuk). Untuk keputusan rilis, targetkan ratusan contoh dengan cakupan kategori tugas yang seimbang. Yang lebih penting dari jumlah adalah keterwakilan: contoh harus mencerminkan distribusi input nyata, bukan soal yang mudah dibuat.

Apakah LLM-as-a-judge bisa menggantikan penilai manusia sepenuhnya?

Tidak. Juri LLM punya bias sistematis (posisi, verbosity, self-enhancement) dan mewarisi blind spot dari model yang menilainya. Paper aslinya sendiri memosisikannya sebagai aproksimasi preferensi manusia yang skalabel, bukan pengganti. Praktik terbaik: otomatis untuk volume, manusia untuk validasi dan kasus kritis.

Benchmark mana yang paling relevan untuk chatbot customer service?

Tidak ada benchmark publik yang mengukur "customer service" secara langsung. Pakai MT-Bench atau AlpacaEval untuk kemampuan percakapan umum sebagai pembanding awal, tapi keputusan akhir harus dari eval set berisi percakapan nyata produkmu — dengan metrik resolusi tugas, bukan sekadar kefasihan.

Bagaimana cara mendeteksi kontaminasi benchmark?

Tiga sinyal: skor jauh lebih tinggi dari kemampuan yang terlihat di tugas nyata, model "mengingat" soal spesifik saat ditanya, dan performa anjlok di varian soal yang diparafrase. Benchmark modern seperti Humanity's Last Exam melawan ini dengan membuang soal yang bisa dijawab model saat kurasi. Untuk eval internal, buat soal sendiri dari data yang tidak pernah dipublikasikan.

Kesimpulan

Evaluasi LLM bukan ritual mengutip skor leaderboard. Itu proses membangun kepercayaan terhadap angka yang kamu laporkan. Mulai dari benchmark publik untuk orientasi, tapi keputusan produk selalu kembali ke eval set milikmu sendiri: contoh nyata, metrik yang sesuai tugas, dan artefak yang bisa diulang. Tambahkan LLM-as-a-judge untuk skala, pahami biasnya, dan simpan manusia untuk penilaian yang benar-benar penting.

Langkah berikutnya yang paling berdampak: minggu ini, kumpulkan 30 contoh dari log produkmu dan jalankan harness sederhana seperti di atas. Angka pertama itu, betapapun sederhananya, sudah lebih berharga daripada sepuluh demo yang "kelihatannya bagus".

Artikel terkait di blog ini: panduan prompt engineering (prompt yang baik adalah setengah dari evaluasi yang baik), panduan lengkap RAG, perbandingan vector database, dan panduan MCP.