Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

In diesem ersten Kapitel stellen wir Pipelines für maschinelles Lernen vor und erläutern alle Schritte, die zu ihrer Erstellung gehören. Wir erklären, was passieren muss, damit dein maschinelles Lernmodell von einem Experiment zu einem robusten Produktionssystem wird. Außerdem stellen wir unser Beispielprojekt vor, das wir im weiteren Verlauf des Buches verwenden werden, um die beschriebenen Prinzipien zu demonstrieren.

Warum Pipelines für maschinelles Lernen?

Der Hauptvorteil von Pipelines für maschinelles Lernen liegt in der Automatisierung der Schritte des Modelllebenszyklus. Wenn neue Trainingsdaten zur Verfügung stehen, sollte ein Arbeitsablauf ausgelöst werden, der Datenvalidierung, Vorverarbeitung, Modelltraining, Analyse und Bereitstellung umfasst. Wir haben beobachtet, dass zu viele Data-Science-Teams diese Schritte manuell durchführen, was nicht nur kostspielig ist, sondern auch eine Fehlerquelle darstellt. Gehen wir im Detail auf die Vorteile von Pipelines für maschinelles Lernen ein:

Die Fähigkeit, sich auf neue Modelle zu konzentrieren, anstatt bestehende Modelle zu pflegen

Automatisierte Pipelines für maschinelles Lernen entlasten Datenwissenschaftler von der Pflege bestehender Modelle. Wir haben beobachtet, dass zu viele Datenwissenschaftler ihre Tage damit verbringen, bereits entwickelte Modelle auf dem neuesten Stand zu halten. Sie führen Skripte manuell aus, um ihre Trainingsdaten vorzuverarbeiten, sie schreiben einmalige Deployment-Skripte oder sie stimmen ihre Modelle manuell ab. Automatisierte Pipelines ermöglichen es Datenwissenschaftlern, neue Modelle zu entwickeln - der Teil ihrer Arbeit, der Spaß macht. Letztendlich führt dies zu einer höheren Arbeitszufriedenheit und zu einer höheren Bindung an den Arbeitsplatz in einem umkämpften Arbeitsmarkt.

Prävention von Wanzen

Automatisierte Pipelines können Bugs verhindern. Wie wir in späteren Kapiteln sehen werden, werden neu erstellte Modelle an einen Satz versionierter Daten und Vorverarbeitungsschritte an das entwickelte Modell gebunden. Das heißt, wenn neue Daten gesammelt werden, wird ein neues Modell erstellt. Wenn die Vorverarbeitungsschritte aktualisiert werden, werden die Trainingsdaten ungültig und es wird ein neues Modell erstellt. In manuellen Workflows für maschinelles Lernen ist eine häufige Fehlerquelle eine Änderung des Vorverarbeitungsschritts, nachdem ein Modell trainiert wurde. In diesem Fall würden wir ein Modell mit anderen Verarbeitungsanweisungen einsetzen als die, mit denen wir das Modell trainiert haben. Diese Fehler können sehr schwer zu beheben sein, da eine Inferenz des Modells zwar noch möglich, aber einfach falsch ist. Mit automatisierten Workflows können diese Fehler vermieden werden.

Nützlicher Papierweg

Die Versuchsnachverfolgung und das Modellfreigabemanagement erstellen einen schriftlichen Nachweis der Modelländerungen. Im Experiment werden Änderungen an den Hyperparametern des Modells, den verwendeten Datensätzen und den daraus resultierenden Modellmetriken (z. B. Verlust oder Genauigkeit) aufgezeichnet. Das Modell-Release-Management hält fest, welches Modell letztendlich ausgewählt und eingesetzt wurde. Dieses Protokoll ist besonders wertvoll, wenn das Data Science Team ein Modell neu erstellen oder die Leistung des Modells verfolgen muss.

Normung

