Dari Trace ke Perbaikan: Siklus Evaluasi Agent AI di Produksi
Agent AI yang berhasil menjawab beberapa pertanyaan saat demo belum tentu siap menangani ribuan permintaan pelanggan. Dalam penggunaan nyata, masukan lebih beragam, sistem eksternal mengalami gangguan, dan rangkaian tindakan agent bisa menyimpang meskipun tidak ada error teknis. Karena itu, pemantauan uptime dan latency saja tidak cukup: layanan dapat merespons dengan cepat namun memilih alat yang salah, menggunakan data lama, atau menyelesaikan tujuan dengan cara yang boros.
Tim perlu memperlakukan evaluasi agent sebagai siklus operasional berkelanjutan. Siklus itu menghubungkan rekaman eksekusi, penilaian kualitas, peninjauan kegagalan, dan pengujian ulang sebelum perubahan dirilis. Fokusnya bukan mengumpulkan sebanyak mungkin log, melainkan menghasilkan bukti yang cukup untuk menjawab pertanyaan praktis: apa yang dilakukan agent, apakah hasilnya benar, dan perbaikan apa yang akan mencegah masalah berulang?
Mengukur perilaku, bukan hanya kesehatan layanan
Pemantauan tradisional tetap penting. Tingkat error, waktu respons, antrean, dan ketersediaan menunjukkan apakah infrastruktur sehat. Namun, agent menambahkan dimensi perilaku. Sebuah permintaan dapat berstatus sukses pada HTTP, sementara agent memanggil alat pencarian yang keliru atau mengirim jawaban tanpa memeriksa kebijakan terbaru.
Untuk memahami perilaku tersebut, satu eksekusi perlu direkam sebagai trace yang berisi langkah-langkah terkait: permintaan awal, pemanggilan model, pemilihan alat, hasil alat, perubahan status, dan respons akhir. Setiap langkah sebaiknya mempunyai waktu, status berhasil atau gagal, serta hubungan dengan langkah induknya. Dalam sistem multi-agent, identitas trace yang sama membantu tim mengikuti perpindahan tugas dari agen koordinator ke agen spesialis.
Tidak semua data perlu disimpan mentah. Argumen alat dan hasilnya dapat memuat data pribadi atau rahasia bisnis. Terapkan penyamaran atau penghapusan bidang sensitif sebelum pengiriman ke penyimpanan observabilitas, batasi akses berdasarkan peran, dan tetapkan masa retensi. Metadata yang aman—misalnya nama alat, kategori kesalahan, durasi, jumlah percobaan ulang, dan ID kasus yang tidak mengungkap identitas—sering sudah cukup untuk menemukan pola.
Rubrik kualitas yang dapat ditindaklanjuti
Nilai kualitas tidak sebaiknya diringkas menjadi satu angka tanpa penjelasan. Pisahkan setidaknya empat dimensi: ketepatan hasil, kepatuhan terhadap kebijakan, keberhasilan menyelesaikan tujuan, dan efisiensi jalur kerja. Untuk agent layanan pelanggan, contohnya, pertanyaan faktual dapat diperiksa terhadap sumber resmi; perubahan pesanan harus cocok dengan catatan transaksi; dan tindakan yang memengaruhi pelanggan harus mengikuti batas otorisasi.
Gunakan pemeriksaan deterministik untuk hal yang bisa dipastikan dengan kode. Validasi bahwa format data sah, jumlah transaksi tidak berubah tanpa izin, dan tool yang dipanggil termasuk daftar yang diizinkan. Rubrik manusia atau penilai berbasis model dapat membantu aspek yang lebih bernuansa, seperti apakah jawaban jelas dan relevan. Penilaian otomatis bukan kebenaran mutlak: kalibrasikan dengan sampel yang ditinjau manusia, ukur perbedaan penilaian, dan jangan biarkan skor rata-rata menutupi kegagalan keselamatan yang serius.
Simpan contoh kasus representatif sebagai himpunan evaluasi. Sertakan kasus rutin, variasi bahasa, data yang tidak lengkap, gangguan layanan, dan upaya meminta tindakan di luar kewenangan. Himpunan ini menjadi pemeriksaan regresi ketika prompt, model, alat, atau kebijakan berubah. Data uji harus dianonimkan dan diperiksa agar tidak menyalin informasi pelanggan yang sebenarnya.
Contoh: agent penanganan retur
Bayangkan toko daring menggunakan agent untuk membantu memproses retur. Agent menerima pesan, mencari pesanan, memeriksa tenggat retur, lalu menyiapkan instruksi atau meminta persetujuan staf untuk pengecualian. Metrik “jawaban terkirim” tidak cukup untuk menilai keberhasilan: agent bisa saja menyetujui barang yang sudah melewati tenggat atau mengambil pesanan milik pelanggan lain.
Tim dapat merekam urutan langkah tanpa memasukkan nama, alamat, atau
isi lengkap percakapan. Contohnya: lookup_order
mengembalikan status cocok/tidak cocok; check_return_window
mengembalikan layak/tidak layak; lalu agent memilih antara menjelaskan
kebijakan atau meneruskan kasus. Pemeriksaan otomatis harus menolak
tindakan pengembalian dana ketika pemeriksaan kelayakan gagal; tim tetap
perlu menguji bahwa penolakan itu bekerja. Sampel trace dengan keputusan
salah ditinjau petugas, kemudian disederhanakan menjadi kasus uji:
pesanan cocok tetapi tenggat terlewati, nomor pesanan ambigu, atau
layanan inventaris tidak merespons.
Jika evaluasi menunjukkan agent terus mencoba ulang saat layanan inventaris gagal, perbaikannya mungkin bukan mengganti model. Tim dapat menetapkan batas percobaan, menambahkan status “perlu ditinjau”, dan membuat kasus gangguan tersebut wajib lulus sebelum rilis. Dengan cara ini, masalah produksi berubah menjadi tes yang mencegah regresi, bukan sekadar tiket yang akhirnya terlupakan.
Menutup lingkaran dari temuan ke rilis
Mulailah dengan memilih satu workflow berisiko terbatas dan mendefinisikan hasil yang diharapkan. Instrumentasikan trace untuk langkah penting, ukur biaya dan latency per eksekusi, lalu tentukan ambang eskalasi. Jangan mengumpulkan semua isi percakapan secara default. Pertimbangkan sampling untuk analisis rutin, tetapi pastikan insiden penting dan kegagalan keselamatan tetap dapat ditelusuri sesuai kebijakan privasi.
Setiap kegagalan yang dikonfirmasi sebaiknya menghasilkan dua keluaran: tindakan korektif dan kasus evaluasi baru. Tindakan dapat berupa memperbaiki instruksi, memvalidasi argumen alat, memperbarui sumber pengetahuan, atau memindahkan keputusan berisiko ke persetujuan manusia. Setelah itu, jalankan kembali himpunan uji dan bandingkan hasil dengan versi sebelumnya. Jika kualitas turun pada kategori penting, tahan perubahan sampai penyebabnya dipahami.
Dashboard yang berguna menampilkan tren menurut kategori, bukan sekadar total. Pantau rasio penyelesaian yang benar, eskalasi, kesalahan pemilihan alat, biaya per keberhasilan, latency, dan kejadian kebijakan. Tetapkan pemilik untuk meninjau anomali dan jadwal untuk memperbarui kasus uji. Tanpa tanggung jawab operasional, metrik hanya menjadi grafik yang dilihat setelah pelanggan mengeluh.
Memisahkan hasil uji dari keputusan rilis
Catat versi yang diuji bersama hasilnya. Jika tim mengubah instruksi setelah pengujian, hasil lama tidak boleh dipakai sebagai bukti bahwa versi baru sudah lolos. Untuk setiap kasus, tuliskan keadaan awal, tindakan yang diizinkan, hasil aktual, dan alasan penilaian. Tandai pemeriksaan yang belum dijalankan secara terpisah dari pemeriksaan yang berhasil.
Pada contoh retur tadi, latihan dapat memakai pesanan sintetis agar pengujian tidak menyentuh transaksi pelanggan. Nama alat dan identitas kasus juga perlu ditinjau: keduanya masih bisa mengungkap informasi jika penamaannya memuat data pribadi. Contoh ini adalah saran rancangan, bukan laporan penerapan pada toko tertentu.
Penutup: kualitas agent dibangun lewat umpan balik
Agent AI tidak menjadi andal hanya karena modelnya lebih kuat atau prompt-nya lebih panjang. Keandalan tumbuh ketika organisasi dapat melihat langkah yang relevan, menilai hasil dengan kriteria yang jelas, melindungi data dalam proses pencatatan, dan mengubah kegagalan nyata menjadi perlindungan sebelum rilis berikutnya.
Takeaway utama: bangun satu lingkaran tertutup—trace yang aman, evaluasi multidimensi, peninjauan kegagalan, lalu regresi sebelum rilis. Mulai dari satu workflow dan beberapa kasus penting; perluas hanya setelah tim mampu menggunakan temuannya untuk mengambil tindakan nyata.
Referensi
Konsep trace dan span merujuk dokumentasi OpenTelemetry. Pembahasan himpunan evaluasi merujuk OpenAI Evals; contoh retur dan rubrik operasional merupakan ilustrasi rancangan dalam artikel ini.