Saat Verifikasi Mandiri Tak Lagi Cukup: Mengintegrasikan Perbaikan Kesalahan Runtime dalam Agen LLM

Kegagalan Model Baru: Verifikasi Mandiri yang Stagnan

Dalam pengembangan pipeline agen AI modern, kegagalan sering kali terjadi dengan cara yang sekilas tampak "bertanggung jawab". Agen menghasilkan jawaban, menjalankan langkah verifikasi mandiri (self-verification), bahkan memanggil sistem "judge" untuk mengkritik hasilnya sendiri. Namun, eksekusi tetap berlanjut meskipun ada kesalahan. Hal ini terjadi karena langkah verifikasi tersebut tidak mampu merevisi rencana secara nyata, tidak bisa membatalkan dampak penggunaan alat (tool) secara aman, atau tidak dapat memercayai sinyal penilaiannya sendiri. Akibatnya, kesalahan tetap lolos ke tahap produksi meskipun sistem telah memiliki mekanisme "verifikasi". (Source)

Celah operasional ini sebenarnya cukup sederhana: verifikasi mandiri selama ini hanya dianggap sebagai titik pengambilan keputusan, bukan sebagai lapisan infrastruktur yang mampu mencegat dan memperbaiki agen saat pemanggilan alat sedang berjalan. Di lingkungan produksi, konsekuensi dari kegagalan ini bukan sekadar pesan yang salah. Pemanggilan alat dapat memicu efek samping yang tidak dapat dibatalkan. Oleh karena itu, pertanyaan bagi praktisi bukan lagi "Apakah agen melakukan pengecekan mandiri?", melainkan "Dapatkah sistem melakukan intervensi dengan cukup cepat dan bukti yang kuat untuk mencegah lolosnya kesalahan?" (Source)

Dua alur penelitian menjelaskan mengapa verifikasi tanpa kemampuan perbaikan ini sering muncul. Pertama, pengecekan mandiri dapat terjebak dalam pola kegagalan yang sama dengan generator jawaban, terutama jika keduanya menggunakan prompt, konteks, dan bias model yang serupa. Kedua, kritik berbasis rubrik dan penilaian dari sistem judge dapat mengalami pergeseran (drift), menjadi rapuh di berbagai domain, atau menurun kualitasnya pada input multibahasa di mana sinyal evaluasi tidak selaras dengan niat pengguna. (Source; Source)

Modus Kegagalan: Verifikasi Tanpa Revisi

Tidak semua mekanisme verifikasi memiliki kualitas yang setara. Salah satu arsitektur yang umum digunakan mengikuti siklus yang sudah dikenal: menyusun rencana, mengkritik diri sendiri, lalu melanjutkan jika kritik dinyatakan lulus. Kegagalan muncul saat kritik dihasilkan, namun revisi tidak mungkin dilakukan atau terlalu lemah. Model mungkin mendeteksi ketidaksesuaian, tetapi tidak memiliki jalur perbaikan yang terstruktur; model mungkin tidak tahu bagian mana yang harus ditulis ulang, tidak diizinkan memanggil alat kembali, atau tidak diperbolehkan mengubah parameter yang menentukan efek samping alat tersebut. Sering kali, sistem secara otomatis memilih untuk "setuju dengan dirinya sendiri" demi menghindari proses pengulangan (retry) yang tidak deterministik. (Source)

Pola lainnya adalah "runtuhnya siklus refleksi" (verification loop collapse). Meskipun siklus refleksi dapat memperbaiki kualitas penalaran dalam evaluasi terkendali, batasan dalam lingkungan produksi—seperti latensi, kuota token, atau ambang batas pemanggilan alat—dapat memaksa siklus tersebut berhenti secara prematur. Begitu siklus berakhir, verifikasi mandiri hanya menjadi sinyal parsial, bukan lagi proses korektif. Mekanisme ini tetap berguna, namun harus dipandang sebagai peringatan yang terbatas, bukan sebuah jaminan keamanan. (Source)

