Data Science und Data Engineering: Projektplanung, Test-Strategien und Herausforderungen

00:00:00: So, Hallöchen, David zum, ja, ich will sagen, zweiten Mal heute.

00:00:05: Hey, Janis, heute in Seenproduktion.

00:00:08: Heute, ja, heute machen wir die Fabrik.

00:00:11: Jetzt habe ich meine Eingangsfrage vorhin schon verprüfert.

00:00:14: Also, vielleicht zum Hintergrund, wir haben schon eine Podcastfolge heute aufgenommen.

00:00:18: Die Folge von vorhin, da ging es um die Data Implugged, dort habe ich die Pizza-Frage gestellt.

00:00:22: Meine neue, ich sag mal, Icebreaker-Frage für den Pizza-Mitwoch.

00:00:26: Wie lief dein Schachspiel gerade?

00:00:28: Sehr, sehr gut. Mit einer Zehnte Sekunde auf der Uher-Schachmatte gesetzt.

00:00:33: Top, perfekte Podcastvorbereitung.

00:00:35: Ja, mit Inkrement oder ohne?

00:00:37: Ohne, eins plus null.

00:00:38: Eins plus null, ja, das ist gut.

00:00:40: Siehst du, habe ich doch mit deinem Schach weiß oder schwarz?

00:00:43: Ich war schwarz.

00:00:44: Dutch?

00:00:45: Sicilien.

00:00:46: Ah, okay.

00:00:48: Ja, nicht schlecht, wir haben schon lange nicht mehr gespielt.

00:00:50: Also, ich will sagen, eigentlich müssen wir den Counter wieder resetten.

00:00:53: Null, null, weil neue Saison oder so eigentlich, ne?

00:00:56: Können wir gerne machen, ja.

00:00:57: Sehr gut.

00:00:58: Auf jeden Fall habe ich ja gelernt, dass man mit dir nicht Civilisation spielt.

00:01:01: Doch, also ich bin nur strategisch, ich bin weiter als anderer, weißt du, ich nutze

00:01:07: meine Mittel.

00:01:08: Manch einer in dieser Firma hätte das wahrscheinlich als moralisch flexibel beziffert.

00:01:13: Ich weiß nicht, ich finde es durchaus legitim, sich mit dem Computer zu verbünden auf der

00:01:16: höchsten Schwierigkeit oder fast höchstens Schwierigkeit und dann Krieg mit den anderen

00:01:19: anzufangen.

00:01:20: Ich finde, das ist okay.

00:01:21: Also für die reinen Podcast-Hürer, ah gut, YouTube-Feed gibt es ja nicht.

00:01:25: Anders sieht gerade sehr, sehr stolz aus.

00:01:27: Ja, nee, das war auch ein Stück weit ein Sieg.

00:01:29: Das Gute ist, wir haben die Folge nie zu, die Runde haben wir nie zu Ende gespielt.

00:01:33: Von daher kann ich mir sogar vorstellen, ich stemme einfach vor, ich hatte gewonnen,

00:01:37: weißt du?

00:01:38: Also, ich bin, ich hatte gute Strategie.

00:01:41: Na gut, heutiges Thema, wir vergleichen mal so ein bisschen unsere, ja, ich will sagen

00:01:47: Fachgebiete, unsere Domäne, in denen wir so unterwegs sind.

00:01:50: Ich glaube, das hatten wir schon länger auf dem Plan.

00:01:51: Und jetzt habe ich, hat mich irgendwie die Motivation gepackt, das mal anzustoßen.

00:01:56: Du bist eher so im Data Science, Machine Learning, Analytics-Bereich unterwegs und ich bin eher

00:02:01: so im Data Engineering, Plattforming und der Softwareentwicklung unterwegs.

00:02:05: Und ich dachte mir, eigentlich ist es mal interessant zu vergleichen, wie wir so arbeiten

00:02:11: oder arbeiten möchten vielleicht auch, also wir können auch, können uns mal so ein paar

00:02:15: Sachen wünschen, wie wir uns Sachen vorstellen.

00:02:17: Mal so ein Eingangsfrage, ich glaube, du kannst das ein bisschen schöner erklären, als ich

00:02:21: jetzt immer tue.

00:02:22: Unser allgemeines Projekt vorgehen, vielleicht mal in der Nachtstelle, wir hatten das ja

00:02:26: schon ein paar Mal ein Podcast, wir müssen nicht zu weit ausholen, aber einfach damit

00:02:29: wir einen Startpunkt haben.

00:02:30: Wie gehen wir üblicherweise in Projekte rein?

00:02:33: Ja, genau, ich würde an der Stelle mich mal direkt nicht zu weit aus dem Fenster lehnen

00:02:38: und spreche mal mehr über Data Science Projekte, an der Stelle und ja quasi unser historisch

00:02:46: gewachsendes Vorgehen, mit dem wir viel Erfolg haben, basiert ja auf diesem System aus einem

00:02:52: Initialen Workshop, in dem wir die Grundlagen für ein Leuchtturmprojekt, wie wir das dann

00:02:57: liebevoll nennen, legen.

00:03:00: Die Idee ist da einfach die, dass man so eine Art Salami-Taktik hat, man startet nicht mit

00:03:06: irgendeinem 6, 7 Monate Projekt mit entsprechenden Budget, weil Data Science schwer planbar ist

00:03:13: und man nicht immer Erfolg garantieren kann, bevor man mit den Daten gearbeitet hat und

00:03:18: das heißt wir sagen, wir gehen hin, wir machen einen Workshop, wir finden erstmal raus, was

00:03:23: es entweder bei einem spezifischen Use Case zu wissen gibt und wie der anzugehen ist oder

00:03:28: vielleicht auch explorativ, was könnte überhaupt der sinnvolle Use Case sein und gehen dann

00:03:32: hin und planen so eine initiale Phase von ein bis drei Monaten, in der wir ja eine Machbarkeitsstudie

00:03:40: machen, aber schon mit dem Ziel da einen MVP zu bauen, ja, irgendetwas, was man benutzen

00:03:48: kann und was einen Mehrwert liefert und das aber wirklich sehr streamlined und zeitlich

00:03:54: begrenzt.

00:03:55: Ja, ich glaube, hatten wir schon mal Projekte, wo kein MVP hinten rausgesprungen ist?

00:04:01: Ja, das ist eigentlich ganz cool, dass wir das in der Form noch nicht hatten, wir hatten

00:04:08: aber schon Projekte, wo das, was hinten rausgekommen ist, schon deutliche Unterschiede hatte

00:04:15: zu dem, was man am Anfang gedacht hat, aber so ein bisschen sage ich, mit einem gewissen

00:04:20: Selbstbewusstsein, einer leichten Cockiness, wenn wir drei Monate mit Daten arbeiten, kommt

00:04:26: da schon ein Mehrwert bei raus, ja, das muss man schon sagen, also dann würde man ja auch

00:04:31: die weiße Flagge unterwegs sitzen und würde sagen, hey, also da geht wirklich so gar nichts,

00:04:35: das ist selten der Fall.

00:04:37: Ja, zur Fähne ist, du hast gesagt, du bewegst dich im Data Science Umfeld und das ist so

00:04:42: unser Data Science Vorgehen, um ehrlich zu sein, so arbeiten wir auch in anderen Bereichen,

00:04:46: also genau das Vorgehen, was du gesagt hast, ich glaube, dass das uns als Firma allgemein

00:04:50: auszeichnen ist, eben, ich sag mal, unser Motto machen statt schnacken, dass man so schnell

00:04:56: wie möglich einfach ins Doing kommt und das eben domainübergreifend und genau mit dem

00:05:03: Hintergrund finde ich es eigentlich mal interessant, unsere Arbeitsweisen zu vergleichen, weil

00:05:06: ich glaube, ehrlich gesagt, dass diese Arbeitsweise besonders gut für Data Science funktioniert,

00:05:11: weil man dort oft adaptiv etwas dransteckt, an einem Unternehmen, an einem bestehenden

00:05:17: Infrastruktur oder einfach eine eigene, neue Aufbauen kann, aber man kann häufig was

00:05:22: draußen anhängen, deswegen muss man oft nicht unbedingt sehr tief in technische bestehende

00:05:27: Prozesse eintauchen, die es unter Umständen schon gibt, meistens ist man ja sehr hochlevelig

00:05:32: unterwegs und ich sag mal, im Bereich Plattform Engineering ist man ja doch eher ein bisschen

00:05:39: tiefer in der Firma vergraben und da finde ich es jetzt gleich mal interessant, so ein

00:05:43: bisschen die Denkweisen zu vergleichen, die wir so an den Tag legen.

00:05:47: Von daher, zur Übersicht, ich habe mir so ein paar Punkte ausgegraben, vielleicht finden

00:05:51: wir noch ein paar andere, einfach nur um die mal genannt zu haben, wir haben uns jetzt

00:05:55: im Vorfeld, einseitig will ich behaupten, auf die Punkte in Bezug auf Projektplanung geeinigt,

00:06:01: also wie weitsichtig planen wir Projekte und was wünschen wir uns in der Planung, interessant

