Evaluasi Kualitas Output AI (LLM Evals): Cara Menguji Chatbot dan Agen AI Sebelum dan Sesudah Rilis

Banyak proyek AI berhenti di tahap demo yang memukau. Chatbot menjawab tiga pertanyaan contoh dengan baik, semua orang bertepuk tangan, lalu sistem dirilis ke pelanggan dan ternyata menjawab dengan percaya diri tetapi salah, mengarang kebijakan yang tidak ada, atau berubah perilakunya setelah model diperbarui. Penyebabnya hampir selalu sama: tidak ada cara terukur untuk mengetahui apakah sistem AI itu cukup baik sebelum dan sesudah dirilis.

Evaluasi kualitas output AI, yang sering disebut LLM evals, adalah praktik untuk mengukur hal itu secara sistematis. Bagi bisnis, evaluasi bukan kemewahan teknis. Ia adalah pagar pengaman yang menentukan apakah fitur AI aman diberikan kepada pelanggan, karyawan, atau proses keuangan Anda. Artikel ini membahas apa yang perlu diukur, cara menyusun set uji dari data nyata, metode penilaian, serta cara memantau kualitas setelah rilis.

Ringkasan

• Demo yang bagus bukan bukti kualitas: tanpa set uji tetap, Anda tidak tahu apakah perubahan prompt atau model membuat hasil lebih baik atau lebih buruk
• Set uji terbaik berasal dari pertanyaan, dokumen, dan kasus tepi nyata di bisnis Anda, dilabeli oleh orang yang paham domain
• Gunakan campuran penilaian otomatis, penilaian oleh model lain, dan tinjauan manusia, masing-masing untuk jenis kualitas yang berbeda
• Tetapkan ambang lulus sebelum rilis, jalankan evaluasi setiap kali prompt, model, atau data berubah, dan pantau kualitas di produksi
• Mulailah dengan 50 sampai 100 kasus uji yang representatif, bukan dengan platform evaluasi yang mahal

Mengapa AI tidak bisa diuji seperti software biasa

Pada software konvensional, pengujian relatif mudah: untuk masukan yang sama, keluaran yang diharapkan sama, sehingga satu pengujian otomatis dapat lulus atau gagal. Model bahasa besar bekerja berbeda. Jawabannya berupa teks bebas, bisa benar dengan banyak cara penulisan, dan bisa berubah sedikit pada setiap eksekusi. Pertanyaan yang sama dengan kata yang sedikit berbeda dapat menghasilkan jawaban yang berbeda kualitasnya.

Karena itu, pengujian AI tidak bertanya apakah keluarannya persis sama, melainkan apakah keluarannya memenuhi kriteria kualitas yang kita tetapkan: benar secara fakta, sesuai sumber, sopan, tidak membocorkan data, dan berformat sesuai kebutuhan. Perubahan dari satu pekerjaan uji kecil menjadi disiplin tersendiri inilah yang melahirkan praktik evaluasi.

Risikonya nyata bagi bisnis. Asisten yang salah menyebut harga atau syarat garansi dapat menimbulkan sengketa. Sistem yang meringkas kontrak dengan melewatkan satu klausul penting dapat menyesatkan keputusan. Dan sistem yang bagus hari ini bisa menurun besok karena penyedia model memperbarui versinya tanpa pemberitahuan yang Anda sadari. Tanpa evaluasi, masalah ini baru terlihat setelah pelanggan mengeluh.

Menentukan apa yang dimaksud dengan kualitas

Sebelum membuat set uji, tentukan dahulu dimensi kualitas yang penting untuk kasus penggunaan Anda. Tidak semua dimensi sama pentingnya, dan menyatakannya secara eksplisit mencegah debat tanpa ujung.

• Ketepatan fakta: apakah isi jawaban benar menurut sumber resmi perusahaan
• Kesetiaan pada sumber (groundedness): apakah jawaban hanya memakai informasi dari dokumen yang diberikan, bukan karangan model
• Kelengkapan: apakah poin penting tidak terlewat
• Kepatuhan format: apakah keluaran sesuai struktur yang dibutuhkan sistem lain, misalnya JSON yang valid
• Keamanan dan kepatuhan: apakah menolak permintaan yang seharusnya ditolak dan tidak membocorkan data pribadi
• Nada dan bahasa: apakah sesuai gaya merek dan bahasa pengguna
• Latensi dan biaya: apakah cukup cepat dan cukup murah per permintaan

