MLOps Teil 2: Prinzipien einhalten mit dem CRISP-ML(Q)-Prozess

Wie kann ein Projekt getreu den Prinzipien von MLOps umgesetzt werden? Wir schauen uns das genauer an.

Was MLOps sind und welche drei Phasen man unterscheidet haben wir bereits hier beschrieben: Blogpost „MLOps Teil 1: Deployment Gaps vermeiden – wie Machine Learning auch wirklich zum Einsatz kommt“.

In diesem Blogbeitrag beschäftigen wir uns mit dem CRISP-ML(Q)-Prozess (Cross-Industry Standard Process for the development of Machine Learning applications with Quality assurance methodology). Dieser definiert die drei MLOps-Phasen genauer und stellt dabei sicher, dass Ziele formuliert und eingehalten werden.

Phasen des CRISP-ML(Q)-Prozesses

Der CRISP-ML(Q)-Prozess besteht insgesamt aus sechs Phasen:

1. Business & Data Understanding (Designen)
2. Data Engineering & Preparation (Modellieren)
3. Machine Learning Model Engineering (Modellieren)
4. Qualitätssicherung für Machine Learning Algorithmen (Modellieren)
5. Deployment (Operationalisieren)
6. Monitoring und Maintenance (Operationalisieren)

Bevor wir uns die einzelnen Phasen des CRISP-ML(Q)-Prozesses ansehen, ist es relevant zu wissen, dass Machine Learning-Projekte ein hohes Risiko des Scheiterns in sich tragen. Wichtig ist dabei der „Fail Fast Fail Cheap“-Ansatz.  Es muss also unbedingt sichergestellt werden, dass ausgearbeitete Ideen schnell  vertestet werden können, um zu merken, wann es nicht möglich ist, ein Projekt umzusetzen, bzw. wo es nötig ist, weitere Vorarbeit zu leisten. Beispielsweise kann erkannt werden, dass aktuell zu wenige Daten vorhanden sind oder die Daten nicht sauber genug bereitgestellt werden können. Auch bei zu geringem Impact auf das Business müssen Projekte frühzeitig beendet und die nächste Idee angegangen werden. Um das zu gewährleisten, wird in jeder Phase des CRISP-ML(Q)-Prozesses eine Risikobewertung vorgenommen. Dabei gibt es drei mögliche Ergebnisse:

1. Risiken sind zu hoch, Projekt wird beendet oder zurückgestellt
2. Risiken sind zu hoch, um die nächste Phase anzugehen. Phase wird weitergeführt und Risiken werden minimiert
3. Risiken sind akzeptabel, Projekt geht in die nächste Phase

Für die Bewertung der Risiken nach den Prinzipien von MLOps  ist es essentiell, beim Einstieg in eine Phase genau festzulegen, was die Erwartungen bzw. Ziele (Genauigkeit des Algorithmus, Einsparpotenzial, Automatisierungsgrad usw.) und die Einschränkungen (Budget, Skillset, Usability, Erklärbarkeit der Modelle usw.) sind. Hierzu müssen messbare Ziele definiert werden, welche im Prozess der Risikobewertung überprüft werden können.

Erst mit dem Erreichen der Ziele wird die nächste Phase im CRISP-ML(Q)-Prozess angegangen. Dabei startet, nach erfolgreicher Ideation bzw. Use Case-Identifizierung, jedes Machine Learning Projekt mit dem „Business und Data Understanding“.

Phase 1: Business und Data Understanding

Das Business und Data Understanding ist darauf ausgelegt, die Machbarkeit des Projektes zu beweisen und die Grundlage für die spätere Modellierung des Problems zu ermöglichen. Dafür müssen messbare Ziele in ihren verschiedenen Ausprägungen definiert werden.  Möglich sind sowohl ökonomische als auch Business-Ziele, die anschließend in Erfolgskriterien für die Machine Learning-Algorithmen überführt werden. Diese Ziele sollten so genau wie möglich definiert und gemeinsam mit dem jeweiligen Fachbereich erarbeitet worden sein.

