Model dengan akurasi bagus di notebook itu baru separuh cerita. Separuh lainnya — yang dulu saya abaikan total — adalah bagaimana model itu tetap hidup di produksi: di-retrain saat data berubah, bisa dilacak versinya, di-deploy tanpa drama, dan dipantau performanya. Itulah MLOps. Angkat seperti DevOps tapi objek yang di-deploy bukan kode, melainkan kode + data + model sekaligus. Episode ini catatan saya memahami empat pilar MLOps.
Pilar 1: Pipeline yang Reproducible
Pipeline ML adalah rangkaian langkah dari data mentah sampai model terlatih: ingest, cleaning, feature engineering, training, evaluasi. Masalah klasik notebook: urutan eksekusi sel acak, hasil tiap run beda, tidak ada yang tahu model produksi dibuat dari data versi mana. Prinsipnya sama seperti CI/CD: setiap artefak harus bisa direproduksi dari sumbernya. scikit-learn punya abstraksi Pipeline yang menyatukan preprocessing dan model jadi satu objek — mengurangi kebocoran data antara train dan test:
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import cross_val_score
from sklearn.datasets import load_iris
X, y = load_iris(return_X_y=True)
pipe = Pipeline([
("scaler", StandardScaler()),
("clf", LogisticRegression(max_iter=1000)),
])
scores = cross_val_score(pipe, X, y, cv=5)
print(scores.mean())Pilar 2: Versioning Data & Model
Kode kita versioning pakai Git; data dan model juga perlu perlakuan sama. Kalau minggu depan akurasi turun, pertanyaan pertama: “model mana? dilatih dari data mana? dengan hyperparameter apa?” Tanpa versioning, jawabannya menebak-nebak. Tools umum: DVC untuk versioning dataset besar di atas Git, MLflow untuk melacak eksperimen (parameter, metrik, artefak model). Contoh logging sederhana dengan MLflow:
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import accuracy_score
from sklearn.datasets import load_iris
X, y = load_iris(return_X_y=True)
X_tr, X_te, y_tr, y_te = train_test_split(X, y, random_state=42)
with mlflow.start_run():
mlflow.log_param("n_estimators", 200)
clf = RandomForestClassifier(n_estimators=200, random_state=42)
clf.fit(X_tr, y_tr)
acc = accuracy_score(y_te, clf.predict(X_te))
mlflow.log_metric("accuracy", acc)
mlflow.sklearn.log_model(clf, "model")Pilar 3: Deployment
Cara termurah menyajikan model: bungkus sebagai REST API. FastAPI pilihan populer karena cepat dan validasi skema otomatis via Pydantic:
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class Features(BaseModel):
sepal_length: float
sepal_width: float
petal_length: float
petal_width: float
@app.post("/predict")
def predict(f: Features):
x = [[f.sepal_length, f.sepal_width, f.petal_length, f.petal_width]]
return {"prediction": int(clf.predict(x)[0])}Untuk skala lebih besar ada serving khusus seperti TensorFlow Serving atau TorchServe, plus strategi rilis yang familiar bagi web developer: canary deployment, A/B testing antar versi model, rollback cepat.
Pilar 4: Monitoring
Model tidak rusak mendadak seperti server down — ia membusuk perlahan. Data dunia nyata bergeser (data drift), distribusi input berubah, dan akurasi tergerus diam-diam. Yang dipantau minimal: latensi dan error rate API (seperti service biasa), distribusi fitur input vs waktu training, dan proxy label ground truth kalau tersedia. Ketika drift terdeteksi, picu retraining. Monitoring tanpa aksi retraining hanya pajangan dashboard.
Opsi Deployment: Mana yang Cocok?
Pilihan deployment tergantung skala dan tim. Untuk prototipe atau proyek internal, REST API dengan Flask atau FastAPI sudah cukup — deploy ke VPS biasa, pakai gunicorn di belakang nginx. Untuk produksi yang harus scalable dan konsisten, bungkus model ke dalam Docker container. Docker menjamin lingkungan inference identik dari development sampai production, menghilangkan “works on my machine” syndrome.
Pilihan ketiga: serverless. AWS Lambda atau Google Cloud Functions bisa menjalankan model kecil tanpa mengelola server. Cocok untuk model inferensi ringan dengan traffic tidak stabil. Namun ada batasan: ukuran package, waktu eksekusi maksimal, dan cold start. Untuk model heavy seperti transformer, container di Kubernetes tetap pilihan utama. Pelajaran saya: jangan pakai serverless untuk model yang butuh GPU — cold start dan resource limit membuat latensi tidak bisa diprediksi.
Monitoring Lebih Detail: Drift dan Degradasi
Tiga jenis drift yang harus dipahami. Data drift adalah perubahan distribusi input — misalnya data sensor berubah karena upgrade hardware. Concept drift adalah hubungan antara fitur dan label berubah — pola yang dipelajari model tidak lagi valid. Model degradation adalah penurunan performa secara umum yang bisa disebabkan drift atau kombinasi faktor lain. Deteksi data drift bisa dilakukan statistik sederhana: bandingkan distribusi fitur saat training vs live data pakai Kolmogorov-Smirnov test atau PSI (Population Stability Index). Konsepnya mirip seperti deteksi anomali — baseline dari training data, threshold untuk alert, dan escalation ke retraining pipeline.
Feature Store: Mengapa Penting?
Saya dulu bingung kenapa perusahaan besar butuh feature store. Ternyata masalahnya sederhana: kode feature engineering sering duplikasi antara training dan serving. Satu tim pakai SQL query tertentu untuk menghitung fitur, tim lain pakai versi berbeda. Hasilnya: training-serving skew. Feature store seperti Feast atau Tecton menyediakan satu sumber kebenaran untuk fitur. Hitungan fitur dilakukan sekali, disimpan, dan bisa diakses oleh training pipeline maupun serving endpoint secara konsisten.
Experiment Tracking: MLflow, W&B, Neptune
MLflow open-source dan bisa dijalankan lokal — cocok untuk individu atau tim kecil. Tidak perlu infrastruktur terpisah, langsung log ke direktori lokal atau remote server. Weights & Biases (W&B) menawarkan dashboard visual yang sangat baik, termukterintegrasi dengan framework populer, dan fitur collaboration untuk tim. Neptune lebih ringan, fokus pada metadata logging dengan UI yang clean. Pilihan saya untuk proyek pribadi: MLflow karena gratis dan self-hosted. Untuk tim dengan budget: W&B karena productivity gain-nya signifikan. Semua tiga mendukung logging hyperparameter, metrics, artifacts, dan model registry.
CI/CD untuk Machine Learning
CI/CD ML mirip dengan CI/CD biasa tetapi ada stage tambahan: data validation dan model evaluation. GitHub Actions bisa menjalankan pipeline DVC setiap push, memastikan data dan model versioning sinkron. Contoh workflow: setiap push ke branch main, GitHub Actions menjalankan data validation (Great Expectations), training, evaluasi model, dan jika metrik memenuhi threshold, otomatis push model ke registry. DVC mendukung remote storage (S3, GCS) sehingga artefak besar tidak masuk ke Git repository. Pipeline seperti ini mengubah “deploy model” dari proses manual menjadi repeatable automation.
name: ML Pipeline
on:
push:
branches: [main]
jobs:
train:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install dvc scikit-learn mlflow
- run: dvc pull
- run: python train.py
- run: dvc pushCase Study: Startup Kecil vs Enterprise
Di startup kecil (tim ML 2-3 orang), MLOps yang realistis: MLflow lokal untuk experiment tracking, DVC untuk data versioning, FastAPI + Docker untuk deployment, dan Prometheus + Grafana untuk monitoring sederhana. Tidak perlu Kubernetes atau feature store di tahap ini. Yang penting: setiap model punya jejak (traceability) — tahu data, parameter, dan kapan di-deploy. Di enterprise (tim ML 10+ orang), kompleksitas naik drastis. Feature store menjadi necessity karena banyak tim berbagi fitur. Kubeflow atau SageMaker untuk orchestration pipeline. Model registry sentral. Monitoring termukcanggih dengan alerting ke Slack. Perbedaan kuncinya: startup bisa improvisasi, enterprise butuh governance dan standarisasi.
Tabel Perbandingan Tools MLOps
| Tools | Fungsi | Open Source? | Cocok Untuk |
|---|---|---|---|
| MLflow | Experiment tracking, model registry | Ya | Individu, tim kecil |
| DVC | Data & model versioning | Ya | Semua skala |
| W&B | Experiment tracking, visualisasi | Sebagian | Tim kollaborasi |
| Feast | Feature store | Ya | Enterprise |
| Kubeflow | Pipeline orchestration | Ya | Enterprise (K8s) |
| TorchServe | Model serving (PyTorch) | Ya | Production serving |
| Seldon Core | Model deployment & monitoring | Ya | Enterprise |
Catatan Pribadi: Pengalaman Pertama Deploy Model
Pengalaman pertama saya deploy model ke produksi masih terasa absurd. Saya punya model klasifikasi sederhana, dilatih di Jupyter notebook, akurasi 95%. Tapi saat ditanya “model versi apa yang sedang jalan?” saya tidak bisa menjawab. Tidak ada logging, tidak ada versioning, bahkan tidak ada tracking data yang dipakai untuk training. Saya deploy dengan cara paling primitif: copy file .pkl ke server, jalankan script Python manual. Semua berjalan — sampai model perlu diupdate dan tidak ada yang tahu apakah yang di-deploy sudah versi terbaru. Pengalaman ini membuka mata saya: model tanpa MLOps seperti kapal tanpa navigasi. Berlayar bisa, tapi sampai tujuan atau tidak tergantung keberuntungan.
Checklist MLOps untuk Proyek Kecil
Bagi yang ingin memulai MLOps di proyek pribadi atau startup kecil, berikut checklist minimum yang saya gunakan sekarang:
- Data versioning: pakai DVC atau minimal catat hash/versi dataset secara manual
- Experiment tracking: MLflow lokal, catat setiap training run dengan parameter dan metrik
- Model registry: simpan model terlatih dengan metadata (metrics, sklearn version, Python version)
- Containerisasi: Dockerfile untuk inference service, termukasuk dependencies dan model
- API testing: pastikan endpoint /predict bisa diakses dan return format yang benar
- Monitoring dasar: log latensi, error rate, dan distribusi input (minimal ke file)
- Retraining trigger: tentukan kapan model harus di-retrain (threshold metrik, jadwal, atau drift detection)
- Dokumentasi: catatan data lineage, keputusan desain model, dan batasan model
| Tahap | Masalah tanpa MLOps | Praktik minimum |
|---|---|---|
| Pipeline | Notebook tak reproducible | Pipeline + seed tetap |
| Versioning | Lupa model versi mana | MLflow/DVC |
| Deployment | Model dikirim via email/screenshot | REST API + container |
| Monitoring | Akurasi turun tak terdeteksi | Drift check + alert |
Jujur saja: untuk proyek pribadi saya belum menjalankan semua ini penuh. Tapi sekali model harus dipertanggungjawabkan ke user nyata, MLOps berhenti jadi kata kunci LinkedIn dan mulai jadi kebutuhan. Checklist di atas bukan target sempurna — minimal yang harus ada agar model tidak hilang jejak saat produksi berjalan.
Komentar Terbaru