Untuk asisten layanan pelanggan, ketepatan fakta dan kesetiaan pada sumber biasanya yang utama. Untuk alat pembuat draf pemasaran, nada dan kreativitas lebih penting daripada kebenaran fakta tunggal. Untuk agen yang menjalankan tindakan di sistem, kepatuhan terhadap batas wewenang menjadi syarat mutlak, topik yang dibahas lebih jauh pada artikel tentang keamanan aplikasi AI dari prompt injection dan kebocoran data.

Menyusun set uji dari data nyata

Set uji, sering disebut golden set atau dataset evaluasi, adalah kumpulan kasus dengan masukan dan jawaban atau kriteria yang diharapkan. Kualitasnya menentukan kualitas seluruh evaluasi, sehingga layak diperlakukan seperti aset bisnis.

Sumber kasus uji

Sumber terbaik adalah data yang benar-benar terjadi. Ambil pertanyaan nyata dari log tiket dukungan, riwayat obrolan WhatsApp, kotak surat layanan pelanggan, atau catatan tim penjualan. Pertanyaan nyata biasanya lebih berantakan, lebih singkat, dan lebih ambigu daripada pertanyaan yang dikarang tim teknis, dan di situlah sistem sering gagal. Jika proyek belum berjalan, minta tim yang paling sering menjawab pelanggan untuk menuliskan dua puluh pertanyaan yang paling sering muncul dan dua puluh yang paling sulit.

Pastikan data pribadi dalam contoh dianonimkan sebelum dipakai, sesuai prinsip pelindungan data pribadi. Set uji sering disalin ke berbagai alat dan penyedia, sehingga lebih aman bila bersih sejak awal.

Komposisi yang seimbang

Set uji yang hanya berisi pertanyaan mudah memberi rasa aman palsu. Susun komposisi yang mencerminkan kenyataan:

• Kasus umum yang mewakili sebagian besar lalu lintas, untuk memastikan kinerja dasar
• Kasus tepi, seperti pertanyaan ambigu, pertanyaan dua bahasa, atau pertanyaan dengan salah ketik
• Kasus yang jawabannya memang tidak ada di dokumen, untuk menguji apakah sistem berani berkata tidak tahu
• Kasus berisiko, seperti permintaan memberi diskon di luar kebijakan atau meminta data pelanggan lain
• Kasus serangan, seperti instruksi tersembunyi di dalam dokumen yang dimasukkan pengguna

Untuk permulaan, 50 sampai 100 kasus yang dipilih dengan baik sudah sangat berguna. Tambahkan kasus baru setiap kali ditemukan kegagalan di produksi, sehingga set uji tumbuh bersama pengalaman dan kegagalan yang sama tidak terulang diam-diam.

Pelabelan oleh orang yang paham domain

Jawaban acuan atau kriteria penilaian harus ditulis atau disetujui oleh orang yang benar-benar memahami bisnisnya: staf layanan pelanggan, akuntan, petugas gudang, atau pakar hukum internal. Pelabelan yang diserahkan sepenuhnya kepada vendor sering melewatkan nuansa perusahaan. Catat juga siapa yang melabeli dan kapan, karena kebijakan berubah dan label yang basi menghasilkan evaluasi yang menyesatkan.

Metode penilaian: kombinasi lebih kuat daripada satu cara

Tidak ada satu metode penilaian yang cocok untuk semua dimensi. Praktik yang berhasil memadukan tiga lapisan.

1. Penilaian otomatis berbasis aturan

Beberapa kualitas dapat diperiksa dengan kode sederhana dan hasilnya pasti: apakah keluaran berupa JSON yang valid, apakah memuat kolom wajib, apakah panjangnya dalam batas, apakah mengandung kata terlarang atau pola nomor kartu. Pemeriksaan ini murah, cepat, dan dapat dijalankan pada setiap perubahan. Gunakan sebanyak mungkin untuk hal yang dapat didefinisikan tegas.

2. Penilaian oleh model lain (LLM sebagai juri)

