Stop Menembak Nyamuk dengan Meriam: Anatomi Membangun Decision Model Mandiri di Production
Kecenderungan default tim rekayasa perangkat lunak belakangan ini seragam: setiap kali ada kebutuhan klasifikasi, routing data, atau filtering intent, solusinya adalah menembakkan prompt ke LLM. Perlu menentukan apakah sebuah transaksi berisiko tinggi? Panggil API model 8B parameter. Perlu mengarahkan tiket dukungan teknis ke divisi yang tepat? Gunakan LLM komersial via cloud.
Pendekatan ini adalah bentuk kemalasan arsitektur. Memakai generative model untuk masalah diskrit menghasilkan tiga masalah fatal: p99 latency yang membengkak hingga satuan detik, biaya komputasi yang tidak scalable, serta hilangnya determinisme sistem.
Tulisan Nish Tahir mengenai pembuatan decision model mandiri mengangkat kembali disiplin rekayasa sistem yang sempat tergeser oleh euforia generatif. Di production, keputusan operasional membutuhkan model yang cepat, murah, dan sepenuhnya dapat diaudit. LLM bukan instrumen yang tepat untuk pekerjaan ini.
---
Problem Statement: Patologi "LLM-as-a-Hammer"
Ketika sebuah sistem bergantung pada LLM untuk pengambilan keputusan biner atau kategorikal (misalnya: allow/block, route-to-queue-A/route-to-queue-B), arsitektur tersebut menanggung beban teknis yang tidak rasional:
- Latency Penalty: Panggilan jaringan eksternal ke provider LLM rata-rata memakan waktu 400 milidetik hingga 2 detik per inferensi. Bahkan jika model di-host secara lokal via vLLM atau TGI, time-to-first-token (TTFT) masih berada di kisaran puluhan hingga ratusan milidetik. Bandingkan dengan decision tree terkompilasi yang mengeksekusi inferensi dalam sub-milidetik (kurang dari 2 milidetik pada CPU standar).
- Non-Determinism: Menyetel
temperature=0tidak menjamin determinisme 100% pada LLM modern akibat optimasi floating-point non-asosiatif dalam batching konkuren di GPU. Di sistem keuangan atau tata kelola kepatuhan, fluktuasi output dengan input identik adalah mimpi buruk audit. - Overhead Sumber Daya: Mengalokasikan puluhan gigabyte VRAM GPU hanya untuk mengekstraksi nilai boolean adalah pemborosan modal (CapEx) dan operasional (OpEx).
Solusinya bukan mencari LLM yang lebih kecil, melainkan kembali ke prinsip fit-for-purpose: membangun decision model spesifik menggunakan algoritma machine learning klasik atau arsitektur jaringan saraf dangkal (shallow neural networks).
---
Mekanisme di Balik Layar: Pipeline dan Runtime
Membangun decision model mandiri tidak mengharuskan tim membangun arsitektur deep learning dari nol. Dalam skenario operasional, model keputusan umumnya bertumpu pada supervised learning klasik seperti Gradient Boosted Decision Trees (XGBoost, LightGBM, CatBoost) atau klasifikasi berbasis representasi vektor padat.
Arsitektur produksi tipikal untuk decision model mandiri beroperasi dalam siklus berikut:
1. Feature Representation & Vectorization
Data mentah diubah menjadi representasi numerik. Jika data bertipe tabular (metadata transaksi, status akun, histori log), pemrosesan melibatkan normalisasi numerik dan one-hot encoding atau target encoding untuk fitur kategorikal. Jika input berupa teks tidak terstruktur (misalnya: pesan dari pengguna), alih-alih melempar seluruh teks ke LLM, teks tersebut dilewatkan ke model embedding ringan (seperti MiniLM atau BGE-small) atau bahkan ekstraktor berbasis n-gram/TF-IDF jika latensi ekstrem diperlukan.
2. Model Selection & Inductive Bias
Untuk data tabular dan keputusan dengan batas tegas (hard boundaries), GBDT (Gradient Boosted Decision Trees) secara konsisten mengungguli deep learning. GBDT mampu menangani missing values, tahan terhadap outliers fitur, dan memetakan fungsi keputusan non-linear dengan parameter memori yang kecil. Jika relasi fitur murni linear atau semi-linear, Logistic Regression dengan regularisasi L1/L2 sering kali sudah memadai dan mengeksekusi inferensi dalam skala mikrosekon.
3. Compilation dan Deployment Topology
Kesalahan fatal yang sering dilakukan tim adalah mendeploy model ML Python langsung menggunakan runtime runtime Flask atau FastAPI lambat dengan dependensi bloated.
Arsitektur optimal menuntut pemisahan tahap pelatihan dan inferensi:
- Training Phase: Dilakukan di Python menggunakan ekosistem standar (scikit-learn, LightGBM).
- Exporting Phase: Model di-export ke format portabel dengan representasi perantara seperti ONNX (Open Neural Network Exchange) atau ditranspilasi ke kode C native menggunakan Treelite.
- Serving Phase: Runtime inferensi di-embed langsung ke dalam binary service utama (misalnya aplikasi Go atau Rust) menggunakan binding ONNX Runtime atau compiled C-libraries.
Dengan topologi ini, inferensi menjadi operasi in-memory murni. Network hop antar-service dieliminasi sepenuhnya.
[Request Input]
│
▼
[Feature Extraction] (Rust/Go In-Memory)
│
▼
[Compiled Model Runtime] (ONNX Runtime / C-Treelite) ──► Latensi: <2ms (CPU)
│
▼
[Deterministic Output]---
Matriks Trade-Off: Cost vs. Complexity
Keputusan beralih dari LLM API ke custom decision model bukanlah keputusan tanpa konsekuensi. Ini adalah pertukaran antara CapEx teknis (beban kerja engineer di awal) dan OpEx jangka panjang (biaya inferensi dan keandalan sistem).
| Parameter | LLM via API (e.g., OpenAI / Anthropic) | In-House Decision Model (GBDT / ONNX) | | :--- | :--- | :--- | | Setup Cost (CapEx) | Sangat Rendah. Cukup rekayasa prompt dan beberapa baris kode integrasi. | Tinggi. Membutuhkan pengumpulan data, pelabelan, feature engineering, dan tuning. | | Inference Cost (OpEx) | Skala linear per token. Membengkak tajam seiring volume request harian. | Mendekati nol. Berjalan di CPU cluster yang sudah ada tanpa butuh node GPU khusus. | | Latency Profile | p99 di kisaran 500ms hingga 3000ms. Rentan terhadap throttling API dan degradasi jaringan. | p99 konsisten di bawah 5ms. Berjalan in-process atau local daemon. | | Determinisme & Audit | Kotak hitam. Penjelasan keputusan bergantung pada halusinasi LLM berikutnya. | Tinggi. Fitur penting (SHAP values) dapat dilacak secara matematis per inferensi. | | Maintenance Burden | Rendah di level pipeline, tapi tinggi pada penanganan regresi output akibat perubahan model provider. | Tinggi pada monitoring data drift, concept drift, dan kebutuhan pipeline re-training otomatis. |
Menggunakan LLM menghemat waktu rekayasa di minggu pertama. Namun pada bulan keenam, saat volume traffic mencapai jutaan request per hari, tagihan API dan kegagalan timeout p99 mulai menghancurkan margin operasional serta SLA sistem.
---
Jebakan Produksi yang Harus Diwaspadai
Membangun decision model mandiri memindahkan tanggung jawab operasional kembali ke pundak tim internal. Ada tiga jebakan yang kerap memicu kegagalan sistem:
- Concept Drift dan Data Drift:
Model keputusan statis bekerja optimal pada distribusi data yang dipelajarinya saat training. Jika perilaku pengguna berubah, akurasi model akan terdegradasi tanpa adanya peringatan error log. Sistem produksi wajib dilengkapi logging distribusi fitur untuk mendeteksi drift secara statistik (misalnya via uji Kolmogorov-Smirnov atau Population Stability Index) sebelum performa anjlok.
- The Ground Truth Problem:
Model membutuhkan data terlabel berkualitas. Mengandalkan pelabelan manual manusia memakan waktu lama. Salah satu pola hibrida modern yang efektif adalah menggunakan LLM secara asinkronus di background hanya untuk menghasilkan label training awal (weak supervision), lalu melatih model keputusan kecil dari dataset tersebut untuk dieksekusi di jalur kritis produksi.
- Feature Leakage:
Dalam inferensi real-time, ketersediaan fitur harus sinkron dengan kondisi saat data diterima. Menyertakan fitur yang hanya terisi setelah aksi terjadi (misalnya: data status akhir transaksi) saat melatih model klasifikasi fraud akan menghasilkan metrik evaluasi yang luar biasa tinggi saat testing, tetapi hancur total saat live di production.
---
Panduan Tindakan untuk Staff & Principal Engineer
Jika tim Anda saat ini berencana mengintegrasikan LLM untuk fitur baru, jalankan evaluasi berikut sebelum menulis satu baris prompt pun:
- Petakan Output Space: Jika output yang dibutuhkan adalah ruang diskrit terbatas (klasifikasi kategori, boolean flag, skor ranking, routing ID), tolak penggunaan LLM secara langsung di jalur request sinkronus.
- Ukur Batas Toleransi Latensi (SLA): Jika sistem menuntut p99 di bawah 50 milidetik, core path sistem Anda tidak boleh memiliki dependensi jaringan ke inference engine berbasis transformer besar.
- Mulai dari Baseline Paling Sederhana: Jangan langsung beralih ke deep learning jika GBDT atau Logistic Regression cukup. Implementasikan model baseline scikit-learn/LightGBM, ukur metrik F1-score atau AUC-ROC terhadap target bisnis, lalu ekspor ke ONNX.
- Gunakan LLM sebagai Tooling, Bukan Runtime: Manfaatkan LLM untuk membantu data augmentation, auto-labeling data historis, atau ekstraksi fitur offline. Biarkan model keputusan terkompilasi yang menangani lalu lintas produksi di layer runtime.
Efisiensi komputasi dan kesederhanaan arsitektur tetap merupakan keunggulan kompetitif fundamental dalam rekayasa perangkat lunak. Model berukuran 5 megabyte yang dieksekusi dalam 1 milidetik di atas CPU selalu lebih unggul daripada model 70 miliar parameter yang lambat, mahal, dan tidak terprediksi.
