Was unterscheidet MLOps von klassischem DevOps?
Direkte Antwort
DevOps automatisiert Build, Test und Deployment von Code, dessen Verhalten sich bei gleichem Input deterministisch vorhersagen lässt. MLOps erweitert diese Praxis um Datenversionierung, Modelltraining als eigenen reproduzierbaren Pipeline-Schritt und laufendes Monitoring von Modellqualität, weil sich das Verhalten eines ML-Modells über Zeit durch Datendrift verändern kann, ohne dass sich der Code selbst geändert hat.
"Bei klassischer Software bleibt ein einmal getesteter Codepfad zuverlässig — bei einem ML-Modell kann sich dieselbe Codebasis morgen anders verhalten, weil sich die Daten in der realen Welt verändert haben.
Teams, die MLOps als "DevOps mit ein paar zusätzlichen Tools" verstehen, unterschätzen regelmäßig, dass ein Modell auch ohne Code-Änderung schlechter werden kann.
Reproduzierbarkeit über Code hinaus
DevOps-Pipelines versionieren Code und Konfiguration. MLOps-Pipelines müssen zusätzlich Trainingsdaten, Modellparameter und die exakte Trainingsumgebung versionieren, weil dasselbe Modell mit leicht veränderten Daten oder Hyperparametern ein anderes Ergebnis liefert.
Tools wie DVC oder MLflow ergänzen klassische Versionskontrolle um diese Dimension, damit ein Trainingslauf später exakt reproduzierbar bleibt.
Deployment eines Modells statt eines Services
Während ein klassisches Software-Deployment vor allem Verfügbarkeit und Performance überwacht, muss ein Modell-Deployment zusätzlich die fachliche Vorhersagequalität im laufenden Betrieb prüfen.
Ein Modell kann technisch fehlerfrei laufen (schnelle Antwortzeiten, keine Exceptions) und trotzdem fachlich zunehmend falsche Vorhersagen liefern, wenn sich die Verteilung der Eingabedaten gegenüber den Trainingsdaten verschiebt.
Kontinuierliches Monitoring auf Datendrift
MLOps-Pipelines brauchen deshalb Monitoring, das nicht nur technische Metriken (Latenz, Fehlerrate), sondern auch statistische Kennzahlen zur Eingabe- und Vorhersageverteilung überwacht.
Weicht diese Verteilung signifikant von der Trainingsverteilung ab, ist das ein Signal für nötiges Retraining, unabhängig davon, ob technische Fehler auftreten.
Wann passt es — wann nicht?
Passt gut
- ✓Es wird ein ML-Modell trainiert und im laufenden Betrieb aktualisiert
Passt nicht
- ✗Es handelt sich um klassische, regelbasierte Software ohne trainierte Modelle