Belajar MLOps - Model Registry & Versioning

#Pendahuluan

Setelah di episode 10 kalian memilih pola deployment, sekarang kita bereskan masalah yang lebih mendasar: di mana model hidup dan bagaimana perjalanannya. Di organisasi tanpa registry, model "produksi" tinggal di folder laptop seseorang — dan ketika harus rollback, tidak ada yang tahu model mana yang sebelumnya dipakai.

Mengapa model registry adalah tulang punggung MLOps? Karena model adalah artefak yang berubah dan punya siklus hidup: lahir dari eksperimen, dipromosikan ke staging, disetujui ke produksi, lalu diarsipkan saat pensiun. Registry adalah single source of truth untuk seluruh perjalanan itu — dengan versi, stage, dan lineage yang tercatat.

#Konsep MLflow Model Registry

MLflow Model Registry adalah direktori terpusat untuk model terdaftar. Dua entitas kunci:

• Registered Model — entitas model dengan nama unik (misal churn-predictor).
• Model Version — setiap versi model di dalam registered model; bersifat immutable.

Setiap versi melewati stage:

Versioning model bersifat immutable: versi tidak bisa diubah isinya setelah dibuat. Kalian tidak "mengedit" model — kalian membuat versi baru. Inilah yang membuat rollback menjadi operasi yang aman dan dapat dilacak.

#Daftarkan Model dari Kode

Setelah training (episode 5) dan setelah CI meloloskan (episode 8), daftarkan model:

import mlflow
from mlflow.tracking import MlflowClient
 
client = MlflowClient()
 
result = client.create_registered_model("churn-predictor")
version = client.create_model_version(
    name="churn-predictor",
    source="runs:/abc123/model",
    description="RF v2, feature set F12, data churn v1.4",
)
print(f"Model version: {version.version}")

Perhatikan deskripsi: ia mencatat konteks — fitur yang dipakai, versi data. Inilah benih lineage yang akan kita lengkapi nanti.

#Alur Promosi Staging → Production

Promosi model adalah keputusan yang sebaiknya tidak dilakukan sembarangan. Alur yang sehat:

1. CI meloloskan model → didaftarkan, stage None.
2. Tim memindahkan ke Staging untuk pengujian (shadow traffic, A/B).
3. Evaluasi staging lolos → promosi ke Production.
4. Model lama di-Archive.

client.transition_model_version_stage(
    name="churn-predictor",
    version=3,
    stage="Staging",
    archive_existing_versions=False,
)
 
client.transition_model_version_stage(
    name="churn-predictor",
    version=3,
    stage="Production",
    archive_existing_versions=True,
)

Parameter archive_existing_versions=True secara otomatis mengarsipkan versi yang sebelumnya Production — pola yang mencegah dua model "production" sekaligus.

#Promosi via Alias (Rekomendasi Modern)

MLflow modern menyarankan alias daripada stage untuk deployment: alias (seperti champion, candidate) memberi semantik yang lebih fleksibel dan bisa dipindahkan tanpa transisi stage:

client.set_registered_model_alias("churn-predictor", "champion", version=3)

Serving kemudian mengambil model "yang sekarang champion" — tanpa tahu nomor versinya. Ini memisahkan nama deployment dari nomor versi, sehingga rollback cukup memindahkan alias.

#Versioning Semantic untuk Model

Model juga bisa diberi semantic version seperti software: MAJOR.MINOR.PATCH.

• MAJOR — perubahan fitur/schema input yang tidak kompatibel ke belakang.
• MINOR — penambahan fitur/model baru yang kompatibel.
• PATCH — retrain dengan data yang sama, hasil perbaikan kecil.

Konsistensi versioning memudahkan komunikasi: "kita pakai churn-predictor 2.3.0" langsung memberi informasi bahwa schema sama dengan 2.x, berbeda dari 1.x.

#Lineage: Menghubungkan Model → Data → Kode

Registry yang baik menjawab pertanyaan audit: "model produksi ini dilatih dari apa?". Lineage menghubungkan tiga komponen:

Rangkai di dalam training:

import mlflow
import subprocess
 
commit = subprocess.check_output(["git", "rev-parse", "HEAD"]).decode().strip()
data_hash = subprocess.check_output(["dvc", "data", "status"]).decode().strip()
 
with mlflow.start_run() as run:
    mlflow.log_param("git_commit", commit)
    mlflow.log_param("data_version", data_hash)
    # ... training ...
    mlflow.sklearn.log_model(model, artifact_path="model")
 
client.set_registered_model_alias("churn-predictor", "champion", run.info.run_id)

Sekarang, untuk setiap model di produksi, kalian bisa menjawab: dibangun dari kode commit apa, di atas data hash apa, oleh run eksperimen mana. Ini prasyarat untuk governance & audit di episode 15.

#Best Practice Registry

• Semua model produksi harus terdaftar — tidak ada model "di luar registry".
• Versi immutable — buat versi baru untuk perubahan; jangan menimpa.
• Promosi terotomasi — CI (episode 8) mendaftarkan, pipeline (episode 7) mempromosikan.
• Deskripsi selalu diisi — model tanpa deskripsi = misteri 6 bulan kemudian.
• Alias untuk deployment — champion/candidate memisahkan logika serving dari nomor versi.

#Common Pitfalls

• Model tidak pernah di-archive → registry dipenuhi versi mati; archive dengan sengaja.
• Promosi manual tanpa jejak → tidak tahu siapa/kapan/waktu promosi; otomasikan dan log.
• Dua versi Production sekaligus → tidak jelas mana yang melayani; gunakan archive_existing_versions.
• Lineage terputus → kode/data tidak tercatat; sertakan commit & data hash di setiap run.
• Deskripsi kosong → audit gagal; konteks model wajib ditulis.

#Penutup

Pada episode 11 ini, kalian telah mengelola siklus hidup model secara terpusat.

Inti yang harus dibawa pulang:

• Registry adalah single source of truth: registered model + version immutable.
• Alur hidup model: None → Staging → Production → Archived.
• Alias (champion) memisahkan nama deployment dari nomor versi — rollback jadi mudah.
• Lineage = git commit + data hash + run ID + registry version.
• Promosi yang terotomasi dan terdokumentasi adalah kunci governance.

Di episode 12 selanjutnya kita akan membahas monitoring & drift detection — data drift, concept drift, metrik model di produksi, dan tools Evidently/WhyLabs/Prometheus untuk menangkap model yang mulai rusak secara diam-diam. Sampai jumpa di episode 12!