Transcript
Robert Glaser: Hi, herzlich willkommen beim INNOQ-Podcast! Heute gibt es uns auch mal parallel als Video. Das probieren wir jetzt einfach mal aus. Vielleicht gefällt es ja dem einen oder der anderen. Ich habe heute meine liebe Kollegin, die Larysa, bei mir. Hallo, Larysa!
Larysa Visengeriyeva Hallo, Robert, grüß dich.
Robert Glaser: Hi, grüß dich. Wir sprechen heute zu einem Thema, was wir noch nicht so oft im Podcast vertreten hatten, nämlich so ein bisschen das ganze Thema Machine Learning und der Betrieb davon, also die operations. Konkret geht es um MLOps. Aber bevor wir da direkt einsteigen in das Thema, magst du vielleicht kurz ein bisschen erzählen, wer du bist, was du bei INNOQ machst, was du vielleicht vorher so gemacht hast. Stell dich doch mal kurz vor.
Larysa Visengeriyeva Danke für die Frage. Ich bin seit einem halben Jahr bei INNOQ und bin recht glücklich damit. Und davor: Ich komme als Überflieger aus der academia. Davor habe ich im Bereich Data Cleaning promoviert. Das heißt, ich habe einige Jahre mich mit dem Thema Data Preparation, Data Cleaning, Data Profiling beschäftigt. Und, wie gesagt, habe in dem Bereich promoviert. Wie ich zu INNOQ gekommen bin? Ja, das ist auch eine lange Geschichte. In diesem halben Jahr frage ich mich andauernd, warum ich das nicht früher gemacht habe. Vor zehn Jahren, als ich als Junior Developer zum ersten Mal auf den INNOQ-Namen gestoßen bin. Und ja, wenn man im deutschsprachigen Raum unterwegs ist, ist es schwer, an INNOQ nicht vorbeizukommen. [nicht über INNOQ zu stolpern? An INNOQ vorbeizukommen?]
Robert Glaser: Das ist doch schön. Das werde ich dem Marketing berichten [lacht].
Larysa Visengeriyeva [lacht] Wie gesagt: INNOQ war für mich schon immer eine kompromisslose Kompetenz im Tech-Bereich. Diese ganzen Begriffe: Self-Contained Systems, Microservices. Ich glaube schon, dass INNOQ das hier in Europa geprägt hat.
Robert Glaser: Aber viel interessanter ist ja: Was hast du vorher gemacht?
Larysa Visengeriyeva Ich war Backend-Entwickler. Das heißt, ich habe mich mit Datenbank-Programmierung beschäftigt. Bis mir langweilig wurde. Und dann habe ich gedacht: Okay, ich brauche echte Probleme, um die zu lösen. Zu dem Zeitpunkt hat sich eine Chance in academia aufgetan. Und, wie schon gesagt, man will an einem echten Problem arbeiten. Und dieses Problem habe ich gefunden, nämlich Data Quality, Data Cleaning, Data Quality Management. Das werden wir auch in unserem Gespräch heute erwähnen. Warum das wichtig ist, insbesondere im Kontext von Machine Learning. Und der zweite Aspekt von INNOQ, den ich wertschätze, ist Diversität. 2016 wurde ich von unserem lieben Kollege Daniel Westheide als Scala-Coach eingeladen, und da durfte ich wirklich diese INNOQ-Kultur von innen kennenlernen. Und das hat mich endgültig überzeugt. Genau. Diese zwei Aspekte von INNOQ: Kompromisslose Kompetenz und Diversität. Es war einfach klar, was ich nach meiner Promotion machen möchte. Und so bin ich hier [gelandet].
Robert Glaser: Aber jetzt müssen wir dringend wechseln von der Selbstbeweihräucherung, sonst springen hinterher noch die lieben Hörerinnen und Hörer ab. [beide lachen] Was machst du denn jetzt aktuell bei INNOQ eigentlich? Womit beschäftigst du dich?
Larysa Visengeriyeva Nachdem ich mich mit einem Problem, nämlich Data Cleaning, beschäftigt habe, habe ich festgestellt: Eigentlich haben wir noch mehr Probleme in dieser Welt. Und ich hatte in meiner Forschung Data-Cleaning-Error-Detection-Systeme entwickelt, wo ich Machine Learning eingesetzt habe. Und es lief ganz gut, bis ich festgestellt habe, beziehungsweise, ich habe mich selbst gefragt: Wenn ich so ein System ausliefern würde, an irgendeinen Kunden, hätte ich keine Chance.
Robert Glaser: Warum?
Larysa Visengeriyeva Irgendwann am Anfang meiner Karriere stand ich da und habe gesagt: Okay, wir wissen, wie Software Engineering funktioniert. Wir können also unsere Software-Systeme bauen. Aber wenn da die Machine Learning reinkommt? Plötzlich verfallen wir in Wüste und 80er und fangen an zu coden mit Spaghetticode und so weiter und so fort. Und auch eine persönliche Story: Ich habe so ein Data-Cleaning-System gebaut mit Machine-Learning-Modellen, und das war so grottenschlecht. Nach dem ersten Review von meinem Paper musste ich natürlich das System umbauen. Und das hat dazu geführt, dass ich das System quasi neu geschrieben habe, weil das alte System einfach irreparabel war. Und da ist bei mir dieses Bewusstsein gekommen: Okay, wenn wir solche Systeme in Betrieb nehmen oder bei Kunden abliefern. Wie machen wir das? Und das Thema habe ich dann auch immer wieder verfolgt. Und je mehr wir uns in dieser Welt bewegen, desto mehr stellen wir fest, dass wir immer mehr Daten ansammeln. Und es gibt diverse Statistiken, diverse Prognosen. Die letzte war zum Beispiel von Statista. Den Link kann ich dann später auch in den Shownotes angeben.
Robert Glaser: Ja, den packen wir später in die Shownotes.
Larysa Visengeriyeva Und da werden wir sehen, dass die Anzahl von Daten exponentiell wächst. Und irgendwann, zu irgendeinem Zeitpunkt werden wir keine andere Möglichkeit haben, als solche Technologien wie Machine Learning, Künstliche Intelligenz oder Data-Science-Methodiken zu verwenden, um aus diesen Daten Insights, also Inhalte, Wert zu schöpfen. Das heißt also, das sind zwei globale Trends, die unser Leben schon prägen. Und das wird immer mehr. Das heißt, wie ich schon gesagt habe: Wir können zwar Machine Learning anwenden, und es ist auch der Fall, dass wir immer mehr Data Scientists einstellen, Data-Science-Teams aufbauen. Aber plötzlich kommen solche Studien wie von Algorithmica. Und die sagen: 80 Prozent aller Modelle, die von Data-Science-Teams und Machine-Learning-Abteilungen gebaut wurden, kommen nicht in Production. Das ist schon eine heftige Zahl, 80 Prozent. Und hier ist natürlich auch sofort die Frage klar: Okay, warum? Und die einfache Antwort auf diese Frage ist: Machine-Learning-Systeme in Betrieb zu nehmen, die zu operationalisieren, ist viel komplexer, als eine quasi konventionelle Software auszuliefern. Da muss man sich einfach im Klaren sein: Wir müssen uns erstmal vorstellen, dass auch dieser Aspekt von Machine Learning wichtig ist: Machine-Learning-Modelle sind nur dann wertvoll, wenn sie irgendwo echte Daten kriegen und irgendetwas predicten. Und das andere Moment bei solchen Systemen ist, dass wir es mit einer erhöhten Komplexität zu tun haben, weil wir nicht nur den Code haben, den wir warten, pflegen, weiterentwickeln müssen, sondern wir haben es jetzt mit Machine-Learning-Modellen zu tun, und Machine-Learning-Modelle gehen auch Hand in Hand mit Daten. Das heißt also: Code, Machine-Learning-Modelle und Daten. Das sind so drei Komponenten, die ins Spiel kommen. Und eine ganz wichtige Sache, um einfach nur Machine-Learning-Produkte oder Machine-Learning-Systeme zu verstehen: Wenn wir beide von der traditionellen Programmierung sprechen, dann kommen Daten, Regeln rein und wir haben Output. Bei den Machine-Learning-Modellen: Machine Learning produziert Programme, Funktionen. Das heißt, wir geben Daten, und Machine Learning sucht da Patterns raus. Und der Output ist quasi dieses Programm, was wir dann für die zukünftigen Daten einsetzen, um die Antwort zu kriegen. Und man muss sich hier auch ganz klar bewusst sein: Es ist kein deterministisches System. Das heißt, die Antworten von diesen Modellen können auch nicht ganz richtig sein, ja, falsch sein. Man sagt so “Probabilistic Systems”. Das heißt, die sind stochastisch. Und genau das macht in diesem ganzen Machine Learning Engineering uns allen zu schaffen.
Robert Glaser: Also ist wahrscheinlich das Testen auch eine Herausforderung? Wenn ich sagen kann, dass sich das nicht deterministisch verhält und ich Änderungen an meinem Modell mache und hinterher kommen durch eigentlich kleine Änderungen völlig unvorhergesehene Ergebnisse raus. Dann ist wahrscheinlich testen eine Herausforderung.
Larysa Visengeriyeva Genau, testen ist eines der essenziellen Elemente für ein Continuous Deployment in den normalen Systemen. Wir können nur so ein automatisiertes Deployment machen, wenn wir entsprechend genug getestet haben, und auf verschiedenen Ebenen. Die ganze Testpyramide muss natürlich abgedeckt werden. Und wenn wir das mit Machine-Learning-Systemen machen, dann ist das Testen noch eine Stufe härter, weil wir halt diesen stochastischen, nicht deterministischen Aspekt haben. Und zweitens: Wir müssen hier nicht nur den Code testen, also den Software-Code von unserer Applikation, sondern wir müssen hier diese ganzen Data Pipelines abtesten. Wir müssen Model Engineering Pipelines testen. Und da kann man zum Beispiel bei Data Pipelines Data-Qualität checken, davon kann ich ein Lied singen [lacht].
Robert Glaser: Ja, das kann ich mir vorstellen [lacht]. Aber lass uns nochmal zwei Schritte zurück machen, weil wir jetzt schon so in die große Welt der Herausforderungen von Machine-Learning-Systemen abgedriftet sind. Darum soll es ja eigentlich auch gehen, weil, das ist ja Kern des Themas. Aber, für mich zumindest, nochmal zwei Schritte zurück. Aus deiner Erfahrung heraus: Was würdest du denn sagen - was sind so die typischen Probleme, die man heute hat oder die dabei auftreten, wenn ich Machine-Learning-Modelle in den Betrieb bringen will? Wir können uns ja einfach mal ein Beispiel ausdenken. Zum Beispiel ein Modell, was Kategorisierung von Tank-Quittungen oder Belegen aller Art vornehmen kann. Wenn ich so ein Modell habe und das Modell evolviert. Ich mache Änderungen, Verbesserungen am Modell über die Zeit. Wie bringe ich so etwas in Betrieb? Kennst du da typische Probleme und Herausforderungen und magst dann mal erklären, wie man die vielleicht angehen kann?
Larysa Visengeriyeva Gut, an sich ist Machine Learning Engineering oder Machine-Learning-Operationalisierung ein relativ junges Thema, junges Gebiet. Allerdings haben wir schon gewisse Patterns, wie man zum Beispiel Machine-Learning-Modelle in Betrieb nimmt. Normalerweise, oder ganz oft, sehen wir folgende Lösung: Wir nehmen den ganzen Machine-Learning-Stack, verpacken den in einen Container und den Container deployen wie auf irgendeinen Server mit Kubernetes. Und dann geben wir einen Endpoint und unser Modell ist dann über eine REST-API ansprechbar, und so kann dieses Modell neue Daten sehen und Predictions machen. Es gibt verschiedene Varianten. Das ist jetzt eine Möglichkeit, das zu tun. Es ist momentan die populärste Variante. Wir können auch, wenn ein Machine-Learning-Modell gebaut wurde und dann in einem bestimmten Format verpackt wurde, das so wie eine normale JAR in unsere Applikation integrieren. Und dann brauchen wir keine REST-API. Es gibt Vorteile und Nachteile. Und es ist auch abhängig von den ganzen Use Cases.
Robert Glaser: Von der Architektur? Also, wenn ich viele Systeme habe, ist es wahrscheinlich schlauer, das Machine-Learning-Modell als eigenen Service irgendwie mit einer kleinen REST-API irgendwo zu deployen. Du hast es ja gerade schon gesagt, vielleicht beispielsweise im Docker-Container verpackt oder ohne Docker-Container, was auch immer am besten passt. Oder wenn ich eh einen Monolithen habe und keine anderen Dienste, kann ich es vielleicht auch als JAR mit in mein Java-Projekt binden.
Larysa Visengeriyeva Genau. Und das ist nur die Hälfte des Problems. Wir haben das Modell in die Welt gesetzt. Das Modell fängt an, neue Daten zu kriegen. Und die eigentliche Arbeit fängt jetzt gerade an, weil die Besonderheit von Machine-Learning-Systemen ist: Die Modelle wurden trainiert auf den alten historischen Daten. Und wir können aber gar nicht voraussagen: Welche Daten werden dann in Zukunft ankommen? Du hast jetzt eine Beispiel-Anwendung gebracht, zur Tankquittung, Belegen.
Robert Glaser: Ich kenne da so ein paar Leute, die entwickeln eine Reisekostenkostenanwendung [lacht]. Deswegen lag mir diese Problemstellung noch im Kopf rum.
Larysa Visengeriyeva Und stell dir vor, die Hälfte der Firma hat sich plötzlich einen Tesla oder ein anderes Elektroauto geleast. Und dann kommen nicht die Tankstellen-, sondern irgendwelche Stromrechnungen.
Robert Glaser: Das ist ein schönes Beispiel, ja.
Larysa Visengeriyeva Aber wir haben jetzt mit unseren historischen Daten das Modell trainiert, was nur die Tankstellen, nur Benzin und Diesel gesehen hat. Und jetzt fängt das Modell an, irgendetwas zu predicten, was überhaupt nicht sinnvoll ist. Das ist ein sehr berühmtes Phänomen, heißt Model Decay. Also: Das Modell ist nicht mehr aktuell. Und genau an dem Zeitpunkt, wo wir feststellen: Okay, irgendetwas mit der Performance von dem Modell läuft nicht gut, müssen wir das Modell neu trainieren. Das heißt, dass wir auch alle Daten, die wir vom Zeitpunkt der Modell-Inbetriebnahme bis zum Feststellen: Das Modell ist jetzt veraltet, [gesammelt haben], einsammeln müssen. Das sind sozusagen neue Daten. Müssen sie irgendwo loggen, monitoren. Und diese Daten müssen wir dann für unser Retraining von dem neuen Modell verwenden. Beziehungsweise, wenn wir dann irgendwo feststellen: Ja, wir brauchen neue Daten. Die Welt hat sich massiv verändert. Dann müssen wir irgendwo auch kreativ werden und sagen: Okay, wo kriegen wir die neuen Daten her? Das ist auch ein sehr wichtiger Aspekt von Machine-Learning-Applikationen. Dann müssen wir natürlich feststellen, dass die Daten auch der Qualität entsprechend sind, weil: Schlechte Daten, schlechte Modelle, garbage in - garbage out. Das ist auch ein sehr verbreitetes Problem. Und an dieses Problem geraten Leute, wenn sie anfangen, mit Machine-Learning-Modellen zu experimentieren. [Dann] kommt das gar nicht auf den Tisch. Aber wenn das tatsächlich im Betrieb läuft, und wir neue Modelle brauchen, dann fangen sie an, an Datenqualität zu denken, weil sie auch feststellen, dass das massiven Einfluss auf die Qualität von den Modellen hat.
Robert Glaser: Das hast du schön gesagt, “garbage in - garbage out”. Da entsteht ja auch dieses Bias-Problem, was viele Machine-Learning-Modelle wahrscheinlich haben, die irgendwie menschliche Facetten kategorisieren sollen oder sowas. Ich habe gestern zum Beispiel ein Beispiel gesehen, wo verpixelte menschliche Gesichter wieder geschärft werden sollten, damit man wieder was erkennt. Dieses typische CSI-optimize [ich finde das bei google nicht, stimmt die Transkription? Vielleicht CS3?]. Und da wurden dann einfach offenkundig Menschen mit verschiedenen Hautfarben immer so optimiert oder geschärft, dass man sie wieder erkennen konnte, dass sie aber letzten Endes wie Menschen mit weißer Hautfarbe aussahen, obwohl sie eigentlich Schwarze Hautfarbe hatten oder ganz andersartig aussahen als die Zielvorstellungen, die dieses komische Machine-Learning-Modell hatte. Das basiert wahrscheinlich auch rein auf den Daten, mit denen dieses Modell trainiert wurde. Und die hatten ganz offenbar schon einen starken Bias drin.
Larysa Visengeriyeva Definitiv. Von solchen Beispielen gibt es auch ganz viele. Wenn wir ein Spiel-Modell entwickeln, das kann vielleicht richtig lustig aussehen. Aber wenn wir überlegen, wie Tesla und die ganze image recognition. Wenn die Modelle nur weiße Menschen erkennen…
Robert Glaser: Alptraumhafte Vorstellung eigentlich.
Larysa Visengeriyeva Genau.
Robert Glaser: Also, da muss man aufpassen. Aber zählt dieses Thema Datenqualität - das ist ja wahrscheinlich das Thema Datenqualität - auch zu diesem, was du ganz am Anfang erwähnt hattest, Machine-Learning-Operations-Überbegriff, womit du dich gerade beschäftigst?
Larysa Visengeriyeva Ja, definitiv. Es ist so, dass wir diese ineinander verketteten Pipelines haben. Und die Datenqualität, oder die Daten-Pipelines, die wir ganz am Anfang haben. Das Ganze propagiert einfach bis zu der Qualität der Predictions, die Machine-Learning-Modelle machen. Das ist die Natur von solchen Machine-Learning-Applikationen. Da, wo wir ineinander verschachtelte Pipelines haben, und diese ganze Propagation der Errors eine ganz wichtige Rolle spielt.
Robert Glaser: Stellen wir uns doch mal vor, wir beide arbeiten in einem Software-Entwicklungsteam, in einer Versicherung oder wo auch immer. Und wir haben eine kleine Business-Anwendung, für die wir zuständig sind. Die Pflege von Verträgen, oder sowas. Und wir haben eine blöde, wiederkehrende Aufgabe, die uns unheimlich viel Zeit kostet, nämlich Risiken in Verträgen zu identifizieren, oder sowas. Und jetzt haben wir im Hackathon letztes Wochenende ein kleines Machine-Learning-Modell entwickelt, was uns vielleicht dabei hilft, irgendwie diese Risiko-Identifizierung vorzunehmen. Und das ist so komfortabel und hat eine richtige Erkennungsrate von 90 Prozent der Risiko-Klassifizierungen. Dann wissen wir ja, nichts geht schneller in Produktion als ein Prototyp [beide lachen]. Und weil wir keine Lust haben, die Risiko-Identifizierung zusammen mit der Fachabteilung immer und immer wieder manuell zu machen, schieben wir das diese Woche in Produktion, und dann läuft das Ding. Was müssen wir denn dabei beachten? Bei dem Betrieb und beim Deployment dieses Modells.
Larysa Visengeriyeva Erstmal: Das ganze Feature Engineering. Einen Schritt zurück. Wir müssen bei Machine-Learning-Applikationen auch zwei Phasen beachten. Das ist die Phase des Trainings und die Phase der Predictions. Da, wo das Modell die neuen Daten kriegt. Und da muss man einige Sachen beachten, wie zum Beispiel Feature-Engineering. Die Features, also, die Inputdaten für unsere Machine-Learning-Algorithmen, müssen genau die gleichen Methoden/Funktionen haben, wie wir in Betrieb haben. Das heißt also, da darf es keine Code-Duplication geben. Zweitens, zum Beispiel…
Robert Glaser: Wie würde ich das denn automatisieren? Also: Ich habe da mein Modell und ich habe mit der Fachabteilung Versicherungsverträge der letzten 25 Jahre und damit wird das Modell trainiert. Dann ist das Modell ja wahrscheinlich eine Datei, wo all das Wissen des Modells drin steckt, und die Erkenntnisse. Wie schiebe ich diese Datei denn in Produktion? Also, wie muss ich mir das vorstellen? Checke ich die mit in ein Repository ein?
Larysa Visengeriyeva Natürlich, ja. [lacht]
Robert Glaser: Oder lade ich das irgendwo hoch? Oder sollte ich das nicht vielleicht wie meine normale Software auch irgendwie in eine Continuous-Delivery-Pipeline integrieren? Wie gehe ich da vor, als Team?
Larysa Visengeriyeva Ich verstehe schon. Also, nachdem diese explorative Phase vorbei ist und wir ein Modell gefunden haben, geht es quasi in diese Operationalisierungs-Phase über. Und hier müssen wir natürlich, genauso wie wir das von den [das habe ich nicht verstanden] Software-Engineering-Prinzipien kennen, als Erstes eine CI/CD-Pipeline aufbauen. Und das empfehle ich auf jeden Fall zu machen, selbst wenn wir kein Modell haben. Wir können erstmal sogar ohne Modell starten. Wir können uns einfach nur eine simple Heuristik überlegen und erstmal diese ganze Pipeline aufbauen. Wir müssen für unsere drei Komponenten - Daten, Modelle und Code - auch so ein Versionierungssystem haben. Und mittlerweile gibt es auch Systeme wie DVC, Data Version Control, die sowas übernehmen. Wir haben also Git, zum Beispiel, für unseren Code und unsere Konfiguration, und wir haben auch DVC, was für uns die Versionierung für Machine-Learning-Modelle und Daten übernimmt. Die arbeiten ganz eng zusammen. Und das lässt sich auch ganz schön in so einer Continuous Integration/Continuous Delivery-Pipeline umsetzen.
Robert Glaser: DVC packen wir mal in die Shownotes.
Larysa Visengeriyeva Auf jeden Fall. Und da haben wir schon sehr gute Erfahrungen in Projekten gemacht, und ich würde sogar sagen von allen MLOps-Systemen ist DVC vielleicht das angenehmste für den Einstieg.
Robert Glaser: Okay. Davon habe ich zum Beispiel noch nie was gehört, das schaue ich mir auch direkt mal an.
Robert Glaser: Genau, und wenn die Pipeline steht, dann ist es einfach, in dem Prozess, bei der Entwicklung von dem Modell auch mit dem Testen anzufangen, weil: Testen ist die Voraussetzung für unseren nahtlosen Übergang in die Production. Und es ist einfach schwierig, Tests im Nachhinein einführen. Das ist der Punkt. Es ist einfacher, Schritt für Schritt, wie man es so kennt, Test-Driven Development, die Tests einfach zu entwickeln. Dann müssen wir natürlich auch die ganze Data Preparation und das Model Engineering, diese beiden wichtigen Pipelines, automatisieren. Diese beiden Routinen müssen irgendwie stabil laufen in dem Operationalisierungs-Betrieb. Und da brauchen wir auch noch eine Komponente, wie Machine Learning Model Registry.
Robert Glaser: Was bedeutet das?
Larysa Visengeriyeva Genauso wie eine Code Registry ist sie ein Repository, wo wir unser Machine-Learning-Modell versioniert ablegen.
Robert Glaser: Ah, okay! Sowas wie NPM oder RubyGems oder JAR-Service [? Das habe ich nicht gefunden, ist das richtig transkribiert?] für Machine-Learning-Modelle.
Larysa Visengeriyeva Zum Beispiel, ja. Aber nur intern. Und meistens ist der Ablauf so, dass wir, wenn wir dann unsere ganzen Pipelines schon komplett entwickelt haben und unser Retraining von den Modellen quasi automatisch stattfindet. Was die höchste Stufe der Automatisierung von Machine Learning ist [lacht].
Robert Glaser: Die will man erreichen, oder? [lacht]
Larysa Visengeriyeva Ja, genau. Die Stufe null ist, dass wir alles manuell [machen]. Also, wir haben eine Reihe von Skripten und hangeln uns da durch. Und dann copy-paste oder manueller Upload in das Production System. Genau, und man will natürlich den ganzen Prozess automatisieren. Und wenn der Retraining-Prozess im Betrieb läuft und wir Data Preparation und Model-Training-Pipelines hinter uns haben, ist das Artefakt, was herauskommt, das Machine-Learning-Modell in einem bestimmten Format. Wir haben in Scikit-learn also ein Pickle-Objekt, TensorFlow und alle anderen Anbieter haben eigene Formate. Es gibt einen Zoo von Formaten. Egal in welchem Format, dieses Modell packen wir in diese Registry. Und dann ist es natürlich auch mit Versionierungsnummer verpackt. Dieses Modell wird dann aus dieser Registry genommen und in einen Container verpackt, was den ganzen entsprechenden Machine-Learning-Stack schon drin hat und das letzte neutrainierte Modell geht dann in Production, wird zum Beispiel auf Kubernetes deployt. Und was man hier natürlich beachten muss, was auch oft schiefläuft, ist: Der Tech Stack für das Model-Training und der Tech Stack für wenn das Modell in Betrieb ist, muss natürlich gleich sein. Wenn die nicht gleich sind, kann alles Mögliche schieflaufen.
Robert Glaser: [lacht] Den Technikzoo gibt es also auch bei den Machine-Learning-Menschen, nicht nur bei den Anwendungsentwicklerinnen und -entwicklern.
Larysa Visengeriyeva Genau! Das muss einem ganz klar sein, dass solche Sachen wie Feature Store für das Feature Engineering gleich sein müssen auf beiden Seiten, Learning und Prediction. Der Tech Stack muss gleich sein für Learning und Prediction. Das sind so Sachen… Man muss erstmal auf die Nase fallen [lacht], bis man das gelernt hat.
Robert Glaser: Aber jetzt sind wir schon verschiedene Phasen von diesem ganzen Thema Operations für Machine Learning durchgegangen. Wir haben am Anfang kurz zur Exploration gesprochen. Vielleicht können wir das gleich noch mal kurz vertiefen. Dann haben wir das Data Design tangiert, dann das Deployment. Aber zu Operations gehört ja hintendran, wenn ich jetzt alles berücksichtigt habe, und ich habe eine hohe Automatisierung, eigentlich auch der daily Betrieb dazu. Das Modell läuft in Produktion. Meine Anwendung auch. Was muss ich da beachten? Da fallen wahrscheinlich auch Themen wie Logging Metrics und sowas an, Metrics wahrscheinlich auch in Hinblick auf: Tut das Modell noch das, was es soll, oder entwickelt es vielleicht ein Bias oder sowas, was gibt es da zu beachten?
Larysa Visengeriyeva Genau, das ist auch ein ganz wichtiger Aspekt, und wie ich schon gesagt habe: Wenn das Modell deployt ist, fängt die Arbeit erst an. Es ist wie so ein kleines Baby. Wenn das Baby da ist, muss es immer beobachtet werden und immer geguckt werden, ob das Baby in die richtige Richtung läuft oder nicht.
Robert Glaser: Richtige Erziehung, ja. [lacht]
Larysa Visengeriyeva Genau. Und wir müssen uns um dieses Baby kümmern. Und wir machen das, indem wir Machine-Learning-Modelle monitoren. Da muss man natürlich sehr stark darauf achten, eben wegen diesem berühmt-berüchtigten Problem mit Model Decay, dem Veralten von Modellen. Und da nimmt man den Standard-Stack für Monitoring. Elastic Search, Kibana.
Robert Glaser: Also nicht anders als bei einer normalen Business-Anwendung.
Larysa Visengeriyeva Es ist nicht anders, aber die Metriken müssen natürlich entsprechend sein. Und eine ganz, ich würde sagen, traditionelle Variante ist, zu gucken, wie die Verteilung von Predictions, die das neue Modell gemacht hat, sich unterscheidet von der Verteilung von den Trainingsdaten. Und wenn sie auseinander driften, wenn die irgendwie nicht gleich aussehen, dann ist das natürlich ein klares Zeichen, dass das Modell sich anders verhält.
Robert Glaser: Ah, okay. Das heißt, um das nochmal mit einem Beispiel zu illustrieren: WIr haben ja gerade darüber gesprochen. Wir haben zehn Jahre Tankquittungen in diesem Belegmodell. Und jetzt auf einmal haben alle Mitarbeitenden der Firma nur noch Elektrofahrzeuge und es landen nur noch Stromrechnungen drin mit Kilowattstunden statt Liter. Und dann driften diese beiden Werte auseinander. Und das kann ich in meinem Logging oder Monitoring, in den Metrics, die ich halt sinnvoll erhebe, dann auch wirklich feststellen?
Larysa Visengeriyeva Genau. Wir müssen hier natürlich auch das Thema berücksichtigen: Es kann sein, dass, wenn wir die neuen Daten kriegen, wir nicht sofort die Labels dazu haben. Da müssen wir natürlich diesen Schritt, dass wir die neuen Daten entsprechend labeln, auch berücksichtigen. Das muss gemacht werden, damit wir auch tatsächlich dann sehen. Und meistens sind das Menschen. Das heißt also, der Mensch ist doch involviert.
Robert Glaser: Ach, braucht man uns doch noch! [lacht]
Larysa Visengeriyeva Genau. Wir können vieles automatisieren, aber darauf muss man schon gucken. Und dann wird man sehen. Aber dieses Labeling-Problem. Egal, in welcher Phase, es ist eine Frage: Wie labeln wir Daten, wer labelt das? Nutzen wir Mechanical Turk dafür, nutzen wir eigene Kräfte, die wir normalerweise nicht haben? Das ist eine sehr unbeliebte Aufgabe. Es gibt Frameworks, es gibt Systeme, es gibt Crowdsourcing-Plattformen dafür. Das muss aber organisiert werden. Und das muss einem bewusst sein, dass, wenn das Modell nach so langem Schwitzen im Betrieb läuft, die Arbeit nicht vorbei ist.
Robert Glaser: Dann fängt die Arbeit erst richtig an.
Larysa Visengeriyeva Genau. Da muss man weiter Metriken [verwenden], muss man loggen. Es gibt sehr viele Aspekte von der ganzen Geschichte. Wenn ich jetzt das Thema regulatives Machine Learning, die ganzen Regulations anfasse, dann muss natürlich alles Mögliche protokolliert werden, zum Beispiel.
Robert Glaser: Also, wenn eine Versicherung in Zukunft zum Beispiel über neue Verträge automatisiert mit Machine Learning entscheidet, oder eine Bank über Kreditvergabe, dann gibt es wahrscheinlich - oder sollte es - Regulierungen der Staaten geben, die sagen: Ey, ihr müsst loggen, wie ihr zu dieser automatisierten Entscheidung gekommen seid, damit niemand diskriminiert wird, oder?
Larysa Visengeriyeva Das ist auf jeden Fall so, und solche solche Bereiche wie Finanz, Versicherung sind sowieso stark regulative Bereiche. Und mit Machine Learning werden sie natürlich auch doppelt reguliert. Das Ganze muss natürlich auch entsprechend gelöst werden, indem Metadaten aufgehoben werden, Versionierung, alle Modelle. Die Modelle müssen auch interpretierbar sein und so weiter und so fort. Neben den Machine Learning Operations, den MLOps, ist Model Governance ein riesiges Thema, und da kann man sich auch mit diesem Problem beschäftigen. [lacht]
Robert Glaser: Können wir noch einmal eine extra Folge zu machen. Also, das Thema erscheint mir unglaublich tief. Aber nochmal zurück. Jetzt haben wir über das Thema Betrieb, also Logging, Monitoring, Metrics des Modells in Production gesprochen. Was gibt’s noch für Facetten bei Machine Learning Operations? Oder waren das schon die vier tragenden Säulen?
Larysa Visengeriyeva Im Grunde genommen, ja. Vielleicht sprengen wir den Rahmen des Podcasts, wenn wir jetzt das Thema Design, also, wie kommen wir überhaupt zu Machine Learning Use Cases…
Robert Glaser: …also dieses Thema “explorative Phase” ganz am Anfang?
Larysa Visengeriyeva Die explorative Phase würde ich als zweite Phase nehmen, da, wo wir unseren Data Scientist haben, der Jupyter Notebook anschmeißt und versucht, mit den Daten, die wir haben und mit den Business Values, die wir in der ersten Phase definiert haben, entsprechende Modelle zu bauen und zu gucken, welches Modell dann für unseren Use Case am besten geeignet ist.
Robert Glaser: Das heißt, es gibt noch eine ganz frühe Phase, ähnlich wie in der Produktentwicklung. Bevor ich Tatsachen schaffe, mache ich mir erst einmal Gedanken: Was sind denn überhaupt unsere Business-Ziele? Und wie kann ein Machine-Learning-Modell oder eine -Lösung dabei helfen, die zu erreichen?
Larysa Visengeriyeva Absolut, ja. Und das ist auch mein Weg gewesen, als ich mich mit MLOps beschäftigt habe. Da habe ich mich die ganze Zeit gefragt: Okay, wir haben verschiedene architektonische Entscheidungen und verschiedene Sachen mit Machine Learning. Es gibt verschiedene Model Serving Patterns, die wir anwenden können. Aber wie komme ich überhaupt zu der Entscheidung? Wie entscheide ich? Bis wir dann festgestellt haben: Diese ganzen Entscheidungen müssen in der Requirements-Engineering-Phase stattfinden. Und das ist so eine Phase des quasi Wie-führen-wir-Machine-Learning/AI-in-unserem-Unternehmen-ein. Das ist jetzt diese Phase, wo wir Use Cases finden müssen, da, wo wir eine ganz klare Frage klären müssen: Was ist mit unseren Daten? Und das ist die Reihenfolge: Erst mal das Problem identifizieren und dann gucken, was wir mit den Daten machen. Oder: Haben wir die Daten dazu? Weil: Machine Learning ist ein Hype heutzutage. Und dieser Hype führt zu “Lass uns irgendetwas Cooles mit Machine Learning machen.”
Robert Glaser: [lacht] Ja. Und Blockchain.
Larysa Visengeriyeva Oder Blockchain [lacht]. Ja.
Robert Glaser: Beides am besten.
Larysa Visengeriyeva Und das führt dazu, dass wir sicherlich zu irgendeinem Modell kommen, das sicherlich irgendetwas Cooles macht. Aber brauchen wir das tatsächlich? Löst das unser Problem? Und das ist ganz klar. Und wenn ich mit den Leuten in den Projekten rede, steige ich in kein Projekt ein, wo mir gesagt wird: Wir haben hier ganz viele Daten. Wir müssen jetzt mit Machine Learning irgendetwas machen. So gehe ich nicht [vor]. Ich sage: Andersrum. Also erstmal werden wir die ganzen Abläufe, die ganzen Workflows, verstehen. Und dann gucken wir, was wir machen können. Können wir irgendetwas optimieren? Können wir irgendwie etwas performanter machen? Können wir unsere Abläufe automatisieren? Oder können wir unseren Usern irgendwas etwas Interaktives einbauen, was uns als Unternehmen weiterbringt, was uns Wert liefert.
Robert Glaser: Oder vor allem die Nutzerinnen und Nutzer, die das am Ende benutzen.
Larysa Visengeriyeva Genau.
Robert Glaser: Was schlägst du denn vor? Wie komme ich denn da hin, ganz am Anfang? Gibt es da so etwas wie Design Sprints oder Event Storming? Was benutzt man dafür?
Larysa Visengeriyeva Wir haben in unserem Team einen DDD Advisor, unseren lieben Michael Plöd. Und da haben wir eine ganz coole Methode ausgearbeitet - und wir haben die auch ausprobiert - die wunderbar funktioniert hat. Wir haben nämlich diese DDD-Methodik, wie Event Storming, genutzt, zusammen mit Machine Learning Design Canvas. Und wir haben die zusammengeführt und daraus eine Methode gebaut: Wie kommen wir zu Machine Learning Use Cases? In einem Unternehmen, in einem Produkt und so weiter und so fort. Event Storming, damit wir überhaupt die ganze Anatomie des Workflows verstehen. Wir kriegen sozusagen mit Event Storming Tasks auch einen ganz tiefen Einblick, wo wir Machine Learning einsetzen können. Und dann werden diese Probleme identifiziert. Daraus werden Opportunities gebaut, und die Opportunities, also unsere Machine Learning Use Cases, werden dann priorisiert. Und dann, für die Prio. 1, bohren wir noch tiefer und versuchen, daraus ein Machine Learning Projekt mit Machine Learning Design Canvas zu strukturieren.
Robert Glaser: Das ML Design Canvas, das heißt so, oder?
Larysa Visengeriyeva Die Methodik haben wir entwickelt, aber Machine Learning Design Canvas kommt nicht von uns. Aber wir haben auf ml-ops.org, auf unserer MLOps Microsite, diesen ganzen Prozess mit Machine Learning Design Canvas auch beschrieben.
Robert Glaser: Ah, okay. Du hattest mir die Seite ja auch schon mal gezeigt. Das heißt, da kann ich mir im Prinzip diese ganzen Schritte nochmal durchlesen, worüber wir jetzt gesprochen haben, vom Design bis zur Exploration bis zum Data Design bis zum Deployment über Betrieb, Metrics, logging, monitoring, was auch immer?
Larysa Visengeriyeva Absolut. Diese Microsite ist entstanden, weil ich mir vor fünf Jahren so eine Ressource gewünscht habe. Und das ist quasi unsere Mission jetzt, dass wir unsere Erfahrung, unser Know-How, in die Welt bringen und zeigen, wie komplex das tatsächlich sein kann, was man alles beachten muss. Und wenn man das weiß, dann muss man es nur umsetzen.
Robert Glaser: Ist doch super. Und das ist auch Open Source, oder? Ihr habt ja, glaube ich, auch ein GitHub-Repository, wo man Contributions einstellen könnte, wenn man Ergänzungen hat für die Seite, oder?
Larysa Visengeriyeva Die Webseite ist neu, da kommt noch ganz viel mehr Content rein. Und ich würde sagen, erst einmal ist es jetzt ein Read-Only, und wir haben da aber auch unsere Referenz-Page. Da, wo man ganz viele Referenzen zu dem Thema MLOps hat. Ich würde vorschlagen, dass wir das erstmal als Read-Only…
Robert Glaser: …alles noch im Aufbau.
Larysa Visengeriyeva Es ist noch im Aufbau, ja. Aber wir können natürlich das…
Robert Glaser: ….wir müssen es auf jeden Fall in die Shownotes packen. Nicht vergessen! [lacht]
Larysa Visengeriyeva Machen wir.
Robert Glaser: ml-ops.org. Und davor hattest du noch die Methodiken erwähnt. Machine Learning Canvas, Machine Learning Design Canvas. Packen wir alles in die Shownotes.
Larysa Visengeriyeva Auf jeden Fall.
Robert Glaser: Und wenn ich jetzt nochmal auf die Uhr gucke, Larysa, wir haben schon lange die Zeit gesprengt, die so eine typische Podcastfolge dauert. Aber das zeigt auch so ein bisschen, wie vielschichtig dieses ganze Thema ist, vom Design über Betrieb und all die Facetten. Wir sollten vielleicht nochmal mindestens eine weitere Folge dazu aufnehmen, oder?
Larysa Visengeriyeva Lass uns das machen! [lacht]
Robert Glaser: Okay, cool. Dann lass uns doch hier einen Schnitt machen und wir versprechen hoch und heilig, wir spendieren noch weitere Folgen dazu. Aber unsere Hörerinnen und Hörer: Lasst uns doch einfach Feedback da, wenn ihr die Folge hier gehört oder gesehen habt. Die gibt’s ja auch zu sehen jetzt. In den Kommentaren, schreibt uns eine E-Mail an [email protected], wie ihr das fandet. Und wenn ihr euch dafür interessiert, dass wir noch ein paar mehr Folgen zu diesem ultra-tiefgründigen Thema aufnehmen sollten - wir hätten zumindest noch was, worüber wir sprechen können - dann lasst uns das doch bitte wissen. Ansonsten hoffen wir, euch hat unser kleines Kaffeepausengespräch hier gefallen. Danke dir, Larysa. Jetzt bin ich zumindest schlauer. Ich hoffe, die Hörerinnen und Hörer auch. Was dieses ganze Thema Betrieb von Machine Learning angeht, das zeigt so ein bisschen, dass völlig neue Paradigmen mindestens mit der gleichen Sorgfalt angegangen werden müssen, was den Betrieb, das Deployment, das Design vor allem angeht, wie wir das mittlerweile in der Softwareentwicklung schon tun. Also, dann lass uns vertagen, auf jeden Fall.
Larysa Visengeriyeva Auf jeden Fall.
Robert Glaser: Dann machen wir hier einen Cut und freuen uns auf die nächsten Folgen. Danke dir.
Larysa Visengeriyeva Vielen Dank, Robert. Bis dann! Tschüß!
Robert Glaser: Tschüß!