Standardisierte Pipelines für maschinelles Lernen verbessern die Erfahrung eines Data Science Teams. Dank der standardisierten Setups können Datenwissenschaftler/innen schnell an Bord geholt werden oder zwischen Teams wechseln und dieselben Entwicklungsumgebungen vorfinden. Das verbessert die Effizienz und reduziert den Zeitaufwand für die Einrichtung eines neuen Projekts. Die Zeit, die in die Einrichtung von Pipelines für maschinelles Lernen investiert wird, kann auch zu einer besseren Mitarbeiterbindung führen.

Der Business Case für Pipelines

Die Implementierung von automatisierten Pipelines für maschinelles Lernen hat drei wichtige Auswirkungen für ein Data Science Team:

  • Mehr Entwicklungszeit für neue Modelle

  • Einfachere Prozesse zur Aktualisierung bestehender Modelle

  • Weniger Zeitaufwand für die Reproduktion von Modellen

All diese Aspekte werden die Kosten von Data-Science-Projekten senken. Aber darüber hinaus werden automatisierte Pipelines für maschinelles Lernen:

  • Sie helfen dabei, mögliche Verzerrungen in den Datensätzen oder in den trainierten Modellen zu erkennen. Das Aufspüren von Verzerrungen kann verhindern, dass Menschen, die mit dem Modell interagieren, Schaden nehmen. So wurde z. B. festgestellt, dass Amazons maschinenlerngestützter Lebenslauf-Screener Frauen benachteiligt.

  • Erstelle einen schriftlichen Nachweis (über die Nachverfolgung von Experimenten und die Verwaltung von Modellfreigaben), der hilfreich ist, wenn Fragen zu Datenschutzgesetzen wie der europäischen Datenschutzgrundverordnung (GDPR) auftauchen.

  • Verschaffe Data Scientists mehr Zeit für die Entwicklung und steigere ihre Arbeitszufriedenheit.

Wann man über Pipelines für maschinelles Lernen nachdenken sollte

Pipelines für maschinelles Lernen bieten eine Reihe von Vorteilen, aber nicht jedes Data Science-Projekt braucht eine Pipeline. Manchmal wollen Datenwissenschaftler/innen einfach nur mit einem neuen Modell experimentieren, eine neue Modellarchitektur untersuchen oder eine aktuelle Veröffentlichung reproduzieren. In diesen Fällen wären Pipelines nicht sinnvoll. Sobald ein Modell jedoch Nutzer hat (z. B. wenn es in einer App verwendet wird), muss es ständig aktualisiert und feinabgestimmt werden. In diesen Fällen sind wir wieder bei den Szenarien, die wir vorhin über die kontinuierliche Aktualisierung von Modellen und die Verringerung der Belastung durch diese Aufgaben für Datenwissenschaftler/innen diskutiert haben.

Pipelines werden auch immer wichtiger, wenn ein Machine-Learning-Projekt wächst. Wenn die Datenmenge oder die Ressourcenanforderungen groß sind, ermöglichen die von uns besprochenen Ansätze eine einfache Skalierung der Infrastruktur. Wenn Wiederholbarkeit wichtig ist, wird diese durch die Automatisierung und den Audit-Trail von Pipelines für maschinelles Lernen gewährleistet.

Überblick über die Schritte in einer Machine Learning Pipeline

Eine Pipeline für maschinelles Lernen beginnt mit der Aufnahme neuer Trainingsdaten und endet damit, dass du eine Art Feedback darüber erhältst, wie dein neu trainiertes Modell funktioniert. Bei diesem Feedback kann es sich um eine Leistungskennzahl aus der Produktion oder um das Feedback der Nutzer deines Produkts handeln. Die Pipeline umfasst eine Vielzahl von Schritten, darunter die Datenvorverarbeitung, das Modelltraining und die Modellanalyse sowie die Bereitstellung des Modells. Du kannst dir vorstellen, dass die manuelle Durchführung dieser Schritte mühsam und sehr fehleranfällig ist. Im Laufe dieses Buches stellen wir dir Werkzeuge und Lösungen vor, mit denen du deine Machine Learning Pipeline automatisieren kannst.

