Patrick: 0:00

[Mic bleed][Mic bleed][Mic bleed][Mic bleed][Mic bleed] Stefan vielen Dank, dass ich hier sein darf.

Stefan: 0:35

Dank, dass du hier bist heute. Erzähl uns doch mal kurz, du zu diesem Thema kommst.

Patrick: 0:41

komme ich zu dem thema hat früh angefangen im studium statistik und dann schnell die machine learning in die data science schiene abgerutscht und für mich dann aber auch gemerkt so reines data science reine modellentwicklung dieses experimentelle trend ist nicht meine welt Und da ist auch der Bedarf beim Kunden nicht da. Kunde hat die Herausforderung, diese entwickelten Modelle auf die Straße zu bringen, skalierfähig auf die Straße zu bringen, schnell auf die Straße zu bringen. Und genau da möchte ich ansetzen und da kann ich dann eben unterstützen mit Aufbau der Infrastruktur, mit MLOps-Prozessen, Paradigmen, was es ja auch ist. Und genau darüber wollen wir jetzt heute auch sprechen.

Stefan: 1:23

Ganz genau. Und als kurzer Disclaimer vorweg, wir werden in die Themen... Machine Learning, Data Science und DevOps nicht tiefer einsteigen. Zum Thema Machine Learning und Data Science haben wir eine entsprechende frühere Podcast-Folge, Einführungen in Data Science und Machine Learning. Hört sie euch doch gerne an, wenn ihr hier noch weiteren Wissensbedarf habt. aber damit steigen wir dann auch direkt ein, Machine Learning und DevOps. Kurz, was ist MLOps und wie unterscheidet es sich vom herkömmlichen DevOps?

Patrick: 1:58

Sehr gute Frage. Denn der eine oder andere wird sich jetzt vielleicht denken, so ein KI-System, so ein ML-System ist ja eigentlich auch bloß ein IT-System. Warum reicht mir denn da nicht DevOps eigentlich aus? Und der neue Punkt, der da jetzt dazukommt, ist eben dieser Aspekt KI-Modell, Machine Learning Modell. Und da kommen jetzt ganz neue Aspekte hinzu. Ich möchte dieses Modell... Funktioniert vielleicht irgendwann nicht mehr. Es ist jetzt nicht einfach wie ein IT-System gebaut. Funktioniert heute wie morgen. So ein Machine Learning Modell funktioniert vielleicht morgen ganz anders. Und ich muss meine Daten überwachen und das sind so die beiden Hauptaspekte, die da dazukommen. Daten und Machine Learning. Und dadurch verändert sich die Art und Weise, wie wir diese ganzen Sachen entwickeln. Und darüber müssen wir uns natürlich dann auch Gedanken machen.

Stefan: 2:45

wir aber irgendwas irgendwo hin deployen können mit unserem DevOps bzw. MLOps, Muss das Ganze ja auch erstmal entstanden sein. Also irgendwo muss ein Data Scientist mal gestanden haben und was getan haben. Was tut denn so ein Data Scientist?

Patrick: 3:00

Sehr gut. Also der Data Scientist, Im Vergleich zum anderen Softwareentwickler, der eine klare Anforderung hat, eine Lösung hat und das umsetzt, ist die Arbeit des Data Scientists ganz, ganz oft ganz, ganz experimentell. Ich probiere viele Dinge aus, die einen funktionieren vielleicht besser, die anderen funktionieren vielleicht schlechter. Und damit sowas einfach ist, verlagert sich die Arbeit von so Data Scientists ganz, ganz oft in Jupyter Notebooks. Also Jupyter Notebooks, für alle, die es nicht wissen, so eine kleine IDI, in der ich einzelne Zellen habe und in der ich einzelne Codeschnipsel einzeln ausführen kann und auch direkt ein Ergebnis darunter sehe.

Stefan: 3:38

Und das funktioniert dann mit Python, wenn ich das richtig im Kopf habe.

Patrick: 3:41

