Mengukur Kinerja AI Agent

Ringkasan bisa enak dibaca sekaligus salah mengambil sumber, mengarang tenggat, atau melewati persetujuan.

Ia dapat membuat summary yang enak dibaca, tetapi mengambil angka dari sumber yang salah. Ia bisa menyusun action items lengkap, tetapi mengarang deadline yang tidak pernah disepakati. Ia juga dapat menjawab cepat, lalu melewati approval dan mengirim hasil ke channel eksternal.

Kalau success criteria-nya hanya “hasilnya bagus”, kegagalan sumber, batas akses, dan approval gampang lolos.

Evaluation untuk AI Agent perlu melihat dua hal sekaligus: kualitas output dan cara workflow mencapai output tersebut. Kita bukan cuma menilai tulisannya. Kita juga memeriksa sumber, batas akses, keputusan, kondisi berhenti, dan tindakan yang dilakukan.

Mulai dari Definisi Selesai

Sebelum mengetes model, tulis dulu kondisi yang membuat pekerjaan bisa disebut beres.

Untuk agent pembuat laporan, “selesai” mungkin berarti periode datanya benar, angka sesuai sumber, perubahan penting terangkat, dan format wajib tersedia. Untuk layanan pelanggan, definisinya bisa mencakup jawaban yang bersumber dari knowledge base, eskalasi untuk kasus berisiko, serta larangan membuat kebijakan baru.

Definisi itu harus mengikuti pekerjaannya. Tidak ada satu score universal yang otomatis cocok untuk semua agent.

Acceptance criteria yang berguna biasanya bisa diperiksa. “Terlihat profesional” terlalu longgar. “Setiap angka pada laporan dapat ditelusuri ke file sumber yang diizinkan” lebih testable. “Membantu user” masih subjektif. “Kasus refund di luar policy diteruskan ke manusia tanpa menjanjikan keputusan” memberi batas yang lebih clear.

Kalau tim belum bisa menjelaskan pass dan fail, mengganti model atau platform belum menyelesaikan masalah. Sistemnya belum punya target yang stabil.

Pisahkan Kualitas Output dan Perilaku Workflow

Output quality adalah bagian yang paling kelihatan. Kita bisa mengecek apakah summary akurat, struktur lengkap, bahasa mudah dipahami, atau field sesuai schema.

Namun, workflow behavior sama pentingnya. Pertanyaannya antara lain:

• Apakah agent hanya membaca sumber yang diizinkan?
• Apakah tool dipanggil dengan parameter yang benar?
• Apakah informasi yang hilang diberi label, bukan dikarang?
• Apakah tindakan berisiko menunggu approval?
• Apakah agent berhenti ketika permintaan melewati kewenangannya?
• Apakah kegagalan tool dilaporkan dengan jujur?

Bayangkan Meeting Operations Agent menghasilkan action plan yang sempurna. Semua keputusan, PIC, dan deadline tertata. Tetapi setelah itu ia langsung broadcast ke Telegram tanpa preview dan approval.

Secara visual, output-nya pass. Secara desain workflow, ia fail.

Evaluation yang hanya membaca jawaban akhir tidak akan menangkap masalah tersebut. Karena itu, log langkah, tool call, sumber context, serta status approval perlu ikut diperiksa sesuai risiko use case.

Uji dengan Kasus Normal dan Kasus Sulit

Demo dengan input yang lengkap sering membuat agent terlihat siap. Real work jarang serapi itu.

Selain kondisi ideal, siapkan kasus yang sengaja mengandung kekosongan. Misalnya, catatan meeting tidak menyebut tenggat. Nama PIC ambigu. Calendar punya dua acara dengan judul mirip. Basis pengetahuan berisi dua kebijakan yang bertentangan. Tool pengiriman gagal setelah draft selesai dibuat.

Tujuannya bukan menjebak model. Kita ingin melihat apakah rule yang dirancang tetap bekerja ketika kondisi tidak ideal.

Untuk setiap kasus, tentukan respons yang diharapkan. Agent mungkin perlu menulis Belum ditentukan, meminta klarifikasi, menampilkan konflik, menyimpan draft, menawarkan retry, atau menghentikan external action. Jangan membiarkan model memilih perilaku aman secara improvisasi.

Test case juga sebaiknya mewakili variasi input yang benar-benar mungkin masuk. Kalau agent akan membaca notes dari banyak orang, jangan menguji satu template bersih saja. Kalau agent akan menerima perintah lewat chat, uji instruksi pendek, revisi, pembatalan, dan permintaan yang berada di luar scope.

Gunakan Sumber sebagai Ground Truth

