MLOps: Wie Daten, Modelle und Governance in der Produktion zusammenkommen

Viele Teams beginnen MLOps-Gespräche mit dem Modell: wie es trainiert wurde, wo es bereitgestellt wird und wie schnell es neu trainiert werden kann. In der Produktion ist das Modell jedoch nur ein Objekt in einem viel größeren System – da gibt es die Tabelle, die es gespeist hat, die Feature-Definition, die es geformt hat, das Label, das drei Tage zu spät kam, das Schema, das sich vorgelagert geändert hat, und die Zugriffsrichtlinie, die bestimmt, wer die Ausgabe nutzen darf.

Aus diesem Grund lässt sich MLOps nicht einfach auf „DevOps für Modelle“ reduzieren. MLOps übernimmt Automatisierung, CI/CD und Release-Disziplin von DevOps, muss aber auch modellspezifische Probleme berücksichtigen, mit denen Softwareteams normalerweise nicht konfrontiert sind: Data Drift, Concept Drift, Feature-Wiederverwendung, Training-Serving Skew, Modell-Erklärbarkeit, Modell-Lineage und Retraining basierend auf neuen Produktionsergebnissen. MLOps verbindet diese Abhängigkeiten, sodass Modelle in Anwendungen integriert werden können, die auch dann zuverlässig bleiben, wenn sich das Geschäft, die Daten und die Betriebsumgebung ändern.

MLOps ist die Reihe von Praktiken, die das Deployment, die Überwachung und die Wartung von ML-Modellen in der Produktion automatisiert und standardisiert. Diese Praktiken helfen Teams dabei, den gesamten Lebenszyklus für maschinelles Lernen (Machine Learning) zu verwalten.

Wie sein Software-Pendant ist auch ein Modell von Code abhängig. Es hängt jedoch auch von Trainingsdaten, Features, Labels, Parametern, Bewertungsmetriken, Laufzeitabhängigkeiten, Serving-Infrastruktur und dem Feedback aus der Umgebung ab, in der die Vorhersagen verwendet werden. MLOps bietet Teams eine Möglichkeit, diese Assets zu versionieren, zu testen, durch Freigabeprozesse zu leiten, konsistent bereitzustellen und zu überwachen, ob sie sich weiterhin wie erwartet verhalten.

Ein Modell, das Leads bewertet, die Nachfrage prognostiziert, Support-Tickets weiterleitet oder verdächtige Transaktionen markiert, ist nicht nur ein Data-Science-Asset. Es ist Teil eines operativen Workflows geworden, bei dem Business-Teams auf dessen Ausgabe angewiesen sind und technische Teams dafür verantwortlich sind, es verfügbar, aktuell und erklärbar zu halten.

Mit starken MLOps-Prozessen können Teams diese Verantwortung in großem Maßstab besser bewältigen. „MLOps wird oft als Tooling-Herausforderung beschrieben, aber in der Praxis sind fragmentierte Workflows das größere Hindernis”, erklärt Trace Smith, Senior AI/ML Architect, Applied Field Engineering bei Snowflake. „Der Trend geht heute in Richtung einer einheitlicheren Daten- und ML-Umgebung, in der Governance und Modell-Workflows in einem Betriebsmodell zusammengeführt werden. Das hilft dabei, operative Reibungsverluste zu reduzieren und den Weg in die Produktion zu beschleunigen.“

Anstatt jedes Modell als einmaliges Projekt zu behandeln, können Teams wiederholbare Pipelines, Überwachung, Versionierung und Governance-Kontrollen nutzen, um Modelle schneller in die Produktion zu überführen, zu erkennen, wenn sich die Performance ändert, und Updates durchzuführen, ohne den operativen Prozess von Grund auf neu aufbauen zu müssen.

MLOps unterstützt Teams auf drei praktische Arten:

• Schnellere Time-to-Market: Automatisierte Pipelines helfen Teams dabei, von manuellen Übergaben zu wiederholbarem Training, Testing, Paketierung und Deployment überzugehen.
• Verbesserte Zuverlässigkeit: Monitoring hilft Teams dabei, Performance-Änderungen, Drift, Datenqualitätsprobleme und Laufzeitfehler zu erkennen, bevor sie sich unbemerkt auf nachgelagerte Entscheidungen auswirken.
• Stärkere Skalierbarkeit und Governance: Versionierung, Lineage, Genehmigungs-Workflows und Zugriffskontrollen helfen Unternehmen dabei, mehr Modelle über mehrere Teams hinweg zu betreiben, ohne sich auf informelle Abstimmungen verlassen zu müssen.