Beispiel, genau, gibt es verschiedene Möglichkeiten, aber so Python ist so die typische Sprache im Data Science Umfeld, einfach weil es am besten gewartet ist und die meisten Möglichkeiten da auf dem Markt mittlerweile gibt. Genau, wie schon gesagt, hat viele Vorteile, ich kann einzelne Schnipsel Code ausprobieren und Kann dann auf diesen Schnipseln, auf den Daten, die ich daraus bekomme, aufbauen, neue Dinge ausprobieren und muss nicht immer von ganz vorne anfangen. Deswegen hat sich die Arbeit in Notebooks verlagert. Hat aber auch die Herausforderung, so ein Notebook ist... Für Experimente gedacht, für den experimentellen Aufbau gedacht und nicht dafür gedacht, in Produktion zu laufen. In Produktion möchte ich ein Skript haben, einen Java, einen Python-File im Data-Science-Umgebung, das ich von mir aus auch in meinem Docker-Container auf Kubernetes deployen kann. Und das funktioniert mit so einem Notebook einfach nicht. Und dafür brauche ich eben oder Prozesse, um diesen Code, den ich dem Pre-Processing zum Beispiel in so einem Notebook erstelle, In so einen Skript zu überführen und da ganz ganz oft gibt es dort Probleme mit Copy-Paste, dass irgendwas schief geht oder irgendwelche Annahmen fehlen sehr sehr fehleranfällig das Ganze hier kann eben MLOps unterstützen indem es beispielsweise automatisiert so ein Notebook ich habe das jetzt als Data Scientist geschrieben kann das dann testen, ich kann auch so Notebooks testen, läuft es Durch, kann da Unit-Tests von mir aus auch dazu schreiben und wenn das Ganze dann funktioniert, so ein Notebook automatisch in Source-Code zu überführen, den ich dann auch deployen kann.

Stefan: 5:29

Deploy-Prozess aus diesem Jupyter-Notebook alles rausziehen, was notwendig ist, um dafür ein Artefakt, was dann auch in einer Art Container deployed werden

Patrick: 5:39

Genau, zum einen das KI-Modell selber, das ich dann irgendwo in einem Storage, in einem Plop-Storage irgendwo ablegen kann, darauf zuzugreifen, aber eben auch die ganzen Pre-Processing-Schritte Und vielleicht auch noch ein bisschen Business-Logik, die ich da drauf setzen muss.

Stefan: 5:53

Spannend. Und dann haben wir unser Artefakt, was dann da irgendwo ist. Und dann sind wir fertig. Oder fehlt uns da noch mehr?

Patrick: 6:01

Natürlich nicht. Wie ich ja schon gesagt habe, dieses Machine Learning Modell ist der eine Part Aber ich brauche natürlich so ein ganzes system darum rum und da ist so ein bisschen jetzt die der tricky part in der ganzen ki anwendung ki funktioniert mit produktionsdaten ich brauche produktive daten die ich lesen kann ich nutzen kann auf denen ich so ein modell trainieren kann ich möchte auch die welt lernen und nicht auf eine testwelt erarbeiten andererseits aber auch ich möchte meinen it system entwickeln rund um dieses modell entwickeln Und da sagt man jetzt aber auch wieder andererweise, ich brauche dafür eine Entwicklungsumgebung, auf der ich keine Produktionsdaten haben darf. da ist eben die Herausforderung, wie bekomme ich denn jetzt eigentlich diese Sachen raus? Zusammen. Das sind ja erstmal zwei verschiedene Umgebungen.

Stefan: 7:08

Wo dann eben auch andere Entwickler die Dinge außenrum entwickeln und da haben wir eben ein Problem. Also ich würde auch rechtlich schon ein Problem damit sehen, dass Data Scientists vorher schon auf Produktionsdaten für die Entwicklung zugreifen können. Aber wenn das mal geklärt ist, haben wir eben dort die Diskrepanz. Und inwieweit kriegt man das jetzt unter einen Hut?

Patrick: 7:34

Ähnlich wie ich gerade eben schon gemeinte, also zum einen dieser Aspekt, Ja, ich kann jetzt so mein Notebook automatisiert in Source-Code überführen, kann das irgendwie in einem GitHub, in einem Bitbucket-Repository ablegen, dann habe ich meinen Code. Das ist klassische DevOps-Technik, die kennen wir. Herausforderung ist jetzt dieses Modell. Und dort gibt es jetzt ähnlich zu einem... Code-Repository führt jetzt MLOps ein Modell-Repository ein, wo ich meine Modelle ablegen kann, wo ich meine Modelle auch versionieren kann und Parameter dazu ablegen kann, wie gut funktioniert denn mein Modell, auf welchen Daten habe ich dieses Modell trainiert, auf welchen Daten habe ich dieses Modell evaluiert. Um Auch auf der Modellebene diese Nachvollziehbarkeit haben zu können. dann kann ich, ähnlich wie aus so einem Bitbucket-Repository oder einem Bitbucket-Repository, GitHub-Repository, ganz, ganz oft wird der Code in Docker-Images verpackt und dann irgendwie in einer Artifact-Registry, in einer Docker-Registry abgelegt. Und ähnlich funktioniert dann auch das mit den Modellen. Ich lege die in so eine Registry ab und aus dieser Registry kann ich dann auch auf andere Umgebungen zugreifen. Und mir diese Sachen dann eben ziehen und in Produktion bringen.

