Kapitel 1. Herausforderungen und bessere Wege bei der Bereitstellung von ML-Lösungen

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

Die gefährlichste Art von Abfall ist der Abfall, den wir nicht erkennen.

Shigeo Shingo, führender Experte für das Toyota Produktionssystem

Nicht alles, mit dem man konfrontiert wird, kann geändert werden, aber nichts kann geändert werden , bis man sich damit auseinandersetzt.

James Baldwin, Schriftsteller und Dramatiker

Viele Einzelpersonen und Organisationen beginnen ihre Reise zum maschinellen Lernen (ML) mit großen Hoffnungen, aber die Erfahrungen vieler ML-Praktiker/innen zeigen uns, dass die Reise zur Bereitstellung von ML-Lösungen mit Fallen, Umwegen und manchmal sogar unüberwindbaren Hindernissen gespickt ist. Hinter dem Hype und den glamourösen Behauptungen, dass Data Science der geilste Job des 21. Jahrhunderts ist, sehen wir oft, dass ML-Praktiker durch mühsame manuelle Arbeit, Feuergefechte in der Produktion, Team-Silos und unhandliche, spröde und komplexe Lösungen festgefahren sind.

Das behindert oder verhindert sogar, dass die Teams den Kunden einen Mehrwert bieten, und frustriert auch die Investitionen und Ambitionen eines Unternehmens in KI. Wie bei Hype-Zyklen üblich, überschreiten viele den Gipfel der überhöhten Erwartungen und landen im Tal der Enttäuschung. Wir könnten sehen, wie einige leistungsstarke ML-Teams das Plateau der Produktivität erreichen und uns fragen, ob wir jemals dort ankommen werden.

Unabhängig von deinem Hintergrund - sei es Wissenschaft, Data Science, ML-Engineering, Produktmanagement, Softwareentwicklung oder etwas anderes - wenn du Produkte oder Systeme entwickelst, die ML beinhalten, wirst du unweigerlich mit den Herausforderungen konfrontiert, die wir in diesem Kapitel beschreiben. In diesem Kapitel versuchen wir, unsere Erfahrungen - und die Erfahrungen anderer - bei der Entwicklung und Bereitstellung von ML-gestützten Produkten zusammenzufassen. Wir hoffen, dass diese Grundsätze und Praktiken dir helfen, unnötige Fallstricke zu vermeiden und einen zuverlässigen Weg für deine Reise zu finden.

Zu Beginn dieses Kapitels stellen wir fest, dass ML in der realen Welt eine doppelte Realität ist: vielversprechend und enttäuschend. Dann untersuchen wir die großen und alltäglichen Herausforderungen, an denen ML-Projekte oft scheitern. Anschließend skizzieren wir einen besseren Weg, der auf den Prinzipien und Praktiken von Lean Delivery, Product Thinking und Agile Engineering basiert. Zum Schluss gehen wir kurz darauf ein, warum diese Praktiken für Teams, die generative KI-Produkte und große Sprachmodelle (LLM) entwickeln, besonders wichtig sind. Betrachte dieses Kapitel als eine Miniaturdarstellung des restlichen Buches.

ML: Versprechen und Enttäuschungen

In diesem Abschnitt sehen wir uns die Belege für das anhaltende Wachstum der Investitionen und des Interesses an ML an, bevor wir uns eingehend mit den Engpässen in den Bereichen Technik, Produkte und Lieferung befassen, die den Ertrag dieser Investitionen behindern.

Anhaltender Optimismus in ML

Lässt man den Hype und unsere individuellen Koordinaten im Hype-Zyklus für einen Moment beiseite, ist KI nach wie vor ein sich schnell entwickelndes Feld, das viele Techniken zur Lösung realer Probleme bietet. Der "AI Index Report 2022" von Stanford hat ergeben, dass sich die weltweiten privaten Investitionen in KI im Jahr 2021 auf rund 94 Milliarden US-Dollar belaufen, was mehr als doppelt so viel ist wie die gesamten privaten Investitionen im Jahr 2019, also noch vor der COVID-19-Pandemie. Die McKinsey-Umfrage "State of AI in 2021" zeigt, dass der Einsatz von KI weiter zunimmt: 56% aller Befragten gaben an, dass KI in mindestens einer Funktion eingesetzt wird, gegenüber 50% im Jahr 2020.

Der Stanford-Bericht zeigt auch, dass Unternehmen weiterhin in die Anwendung verschiedener ML-Techniken investieren - z. B. natürliches Sprachverständnis, Computer Vision, Reinforcement Learning - und zwar in einer Vielzahl von Branchen wie dem Gesundheitswesen, dem Einzelhandel, der Produktion und den Finanzdienstleistungen. Im Hinblick auf Aufträge und Qualifikationen hat die Stanford-Analyse von Millionen von Stellenausschreibungen seit 2010 gezeigt, dass die Nachfrage nach ML-Fähigkeiten in den letzten zehn Jahren stetig gestiegen ist, auch während und nach der COVID-19-Pandemie.

Diese Trends sind zwar aus der Perspektive der Chancen beruhigend, aber sie sind auch höchst besorgniserregend, wenn wir vorankommen, ohne uns den Herausforderungen zu stellen und aus ihnen zu lernen, die uns in der Vergangenheit in die Falle gelockt haben - sowohl die Produzenten als auch die Konsumenten von ML-Systemen. Schauen wir uns diese Fallstricke im Detail an.

Warum ML-Projekte fehlschlagen

Trotz der Vielzahl von Kaggle-Notizbüchern, die in den Charts ganz oben stehen, kommt es häufig vor, dass ML-Projekte in der realen Welt fehlschlagen. Scheitern kann in verschiedenen Formen auftreten, z. B:

Unfähigkeit, ein ML-fähiges Produkt in die Produktion zu bringen
Versand von Produkten, die die Kunden nicht nutzen
Einsatz von fehlerhaften Produkten, denen die Kunden nicht vertrauen
Unfähigkeit, Modelle in der Produktion schnell genug weiterzuentwickeln und zu verbessern

Nur um das klarzustellen - wir versuchen nicht, Misserfolge zu vermeiden. Wie wir alle wissen, ist Scheitern ebenso wertvoll wie unvermeidlich. Wir können eine Menge aus Fehlschlägen lernen. Das Problem entsteht, wenn die Kosten des Scheiterns steigen - verpasste Fristen, nicht erreichte Geschäftsergebnisse und manchmal sogar Kollateralschäden: Schäden für Menschen und der Verlust von Aufträgen und Existenzen vieler Beschäftigter, die nicht einmal direkt mit der ML-Initiative zu tun haben.

Wir wollen kostengünstig und sicher scheitern, und zwar oft, um die Erfolgsaussichten für alle Beteiligten zu verbessern. Außerdem wollen wir aus Fehlschlägen lernen, indem wir zum Beispiel unsere Experimente und Erfahrungen dokumentieren und veröffentlichen, damit wir nicht immer wieder auf dieselbe Weise scheitern. In diesem Abschnitt sehen wir uns einige häufige Herausforderungen an, die unsere Erfolgschancen mindern - in den Bereichen Produkt, Lieferung und Technik. Im nächsten Abschnitt erkunden wir, wie wir die Kosten und die Wahrscheinlichkeit des Scheiterns verringern und effektivere Ergebnisse erzielen können.

Beginnen wir auf einer hohen Ebene und schauen wir uns dann die alltäglichen Hindernisse für den Wertfluss genauer an.

Übersicht auf hoher Ebene: Hindernisse für den Erfolg

Wenn wir auf der Ebene eines ML-Projekts oder eines Arbeitsprogramms betrachten, haben wir erlebt, dass ML-Projekte aufgrund der folgenden Herausforderungen fehlgeschlagen sind, um die gewünschten Ergebnisse zu erzielen:

Es schlägt fehl, das richtige Problem zu lösen oder den Nutzern einen Mehrwert zu bieten

Bei dieser Art des Scheiterns misslingt es uns, die angestrebten Geschäftsergebnisse zu erreichen, selbst wenn wir die richtigen technischen Praktiken anwenden und "das Ding richtig bauen", weil das Team nicht "das richtige Ding gebaut" hat. Das passiert oft, wenn es dem Team an Produktmanagement-Fähigkeiten mangelt oder die Ausrichtung auf Produkt und Geschäft fehlt. Ohne ein ausgereiftes Produktdenken im Team vernachlässigen ML-Teams häufig die Techniken der menschenzentrierten Gestaltung, wie z. B. Benutzertests oder User Journey Mapping, um die Schmerzen, Bedürfnisse und Wünsche der Benutzer/innen zu ermitteln.¹

Herausforderungen bei der Produktion von Modellen

Viele KI-Projekte erblicken nicht das Licht der Welt in der Produktion. Eine Gartner-Umfrage aus dem Jahr 2021 unter rund 200 Geschäfts- und IT-Fachleuten ergab, dass nur 53 % der KI-Projekte von der Pilotphase in die Produktion übergehen, und bei denjenigen, die es schaffen, dauert es im Durchschnitt neun Monate bis dahin.² Die Herausforderungen bei der Umsetzung von ML-Modellen in die Produktion beschränken sich nicht nur auf rechnerische Aspekte wie die Bereitstellung der Modelle, sondern können auch mit den Daten zusammenhängen (z. B. wenn die Inferenzdaten in der Produktion nicht in geeigneter Qualität, Latenz und Verteilung zur Verfügung stehen).

Herausforderungen nach der Produktion von Modellen

Wenn sie erst einmal in Produktion sind, werden ML-Praktiker häufig von Mühsal und Langeweile erdrückt, die iterative Experimente und Modellverbesserungen verhindern. In seinem Bericht "2021 Enterprise Trends in Machine Learning" berichtet Algorithmia, dass 64% der Unternehmen mehr als einen Monat brauchen, um ein neues Modell zu implementieren - ein Anstieg gegenüber 58% im Algorithmia-Bericht für 2020. Der Bericht stellt außerdem fest, dass 38 % der Unternehmen mehr als 50 % der Zeit ihrer Data Scientists für die Implementierung aufwenden - und das wird mit zunehmender Größe immer schlimmer.

Lange oder fehlende Rückkopplungsschleifen

Während der Modellentwicklung sind die Feedbackschleifen oft lang und mühsam, was wertvolle Zeit von wichtigen ML-Produktentwicklungsarbeiten ablenkt. Die wichtigste Methode, um herauszufinden, ob alles funktioniert, besteht darin, ein Trainingsnotizbuch oder -skript manuell auszuführen, zu warten, bis es fertig ist - manchmal stundenlang - und dann manuell durch Protokolle oder gedruckte Anweisungen zu waten, um einige Modellmetriken zu überprüfen, um festzustellen, ob das Modell immer noch so gut ist wie zuvor. Das lässt sich nicht gut skalieren und oft werden wir durch unerwartete Fehler und Qualitätseinbußen während der Entwicklung und sogar in der Produktion behindert.

Viele Modelle werden nicht mit Mechanismen eingesetzt, um aus der Produktion zu lernen - z. B. mit Mechanismen zur Datenerfassung und -kennzeichnung. Ohne diese Rückkopplungsschleife verpassen die Teams die Möglichkeit, die Modellqualität durch datenzentrierte Ansätze zu verbessern.

Spröde und unübersichtliche Codebasen

ML-Codebases sind oft voll von Code Smells - z.B. schlecht benannte Variablen, lange und verschlungene Funktionen, eng gekoppelter Spaghetti-Code - die den Code schwer verständlich und daher schwer zu ändern machen. Die Komplexität und das Risiko von Fehlern und Bugs steigen mit jeder neuen Funktion exponentiell an. Das Ändern oder Erweitern der Codebasis wird zu einer entmutigenden Aufgabe, da die Entwickler die Feinheiten der verworrenen Codebasis und der damit verbundenen Systeme oder Pipelines entschlüsseln müssen.

Wenn das ML-System keine automatisierten Tests hat, wird es noch brüchiger. Außerdem ist das Fehlen von Tests der Nährboden für noch mehr Komplexität, denn niemand will ein Refactoring durchführen, wenn dies bedeutet, dass er versehentlich und unwissentlich Regressionen einführt. Das alles führt zu längeren Entwicklungszyklen und geringerer Produktivität.

Probleme mit der Datenqualität in der Produktion

Wir wollen diesen Punkt mit einem Beispiel illustrieren: Eine Studie im British Medical Journal ergab, dass keines der Hunderte von Prognosemodellen, die entwickelt wurden, um Krankenhäusern bei der Erkennung von COVID-19 zu helfen, tatsächlich funktionierte. Es gab viele Gründe für das Scheitern dieser Modelle, und ein Hauptgrund war die Datenqualität. Einer der Hauptgründe war die Datenqualität. Es gab Datenlecks (die die Modelle besser erscheinen ließen, als sie tatsächlich sind), falsch beschriftete Daten und eine asymmetrische Verteilung zwischen den Trainingsdaten und den tatsächlichen Daten in der Produktion.

