Saya menemukan bahwa satu metrik safety-gate menyembunyikan pemadaman (outage) selama sehari penuh pada fitur penjelasan berbasis AI. Dengan memperlakukan "penolakan gerbang" (gate rejection) dan "kegagalan pemuatan model" (model load failure) sebagai hal yang sama, metrik tersebut memberikan kesan kesehatan sistem yang palsu. Metrik tersebut mencatat empat penolakan dan nol keberhasilan, padahal model tidak pernah berjalan selama periode tersebut—sebuah kesalahan yang bisa membuat operator buta terhadap sistem yang rusak.
Bagaimana kebingungan itu terjadi
Fitur ini menggunakan model bahasa lokal untuk mengubah logika mesin mentah menjadi kalimat yang dapat dibaca manusia. Sebuah safety gate di hilir (downstream) memblokir setiap output yang melanggar aturan yang telah ditentukan. Di produksi, saya mengekspos satu counter tunggal yang bertambah setiap kali gerbang menolak sebuah kalimat. Ketika drone mencatat empat penjelasan AI, counter melaporkan empat penolakan dan tidak ada output yang berhasil. Saya menganggap hal itu sebagai gerbang yang menjalankan tugasnya, bukan sebagai fitur yang sedang mati.
Apa yang ditutupi oleh counter tersebut adalah kegagalan dua tahap:
- Model tidak berjalan – Model berbagi mesin dengan sisa sistem lainnya. Untuk menghemat memori, host akan mengosongkannya (unload) setelah tidak ada aktivitas.
- Timeout saat pemuatan ulang – Ketika ancaman baru muncul, sistem mencoba memuat ulang data model sekitar dua gigabyte. Pemuatan ulang tersebut melebihi batas waktu respons (timeout) tiga puluh detik, sehingga permintaan mengalami timeout dan mengembalikan jawaban kosong.
Karena counter memperlakukan penolakan gerbang dan jawaban kosong akibat timeout sebagai peristiwa yang sama, dashboard menunjukkan "safety gate berfungsi" padahal fitur AI tersebut sebenarnya mati.
Mengapa hal ini penting
Dalam produk berbasis AI, safety gate menghentikan output yang berbahaya atau tidak masuk akal. Operator memantau laju (fire rate) gerbang sebagai sinyal kesehatan. Ketika sinyal tersebut menyatu dengan mode kegagalan yang tidak terkait, metrik tersebut menjadi kebohongan yang sunyi: ia memberikan rasa aman padahal layanan tidak tersedia.
Perbaikan yang memulihkan visibilitas
Saya melakukan tiga perubahan praktis:
- Menjaga model tetap ada (resident) – Menyesuaikan host untuk mempertahankan model di dalam memori, sehingga menghilangkan penundaan pemuatan ulang.
- Memperpanjang timeout – Meningkatkan jendela respons untuk menangani pemuatan lambat yang sesekali terjadi.
- Memisahkan counter – Mengganti metrik tunggal "ditolak oleh gerbang" dengan empat counter yang berbeda: accepted, rejected, empty response, dan no answer.
Langkah ketiga terbukti menentukan. Alih-alih satu angka yang bisa diartikan secara ambigu, rincian empat bagian tersebut menunjukkan apakah safety gate aktif, apakah model memberikan jawaban, atau apakah permintaan tersebut tidak pernah mencapai model sama sekali.
Trade-offs dan argumen penentang
Apa yang harus diperhatikan selanjutnya
Pengembang yang meluncurkan komponen AI harus mengaudit setiap counter agregat yang mencampur pemeriksaan keamanan dengan kegagalan tingkat sistem. Membangun log riwayat terperinci yang mencatat jalur setiap permintaan—awal pemuatan model, evaluasi gerbang, hasil akhir—menyediakan data forensik yang diperlukan untuk mendeteksi masalah tersembunyi.
Intisari: Metrik "gate-rejection" tunggal dapat menyembunyikan layanan AI yang mati; membagi metrik tersebut menjadi peristiwa-peristiwa penyusunnya akan mengungkap kebenaran dan mencegah kepercayaan palsu pada sistem yang sebenarnya tidak berfungsi.