Untuk dimensi yang lebih halus seperti kesetiaan pada sumber atau kejelasan, model bahasa lain dapat diminta menilai jawaban berdasarkan rubrik tertulis, misalnya skala satu sampai lima beserta definisi tiap angka. Metode ini jauh lebih terukur daripada menilai satu per satu secara manual, tetapi punya kelemahan: juri model bisa bias terhadap jawaban panjang, bisa menyukai gaya modelnya sendiri, dan tidak selalu konsisten. Karena itu, kalibrasi juri dengan membandingkan penilaiannya terhadap penilaian manusia pada sampel kecil, dan perbaiki rubrik sampai kesesuaiannya memadai.

3. Tinjauan manusia

Manusia tetap standar emas untuk hal yang menyangkut risiko dan nuansa. Ambil sampel acak dari keluaran, ditambah semua kasus yang dinilai buruk oleh juri otomatis, lalu minta reviewer yang paham domain menilainya. Tinjauan manusia mahal, jadi gunakan secara terarah: sebelum rilis besar, setelah perubahan signifikan, dan secara berkala dengan sampel kecil di produksi.

Untuk sistem berbasis pencarian dokumen seperti chatbot berbasis pengetahuan perusahaan dengan RAG, evaluasi sebaiknya memisahkan dua bagian: apakah pencarian menemukan dokumen yang tepat, dan apakah model menjawab dengan benar berdasarkan dokumen itu. Memisahkannya mempercepat diagnosis, karena perbaikan untuk masalah pencarian sangat berbeda dengan perbaikan untuk masalah jawaban.

Menetapkan ambang lulus dan gerbang rilis

Evaluasi baru berguna jika dihubungkan dengan keputusan. Sebelum rilis, tetapkan ambang lulus yang disepakati pemilik bisnis, bukan hanya tim teknis.

• Tentukan skor minimum per dimensi, misalnya ketepatan fakta minimal 95 persen pada kasus umum
• Tetapkan nol toleransi untuk kategori kritis, misalnya tidak boleh membocorkan data pelanggan lain pada satu pun kasus serangan
• Tetapkan batas regresi, misalnya perubahan tidak boleh menurunkan skor mana pun lebih dari dua poin dibandingkan versi sebelumnya
• Tentukan siapa yang berwenang menyetujui pengecualian dan bagaimana alasannya dicatat

Gerbang semacam ini mirip dengan pengujian otomatis pada pengembangan software biasa. Jika Anda sudah memiliki alur pengujian otomatis dan CI/CD, evaluasi AI dapat dijalankan sebagai langkah tambahan di dalamnya: setiap perubahan prompt, model, atau basis pengetahuan memicu evaluasi, dan rilis tertahan bila skor turun di bawah ambang.

Perubahan apa saja yang perlu memicu evaluasi ulang

Sistem AI memiliki lebih banyak bagian yang dapat berubah daripada software biasa, dan setiap perubahan dapat memengaruhi kualitas.

• Perubahan prompt atau instruksi sistem, bahkan yang tampak sepele seperti satu kalimat tambahan
• Penggantian atau pembaruan versi model, termasuk pembaruan otomatis oleh penyedia
• Perubahan basis pengetahuan: dokumen baru, kebijakan yang direvisi, atau dokumen lama yang dihapus
• Perubahan pengaturan seperti suhu, panjang konteks, atau jumlah dokumen yang diambil
• Penambahan atau perubahan alat yang dapat dipanggil agen
• Perubahan pola pengguna, misalnya produk baru yang menimbulkan jenis pertanyaan baru

Kunci versi model bila memungkinkan, sehingga perubahan hanya terjadi ketika Anda memutuskannya dan sudah mengujinya. Pertimbangan serupa muncul saat memilih antara LLM self-hosted atau API cloud, karena kendali atas versi model berbeda pada tiap pilihan.

Memantau kualitas setelah rilis

Set uji menangkap masalah yang sudah Anda bayangkan. Produksi akan menunjukkan masalah yang belum terbayangkan. Karena itu, evaluasi tidak berhenti saat rilis.

• Catat masukan, keluaran, dokumen yang diambil, dan versi prompt serta model untuk setiap interaksi, dengan pengamanan data yang layak
• Sediakan tombol umpan balik sederhana bagi pengguna, seperti jempol naik atau turun, lalu tinjau semua yang bernilai buruk
• Ambil sampel acak interaksi setiap minggu untuk ditinjau manusia
• Pantau indikator proksi: tingkat eskalasi ke manusia, tingkat pertanyaan diulang, rasio jawaban tidak tahu, dan keluhan
• Lacak biaya per interaksi dan waktu respons, karena penurunan efisiensi sering menjadi tanda awal masalah
• Masukkan setiap kegagalan nyata ke dalam set uji agar tidak terulang