Wie du in Abbildung 1-1 sehen kannst, ist die Pipeline eigentlich ein wiederkehrender Zyklus. Es können kontinuierlich Daten gesammelt und somit auch die Modelle für maschinelles Lernen aktualisiert werden. Mehr Daten bedeuten in der Regel bessere Modelle. Und wegen dieses ständigen Zustroms von Daten ist Automatisierung der Schlüssel. In der Praxis solltest du deine Modelle häufig neu trainieren. Wenn du das nicht tust, sinkt in vielen Fällen die Genauigkeit, weil sich die Trainingsdaten von den neuen Daten unterscheiden, auf deren Grundlage das Modell Vorhersagen macht. Wenn das Umlernen ein manueller Prozess ist, bei dem die neuen Trainingsdaten manuell validiert oder die aktualisierten Modelle analysiert werden müssen, hat ein Datenwissenschaftler oder Ingenieur für maschinelles Lernen keine Zeit, neue Modelle für ganz andere Geschäftsprobleme zu entwickeln.

Model Life Cycle
Abbildung 1-1. Lebenszyklus des Modells

Eine Pipeline für maschinelles Lernen umfasst in der Regel die Schritte in den folgenden Abschnitten.

Dateningestion und Datenversionierung

Wie in Kapitel 3 beschrieben, steht am Anfang jeder Pipeline für maschinelles Lernen das Einlesen der Daten. In diesem Pipelineschritt verarbeiten wir die Daten in ein Format, das die folgenden Komponenten verarbeiten können. Bei der Datenübernahme wird kein Feature Engineering durchgeführt (dies geschieht nach der Datenvalidierung). Es ist auch ein guter Zeitpunkt, die eingehenden Daten zu versionieren, um am Ende der Pipeline einen Daten-Snapshot mit dem trainierten Modell zu verbinden.

Datenvalidierung

Bevor wir eine neue Modellversion trainieren, müssen wir die neuen Daten validieren. Bei der Datenvalidierung(Kapitel 4) geht es darum, zu überprüfen, ob die Statistiken der neuen Daten den Erwartungen entsprechen (z. B. der Bereich, die Anzahl der Kategorien und die Verteilung der Kategorien). Außerdem wird der Datenwissenschaftler gewarnt, wenn Anomalien entdeckt werden. Wenn du zum Beispiel ein binäres Klassifizierungsmodell trainierst, könnten deine Trainingsdaten zu 50 % aus Proben der Klasse X und zu 50 % aus Proben der Klasse Y bestehen. Datenvalidierungstools geben Warnmeldungen aus, wenn sich die Aufteilung zwischen diesen Klassen ändert, z. B. wenn die neu erhobenen Daten zu 70/30 auf die beiden Klassen aufgeteilt sind. Wenn ein Modell mit einem solch unausgewogenen Trainingssatz trainiert wird und der Datenwissenschaftler die Verlustfunktion des Modells nicht angepasst hat oder zu viele oder zu wenige Stichproben der Kategorie X oder Y genommen hat, könnten die Modellvorhersagen in Richtung der dominanten Kategorie verzerrt sein.

Gängige Tools zur Datenvalidierung ermöglichen es dir auch, verschiedene Datensätze zu vergleichen. Wenn du einen Datensatz mit einem dominanten Label hast und den Datensatz in einen Trainings- und einen Validierungssatz aufteilst, musst du sicherstellen, dass die Aufteilung der Labels in den beiden Datensätzen ungefähr gleich ist. Mit Datenvalidierungstools kannst du Datensätze vergleichen und Anomalien aufzeigen.

Fällt bei der Validierung etwas Ungewöhnliches auf, kann die Pipeline hier gestoppt und der Datenwissenschaftler alarmiert werden. Wird eine Verschiebung in den Daten festgestellt, kann der Datenwissenschaftler oder der Ingenieur für maschinelles Lernen entweder das Sampling der einzelnen Klassen ändern (z. B. nur die gleiche Anzahl von Beispielen aus jeder Klasse auswählen) oder die Verlustfunktion des Modells ändern, eine neue Pipeline zur Modellerstellung starten und den Lebenszyklus neu beginnen.

Datenvorverarbeitung

