Ihre Herausforderungen beim Betrieb von Machine Learning

Um mit einem Machine Learning (ML) Projekt einen Mehrwert zu erzielen ist es erforderlich, dass ein oder mehrere ML-Modelle in Produktion laufen. Viele ML-Projekte scheitern jedoch an dieser Hürde, denn das entwickelte ML-Modell mit dem zugehörigen Code machen in einem ganzheitlichen produktiven ML-System nur noch einen geringen Anteil aus. Je nach Anforderungen sind Themen wie eine geeignete Infrastruktur, der Aufbau von ML-Pipelines wie z.B. automatisches Trainieren und Ausrollen neuer Modelle, Monitoring der produktiven Modelle und der Infrastruktur, Datenschutz, Sicherheit, Compliance, technische Anforderungen wie z.B. Verschlüsselung, Authentifizierung, Skalierung, Verfügbarkeit usw. zu lösen.

Falls zu spät über Konzepte für das Automatisieren von operativen ML-Landschaften nachgedacht wird, können je nach Anwendungsfall folgende Probleme auftreten:

  • Lange Ausrollzyklen für neue Modelle durch manuelle Trainings- und Deploymentprozesse.
  • Keine kontinuierliche und standardisierte Qualitätssicherung von Daten und Modellen aufgrund fehlender Standards.
  • Lange Ausrollzyklen für neuen Code durch manuelles Testen und Deployment.
  • Ohne ein Monitoring von produktiven Modellen kann es zu obsoleten Modellen und damit falschen Vorhersagen kommen, ohne dass es bemerkt wird.
  • Ohne ein Monitoring des gesamten ML-Systems können beispielsweise Performanceprobleme auftreten oder Ressourcen nicht richtig verteilt werden.
  • Durch fehlendes Daten-, Experiment- und Modellmanagement kann keine Automatisierung, Standardisierung, Wiederholbarkeit und Nachvollziehbarkeit erreicht werden.

Eine falsche Wahl der Infrastruktur, der Technik oder des Frameworks kann dazu führen, dass gegenwärtige oder zukünftige Anforderungen nicht mehr erfüllt werden können. Im schlimmsten Fall zieht das eine komplette Neuentwicklung des ML-Systems oder einzelner Komponenten nach sich.

Ihre Vorteile durch den Betrieb von Machine Learning

MLOps zielt auf eine Automatisierung und Standardisierung des gesamten ML-Lebenszyklus ab. Einer der wichtigsten Aspekte ist das kontinuierliche Trainieren und Ausrollen neuer Modelle. Um diese Prozesse zu automatisieren, bedarf es einer standardisierten ML-Pipeline mit zusätzlichen Schritten wie Daten- und Modellvalidierungen sowie Pipeline-Trigger zum Auslösen neuer Trainingsvorgänge. Weitere Voraussetzungen sind eine systematische Versionierung und Speicherung von Daten, Experimenten und Modellen, um Transparenz und Evaluierungen zu ermöglichen. Modulare, standardisierte und reproduzierbare Komponenten bilden die Grundlage für einzelne Schritte in der ML-Pipeline und sorgen dafür, dass keine Lücke mehr zwischen dem Entwicklungsstadium und dem Produktivbetrieb aufkommt.

Ein zentraler Bestandteil beim Betrieb von produktiven Machine Learning Modellen ist ein aktives Monitoring sowohl der Modellperformance als auch von technischen Metriken wie beispielsweise Antwortzeiten der Services oder CPU- und Speicherauslastung. Damit kann die Güte des Modells in Produktion überwacht und rückverfolgt werden, falls Performanceprobleme auftreten. Ebenso werden eingehende Daten auf signifikante Veränderungen überwacht (Concept Drift Detection), um einen neuen Trainingsprozess aufgrund eines veralteten Modells anzustoßen. Das technische Monitoring dient zur Sicherstellung des reibungslosen Betriebs des kompletten ML-Systems. Falls zum Beispiel zu hohe Lasten auftreten, die von der vorhandenen Infrastruktur nicht gestemmt werden können, werden automatisch neue Ressourcen hinzugefügt.

Mit einem automatisierten und standardisierten ML-Lebenszyklus werden folgende Vorteile geschaffen:

  • Automatisiertes und kontinuierliches Training sowie Ausrollen neuer Machine Learning Modelle in Produktion.
  • Geringe Ausrollzyklen für neue Modelle, da alle Schritte der Trainings-Pipeline automatisiert und nicht manuell durchgeführt werden. Dadurch verkürzt sich die Zeit vom Triggern des ML-Trainings bis zum tatsächlich ausgerollten Modell erheblich.
  • Automatisierte Qualitätssicherung der Daten und Modelle.
  • Reproduzierbarkeit und Nachverfolgung von Experimenten und Modellen.
  • Überwachung der Modelle und Infrastruktur.
  • Schnelle Iterationen von Experimenten durch standardisierte, orchestrierte ML-Pipelines.