00:06:09: ist noch der Punkt Code Qualität, wer achtet von uns wie auf Code Qualität oder wie ist

00:06:16: Code Qualität so bei den Erfahrungen zu sehen, wie leben wir das aus und dann noch ein,

00:06:22: zwei, drei andere Sachen, um da durch, schnell durch zu rennen, Testing kommt kurz dran,

00:06:26: Multi-Environment-Entwicklung und der letztliche Projektwert und ich glaube, gerade das letzte

00:06:30: ist mit Sicherheit einer der interessanteren und kontroverseren Sachen, aber lass uns

00:06:35: gerne mal am Anfang starten, Projektplanung, wie würdest du sagen, was ist so dein Wunsch

00:06:41: für ein Data Science Projekt, du hast jetzt ein Use Case evaluiert im Workshop und ihr

00:06:45: wollt jetzt ein Leuchttor machen, wie tief gehst du die erste Planung an?

00:06:50: Ja, also das ist tatsächlich jetzt ein bisschen redundant zu dem, was wir eben auch schon über

00:06:57: die Masterklasse besprochen haben, weil ich da auch schon erzählt habe, Workshop, worauf

00:07:01: kommt es an und so weiter, aber in a nutshell, was für uns ganz wichtig ist, damit wir effizient

00:07:07: und schnell arbeiten können ist, wir müssen in jedem einzelnen Use Case an das Domänenwissen

00:07:12: rankommen und wir müssen einen Experten haben, mit dem wir in einem schnellen und einfachen

00:07:17: Austausch Fragen klären können, weil im Zweifelsfall weiß ich nicht, worauf es bei der Produktion

00:07:22: bei Compound Kunststoffen ankommt, wie man Lebensmittelstärke verarbeitet oder was die

00:07:29: zentralen Constraints bei der Produktionsplanung in einem Stahlhochofen sind, da muss ich

00:07:34: mit jemandem sprechen können, der mir diese Infos gibt und ich brauche eine klare Herangehensweise

00:07:42: um mit den Daten zu arbeiten, ich muss wissen, wer gibt mir Zugriffe darauf, was bedeuten

00:07:47: die Daten, was bedeuten die Speiten, das ist vielleicht auch so ein Unterschied zu dir,

00:07:51: also die ist wichtig, alle Daten sind da und es geht schnell und kostet nicht so viel,

00:07:56: das ist so meine Vorstellung von deiner Arbeit, jetzt ganz einfach gesprochen und mir geht

00:08:01: es ja um den Inhalt der Spalten, macht der Sinn, sind da keine fehlerhaften Daten drin,

00:08:05: wie hängt Spalte X mit Spalte Y zusammen und wie benutze ich das in meinem Modell und

00:08:10: diese Dinge müssen geklärt sein und die müssen schnell und einfach zu klären sein, damit

00:08:16: man dann wirklich als Data Scientist arbeiten kann.

00:08:19: Und wenn ich jetzt über Projektplanung nachdenke, dann denke ich in allererster Linie auch mit

00:08:23: an Gira oder irgendein Ticket Tool.

00:08:25: So jetzt geht es bei euch neu in ein Projekt rein, du hast jetzt das leere Gira Board.

00:08:30: Wie viele Tickets kannst du von dir aus an Tag 1 schon schreiben?

00:08:34: Es ist sehr unterschiedlich viel, ich glaube eine Sache, mit der wir ja natürlich jetzt

00:08:39: auch aufholen müssen, wir ziehen das so ein bisschen hier auf, aber wir können ja bei

00:08:43: Alionicht, Data Engineering und Machine Learning trennen.

00:08:45: Du musst immer ein Beides tun oder du musst zumindest für beides jemanden im Team haben

00:08:51: und das heißt die ersten Tickets, Erstellung des Use Case spezifischen Datenmodells, Bereitstellung

00:08:58: der ETL-Strecken, auch weil auch das versuchen wir von Anfang an, einfache Governance Frameworks

00:09:07: und so umzusetzen.

00:09:08: Das ist klar, das können wir machen in Teilen, unter anderem dank deiner Vorbeit können

00:09:14: wir das auch schon mit Templates und Infrastructure as Code tun, das ist das eine und dann ist

00:09:21: Data Science natürlich und ich glaube darauf ist es ja so ein bisschen hinaus ein iterativerer

00:09:26: Approach, wo wir ausprobieren müssen und das heißt ja, das ist nicht weg, wir fangen

00:09:31: an und haben viele Notebooks und da drin machen wir Explorationsstudien, Annahmentests,

00:09:37: Desentests, Modelle, Modelle die wir ausprobieren, das muss alles passieren, da muss man dann

00:09:46: drüber sprechen mit den Experten, die Data Scientists untereinander und da müssen wir

00:09:50: am Ende hoffentlich Erkenntnisse gewinnen, die wir dann in Produktions Code überführen

00:09:55: können.

00:09:56: Das heißt am Anfang was wir typischerweise machen ist, wir machen eine Technik oder einen

00:10:02: Data Science Planning und überlegen uns was sind die Fragen die wir an die Daten stellen

00:10:07: müssen, so was interessiert uns bezüglich statistischer Verteilungen, bezüglich Ausreißern,

00:10:13: bezüglich Korrelationen oder ja Nichtlinian Zusammenhängen und da gibt es dann die Aufgaben,

00:10:22: mache mal eine Mutual Information Study, schreibe mal Code für Ausreißer Entfernung, bereite

00:10:29: die Sensordaten vor all diese Dinge, das können wir schon schreiben, aber das passiert dann

00:10:33: in erster Runde, einfach erstmal in einem Notebook und ja noch nicht als Production Code.

00:10:39: Aber diese ganzen Denkweisen sind die von Tag 1 da oder ist das ein iterativer Prozess,

00:10:44: also kannst du an Tag 1 sagen die Sachen die du jetzt gerade genannt hast zum Schluss,

00:10:48: die wirst du ohnehin brauchen, siehst du das im Vorfeld schon immer oder ist das eher

00:10:52: etwas was man dann zufällig sieht in der ersten Woche, in der zweiten Woche und dann wird

00:10:56: es halt reingeschoben.

00:10:57: Ja also das passiert schon, On the Fly kommen viele Erkenntnisse zu, also ein paar grundlegende

00:11:02: Dinge sind immer klar, ich glaube jeder wird anfangen und wird sich die Daten erstmal

00:11:06: anschauen, wird die typischen EDA Notebooks haben, aber dann unterwegs kommen einem dann

00:11:15: noch mehr Gedanken und noch mehr Fragen, die man eigentlich an die Daten hat.

00:11:18: Das was ich jetzt so ein bisschen raushöre ist, es ist gar nicht so klar, wann das Ende

00:11:23: einer Aufgabe erreicht, das bei euch, oder?

00:11:25: Genau, also Akzeptanzkriterien im Ticket ist, sage ich mal, diesen Schwammiger vielleicht,

00:11:32: genau, also ich mein gut, den Punkt den habe ich ja, ich habe ja bewusst Punkte aufgeschrieben,

00:11:38: wo sich unsere Arbeitsweisen und Denkweisen auch unterscheiden und ich finde, das hat

00:11:41: man total gemerkt jetzt hier, ich persönlich, wenn ich in ein Projekt reinkomme, wo es eben

00:11:47: um die reine Plattformaufgabe geht, es geht darum, dass man ETA Strecken baut, es geht

00:11:51: darum, dass man weiß ich nicht Databricks oder die Cloud hochzieht oder solche Sachen,

00:11:56: ich finde da hat man am Anfang immer ein sehr, sehr klares Bild, man hat viele einzelne Schritte,

00:12:00: die für sich auch sehr, sehr klar abgrenzbar sind, mit einem klaren Anfang, ein klares

00:12:04: Ende und natürlich, es kommen im Laufe der Zeit immer wieder Aufgaben dazu und man kann

00:12:08: nicht alles vorhersehen, aber ich würde sagen, dass ich doch durchaus weiter in die Zukunft

00:12:14: denken kann, von Tag-1 an, ohne irgendwas bisher angefasst zu haben, ohne mit irgendjemandem

00:12:20: gesprochen zu haben, als du es in der Regel kannst.

00:12:22: Mir kommt gerade unterwegs eine lustige Metapher.

00:12:26: Ich hab jetzt abends immer mal Videos von Bob Ross geguckt, wie der ein Bild malt, und

00:12:33: der malt dann so ein Landschaftsbild und dann sagt er, guck mal hier ist der Berg und schaut

00:12:39: mal an, da ist ja ein Fluss und vielleicht neben dem Fluss ist ein Gebüsch und da mal ich

00:12:43: ein Hase dahinter und das ist so ein bisschen der Data Scientist, der geht durch die Landschaft

00:12:46: und unterwegs fällt ihm auf, was es da noch geben könnte und wie man das noch weiter

00:12:50: entwickeln könnte und du kommst mir eher so vor wie der Bildhauer, der sagt, hier ist

00:12:53: der Marmoblock, da soll nachher ein Pferd stehen, ich hau jetzt einfach alles weg, was nicht

00:12:58: Pferd ist und am Ende hab ich das Pferd, also du hast das finale Bild, das existiert schon