Es ist sehr wahrscheinlich, dass du deine frisch gesammelten Daten nicht direkt für das Training deines maschinellen Lernmodells verwenden kannst. In fast allen Fällen musst du die Daten vorverarbeiten, um sie für deine Trainingsläufe zu verwenden. Oft müssen die Labels in einen oder mehrere Vektoren umgewandelt werden.1 Das Gleiche gilt für die Modelleingaben. Wenn du ein Modell aus Textdaten trainierst, musst du die Zeichen des Textes in Indizes oder die Text-Token in Wortvektoren umwandeln. Da die Vorverarbeitung nur vor dem Modelltraining und nicht bei jeder Trainingsepoche erforderlich ist, ist es am sinnvollsten, die Vorverarbeitung in einem eigenen Lebenszyklusschritt vor dem Training des Modells durchzuführen.

Die Tools für die Datenvorverarbeitung können von einem einfachen Python-Skript bis hin zu ausgefeilten Graphmodellen reichen. Die meisten Datenwissenschaftler/innen konzentrieren sich zwar auf die Verarbeitungsmöglichkeiten ihrer bevorzugten Tools, aber es ist auch wichtig, dass Änderungen der Vorverarbeitungsschritte mit den verarbeiteten Daten verknüpft werden können und umgekehrt. Das heißt, wenn jemand einen Verarbeitungsschritt ändert (z. B. ein zusätzliches Label in einer One-Hot-Vektor-Konvertierung zulässt), sollten die vorherigen Trainingsdaten ungültig werden und eine Aktualisierung der gesamten Pipeline erzwingen. Wir beschreiben diesen Pipelineschritt in Kapitel 5.

Modellschulung und -abstimmung

Der Schritt des Modelltrainings(Kapitel 6) ist das Herzstück der Pipeline für maschinelles Lernen. In diesem Schritt trainieren wir ein Modell so, dass es Eingaben annimmt und eine Ausgabe mit dem geringstmöglichen Fehler vorhersagt. Bei größeren Modellen und vor allem bei großen Trainingsmengen kann dieser Schritt schnell unübersichtlich werden. Da der Speicher für unsere Berechnungen in der Regel eine endliche Ressource ist, ist die effiziente Verteilung des Modelltrainings entscheidend.

Dem Modelltuning wird in letzter Zeit viel Aufmerksamkeit geschenkt, weil es zu erheblichen Leistungsverbesserungen führen und einen Wettbewerbsvorteil verschaffen kann. Je nach deinem Machine-Learning-Projekt kannst du dich dafür entscheiden, dein Modell zu tunen, bevor du über Machine-Learning-Pipelines nachdenkst, oder du möchtest es als Teil deiner Pipeline tunen. Da unsere Pipelines dank ihrer zugrundeliegenden Architektur skalierbar sind, können wir eine große Anzahl von Modellen parallel oder nacheinander aufsetzen. So können wir die optimalen Modell-Hyperparameter für unser endgültiges Produktionsmodell herausfinden.

Modellanalyse

In der Regel verwenden wir die Genauigkeit oder den Verlust, um den optimalen Satz an Modellparametern zu bestimmen. Sobald wir uns jedoch auf die endgültige Version des Modells geeinigt haben, ist es äußerst sinnvoll, die Leistung des Modells eingehender zu analysieren (wie in Kapitel 7 beschrieben). Dazu kann die Berechnung anderer Kennzahlen wie Präzision, Recall und AUC (Fläche unter der Kurve) gehören, oder die Berechnung der Leistung auf einem größeren Datensatz als dem beim Training verwendeten Validierungssatz.

Ein weiterer Grund für eine gründliche Modellanalyse ist die Überprüfung, ob die Vorhersagen des Modells fair sind. Es ist unmöglich zu sagen, wie das Modell für verschiedene Gruppen von Nutzern abschneidet, wenn der Datensatz nicht aufgeteilt und die Leistung für jede Gruppe berechnet wird. Wir können auch die Abhängigkeit des Modells von den im Training verwendeten Merkmalen untersuchen und herausfinden, wie sich die Vorhersagen des Modells ändern würden, wenn wir die Merkmale eines einzelnen Trainingsbeispiels ändern würden.

