Die Entwicklung von Produkten mit maschinellem Lernen oder ML-gestützten Produktfunktionen umfasst zwei unterschiedliche Disziplinen:
- Modellentwicklung: Data Scientists – hochqualifiziert in Statistik, linearer Algebra und Kalkül – trainieren, bewerten und wählen das leistungsfähigste statistische oder neuronale Netzwerkmodell aus.
- Modell-Bereitstellung: Entwickler – hochqualifiziert in Softwaredesign und ‑technik – erstellen ein robustes Softwaresystem, stellen es in der Cloud bereit und skalieren es, um eine große Anzahl gleichzeitiger Modellinferenzanfragen zu bedienen.
Das ist natürlich eine grobe Vereinfachung. Für die Entwicklung nützlicher und erfolgreicher ML-gestützter Produkte sind mehrere andere wichtige Fachkenntnisse erforderlich:
- Datentechnik: Aufbau von Datenpipelines zum Sammeln von Daten aus unterschiedlichen Quellen, Aufbereitung und Umwandlung dieser Daten in homogene, saubere Daten, die sicher für das Training von Modellen verwendet werden können.
- Produktdesign: Verstehen der geschäftlichen Anforderungen, Identifizieren von wichtigen Zielen und relevanten Geschäftsmatrizen; Definieren von Produktfunktionen oder User Stories für diese Ziele, Erkennen der zugrundeliegenden Probleme, die mit ML besser gelöst werden können; Entwerfen von Benutzererfahrungen, um nicht nur die ML-Modellvorhersage nahtlos mit den übrigen Produktfunktionen zu nutzen, sondern auch (Re-)Aktionen der Benutzer als implizite Bewertung der Modellergebnisse zu sammeln und zur Verbesserung der Modelle zu nutzen.
- Sicherheitsanalyse: Sicherstellen, dass das Softwaresystem, die Daten und das Modell sicher sind und dass keine personenbezogenen Daten durch die Kombination von Modellergebnissen und anderen öffentlich zugänglichen Informationen oder Daten offengelegt werden.
- KI-Ethik: Stellen Sie sicher, dass alle geltenden Gesetze eingehalten werden, und fügen Sie Maßnahmen zum Schutz vor jeglicher Art von Voreingenommenheit hinzu (z. B. Begrenzung des Umfangs des Modells, zusätzliche menschliche Aufsicht usw.).
Da immer mehr Modelle in der Produktion eingesetzt werden, hat die Bedeutung von MLOps natürlich zugenommen. Der Schwerpunkt liegt zunehmend auf der nahtlosen Gestaltung und Funktion von ML-Modellen innerhalb des Gesamtprodukts. Die Entwicklung von Modellen kann nicht in einem Silo erfolgen, da dies Auswirkungen auf das Produkt und das Unternehmen haben kann.
Wir brauchen einen ML-Lebenszyklus, der auf die Realitäten von ML-gestützten Produkten und MLOps abgestimmt ist. Er sollte die Sichtbarkeit für alle Beteiligten erleichtern, ohne zu viele Änderungen in den bestehenden Arbeitsabläufen der Datenwissenschaftler und Ingenieure zu verursachen.
Im weiteren Verlauf des Artikels gebe ich zunächst einen Überblick über die typischen Modellentwicklungs- und Softwareentwicklungs-Workflows und zeige dann auf, wie beide zusammengeführt werden können, um sich an die Anforderungen der Erstellung ML-gestützter Produkte in der MLOps-Ära anzupassen.
Lebenszyklus der Modellentwicklung
Lassen wir die Online-Bereitstellung von Modellen in der Produktion für einen Moment beiseite. Data Scientists entwickeln seit über einem Jahrzehnt statistische Modelle und Modelle mit neuronalen Netzen. Häufig wurden diese Modelle offline (d. h. manuell) für prädiktive Analysen verwendet.
Die Modellentwicklung besteht aus zwei Gruppen von Aktivitäten: Datenvorbereitung und Modelltraining. Sie beginnt mit der Formulierung eines ML-Problems und endet mit der Modellauswertung.
Formulieren
Data Scientists übersetzen ein Unternehmensziel in ein Problem des maschinellen Lernens. Es gibt mehrere Faktoren, die Sie berücksichtigen müssen:
- Geschäftsziel: Beschränken Sie sich auf eine kleine Gruppe von ML-Problemen, die dem Unternehmensziel dienen können.
- Kosten von Fehlern: Kein ML-Modell kann zu 100 % genau sein. Wie hoch sind die Kosten für falsch-positive und falsch-negative Ergebnisse? Wenn beispielsweise ein Bildklassifizierungsmodell bei einer gesunden Person fälschlicherweise Brustkrebs vorhersagt, wird dies durch weitere Tests korrigiert. Wenn das Modell jedoch den Krebs bei einem Patienten nicht diagnostiziert, kann dies aufgrund der späten Erkennung tödlich sein.
- Datenverfügbarkeit: Es mag Sie überraschen, aber Sie können mit keinen Daten beginnen und Ihre Datenerhebung mit einem Bootstrap durchführen. Je umfangreicher die Daten sind, desto mehr Arten von Modellen sind denkbar. Wenn Sie beispielsweise eine Anomalieerkennung ohne markierte Daten durchführen möchten, können Sie mit verschiedenen Arten von unüberwachten Clustering-Algorithmen beginnen und Punkte, die sich in keinem Cluster befinden, als Anomalien markieren. Wenn Sie jedoch Benutzerreaktionen auf Ihr Modell sammeln, erhalten Sie einen markierten Datensatz. Dann möchten Sie vielleicht ausprobieren, ob ein überwachtes Klassifizierungsmodell besser funktioniert.
- Bewertungsmetriken: Je nach Problemstellung sollten Sie auch eine Metrik für die Modellleistung festlegen, die Sie optimieren möchten und die mit der Geschäftsmetrik für Ihr Geschäftsziel übereinstimmen sollte.
Sammeln
Sammeln Sie die erforderlichen Daten aus internen Anwendungen sowie aus externen Quellen. Dies kann durch Scrapen des Webs, Erfassen von Ereignisströmen aus Ihrer mobilen Anwendung oder Ihrem Webservice, Change Data Capture (CDC)-Streams aus operativen (OLTP-)Datenbanken, Anwendungsprotokollen usw. geschehen. Sie können alle benötigten Daten in Ihre Datenpipeline einspeisen, die von Data Engineers entwickelt und gepflegt wird.
Kuratieren
Die gesammelten Daten sind fast nie unversehrt. Sie müssen bereinigt, Duplikate entfernt, fehlende Werte ergänzt und in einem Data Warehouse oder einem Data Lake gespeichert werden. Wenn die Daten für das Training eines überwachten ML-Modells bestimmt sind, müssen Sie sie auch beschriften. Außerdem müssen Sie die Daten katalogisieren, damit sie leicht gefunden und richtig verstanden werden können. Versuchen Sie, so viel wie möglich zu automatisieren, aber es wird auch Teile geben, die manuell erledigt werden müssen (insbesondere die Beschriftung).
Umwandlung
Sobald die Daten bereinigt sind, können Sie sie so umwandeln, dass sie für die Analyse und ML-Modellierung geeignet sind. Dazu kann es erforderlich sein, die Struktur zu ändern, sie mit anderen Tabellen zu verbinden, sie entlang wichtiger Dimensionen zu aggregieren oder zusammenzufassen, zusätzliche Merkmale zu berechnen usw. Data Engineers sollten all dies in der Datenpipeline automatisieren.
Validieren
Implementieren Sie Qualitätsprüfungen, führen Sie Protokolle über statistische Verteilungen im Zeitverlauf und erstellen Sie Auslöser, die eine Warnung auslösen, wenn eine der Prüfungen fehlschlägt oder die Verteilung über die erwarteten Grenzen hinausgeht. Data Engineers implementieren in Absprache mit Data Scientists diese Validierungen in der Datenpipeline.
Erforschen
Data Scientists führen explorative Datenanalysen (EDA) durch, um die Beziehungen zwischen verschiedenen Merkmalen und dem Zielwert, den das Modell vorhersagen soll, zu verstehen. Sie führen auch Feature Engineering durch, was wahrscheinlich dazu führt, dass weitere Umwandlungs- und Validierungsprüfungen hinzugefügt werden (die beiden vorherigen Phasen).
Trainieren
Data Scientists trainieren mehrere Modi, führen Experimente durch, vergleichen die Modellleistung, stimmen Hyperparameter ab und wählen einige Modelle mit der besten Leistung aus.
Auswerten
Bewerten Sie die Modelleigenschaften anhand von Geschäftszielen und ‑kennzahlen. Einige Rückmeldungen können sogar dazu führen, dass das ML-Problem anders formuliert wird und der gesamte Prozess noch einmal wiederholt wird.
Diese Data-ML-Endlosschleife ist nicht linear. Nicht in jeder Phase geht man zur nächsten Phase über. Wenn man Probleme entdeckt, kehrt man zur entsprechenden vorherigen Stufe zurück, um sie zu lösen. Es gibt also implizite Übergänge von jeder Phase zu früheren Phasen.
Es ist ähnlich wie bei der DevOps-Schleife, der Entwickler folgen. Nicht jeder Code, der die Testphase durchläuft, wird zur Freigabe weitergeleitet. Wenn die Tests fehlschlagen, geht es zurück in die Code- (manchmal sogar in die Planungs-) Phase, um die Probleme zu beheben.
Lebenszyklus der Softwareentwicklung
Die DevOps-Endlosschleife ist der De-facto-Standard für den Softwareentwicklungslebenszyklus zur schnellen Erstellung und Bereitstellung von Softwareanwendungen und ‑diensten in der Cloud.
Er besteht aus zwei Gruppen von Aktivitäten: Entwurf und Entwicklung eines Softwaresystems sowie Bereitstellung und Überwachung von Softwarediensten und ‑anwendungen.
Planen
Dies ist die erste Phase für jedes Produkt oder Produktmerkmal. Sie erörtern die Geschäftsziele und die wichtigsten Geschäftskennzahlen sowie die Produktfunktionen, die zur Erreichung dieser Ziele beitragen können. Sie gehen den Problemen der Endbenutzer auf den Grund und diskutieren über die User Journeys, um diese Probleme zu lösen und die erforderlichen Daten zu sammeln, um zu beurteilen, wie ein ML-Modell in der realen Welt funktioniert.
Codieren
Entwerfen und entwickeln Sie die Software, das End-to-End-Produkt oder die Anwendung, und nicht nur ML-Modelle. Legen Sie Verträge und APIs fest, die der Anwendungscode verwendet, um die Modellinferenz aufzurufen und ihre Ergebnisse zu nutzen, und auch, welche Benutzerreaktionen und Rückmeldungen gesammelt werden sollen.
Es ist sehr wichtig, dass sich Entwickler, Dateningenieure und Datenwissenschaftler hier auf die gleiche Seite stellen. So lassen sich später böse Überraschungen vermeiden.
Erstellen
In dieser Phase wird die kontinuierliche Integration verschiedener Teile vorangetrieben, während sie sich weiterentwickeln und in eine Form verpackt werden, die veröffentlicht werden kann. Dabei kann es sich um eine Bibliothek oder ein SDK, ein Docker-Image oder ein Anwendungs-Binary (z. B. apk für Android-Apps) handeln.
Testen
Unit-Tests, Integrationstests, Abdeckungstests, Leistungstests, Lasttests, Datenschutztests, Sicherheitstests und Bias-Tests. Denken Sie an alle Arten von Software- und ML-Tests, die hier anwendbar sind, und automatisieren Sie sie so weit wie möglich.
Die Tests werden in einer Staging-Umgebung durchgeführt, die der angestrebten Produktionsumgebung ähnelt, aber nicht für einen ähnlichen Umfang ausgelegt ist. Sie kann Dummy‑, künstliche oder anonymisierte Daten enthalten, um das Softwaresystem durchgängig zu testen.
Freigeben
Sobald alle automatisierten Tests bestanden sind und in einigen Fällen die Testergebnisse manuell überprüft wurden, werden der Softwarecode oder die Modelle zur Freigabe freigegeben. Genau wie der Code sollten auch die Modelle versioniert und die notwendigen Metadaten automatisch erfasst werden. So wie die Docker-Images in einem Docker-Repo versioniert werden, sollte auch das Modell in einem Modell-Repo persistiert werden.
Wenn Modelle zusammen mit dem Code für den Microservice, der das Modell bedient, verpackt werden, dann enthält das Docker-Image auch das Modell-Image. An dieser Stelle endet die kontinuierliche Integration und das kontinuierliche Deployment beginnt.
Bereitstellen
Auswahl der freigegebenen Artefakte aus dem Docker-Repository oder Modellspeicher und Bereitstellung in der Produktionsinfrastruktur. Je nach Ihrem Bedarf können Sie Infrastructure as a Service (IaaS), Container as a Service (CaaS) oder Platform as a Service (PaaS) wählen.
Sie können auch TensorFlow Serve, PyTorch Serve oder Dienste wie SageMaker und Vertex AI für die Bereitstellung Ihrer Modelldienste verwenden.
Betreiben
Sobald die Dienste bereitgestellt sind, können Sie beschließen, zunächst einen kleinen Prozentsatz des Datenverkehrs zu senden. Canary Deployment ist eine gängige Taktik, um in Phasen zu aktualisieren (z. B. 2%, 5%, 10%, 25%, 75%, 100%). Im Falle eines Problems, unerwarteten Verhaltens oder eines Rückgangs der Metriken können Sie die Bereitstellung zurücknehmen.
Sobald das Tor für 100 % Datenverkehr geöffnet ist, sollte Ihre Bereitstellungsinfrastruktur den alten Dienst nach und nach abschalten. Außerdem sollte sie sich an die Lastspitzen und ‑abfälle anpassen. Kubernetes und KubeFlow sind gängige Tools für diesen Zweck.
Überwachen
In dieser letzten Phase überwachen Sie ständig den Zustand der Dienste, Fehler, Latenzen, Modellvorhersagen, Ausreißer und die Verteilung der Eingabemodellmerkmale usw. Falls ein Problem auftritt, können Sie je nach Schweregrad und Diagnose das System auf eine ältere Version zurücksetzen, einen Hotfix veröffentlichen, ein erneutes Modelltraining anstoßen oder was auch immer sonst erforderlich ist.
MLOps-Lebenszyklus
Derzeit ist es üblich, dass Datenwissenschaftler ein Modell entwickeln und es dann den Entwicklern und ML-Ingenieuren zur Integration in das übrige System und zum Einsatz in der Produktion „überlassen“.
Die ML- und Entwicklungssilos und die fragmentierten Eigentumsverhältnisse sind einer der häufigsten Gründe für das Scheitern vieler ML-Projekte. Die Vereinheitlichung der Lebenszyklen von Modell und Softwareentwicklung verschafft allen Beteiligten die dringend benötigte Transparenz.
Der Planungsschritt ist der Startpunkt
Die Produktplanung kommt vor allem anderen. Bei der Definition von Geschäftszielen und der Gestaltung von Benutzererfahrungen sollte nicht nur die Produktfunktionalität berücksichtigt werden, sondern auch, wie die Modellergebnisse und die Erfassung der Benutzerreaktionen in das Produktionsdesign integriert werden.
Anders als bei herkömmlicher Software, bei der mit der Zeit immer mehr Daten gesammelt werden, muss die Benutzererfahrung der ML-Aspekte eines Produkts möglicherweise aktualisiert werden, um davon zu profitieren, auch wenn es keine „neue Funktionalität“ gibt.
Bauen Sie das Produkt zunächst ohne ML
Oftmals baue ich eine End-to-End-Anwendung zunächst mit einer regelbasierten Heuristik oder einem Dummy-Modell auf und schließe die Daten-ML-Schleife komplett ab. Dies dient als Basismodell und ist bei der Datenerfassung nützlich. Es gibt den Datenwissenschaftlern auch einen Kontext, indem es zeigt, wie das Modell im Produkt verwendet wird.
Unterschiedliche Kadenz für Modell- und Softwareentwicklung
Die Entwicklung eines ML-Modells unterscheidet sich deutlich von der Entwicklung von Software. Softwaresysteme können inkrementell entwickelt werden (wobei einige Teile nicht funktionieren). Anders als Softwareteile können ML-Modelle nicht in eine feine Granularität zerlegt werden.
Ein einziger Lebenszyklus schließt nicht aus, dass sich die Räder von Data, ML, Dev und Ops mit unterschiedlicher Geschwindigkeit drehen. In der Tat geschieht dies bereits bei DevOps. Bei einigen Teams führt nicht jeder Entwicklungssprint zur Bereitstellung einer neuen Version. Andererseits gibt es Teams, die stündlich neue Versionen bereitstellen, d. h. Hunderte von Malen in einem einzigen Sprint. Jedes Rad soll sich mit seiner eigenen optimalen Geschwindigkeit drehen.
Konsolidierte Eigenverantwortung, frühe Integration, häufige Iteration
Dies sind meine 3 Konzepte zur Verbesserung der Erfolgsquote bei der Entwicklung und dem Einsatz von ML-gestützten Produkten:
- Konsolidierte Verantwortlichkeit: Ein funktionsübergreifendes Team ist für das gesamte Projekt verantwortlich.
- Frühzeitig einbinden: Implementieren Sie ein einfaches (regelbasiertes oder Dummy-) Modell und entwickeln Sie zunächst eine Produktfunktion von Anfang bis Ende.
- Häufig iterieren: Bessere Modelle erstellen und das einfache Modell ersetzen, überwachen und wiederholen.
Zusammenfassung
Der Lebenszyklus des maschinellen Lernens für die MLOps-Ära bringt die Modellentwicklung und die Softwareentwicklung zu einem unlösbaren Knoten zusammen. Es erleichtert die Sichtbarkeit für alle Beteiligten bei der Entwicklung von ML-gestützten Produkten und Funktionen.
Quelle: medium
Erfahren Sie hier mehr über Lösungen im Bereich Data Management oder besuchen Sie eines unserer kostenlosen Webinare.
