Was ist MLOps? Machine Learning Operations

Machine Learning funktioniert im Notebook. Im Labor. Als Proof of Concept. Was selten funktioniert: dasselbe Modell zuverlässig, wartbar und skalierbar im Produktionsbetrieb zu halten. Genau diese Lücke schliesst MLOps.

MLOps steht für Machine Learning Operations und beschreibt die Praktiken, Tools und Prozesse, die nötig sind, um KI-Modelle von der Entwicklung in den Betrieb zu überführen – und dort am Laufen zu halten. Der Begriff ist eine Erweiterung von DevOps (der bewährten Praxis für Software-Deployment) auf die spezifischen Herausforderungen von Machine Learning.

Warum braucht ML eigene Ops? Weil ML-Systeme sich fundamental von klassischer Software unterscheiden: Sie hängen nicht nur vom Code ab, sondern auch von Daten. Und Daten ändern sich. Maschinen verschleissen anders als vor zwei Jahren. Fahrgastzahlen verschieben sich. Prozesse in der Verwaltung werden angepasst. Wenn sich die Daten ändern, aber das Modell gleich bleibt, sinkt die Vorhersagequalität – oft schleichend und unbemerkt. Dieses Phänomen heisst Data Drift und ist der Hauptgrund, warum KI-Projekte nach dem Proof of Concept im Sande verlaufen.

Das Problem: Die Lücke zwischen Prototyp und Produktion

Branchenstudien zeigen: Laut einer Gartner-Erhebung aus 2024 schaffen es im Durchschnitt nur 48% der KI-Projekte vom Prototyp in die Produktion – und selbst die erfolgreichen brauchen dafür acht Monate. Nicht weil die Modelle schlecht sind, sondern weil die Infrastruktur fehlt, sie zuverlässig zu betreiben. Im Detail:

Kein Deployment-Prozess. Ein Data Scientist trainiert ein Modell in einem Jupyter Notebook. Um es produktiv zu machen, muss jemand eine API drumherum bauen, es auf einen Server deployen, Logging einrichten und Monitoring aufsetzen. Oft gibt es niemanden, der das kann oder will.

Keine Reproduzierbarkeit. Welche Daten wurden für das Training verwendet? Welche Hyperparameter? Welche Version der Trainingsskripte? Wenn diese Fragen nicht beantwortet werden können, ist das Modell eine Blackbox – und jedes Retraining ein Glücksspiel.

Kein Monitoring. Das Modell läuft – aber niemand prüft, ob die Vorhersagen noch stimmen. Bei der Schweizerischen Post wäre ein Predictive-Maintenance-Modell wertlos, wenn es den Verschleiss von Sortieranlagen-Komponenten nicht mehr korrekt vorhersagt, weil sich die Betriebsparameter geändert haben.

Keine Governance. Wer hat das Modell trainiert? Wer hat es freigegeben? Auf welchen Daten basiert es? In regulierten Umgebungen – öffentliche Verwaltung, Gesundheit, Finanz – sind diese Fragen nicht optional.

Der MLOps-Lebenszyklus

MLOps strukturiert den gesamten Weg eines ML-Modells in wiederkehrende Phasen:

1. Datenaufbereitung

Alles beginnt bei den Daten. Rohdaten aus ERP, Sensorik, Ticketing oder Dokumenten werden gesammelt, bereinigt und in Features umgewandelt – die Eingabevariablen für das Modell. Dieser Schritt ist oft der aufwändigste: Data Scientists verbringen 60–80% ihrer Zeit mit Datenaufbereitung.

Hier zahlt sich eine bestehende Datenplattform aus. Wenn Daten bereits über Data Pipelines in ein Data Warehouse oder einen Data Lake fliessen, muss das ML-Team nicht bei Null anfangen. Die dbt-Transformationen, die für BI-Dashboards laufen, liefern oft bereits 70% der benötigten Features.

