Empat Jebakan Diam-Diam di Angka Benchmark Saya
Di proyek medcoder (asisten AI yang saya kerjakan untuk mengusulkan kode diagnosis ICD-10 dan tindakan ICD-9-CM dari catatan SOAP), saya punya satu stack terpisah khusus buat eksperimen — supaya bisa coba-coba perubahan tanpa mengganggu yang sedang jalan, lalu dibandingkan hasilnya lewat benchmark sintetis internal. Masalahnya: angka dari benchmark itu sempat salah selama berbulan-bulan, dan saya sama sekali tidak sadar, karena empat masalah kecil di setup pengukurannya saling menutupi satu sama lain.
Empat Masalah yang Ditemukan Sekaligus
Semuanya ketahuan dalam satu sesi investigasi yang sama:
- Stack eksperimen ketinggalan kamus. Stack yang dipakai buat eksperimen ternyata tidak punya 83 singkatan klinis yang sudah ada di stack produksi. Akibatnya, hasil untuk kategori gigi terlihat sekitar 5,5 poin lebih bagus dari kenyataan — bukan karena perubahan kodenya memang bagus, tapi karena stack ujinya kebetulan lebih pintar duluan di bagian kamus.
- Produksi ketinggalan sinonim kode tindakan. Sebaliknya, produksi ternyata kekurangan sekitar 141 kode ICD-9-CM bersinonim yang sudah ada di stack eksperimen. Jadi untuk metrik ini arahnya kebalik — akurasi kode tindakan di produksi sebenarnya lebih buruk dari yang dilaporkan benchmark.
- Semua kasus uji lewat satu akun yang sama. Seluruh kasus benchmark, termasuk puluhan kasus rumah sakit dan puluhan kasus gigi, ternyata dikirim lewat satu akun uji tunggal yang terikat ke satu jenis fasilitas saja (klinik rawat jalan/FKTP). Jadi bagian mana pun dari sistem yang perilakunya seharusnya berbeda tergantung jenis fasilitas, tidak pernah benar-benar diuji dengan jenis fasilitas yang benar.
- Gerbang pengecekan kesiapan ikut kena. Sistem punya semacam gerbang warm-up yang mengecek kesiapan sebelum dianggap layak diukur. Gerbang ini ternyata juga memakai akun uji yang sama itu — dan karena memori riwayat koding di sistem ini dipisah per fasilitas, riwayat milik rumah sakit yang sebenarnya jadi tidak pernah terlihat oleh gerbang ini. Jadi gerbang itu diam-diam selalu menguji skenario fasilitas baru tanpa riwayat, bukan fasilitas yang sebenarnya sedang berjalan.
Kenapa Susah Ketahuan: Saling Menutupi
Yang bikin empat hal ini bertahan lama tanpa ketahuan adalah tiga yang pertama saling menutupi efeknya satu sama lain di angka agregat — tidak ada satu pun yang, dilihat sendirian, kelihatan jelas salah. Angka akhirnya kelihatan wajar, kadang malah kelihatan bagus, jadi tidak ada alasan untuk curiga.
Yang akhirnya membongkar semuanya justru kejadian yang kelihatannya remeh: satu ronde benchmark keluar dengan angka identik sampai desimal terakhir dengan ronde sebelumnya — padahal di antara dua ronde itu ada perubahan kode yang seharusnya mempengaruhi hasil. Kecocokan sempurna seperti itu seharusnya jadi tanda bahaya, bukan dianggap kebetulan bagus: itu bukti bahwa perubahan kodenya tidak pernah benar-benar aktif diuji.
Fix dan Kebiasaan Baru
Saya bikin dua script pemeriksa yang sekarang jadi wajib dijalankan: satu untuk mengecek sinkronisasi antara stack eksperimen dan produksi sebelum percaya angka apa pun, satu lagi untuk memeriksa korpus data setiap kali ada impor data uji baru. Dua-duanya murni pemeriksaan konsistensi setup, bukan mengubah logika sistem sama sekali.
Aturan baru yang saya pegang sekarang: kalau dua ronde benchmark keluar identik persis, jangan buru-buru simpulkan perubahan ini tidak berpengaruh — periksa dulu apakah perubahannya benar-benar aktif dijalankan di ronde itu. Kesamaan sempurna itu jauh lebih sering berarti pengukurannya rusak daripada perubahannya memang tidak berdampak.
Pelajaran
Setup pengukuran itu sendiri adalah bagian dari sistem yang harus dijaga sama seriusnya dengan kode produksinya. Empat hal di atas semuanya soal ketidakcocokan diam-diam antara apa yang diuji dan apa yang sebenarnya berjalan — dan karena efeknya saling menutupi, tidak ada satu angka pun yang kelihatan salah sampai saya sengaja mencari ketidakcocokan itu satu per satu. Kalau kamu punya stack eksperimen terpisah dari produksi, jangan anggap keduanya otomatis sinkron — buat pemeriksaan eksplisit yang memastikan itu, dan curigai hasil yang terlalu rapi atau terlalu identik.