Kritik berbasis rubrik juga menyimpan jebakan tersendiri. Rubrik yang dianggap "benar" sekalipun tetap bisa gagal jika tidak diuji terhadap modus kegagalan sistem yang sebenarnya di lapangan. Jika rubrik lebih menghargai konsistensi di permukaan—seperti bahasa yang fasih dan terdengar "lengkap"—sambil mengabaikan batasan operasional (perizinan, ketersediaan data, prasyarat alat), sistem judge dapat menyetujui tindakan yang salah. Literatur mengenai kritik dan evaluasi menekankan bahwa desain dan kalibrasi rubrik bukanlah hal sepele, dan dapat menghasilkan tingkat kelulusan yang tinggi namun menyesatkan jika konteks evaluasi berbeda dengan kondisi penerapan aslinya. (Source)

Keandalan Sistem Judge: Pergeseran dan Jebakan Bahasa

Verifikasi mandiri berbasis judge sangat menarik karena mampu mengubah penalaran kualitatif menjadi skor numerik. Namun, keandalan bukan sekadar "atribut dari model", melainkan properti dari seluruh alur evaluasi: mulai dari prompting, rubrik, perutean bahasa, hingga aturan keputusan yang mengubah skor menjadi tindakan.

Hal ini dimulai dari pergeseran (drift) dan kalibrasi yang terukur. Banyak tim menerapkan ambang batas statis (misalnya, "terima jika skor > X"), namun kemudian menyadari bahwa distribusi skor telah bergeser karena adanya perubahan pada prompting agen, skema alat yang berkembang, atau profil pengguna yang berubah. Ketika hal ini terjadi, skor numerik yang sama tidak lagi mencerminkan risiko yang sama. Dalam operasional produksi, kalibrasi sistem judge harus diperlakukan sebagai sistem yang dipantau secara terus-menerus. Estimasi tingkat penerimaan salah (false-accept rate) dan tingkat penolakan salah (false-reject rate) perlu dilakukan secara terpisah untuk setiap domain dan jenis alat. Tanpa rekalibrasi berkelanjutan, penyetelan ambang batas hanya akan membuat sistem penilaian menjadi penghalang yang rapuh. (Source; Source)

Selanjutnya, terdapat modus kegagalan multibahasa. Masalah evaluasi multibahasa sering kali tampak seperti penurunan kualitas di lokasi tertentu, hingga dilakukan analisis mendalam terhadap sumber sinyalnya. Sistem judge mungkin menilai artefak bentuk bahasa—seperti kehalusan terjemahan atau frasa idiomatik—daripada kebenaran tugas, terutama jika rubrik bergantung pada konsep yang lebih mudah diekspresikan dalam satu bahasa tertentu. Akibatnya, makna skor menjadi sangat bergantung pada bahasa yang digunakan. Tindakan korektif Anda pun harus demikian: pertahankan aturan keputusan per bahasa dan pantau kesesuaian judge dengan proksi ortogonal (misalnya, apakah eksekusi alat berikutnya berhasil tanpa memicu guardrail). Jika kesesuaian tersebut menyimpang, itu adalah bukti bahwa sistem judge tidak lagi mengukur apa yang seharusnya diukur. (Source; Source)

Mekanisme pergeseran yang lebih halus adalah bias bersama (shared bias). Jika sistem judge menggunakan LLM lain dengan prompting serupa, dan agen serta judge berbagi konteks yang sama, sistem judge cenderung "merasionalisasi" rencana agen alih-alih mendeteksi kesalahannya. Dalam log sistem, hal ini terlihat dari tingkat kelulusan judge yang tinggi namun dibarengi dengan kegagalan sistemik di tahap hilir—inilah ciri khas dari "verifikasi yang tidak bisa memperbaiki". Untuk mendeteksinya, pantau hasil penilaian judge berdasarkan prasyarat alat. Jika banyak rencana yang "lolos" ternyata melanggar batasan alat—seperti kolom wajib yang hilang, izin ditolak, atau ketidaksesuaian skema—berarti sistem judge sebenarnya hanya menilai kelayakan semu, bukan kebenaran yang sesungguhnya. (Source)

