Mengevaluasi Output LLM Secara Objektif

Salah satu kebiasaan buruk yang paling sering saya lihat ketika tim mulai serius pakai LLM di produksi adalah: ganti prompt, coba beberapa contoh manual, kelihatan lebih bagus, langsung deploy. Masalahnya, "kelihatan lebih bagus" itu bias yang sangat kuat. Kita cenderung menguji dengan kasus yang kita ingat bermasalah, lalu puas begitu kasus itu membaik, padahal bisa saja perubahan itu memperbaiki satu hal dan merusak lima hal lain yang tidak kita cek. Di sistem yang berurusan dengan data sensitif seperti rekam medis, kebiasaan ini berisiko besar. Karena itu saya selalu mendorong tim untuk punya benchmark kecil sebelum mempercayai perubahan apa pun pada prompt atau model.

Kenapa Uji Coba Manual Tidak Cukup

Uji coba manual gagal karena tiga alasan yang saling berkaitan. Pertama, sampelnya kecil dan dipilih secara tidak acak — biasanya kasus yang paling gampang diingat, bukan yang paling representatif. Kedua, tidak ada baseline yang tercatat, jadi kita membandingkan hasil baru dengan ingatan kita soal hasil lama, bukan dengan angka konkret. Ketiga, evaluasinya subjektif: satu orang bilang bagus, orang lain bisa menilai berbeda untuk kasus yang sama. Ketiga hal ini membuat keputusan "prompt ini lebih baik" jadi rapuh, dan biasanya baru ketahuan salah setelah masalah muncul di lingkungan nyata.

Membangun Benchmark Kecil yang Berguna

Benchmark tidak harus besar untuk berguna. Yang penting tiga hal: representatif, punya jawaban rujukan, dan bisa dijalankan ulang secara otomatis. Langkah praktisnya kira-kira begini:

Kumpulkan set kasus tetap — sebagai ilustrasi, misalnya 30-50 contoh input nyata yang mencakup kasus umum, kasus edge, dan kasus yang pernah gagal sebelumnya.
Untuk setiap kasus, tentukan jawaban rujukan atau kriteria penilaian yang jelas, bukan sekadar "kelihatan masuk akal".
Simpan set ini sebagai file statis (JSON atau CSV sederhana) yang tidak berubah kecuali disengaja, supaya perbandingan antar versi prompt adil.

Contoh struktur yang sering saya pakai untuk kasus semacam ini:

{
  "id": "case-014",
  "input": "...",
  "expected": "...",
  "criteria": ["mengandung diagnosis utama", "format sesuai skema"]
}

Dengan struktur seperti ini, saya bisa menjalankan prompt lama dan prompt baru terhadap seluruh set, lalu membandingkan skor agregatnya, bukan cuma satu-dua contoh yang kebetulan terlihat.

Memilih Metrik yang Tidak Menipu

Bagian yang paling sering salah kaprah adalah memilih metrik. Skor kemiripan teks (semacam exact match atau similarity) mudah dihitung tapi gampang menyesatkan — output bisa mirip secara teks tapi salah secara substansi, atau berbeda kata tapi benar secara makna. Untuk tugas yang butuh penilaian kualitatif, pendekatan yang lebih tahan lama adalah kombinasi: metrik otomatis untuk hal yang bisa diverifikasi secara struktural (format, keberadaan field wajib, validitas terhadap skema), plus rubrik penilaian yang jelas untuk hal yang lebih nuansa, dinilai manusia atau LLM lain sebagai juri dengan kriteria eksplisit. Kuncinya bukan mencari satu angka ajaib, tapi memastikan metrik itu benar-benar mengukur hal yang kita pedulikan, dan kita tahu batas-batas metriknya.

Menjadikannya Kebiasaan, Bukan Proyek Sekali Jalan

Benchmark yang hanya dijalankan sekali nilainya terbatas. Yang membuatnya bermanfaat jangka panjang adalah menjalankannya setiap kali ada perubahan pada prompt, model, atau parameter, lalu membandingkan skor sebelum dan sesudah secara eksplisit. Saya juga membiasakan menambah kasus baru ke benchmark setiap kali menemukan kegagalan di produksi — supaya set uji ini terus berkembang mengikuti realita, bukan statis selamanya.

Takeaway

Mempercayai perubahan pada sistem LLM hanya karena "terasa lebih baik" adalah cara paling mudah untuk kecolongan regresi diam-diam. Investasi kecil membangun benchmark — set kasus representatif, kriteria penilaian jelas, dan kebiasaan menjalankannya di setiap perubahan — jauh lebih murah daripada menanggung akibat perubahan yang ternyata memperburuk sesuatu yang tidak sempat dicek secara manual.