Ähnlich wie bei der Modellanpassung und der endgültigen Auswahl des besten Modells ist auch bei diesem Arbeitsschritt eine Überprüfung durch einen Datenwissenschaftler erforderlich. Wir werden jedoch zeigen, wie die gesamte Analyse automatisiert werden kann und nur die abschließende Überprüfung durch einen Menschen erfolgt. Durch die Automatisierung bleibt die Analyse der Modelle einheitlich und mit anderen Analysen vergleichbar.

Modellversionierung

Der Zweck des Modellversions- und Validierungsschritts ist es, den Überblick darüber zu behalten, welches Modell, welcher Satz von Hyperparametern und welche Datensätze für die nächste Version ausgewählt wurden, die eingesetzt werden soll.

Die semantische Versionierung in der Softwareentwicklung erfordert, dass du die Hauptversionsnummer erhöhst, wenn du eine inkompatible Änderung an deiner API vornimmst oder wenn du wichtige Funktionen hinzufügst. Andernfalls erhöhst du die Minor-Versionsnummer. Das Modell-Release-Management hat einen weiteren Freiheitsgrad: den Datensatz. Es gibt Situationen, in denen du einen erheblichen Unterschied in der Modellleistung erreichen kannst, ohne einen einzigen Modellparameter oder eine Architekturbeschreibung zu ändern, indem du deutlich mehr und/oder bessere Daten für den Trainingsprozess bereitstellst. Rechtfertigt diese Leistungssteigerung ein größeres Versions-Upgrade?

Auch wenn die Antwort auf diese Frage für jedes Data-Science-Team anders ausfallen kann, ist es unerlässlich, alle Eingaben in eine neue Modellversion zu dokumentieren (Hyperparameter, Datensätze, Architektur) und sie als Teil dieses Freigabeschritts zu verfolgen.

Model Deployment

Sobald du dein Modell trainiert, abgestimmt und analysiert hast, ist es bereit für die Hauptphase. Leider werden zu viele Modelle mit einmaligen Implementierungen eingesetzt, was die Aktualisierung der Modelle zu einem spröden Prozess macht.

Mit modernen Modellservern kannst du deine Modelle bereitstellen, ohne Web-App-Code zu schreiben. Oft bieten sie mehrere API-Schnittstellen wie REST (Representational State Transfer) oder RPC (Remote Procedure Call) und ermöglichen es dir, mehrere Versionen desselben Modells gleichzeitig zu hosten. Wenn du mehrere Versionen gleichzeitig bereitstellst, kannst du A/B-Tests mit deinen Modellen durchführen und so wertvolles Feedback zu deinen Modellverbesserungen erhalten.

Mit Modellservern kannst du auch eine Modellversion aktualisieren, ohne deine Anwendung neu bereitstellen zu müssen, was die Ausfallzeiten deiner Anwendung verringert und die Kommunikation zwischen der Anwendungsentwicklung und den Teams für maschinelles Lernen vereinfacht. Wir beschreiben die Modellbereitstellung in den Kapiteln 8 und 9.

Rückkopplungsschleifen

Der letzte Schritt in der Pipeline des maschinellen Lernens wird oft vergessen, aber er ist entscheidend für den Erfolg von Data Science-Projekten. Wir müssen den Kreislauf schließen. Dann können wir die Effektivität und Leistung des neu eingesetzten Modells messen. In diesem Schritt können wir wertvolle Informationen über die Leistung des Modells erfassen. In manchen Situationen können wir auch neue Trainingsdaten erfassen, um unsere Datensätze zu erweitern und unser Modell zu aktualisieren. Dabei kann ein Mensch in die Schleife einbezogen werden, oder es kann automatisch geschehen. Wir besprechen Feedbackschleifen in Kapitel 13.

Bis auf die beiden manuellen Überprüfungsschritte (die Modellanalyse und das Feedback) können wir die gesamte Pipeline automatisieren. Datenwissenschaftler sollten sich auf die Entwicklung neuer Modelle konzentrieren können und nicht auf die Aktualisierung und Pflege bestehender Modelle.

