Kommentar von Horst Mundt, Databricks Das ist der Unterschied zwischen modell- und datenzentrierten MLOps

Anbieter zum Thema

Disy Informationssysteme GmbH

Sinequa

Insider Research

Databricks GmbH

Der Einsatz von maschinellem Lernen (ML) in Deutschland nimmt zu. Ein aktueller Bericht von IDG Research Services zeigt, dass zwei Drittel der deutschen Unternehmen ML einsetzen und 86 Prozent der Teilnehmer angaben, dass sie ein eigenes Budget für ML-Projekte haben. 60 Prozent der Unternehmen, die ML zuvor eingesetzt hatten, berichten darüber hinaus, dass sie bereits nach drei Monaten erste Ergebnisse erzielen konnten.

Doch trotz dieser positiven Dynamik ist die Misserfolgsquote bei ML-Projekten hoch. Aus Berichten von Gartner und anderen geht hervor, dass zwischen 85 und 96 Prozent dieser Projekte nie live gehen. Ein aktueller Bericht von Databricks und dem MIT zeigt, dass die Skalierung von ML-Anwendungsfällen für viele Unternehmen äußerst komplex zu sein scheint. Laut 55 Prozent der Befragten ist die größte Herausforderung das Fehlen eines zentralen Ortes zum Speichern und Wiederauffinden von ML-Modellen. Dieses Fehlen sowie der fehleranfällige Austausch zwischen Data-Science- und Betriebsteams und der Mangel an qualifizierten ML-Ressourcen – beides wurde von 39 Prozent der Befragten genannt – deuten auf große Schwierigkeiten bei der Zusammenarbeit zwischen ML-, Daten- und Business-Anwenderteams hin.

Gründe für das Scheitern können zu ehrgeizige Ziele zu Beginn und vor allem unklare Vorstellungen darüber sein, wie die ML-Modelle später genutzt werden sollen. Die Strategie und der Business Case sind die wichtigsten Voraussetzungen zu Beginn eines jeden ML-Modells und -Projekts. Daten sind ebenfalls entscheidend und eine der wichtigsten Komponenten von ML. Die Sprichwörter „Garbage in, Garbage out“ und „80 Prozent der Zeit eines Data Scientists wird mit dem Bereinigen von Daten verbracht“ sind in der Data Science Community wohlbekannt und beziehen sich beide auf Daten im Zusammenhang mit einem erfolgreichen Modelltraining. Wenn die Eingabedaten für das Training von geringer Qualität sind, dann ist auch das Ausgabemodell von geringer Qualität, so einfach ist das. Das Trainieren von Modellen ist jedoch nur ein Teil eines produktiven ML-Systems.

Um den Erfolg zuverlässig zu messen und aufrechtzuerhalten, muss eine Vielzahl von Daten gesammelt werden, um die geschäftlichen und technischen Anforderungen zu erfüllen. Zum Beispiel, wie man mit den betriebswirtschaftlichen KPIs für ein bestimmtes Projekt Schritt halten kann. Es muss festgelegt werden, wer für das Modell verantwortlich ist und wie seine Entwicklung zurückverfolgt werden kann. Das nachstehende Diagramm veranschaulicht einen möglichen Datenfluss in einer fiktiven Webanwendung, die ML verwendet, um Käufern Pflanzen zu empfehlen, sowie die Data-Teammitglieder, die für jede Stufe verantwortlich sind.

Die Quelldaten fließen von der Webanwendung in einen Zwischenspeicher und dann in abgeleitete Tabellen. Diese werden für die Überwachung, die Berichterstattung, das Feature Engineering und das Modelltraining verwendet. Zusätzliche Metadaten über das Modell werden extrahiert, und Protokolle von Tests und Bereitstellung werden für Audits und Compliance gesammelt. Ein Projekt, das nicht in der Lage ist, diese Daten zu verwalten, läuft Gefahr zu scheitern, unabhängig davon, wie gut das ML-Modell selbst in einem bestimmten Schritt funktioniert.

ML-Engineering, MLOps und Modell-Governance

