Belajar ML Engineer - Model Monitoring & Drift

#Pendahuluan

Setelah di episode 10 model kalian dideploy lewat pipeline CI/CD, ada satu kenyataan yang sering mengejutkan: model yang bagus saat diluncurkan akan menurun secara perlahan. Ini bukan teori — ini kepastian statistik. Dunia berubah: perilaku pengguna berubah, musim berganti, produk baru dirilis, dan semua perubahan itu menggeser pola data yang dipelajari model.

Banyak organisasi merasakan modelnya "menjadi bodoh" beberapa bulan setelah deploy, tanpa bisa menjelaskan kapan mulai dan kenapa. Itu tanda monitoring yang tidak ada. Episode ini membangun sistem monitoring yang mendeteksi masalah sebelum dampaknya terasa di bisnis — bukan setelah pengguna mengeluh.

#Jenis Drift yang Harus Dipahami

Ada tiga cara data bisa "menyimpang" dari kondisi training:

#1. Data Drift (Covariate Shift)

Distribusi input berubah. Contoh: model dilatih saat mayoritas pengguna dari desktop; dua bulan kemudian 60% trafik dari mobile. Fitur seperti screen_width, session_length, click_pattern bergeser — model melihat input yang belum pernah dilihatnya.

#2. Concept Drift

Hubungan input → target berubah. Contoh: model memprediksi churn dari pola aktivitas. Sejak kompetitor rilis fitur baru, pola yang sama tidak lagi menandakan churn — konsep "churn" berubah. Distribusi input bisa tetap sama, tapi maknanya berubah.

#3. Data Quality Issues

Data rusak secara struktural: kolom kosong mendadak, nilai di luar rentang, duplikasi berlipat. Ini bukan drift murni, tapi penyebab performa turun paling umum di lapangan.

#Memantau Distribusi Feature (Data Drift)

Cara paling umum: bandingkan distribusi feature di produksi dengan distribusi reference (training set atau window terakhir yang sehat).

import numpy as np
 
 
def psi(reference: np.ndarray, current: np.ndarray, bins: int = 10) -> float:
    ref_hist, _ = np.histogram(reference, bins=bins, density=False)
    cur_hist, _ = np.histogram(current, bins=bins, density=False)
    ref_pct = ref_hist / ref_hist.sum() + 1e-8
    cur_pct = cur_hist / cur_hist.sum() + 1e-8
    return float(np.sum((cur_pct - ref_pct) * np.log(cur_pct / ref_pct)))
 
 
# interpretasi umum: < 0.1 stabil, 0.1-0.25 peringatan, > 0.25 drift signifikan
print(psi(reference_features, live_features))

Deteksi drift hanyalah alat; keputusan tetap di tangan engineer: feature mana yang harus diwasapdai, dan drift sebesar apa yang benar-benar berarti bagi bisnis.

#Memantau Model dan Bisnis

Karena ground truth sering terlambat (label churn baru terlihat 30 hari kemudian), monitoring butuh tiga lapisan:

Yang sering terlupakan: metrik bisnis. Model bisa tetap "akurat" di metrik internal tapi bisnisnya turun karena model dipakai dengan cara yang tidak terduga. Lag (keterlambatan label) bisa diatasi dengan proxy ground truth: metrik bisnis yang terlihat cepat (konversi dalam 1 jam) sebagai sinyal awal.

#Alerting: Memberitahu Sebelum Terlambat

Alerting yang baik punya tiga sifat: relevan (memicu aksi), jarang (tidak membuat mati rasa), dan kontekstual (memberi petunjuk penyebab).

def check_and_alert(feature_name: str, psi_value: float) -> None:
    if psi_value > 0.25:
        send_alert(
            severity="high",
            message=f"Data drift {feature_name}: PSI={psi_value:.2f}",
            details=f"Referensi: training window 2026-01..2026-06",
        )

Hindari alert yang "selalu bunyi" — alarm fatigue membuat alert diabaikan, dan alarm yang diabaikan lebih berbahaya daripada tidak ada alarm sama sekali. Set threshold berbasis data historis, bukan tebakan.

#Loop Retraining: Menanggapi Drift

Saat drift terdeteksi, bukan otomatis retrain — tetapi keputusan harus terstruktur:

Jangan retrain membabi buta — model baru harus melewati gerbang yang sama seperti model pertama (episode 10). Retraining yang tidak dievaluasi bisa menurunkan kualitas daripada menjaganya.

#Tooling Monitoring

Pilihan tooling untuk dipakai sesuai kebutuhan:

• Prometheus + Grafana: metrik infrastruktur dan model (latensi, error, QPS) — standar de facto.
• Evidently AI: pustaka open source khusus deteksi drift data/model dengan laporan visual.
• WhyLabs / Arize / Fiddler: platform observability ML komersial dengan drift, bias, dan root cause analysis.
• MLflow model monitoring (lebih terbatas).

Mulai sederhana: metrik dasar via Prometheus/Grafana + deteksi drift dengan Evidently. Naik ke platform penuh saat skala menuntut.

#Common Pitfalls

#Penutup

Pada episode 11 ini, kalian telah membangun sistem monitoring:

• Kenali data drift vs concept drift vs data quality — dan bedakan deteksinya.
• Pantau empat lapisan: infrastruktur, data, model, dan bisnis.
• Set alerting yang relevan, jarang, dan kontekstual.
• Tanggapi drift dengan loop retraining terstruktur yang melewati gerbang evaluasi.
• Pilih tooling sesuai skala: Prometheus/Grafana + Evidently untuk mulai.

Di episode 12 selanjutnya kita memasuki dunia deep learning: Deep Learning dengan PyTorch — autograd, Dataset/Dataloader, training loop manual, dan pemanfaatan GPU untuk melatih CNN maupun model tabular secara profesional. Sampai jumpa di episode 12!