Berhentilah menjalankan benchmark model terbaru dan mulailah mengamati agen Anda saat mencoba membatalkan langganan. Celah di antara kedua aktivitas tersebut adalah tempat di mana sistem produksi hancur. Tes satu putaran dapat memberi tahu Anda apakah sebuah respons terdengar menyenangkan. Namun, tes tersebut tidak dapat memberi tahu Anda apakah agen tersebut baru saja mengembalikan dana ke pelanggan yang salah, melakukan looping empat belas kali terhadap API kalender, atau memutuskan untuk melewatkan pemeriksaan penipuan sepenuhnya. Teks adalah hal yang paling tidak berbahaya yang dihasilkan oleh agen. Risiko yang sebenarnya tersembunyi dalam alat yang disentuhnya, data yang diubahnya, dan momen-momen ketika ia seharusnya meminta bantuan tetapi terus berjalan.
Mengapa Benchmark Teks Gagal di Produksi
Skor tinggi pada benchmark standar telah menjadi bentuk kenyamanan yang menyesatkan. Agen yang menulis prosa elegan mungkin tetap menjadi bahaya operasional. Ketika sistem Anda memesan janji temu, mengedit catatan database, atau mengajukan tiket dukungan, teks yang dihasilkan hanyalah permukaan yang terlihat dari alur kerja tersebut. Di bawahnya, agen sedang membuat keputusan konkret tentang endpoint mana yang harus dipanggil, payload apa yang harus dikirim, dan kapan harus berhenti. Ia bisa menempati posisi teratas di papan peringkat pemahaman bacaan sambil merugikan Anda dengan memesan sumber daya ganda, mengubah baris yang salah, atau membocorkan status sensitif ke dalam file log. Anda perlu memverifikasi mekanika kerja, bukan sekadar polesan outputnya. Jika sebuah agen dapat mencetak skor tinggi pada tes QA offline namun tetap gagal dalam alur kerja Anda karena melakukan looping atau menyalahgunakan alat, maka evaluasi Anda sedang melihat sinyal yang salah.
Memetakan Lima Dependensi
Tim di Van Data Team memulai setiap evaluasi dengan memetakan lima titik kendali spesifik. Ini mengubah pertanyaannya secara keseluruhan. Anda berhenti bertanya apakah satu model lebih pintar dari yang lain. Anda mulai bertanya apakah agen tersebut benar-benar dapat menyelesaikan tugas produksi di bawah batasan nyata Anda.
Hasil bisnis. Tentukan apa arti "selesai" dalam bentuk dolar dan dampak pelanggan. Sebuah tugas tidak dianggap selesai hanya karena agen mengeluarkan ringkasan. Tugas tersebut selesai ketika catatan inventaris akurat, janji temu terkonfirmasi, dan pelanggan menerima nomor pelacakan yang valid.
Status yang dapat diubah (Mutable state). Ketahui persis apa yang boleh diubah oleh agen. Tabel mana, status mana, flag akun mana? Jika agen dapat mengeluarkan pengembalian dana, menjadwalkan ulang pekerjaan, atau memperbarui alamat penagihan, Anda perlu mendata setiap field yang disentuhnya.
Izin alat (Tool permissions). Bersikaplah eksplisit mengenai endpoint API dan fungsi mana yang masuk dalam cakupan. Agen dengan akses ke alat pencarian, alat tulis, dan alat notifikasi akan mencampuradukkannya jika batasannya tidak jelas. Petakan setiap izin ke kebutuhan operasional tertentu.
Pemulihan kegagalan (Failure recovery). Putuskan apa yang terjadi ketika API kalender mengalami timeout, mengembalikan error 500, atau memberikan JSON yang malformed. Agen tidak boleh panik, berhalusinasi dengan pesan sukses, atau mencoba ulang selamanya. Ia membutuhkan jalur fallback yang jelas.
Gerbang peninjauan manusia (Human review gates). Identifikasi momen di mana seseorang harus memberikan persetujuan sebelum agen melanjutkan. Ini bukan tanda kelemahan dalam otomatisasi. Ini adalah katup pengaman untuk perubahan berdampak tinggi dan sumber label ground-truth untuk rubrik Anda.
Seperti Apa Rencana Evaluasi yang Sebenarnya
Setelah dependensi dipetakan, Anda memerlukan rencana evaluasi yang sesuai dengan kerumitan produksi. Metrik slide presentasi tidak akan membantu Anda di sini.
Bangun set pengujian dari kegagalan produksi nyata, bukan dari bank pertanyaan sintetis. Jika agen Anda gagal Selasa lalu karena bingung antara dua SKU yang mirip, kebingungan yang sama persis tersebut harus menjadi kasus uji permanen. Suite evaluasi Anda harus berkembang setiap kali sebuah insiden mengajarkan sesuatu yang baru kepada Anda.
Tulis rubrik yang mendefinisikan penyelesaian yang berhasil dalam istilah operasional. Kriteria samar seperti "membantu" atau "akurat" tidaklah berguna. Rubrik yang berguna menyatakan bahwa tugas pengembalian dana hanya berhasil jika ID pembayaran asli dirujuk, jumlahnya sesuai dengan permintaan, email konfirmasi telah masuk antrean, dan ID transaksi telah dicatat.
Tentukan spesifikasi trace untuk panggilan alat dan retry. Anda memerlukan observabilitas terhadap apa yang direncanakan agen, apa yang sebenarnya ia panggil, berapa kali ia mencoba ulang, dan apakah strategi retry tersebut sudah tepat. Sebuah trace tanpa granularitas tingkat alat hanyalah sebuah cerita yang indah.
Tetapkan kebijakan tentang kapan harus memberi peringatan kepada manusia. Agen harus mengetahui batasannya sendiri. Jika sebuah permintaan melebihi ambang batas dolar, merujuk ke akun VIP, atau menemui status yang belum pernah ia lihat sebelumnya, ia harus melakukan eskalasi daripada menebak-nebak.
Pasang release gate untuk memblokir pembaruan model yang buruk. Sebuah model baru hanya dianggap sebagai peningkatan jika ia memperbaiki hasil spesifik Anda. Jika ia lebih sering berhalusinasi pada argumen tool, meningkatkan latensi, atau menimbulkan risiko keamanan baru, maka model tersebut tidak boleh dirilis. Gate ini menjaga stabilitas produksi bahkan ketika vendor model dasar merilis versi baru.
Runtime Grading: Mengawasi Kerja Agen
Anthropic telah mendorong industri untuk bergerak melampaui pengujian offline menuju runtime grading. Alih-alih menilai transkrip setelah kejadian, runtime grading memungkinkan sistem menilai pekerjaan agen saat tugas tersebut masih berjalan. Ini memberikan kesempatan untuk menangkap kesalahan sebelum kesalahan tersebut menjadi masalah nyata yang sulit diperbaiki.
Menambahkan grader membutuhkan biaya token dan latensi. Anda tidak mampu menilai setiap langkah kecil. Penempatan setiap grader adalah keputusan desain. Letakkan mereka di tempat di mana kesalahan akan berakibat mahal. Checkpoint yang paling berharga berada tepat sebelum melakukan perubahan status ke database, tepat sebelum memproses pembayaran, dan tepat sebelum mengirim pesan ke pelanggan. Inilah momen-momen di mana keputusan yang buruk menjadi tindakan yang tidak dapat dibatalkan.
Waspadai titik buta tertentu. Jika model yang sama melakukan pekerjaan sekaligus menilai pekerjaan tersebut, ia mungkin melewatkan kesalahan yang sama. Penalaran yang menghasilkan kesalahan dapat dengan mudah merasionalisasi kesalahan tersebut saat peninjauan. Untuk tugas-tugas berdampak tinggi, libatkan peninjauan manusia (human review) dalam prosesnya. Biarkan manusia memvalidasi penilaian grader itu sendiri, terutama ketika uang atau kepercayaan pelanggan menjadi taruhannya.
Tujuannya di sini adalah kontrol operasional. Hubungkan data insiden, rubrik tugas, dan runtime traces Anda ke dalam satu siklus umpan balik. Evaluasi seluruh jalur: rencana, penggunaan tool, perilaku pemulihan, dan hasil akhir. Gunakan pengujian offline untuk menangkap kesalahan yang sudah diketahui dan dapat direproduksi sebelum rilis. Gunakan runtime traces untuk menemukan kegagalan baru yang tidak Anda antisipasi. Gunakan human review untuk menemukan di mana rubrik Anda masih terlalu sederhana dan perlu diperketat.
Jadi tanyakan pada diri sendiri: di mana Anda akan menempatkan runtime grader dalam alur kerja Anda? Sebelum pemanggilan tool, setelah pemanggilan tool, atau hanya sebelum perubahan yang berisiko? Kebanyakan tim memulai terlalu luas, menilai segalanya, lalu terhenti karena biaya yang membengkak. Mulailah secara sempit. Pilih satu tindakan yang paling merugikan jika terjadi kesalahan. Letakkan grader di sana terlebih dahulu.
Mulai dengan Satu Kesalahan yang Berakibat Mahal
Evaluasi operasional bukanlah latihan penelitian. Ini adalah cara agar Anda bisa tidur lebih nyenyak setelah agen tersebut aktif. Anda tidak memerlukan kerangka kerja yang sempurna pada hari pertama. Anda hanya butuh satu alur kerja yang terdefinisi dengan baik, rubrik yang ditulis dalam istilah bisnis yang lugas, dan grader yang ditempatkan tepat pada saat kesalahan menjadi mahal. Lakukan itu dengan benar, dan Anda akan memiliki fondasi yang benar-benar dapat Anda percayai.
Jika Anda ingin mendalami evaluasi agen dan runtime grading bersama komunitas praktisi, Anda dapat menemukan komunitas belajar GyaanSetu di https://t.me/GyaanSetuAi.