Kapitel 1. Einführung
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Wir beginnen mit einem Modell oder Rahmenwerk für das Hinzufügen von maschinellem Lernen (ML) zu einer Website, das in vielen Bereichen anwendbar ist - nicht nur in diesem Beispiel. Dieses Modell nennen wir die ML-Schleife.
Der ML-Lebenszyklus
ML-Anwendungen sind nie wirklich fertig. Sie beginnen und enden auch nicht an einem bestimmten Ort, weder technisch noch organisatorisch. ML-Modellentwickler hoffen oft , dass ihr Leben einfach ist und sie nur einmal Daten sammeln und ein Modell trainieren müssen, aber das ist selten der Fall.
Ein einfaches Gedankenexperiment kann uns helfen zu verstehen, warum. Nehmen wir an, wir haben ein ML-Modell und untersuchen, ob das Modell gut genug funktioniert (gemäß einem bestimmten Schwellenwert) oder nicht. Wenn es nicht gut genug funktioniert, arbeiten Data Scientists, Business Analysten und ML-Ingenieure zusammen, um die Fehler zu verstehen und sie zu verbessern. Wie zu erwarten, ist dies mit viel Arbeit verbunden: Vielleicht muss die bestehende Trainingspipeline geändert werden, um einige Merkmale zu ändern, Daten hinzuzufügen oder zu entfernen und das Modell umzustrukturieren, um das bereits Erreichte zu wiederholen.
Wenn das Modell hingegen gut funktioniert, sind die Unternehmen in der Regel begeistert. Der Gedanke liegt nahe: Wenn wir schon mit einem naiven Versuch so viele Fortschritte machen können, wie viel besser können wir dann erst sein, wenn wir härter daran arbeiten und das Modell weiterentwickeln. Das bedeutet in der Regel - du ahnst es schon -, dass wir die bestehende Trainingspipeline verändern, Merkmale ändern, Daten hinzufügen oder entfernen und möglicherweise sogar das Modell umstrukturieren. In jedem Fall wird mehr oder weniger die gleiche Arbeit geleistet, und das erste Modell, das wir erstellen, ist lediglich ein Ausgangspunkt für das, was wir als nächstes tun.
Schauen wir uns den ML-Lebenszyklus oder die Schleife genauer an(Abbildung 1-1).
Abbildung 1-1. ML-Lebenszyklus
ML-Systeme beginnen mit Daten. Beginnen wir also auf der linken Seite des Diagramms und gehen wir diesen Kreislauf im Detail durch. Wir werden uns jede Phase genau ansehen und im Zusammenhang mit unserer Shopping-Site erklären, wer in der Organisation an jeder Phase beteiligt ist und welche Schlüsselaktivitäten sie ausführen werden.
Datenerhebung und -analyse
Zuerst macht das Team eine Bestandsaufnahme der Daten, über die es verfügt, und beginnt, diese Daten zu bewerten. Die Teammitglieder müssen entscheiden, ob sie über alle benötigten Daten verfügen, und dann Prioritäten setzen, für welche geschäftlichen oder organisatorischen Zwecke sie die Daten nutzen können. Dann müssen sie die Daten sammeln und verarbeiten.
Die Arbeit im Zusammenhang mit der Datenerfassung und -analyse berührt fast jeden im Unternehmen, aber wie genau sie ihn berührt, ist von Unternehmen zu Unternehmen sehr unterschiedlich. Geschäftsanalysten können zum Beispiel in den Finanz-, Buchhaltungs- oder Produktteams tätig sein und jeden Tag mit den von der Plattform bereitgestellten Daten arbeiten. Oder Daten- und Plattformingenieure entwickeln wiederverwendbare Tools für die Datenaufnahme, -bereinigung und -verarbeitung, obwohl sie vielleicht nicht an Geschäftsentscheidungen beteiligt sind. (In einem kleineren Unternehmen sind sie vielleicht nur Software- oder Produktingenieure.) In manchen Unternehmen gibt es formale Data-Engineering-Rollen. In anderen Unternehmen gibt es Data Scientists, Produktanalysten und User Experience (UX)-Forscher, die alle die Ergebnisse dieser Phase nutzen.
Bei YarnIt, unserem Webshop-Betreiber, ist der größte Teil der Organisation an diesem Schritt beteiligt. Dazu gehören die Geschäfts- und Produktteams, die am besten wissen, in welchen Bereichen des Unternehmens eine Optimierung am sinnvollsten ist. Sie können zum Beispiel feststellen, ob eine kleine Gewinnsteigerung bei jedem Verkauf für das Geschäft wichtiger ist oder ob es stattdessen sinnvoller ist, die Bestellhäufigkeit etwas zu erhöhen. Sie können auf Probleme oder Chancen bei Produkten mit niedriger und hoher Gewinnspanne hinweisen und über die Segmentierung der Kunden in mehr und weniger profitable Kunden sprechen. Produkt- und ML-Ingenieure werden ebenfalls involviert sein und darüber nachdenken, was mit all diesen Daten zu tun ist, und Site Reliability Engineers (SREs) werden Empfehlungen und Entscheidungen über die gesamte Pipeline treffen, um sie überwachbarer, handhabbarer und zuverlässiger zu machen.
Die Verwaltung von Daten für ML ist ein so umfangreiches Thema, dass wir Kapitel 2 den Grundsätzen der Datenverwaltung gewidmet haben und später in den Kapiteln 4 und 10 auf Trainingsdaten eingehen. Für den Moment ist es sinnvoll, davon auszugehen, dass die richtige Gestaltung und Verwaltung eines Datenerfassungs- und -verarbeitungssystems das Herzstück eines jeden guten ML-Systems ist. Sobald wir die Daten an einem geeigneten Ort und in einem geeigneten Format haben, werden wir damit beginnen, ein Modell zu trainieren.
ML Training Pipelines
ML-Trainings-Pipelines werden von Dateningenieuren, Datenwissenschaftlern, ML-Ingenieuren und SREs spezifiziert, entwickelt, gebaut und genutzt. Sie sind spezielle Extrahier-, Transformier- und Ladepipelines (ETL) für die Datenverarbeitung, die die unverarbeiteten Daten lesen und den ML-Algorithmus und die Struktur unseres Modells auf die Daten anwenden.1 Ihre Aufgabe ist es, die Trainingsdaten zu verarbeiten und fertige Modelle zu erstellen, die dann ausgewertet und verwendet werden können. Einige Modelle sind unvollständig, da sie nur einen Teil der verfügbaren Daten abdecken, und andere sind unvollständig, da sie nur einen Teil des gesamten ML-Lernprozesses abdecken sollen.
Trainingspipelines sind einer der einzigen Teile unseres ML-Systems, die direkt und explizit ML-spezifische Algorithmen verwenden, obwohl diese auch hier meist in relativ ausgereiften Plattformen und Frameworks wie TensorFlow und PyTorch verpackt sind.
Die Trainingspipelines sind auch einer der wenigen Teile unseres ML-Systems, bei dem die Auseinandersetzung mit diesen algorithmischen Details zunächst unvermeidlich ist. Nachdem die ML-Ingenieure eine Trainingspipeline erstellt und validiert haben - wahrscheinlich unter Verwendung relativ ausgereifter Bibliotheken - kann die Pipeline von anderen wiederverwendet werden, ohne dass diese direkte statistische Fachkenntnisse benötigen.2
Trainingspipelines haben die gleichen Zuverlässigkeitsprobleme wie alle anderen Datenumwandlungspipelines und darüber hinaus noch einige ML-spezifische. Die häufigsten Ausfälle von ML-Trainingspipelines sind folgende:
Mangel an Daten
Mangel an korrekt formatierten Daten
Softwarefehler oder Fehler bei der Implementierung des Datenparsing- oder ML-Algorithmus
Pipeline oder Modell falsch konfiguriert
Mangel an Ressourcen
Hardware-Ausfälle (relativ häufig, weil ML-Berechnungen so groß und langwierig sind)
Ausfälle von verteilten Systemen (die oft entstehen, weil du für die Ausbildung auf ein verteiltes System umgestiegen bist, um Hardwareausfälle zu vermeiden)
All diese Fehler sind auch charakteristisch für die Fehlermodi einer normalen (nicht-ML) ETL-Datenpipeline. ML-Modelle können jedoch aus Gründen der Datenverteilung, fehlender Daten, zu geringer Stichprobengröße oder einer ganzen Reihe von Problemen fehlschlagen, die in der normalen ETL-Welt unbekannt sind.3 Ein konkretes Beispiel, auf das in Kapitel 2 näher eingegangen wird, beruht auf der Idee, dass fehlende, falsch verarbeitete oder anderweitig nicht verwendbare Teilmengen von Daten eine häufige Ursache für das Scheitern von ML-Trainingspipelines sind. In den Kapiteln 7 und 9 werden wir darüber sprechen, wie wir Trainingspipelines überwachen und diese Art von Problemen (im Allgemeinen als Verteilungsverschiebungen bekannt) erkennen können. Erinnern wir uns einfach daran, dass ML-Pipelines wirklich etwas schwieriger zu betreiben sind als andere Datenpipelines, weil es diese Art von subtilen Fehlerquellen gibt.
Falls es noch nicht klar ist: ML-Trainings-Pipelines sind absolut und vollständig ein Produktionssystem, das die gleiche Sorgfalt und Aufmerksamkeit verdient wie die Bereitstellung von Binärdateien oder die Datenanalyse. (Falls du dich in einer Umgebung befindest, in der außer dir niemand daran glaubt, ist es ein schwacher Trost zu wissen, dass es genug Gegenbeispiele geben wird, um jeden zu überzeugen - irgendwann.) Als Beispiel dafür, was passieren kann, wenn du der Produktion nicht genügend Aufmerksamkeit schenkst, kennen wir Geschichten über Unternehmen, die auf Modellen aufgebaut sind, die von Praktikanten erstellt wurden, die nun das Unternehmen verlassen haben und niemand weiß, wie man sie neu erstellen kann. Es ist wahrscheinlich oberflächlich, das zu sagen, aber wir empfehlen dir, niemals in diese Situation zu geraten. Wenn du es dir zur Gewohnheit machst, deine Arbeit aufzuschreiben und sie zu automatisieren, kannst du das vermeiden. Die gute Nachricht ist, dass es durchaus möglich ist, klein anzufangen, mit manuellen Vorgängen und ohne besondere Anforderungen an die Reproduzierbarkeit. Unserer Meinung nach ist es umso besser, je früher du dazu übergehen kannst, deine Modellschulung zu automatisieren und durch einfache Prüfungen auf Korrektheit und Erhaltung des Modells zu kontrollieren.
In jedem Fall müssen wir, wenn wir ein Modell erfolgreich erstellen können, es in die kundenorientierte Umgebung integrieren.
Anwendungen erstellen und validieren
Ein ML-Modell ist im Grunde ein Satz von Software Fähigkeiten, die freigeschaltet werden müssen, um einen Mehrwert zu bieten. Du kannst nicht einfach auf das Modell starren, du musst es abfragen - ihm Fragen stellen. Am einfachsten ist es, einen direkten Mechanismus zur Verfügung zu stellen, mit dem man die Vorhersagen nachschlagen kann (oder einen Bericht über einen anderen Aspekt des Modells). Meistens müssen wir jedoch etwas Komplizierteres einbinden: Welchen Zweck das Modell auch immer erfüllen soll, wird in der Regel am besten durch die Integration des Modells in ein anderes System erfüllt. Die Integration in unsere Anwendungen wird von Mitarbeitern in unseren Produkt- und Geschäftsfunktionen festgelegt, von ML-Ingenieuren und Softwareentwicklern durchgeführt und von Qualitätsanalysten überwacht. Weitere Einzelheiten dazu findest du in Kapitel 12.
Nehmen wir yarnit.ai, unsere Online-Einkaufsseite, auf der Menschen aus allen Gesellschaftsschichten und aus der ganzen Welt das beste Garn zum Stricken oder Häkeln finden können, und zwar mit KI-basierten Empfehlungen! Betrachten wir als Beispiel ein Modell, das einem Kunden weitere Einkäufe empfiehlt. Dieses Modell könnte die Einkaufshistorie eines Nutzers sowie die Liste der Produkte, die sich derzeit in seinem Einkaufswagen befinden, zusammen mit anderen Faktoren wie dem Land, in das normalerweise geliefert wird, der Preisspanne, in der er normalerweise einkauft, und so weiter berücksichtigen. Das Modell könnte diese Merkmale nutzen, um eine Rangliste der Produkte zu erstellen, die der Kunde in Erwägung ziehen könnte.
Um dem Unternehmen und den Nutzern einen Mehrwert zu bieten, müssen wir dieses Modell in die Website selbst integrieren. Wir müssen entscheiden, wo wir das Modell abfragen und was wir mit den Ergebnissen machen wollen. Eine einfache Lösung könnte sein, einige Ergebnisse in einer horizontalen Liste direkt unter dem Warenkorb anzuzeigen, wenn ein Nutzer überlegt, ob er zur Kasse gehen soll. Das scheint ein vernünftiger erster Schritt zu sein, der den Kunden einen gewissen Nutzen bringt und YarnIt möglicherweise ein paar zusätzliche Einnahmen verschafft.
Um festzustellen, wie gut unsere Integration funktioniert, sollte das System protokollieren, was es anzeigt und ob die Nutzer/innen etwas tun - legen sie Artikel in ihren Warenkorb und kaufen sie schließlich? Durch die Aufzeichnung solcher Ereignisse liefert die Integration neues Feedback für unser Modell, sodass es die Qualität seiner eigenen Empfehlungen trainieren und verbessern kann.4 In diesem Stadium überprüfen wir jedoch nur, ob das Modell überhaupt funktioniert, d. h. ob es in unser Serving-System geladen wird, ob die Abfragen von unserer Webserver-Anwendung ausgeführt werden, ob die Ergebnisse den Nutzern angezeigt werden, ob die Vorhersagen protokolliert werden und ob die Protokolle für das künftige Modelltraining gespeichert werden. Als Nächstes steht der Prozess der Bewertung der Modellqualität und -leistung an.
Qualität und Leistungsbewertung
ML-Modelle sind natürlich nur nützlich, wenn sie funktionieren. Es stellt sich heraus, dass erstaunlich viel Detailarbeit nötig ist, um diese Frage tatsächlich zu beantworten - angefangen bei dem fast schon amüsanten, aber absolut wahren Punkt, dass wir entscheiden müssen, was als funktionierend gilt und wie wir die Leistung des Modells im Hinblick auf dieses Ziel bewerten wollen. Dazu müssen wir in der Regel den Effekt bestimmen, den wir erzielen wollen, und ihn in verschiedenen Untergruppen (oder Slices) von repräsentativen Abfragen oder Anwendungsfällen messen. Dies wird in Kapitel 5 ausführlicher behandelt.
Wenn wir uns entschieden haben, was wir auswerten wollen, sollten wir den Prozess zunächst offline durchführen. Die einfachste Art, sich das vorzustellen, ist, dass wir eine unserer Meinung nach repräsentative Reihe von Abfragen stellen und die Ergebnisse analysieren, indem wir die Antworten mit einer angenommenen Reihe von "richtigen" oder "wahren" Antworten vergleichen. So können wir feststellen, wie gut das Modell in der Produktion funktionieren sollte. Sobald wir ein gewisses Vertrauen in die grundsätzliche Leistungsfähigkeit des Modells haben, können wir eine erste Integration durchführen, entweder live oder im Dunkeln, indem wir das System starten. Beim Live-Launch nimmt das Modell den Produktionsverkehr auf, wirkt sich auf die Website und die abhängigen Systeme aus und so weiter. Wenn wir vorsichtig sind oder Glück haben, ist dies ein vernünftiger Schritt, solange wir die wichtigsten Kennzahlen überwachen, um sicherzustellen, dass wir das Nutzererlebnis nicht beeinträchtigen.
Bei einem "Dark Launch" wird das Modell von konsultiert und das Ergebnis protokolliert, aber nicht aktiv auf der Website verwendet, so wie die Nutzer es sehen. Das kann uns Vertrauen in die technische Integration des Modells in unsere Webanwendung geben, aber es wird uns wahrscheinlich nicht viel Vertrauen in die Qualität des Modells geben.
Schließlich gibt es noch einen Mittelweg: Wir könnten in unserer Anwendung die Fähigkeit einbauen, das Modell nur manchmal für einen Bruchteil der Nutzer zu verwenden. Die Auswahl dieses Anteils ist ein erstaunlich fortgeschrittenes Thema, das den Rahmen dieses Buches sprengen würde,5 Der Grundgedanke ist einfach: Wir probieren das Modell an einigen Abfragen aus und gewinnen Vertrauen in die Integration und die Qualität des Modells.
Sobald wir uns sicher sind, dass das Modell keinen Schaden anrichtet und unseren Nutzern hilft (und hoffentlich auch unseren Einnahmen!), sind wir fast bereit für den Start. Aber zuerst müssen wir uns auf die Überwachung, Messung und kontinuierliche Verbesserung konzentrieren.
Definieren und Messen von SLOs
Service-Level-Ziele(SLOs) sind vordefinierte Schwellenwerte für bestimmte Messungen, oft bekannt als Service-Level-Indikatoren(SLIs), die festlegen, ob das System die Anforderungen erfüllt. Ein konkretes Beispiel ist "99,99 % der HTTP-Anfragen werden innerhalb von 150 ms erfolgreich abgeschlossen (mit einem 20-fachen Code)." SLOs sind die natürliche Domäne von SREs, aber auch für Produktmanager/innen, die festlegen, was das Produkt leisten muss und wie es seine Nutzer/innen behandelt, sowie für Datenwissenschaftler/innen, ML-Ingenieure/innen und Softwareentwickler/innen sind sie entscheidend. SLOs zu spezifizieren ist generell eine Herausforderung, aber bei ML-Systemen ist es noch schwieriger, da selbst kleinste Veränderungen in den Daten oder in der Welt um uns herum die Leistung des Systems erheblich beeinträchtigen können.
Dennoch können wir offensichtliche Trennungen nutzen, um über SLOs für ML-Systeme nachzudenken. Erstens können wir die Unterteilung in Servicing, Training und die Anwendung selbst nutzen. Zweitens können wir zwischen den traditionellen goldenen vier Signalen (Latenz, Traffic, Fehler, Sättigung) und den Interna von ML-Operationen unterscheiden, die zwar weniger allgemein sind als die goldenen Signale, aber immer noch nicht völlig domänenspezifisch. Drittens gibt es SLOs, die sich auf die Funktionsweise der ML-erweiterten Anwendung selbst beziehen.
Schauen wir uns konkret einige sehr einfache Vorschläge an , wie diese Ideen über SLOs direkt auf yarnit.ai angewendet werden können. Wir sollten für jedes System eigene SLOs haben: für die Bedienung, das Training und die Anwendung. Für die Bedienung des Modells könnten wir uns einfach die Fehlerquoten ansehen, so wie wir es bei jedem anderen System auch tun würden. Für das Training sollten wir uns den Durchsatz ansehen (Beispiele pro trainierter Sekunde oder vielleicht Bytes an trainierten Daten, wenn unsere Modelle alle eine vergleichbare Komplexität haben). Wir könnten auch einen allgemeinen SLO für den Abschluss des Modelltrainings festlegen (z. B. 95% der Trainingsläufe innerhalb einer bestimmten Anzahl von Sekunden). Und in der Anwendung sollten wir wahrscheinlich Kennzahlen wie die Anzahl der angezeigten Empfehlungen und die erfolgreichen Aufrufe der Modellserver überwachen (aus Sicht der Anwendung, die mit der Fehlerquote des Modellservers übereinstimmen kann oder auch nicht).
Beachte jedoch, dass es in keinem dieser Beispiele um die ML-Leistung der Modelle geht. Dafür müssen wir SLOs festlegen, die sich auf den Geschäftszweck der Anwendungen selbst beziehen, und die Messung könnte über wesentlich längere Zeiträume erfolgen. Gute Ausgangspunkte für unsere Website wären wahrscheinlich die Klickrate bei modellgenerierten Vorschlägen und die Suchergebnisse mit Modell-Ranking. Wir sollten wahrscheinlich auch einen End-to-End-SLO für die dem Modell zurechenbaren Umsätze festlegen und diese nicht nur insgesamt, sondern auch in angemessenen Teilbereichen unserer Kunden (nach Region oder möglicherweise nach Kundentyp) messen.
In Kapitel 9 gehen wir näher darauf ein, aber für den Moment bitten wir dich zu akzeptieren, dass es vernünftige Wege gibt, SLOs für einen ML-Kontext zu finden, und dass sie viele der gleichen Techniken beinhalten, die auch in SLO-Gesprächen außerhalb von ML verwendet werden (obwohl die Details, wie ML funktioniert, solche Gespräche wahrscheinlich länger machen werden). Aber lass dich von der Komplexität nicht von den Grundlagen ablenken. Letztendlich ist es entscheidend, dass die Produkt- und Geschäftsverantwortlichen festlegen, welche SLOs sie tolerieren können und welche nicht, damit sich die Ressourcen der Produktionstechnik im Unternehmen auf die Erreichung der richtigen Ziele konzentrieren.
Sobald wir die Daten gesammelt, das Modell erstellt, in unsere Anwendung integriert, seine Qualität gemessen und die SLOs festgelegt haben, sind wir bereit für die aufregende Phase des Starts!
Start
Wir bekommen jetzt zum ersten Mal direkten Input von Kunden! Hier arbeiten Produkt-Software-Ingenieure, ML-Ingenieure und SREs zusammen, um eine aktualisierte Version unserer Anwendung an unsere Endnutzer zu liefern. Wenn wir mit einer computer- oder mobilbasierten Anwendung arbeiten würden, würde dies eine Softwarefreigabe und alle Qualitätstests beinhalten, die diese Art von Freigaben mit sich bringen. In unserem Fall geben wir jedoch eine neue Version der Website heraus, die die Empfehlungen und Ergebnisse unserer ML-Modelle enthält.
Der Start einer ML-Pipeline ( ) hat viele Gemeinsamkeiten mit dem Start jedes anderen Online-Systems, aber es gibt auch eine ganze Reihe von Problemen, die speziell für ML-Systeme gelten. Allgemeine Empfehlungen zum Start von Online-Systemen findest du in Kapitel 32 von Site Reliability Engineering: How Google Runs Production Systems, herausgegeben von Betsy Beyer et al. (O'Reilly, 2016). Du solltest auf jeden Fall dafür sorgen, dass die Grundlagen der Überwachung/Beobachtbarkeit, der Kontrolle von Releases und des Rollbacks abgedeckt sind - es ist gefährlich, mit einem Launch fortzufahren, für den es keinen definierten Rollback-Plan gibt. Wenn deine Infrastruktur kein einfaches oder gar kein Rollback zulässt, empfehlen wir dir dringend, dieses Problem vor dem Start zu lösen. Auf einige ML-spezifische Probleme gehen wir im Folgenden unter näher ein.
Modelle als Code
Erinnere dich daran, dass Modelle genauso Code sind wie die Binärdateien deines Trainingssystems, der Serving-Pfad und der Datenverarbeitungscode. Der Einsatz eines neuen Modells kann dein Serving-System zum Absturz bringen und deine Online-Empfehlungen ruinieren. Der Einsatz neuer Modelle kann sich sogar auf das Training in einigen Systemen auswirken (z. B. wenn du Transfer Learning verwendest, um das Training mit einem anderen Modell zu beginnen). Es ist wichtig, die Einführung von Code und Modellen ähnlich zu behandeln: Auch wenn einige Unternehmen neue Modelle (z. B.) während der Ferienzeit einführen, ist es durchaus möglich, dass die Modelle schief gehen. Unserer Meinung nach ist das Risiko für beide gleich hoch und sollte entsprechend gemildert werden.
Langsam starten
Wenn wir eine neue Version eines Online-Systems einführen, können wir dies oft schrittweise tun, indem wir mit einem Bruchteil aller Server oder Nutzer/innen beginnen und erst mit der Zeit aufstocken, wenn wir Vertrauen in das korrekte Verhalten unseres Systems und die Qualität unserer ML-Verbesserungen gewinnen. Hier versuchen wir, den Schaden zu begrenzen und Vertrauen in zwei Dimensionen zu gewinnen: Nutzer und Server. Wir wollen nicht alle Nutzer/innen einem schrecklichen System oder Modell aussetzen, wenn wir es zufällig entwickelt haben; stattdessen zeigen wir es zunächst einer kleinen Gruppe von Endnutzer/innen und erweitern es dann schrittweise. Analog dazu wollen wir bei unserer Serverflotte nicht unsere gesamte Rechenkapazität auf einmal riskieren, wenn wir ein System gebaut haben, das nicht oder nicht gut läuft.
Der kniffligste Aspekt dabei ist sicherzustellen, dass das neue System das alte System während der Einführung nicht beeinträchtigen kann. Bei ML-Systemen geschieht dies in der Regel über Artefakte der Zwischenspeicherung. Insbesondere Formatänderungen und Änderungen der Semantik führen zu Fehlern bei der Interpretation der Daten. Diese werden in Kapitel 2 behandelt.
Freigeben, nicht refaktorisieren
Das allgemeine Gebot, so wenig wie möglich auf einmal zu ändern, gilt für viele Systeme, ist aber bei ML-Systemen besonders akut. Das Verhalten des Gesamtsystems ist so anfällig für Veränderungen (z. B. durch Änderungen der zugrunde liegenden Daten), dass ein Refactoring, das in jedem anderen Kontext trivial wäre, es unmöglich machen kann, herauszufinden, was falsch läuft.
Rollouts auf der Datenebene isolieren
Bei einem schrittweisen Rollout solltest du dich daran erinnern, dass die Isolierung sowohl auf der Datenebene als auch auf der Code-/Anfrage-/Serving-Ebene erfolgen muss. Wenn ein neues Modell oder Serving-System Ausgaben protokolliert, die von älteren Versionen des Codes oder Modells verbraucht werden, kann die Diagnose von Problemen langwierig und schwierig sein.
Das ist nicht nur ein ML-Problem, und das Versäumnis, die Daten eines neuen Codepfads von einem älteren Codepfad zu isolieren, hat in den letzten Jahren für einige spannende Ausfälle gesorgt. Das kann jedem System passieren, das Daten verarbeitet, die von einem anderen Element des Systems erzeugt wurden, obwohl die Fehler in ML-Systemen eher subtiler und schwerer zu erkennen sind.
SLOs während der Einführung messen
Stelle sicher, dass du mindestens ein Dashboard hast, das die aktuellsten und sensibelsten Kennzahlen anzeigt, und behalte diese während des Starts im Auge. Wenn du herausgefunden hast, welche Kennzahlen dir am wichtigsten sind und welche am ehesten auf einen Fehlstart hindeuten, kannst du diese in einem Dienst kodieren, der deinen Start automatisch stoppt, wenn es in Zukunft schlecht läuft.
Überprüfe die Markteinführung
Stelle entweder manuell oder automatisch sicher, dass jemand oder etwas während eines Starts jeglicher Art aufpasst. Kleinere Organisationen oder größere (oder ungewöhnlichere) Starts sollten wahrscheinlich von Menschen überwacht werden. Wenn du, wie bereits erwähnt, Vertrauen gewinnst, kannst du dich auf automatisierte Systeme verlassen, die diese Aufgabe übernehmen und so die Startrate deutlich erhöhen!
Überwachung und Rückkopplungsschleifen
Wie bei jedem anderen verteilten System ist die Information über die korrekte oder inkorrekte Funktionsweise unseres ML-Systems der Schlüssel zu seinem effektiven und zuverlässigen Betrieb. Die primären Ziele des "korrekten" Funktionierens zu ermitteln, ist nach wie vor eindeutig Aufgabe der Produkt- und Geschäftsmitarbeiter. Dateningenieure identifizieren Signale, und Softwareentwickler und SREs helfen bei der Implementierung der Datenerfassung, Überwachung und Alarmierung.
Dies steht in engem Zusammenhang mit der SLO-Diskussion, da die Überwachungssignale oft direkt in die Auswahl oder Erstellung von SLOs einfließen. Hier gehen wir etwas tiefer in die Kategorien ein:
- Gesundheit des Systems, oder goldene Signale
- Diese unterscheiden sich nicht von allen anderen Signalen, die nicht von ML stammen. Betrachte das End-to-End-System als ein System zur Datenaufnahme, -verarbeitung, und -bereitstellung und überwache es entsprechend. Laufen die Prozesse? Machen sie Fortschritte? Kommen neue Daten an? Und so weiter (mehr dazu erfährst du in Kapitel 9). Es ist leicht, sich von der Komplexität von ML ablenken zu lassen. Es ist jedoch wichtig, sich daran zu erinnern, dass ML-Systeme genau das sind: Systeme. Sie haben die gleichen Fehlerquellen wie andere verteilte Systeme, aber auch einige neue. Vergiss die Grundlagen nicht, und das ist die Idee hinter dem Golden Signal-Ansatz für die Überwachung: Finde allgemeine, übergeordnete Messgrößen, die für das Systemverhalten insgesamt repräsentativ sind.
- Grundlegende Modellgesundheit oder generische ML-Signale
- Überprüfung der grundlegenden Modellgesundheit Metriken sind das ML-Äquivalent zur Systemgesundheit: Sie sind nicht besonders ausgefeilt oder eng an die Domäne gekoppelt, enthalten aber grundlegende und repräsentative Fakten über das Modellierungssystem. Haben neue Modelle die erwartete Größe? Können sie ohne Fehler in unser System geladen werden? Das wichtigste Kriterium in diesem Fall ist, ob du den Inhalt des Modells verstehen musst, um die Überwachung durchführen zu können; wenn nicht, ist die Überwachung, die du durchführst, eine Frage der grundlegenden Modellgesundheit. Dieser kontextfreie Ansatz ist von großem Nutzen.
- Modellqualität oder domänenspezifische Signale
- Das Schwierigste, was und Instrument zu überwachen ist, ist die Modellqualität. Es gibt keine klare Grenze zwischen einem betriebsrelevanten Problem mit der Modellqualität und einer Möglichkeit zur Verbesserung der Modellqualität. Wenn unser Modell z. B. schlechte Empfehlungen für Leute ausspricht, die auf unserer Website zwar Nadeln, aber kein Garn kaufen, könnte das eine Gelegenheit sein, unser Modell zu verbessern (wenn wir uns dafür entschieden haben, mit diesem Qualitätsniveau zu starten), oder es könnte ein dringender Vorfall sein, der sofortige Maßnahmen erfordert (wenn es sich um einen kürzlichen Rückschritt handelt).7 Der Unterschied ist der Kontext. Das ist auch der schwierigste Aspekt von ML-Systemen, mit dem sich die meisten SREs auseinandersetzen müssen: Es gibt kein objektives Maß für "gut genug" für die Modellqualität, und, was noch schlimmer ist, es ist ein mehrdimensionaler Raum, der schwer zu messen ist. Letztendlich müssen die Produkt- und Unternehmensverantwortlichen reale Messgrößen festlegen, die anzeigen, ob die Modelle ihren Anforderungen entsprechen, und die ML-Ingenieure und SREs müssen zusammenarbeiten, um zu bestimmen, welche Qualitätsmaßstäbe am direktesten mit diesen Ergebnissen korrelieren.
Als letzten Schritt in der Schleife müssen wir sicherstellen, dass die Art und Weise, wie unsere Endnutzer mit den Modellen interagieren, in die nächste Runde der Datenerfassung einfließt und bereit ist, die Schleife erneut zu durchlaufen. ML-Servicesysteme sollten alles protokollieren, was sie für nützlich halten, damit sie sich in Zukunft verbessern können. In der Regel sind das zumindest die Anfragen, die sie erhalten haben, die Antworten, die sie gegeben haben, und etwas darüber, warum sie diese Antworten gegeben haben. Das "Warum" kann so einfach sein wie ein eindimensionaler Relevanzwert oder es kann eine komplexere Reihe von Faktoren sein, die in eine Entscheidung einfließen.
Wir haben unsere erste Runde gedreht und sind bereit, von vorne zu beginnen. Zu diesem Zeitpunkt sollte yarnit.ai zumindest über eine minimale ML-Funktionalität verfügen und wir sollten in der Lage sein, es kontinuierlich zu verbessern, indem wir entweder die ersten Modelle verbessern oder andere Aspekte der Website identifizieren, die mit ML verbessert werden können.
Lektionen aus dem Loop
Es sollte jetzt klar sein, dass ML mit Daten beginnt und endet. Eine erfolgreiche und zuverlässige Integration von ML in ein Unternehmen oder eine Anwendung ist nicht möglich, ohne die Daten zu verstehen, die du hast, und die Informationen, die du aus ihnen extrahieren kannst. Damit das alles funktioniert, müssen wir die Daten zähmen.
Es sollte auch klar sein, dass es keine einheitliche Reihenfolge für die Implementierung von ML in einem bestimmten Umfeld gibt. In der Regel ist es sinnvoll, mit den Daten zu beginnen, aber von dort aus musst du jede dieser Funktionsstufen besuchen und sie möglicherweise sogar noch einmal besuchen. Die Probleme, die wir lösen wollen, bestimmen die Daten, die wir brauchen. Die dienende Infrastruktur gibt uns Aufschluss über die Modelle, die wir erstellen können. Die Schulungsumgebung schränkt die Art der Daten ein, die wir verwenden werden, und die Menge der Daten, die wir verarbeiten können. Datenschutz und ethische Grundsätze prägen jede dieser Anforderungen. Der Prozess der Modellerstellung erfordert einen ganzheitlichen Blick auf den gesamten Kreislauf, aber auch auf die gesamte Organisation selbst. In der ML-Domäne ist eine strikte Trennung der Bereiche weder möglich noch sinnvoll.
Hinter all dem verbirgt sich die Frage nach dem Entwicklungsstand des Unternehmens und der Risikotoleranz in Bezug auf ML. Nicht alle Unternehmen sind bereit, massiv in diese Technologien zu investieren und ihre kritischen Geschäftsfunktionen auf unbewährte Algorithmen zu setzen - und das sollten sie auch nicht! Selbst für Unternehmen mit viel Erfahrung mit ML und der Fähigkeit, die Qualität und den Wert von Modellen zu bewerten, sollten die meisten neuen ML-Ideen zunächst ausprobiert werden, denn die meisten neuen ML-Ideen funktionieren nicht. In vielerlei Hinsicht wird ML-Engineering am besten als kontinuierliches Experiment betrachtet, bei dem inkrementelle Änderungen und Optimierungen vorgenommen werden, um zu sehen, was sich bewährt, indem die Erfolgskriterien mit Hilfe des Produktmanagements bewertet werden. Es ist nicht möglich, ML als deterministischen Entwicklungsprozess zu betrachten, wie es in der Softwareentwicklung heute oft versucht wird. Doch selbst angesichts des grundlegenden Chaos in der heutigen Welt kannst du die Chancen, dass deine ML-Experimente letztendlich funktionieren, erheblich verbessern, wenn du diszipliniert vorgehst, wenn du das erste Experiment durchführst.8
Da die Umsetzung zyklisch erfolgt, kann dieses Buch in fast jeder Reihenfolge gelesen werden. Such dir ein Kapitel aus, das dem am nächsten kommt, was dich im Moment am meisten interessiert, und fang dort an. Dann überlegst du dir, welche Fragen dich am meisten beschäftigen und gehst zu diesem Kapitel über. In allen Kapiteln gibt es umfangreiche Querverweise zu den anderen Kapiteln.
Wenn du ein Leser bist, der in der Reihenfolge liest, ist das auch in Ordnung, und du wirst mit den Daten beginnen. Wer sich dafür interessiert, wie Fairness und Ethik in jedem Teil der Infrastruktur berücksichtigt werden müssen, sollte Kapitel 6 überspringen.
Am Ende des Buches solltest du ein konkretes Verständnis dafür haben, wo du mit der Integration von ML in die Dienstleistungen deiner Organisation beginnen kannst. Du wirst auch einen Fahrplan für die Änderungen haben, die vorgenommen werden müssen, damit dieser Prozess erfolgreich ist.
1 ETL ist eine gängige Abstraktion, um diese Art der Datenverarbeitung darzustellen. Die Wikipedia-Seite "Extrahieren, Transformieren, Laden" bietet einen guten Überblick.
2 Welche ausgereiften Bibliotheken und Systeme wir verwenden, hängt hauptsächlich von der Anwendung ab. Heutzutage werden TensorFlow, JAX und PyTorch häufig für Deep Learning eingesetzt, aber es gibt auch viele andere Systeme, wenn deine Anwendung von einer anderen Art des Lernens profitiert (XGBoost ist zum Beispiel weit verbreitet). Die Auswahl einer Modellarchitektur geht über den Rahmen dieses Buches hinaus, obwohl kleine Teile davon in den Kapiteln 3 und 7 behandelt werden.
3 Mehr dazu findest du in Andrej Karpathys ausgezeichnetem Blogbeitrag "A Recipe for Training Neural Networks" ( 2019).
4 Wenn du das Konzept der A/B-Tests aus dem E-Commerce kennst, ist dies auch ein geeigneter Ort, um sicherzustellen, dass das System für solche Tests als Teil der Integrationstests korrekt funktioniert. Ein großartiger Anwendungsfall ist hier die Unterscheidung des Nutzerverhaltens mit und ohne ML-Vorschläge.
5 Naiverweise könnten wir einfach eine Zufallszahl generieren und 1% davon für das Modell auswählen. Das würde aber bedeuten, dass ein und derselbe Nutzer in ein und derselben Websitzung manchmal vom Modell generierte Empfehlungen erhält und manchmal nicht. Das hilft uns wahrscheinlich nicht dabei, herauszufinden, ob das Modell in allen Aspekten funktioniert, und könnte zu wirklich schlechten Nutzererfahrungen führen. Bei einer Webanwendung könnten wir also 1% aller angemeldeten Nutzer/innen auswählen, um die modellgenerierten Ergebnisse zu erhalten, oder vielleicht 1% aller Cookies. In diesem Fall können wir nicht ohne Weiteres feststellen, wie sich die modellgenerierten Ergebnisse auf die Nutzer/innen auswirken, und es könnte zu Verzerrungen bei der Auswahl der aktuellen Nutzer/innen gegenüber neuen Nutzer/innen kommen. Wir könnten wollen, dass ein und derselbe Nutzer manchmal modellgenerierte Ergebnisse erhält und manchmal nicht, oder wir könnten wollen, dass einige Nutzer dies immer tun, andere aber nur an bestimmten Sitzungen oder Tagen. Der wichtigste Punkt ist, dass die Frage , wie man den Zugang zu den ML-Ergebnissen randomisiert, statistisch etwas kompliziert ist.
6 Der Vollständigkeit halber sei gesagt, dass es auch einen sicheren Weg gibt, ein neues Datenformat einzuführen: Nämlich indem man die Unterstützung für das Lesen des Formats in einem progressiven Rollout hinzufügt, der abgeschlossen ist, bevor das System mit dem Schreiben des Formats beginnt. Das wurde in diesem Fall natürlich nicht gemacht.
7 Vergiss auch die Datendrift nicht: Ein Modell aus dem Jahr 2019 würde eine ganz andere Vorstellung von der Bedeutung und dem Sinn von Gesichtsmasken in den meisten Teilen der Welt haben als ein Modell aus dem Jahr 2020.
8 "Taming the Tail: Adventures in Improving AI Economics" von Martin Casado und Matt Bornstein ist ein Artikel, den du in diesem Zusammenhang lesen solltest.
Get Zuverlässiges 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.
