Dr. Richard Müller
Managing Consultant
Dr. Sven Upgang
Senior Consultant und Experte für Big Data und ML
Im neuesten Senacor Innolab hat es sich ein Team von Senacor-Kolleg:innen zur Aufgabe gemacht, Machine Learning Modelle mit Hilfe von MLOps zu operationalisieren. In einer Azure-Umgebung wurde das Konzept auf die Probe gestellt und ein Text-Summarizer für Artikel des Senacor Blogs entwickelt. Es zeigt sich: Die Azure Machine Learning Lösung Azure ML bietet einige hilfreiche Funktionen. In Verbindung mit Azures DevOps-Produkt ergibt das allerdings nicht automatisch auch ein „Azure MLOps“.
„In Österreich wird mit der Bildungskarenz ein innovatives Konzept zur Weiterbildung innerhalb eines gesicherten finanziellen Rahmens angeboten. Neben dem Erwerb der Sprachkompetenz wollte ich vollständig in diese für mich fremde Kultur eintauchen und das Leben aus einem anderen Blickwinkel betrachten. Mit Blick auf die Realisierung möchte ich meinem damaligen Projektumfeld ein großes Dankeschön aussprechen.“
Erkannt, worum es hier geht? Fleißige Lerser:innen unseres Blogs werden selbstverständlich erkannt haben, dass es sich hierbei um eine Zusammenfassung eines Blogartikel von Markus Arzt über ein Sabbatical bei Senacor handelt. Wer fasste hier zusammen? Eine von uns trainierte KI.
Zugegeben: Die KI befindet sich noch in der Ausbildung, doch das Ergebnis kann sich sehen lassen: Das zugrundeliegende Machine Learning-Modell hat ein Team aus Senacor-Kolleg:innen und Data Scientists innerhalb von drei Wochen in Azure implementiert. Ziel war es herauszufinden, inwiefern MLOps in einer Azure-Umgebung umsetzbar ist. Eine herausfordernde Aufgabe, die aber die erwünschten Erfolge erzielte.
Ausgangslage: MLOps, Summarization, Innovationlab
MLOps zielt darauf Machine Learning-Modelle effizient und zuverlässig betreiben und weiterentwickeln zu können. Das Wort setzt sich aus den Begriffen Machine Learning (ML) und der bereits etablierten Entwicklungspraxis für Software DevOps zusammen. Hierbei erweitert diese recht neue Praxis den DevOps-Kreislauf um einen ML-Lifecycle (siehe Abbildung 1).
Abbildung 1: Der MLOps-Kreislauf erweitert den DevOps-Lifecycle um die klassischen ML-Segmente
Um ein ML-Modell effizient zu betreiben, braucht es also nicht nur die traditionellen Phasen der Software-Entwicklung (Development: Code, Build, Test) und -Betrieb (Operation: Release, Deploy, Operate, Monitor), sondern zusätzlich die klassischen Machine Learning-Phasen. Dazu gehört, die Daten zu analysieren (Explore), sie auf ihre Qualität zu prüfen (Validate) und zu bereinigen (Clean). Zugleich müssen Data Scientists Modelle trainieren (Engineer) und deren Performance regelmäßig prüfen (Evaluate).
In der Vergangenheit hat Senacor die Expertise im Bereich MLOps weiter verstärkt. Um sie noch zu erweitern, zielten Kolleg:innen darauf, MLOps prototypisch in der Microsoft Azure-Umgebung zu verproben. Im Fokus stand dabei die Frage: Lassen sich die bereits existierenden Programme Azure DevOps und Azure ML so verbinden, dass schlussendlich dabei eine Art „Azure MLOps“ herausspringt?
Auf der Suche nach einem Anwendungsfall, der Senacor auch nachhaltig nutzen würde, fiel die Wahl auf Zusammenfassungen von Artikeln des Senacor-Blogs. Das Redaktionsteam will die dafür konzipierte KI zukünftig auch anwenden. Dafür nahmen sich Entwickler:innen und Data Scientists in einem Innovationslabor der Aufgabe an. Sie haben dabei viel über Azure ML Studio gelernt und die einzelnen Elemente des ML-Lifecycles nochmal genau unter die Lupe genommen.
Azure ML Studio – Der Umgang mit den Daten
Eine Gemeinsamkeit, auf die sich Data Scientists bei der Arbeit mit sämtlichen ML-Applikationen einstellen müssen: Die meiste Zeit verbringen sie damit, Daten aufzubereiten, zusammenzutragen und zu bereinigen. Das ist bei Azure ML nicht anders. Zunächst verschaffte sich das Team einen Überblick darüber, wie sie Daten in Azure behandeln. Dazu bietet die Cloud-Computing-Plattform Datastores. Innerhalb dieser Datastores lassen sich wiederum Datasets definieren, die thematisch zusammenhängende Daten darstellen.
Abbildung 2: Ein Einblick in die Datenumgebung in Azure ML
Die Datasets teilen sich in registered und unregistered Datasets auf. Wobei registered Datasets sowohl einen Namen besitzt als auch zusätzliche Features in Azure ML enthält. Dazu gehört beispielsweise eine automatische Versionierung oder einfacher Zugang über den Namen. Datasets bildet Azure entweder als Container ab, in dem alle möglichen Dateitypen Platz finden (Azure File Datasets) oder als spezieller Ablageort für Tabellen-Daten (Tabular Dataset). Mithilfe eines selbstgeschriebenen Python-Moduls und dem Azure Software Development Kit konnten die Expert:innen die Datasets von Azure in Jupyter-Notebooks bedienen, laden und speichern.
Der Datenüberblick war aber nur der erste Schritt auf der Azure-Entdeckungsreise. Nun standen die Data Scientists vor der Aufgabe, 49 vorhandene Blogartikel zu analysieren und aufzubereiten. Das Problem: Im Normalfall ist eine derartig geringe Stichprobe eigentlich nicht ausreichend, um ein ML-Modell effizient zu trainieren. Erschwerend hinzu kam, dass Zusammenfassungen nur für sehr wenige Artikel existierten und sich sowohl Länge als auch Schreibstil der Autor:innen stark voneinander unterschieden. Somit benötigte das Team ein Modell, das bereits Vorerfahrungen im Umgang mit Texten in deutscher, aber auch in englischer Sprache, vorweisen konnte.
Mit Finetuning zum gewünschten Modell
Sie entschieden sich für ein vortrainiertes mt5-Modell als Grundlage. Der große Vorteil des Modells: Es ist multilingual trainiert und somit eins der wenig vorhandenen Modelle, das mit deutschen Texten umgehen kann. Allerdings ist es auf einzeilige Zusammenfassungen von sachlichen und formellen Texten trainiert, sodass der lockere Schreibstil eines Blogartikels ein komplett neues Trainings-Set bedeutet. Daher lag es nun an den Data Scientists, dieses Modell mit Finetuning an die gewünschte Darstellungsform und mehrzeilige Zusammenfassungen zu gewöhnen.
Um den ersten Trainingslauf überhaupt starten zu können, mussten zunächst die notwendigen Schritte zur Data Preparation definiert werden. Dazu gehört unter anderem HTML-Tags, Hyperlinks oder Sonderzeichen aus den vorhandenen Blogartikeln zu entfernen. Dazu luden die Data Scientists die Texte via Python-Funktion von einem Jupyter Notebook und reinigten diese automatisiert mittels Skripten. Zusätzlich holten sie manuelle Zusammenfassungen der Blog-Autoren ein oder schrieben sie selbst. Mithilfe der Data Preparation und dem Finetuning auf dem Compute-Cluster entstand so ein vorläufiges Trainings-Set für die erste Modellversion.
Engineer in Azure ML Studio – Den Blog-Summarizer zum Laufen bringen
Hinter dem Konzept MLOps steckt die Absicht, Machine Learning und DevOps gleichzeitig zu ermöglichen. Deshalb investierten die Data Scientists viel Zeit, die Skripte lauffähig zu machen – sowohl für die Ausführung aus einem Jupyter-Notebook als auch für den Einsatz in der automatisierten Trainingspipeline. Der Prozess läuft dabei recht ähnlich ab. Egal, ob aus einem lokalen Notebook heraus oder als Teil der Trainingspipeline, in beiden Fällen startet ein Experiment-Run in der Azure Cloud. Dieser Run führt das Trainingsskript aus, welches sich die notwendigen Daten (Blogposts) und das vortrainierte Modell (mt5) aus den Datastores lädt. Nach dem Finetuning wird dann das neue Modell wieder im Datastore gespeichert.
Abbildung 3: Das Training startete mit dem Experiment Run mithilfe lokal erstellter Jupyter-Notebooks
Um die Schritte, die den Blog-Summarizer erzeugen, harmonisch in den Kreislauf von DevOps einzubetten, war insgesamt ein größerer Initialaufwand notwendig. Die erzielten Ergebnisse würden nun allerdings erlauben, auch andere Machine Learning-Modelle einfach zu implementieren. Hierfür müssen jedoch die Trainingsskripte angepasst werden, ohne dabei die sonstige Architektur zu verändern. Das würde sogar einen vollautomatisierten Kreislauf denkbar machen. Der Blog-Summarizer kann dieses Szenario allerdings nicht darstellen. Die automatische Evaluierung des Modells ist bislang nicht gelöst und verhindert somit, zuverlässig über die Qualität des Modells zu entscheiden.
Evaluate in Azure ML – Wie gut fasst die KI zusammen?
Die Zusammenfassungen, die das Modell in den ersten Durchgängen ausspuckte, hatten qualitativ noch Defizite. Die KI sollte lange Dokumente in kürzere, flüssige und von Menschen lesbare Texte verwandeln und gleichzeitig auch noch die Kernaussagen des Artikels auf den Punkt bringen. Ganz schön hohe Anforderungen für eine KI. Um zu evaluieren, wie gut sie das bereits umsetzt, zog das Team vier Kriterien heran: Textkohärenz, Konsistenz, Schreibfluss und Relevanz. Für jede dieser vier Kriterien wählten die Expert:innen eine Metrik aus, um den Output des Modell mit Hilfe eines Score-Wertes zu beurteilen. Die Metriken liefern Anhaltspunkte zur Güte der Zusammenfassung. Jedoch wird schnell deutlich, dass der Score nicht immer mit dem Eindruck eines menschlichen Lesers übereinstimmt.
Aktuell liegt der Ball also weiterhin beim Entwickler-Team. Sie arbeiten nun daran, die Qualität der Zusammenfassungen Schritt für Schritt weiter anzuheben. Das Ziel ist, das Modell automatisch durch frisch veröffentlichte Blogbeiträge zu trainieren und aus der wachsenden Datenmenge eine bessere Modellperformance zu erzeugen. Schlägt das Training an, dann wird die KI die Arbeit im Redaktionsteam demnächst effizient begleiten können.
Fazit: Azure MLOps ist möglich, aber umständlich
Insgesamt bietet Azure ML Studio eine einfache Umgebung für Notebooks, wovon das Team im Innolab profitierte. Allerdings war die Integration in Azure DevOps deutlich umständlicher. Azure DevOps fokussiert sich auf automatisierte und regelmäßige Deployments von allgemeiner Software. In diesem Fall ist die Software allerdings ein ML-Modell und dessen Trainingspipeline, womit Azure DevOps nicht out-of-the-box funktioniert. Das Experiment-Tracking in Azure ML Studio wiederum war schnell nutzbar.
Skripte, die aus Notebooks heraus starten, erschweren das Training und die Modellierung und erfordern temporäre Speicherorte für Datensatz oder Modelle. Der Support von Azure selbst ist zudem umständlich und langsam. Eine Erhöhung von Quotas – also die Begrenzung von Ressourcen – ist aktuell nicht möglich, eine Übertragung scheiterte am kryptischen Mail-Support.
Schlussendlich sind die Herangehensweisen in der Azure Umgebung von DevOps und Data Scientists unterschiedlich, wodurch auch die Unterstützung zwischen den jeweiligen Tools nur bedingt vorhanden ist. Die Formel „Azure DevOps + Azure ML Studio = Azure MLOps“ geht aus den gesammelten Erfahrungen nicht hundertprozentig hervor. Jedoch ist über Umwege möglich, eine ähnliche Struktur aufzusetzen. Um es als einen out-of-the-box MLOps-Liefcycle zu beschreiben, sind die Umwege aber noch zu lang.