Kelancaran bahasa bukan bukti bahwa hasilnya benar. Model dapat menyampaikan fakta keliru dengan confidence tinggi.

Untuk pekerjaan ekstraksi, bandingkan output dengan sumber yang sudah ditandai. Apakah semua keputusan memang disebut? Apakah action item tertangkap tanpa menambahkan komitmen baru? Apakah angka dan tanggal tetap sama?

Untuk pekerjaan yang mengandung judgment, ground truth bisa lebih kompleks. Tim mungkin perlu rubric dan reviewer manusia. Rubric tersebut tetap harus menjelaskan apa yang dinilai, misalnya relevansi rekomendasi terhadap constraint, kelengkapan risiko, atau kepatuhan pada policy.

Jangan mengubah satu penilaian subjektif menjadi angka yang tampak saintifik. Score berguna kalau kriterianya konsisten dan batas interpretasinya dipahami. Kalau dua reviewer terus berbeda pendapat, rubric-nya mungkin perlu diperjelas sebelum agent dinilai lebih jauh.

Catat Jenis Failure, Bukan Cuma Nilai Akhir

Satu angka agregat dapat menyembunyikan pola penting.

Agent yang sering salah format membutuhkan perbaikan berbeda dari agent yang mengambil sumber keliru. Agent yang gagal saat tool timeout juga berbeda dari agent yang melewati permission. Walaupun total pass rate-nya terlihat serupa, tindakan perbaikannya tidak sama.

Kelompokkan failure sesuai komponen workflow, misalnya:

• context atau source selection;
• instruction following;
• extraction dan reasoning;
• tool execution;
• permission dan approval;
• output format;
• error handling;
• serta handoff ke manusia.

Kategori ini membantu tim menentukan apakah yang perlu diubah adalah prompt, retrieval, schema, tool wrapper, access control, atau keseluruhan flow.

Setelah ada perubahan, jalankan ulang kasus lama. Perbaikan pada satu area bisa membuat area lain mundur. Instruction yang makin ketat mungkin mengurangi informasi palsu, tetapi juga membuat agent terlalu sering berhenti. Tool baru dapat memperluas kemampuan sekaligus menambah titik gagal.

Evaluation bukan ujian sekali sebelum launch. Ia menjadi loop untuk melihat perubahan secara sadar.

Tentukan Risiko yang Tidak Boleh Lolos

Tidak semua error punya dampak yang sama.

Typo kecil pada draft internal berbeda dari pengiriman invoice ke alamat yang salah. Summary yang melewatkan satu kalimat berbeda dari agent yang mengubah data atau mengirim pesan tanpa izin.

Tandai failure yang harus menjadi hard fail. Contohnya bisa berupa mengarang angka, memakai credential di luar scope, melewati approval, mengeksekusi action setelah user membatalkan, atau menyembunyikan kegagalan tool.

Untuk risiko tinggi, jangan hanya mengandalkan evaluasi bahasa. Gunakan control di level sistem: allowlist, permission, schema validation, approval gate, idempotency, dan pembatasan action. Evaluation lalu memastikan control tersebut benar-benar bekerja.

Buat Evaluation Set Kecil yang Meaningful

Tim tidak harus memulai dari dashboard kompleks. Ambil kumpulan kasus yang mewakili pekerjaan inti dan failure paling berisiko.

Untuk tiap kasus, simpan input, sumber yang boleh dipakai, output atau perilaku yang diharapkan, serta alasan pass atau fail. Jalankan secara konsisten setiap kali workflow berubah. Tambahkan kasus baru ketika menemukan failure yang sebelumnya belum terwakili.

Yang penting bukan jumlah pengujian yang terlihat mengesankan. Yang penting adalah hubungan antara pengujian, pekerjaan nyata, dan risiko yang ingin dikendalikan.

Di workshop Building AI Employees, peserta akan berlatih mengubah ekspektasi yang kabur menjadi success criteria, error condition, dan approval rule untuk sebuah workflow AI Agent. Meeting Operations Agent digunakan sebagai laboratorium desain; implementasi dan demo-nya masih menjadi target sesi, bukan bukti performa production.

Kumpulan uji yang kecil tetapi mewakili pekerjaan nyata lebih berguna daripada banyak skor tanpa hubungan dengan risiko. Cara menyusun kriteria lulus, kondisi gagal, dan aturan persetujuan ini dibahas dalam workshop:

https://goakal.com/ai-builders-id/building-ai-employees

Agent yang berguna bukan agent yang selalu terlihat pintar. Ia punya definisi selesai, kegagalan yang tidak boleh lolos, dan jejak keputusan yang bisa diperiksa saat hasilnya dipertanyakan.