Der Einbezug des Fachbereichs ist hier entscheidend, um die Akzeptanz des Projektes und den richtigen Scope zu gewährleisten. Auch die Expertise der Fachexperten ist wichtig, um alle einflussreichen Datenquellen für das Projekt zu identifizieren. Um diese Phase abzuschließen, muss ein Prototyp des Projektes erstellt und die Machbarkeit evaluiert werden. Der Aufwand und der Zeithorizont sollten dafür im Verhältnis zum möglichen Return des Vorhabens stehen.

Für das Prototyping wird normalerweise mit einer kleinen Teilmenge der vorhandenen Daten gearbeitet. Daher sind die Anforderungen an die Infrastruktur des Projektes hier noch sehr klein. Genügt der Prototyp den definierten Anforderungen, kann die nächste Phase angegangen werden.

Phase 2: Data Engineering & Preparation

Ist ein Prototyp erstellt und die Machbarkeit nachgewiesen, geht es in die Umsetzung. Wie bei jeder Phase werden auch hier zunächst Ziele definiert. In diesem Fall könnten messbare Ziele auf die Verfügbarkeit der Daten, die Sauberkeit der Daten, die Updateintervalle der Daten oder die Stabilität der Datenpipeline abzielen. Muss im späteren Betrieb des Machine Learning-Modells die Vorhersage auch mit Daten aus der Datenpipeline angereichert werden, sind auch Latenzüberlegungen zu berücksichtigen. Latenz beschreibt dabei die Geschwindigkeit, mit der die Daten zur Laufzeit der Vorhersage abgefragt werden können.

Wurden die Ziele der Phase definiert, müssen hierfür alle relevanten vorhandenen Datenquellen für die Analyse nutzbar gemacht werden. Für weitere Daten, welche noch nicht im Unternehmen vorhanden sind, ist auch die Erstellung von neuen Pipelines nötig. Wie die Aufbereitung und die Speicherlösung der Daten genau ausgestaltet wird, hängt von verschiedenen Faktoren und den Gegebenheiten bzw. dem datentechnischen Reifegrad des Unternehmens ab. Existiert ein Data Warehouse, welches auf analytische Workflows ausgelegt ist? Gibt es eventuell schon einen Featurestore, welcher die Nutzbarkeit von Variablen über mehrere ML-Projekte vereinfacht? Reden wir von Daten, die in einem Stream ankommen, wie beispielsweise Sensordaten von Maschinen? Oder sind es eher statische Daten, welche in einem regelmäßigen Rhythmus in die Speicherlösung geschrieben werden? Haben die Daten ein Format welches sich in einer relationalen Datenbank abbilden lässt oder wird eher eine FileStorage-Lösung wie in einem Data Lake benötigt? Das sind nur einige Fragen, die sich Data Engineers stellen müssen, um eine geeignete Datenpipeline zu erstellen.

Wichtig für die spätere Analyse ist auch eine Versionierung der Daten, damit bei Experimenten zur Erstellung von ML-Algorithmen genau beschrieben werden kann, welche Trainingsdaten genutzt wurden. Das macht einen umfassenderen Vergleich zwischen verschiedenen Modellen mit unterschiedlichen Features möglich.

Die definierten Ziele werden durchgängig evaluiert. Bei Erreichung der Mindestanforderungen geht es in die nächste Phase über, der Modellierung. Dieser Übergang erfolgt fließend mit wechselseitigen Beeinflussungen von Data Engineering und Preparation und Modellierung und Qualitätssicherung der Modelle.

Zoomt man für einen Moment wieder aus dem einzelnen Projekt heraus, ist es sehr wichtig, dass Datenpipelines bzw. Datentöpfe nicht einzeln pro Projekt wieder neu erstellt werden müssen. Ein Datenkatalog zur unternehmensweiten Regelung von Datentöpfe und Zuständigkeiten oder optimalerweise ein Featurestore, welcher ähnlich zum Datenkatalog noch einige zusätzliche Funktionen besitzt, die speziell auf die Anforderungen von Machine Learning beruhen, beschleunigen die Produktivität und die Entwicklungszyklen von Data Engineers und Data Scientisten enorm.