Datenschutz

Zum Zeitpunkt des Verfassens dieses Artikels stehen Datenschutzaspekte außerhalb der Standard-Pipeline für maschinelles Lernen. Wir gehen davon aus, dass sich dies in Zukunft ändern wird, da die Bedenken der Verbraucher/innen über die Verwendung ihrer Daten wachsen und neue Gesetze die Verwendung persönlicher Daten einschränken werden. Dies wird dazu führen, dass datenschutzfreundliche Methoden in die Tools zum Aufbau von Pipelines für maschinelles Lernen integriert werden.

In Kapitel 14 besprechen wir mehrere aktuelle Optionen zur Verbesserung der Privatsphäre in maschinellen Lernmodellen:

  • Differenzieller Datenschutz, bei dem die Mathematik garantiert, dass die Modellvorhersagen die Daten eines Nutzers nicht preisgeben

  • Föderiertes Lernen, bei dem die Rohdaten das Gerät des Nutzers nicht verlassen

  • Verschlüsseltes maschinelles Lernen, bei dem entweder der gesamte Trainingsprozess im verschlüsselten Raum ablaufen kann oder ein auf Rohdaten trainiertes Modell verschlüsselt werden kann

Pipeline-Orchestrierung

Alle im vorigen Abschnitt beschriebenen Komponenten einer Pipeline für maschinelles Lernen müssen unter ausgeführt oder, wie wir sagen, orchestriert werden, damit die Komponenten in der richtigen Reihenfolge ausgeführt werden. Die Eingaben für eine Komponente müssen berechnet werden, bevor eine Komponente ausgeführt wird. Die Orchestrierung dieser Schritte wird von Tools wie Apache Beam, Apache Airflow (siehe Kapitel 11) oder Kubeflow Pipelines für die Kubernetes-Infrastruktur (siehe Kapitel 12) übernommen.

Während Datenpipeline-Tools die Schritte der Pipeline für maschinelles Lernen koordinieren, erfassen Pipeline-Artefaktspeicher wie der TensorFlow ML MetadataStore die Ergebnisse der einzelnen Prozesse. In Kapitel 2 geben wir einen Überblick über den Metadatenspeicher von TFX und werfen einen Blick hinter die Kulissen von TFX und seinen Pipeline-Komponenten.

Warum Pipeline Orchestration?

Im Jahr 2015 kam eine Gruppe von Machine-Learning-Ingenieuren bei Google zu dem Schluss, dass einer der Gründe, warum Machine-Learning-Projekte oft fehlschlagen, darin liegt, dass die meisten Projekte mit benutzerdefiniertem Code ausgestattet sind, um die Lücke zwischen den einzelnen Schritten der Machine-Learning-Pipeline zu schließen.2 Dieser benutzerdefinierte Code lässt sich jedoch nicht einfach von einem Projekt zum nächsten übertragen. Die Forscher haben ihre Ergebnisse in dem Papier "Hidden Technical Debt in Machine Learning Systems" zusammengefasst.3 Die Autoren argumentieren darin, dass der Klebecode zwischen den Pipelineschritten oft brüchig ist und dass benutzerdefinierte Skripte nicht über bestimmte Fälle hinaus skalierbar sind. Im Laufe der Zeit sind Tools wie Apache Beam, Apache Airflow oder Kubeflow Pipelines entwickelt worden. Sie ermöglichen eine standardisierte Orchestrierung und eine Abstraktion des Glue Codes zwischen den Aufgaben.

Auch wenn es zunächst mühsam erscheinen mag, ein neues Tool (z.B. Beam oder Airflow) oder ein neues Framework (z.B. Kubeflow) zu erlernen und eine zusätzliche Infrastruktur für maschinelles Lernen (z.B. Kubernetes) einzurichten, wird sich die Zeitinvestition sehr bald auszahlen. Wenn du keine standardisierten Pipelines für maschinelles Lernen einführst, müssen sich die Data Science-Teams mit einzigartigen Projektkonfigurationen, willkürlichen Speicherorten für Protokolldateien, einzigartigen Debugging-Schritten usw. auseinandersetzen. Die Liste der Komplikationen kann endlos sein.

