Menguji Fitur LLM secara Praktis

Menguji fitur berbasis LLM terasa berbeda dari menguji fungsi biasa. Input yang sama tidak selalu menghasilkan kalimat yang sama, padahal keduanya bisa sama-sama benar.

Karena itu, saya tidak mencoba membandingkan seluruh jawaban dengan satu string yang dianggap sempurna. Yang lebih berguna adalah memeriksa perilaku penting: apakah informasi wajib tersedia, apakah tool yang benar dipilih, dan apakah sistem menolak permintaan yang seharusnya ditolak.

Mulai dari kegagalan yang ingin dicegah

Daftar evaluasi pertama tidak perlu berisi ratusan kasus. Mulailah dari risiko yang paling dekat dengan pengguna.

Untuk learning assistant, contohnya bisa berupa:

• Memberikan jawaban yang tidak didukung materi
• Membuka materi milik kelas lain
• Memanggil tool sebelum informasi wajib tersedia
• Menampilkan detail internal error kepada pengguna
• Menjawab dengan bahasa yang terlalu rumit

Daftar tersebut lebih mudah diubah menjadi test daripada target abstrak seperti “jawaban harus bagus”.

Simpan kasus evaluasi sebagai data

Kasus yang tersimpan secara terstruktur lebih mudah dijalankan ulang ketika prompt atau model berubah.

type EvaluationCase = {
  id: string;
  input: string;
  context?: string[];
  expectedTool?: string;
  mustInclude?: string[];
  mustNotInclude?: string[];
};

const cases: EvaluationCase[] = [
  {
    id: 'ask-for-course-summary',
    input: 'Tolong ringkas materi pada kelas ini.',
    expectedTool: 'search_course_materials',
    mustInclude: ['ringkasan']
  }
];

Dataset kecil yang berasal dari pertanyaan nyata biasanya lebih berharga daripada dataset besar yang dibuat tanpa mengetahui pola penggunaan produk.

Pisahkan pemeriksaan deterministik

Sebagian perilaku dapat diperiksa tanpa model penilai:

• Apakah status response berhasil?
• Apakah tool yang benar dipanggil?
• Apakah argumen memenuhi schema?
• Apakah latency melewati batas?
• Apakah jawaban menyertakan citation?
• Apakah data sensitif muncul?

Pemeriksaan deterministik cepat, murah, dan mudah dijelaskan ketika gagal. Gunakan sebanyak mungkin sebelum menambahkan penilaian berbasis LLM.

Gunakan rubric untuk kualitas jawaban

Hal seperti relevansi, kejelasan, dan tingkat kesulitan bahasa membutuhkan penilaian yang lebih fleksibel. Rubric membuat penilaian tersebut tidak terlalu kabur.

Contoh rubric sederhana:

Nilai	Relevansi
0	Tidak menjawab pertanyaan
1	Menjawab sebagian, banyak informasi tidak relevan
2	Menjawab inti pertanyaan dengan sedikit kekurangan
3	Menjawab lengkap dan tetap fokus

Rubric yang sempit lebih mudah digunakan secara konsisten daripada satu instruksi besar untuk menilai semua aspek jawaban sekaligus.

LLM sebagai penilai bukan sumber kebenaran tunggal

Model dapat membantu memberi skor pada jawaban terbuka, tetapi hasilnya tetap perlu diperiksa. Gunakan prompt penilai yang menyertakan input, context, jawaban, dan rubric. Minta output terstruktur agar hasilnya mudah dibandingkan.

Beberapa langkah yang membantu:

• Gunakan model dan konfigurasi penilai yang tetap
• Nilai satu kriteria dalam satu waktu
• Sertakan alasan singkat bersama skor
• Bandingkan sebagian hasil dengan penilaian manusia
• Jangan gunakan model penilai untuk aturan keamanan yang bisa diperiksa secara pasti

Jika skor otomatis sering berbeda dari manusia, perbaiki rubric atau dataset sebelum mempercayai angka agregatnya.

Ukur perubahan, bukan hanya skor akhir

Evaluasi paling berguna ketika membandingkan versi. Jalankan dataset yang sama terhadap prompt lama dan prompt baru, lalu lihat kasus mana yang membaik atau memburuk.

Baseline pass rate: 82%
Candidate pass rate: 87%
Improved cases: 9
Regressed cases: 4

Angka 87% sendiri tidak banyak bercerita. Empat kasus regresi mungkin justru menyentuh fitur paling penting. Selalu lihat contoh konkret di balik skor.

Catat biaya dan waktu respons

Jawaban yang sedikit lebih baik belum tentu layak jika biaya menjadi tiga kali lipat atau waktu tunggu terlalu lama. Simpan beberapa metrik bersama hasil evaluasi:

• Input dan output token
• Total biaya per kasus
• Time to first token
• Total latency
• Jumlah tool call
• Jumlah retry

Dengan begitu, pemilihan model dan prompt menjadi keputusan produk, bukan perlombaan mendapatkan skor kualitas tertinggi.

Tambahkan kasus dari production

Evaluasi tidak pernah benar-benar selesai. Ketika ditemukan kegagalan baru, ubah kejadian tersebut menjadi test case setelah menghapus data pribadi.

Siklusnya sederhana:

1. Temukan pola kegagalan.
2. Tambahkan contoh yang mewakili pola tersebut.
3. Reproduksi dengan konfigurasi saat ini.
4. Perbaiki prompt, retrieval, tool, atau business rule.
5. Jalankan seluruh evaluasi untuk mencari regresi lain.

Kesimpulan

Evaluasi LLM tidak harus dimulai dengan sistem yang rumit. Dataset kecil, pemeriksaan deterministik, dan rubric yang jelas sudah cukup untuk membuat perubahan lebih terukur.

Tujuannya bukan membuktikan bahwa model selalu benar. Tujuannya mengetahui batas perilaku sistem dan menangkap kegagalan penting sebelum pengguna yang menemukannya.