Menjalankan Asisten Coding Medis di Atas Ollama Lokal

Beberapa waktu lalu saya membangun medcoder, aplikasi kecil yang saya deploy sendiri di Mac Studio di rumah. Tujuannya sederhana: membantu petugas rekam medis di klinik rawat jalan mengusulkan kode diagnosis dan tindakan standar (ICD-10 dan ICD-9-CM) dari catatan medis yang ditulis dokter atau perawat. Saya tegaskan dari awal: ini bukan alat yang mengambil keputusan medis, cuma membantu bagian administratif penomoran kode yang selama ini dikerjakan manual dan rawan salah ketik atau salah pilih kode.

Karena datanya sensitif dan saya ingin kontrol penuh, semuanya saya jalankan sendiri (self-hosted), bukan lewat API model AI komersial di cloud.

Arsitektur: kenapa model bahasanya tidak ikut masuk container

Layanan web dan API medcoder jalan di container Docker seperti biasa. Tapi model bahasa (LLM) yang jadi otaknya saya jalankan langsung di sistem operasi Mac, di luar Docker, lewat Ollama. Alasannya teknis: supaya inferensi bisa memakai chip Apple Silicon secara penuh. Kalau LLM ikut dibungkus container, akselerasi hardware-nya tidak maksimal. Jadi arsitekturnya jadi hybrid — container-container tadi memanggil Ollama lewat jaringan internal Docker ke proses yang jalan native di host.

Root cause: model kecil itu suka mengarang

Sebelum memutuskan model mana yang dipakai produksi, saya bikin semacam ujian: 13 kasus uji "emas" yang sudah saya tahu jawaban benarnya, lalu hasil dari tiap model diperiksa oleh proses juri independen ganda (dua penilaian terpisah, bukan cuma satu pemeriksaan sepihak).

Hasilnya cukup mengejutkan. Model-model kecil ternyata sering berhalusinasi — mengarang kode tindakan yang sebenarnya sama sekali tidak disebutkan di catatan medis. Dari 10 kasus di mana seharusnya tidak ada kode tindakan sama sekali, model kecil salah di 9 kasus: dia tetap "menemukan" tindakan yang tidak ada. Untuk kasus penggunaan seperti ini, itu jelas berbahaya — salah satu hal terakhir yang saya mau adalah sistem yang percaya diri mengarang data medis.

Model menengah dengan 9 miliar parameter yang akhirnya saya pilih justru nol halusinasi dari 55 prediksi uji. Bukan berarti model besar otomatis lebih pintar untuk semua hal, tapi untuk kasus "jangan mengarang kalau tidak ada buktinya", ukuran dan kualitas model ternyata sangat menentukan.

Kejutan teknis dari model "berpikir"

Model yang saya pakai termasuk kategori reasoning/thinking model — dia biasanya menuliskan proses berpikirnya sebelum menjawab. Enak untuk debugging manual, tapi berantakan kalau outputnya mau diparsing otomatis oleh sistem. Solusinya: mode penjelasan langkah berpikir itu harus dipaksa dimatikan secara eksplisit supaya keluarannya rapi dan bisa diparsing terstruktur.

Kejutan kedua soal memory. Kalau ukuran context window tidak diberi tahu secara eksplisit, model ini load dengan ukuran default yang jauh lebih besar dari kebutuhan sebenarnya — dan itu bikin memory Mac penuh sampai mulai swap ke disk, yang tentu saja memperlambat semuanya. Fix-nya: set context window secara eksplisit sesuai kebutuhan nyata, bukan mengandalkan default.

Belakangan saya sadar ada kebiasaan aneh ketiga: arsitektur model ini (tipe hybrid/recurrent) membuat pemakaian RAM-nya perlahan naik terus selama dipakai lama tanpa henti. Rupanya dia menyimpan semacam cache internal yang terus menumpuk selagi jalan.

Solusi dan pelajaran

Untuk masalah cache yang menumpuk, saya tidak buru-buru mencari perbaikan rumit di level model. Solusinya justru sederhana: jadwal otomatis tengah malam yang me-restart proses model itu setiap hari. Cache-nya jadi ke-reset rutin sebelum sempat membengkak, tanpa mengganggu jam kerja klinik.

Kadang solusi paling robust bukan yang paling elegan secara teknis, tapi yang paling gampang dipercaya jalan tiap hari tanpa saya awasi.

Yang saya bawa pulang dari proyek ini: sebelum percaya sebuah model AI untuk kasus yang berdampak nyata, uji dulu dengan kasus yang jawabannya sudah kamu tahu — termasuk kasus "seharusnya tidak ada jawaban". Dan untuk operasional harian, jangan lupa hal-hal membosankan seperti manajemen memory dan restart terjadwal — itu yang justru sering menentukan apakah sistem AI kamu stabil dalam jangka panjang atau tidak.