Feature Store. Ein zentraler Speicher für wiederverwendbare Features. Statt dass jeder Data Scientist dieselben Berechnungen erneut implementiert (z.B. «durchschnittliche Vibration der letzten 24 Stunden»), werden Features einmal berechnet und allen Modellen zur Verfügung gestellt. Das spart Zeit und stellt Konsistenz sicher.

2. Modellentwicklung und Experiment-Tracking

Data Scientists trainieren und vergleichen verschiedene Modelle. MLOps erfordert, dass jedes Experiment vollständig dokumentiert wird: verwendete Daten, Hyperparameter, Code-Version, Metriken (Accuracy, Precision, Recall, F1-Score). Tools wie MLflow oder Azure ML registrieren diese Informationen automatisch.

Das ist der Punkt, an dem Supervised und Unsupervised Learning relevant werden: Die Wahl des Algorithmus ist Teil des Experiments. Für die Defekterkennung mittels Computer Vision testet man andere Modellarchitekturen als für die Klassifikation von Servicefällen bei V-ZUG.

3. Validierung und Testing

Bevor ein Modell in Produktion geht, muss es systematisch geprüft werden – nicht nur auf Genauigkeit, sondern auch auf Robustheit, Fairness und Edge Cases. Typische Tests:

Performance-Tests. Erreicht das Modell die definierten Schwellenwerte (z.B. Precision > 95% für Defekterkennung)?

Data-Validation. Stimmen die Eingabedaten mit dem erwarteten Schema überein? Gibt es unerwartete Null-Werte, neue Kategorien, veränderte Verteilungen?

Bias-Tests. Behandelt das Modell verschiedene Gruppen oder Szenarien fair? Besonders relevant in der öffentlichen Verwaltung.

4. Deployment

Das Modell wird als Service bereitgestellt – typischerweise als REST-API, als Batch-Job oder eingebettet in eine bestehende Applikation. MLOps automatisiert diesen Schritt über CI/CD-Pipelines: Wenn ein Modell die Tests besteht, wird es automatisch in die Produktionsumgebung ausgerollt.

Deployment-Strategien: Shadow Mode (das neue Modell läuft parallel zum alten, ohne Entscheidungen zu treffen – zum Vergleich), Canary Release (das neue Modell übernimmt zunächst nur 10% der Anfragen) oder Blue/Green Deployment (sofortiger Wechsel mit Rollback-Option).

5. Monitoring und Alerting

Nach dem Deployment beginnt die eigentliche Arbeit. Das Modell muss überwacht werden auf:

Data Drift. Verändern sich die Eingabedaten? Wenn eine Maschine umgerüstet wird oder ein neuer Schienentyp verlegt wird, verschieben sich die Datenverteilungen – und das Modell verliert an Genauigkeit.

Concept Drift. Verändert sich der Zusammenhang zwischen Eingabe und Ergebnis? Was vor einem Jahr ein Frühindikator für einen Lagerschaden war, ist es nach einer Designänderung vielleicht nicht mehr.

Performance-Metriken. Wie genau sind die Vorhersagen in der echten Welt? Nicht in der Testumgebung, sondern im täglichen Betrieb.

Infrastruktur-Metriken. Antwortzeiten, Fehlerrate, Ressourcenverbrauch. Ein Modell, das 5 Sekunden pro Vorhersage braucht, ist für Echtzeit-Anwendungen unbrauchbar.

6. Retraining

Wenn Drift erkannt oder die Performance unter einen Schwellenwert fällt, wird das Modell mit aktuellen Daten neu trainiert. MLOps automatisiert diesen Kreislauf: Neue Daten fliessen in die Pipeline → Modell wird trainiert → Tests werden durchgeführt → Bei Erfolg wird automatisch deployed.

Die drei Reifegrade von MLOps

Nicht jedes Unternehmen braucht volle Automatisierung. Die Reifegrade helfen bei der Standortbestimmung:

Die meisten Unternehmen, mit denen wir arbeiten, starten bei Stufe 0 und bewegen sich Richtung Stufe 1. Das ist der grösste Hebel: Der Schritt von «es funktioniert auf meinem Laptop» zu «es läuft reproduzierbar in der Pipeline» eliminiert die häufigsten Fehlerquellen.

MLOps in der Praxis: Drei Szenarien

Industrie: Predictive Maintenance skalieren

Ein Unternehmen hat einen erfolgreichen PoC für vorausschauende Wartung: Ein Modell erkennt anhand von Vibrationsdaten bevorstehende Lagerschäden an Fräsmaschinen. Jetzt soll das gleiche Prinzip auf 50 weitere Maschinen – mit unterschiedlichen Sensortypen und Betriebsbedingungen – ausgerollt werden.

Ohne MLOps: 50 individuelle Notebooks, 50 manuelle Deployments, 50 Modelle ohne Monitoring. Wenn eine Maschine umgerüstet wird, merkt niemand, dass das Modell nicht mehr passt.

Mit MLOps: Eine Pipeline, die für jede Maschine automatisch trainiert, testet und deployed. Drift-Detection alarmiert, wenn sich Datenverteilungen ändern. Retraining läuft automatisch. Das Data-Engineering-Fundament dafür liefert die bestehende Datenarchitektur.

Verkehr: Akustikerkennung im Dauerbetrieb

Bei BERNMOBIL setzen wir KI-basierte Akustikerkennung für den Schienenzustand ein. Solche Modelle müssen im Dauerbetrieb funktionieren – bei Regen, Schnee, unterschiedlichen Geschwindigkeiten und Fahrzeugtypen.

MLOps sichert hier die Qualität ab: Monitoring erkennt, wenn sich das akustische Profil verändert (z.B. durch einen neuen Radtyp). Automatisches Retraining stellt sicher, dass das Modell aktuell bleibt. Und das Experiment-Tracking dokumentiert, warum Version 7 des Modells besser funktioniert als Version 5.

Verwaltung: Klassifikationsmodelle pflegen

Öffentliche Verwaltungen setzen zunehmend ML ein – etwa für die automatisierte Klassifikation von Anträgen, die Erkennung von Duplikaten in Registern oder die Priorisierung von Anfragen. Diese Modelle müssen nicht nur genau sein, sondern auch erklärbar und auditierbar.

MLOps liefert genau das: Jedes Modell hat eine dokumentierte Trainingshistorie, definierte Testkriterien und eine Freigabeprozedur. Wenn ein Auditor fragt «Auf welchen Daten basiert diese automatische Entscheidung?», gibt es eine Antwort.

MLOps und Datenplattform: Warum beides zusammengehört

Der häufigste Fehler bei MLOps-Einführungen: Teams versuchen, MLOps aufzubauen, ohne eine solide Dateninfrastruktur zu haben. Das ist, als würde man ein Monitoring-System einrichten, bevor die Maschine überhaupt Daten liefert.

Die Abhängigkeiten sind klar:

Ohne saubere Daten kein gutes Modell. Wenn die Sensordaten voller Lücken sind, die ERP-Exporte inkonsistent und die Dokumente unstrukturiert – dann hilft das beste MLOps-Framework nichts. Erst die Data Pipeline und das Data Warehouse schaffen die Grundlage.

Ohne Feature Store keine Wiederverwendbarkeit. Features, die bereits für BI-Dashboards berechnet werden (z.B. «OEE pro Linie und Schicht»), können oft direkt für ML-Modelle verwendet werden. Das setzt eine saubere Data-Governance-Struktur voraus.

Ohne Monitoring-Infrastruktur kein Drift-Detection. Um Data Drift zu erkennen, müssen die aktuellen Eingabedaten mit den Trainingsdaten verglichen werden – in Echtzeit oder zumindest täglich. Das erfordert eine funktionierende Pipeline, nicht ein manuelles Skript.