Verifikasi sebagai Infrastruktur: Audit pada Tindakan Nyata

Perbaikan kesalahan runtime (runtime error correction) hanya akan menjadi nyata jika verifikasi menghasilkan telemetri yang dapat ditindaklanjuti. Trace logging bukan sekadar prasyarat kepatuhan, melainkan fondasi bagi intervensi deterministik. Anda perlu mengetahui apa yang diputuskan oleh agen, alat apa yang dicoba, parameter apa yang digunakan, izin apa yang berlaku, dan output antara mana yang memicu keputusan tersebut. Audit pemanggilan alat (tool-call auditing) dan kontrol akses yang ketat sangat krusial karena memungkinkan lapisan koreksi untuk memblokir atau memodifikasi langkah selanjutnya. (Source)

Kemampuan audit juga mengubah cara tim merancang perbaikan. Jika Anda dapat memutar ulang urutan pemanggilan alat dengan parameter yang tepat, Anda dapat menguji apakah lapisan verifikasi mampu memblokir kesalahan yang sama di masa mendatang. Literatur arXiv mengenai kerangka evaluasi dan sistem kritik model mendukung arah ini: evaluasi yang tangguh bergantung pada jejak terstruktur dan rubrik yang konsisten agar peningkatan kualitas dapat diukur secara objektif, bukan hanya berdasarkan anekdot. (Source)

Pendekatan praktis adalah membagi verifikasi menjadi pemeriksaan pra-tindakan (pre-action) dan pasca-tindakan (post-action). Pemeriksaan pra-tindakan menentukan apakah pemanggilan alat diizinkan. Pemeriksaan pasca-tindakan menentukan apakah perlu dilakukan rollback, pengulangan, atau eskalasi. Jika Anda hanya melakukan kritik pasca-tindakan, Anda hanya mendiagnosis kegagalan tanpa bisa mencegahnya. Infrastruktur audit pemanggilan alat memungkinkan adanya gerbang pra-tindakan berbasis bukti nyata, bukan sekadar berdasarkan intuisi model. (Source)

Perbaikan Kesalahan Runtime: Intervensi di Tengah Eksekusi

Perbaikan kesalahan runtime harus dirancang sebagai sistem kontrol. Konsep intinya sederhana: verifikasi harus mengendalikan transisi runtime berikutnya. Jika pengecekan mandiri atau sistem judge menandai rencana yang tidak aman, sistem harus menghentikan pemanggilan alat, beralih ke alat atau parameter alternatif yang lebih aman, meminta bukti tambahan, atau meneruskannya ke persetujuan manusia. Tindakan kontrol ini harus cukup deterministik untuk memenuhi target keandalan operasional. (Source)

Kesalahan umum yang sering dilakukan tim adalah mengimplementasikan "perbaikan" hanya dengan "menghasilkan ulang jawaban sampai terdengar benar." Cara ini mungkin mengurangi kesalahan di tingkat teks, namun tidak menjamin keamanan efek samping alat. Kontrol akses alat membantu dengan membatasi alat apa yang dapat dipanggil agen dan di bawah otorisasi apa. Dengan demikian, lapisan koreksi dapat memilih dari alternatif yang diizinkan daripada mencoba memperbaiki penggunaan alat yang sembarang. (Source)

Tata kelola menentukan apakah perbaikan dilakukan secara otomatis. Di banyak lingkungan, perbaikan otomatis tepat untuk kesalahan berisiko rendah dan dapat dibatalkan (seperti kolom opsional yang hilang). Namun, keterlibatan manusia (human-in-the-loop) diperlukan saat perbaikan dapat mengubah makna, izin, dampak finansial, atau status eksternal. Riset keamanan agen menekankan bahwa intervensi keselamatan harus dikaitkan dengan evaluasi risiko, bukan sekadar ambang batas yang seragam. (Source)