Die Funktionsweise für den Betrieb von Machine Learning

Der Aufbau sieht mindestens eine Experiment- und Produktivumgebung vor. Je nach Anwendungsfall können weitere Umgebungen wie eine Testumgebung und verschiedene Staging-Umgebungen nach Bedarf hinzugefügt werden. Die Experimentumgebung erlaubt eine schnelle Iteration und Durchführung von experimentellen Trainingsprozessen. Hierfür kommen orchestrierte ML-Trainingspipelines zum Einsatz. Das Ziel ist, dass die Trainings-Pipeline der Experiment-Umgebung sich so wenig wie möglich von der Pipeline der Produktionsumgebung unterscheidet. In Projekten sollte schnellstmöglich dazu übergegangen werden, orchestrierte Pipelines mit standardisierten Komponenten zu verwenden, anstatt manuelle Schritte beispielsweise in Jupyter-Notebooks auszuführen. Durch orchestrierte ML-Pipelines in der Experimentumgebung können neue oder modifizierte Pipelines mit wenig Aufwand in Produktion ausgerollt werden und es entsteht von Anfang an keine große Lücke zwischen Code in der Entwicklungsphase und dem tatsächlichen Einsatz.

Referenzarchitektur einer ML-Landschaft. Quelle: eigene Darstellung angelehnt an Google.

Das automatische Erstellen, Testen und Ausrollen einer Pipeline wird mithilfe einer sogenannten Continuous Integration/ Continuous Delivery (CI/CD) Pipeline erreicht. Dadurch werden in kürzester Zeit Updates für die Pipeline in Produktion überführt, die bereits auf ihre Funktionalität getestet wurden. Insgesamt baut MLOps auf die DevOps-Prinzipien der Softwareentwicklung auf.

Die Daten für alle Umgebungen werden zentral in einem Feature Store gehalten. Dieser dient zur systematischen Speicherung und Versionierung von Daten und Features. Dadurch können Features von mehreren Teams gleichzeitig genutzt werden und es entstehen keine Silos beim Feature Engineering. Die Daten können von mehreren Quellen angebunden werden. Dabei spielt die Skalierung eine wesentliche Rolle. Auch bei sehr großen Datensätzen muss in Echtzeit der Zugriff auf aktuelle Daten gegeben sein. Des Weiteren müssen die Daten sowohl für alle Umgebungen als auch für unterschiedliche Komponenten wie dem Modell-Training und dem Prediction Service immer konsistent und aktuell sein, damit der Sprung von der Entwicklung in den produktiven Einsatz schnell und ohne mögliche Fehlerquellen erreicht werden kann.

Wesentliche Pipeline-Komponenten:

Die aus dem Feature Store extrahierten Daten werden auf verschiedene Eigenschaften überprüft. Beispielsweise können sie mit einem hinterlegten Datenschema abgeglichen werden, um Anomalien, fehlende Werte, Feature-Bereiche oder falsche Datentypen zu identifizieren. Optional kann noch ermittelt werden, ob ein sogenannter Data Drift vorliegt. Dabei handelt es sich um eine signifikante Veränderung in der Verteilung der Daten im Vergleich zur vorherigen Version. Das Ergebnis kann genutzt werden, um zu entscheiden, ob ein neues Training angestoßen werden sollte.

Nach dem Training wird das Modell mit dem vorbereiteten Testdatensatz evaluiert. Der Output besteht aus allen nötigen Metriken und Kennzahlen, um die Qualität des Modells und die Fähigkeit zur Generalisierung zu bestimmen.

Im Anschluss werden die Metriken des neuen Modells mit denen des aktuellen Modells oder einer Baseline verglichen. Damit das neue Modell in Produktion ausgerollt werden kann, muss die Performance die Baseline oder das alte Modell übertreffen. Dabei sind abhängig vom Anwendungsfall die Granularität und verschiedene Metriken zu beachten. So kann beispielsweise nur die Betrachtung der Genauigkeit bei einer Klassifikationsaufgabe keine Unterschiede zwischen Falsch-Positiven und Falsch-Negativen ausmachen, was zu einer trügerischen Sicherheit führen kann.

