Evaluasi agen AI jangan berhenti di akurasi—hitung biaya tiap tugas berhasil

Evaluasi agen AI harus dimulai dari tugas yang hasilnya dapat diverifikasi, bukan berhenti pada akurasi jawaban. Susun kumpulan tugas dan kebenaran dasar, rekam lintasan alat, lalu ukur keberhasilan tugas, kegagalan kritis, latensi, serta seluruh biaya eksekusi.

Metrik ekonominya adalah biaya per tugas berhasil: total biaya semua percobaan dibagi jumlah tugas yang lulus. Karena percobaan gagal tetap masuk pembilang, konfigurasi yang murah sekali jalan tidak otomatis lebih efisien daripada konfigurasi yang sedikit lebih mahal tetapi lebih sering menuntaskan pekerjaan.

1. Jadikan tugas pengguna sebagai unit evaluasi

Satu kasus uji sebaiknya mewakili satu tujuan pengguna yang dapat dinyatakan lulus atau gagal. Simpan masukan, kondisi awal, hasil yang harus terlihat, tindakan terlarang, batas waktu, dan lintasan alat yang diwajibkan hanya jika urutannya memang penting.

Dokumentasi Amazon Bedrock AgentCore Evaluations menyebut pencapaian tujuan menyeluruh, kebenaran respons, dan akurasi alat yang dipanggil sebagai dimensi yang dapat diukur. Jadi, jawaban yang benar belum membuktikan bahwa agen menyelesaikan tujuan melalui tindakan yang tepat.

Gunakan template kasus berikut:

• ID dan kategori: pengenal tetap serta jenis tugas, seperti pencarian, pembaruan data, atau transaksi.
• Masukan dan kondisi awal: permintaan pengguna, konteks yang tersedia, serta keadaan sistem sebelum agen bertindak.
• Kebenaran dasar: jawaban, fakta, perubahan keadaan, atau urutan tindakan yang diharapkan.
• Batas proses: alat wajib atau terlarang, parameter penting, izin, dan jumlah langkah maksimum.
• Kriteria lulus: pemeriksaan biner yang dapat diulang.
• Label risiko: tingkat dampak jika agen salah bertindak.

Contoh hipotetis: agen layanan pelanggan diminta mengubah alamat pengiriman untuk pesanan yang belum diproses. Kebenaran dasarnya bukan kalimat “alamat telah diubah”, melainkan alamat baru tersimpan pada pesanan yang tepat, status pesanan memang memenuhi syarat, dan tidak ada pesanan lain yang berubah.

2. Bentuk kumpulan tugas dari variasi dan kegagalan nyata

Kumpulan uji perlu mencakup lebih dari permintaan normal. Tambahkan variasi bahasa Indonesia yang wajar, informasi yang hilang, maksud ambigu, hasil alat kosong, waktu habis, permintaan berulang, konflik instruksi, serta tindakan yang harus ditolak atau dialihkan kepada manusia.

Pisahkan set pengembangan dari set regresi. Set pengembangan dipakai untuk memperbaiki prompt, model, atau orkestrasi; set regresi mempertahankan kasus lama agar perubahan berikutnya tidak menghidupkan kembali kegagalan yang sudah ditemukan. Catat versi tugas, konfigurasi agen, definisi alat, dan lingkungan pengujian agar perbandingan antarkonfigurasi tetap setara.

Komposisi kasus sebaiknya mempertimbangkan dampak, bukan frekuensi saja. Tugas yang jarang terjadi tetapi dapat menghapus data, membocorkan informasi, atau menghasilkan transaksi salah memerlukan kriteria yang lebih ketat daripada pertanyaan informasional berisiko rendah.

3. Pisahkan penilaian hasil dan proses

Buat dua lapisan skor. Evaluasi hasil memeriksa apakah tujuan selesai, keluaran benar dan dapat digunakan, serta batas tugas dipatuhi. Evaluasi proses memeriksa pilihan alat, parameter, keberhasilan eksekusi, pemanfaatan keluaran alat, dan langkah yang tidak diperlukan.

Panduan evaluator agen Microsoft Foundry membedakan evaluasi sistem dari evaluasi proses; pemeriksaan prosesnya mencakup pemilihan alat, akurasi input, pemanfaatan output, serta keberhasilan panggilan alat. Pemisahan ini dapat mengungkap agen yang memperoleh jawaban benar setelah memilih alat atau parameter yang keliru.

Scorecard minimum dapat memakai metrik berikut:

• Tingkat keberhasilan tugas = tugas lulus ÷ seluruh tugas.
• Akurasi panggilan alat = panggilan dengan alat dan parameter yang benar ÷ panggilan yang dinilai.
• Tingkat kegagalan teknis = panggilan yang mengalami error atau waktu habis ÷ seluruh panggilan.
• Tingkat pelanggaran = tugas dengan sedikitnya satu pelanggaran ÷ seluruh tugas.
• Langkah per tugas berhasil = seluruh langkah agen ÷ jumlah tugas lulus.