Urgensi Operasional: OpenClaw dan Penguatan Berbasis Audit

Adopsi OpenClaw dan panduan keamanan yang ada membuat isu ini menjadi lebih konkret. Laporan dari Tom’s Hardware menyebutkan bahwa Tiongkok melarang penggunaan OpenClaw pada komputer pemerintah dan mengeluarkan pedoman keamanan di tengah adopsi yang meluas. Bagi operator, pelajaran pentingnya bukanlah pada kebijakan utama tersebut, melainkan fakta bahwa akses alat runtime dan verifikasi tidak lagi bisa dianggap opsional saat sistem beroperasi di bawah pengawasan ketat.

Catatan rilis OpenClaw sendiri mendeskripsikan pengembangan berkelanjutan seputar keamanan, termasuk kekhawatiran runtime agen dan penguatan operasional. Meskipun Anda tidak menggunakan OpenClaw, prinsip dasarnya tetap relevan: seiring dengan meluasnya penggunaan sistem agen, verifikasi dan perbaikan harus siap audit (audit-ready), tidak cukup hanya dengan "kewarasan model". Lapisan koreksi yang tidak dapat menunjukkan apa yang diblokir, mengapa diblokir, dan bukti apa yang digunakan akan gagal dalam pengujian operasional.

Dalam praktiknya, "siap audit" berarti mampu menjawab pertanyaan dari regulator dan tim keamanan internal sejak jam pertama, bukan bulan pertama. Ketika sistem mengubah sesuatu (menolak panggilan, menulis ulang parameter, atau eskalasi ke manusia), apa yang sebenarnya terjadi, dan apakah tindakan tersebut dibenarkan oleh sinyal evaluasi yang Anda klaim? Log Anda membutuhkan lebih dari sekadar label keputusan. Anda memerlukan rantai bukti: (1) kandidat pemanggilan alat (nama alat + parameter + target), (2) artefak verifikasi yang memberikan otorisasi (skor judge/rubrik/input bahasa), dan (3) hasil otorisasi (diizinkan/ditolak/dimodifikasi/dieskalasi) beserta aturan spesifik yang dipicu. Tanpa hal tersebut, verifikasi hanyalah sebuah narasi, bukan mekanisme kontrol. (Source)

Arsitektur menentukan hasil audit. Jika Anda menjalankan penilaian judge sebagai kalkulasi sampingan yang tidak terlacak, Anda mungkin memiliki skor tanpa bukti pendukung. Jika Anda hanya membatasi pemanggilan alat setelah eksekusi (pemeriksaan pasca-tindakan), Anda bisa menjelaskan kegagalan tetapi tidak bisa mencegahnya—hal ini melemahkan pengurangan risiko sekaligus kemampuan audit. Jika pembatasan alat dilakukan pra-tindakan dengan keputusan deterministik dan bukti yang terlacak, lapisan koreksi Anda dapat diperiksa, diuji, dan ditingkatkan layaknya kontrol keamanan lainnya.

Studi Kasus: Signifikansi Lapisan Koreksi

Kerangka evaluasi praktis menunjukkan bagaimana kritik dan verifikasi berperilaku saat kondisi penerapan bergeser. Salah satu contoh dari studi evaluasi menunjukkan bahwa skor evaluasi bisa menyesatkan jika rubrik tidak sesuai dengan distribusi operasional, dan penambahan artefak evaluasi terstruktur dapat memperbaiki keandalan. Kesimpulan yang didokumentasikan adalah bahwa verifikasi harus dikalibrasi sesuai kondisi tugas, bukan diasumsikan dapat ditransfer begitu saja. (Source)