In der Modell-Registry werden alle trainierten Modelle in der jeweiligen Umgebung zentral gespeichert und versioniert. Die zugehörigen Metriken und Metadaten der Modelle liegen in einer separaten Meta-Datenbank. Aus der Modell-Registry kann automatisiert das aktuelle Modell in den Prediction Service ausgerollt werden, der durch einen Endpunkt angesprochen werden kann. Damit werden, vergleichbar mit den Daten, Silos für Modelle vermieden und gleichzeitig eine Ausfallsicherheit erreicht.

In der Meta-Datenbank werden sämtliche Metadaten, Metriken, Parameter und Hyperparameter jeder Komponente der Pipeline systematisch gespeichert und versioniert. Damit wird Transparenz, Nachverfolgung und Reproduzierbarkeit von Experimenten bzw. Pipeline-Durchläufen geschaffen. Die Meta-Datenbank legt zudem Zeiger auf die zugehörigen Artefakte wie Modelle und Daten im Feature Store und der Modell-Registry ab.

Das validierte ML-Modell wird als Prediction Service ausgerollt. Je nach technischen Anforderungen sind Themen wie Skalierbarkeit, Verschlüsselung, Authentifizierung, Antwortzeiten und Verfügbarkeit zu beachten. Entsprechend des Anwendungsfalls gibt es unterschiedliche Szenarien für das Model Deployment. Beispielsweise erhält beim A/B Testing das neue Modell nur einen geringen Prozentsatz der Anfragen. Ähnlich dazu verhält sich das sogenannte Shadow Model. Dabei läuft das neue Modell im Hintergrund, wodurch die Performance auf echten Daten gemessen und evaluiert werden kann. Der Prediction Service besteht aus einer Inferenz-Pipeline. Jedes ML-Modell benötigt eine Vorverarbeitung der Daten, ähnlich zu der im Trainingsvorgang, bevor diese an das tatsächliche Modell übergeben werden können. Optional kann noch eine Nachverarbeitung der Vorhersagen des Modells erfolgen, bevor das finale Ergebnis an den Aufrufer zurückgegeben wird.

Das Monitoring ist als unerlässliche Komponente für den produktiven Betrieb eng mit dem Prediction Service verbunden.

Dabei werden fachliche Aspekte des Prediction Service (fachliches Monitoring) sowie die gesamte Produktivumgebung (technisches Monitoring) überwacht. Das fachliche Monitoring ist stark vom Anwendungsfall abhängig. Bestandteile wie Model Performance Monitoring, Outlier Detection, Concept Drift Detection oder Adversarial Attack Detection sollten in Betracht gezogen werden. In jedem Fall muss die Performance des Modells in der Produktions-Umgebung überwacht werden, um die Vorhersagequalität auf sich möglicherweise veränderte Daten zu überprüfen. Zudem ist die Erkennung, ob eine Veränderung in der Verteilung der Daten im Vergleich zu den Trainingsdaten vorliegt (Concept Drift Detection), eine weitere wichtige Komponente, um festzustellen, ob ein neuer Trainingsprozess angestoßen werden soll.

Das technische Monitoring dient der Sicherstellung, dass der Prediction Service und die Monitoring-Komponenten reibungslos ausgeführt werden. Dazu werden beispielsweise Metriken wie CPU- oder Speicher-Auslastung, Requests per Second, Response Time und Success Rate automatisch gesammelt und in Dashboards visualisiert. Zudem können Alarme auf verschiedene Kennzahlen und Metriken eingerichtet werden. Feedbackloops stellen eine weitere Möglichkeit dar, die Modell-Qualität zu wahren oder zu verbessern. Eine mögliche Umsetzung wäre, den Aufrufer direkt zu fragen, ob er mit der Vorhersage der Services einverstanden ist oder diese korrigieren möchte. Das Feedback wird in einem späteren Training genutzt, um das Modell dahingehend anzupassen. Bei einer automatisierten ML-Landschaft wird das ML-Training eigenständig durch Trigger angestoßen.

Unterschiedliche Szenarien können dabei ein neues Modell-Training auslösen:

  • Durch ein zeitliches Intervall, beispielsweise von einem Monat.
  • Durch die Verfügbarkeit von neuen Daten.
  • Falls die Model-Performance stark zurückgeht.
  • Falls eine signifikante Veränderung in der Verteilung der eingehenden Daten auftritt.
    Veränderung des Modells selbst oder des Codes zur Vorverarbeitung.

Technologien für den Betrieb von Machine Learning