Genau deshalb starten wir bei Kunden immer mit der Dateninfrastruktur. Die Datenlandkarte zeigt, welche Daten wo liegen. Die Datenstrategie priorisiert, welche davon für ML relevant sind. Und die Datenplattform – ob Microsoft Fabric, Snowflake oder Azure – schafft die Basis, auf der MLOps aufsetzen kann.

MLOps vs. DevOps: Was ist anders?

Beide teilen Prinzipien wie CI/CD, Versionierung und Automatisierung. Die Unterschiede:

Code + Daten + Modell. In DevOps wird nur Code versioniert und deployed. In MLOps müssen zusätzlich die Trainingsdaten und das Modell-Artefakt versioniert werden. Ein Modell ist nur dann reproduzierbar, wenn alle drei Komponenten dokumentiert sind.

Testen ist komplexer. Software besteht Unit-Tests oder nicht. ML-Modelle haben keine binären Testergebnisse – sie haben eine Accuracy von 94,3% statt 95,1%. Die Entscheidung «Ist das gut genug?» ist kontextabhängig und erfordert Domänenwissen.

Drift gibt es nur bei ML. Software altert nicht (der Code von gestern tut heute dasselbe). ML-Modelle altern, weil sich die Welt um sie herum ändert. Monitoring für Drift ist ein MLOps-spezifisches Konzept.

Wie Sie starten

MLOps muss nicht kompliziert sein. Unser empfohlener Einstieg:

1. Ein bestehendes Modell nehmen. Nicht mit MLOps auf der grünen Wiese beginnen, sondern ein Modell, das bereits im PoC funktioniert, als erstes in eine reproduzierbare Pipeline überführen.

2. Experiment-Tracking einrichten. MLflow ist Open Source, einfach aufzusetzen und sofort nutzbar. Ab jetzt wird jedes Experiment dokumentiert – Daten, Parameter, Metriken, Code-Version.

3. Deployment automatisieren. Statt manuell deployen: Ein Skript oder eine CI/CD-Pipeline, die das Modell als API bereitstellt. Kein Overengineering – ein einfaches Deployment-Skript reicht für den Anfang.

4. Basis-Monitoring einrichten. Mindestens: Input-Daten auf Plausibilität prüfen, Vorhersage-Metriken tracken, Alerting bei Auffälligkeiten. Kann mit wenigen Zeilen Code in bestehende Dashboards integriert werden.

5. Retraining-Zyklus definieren. Monatlich? Quartalsweise? Eventgesteuert? Der richtige Rhythmus hängt vom Use Case ab. Für Predictive Maintenance in der Industrie ist monatlich oft sinnvoll. Für saisonale Prognosen im Verkehr eher quartalsweise.

Wie wir Sie unterstützen

MLOps ist kein isoliertes Thema – es sitzt auf Datenplattformen, verbindet Data Engineering mit AI-Engineering und erfordert ein Verständnis für die Branche, in der das Modell eingesetzt wird.

Wir bringen alle drei Perspektiven zusammen: Dateninfrastruktur, KI-Modellierung und Domänenwissen aus Projekten in Industrie, öffentlichem Verkehr und öffentlicher Verwaltung.

Sie haben ein KI-Modell, das im PoC funktioniert – aber nicht in Produktion? Kontaktieren Sie uns – wir bringen es dorthin.

Weiterführende Glossar-Einträge

• Was ist Generative AI? – GenAI und klassische KI im Vergleich
• Was ist RAG? – Unternehmenswissen mit LLMs verbinden
• Supervised vs. Unsupervised Learning – Grundlagen der Modelltypen
• Was ist eine Data Pipeline? – Daten automatisiert verarbeiten
• dbt + Microsoft Fabric – Data Engineering als ML-Fundament
• Was ist ein Data Warehouse? – Strukturierte Daten für Analysen
• Was ist ein Data Lake? – Rohdatenspeicher für ML-Training
• Data Governance – Datenqualität sicherstellen
• Vom Shopfloor zum Insight – Produktionsdaten analysierbar machen
• Datenlandkarte erstellen – Datenquellen systematisch erfassen

‍