00:13:03: in dir und du machst nur noch den Weg dahin frei und wir laufen so ein bisschen durch die

00:13:09: Landschaft und müssen dann unterwegs auch ein bisschen uns den Weg bahnen und ebnen.

00:13:14: Ja und vielleicht auch ein bisschen übermalen und kaschieren.

00:13:17: Das kommt vor.

00:13:18: Wobei ich glaube auch das muss ich machen, kannst du Aufgaben schätzen im Vorfeld?

00:13:25: Ich würde sagen es ist eher ein definieren, ich gebe mir eine bestimmte Zeit, die ich für

00:13:33: etwas aufwenden will und dann höre ich im Zweifelsfall auch auf diesen Weg zu verfolgen,

00:13:38: wenn er nicht zum Erfolg geführt hat.

00:13:41: Wenn der super schnell und gut zum Erfolg führt ist natürlich gut, aber so was sind

00:13:48: Beispiele, du sagst, du möchtest polynomial Interaction Features testen und willst gucken

00:13:58: ob die einen Einfluss haben und ob die das Modell besser machen und jetzt kannst du

00:14:02: natürlich sagen ja ich mach das und dann ich will dann, dass das Modell 10 Accuracy Punkte

00:14:08: besser ist und das soll zwei Tage dauern, aber dann hast du zwei Tage lang alle möglichen

00:14:14: Sachen ausprobiert und hast es einfach immer noch nicht gefunden und jetzt kannst du natürlich

00:14:19: sagen, ich probiere das noch bis zur X in Ordnung weiter oder ich sage vielleicht ist

00:14:23: das an der Stelle, macht es jetzt irgendwie keinen Sinn mehr und ist fertig.

00:14:27: Genau und du hast ja schon gesagt, die Aufgabenbeschreibung selbst ist eher eine Fragestellung und keine

00:14:32: Technischen Requirements, zumindest im ersten Schritt nämlich stark an.

00:14:35: Ich glaube hinterher erinnert sich das, wenn es an das Modell Deployment und alles geht,

00:14:38: dann wird es sehr, sehr konkret, aber ich glaube am Anfang ist man doch sehr unkonkret unterwegs,

00:14:43: habe ich das richtig verstanden.

00:14:44: Genau, ja, so am Anfang ist es Beating Debush und guckt mal irgendwo jemand raus springt,

00:14:50: das kann man schon ein bisschen so sagen, genau und vielleicht um an der Stelle schon

00:14:54: mal die Brücke zu schlagen, das ist nämlich ein Thema, ich weiß gar nicht ob wir da auch

00:14:58: schon darüber gesprochen haben in letzter Zeit, das hat dann bei mir zum Beispiel auch

00:15:04: Auswirkungen auf die erwartete Codequalität, weil ich glaube in dieser initialen Phase

00:15:11: des Ausprobierens geht es einfach auch darum schnell zu sein und wenn du jetzt der Data

00:15:16: Scientist bist und du hast irgendwie 10 verschiedene Ansätze getestet, von denen einer funktioniert

00:15:22: ist mir ehrlich gesagt die Codequalität der neuen, die nicht funktioniert haben, relativ

00:15:26: egal und wichtig ist erstmal, dass du mir gesagt hast, ich habe den Weg gefunden und

00:15:31: dann gehst du in eine Phase, wo du vielleicht diesen Code aufbereitest und schöner machst,

00:15:36: aber ich habe nichts davon, wenn du von Anfang an wunderschöne Klassen schreibst und machst

00:15:41: noch Tests für jede deiner Datmanipulation und was weiß ich und dann kommt draus, brauchen

00:15:45: wir alles nicht, weil hilft uns nicht.

00:15:48: Ja, vielleicht muss man hier auch unterscheiden zwischen der Explorationsphase und hinterher

00:15:53: die Deploymentphase, aber das ist eine ehe gute Überleitung an dem Punkt, Codequalität,

00:15:58: du hast jetzt schon gesagt, ich sage mal in der Explorationsphase ist die Codequalität

00:16:02: total egal, ich würde sagen, ihr entwickelt da auch sehr für euch selbst, oder, entwickelt

00:16:07: die auch für euren Kollegen und Kolleginnen.

00:16:10: Ja, ich würde tatsächlich sagen, dass es da auch bei Alio eine stückweite Nevolution

00:16:15: gab, das kann man schon sagen, wir sind da besser geworden und da auch direkt leichtes

00:16:20: zurück rudern, das soll immer noch nicht der letzte Humbook sein und vielleicht kommt

00:16:26: irgendwann jemand mal auf die Idee zurück mit einem leicht anderen Ansatz und möchte trotzdem

00:16:30: aufbauen auf dem Test, den du schon mal gemacht hast, wo du gesagt hast, ich habe hier nichts

00:16:33: gefunden, aber vielleicht bist du ja einfach nur nicht weit genug gegangen, dann möchte

00:16:36: ich mir das schon angucken können und wenn wir jetzt sagen, zum Beispiel wir nutzen

00:16:40: vier Notebooks dafür, nach wie vor, dann habe ich aber schon ein paar Ansprüche daran

00:16:45: und ich möchte schon deinen Denkprozess nachvollziehen können und da zum Beispiel einfach Markdown,

00:16:51: schreib mir rein, warum hast du folgenden Test gemacht, warum hast du folgende Sache

00:16:55: ausprobiert und dann hast du ein Ergebnis und was sagt dir dieses Ergebnis jetzt und warum

00:17:00: machst du danach Schritt 2, 3 und 4 und welcher Logik folgt das und das hilft mir einfach,

00:17:05: wenn ich mir das hinterher anschaue und wenn ich mich hinterher nochmal frage, der Janis

00:17:09: hat ja schon mal getestet, ob es da irgendwie nicht lineare Korrelationen gibt, was hat

00:17:16: der denn da eigentlich getestet und warum hat der im Ticket geschrieben am Ende nichts

00:17:21: Sinnvolles gefunden und vielleicht hat der ja bestimmte Dinge gar nicht getestet, das

00:17:26: will ich sehen können und ich will auch sehen können, auf welchen Daten hast du das denn

00:17:31: getestet, auf welchem Zeitraum, mit welchen Methoden und das muss ein bisschen nachvollziehbar

00:17:37: sein, das sind dann eher so inhaltliche Punkte und wir können das Codequalität nennen, Dokumentationsqualität

00:17:45: Ich wollte sagen Dokumentationen, die mir wichtig sind, Ergebnis, Dokumentation als elementarer

00:17:51: Standteil.

00:17:52: Ich mache es auch mal offiziell an der Stelle, shout out an Tobi, der macht das sehr schön.

00:17:57: Tobi sagt immer liebevoll, ich habe gestern noch einen Tag mal eine Notebookstudie gemacht,

00:18:01: und dann kriegst du so eine kleine Bachelorarbeit von ihm, in der er schreibt mehr Markthontext

00:18:07: als Code, aber ist sehr erhähnend zu lesen.

00:18:10: Auch hier wieder einen Weltenunterschied, die Punkte, die ich jetzt aufgeschrieben habe,

00:18:15: die entspringen ja irgendwie, ich habe ja gesagt, die wurden einheitlich, einseitig entschieden,

00:18:20: Codequalität.

00:18:21: Was ich mir unter Codequalität vorstelle, ich weiß nicht, ich lese das Buch Clean Code,

00:18:25: ich lese da drin, okay, eine Signatur soll so einfach wie möglich sein von einer Methode

00:18:31: oder wie auch immer.

00:18:33: Man hat irgendwie Pep-Age Standards, an die man sich hält.

00:18:37: Man hat keine Lintings, also man codeet einfach konventionell, man hat vielleicht ein Codeformat

00:18:45: hat.

00:18:46: Das spielt für mich alles, wenn ich den Begriff Codequalität höre, spielt das für mich alles

00:18:49: in die Codequalität mit rein und davon habe ich jetzt bei dir zum Beispiel gar nichts gehört.

00:18:55: Ja, du siehst uns wieder als die Metzger der Software-Entwicklung, ich weiß.

00:19:02: Also dazu, wir nutzen schon, zum Beispiel auch wenn wir lokal entwickeln und ich weiß,

00:19:08: du magst sie nicht so, aber wir ist Code-Dev-Containers und da drin ist Flake 8 vorgesehen, da drin

00:19:15: ist eine Line-Length vorgesehen.

00:19:18: So, das ist schon – auch bei Notebooks?

00:19:22: Besser als nichts, Zukunft auch bei Notebooks, ja, ne, aber so ein paar Dinge in diese Richtung

00:19:33: schon, aber wie gesagt, diese klare Unterscheidung, Explorationsphase und Produktivcode und am

00:19:41: Ende, wenn ich irgendwas gefunden habe, was funktioniert, wenn ich ein Modell bauen will,

00:19:45: das Modell soll vielleicht Teil einer Klasse sein, die ich dann irgendwo in ein Docker-Container

00:19:51: packe, was irgendwo läuft, dieser Code und da, glaube ich, nützt uns auch der Austausch,

00:19:57: sage ich mal, mit den Software-Entwicklungen, mit den Data-Engineeren und ein bisschen von