Stefan: 8:47

Kann es dort dann aber nicht Probleme geben, wenn man diese auf Produktionsdaten trainierten Modelle in den Testumgebungen benutzt, weil dort sind ja auch Daten vorhanden, die nicht zwangsläufig so produktionsnah sind, wie man das gerne hätte in einer idealen Welt und dass dann ein Modell, was In Produktion richtig gut funktionieren kann, in einem Testsystem gar nicht so gut funktioniert? Oder werden dann auf den Testumgebungen die Modelle auf den Testdaten trainiert?

Patrick: 9:16

Genau, da müssen wir jetzt ein bisschen unterscheiden. würde es einerseits ein bisschen in Integrationstests unterscheiden, wo wir einfach nur schauen, funktioniert denn mein Modell im Zusammenspiel mit diesen ganzen Komponenten, die ich da noch drum herum baue, Tabelle, Pre-Processing etc., Data Pipelines etc. Und den zweiten Teil, das ist dann der viel, viel spannendere Teil, das sind dann die Regressionstests. Und da geht genau das darauf ein, worüber du gerade gesprochen hast. möchte schauen, funktioniert denn mein Modell auch in diesem ganzen System so, wie ich es entwickelt habe? Und hier uns jetzt auch wieder der Regulator, in dem berechtigten Interesse dürfen wir das machen, wenn wir sagen, Auf dieser Testumgebung herrschen die gleichen Sicherheitsvorkehrungen wie auf unserer Produktivumgebung.

Stefan: 10:06

Okay, das heißt, dann haben wir aber auch sehr viel höhere Anforderungen an Testumgebung, als wir vorher

Patrick: 10:11

Genau, in dem Fall ist dann auch wieder die Frage, wie treibe ich denn das Ganze? Und da würde ich ganz klar sagen, Einmal eine Testumgebung, wo ich Integrationstests einfach bloß in Funktionstests mache und dann eben nochmal eine zweite Umgebung, wo ich rein solche Regressionstests mache, um genau das zu überprüfen und da quasi eine Kopie der Produktion habe.

Stefan: 10:33

Spannend. Also auch noch mehr Arbeit für DevOps. Solche Infrastrukturen dann entsprechend auch zur Verfügung zu stellen und möglichst einfach hochzuziehen, wenn sie denn notwendig

Patrick: 10:46

Genau,

Stefan: 10:47

Gut, hattest eben auch schon mal von dem Regulator geredet. Inwieweit hängt der Regulator denn damit drin?

Patrick: 10:55

Regulator ist jetzt im KI stark am Kommen. Der Regulator hat ein starkes Potenzial entdeckt, dass wir da was regulieren müssen ich vergleiche das immer so ein bisschen mit, Mit dem Flugzeugbau. Vor 60 Jahren, als die Flugzeuge entwickelt wurden, keiner hat sich getraut, in so ein Flugzeug reinzusetzen. Erst als wir angefangen haben, Sicherheitsvorkehrungen einzubauen, hat sich das Vertrauen in der Bevölkerung entwickelt und man hat gesagt, okay, das Ganze ist gut reguliert, das sind Sicherheitsvorkehrungen, Das wird überprüft regelmäßig gewartet jetzt traue ich mich in dieses flugzeug zu setzen ganz ähnlich ist es jetzt aktuell auch mit der regulatorie für ki und da hat jetzt die europäische union den eu verabschiedet der hat es dann auch in den nächsten tagen veröffentlicht wird und mit genau diesem ziel sie möchten vertrauen in die ki schaffen und dadurch eben KI fördern, dass es mehr genutzt wird, weil wahnsinnig viel Potenzial in dem ganzen Thema steckt. Und habe ich natürlich schon gesprochen von Maßnahmen, wie das Ganze kontrolliert wird. da ist dann eben ein Aspekt, wir brauchen ein Risikomanagement, wir müssen nachvollziehen können, auch Nachvollziehbarkeit ist ein großer Punkt, wie gut funktioniert denn eigentlich mein Modell. Ich muss genau das nachweisen können, mit welchen Daten wurde mein Modell trainiert, was waren denn die Evaluationsergebnisse, diese Dinge. Und genau da kann jetzt MLOps eben unterstützen, indem es so ein Modell, wenn ich das versioniere in so einem Model Registry, wie ich gerade erwähnt habe, Direkt anfügt, ich habe diese Daten verwendet, diesen Validierungssatz, das waren meine Evaluationsergebnisse. Das kann ich vollautomatisch machen, ich dem Regulator dadurch eigentlich nur durch einen Knopfdruck an dieser Stelle genüge.