Gerichtet azyklische Graphen

Pipeline-Tools wie Apache Beam, Apache Airflow und Kubeflow Pipelines verwalten den Fluss von Aufgaben durch eine grafische Darstellung der Aufgabenabhängigkeiten.

Wie das Beispieldiagramm in Abbildung 1-2 zeigt, sind die Pipelineschritte gerichtet. Das bedeutet, dass eine Pipeline mit Aufgabe A beginnt und mit Aufgabe E endet, was garantiert, dass der Ausführungspfad durch die Abhängigkeiten der Aufgaben klar definiert ist. Gerichtete Graphen vermeiden Situationen, in denen einige Aufgaben beginnen, ohne dass alle Abhängigkeiten vollständig berechnet wurden. Da wir wissen, dass wir unsere Trainingsdaten vor dem Training eines Modells vorverarbeiten müssen, verhindert die Darstellung als gerichteter Graph, dass die Trainingsaufgabe ausgeführt wird, bevor der Vorverarbeitungsschritt abgeschlossen ist.

DAG
Abbildung 1-2. Beispiel für einen gerichteten azyklischen Graphen

Pipeline-Graphen müssen außerdem azyklisch sein, d.h., dass ein Graph nicht mit einer bereits abgeschlossenen Aufgabe verknüpft ist. Das würde bedeuten, dass die Pipeline endlos laufen könnte und der Arbeitsablauf somit nicht beendet würde.

Aufgrund dieser beiden Bedingungen ( gerichtet und azyklisch) werden Pipeline-Graphen als gerichtete azyklische Graphen (DAGs) bezeichnet. Du wirst feststellen, dass DAGs ein zentrales Konzept der meisten Workflow-Tools sind. Wie diese Graphen ausgeführt werden, werden wir in den Kapiteln 11 und 12 genauer besprechen.

Unser Beispielprojekt

Um dieses Buch zu begleiten, haben wir ein Beispielprojekt mit Open-Source-Daten erstellt. Der Datensatz ist eine Sammlung von Verbraucherbeschwerden über Finanzprodukte in den Vereinigten Staaten und enthält eine Mischung aus strukturierten Daten (kategorische/numerische Daten) und unstrukturierten Daten (Text). Die Daten stammen vom Consumer Finance Protection Bureau.

Abbildung 1-3 zeigt ein Beispiel aus diesem Datensatz.

Data Sample
Abbildung 1-3. Datenbeispiel

Das Problem des maschinellen Lernens besteht darin, anhand von Daten über die Beschwerde vorherzusagen, ob der Verbraucher die Beschwerde angefochten hat. In diesem Datensatz werden 30% der Beschwerden angefochten, also ist der Datensatz nicht ausgewogen.

Projektstruktur

Wir haben unser Beispielprojekt als GitHub-Repos zur Verfügung gestellt, und du kannst es wie gewohnt mit dem folgenden Befehl klonen:

$ git clone https://github.com/Building-ML-Pipelines/\
            building-machine-learning-pipelines.git

Python-Paket-Versionen

Für die Erstellung unseres Beispielprojekts haben wir Python 3.6-3.8 verwendet. Wir haben TensorFlow Version 2.2.0 und TFX Version 0.22.0 verwendet. Wir tun unser Bestes, um unser GitHub Repo mit zukünftigen Versionen zu aktualisieren, aber wir können nicht garantieren, dass das Projekt mit anderen Sprach- oder Paketversionen funktioniert.

Unser Beispielprojekt enthält Folgendes:

  • Ein Kapitelordner mit Notizbüchern für eigenständige Beispiele aus den Kapiteln 3, 4, 7 und 14

  • Ein Komponentenordner mit dem Code für allgemeine Komponenten wie die Modelldefinition

  • Eine komplette interaktive Pipeline

  • Ein Beispiel für ein Experiment zum maschinellen Lernen, das den Ausgangspunkt für die Pipeline bildet

  • Vollständige Beispielpipelines, die von Apache Beam, Apache Airflow und Kubeflow Pipelines orchestriert werden

  • Ein Dienstprogramm-Ordner mit einem Skript zum Herunterladen der Daten

