Agent Evaluation untuk Developer Indonesia: Cara Menguji Fitur AI Sebelum Pengguna Menemukan Bug-nya
TL;DR: Agent evaluation adalah pengujian sistematis perilaku AI agent yang menilai bukan hanya output akhir tetapi seluruh trajectory: pemilihan tool, kualitas argumen, dan konsistensi pada skenario serupa. Tim Indonesia yang membangun fitur AI di produksi wajib memelihara dataset evaluasi 50-200 skenario yang dijalankan setiap kali prompt, model, atau tool berubah.
Dalam tiga bulan terakhir, saya membantu beberapa tim produk di Jakarta yang baru meluncurkan fitur berbasis AI. Pola yang berulang sama: fitur lulus uji manual saat demo internal, lulus QA tradisional, lalu tiga minggu setelah rilis muncul keluhan pengguna yang aneh. Bot menjawab pertanyaan harga dengan nominal salah. Asisten riset memilih tool pencarian web padahal data sudah ada di database internal. Agen email mengirim follow-up ke kontak yang sudah unsubscribe.
Akar masalahnya bukan kualitas LLM yang rendah, tetapi tidak adanya proses evaluasi terstruktur. Tim memperlakukan fitur AI seperti kode tradisional, padahal sistem non-deterministik memerlukan pendekatan berbeda. Agent evaluation adalah praktik yang menjembatani gap ini.
Mengapa Uji Manual Tidak Cukup
Uji manual punya tiga kelemahan struktural saat dipakai pada AI agent. Pertama, manusia cepat lelah dan cenderung memeriksa happy path. Kedua, satu update model dari penyedia upstream bisa diam-diam menurunkan kualitas pada skenario yang sebelumnya lulus, dan tidak ada yang sadar sampai keluhan masuk. Ketiga, manusia sulit memeriksa konsistensi: agent yang menjawab benar 9 dari 10 kali tampak baik secara intuitif, tetapi 10 persen kegagalan pada fitur yang melayani 50 ribu request per hari berarti 5 ribu pengalaman buruk.
Uji manual juga tidak skalabel. Tim engineering tidak bisa menghabiskan dua hari memeriksa perilaku agent setiap kali prompt diubah. Kalau setiap perubahan prompt memakan biaya QA tinggi, tim akan berhenti melakukan iterasi, dan justru itu yang membuat fitur AI cepat usang.
Empat Dimensi yang Wajib Diukur
Agent evaluation berbeda dari evaluasi LLM biasa karena menilai seluruh trajectory, bukan hanya satu pasangan input-output. Empat dimensi yang menjadi standar industri saat ini:
| Dimensi | Pertanyaan | Cara ukur |
|---|---|---|
| Task success | Apakah tujuan tercapai? | rubric score 1-5 oleh LLM-as-judge |
| Tool selection | Apakah tool yang tepat dipanggil? | precision/recall pada tool calls |
| Argument validity | Apakah parameter ke tool benar? | schema validation rate |
| Consistency | Stabil pada N kali run? | variance score across replicas |
Tim yang lebih matang menambah dimensi cost (token usage per task) dan latency (steps to completion) untuk menjaga ekonomi unit fitur tetap sehat seiring volume tumbuh.
Studi Kasus: Membangun Eval Dataset di Atmo (LMS)
Saat membangun fitur asisten kursus di Atmo, kami awalnya mengandalkan review manual oleh tim konten. Setelah dua kali terjadi regresi senyap akibat update model upstream, kami beralih ke pipeline evaluasi otomatis. Prosesnya: kami kumpulkan 80 skenario riil dari log percakapan minggu pertama, klasifikasikan menjadi 5 kategori (pertanyaan kurikulum, navigasi platform, isu pembayaran, troubleshooting login, dan pertanyaan di luar scope), lalu untuk tiap skenario kami tulis "expected behavior" dalam bentuk rubrik tiga poin.
Setiap kali prompt sistem diubah atau model diganti, pipeline menjalankan 80 skenario itu dan melaporkan delta. Tim hanya merilis perubahan kalau task success rate stabil di atas 88 persen dan tool selection precision di atas 92 persen. Pendekatan ini memangkas waktu QA dari 2 hari ke 30 menit dan mendeteksi tiga regresi yang sebelumnya tidak terlihat saat tim hanya mengandalkan spot check.
Pola serupa kami terapkan di klien Vetmo (pet care chatbot), dengan adaptasi untuk konteks veterinary. Kuncinya bukan jumlah skenario yang besar, tetapi kualitas kurasi: 50 skenario yang menutupi happy path, edge case, dan adversarial input lebih bernilai daripada 500 skenario sintetik yang seragam.
Tiga Lapisan Evaluasi yang Saling Melengkapi
Praktik yang saya rekomendasikan untuk tim Indonesia adalah menggabungkan tiga lapisan, mengikuti panduan dari OpenAI Evals dan dokumentasi Anthropic:
Lapisan 1, automated checks deterministik. Untuk hal yang bisa diukur kode: schema validity, tool call presence, response length, regex pada output kunci. Cepat, murah, jalan setiap commit.
Lapisan 2, LLM-as-judge. Untuk dimensi subjektif seperti relevance, tone, atau correctness terhadap rubrik. Pakai model yang lebih kuat dari model produksi untuk menilai. Biaya lebih tinggi, jalankan harian atau pada PR yang menyentuh prompt.
Lapisan 3, spot review manusia. Untuk kasus berisiko tinggi (medis, legal, keuangan) atau saat skor LLM-as-judge dan automated checks tidak sepakat. Jadikan setiap insiden produksi sebagai test case permanen di lapisan 1 atau 2.
Pertanyaan Umum
Berapa biaya menjalankan evaluasi rutin?
Untuk dataset 80 skenario dengan LLM-as-judge memakai model premium, biaya tipikal Rp 30 ribu sampai Rp 100 ribu per run. Kalau pipeline jalan 5 kali per minggu, total bulanan masih di bawah Rp 2 juta, jauh lebih murah daripada biaya rollback insiden produksi.
Kapan waktu yang tepat untuk mulai membangun eval pipeline?
Sebaiknya sebelum rilis publik pertama. Banyak tim menunda dengan alasan "nanti saja kalau sudah banyak data", padahal justru data dari rilis publik yang berbahaya kalau belum ada eval untuk mendeteksi regresi.
Apakah cukup memakai eval bawaan dari penyedia model?
Eval bawaan baik untuk kemampuan umum model, tetapi tidak menutupi konteks bisnis Anda. Tim wajib membangun dataset domain-spesifik sendiri, terutama untuk Bahasa Indonesia dan skenario lokal.
Bagaimana menangani non-determinisme dalam evaluasi?
Jalankan setiap skenario minimal 3 kali (idealnya 5) lalu hitung variance. Skenario dengan variance tinggi adalah sinyal bahwa prompt atau tool design perlu diperketat agar perilaku lebih konsisten.
Investasi Kecil yang Mengembalikan Kepercayaan Tim
Tim yang memiliki eval pipeline berfungsi mengubah hubungannya dengan AI dari "berdoa setelah rilis" menjadi "mengukur sebelum rilis". Investasi awalnya bukan teknis, melainkan kurasi dataset 50 skenario yang merepresentasikan kasus pengguna nyata. Setelah pondasi itu ada, sisanya tinggal otomatisasi dan disiplin menambah test case setiap kali insiden terjadi.
Per April 2026, kompetisi fitur AI di Indonesia sudah ketat. Pembedanya bukan model siapa yang dipakai, tetapi seberapa serius tim merawat kualitas perilaku agent dari waktu ke waktu. Agent evaluation adalah salah satu disiplin paling murah dengan return tertinggi yang bisa diadopsi tim hari ini.
Artikel Terkait
Website Bisnis
Cara Marketer Indonesia Pasang CSS field-sizing: content di Next.js untuk Form Kontak, Pangkas 6 KB Library Autosize dan Hilangkan Hydration Mismatch SSR di 2026
Pasang field-sizing: content di Next.js untuk auto-resize textarea tanpa JS. Hemat 6 KB autosize, hilangkan hydration mismatch SSR, dan jaga INP stabil di form panjang.
Website Bisnis
Cara Marketer Indonesia Pasang CSS light-dark() di Next.js untuk Dark Mode Otomatis, Pangkas 38 Baris Media Query dan Hilangkan Hydration Mismatch Theme di 2026
Ganti next-themes dual class jadi 1 fungsi CSS. Studi kasus Vetmo: bundle CSS turun 24%, LCP membaik 180 ms, dan hydration mismatch dark mode hilang total.
Website Bisnis
Cara Marketer Indonesia Pasang CSS reading-flow di Next.js untuk Layout Flex dan Grid, Sinkronkan Urutan Tab dengan Visual dan Lulus Audit WCAG 2.2 di 2026
Pasang CSS reading-flow di Next.js untuk menyamakan urutan keyboard tab dengan layout visual. Hilangkan tabindex manual dan lulus audit WCAG 2.2 level AA.
Butuh website yang benar-benar bekerja?
Hubungi Vito untuk konsultasi gratis 15 menit.
WhatsApp Sekarang