Gunakan pemeriksaan deterministik untuk keadaan yang pasti, seperti nilai basis data, format parameter, hak akses, dan jumlah transaksi. Penilai manusia atau model dapat membantu menilai relevansi dan kegunaan, tetapi rubriknya harus eksplisit; audit sampel secara berkala agar perubahan perilaku penilai tidak terbaca sebagai peningkatan agen.

4. Masukkan setiap kegagalan ke dalam perhitungan biaya

Catat biaya token masukan dan keluaran, API berbayar, komputasi, penyimpanan atau pengambilan data, serta evaluasi. Tutorial evaluasi agen IBM memisahkan akurasi, waktu respons, dan biaya sumber daya; komponen biaya yang disebutkan mencakup penggunaan token, waktu komputasi, jumlah panggilan API, dan konsumsi memori.

Tiga rumus ini menjawab pertanyaan yang berbeda:

• Biaya per percobaan = total biaya seluruh percobaan ÷ jumlah percobaan.
• Biaya per tugas berhasil = total biaya seluruh percobaan ÷ jumlah tugas lulus.
• Biaya kegagalan = biaya percobaan gagal + biaya pemulihan yang dapat diukur secara konsisten.

Contoh hipotetis: konfigurasi A menghabiskan Rp100.000 untuk 100 tugas dan meluluskan 80 tugas. Biayanya Rp1.000 per percobaan, tetapi Rp1.250 per tugas berhasil. Konfigurasi B menghabiskan Rp110.000 dan meluluskan 95 tugas; biayanya Rp1.100 per percobaan dan sekitar Rp1.158 per tugas berhasil. B lebih mahal setiap kali dijalankan, tetapi lebih murah untuk menghasilkan satu pekerjaan yang selesai.

Laporkan latensi median dan persentil tinggi, lalu pecah biaya serta latensi menurut kategori tugas. Angka gabungan dapat menyembunyikan alur tertentu yang lambat atau mahal, sedangkan rata-rata latensi tidak menunjukkan dengan baik pengalaman pada ekor distribusi.

5. Tentukan gerbang produksi sebelum membaca skor

Ambang lulus harus mengikuti risiko dan kebutuhan layanan, bukan dipilih setelah hasil terlihat. Gerbang dapat mensyaratkan tingkat keberhasilan minimum, nol pelanggaran kritis, batas kesalahan parameter, batas latensi persentil tinggi, dan plafon biaya per tugas berhasil secara bersamaan.

Jangan menutup kegagalan kritis dengan rata-rata kualitas bahasa. Terapkan hard fail untuk pelanggaran keamanan, privasi, otorisasi, transaksi ganda, atau tindakan lain yang sulit dipulihkan. Untuk kategori berisiko tinggi, syarat khusus per kategori lebih informatif daripada satu skor agregat.

Bandingkan konfigurasi pada kasus dan jumlah pengulangan yang sama. Pengulangan pada tugas penting memperlihatkan konsistensi, bukan hanya hasil terbaik. Konfigurasi layak dipromosikan jika seluruh gerbang terpenuhi dan tidak menimbulkan kemunduran material pada kategori berisiko tinggi.

6. Gunakan evaluasi batch dan daring untuk pertanyaan berbeda

Evaluasi batch cocok sebelum rilis, setelah perubahan model atau prompt, dan ketika tim perlu mereproduksi insiden pada data tetap. Kondisinya lebih terkendali, kebenaran dasar dapat disediakan, dan dua versi lebih mudah dibandingkan.

Evaluasi daring digunakan setelah penerapan untuk menemukan perubahan pola permintaan, kegagalan integrasi, lonjakan latensi, serta biaya yang tidak muncul dalam set pengujian. Ambil sampel dengan perlindungan data yang sesuai, tinjau kegagalannya, lalu masukkan kasus yang sudah divalidasi ke set regresi.

Siklusnya adalah uji batch, penerapan terbatas, pemantauan lalu lintas nyata, triase kegagalan, pembaruan set regresi, lalu pengujian ulang. Dashboard produksi perlu memisahkan hasil menurut versi agen dan kategori tugas, dengan metrik keberhasilan tugas, pelanggaran kritis, kegagalan alat, latensi persentil tinggi, serta biaya per tugas berhasil.

Gerbang produksi akhirnya harus menjawab satu pertanyaan utuh: apakah agen menyelesaikan tugas yang benar, melalui tindakan yang benar, dalam batas risiko, waktu, dan biaya yang telah ditetapkan? Akurasi jawaban hanya mengisi satu bagian dari keputusan tersebut.

Baca juga:

• Agen OpenAI lolos dari sandbox dan membobol Hugging Face
• Agen AI dapat memakai 1.000 kali lebih banyak token—biaya tinggi belum tentu akurat
• Jangan tempel data rahasia ke AI: lima pemeriksaan sebelum mengirim prompt