Belajar ML Engineer - Siklus Hidup & Arsitektur ML
Membedah siklus hidup sistem ML dari problem framing, data, model, deployment, monitoring, sampai iterasi, plus arsitektur tiga lapis (training, serving, monitoring) dan mengapa setiap komponen punya tanggung jawab yang berbeda dalam menjaga sistem tetap sehat
#Pendahuluan
Setelah di episode 1 kita memetakan peran MLE di antara data scientist dan software engineer, pada episode ini kita membangun gambaran utuh tentang bagaimana sistem ML hidup di dunia nyata. Banyak pemula membayangkan ML sebagai "training model lalu selesai" — padahal training hanya satu titik kecil dalam perjalanan panjang yang disebut ML lifecycle.
Memahami lifecycle dan arsitektur sejak awal akan mengubah cara kalian berpikir: setiap keputusan di tahap awal (definisi masalah, pemilihan data, desain feature) berdampak langsung pada biaya operasional dan keandalan sistem di tahap akhir. Episode ini adalah blueprint yang akan dirujuk terus oleh semua episode berikutnya.
#Siklus Hidup Sistem ML
Sebuah sistem ML yang sehat berjalan dalam siklus tertutup, bukan garis lurus:
#1. Problem Framing
Semua dimulai dari pertanyaan bisnis: "prediksi churn", "rekomendasi produk", "deteksi fraud". Tugas MLE di tahap ini adalah mengubah masalah bisnis menjadi masalah ML yang terdefinisi: apa input-nya, apa target-nya, metrik apa yang sukses, dan seberapa sering prediksi dibutuhkan. Kesalahan paling umum adalah langsung memilih model sebelum masalah terdefinisi — garbage framing, garbage system.
#2. Data dan Label
Data adalah bahan bakar sistem. Di tahap ini kalian: mengumpulkan data dari pipeline (episode 17), membersihkannya, membuat label (jika supervised), membagi train/val/test, dan memastikan data mencerminkan dunia nyata. Keputusan di sini menentukan hampir seluruh hasil akhir — model terbaik pun tidak bisa menebak pola yang tidak ada di data.
#3. Model Training dan Evaluation
Kalian melatih model, mencatat eksperimen (episode 6), dan mengevaluasi secara jujur (episode 7). Di dunia produksi, kalian juga menjaga reproduksibilitas: data, kode, dan model harus bisa ditelusuri (episode 8). Evaluasi bukan sekali jalan — kalian menguji terhadap beberapa threshold, memeriksa kalibrasi, dan membandingkan baseline.
#4. Deployment
Model dikemas ke container (episode 9) dan disajikan lewat API. Bisa sebagai batch prediction (menjalankan prediksi untuk ribuan baris sekaligus) atau online inference (prediksi real-time per request). CI/CD ML (episode 10) memastikan perubahan kode atau data tidak mengirim sistem yang rusak ke produksi.
#5. Monitoring dan Iterasi
Setelah live, sistem tidak selesai. Kalian memantau latensi, error rate, dan drift — perubahan distribusi data yang diam-diam menurunkan kualitas model (episode 11). Monitoring yang baik adalah umpan balik ke tahap framing: model yang drop performanya memicu retraining atau bahkan re-framing masalah.
#Arsitektur Sistem ML
Sistem ML produksi tersusun dari tiga lapis utama yang terpisah secara fisik maupun tanggung jawab:
| Lapisan | Komponen | Tugas Utama |
|---|---|---|
| Training | Pipeline data, trainer, experiment tracking | Menghasilkan model dari data historis |
| Serving | API server, model runtime, cache | Menyajikan prediksi ke konsumen |
| Monitoring | Logging, metrik, alerting, drift detection | Menjaga sistem tetap sehat & teramati |
#Training Layer
Di lapisan ini terjadi semua pekerjaan "sebelum produksi": ekstraksi data dari warehouse, transformasi feature, training, dan evaluasi. Biasanya berjalan sebagai job terjadwal (misal nightly) atau dipicu event (retraining saat data baru tiba). Output utamanya adalah model artifact + metadata (hyperparameter, dataset hash, metrik) yang disimpan di model registry.
#Serving Layer
Model artifact disajikan ke aplikasi. Dua pola utama:
- Online serving: API REST/gRPC menjawab permintaan per-request dengan latensi rendah (rekomendasi, fraud check).
- Batch serving: prediksi dijalankan terjadwal untuk sekumpulan data (skor churn untuk seluruh customer tiap malam).
Layer ini juga menangani masalah yang sering diremehkan: load balancing, cache untuk hasil yang sama, dan fallback saat model gagal.
#Monitoring Layer
Lapisan yang paling sering dilupakan tetapi paling menentukan usia sistem. Di sini kalian mengumpulkan: metrik infrastruktur (latensi, throughput, error), metrik data (distribusi feature, missing value), dan metrik bisnis (konversi, kerugian fraud). Ketiganya digabungkan untuk mendeteksi masalah sebelum pengguna mengeluh.
#Pola Arsitektur yang Harus Dihindari
Berdasarkan pengalaman lapangan, ada beberapa anti-pattern arsitektur yang sering muncul:
| Anti-pattern | Masalah |
|---|---|
| Model + business logic dalam satu service | Deploy model = deploy ulang seluruh aplikasi |
| Feature engineering hanya di notebook | Logic transformasi tidak konsisten antara training & serving |
| Tanpa model registry | Tidak tahu model mana yang sedang live dan kenapa |
| Tanpa monitoring data | Model diam-diam menurun selama berbulan-bulan tanpa disadari |
Semua anti-pattern ini akan kita bongkar satu per satu di episode-episode berikutnya.
#Contoh Arsitektur Nyata: Model Churn
Untuk memperjelas, mari terapkan tiga lapis arsitektur pada satu contoh yang akan terus kita pakai di series ini: model prediksi churn pelanggan.
| Lapisan | Komponen | Contoh Konkret |
|---|---|---|
| Training | Pipeline data | Job malam: agregasi event 30 hari dari warehouse, simpan dataset ber-version |
| Training | Trainer | XGBoost/Logistic Regression dengan tracking MLflow, simpan ke registry |
| Serving | API | FastAPI/BentoML: menerima user_id, mengambil feature, mengembalikan probabilitas churn |
| Serving | Feature lookup | Feature dihitung batch tiap malam, diambil saat request (bukan dihitung di request) |
| Monitoring | Metrik | Latensi p95, error rate, PSI feature event_count tiap hari |
| Monitoring | Loop | Drift tinggi → retraining terjadwal → model baru lewat gerbang evaluasi |
Perhatikan pola penting yang muncul: training dan serving memakai feature yang sama — feature dihitung sekali di malam hari, disimpan, lalu dipakai kedua lapisan. Inilah bentuk awal dari feature store yang akan kita bangun lengkap di episode 17.
#Menerapkan Lifecycle pada Keputusan Sehari-hari
Kekuatan blueprint ini terlihat saat kalian menghadapi keputusan kecil sehari-hari. Setiap pertanyaan berikut punya jawaban yang menjadi lebih jelas dengan mental model lifecycle:
- "Harus mulai dari mana?" → Problem framing (episode 2-3) — bukan langsung memilih model.
- "Data apa yang dibutuhkan?" → Data & feature (episode 4, 17).
- "Model yang mana?" → Training & evaluasi (episode 5, 7) — keputusan berbasis metrik.
- "Bagaimana meluncurkan?" → Deployment & CI/CD (episode 9-10).
- "Bagaimana menjaga tetap sehat?" → Monitoring (episode 11) — umpan balik ke iterasi.
Pola pikir inilah yang membedakan MLE dari sekadar "orang yang memanggil fit". Setiap masalah bisnis, kalian terjemahkan ke siklus ini dan tahu persis di titik mana kalian berada serta langkah apa berikutnya.
#Penutup
Pada episode 2 ini, kalian telah membangun blueprint sistem ML:
- ML lifecycle adalah siklus tertutup: framing → data → model → deployment → monitoring → iterasi.
- Arsitektur sistem ML terbagi tiga lapis: training, serving, monitoring — masing-masing dengan tanggung jawab berbeda.
- Monitoring adalah umpan balik yang menggerakkan iterasi; tanpa monitoring, sistem hanya menua diam-diam.
- Hindari anti-pattern: service yang menyatukan model & bisnis, feature logic yang terpecah, dan registry yang tidak ada.
Di episode 3 selanjutnya kita akan masuk ke praktik pertama: Python for ML Production — menulis kode Python yang layak produksi dengan NumPy/Pandas, dataclasses, type hint, dan testing, plus refactor notebook menjadi kode modular yang bersih. Sampai jumpa di episode 3!