Satu Aturan Prompt yang Rapuh: Nambah atau Kurangi, Dua-Duanya Merusak

Di proyek medcoder (asisten AI yang saya kerjakan untuk mengusulkan kode diagnosis ICD-10 dan kode tindakan ICD-9-CM dari catatan SOAP), ada satu aturan kecil di prompt yang mengatur kapan sebuah kode tindakan sebaiknya diikutkan, termasuk satu pengecualian khusus untuk kasus yang ditandai "cito" (istilah untuk kondisi mendesak/darurat). Saya kira ini aturan yang aman untuk dirapikan sedikit. Ternyata saya salah besar, dan pelajarannya baru benar-benar kelihatan setelah saya coba dari dua arah berlawanan.

Aturan yang Ternyata Satu Kesatuan yang Rapuh

Catatan lama saya cuma memperingatkan satu arah: jangan menambah kualifikasi ke aturan ini, karena pernah diuji dan hasilnya model mengembalikan daftar kode tindakan yang KOSONG TOTAL — bukan cuma berkurang, tapi nol sama sekali, dan itu konsisten terjadi di empat kali percobaan berturut-turut.

Karena peringatan lama itu cuma soal "menambah", saya pikir mengurangi pasti aman-aman saja. Saya coba membuang satu klausa pengecualian saja — yang mengatur soal kasus bertanda cito tadi — dengan asumsi ini perubahan kecil dan searah dengan tujuan saya (menyederhanakan prompt). Hasilnya, terukur di tanggal yang sama:

Akurasi diagnosis utama untuk kategori FKTP (fasilitas kesehatan tingkat pertama) turun dari 87,5% ke 86,7%.
Akurasi diagnosis utama untuk kategori FKRTL (fasilitas rujukan tingkat lanjut) turun dari 80,0% ke 78,9%.
Yang paling mengejutkan: skor F1 untuk kode tindakan di kategori FKRTL — bagian yang justru ingin saya perbaiki — malah ANJLOK dari 19,6% ke 17,5%. Persis kebalikan dari yang saya targetkan.

Jadi bukan cuma "menambah" yang berbahaya seperti dugaan awal saya — "mengurangi" pun sama merusaknya, dan efeknya menjalar ke bagian yang bahkan tidak berhubungan langsung (diagnosis, bukan cuma tindakan).

Yang Menarik: Aturannya Sendiri Sebenarnya Benar

Bagian yang menurut saya paling penting dari kejadian ini bukan soal kerusakannya, tapi soal validasi aturannya. Sebelum menyimpulkan bahwa aturan cito ini cuma beban yang perlu disederhanakan, saya cek dulu apakah pengecualian itu memang mencerminkan sesuatu yang nyata di data klaim asli.

Dari 61.606 kunjungan klaim historis, saya bandingkan dua kelompok teks: yang ditandai "cito" dan yang ditandai bersyarat (kondisional). Hasilnya jelas: teks ber-cito dikode dengan kode tindakan pada 72% kasus (23 dari 32), sementara teks bersyarat cuma 18% (246 dari 1.382). Beda yang sangat besar, dan konsisten dengan kebiasaan koding nyata di lapangan.

Artinya aturan itu sendiri BENAR — dia menangkap pola asli yang memang ada di cara koder sungguhan bekerja. Masalahnya bukan di desain aturannya, tapi di batas kemampuan model 9B ini untuk memegang aturan bersyarat seperti itu tanpa goyah begitu strukturnya disentuh sedikit pun.

Biaya dan Solusi

Eksperimen mengurangi ini memakan sekitar dua ronde benchmark penuh (kira-kira 3 jam), dan sempat membuat prompt saya naik dua versi sebelum akhirnya saya kembalikan lagi ke versi semula begitu angkanya jelas-jelas memburuk. Solusinya sederhana sebenarnya: jangan sentuh aturan ini sama sekali untuk model ukuran ini — perlakukan sebagai satu kesatuan yang rapuh, bukan kumpulan klausa yang bisa diutak-atik satu-satu.

Saya sengaja meninggalkan bukti perbandingan 72:18 itu langsung sebagai komentar di kode prompt-nya, supaya kalau suatu saat saya (atau siapa pun yang meneruskan proyek ini) mencoba model yang lebih kuat, aturan ini bisa langsung diuji ulang tanpa perlu menggali dulu kenapa aturan itu ada.

Pelajaran

Akar kelemahan kode tindakan di kategori FKRTL ternyata bukan soal pencarian kandidat kode (recall kandidatnya sudah cukup tinggi, sekitar 80%) — masalahnya ada di keputusan model soal kapan harus mengeluarkan kode dan kapan tidak, sesuatu yang jauh lebih halus daripada sekadar "kode ini ada di daftar kandidat atau tidak".

Yang saya bawa pulang: kalau sebuah aturan di prompt sudah terbukti rapuh ke satu arah (menambah), jangan otomatis mengasumsikan arah sebaliknya (mengurangi) itu aman. Uji dua-duanya secara eksplisit sebelum menyentuh apa pun — dan kalau sebuah aturan ternyata tervalidasi benar oleh data asli tapi model tetap kesulitan memegangnya, itu tanda batas kemampuan model, bukan alasan untuk membuang aturannya.