DevOps konzentriert sich auf die Softwarebereitstellung. MLOps erstreckt sich auf die Daten und das statistische Verhalten von ML-Systemen.

Der MLOps-Prozess funktioniert eher als Schleife denn als lineare Übergabe. Teams erfassen und validieren Daten, bereiten Features vor, trainieren und evaluieren Modelle, registrieren und deployen genehmigte Versionen und speisen dann Produktionssignale in die nächste Runde von Monitoring und Retraining ein.

Datenerfassung und Ingestion

Der Lebenszyklus beginnt mit Daten aus Quellsystemen wie Datenbanken, Dateien, Streams, APIs, Anwendungen und Drittanbieter-Datasets. Für produktives ML umfasst die Ingestion mehr als nur das Verschieben von Daten in eine Trainingsumgebung. Sie bewahrt genügend Kontext, um zu verstehen, woher die Daten stammen, wie aktuell sie sind und ob sie für den vorgesehenen Zweck verwendet werden können.

Datenvalidierung und Qualitätsprüfungen

Bevor Daten für das Training oder die Inferenz verwendet werden, müssen sie auf fehlende Werte, Schemaänderungen, Ausreißer, doppelte Datensätze, Bias, Datenschutzprobleme und Aktualität geprüft werden. Diese Prüfungen helfen zu verhindern, dass fehlerhafte Eingaben zum Modellverhalten werden. Beispielsweise können eine Spalte, die sich von Integer zu String ändert, ein Feed, der nicht mehr aktualisiert wird, oder ein Label, das später als erwartet verfügbar ist, die Modellqualität beeinträchtigen, lange bevor jemand einen sichtbaren Produktionsausfall bemerkt.

Datenvorbereitung und Feature Engineering

Feature Engineering verwandelt Rohdaten in modellfertige Signale, indem Daten bereinigt, transformiert, verknüpft, gelabelt und angereichert werden. In ausgereiften MLOps-Umgebungen definieren Teams häufig verwendete Features einmal und verwenden sie dann konsistent für Training und Inferenz wieder. Dies verringert das Risiko, dass ein Team „aktive Kund:innen“ oder „aktuelles Transaktionsvolumen“ anders berechnet als ein anderes Team, oder dass ein Produktionsmodell eine Feature-Logik verwendet, die nicht mehr mit der während des Trainings verwendeten Version übereinstimmt.

Modellentwicklung

Data Scientists und ML Engineers trainieren Modelle mithilfe von Notebooks, Skripten, automatisiertem maschinellem Lernen (AutoML) oder ML-Frameworks. Sie vergleichen Algorithmen, Parameter, Trainingsfenster und Datasets, um den Ansatz zu finden, der am besten zum Vorhersageproblem passt. Die wichtigste MLOps-Anforderung an die Modellentwicklung besteht darin, dass beim Experimentieren genügend Metadaten generiert werden, damit eine andere Person, eine Pipeline oder ein Genehmigungs-Workflow nachvollziehen kann, was trainiert wurde, welche Daten verwendet wurden und wie das Modell abgeschnitten hat.

Experiment-Tracking

Experiment-Tracking erfasst Modellversionen, Datasets, Code, Parameter, Metriken, Artefakte und Ergebnisse. Ohne dieses Tracking wissen Teams vielleicht, dass ein Durchlauf besser abgeschnitten hat als ein anderer, aber nicht warum. Damit können sie jedoch Kandidaten vergleichen, ein Ergebnis reproduzieren und erklären, welche Modellversion in die Produktion überführt wurde.

Modellvalidierung und -evaluierung

Die Modellevaluierung testet, ob ein trainiertes Modell genau, zuverlässig und für den Geschäftsprozess geeignet ist, den es unterstützen soll. Die Evaluierung umfasst das Tracking technischer Metriken wie Genauigkeit, Präzision, Recall, F1, AUC, RMSE und Latenz sowie Fairness, Robustheit und Geschäfts-KPIs. Der Evaluierungsprozess sollte auch testen, ob sich das Modell für wichtige Segmente, Regionen, Produktlinien oder Risikokategorien akzeptabel verhält – und nicht nur, ob es im Durchschnitt gut abschneidet.

Modellpaketierung und Modellregistrierung