Stefan: 12:48

heißt, der Regulator ist an der Stelle im Endeffekt die Kontrollinstanz, die sagt, hier, wenn KI benutzt wird, wenn Modelle trainiert werden, dann muss in irgendeiner Form nachvollziehbar sein, wie ist das Ganze passiert. Damit werden kann, im Notfall ist Schindluder damit getrieben worden oder nicht.

Patrick: 13:07

Im Grunde genommen ja. Wir müssen nur so ein bisschen unterscheiden, je nach Anwendungsfall, aber das geht jetzt für diese Folge zu tief.

Stefan: 13:14

da bin ich ganz bei dir. das heißt, hat unseren ganzen Prozess, für den ganz normalen DevOps-Prozess ein paar Vorteile, wenn man mit KI-Modellen arbeitet, kann also den ganzen Entwicklungsprozess unterstützen, dass Data Scientists weiter auf ihren Jupyter-Notebooks arbeiten können und dort automatisiert die Code extrahiert und deploybar gemacht werden kann. MLOps kann zusätzlich unterstützen, solche Probleme oder Herausforderungen bei Testumgebungen und verschiedenen Daten auf verschiedenen Umgebungen, die Problematik besser gestalten zu können, damit auch alle weiterhin fröhlich vor sich hin entwickeln können und gute Ergebnisse produzieren können. Und dann in letzter Instanz kann es auch noch helfen, die Nachweisbarkeit für die Regulatorik. Sicherzustellen. wir noch mehr Punkte beim MLOps, die wir bis jetzt vergessen haben?

Patrick: 14:18

Durchaus. Direkt der erste. Wenn wir an DevOps denken, denken wir an eine CICD-Pipeline. Eines der ersten Dinge. Und auch hier hat MLOps erweitert diesen Aspekt der CI-CD-Pipeline durch eine CT-Pipeline, Continuous Training. ich schon meinte, so ein KI-Modell funktioniert morgen vielleicht schon wieder ganz anders als heute. Woran liegt das denn eigentlich? So ein Modell ist auf der Vergangenheit trainiert. Ich habe ja nur Daten aus der Vergangenheit, die ich zum Training verwenden kann. Ich möchte jetzt heute irgendwie die Gegenwart damit abbilden und möchte damit eigentlich die Zukunft vorhersagen. Und ein ganz schönes Beispiel dafür ist Schuhverkäufe. möchte jetzt Sommerschuhe verkaufen. Sommer naht, Sommerschuhe verkaufen. Jetzt habe ich ein KI-Modell dafür trainiert. Funktioniert wunderbar zur Vorhersage von Sommerschuhen. Richtung August, September neigt sich der Sommer dann aber auch so langsam dem Ende und ich möchte vielleicht Herbst- oder Winterschuhe verkaufen. funktioniert mein Modell aber gar nicht auf Herbst- oder Winterschuhen. Das sagt mir immer noch, kauf Sommerschuhe, weil ich kenne nur Sommerschuhe. Und genau diesen Prozess, dass so ein Modell derzeit abbauen kann, weil sich die Daten dahinter verändern, Den müssen wir zum einen überwachen, können wir gleich noch mal kurz drüber sprechen, und dann müssen wir dem Ganzen aber auch gegenwirken. Und da muss ich mein Modell neu trainieren.

Stefan: 15:39

