Belajar MLOps - Model Retraining & Automation

#Pendahuluan

Setelah di episode 12 kalian bisa mendeteksi drift, muncul pertanyaan berikutnya: lalu apa? Model yang drift tidak bisa dibiarkan — tetapi model yang di-retrain setiap hari juga boros biaya GPU. Kuncinya adalah memicu retraining pada waktu yang tepat, dengan cara yang terotomasi dan terkontrol.

Mengapa retraining automation adalah puncak kematangan MLOps? Karena inilah yang disebut zero-touch pipeline — tren dominan 2026: data baru masuk → model baru dilatih → dievaluasi → dipromosikan — semua tanpa manusia yang mengklik tombol. Episode ini membahas kapan memicu retraining, bagaimana loop umpan balik bekerja, dan bagaimana melakukannya tanpa menembak kaki sendiri.

#Tiga Strategi Trigger Retraining

#1. Berbasis Jadwal (Scheduled)

Retraining dijalankan berkala — mingguan, bulanan — tanpa melihat kondisi model. Paling sederhana, cocok jika data berubah pada ritme yang stabil.

0 2 * * 1 cd /opt/churn && dvc pull && python -m churn.train

#2. Berbasis Threshold (Performance/Drift)

Retraining dipicu peristiwa: drift score melewati ambang, atau akurasi live turun di bawah target. Hemat biaya — model hanya dilatih saat dibutuhkan.

from evidently.report import Report
from evidently.metric_preset import DataDriftPreset
 
def should_retrain(prod_df, threshold: float = 0.3) -> bool:
    report = Report(metrics=[DataDriftPreset()])
    report.run(reference_data=train_df, current_data=prod_df)
    drift = report.as_dict()["data_drift"]["share_of_drifted_columns"]
    return drift > threshold

#3. Berbasis Event (Data Baru)

Retraining dipicu oleh kedatangan data baru — file diletakkan di bucket, event dipublish ke Kafka, atau tabel produksi diperbarui. Paling cepat merespons perubahan, dan paling sulit dikendalikan biayanya.

File baru di S3 → Event (S3 notification) → Trigger pipeline retraining

Praktik terbaik: kombinasi. Contoh pola umum:

• Jadwal bulanan sebagai baseline.
• Drift threshold sebagai pengaman tambahan.
• Data baru signifikan (misal dataset bertambah 20%) sebagai trigger manual.

#Feedback Loops: Sumber Label

Retraining yang baik membutuhkan label baru — dan label sering tidak tersedia otomatis. Dua mekanisme utama:

• Natural labels — label muncul sebagai konsekuensi alami: transaksi berhasil/gagal, tagihan lunas/tunggak, click-through. Dapat diambil dari sistem produksi secara otomatis.
• Human-in-the-loop — manusia melabeli sample, sering lewat UI review. Lebih mahal, tapi kualitas label lebih tinggi.

def collect_training_data(window_days: int = 90):
    """Gabungkan prediksi lama dengan label yang sudah terkonfirmasi."""
    predictions = load_predictions_from_db()
    outcomes = load_outcomes_from_db()
    df = predictions.merge(outcomes, on="customer_id")
    return df[df["outcome_known_at"] >= today - timedelta(days=window_days)]

Dengan loop ini, dataset training "segar" mengalir otomatis ke pipeline — tanpa manusia mengekspor CSV. Ini adalah jantung dari self-improving system.

#Zero-Touch Pipeline: Alur Lengkap

Inilah arsitektur level 2 yang kita singgung di episode 2:

Setiap langkah terotomasi, tetapi gate evaluasi tetap menjadi penjaga. Model baru hanya dipromosikan jika mengalahkan atau menyamai champion (model produksi saat ini). Inilah bedanya zero-touch dengan "retraining buta".

Implementasi gatenya:

import mlflow
 
def evaluate_vs_champion(candidate_run_id: str, threshold_improve: float = 0.005):
    client = mlflow.tracking.MlflowClient()
    candidate = client.get_run(candidate_run_id).data.metrics["accuracy"]
    champion_version = client.get_model_version_by_alias("churn-predictor", "champion")
    champion = client.get_run(champion_version.run_id).data.metrics["accuracy"]
 
    if candidate >= champion + threshold_improve:
        client.set_registered_model_alias("churn-predictor", "champion", candidate_run_id)
        return "PROMOTED"
    return "KEPT_CHAMPION"

Model baru wajib mengalahkan champion dengan margin tertentu sebelum menggantikannya. Margin (0.005) mencegah pergantian sia-sia akibat fluktuasi acak.

#Menangani Risiko Auto-Retraining

Automasi penuh menimbulkan risiko yang harus dikelola:

Salah satu pola paling penting adalah cooldown: jangan biarkan retraining otomatis berjalan lebih dari batas tertentu per periode, dan beri jeda setelah promosi. Model yang di-retrain minggu ini tidak perlu di-retrain lagi besok hanya karena drift kecil.

#Praktik Baik Retraining

• Mulai dari jadwal, naikkan bertahap — jangan langsung full zero-touch pada model pertama.
• Champion-challenger selalu — simpan champion di registry; challenger diuji melawannya.
• Shadow deploy — jalankan model baru di samping produksi (tanpa melayani traffic) untuk mengukur kualitas.
• Semua tercatat — trigger, data, keputusan promosi di-log untuk audit (episode 15).
• Rollback siap — jika model baru lebih buruk setelah promosi, alias kembali ke versi sebelumnya.

#Common Pitfalls

• Retraining tanpa evaluasi vs champion → kualitas menurun diam-diam dari siklus ke siklus.
• Trigger hanya drift tanpa cooldown → model berubah-ubah dan biaya membengkak.
• Label kotor dari produksi → retraining menguatkan bias; validasi label.
• Tanpa monitoring setelah auto-promote → regresi baru terdeteksi berminggu-minggu kemudian.
• Gate yang terlalu ketat → model bagus tidak pernah naik; margin yang terlalu longgar → noise menggantikan model bagus.

#Penutup

Pada episode 13 ini, kalian telah mengotomasi pembaruan model.

Inti yang harus dibawa pulang:

• Trigger retraining: jadwal, threshold drift, dan event data baru — kombinasikan.
• Feedback loop: natural labels dari produksi + human-in-the-loop untuk label berkualitas.
• Zero-touch pipeline berjalan hanya jika gate vs champion lolos.
• Kelola risiko: cooldown, validasi data, budget, shadow deploy, dan rollback siap.
• Semua keputusan auto-retraining tercatat untuk audit.

Di episode 14 selanjutnya kita akan membahas feature store in production — online vs offline store, point-in-time correctness, dan Feast sebagai implementasi, untuk menghilangkan training-serving skew. Sampai jumpa di episode 14!