Sobald ein Modell die Evaluierung besteht, paketieren Teams es mit Abhängigkeiten und Metadaten und speichern es dann in einer Modell-Registry. Die Registry dient als kontrollierter Ort zur Verwaltung von Versionen, Genehmigungsstatus, Lineage, Deployment-Status und operativen Metadaten.

Modellbereitstellung (Deployment)

Das Modell-Deployment überführt das Modell als Batch-Job, Echtzeit-API, Streaming-Inferenz-Pipeline, eingebettetes Anwendungs-Feature oder Edge-Deployment in die Produktion. Das Serving-Muster hängt von Latenz, Kosten, Aktualität und geschäftlichen Anforderungen ab. Beispielsweise benötigt ein Betrugsmodell möglicherweise Echtzeit-Inferenz, während ein monatliches Propensity-Modell als Batch-Scoring-Job ausgeführt werden kann, der Vorhersagen zur weiteren Verwendung in eine Tabelle zurückschreibt.

Model Serving

Nach dem Deployment muss das Modell so bereitgestellt werden, dass es den Anforderungen der Anwendung an Latenz, Skalierung, Kosten und Aktualität entspricht. Model Serving ist die Laufzeitschicht, die Vorhersagen über Batch-Scoring, Echtzeit-APIs, Streaming-Inferenz, eingebettete Anwendungslogik oder Edge-Umgebungen verfügbar macht. Diese Schicht muss die Eingabevorbereitung, den Feature-Abruf, Laufzeitabhängigkeiten, Skalierung, Zugriffskontrollen, Latenz und Fehlerbehandlung verwalten, damit die genehmigte Modellversion zuverlässig in der Produktion eingesetzt werden kann.

Modellüberwachung

Die Modellüberwachung verfolgt, ob sich ein Modell nach dem Deployment weiterhin wie erwartet verhält. Teams überwachen in der Regel die Produktions-Performance, Latenz, Fehler, Data Drift, Concept Drift, Modellqualität, Kosten und den operativen Zustand.

Feedback und Retraining

Produktionsvorhersagen generieren neue Informationen: Labels, Benutzeraktionen, Geschäftsergebnisse, menschliches Feedback und Drift-Signale. MLOps führt diese Informationen in den Lebenszyklus zurück, sodass Teams Modelle neu trainieren, revalidieren und erneut bereitstellen können, wenn die aktuelle Version nicht mehr gut genug abschneidet. Der Auslöser für das Retraining kann zeitgesteuert, ereignisgesteuert oder an Monitoring-Schwellenwerte gebunden sein, abhängig vom Risiko und der Volatilität des Anwendungsfalls.

Governance und Compliance

Governance erstreckt sich über den gesamten ML-Lebenszyklus. Teams müssen Zugriff, Audit-Trails, Erklärbarkeit, Lineage, Datenschutz, Sicherheit, Genehmigungen und regulatorische Anforderungen von den Rohdaten bis zur Produktionsinferenz verwalten. Dies ist besonders wichtig, wenn Modelle Entscheidungen in den Bereichen Kreditvergabe, Preisgestaltung, Gesundheitswesen, Beschäftigung, Betrugserkennung, Sicherheit oder andere Entscheidungen mit weitreichenden Folgen beeinflussen. Governance hilft Teams auch bei der Beantwortung grundlegender operativer Fragen: Welche Modellversion wird ausgeführt? Mit welchen Daten wurde es trainiert? Welche Features verwendet es? Wer hat es genehmigt? Was hat sich seit der letzten Version geändert?

MLOps erfordert eine miteinander verbundene Reihe von Komponenten. Einige Unternehmen stellen diese Komponenten über mehrere Systeme hinweg zusammen, während andere eine integrierte Plattform bevorzugen, die Daten, Feature-Management, Modellbetrieb und Governance enger zusammenführt.

Die MLOps-Reifestufe steigt in der Regel, wenn Teams mehr vom Lebenszyklus automatisieren und stärkere Kontrollen für Reproduzierbarkeit, Monitoring und Governance hinzufügen. Das MLOps-Reifestufenmodell von Google Cloud ist ein gängiger Referenzpunkt.

Stufe 0: Manueller Prozess

Auf Stufe 0 ist die ML-Arbeit Notebook-gesteuert und stark manuell geprägt. Data Scientists bereiten Daten vor, trainieren Modelle, evaluieren Ergebnisse und übergeben Artefakte durch informelle Prozesse. Dies kann für Experimente funktionieren, birgt jedoch Risiken, wenn Modelle in der Produktion reproduziert, aktualisiert oder überwacht werden müssen.