00:20:00: denen zu lernen, weil am Ende ML Ops ist ein großes Thema und das ist die ICD für Machine-Learning

00:20:07: und da muss man auch lernen von denen, die das schon seit Jahrzehnten sehr gut machen

00:20:12: und das hilft hier hinten raus ganz extrem, deswegen, dass in dieser zweiten Phase sollten

00:20:20: wir auch deutlich höhere Ansprüche an den Code selber haben und eine Sache, die mir noch

00:20:25: unterwegs einfällt, um die noch anzuhängen, was auch wichtig ist und was wirklich zeitspart,

00:20:32: du willst in verschiedenen Bereichen Dinge ausprobieren, du willst unterschiedliche Featuresets

00:20:40: benutzen für deine Modelle, du willst unterschiedliche Modelle benutzen, Modelle sollen unterschiedliche

00:20:45: Hyperparameter haben, all diese Dinge und du könntest jetzt Code schreiben, wo du das

00:20:50: in jedem Notebook hinschreibst und hardcoded festhältst und es ist jedes Mal anders oder

00:20:55: du modularisierst das in ein paar Funktionen, wo du das als Parameter mitgeben kannst,

00:20:59: sodass die gleichen Leute den Code benutzen können und damit noch mal ein anderes Featureset

00:21:03: testen können, ein anderes Modell machen können und das dann auch einfacher locken können,

00:21:07: zum Beispiel in ML Flow.

00:21:08: Das ist auch so eine Sache für Codequalität, ich will trotzdem auch flexiblen Code schreiben,

00:21:13: anpassbaren Code schreiben und das hilft mir tatsächlich auch in der ersten Phase, weil

00:21:17: ich dann schneller mehr testen kann, wenn ich das in jedem Notebook wieder neu schreibe

00:21:21: oder irgendwie nur ein Notebook klone und dann da drin rumwurstel, macht es auch nicht

00:21:26: besser.

00:21:27: Ich finde so für Softwareentwickler hätte ich gesagt eine Selbstverständlichkeit, du

00:21:30: hast jetzt letztlich das dry Concept vorgestellt, don't repeat yourself, man muss an der Stelle

00:21:37: auch fair sein, Themenschwerpunkte, die sind ja schlichtweg anders, wenn jeder Data Scientist

00:21:41: ein ausgebildeter Softwareentwickler wäre, dann wäre halt jeder Softwareentwickler auch

00:21:45: nur ein Softwareentwickler.

00:21:46: Also letztlich ist die, ich glaube, die inhaltliche Ausprägung auf einem bestimmten Domänenbereich,

00:21:54: den man jetzt jeweils abdeckt, der ist einfach intensiver oder weniger intensiv.

00:21:57: Ja und du hast einen anderen Weg, der dich dahin führt, einen gewissen Code zu schreiben,

00:22:05: zum Beispiel, ich versuche jetzt ein gutes, prägnantes Beispiel zu finden, du sprichst

00:22:16: mit dem Domänen-Experten und der sagt dir, dass er einen gewissen physikalischen chemischen

00:22:22: Zusammenhang in den Features vermutet und dann sagt er, naja du musst da irgendwie so eine

00:22:27: Art oder das, was du daraus schließt ist, ich brauche irgendeine Art Interaction-Feature,

00:22:32: wo ich die miteinander verwurschteln muss oder wo ich irgendeinen Feature mal quadrieren

00:22:37: muss, solche Dinge, oder er sagt dir vielleicht einfacher ein bestimmter Sensor, der hat manchmal

00:22:44: Ausreißer und du musst die Ausreißer entfernen und du machst das und dann sprichst du so

00:22:48: sehr konkret mit diesem Domänen-Experten, der sagt dir das über einen bestimmten Sensor

00:22:54: und was machst du, naja, du nimmst dir den Sensor, nimmst die Werte, machst eine Ausreißerentfernung,

00:23:01: eine Outlier-Detection und dann ist es so ein Learning zu sagen, hey, wenn das davor

00:23:06: kommt, vielleicht kommt das auch anders vor, vielleicht wäre es gut, ich schreibe da eine

00:23:09: allgemeine Funktion für und die lasse ich mal über alles laufen, guck mir das an und

00:23:12: entscheide dann, wo ich die benutze und wo ich die nicht benutze und das ist so eine,

00:23:17: ja, ist das dann Code-Qualität, ist das eine Erfahrungswissen und ein Vermeiden von, ich

00:23:24: stücke mir das zusammen wie so ein kleines Data Science Frankenstein-Monster, was ich

00:23:28: aufbauen.

00:23:29: Ja, naja, auf jeden Fall, machen wir mal einen Punkt hier, einen Punkt weiter gedacht, ich

00:23:36: glaube das geht auch noch in die Richtung Code-Qualität rein, aber das reine Testing,

00:23:39: vielleicht fange ich hier einfach mal an, meinen Standpunkt hier, wenn ich soft verschreibe,

00:23:44: dann habe ich sehr oft, ich sage mal, unitests, Integration-Tests, also entweder teste ich

00:23:49: einzelne Komponenten meines Codes sehr explizit für sich, nur Inhaltscodes oder ich teste

00:23:54: einzelne Komponenten, wie sie mit Infrastruktur außer Haltscodes interagieren, das wären

00:23:59: dann die Integration-Tests, dann gibt es, wenn ich besonders voll bin, noch die end-to-end-Tests,

00:24:03: das schmeiß ich vorne was rein in meine Funktion und schau was hinten rauskommt und teste quasi

00:24:09: nicht nur einzelne Funktionen, sehr modular, sondern Funktionen als, ja, ich sage mal,

00:24:15: ganze Programmabläufe, wenn man so will und das ist bei mir relativ stark vorgegeben,

00:24:22: also da, weiß ich nicht, gibt es auch keinen großen Weg drum herum und es ist eigentlich

00:24:24: immer klar, wie ich das mache, ich meine, letztlich habe ich ja immer klare nutzbare

00:24:29: Komponenten und die kann ich sehr, sehr klar testen mit sehr bekannten Schemas.

00:24:34: Wie ist das bei dir im Data Science Machine Learning Bereich?

00:24:40: Ich würde sagen, schwerpunktmäßig sind es ein paar andere Test-Ideen, über die man

00:24:48: mehr nachdenkt.

00:24:49: Die eine Sache, wo fange ich an, eine Sache, die zum Beispiel sinnvoll ist, die so in die

00:24:57: Art von Unitests geht, ist, ich habe einen Modell trainiert, die Blut möchte ich benutzen

00:25:06: und das erwartet bestimmte Inputs, also erwartet, also man kann das in MLflow zum Beispiel mit

00:25:11: einer Signatur locken, ich kann sogar ein Beispiel-Datensatz locken, der da reingehen

00:25:14: sollte und was sollte rausgehen und auf sowas kann ich testen, wenn jetzt neue Daten kommen,

00:25:19: haben die das richtige Schema, haben die, das heißt, du kannst irgendwie AP-Kompatibilität

00:25:25: lassen.

00:25:26: Genau, haben die die richtigen Datentypen und auch eine inhaltlich wichtige Sache, wenn

00:25:31: ich meinen Modell trainiert habe, habe ich ja da Annahmen über den Parameterraum, aus

00:25:36: dem diese Daten kommen können.

00:25:38: Dann denke ich zum Beispiel, der pH-Wert soll irgendwo zwischen 0 und 14 liegen oder,

00:25:45: keine Ahnung, zwischen 5 und 8, nur das macht Sinn und vielleicht macht es an der Stelle

00:25:50: Sinn, einen Test zu schreiben oder einen Assert zu machen, wenn ich jetzt auf einmal in Inferenz

00:25:57: einen Wert habe, der nicht in den Trainingsraten enthalten ist, weil das hat einen Einfluss

00:26:01: auf meine Modellgenauigkeit, sowas kann ich testen.

00:26:04: Da gibt es zum Beispiel Libraries wie Pandera, mit denen man eben ganzen Pandas, DataFrames

00:26:12: anhand bestimmter Constraints prüft, das ist ein wichtiger Punkt und der andere Punkt,

00:26:18: der ist dann eher so eine Art Monitoring und betrifft die Gesamtheit der Daten.

00:26:25: Sind die Annahmen, die ich beim Modelltraining getroffen habe, sind die noch valide?

00:26:30: Ich habe da bestimmte Verteilungen angenommen, stimmen die oder nicht Datatrift.

00:26:33: Ist die Modellvorhersage, bleibt die stabil oder habe ich einen Prediction-Trift, diese

00:26:38: typischen Trift-Detection-Sachen, Concept-Trift, macht das alles noch Sinn und dann entsprechend

00:26:43: Neues trainieren der Modelle und letzter Punkt, ich habe ein Modell trainiert, ich benutze

00:26:48: das, bringt es mir denn was, Abitesting gibt es hier auch.

00:26:53: Du testest im Prinzip immer den Output und nicht den Weg dahin, wenn man so will.

00:26:58: Also das was du jetzt gerade beschrieben hast, du testest immer das finale Modell, das ist

