Glossar
KIDatageneral

MLOps

Auch: MLOps, Machine Learning Operations, ML Ops, LLMOps, ModelOps

Machine Learning Operations: die Verbindung von ML- und DevOps-Praktiken, um Modelle zu industrialisieren, auszurollen, zu überwachen und in der Produktion zuverlässig neu zu trainieren.

Was es ist

MLOps (Machine Learning Operations) bezeichnet die Praktiken, Tools und organisatorischen Disziplinen, mit denen Machine-Learning-Modelle vom Experiment in einen zuverlässigen, wiederholbaren Produktivbetrieb überführt werden. Die Automatisierung und Strenge von DevOps wird dabei auf die spezifischen Herausforderungen von ML angewendet: Data Pipelines, Modelltraining, Versionierung, Deployment und laufendes Monitoring.

Anders als klassische Software hängt ein ML-System nicht nur vom Code, sondern auch von Daten ab. Ein Modell, das im letzten Quartal funktionierte, kann unbemerkt an Qualität verlieren, wenn sich Kundenverhalten, Preise oder Marktbedingungen verschieben. MLOps existiert, um dieses bewegliche Ziel zu beherrschen.

Warum es zählt

Die meisten ML-Projekte erreichen nie die Produktion, und viele, die es tun, scheitern still. MLOps schließt die Lücke zwischen einem vielversprechenden Prototyp und einer verlässlichen Business-Fähigkeit.

  • Zuverlässigkeit: Modelle verhalten sich vorhersehbar und lassen sich zurückrollen.
  • Reproduzierbarkeit: Jedes Ergebnis lässt sich auf bestimmte Daten, Code und Parameter zurückführen.
  • Geschwindigkeit: Neue Versionen gehen in Stunden oder Tagen live, nicht in Monaten.
  • Governance: Audit Trails, Zugriffskontrolle und dokumentierte Lineage unterstützen Compliance.
  • Kostenkontrolle: Automatisiertes Retraining und Monitoring verhindern teure stille Ausfälle.

Wie es in der Praxis eingesetzt wird

Ein ausgereiftes MLOps-Setup deckt typischerweise ab:

  • Data- und Feature-Pipelines: versioniert, validiert und wiederholbar.
  • Experiment Tracking: Erfassen von Parametern, Metriken und Artefakten.
  • Model Registry: ein Katalog freigegebener Modellversionen und ihres Status.
  • CI/CD für Modelle: automatisiertes Testen, Packaging und Deployment.
  • Monitoring: Überwachung von Latenz, Genauigkeit und Data Drift (Inputs, die sich im Laufe der Zeit verändern).
  • Automatisiertes Retraining: ausgelöst nach Zeitplan oder bei erkanntem Drift.

Diese Praktiken gelten gleichermaßen für klassische Vorhersagemodelle und für angewandte LLM-Systeme (wo auch Prompts, Retrieval-Quellen und Evaluationssets versioniert und überwacht werden müssen, teils LLMOps genannt).

Ein konkretes Beispiel

Eine Bank rollt ein Credit-Scoring-Modell aus.

1. Data Scientists trainieren ein Modell; der Run wird mit Datensatzversion und Metriken geloggt.

2. Das Modell besteht automatisierte Fairness- und Genauigkeitstests und geht dann als „staging“ in die Registry.

3. Nach menschlicher Freigabe wird es auf „production“ hochgestuft und über eine API bereitgestellt.

4. Das Monitoring meldet, dass sich die Einkommensverteilung der Antragsteller verschoben hat (Drift) und die Zusagequoten steigen.

5. Eine automatisierte Pipeline trainiert auf frischen Daten neu, die neue Version wird getestet und ersetzt die alte mit vollständiger Audit-Historie.

Ohne MLOps bliebe Schritt 4 möglicherweise unbemerkt, bis Verluste oder eine Aufsichtsbehörde das Problem sichtbar machen.

The MLOps lifecycle Data and features Train and track Registry and deploy Serve in production Monitor and detect drift Retrain (automated)
MLOps as a closed loop: data and training feed deployment, while monitoring and drift detection trigger automated retraining.

Häufige Fragen

Was ist MLOps in einfachen Worten?

MLOps (Machine Learning Operations) bezeichnet die Praktiken, Tools und organisatorischen Disziplinen, die Machine-Learning-Modelle vom Experiment in einen zuverlässigen Produktivbetrieb bringen. Die Automatisierung und Strenge von DevOps wird auf ML-spezifische Probleme angewendet: Data Pipelines, Modelltraining, Versionierung, Deployment und laufendes Monitoring. Der zentrale Unterschied zu klassischer Software: Ein ML-System hängt nicht nur vom Code, sondern auch von Daten ab. Ein Modell, das im letzten Quartal funktionierte, kann still an Qualität verlieren, wenn sich Verhalten oder Marktbedingungen verschieben.

Was ist der Unterschied zwischen MLOps und DevOps?

DevOps industrialisiert Code; MLOps industrialisiert Code plus Daten plus Modelle. Eine klassische Anwendung verhält sich gleich, solange niemand den Code ändert, während ein ML-Modell ohne jede Codeänderung an Genauigkeit verlieren kann, weil sich die eingehenden Daten verschoben haben. Deshalb ergänzt MLOps das übliche CI/CD um Data- und Feature-Pipelines, Experiment Tracking, eine Model Registry, Drift-Monitoring und automatisiertes Retraining.

Was ist Data Drift und warum erzwingt er Retraining?

Data Drift bedeutet, dass sich die Inputs, die ein Modell in der Produktion erhält, im Laufe der Zeit gegenüber den Trainingsdaten verändern. Da das Modell Zusammenhänge aus der alten Verteilung gelernt hat, werden seine Vorhersagen zunehmend unzuverlässiger, oft ohne sichtbaren Fehler. Das Monitoring auf Drift löst das Retraining aus, entweder nach Zeitplan oder automatisch bei erkannter Verschiebung.

Was umfasst ein ausgereiftes MLOps-Setup konkret?

Sechs Bausteine: versionierte und validierte Data- und Feature-Pipelines, Experiment Tracking (Parameter, Metriken, Artefakte), eine Model Registry mit freigegebenen Versionen und ihrem Status, CI/CD für automatisiertes Testen und Deployment von Modellen, Monitoring von Latenz, Genauigkeit und Data Drift sowie automatisiertes Retraining, ausgelöst nach Zeitplan oder bei Drift. Zusammen liefern sie Zuverlässigkeit, Reproduzierbarkeit, schnellere Releases, Audit Trails für die Governance und Schutz vor teuren stillen Ausfällen.

Gelten MLOps-Praktiken auch für LLM-Projekte, oder ist das etwas anderes?

Sie gelten, und die Variante wird teils LLMOps genannt. Dieselbe Disziplin gilt für angewandte LLM-Systeme, nur müssen neben dem Modell selbst auch Prompts, Retrieval-Quellen und Evaluationssets versioniert und überwacht werden. Die zugrunde liegende Logik bleibt: jedes Ergebnis auf bestimmte Inputs zurückführen, vor der Freigabe testen und nach dem Deployment überwachen.