Und das klingt für mich so, als wäre dann erstmal wieder Entwicklungsaufwand notwendig. Das heißt, ich muss jedes halbe Jahr mein Modell neu entwickeln, West Case, oder habe ich da eine falsche Vorstellung?

Patrick: 15:49

Im Best Case, ja. Im einfachsten Fall, im schönsten Fall. Habe ich da gar keinen Aufwand, ich kann in der Produktion überwachen, mein Modell baut ab, meine Ergebnisse werden schlechter, jetzt kann ich automatisierend, Ein Neutraining von so einem Modell starten. Ich kenne ja die Rahmenparameter von so einem Modell, ich füge dem Ganzen jetzt nur neue Daten ein, trainiere das neu und wenn ich jetzt eine gute DevOps-Pipeline auch habe, mit einer CI-CD-Pipeline, kriege ich dieses Modell bis nahezu Produktion automatisch getestet und deployed. Sodass ich dann diese ganzen Herausforderungen, die ich davor hatte, mit dem manuellen Copy-Pasten aus so einer Data-Science-Umgebung, in der Dev-Umgebung, auf die Test-Umgebung, diesen manuellen Aufwand gar nicht mehr habe, sondern komplett automatisiert habe. Und wenn ich das Ganze auf die Spitze treiben möchte, kann ich so ein Retraining auch in ein Live-Retraining übergehen. Wird gelegentlich auch dort Anwendung, wo wir Aktienkurse vorhersagen. Da bringt es mir jetzt nichts, wenn ich den Aktienkurs von gestern nur nutze, Oder den von einer stunde von vor zwei stunden wenn der aktienkurs jetzt abstürzt dann gehe ich da eine live training über jedes mal wenn ein neuer datenpunkt reinkommt trainiere ich dieses modell neu und Und deploy es auch direkt.

Stefan: 17:12

heißt, wir haben auch wirklich quasi sekündlich im besten Fall neue Modelle, die dann immer wieder neu ausgerollt werden, dort auf dem aktuellsten Stand zu sein.

Patrick: 17:22

Zum Beispiel, genau, hängt immer vom Anwendungsfall ab, ob man es denn benötigt, aber ich kann so auf die Spitze treiben, ja.

Stefan: 17:28

Und du hattest eben noch was mit einer Überprüfung erwähnt.

Patrick: 17:32

Genau, den Aspekt Monitoring. Wie ich jetzt schon meinte, so ein Modell baut ab mit der Zeit. Die Daten verändern sich, Data Drift genannt, und das muss ich überwachen. Ähnlich zu DevOps es Überwachungsmechanismen in Richtung Auslastung, CPU, Memory, funktioniert mein System, muss ich da was ändern. Und ganz ähnlich dazu gibt es im Machine Learning Umfeld eben wieder Software. Die ich an meinen Daten überwache. meine Daten noch die gleiche Verteilung wie bei der Annahme beim Training haben sie es nicht mehr? Und dort steckt jetzt dann auch die Arbeit eines guten Data Scientists. muss einschätzen können, ab welcher Abweichung mein Modell denn jetzt neu trainieren muss. Und deshalb sind die Data Scientists auch so gut bezahlt auf dem Markt, weil Sind wir ehrlich, jeder kann mit einem YouTube-Video eine kleine Regression zusammenklicken, das ist nicht die Herausforderung. die Herausforderung besteht darin zu entscheiden, wann ist denn jetzt mein Modell gut? Und wann ist es nicht mehr gut? Und genau da kann MLOps unterstützen, diese Dinge zu überwachen. Und dann, wenn es nicht mehr gut ist, direkt automatisiert neu zu trainieren. Und ich habe überhaupt keinen Aufwand mehr damit.

Stefan: 18:47

klingt extrem praktisch. Das heißt, man würde ein einziges Mal entwickeln, hätte solche entsprechenden Monitoring-Instanzen in irgendeiner Form, immer wenn es unter einem bestimmten Schwellwert geht, lasse ich die Pipeline einmal laufen, habe dann hoffentlich wieder ein gutes Modell. Und alles ist schön und müsste erst wenn das nicht mehr hilft wieder in eine neue entwicklung gehen

Patrick: 19:09

