MLOps

MLOps (Machine Learning Operations) bezeichnet die Betriebs-Disziplin, mit der selbst trainierte Machine-Learning-Modelle (Programme, die aus Daten Muster lernen und daraus Vorhersagen ableiten, z. B. eine Kündigungs-Prognose) über ihren gesamten Lebenszyklus geplant, trainiert, ausgerollt, überwacht und aktuell gehalten werden. Der Begriff überträgt Prinzipien aus DevOps (dem etablierten Betriebsansatz für Software) auf ML und ergänzt sie um sechs Bausteine: Feature Store (Speicher für Modell-Eingangswerte), Trainings-Pipeline (automatisierter Ablauf zum Neu-Berechnen des Modells), Model Registry (versionierter Katalog freigegebener Modelle), Model Serving (Auslieferung des Modells über Schnittstellen) und Drift-Monitoring (Überwachung, ob sich die Realität vom Trainingszustand entfernt).

Was ist MLOps?

MLOps ist die Antwort auf eine wiederkehrende Beobachtung: Ein Modell, das in der Arbeitsumgebung eines Data Scientists (interaktives Notebook, in dem Daten analysiert und Modelle prototypisch trainiert werden) sauber funktioniert, ist nicht dasselbe wie ein Modell im produktiven Betrieb. Produktion verlangt, dass sich jedes Training exakt wiederholen lässt (reproduzierbar), dass jede ausgelieferte Modell-Version eindeutig identifizierbar ist (versioniertes Deployment), dass die Vorhersage-Qualität dauerhaft überwacht wird und dass ein definierter Weg existiert, das Modell bei Bedarf neu zu trainieren. Der [Algorithmia-Report „State of Enterprise ML" 2020](https://info.algorithmia.com/2020-state-of-enterprise-machine-learning) berichtete, dass 55 Prozent der befragten Unternehmen kein einziges ihrer entwickelten ML-Modelle produktiv betrieben. Die Lücke sitzt zwischen erfolgreichem Training und stabilem Betrieb. MLOps schliesst diese Lücke als eigene Disziplin.

Der Aufbau ruht auf sechs Bausteinen. Datenversorgung und Feature Engineering liefern die Modell-Eingaben aus Roh- und Silber-Tabellen; ein Feature Store hält die berechneten Werte für Training und Inferenz mit identischer Semantik vor. Experiment- und Trainings-Management versioniert Trainings-Läufe reproduzierbar (Hyperparameter, Metriken, Artefakte, Daten- und Code-Version); das De-facto-Werkzeug ist [MLflow](https://mlflow.org/). Model Registry führt einen versionierten Katalog freigegebener Modelle mit Stage-Übergängen (Staging, Production, Archived). CI/CD für ML orchestriert automatisierte Trainings-Pipelines, Test-Gates und Deployment. Model Serving liefert das Modell hinter einem Endpoint aus, als Batch-Job, Online-Inferenz per REST oder Streaming-Scoring. Monitoring vergleicht Feature-Verteilungen, Modell-Metriken und Vorhersage-Verteilungen laufend gegen die Trainings-Baseline und alarmiert bei Data Drift, Concept Drift oder Qualitätsverfall.

Der Begriff hat sich zwischen 2018 und 2021 als eigenständige Disziplin etabliert. Googles [„Practitioners Guide to MLOps"](https://cloud.google.com/resources/mlops-whitepaper) und der Blog-Post [„MLOps: Continuous delivery and automation pipelines in machine learning"](https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning) definieren ein Reifegrad-Modell mit drei Stufen (Level 0 bis Level 2), das heute als kanonische Referenz gilt: Level 0 = manueller ML-Prozess, Level 1 = automatisierte Trainings-Pipeline mit Continuous Training, Level 2 = vollständige CI/CD-Automatisierung inklusive Trigger-basiertem Re-Training. Gartner führt MLOps seit 2020 im Hype Cycle for AI als eigene Kategorie, Databricks veröffentlicht mit dem [„Big Book of MLOps"](https://www.databricks.com/resources/ebook/the-big-book-of-mlops) eine Referenz-Architektur auf Basis von MLflow, Unity Catalog Model Registry, Feature Store, Model Serving und Lakehouse Monitoring.

Abgrenzung zu DevOps, LLMOps, AgentOps, Data Engineering und ML Pipelines

Der Begriff wird häufig mit angrenzenden Disziplinen vermischt. Die folgende Tabelle sortiert die fünf häufigsten Verwechslungen.

DevOps ist der Vorläufer: Software wird gebaut, getestet, deployt. MLOps setzt DevOps voraus und erweitert um die ML-spezifischen Artefakte, die Software nicht kennt: Datenversionen, Feature-Definitionen, Modellgewichte, Experiment-Metriken und die Notwendigkeit, ein Modell bei Drift neu zu trainieren, anstatt es unverändert weiter auszuliefern. Ein reiner DevOps-Betrieb behandelt das Modell als Binär-Artefakt, ohne Rücksicht auf Qualitätsalterung.

LLMOps ist der Nachbar auf der GenAI-Seite. Der Trennungsschnitt sitzt am Modell-Eigentum: MLOps betreibt selbst trainierte Modelle mit eigenen Feature-Vektoren, LLMOps steuert fremde grosse Sprachmodelle über Prompts an und misst deren Antwort-Qualität mit Golden-Datasets und LLM-as-a-Judge-Scores. Die Kosten entstehen in MLOps pro Trainings-Lauf und Batch-Job, in LLMOps pro Token. In hybriden KI-Landschaften laufen beide parallel: MLOps für das Churn- und Forecasting-Modell, LLMOps für den RAG-basierten Wissensassistenten. AgentOps liegt eine Ebene darüber und bündelt den Lifecycle autonomer Agenten (Planung, Tool-Nutzung, Memory, Human-in-the-Loop); ein Agent nutzt LLMOps und gegebenenfalls MLOps als Modell-Ebene, hat aber eigene Bausteine für Tool-Registrierung und Agenten-Freigabe.

Data Engineering und DataOps liegen unterhalb von MLOps. Sie sichern, dass die Roh- und Feature-Quellen korrekt, aktuell und dokumentiert sind (Bronze/Silber/Gold-Tabellen, Data Contracts, Lineage). MLOps setzt darauf auf und ist modellagnostisch nach unten: Ein sauber betriebenes Data-Engineering liefert die Daten, MLOps macht daraus Modelle. ML Pipelines sind die technische Ausführungs-Kette innerhalb von MLOps (der DAG aus Feature-Berechnung, Training, Evaluation, Deployment). Der Unterschied liegt in der Reichweite: MLOps umfasst zusätzlich Registry, Serving, Monitoring und Governance, ML Pipelines sind ein Baustein davon.

Beispiel: Churn-Prognose als produktive MLOps-Strecke

Ein Handelsunternehmen betreibt eine Churn-Prognose für Bestandskunden auf einem Databricks-Lakehouse. Die MLOps-Sicht spannt sich über sechs Ebenen.

Ein täglicher Batch-Job berechnet 25 Features pro Kundenkonto aus Silber-Tabellen (Nutzungs-Aggregate über 7, 30, 90 Tage, Ticketvolumen, Zahlungshistorie) und schreibt sie in eine Feature-Tabelle im Unity Catalog Feature Store. Feature-Definitionen liegen als Code mit Owner, Schema und Versionsnummer vor. Ein wöchentlicher Trainings-Run in einer MLflow-Trainings-Pipeline zieht einen historischen Datensatz per Point-in-Time-Join aus dem Feature Store, trainiert einen LightGBM-Klassifikator und schreibt Hyperparameter, Metriken (AUC, Recall bei Top-Decile), Artefakte und die Trainings-Daten-Version in das MLflow-Tracking.

Der beste Kandidat wird nach bestandenem Offline-Check in die Unity Catalog Model Registry geschrieben und im Alias champion@staging gehalten. Ein CI/CD-Job (GitHub Actions oder Databricks Asset Bundles) prüft die neue Version gegen die Vorgänger-Baseline: AUC muss mindestens gleich, die Bias-Prüfung (Gleichverteilung der False-Positive-Rate über Kundengruppen) muss bestehen, die Inferenz-Latenz muss unter einer Schwelle liegen. Nach erfolgreichem Test wird der Alias auf champion@production gesetzt und das alte Modell in archived überführt.

Model Serving läuft als täglicher Batch-Scoring-Job auf Databricks: Der Job lädt die aktuellen Feature-Werte aus dem Feature Store, ruft das Production-Modell aus der Registry auf und schreibt die Scores mit Referenzdatum in eine Gold-Tabelle, die das Marketing-Team für Kampagnen-Ausspielung konsumiert.

Monitoring läuft über Databricks Lakehouse Monitoring. Die Feature-Verteilungen und die Vorhersage-Verteilung werden täglich gegen die Trainings-Baseline verglichen (Population Stability Index, KS-Statistik pro Feature). Fällt eine Kennzahl über eine definierte Schwelle, öffnet der Monitor ein Ticket und triggert einen ausserplanmässigen Trainings-Lauf. Modell-Qualität wird gegen nachgelagerte Ground-Truth-Signale (tatsächliche Kündigungen 90 Tage später) rückgemessen; sinkt die AUC über zwei Wochen unter die Baseline, wird das nächste Re-Training beschleunigt.