Praktik ini sejalan dengan prinsip observabilitas, log, dan penanganan error: Anda tidak dapat memperbaiki yang tidak dapat Anda lihat.

Kesalahan umum dalam evaluasi AI

• Menguji hanya dengan pertanyaan yang dikarang tim pengembang, sehingga set uji terlalu mudah dan tidak mencerminkan pelanggan nyata
• Mengganti prompt berkali-kali dengan menilai berdasarkan firasat dari tiga contoh, bukan dari set uji tetap
• Mengandalkan satu skor rata-rata yang menyembunyikan kegagalan serius pada kategori kecil tetapi berisiko
• Memakai juri model tanpa pernah mengkalibrasinya terhadap penilaian manusia
• Membocorkan kasus uji ke dalam prompt atau data pelatihan sehingga skor tampak tinggi tetapi menyesatkan
• Tidak memperbarui set uji ketika kebijakan, harga, atau produk berubah
• Menganggap evaluasi sebagai proyek sekali jalan, bukan proses berkelanjutan

Langkah memulai dalam dua sampai empat minggu

1. Pilih satu kasus penggunaan AI yang paling penting atau paling berisiko, jangan semuanya sekaligus.

2. Tulis definisi kualitas dalam satu halaman dan sepakati dengan pemilik bisnis.

3. Kumpulkan 50 sampai 100 kasus nyata yang dianonimkan, termasuk kasus tepi dan kasus berisiko.

4. Minta staf yang paham domain menulis jawaban acuan atau rubrik penilaian.

5. Jalankan sistem saat ini terhadap set uji untuk mendapat skor dasar, sekalipun hasilnya mengecewakan.

6. Bangun penilaian otomatis untuk hal yang pasti, dan juri model yang dikalibrasi untuk hal yang halus.

7. Tetapkan ambang lulus dan jalankan evaluasi sebelum setiap perubahan dirilis.

8. Aktifkan pencatatan dan umpan balik di produksi, lalu tambahkan kegagalan nyata ke set uji.

Pendekatan ini sejalan dengan kebijakan penggunaan AI dan tata kelola AI di perusahaan: hasil evaluasi menjadi bukti bahwa sistem AI diawasi, bukan sekadar dipercaya.

Pertanyaan yang sering diajukan

Apakah kita perlu platform evaluasi khusus? Tidak untuk permulaan. Spreadsheet berisi kasus uji dan satu skrip yang memanggil sistem lalu menilai hasilnya sudah cukup untuk melihat nilai praktik ini. Platform khusus berguna setelah volume dan jumlah anggota tim bertambah.

Apakah penilaian oleh model lain dapat dipercaya? Dapat, dengan syarat rubriknya jelas dan hasilnya dikalibrasi terhadap penilaian manusia pada sampel. Jangan menjadikannya satu-satunya penentu untuk keputusan berisiko tinggi.

Berapa kali evaluasi harus dijalankan? Setiap kali ada perubahan prompt, model, data, atau alat, ditambah pemeriksaan terjadwal mingguan atau bulanan untuk menangkap penurunan yang disebabkan faktor eksternal.

Apakah evaluasi menjamin AI tidak pernah salah? Tidak. Evaluasi mengurangi dan mengukur risiko, bukan menghilangkannya. Karena itu, untuk keputusan berdampak besar tetap sediakan tinjauan manusia dan jalur eskalasi.

Kesimpulan

AI yang andal bukan hasil prompt yang cerdas semata, melainkan hasil proses pengukuran yang disiplin. Dengan definisi kualitas yang jelas, set uji dari data nyata, kombinasi penilaian otomatis dan manusia, ambang lulus sebelum rilis, serta pemantauan setelahnya, bisnis dapat memakai AI dengan keyakinan yang berdasar. Mulailah kecil dengan satu kasus penggunaan dan puluhan contoh nyata. Nilai terbesarnya muncul ketika setiap perubahan dapat dijawab dengan angka, bukan firasat.