Riset infrastruktur pada kontrol akses alat mendukung pandangan "lapisan penegakan" (enforcement layer). Pendekatan ini memperlakukan pemanggilan alat sebagai operasi istimewa dan menggunakan akses terbatas untuk mencegah efek samping yang tidak terkendali, sementara sinyal verifikasi menentukan apakah akan mengizinkan, mengulang, atau menghentikan proses. Hal ini secara langsung menjawab masalah "verifikasi yang tidak bisa memperbaiki": pembatasan alat mengubah sinyal yang lemah menjadi kontrol yang dapat ditegakkan secara hukum. (Source)

Peristiwa operasional terkait OpenClaw menambah konteks lini masa. Laporan Tom’s Hardware mengenai larangan pemerintah dan penerbitan pedoman keamanan membingkai lonjakan adopsi sebagai pendorong penegakan aturan. Tak lama kemudian, catatan rilis OpenClaw menunjukkan iterasi berkelanjutan seputar keamanan runtime. Bagi praktisi, implikasinya sangat praktis: penguatan keamanan dapat terjadi secara mendadak, dan sistem tanpa lapisan koreksi yang siap audit akan terpaksa melakukan perombakan di bawah tekanan.

Jebakan evaluasi multibahasa juga didukung oleh riset mengenai sensitivitas evaluasi dan perilaku rubrik di berbagai prompt dan bahasa. Secara operasional, penerapan multibahasa sering kali baru menyadari belakangan bahwa metrik "kualitas" meningkat dalam bahasa Inggris tetapi tidak di bahasa lain, menyebabkan ambang batas koreksi berperilaku tidak konsisten. Solusinya bukan sekadar menambah terjemahan, melainkan membangun kebijakan evaluasi dan koreksi yang sadar bahasa (language-aware). (Source; Source)

Guardrails Terukur: Angka yang Harus Dipantau

Metrik harus mencerminkan kegagalan produksi, bukan sekadar evaluasi bangku tes. Beberapa sumber literatur evaluasi menekankan bahwa keandalan bergantung pada sinyal terukur seperti tingkat kesalahan di bawah berbagai kondisi. Meskipun sumber-sumber ini lebih fokus pada metodologi, terjemahan operasionalnya sangat langsung: pantau perilaku lulus/gagal berdasarkan bahasa, jenis alat, dan tindakan koreksi. (Source; Source)

Sinyal kuantitatif harus berfokus pada kinerja kontrol, bukan hanya kualitas model. Ukur apa yang berhasil dicegah oleh lapisan koreksi, apa yang gagal dicegah, dan di mana lapisan tersebut memperlambat sistem hingga merusak siklus kerja.

Setidaknya, pantau hal berikut:

1. Blocked-revise rate (cakupan kontrol): Fraksi keputusan pemicu alat di mana verifikasi menandai kegagalan dan sistem menolak atau memodifikasi pemanggilan alat (bukan sekadar memberikan peringatan teks).
2. Unsafe-allow rate (kebocoran kasus terburuk): Fraksi rencana tidak aman di mana sistem judge atau pemeriksaan pra-tindakan meloloskannya, dan eksekusi alat berikutnya mencapai kondisi gagal.
3. Kesesuaian judge-hasil berdasarkan bahasa dan jenis alat: Korelasi antara vonis judge dengan keberhasilan atau kegagalan alat di tahap hilir, disegmentasi berdasarkan versi rubrik dan versi prompt judge. Jika kesesuaian menurun, Anda dapat mendeteksi pergeseran kalibrasi sebelum pengguna menyadarinya.
4. Ketepatan waktu koreksi: Proporsi sesi di mana siklus koreksi selesai dalam batas latensi sehingga pembatasan benar-benar dapat terjadi. Kegagalan siklus refleksi sering kali tampak seperti "koreksi tidak melakukan apa-apa," padahal penyebab utamanya adalah timeout dan batas token. (Source)
5. Beban human-in-the-loop (biaya tata kelola): Tingkat eskalasi dan waktu pengambilan keputusan untuk koreksi risiko tinggi. Eskalasi yang tinggi mungkin demi keamanan, namun bisa juga menandakan masalah rubrik yang menciptakan penolakan salah (false rejects).

