Der Moment, in dem ein Data Scientist sagt “das Modell funktioniert”, ist nicht das Ende eines Projekts. Es ist der Anfang. Und hier beginnt das, was die meisten Organisationen unterschätzen.

Die Notebook-Illusion

In einem Jupyter Notebook sieht alles sauber aus. Daten laden, Features berechnen, Modell trainieren, Accuracy messen. Fertig. Aber dieses Notebook ist kein Produktionssystem. Es ist ein Prototyp.

Zwischen “funktioniert im Notebook” und “funktioniert in Produktion” liegen Welten:

  • Woher kommen die Daten in Echtzeit?
  • Wie wird das Modell versioniert?
  • Was passiert, wenn die Eingabedaten sich ändern (Data Drift)?
  • Wie erkennst du, dass die Vorhersagequalität sinkt?
  • Wie rollst du ein neues Modell aus, ohne den Dienst zu unterbrechen?

Das sind keine theoretischen Fragen. Das sind die Fragen, die Projekte scheitern lassen.

MLOps ist DevOps für ML

MLOps überträgt die Prinzipien von DevOps auf Machine Learning. Automatisierung. Reproduzierbarkeit. Monitoring. CI/CD. Aber mit einer zusätzlichen Dimension: Daten.

In klassischem DevOps ist der Code die einzige Variable. In MLOps hast du drei: Code, Daten und Modell. Jede Kombination muss versioniert, getestet und nachvollziehbar sein.

Das bedeutet:

  • Feature Stores statt Copy-Paste von SQL-Queries
  • Model Registry statt “das Modell liegt auf Andres Laptop”
  • Automated Retraining Pipelines statt manueller Nachtrainings alle paar Monate
  • Model Monitoring für Drift Detection, nicht nur System-Monitoring

Was ich in der Praxis sehe

Die häufigsten Probleme in ML-Projekten sind keine ML-Probleme. Sie sind Engineering-Probleme.

Das Team hat ein fantastisches Modell, aber keinen Weg, es zu deployen. Die Daten-Pipeline bricht jeden Montag, weil ein Upstream-System sein Format geändert hat. Das Modell wird einmal trainiert und dann nie wieder angefasst, obwohl sich die Datenverteilung längst verschoben hat.

Die Lösung ist nicht besseres ML. Die Lösung ist besseres Engineering.

Der pragmatische Einstieg

MLOps muss nicht mit einer Plattform wie Kubeflow oder MLflow starten. Es kann mit drei simplen Maßnahmen beginnen:

  1. Versioniere alles. Code, Daten, Modell-Artefakte, Hyperparameter. Git für Code, DVC oder ähnliches für Daten.
  2. Automatisiere das Training. Ein Skript, das ohne manuellen Eingriff ein Modell trainiert und evaluiert. Kein Notebook, ein Skript.
  3. Messe die Modellqualität in Produktion. Nicht nur beim Training. Prediction-Monitoring, Input-Drift-Detection, regelmäßiger Vergleich mit Ground Truth.

Das klingt unspektakulär. Aber die meisten ML-Projekte, die in Produktion scheitern, scheitern an genau diesen Grundlagen. Nicht an der Modellarchitektur.

ML ist Wissenschaft. MLOps ist Engineering. Beides braucht Können. Aber nur zusammen entsteht Wirkung.