MLOps 2026: MLflow, Model Registry und technische Interviewfragen

MLOps-Interviewfragen haben sich 2026 von einer Nischenspezialisierung zu einem zentralen Bestandteil der Einstellungsverfahren im Bereich Data Science und Machine-Learning-Engineering entwickelt. Teams fragen längst nicht mehr nur, wie ein Modell trainiert wird; sie prüfen, wie es getrackt, versioniert, deployt und überwacht wird, sobald echter Traffic darauf trifft. Dieser Leitfaden arbeitet die Fragen durch, die in MLOps-Interviews immer wieder auftauchen, gruppiert nach Phase im Lebenszyklus und mit MLflow-Beispielen, die produktive Setups widerspiegeln.

MLOps-Interviewfragen zum Machine-Learning-Lebenszyklus

Q1: Was ist MLOps und worin unterscheidet es sich von DevOps?

MLOps überträgt DevOps-Prinzipien wie Automatisierung, CI/CD und Monitoring auf Machine-Learning-Systeme und ergänzt sie um drei Aspekte, die klassische Software nicht kennt: Datenversionierung, Modellversionierung und kontinuierliche Validierung gegen live auftretende Datenverteilungen. Im klassischen DevOps ist Code das einzige Artefakt, das sich ändert. In MLOps versionieren sich Code, Daten und das trainierte Modell jeweils unabhängig voneinander, und jedes der drei kann die Ausgabequalität stillschweigend verschlechtern, ohne dass sich eine einzige Zeile Code ändert. Das oft zitierte Paper Hidden Technical Debt in Machine Learning Systems macht deutlich, dass der Modellcode nur einen kleinen Bruchteil eines realen ML-Systems ausmacht, während Datenpipelines, Monitoring und Konfiguration den Großteil der Oberfläche bestimmen.

Q2: Die Phasen eines produktiven ML-Lebenszyklus durchgehen.

Eine starke Antwort benennt fünf Phasen und das Artefakt, das jede von ihnen erzeugt: Datenaufnahme und -validierung (ein versionierter Datensatz), Experimentieren (getrackte Runs mit Metriken), Modellregistrierung (ein versioniertes, beförderbares Modell), Deployment (ein Serving-Endpunkt oder Batch-Job) und Monitoring (Drift- und Performance-Telemetrie, die in das Retraining zurückfließt). Interviewer achten auf die Rückkopplungsschleife: Das Monitoring muss auf das Experimentieren zurückwirken, sonst ist das System eine Einbahn-Pipeline, die mit der Zeit verrottet.

Experiment-Tracking mit einem MLflow-Tutorial-Beispiel

Experiment-Tracking ist das Fundament, auf dem die meisten MLOps-Fragen aufbauen, deshalb hat eine MLflow-Tutorial-Antwort, die echtes Logging zeigt, Gewicht. MLflow zeichnet Parameter, Metriken und Artefakte pro Run auf, was jedes Ergebnis über seine Run-ID reproduzierbar macht.

Q3: Wie erfasst MLflow-Tracking ein Experiment, und warum ist die Run-ID entscheidend?

Jeder Aufruf von mlflow.start_run() öffnet einen Run, der Hyperparameter, Metriken und das serialisierte Modell protokolliert. Die Run-ID ist der unveränderliche Bezeichner, der eine Metrik an genau den Code, die Parameter und den Datenstand zurückbindet, aus denen sie entstanden ist – und genau das macht ein Experiment noch Monate später reproduzierbar.

# 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

Das Argument name ersetzt das veraltete artifact_path in MLflow 3.x – eine Änderung, die zu erwähnen sich lohnt, um Vertrautheit mit der aktuellen API zu zeigen. Kandidaten, die Feature- und Datensatz-Tracking über Validierungsmuster für ML-Pipelines ansprechen, schneiden in der Regel besser ab, weil Reproduzierbarkeit von der gesamten Pipeline abhängt, nicht nur vom Modell.

Model Registry 2026: Versionierung und Beförderung