Phase 3: Machine Learning Model Engineering

In der Phase des Modellierens werden verschiedenste Experimente durchgeführt und getrackt. Auch hier werden wieder Ziele definiert bezüglich der Anforderungen und Grenzen, die an den Algorithmus gestellt werden müssen. Hat man seine Arbeit aber richtig gemacht, mappen diese Ziele sehr stark mit denen aus dem Business Understanding, sodass diese nur noch geschärft oder bei neuen Informationen upgedated werden müssen. Dabei stellen sich häufig die gleichen Fragen, welche wieder in messbare Ziele umformuliert werden müssen. Will man mehr Genauigkeit in den Vorhersagen und gibt dafür die Erklärbarkeit auf? Ist der Algorithmus fair und sicher oder werden soziale Ungerechtigkeiten in den Daten einfach auf den Algorithmus übertragen? Welche Genauigkeit ist gut genug? Wie schnell muss eine Vorhersage bereitgestellt werden?

Alle Metriken, die sich aus diesen Fragestellungen und der Problemstellung ableiten, müssen bei Experimenten überprüft werden. Es sollte dabei möglich sein, jedes einzelne Experiment mit den Metriken und Metadaten, wie versionierte Daten und versionierten Code, zu tracken. Das schafft die Basis für die Analyse zwischen verschiedenen Algorithmen, unterschiedlichen Features und unterschiedlichen Datensätzen.

Ein MLOps Tracking Tool macht die Verbesserung der Metriken über die Zeit und Experimente hinweg ersichtlich und zeigt außerdem auf, weshalb eine Verbesserung erzielt wurde und wo gemäß der Prinzipien von MLOps noch  Potentiale im Projekt liegen.

Das grundlegende Handwerkszeug eines ML-Entwicklers ist natürlich auch noch gefragt: Preprocessing für die Anpassung auf den jeweiligen Algorithmus, sinnvolles Trennen in Train, Test und Validation Set für die Messung der Performance in einem realen Szenario und Grid Search von Hyperparametern mit geeigneter Cross-Validation.

Für jedes Experiment muss auch ein Modell in einem später nutzbaren Format gespeichert werden. Auch dafür eignet sich ein MLOps Tracking Tool mit Model Registry hervorragend. Eine Model Registry ist eine einfache Möglichkeit, Modelle zu speichern und zu laden, meistens auf Basis von Cloud-Speichersystemen, wie Azure Blob Storage. Wurden die ersten Modelle erstellt und sind die Mindestanforderungen und Grenzen des Algorithmus eingehalten, geht es in die erste Phase der Evaluation des Modells. Modellieren und Evaluieren ist ein iterativer Zyklus, der mit dem Erreichen der Ziele aus beiden Phasen endet.

Phase 4: Qualitätssicherung für Machine Learning-Algorithmen

Die Qualitätssicherung ist gemäß den Prinzipien von MLOps der letzte Check vor dem produktiven Einsatz des Modells. Hier werden alle Qualitätsziele für den Algorithmus, die in den vorherigen Phasen definiert wurden, überprüft. Bei Nichteinhalten der Qualitätsziele werden mögliche Verbesserungspotenziale aufgedeckt und es findet eine weitere Iteration des Modellierens statt. Eine saubere Vorarbeit ist entscheidend, damit alle Informationen für eine Entscheidungsfindung vorhanden sind.

Der Overhead, den MLOps mit sich bringt, zahlt sich nun aus. Wir haben die Wirtschaftlichkeit in Phase 1 überprüft und Business-Ziele festgelegt. Wir wissen, dass wir mit sauberen Daten gearbeitet haben, durch das erfolgreiche Abschließen der Phase 2. Dank des Trackings jedes einzelnen Experiments in Phase 3 kennen wir die beste Kombination an Features und Algorithmen und die Metriken, welche wir nun mit den Business Zielen abgleichen können.