00:27:02: im Prinzip das, was ich bei mir als N2N-Test, faulerweise bezeichnen würde, wo du sagst,

00:27:08: Hier ist das Modell. Ich schaue jetzt wie gut performt das unter verschiedenen Gesichtspunkten.

00:27:12: Das ist letztlich immer ein Output-Test. Oder testet ihr auch explizit häufiger mal den Weg zum Modell.

00:27:17: Naja, also ich sag mal so, dass wie Datatrift ist ja erstmal der reine Input. Also ist der Input noch so wie ich ihn erwarte.

00:27:23: Der Daten-Input.

00:27:24: Der Daten-Input, entsprechend die Feature und auch den Verteilungen, die sie haben sollten.

00:27:28: Oder auch so was wie Pandera-Tests haben die noch das Schema, wie es funktionieren sollte und so was wie ein

00:27:34: Konzept-Drift ist ja stimmt der angenommenen Bezug zwischen Input-Daten und erwarteten Labels, stimmt der noch.

00:27:44: Das ist ja, sag ich mal, auch eine Art der Weg, den man da monitort, den man testet.

00:27:49: Genau und dann hinterher der Output ist der auch beim erwarteten Bereich.

00:27:53: Ja gut, aber das worauf ich jetzt hinaus wollte war, ihr trainiert ja ein Modell.

00:27:58: Und die Methoden, die du jetzt gerade beschreibst, die gehen alle auf das fertige Modell.

00:28:03: Aber das trainierte Modell ist ja auch irgendwie eine Form von Code.

00:28:06: Ihr lest ja Daten, ihr macht damit was und ich nehme jetzt mal nicht an, dass das Training einzeilig ist,

00:28:11: sondern vielleicht habt ihr da auch so ein paar hundert Zahlen an Code zwischen und vielleicht auch ein paar Funktionen.

00:28:17: Würdest du sagen, dass, ich sag mal, Unit-Testing auf diesen Funktionen verbreitet ist oder weniger verbreitet?

00:28:22: Oder würdest du sagen, dass das sinnvoll ist oder weniger sinnvoll?

00:28:26: Nein, jetzt nicht in der großen Masse vorhanden bei uns.

00:28:32: Ja, ich meine, du kannst natürlich, ich sag mal, du könntest eine Funktion,

00:28:38: ich bleibe irgendwie bei diesem Outlier Detection Thema, die könntest du jetzt unitesten.

00:28:43: Ehrlich gesagt mache ich das nicht so oft.

00:28:46: Das macht ja wahrscheinlich auch einfach wenig Sinn, ne?

00:28:49: Ja gut, du könntest natürlich, was könnte passieren,

00:28:54: wenn da jetzt jemand die umbaut und ändert darin die Annahme und das passt dann nicht mehr zu deiner Annahme,

00:28:59: da wäre es vielleicht schon sinnvoll, das zu testen.

00:29:01: Ich würde aber auch hoffen, dass das keiner einfach so macht.

00:29:05: Aber das würde ja dann auch wieder hinten rauswahlen bei Modell entsprechend.

00:29:09: Ja.

00:29:10: Ich meine, wenn das Modell dann am Ende besser performt, wäre es ja fast, könnte man sich jetzt fragen,

00:29:16: warum, aber solange es nicht schlechter performt, wäre das ja auch gar nicht so schlimm, oder?

00:29:24: Ja, also wenn du versehentlich mal ein Modell besser machst, würde ich dir mal erstmal einverstanden.

00:29:30: Wir haben aber dann trotzdem schön zu wissen, warum.

00:29:33: Ja, okay.

00:29:34: Nee, es ist spannend, wie gesagt, unterschiedliche Denkweisen.

00:29:37: Ich finde darüber sollte man auch öfter mal reden.

00:29:39: Ein Bereich, wo ich gesagt hätte, das ist total selbstverständlich,

00:29:43: wo ich auch, ich glaube, das war vor einem halben Jahr Unterschiede gemerkt habe in Denkweisen,

00:29:48: ist der Umgang mit verschiedenen Entwicklungsumgebungen.

00:29:51: Also auch hier als Hintergrund, als Entwickler entwickle ich häufig auf Dev.

00:29:57: Das ist letztlich eine Entwicklungsumgebung, die steht mir zur Verfügung oder dem Team, auf dem ich arbeite.

00:30:02: Und da habe ich dann auch echte Infrastruktur.

00:30:04: Und ich muss nicht Angst haben, dass ich das Produktivsystem kaputt mache mit dem, was ich mache.

00:30:10: So, wenn ich das dann hinterher deploye, dann ist es oft so, dass es nochmal irgendwie auf so einer Staging-Environment geht,

00:30:17: wo das einfach die nächste höhere Entwicklungsumgebung ist, die dann schon stabiler sein soll als Test,

00:30:23: aber die ist immer noch nicht live.

00:30:25: Und am Ende kommt dann die Produktiv-Umgebung, typischerweise.

00:30:28: Und da komme ich als Entwickler häufig gar nicht mal mehr drauf mit meinen IDEs und was ich da nicht alles habe

00:30:36: und auch nicht direkt auf den Server.

00:30:38: Ich kann ich da ganz oft nur noch mit die ICD Pipelines drauf zugreifen und sie halt im Monitoring, ob alles stimmt oder nicht.

00:30:44: Aber das ist für mich so ein gängiger Prozess.

00:30:47: Ich entwickle einfach auf Dev.

00:30:49: Und ich muss keine Angst haben, dass ich irgendwas kaputt mache.

00:30:52: Und das funktioniert für mich persönlich auch sehr, sehr gut.

00:30:55: So, jetzt frage ich mich im Bereich Data Science.

00:30:58: Kann sowas funktionieren?

00:30:59: Also, kannst du auf einem Reihen oder wie ist für dich Dev definiert?

00:31:07: Ich weiß nicht, ob ich da eine eindeutige Antwort zu habe.

00:31:09: Ja, das ist eine Sache, die muss dich lernen.

00:31:11: Das ist eben das Interessante.

00:31:13: Ich glaube, da gibt es ganz unterschiedliche Umgebungen, die man haben kann.

00:31:20: Ich bin gerade mehr in unseren Industrieprojekten involviert.

00:31:25: Und da ist zum Beispiel ein Setup, was wir haben.

00:31:29: Ich erzähle einfach mal, wenn du sagst, inwiefern das zu deiner Frage passt.

00:31:33: Daten, zum Beispiel Sensordaten, kommen rein.

00:31:38: Und wir verwalten die alle in der Cloud.

00:31:41: In der Cloud, in dem Fall auf Databricks, trainiere ich mein Modell.

00:31:45: Teste das mit Testdaten.

00:31:48: Und möchte registriere das in MLflow.

00:31:52: Und irgendwann packe ich das in ein Docker-Container und deploye das auf einem Edge-Device.

00:31:57: Das ist dann quasi prod.

00:31:59: Ja, das heißt, auf eine Art ist es da.

00:32:01: Und da haben wir es dann so, dass wir sagen, okay, jetzt haben wir da irgendwo ein funktionierendes, gutes, laufendes Modell.

00:32:07: Und das haben wir dann auf einem Slot darliegen.

00:32:10: Da sagen wir, Slot 1, das sind die Predictions, die glaubt ihr.

00:32:14: Und jetzt haben wir einen Monat neue Daten gesammelt.

00:32:16: Oder wir hatten Data Drift Detected, whatever.

00:32:19: Und haben ein neues Modell trainiert.

00:32:21: Das legen wir dann daneben auf Slot 2.

00:32:23: Und schauen uns mal eine Zeit lang an im Vergleich die Modelle, wie performen die.

00:32:27: Was wir dann aber stand jetzt noch machen ist, wir mit Expertenblick schauen wir drauf und sagen irgendwann, wir schieben das von Slot 2 auf Slot 1 und sagen, das ist jetzt das Modell, den wir folgen.

00:32:39: Das ist jetzt nicht in dem Sinne, wie ich weiß, dass du arbeitest.

00:32:43: Ich habe verschiedene Databricks Workspaces mit auch vielleicht unterschiedlichen Daten in den jeweiligen Stages.

00:32:49: Das nicht.

00:32:50: Aber es ist so eine Testung, ob ich ein Modell wirklich live nutzen will in der Produktion.

00:32:56: Ja, letztlich beschreibst du ja jetzt auch produktiv mit einem gewissen ABI-Testing, das finde ich jetzt total legitim.

00:33:02: Aber interessant zu hören sind die Testdaten, die du verwendest.

00:33:05: Sind die Testdaten, sind das dann echte Daten oder sind die irgendwie generiert, wie kann ich mir die vorstellen?

00:33:10: Die sind alles echte Daten.

00:33:11: Das sind dann produktive Daten wirklich?

00:33:13: Ja.

00:33:14: Okay, das heißt, weil letztlich ist das ja, also für mich ist Prot ja heilig und ich sehe gar nichts auf Prot.

00:33:22: Ich sehe keine Usernamen, ich sehe keine E-Mail-Adressen, ich sehe gar nichts.

00:33:26: So, und alles, was ich auf Devs sehe, ist häufig generiert oder ich sage mal ein pseudonymisierter Abzug, wenn überhaupt.

