Anda mengirimkan fitur bertenaga LLM enam bulan lalu. Ini diuji dengan baik sebelum diluncurkan. Pengguna tampak senang pada awalnya. Namun belakangan ini, tiket dukungan tentang kualitas AI semakin meningkat. Penyedia model memberikan pembaruan bulan lalu yang tidak terlalu Anda evaluasi. Kumpulan data evaluasi Anda belum disegarkan sejak diluncurkan. Dan tim yang membuat fitur tersebut telah beralih ke proyek lain, hanya memeriksa jika ada kerusakan yang cukup parah sehingga memerlukan perhatian.
Ini adalah lintasan default untuk fitur LLM tanpa evaluasi berkelanjutan. Model berubah, data berubah, ekspektasi pengguna berubah, dan tidak ada yang menyadari penurunan kualitas hingga hal ini menjadi masalah nyata.
LLM evaluasi retrospektif adalah praktik yang mencegah pembusukan yang lambat ini. Bukan fase pengujian yang dilakukan satu kali sebelum peluncuran, namun kebiasaan berulang dalam mengukur kualitas, memahami kegagalan, dan melakukan peningkatan secara sistematis.
Mengapa Evaluasi LLM Berbeda Secara Mendasar
Jika Anda berasal dari pengembangan perangkat lunak tradisional, naluri Anda tentang pengujian akan menyesatkan Anda dengan LLMs. Inilah alasannya:
Keluaran bersifat non-deterministik. Masukan yang sama dapat menghasilkan keluaran yang berbeda setiap saat. Ini berarti Anda tidak dapat menguji dengan pernyataan sederhana "output yang diharapkan sama dengan output aktual". Anda perlu mengevaluasi kualitas keluaran pada suatu spektrum, bukan dengan lulus/gagal biner.
Kebenaran bersifat subjektif. Untuk banyak tugas LLM, tidak ada satu jawaban yang benar. Ringkasan yang bagus, tanggapan layanan pelanggan yang membantu, email yang ditulis dengan baik — ini melibatkan keputusan penilaian yang tidak disetujui oleh orang-orang yang berakal sehat. Kerangka evaluasi Anda perlu menangani subjektivitas ini secara eksplisit.
Kualitas menurun secara diam-diam. Perangkat lunak tradisional rusak parah: kesalahan, kerusakan, pengujian yang gagal. LLM kualitas menurun secara bertahap: keluaran yang dihasilkan sedikit kurang akurat, nada yang sedikit berbeda, tanggapan yang sedikit kurang relevan. Saat seseorang menyadarinya, kualitasnya mungkin telah menurun selama berminggu-minggu.
Model di bawah Anda berubah. Jika Anda menggunakan model berbasis API (yang merupakan sebagian besar tim), penyedia model dapat memperbarui model kapan saja. Pembaruan ini biasanya memperbaiki keadaan secara keseluruhan, namun dapat mengubah perilaku kasus penggunaan spesifik Anda dengan cara yang tidak Anda harapkan.
Perbedaan ini berarti Anda memerlukan praktik evaluasi berkelanjutan, bukan pendekatan uji coba.
Apa yang Harus Diukur
Anda tidak perlu mengukur semuanya. Anda perlu mengukur hal-hal yang penting untuk kasus penggunaan spesifik Anda, dan mengukurnya secara konsisten untuk melihat tren. Berikut kerangka praktisnya.
Akurasi dan Kesetiaan
Apakah model menghasilkan informasi yang benar? Dimensi ini paling penting untuk tugas faktual: menjawab pertanyaan, merangkum, mengekstraksi data, menganalisis.
Cara mengevaluasi: Ambil contoh hasil produksi terkini. Minta peninjau manusia untuk memeriksa masing-masing kesalahan faktual, halusinasi (informasi yang tidak didukung oleh konteks yang diberikan), dan kelalaian (informasi penting yang tersedia tetapi tidak disertakan).
Apa yang harus dilacak: Tingkat kesalahan faktual per sampel, dan apakah trennya naik atau turun. Lacak juga tingkat keparahan kesalahannya — nama yang salah eja tidak terlalu mengkhawatirkan dibandingkan angka keuangan yang salah.
Instruksi Mengikuti
Apakah model melakukan apa yang Anda minta? Hal ini mencakup kepatuhan format, kepatuhan batasan, dan penyelesaian tugas.
Cara mengevaluasi: Tetapkan kriteria yang jelas tentang seperti apa pelaksanaan tugas yang "benar". Apakah outputnya sesuai dengan format yang diminta? Apakah ini menghormati batasan panjang? Apakah itu tetap berada dalam cakupan yang ditentukan? Penilaian ini lebih dapat diukur secara obyektif dibandingkan penilaian kualitas.
Apa yang harus dilacak: Persentase keluaran yang mengikuti semua instruksi. Kategorikan pelanggarannya — apakah itu masalah format, pelanggaran batasan, atau penyimpangan cakupan? Masing-masing menunjuk ke perbaikan yang berbeda.
Kualitas yang Dipersepsikan Pengguna
Apakah pengguna menganggap keluarannya bermanfaat, ditulis dengan baik, dan berguna? Ini adalah dimensi yang paling sulit diukur namun bisa dibilang paling penting.
Cara mengevaluasi: Dua pendekatan bekerja dengan baik. Pertama, sinyal dalam produk: suka/tidak suka, penilaian eksplisit, pertanyaan lanjutan (jika pengguna menanyakan tindak lanjut, respons pertama mungkin belum lengkap). Kedua, evaluasi manusia secara berkala: ambil sampel dan beri peringkat pada rubrik yang mendefinisikan arti "baik" untuk fitur Anda.
Apa yang harus dilacak: Tren kepuasan keseluruhan dan dimensi kualitas spesifik tempat pengguna mengungkapkan ketidakpuasan.
Keamanan dan Keselarasan
Apakah model menghasilkan keluaran yang merugikan, bias, atau tidak sesuai? Dimensi ini adalah taruhannya — kegagalan di sini memiliki dampak yang sangat besar.
Cara mengevaluasi: Jalankan rangkaian uji keamanan Anda secara teratur (tidak hanya saat peluncuran). Sertakan pengujian permusuhan: masukan yang dirancang untuk memicu keluaran yang merugikan. Tinjau setiap keluaran yang ditandai oleh lapisan moderasi konten Anda.
Apa yang harus dilacak: Tingkat pelanggaran keselamatan, termasuk nyaris celaka yang tertangkap oleh filter. Lacak hasil pengujian yang berlawanan di seluruh pembaruan model — model yang aman sebelum pembaruan mungkin tidak aman setelahnya.
Evaluasi Retrospektif
Irama
Bulanan berfungsi dengan baik untuk sebagian besar tim. Lebih sering jika Anda berada di domain berisiko tinggi (layanan kesehatan, keuangan, hukum) atau jika Anda mengulangi perintah dengan cepat. Lebih jarang jika fitur Anda stabil dan berisiko rendah — namun tidak pernah kurang dari triwulanan.
Persiapan
Retrospektif hanya akan sebaik data yang Anda berikan. Seseorang dalam tim (rotasi peran ini) perlu mempersiapkan:
Dasbor metrik. Metrik kualitas utama Anda untuk periode saat ini, dibandingkan periode sebelumnya. Jaga agar hal ini tetap fokus — maksimum 4-6 metrik, yang terkait langsung dengan dimensi di atas.
Contoh hasil evaluasi. Jalankan rangkaian evaluasi Anda dan tampilkan hasilnya. Jika Anda melakukan evaluasi manusia, selesaikan sebelum rapat, bukan selama rapat.
Contoh kegagalan. 5-10 keluaran terburuk pada periode tersebut. Sertakan konteks lengkap: masukan, perintah, keluaran, dan mengapa itu buruk. Contoh nyata inilah yang menjadi tempat terjadinya diskusi paling produktif.
Changelog. Perubahan apa pun yang mungkin memengaruhi kualitas: pembaruan cepat, perubahan versi model, pembaruan data, perubahan fitur, perubahan pola penggunaan.
Struktur Rapat (60 menit)
Peninjauan metrik (10 menit). Apakah kita meningkat, menurun, atau tetap pada setiap dimensi? Adakah metrik yang melewati ambang batas yang kami pedulikan? Adakah perubahan tak terduga yang tidak dapat kami jelaskan?
Menyelami kegagalan secara mendalam (25 menit). Telusuri contoh kegagalan. Untuk masing-masingnya, tim harus mendiskusikan:
- Apa yang salah secara spesifik?
- Apakah ini mode kegagalan baru atau yang pernah kita lihat sebelumnya?
- Apa penyebab utama — prompt, model, data, atau hal lainnya?
- Bagaimana cara kami mengetahui hal ini secara otomatis di masa mendatang?
Tujuannya bukan untuk memperbaiki setiap kegagalan dalam rapat. Tujuannya untuk memahami pola dan memprioritaskan.
Tinjauan proses evaluasi (10 menit). Apakah evaluasi kita benar-benar mengukur hal yang benar? Apakah ada mode kegagalan yang tidak kita tangkap? Apakah kami perlu memperbarui kasus pengujian kami? Apakah kriteria evaluasi kami masih selaras dengan hal yang menjadi perhatian pengguna?
Tinjauan meta ini penting. Proses evaluasi bisa menjadi membosankan seperti hal lainnya. Jika kasus pengujian Anda semuanya berasal dari enam bulan yang lalu dan kebutuhan pengguna telah berubah, evaluasi Anda memberikan Anda rasa aman yang salah.
Item tindakan (15 menit). Pilih 2-3 peningkatan spesifik. Ini biasanya terbagi dalam kategori:
- Mendorong perubahan untuk mengatasi pola kegagalan tertentu
- Peningkatan evaluasi (kasus pengujian baru, rubrik yang diperbarui, otomatisasi yang lebih baik)
- Pembaruan pagar pembatas (filter keamanan baru, pemeriksaan pasca-pemrosesan tambahan)
- Tugas investigasi (gali perubahan kualitas yang tidak dapat dijelaskan, buat profil mode kegagalan tertentu)
Membangun Tumpukan Evaluasi Anda
Anda tidak memerlukan peralatan mahal untuk memulai. Berikut kemajuan praktisnya.
Fase 1: Evaluasi Manual (Mulai dari Sini)
Mingguan, sampel 20-30 hasil produksi. Mintalah dua anggota tim secara independen menilai masing-masing rubrik kualitas Anda. Bandingkan penilaian mereka — jika mereka sering berbeda pendapat, rubrik Anda harus lebih spesifik. Lacak peringkat ini dalam spreadsheet.
Ini tidak menarik namun efektif. Anda akan mempelajari lebih lanjut perilaku model Anda dengan membaca 30 keluaran nyata dibandingkan dengan metrik otomatis mana pun.
Fase 2: Evaluasi Semi-Otomatis
Buat kumpulan data evaluasi: 100-200 contoh dengan masukan, karakteristik keluaran yang diharapkan (belum tentu keluaran yang tepat), dan anotasi kualitas. Jalankan ini secara otomatis setiap kali Anda mengubah perintah atau model. Gunakan hasilnya untuk menangkap regresi sebelum mencapai produksi.
Tambahkan evaluasi LLM sebagai juri untuk dimensi yang berfungsi dengan baik: kepatuhan format, mengikuti instruksi, verifikasi faktual dasar. Gunakan evaluasi manusia untuk dimensi yang tidak: nuansa, kegunaan, kesesuaian nada.
Fase 3: Pemantauan Berkelanjutan
Siapkan pemeriksaan kualitas otomatis pada lalu lintas produksi. Ikan ini tidak perlu menangkap semuanya — mereka perlu menangkap cukup banyak untuk mengingatkan Anda ketika kualitas berubah secara signifikan. Pendekatan sederhana: ambil sampel secara acak sebagian kecil kueri produksi, jalankan pemeriksaan otomatis, dan beri peringatan jika tingkat kegagalan melebihi ambang batas.
Ini melengkapi dan bukan menggantikan evaluasi manusia Anda. Pemantauan otomatis menangkap perubahan mendadak dengan cepat. Evaluasi manusia menangkap penyimpangan kualitas halus yang terlewatkan oleh metrik otomatis.
Kesalahan Umum dalam Evaluasi
Mengevaluasi hanya berdasarkan contoh yang mudah. Jika kumpulan data evaluasi Anda tidak menyertakan kasus sulit, Anda mengukur kinerja kasus terbaik, bukan kinerja dunia nyata. Sertakan masukan yang bersifat permusuhan, kueri yang ambigu, konten khusus domain, dan jenis masukan berantakan yang dikirimkan oleh pengguna Anda yang sebenarnya.
Menggunakan metrik otomatis sebagai satu-satunya ukuran. Metrik otomatis (BLEU, ROUGE, BERTScore) berguna untuk melacak tren namun berkorelasi buruk dengan penilaian kualitas manusia untuk banyak tugas. Jika metrik otomatis Anda menyatakan kualitas baik-baik saja tetapi pengguna mengeluh, percayalah pada pengguna.
Membandingkan model pada kumpulan evaluasi yang berbeda. Jika Anda mengevaluasi apakah akan mengganti model, gunakan kumpulan evaluasi yang sama persis untuk keduanya. Jika Anda menguji Model A pada satu kumpulan contoh dan Model B pada kumpulan contoh yang berbeda, perbandingannya tidak ada artinya.
Tidak melacak kesepakatan antar penilai. Jika manusia evaluator Anda tidak setuju pada 40% penilaian, data evaluasi Anda bermasalah. Sempurnakan rubrik Anda, berikan lebih banyak pelatihan, atau terima bahwa tugas tersebut bersifat subjektif dan rancang metrik Anda sesuai dengan itu.
Terlalu jarang mengevaluasi. Evaluasi bulanan dengan perubahan model mingguan berarti Anda selalu melihat data yang sudah usang. Cocokkan irama evaluasi Anda dengan irama perubahan Anda.
Menjadikan Evaluasi Bagian dari Budaya
Bagian tersulit dari evaluasi LLM bukanlah metodologinya — namun mempertahankan praktiknya. Evaluasi terasa seperti overhead, terutama ketika segala sesuatunya berjalan dengan baik. Godaan untuk melewatkan "bulan ini saja" memang nyata.
Apa yang membantu: membuat hasil evaluasi terlihat. Bagikan di saluran tim. Rayakan peningkatan kualitas. Perlakukan regresi kualitas sebagai insiden yang patut diselidiki. Ketika evaluasi mengungkap suatu masalah sebelum pengguna menyadarinya, buatlah masalah tersebut terlihat juga — hal ini membenarkan investasi yang sedang dilakukan.
Seiring waktu, tim dengan praktik evaluasi yang kuat mengembangkan intuisi yang lebih baik tentang model mereka. Mereka mengantisipasi mode kegagalan. Mereka membuat perubahan cepat dengan lebih percaya diri. Mereka menangkap masalah lebih cepat ketika masalah itu benar-benar terjadi. Retrospektif adalah mekanisme yang membangun pengetahuan institusional tersebut.
Coba NextRetro gratis — Susun retrospektif evaluasi Anda dengan tahapan untuk peninjauan metrik, analisis kegagalan, dan perencanaan peningkatan.
Terakhir Diperbarui: Februari 2026
Waktu Membaca: 8 menit