Mit all den vorhanden Informationen ist jetzt eine fundierte Entscheidung zur Produktivsetzung des Algorithmus möglich. Bei Einhaltung aller Ziele kann die produktive Phase des Projektes beginnen.

Phase 5: Deployment

Ziel des Deployments ist es, das Machine Learning-Modell für eine Applikation bereitzustellen. Unabhängig von der Art, wie das Modell angesprochen werden soll (API, Stream oder Batchprozess), werden für das Deployment CI/CD-Pipelines erstellt, welche eine kontinuierliche stabile Bereitstellung der Modelle sicherstellt und testet. Die Integration der Modelle erfolgt dabei über die oben genannte Model Registry, in der die fertig trainierten Modelle für den produktiven Einsatz abgelegt sind. Der Anwendungscode für die Vorhersage ist über diese Methode einfach zu entwickeln und wiederzuverwenden.

Im Unterschied zur klassischen Softwareentwicklung, ist die abnehmende Aktualität der Modelle zu berücksichtigen. Eine Bereitstellung kann also erfolgen, ohne dass sich der Anwendungscode geändert hat, indem eine neue Version des Algorithmus trainiert wurde. Das Deployment ist nach den Prinzipien von MLOps  erfolgreich, wenn das fertig trainierte Modell ohne Fehler in der Anwendung nutzbar ist.

Phase 6: Monitoring und Maintenance

Die letzte Phase einer Iteration des CRISP-ML(Q)-Prozesses ist die Phase des Monitorings und der Maintenance. Risiken, die nach der Bereitstellung des ML-Algorithmus auftreten, werden beobachtet, mit dem Ziel frühzeitig eingreifen und Anpassungen vorzunehmen zu können. Das größte Risiko liegt dabei in der Verschlechterung der Performance des Modelles über die Zeit hinweg. Jedes Modell, welches eine volatile, sich über die Zeit verändernde Datengrundlage besitzt, wird ungenaue, je länger es produktiv im Einsatz ist. Es muss daher mit neueren Datenpunkten gefüttert werden. Monitoring hilft dabei, zu sehen, wie ein Modell in der Praxis performt und dabei den richtigen Zeitpunkt eines nötigen Trainingslaufs zu erkennen. Ein sauberes Logging der Eingangsdaten und der Vorhersage ist entscheidend für die Messung der Performance. Ein Dashboard mit eingebauten Grenzwerten und Benachrichtigungen dient dazu, zeitnah auf Veränderungen in der Performance zu reagieren. Dazu müssen Metriken im Verlauf der Zeit gemessen und mit dem ursprünglichen Modell verglichen werden. Fällt eine dieser Metriken ab, ist es an der Zeit, neu zu trainieren.

Damit haben wir einen kompletten Zyklus im CRISP-ML(Q) durchlaufen. Jetzt beginnt die kontinuierliche Verbesserung aller Phasen. Durch das strikte Einhalten der Prinzipien von MLOps werden Iterationen effizienter und damit wirtschaftlicher. Auch Skaleneffekte, beispielsweise mit einem Featurestore, sind mit einer guten Infrastruktur über Projekte hinweg zu erzielen.

Fazit zum CRISP-ML(Q)-Prozess nach den Prinzipen von MLOps

Im ersten Blogpost haben wir uns allgemein damit beschäftigt, was MLOps sind und was wir damit vermeiden wollen, nämlich Deployment Gaps. In Teil zwei haben wir ein Vorgehensmodell kennenglernt, welches uns richtig eingesetzt erlaubt, MLOps als Standardwerkzeug in jedem Projekt zu integrieren.

Durch den CRISP-ML(Q)-Prozess werden Chancen erkannt und in einem strukturierten Prozess in Mehrwert überführt. Risiken werden durch die Einhaltung der in jeder Phase zu definierenden Qualitätsziele minimiert. Die Verbindung einer guten MLOps-Infrastruktur mit der Umsetzung der Projekte nach CRISP-ML(Q) reduziert daher die Deployment Gap deutlich. Dieser Effekt steigert sich außerdem dank Lern- und Skaleneffekte im Verlauf der Zeit.