00:33:35: So, und auch der ist oftmals in Frage zu stellen.

00:33:37: Aber das kann ja in deiner Welt gar nicht richtig funktionieren.

00:33:40: Also du brauchst ja eigentlich immer für das, was du machst, einen repräsentativen Datensatz.

00:33:44: Und der muss ja eigentlich immer irgendwie prot-like sein, oder?

00:33:50: Ja, also in dem Sinne, dass natürlich ich das Modell mit gewissen Features trainieren muss und die Feature, die muss es dann auch geben in der Inferenz.

00:33:58: Das stimmt, ja.

00:33:59: Aber das bedeutet ja nicht, dass du nicht zum Beispiel Usernamen quasi haschen kannst und ich arbeite dann halt mit den Hash-Wänden.

00:34:10: Da muss das halt live auch passieren, da müssen ja durch die gleiche Pipeline laufen.

00:34:14: Das ist ja okay.

00:34:16: Für mich wäre es jetzt auf der anderen Seite auch logisch, dass ich meinen Code über verschiedene Umgebungen hinweg deploye und teste.

00:34:23: Und nochmal individuell schaue, ob es da wirklich funktioniert.

00:34:26: Würde das für...

00:34:28: Und ich weiß, da gibt es verschiedene Ansätze, das muss man auch dazusagen.

00:34:32: Also das, was wir jetzt gerade sagen, es ist sehr einseitig erzählt.

00:34:36: Aber würdest du sagen, dass zumindest in deiner Projekterfahrung, die du jetzt hast, das Sinn gemacht hätte, ein Modell einmal auf Dev zu trainieren,

00:34:44: dann auf Proz zu trainieren und jeweils individuell zu deployen.

00:34:48: Oder würdest du sagen, dass das Sinnvollste ist, was du bisher gesehen hast, dass du, meiner Wege, eine Entwicklungsumgebung hast.

00:34:54: Auf der trainierst du dein Modell und dieses Modell, das ist dann schon produktiv tauglich und das wird dann direkt nach Proz deployet.

00:35:01: Ja, also ich glaube, diese Entscheidung für Deploy Code, Deploy Model, die hängt von so ein paar Fragen ab, die man sich beantworten muss.

00:35:10: Und die eine Frage ist jetzt zum Beispiel, hast du jetzt in deiner Umgebung auf State oder Prod überhaupt genug Daten, um das Modell zu trainieren?

00:35:19: Das Modell hängt ja auch ab von der Anzahl der Daten, mit denen ich es trainiere.

00:35:23: Und wenn du da nur einen eingeschränkten Bereich hast und dann wäre das Modell entsprechend schlechter bei gleichem Trainingscode,

00:35:31: dann wirst du es ja schon mit allen Daten trainieren.

00:35:33: Also hast du überhaupt in allen Systemen alle Daten.

00:35:36: Und du hast unterschiedliche Verwaltungsaufwände.

00:35:42: Möchtest du das Ganze über eine CICD Pipeline machen, mit entsprechend teurem jeweils neuem Trainieren des Modells?

00:35:51: Oder willst du irgendwo ein zentrales Model Registry haben, das du aber dann auch nur an einer Stelle siehst,

00:36:00: von dem aus du das Modell überall hinschubst und du dann sehen musst, wie du deine Berechtigung verteilst.

00:36:08: Ja, ich habe da keine allgemeingültige Präferenz.

00:36:12: Ja, ich finde das für mich wirklich in erster Linie interessant, weil genau dieser Ansatz, Deploy Code, ist in meiner Welt ein totaler No-Brainer.

00:36:22: Also da ist es ganz klar, ich trage meinen Code durch die verschiedenen Umgebungen und ich teste ihn auf jede Umgebung individuell.

00:36:29: Aber ich finde es extrem schwierig im Data Science Bereich genauso zu denken, weil das macht überhaupt keinen Sinn.

00:36:34: Wenn ich jetzt von meinem Standpunkt ausgehe, dass ich produktiv gar keinen Zugriff mehr habe.

00:36:39: Ich sage mal, für dich würde es ja gar keinen Sinn machen, hinterher auf den echten Produktivdatensatz zu trainieren und keinen Zugriff darauf zu haben.

00:36:46: Du brauchst ja irgendwie trotzdem, weiß ich nicht, Metriken.

00:36:49: Du brauchst bestimmte Sachen, die musst du da sehen und dann musst du dir halt die Frage stellen am Ende, was passiert, wenn das nicht klappt.

00:36:55: Was passiert, wenn das Modell auf einmal produktiv schlechter performt, als es vielleicht in der Entwicklungsumgebung performt hat?

00:37:02: Gibt es da überhaupt einen Ansatz, dieses Problem zu lösen, außer du kriegst jetzt einen kompletten produktiven Datenabzug?

00:37:10: Weiß was ich meine?

00:37:12: Also ich finde diese ganze Denkweise, dass man jeden Schritt einzeln, der zum Prozess gehört, über alle Umgebungen hinweg testet.

00:37:19: Was macht für mich im Data Science Machine Learning Bereich sehr wenig Sinn gefühlt?

00:37:26: Ja, ich müsste das noch mal mehr aus deiner Warte durchdenken.

00:37:37: Ich habe mir die Frage so noch nicht gestellt.

00:37:40: Also für mich läuft es auf diese Trift-Themen hinaus und für mich ist halt wichtig, dass die Verteilung meiner Daten, auf denen ich trainiert habe, der entspricht, in der ich vorher sagen mache.

00:37:53: Und dafür monitoriere ich Data-Trift, Feature-Trift und so weiter.

00:37:57: Und sobald das nicht mehr gegeben ist, muss ich meine Trainingsdaten neu schneiden, so dass ich wieder eine repräsentative Verteilung der Daten habe.

00:38:07: Und das heißt für mich ist das eher so eine Art zeitlicher Gap in den Daten.

00:38:13: Wo sind meine Trainingsdaten und die typischerweise sind ja die Produktionsdaten dann die Neueren, die halt neu reinkommen, für die ich vielleicht noch gar keine Labels habe live, auf denen ich eine Vorhersage mache, als dass es ein Systemmischer ist, auf welchem System bewege ich mich.

00:38:31: Jedenfalls jetzt in unseren Use Cases.

00:38:36: Ja, es sind einfach grundlegend andere Fragen, die man sich in den Bereichen stellt.

00:38:40: Wie gesagt, bei mir ist es eher Prozess getrieben.

00:38:42: Wir haben das ja Eingangs in der Projektplanung schon gehabt, dass man sich am Anfang ganz andere Fragen stellen kann in den unterschiedlichen Bereichen und so ist es jetzt auch hier, glaube ich.

00:38:52: Aber ja, genau, wir haben noch einen Punkt auf der Liste.

00:38:58: Ich meine, das mit den Entwicklungsumgebungen ist vielleicht ein bisschen abstrakt, aber der nächste Punkt ist wieder sehr, sehr schön konkret.

00:39:05: Das ist der Projekt Wert, sage ich jetzt mal.

00:39:08: Und vielleicht schaut dort an unsere letzte Folge.

00:39:12: Wir haben ja vor einigen Stunden inzwischen, glaube ich, über die Data in Plug gesprochen, da hatten wir ja so zwei Masterclasses.

00:39:21: Und bei meiner Masterclass habe ich am Ende gesagt, was man tun muss oder welche Denkweise man am besten an den Start bringen könnte, sollte wie auch immer.

00:39:32: Wenn man jetzt von null an eine, ich sage mal, zentrale Datenplattformlösung bauen möchte, die auch Data Science Use Cases und KI Use Cases und Analytics ermöglicht.

00:39:43: Und einer dieser Punkte war eben, man sollte einen klaren Business Use Case für sich definieren, weil es dann einfach am meisten Spaß macht.

00:39:50: Das heißt, man sollte, meiner Meinung nach, etwas klar Messbares definieren, wo man sagt, okay, das bringt uns einen gewissen expliziten Wert.

00:40:01: Und da würde ich sagen, hat man im Data Science Machine Learning Bereich wesentlich bessere Karten als im Bereich Plattform Engineering und Data Engineering.

00:40:11: Würdest du das so unterschreiben?

00:40:13: Ja.

00:40:14: Ja, genau. Also ich meine, was wir schon versuchen, was wir auch ganz am Anfang von einem Projekt versuchen, ist wirklich einen Business Value abzuschätzen in Zahlen.

00:40:28: Also man plant ja, so unsicher Data Science auch ist, man plant eine gewisse Zeit ein, die es braucht, um ein Modell zu entwickeln.

00:40:39: Und dann kann man abschätzen, wenn ich damit eine bestimmte Verbesserung erziele, wann hat sich das Projekt refinanziert.

00:40:47: Und sagen wir mal, ich habe einen Produktionsprozess, wo ich die Produktionszeit verkürzen will, durch eine bessere Anlagensteuerung, wie auch immer.

00:40:57: Dann kann ich ja wirklich sagen, okay, jeder Produktionslauf wird zehn Prozent schneller, das schafft mir eine gewisse Kapazitätserhöhung.