Genau. Das klingt auch im ersten Moment super einfach, aber da steckt jahrelange Hinarbeit hin, denn so MLOps setze ich nicht von heute auf morgen um. ich jetzt heute zu dem Kunden gehe, der noch nie was von MLOps gehört hat und ihm sage, hier, bau dir jetzt die krassesten Pipelines, die tollsten Pipelines, dass dir dein Modell automatisch neu trainiert und in Produktion bringt, der wird überhaupt nicht wissen, wovon ich rede. Im aller allerbesten Fall er ein funktionierendes DevOps, was wir jetzt auch schon ganz, ganz oft voraussetzen. Und dann fangen wir schrittweise an. Lasst uns anfangen mit Modellversionierung. Lasst uns weitermachen mit von so einem Modell. Dieser Trainingslauf, diese Daten habe ich verwendet. Das waren die Testergebnisse. Lasst uns mit kleinen Schritten anfangen, denn auch meine Organisation muss mitwachsen mit diesen ganzen Strukturen. Denn ich muss mir im MLOps auch ganz, ganz oft dann die Frage stellen, betreibe ich denn das eigentlich, wo wir wieder beim eigentlichen Operations auch wären. Denn ich kann natürlich sagen, wer entwickelt, betreibt. Ich habe alles zentral in einer zentralen KI-Entwicklung. Ich kann aber auch einen ganz anderen Ansatz fahren und sagen, die Fachabteilungen entwickeln und wir stellen dann das Modell zentral in einer IT zur Verfügung. Und dann kommen wieder diese Fragen mit Monitoring, wer überwacht denn dieses Modell, wer ist dafür verantwortlich, an wen muss ich mich melden, wenn dieses Modell nachlässt, wenn es nicht mehr so gut ist, wer ist dafür verantwortlich für so ein Neutraining und auch das ist MLOps, diese organisatorischen, firmestrukturellen Dinge mit anzugehen und nicht nur diese technischen Aspekte.

Stefan: 21:11

Das klingt erstmal auch nach einem ganz schön großen Investment, um sowas einzuführen. Zum einen auf der organisatorischen Seite für die Umstrukturierung. Zum anderen, wie sieht das Ganze mit den Ressourcen aus, weil ich kann mir vorstellen, wenn kontinuierlich solche Modelle neu trainiert werden und mit jedem Durchlauf von einer entsprechenden Pipeline Ist dort bestimmt auch sehr viel mehr Hardware-Leistung notwendig.

Patrick: 21:36

Ja, zum einen Punkt, brauche ganz ganz neue Skills. Ich brauche, wir hatten es schon angesprochen, den Data Scientist. Ich brauche aber auch einen Neue Art von Engineer. Ich brauche jetzt plötzlich einen Machine-Learning-Engineer, der zum einen die Software kann, die Hardware-Komponente, was brauche ich denn an Infrastruktur, wie baue ich das Ganze skalierfähig auf. Der braucht aber auf der anderen Seite auch die dieses Machine-Learning-Wissen zu einem gewissen Teil, um zu verstehen, Wie funktioniert denn mein Modell? Was brauche ich denn dann tatsächlich an Infrastruktur? Und was wir dann auch merken, der Trend im Machine Learning Umfeld geht ganz klar Richtung Hyperscaler, Richtung Cloud. Die Hyperscaler sind da wahnsinnig am Investieren. Azure, Microsoft hat OpenAI mit aufgekauft, dahin investieren. Google versucht nachzuziehen, aber auch auf den Plattformen selbst gibt es mittlerweile Ideen, Ganze Software-as-a-Service-Tools, die sich nur um dieses MLOps kümmern, ich dann quasi auf der Plattform end-to-end mein Machine Learning Modell entwickeln kann, diese Trainingsläufe tracken kann und dann eben auch dort Software-as-a-Service bereitstellen kann.

Stefan: 22:58

heißt, wenn ich dann eben die Expertise nicht zwangsläufig zur Verfügung habe, kann ich dort auf die Unterstützung von den Hyperscalern hoffen.

Patrick: 23:07

Genau, wir müssen uns natürlich immer die Frage stellen, brauchen wir denn wirklich alles von diesen Hyperscalern? Passen die in meine Prozesse, in meine Strukturen? Was muss ich anpassen? Muss ich meine Struktur anpassen? Oder muss ich vielleicht das Tool ein bisschen auf meine Bedürfnisse anpassen? Und da ist die große Herausforderung. Da herrscht wahnsinnig viel Spannung in den Projekten. Da ist wahnsinnig viel Unsicherheit auch bei den Kunden zu spüren. Und genau da versuchen wir eben auch mit zu unterstützen. Wie baue ich sowas nachhaltig? Schritt für Schritt auf kein Big Bang, machen das langsam, die ersten Prozesse, implementieren die. Das ist natürlich auch immer ein Riesenaufwand für den Data Scientist, weil sich seine Arbeit von heute auf morgen komplett ändert. Ich muss auf ganz neue Dinge achten.

