Evaluasi Output LLM Sebelum Dipakai Produksi
Kalau kamu biasa menguji perangkat lunak, kamu tahu bahwa input yang sama biasanya menghasilkan output yang sama. Pada model bahasa, anggapan itu tidak berlaku. Pertanyaan yang sama bisa dijawab dengan sedikit berbeda tiap kali dipanggil, bahkan dengan pengaturan yang sama. Ketidakpastian inilah yang membuat evaluasi output menjadi bagian wajib, bukan tambahan opsional, sebelum sebuah fitur dipakai di produksi.
Kenapa output LLM tidak deterministik
Model bahasa menghasilkan teks dengan memilih token berikutnya berdasarkan probabilitas. Karena proses pemilihannya punya unsur acak, dua permintaan identik bisa memberi hasil yang tidak identik. Perbedaan ini kadang tidak berarti, tetapi di lain waktu bisa mengubah makna, memutus format, atau menghilangkan detail penting.
Laporan teknis GPT-4 menegaskan bahwa model seperti ini masih bisa keliru dan menghasilkan informasi yang tidak benar. Model yang tampak canggih pada berbagai tolok ukur tetap punya keterbatasan di banyak skenario dunia nyata. Artinya, hasil yang terlihat bagus pada satu contoh belum tentu konsisten di ribuan contoh lain.
Karena itu, mutu tidak bisa dinilai dari satu kali coba. Kamu perlu mengukur perilaku model pada banyak kasus, melihat bagaimana ia gagal, dan mengulang pengukuran setiap kali ada perubahan. Inilah inti dari evaluasi.
Evaluasi otomatis versus penilaian manusia
Ada dua pendekatan besar untuk menilai keluaran model. Yang pertama adalah evaluasi otomatis, di mana kriteria ditulis sebagai kode atau aturan yang bisa dijalankan mesin. Contohnya memeriksa apakah keluaran berupa JSON valid, apakah jawaban memuat kata kunci tertentu, atau apakah formatnya sesuai pola yang diharapkan.
Pendekatan kedua adalah penilaian manusia, di mana orang membaca dan memberi nilai berdasarkan kejelasan, relevansi, atau kesesuaian konteks. Penilaian manusia lebih fleksibel dan bisa menangkap nuansa yang sulit dirumuskan sebagai aturan, tetapi lebih lambat dan lebih mahal.
Kerangka Evals mendukung campuran keduanya. Ada penilai berbasis kode, ada penilai berbasis model, dan ada penilai manusia. Masing-masing punya tempat. Untuk hal yang bisa diukur secara objektif, penilai berbasis kode cepat dan konsisten. Untuk hal yang butuh pertimbangan, penilaian manusia atau penilai model bisa dipakai, dengan catatan hasilnya tetap perlu diperiksa.
Membangun set kasus uji
Langkah paling menentukan adalah menyusun kumpulan kasus uji yang mewakili pemakaian nyata. Kumpulan ini sebaiknya mencakup pertanyaan umum, kasus tepi, input yang membingungkan, dan permintaan yang berpotensi bermasalah. Semakin dekat kasus uji dengan kenyataan, semakin berguna hasilnya.
Praktik yang sehat:
- Kumpulkan contoh nyata dari pemakaian, bukan hanya buatan.
- Sertakan kasus sulit yang pernah membuat model gagal.
- Tentukan jawaban atau perilaku yang diharapkan untuk tiap kasus.
- Tambah kasus baru setiap kali menemukan kegagalan.
- Simpan set uji agar bisa dijalankan ulang kapan pun.
Poin terakhir penting. Set kasus uji yang tersimpan menjadi tolok ukur tetap. Ketika kamu mengganti prompt, menambah tool, atau berpindah versi model, kamu bisa menjalankan set yang sama dan membandingkan hasilnya. Tanpa tolok ukur ini, kamu hanya menebak apakah perubahan membawa perbaikan.
Memilih metrik yang masuk akal
Metrik membuat hasil evaluasi bisa dibandingkan. Untuk tugas yang punya jawaban benar tunggal, kamu bisa mengukur tingkat ketepatan. Untuk keluaran terstruktur, kamu bisa mengukur tingkat keberhasilan validasi skema. Untuk teks bebas, kamu bisa memakai nilai dari penilai manusia atau penilai model.
Yang terpenting, metrik harus selaras dengan tujuan fitur. Kalau yang kamu jaga adalah keamanan dan format, mengukur kelancaran bahasa saja tidak cukup. Pilih beberapa metrik yang saling melengkapi, lalu pantau semuanya. Kadang perbaikan pada satu metrik mengorbankan metrik lain, dan evaluasi membantu kamu melihat pertukaran itu.
Hindari tergoda mengejar satu angka besar yang terlihat mengesankan. Sebuah skor tunggal bisa menyembunyikan kelemahan penting. Misalnya, model yang unggul secara keseluruhan tetap bisa sering gagal pada satu kategori pertanyaan tertentu. Karena itu, pecah hasil evaluasi per jenis kasus, supaya kamu tahu di mana model kuat dan di mana ia rapuh. Rincian seperti ini jauh lebih berguna daripada satu nilai ringkasan.
Memantau di produksi dan mengulang evaluasi
Evaluasi sebelum rilis hanyalah awal. Setelah fitur berjalan, dunia nyata menghadirkan input yang tidak pernah kamu bayangkan. Karena itu, pemantauan di produksi penting. Catat masukan dan keluaran, awasi tingkat kegagalan, dan kumpulkan contoh yang bermasalah untuk dijadikan kasus uji baru.
Panduan praktik produksi menekankan pentingnya menangani hal-hal seperti batas laju permintaan, latensi, biaya, dan risiko penyalahgunaan. Mutu keluaran berdiri berdampingan dengan faktor-faktor ini. Fitur yang akurat tetapi lambat atau mahal tetap bisa gagal dipakai, jadi ukurlah keduanya.
Evaluasi juga harus diulang setiap kali ada perubahan. Mengganti model, mengubah prompt, atau menambah tool bisa menggeser perilaku dengan cara yang tak terduga. Kebiasaan yang baik adalah menjalankan set uji secara teratur, membandingkan hasil antar versi, dan tidak merilis perubahan besar tanpa bukti bahwa mutunya tidak turun.
Menjadikannya kebiasaan, bukan proyek sekali jadi
Evaluasi paling berguna kalau menjadi bagian dari alur kerja rutin, seperti halnya pengujian perangkat lunak. Setiap perubahan melewati set uji, hasilnya dicatat, dan kegagalan ditindaklanjuti. Lama-lama kamu membangun riwayat yang membuat keputusan lebih mudah: versi mana yang lebih baik, perubahan mana yang membawa regresi, dan kasus mana yang masih rapuh.
Dengan pendekatan ini, kualitas tidak lagi bergantung pada keberuntungan tiap panggilan. Ia menjadi sesuatu yang kamu ukur, pantau, dan tingkatkan terus-menerus. Untuk fitur yang dipakai banyak orang, kebiasaan ini adalah pembeda antara sekadar prototipe dan sistem yang bisa dipercaya.
Pada akhirnya, evaluasi bukan sekadar mencari kesalahan. Ia memberimu alasan untuk percaya pada keputusanmu, sekaligus data untuk membantah asumsi yang ternyata keliru. Tim yang mengukur akan lebih cepat belajar, karena setiap perubahan meninggalkan jejak yang bisa ditelusuri.