00:41:07: Und diese zusätzliche Kapazität im Jahr, die hat einen Wert, wo ich quasi ohne sonstiges Invest einfach mehr produzieren kann.

00:41:15: Das kann ich verkaufen, dann habe ich Geld verdient.

00:41:17: Wenn ich eine optimierte Produktionsplanung habe und dabei die Person, die die Planung macht, Entlastung, die hat mehr Zeit, andere Dinge zu machen,

00:41:27: dann spare ich schon mal deren Zeit ein, die sie irgendwo anders werthaltiger einbringen kann.

00:41:32: Und vielleicht kann ich auch so Dinge wie stillstände, unnötige Rüstzeiten, all solche Dinge, die kann ich verringern.

00:41:38: Und wenn ich da eine Abschätzung treffen kann, was halten wir für realistisch.

00:41:43: Vielleicht auch erste Tests mal mache, was für Optimierungspotenziale gibt es da.

00:41:48: Dann kann ich da wirklich einen Zahlenwert, mir als Ziel definieren, wo ich hinkommen will.

00:41:55: Und der macht es natürlich deutlich leichter, das Projekt voranzubringen.

00:41:59: Wo ich gemerkt, das ist dann am Anfang, das ist der Plan.

00:42:03: Und wer mir auch gesagt, man kommt nicht immer genau dann, manchmal ist man viel besser.

00:42:07: Manchmal findet man einen ganz anderen Wert.

00:42:10: Auf dem Weg, das eine zu verbessern, schafft man es, etwas anderes zu verbessern.

00:42:15: Während man mit den Daten arbeitet, so ehrlich muss man sein, dass es jetzt nicht eins zu eins so, dass man das umsetzt.

00:42:20: Für mich klingt das, was ihr immer erarbeitet, immer so eine Art, wie so einzelne Microservices.

00:42:26: So, das ist halt das tolle, also ich sag mal, du kannst in deinem Alltag relativ kuhle und leicht zu erklären,

00:42:33: der Produkte bauen oder was heißt leicht zu erklären.

00:42:35: Es ist halt klar, was sie machen und wobei sie helfen.

00:42:38: Und wenn ich jetzt meine Arbeit dagegen überstelle, wo ich halt irgendwie eine Plattform aufbauer

00:42:43: und ETL-Strecken aufbauer, ist der Wert, den ich bringe, eben ich sag mal, der ist schon vorhanden,

00:42:48: aber der ist wesentlich abstrakter, der ist wesentlich, ja, ich sag mal, sehr hypothetisch.

00:42:53: Ja, wir könnten vielleicht sagen da, wo wir uns, das, was so ein bisschen die Brücke ist,

00:42:59: also wenn wir sagen, auf der einen Seite ganz konkret das Machine Learning-Modell,

00:43:03: was eine Zeit optimiert oder bla bla bla, okay, das ist sehr konkret.

00:43:09: Auf der anderen Seite die Plattform, die mir die Möglichkeit gibt, irgendwann so ein Modell zu bauen.

00:43:14: Vielleicht hat man in der Mitte, also wer jetzt mal so eine These im Gespräch von mir, Analytics,

00:43:19: sowas wie ich, ich baue erstmal ein Dashboard,

00:43:24: wir haben zum Beispiel so Projekte, mit denen ich erstmal überhaupt in der Lage bin,

00:43:28: meine Prozesse transparent aufzuschlüsseln, so an welcher Stelle entstehen eigentlich Kosten,

00:43:35: an welcher Stelle habe ich vielleicht einen Problem im Einkaufen,

00:43:41: Problem in der Fertigung, wie auch immer, einfach erstmal nur in einer Darstellung,

00:43:46: da habe ich noch nicht so eine ganz konkrete Handlungsanweisung, mache dieses oder jenes anders Stelle,

00:43:52: den Wert anders ein oder bla bla bla, aber ich habe eine Gesichtbarkeit erstmal.

00:43:58: Und das ist vielleicht so der Mittelpunkt und das ist ja auch das, was du dann erstmal ermöglichen musst.

00:44:04: Also, weil sagen wir mal, ich habe das Projekt mit dir noch nicht gemacht

00:44:09: und ich habe meine SAP-Daten, die lieben in SAP, ich habe meine CRM-Daten,

00:44:15: ich habe meine Fabrikationsdaten, wie läuft es denn das Geschäft?

00:44:20: Ja klar, und die müssen irgendwie zusammengebracht werden.

00:44:23: Genau, und da muss man sich ja die Frage stellen, wie wohl fühlt man sich in diesem blinden Flug?

00:44:27: Nee, absolut, ich will jetzt auch nicht, ich will nicht die Wertigkeiten miteinander vergleichen,

00:44:33: darauf soll es nicht hinauslaufen, sondern einfach, ich sage mal, die Wahrnehmung und Erklärbarkeit.

00:44:38: Weil ich meine, es ist ja schön zu sagen, wenn wir Projekt XY umsetzen,

00:44:44: dann steigern wir die Effizienz unserer Anlagen, meinetwegen.

00:44:49: Wenn jetzt ein Data-Engineer hergeht und sagt, ich liefe euch jetzt die Daten,

00:44:54: dann bringe ich andere Leute halt an die Arbeit, weil das ist einfach eine andere Art von Aussage.

00:44:59: Also andere Leute an die Arbeit bringen, man schafft quasi die Grundlage zur Wertschöpfung erstmal.

00:45:04: Ich bin heute ein kleines Metaphern-Monster, aber ich sage mal, Winter,

00:45:08: du gehst rüber zu deinem Auto, die Scheibe ist gefroren.

00:45:12: Du kannst einfach losfahren, wenn du der mutige Typ bist, oder du stellst dich hin und du kratzt,

00:45:18: und in dem Moment, wo du kratzt, bist du noch kein Meter vorwärts gekommen, du hast noch kein Meter Gewinn gemacht.

00:45:23: Aber kratzen kann echt viel Sinn machen, so vor dem Losfahren.

00:45:29: Und das ist ein bisschen deine Arbeit. Also so würde ich es vielleicht verkaufen.

00:45:34: Möchtest du sehen, wo du hinfährst?

00:45:37: Ja, weiß ich nicht. Kann man mit Sicherheit so sehen.

00:45:42: Ich sehe es immer noch so ein bisschen als Basis bauen, Backbauen und Grundlagen schaffen.

00:45:48: Ich würde sagen, die Leute, die kratzen sich nur so ein kleines bisschen frei.

00:45:52: Wo du wirklich fahren kannst, dann guckst du so ein bisschen, und dann kannst du ja schon Tempo 30 zum Büro reichen.

00:45:58: Das ist ja letztlich nicht das iterative Arbeit. Man fängt klein an und arbeitet sich dann auf das Große hinaus,

00:46:04: aber das Kratzen, das ist schon sinnvoll, um zur Arbeit zu kommen, will ich behaupten.

00:46:08: Mir ist unterwegs auch noch eine Idee gekommen, beziehungsweise eine Überlegung, das ganze Thema LLM.

00:46:13: Ich glaube, da bewegen wir uns jetzt langsam wieder aufeinander zu.

00:46:16: Weil ich sage mal, diese ganzen Chat-Clines sind ja letztlich nur eine rein, ich sage mal,

00:46:22: hypothetische Effizienzsteigerung der Belegschaft.

00:46:25: Und momentan will ja jeder irgendwie ein Chat-Client haben, weil jeder die Hoffnung hat,

00:46:29: dass wir dadurch effizienter werden, Sachen leichter finden, weniger Fehler machen, wie auch immer.

00:46:34: Wenn es hinterher gemessen wird, umso besser.

00:46:37: Aber auch hier würde ich sagen, hier bewegt sich endlich mal wieder Data Science oder Machine Learning auf Data Engineering zu.

00:46:44: Und es werden hypothetische Werte geschaffen, die eben, wie gesagt, genauso wertig sind wie alles andere,

00:46:51: aber deren Wert unter Umständen nicht ganz leicht zu erklären ist.

00:46:55: Ja, also in der Gesamtheit auf jeden Fall schwer, aber es ist ganz spannend, weil du das sagst.

00:47:01: Ich habe neulich drüber nachgedacht, wie oft ich eigentlich in den letzten 6 Monaten meine eigene Arbeitsweise umgestellt habe.

00:47:09: Und das ist erschreckend oft.

00:47:11: Also so von wegen, man hat mal was gelernt und dann zieht man das durch bis zur Rente.

00:47:16: Das ist halt so gar nicht der Fall, sondern wenn es eine sinnvolle Co-Pilot Integration in VS Code gibt,

00:47:24: dann spart ihr das barere Minuten bei jeder möglichen Tätigkeit, wenn du sie auch benutzt.

00:47:31: Also wenn du dir dann noch die Zeit nimmst, wirklich selber 200 Spalten der SQL-Tabelle hinzuschreiben und auf Englisch zu übersetzen.

00:47:42: Oder ob du den Inline Chat nimmst und sagt, übersetzt dir auf Englisch, das ist halt ein Unterschied von ein paar Minuten.

00:47:48: Das ist eine totale Kleinigkeit, aber das an ganz vielen Stellen.