DevOps und Data Governance haben das Risiko von gescheiterten ML-Projekten gesenkt und sind zu eigenständigen Disziplinen geworden. ML-Engineering hat sich ebenfalls zu einer eigenen Disziplin entwickelt. Ihr Ziel ist es, den Betrieb (auch MLOps genannt) und die Governance von ML-Anwendungen zu gewährleisten. Mit diesen Aufgaben sind verschiedene Arten von Risiken verbunden. Erstens das Risiko, das dem System der ML-Anwendungen innewohnt, und zweitens das Risiko der Nichtübereinstimmung mit externen Systemen. Die Infrastruktur der Datenpipeline, die KPIs, die Modellüberwachung und die Dokumentation sollten nicht fehlen, da sonst das System instabil oder ineffektiv wird. Auf der anderen Seite läuft eine gut konzipierte App, die nicht den unternehmensinternen, regulatorischen und ethischen Anforderungen entspricht, Gefahr, Budgetmittel zu verlieren, Bußgelder zu erhalten oder sogar den Ruf des Unternehmens zu schädigen. MLOps und Modell-Governance stecken noch in den Kinderschuhen, und es gibt hierfür noch keine offiziellen Standards oder Definitionen, aber sie stellen gute Ansätze dar, um die oben genannten Risiken mindern.

MLOps ist die aktive Verwaltung eines produktiven Modells und dessen Aufgabe, einschließlich seiner Stabilität und Effektivität. Mit anderen Worten: MLOps befasst sich in erster Linie mit der Aufrechterhaltung der Funktion der ML-Anwendung durch besseres Management von Daten, Modell und Entwicklung. Einfach ausgedrückt: MLOps = ModelOps + DataOps + DevOps.

Model Governance hingegen ist die Kontrolle und Regulierung eines Modells, seiner Aufgabe und seiner Auswirkungen auf die umgebenden Systeme. Sie befasst sich in erster Linie mit den weiterreichenden Folgen der Funktionsweise einer ML-Anwendung in der realen Welt. Um ein System aufzubauen, das die menschlichen Werte berücksichtigt und gleichzeitig funktional ist, braucht man also beides.

Nachdem wir zwischen Betrieb und Governance unterschieden haben, können wir nun untersuchen, welche spezifischen Fähigkeiten zu deren Unterstützung erforderlich sind. Die Erkenntnisse lassen sich in sechs Kategorien einteilen:

1. Datenverarbeitung und -verwaltung

Da die meisten Innovationen im Bereich ML im Open Source-Bereich stattfinden, ist die Unterstützung von strukturierten und unstrukturierten Datentypen mit offenen Formaten und APIs eine Grundvoraussetzung. Das System muss auch Pipelines für KPIs, Modelltraining/Inferenz, Target Drift, Testing und Protokollierung verarbeiten und verwalten. Dabei sollte beachtet werden, dass nicht alle Pipelines Daten auf die gleiche Weise oder mit den gleichen SLAs verarbeiten. Je nach Anwendungsfall kann eine Trainingspipeline GPUs erfordern, eine Überwachungspipeline Streaming und eine Inferenzpipeline Online-Serving mit geringer Latenz. Merkmale müssen zwischen Trainings- (offline) und Serving-Umgebungen (online) konsistent gehalten werden, was viele dazu veranlasst, Feature-Stores als Lösung zu betrachten.

2. Sichere Zusammenarbeit

ML-Engineering in der realen Welt ist ein funktionsübergreifendes Unterfangen – ein gründliches Projektmanagement und eine kontinuierliche Zusammenarbeit zwischen dem Data-Team und den Geschäftsinteressenten sind entscheidend für den Erfolg. Zugriffskontrollen spielen hier eine große Rolle, damit die richtigen Gruppen am selben Ort an Daten, Code und Modellen arbeiten können und gleichzeitig das Risiko menschlicher Fehler oder Fehlverhaltens begrenzt wird.

3. Prüfung

Um sicherzustellen, dass das System den Qualitätserwartungen entspricht, sollten Tests für Code, Daten und Modelle durchgeführt werden. Dazu gehören Unit-Tests für den Pipeline-Code, die Feature Engineering, Training, Serving und Metriken abdecken, sowie End-to-End-Integrationstests. Modelle sollten auf ihre Referenzgenauigkeit über demografische und geografische Segmente hinweg auf die Bedeutung von Merkmalen, auf Verzerrungen, auf Konflikte im Eingabeschema und auf die Effizienz der Berechnung getestet werden. Die Daten sollten auf das Vorhandensein sensibler Informationen und auf Verzerrungen beim Training/Serving sowie auf Validierungsschwellen für Merkmals- und Zieldrift getestet werden. Idealerweise automatisiert, verringern Tests die Wahrscheinlichkeit menschlicher Fehler und helfen bei der Einhaltung der Vorschriften.