Die MLflow Model Registry verwandelt ein Run-Artefakt in ein verwaltetes, beförderbares Objekt. Die größte jüngste Veränderung – und ein häufiger Prüfpunkt in Interviews 2026 – ist die Abkehr von benannten Stages.

Q4: Wie befördert die MLflow Model Registry ein Modell, und was hat sich 2026 geändert?

Frühere MLflow-Versionen beförderten Modelle über feste Stages namens Staging, Production und Archived. MLflow 3.x verwirft diese Stages zugunsten von Aliassen und Tags, weil eine fest verdrahtete Stage-Liste reale Deployment-Topologien wie Champion, Challenger oder Shadow nicht abbilden konnte. Ein Alias ist ein veränderbarer Zeiger auf genau eine Version, sodass Beförderung zum Neuzuweisen des Alias wird, statt das Modell zu verändern.

# 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")

Da Konsumenten models:/churn-classifier@champion laden, ist ein Rollback eine einzige Alias-Neuzuweisung auf eine frühere Version – ohne erneutes Deployment. Die offizielle Dokumentation der MLflow Model Registry behandelt Alias-Governance und Webhook-Trigger im Detail.

Machine-Learning-Deployment-Muster und Serving

Deployment-Fragen trennen Kandidaten, die Modelle ausgeliefert haben, von jenen, die sie nur trainiert haben. Die Wahl des Musters folgt dem Latenzbudget, nicht der persönlichen Vorliebe.

Q5: Batch-, Online- und Streaming-Deployment für Machine Learning vergleichen.

| Muster | Latenz | Typischer Anwendungsfall | Serving-Oberfläche | |---------|---------|------------------|-----------------| | Batch | Stunden bis täglich | Churn-Scoring, Aktualisierung von Empfehlungen | Geplanter Job, der in eine Tabelle schreibt | | Online (Echtzeit) | Zehner-Millisekunden | Betrugsprüfungen, Ranking zur Anfragezeit | REST- oder gRPC-Endpunkt | | Streaming | Sub-Sekunde, kontinuierlich | Anomalie-Erkennung in Event-Strömen | Consumer an einer Message Queue |

Die Anschlussfrage lautet fast immer, wie der Online-Fall ausgeliefert wird. Ein MLflow-Modell verpackt seine eigene Umgebung, sodass das Serving ein einziger Befehl gegen eine Registry-URI ist.

# 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: Wie senken Blue-Green- und Canary-Deployments das Risiko eines Modell-Rollouts?

Blue-Green hält zwei identische Umgebungen vor und schaltet den gesamten Traffic auf einmal um, nachdem das neue Modell die Prüfungen bestanden hat – das ergibt einen sofortigen Rollback-Pfad. Canary leitet einen kleinen Prozentsatz des Traffics auf die neue Version, beobachtet Live-Metriken und steigert dann schrittweise. Für Modelle ist Canary meist sicherer, weil Qualitätsprobleme eines Modells erst gegen echte Eingaben sichtbar werden und ein Canary den Wirkungsbereich auf einen Bruchteil der Nutzer begrenzt.

Testing und CI/CD für Machine-Learning-Pipelines

Q7: Was testet CI/CD in einer ML-Pipeline, das eine gewöhnliche Software-Pipeline nicht testet?

Eine Software-CI-Pipeline führt Unit- und Integrationstests am Code aus. Eine ML-Pipeline ergänzt darüber hinaus Daten- und Modelltests: Schema-Validierung eingehender Daten, Verteilungsprüfungen, damit ein Trainingslauf nicht stillschweigend korrupte Features aufnimmt, und ein Modell-Qualitäts-Gate, das den Build scheitern lässt, wenn ein Kandidat auf einem festen Holdout-Set unter dem aktuellen Champion abschneidet. Continuous Delivery für ML befördert deshalb ein Modell-Artefakt, nicht nur ein Container-Image, und das Beförderungs-Gate ist ein Metrik-Schwellenwert und nicht allein eine grüne Testsuite. Eine rigorose Pipeline fixiert zudem Daten-Snapshots und Abhängigkeitsversionen, sodass jeder erneute Lauf deterministisch ist – und genau das unterscheidet einen reproduzierbaren Build von einem, der heute zufällig durchläuft.

