Ihr Unternehmen hat also beschlossen, in maschinelles Lernen zu investieren. Sie haben ein talentiertes Team von Datenwissenschaftlern, die Modelle entwickeln, um wichtige Probleme zu lösen, die noch vor ein paar Jahren unerreichbar waren. Alle Leistungskennzahlen sehen großartig aus, die Demos lassen die Kinnlade herunterklappen und die Führungskräfte fragen, wie schnell Sie ein Modell in Produktion bringen können.
Das sollte ziemlich schnell gehen, denken Sie. Schließlich haben Sie bereits alle fortgeschrittenen wissenschaftlichen und mathematischen Probleme gelöst, sodass nur noch die routinemäßige IT-Arbeit übrig ist. Wie schwer kann das schon sein?
Ziemlich schwer, wie sich herausstellt. Deeplearning.ai berichtet, dass „nur 22 Prozent der Unternehmen, die maschinelles Lernen einsetzen, ein Modell erfolgreich implementiert haben“. Was macht es so schwierig? Und was müssen wir tun, um die Situation zu verbessern?
Beginnen wir damit, die Ursachen zu untersuchen.
Herausforderungen
In der Welt der traditionellen Softwareentwicklung hat eine Reihe von Praktiken, die als DevOps bekannt sind, es möglich gemacht, Software innerhalb von Minuten in die Produktion zu überführen und sie zuverlässig am Laufen zu halten. DevOps stützt sich auf Tools, Automatisierung und Arbeitsabläufe, um die zufällige Komplexität zu beseitigen und es den Entwicklern zu ermöglichen, sich auf die eigentlichen Probleme zu konzentrieren, die gelöst werden müssen. Dieser Ansatz ist so erfolgreich, dass viele Unternehmen ihn bereits beherrschen. Warum können wir also nicht einfach das Gleiche für ML tun?
Der Grund dafür ist, dass es einen grundlegenden Unterschied zwischen ML und herkömmlicher Software gibt: ML besteht nicht nur aus Code, sondern aus Code und Daten. Ein ML-Modell, das Artefakt, das Sie am Ende in der Produktion einsetzen, wird durch die Anwendung eines Algorithmus auf eine Menge von Trainingsdaten erstellt, die das Verhalten des Modells in der Produktion beeinflussen werden. Entscheidend ist, dass das Verhalten des Modells auch von den Eingabedaten abhängt, die es zum Zeitpunkt der Vorhersage erhält und die Sie nicht im Voraus kennen können.
Während der Code sorgfältig in einer kontrollierten Entwicklungsumgebung erstellt wird, stammen die Daten aus der unendlichen Entropiequelle, die als „die reale Welt“ bekannt ist. Sie verändern sich ständig, und man kann nicht kontrollieren, wie sie sich verändern werden. Man kann sich ihre Beziehung so vorstellen, als lebten Code und Daten auf getrennten Ebenen, die sich die Zeitdimension teilen, aber in allen anderen Bereichen unabhängig sind. Die Herausforderung eines ML-Prozesses besteht darin, auf kontrollierte Weise eine Brücke zwischen diesen beiden Ebenen zu schlagen.
Diese grundlegende Trennung führt zu mehreren wichtigen Herausforderungen, die von jedem gelöst werden müssen, der beispielsweise ein ML-Modell erfolgreich in die Produktion bringen will:
- Langsame, spröde und inkonsistente Bereitstellung
- Mangel an Reproduzierbarkeit
- Leistungseinbußen (Verzerrung durch Training)
Da das Wort „Daten“ in diesem Artikel bereits mehrfach verwendet wurde, denken Sie vielleicht an eine andere Disziplin, die uns helfen könnte: Data Engineering. Und Sie hätten Recht: Data Engineering bietet wichtige Werkzeuge und Konzepte, die für die Lösung des Rätsels ML in der Produktion unerlässlich sind. Um das Rätsel zu lösen, müssen wir Praktiken aus DevOps und Data Engineering kombinieren und einige hinzufügen, die einzigartig für ML sind.
ML Ops kann also durch diese Schnittmenge definiert werden:
ML Ops kann also durch diese Schnittmenge definiert werden:
ML Ops ist die Schnittmenge von Machine Learning, DevOps und Data Engineering
Wir könnten ML Ops also wie folgt definieren:
ML Ops ist eine Reihe von Praktiken, die maschinelles Lernen, DevOps und Data Engineering kombinieren und darauf abzielen, ML-Systeme zuverlässig und effizient in der Produktion einzusetzen und zu warten.
Schauen wir uns nun an, was dies im Einzelnen bedeutet, indem wir die einzelnen Praktiken untersuchen, die zur Erreichung der Ziele von ML Ops eingesetzt werden können.
Praktiken
Hybride Teams
Da wir bereits festgestellt haben, dass die Produktion eines ML-Modells eine Reihe von Fähigkeiten erfordert, die bisher als getrennt betrachtet wurden, brauchen wir, um erfolgreich zu sein, ein hybrides Team, das dieses Spektrum von Fähigkeiten zusammen abdeckt. Es ist natürlich möglich, dass eine einzige Person alle diese Fähigkeiten gut genug beherrscht, und in diesem Fall könnten wir diese Person einen vollständigen ML Ops Engineer nennen. Das wahrscheinlichste Szenario ist jedoch, dass ein erfolgreiches Team einen Data Scientist oder ML Engineer, einen DevOps Engineer und einen Data Engineer umfassen würde.
Die genaue Zusammensetzung, Organisation und Bezeichnung des Teams kann variieren, aber das Wichtigste ist die Erkenntnis, dass ein Data Scientist allein die Ziele von ML Ops nicht erreichen kann. Selbst wenn eine Organisation alle notwendigen Fähigkeiten umfasst, wird sie nicht erfolgreich sein, wenn sie nicht eng zusammenarbeiten.
Eine weitere wichtige Änderung besteht darin, dass Data Scientists grundlegende Software-Engineering-Fähigkeiten wie Code-Modularisierung, Wiederverwendung, Testen und Versionierung beherrschen müssen; es reicht nicht aus, ein Modell in einem unordentlichen Notebook zum Laufen zu bringen. Aus diesem Grund führen viele Unternehmen den Titel ML Engineer ein, der diese Fähigkeiten hervorhebt. In vielen Fällen führen ML-Ingenieure in der Praxis viele der Aktivitäten aus, die für ML Ops erforderlich sind.
ML-Pipelines
Eines der Kernkonzepte des Data Engineering ist die Datenpipeline. Eine Datenpipeline ist eine Reihe von Transformationen, die auf Daten zwischen ihrer Quelle und einem Ziel angewendet werden. Sie werden in der Regel als Graph definiert, in dem jeder Knoten eine Transformation darstellt und die Kanten Abhängigkeiten oder die Ausführungsreihenfolge repräsentieren. Es gibt viele spezialisierte Tools, die bei der Erstellung, Verwaltung und Ausführung dieser Pipelines helfen. Datenpipelines können auch als ETL-Pipelines (extract, transform and load) bezeichnet werden.
ML-Modelle erfordern immer irgendeine Art von Datentransformation, die in der Regel über Skripte oder sogar Zellen in einem Notebook erfolgt, wodurch sie schwer zu verwalten und zuverlässig auszuführen sind. Die Umstellung auf richtige Datenpipelines bietet viele Vorteile bei der Wiederverwendung von Code, der Transparenz zur Laufzeit, der Verwaltung und der Skalierbarkeit.
Da ML-Training auch als Datentransformation betrachtet werden kann, ist es naheliegend, die spezifischen ML-Schritte in die Datenpipeline selbst einzubinden und sie in eine ML-Pipeline zu verwandeln. Für die meisten Modelle werden zwei Versionen der Pipeline benötigt: eine für das Training und eine für die Verarbeitung. Der Grund dafür ist, dass sich die Datenformate und die Art des Zugriffs auf sie in der Regel von einem Moment zum anderen stark unterscheiden, insbesondere bei Modellen, die in Echtzeit-Anfragen bedient werden (im Gegensatz zu Batch-Vorhersageläufen).
Die ML Pipeline ist ein reines Code-Artefakt, unabhängig von spezifischen Dateninstanzen. Das bedeutet, dass es möglich ist, ihre Versionen in der Versionskontrolle zu verfolgen und ihre Bereitstellung mit einer regulären CI/CD-Pipeline zu automatisieren, einer Kernpraxis von DevOps. Auf diese Weise können wir die Code- und Datenebenen auf strukturierte und automatisierte Weise miteinander verbinden:
Beachten Sie, dass es zwei verschiedene ML-Pipelines gibt: die Trainings-Pipeline und die Serving-Pipeline. Sie haben gemeinsam, dass die von ihnen durchgeführten Datentransformationen Daten im gleichen Format erzeugen müssen, aber ihre Implementierungen können sehr unterschiedlich sein. So läuft die Trainingspipeline in der Regel über Stapeldateien, die alle Merkmale enthalten, während die Serving-Pipeline oft online läuft und nur einen Teil der Merkmale in den Anfragen erhält und den Rest aus einer Datenbank abruft.
Es ist jedoch wichtig sicherzustellen, dass diese beiden Pipelines konsistent sind, weshalb man versuchen sollte, Code und Daten so oft wie möglich wiederzuverwenden. Einige Tools können bei diesem Ziel helfen:
- Transformations-Frameworks wie TensorFlow Transform können sicherstellen, dass Berechnungen auf der Grundlage von Trainingsmengenstatistiken, wie Durchschnittswerte und Standardabweichungen für die Normalisierung, konsistent sind.
- Feature Stores sind Datenbanken, die Werte speichern, die nicht Teil einer Vorhersageanforderung sind, zum Beispiel Features, die über die Historie eines Nutzers berechnet werden.
Modell- und Datenversionierung
Um Reproduzierbarkeit zu gewährleisten, ist eine konsistente Versionsverfolgung unerlässlich. In der traditionellen Softwarewelt reicht es aus, den Code zu versionieren, da das gesamte Verhalten durch ihn definiert wird. Bei ML müssen wir auch Modellversionen verfolgen, zusammen mit den Daten, die zum Training verwendet werden, und einigen Metainformationen wie Trainingshyperparametern.
Modelle und Metadaten können in einem Standard-Versionskontrollsystem wie Git nachverfolgt werden, aber die Daten sind oft zu groß und veränderlich, als dass dies effizient und praktisch wäre. Es ist auch wichtig, den Lebenszyklus des Modells nicht an den Lebenszyklus des Codes zu binden, da die Modellschulung oft nach einem anderen Zeitplan erfolgt. Außerdem ist es notwendig, die Daten zu versionieren und jedes trainierte Modell mit den genauen Versionen des Codes, der Daten und der verwendeten Hyperparameter zu verknüpfen. Die ideale Lösung wäre ein speziell entwickeltes Tool, aber bisher gibt es keinen klaren Konsens auf dem Markt, und es werden viele Schemata verwendet, von denen die meisten auf Datei-/Objektspeicher-Konventionen und Metadaten-Datenbanken basieren.
Modell-Validierung
Eine weitere Standard-DevOps-Praxis ist die Testautomatisierung, in der Regel in Form von Einheitstests und Integrationstests. Das Bestehen dieser Tests ist eine Voraussetzung dafür, dass eine neue Version bereitgestellt werden kann. Umfassende automatisierte Tests können einem Team großes Vertrauen geben und das Tempo der Produktionsbereitstellung erheblich beschleunigen.
ML-Modelle sind schwieriger zu testen, da kein Modell 100 % korrekte Ergebnisse liefert. Das bedeutet, dass die Modellvalidierungstests notwendigerweise statistischer Natur sein müssen, anstatt einen binären Pass/Fail-Status zu haben. Um zu entscheiden, ob ein Modell gut genug für den Einsatz ist, muss man die richtigen Metriken und den Schwellenwert ihrer akzeptablen Werte festlegen, in der Regel empirisch und oft durch Vergleich mit früheren Modellen oder Benchmarks.
Es reicht auch nicht aus, eine einzige Metrik für die gesamte Validierungsmenge zu verfolgen. Genauso wie gute Unit-Tests mehrere Fälle testen müssen, muss die Modellvalidierung individuell für relevante Segmente der Daten, so genannte Slices, durchgeführt werden. Wenn z. B. das Geschlecht direkt oder indirekt ein relevantes Merkmal eines Modells sein könnte, sollten separate Metriken für Männer, Frauen und andere Geschlechter verfolgt werden. Andernfalls könnte das Modell Probleme mit der Fairness haben oder in wichtigen Segmenten unterdurchschnittliche Ergebnisse liefern.
Wenn es Ihnen gelingt, Modelle auf automatisierte und zuverlässige Weise zusammen mit dem Rest der ML-Pipeline zu validieren, können Sie den Kreislauf sogar schließen und Online-Modelltraining implementieren, wenn dies für den Anwendungsfall sinnvoll ist.
Datenvalidierung
Eine gute Datenpipeline beginnt in der Regel mit der Validierung der Eingabedaten. Zu den üblichen Validierungen gehören Dateiformat und ‑größe, Spaltentypen, Null- oder Leerwerte und ungültige Werte. All dies ist für ML-Training und ‑Vorhersagen erforderlich, da sonst ein fehlerhaftes Modell auftaucht und man sich auf der Suche nach dem Grund den Kopf zerbrechen muss. Die Datenvalidierung ist vergleichbar mit dem Unit-Testing im Bereich des Codes.
Zusätzlich zu den grundlegenden Validierungen, die jede Datenpipeline durchführt, sollten ML-Pipelines auch die statistischen Eigenschaften der Eingaben auf höherer Ebene validieren. Wenn sich beispielsweise der Durchschnitt oder die Standardabweichung eines Merkmals von einem Trainingsdatensatz zu einem anderen erheblich ändert, wird sich dies wahrscheinlich auf das trainierte Modell und seine Vorhersagen auswirken. Dies könnte eine tatsächliche Veränderung in den Daten widerspiegeln oder eine Anomalie sein, die durch die Art der Datenverarbeitung verursacht wird. Daher ist es wichtig, systemische Fehler, die das Modell verunreinigen könnten, zu überprüfen und auszuschließen und sie gegebenenfalls zu beheben.
Überwachung
Die Überwachung von Produktionssystemen ist unerlässlich, damit sie gut laufen. Bei ML-Systemen ist die Überwachung sogar noch wichtiger, da ihre Leistung nicht nur von Faktoren abhängt, die wir bis zu einem gewissen Grad kontrollieren können, wie z. B. die Infrastruktur und unsere eigene Software, sondern auch von Daten, über die wir viel weniger Kontrolle haben. Daher müssen wir nicht nur Standardkennzahlen wie Latenz, Datenverkehr, Fehler und Sättigung überwachen, sondern auch die Leistung der Modellvorhersage.
Eine offensichtliche Herausforderung bei der Überwachung der Modellleistung besteht darin, dass wir in der Regel kein verifiziertes Label haben, mit dem wir die Vorhersagen unseres Modells vergleichen können, da das Modell mit neuen Daten arbeitet. In einigen Fällen können wir die Effektivität des Modells auf indirekte Weise bewerten, indem wir beispielsweise die Klickrate für ein Empfehlungsmodell messen. In anderen Fällen müssen wir uns auf Vergleiche zwischen Zeiträumen verlassen, indem wir beispielsweise stündlich einen Prozentsatz positiver Klassifizierungen berechnen und eine Warnung ausgeben, wenn dieser um mehr als ein paar Prozent vom Durchschnitt für diesen Zeitraum abweicht.
Wie bei der Validierung des Modells ist es auch hier wichtig, die Metriken über Slices hinweg und nicht nur global zu überwachen, um Probleme zu erkennen, die bestimmte Segmente betreffen.
Zusammenfassung
In dem Maße, wie sich ML von der Forschung zu angewandten Geschäftslösungen entwickelt, müssen wir auch die Reife der Betriebsprozesse verbessern. Glücklicherweise können wir viele Praktiken aus Disziplinen übernehmen, die vor ML entstanden sind.
Die folgende Tabelle fasst die wichtigsten Praktiken von ML Ops zusammen und zeigt, wie sie mit DevOps und Data Engineering zusammenhängen:
Es handelt sich um eine brandneue und aufregende Disziplin mit Werkzeugen und Verfahren, die sich wahrscheinlich sehr schnell weiterentwickeln werden. Die Entwicklung und Anwendung von Produktionstechniken auf ML bietet zweifellos eine Menge Möglichkeiten.
Quelle: medium
Erfahren Sie hier mehr über Lösungen im Bereich Data Management oder besuchen Sie eines unserer kostenlosen Webinare.