4. Überwachung

Eine regelmäßige Überwachung des Systems hilft dabei, Ereignisse zu erkennen und darauf zu reagieren, die ein Risiko für seine Stabilität und Wirksamkeit darstellen. Wie schnell kann entdeckt werden, wenn eine wichtige Pipeline ausfällt, ein Modell veraltet oder eine neue Version ein Speicherleck in der Produktion verursacht? Wann wurden das letzte Mal alle Eingabemerkmalstabellen aktualisiert oder hat jemand versucht, auf eingeschränkte Daten zuzugreifen? Die Antworten auf diese Fragen können eine Mischung aus Live- (Streaming), periodischen (Batch) und ereignisgesteuerten Aktualisierungen erfordern.

5. Reproduzierbarkeit

Dies bezieht sich auf die Fähigkeit, die Ergebnisse eines Modells zu validieren, indem dessen Definition (Code), Eingaben (Daten) und Systemumgebung (Abhängigkeiten) neu erstellt werden. Wenn ein neues Modell eine unerwartet schlechte Leistung zeigt oder eine Verzerrung in Bezug auf ein Bevölkerungssegment aufweist, müssen Unternehmen in der Lage sein, den Code und die Daten, die für die Entwicklung von Merkmalen und die Schulung verwendet wurden, zu überprüfen, eine alternative Version zu reproduzieren und erneut bereitzustellen.

6. Dokumentation

Die Dokumentation einer ML-Anwendung skaliert das betriebliche Wissen, senkt das Risiko technischer Probleme und dient als Bollwerk gegen Compliance-Verstöße. Dazu gehören eine Buchführung und Visualisierung der Systemarchitektur, die Schemata, Parameter und Abhängigkeiten von Eigenschaften, Modellen und Metriken sowie Berichte über jedes Modell in der Produktion und die dazugehörigen Governance-Anforderungen.

Der Bedarf an einer datenzentrierten Machine-Learning-Plattform

Data Science Tools, die aus einem modellzentrierten Ansatz hervorgegangen sind, sind in Bezug auf die einfache unternehmensweite Einführbarkeit, die Integration in die Dateninfrastruktur und die Funktionen für die Zusammenarbeit grundlegend eingeschränkt. Sie bieten erweiterte Modellverwaltungsfunktionen in einer Software, die von kritischen Datenpipelines und Produktionsumgebungen getrennt ist. Diese unzusammenhängende Architektur verlässt sich auf andere Dienste, um die kritischste Komponente der Infrastruktur zu verwalten – die Daten.

Das hat zur Folge, dass Zugriffskontrolle, Tests und Dokumentation für den gesamten Datenfluss über mehrere Plattformen verteilt sind. Eine Trennung an dieser Stelle erscheint willkürlich und erhöht, wie bereits festgestellt wurde, unnötig die Komplexität und das Ausfallrisiko für jede ML-Anwendung. Eine datenzentrierte ML-Plattform, wie z. B. ein Lakehouse, bringt Modelle und Features zusammen mit Daten für Geschäftskennzahlen, Überwachung und Compliance.

Lakehouses sind per Definition datenzentriert und kombinieren die Flexibilität und Skalierbarkeit von Data Lakes mit der Leistungsfähigkeit und den Datenmanagementfähigkeiten eines Data Warehouse. Ihre Open-Source-Natur macht es einfach, ML dort zu integrieren, wo die Daten liegen. Es besteht keine Notwendigkeit, Daten aus einem proprietären System zu exportieren, um ML-Frameworks zu nutzen. Dadurch wird auch die Akzeptanz erheblich erleichtert.

Schlussfolgerung

Ein modellzentrierter Ansatz für ML-Anwendungen kann ungewollt eine große Risikoquelle darstellen. Der Wechsel zu einem datenzentrierten Ansatz zeigt auf, dass dieses Risiko in der Verantwortung der Anwendungsfunktion selbst oder in der Einhaltung externer Vorgaben liegt. MLOps und -Governance sind neu entstehende Disziplinen, die darauf abzielen, Vertrauen in ML-Initiativen zu schaffen und deren Risiken zu verringern, was sie durch eine Reihe grundlegender Fähigkeiten erreichen. Die Zukunft liegt in einer Lakehouse-Architektur, die offen und einfach zu übernehmen ist.

(ID:47618038)