Belajar MLOps - Monitoring & Drift Detection

#Pendahuluan

Setelah di episode 11 model kalian terdaftar rapi di registry, tibalah kebenaran yang sering ditolak dunia ML: model yang bagus hari ini bisa rusak bulan depan — tanpa error apa pun. Tidak ada crash, tidak ada 5xx, tidak ada log merah. Prediksi hanya semakin salah secara diam-diam karena dunia berubah.

Mengapa monitoring model adalah pembeda antara MLOps dan sekadar "deploy ML"? Karena deployment adalah titik awal, bukan akhir. Episode ini mengajarkan kalian mendeteksi model yang mulai rusak: apa itu drift, bagaimana mengukurnya, dan tools apa yang dipakai — sebelum kerusakan itu dirasakan pengguna.

#Tiga Jenis Drift

Ada tiga bentuk pergeseran yang wajib kalian kenali:

#Data Drift

Distribusi input berubah. Contoh: model dilatih saat mayoritas pelanggan berusia 25-40 tahun, tetapi dua tahun kemudian basis pelanggan didominasi usia 50+. Input model bergeser dari pola yang pernah dilihatnya.

#Concept Drift

Hubungan input → target berubah. Contoh: perilaku pelanggan yang berlangganan bulanan berubah drastis karena pesaing baru — pola yang dulu menandakan loyalitas sekarang menandakan churn. Input sama, tetapi artinya berbeda.

#Prediction Drift

Distribusi output prediksi berubah. Bisa menjadi indikasi awal data drift atau concept drift. Contoh: persentase pelanggan yang diprediksi churn melonjak dari 12% ke 30% tanpa perubahan bisnis yang jelas.

#Metrik yang Dipantau

Monitoring model punya tiga lapisan:

Masalah khas ML: label sering datang terlambat. Saat prediksi churn dibuat, kalian tidak tahu jawabannya sampai 3 bulan kemudian. Karena itu drift detection menjadi pengganti "akurasi" untuk deteksi dini — dan saat label tiba, performa dihitung untuk konfirmasi.

#Deteksi Drift dengan Evidently

Evidently adalah open source library Python yang paling populer untuk monitoring ML. Ia menghitung drift per kolom dan menghasilkan laporan.

from evidently.report import Report
from evidently.metric_preset import DataDriftPreset, RegressionPreset
 
report = Report(metrics=[DataDriftPreset(), RegressionPreset()])
report.run(
    reference_data=train_df,  # baseline distribusi training
    current_data=prod_df,     # data produksi terbaru
)
report.save_html("reports/drift_report.html")

Hasilnya: drift score untuk tiap fitur (menggunakan PSI, Kolmogorov-Smirnov, atau metode lain). Fitur dengan skor di atas threshold (misal 0.3 untuk PSI) menandakan data drift.

Untuk deteksi otomatis dan alerting, Evidently punya Evidently AI (SaaS) — atau kalian integrasikan Evidently ke pipeline sendiri: jadwalkan perhitungan drift tiap hari, dan kirim alert jika drift melampaui ambang.

#Alerting: Menghubungkan ke On-Call

Drift tidak berguna jika hanya tercatat di dashboard. Hubungkan ke alerting yang benar:

import requests
 
def check_and_alert(drift_score: float, threshold: float = 0.3):
    if drift_score > threshold:
        requests.post(
            "https://hooks.slack.com/services/XXXX",
            json={"text": f"⚠️ Data drift {drift_score:.2f} pada fitur tenure!"},
        )

Atau untuk metrik infrastruktur, gunakan Prometheus: expose metrik model (latency, error, drift) sebagai /metrics, lalu atur alert rule:

groups:
  - name: ml-model
    rules:
      - alert: HighPredictionDrift
        expr: churn_churn_probability_avg > 0.30
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "Distribusi prediksi churn melonjak tinggi"

Ini mengikuti pola monitoring standar DevOps: metrics → dashboard → alert → on-call, dengan tambahan metrik ML.

#WhyLabs dan Tools Komersial

WhyLabs (berbasis library open source whylogs) menyediakan monitoring model terkelola dengan profil data otomatis, alerting, dan dashboard — alternatif SaaS jika tim tidak ingin membangun sendiri. Pola penggunaannya: kirim profil data per batch, WhyLabs mendeteksi anomali dan mengirim alert.

Perbandingan singkat:

#Threshold Drift: Menentukan Ambang

Ambang drift bukan angka universal — ia harus dikalibrasi ke dampak bisnis:

• Fitur paling penting bagi model → threshold lebih ketat (0.1-0.2).
• Fitur pendukung yang jarang berpengaruh → threshold longgar.
• Mulai dari nilai default tool, lalu sesuaikan berdasarkan pengalaman dan historis drift.

Alur yang sehat: (1) pantau 2-4 minggu tanpa alert, (2) ukur variasi normal, (3) baru tetapkan threshold di atas variasi normal itu. Threshold yang terlalu ketat menciptakan alert fatigue — yang berbahaya karena membuat orang berhenti memedulikan alert.

#Common Pitfalls

• Monitoring hanya infrastruktur → latency hijau padahal model rusak; drift wajib dipantau.
• Drift tanpa konteks bisnis → alert diabaikan karena terlalu sering; kalibrasi threshold.
• Menunggu label untuk "memantau" → deteksi dini hilang; drift adalah proksi sebelum label tiba.
• Alert tanpa pemilik → tidak ada yang merespons; tetapkan on-call dan runbook.
• Baseline salah → drift dihitung terhadap data yang salah; gunakan data training yang valid sebagai referensi.

#Penutup

Pada episode 12 ini, kalian telah menangkap model yang rusak secara diam-diam.

Inti yang harus dibawa pulang:

• Tiga drift: data drift (input berubah), concept drift (hubungan berubah), prediction drift (output berubah).
• Monitoring tiga lapis: infra, performa, dan data/drift.
• Evidently untuk deteksi drift; Prometheus untuk metrik real-time dan alert.
• Threshold harus dikalibrasi ke bisnis, bukan angka default.
• Drift adalah sinyal untuk manusia memutuskan — jembatan menuju retraining.

Di episode 13 selanjutnya kita akan membahas model retraining & automation — kapan dan bagaimana model diperbarui, feedback loops, dan zero-touch pipeline yang menggantikan intervensi manual dengan trigger otomatis. Sampai jumpa di episode 13!