In den folgenden Kapiteln führen wir dich durch die notwendigen Schritte, um das Beispiel-Experiment für maschinelles Lernen, in unserem Fall ein Jupyter-Notebook mit einer Keras-Modellarchitektur, in eine vollständige End-to-End-Pipeline für maschinelles Lernen zu verwandeln.

Unser Machine Learning Modell

Der Kern unseres Beispielprojekts für Deep Learning ist das Modell, das von der Funktion get_model im components/module.py Skript unseres Beispielprojekts erstellt wird. Das Modell sagt anhand der folgenden Merkmale voraus, ob ein Verbraucher eine Beschwerde angefochten hat:

  • Das Finanzprodukt

  • Das Teilprodukt

  • Die Antwort des Unternehmens auf die Beschwerde

  • Das Problem, über das sich der Verbraucher beschwert hat

  • Der US-Staat

  • Die Postleitzahl

  • Der Text der Beschwerde (die Erzählung)

Für den Aufbau der Pipeline für maschinelles Lernen gehen wir davon aus, dass die Modellarchitektur fertig entworfen ist und wir das Modell nicht verändern werden. Auf die Modellarchitektur gehen wir in Kapitel 6 genauer ein. Aber für dieses Buch ist die Modellarchitektur ein sehr unwichtiger Punkt. In diesem Buch geht es darum, was du mit deinem Modell machen kannst, sobald du es hast.

Ziel des Beispielprojekts

Im Laufe dieses Buches werden wir die notwendigen Frameworks, Komponenten und Infrastrukturelemente vorstellen, um unser Beispielmodell für maschinelles Lernen kontinuierlich zu trainieren. Wir werden den Stack aus dem Architekturdiagramm in Abbildung 1-4 verwenden.

Machine learning Pipeline Architecture for our Example Project
Abbildung 1-4. Architektur der Pipeline für maschinelles Lernen für unser Beispielprojekt

Wir haben versucht, ein generisches Machine-Learning-Problem zu implementieren, das leicht durch dein spezifisches Machine-Learning-Problem ersetzt werden kann. Die Struktur und der grundlegende Aufbau der Pipeline für maschinelles Lernen bleiben gleich und können auf deinen Anwendungsfall übertragen werden. Jede Komponente muss etwas angepasst werden (z. B. woher die Daten kommen sollen), aber wie wir noch sehen werden, ist der Anpassungsbedarf begrenzt.

Zusammenfassung

In diesem Kapitel haben wir das Konzept der Pipelines für maschinelles Lernen vorgestellt und die einzelnen Schritte erläutert. Wir haben auch die Vorteile der Automatisierung dieses Prozesses aufgezeigt. Außerdem haben wir die Weichen für die folgenden Kapitel gestellt und eine kurze Übersicht über jedes Kapitel sowie eine Einführung in unser Beispielprojekt gegeben. Im nächsten Kapitel werden wir mit dem Aufbau unserer Pipeline beginnen!

1 Bei überwachten Klassifizierungsproblemen mit mehreren Klassen als Ausgaben ist es oft notwendig, von einer Kategorie in einen Vektor wie (0,1,0) zu konvertieren, der ein One-Hot-Vektor ist, oder von einer Liste von Kategorien in einen Vektor wie (1,1,0), der ein Multi-Hot-Vektor ist.

2 Google startete 2007 ein internes Projekt namens Sibyl, um eine interne Pipeline für maschinelles Lernen zu verwalten. Im Jahr 2015 erlangte das Thema jedoch größere Aufmerksamkeit, als D. Sculley et al. ihre Erkenntnisse über Machine Learning Pipelines unter dem Titel "Hidden Technical Debt in Machine Learning Systems" veröffentlichten .

3 D. Sculley et al., "Hidden Technical Debt in Machine Learning Systems", Google, Inc. (2015).

Get Aufbau von Pipelines für maschinelles Lernen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.