Stufe 1: Automatisierung von ML-Pipelines

Auf Stufe 1 automatisieren Teams die ML-Pipeline, sodass Modelle mit wiederholbaren Validierungs-, Trainings- und Evaluierungsschritten auf neuen Daten neu trainiert werden können. Das Ziel ist Continuous Training: eine kontrollierte Methode, um Modelle zu aktualisieren, sobald neue Daten verfügbar sind. Diese Stufe reduziert manuelle Übergaben, aber die Pipeline selbst erfordert möglicherweise noch ein separates Release-Management.

Stufe 2: Automatisierung von CI/CD-Pipelines

Auf Stufe 2 automatisieren Teams den Build, Test und das Deployment der ML-Pipelines selbst. Änderungen an Code, Datenvalidierungslogik, Trainings-Workflows und Deployment-Definitionen durchlaufen CI/CD-Prozesse. Hier ähneln ML-Operations eher einer Production-Engineering-Disziplin mit versionierten Pipelines, automatisierten Tests und kontrollierter Überführung über Umgebungen hinweg.

Fortgeschrittene Reifestufen: Autonome und kontrollierte Abläufe

Einige Reifestufenmodelle fügen eine höhere Stufe für fortgeschrittene oder autonome Abläufe hinzu. In dieser Phase können Monitoring-Signale Retraining-Workflows auslösen, Governance-Prüfungen sind in die Überführungspfade eingebettet und Teams können viele Modelle mit einheitlichen Richtlinien verwalten. Das Ziel ist nicht, menschliches Urteilsvermögen zu ersetzen, insbesondere bei Modellen mit großen Auswirkungen, sondern die routinemäßige Erkennung, Validierung und Eskalation systematischer zu gestalten.

Erfahren Sie, wie Sie mit Snowflake ML umfangreiche Modelle erstellen und operationalisieren:

Large Language Model Operations (LLMOps) erweitert MLOps-Praktiken auf Anwendungen für generative KI. LLMOps ergänzt MLOps um neue operative Aspekte in den Bereichen Prompts, Retrieval, Kontext, Token-Nutzung, Sicherheit und Evaluierung.

LLMOps umfasst in der Regel:

• Versionierung von Prompts und Systemanweisungen
• Evaluierungs-Frameworks für Faktentreue, Relevanz, Tonalität, Sicherheit und Aufgabenerfüllung
• Überwachung der RAG-Pipeline, einschließlich Dokumentenaktualität und Retrieval-Qualität
• Verfolgung von Token-Kosten und Latenzoptimierung
• Guardrail-Überwachung auf Datenschutz, Toxizität, Faktenbasierung und Richtlinienverstöße
• Feedbackschleifen für menschliche Überprüfung und Modellverbesserung

Das gleiche Funktionsprinzip gilt jedoch weiterhin: Die Anwendung ist nur so zuverlässig wie die Daten, der Kontext, die Evaluierung und die Governance dahinter.

Solide MLOps-Praktiken helfen Teams dabei, zu verhindern, dass produktives ML zu einer Ansammlung einmaliger Übergaben wird. Wenn Modelle aus der Entwicklung in Live-Workflows übergehen, benötigen Teams konsistente Methoden, um die Assets zu versionieren, die das Verhalten beeinflussen, Änderungen vor dem Release zu testen, die Performance in der Produktion zu überwachen und Modelle zu aktualisieren, ohne die Nachvollziehbarkeit zu verlieren.

Versionieren Sie alles, was das Modellverhalten beeinflusst

MLOps sollte Code, Datasets, Feature-Definitionen, Parameter, Modellartefakte, Abhängigkeiten, Evaluierungsergebnisse und Deployment-Metadaten versionieren. Wenn sich ein Modell ändert, müssen Teams wissen, ob sich die Performance aufgrund neuer Trainingsdaten, einer neuen Feature-Logik, eines anderen Parametersatzes oder einer neuen Laufzeitumgebung geändert hat.

Automatisieren Sie Tests und CI/CD dort, wo es das Risiko reduziert

Die Automatisierung sollte die Prüfungen abdecken, die Teams zuverlässig wiederholen müssen: Datenvalidierung, Feature-Validierung, Modellevaluierung, Paketierung, Deployment und Rollback. CI/CD für ML sollte auch modellspezifische Tests umfassen, wie z. B. Drift-Prüfungen, Bias-Tests, Latenzschwellenwerte und Leitplanken für Geschäfts-KPIs.

