MLOps di 2026: MLflow, Model Registry, dan Pertanyaan Wawancara Teknis

Pertanyaan wawancara MLOps telah bergeser dari spesialisasi khusus menjadi bagian inti dari perekrutan data science dan machine learning engineering pada 2026. Tim tidak lagi hanya menanyakan bagaimana sebuah model dilatih; mereka menyelidiki bagaimana model itu dilacak, diversikan, di-deploy, dan dipantau setelah trafik nyata menjangkaunya. Panduan ini membahas pertanyaan-pertanyaan yang kerap berulang dalam wawancara MLOps, dikelompokkan berdasarkan tahap siklus hidup, dengan contoh MLflow yang mencerminkan pengaturan produksi.

Pertanyaan Wawancara MLOps tentang Siklus Hidup Machine Learning

Q1: Apa itu MLOps dan bagaimana perbedaannya dengan DevOps?

MLOps menerapkan prinsip-prinsip DevOps seperti otomatisasi, CI/CD, dan pemantauan pada sistem machine learning, lalu menambahkan tiga hal yang tidak dimiliki perangkat lunak tradisional: versioning data, versioning model, dan validasi berkelanjutan terhadap distribusi data langsung. Dalam DevOps klasik, kode adalah satu-satunya artefak yang berubah. Dalam MLOps, kode, data, dan model terlatih masing-masing diversikan secara independen, dan salah satu dari ketiganya dapat menurunkan kualitas keluaran secara diam-diam tanpa satu baris kode pun berubah. Makalah Hidden Technical Debt in Machine Learning Systems yang sering dikutip menegaskan bahwa kode model hanyalah sebagian kecil dari sistem ML nyata, dengan pipeline data, pemantauan, dan konfigurasi yang mendominasi cakupannya.

Q2: Jelaskan tahap-tahap dalam siklus hidup ML produksi.

Jawaban yang kuat menyebut lima tahap beserta artefak yang dihasilkan masing-masing: ingesti dan validasi data (dataset yang diversikan), eksperimentasi (run terlacak dengan metrik), registrasi model (model yang diversikan dan dapat dipromosikan), deployment (endpoint penyajian atau job batch), dan pemantauan (telemetri drift dan performa yang mengumpan balik ke pelatihan ulang). Pewawancara menyimak keberadaan feedback loop: pemantauan harus terhubung kembali ke eksperimentasi, sebab jika tidak, sistem menjadi pipeline satu arah yang membusuk seiring waktu.

Pelacakan Eksperimen dengan Contoh Tutorial MLflow

Pelacakan eksperimen adalah fondasi yang menjadi dasar sebagian besar pertanyaan MLOps, sehingga jawaban tutorial MLflow yang menunjukkan logging nyata memiliki bobot. MLflow mencatat parameter, metrik, dan artefak per run, yang membuat setiap hasil dapat direproduksi dari run ID-nya.

Q3: Bagaimana pelacakan MLflow menangkap sebuah eksperimen, dan mengapa run ID penting?

Setiap pemanggilan mlflow.start_run() membuka sebuah run yang mencatat hyperparameter, metrik, dan model terserialisasi. Run ID adalah pegangan yang tidak dapat diubah yang mengikat sebuah metrik kembali ke kode, parameter, dan snapshot data persis yang menghasilkannya, dan inilah yang membuat sebuah eksperimen dapat direproduksi berbulan-bulan kemudian.

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

Argumen name menggantikan artifact_path yang usang pada MLflow 3.x, sebuah perubahan yang layak disebutkan untuk menunjukkan kesadaran akan API terkini. Kandidat yang merujuk pelacakan fitur dan dataset melalui pola validasi pipeline ML cenderung memperoleh nilai lebih tinggi, karena reprodusibilitas bergantung pada keseluruhan pipeline, bukan hanya model.

Model Registry 2026: Versioning dan Promosi

MLflow Model Registry mengubah artefak run menjadi objek yang tata kelolanya terkendali dan dapat dipromosikan. Pergeseran terbesar baru-baru ini, dan probe wawancara 2026 yang sering muncul, adalah beralihnya dari stage bernama.

Q4: Bagaimana MLflow Model Registry mempromosikan sebuah model, dan apa yang berubah pada 2026?

Versi MLflow sebelumnya mempromosikan model melalui stage tetap bernama Staging, Production, dan Archived. MLflow 3.x menghentikan penggunaan stage tersebut demi alias dan tag, karena daftar stage yang dikodekan secara kaku tidak dapat mengekspresikan topologi deployment nyata seperti champion, challenger, atau shadow. Sebuah alias adalah penunjuk yang dapat berubah menuju satu versi, sehingga promosi menjadi penetapan ulang alias alih-alih memodifikasi model.

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

Karena konsumen memuat models:/churn-classifier@champion, sebuah rollback hanyalah satu penetapan ulang alias ke versi sebelumnya, tanpa deploy ulang. Dokumentasi resmi MLflow Model Registry membahas tata kelola alias dan pemicu webhook secara mendalam.

Pola Deployment dan Penyajian Machine Learning

Pertanyaan deployment memisahkan kandidat yang telah merilis model dari mereka yang hanya melatihnya. Pemilihan pola mengikuti anggaran latensi, bukan preferensi pribadi.

Q5: Bandingkan deployment machine learning batch, online, dan streaming.

| Pola | Latensi | Kasus penggunaan umum | Permukaan penyajian | |---------|---------|------------------|-----------------| | Batch | Jam hingga harian | Skoring churn, penyegaran rekomendasi | Job terjadwal yang menulis ke tabel | | Online (real-time) | Puluhan milidetik | Pemeriksaan penipuan, pemeringkatan saat permintaan | Endpoint REST atau gRPC | | Streaming | Subdetik, kontinu | Deteksi anomali pada aliran event | Consumer pada message queue |