Die Technologievielfalt im Bereich von MLOps ist überwältigend und stetig im Wandel. Für einzelne Komponenten, wie z.B. dem Tracking von Parametern und Metriken oder dem Pipelining, stehen viele unterschiedliche Tools und Technologien zur Verfügung. Diese müssen zu einer MLOps-Landschaft kombiniert werden. Als Alternative gibt es kommerzielle Plattformen wie das Azure ML Studio, den AWS Sagemaker oder die Google Vertex AI Plattform, die eine ganzheitliche MLOps-Lösung in der jeweiligen Cloud darstellen. Eine weitere Möglichkeit bietet Kubeflow mit einer Open-Source Plattform, die in jeder Cloud und On-Premise ausgerollt werden kann. Insgesamt müssen verschiedene Technologien und Tools vor dem Hintergrund des Anwendungsfall und der Anforderungen beleuchtet werden, um geeignete Werkzeuge oder eine ganzheitliche Plattform auszuwählen.

Im Folgenden wird eine konkrete Umsetzung einer exemplarischen MLOps-Landschaft anhand eines ML-Empfehlungs-Services (Recommender-System) für Webshop-Artikel betrachtet. Die zugrundeliegende MLOps-Plattform ist Kubeflow, ein auf Kubernetes basierendes Open-Source Projekt, welches eine sehr große Flexibilität bietet und unabhängig vom Cloud-Anbieter ist. Kubeflow besteht aus mehreren Komponenten wie Pipelines, Jupyter-Server oder KFServing und deckt damit eine große Bandbreite der MLOps-Anforderungen ab. Die Referenzarchitektur für den Anwendungsfall eines Empfehlungsdienstes sieht wie folgt aus:

Referenzarchitektur eines Empfehlungsdienstes. Quelle: eigene Darstellung angelehnt an Google.

Die MLOps-Landschaft sieht zwei Kubernetes Umgebungen vor. Kubernetes zeichnet sich unter anderem durch eine hohe Verfügbarkeit, Stabilität, Skalierbarkeit und Container für leichtgewichtige Microservice-Architekturen aus. Demnach ist Kubernetes bestens für den Anwendungsfall eines Empfehlungssystems geeignet, da gerade Verfügbarkeit und Skalierbarkeit zentrale Anforderungen an den ML-Service sind. In der Kubernetes Entwicklungsumgebung ist die Kubeflow Plattform zum Experimentieren von Training-Pipelines aufgesetzt. Metadaten, Parameter und Metriken der Trainingsdurchläufe werden durch den MLflow Tracking-Server aufgezeichnet und in einer Meta-Datenbank wie z.B. MySQL persistent gespeichert. Artefakte wie ML-Modelle werden im sogenannten Artefakt-Storage gespeichert, was beispielsweise ein Amazon S3 Bucket oder ein Repository sein kann. Ziel dieser Umgebung und der Pipeline ist, dass der Unterschied zur Produktions-Pipeline so gering wie möglich ist, um ein schnelles Deployment von einzelnen Komponenten oder einer komplett neuen Pipeline zu ermöglichen.

Wird ein Software-Update durch einen Git-Commit ausgelöst, kann mithilfe einer Gitlab CI/CD Pipeline die neue Trainings-Pipeline automatisiert in Produktion ausgerollt werden. Dazu werden die Container zusammen mit dem Python Source Code erstellt, verschiedene Software-Tests wie Unit-Tests, Integrations-Tests, End-zu-End-Tests usw. durchgeführt, bevor die erstellten Container in eine Container-Registry, z.B. in Gitlab der Produktiv-Umgebung, hochgeladen werden. Daraus kann das Deployment in Produktion ausgeführt werden.

Aktuell befindet sich der Feature Store von Kubeflow (Feast) noch in Entwicklung, dennoch stellt er grundlegende Funktionalitäten bereits zur Verfügung. Mit ihm ist es möglich, versionierte und konsistente Features in der Cloud zu speichern, die von mehreren Umgebungen und unterschiedlichen Teams oder Projekten genutzt werden können. Es können sowohl historische Daten für ein Modell-Training als auch Echtzeitdaten abgefragt werden, die für die Inferenz benötigt werden.

Die Kubernetes Produktivumgebung besteht aus der Kubeflow Plattform und einem technischen Monitoring, auf das später eingegangen wird. Die Kubeflow Trainings-Pipeline in Produktion ist durch die Gitlab CI/CD Pipeline ausgerollt und vorher in der Entwicklungsumgebung erstellt und getestet worden. Was das Experiment- und Modell-Tracking betrifft, sind beide Training-Pipelines identisch. Die Pipeline in Produktion wird automatisiert durch Trigger angestoßen und zieht sich die relevanten Features aus dem Feature Store für einen neuen Trainingsprozess. Nach dem Training wird das Modell als KFServing Inference Service ausgerollt. KFServing ist eine Komponente von Kubeflow, die für das Ausrollen und Betreiben von ML-Modellen verschiedener Frameworks konzipiert wurde. Es stellt Funktionen wie eine automatische anfragenbasierte Skalierung der Services auf CPUs und GPUs, Explainer, Batching, A/B Testing, Multi-Armed-Bandits sowie Traffic- und Versions-Management zur Verfügung.