Monitoring, Data Drift und Modell-Retraining

Ein deploytes Modell verschlechtert sich, während sich die Welt darunter verschiebt, deshalb zeigt sich bei Monitoring-Fragen das Senior-Signal.

Q8: Wie wird Data Drift erkannt, und welche Metrik quantifiziert ihn?

Data Drift bedeutet, dass sich die Verteilung der Produktionseingaben von der Trainingsverteilung entfernt hat. Der Population Stability Index (PSI) ist ein verbreitetes, framework-unabhängiges Maß: Er teilt eine Referenzverteilung in Bins ein, vergleicht die Produktionshäufigkeiten mit diesen Bins und summiert die gewichteten logarithmischen Differenzen.

# 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)

Über eine selbstgebaute Metrik hinaus greifen produktive Teams zu Tooling wie Evidently, um Feature-Drift, Target-Drift und Datenqualität nach Zeitplan zu verfolgen. Eine vollständige Antwort unterscheidet Data Drift (die Eingaben verschieben sich) von Concept Drift (die Beziehung zwischen Eingabe und Ausgabe verschiebt sich), weil Letzterer nicht durch das Beobachten der Eingaben allein erfasst werden kann und gelabelte Ergebnisse erfordert.

Q9: Was sollte eine Retraining-Pipeline auslösen?

Zeitbasiertes Retraining in festem Takt ist die einfachste Option, verschwendet aber Rechenleistung, wenn sich nichts geändert hat, und reagiert langsam, wenn etwas bricht. Bessere Auslöser sind metrikbasiert: Retraining, wenn der PSI einen Schwellenwert überschreitet, wenn eine Live-Evaluationsmetrik unter eine Untergrenze fällt oder wenn ein geplanter Backtest auf frisch gelabelten Daten sich verschlechtert. Der Retraining-Job registriert dann einen Challenger, den ein Canary-Rollout gegen den aktuellen Champion vergleicht, bevor irgendein Alias neu zugewiesen wird.

MLOps-Interviewfragen zum System Design

Q10: Eine Plattform entwerfen, die Hunderte Modelle mit konsistenten Features ausliefert.

Das erwartete Herzstück ist ein Feature Store, der Training-Serving-Skew löst, indem er Features einmal berechnet und Training wie Inferenz dieselben Werte liefert. Werkzeuge wie Feast bieten einen Offline-Store für das Training und einen Online-Store mit geringer Latenz für das Serving. Ein vollständiger Entwurf benennt außerdem eine Model Registry für die Versionierung, einen Tracking-Server für die Lineage, einen Orchestrator für Pipelines und eine Monitoring-Schicht, die den Kreis zurück zum Retraining schließt. Die Antwort an echter Feature-Arbeit zu verankern – etwa an den Trade-offs, die dieser Leitfaden zu Feature-Engineering-Interviewfragen behandelt – signalisiert praktische Erfahrung statt bloßem Auswendiglernen von Diagrammen.

Fazit

• MLOps als DevOps plus Daten- und Modellversionierung begreifen: Reproduzierbarkeit, Beförderungssicherheit und Monitoring sind die drei Achsen, die Interviewer bewerten
• Den API-Wandel in MLflow 3.x kennen: Aliasse und Tags ersetzen die veralteten Stages Staging und Production, und log_model nimmt nun name statt artifact_path
• Das Deployment-Muster am Latenzbudget ausrichten und bei Modell-Rollouts Canary gegenüber Blue-Green vorziehen, weil Qualitätsprobleme erst gegen Live-Eingaben auftreten
• Drift mit einer konkreten Metrik wie PSI quantifizieren und Data Drift von Concept Drift unterscheiden, da nur einer ohne Labels sichtbar ist
• Retraining anhand von Metriken statt nach dem Kalender auslösen und den daraus entstehenden Challenger durch einen Canary leiten, bevor der Champion-Alias neu zugewiesen wird
• In jeder System-Design-Antwort einen Feature Store nennen, um die Lücke des Training-Serving-Skews zu schließen, bevor sie als Anschlussfrage aufkommt