← Blog · Engineering · 9 min read
Menilai output AI dengan perasaan tidak akan bertahan di produksi. Pelajari cara membangun harness evaluasi yang objektif, dapat diulang, dan menangkap regresi sebelum pengguna.
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Book a call"Coba beberapa pertanyaan, lihat hasilnya, kalau kelihatannya bagus ya kita rilis." Kalimat ini mungkin terdengar wajar di rapat, tetapi ia adalah resep untuk kegagalan yang lambat dan menyakitkan. Menilai output LLM dengan perasaan — sering disebut *vibe check* — bekerja saat Anda punya sepuluh contoh dan satu pasang mata. Ia runtuh total saat Anda punya ribuan permintaan per hari, tiga orang yang menyentuh prompt, dan dua model yang berebut menjadi pilihan.
Masalah mendasar evaluasi berbasis perasaan adalah ia tidak dapat diulang dan tidak dapat dibandingkan. Anda mengubah prompt, mencobanya, merasa "lebih baik", lalu menemukan dua minggu kemudian bahwa perubahan itu diam-diam merusak sepuluh kasus lain yang tidak Anda uji. Tanpa harness evaluasi yang objektif, Anda menerbangkan produk AI dalam kabut. Artikel ini menunjukkan cara membangun evaluasi yang terukur, dapat diulang, dan menangkap regresi sebelum pengguna Anda yang menangkapnya.
Pada perangkat lunak deterministik, sebuah fungsi tambah(2, 2) selalu mengembalikan 4. Tes pass atau fail tanpa ambiguitas. LLM tidak bekerja begitu. Untuk pertanyaan yang sama, model bisa memberi dua jawaban berbeda yang keduanya benar, atau satu jawaban yang 80% benar. Tidak ada satu string "jawaban benar" untuk dicocokkan persis.
Inilah yang membuat banyak tim menyerah pada evaluasi terukur dan kembali ke perasaan. Padahal solusinya bukan menyerah, melainkan mengukur dimensi yang tepat dengan alat yang tepat. Kita tidak mengukur kecocokan string; kita mengukur apakah jawaban benar, relevan, lengkap, dan berakar pada fakta — properti yang bisa dinilai secara sistematis meski tidak deterministik.
Tidak ada evaluasi tanpa data referensi. Golden dataset adalah kumpulan kasus uji yang dikurasi dengan cermat — pasangan input dan output yang diharapkan, atau setidaknya kriteria yang harus dipenuhi output.
Cara membangunnya yang benar:
Ambil dari kenyataan, bukan imajinasi. Sumber terbaik adalah pertanyaan dan kasus nyata dari pengguna atau dari tim operasional yang akan memakai sistem. Pertanyaan yang Anda karang sendiri cenderung terlalu rapi dan tidak mewakili kekacauan dunia nyata.
Sertakan kasus sulit dan kasus tepi. Justru di sinilah model gagal: pertanyaan ambigu, di luar cakupan, atau yang seharusnya dijawab "tidak tahu". Golden dataset yang hanya berisi pertanyaan mudah memberi rasa aman palsu.
Libatkan ahli domain. Untuk produk perbankan, jawaban referensi harus divalidasi tim kepatuhan. Untuk produk hukum, oleh ahli hukum. Label yang salah membuat seluruh evaluasi menyesatkan.
Mulai kecil, tumbuhkan terus. Lima puluh kasus berkualitas tinggi jauh lebih berharga daripada lima ratus kasus asal-asalan. Setiap kali sistem gagal di produksi dengan cara baru, tambahkan kasus itu ke golden dataset agar kegagalan tersebut tidak pernah lolos lagi.
Golden dataset adalah aset jangka panjang paling berharga dalam membangun produk AI. Model dan prompt akan berganti; kasus uji yang baik akan menemani Anda bertahun-tahun.
Untuk produk berbasis RAG dan LLM, beberapa metrik telah terbukti menangkap dimensi kualitas yang penting:
Faithfulness (groundedness). Apakah jawaban benar-benar didukung oleh konteks atau sumber yang diberikan, atau model mengarang? Ini metrik anti-halusinasi terpenting, terutama di sektor di mana jawaban salah punya konsekuensi serius.
Answer relevance. Apakah jawaban benar-benar menjawab pertanyaan, atau hanya berputar-putar di sekitarnya?
Context relevance. Untuk RAG, apakah dokumen yang diambil memang relevan? Memisahkan metrik ini membantu Anda tahu apakah masalahnya di retrieval atau di generasi.
Completeness. Apakah jawaban mencakup semua poin penting, bukan hanya satu dari tiga syarat yang seharusnya disebutkan?
Correctness terhadap referensi. Untuk pertanyaan berjawaban faktual, apakah jawaban sesuai dengan jawaban referensi golden.
Yang penting: pilih metrik sesuai jenis produk. Chatbot CS butuh penekanan berbeda dari asisten ekstraksi dokumen. Jangan mengukur segalanya; ukur yang menentukan keberhasilan produk Anda.
Bagaimana menilai "faithfulness" secara otomatis pada ribuan kasus tanpa membayar manusia membaca semuanya? Di sinilah LLM-as-judge masuk: gunakan sebuah model untuk menilai output model lain berdasarkan rubrik yang ketat.
Agar teknik ini dapat dipercaya, beberapa praktik penting:
Rubrik eksplisit, bukan opini. Jangan minta judge "nilai bagus atau tidak". Beri kriteria spesifik: "Beri skor 1 jika setiap klaim dalam jawaban didukung oleh konteks; 0 jika ada klaim yang tidak ada di konteks." Semakin terstruktur rubrik, semakin konsisten penilaian.
Minta alasan sebelum skor. Memaksa judge menuliskan justifikasi sebelum memberi angka meningkatkan kualitas dan memberi Anda jejak untuk audit.
Kalibrasi terhadap manusia. Sesekali, bandingkan penilaian judge dengan penilaian ahli pada sampel. Jika keduanya banyak berbeda, perbaiki rubrik. Judge yang tidak terkalibrasi hanya memindahkan masalah.
Waspadai bias. Model judge punya kecenderungan, misalnya menyukai jawaban panjang. Sadari ini saat menafsirkan skor.
LLM-as-judge tidak sempurna, tetapi jauh lebih konsisten dan dapat diskalakan daripada penilaian manusia ad hoc. Yang penting bukan kesempurnaan absolut, melainkan konsistensi yang cukup untuk membandingkan versi A dengan versi B secara adil.
Evaluasi punya dua momen yang sama pentingnya.
Evaluasi offline terjadi sebelum rilis, di lingkungan pengembangan, terhadap golden dataset. Inilah tempat Anda mencegah regresi masuk ke produksi. Setiap perubahan prompt, model, atau parameter dijalankan melawan golden dataset dan dibandingkan dengan baseline.
Evaluasi online terjadi di produksi, terhadap trafik nyata. Karena Anda tidak punya jawaban referensi untuk query pengguna yang baru, evaluasi online mengandalkan sinyal lain: skor faithfulness otomatis pada sampel, umpan balik pengguna (thumbs up/down), tingkat eskalasi ke manusia, dan deteksi anomali. Evaluasi online menangkap pergeseran yang tidak pernah Anda bayangkan saat membuat golden dataset — pola pertanyaan baru, perubahan perilaku model penyedia, atau degradasi data.
Keduanya saling menyusui: temuan dari online menjadi kasus baru di golden dataset offline.
Evaluasi yang hanya dijalankan manual sesekali akan terlupakan saat tim sibuk. Kekuatan sejati muncul ketika evaluasi menjadi gerbang regresi otomatis di pipeline CI Anda.
Polanya sederhana namun ampuh:
Setiap perubahan kode atau prompt yang menyentuh perilaku AI memicu eksekusi golden dataset secara otomatis.
Hasil dibandingkan dengan baseline yang tersimpan.
Jika metrik kunci turun melewati ambang yang Anda tetapkan, build gagal — sama seperti tes unit yang gagal menghentikan rilis.
Dengan ini, kualitas AI berhenti menjadi tanggung jawab heroik satu orang dan menjadi properti sistem yang dijaga otomatis. Seorang engineer yang tanpa sengaja merusak faithfulness dengan "memperbaiki" sebuah prompt akan langsung tahu, bukan dua minggu kemudian dari keluhan pengguna.
Ingat untuk menetapkan ambang yang realistis: karena LLM stokastik, sedikit variasi antar-jalankan adalah normal. Gunakan ambang yang menangkap regresi nyata tanpa menghasilkan alarm palsu yang membuat tim mengabaikannya.
Satu dimensi yang sering luput dari panduan evaluasi yang ditulis untuk audiens global: tantangan khusus saat produk Anda beroperasi dalam Bahasa Indonesia. Mengabaikan ini membuat evaluasi Anda buta terhadap kegagalan yang justru paling sering dialami pengguna lokal.
Beberapa hal yang perlu masuk ke golden dataset dan rubrik penilaian Anda:
Variasi formal dan informal. Pengguna Indonesia berpindah-pindah antara bahasa baku, bahasa percakapan, dan singkatan. Golden dataset yang hanya berisi pertanyaan formal akan memberi rasa aman palsu, karena pengguna nyata bertanya dengan cara yang jauh lebih santai.
Code-switching. Campuran Bahasa Indonesia dan Inggris ("tolong cek statusnya dong, sudah di-approve belum?") lazim di lingkungan profesional. Sistem dan evaluasi Anda harus menanganinya.
Akurasi istilah lokal dan domain. Untuk produk perbankan atau hukum, istilah seperti nama produk, singkatan regulasi, atau frasa hukum harus dinilai akurat oleh ahli domain lokal, bukan oleh penilai generik.
Sensitivitas judge terhadap Bahasa Indonesia. Jika Anda memakai LLM-as-judge, verifikasi bahwa model judge menilai output Bahasa Indonesia secara konsisten. Beberapa model lebih lemah menilai nuansa dalam bahasa non-Inggris, dan judge yang tidak akurat membuat seluruh evaluasi menyesatkan.
Memasukkan dimensi lokal ini bukan formalitas. Ia menangkap kelas kegagalan yang tidak akan pernah muncul jika Anda mengevaluasi seolah-olah produk Anda berbahasa Inggris, padahal pengguna Anda jelas tidak.
Harness evaluasi yang canggih tidak ada gunanya jika tim memperlakukannya sebagai formalitas. Pergeseran terpenting bersifat budaya: setiap perubahan pada sistem AI harus disertai pertanyaan "apa dampaknya pada metrik kita?" Setiap kegagalan produksi harus berakhir sebagai kasus uji baru. Setiap klaim "ini lebih baik" harus didukung angka, bukan kesan.
Tim yang menanamkan disiplin ini bergerak lebih cepat dalam jangka panjang, bukan lebih lambat — karena mereka bisa bereksperimen dengan berani, tahu bahwa jaring pengaman akan menangkap mereka jika salah langkah. Itulah perbedaan antara produk AI yang membaik dari waktu ke waktu dan produk yang perlahan membusuk.
Salah satu alasan tim tidak pernah memulai evaluasi adalah membayangkannya sebagai proyek raksasa: platform khusus, ratusan metrik, infrastruktur rumit. Akibatnya mereka menunda terus dan kembali ke vibe check. Kenyataannya, evaluasi yang berguna bisa dimulai sangat sederhana dan tumbuh seiring kebutuhan.
Jalur awal yang realistis untuk tim Indonesia dengan sumber daya terbatas:
Minggu pertama: kumpulkan 30 kasus nyata. Ambil dari log produksi atau dari tim operasional. Tuliskan input dan jawaban yang seharusnya, divalidasi satu ahli domain. Simpan dalam format sederhana — bahkan spreadsheet cukup untuk memulai.
Minggu kedua: skor manual. Jalankan sistem pada 30 kasus itu dan nilai setiap output terhadap kriteria yang jelas. Ya, ini manual dan lambat, tetapi memberi Anda angka baseline pertama yang objektif. Sekarang Anda tahu posisi sebenarnya.
Minggu ketiga: otomasi dengan LLM-as-judge. Ubah penilaian manual menjadi rubrik untuk model judge, lalu kalibrasi terhadap penilaian manual Anda sebelumnya. Sekarang evaluasi bisa dijalankan kapan saja dengan biaya rendah.
Seterusnya: integrasikan ke alur kerja. Jalankan evaluasi otomatis setiap kali ada perubahan, dan jadikan gerbang sebelum rilis.
Pesannya: evaluasi yang tidak sempurna tetapi konsisten jauh lebih berharga daripada evaluasi sempurna yang tidak pernah dibangun. Mulai kecil, buktikan nilainya, lalu investasikan lebih banyak setelah tim melihat manfaatnya.
Punya angka tidak otomatis berarti membuat keputusan yang benar. Beberapa kesalahan tafsir yang umum bisa menjerumuskan tim yang baru mengadopsi evaluasi.
Jangan mengejar satu angka agregat. Skor rata-rata yang naik bisa menyembunyikan kenyataan bahwa sistem membaik pada kasus mudah tetapi memburuk pada kasus kritis. Selalu lihat distribusi dan, khususnya, kasus yang gagal. Satu kegagalan pada pertanyaan kepatuhan perbankan bisa lebih merusak daripada peningkatan pada sepuluh pertanyaan sepele.
Bedakan masalah retrieval dari masalah generasi. Untuk RAG, jika jawaban buruk, periksa apakah konteks yang diambil memang relevan. Memperbaiki prompt tidak akan menolong jika masalahnya ada di retrieval yang mengambil dokumen salah.
Hormati sifat stokastik. Karena LLM tidak deterministik, perbedaan kecil antar-jalankan adalah normal. Jangan bereaksi berlebihan terhadap fluktuasi minor; cari tren yang konsisten lintas beberapa eksekusi.
Jaga golden dataset tetap relevan. Jika pola pertanyaan pengguna bergeser tetapi golden dataset Anda statis, Anda mengukur masalah lama. Tinjau dan perbarui dataset secara berkala dengan kasus dari produksi.
Evaluasi adalah kompas, bukan autopilot. Ia memberi tahu arah, tetapi penilaian tim tetap dibutuhkan untuk memutuskan apa yang benar-benar penting bagi produk dan pengguna Anda.
Evaluasi yang terukur adalah perbedaan antara produk AI yang Anda percayai dan produk yang Anda harap-harap cemas. Golden dataset, metrik yang tepat, LLM-as-judge yang terkalibrasi, dan gerbang regresi di CI bukan kemewahan — ia syarat untuk berani naik ke produksi dan tetap di sana.
Sainskerta Solusi Nusantara membantu tim Indonesia membangun fondasi evaluasi ini dari awal: menyusun golden dataset bersama ahli domain Anda, mendesain metrik yang relevan dengan produk, dan mengintegrasikan gerbang kualitas ke alur pengembangan. Jika Anda ingin keluar dari mode vibe check dan mulai mengukur kualitas AI secara objektif, jadwalkan sesi konsultasi dengan tim kami lewat halaman Kontak. Mari kita pastikan setiap rilis AI Anda lebih baik, bukan diam-diam lebih buruk.