Pertanyaan lanjutannya hampir selalu menanyakan cara menyajikan kasus online. Sebuah model MLflow mengemas lingkungannya sendiri, sehingga menyajikannya cukup dengan satu perintah terhadap URI registry.

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6: Bagaimana deployment blue-green dan canary mengurangi risiko dalam rollout model?

Blue-green mempertahankan dua lingkungan yang identik dan mengalihkan seluruh trafik sekaligus setelah model baru lolos pemeriksaan, sehingga memberikan jalur rollback instan. Canary mengarahkan sebagian kecil trafik ke versi baru, mengamati metrik langsung, lalu menaikkannya secara bertahap. Untuk model, canary biasanya lebih aman karena masalah kualitas model hanya muncul terhadap input nyata, dan canary membatasi radius dampak ke sebagian kecil pengguna.

Pengujian dan CI/CD untuk Pipeline Machine Learning

Q7: Apa yang diuji CI/CD dalam pipeline ML yang tidak diuji oleh pipeline perangkat lunak standar?

Pipeline CI perangkat lunak menjalankan pengujian unit dan integrasi pada kode. Pipeline ML menambahkan pengujian data dan model di atasnya: validasi skema pada data masuk, pemeriksaan distribusi agar sebuah run pelatihan tidak diam-diam menyerap fitur yang rusak, dan gate kualitas model yang menggagalkan build ketika kandidat memperoleh skor di bawah champion saat ini pada holdout set tetap. Continuous delivery untuk ML karenanya mempromosikan sebuah artefak model, bukan sekadar image kontainer, dan gate promosinya adalah ambang metrik alih-alih hanya rangkaian pengujian yang hijau. Pipeline yang ketat juga menyematkan snapshot data dan versi dependensi sehingga setiap jalankan ulang bersifat deterministik, dan inilah yang membedakan build yang dapat direproduksi dari build yang kebetulan lolos hari ini.

Pemantauan, Data Drift, dan Pelatihan Ulang Model

Sebuah model yang di-deploy menurun seiring dunia bergeser di bawahnya, sehingga pertanyaan pemantauan adalah tempat sinyal senioritas muncul.

Q8: Bagaimana data drift dideteksi, dan metrik apa yang mengukurnya?

Data drift berarti distribusi input produksi telah bergeser menjauh dari distribusi pelatihan. Population Stability Index (PSI) adalah ukuran yang umum dan tidak bergantung pada framework: ia membagi distribusi referensi ke dalam bin, membandingkan frekuensi produksi terhadap bin tersebut, lalu menjumlahkan selisih log berbobot.

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

Di luar metrik buatan sendiri, tim produksi mengandalkan perkakas seperti Evidently untuk melacak drift fitur, drift target, dan kualitas data secara terjadwal. Jawaban yang lengkap membedakan data drift (input bergeser) dari concept drift (hubungan input-ke-output bergeser), karena yang kedua tidak dapat ditangkap hanya dengan mengamati input dan memerlukan hasil berlabel.

Q9: Apa yang seharusnya memicu pipeline pelatihan ulang?

Pelatihan ulang berbasis waktu pada irama tetap adalah opsi paling sederhana, tetapi memboroskan komputasi ketika tidak ada yang berubah dan bereaksi lambat ketika sesuatu rusak. Pemicu yang lebih baik bersifat berbasis metrik: latih ulang ketika PSI melewati ambang, ketika metrik evaluasi langsung turun di bawah batas bawah, atau ketika backtest terjadwal pada data yang baru dilabeli mengalami regresi. Job pelatihan ulang kemudian meregistrasikan sebuah challenger, yang dibandingkan oleh rollout canary terhadap champion saat ini sebelum alias mana pun ditetapkan ulang.

Pertanyaan Wawancara System Design MLOps

Q10: Rancang sebuah platform yang menyajikan ratusan model dengan fitur yang konsisten.

Pusat perhatian yang diharapkan adalah feature store, yang menyelesaikan training-serving skew dengan menghitung fitur satu kali dan menyajikan nilai yang identik ke pelatihan maupun inferensi. Perkakas seperti Feast menyediakan offline store untuk pelatihan dan online store berlatensi rendah untuk penyajian. Desain yang lengkap juga menyebut model registry untuk versioning, tracking server untuk lineage, orkestrator untuk pipeline, dan lapisan pemantauan yang menutup loop kembali ke pelatihan ulang. Mendasarkan jawaban pada pekerjaan fitur nyata, seperti tradeoff yang dibahas dalam panduan wawancara feature engineering ini, menandakan pengalaman langsung alih-alih sekadar mengingat diagram.

Kesimpulan

• Bingkai MLOps sebagai DevOps ditambah versioning data dan model: reprodusibilitas, keamanan promosi, dan pemantauan adalah tiga sumbu yang dinilai pewawancara
• Pahami pergeseran API MLflow 3.x: alias dan tag menggantikan stage Staging dan Production yang usang, dan log_model kini menerima name alih-alih artifact_path
• Cocokkan pola deployment dengan anggaran latensi, dan pilih canary daripada blue-green untuk rollout model karena masalah kualitas hanya muncul terhadap input langsung
• Kuantifikasi drift dengan metrik konkret seperti PSI, dan bedakan data drift dari concept drift, karena hanya satu yang terlihat tanpa label
• Picu pelatihan ulang berdasarkan metrik alih-alih kalender, dan arahkan challenger yang dihasilkan melalui canary sebelum menetapkan ulang alias champion
• Sebut feature store dalam setiap jawaban system design untuk menutup celah training-serving skew sebelum diangkat sebagai pertanyaan lanjutan