Continuous Delivery for Machine Learning
Von Danilo Sato, Arif Wider and Christoph Windheuser
Veröffentlicht: 5. Juli 2019
Machine Learning-Anwendungen in Produktion bringen, ist schwer.
In der heutigen Softwareentwicklung ist es selbstverständlich geworden, dass Usern laufend neue Funktionen und Erweiterungen geboten werden. Das trifft sowohl bei Benutzeranwendungen im Mobil-, Web- und Desktop-Bereich zu als auch bei moderner Unternehmenssoftware. Umfangreiche und den Betrieb störende Software Go Lives werden nicht mehr geduldet. Thoughtworks ist ein Pionier bei Continuous Delivery (CD), einer Reihe von Prinzipien und Praktiken, die die Frequenz mit der Software zuverlässig produktiv ausgeliefert werden kann, drastisch erhöhen.
Da Organisationen zunehmend Daten-getrieben arbeiten oder sich sogar bereits in Richtung KI-getrieben orientieren, wird es immer wichtiger, Data-Science- und Data-Engineering-Ansätze in die Softwareentwicklung einfließen zu lassen, damit keine spezialisierten Silos entstehen, die eine effiziente Zusammenarbeit verhindern. Allerdings ist diese Integration auch mit neuen Hürden verbunden:
Mehr Artefakte, die sich verändern. Es müssen nicht nur die Softwarecode-Artefakte verwaltet werden, sondern auch die Datenbasis und Machine Learning (ML)-Modelle sowie die in den Modellen verwendeten Parameter und Hyperparameter. Sämtliche dieser Artefakte müssen über verschiedene Stufen hinweg administriert, versioniert und optimiert werden, bis sie in Produktion übernommen werden. Die Sicherstellung von Versionierung, Qualitätskontrolle, Zuverlässigkeit, Wiederholbarkeit und Prüffähigkeit ist daher aufwändiger und komplexer.
Größe und Übertragbarkeit. Die Größenordnung von Trainingsdaten und ML-Modellen liegt im Allgemeinen deutlich über der von Softwarecode. Insofern sind für eine effiziente Handhabung andere Werkzeuge erforderlich. Dies erschwert die Nutzung eines universellen Artefakt-Formats, was zu einer "Über den Zaun werfen"-Mentalität zwischen den verschiedenen Teams führen kann.
Unterschiedliche Fähigkeiten und Arbeitsmethoden der Mitarbeiter. Für die Entwicklung von ML-Anwendungen werden Fachkräfte mit sich ergänzenden Fähigkeiten benötigt. Mitunter haben diese Fachkräfte gegensätzliche Zielsetzungen, Ansätze oder Arbeitsmethoden:
- Data Scientists befassen sich mit den Daten, extrahieren Merkmale und suchen nach geeigneten Modellen, mit denen sich die gewünschten Erkenntnisse am besten gewinnen lassen. Sie gehen vorzugsweise wissenschaftlich vor, indem sie Hypothesen aufstellen und diese anhand der Daten verifizieren oder entkräften. Sie brauchen Werkzeuge, mit denen sie Daten verarbeiten, parallele Experimente durchführen, Prototypen zügig erstellen, Daten visualisieren und mehrere Modelle skalierbar trainieren können.
- EntwicklerInnen und ML-Engineers wollen die Modelle in reale Anwendungen oder Services einbinden und dort einsetzen. Ihr Anliegen ist es, dass die Modelle möglichst zuverlässig, sicher, effizient und skalierbar sind.
- Data Engineers kümmern sich darum, dass die richtigen Daten stets auf dem aktuellen Stand und von hoher Qualität sind und im jeweils benötigten Umfang, Format und Detailgrad schnell und kosteneffizient abgerufen werden können.
- Die (Unternehmens-) Fachseite definiert die Anforderungen. Sie geben die Untersuchungsrichtung der Data Scientists vor. Sie legen fest, anhand welcher Kennzahlen gemessen wird, ob das ML-System die gewünschten Resultate auf dem angestrebten Qualitätsniveau liefert.
Continuous Delivery for Machine Learning (CD4ML) ist der technische Ansatz, mit dem dieser Problematik entgegengewirkt werden soll. CD4ML bringt die verschiedenen Gruppen an einen Tisch, sodass sie ML-Anwendungen entwickeln, bereitstellen und kontinuierlich verbessern können.
Der Continuous-Intelligence-Zyklus
Im ersten Artikel der Reihe The Intelligent Enterprise haben wir den Continuous-Intelligence-Zyklus vorgestellt (siehe Abbildung 2).
Hierbei handelt es sich um einen Prozess, der in irgendeiner Form in fast jedem Unternehmen existiert, und der das Ziel hat gesammelte Daten erst in Informationen und dann in Erkenntnisse und Maßnahmen umzuwandeln, um so datengestützte Entscheidungen zu ermöglichen. In traditionellen Organisationen basiert dieser Zyklus auf Altsystemen (wie Data Warehouses oder ERP-Systemen) und Entscheidungen durch Menschen. In diesen Organisationen ist der Prozess langwierig und hakt an etlichen Stellen: ML-Anwendungen werden oft losgelöst entwickelt und kommen nie über die Proof-of-Concept-Phase hinaus. Schaffen sie es tatsächlich bis zur Produktion, handelt es sich oft um eine einmalige Angelegenheit. Das Aktualisieren und Neutrainieren gestaltet sich schwierig, so dass Modelle bald veraltet und überholt sind.
Intelligente Unternehmen wissen, wie sie den Continuous-Intelligence-Zyklus beschleunigen und Reibungspunkte beseitigen können. CD4ML ist der technische Ansatz zur schnelleren Wertschöpfung von ML-Anwendungen im Rahmen des Continuous-Intelligence-Zyklus. CD4ML macht es möglich, von Offline-Modellen und manuellen Implementierungen wegzukommen, den Prozess der datengestützten Gewinnung von Informationen, Erkenntnissen und Entscheidungen auf ganzer Linie zu automatisieren, und daraus wieder Daten zu erfassen, mit denen sich die Ergebnisse messen lassen. So kann der Continuous-Intelligence-Zyklus schneller durchlaufen werden. Durch Berücksichtigung des Feedbacks im Prozess lassen sich zudem qualitativ bessere Ergebnisse bei geringerem Risiko erzielen.
Was ist CD4ML?
CD4ML ist eine Anwendung und Erweiterung von Continuous Delivery (CD). In ihrem wegweisenden Buch definierten Jez Humble und David Farley Continuous Delivery als Softwareentwicklungsansatz, bei dem Teams Software in kurzen Zyklen produzieren, sodass die Software jederzeit zuverlässig ausgeliefert werden kann. Bewerkstelligen lässt sich dies durch einen wiederholbaren, zuverlässigen Prozess für die Softwareerstellung, durch eine möglichst weitreichende Automatisierung und durch Fokussierung auf Qualität.
Humble und Farley zufolge ist Continuous Delivery die Fähigkeit, Änderungen jeglicher Art (einschließlich neuer Funktionen, Konfigurationsänderungen, Fehlerkorrekturen und experimenteller Änderungen) in Produktion zu bringen bzw. an die Anwender zu übergeben – sicher, schnell und nachhaltig.
Änderungen an den ML-Modellen sind lediglich eine weitere Art von Änderungen, die verwaltet und ausgeliefert werden müssen. Die existierenden CD-Techniken und -Werkzeuge müssen jedoch erweitert werden, um auch mit diesen Artefakten umgehen zu können. Außerdem wird der gesamte Softwareentwicklungszyklus komplexer, da die Teammitglieder in einem cross-funktionalen Team (Data Scientists, Data Engineers, EntwicklerInnen und ML-Engineers) unterschiedliche Kompetenzen und Vorgehensweisen mitbringen.
Thoughtworks hat den Continuous-Delivery-Ansatz weiterentwickelt, sodass er sich auch auf ML-Anwendungen anwenden lässt, und bezeichnet diesen neuen Ansatz als Continuous Delivery for Machine Learning (CD4ML). Die Definition von Continuous Delivery wird um neue Elemente erweitert, die zur Beschleunigung des Continuous-Intelligence-Zyklus nötig sind:
Continuous Delivery for Machine Learning (CD4ML) ist ein Softwareentwicklungsansatz, bei dem ein cross-funktionales Team ML-Anwendungen entwickelt, die auf Code, Daten und Modellen basieren; und zwar mittels kleiner, inkrementeller Änderungen, die jederzeit reproduzierbar und zuverlässig ausgeliefert werden können, in kurzen Adaptionszyklen.
Diese Definition umfasst alle wesentlichen Grundsätze:
Softwareentwicklungsansatz. Teams können damit effizient hochwertige Software erzeugen.
Cross-funktionales Team. Fachkräfte mit unterschiedlichen Fähigkeiten und Workflows, die sich über Data Engineering, Data Science, Entwicklung, Betrieb und andere Wissensbereiche erstrecken, arbeiten eng zusammen, sodass die Kompetenzen und Stärken der einzelnen Teammitglieder zum Tragen kommen.
Erzeugung von Software auf der Grundlage von Code, Daten und ML-Modellen. Jedes Artefakt des Softwareentwicklungsprozesses (Code, Daten, Modelle, Parameter) setzt bestimmte Werkzeuge und Workflows voraus und muss entsprechend verwaltet werden.
Kleine, inkrementelle Änderungen. Die Entwicklung und Auslieferung von Software-Artefakten ist in kleinschrittige Änderungen unterteilt. Dies gewährleistet Transparenz und Kontrolle hinsichtlich der Auswirkungen dieser Änderungen und macht den Prozess sicherer.
Reproduzierbare und zuverlässige Softwareauslieferung. Der Prozess zur Auslieferung produktionsreifer Software ist zuverlässig und reproduzierbar. Er erfolgt weitestgehend automatisiert. Alle Artefakte (Code, Daten, Modelle, Parameter) verfügen über eine entsprechende Versionsverwaltung.
Jederzeitige Softwareauslieferung. Wichtig ist, dass die Software jederzeit produktionsreif ausgeliefert werden könnte. Selbst wenn Organisationen nicht laufend Software ausliefern möchten – durch die Auslieferungsfähigkeit ist das tatsächliche Freigabedatum eine Geschäftsentscheidung und keine technische.
Kurze Adaptionszyklen. Kurze Entwicklungszyklen spielen sich in einer Größenordnung von Tagen oder Stunden anstatt von Wochen, Monaten oder gar Jahren ab. Dazu bedarf es eines automatisierten Prozesses, einschließlich integrierter Qualitätssicherungen. So entsteht eine Feedbackschleife: Sie ziehen Rückschlüsse aus dem Verhalten der produktiven Software und können Ihre Modelle entsprechend anpassen.
Zusammenspiel der Komponenten
CD4ML dient dazu, den ML-Lebenszyklus durchgängig zu automatisieren und einen kontinuierlichen, reibungslosen Prozess zu gewährleisten: von der Datenerfassung über das Modellieren und Experimentieren zur Lenkung und weiter zum Produktiveinsatz. In Abbildung 3 wird der gesamte Prozess übersichtlich dargestellt.
In der Darstellung beginnt der Zyklus links. Data Scientists befassen sich mit Daten, die sie in verschiedenen Datenquellen vorfinden und abrufen. Sie extrahieren Merkmale, unterteilen die Daten in Trainings- und Testdaten, erstellen Modelle und experimentieren mit ihnen. Sie schreiben Code, um die Modelle zu trainieren (häufig in Python oder R), und optimieren diese Modelle mit Hilfe der Parameter und Hyperparameter.
Während die Modelle trainiert werden, führen die Data Scientists laufend Evaluierungen durch. Dabei werden die Fehlerrate der Modelle, die Konfusionsmatrix und die Anzahl falsch positiver und falsch negativer Ergebnisse geprüft, oder es werden bestimmte Testskripte ausgeführt, z. B. für Chatbots. Die Tests sollten mit Hilfe von Testumgebungen, Testskripten oder Testprogrammen so weit wie möglich automatisiert werden.
Hat man ein gutes Modell ermittelt, kann es produktionsreif gemacht werden. Dafür ist eine Anpassung des Modells an die Produktivumgebung nötig. Eventuell muss der Modellcode in Container verpackt oder in eine Sprache wie Java oder C++ umgewandelt werden (manuell oder mittels automatischer Transformationswerkzeuge). Die produktionsreife Version des Modells muss mit anderen Komponenten der Gesamtarchitektur erneut getestet werden, bevor sie tatsächlich produktiv ausgeliefert werden kann.
Im Produktiveinsatz müssen wir beobachten und verfolgen, wie sich das Modell in der Praxis verhält. Messgrößen wie Nutzung, Input, Output und mögliches Bias des Modells liefern wichtige Informationen über dessen Leistungsfähigkeit. Diese Daten sollten dann in die erste Prozessstufe zurückfließen, damit weitere Verbesserungen erfolgen können: Der gesamte Continuous-Intelligence-Zyklus wird erneut durchlaufen.
Der Transport der Artefakte (Quellcode, ausführbare Programme, Trainings- und Testdaten oder Modellparameter) zwischen den verschiedenen Prozessstufen wird über Pipelines gesteuert, die mittels eines CD-Orchestrierungswerkzeugs ausgeführt werden. Da jedes Artefakt versioniert wird, sind Reproduzierbarkeit und Prüffähigkeit gegeben. Dadurch lassen sich bei Bedarf Vorgängerversionen wiederherstellen. Das CD-Orchestrierungswerkzeug sorgt für den reibungslosen Ablauf des gesamten Prozesses und ermöglicht außerdem Governance und Compliance. Im Prozess sind also bestimmte Qualitätsstandards und Fairness-Checks enthalten.
CD4ML in Aktion
Wir möchten den Ansatz in der Praxis anhand eines echten, von Thoughtworks realisierten Kundenprojektes demonstrieren. Die Entwicklung unseres heutigen CD4ML-Konzepts begann vor einigen Jahren. Damals wandten wir bei der Entwicklung einer Endnutzer-orientieren ML-Anwendung erstmals Continuous Delivery an. Die Einzelheiten können Sie hier nachlesen.
Unsere Aufgabe bestand darin, für einen führenden europäischen Online-Automarkt eine Engine zur Schätzung von Preisen zu erstellen. Die Engine musste in der Lage sein, allen Kauf- oder Verkaufsinteressierten einen realistischen Schätzwert zu unterbreiten. Die Preisschätzung sollte sich auf die bisherigen Fahrzeugverkäufe auf dem Online-Marktplatz stützen. Da sich der Gebrauchtwagenmarkt ständig verändert, muss das Prognosemodell immer wieder mit neuen Daten trainiert werden. Die perfekte Aufgabe für CD4ML also.
Abbildung 4 gibt den allgemeinen CD4ML-Ablauf für diesen konkreten Fall wieder. Data Scientists trainieren das Modell mit den Daten des Online-Marktplatzes (wie Angaben zum Fahrzeug, Angebotspreis und tatsächlichem Verkaufspreis). Das Modell prognostiziert dann ausgehend von Fahrzeugmodell, Fahrzeugalter, Laufleistung, Motortyp, Ausstattung usw. einen Preis.
Bevor ein Modell trainiert werden kann, müssen die Daten erst einmal gründlich von Ausreißern, falschen Listenpreisen oder fehlerhaften Daten bereinigt werden. Das ist das erste Quality Gate, das automatisiert werden sollte: Gibt es genügend verwendbare Daten, um überhaupt ein Prognosemodell für ein bestimmtes Fahrzeugmodell zu erstellen?
Sobald das trainierte Modell eine ausreichende Anzahl korrekter Schätzpreise liefert, wird es als produktionsreifes Artefakt exportiert (JAR- oder Pickle-Datei). Das ist das zweite Quality Gate: Ist die Fehlerquote des Modells akzeptabel?
Anschließend wird dieses Prognosemodell in ein für die Zielplattform geeignetes Format umgewandelt, verpackt und in ein bereitstellbares Artefakt integriert. Beispielsweise ein JAR mit integriertem Webserver oder ein Container-Image, das direkt in einer Produktivumgebung bereitgestellt werden kann. Dieses bereitgestellte Artefakt wird nun erneut getestet, diesmal auf Ende-zu-Ende-Basis: Liefert es noch immer die gleichen Ergebnisse wie das ursprüngliche, nicht integrierte Prognosemodell? Verhält es sich in einer Produktivumgebung korrekt? Werden Consumer-Driven Contracts beachtet? Das ist das dritte Quality Gate.
Passiert das Modell alle drei Quality Gates mit Erfolg, wird das neu trainierte Modell als Preisprognosedienst ausgeliefert und produktiv geschaltet. Dabei sollten alle Schritte unbedingt automatisiert werden, damit das Modell (solange die Quality Gates erfolgreich durchlaufen werden) ohne manuellen Eingriff mit den aktuellen Marktveränderungen erneut trainiert werden kann.
Abschließend wird die Preisprognose im Live-Betrieb laufend überwacht: Wie reagieren die VerkäuferInnen auf die Preisempfehlungen? Wie stark weicht der Inseratspreis vom Vorschlag ab? Wie eng liegen Preisprognose und endgültiger Verkaufspreis des jeweiligen Fahrzeugs beieinander? Wie wirkt sich die Umstellung insgesamt aus? Welchen Eindruck haben die Nutzer, gibt es z. B. mehr Beschwerden oder mehr positive Rückmeldungen? Für einen direkten Leistungsvergleich kann es mitunter sinnvoll sein, das neue Modell parallel zur alten Version auszuliefern. Schlussendlich fließen sämtliche neuen Daten in die nächste Iteration des Modelltrainings ein, sei es direkt durch neue Daten zu verkauften Fahrzeugen oder indem die Hyperparameter des Modells anhand von Benutzerfeedback verändert werden. Hiermit schließt sich der Continuous-Intelligence-Zyklus.
Chancen von CD4ML und Ausblick
Mit der Einführung von Continuous Delivery for Machine Learning eröffnen sich Unternehmen neue Chancen, zum intelligenten Unternehmen zu werden. Durch Automatisierung des gesamten Prozesses vom Experimentieren bis zur Auslieferung und Überwachung im Produktivbetrieb wird CD4ML zum strategischen Wegbereiter. Es schafft eine Technologiekompetenz, die letztlich Wettbewerbsvorteile bringt. Ferner erlaubt es Ihrer Organisation, Lernen und Feedback in den Prozess aufzunehmen und so kontinuierliche Verbesserungen zu erzielen.
Bei diesem Ansatz werden außerdem die Silos aus einzelnen Teams und Fähigkeiten aufgebrochen. Stattdessen entsteht eine funktionsübergreifende Kooperationsstruktur, die zur Wertschöpfung beiträgt. Sie haben die Möglichkeit, Ihre Organisationsstruktur und Technologielandschaft neu aufzusetzen und Ihre Teams und Systeme auf die Geschäftsergebnisse auszurichten. In weiteren Artikeln unserer Reihe werden wir uns damit befassen, wie man die Welt der Daten und des maschinellen Lernens produktorientiert betrachten kann (Stichwort „Product Thinking“). Außerdem werden wir aufzeigen, wie wichtig eine Continuous-Intelligence-förderliche Kultur ist.
Eine weitere ausgezeichnete Möglichkeit zur erfolgreichen Anwendung von CD4ML bietet „Platform Thinking“ auf Ebene der Dateninfrastruktur. Dabei können Teams neue Produkte für maschinelles Lernen und zur Erkenntnisgewinnung schnell entwickeln und freigeben, ohne dass sie von vorn anfangen, Doppelarbeit leisten oder gängige Komponenten von Grund auf neu erstellen müssen. Ein Artikel wird komplett den technischen Komponenten, Tools, Techniken und der Automatisierungsinfrastruktur gewidmet sein, mit deren Hilfe sich CD4ML leichter implementieren lässt.
Dank Automatisierung und offener Standards liefert CD4ML die Mittel für einen robusten Prozess zur Lenkung von Daten und Architektur innerhalb des Unternehmens. Mit CD4ML lassen sich Prozesse einführen, mit denen Sie Ihre Modelle auf dem Weg zur Produktionsreife in Bezug auf Fairness, Bias, Compliance oder andere Qualitätsattribute überprüfen können. Wie bei Continuous Delivery in der Softwareentwicklung können Sie mit CD4ML die Risiken der zügigen Produktivauslieferung von Änderungen sicher und zuverlässig steuern.
Alles in allem befördert Continuous Delivery for Machine Learning die Entwicklung von ML-Anwendungen weg von unberechenbarer Proof-of-Concept-Programmierung hin zu professioneller, hochmoderner Softwareentwicklung.
Read Part 1 of this series to explore models of enterprise intelligence: to understand how businesses use data to derive insights today, and how they can improve.
Part 2 delves deeper into patterns of enterprise intelligence and identifies the points of friction and opportunities for improvement in the Continuous Intelligence cycle.