Erschwerend kommt hinzu, dass die bereits erwähnten Herausforderungen beim automatisierten Training, der Neubewertung, dem erneuten Testen und dem erneuten Einsatz von Modellen unsere Fähigkeit einschränken, auf die sich im Laufe der Zeit ändernden Datenverteilungen zu reagieren.

Unzureichende Datensicherheit und Datenschutz

Datensicherheit und Datenschutz sind Querschnittsthemen, für die jeder im Unternehmen verantwortlich sein sollte, von den Produktteams bis zu den Datentechnikern und jedem Team dazwischen. Im Zusammenhang mit ML gibt es einige besondere Herausforderungen in Bezug auf Datensicherheit und Datenschutz, die dazu führen können, dass ein Produkt fehlschlägt. Eine dieser Herausforderungen ist das Data Poisoning, bei dem bösartige oder verzerrte Daten in die Trainingsmenge eingespeist werden, um das Modell zu verfälschen. Erinnert euch an den berühmten (oder berüchtigten) Microsoft Tay Chatbot, der bereits einen Tag nach seiner Veröffentlichung vom Netz genommen wurde, weil er aufrührerische und beleidigende Inhalte von Nutzern lernte, die ihn absichtlich darauf trainieren wollten, solche Antworten zu geben. Oder in jüngerer Zeit, mit dem Aufkommen von LLMs, haben wir Eingabeaufforderungen gesehen, die dazu geführt haben, dass Chatbots die Trainingsdaten der Nutzer/innen ausspioniert und die Systemaufforderungen offengelegt haben.

Ethisch problematische ML-Produkte

Man muss nicht lange suchen, um zu sehen, wie ML in der freien Wildbahn schiefgehen kann. Du hast vielleicht schon von Amazons Rekrutierungstool gehört, das Lebensläufe, die das Wort "Frauen" enthalten, bestraft hat (Amazon hat das Tool ein Jahr nach seiner Veröffentlichung wieder abgeschaltet). Ein anderes Beispiel: Eine Benchmark-Analyse von ProPublica ergab, dass ein ML-System zur Vorhersage von Rückfällen bei schwarzen Angeklagten eine doppelt so hohe Falsch-Positiv-Rate aufwies wie bei weißen Angeklagten, und eine doppelt so hohe Falsch-Negativ-Rate bei weißen Angeklagten.

Nachdem wir nun ein umfassendes Bild der Gründe für das Scheitern von ML-Projekten gezeichnet haben, wollen wir einen Blick auf die alltäglichen Herausforderungen werfen, die es ML-Projekten schwer machen, erfolgreich zu sein.

Blick auf die Mikroebene: Alltägliche Erfolgshindernisse

Auf gibt es auf der Mikroebene - also auf der Ebene der Bereitstellung von Funktionen in einem ML-Projekt - mehrere Engpässe, die uns daran hindern, unsere Ideen umzusetzen.

Diese Sichtweise wird am besten deutlich, wenn man eine User Story im agilen Entwicklungslebenszyklus unter zwei Bedingungen gegenüberstellt: einer Umgebung mit geringer Effektivität und einer Umgebung mit hoher Effektivität. Unserer Erfahrung nach sind diese Hindernisse nicht nur auf unsere Herangehensweise an ML und Technik zurückzuführen, sondern auch auf suboptimale Arbeitsabläufe in der Zusammenarbeit und ungeplante Arbeit.

Lebenszyklus einer Geschichte in einer Umgebung mit geringer Effektivität

Reisen wir mit Dana, der Protagonistin unseres Buches und ML-Ingenieurin, in dieses Szenario. Die Figur ist fiktiv, aber der Schmerz ist real:

Dana beginnt ihren Tag damit, dass sie sich sofort mit Warnmeldungen für Probleme in der Produktion und mit Anfragen des Kundensupports beschäftigen muss, warum sich das Modell auf eine bestimmte Weise verhalten hat. Danas Team leidet bereits an Alarmmüdigkeit, was bedeutet, dass sie die eingehenden Alarme oft ignorieren. Dadurch werden das Problem und die Anzahl der täglichen Warnmeldungen nur noch größer.
Dana überprüft eine Reihe von Protokollierungs- und Überwachungssystemen, um das Problem einzugrenzen, da es keine systemübergreifenden Protokolle gibt. Sie befragt das Modell manuell, um eine Erklärung dafür zu finden, warum das Modell diese bestimmte Vorhersage für diesen Kunden getroffen hat. Sie erinnert sich vage daran, dass es im letzten Monat eine ähnliche Kundenanfrage gab, kann aber keine internen Unterlagen darüber finden, wie solche Kundenanfragen gelöst werden.
Dana schickt eine Erinnerung in den Team-Chat, um nach einem Freiwilligen zu fragen, der einen Pull Request überprüft, den sie letzte Woche erstellt hat, damit er zusammengeführt werden kann.
Schließlich löst Dana das Problem und findet etwas Zeit, um zu programmieren und eine Aufgabe von der Wandtafel des Teams zu übernehmen.
Die Codebasis verfügt über keine automatisierten Tests. Nachdem sie also einige Codeänderungen vorgenommen hat, muss Dana das gesamte Trainingsskript oder -notizbuch neu starten und ausführen, die Dauer des Modelltrainings - in ihrem Fall 40 Minuten - abwarten und hoffen, dass es ohne Fehler läuft. Außerdem überprüft sie manuell einige Druckanweisungen am Ende, um sicherzustellen, dass die Modellmetrik nicht gesunken ist. Manchmal versagt der Code auf halbem Weg, weil sich bei der Entwicklung ein Fehler eingeschlichen hat.
Dana möchte eine Kaffeepause machen, hat aber ein schlechtes Gewissen, weil sie zu viel zu tun hat. Also macht sie sich in zwei Minuten einen Kaffee und trinkt ihn an ihrem Schreibtisch, während sie weiterarbeitet.
Während des Programmierens erhielt Dana Kommentare und Fragen zum Pull Request. Ein Kommentar lautete zum Beispiel, dass eine bestimmte Funktion zu lang und schwer zu lesen sei. Dana wechselt daraufhin den Kontext, tippt eine Antwort - ohne notwendigerweise den Code zu aktualisieren - für die Designentscheidungen, die sie letzte Woche getroffen haben, und erwähnt, dass sie beim nächsten Mal eine Storycard zum Refactoring dieser langen Funktion erstellen wird.
Nachdem sie zwei Wochen in eine Lösung investiert hat (ohne Pair Programming), teilt sie diese dem Team mit. Der technische Leiter des Teams stellt fest, dass die Lösung zu viel Komplexität in die Codebasis bringt und neu geschrieben werden muss. Er fügt hinzu, dass die Story ohnehin keine hohe Priorität hatte und dass es eine andere Story gab, die Dana stattdessen bearbeiten kann.

Kannst du dir vorstellen, wie frustriert und demotiviert Dana sein muss? Die langen Feedback-Zyklen und der Kontextwechsel - zwischen ML und anderen lästigen Aufgaben wie der Überprüfung von Pull-Anfragen - schränkten sie in ihrer Leistungsfähigkeit ein. Der Kontextwechsel hatte auch einen echten kognitiven Preis, durch den sie sich erschöpft und unproduktiv fühlten. Manchmal loggen sie sich nach den Bürozeiten wieder ein, weil sie den Druck verspüren, die Arbeit zu beenden - und es gab einfach nicht genug Zeit am Tag, um sie alle zu erledigen.

Lange Rückkopplungsschleifen bei jedem Schritt auf der Mikroebene führen zu einem Gesamtanstieg der Zykluszeit, was zu weniger Experimentier- oder Iterationszyklen an einem Tag führt (siehe Abbildung 1-1). Arbeit und Aufwand werden oft zwischen mehreren Aufgaben hin- und hergeschoben, was zu einem gestörten Arbeitsfluss führt.

Lebenszyklus einer Geschichte in einer hocheffektiven Umgebung

Schauen wir uns unter an, wie unterschiedlich die Dinge für Dana in einer hocheffektiven Umgebung sein können:

Dana beginnt den Tag, indem sie das Projektmanagement-Tool des Teams überprüft und dann am Standup teilnimmt, wo sie eine Story Card abholen kann. Jede Story Card beschreibt den geschäftlichen Wert, der aus der Produktperspektive validiert wurde, und schafft Klarheit darüber, woran sie arbeiten müssen, mit einer klaren Definition von "erledigt".
Dana tut sich mit einem Teamkollegen zusammen, um einen Code zu schreiben, der das Problem auf der Storycard löst. Während sie programmieren, helfen sie sich gegenseitig, ihre blinden Flecken zu entdecken, geben sich gegenseitig Echtzeit-Feedback - z.B. eine einfachere Lösung für ein bestimmtes Problem - und teilen ihr Wissen.
Während sie programmieren, wird jede inkrementelle Codeänderung innerhalb von Sekunden oder Minuten durch automatisierte Tests validiert - sowohl durch bestehende Tests als auch durch neue Tests, die sie schreiben. Sie lassen die gesamte ML-Modell-Trainings-Pipeline lokal auf einem kleinen Datensatz laufen und erhalten innerhalb einer Minute Rückmeldung darüber, ob alles noch wie erwartet funktioniert.
Wenn sie ein vollständiges ML-Modelltraining durchführen müssen, können sie das Training auf einer groß angelegten Infrastruktur von ihrem lokalen Rechner aus mit ihren lokalen Codeänderungen auslösen, ohne dass sie "pushen müssen, um zu wissen, ob etwas funktioniert". Das Modelltraining beginnt dann in einer Umgebung mit dem nötigen Zugang zu Produktionsdaten und skalierbaren Rechenressourcen.
Sie übertragen die Codeänderung, die eine Reihe automatisierter Prüfungen in der Continuous Integration and Continuous Delivery (CI/CD) Pipeline durchläuft, bevor sie ein vollständiges ML-Modelltraining auslöst, das je nach ML-Modellarchitektur und Datenmenge zwischen Minuten und Stunden dauern kann.
Dana und ihr Paar konzentrieren sich einige Stunden lang auf ihre Aufgabe, gespickt mit regelmäßigen Pausen, Kaffee und sogar Spaziergängen (getrennt). Sie können das ohne ein schlechtes Gewissen tun, weil sie wissen, dass sie so besser arbeiten können und weil sie Vertrauen in die Vorhersehbarkeit ihrer Arbeit haben.
Nach Abschluss des Modelltrainings wird automatisch eine Pipeline für den Einsatz des Modells gestartet. Die Deployment-Pipeline führt Qualitätstests für das Modell durch und prüft, ob das Modell in Bezug auf eine Reihe festgelegter Metriken (z. B. Genauigkeit, Präzision) über dem Qualitätsschwellenwert liegt. Wenn die Qualität des Modells zufriedenstellend ist, wird das neu trainierte Modellartefakt automatisch verpackt und in eine Vorproduktionsumgebung bereitgestellt.
Wenn die Definition von "erledigt" auf der Story Card erfüllt ist, informiert Dana das Team, beruft eine 20-minütige Teambesprechung ein, um dem Team den Kontext zu erläutern, und demonstriert, wie die Lösung die Definition von "erledigt" erfüllt. Wenn sie etwas übersehen haben, kann jeder Teammitglied an Ort und Stelle Feedback geben.
Wenn keine weiteren Entwicklungsarbeiten erforderlich sind, setzt ein anderer Teammitglied den "Testhut" auf und bringt eine neue Perspektive ein, um zu prüfen, ob die Lösung die Definition von "fertig" erfüllt. Das Teammitglied kann innerhalb eines angemessenen Zeitrahmens Sondierungs- und High-Level-Tests durchführen, da die meisten, wenn nicht sogar alle Akzeptanzkriterien der neuen Funktion bereits durch automatisierte Tests geprüft wurden.
Wann immer das Unternehmen es wünscht, kann es die Änderungen schrittweise für die Nutzer in der Produktion freigeben und gleichzeitig die Geschäfts- und Betriebskennzahlen überwachen. Da das Team eine gute Testabdeckung beibehalten hat, kann es, wenn die Pipeline grünes Licht gibt, das neue Modell unbesorgt in die Produktion übernehmen.

Dana und ihre Teammitglieder machen täglich schrittweise Fortschritte beim Lieferplan. Die Geschwindigkeit des Teams ist höher und stabiler als in der Umgebung mit geringer Effektivität. Die Arbeit und die Bemühungen fließen im Allgemeinen vorwärts, und Dana verlässt die Arbeit mit einem zufriedenen Gefühl und mit Wind in den Haaren. Huzzah!

