Blog
4 Min. Lesezeit
von Victor Wolf, Lars Kleinschmidt, Martin Siehler & Simon Siedersleben
MLOps ist die Abkürzung für Machine Learning Operations und ist ein Paradigma, das darauf abzielt, Machine-Learning-Modelle zuverlässig und effizient zu implementieren und zu warten. MLOps unterscheidet sich vom klassischen DevOps insbesondere dadurch, dass es sowohl Modelle als auch Daten in den Entwicklungs- und Betriebsprozess integriert. Eine Herausforderung besteht darin, dass Daten und Modelle sehr groß sein können, was die aktive Entwicklung und Wartung dieser Systeme erschwert. Im besten Fall orchestriert MLOps nicht nur das Management von Big Data und komplexen Modellen, sondern erleichtert auch die Zusammenarbeit zwischen Data Scientists, Entwicklern und Operations-Ingenieuren.
Mehr denn je ist der Einfluss von KI in der heutigen Gesellschaft spürbar. Auch in der Projektwelt gibt es derzeit zahlreiche KI-Projekte oder Projekte, die mithilfe von KI optimiert werden können – sei es in der Gesichtserkennung, bei Produktempfehlungen, der Anomalieerkennung oder bei Chatbots. Aus diesem Grund haben wir im Rahmen unserer AI Guild einen Blueprint entwickelt, der KI optimal in die Softwareentwicklung integriert.
Neben dem Wissensaufbau zu diesem Thema haben wir einen praktischen Ansatz gewählt und uns zum Ziel gesetzt, ein einfaches ML-Problem mit typischen MLOps-Techniken anzugehen und in einem Proof of Concept (PoC) festzuhalten. Vor allem war es uns wichtig, die Pipeline selbst gestalten und in einer von uns verwalteten Cloud betreiben zu können.
Dabei stellte sich sofort die erste Frage: Welche Technologien wollen wir eigentlich nutzen, um diese Pipeline aufzubauen und bereitzustellen? Nach einer kurzen Google-Suche stießen wir direkt auf zahlreiche Lösungen, die eine einfache Bereitstellung von MLOps bei hoher Anpassungsfähigkeit an Cloud- und Projektbedingungen versprachen. Wir sind diesen Ansätzen einfach gefolgt und haben verschiedene Frameworks getestet. Leider mussten wir schnell feststellen, dass wir viel zu hohen Versprechungen zum Opfer gefallen waren. Einige der Lösungen waren technisch bei Weitem nicht ausgereift genug oder nicht so flexibel einsetzbar, wie wir gehofft hatten. ZenML war dafür ein typisches Beispiel: Lokal konnten wir schnell eine Pipeline aufsetzen, die unser Problem lösen konnte. Die wesentlichen Herausforderungen entstanden jedoch beim Versuch, diese Pipeline in der Cloud bereitzustellen und zu betreiben. Die scheinbar einfache Deployment-Funktionalität führte zu zahlreichen Fehlern, und nach einigen Versuchen, diese zu beheben sowie Issues auf GitHub zu erstellen, kamen wir nicht weiter, bis wir das Projekt schließlich wieder zur Seite legten. Einen weiteren Versuch unternahmen wir mit TFX. TFX ist ein Ausführungs-Framework für TensorFlow, das auf Kubeflow Pipelines basiert. Diese Lösung funktioniert ähnlich wie Kubeflow Pipelines und fügt eine zusätzliche Abstraktionsschicht hinzu. Damit konnten wir Pipelines in der Cloud bereitstellen. Der Mehrwert gegenüber Kubeflow Pipelines war für uns jedoch zu gering.
Dennoch brachte uns dies unserer Entscheidung einen Schritt näher. Warum also nicht direkt Kubeflow Pipelines nutzen? Mit Kubeflow Pipelines können Sie Ihre Pipelines einfach definieren und direkt auf einem Kubeflow-Cluster bereitstellen. Kubeflow selbst basiert direkt auf dem Kubernetes-Stack und läuft daher Cloud-agnostisch. Für diese Lösung benötigten wir etwas mehr Anpassung und Konfiguration, um die Komponenten miteinander zu verdrahten. Allerdings erhielten wir dadurch auch direkten Einfluss auf die Funktionalitäten, die wir für unsere Pipeline benötigten. Am Ende begannen wir damit, unser eigenes MLOps-Framework / unseren eigenen Blueprint auf Basis von Kubeflow Pipelines aufzubauen. Nun haben wir die volle Kontrolle über die Funktionalität und können im Falle von Problemen leichter reagieren.
Damit machten wir uns daran, den geplanten PoC anzugehen.
Um die Entscheidung für Kubeflow zu validieren, haben wir eine PoC-Pipeline entwickelt, um die Funktionalität von Kubeflow im Detail kennenzulernen. Dafür haben wir ein einfaches TensorFlow-Modell (Fashion MNIST) verwendet.
Wir haben zwei alternative Varianten für die Ausführung und Bereitstellung entwickelt: Eine Variante nutzt eine klassische Kubeflow-Instanz, die wir in der Google Kubernetes Engine (GKE) betreiben, während die andere Vertex AI verwendet. Vertex AI kann Kubeflow-Pipelines mit geringem administrativem Aufwand ausführen.
Die Vertex-AI-Variante eignet sich gut, wenn man schnell in die Feinheiten von Kubeflow einsteigen möchte, ohne sich um eine eigene Kubeflow-Instanz kümmern zu müssen. Hinsichtlich der Unabhängigkeit von Cloud-Anbietern macht eine eigene Kubeflow-Instanz jedoch oft mehr Sinn. Die Pipeline führt vier Schritte aus:
Die Daten für das Training und die Evaluierung des Modells müssen zu Beginn bereitgestellt werden. In diesem Fall werden die Daten aus dem Keras-Fashion-MNIST-Datensatz geladen. Alternativ können sie auch aus CSV-Dateien, Datenbanken oder anderen Datenquellen geladen werden.
Das Modell wird trainiert. In diesem Fall wird TensorFlow für das Training verwendet.
Die Funktionalität ist vom Konzept her jedoch so offen gestaltet, dass jede Art von Modell trainiert werden kann. Die Pipeline speichert das trainierte Modell in einem Google Cloud Bucket.
Um die Genauigkeit des Modells zu überprüfen und seine Qualität im Vergleich zu vorherigen Versionen zu bewerten, werden in diesem Schritt Tests mit den in Schritt eins gesammelten Testdaten durchgeführt. Daraus können Metriken wie die Genauigkeit (Accuracy) erfasst werden. Wenn das Modell bestimmte Mindestwerte unterschreitet oder schlechter als das vorherige ist, kann es abgelehnt werden, sodass das alte Modell verfügbar bleibt.
Das Modell wird über einen Serving-Container an einem Endpunkt bereitgestellt. Dieser Container ist entweder vorgefertigt (z. B. der TensorFlow Serving Container) oder kann vom Benutzer selbst erstellt werden. Hierfür kann entweder Vertex AI Serving genutzt werden oder der Container wird im selben GKE-Cluster bereitgestellt, der bereits für Kubeflow genutzt wird.
Wir sind mit den gebotenen Funktionalitäten sehr zufrieden. Ein Drittanbieter-Modell konnte mithilfe unseres PoCs in sehr kurzer Zeit integriert werden. Kubeflow ist vielseitig und lässt sich sinnvoll einsetzen. Die vier im PoC umgesetzten Schritte stellen das Minimum für unseren Anwendungsfall dar.
Weitere Schritte können jedoch problemlos hinzugefügt werden.
Auf der Suche nach dem idealen MLOps-Ökosystem haben wir die Erkenntnisse aus unserem PoC genutzt, um weitere Schlüsselaspekte zu berücksichtigen. Ein kritischer Punkt ist, dass unser aktueller PoC stark auf Google-Cloud-Komponenten basiert. Daher planen wir die Entwicklung eines universellen Blueprints, der nicht nur Cloud-agnostisch und anbieterunabhängig, sondern auch einfach zu konfigurieren und zu integrieren ist. Das Diagramm bietet einen Überblick über die geplanten Komponenten des Blueprints.
Unser MLOps Blueprint Cloud Stack
Wir beabsichtigen, unseren PoC um Observability-Komponenten unter Verwendung eines Prometheus-Grafana-Stacks zu erweitern. Auch Evidently AI könnte eingesetzt werden, um ML-spezifische Metriken zu erfassen. Im Bereich Continuous Delivery streben wir ebenfalls eine Verbesserung an, um einen stärkeren Fokus auf GitOps zu legen. Dies könnte durch die Implementierung von Flux geschehen. Außerdem planen wir, unseren aktuellen Serving-Container durch ein Serving-Framework zu unterstützen; BentoML wäre hier eine Option. Im Datensegment möchten wir mehrere konfigurierbare Datenquellen integrieren. Obwohl der Modell-Aspekt durch unseren PoC weitgehend abgedeckt ist, sehen wir Optimierungspotenzial durch den Einsatz einer effizienten Model Registry wie MLflow.
Wir haben Kubeflow als Fundament für unseren gesamten MLOps-Stack gewählt. Dies liegt an seinen Kubernetes-nativen Eigenschaften, die eine gewisse Unabhängigkeit von Anbietern gewährleisten, sowie an den positiven Erfahrungen, die wir bereits in unserem PoC mit Kubeflow gesammelt haben.
Unser nächstes Ziel ist die Umsetzung dieses universellen Blueprints. Dies soll es ermöglichen, die unterschiedlichsten ML-Anwendungsfälle mit einfachen Konfigurationen zu unterstützen. Das ebnet den Weg für den produktiven Einsatz von ML-Systemen bei QAware, indem es eine flexible und robuste Basis für verschiedene Anwendungen bietet.