00:47:52: Genau, aber es ist natürlich in der Gesamtheit nicht messbar.

00:47:55: Wie viel spart mir das jetzt ein, dass ich Co-Pilot nutze, wie viel effizienter bin ich dadurch?

00:48:02: Ich weiß ehrlich gesagt nicht, es gibt dir immer diese Reportedenwerte, ich weiß nicht, wie die gemessen werden.

00:48:06: Ja, ich weiß auch nicht, wer sie schreibt.

00:48:08: Also, man muss ja immer überlegen, was davon Marketing ist, was davon echt ist.

00:48:16: Also ich glaube, ehrlich gesagt, an einer Effizienzsteigerung, aber ich habe sie bei mir auch noch nicht gemessen.

00:48:21: Ich weiß nicht, ob ich heute schneller programmiere als noch vor zwei Jahren.

00:48:25: Schreibst du Unitests noch selber?

00:48:27: Ja, größtenteils.

00:48:29: Das überrascht mich jetzt.

00:48:31: Das, was ich oft mache, ist, ich frage einen Chat-Cline, welche Tests ich schreiben könnte oder was für Tests.

00:48:40: Es kommt halt auch immer die Frage oder es kommt immer darauf an, was die Grundlage für einen Unitest ist.

00:48:47: Manchmal brauchst du eben viele Fix-Chests, also viele feste Datensätze, in bestimmter Art und Weise vorbereitet.

00:48:54: Und da sind die Chat-Clines nicht alle gleich gut drin, dass dir die richtigen Daten in den Unitests einschubst.

00:49:00: Schreibst du Doc-Strings noch selber?

00:49:02: Na, ich mache meistens, mache ich ein Enter zwischen Funktionsdefinition und Coder drunter und schaue erstmal, was Co-Pilot mir davor schlägt.

00:49:15: Das ist auch mein Weg.

00:49:16: Dann drücke ich einmal auf Tab und schaue, wie zufrieden ich damit bin.

00:49:19: Was mich manchmal ein bisschen nervt, ist, dass Co-Pilot bei mir zumindest häufig in den Doc-String-Konventionen hin und her springt.

00:49:27: Also ich mag sehr gerne NumPy-Docs, das ist jetzt vielleicht ein bisschen Nerd-Hawk, aber gut.

00:49:31: Und Co-Pilot nutzt intuitiv sehr gerne Google-Docs.

00:49:35: Und dann habe ich häufig verschiedene Konventionen vorgeschlagen, auf Anhieb das nervt mich ein bisschen.

00:49:40: Aber da bin ich ehrlich, ich weiß nicht, und das ist auch ein Spruch, den ich in letzter Zeit häufig sage,

00:49:45: inwiefern das Problem nicht vor dem Bildschirm sitzt.

00:49:48: Also ich will nicht ausschließen, dass es schlichtweg an mir liegt, dass das da nicht immer gleich gut funktioniert.

00:49:54: Ja, spannend, okay.

00:49:56: Nee, ich hatte auch letztens mit Tim die spannende Frage, ob Vibe-Coding im Bereich Data Science richtig funktionieren kann.

00:50:04: Machst du schon Vibe-Coding im Bereich Data Science?

00:50:07: Sehr, sehr limitiert, und zwar in Form von Demos.

00:50:12: Also wenn ich einfach in einem initialen Gespräch mal eine Vorstellung davon haben will,

00:50:21: was könnten wir bauen wollen, wie könnte das aussehen?

00:50:25: Und im Endeffekt, also früher habe ich für sowas irgendwie Excalidraw, Myrow, wie auch immer genommen,

00:50:31: und habe halt gemalt. Also ich habe einfach gemalt, wie könnte ein Frontend aussehen, wie könnte irgendwas sein.

00:50:37: Und wenn ich jetzt aber mit Vibe-Coding sagen kann, ja, erstellen wir mal einfach so ein Frontend.

00:50:43: Und ich kann es ja dann schon benutzen, ich kann drin rumklicken, und dann kann ich da mir auch schon Feedback einholen.

00:50:48: Das ist natürlich schöner, als wenn ich ein Bild habe.

00:50:51: Aber das war es dann auch, den Rest selber bauen.

00:50:55: Ja gut, es ist dann aber auch so ein bisschen der Tatsache geschuldet, dass du mit Streamlet arbeitest.

00:50:59: Also die Frage ist, wie gut kann man Vibe-Coding in Power BI, wenn das jetzt eine Dashboard-Lösung ist?

00:51:06: Nein, da hatte ich letztens mal mit Tim drüber gesprochen.

00:51:10: Ich weiß ehrlich gesagt gar nicht mehr so genau, was da seine Antwort war,

00:51:14: und ich will ihm die auch nicht in den Mund legen, falsche in den Mund legen.

00:51:17: Ich selbst mache auch sehr wenig Vibe-Coding, muss ich gestehen.

00:51:20: Ich habe mir aber sagen lassen, dass es gerade für meinen Bereich überraschend gut funktioniert.

00:51:23: Also da gibt es ja mittlerweile auch wie es Code-ähnliche Editor, und ich vergesse mal die Namen,

00:51:29: mit denen man dann quasi nur noch eine Prompt reinhaut, und die schreiben dir den Code dann komplett und integrieren den dann auch sofort.

00:51:35: Also du musst dann nicht mal mehr zwischen ChatGBT hin und her kopieren,

00:51:40: oder meinetwegen das Chat-Fenster von Co-Pilot nutzen.

00:51:46: Also da gibt es mittlerweile ganz coole Lösungen, die wohl auch relativ gut funktionieren, wenn sie dich einmal verstanden haben.

00:51:52: Wobei ich zugeben muss, unser Co-Pilot Agent-Mode hat mich noch nicht so abgeholt.

00:51:57: Den habe ich jetzt ausprobiert. Letzte Woche sollte mir eine Streamlit App mit Multi-Pages umschreiben.

00:52:10: Aber vielleicht auch da wieder. Vielleicht lag das Problem vor dem Bildschirm. Ich möchte dich nicht ausschließen an der Stelle.

00:52:16: Ja genau. Und ich finde Streamlit ist manchmal auch ein bisschen eigenwillig in den Patterns.

00:52:21: Also ich habe an der Stelle tatsächlich, muss ich sagen, ich habe neulich mit Rapid eine kleine Demo-App gebaut,

00:52:27: und ich war schon sehr beeindruckt. Also die hatte genau die Funktionalitäten alle so, wie ich sie mir vorgestellt habe.

00:52:36: Ich konnte sie benutzen und das reicht mir an der Stelle. Ich will ja nur etwas haben, was jemand ausprobieren kann,

00:52:41: und wo er mir sagt, wie er es anders haben will. Und danach bauen wir es sowieso noch, damit wir auch verstehen,

00:52:47: was da passiert und damit wir darüber nachdenken. Ich glaube, das ist immer gefährlich, wenn du etwas geliefert bekommst.

00:52:53: Kleiner, kleiner Flashback zu meiner Uni-Zeit. Wenn du für irgendeinen Physik-Zettel schon die Lösungen hattest,

00:52:59: und du hast die abgeschrieben, das waren die Aufgaben, die hast du in der Klausur falsch gemacht.

00:53:04: Weil wenn du nicht einmal selber das Problem hattest, wenn du es nicht wirklich verstanden hast,

00:53:08: dann kannst du ab da nicht weiter denken, dann bist du da quasi abgeschnitten an der Stelle.

00:53:11: Und ich glaube, das ist für mich die ganz große Gefahr. Das Ding wird immer größer, man ist sehr früh irgendwo abgeschnitten worden.

00:53:18: Und an der Stelle, wo dann dein Assistent an seine Grenzen kommt, da bist du schon lange hilflos.

00:53:24: Und deswegen bin ich da dafür, dass das bauen wir selber, das verstehen wir selber, dass wir unsere Erfahrungen einfließen.

00:53:30: Aber die initiale Idee, wenn ich da schneller sein kann, anstatt dass ich eine Demo die WE wegwerfen,

00:53:35: selber zwei Tage lang bauen, dass ich die noch in 15 Minuten erstellen kann.

00:53:39: Die Meinung, die teile ich. Aber ich muss auch sagen, in dem Moment, wenn man über Vibe-Coding anfängt zu reden,

00:53:45: ist der Podcast eigentlich auch vorbei. Also ich finde, das ist immer ein sehr schönes Ende.

00:53:50: Ich meine, das ist ja etwas, da reden momentan jeder darüber.

00:53:53: Ich finde, wir haben an der Stelle genug darüber gesprochen.

00:53:55: Ich finde es ein sehr interessanten Bereich für Data Science insbesondere.

00:54:00: Ich bin gespannt, wie sich das dahin noch entwickelt. Aber das muss nicht Teil dieses Podcasts sein.

00:54:05: Ich danke dir sehr, sehr herzlich für deine Zeit. Und sag mal, bis zum nächsten Mal.

00:54:10: Gerne.

00:54:11: In 10 Minuten, ne?

00:54:12: Ja, 3er Eigentrag schaffe ich nicht.

00:54:15: Nee, sehr gut. Tschau.