Um die Geschichte von zwei Geschwindigkeiten abzuschließen, lass uns herauszoomen und in Abbildung 1-1 die Zeit vergleichen, die benötigt wird, um etwas in einer Umgebung mit hoher Effektivität (obere Reihe) und einer Umgebung mit niedriger Effektivität (untere Reihe) zu erledigen.

Tabelle 1-1 zeigt die Rückkopplungsmechanismen, die eine hocheffektive Umgebung von einer niedrig-effektiven Umgebung unterscheiden. Jede Zeile steht für eine wichtige Aufgabe im Lebenszyklus der Modellentwicklung, und in den Spalten werden die relativen Feedback-Zykluszeiten verglichen.

Tabelle 1-1. Vergleich der Feedback-Mechanismen und der Zeit bis zum Feedback in Umgebungen mit hoher und niedriger Effektivität
Aufgabe	Feedback-Schleifen und Zeit bis zum Feedback für jede Aufgabe (in ungefähren Größenordnungen)
Aufgabe	Hocheffektive Umgebung	Umwelt mit geringer Effektivität
Testen, ob die Codeänderungen wie erwartet funktionieren	Automatisierte Prüfung (~ Sekunden bis Minuten) ⬤⬤	Manuelle Prüfung (~ Minuten bis Stunden) ⬤⬤⬤⬤
Testen, ob die ML-Trainings-Pipeline durchgängig funktioniert	Training Rauchprobe (~ 1 Minute) ⬤⬤	Vollständige Modellschulung (~ Minuten bis Stunden, abhängig von der Modellarchitektur) ⬤⬤⬤⬤⬤
Feedback zu Codeänderungen erhalten	Paarweise Programmierung (~ Sekunden bis Minuten) ⬤⬤	Pull-Reviews (~ Stunden bis Tage) ⬤⬤⬤⬤⬤⬤⬤
Verstehen, ob die Anwendung in der Produktion wie erwartet funktioniert	Überwachung in der Produktion (~ Sekunden - wie es passiert) ⬤	Kundenbeschwerden (~ Tage, oder länger, wenn nicht direkt gemeldet) ⬤⬤⬤⬤⬤⬤⬤

Nachdem wir uns ein Bild von den häufigen Fallstricken bei der Bereitstellung von ML-Lösungen und einer effektiveren Alternative gemacht haben, wollen wir uns nun ansehen, wie Teams von einer Umgebung mit geringer Effektivität zu einer Umgebung mit hoher Effektivität gelangen können.

Gibt es einen besseren Weg? Wie Systemdenken und Lean helfen können

Ein schlechtes System wird einen guten Menschen jedes Mal schlagen.

W. Edwards Deming, Wirtschaftswissenschaftler und Wirtschaftsingenieur

Im vorigen Abschnitt haben wir gesehen, dass Dana in einem Umfeld mit geringer Effektivität mit unnötiger Arbeit und Nacharbeit konfrontiert ist, was zu ständiger Frustration und möglicherweise zum Burnout führt. Die Mühen, die Frustration und das Burnout, mit denen ML-Praktiker/innen oft konfrontiert sind, zeigen, dass unser Arbeitssystem verbessert werden kann.

In diesem Abschnitt werden wir untersuchen, warum MLOps allein nicht ausreicht, um die Effektivität von ML-Praktikern zu verbessern. Wir werden einen Blick auf das Systemdenken werfen, um eine Reihe von Praktiken zu identifizieren, die für eine effektive ML-Leistung erforderlich sind. Dann schauen wir uns die Lean-Prinzipien und -Praktiken an, die uns dabei helfen können, diese Teilsysteme so miteinander zu verbinden, dass Verschwendung reduziert und der Wertfluss maximiert wird.

Du kannst deine Probleme nicht "wegmogeln"

Ein reflexartiger, aber fehlgeleiteter Ansatz zur Verbesserung der Effektivität der ML-Bereitstellung besteht darin, dass Unternehmen auf MLOps-Praktiken und ML-Plattformen zurückgreifen. Sie mögen zwar notwendig sein, aber sie reichen allein nicht aus.

In der Welt der Softwarebereitstellung kannst du deine Probleme nicht mit "DevOps" oder "Plattformen" beseitigen. DevOps hilft dabei, ein Teilsystem (Infrastruktur, Bereitstellung und Betrieb) zu optimieren und zu verwalten, aber andere Teilsysteme (z. B. Softwaredesign, Benutzererfahrung, Lebenszyklus der Softwarebereitstellung) sind genauso wichtig, um großartige Produkte zu liefern .

Auch bei ML kannst du deine Probleme nicht mit MLOps beseitigen. Keine noch so gute MLOps-Praxis und keine noch so gute Plattform kann uns vor der Verschwendung und Nacharbeit bewahren, die aus dem Fehlen von Softwareentwicklungspraktiken (z. B. automatisierte Tests, faktenbasiertes Design usw.) und Produktbereitstellungspraktiken (z. B. Customer Journey Mapping, klare User Stories usw.) resultieren. MLOps und ML-Plattformen werden keine umfassenden Tests für dich schreiben, nicht für dich mit den Nutzern sprechen oder die negativen Auswirkungen von Teamsilos für dich reduzieren.

In einer Studie über 150 erfolgreiche ML-gesteuerte kundenorientierte Anwendungen bei Booking.com, die in strengen randomisierten kontrollierten Studien durchgeführt wurde, kamen die Autoren zu dem Schluss, dass der Schlüsselfaktor für den Erfolg von ein iterativer, hypothesengesteuerter Prozess ist , der mit anderen Disziplinen wie Produktentwicklung, Benutzererfahrung, Informatik, Softwareentwicklung, Kausalschluss und anderen integriert ist. Diese Erkenntnis deckt sich auch mit unserem Ansatz, der auf unserer Erfahrung mit der Bereitstellung zahlreicher ML- und Datenprodukte beruht. Wir haben immer wieder festgestellt, dass für erfolgreiche ML-Projekte ein multidisziplinärer Ansatz erforderlich ist, der diese fünf Disziplinen umfasst: Produkt, Softwareentwicklung, Daten, ML und Lieferung (siehe Abbildung 1-2).

Um den Wert der Kombination dieser fünf Disziplinen zu erkennen - oder die Kosten, die entstehen, wenn man sich nur auf einige Disziplinen konzentriert und andere ignoriert - können wir die Linse des Systemdenkens aufsetzen. Im nächsten Abschnitt werden wir uns ansehen, wie das Systemdenken dazu beitragen kann, die miteinander verbundenen Disziplinen aufzudecken, die für die effektive Bereitstellung von ML-Produkten erforderlich sind.

Das Ganze sehen: Systemisches Denken für eine effektive ML-Bereitstellung

Systemdenken hilft uns, unseren Blick von den einzelnen Teilen eines Systems auf die Beziehungen und Wechselwirkungen zwischen allen Komponenten zu richten, die ein System ausmachen. Das Systemdenken gibt uns mentale Modelle und Werkzeuge an die Hand, mit denen wir Strukturen, die uns nicht gut tun, verstehen und schließlich verändern können, einschließlich unserer mentalen Modelle und Wahrnehmungen.

Du fragst dich vielleicht, warum wir die ML-Produktlieferung als System betrachten sollten? Und was ist überhaupt ein System? Donella H. Meadows, eine Pionierin des Systemdenkens, definiert ein System als eine zusammenhängende Menge von Elementen, die kohärent organisiert sind und etwas bewirken. Ein System muss aus drei Arten von Dingen bestehen: Elementen, Verbindungen und einer Funktion oder einem Zweck.

Lies dir noch einmal im Zusammenhang mit der Bereitstellung von ML-Produkten durch. Ein System muss aus drei Arten von Dingen bestehen (siehe Abbildung 1-3):

Elemente: Wie zum Beispiel Daten, ML-Experimente, Softwareentwicklung, Infrastruktur und Bereitstellung, Nutzer und Kunden sowie Produktdesign und Nutzererfahrung
Zusammenschaltungen: Wie z. B. funktionsübergreifende Zusammenarbeit und ML-Systeme in der Produktion, die Daten für die anschließende Kennzeichnung und Umschulung erzeugen
Eine Funktion oder ein Zweck des ML-Produkts: Zum Beispiel, indem wir den Nutzern helfen, die am besten geeigneten Produkte zu finden

Unsere Fähigkeit, den Informationsfluss in diesen Zusammenhängen zu erkennen und zu optimieren, hilft uns, ML-Produkte effektiv zu liefern. Im Gegensatz dazu werden Teams, die die Entwicklung von ML-Produkten ausschließlich als Daten- und ML-Problem betrachten, eher fehlschlagen, weil die wahre, ganzheitliche Natur des Systems (z. B. die Nutzererfahrung, die für den Erfolg des Produkts entscheidend ist) irgendwann zum Vorschein kommen wird.

Das Systemdenken erkennt an, dass die Komponenten eines Systems miteinander verbunden sind und dass Veränderungen in einem Teil des Systems sich auf den Rest des Systems auswirken können. Das heißt, um ein System wirklich zu verstehen und zu verbessern, müssen wir es als Ganzes betrachten und wissen, wie alle Teile zusammenwirken.

Zum Glück gibt es eine Philosophie, die uns dabei helfen kann, den Informationsfluss zwischen den einzelnen Elementen eines ML-Liefersystems zu verbessern: Lean.

Die fünf Disziplinen, die für eine wirksame ML-Bereitstellung erforderlich sind

In diesem Abschnitt beginnen wir mit einem Crashkurs darüber, was Lean ist und wie es uns helfen kann, ML-Produkte effektiver zu liefern. Dann gehen wir kurz auf die fünf Disziplinen ein, die für die ML-Bereitstellung erforderlich sind - Produkt, Bereitstellung, Softwareentwicklung, Daten und ML - und beschreiben die wichtigsten Prinzipien und Praktiken in jeder Disziplin, die ML-Teams das schnelle Feedback geben, das sie brauchen, um das richtige Produkt zu entwickeln.

Um es gleich vorweg zu nehmen: Jede dieser fünf Disziplinen ist ein eigenes Buch wert - wenn nicht sogar eine ganze Sammlung von Büchern - und die Prinzipien und Praktiken, die wir in diesem Kapitel vorstellen, sind keineswegs erschöpfend. Nichtsdestotrotz bilden sie einen guten Anfang und sind Grundsätze und Praktiken, die wir in jedes ML-Projekt einbringen, um ML-Lösungen effektiv zu entwickeln. In diesem Abschnitt wird unser Weg auf einer hohen Ebene skizziert und wir werden in den restlichen Kapiteln des Buches ins Detail gehen.

Was ist Lean, und warum sollten sich ML-Praktiker dafür interessieren?

Bei ML-Projekten (wie bei vielen anderen Software- oder Datenprojekten) kommt es häufig vor, dass Teams verschiedene Formen von Verschwendung erleben. Vielleicht hast du zum Beispiel Zeit und Mühe investiert, um eine Funktion "fertigzustellen", nur um dann festzustellen, dass die Funktion keinen nachweisbaren Wert für den Kunden hat. Oder du hast vielleicht Tage damit verschwendet, auf ein anderes Team zu warten, weil du es hin- und hergeschickt hast. Oder vielleicht wurde dein Arbeitsfluss unerwartet durch Fehler oder Bugs in deinem Produkt unterbrochen.³ All diese Verschwendungen tragen zu negativen Ergebnissen bei, wie z. B. Verzögerungen bei der Veröffentlichung und verpasste Meilensteine, mehr Arbeit (und das Gefühl, nicht genug Zeit zu haben, um die ganze Arbeit zu erledigen), Stress und folglich eine niedrige Team-Moral.

Wenn du eines dieser negativen Ergebnisse erlebt hast, heißt es zunächst einmal: Willkommen in der Welt der Menschen. Das sind Herausforderungen, die wir persönlich erlebt haben und in gewissem Maße auch weiterhin erleben werden, denn kein System kann 100%ig abfallfrei oder lärmfrei sein.

Zweitens können die Lean-Prinzipien und -Praktiken helfen. Lean ermöglicht es Unternehmen, Kunden besser zu bedienen, indem sie den Kundennutzen ermitteln und effizient Produkte liefern, die die Kundenbedürfnisse erfüllen. Indem sie die Stimme des Kunden in den Entwicklungs- und Lieferprozess einbeziehen, können die Teams die Bedürfnisse der Endnutzer besser verstehen und entsprechende Produkte für sie entwickeln. Lean hilft uns dabei, besser zu werden, was wir tun, und ermöglicht es uns, Verschwendung zu minimieren und den Wert zu maximieren.

Lean-Praktiken haben ihren Ursprung bei Toyota in den 1950er Jahren. Die Philosophie war zunächst als Toyota Production System (TPS) bekannt. James P. Womack und Daniel T. Jones haben sie später in ihrem Buch The Machine That Changed the World (Free Press) verfeinert und als Lean-Prinzipien bekannt gemacht. Die folgenden fünf Lean-Prinzipien (siehe Abbildung 1-4) haben unter anderem die Automobil-, Fertigungs- und IT-Branche verändert:

