Eval Harness: Disiplin Wajib Brand Indonesia Sebelum Deploy Update Chatbot AI di 2026

TL;DR: Eval harness adalah pipeline yang menjalankan kumpulan tes evaluasi AI otomatis (akurasi, faithfulness, biaya, latency) setiap kali ada perubahan, lalu mencatat hasil untuk dibandingkan antar versi. Tanpa eval harness, brand Indonesia tidak punya cara objektif memutuskan apakah update prompt atau pergantian model membuat chatbot membaik atau memburuk. Tiga komponen wajibnya: eval set, scorer, threshold gate.

Pola yang sering saya temui di brand Indonesia yang baru adopsi chatbot AI: tim mengubah prompt sistem, mengetik 5-10 contoh manual, lalu deploy ke produksi karena "kelihatannya lebih baik". Beberapa hari kemudian muncul keluhan baru dari user, dan tidak ada cara objektif untuk membuktikan apakah update tersebut yang menyebabkannya atau memang regresi spontan.

Disiplin yang menutup celah ini adalah eval harness. Pendekatannya tidak rumit, tapi konsisten diabaikan sampai ada insiden besar.

Apa Itu Eval Harness dan Bedanya dengan QA Manual

Eval harness adalah versi unit test untuk sistem AI. Sebuah pipeline menjalankan kumpulan tes evaluasi otomatis setiap kali ada perubahan, mencatat skor di setiap dimensi (akurasi, faithfulness, biaya, latency), dan membandingkannya dengan versi sebelumnya.

Beda dengan QA manual yang sering rapuh karena bias konfirmasi, eval harness memaksa keputusan berbasis bukti. Tim tidak lagi berdebat "rasa-rasanya lebih bagus", tapi membandingkan angka konkret di dataset evaluasi yang sama.

Tiga Komponen Wajib

Eval set adalah dataset uji yang merepresentasikan distribusi real produksi. Mulai dari 50 kasus yang menutupi top intents dan edge case yang pernah dilaporkan. Tambah 10-20 kasus tiap kali ditemukan bug baru di produksi. Eval set bukan hal statis, ia tumbuh seiring brand belajar.

Scorer menentukan bagaimana setiap output dinilai. Untuk tugas dengan jawaban tegas (SKU, harga, status pesanan), pakai exact match atau regex. Untuk jawaban bebas, kombinasikan rubric scoring dengan LLM as judge, dan validasi sample dengan reviewer manusia tiap minggu untuk kalibrasi.

Threshold gate adalah aturan pass/fail. Misalnya: skor akurasi turun lebih dari 3% dari baseline maka build diblokir. Threshold ini yang membuat eval harness benar-benar guard rail, bukan sekadar dasbor yang dilihat sesekali.

Studi Kasus dari Lapangan

Saat membangun chatbot konsultasi awal di Vetmo, tim awalnya merilis update prompt setiap minggu tanpa eval harness. Dua bulan jalan, kami sadar ada regresi senyap: chatbot mulai sering memberikan saran "konsultasi langsung ke dokter" untuk kasus yang sebenarnya bisa dijawab edukatif. Setelah dipasang eval harness dengan 120 kasus uji yang dikurasi dari log produksi, akar masalah ketemu di update prompt 5 minggu sebelumnya. Sejak itu, tidak ada update yang dirilis tanpa lewat harness, dan iterasi justru jadi lebih cepat karena tim lebih percaya diri.

Pola serupa diterapkan di Atmo (LMS) untuk fitur Q&A peserta. Eval set dimulai dari 60 kasus, tumbuh ke 280 dalam 6 bulan. Setiap pergantian model, perubahan prompt, dan update chunk size di pipeline RAG harus lewat harness sebelum deploy.

Cara Mulai dalam Dua Minggu

Praktik standar yang saya rekomendasikan untuk tim yang baru mau adopsi:

Minggu 1: Bangun eval set MVP. Kumpulkan 50 kasus dari log produksi atau wawancara CS. Setiap kasus berisi: input user, konteks tambahan jika ada, expected output (boleh format kriteria, bukan harus jawaban exact), dan label intent.

Minggu 1-2: Bangun scorer. Untuk MVP, mulai dari rubric sederhana: relevansi (0-3), faktualitas (0-3), tone (0-2). Pakai judge LLM untuk skoring otomatis, lalu reviewer manusia validasi sample 20% mingguan.

Minggu 2: Integrasikan ke pipeline release. Tambahkan langkah CI yang menjalankan harness setiap pull request ke prompt atau konfigurasi model. Pasang threshold pass/fail. Kalau pakai feature flag, eval harness juga bisa dijalankan saat rollout bertahap.

Dokumentasi praktis yang saya rekomendasikan: OpenAI evals framework sebagai referensi pola dan Anthropic prompt engineering guide.

Pertanyaan Umum

Apakah harus pakai LLM-as-judge untuk semua scoring?

Tidak. Untuk jawaban tegas, pakai exact match atau regex (lebih murah dan deterministik). LLM-as-judge dipakai untuk jawaban bebas, dengan rubric jelas dan validasi reviewer manusia berkala.

Berapa biaya menjalankan eval harness setiap PR?

Untuk eval set 100 kasus, biaya per run tipikal 0,5-3 USD tergantung model judge. Karena ini ditanggung di tahap CI (bukan produksi), nilai dibanding mencegah regresi sangat tinggi.

Bagaimana kalau eval set jadi outdated karena distribusi user berubah?

Lakukan refresh kuartalan: tarik 50-100 sample acak dari log produksi terbaru, kurasi yang relevan, tambahkan ke eval set. Pensiunkan kasus yang sudah tidak representatif.

Apakah eval harness menggantikan testing manual?

Tidak menggantikan, melengkapi. Manual review tetap dilakukan untuk kategori sensitif (medical, legal, financial) dan saat ada perubahan besar arsitektur. Eval harness mengotomasi yang bisa diotomasi.

Apa risiko kalau tim baru mengandalkan eval harness?

Eval set yang bias atau terlalu kecil bisa memberi false confidence. Mitigasi: audit komposisi eval set kuartalan, pastikan distribusi mencerminkan produksi, dan pertahankan disiplin reviewer manusia untuk sample.

Eval Harness adalah Investasi Compounding

Brand Indonesia yang serius scaling AI di 2026 perlu memperlakukan eval harness sama seriusnya dengan unit test di codebase. Investasi awal 2-3 minggu, tapi setiap iterasi setelahnya jadi lebih cepat dan lebih aman. Tim yang skip langkah ini biasanya bayar dengan insiden produksi yang bisa dicegah, atau dengan keengganan untuk update yang membuat fitur jadi stale.

Tanpa eval harness, deploy update model atau prompt sama dengan men-deploy code tanpa test. Bisa jalan, sampai tidak.