Stefan: 23:58

das heißt im endeffekt wenn ich damit anfangen möchte dann ist das erste was ich als skill bräuchte ein entsprechender data scientist und anschließend wie ich das ganze dann in meinen aktuellen der fox prozess einbindet das kann dann graduell und schnell Mit durchaus Unterstützung von Hyperscalern, mit Software as a Service, aber dann eben auch langfristig mit eigenen Machine Learning Engineering aufgebaut werden. Aber es ist nicht direkt von Anfang an notwendig. Also ich könnte auch erstmal einfach mit einem Data Scientist ins Rennen gehen. Viel manuell und handarbeit leisten und dann nach und nach nach erfolg des ganzen anfangen den prozess um zu strukturieren

Patrick: 24:39

Genau. Das Einzige, was wichtig ist, früh anfangen, um Altschulden möglichst nicht aufkommen zu lassen. Denn je später ich mit MLOps anfange, Desto mehr Schulden baue ich mir auf und die kriege ich im Nachhinein nur sehr, sehr schwer und langwierig wieder abgebaut.

Stefan: 24:57

Das klingt für mich absolut plausibel. Und es klingt für mich aber auch so, dass MLOps so viel Unterstützung in diesem ganzen Prozess leisten kann, dass sich der Aufwand auch immer schon früh lohnt, damit nicht zu viele Arbeitsbeschaffungsmaßnahmen für die entsprechenden Entwickler und Entwicklerinnen der ganzen Strecke sind. Man

Patrick: 25:18

Definitiv. Man muss sich darauf einlassen, es ist ein Investment, aber dann kann es einem den Prozess sehr, sehr schnell erleichtern und im Vergleich jetzt nochmal Richtung DevOps, was bringt es denn? Amazon hat es durch ein gutes DevOps geschafft, alle elf Minuten produktiv zu releasen. Und gut kann dann natürlich auch MLOps unterstützen. Im Bankenumfeld natürlich klar. Nicht so schnell, nicht so viel, aber es kann uns wahnsinnig die Arbeit beschleunigen.

Stefan: 25:49

Das klingt nach einem sehr großen Vorteil. Gut, haben wir dann auch soweit alle Punkte, die wichtig sind für MLOps. Oder habe ich jetzt noch irgendwas komplett vergessen?

Patrick: 26:00

Nö, schon von meiner Seite.

Stefan: 26:02

Dann haben wir, denke ich, einen sehr guten Überblick über das Ganze bekommen. Danke dir. wäre für mich für den Abschluss noch so ein bisschen wichtig, wenn unsere Hörerinnen und Hörer sich mit dem Thema weiter auseinandersetzen wollen, hättest du vielleicht irgendwelche Literaturhinweise oder auch Webseiten, auf denen man sich da zu dem Thema ein bisschen weiter noch einlesen kann.

Patrick: 26:23

Genau, also Webseiten gibt es zuhauf, wenn man googelt, gibt es auch genügend Tools. MLflow ist ein ganz gutes Tool, Databricks ist ein gutes Tool, VeloHi ist ein ganz gutes Tool und Richtung Literaturhinweise kann ich euch die Bücher von O'Reilly sehr, sehr ans Herz legen. Die sind da sehr, sehr gut. Die Introduction to MLOps und Implementing MLOps into the Enterprise. Eben, dass sich dann auch mit diesen Fragen beschäftigt, welche Strukturen, welche Kommunikationskanäle brauche ich denn dann auch in meiner Firma, in meiner Bank, in meiner Company.

Stefan: 26:59

Danke dir. Danke für den vielen Input. Ich habe heute sehr viel gelernt zum Thema MLOps. Ich hoffe, unsere lieben Zuhörerinnen und Zuhörer ebenso und bedanke mich dafür, dass du heute hier warst und damit wäre es, wenn wir am Ende

Patrick: 27:14

Vielen Dank. Mir hat es wahnsinnig viel Spaß gemacht und gerne mal wieder. Tschüss.