Grundsatz 1: Wert erkennen: Finde heraus, was für den Kunden am wertvollsten ist und konzentriere dich darauf, diesen Wert zu maximieren.
Prinzip 2: Abbildung des Wertstroms: Identifiziere die Schritte im Prozess, die einen Mehrwert schaffen, und eliminiere die, die keinen Mehrwert schaffen.
Prinzip 3: Fluss schaffen: Rationalisiere den Prozess, um einen reibungslosen und kontinuierlichen Arbeitsfluss zu schaffen.
Prinzip 4: Pull etablieren: Nutze die Kundennachfrage, um die Produktion anzustoßen und Überproduktion zu vermeiden.
Grundsatz 5: Kontinuierliche Verbesserung: Strebe kontinuierlich nach Verbesserungen und beseitige Verschwendung in allen Bereichen der Wertschöpfungskette.

Unsere Erfahrung bei der Bereitstellung von ML-Produkten zeigt, dass Lean uns dazu bringt, wertschöpfende Arbeit zu leisten, die dann eine positive Rückkopplungsschleife aus Kundenzufriedenheit, Teammoral und Lieferdynamik erzeugt. Anstatt beispielsweise neue Funktionen zu entwickeln, nur weil sie neue Technologien beinhalten, identifizieren und priorisieren wir zunächst die Funktionen, die den Nutzern den größten Nutzen bringen (Prinzip 1), und "ziehen" sie in unseren Lieferfluss, sobald die Nachfrage da ist (Prinzip 4). In Fällen, in denen wir dies nicht getan haben, haben wir dagegen Zeit und Mühe investiert, um eine Funktion fertigzustellen, die die Codebasis komplizierter gemacht hat, ohne einen nachweisbaren Wert zu haben. Für diejenigen mit scharfen Lean-Augen: Ja - du hast gerade Verschwendung entdeckt!

Wertstromanalyse (Prinzip 2) ist ein Werkzeug, mit dem wir alle Schritte und Ressourcen, die an der Lieferung einer Werteinheit (z. B. einer Produktfunktion) an die Kunden beteiligt sind, visuell darstellen können. Teams können dieses Werkzeug nutzen, um Verschwendung zu erkennen, darauf hinzuarbeiten, sie zu beseitigen und den Wertfluss zu verbessern (Grundsatz 3).

Um den Wertstrom deines Teams oder Produkts abzubilden, kannst du diese Schritte befolgen:

Bestimme das Produkt oder die Dienstleistung, die abgebildet werden soll. Das kann ein einzelnes Produkt oder ein ganzer Prozess sein.
Identifiziere die Karte des aktuellen Zustands. Erstelle eine visuelle Darstellung des aktuellen Prozesses, einschließlich aller Schritte und Materialien (einschließlich Zeit und Arbeit), die von den Rohstoffen bis zum fertigen Produkt beteiligt sind.
Identifiziere wertschöpfende und nicht wertschöpfende Aktivitäten. Bestimme, welche Schritte einen Mehrwert für das Produkt oder die Dienstleistung darstellen und welche nicht.
Identifiziere Verschwendung. Suche nach Bereichen mit Überproduktion, Wartezeiten, Mängeln, Überbearbeitung, übermäßigem Bestand, unnötiger Bewegung, übermäßigem Transport, unnötigem Einsatz von Rohstoffen und unnötigem Aufwand.
Erstelle eine Karte des zukünftigen Zustands. Gestalte den Prozess auf der Grundlage der Analyse des aktuellen Zustands neu, um Verschwendung zu vermeiden und einen effizienteren Material- und Informationsfluss zu schaffen.
Änderungen umsetzen. Setze den neu gestalteten Prozess in die Praxis um und überwache und verbessere ihn kontinuierlich (Grundsatz 5).

Nachdem wir nun ein grundlegendes Verständnis von Lean haben, wollen wir uns ansehen, wie Lean mit den fünf Disziplinen zusammenwirkt, um eine Reihe von Praktiken zu entwickeln, die ML-Teams helfen können, Feedbackschleifen zu verkürzen und schnell zu einem wertvollen Produkt zu gelangen. Zusammengenommen tragen diese Praktiken dazu bei, mehrere wünschenswerte und sich gegenseitig verstärkende Merkmale in unserem System für die Bereitstellung von ML-Produkten zu schaffen: schnelleres Feedback, billigere und weniger Fehler, vorhersehbare Lieferung und vor allem wertvolle Ergebnisse.

Hinweis

Wenn dir die Erklärungen zu den einzelnen Praktiken in diesem Kapitel zu kurz sind, mach dir keine Sorgen! Im Laufe des Buches werden wir genauer erklären, warum und wie wir diese und andere Methoden bei der Entwicklung von ML-Produkten anwenden.

Die erste Disziplin: Produkt

Ohne die Produktdisziplin kann kein noch so großes Fachwissen in den anderen Disziplinen (z. B. ML, Daten, Softwareentwicklung) einem Team helfen, ML-Produkte effektiv zu entwickeln. Wenn wir die Bedürfnisse der Nutzer/innen und das Geschäftsmodell des Unternehmens nicht verstehen, ist es schwierig, die Zustimmung der Geschäftsleitung zu erhalten, um mit der Arbeit zu beginnen. Selbst wenn die Teams loslegen, kann das Fehlen eines produktorientierten Ansatzes dazu führen, dass sie sich in einem Vakuum von Produktwissen befinden, das schnell mit unbegründeten Annahmen gefüllt wird.

Ohne das Geschäftsmodell und die Kundenbedürfnisse zu verstehen, kann man leicht den Schwung und die Richtung verlieren. Mit einem produktorientierten Ansatz können ML-Teams dagegen mit dem Ziel vor Augen beginnen, ihre Annahmen kontinuierlich überprüfen und sicherstellen, dass sie Lösungen entwickeln, die den Bedürfnissen ihrer Kunden entsprechen.

Mit der Lean-Mentalität erkennen wir, dass alle unsere Ideen auf Annahmen beruhen, die getestet werden müssen, und dass sich viele dieser Annahmen als falsch erweisen können. Lean bietet eine Reihe von Prinzipien und Praktiken, um unsere Hypothesen zu testen, z. B. durch Prototypentests, Safe-to-fail-Experimente und Build-Measure-Learn-Zyklen. Jedes Experiment liefert Erkenntnisse, die uns helfen, fundierte Entscheidungen zu treffen: durchhalten, umschwenken oder aufhören. Wenn wir schlechte Ideen frühzeitig verwerfen, können wir Zeit und Ressourcen sparen und uns auf Ideen konzentrieren, die den Kunden einen Mehrwert bringen. Lean hilft uns, schneller voranzukommen und "Gelegenheiten zu nutzen, indem wir das Richtige zur richtigen Zeit bauen und keine Zeit mehr mit Ideen verschwenden, die nicht wertvoll sind."⁴

Wie Henrik Kniberg von Spotify es ausdrückt: "Produktentwicklung ist nicht einfach. Tatsächlich scheitern die meisten Produktentwicklungsbemühungen, und der häufigste Grund für das Scheitern ist, das falsche Produkt zu bauen."⁵ Dabei geht es nicht darum, Fehlschläge zu vermeiden, sondern schneller und sicherer zu scheitern, indem schnelle Feedbackschleifen geschaffen werden, um Empathie aufzubauen und zu lernen. Schauen wir uns einige Praktiken an, die uns dabei helfen können, dies zu erreichen.

Entdeckung