Überwachen Sie Produktionsmodelle kontinuierlich

Die Produktionsüberwachung sollte den Systemzustand und das Modellverhalten nachverfolgen. Latenz, Fehler und Kosten sind wichtig, aber das gilt auch für Eingabeverteilungen, Vorhersageverteilungen, Modell-Performance, Drift und Datenaktualität.

Sorgen Sie für Reproduzierbarkeit

Ein Team sollte in der Lage sein, zu beantworten, wie ein Modell erstellt wurde, mit welchem Dataset und welchen Features es trainiert wurde, welcher Code und welche Parameter verwendet wurden, welche Metriken die Freigabe gerechtfertigt haben und welche Version derzeit Vorhersagen liefert. Reproduzierbarkeit hilft bei Debugging, Auditierbarkeit, Zusammenarbeit und Compliance.

Beginnen Sie auf der Reifestufe, die das Team aufrechterhalten kann

Die MLOps-Reifestufe sollte den Anforderungen, Fähigkeiten und dem Risikoprofil des Unternehmens entsprechen. Ein Team mit einem risikoarmen Batch-Modell benötigt am ersten Tag möglicherweise kein autonomes Retraining. Ein Team mit vielen kundenorientierten Modellen, regulierten Anwendungsfällen oder sich schnell ändernden Daten benötigt früher eine stärkere Automatisierung, Monitoring und Governance.

Viele MLOps-Architekturen verschieben Daten über separate Systeme für Vorbereitung, Training, Feature-Management, Registry, Serving und Monitoring. Diese Trennung kann zu zusätzlichen Kopien, unzusammenhängender Lineage und mehr Orten führen, an denen Zugriffsrichtlinien oder Feature-Definitionen abweichen können. Der Ansatz von Snowflake besteht darin, einen größeren Teil des ML-Lebenszyklus zu den kontrollierten Daten in der Snowflake AI Data Cloud zu bringen.

Mit Snowflake ML können Teams Modelle näher an den Daten erstellen, trainieren, bereitstellen und überwachen, die diese Modelle verwenden. Snowflake ML umfasst Funktionen wie Snowpark ML APIs für die Entwicklung, Snowflake Notebooks für Exploration und Zusammenarbeit, den Snowflake Feature Store für das Feature-Management und die Snowflake Model Registry für Versionierung und Governance. ML Observability ermöglicht die Überwachung registrierter Produktionsmodelle, einschließlich Performance-, Drift- und Volumenmetriken, mit aktueller Unterstützung für Regressions- und binäre Klassifikationsmodelle.

Features können einmal definiert, durch Zugriffskontrollen verwaltet und über Lineage nachverfolgt werden, wenn sie vom Training in die Inferenz übergehen, während Modelle Metadaten, Versionsverlauf und Deployment-Status durch eine Registry mitführen. Data Scientists können weiterhin in Notebooks experimentieren, aber die Arbeit bleibt näher an den kontrollierten Daten, wobei eine Überwachung eingerichtet ist, um zu erkennen, wenn Produktionseingaben von den während der Evaluierung getroffenen Annahmen abweichen.

MLOps wird oft durch die Mechanismen des Deployments beschrieben: Pipelines, Registries, CI/CD, Monitoring und Retraining. Diese Mechanismen sind valide, aber sie lösen das größere Problem nur, wenn sie mit den Daten und dem Governance-Kontext rund um das Modell verbunden bleiben. Einer Modellversion lässt sich leichter vertrauen, wenn Teams die Daten nachverfolgen können, mit denen sie trainiert wurde, die verwendeten Features verstehen, sehen, wie sie während der Evaluierung abgeschnitten hat, und erkennen können, wenn sich das Verhalten in der Produktion zu ändern beginnt.

Da ML Teil von immer mehr Anwendungen und Geschäfts-Workflows wird, kann dieser operative Kontext nicht als optional betrachtet werden. Teams benötigen eine Möglichkeit, schnell zu agieren, ohne die Lineage zu verlieren, Features wiederzuverwenden, ohne Logik zu duplizieren, Modelle zu überwachen, ohne sie von den Daten zu trennen, von denen sie abhängen, und Produktionssysteme zu aktualisieren, ohne sich auf manuelle Übergaben verlassen zu müssen. MLOps bietet diese Struktur.