Bei einer Anfrage an den Inference Service wird die Antwort nach der Inferenz und der Nachverarbeitung sowohl an den Aufrufer als auch an das fachliche Monitoring weitergeleitet. KFServing setzt in seiner Referenzarchitektur einen Knative-Broker ein, um eine Weiterleitung der Prediction an beliebig viele weitere Komponenten zu erlauben. In diesem Anwendungsfall handelt es sich um das Model Performance Monitoring, die Concept Drift Detection und die Outlier Detection. Diese Komponenten können durch eine Eigenentwicklung oder mithilfe von bestehenden Algorithmen beispielsweise der Alibi-Detect Bibliothek erstellt werden. Die resultierenden Metriken werden persistent in einer Zeitreihendatenbank wie der InfluxDB gespeichert.

Für das technische Monitoring der gesamten Produktivumgebung können eine Vielzahl an Tools eingesetzt werden. Beliebte Open-Source Kombinationen sind beispielsweise Prometheus und Grafana und/oder ein ELK-Stack. Prometheus dient zur Überwachung des Kubernetes Clusters und sammelt Metriken auf verschiedenen Ebenen wie dem gesamten Cluster, Nodes, Pods, Namespaces oder Services. Mittels Grafana können vorgefertigte und neue Dashboards zur Visualisierung der Metriken von Prometheus und des fachlichen Monitorings genutzt werden. Zusätzlich können Alarme in beiden Tools konfiguriert werden.

Unsere Dienstleistungen für den Betrieb von Machine Learning

Das konkrete MLOps-Konzept erarbeiten wir entsprechend Ihrer individuellen Anforderungen und Bedürfnisse. Zu Beginn ist es uns wichtig, dass wir uns ein genaues Bild von Ihrem Geschäftsfall machen und Ihre Anforderungen an ein solches System sehr gut verstehen. Gerne unterstützen wir Sie bei der Konzeption, Auswahl der Technologie und der Implementierung der notwendigen Komponenten:

  • Innovationsworkshop: Wir besprechen Ihre Ausgangssituation, den Ist-Zustands der ML-Landschaft, Ziele und identifizieren Potenziale. Gemeinsam bewerten und priorisieren wir die Potenziale. Gerne berichten wir Ihnen, wie andere Unternehmen vergleichbare KI-Automatisierungsaufgaben angegangen sind. Am Ende des Tages haben Sie eine Vielzahl an Ideen, wie Ihnen der Start in das Thema gelingen kann.
  • Planung der Vorgehensweise: Ausgehend von Ihrer Ausgangssituation, wählen wir die passenden Technologien und planen detailliert die Umsetzung.
  • Umsetzung einer ersten Automatisierung: Dabei schauen wir zusammen auf die Quick Wins und achten darauf, dass bereits der erste Schritt einen wertvollen Beitrag leistet und Ihre Prozesse verbessert. Bei der Umsetzung des Projekts legen wir Wert auf einen agilen Ansatz. In enger Kooperation mit Ihnen erstellen wir die Lösung schrittweise und integrieren sie fortlaufend in Ihre Strukturen. Bei Bedarf können wir so schnell auf geänderte Umstände reagieren.
  • Trainings für einen gezielten Wissenstransfer: Wir möchten Sie befähigen, auch eigenständig weiterarbeiten zu können. In Workshops und Trainings holen wir Sie dort ab, wo Sie gerade stehen und bereiten Themen fachgerecht auf.
  • Technologieberatung: Den Überblick über alle Technologien bzgl. MLOps zu haben, ist eine echte Herausforderung. Wir helfen Ihnen, die für Sie geeigneten Technologien zu finden und Sie bei der Entscheidung zu beraten.
  • MLOps Engineer as a Service: Expert:innen automatisieren und betreiben nach Ihren Anforderungen und Gegebenheiten Ihre ML-Landschaft.

Ihr Ansprechpartner

Novatec_Christoph-Heger

Dr. Christoph Heger

Head of Practice Area Data Intelligence
Inhaltsverzeichnis
Dr. Christoph Heger Head of Practice Area Data Intelligence
Novatec_Christoph-Heger