Discovery ist eine Reihe von Aktivitäten, die uns helfen, das Problem, die Chance und mögliche Lösungen besser zu verstehen. Sie bietet eine Struktur, um Ungewissheit durch schnelle, zeitlich begrenzte, iterative Aktivitäten zu bewältigen, die verschiedene Interessengruppen und Kunden einbeziehen. Wie in Lean Enterprise (O'Reilly) anschaulich dargelegt, beginnt der Prozess der Entwicklung einer gemeinsamen Vision immer mit einer klaren Definition des Problems, denn eine klare Problemstellung hilft dem Team, sich auf das Wesentliche zu konzentrieren und Ablenkungen zu ignorieren.

Discovery macht ausgiebig Gebrauch von visuellen Artefakten, um Ideen zu visualisieren, zu externalisieren, zu diskutieren, zu testen und weiterzuentwickeln. Einige nützliche visuelle Ideenskizzen sind die Lean Canvas und Value Proposition Canvas, und es gibt noch viele andere. Bei der Ideenfindung stellen wir bewusst die Kunden und das Unternehmen in den Mittelpunkt und schaffen viel Raum für die Stimme des Kunden, die wir u. a. durch User Journey Mapping, kontextbezogene Befragungen und Kundeninterviews sammeln, um Hypothesen über die Passung von Problem und Lösung sowie Produkt und Markt unserer Ideen zu formulieren und zu testen.

Im Zusammenhang mit ML helfen uns Discovery-Techniken dabei, den Wert und die Machbarkeit von Lösungsansätzen frühzeitig einzuschätzen, damit wir mit fundiertem Vertrauen in die Umsetzung gehen können. Ein hilfreiches Tool in diesem Zusammenhang ist das Data Product Canvas, das einen Rahmen für die Verbindung zwischen Datenerfassung, ML und Wertschöpfung bietet. Es ist auch wichtig, Discovery zu nutzen, um Erfolgskriterien zu formulieren und eine Einigung zwischen den Beteiligten darüber zu erzielen, wie wir die Zweckmäßigkeit der in Frage kommenden Lösungen bewerten.

InLean Enterprise gibt es ein ausgezeichnetes Kapitel über Discovery, und wir empfehlen dir, es zu lesen, um zu verstehen, wie du Discovery-Workshops in deinem Unternehmen strukturieren und durchführen kannst. Discovery ist auch keine einmalige Aktivität - die Prinzipien können kontinuierlich geübt werden, während wir bauen, messen und lernen, um Produkte zu entwickeln, die die Kunden schätzen.

Prototypentests

Hast du schon von dem Gleichnis von den Keramiktöpfen gehört?⁶ In diesem Gleichnis beauftragte ein Töpferlehrer die Hälfte der Klasse, den bestmöglichen Topf herzustellen, aber nur jeweils einen. Die andere Hälfte der Klasse wurde angewiesen, in der gleichen Zeit so viele Töpfe wie möglich herzustellen. Am Ende produzierte die letztere Gruppe - die den Vorteil hatte, iterativ viele Prototypen zu entwickeln - die höherwertigen Töpfe.

Prototypen ermöglichen es uns, unsere Ideen schnell und kostengünstig mit den Nutzern zu testen und unsere Annahmen und Hypothesen zu bestätigen oder zu widerlegen. Dabei kann es sich um einfache "handgezeichnete" Zeichnungen einer Schnittstelle handeln, mit der die Nutzer interagieren würden, oder um anklickbare interaktive Modelle. In manchen Fällen entscheiden wir uns sogar für "Wizard of Oz"-Prototypen, d. h. ein echtes Produkt, bei dem alle Produktfunktionen hinter den Kulissen manuell ausgeführt werden, ohne dass die Person, die das Produkt benutzt, es merkt.⁷ (Es ist wichtig zu wissen, dass "Wizard of Oz" für das Testen von Prototypen und nicht für den Betrieb von Produktionssystemen gedacht ist. Diese Fehlanwendung, die unverhohlen als "künstliche künstliche Intelligenz" bezeichnet wurde , beinhaltet einen nicht skalierbaren menschlichen Aufwand, um Probleme zu lösen, die KI nicht lösen kann).

Unabhängig davon, welche Methode du wählst, ist das Testen von Prototypen bei der Entwicklung von ML-Produkten besonders nützlich, weil wir Feedback von den Nutzern erhalten können, bevor wir kostspielige Investitionen in Daten, ML und MLOps tätigen. Prototypentests helfen uns, unsere Feedbackschleife von Wochen oder Monaten (Zeit, die wir für die Entwicklung von Daten, ML und MLOps aufwenden) auf Tage zu verkürzen. Das nenne ich mal schnelles Feedback!

Die zweite Disziplin: Lieferung

Wenn die Produktdisziplin sich damit befasst, was wir bauen und warum, spricht die Lieferdisziplin darüber, wie wir unsere Ideen umsetzen. An der Bereitstellung eines ML-Produkts sind mehrere Disziplinen beteiligt: Lieferplanung, Technik, Produkt, ML, Sicherheit, Daten und so weiter. Wir verwenden den Begriff " Lieferung" hier, um die Aspekte der Lieferplanung bei der Entwicklung von ML-Lösungen zu bezeichnen.

Die Lieferdisziplin konzentriert sich in erster Linie auf die Gestaltung, Dimensionierung und Abfolge der Arbeit in drei Horizonten (von nah bis fern): User Stories oder Features, Iterationen und Releases. Es geht auch darum, wie unsere Teams arbeiten und wie sie sich zusammensetzen:

Team Formen
Arbeitsweisen (z. B. Standups und Retrospektiven)
Gesundheit des Teams (z. B. Moral und psychologische Sicherheit)
Risikomanagement bei der Lieferung

Lean erkennt an, dass Talente das wertvollste Kapital eines Unternehmens sind, und die Lieferdisziplin untermauert diese Überzeugung, indem sie Strukturen schafft, die Hindernisse in unseren Arbeitssystemen minimieren und die Beiträge jedes einzelnen Teammitglieds und die kollektive Verantwortung verstärken. Richtig angewandt, können Lieferpraktiken uns helfen, Verschwendung zu reduzieren und den Wertfluss zu verbessern.

Die Lieferung ist ein oft übersehener, aber äußerst wichtiger Aspekt bei der Entwicklung von ML-Produkten. Wenn wir alle anderen Disziplinen richtig machen, aber die Lieferung vernachlässigen, werden wir wahrscheinlich nicht in der Lage sein, unser ML-Produkt rechtzeitig und zuverlässig an die Nutzer zu liefern (wir werden gleich erklären, warum). Dies kann zu einer geringeren Kundenzufriedenheit, einer geringeren Wettbewerbsfähigkeit, verpassten Chancen und letztendlich zum Scheitern der gewünschten Geschäftsergebnisse führen.

Schauen wir uns einige grundlegende Lieferpraktiken an.

Vertikal geschnittene Arbeit

Ein häufiger Fallstrick bei der Bereitstellung von ML ist die horizontale Aufteilung der Arbeit, bei der wir nacheinander funktionale Schichten einer technischen Lösung - z. B. Data Lake, ML-Plattform, ML-Modelle, UX-Schnittstellen - von unten nach oben bereitstellen. Dies ist ein riskanter Ansatz, da die Kunden das Produkt erst nach Monaten oder sogar Jahren erheblicher technischer Investitionen erleben und wertvolles Feedback geben können. Außerdem führt das horizontale Slicing natürlich zu Problemen bei der späten Integration, wenn horizontale Slices zusammenkommen, was das Risiko von Verzögerungen bei der Veröffentlichung erhöht.

Um dies abzumildern, können wir die Arbeit und die Stories vertikal aufteilen. Eine vertikal gegliederte Story ist eine Story, die als eigenständige Wertschöpfungseinheit definiert ist und alle notwendigen Funktionen enthält, von den nutzerorientierten Aspekten (z. B. ein Frontend) bis hin zu den eher backendorientierten Aspekten (z. B. Datenpipelines, ML-Modelle). Die Definition von "Benutzerfreundlichkeit" hängt davon ab, wer deine Benutzer sind. Wenn du zum Beispiel ein Plattformteam bist, das eine ML-Plattform für Datenwissenschaftler/innen entwickelt, kann die benutzerorientierte Komponente ein Kommandozeilentool sein und nicht eine Frontend-Anwendung.

Das Prinzip des vertikalen Slicing gilt auch über einzelne Merkmale hinaus. So sieht das vertikale Slicing in den drei Horizonten der Lieferdisziplin aus:

Auf der Ebene einer Geschichte artikulieren und demonstrieren wir den Geschäftswert jeder Geschichte.
Auf der Ebene einer Iteration planen und priorisieren wir Geschichten, die zusammenhängen, um ein greifbares Ergebnis zu erreichen.
Auf der Ebene eines Releases planen, ordnen und priorisieren wir eine Sammlung von Geschichten, die darauf ausgerichtet ist, einen nachweisbaren Geschäftswert zu schaffen.

Was ist, wenn der minimale vertikale Schnitt nicht gut genug ist?

An dieser Stelle fragst du dich vielleicht, was passiert, wenn der minimale vertikale Ausschnitt die erwartete Modellleistung für die Produktionsfreigabe nicht erfüllen kann? Wenn wir zum Beispiel ein Modell zur Vorhersage von Lagerbeständen trainieren, werden die Vorhersagen des Modells als Grundlage für Entscheidungen über die Lagerhaltung dienen, und fehlerhafte Vorhersagen können potenziell Millionen von Dollar an tatsächlichen Kosten und Einnahmen kosten.

Das ist eine Situation, mit der alle ML-Praktiker unweigerlich konfrontiert werden, und verschiedene Techniken können uns helfen, das Risiko und die Kosten dieses Szenarios zu reduzieren. Wenn wir zum Beispiel Prototypen testen, wie weiter oben in der Produktdisziplin beschrieben, hilft uns das Training von Prototypmodellen dabei, die Machbarkeit und Durchführbarkeit eines ML-Ansatzes zur Lösung des Geschäftsproblems zu testen. Wenn wir dies während der Discovery-Phase so früh und so schnell wie möglich tun, können wir vermeiden, dass wir Wochen und Monate für die Entwicklung eines vertikalen Modells verschwenden, das in einer Sackgasse enden könnte.

Wir können auch die Technik des Framing ML Problems anwenden, bei der wir mit den relevanten Kunden oder Stakeholdern zusammenarbeiten, um die geeignete Verantwortungsgrenze für ein ML-System zu finden. Wenn wir Experimente durchführen, um Ideen zu testen, gewinnen wir Erkenntnisse, die uns sagen, wo und wie ML für die Lösung des Geschäftsproblems geeignet ist (oder nicht). Wir beschreiben das Framing von ML-Problemen ausführlicher im späteren Abschnitt über die ML-Disziplin.

Vertikal gegliederte Teams oder funktionsübergreifende Teams

Ein weiterer häufiger Fallstrick bei der Bereitstellung von ML ist die Aufteilung der Teams nach Funktionen, z. B. indem Data Science, Data Engineering und Product Engineering in getrennten Teams arbeiten. Diese Struktur führt zu zwei Hauptproblemen. Erstens geraten die Teams unweigerlich in Backlog-Kopplung, d.h. ein Team ist von einem anderen Team abhängig, um eine Funktion zu liefern. Eine informelle Analyse ergab, dass die Backlog-Kopplung die Zeit zur Fertigstellung einer Aufgabe im Durchschnitt um das 10- bis 12-fache erhöht.

Das zweite Problem ist die Manifestation des Conway's Law, also das Phänomen, dass Teams Systeme und Software entwickeln, die ihre Kommunikationsstruktur widerspiegeln. Wir haben zum Beispiel erlebt, dass zwei Teams, die an demselben Produkt arbeiten, zwei verschiedene Lösungen entwickelt haben, um das gleiche Problem zu lösen: die Bereitstellung von Modellinferenzen mit geringer Latenzzeit. Hier kommt das Conway'sche Gesetz zum Tragen. Der Weg des geringsten Widerstands führt Teams dazu, lokale Optimierungen zu finden, anstatt gemeinsame Funktionen zu koordinieren.

Wir können diese Probleme für ein bestimmtes Produkt entschärfen, indem wir die Fähigkeiten ermitteln, die für das Produkt von Natur aus zusammengehören, und ein funktionsübergreifendes Team um das Produkt herum aufbauen - von den Frontend-Elementen (z. B. Experience Design, UI-Design) bis zu den Backend-Elementen (z. B. ML, MLOps, Data Engineering). Diese Praxis, multidisziplinäre Teams zu bilden, wird manchmal als Inverse Conway Maneuver bezeichnet. Dies bringt vier große Vorteile mit sich:

Verbessert die Geschwindigkeit und Qualität der Entscheidungsfindung

Der gemeinsame Kontext und Rhythmus verringert die Reibung, die bei der Diskussion und Iteration aller Dinge entsteht (z. B. Designentscheidungen, Priorisierungsaufrufe, zu validierende Annahmen). Anstatt ein Treffen zwischen mehreren Teams zu koordinieren, können wir ein Problem einfach über die Kommunikationskanäle eines bestimmten Teams besprechen (z. B. Standup, Huddles, Chat).

Reduziert das Hin- und Herreichen und Warten

Wenn das Slicing richtig gemacht wird, sollte das funktionsübergreifende Team autonom sein - das bedeutet, dass das Team in der Lage ist, Funktionen und End-to-End-Funktionalität zu entwickeln und zu liefern, ohne von einem anderen Team abhängig zu sein oder auf dieses zu warten.

Reduziert blinde Flecken durch Vielfalt

Ein vielfältiges Team mit unterschiedlichen Fähigkeiten und Perspektiven kann dazu beitragen, dass das ML-Projekt abgerundet ist und alle relevanten Überlegungen berücksichtigt werden. Ein UX-Designer könnte zum Beispiel Prototypen erstellen, um Ideen mit Kunden zu testen und zu verfeinern, bevor wir einen erheblichen technischen Aufwand in ML investieren.

Reduziert die Chargengröße

Die Arbeit in kleineren Chargen hat viele Vorteile und ist eines der Grundprinzipien von Lean Software Delivery. Wie in Donald Reinertsens Principles of Product Development Flow (Celeritas) beschrieben, ermöglichen kleinere Chargen schnelleres Feedback, geringeres Risiko, weniger Verschwendung und höhere Qualität.

Die ersten drei Vorteile funktionsübergreifender Teams - verbesserte Kommunikation und Zusammenarbeit, weniger Übergaben, vielfältiges Fachwissen - ermöglichen es den Teams, die Losgröße zu verringern. Anstatt eine Funktion erst zu entwickeln und zu optimieren, bevor sie einem breiteren Publikum zur Verfügung gestellt werden kann, verfügt ein funktionsübergreifendes Team über das nötige Produkt- und Fachwissen, um dieses Feedback zu geben (oder wenn nicht, weiß es zumindest, wie es kosteneffiziente Wege findet, die Antworten zu finden).

Auch funktionsübergreifende Teams sind nicht frei von Problemen. Es besteht die Gefahr, dass jedes Produktteam seine eigene idiosynkratische Lösung für Probleme entwickelt, die produktübergreifend immer wieder auftreten. Wir sind jedoch der Meinung, dass dies mit den richtigen technischen Praktiken ein höheres Qualitätsproblem darstellt als der schlechte Arbeitsfluss, der durch funktional getrennte Teams entsteht. Darüber hinaus gibt es Möglichkeiten, die Produktteams aufeinander abzustimmen, wie z. B. Communitys of Practice, Plattformteams und so weiter. Wir werden diese in Kapitel 11 ausführlich besprechen.

Im Gegensatz dazu haben wir gesehen, dass funktional spezialisierte Teams effektiv zusammenarbeiten, wenn sie ein starkes agiles Programmmanagement haben, das ein klares, aktuelles Bild der End-to-End-Lieferung und des Produktbetriebs liefert und kollektive Richtlinien für eine nachhaltige Arbeit zur Verbesserung des Gesamtsystems aufstellt.

Es gibt keine einheitliche Teamform, und die richtigen Teamformen und Interaktionsmodi für deine Organisation hängen von vielen Faktoren ab, die sich im Laufe der Zeit weiterentwickeln werden. In Kapitel 11 gehen wir auf verschiedene Teamformen ein und erklären, wie die Prinzipien der Team-Topologien dir dabei helfen können, geeignete Teamformen und Interaktionsmodi für ML-Teams in deiner Organisation zu finden.

Arbeitsweisen

Ways of Working (WoW) bezieht sich auf die Prozesse, Praktiken und Werkzeuge, die ein Team verwendet, um Produktfunktionen zu liefern. Dazu gehören u. a. agile Zeremonien (z. B. Standups, Retros, Feedback), User Story Workflows (z. B. Kanban, Story Kickoffs, Pair Programming, Desk Checks⁸) und die Qualitätssicherung (z. B. automatisierte Tests, manuelle Tests, "Stoppen der Linie", wenn Fehler auftreten).

Eine häufige Falle, in die Teams tappen, ist, der Form zu folgen, aber die Substanz oder Absicht dieser WoW-Praktiken zu vernachlässigen. Wenn wir WoW nicht als kohärentes Ganzes verstehen und praktizieren, kann das oft kontraproduktiv sein. Teams könnten zum Beispiel Standups durchführen, dabei aber die Absicht verpassen, die Arbeit sichtbar zu machen, da sich die Teammitglieder hinter allgemeinen Updates verstecken ("Ich habe gestern an X gearbeitet und werde heute daran weiterarbeiten"). Stattdessen sollte jede dieser WoW-Praktiken dem Team helfen, kontextbezogene Informationen zu erhalten (z. B. "Ich stecke in Y fest" und "Oh, das habe ich auch schon erlebt und ich weiß, wie ich dir helfen kann"). Das verbessert das gemeinsame Verständnis, schafft Übereinstimmung und versorgt jedes Teammitglied mit Informationen, die den Wertfluss verbessern.

Messung der Lieferkennzahlen

Eine oft übersehene Praxis - selbst in agilen Teams - ist das Erfassen von Lieferkennzahlen (z. B. Iterationsgeschwindigkeit, Durchlaufzeit, Fehlerraten) im Laufe der Zeit. Wenn wir uns das Team als Fließband vorstellen (das kreative Lösungen und keine vorgefertigten Widgets produziert), können uns diese Kennzahlen dabei helfen, den Zustand der Lieferung regelmäßig zu überwachen und uns darauf aufmerksam zu machen, wenn wir vom Lieferplan oder der Zeitplanung abweichen.

Teams können und sollten die Leistung bei der Softwarebereitstellung auch mit den vier Schlüsselkennzahlen von messen: Vorlaufzeit, Bereitstellungshäufigkeit, mittlere Wiederherstellungszeit (MTTR) und Fehlerquote bei Änderungen. In ihrem Buch Accelerate (IT Revolution Press), das auf einer vierjährigen Untersuchung und statistischen Analyse von Technologieunternehmen basiert, haben die Autoren herausgefunden, dass die Leistung bei der Softwarebereitstellung (gemessen an den vier Schlüsselkennzahlen) mit den Geschäftsergebnissen und der finanziellen Leistung eines Unternehmens korreliert. Die Messung der vier Schlüsselkennzahlen hilft uns, einen gleichmäßigen und qualitativ hochwertigen Fluss in unserer Produktionslinie zu gewährleisten.

Der objektive Charakter dieser Kennzahlen hilft dabei, die Planungsgespräche auf Daten zu stützen und dem Team dabei zu helfen, die anstehende Arbeit (in Form von quantitativen Schätzungen) zu sehen und zu erkennen, wie gut sie ihrem Ziel näher kommen. In einer idealen Umgebung würden diese Kennzahlen ausschließlich für die kontinuierliche Verbesserung genutzt, damit wir unsere Produktionslinie im Laufe der Zeit verbessern und unsere Produktlieferungsziele erreichen können.

In anderen, nicht so idealen Umgebungen können Kennzahlen jedoch missbraucht, manipuliert und schließlich dysfunktional werden. Das Gesetz von besagt: "Wenn eine Maßnahme zu einem Ziel wird, ist sie keine gute Maßnahme mehr". Stelle sicher, dass du die richtigen Ergebnisse misst und dich kontinuierlich verbesserst, um die richtigen Messgrößen für die ML-Praxis deiner Organisation zu finden. Wir gehen ausführlicher auf die Messung der Teamgesundheit ein, wenn wir in Kapitel 10 die Fallstricke der Produktivitätsmessung und deren Vermeidung besprechen.

Die dritte Disziplin: Technik

Entscheidend ist, dass die Geschwindigkeit, mit der wir lernen, unser Produkt oder unseren Prototyp auf der Grundlage des Feedbacks aktualisieren und erneut testen können, einen starken Wettbewerbsvorteil darstellt. Das ist das Wertversprechen der Lean-Engineering-Praktiken.

Jez Humble, Joanne Molesky und Barry O'Reilly in Lean Enterprise

Alle technischen Praktiken, die wir in diesem Abschnitt vorstellen, konzentrieren sich auf eines: die Verkürzung von Feedbackschleifen. Das vorangegangene Zitat aus Lean Enterprise drückt es gut aus: Ein effektives Team ist in der Lage, die erforderlichen Änderungen schnell vorzunehmen, zu testen und freizugeben - sei es am Code, an den Daten oder an den ML-Modellen.

Automatisiertes Testen

In ML-Projekten sieht man häufig haufenweise Code ohne automatisierte Tests. Ohne automatisierte Tests werden Änderungen fehleranfällig, mühsam und anstrengend. Wenn wir einen Teil der Codebasis ändern, zwingt uns das Fehlen von Tests dazu, die gesamte Codebasis manuell zu testen, um sicherzustellen, dass eine Änderung (z. B. in der Feature-Engineering-Logik) keine Verschlechterung (z. B. der Modellqualität oder des API-Verhaltens in Kantenfällen) verursacht hat. Das bedeutet, dass ein großer Teil der Zeit, des Aufwands und der kognitiven Belastung für Arbeiten aufgewendet wird, die nichts mit der ML zu tun haben.

Im Gegensatz dazu helfen umfassende automatisierte Tests den Teams, das Experimentieren zu beschleunigen, die kognitive Belastung zu verringern und schnelles Feedback zu erhalten. Automatisierte Tests geben uns schnelles Feedback zu Änderungen und lassen uns wissen, ob alles noch so funktioniert wie erwartet. In der Praxis kann das einen Unterschied wie Tag und Nacht machen, wenn es darum geht, wie schnell wir unsere Ideen umsetzen und die Storys richtig abarbeiten können.

Effektive Teams sind diejenigen, die wertvolle Änderungen in verschiedenen Bereichen eines Produkts begrüßen und darauf reagieren können: neue Geschäftsanforderungen, Feature-Engineering-Strategien, Modellierungsansätze, Trainingsdaten und vieles mehr. Automatisierte Tests ermöglichen eine solche Reaktionsfähigkeit und Zuverlässigkeit angesichts dieser Veränderungen. In den Kapiteln 5 und 6 werden wir Techniken zum Testen von ML-Systemen vorstellen.

Refactoring

Der zweite Hauptsatz der Thermodynamik besagt, dass das Universum zu Unordnung oder Entropie neigt. Unsere Codebasen - ob ML oder andere - sind da keine Ausnahme. Mit jedem "Quick Hack" und jeder Funktion, die ohne bewusste Anstrengungen zur Minimierung der Entropie bereitgestellt wird, wird die Codebasis immer unübersichtlicher und brüchiger. Dadurch wird der Code immer schwieriger zu verstehen und die Änderung des Codes wird mühsam und fehleranfällig.

ML-Projekte ohne automatisierte Tests sind besonders anfällig für exponentielle Komplexität, denn ohne automatisierte Tests ist das Refactoring mühsam zu testen und sehr riskant. Folglich wird das Refactoring zu einem bedeutenden Unterfangen, das auf den Friedhof des Backlogs verbannt wird. Dadurch entsteht ein Teufelskreis und es wird für ML-Fachleute immer schwieriger, ihre ML-Lösungen weiterzuentwickeln .

In einem effektiven Team ist Refactoring etwas, das so sicher und einfach zu machen ist, dass wir es als Teil der Funktionsbereitstellung durchführen können und nicht als nachträgliche Maßnahme. Solche Teams können dies in der Regel aus drei Gründen tun:

Sie haben umfassende Tests, die ihnen schnelles Feedback darüber geben, ob ein Refactoring das Verhalten erhalten hat.
Sie haben ihren Code-Editor konfiguriert und die Fähigkeit moderner Code-Editoren genutzt, Refactoring-Aktionen auszuführen (z. B. Variablen umbenennen, Funktion extrahieren, Signatur ändern).
Der Umfang der technischen Schulden und/oder der Arbeitsbelastung ist auf einem gesunden Niveau. Anstatt sich vom Druck erdrückt zu fühlen, sind sie in der Lage, bei Bedarf Refactoring durchzuführen, um die Lesbarkeit und Qualität der Codebasis zu verbessern.

Effektivität des Code-Editors

Wie im vorigen Punkt angedeutet hat, verfügen moderne Code-Editoren über viele leistungsstarke Funktionen, die den Autoren helfen können, ihren Code effektiver zu schreiben. Der Code-Editor kann sich um die Details auf niedriger Ebene kümmern, sodass unsere kognitiven Fähigkeiten für die Lösung von Problemen auf höherer Ebene zur Verfügung stehen.

Anstatt Variablen durch manuelles Suchen und Ersetzen umzubenennen, kann der Code-Editor zum Beispiel alle Verweise auf eine Variable mit einem einzigen Shortcut umbenennen. Anstatt manuell nach der Syntax zu suchen, um eine Funktion zu importieren (z. B. cross_val_score()), können wir einen Shortcut drücken und die IDE kann die Funktion automatisch für uns importieren.

Wenn er richtig konfiguriert ist, wird der Code-Editor zu einem leistungsstarken Assistenten (auch ohne KI-Technologien) und kann uns dabei helfen, unsere Ideen umzusetzen, Probleme zu lösen und Mehrwert zu schaffen.

Kontinuierliche Bereitstellung für ML

Wäre es nicht toll, wenn es eine Möglichkeit gäbe, ML-Fachleute dabei zu unterstützen, die Arbeit zu reduzieren, Experimente zu beschleunigen und qualitativ hochwertige Produkte zu entwickeln? Genau das ist es, wasContinuous Delivery for ML (CD4ML) den Teams ermöglicht. CD4ML ist die Anwendung der Prinzipien und Praktiken von für kontinuierliche Lieferung auf ML-Projekte. Es ermöglicht Teams, Feedbackschleifen zu verkürzen und Qualitätskontrollen einzurichten, um sicherzustellen, dass Software und ML-Modelle von hoher Qualität sind und sicher und effizient in die Produktion überführt werden können.

Untersuchungen von Accelerate zeigen, dass kontinuierliche Lieferpraktiken Unternehmen dabei helfen, eine bessere technische und geschäftliche Leistung zu erzielen, indem sie Teams in die Lage versetzen, zuverlässig Werte zu liefern und schnell auf Veränderungen der Marktanforderungen zu reagieren. Dies wird durch unsere Erfahrungen mit ML-Teams untermauert. CD4ML hat uns geholfen, unsere Geschwindigkeit, Reaktionsfähigkeit, kognitive Belastung, Zufriedenheit und Produktqualität zu verbessern.

In Kapitel 9 werden wir CD4ML im Detail vorstellen. Hier schon mal ein Überblick über die technischen Komponenten (siehe Abbildung 1-5):

Reproduzierbare Modellschulung, -bewertung und -erprobung
Modell serviert
Prüfung und Qualitätssicherung
Modell-Einsatz
Modellüberwachung und Beobachtbarkeit

Die vierte Disziplin: ML

Die ML-Disziplin umfasst mehr als das Wissen, wie man ML-Modelle trainiert, auswählt, verbessert, einsetzt und nutzt. Sie umfasst auch Kompetenzen wie ML-Problemstellung, ML-Systemdesign, Design für Erklärbarkeit, Zuverlässigkeit, verantwortungsvolle KI und ML-Governance, unter anderem.

ML-Probleme einrahmen

frühen und explorativen Phasen von ML-Projekten ist meist unklar, welches Problem wir lösen sollen, für wen wir es lösen und vor allem, warum wir es lösen sollen. Außerdem ist vielleicht nicht klar, welches ML-Paradigma oder welche Modellarchitekturen uns helfen können - oder sogar welche Daten wir haben oder brauchen, um das Problem zu lösen. Deshalb ist es wichtig, ML-Probleme zu formulieren, Ideen zu strukturieren und umzusetzen und Hypothesen mit den relevanten Kunden oder Stakeholdern zu überprüfen. Das Sprichwort "Ein gut definiertes Problem ist ein halb gelöstes Problem" trifft in diesem Zusammenhang gut zu.

Es gibt verschiedene Tools, die uns dabei helfen können, ML-Probleme zu formulieren, z. B. das Data Product Canvas, auf das wir weiter oben in diesem Kapitel hingewiesen haben. Ein weiteres Tool, das uns dabei hilft, unsere Ideen in schnellen Zyklen zu formulieren und zu testen und das Gelernte im Laufe der Zeit zu verfolgen, ist die Hypothesis Canvas (siehe Abbildung 1-6).⁹ Der Hypothese Canvas hilft uns bei der Formulierung überprüfbarer Hypothesen, bei der Darlegung, warum eine Idee wertvoll sein könnte und wer davon profitieren wird, und bei der Ausrichtung auf die Messung objektiver Metriken, um Ideen zu validieren oder zu entkräften. Es ist eine weitere Möglichkeit, Feedbackschleifen zu verkürzen, indem wir gezielte, zeitlich begrenzte Experimente durchführen. Wir werden uns hier kurz fassen, da wir im nächsten Kapitel detailliert auf diese Leinwände eingehen werden.

ML-Systeme entwerfen

Die Entwicklung von ML-Systemen besteht aus vielen Teilen, z. B. dem Sammeln und Verarbeiten der Daten, die für das Modell benötigt werden, der Auswahl des geeigneten ML-Ansatzes, der Bewertung der Leistung des Modells, der Berücksichtigung von Zugriffsmustern und Skalierbarkeitsanforderungen, dem Verständnis von ML-Fehlermodi und der Identifizierung von modell- und datenzentrierten Strategien zur iterativen Verbesserung des Modells.

Es gibt ein großartiges Buch zu diesem Thema, Designing Machine Learning Systems von Chip Huyen (O'Reilly), und wir empfehlen dir, es zu lesen, falls du es nicht schon getan hast. Da es bereits viel Literatur zu diesem Thema gibt, wird unser Buch nicht auf die Konzepte eingehen, die bereits in Designing ML Systems behandelt werden.

Verantwortungsvolle KI- und ML-Governance

Die MIT Sloan Management Review hat eine prägnante und praktische Definition von Responsible AI:

Ein Rahmenwerk mit Grundsätzen, Richtlinien, Werkzeugen und Prozessen, das sicherstellt, dass KI-Systeme im Dienste des Guten für den Einzelnen und die Gesellschaft entwickelt und betrieben werden und gleichzeitig eine transformative Wirkung auf das Geschäft erzielen.

Im "2022 Responsible AI Global Executive Report" des MIT Sloan wird festgestellt, dass die KI-Initiativen zwar zunehmen, die verantwortungsvolle KI aber hinterherhinkt. Von den befragten Unternehmen wenden 52 % einige Praktiken der verantwortungsvollen KI an, aber 79 % geben an, dass ihre Umsetzungen in Umfang und Reichweite begrenzt sind. Sie erkennen zwar an, dass verantwortungsvolle KI für die Bewältigung von KI-Risiken wie Sicherheit, Voreingenommenheit, Fairness und Datenschutz von entscheidender Bedeutung ist, geben aber zu, dass sie dem Thema keine Priorität einräumen. Diese Lücke erhöht das Risiko negativer Folgen für ihre Kunden und setzt das Unternehmen regulatorischen und finanziellen Risiken sowie Risiken für die Kundenzufriedenheit aus.

Wenn die verantwortliche KI der sprichwörtliche Berggipfel ist, fehlt den Teams oft nur ein Kompass, um dorthin zu gelangen. Sie brauchen auch eine Karte, Wege, Orientierung und Transportmittel. Hier kommt die ML-Governance ins Spiel, ein wichtiger Mechanismus, den Teams nutzen können, um die Ziele der verantwortungsvollen KI zu erreichen, neben anderen Zielen von ML-Teams.

Die ML-Governance umfasst ein breites Spektrum an Prozessen, Richtlinien und Praktiken, die den Praktikern helfen sollen, ML-Produkte verantwortungsvoll und zuverlässig zu liefern. Sie erstreckt sich über den gesamten Lebenszyklus von ML-Produkten und spielt in jeder der folgenden Phasen eine Rolle:

Modellentwicklung: Richtlinien, bewährte Methoden und goldene Wege für die Entwicklung, Prüfung, Dokumentation und den Einsatz von ML-Modellen
Modellbewertung: Methoden zur Bewertung der Modellleistung, zur Identifizierung von Verzerrungen und zur Gewährleistung der Fairness vor dem Einsatz
Überwachung und Feedbackschleifen: Systeme zur kontinuierlichen Überwachung der Modellleistung, zum Sammeln von Nutzerfeedback und zur Verbesserung der Modelle
Minderungsstrategien: Ansätze zur Identifizierung und Milderung von Verzerrungen in Daten und Algorithmen, um negative und ungerechte Ergebnisse zu vermeiden
Erklärbarkeit: Techniken und Werkzeuge, um das Verhalten eines Modells in bestimmten Szenarien zu erklären, um die Transparenz zu verbessern, das Vertrauen der Nutzer zu stärken und die Fehleranalyse zu erleichtern
Rechenschaftspflicht: Klar definierte Rollen, Verantwortlichkeiten und Zuständigkeiten; multidisziplinäre Teams, die in der Lage sind, ML-Systeme und Risikomanagementprozesse zu verwalten
Einhaltung von Vorschriften: Einhaltung gesetzlicher und branchenspezifischer Vorschriften oder Prüfungsanforderungen hinsichtlich der Nutzung von Daten und ML
Richtlinien zum Umgang mit Daten: Richtlinien für die Erhebung, Speicherung und Verarbeitung von Daten zur Gewährleistung des Datenschutzes und der Datensicherheit
Zustimmung der Nutzer und Schutz der Privatsphäre: Maßnahmen zur Einholung der informierten Zustimmung der Nutzer und zum Schutz ihrer Privatsphäre
Ethische Richtlinien: Grundsätze für die Entwicklung und Nutzung von ML unter Berücksichtigung der sozialen Auswirkungen, der menschlichen Werte, potenzieller Risiken und der Möglichkeit von Schäden

Obwohl der Begriff "Governance" in der Regel bürokratische Assoziationen hervorruft, werden wir in Kapitel 9 zeigen, dass ML-Governance auch auf schlanke und leichtgewichtige Weise umgesetzt werden kann. Unserer Erfahrung nach ergänzen Continuous Delivery und Lean Engineering die Governance durch die Einrichtung von Safe-to-Fail-Zonen und Feedback-Mechanismen. Zusammengenommen helfen diese Governance-Praktiken den Teams nicht nur, Risiken zu reduzieren und negative Folgen zu vermeiden, sondern auch, innovativ zu sein und Mehrwert zu schaffen.

In Kapitel 9 werden wir auch andere hilfreiche Ressourcen für ML-Governance vorstellen, wie das "Responsible Tech Playbook" und die Google Model Cards.

Die fünfte Disziplin: Daten

Wie viele ML-Praktiker wissen, hängt die Qualität unserer ML-Modelle von der Qualität unserer Daten ab. Wenn die Daten in unserer Trainingsstichprobe verzerrt sind (im Vergleich zur Verteilung der Grundgesamtheit), dann wird das Modell lernen und die Verzerrung beibehalten . Wie es so schön heißt: "Wenn sich die Technologie von heute auf die Daten von gestern stützt, spiegelt sie einfach unsere Fehler und Verzerrungen der Vergangenheit wider."¹⁰

Um bessere ML-Lösungen zu liefern, können Teams die folgenden Praktiken in der Datendisziplin berücksichtigen.

Den Kreislauf der Datenerhebung schließen

Da wir Modelle trainieren und einsetzen, sollte unser ML-Systemdesign auch berücksichtigen, wie wir die Vorhersagen des Modells in der Produktion sammeln und aufbereiten, damit wir sie beschriften und eine qualitativ hochwertige Grundlage für die Evaluierung und das erneute Training der Modelle schaffen können.

Die Beschriftung kann eine mühsame Aufgabe sein und ist oft der Engpass. Wenn dies der Fall ist, können wir auch überlegen, wie wir die Beschriftung durch Techniken wie aktives Lernen, selbstüberwachtes Lernen und schwache Überwachung skalieren können. Wenn für unsere ML-Aufgabe natürliche Beschriftungen - Ground-Truth-Beschriftungen, die automatisch oder teilweise ausgewertet werden können - zur Verfügung stehen, sollten wir auch Software und Dateneingabepipelines entwickeln, die die natürlichen Beschriftungen zusammen mit den zugehörigen Merkmalen für die gegebenen Datenpunkte einfließen lassen, sobald sie verfügbar sind.

Beim Sammeln natürlicher Kennzeichnungen müssen wir auch überlegen, wie wir die Risiken von Data Poisoning-Angriffen (mehr dazu in Kürze) und gefährlichen unkontrollierten Rückkopplungsschleifen mindern können, bei denen die verzerrten Vorhersagen des Modells Auswirkungen auf die reale Welt haben, wodurch die Verzerrung in den Daten und den nachfolgenden Modellen noch verstärkt wird.

Teams konzentrieren sich oft auf die letzte Meile der ML-Bereitstellung - mit einem verzerrten Fokus darauf, ein zufriedenstellendes Modell auf die Beine zu stellen - und vernachlässigen es, den Datenerhebungskreislauf in Vorbereitung auf die nächste Etappe und den nächsten Zyklus der Modellverbesserung zu schließen. In diesem Fall verpassen sie die Möglichkeit, ML-Modelle durch datenzentrierte Ansätze zu verbessern.

Schauen wir uns die letzte Übung für dieses Kapitel an: Datensicherheit und Datenschutz.

Datensicherheit und Datenschutz

Wie bereits in diesem Kapitel erwähnt hat, sind Datensicherheit und Datenschutz bereichsübergreifende Themen, für die jeder im Unternehmen verantwortlich sein sollte, von den Produktteams bis zu den Datentechnikteams und jedem Team dazwischen. Ein Unternehmen kann seine Daten schützen, indem es Defense in Depth (Verteidigung in der Tiefe) praktiziert, bei der mehrere Schichten von Sicherheitskontrollen in einem System eingesetzt werden. Neben der sicheren Speicherung von Daten bei der Übertragung und im Ruhezustand durch Verschlüsselung und Zugriffskontrollen können Teams zum Beispiel auch das Prinzip der geringsten Privilegien anwenden und sicherstellen, dass nur autorisierte Personen und Systeme auf die Daten zugreifen können.

Auf organisatorischer Ebene muss es Richtlinien für die Datenverwaltung und das Datenmanagement geben, die klare Richtlinien dafür festlegen und durchsetzen, wie Teams Daten sammeln, speichern und nutzen. So kann sichergestellt werden, dass die Daten nach ethischen Grundsätzen und in Übereinstimmung mit den einschlägigen Gesetzen und Vorschriften verwendet werden.

Gelten diese Praktiken auch für generative KI und große Sprachmodelle?

Da Generative KI und LLMs im kollektiven Bewusstsein und in den Produktplänen vieler Unternehmen an Bedeutung gewonnen haben, hatten wir und unsere Kollegen die Möglichkeit, mit Unternehmen zusammenzuarbeiten, um Produkte zu konzipieren, zu entwickeln und zu liefern, die generative KI nutzen.¹¹

Zum Zeitpunkt der Erstellung dieses Artikels (Ende 2023) verwenden viele generative KI-Anwendungen LLMs für die Verarbeitung natürlicher Sprache. LLMs sind eine Art neuronales Netzwerk, das auf der Transformator-Architektur basiert. Es gibt noch andere generative neuronale Netzwerkarchitekturen, darunter Generative Adversarial Networks (GANs) und Autoencoder. Es gibt auch andere Arten der KI, die generativ sind, wie z. B. Bayes'sche Methoden.

LLMs erzeugen in der Regel Text, wobei es sich um natürliche Sprache oder strukturierte Formen wie Tabellen, JSON oder Code handeln kann. Ein LLM erzeugt einen Strom von Ausgabe-Token als Antwort auf einige Eingabe-Token, die auch als "Eingabeaufforderung" bezeichnet werden. Token stellen eine Einheit der Texteingabe und -ausgabe dar. Zum Beispiel könnte das Modell Llama 2 7B als Antwort auf eine Eingabeaufforderung mit einer offenen Anfrage eine Ausgabe erzeugen, die mit dem Token #4587 "Of" beginnt, gefolgt vom Token #3236 "course", und so weiter. LLMs können auch multimodal sein und Bilder, Audiodaten und andere Arten von Daten verarbeiten und erzeugen.

Als neuronales Netz wird ein LLM mit vielen, vielen Instanzen von Eingaben und ihren erwarteten Ausgaben trainiert. Dabei wird der stochastische Gradientenabstieg (SGD) verwendet, um eine Verlustfunktion zu minimieren, die die Differenz zwischen den vorhergesagten und erwarteten Ausgaben darstellt. Bei jeder Trainingsiteration passt SGD die Gewichte des neuronalen Netzes an, um die Verlustfunktion für die nachfolgenden Vorhersagen zu reduzieren. Obwohl das LLM-Training komplex und mehrstufig ist und große Datenmengen benötigt, ist es qualitativ dasselbe wie das Training anderer ML-Modelle, die in diesem Buch behandelt werden. Daher ist dieses Buch auch weiterhin ein nützliches Nachschlagewerk für Teams, die LLMs trainieren oder feinjustieren.

Viele Anwendungen, die generative KI integrieren, werden die Komplexität des Trainings oder der Feinabstimmung von LLMs vermeiden und einfach eine vortrainierte LLM im Inferenzmodus als flexible Anwendungskomponente verwenden. Ein isolierter LLM hat aufgrund seiner Ausbildung ein gewisses Grundniveau an Fähigkeiten. Bei der Integration in eine Anwendung kann ein LLM in der Eingabeaufforderung zusätzlichen Kontext erhalten und/oder mehrere Aufrufe können für bessere Antworten orchestriert werden. Diese LLM-Fähigkeiten werden als Zero-Shot-, Little-Shot- und In-Context-Lernen bezeichnet, und die Techniken zur Nutzung dieser Fähigkeiten werden als " Prompt-Engineering" bezeichnet.

Diese Techniken zur Anwendungsintegration erweitern die grundlegenden Fähigkeiten von LLMs, indem sie Zugang zu zusätzlichen Daten bieten. LLMs generieren zwar Inhalte, aber man kann sich nicht darauf verlassen, dass sie Informationen perfekt abrufen, sensible Informationen unterdrücken, schlussfolgern, planen, berechnen oder böswillige Absichten erkennen können. Dies kann es erforderlich machen, dass die Anwendung auch herkömmliche Techniken zur Verarbeitung natürlicher Sprache (NLP) und zur Entwicklung von Softwareanwendungen einsetzt, um LLM-Eingaben oder -Ausgaben einzuschränken, um eine bessere Leistung, Robustheit oder Schutz vor Bedrohungen zu erreichen. Im Allgemeinen machen diese Überlegungen die Integration von LLMs komplex.

Unabhängig davon, ob du ein vortrainiertes Modell integrierst oder ein eigenes Modell trainierst, sind die in diesem Buch beschriebenen Grundsätze der Softwarearchitektur und Entwicklungspraktiken nach wie vor relevant und möglicherweise sogar noch wichtiger, da die manchmal unvorhersehbare Natur der LLM-Antworten berücksichtigt werden muss.

Obwohl generative KI und LLMs zu einem Paradigmenwechsel bei den Methoden geführt haben, mit denen wir Modelle so steuern oder einschränken, dass sie bestimmte Funktionen erfüllen, haben sich die Grundlagen von Lean Product Delivery und Engineering nicht verändert. Tatsächlich haben uns die grundlegenden Werkzeuge und Techniken in diesem Buch dabei geholfen, in den Bereichen Produkt, Lieferung, ML und Entwicklung frühzeitig Hypothesen zu formulieren und zu testen, schnell zu iterieren und zuverlässig zu liefern. Dank der in diesem Kapitel vorgestellten Techniken konnten wir die Zeit und die Kosten bis zur Wertschöpfung reduzieren, selbst wenn wir uns mit den komplexen Aspekten der generativen KI und der LLMs auseinandersetzen.

In Kapitel 2 gehen wir kurz darauf ein, wie Produktentdeckungstechniken uns geholfen haben und dir helfen können, deinen Fokus bei der Gestaltung von generativen KI-Produktmöglichkeiten zu schärfen. In Kapitel 6 gehen wir ausführlicher auf Teststrategien und -techniken für LLM-Anwendungen ein.

Klopfe dir selbst auf die Schulter, denn du hast soeben eine Menge über die miteinander verbundenen Disziplinen gelernt, die für die effektive Bereitstellung von ML-Lösungen unerlässlich sind!

Bevor wir dieses Kapitel abschließen, möchten wir noch darauf hinweisen, dass diese Praktiken als Frühindikatoren für positive oder unerwünschte Ergebnisse dienen können. Wenn wir zum Beispiel unsere Produktideen nicht frühzeitig und oft mit den Nutzern validieren - wir wissen ja, wie der Film endet -, ist die Wahrscheinlichkeit größer, dass wir viel Zeit und Mühe in die Entwicklung des falschen Produkts investieren. Wenn wir keine funktionsübergreifenden Teams haben, werden wir mit der Kopplung des Backlogs konfrontiert, da mehrere Teams sich abstimmen und aufeinander warten müssen, um den Nutzern eine Änderung zu liefern.

Das ist nicht nur anekdotisch. In einer wissenschaftlichen Studie über die Leistung und Effektivität von technischen Unternehmen, an der mehr als 2.800 Organisationen teilnahmen, fanden die Autoren heraus, dass Organisationen, die Praktiken wie Continuous Delivery, Lean, funktionsübergreifende Teams und generative Kulturen anwenden, ein höheres Leistungsniveau aufweisen - schnellere Bereitstellung von Funktionen, geringere Fehlerquoten und höhere Mitarbeiterzufriedenheit.¹² Mit anderen Worten: Diese Praktiken können tatsächlich die Leistung eines Unternehmens vorhersagen.

Fazit

Fassen wir noch einmal zusammen, was wir in diesem Kapitel behandelt haben. Zunächst haben wir uns angeschaut, warum ML-Projekte häufig fehlschlagen, und wir haben verglichen, wie die ML-Bereitstellung in Umgebungen mit geringer und hoher Effektivität aussieht. Dann haben wir uns mit Systemdenken beschäftigt, um die Disziplinen zu ermitteln, die für eine effektive ML-Bereitstellung erforderlich sind. Wir haben uns angesehen, wie Lean uns hilft, Verschwendung zu reduzieren und den Wert zu maximieren. Zum Schluss haben wir uns einen Überblick über die Praktiken in den fünf Disziplinen (Produkt, Lieferung, Softwareentwicklung, ML und Daten) verschafft, die uns helfen können, ML-Lösungen effektiver bereitzustellen.

Bei unseren Gesprächen mit verschiedenen ML- oder Data-Science-Teams aus unterschiedlichen Branchen stellen wir immer wieder eine Kluft zwischen der Welt von ML und der Welt der schlanken Softwareentwicklung fest. Während sich diese Kluft in bestimmten Bereichen verringert hat - wo ML-Teams durch die Einführung der notwendigen Produkt-, Liefer- und Entwicklungspraktiken hervorragende ML-Produkterfahrungen liefern können -, bleibt sie für viele Teams weiterhin groß (du kannst dir Danas Erfahrungen in der Umgebung mit geringer Effektivität weiter oben in diesem Kapitel ansehen, um diese Kluft zu erkennen).

Um diese Lücke zu schließen, braucht die ML-Gemeinschaft einen Paradigmenwechsel - eine grundlegende Änderung der Herangehensweise oder der zugrunde liegenden Annahmen - um zu erkennen, dass die Entwicklung eines ML-gesteuerten Produkts nicht nur ein ML- und Datenproblem ist. Es ist in erster Linie ein Produktproblem, das heißt, es ist ein Produkt-, Entwicklungs- und Lieferproblem - und es erfordert einen ganzheitlichen, multidisziplinären Ansatz.

Die gute Nachricht ist, dass du nicht den Ozean zum Kochen bringen oder das Rad neu erfinden musst - in jeder Disziplin gibt es Prinzipien und Praktiken, die Teams geholfen haben, erfolgreich ML-Produkterfahrungen zu liefern. Im weiteren Verlauf dieses Buches werden wir diese Prinzipien und Praktiken untersuchen und herausfinden, wie sie unsere Effektivität bei der Bereitstellung von ML-Lösungen verbessern können. Wir werden die Prinzipien und Praktiken langsam und praxisnah erläutern und dabei mit dem Produkt und der Bereitstellung beginnen. Es wird anwendbare Praktiken, Frameworks und Codebeispiele geben, die du in deine ML-Projekte einbringen kannst. Wir hoffen, dass du gut angeschnallt bist und dich auf die Fahrt freust.

Eine Einladung, mit uns zu reisen

Wir haben in diesem Kapitel viel erreicht. Je nachdem, wo du dich auf deiner Reise befindest und welche Erfahrungen du gemacht hast, hast du vielleicht das Gefühl, dass der gewünschte Zustand, den wir gezeichnet haben, unüberwindbar ist. Oder du bist begeistert, dass andere deine Schmerzen und Herausforderungen kennen und dass es einen besseren Weg gibt.

Wo auch immer du dich auf diesem Kontinuum befindest, wir hoffen, dass du dieses Buch als eine Einladung verstehst. Wir laden dich ein, dich auf die fünf Disziplinen einzulassen und zu erforschen, wie ML-Praktiker/innen ihre ML-Lösungen verbessern können. Unserer Erfahrung nach umfasst jede Disziplin kompatible Techniken, die Teams schon heute einsetzen können, um ihre vorhandenen Fähigkeiten zu ergänzen - sei es in der ML-, Produkt- oder Softwareentwicklung.

Dieses Buch ist auch eine Einladung, über die ML-Projekte deines Teams oder deiner Organisation nachzudenken, um Bereiche mit Wert und Bereiche mit Verschwendung zu erkennen. Wir hoffen, dass die Prinzipien und Praktiken, die wir in diesem Buch vorstellen, dir helfen werden, kürzere und zuverlässigere Wege zu deinem Ziel zu finden. Uns haben sie auf jeden Fall geholfen (deshalb haben wir beschlossen, ein Buch darüber zu schreiben!), und wir wenden diese Prinzipien und Praktiken auch weiterhin bei unseren ML-Projekten an.

Wir erkennen an, dass es mehr als Willenskraft und gute Praktiken braucht, um Veränderungen zu bewirken. Es braucht unter anderem ein gewisses Maß an organisatorischer Abstimmung, eine förderliche Unternehmenskultur und eine gute Führung (auf die wir in den Kapiteln 10 und 11 näher eingehen werden). Dieses Buch wurde in der Überzeugung geschrieben, dass Teams, die über praktisches Wissen verfügen, wie man ML-Lösungen effektiv umsetzt, in der Lage sind, nach und nach bessere Vorgehensweisen zu entwickeln, wirkungsvolle Ergebnisse zu erzielen und Veränderungen in ihrer Organisation zu bewirken und zu inspirieren.

¹ Es ist erwähnenswert, dass die Identifizierung des falschen Kundenproblems, das gelöst werden soll, nicht nur bei ML vorkommt, sondern dass jedes Produkt dafür anfällig ist.

² Da es sich bei dieser Gartner-Umfrage um eine kleine Umfrage mit nur 200 Teilnehmern handelt, ist es wahrscheinlich, dass die Anzahl der ML-Projekte, die nie umgesetzt wurden, je nach Region, Branche und Unternehmen stark variiert. Nimm die konkrete Zahl mit einer Prise Salz und versuche, sie mit deinen qualitativen Erfahrungen zu vergleichen. Hast du persönlich von ML-Projekten gehört oder erlebt, die trotz monatelanger Investitionen nie an die Nutzer/innen ausgeliefert wurden?

³ Lean bietet eine nuancierte Klassifizierung von Verschwendung, auch bekannt als die "acht tödlichen Verschwendungen", die häufige Ineffizienzen aufzählen, die im Prozess der Wertschöpfung für Kunden auftreten können. Die drei Beispiele in diesem Absatz beziehen sich jeweils auf Überproduktion, Wartezeiten und Mängel. Die übrigen fünf Arten von Verschwendung sind: Transport, Überarbeitung, Lagerbestand, Bewegung und nicht ausgelastete Talente.

⁴ Jez Humble, Joanne Molesky, und Barry O'Reilly, Lean Enterprise (Sebastopol: O'Reilly, 2014).

⁵ Humble et al., Lean Enterprise.

⁶ Diese Parabel wurde erstmals in David Bayles und Ted Orlands Buch Art & Fear (Image Continuum Press) erzählt und basiert auf einer wahren Begebenheit, nur dass es sich um Fotografien und nicht um Keramiktöpfe handelt. Der Lehrer in der wahren Geschichte war Ted Orland, der Assistent von Ansel Adams, dem berühmten amerikanischen Fotografen und Umweltschützer, war.

⁷ Jeremy Jordan hat einen exzellenten Artikel geschrieben, in dem er beschreibt, wie wir mit Hilfe von Designtools Prototypen und Iterationen für das Nutzererlebnis erstellen können, um mögliche Lösungen zu kommunizieren.

⁸ Ein Desk Check ist eine kurze (z.B. 15-minütige) Besprechung mit dem Team, wenn ein Team glaubt, dass die Entwicklungsarbeit für ein Feature abgeschlossen ist. Es müssen nicht alle anwesend sein, aber es ist hilfreich, wenn die Produkt-, Technik- und Qualitätsbeauftragten beim Desk Check dabei sind. Wir haben festgestellt, dass eine kurze Besprechung der Definition des Begriffs "fertig" und der Art und Weise, wie das Paar die Funktion geliefert hat, zu einer konzentrierten und offenen Diskussion führen kann. Außerdem erspart es den Teammitgliedern das mehrfache Wechseln des Kontexts und das Warten in einem langwierigen Hin- und Hergespräch in einer Chat-Gruppe.

⁹ Das Wort "Hypothese" ist in diesem Zusammenhang technisch anders, aber begrifflich ähnlich wie in der Statistik definiert. In diesem Zusammenhang ist eine Hypothese eine überprüfbare Annahme, die als Ausgangspunkt für iterative Experimente und Tests verwendet wird, um die effektivste Lösung für das Problem zu finden.

¹⁰ Patrick K. Lin, Machine See, Machine Do: How Technology Mirrors Bias in Our Criminal Justice System (Potomac, MD: New Degree Press, 2021).

¹¹ Wenn wir über generative KI im Zusammenhang mit effektiven ML-Teams sprechen, meinen wir nicht den Einsatz von generischen Chatbots oder neuen Produktivitätstools, die Softwareentwicklungsteams beim Schreiben von Code oder User Stories helfen. Wir sprechen von ML-Teams, die eine Rolle beim Aufbau neuer Systeme spielen, die Generative KI-Technologie beinhalten.

¹² Nicole Forsgren, Jez Humble, und Gene Kim, Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Upper Saddle River, NJ: Addison-Wesley, 2018).

Get Effektive Teams 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.

Start your free trial