Riset evaluasi menekankan sensitivitas rubrik, dan metrik-metrik ini memunculkan hal tersebut secara nyata dalam produksi. (Source; Source)

Cetak Biru Implementasi: Desain Runtime Siap Pakai

Mulailah dengan unit terkecil yang dapat ditegakkan: audit pemanggilan alat dengan eksekusi berizin. Rekam setiap pemanggilan alat beserta parameternya, cakupan otorisasi, dan tautan ke keputusan verifikasi yang mengizinkannya. Kemudian, terapkan pemeriksaan pra-tindakan yang merujuk pada output verifikasi mandiri dan skor judge, namun gunakan skor tersebut hanya sebagai bukti untuk mengizinkan atau menolak pemanggilan alat berikutnya. (Source)

Selanjutnya, implementasikan tindakan koreksi runtime sebagai rangkaian terbatas: tolak pemanggilan alat dan minta klarifikasi, susun ulang rencana dengan rentang parameter terbatas, atau eskalasi ke persetujuan manusia jika tugas berisiko tinggi atau kepercayaan judge rendah. Fokus utamanya adalah determinisme. Lapisan koreksi Anda tidak boleh bergantung sepenuhnya pada model yang sama yang menghasilkan rencana berisiko tersebut. (Source; Source)

Terakhir, kelola perilaku multibahasa. Simpan versi rubrik, prompt judge, dan input deteksi bahasa dalam log jejak. Terapkan ambang batas per bahasa dan lakukan audit pergeseran judge secara berkala. Jika tingkat kelulusan multibahasa berubah tanpa peningkatan hasil yang aman, lakukan rekalibrasi. Sensitivitas evaluasi terhadap prompt dan bahasa adalah tema yang berulang dalam berbagai sumber tervalidasi, dan hal inilah yang membentuk kebijakan koreksi. (Source; Source)

Proyeksi: Apa yang Harus Disiapkan Sebelum Audit Berikutnya

Dalam siklus penerapan berikutnya, perkirakan adanya tekanan kuat untuk kemampuan audit dan penguatan runtime seiring dengan percepatan adopsi agen AI. Tindakan terkait OpenClaw menunjukkan betapa cepatnya batasan operasional dapat mengetat, terutama saat sistem memasuki lingkungan pemerintahan atau pengawasan tinggi. Arsitektur yang "hanya verifikasi" tidak akan lagi dianggap memadai; perbaikan kesalahan runtime dan audit pemanggilan alat akan menjadi standar minimal.

Jadikan hal ini konkret. Tunjuk penanggung jawab keamanan untuk menentukan aturan otorisasi koreksi. Pastikan lapisan runtime agen mampu: (a) memblokir pemanggilan alat pada pemeriksaan pra-tindakan yang gagal, (b) mencatat setiap keputusan otorisasi dengan bukti dari sistem judge dan konteks bahasa, serta (c) mengarahkan koreksi risiko tinggi ke peninjauan manusia. Hal ini selaras dengan infrastruktur kontrol akses alat, mekanisme penegakan yang mencegah lolosnya kesalahan. (Source)

Lini masa sangat menentukan. Pada kuartal berikutnya, implementasikan trace logging ujung-ke-ujung dan audit pemanggilan alat, lalu tambahkan gerbang pra-tindakan dan tindakan pengulangan yang terbatas. Pada dua kuartal mendatang, tambahkan kalibrasi judge multibahasa dengan ambang batas per bahasa dan pantau pergeseran judge. Dengan mengikuti urutan ini, Anda dapat beralih dari sekadar "mampu menjelaskan kegagalan" menjadi "mampu mencegah kegagalan". (Source; Source)

Kesimpulan

Jadikan verifikasi sebagai sensor Anda dan perbaikan runtime sebagai rem Anda. Jika Anda tidak dapat menghentikan efek samping alat yang tidak aman tepat waktu, sistem Anda belum layak menyandang predikat "terverifikasi".