Transkript: Data Science

Hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast.

Heute Episode 67.

Wir reden über Data Science.

Hallo, hallo, hallo Dominik und herzlich willkommen.

Hi Mira.

Mira, hallo.

Schön, dass du da bist.

Normalerweise fangen wir immer mit News an, da hat er auch gesagt, haben wir heute gar nicht so viele und die letzten sind doch gar nicht so lange her.

Wir reden über Data Science.

Wir wollten, glaube ich, nochmal ganz von vorne anfangen, weil wir noch nicht so viele Data Science Folgen hatten oder uns vorgenommen hatten, noch einige mehr davon aufzunehmen, als wir bis jetzt haben.

Und mit Python macht man ja recht viel Data Science.

Vielleicht erzählst aber erstmal was über dich und stell dich kurz vor und dann sprechen wir das Thema.

Ja, gerne.

Also praktischerweise bin ich Data Scientist.

Das heißt, wir haben heute bestimmt eine Menge zu besprechen.

Ich bin auch seit einem Jahr Geschäftsführerin zusammen mit einem Kollegen in unserer Beratung.

Ich habe dort angefangen direkt nach dem Studium, bin da seit einigen Jahren und inzwischen bin ich dann mit an die Spitze gerückt.

Ursprünglich habe ich aber Psychologie studiert und so richtig weg davon bin ich auch gar nicht.

Ich muss auch sagen, dass man in der Psychologie schon auch viel Datenanalyse und Statistik macht.

Und da hat es mir auch noch nicht gereicht.

Deswegen habe ich dann noch einen Statistikmeister drangehängt und bin dann so in der Statistikberatung damals gelandet.

Da hieß es noch mehr Statistik.

Inzwischen würden wir natürlich sagen, wir machen Data Science oder aktuell sagt man wahrscheinlich am besten noch AI, damit halt auch wirklich klar ist, was eigentlich gemeint ist.

So ändern sich die Begriffe ein bisschen und ist natürlich über die Zeit auch total viel dazugekommen.

Machine Learning, was ja vor einigen Jahren eben noch nicht so da war.

Vor einigen Jahren haben wir noch ganz viel mit R gemacht.

Am Anfang, inzwischen ist eigentlich fast alles in Python, bis auch so ein paar einzelne Projekte, vor allem im Forschungsbereich, da sind die Leute noch ein bisschen mehr mit R unterwegs.

Und ja, ich kann gerne noch ganz kurz was über mein Unternehmen sagen.

Wir sind eine Data Science Beratung, haben also sehr viele wechselnde Projekte, sind 17 Leute, sind in Berlin.

Das heißt, zum Hörertreffen wird es dann wahrscheinlich auch nichts für mich, weil es ein bisschen zu weit ist, um mal kurz vorbeizukommen.

Und die Deutsche Bahn hatte ich letztes

Wochenende wieder von Berlin hierher.

Das war wieder hervorragend.

Ja, sollte man sich einfach ein paar gute Podcasts vorher mitnehmen und dann.

Ja, wir haben ja noch ein paar Episoden.

Vielleicht habt ihr noch nicht alle gehört.

Ja, da kann man dann schon noch ein bisschen länger Bahn fahren.

Ja, und aktuell bin ich witzigerweise, also ich habe erst viel Data Science gemacht, bin dann immer mehr auf in die Projektleitung gegangen und da passt es dann ja auch wieder mit der Psychologie.

Und jetzt bin ich aber witzigerweise so ein bisschen back to the roots, bin im Kundenprojekt drin, so bodyleasing-mäßig dort mit im Team und bin dort classic as Data Scientist im Team drin und das macht mir auch ganz groß.

Wir haben teilweise länger laufende Projekte, aber auch manchmal Einzelprojekte, die nur ein paar Monate sind, and it's natürlich auch total spannend, weil man dann sehr viel Abwechslung hat anders in verschiedene Themen reinkommt.

And we have a podcast, that is der Grund, warum ich jetzt hier sitze and you kennt.

Ein Unternehmens-Podcast, in dem ich manchmal, aber auch noch nicht immer zu hören bin, wo wir ganz viele Themen rund um Data Science besprechen, den Data Science Deep Dive.

Genau, das habe ich sehr später.

Ja, habe ich auch schon reingehört, fand ich sehr gut.

Ja.

Gut.

Also, was ist denn eigentlich Data Science?

Ja, also ganz gesprochen ausgedrückt, wir wollen Erkenntnisse aus Daten gewinnen.

Das ist jetzt auch irgendwie ziemlich allgemein, aber es geht darum, dass man Dinge versteht, dass man auch Dinge vor leer sagt und dass man teilweise sogar Entscheidungen dann trifft, entweder noch manuell oder sogar automatisiert auf Basis von Daten.

Oder anders gesagt, man will halt aus großen und oft komplexen Datensätzen Muster erkennen, die man jetzt mit bloßem Auge überhaupt nicht erkennen könnte und nur erkennt, wenn man eine Analyse macht.

Also tatsächlich Statistik im weiteren Sinne, wie man das halt dann in

der Psychologie oder Gehonometrie oder so.

Auf jeden Fall, ja, ein Teil ist ja auch so, manche sagen, ja, Statistik oder Machine Learning überschneidet sich auch an ganz vielen Stellen.

Ja, klar.

Man sagt ja oft, man braucht so drei Bereiche.

Das eine ist die fachliche Expertise.

Also ich kenne mich zum Beispiel aus mit dem Bereich, in dem ich gerade was mache, zum Beispiel Umweltdaten oder Verkaufsdaten, Online-Shopping, was auch immer.

Das zweite sind methodische Kenntnisse.

Da sind wir halt bei dem Thema Statistik, Machine Learning, haben Leute natürlich auch unterschiedliche Schwerpunkte.

Manche sind mehr mit Bilddaten unterwegs, mit Text, mit tabularen Daten, da bin ich vor allem unterwegs.

Und das dritte ist, dass man natürlich auch Coding-Kenntnisse braucht.

Also so das, was aus der Informatik kommt, damit man seine Analysen irgendwie programmieren kann.

Es ist natürlich irgendwie auch fast zu viel verlangt, das alles gleichzeitig zu können.

Also dass ich super gut coden kann, dass ich auch noch super gut in Statistiken und Maschinen bin und dann gleichzeitig noch in dem Fachbereich so lange unterwegs bin, dass ich mich da wahnsinnig gut auskenne.

Ist ja doch ziemlich viel.

Das schafft man vielleicht nach ein paar Jahren.

Aber deswegen sind wir auch meistens in Teams unterwegs oder wir als Beratung, wir sind natürlich daran gewöhnt, dass wir uns schnell neue Themen reinfinden.

Trotzdem brauchen wir in einem neuen Projekt natürlich ganz viel Kommunikation mit unseren KundInnen, die uns auch ihre Fachexpertise dann mitgeben, weil wir dann vor allem die methodischen Kenntnisse und das Coding mitbringen.

Das finde ich auch immer am schwierigsten, mit Kunden, also die Domain-Knowledge dann zu haben oder jemanden zu haben, mit den man darüber reden kann, mal in so eine Sprache zu finden.

Genau.

Das ist schwierig.

Auf dem Level, dass man halt versteht, was man gegenseitig voneinander will oder was man bereitstellen kann oder wie lange das dauert und Sachen, die man auf der einen Seite für einfach hält und auf der anderen Seite vielleicht ein bisschen schwieriger.

Aber ihr seid dann auch meistens tatsächlich, du hast es eben schon angesprochen, Bodyleasing, also quasi in den Teams selber unterwegs und unterschiedlich.

Achso, oder ihr setzt auch Projekte komplett um für Kunden als Team sozusagen und gebt dann ein Produkt an den Kunden oder so.

Ja, das gibt es auch.

Ja, sehr, sehr unterschiedlich.

Also wir sind für einen langjährigen Kunden sind wir eigentlich fast so wie eine zweite Data Science-Abteilung.

Die haben auch selbst eine Data Science Abteilung, aber die Aufgaben ist da so halt verteilt.

Und da machen wir auch den kompletten Betrieb und die Wartung mit.

Also wir machen nicht nur die reine Data Science, sondern auch alles, was im DevOps-Bereich anfällt.

Ich bin aber mehr im Data Science-Bereich unterwegs.

Und wir haben eben ja auch zunehmend das Thema Bodyleasing.

Das war früher irgendwie kaum, weil früher hatten viele Unternehmen auch selbst keine Data Science Abteilung.

Und da gab es eine Zeit, da waren die halt alle irgendwie ganz verzweifelt und waren dann total froh, dass das jemand für sie macht.

Und inzwischen ist es eher so, dass die Unternehmen, die groß sind und die überhaupt von der Kultur her in Richtung datenbasiertes Unternehmen gehen, die haben jetzt eine Data Science Abteilung, aber die haben dann halt hier und da mal Lücken und finden niemanden und nehmen uns dann dann dazu.

Wenn du jetzt Methoden angesprochen hast, was würdest du denn sagen, wie ist das denn in der Praxis?

Habt ihr da viel mit sophisticated Methoden noch zu tun, die ihr jetzt aus der Uni oder so noch kennt?

Oder ist das meistens dann schon einfache Zeugs, weil einfach die Datenprobleme andere sind, als jetzt gute Methoden auszusuchen?

Es ist tatsächlich oft ziemlich anspruchsvoll.

Ich glaube, das sind aber auch so die Projekte, die wir uns rauspicken oder für die wir dann auch weiterempfohlen werden.

Wir haben zum Beispiel was im Sportwettenbereich und da kann man sich ja vorstellen, wenn man mal überlegt, wie sage ich eigentlich vorher, wie viele Tore von diesen beiden Mannschaften in dem Spiel fallen und wie viel in der ersten und zweiten Halbzeit und so.

Es wird schon ganz schön kompliziert und da haben dann die Leute mit Statistikhintergrund auch ganz viel Spaß.

Manchmal sind die Sachen halt noch ein bisschen simpler, aber oft wird es dann doch irgendwie schon ein bisschen komplexer.

Wir sind aber auch tatsächlich darauf spezialisiert.

Also es gibt ja auch ganz viele Sachen, wo vielleicht auch erstmal eine gute Visualisierung ausreicht.

Visualisierung machen wir natürlich auch mit, aber ein Projekt, wo es nur um Dashboard mit Visualisierung geht, landet seltener bei uns.

Ja, wie kommt man denn eigentlich zur Data Science?

Du hast gesagt, du hast Psychologie studiert und dann fandst du Statistik spannend.

Ich habe vorher geschaftslehre studiert und da fand ich auch Statistik eigentlich spannend.

Es hat bei mir noch ein bisschen Umweg gebraucht, aber ich glaube, auch da hätte man direkt den Weg Richtung Data Science finden können.

Ja, auf jeden Fall.

Also das ist auch so ein typischer Hintergrund.

Ich habe ja in dem Statistikmaster war ich ja, da waren viele, die vorhin Mathe gemacht haben, aber auch viele mit ganz anderen Hintergründen, viel Wirtschaftswissenschaften.

Ich habe auch KollegInnen mit Soziologie-Hintergrund oder Physik.

Ich glaube, das ist sogar so ein bisschen Klassiker, dass die Physiker sich irgendwie dann in die Statistik und Machine Learning Welt verirren.

Und wir haben noch gar nicht so lange auch jemanden mit Informatik-Hintergrund.

Das klingt irgendwie witzig.

Nur Leute, also die ist jetzt schon, ich glaube schon drei Jahre bei uns, aber ja, vorher hat man nur Leute mit einem anderen Hintergrund.

Ich glaube, es ist aber ein bisschen schwieriger geworden, quer einzusteigen, weil es inzwischen ja sehr viele tatsächlich Data Science-Studien-Dinge gibt oder Informatik mit ganz starkem Machine Learning-Schwerpunkt.

Und wenn man dann sagt, ja, ich habe da, also ich habe BWL studiert und ich finde Statistik gut und habe ein paar Kurse gemacht, dann konkurriert man halt inzwischen mit Leuten, die da leider dann schon viel, viel mehr mitbringen.

Also ich glaube, das ist schon schwieriger geworden.

Der BWL ist ja auch nicht VWL zum Beispiel, ja.

Ja, ich weiß.

Aber es ist ja auch ein Fach, wo man ja doch, je nachdem, wie man sich da orientiert, viel Statistik machen kann.

Ja, also Ökonometrie kann

man schon tief reingehen, glaube ich da.

Es ist halt die Frage,

wie gut man dann in das Programmieren reinkommt und in das, was man da an Methoden noch so mitbringt.

Ja, aber das ist auf jeden Fall eine interessante Geschichte.

Das habe ich auf jeden Fall, also jedenfalls in den Data Science-Projekten, in denen ich so unterwegs war, halt auch irgendwie immer wieder gesehen, dass halt oft die Leute, also ich weiß nicht, wie das bei euch ist, ob ihr, weil normalerweise Softwareentwicklungsgeschichten, die ich so mache, da habe ich dann halt eben mit Abteilungen zu tun, die halt irgendwie Softwareentwicklung machen oder so, aber bei den Data Science-Geschichten ist es immer sowas wie Business Intelligence oder so.

Und das sind andere Leute, das sind ein bisschen so, die sind so ähnlich, also das sind oft irgendwie Leute, die was Naturwissenschaftliches studiert haben oder so, dann da promoviert haben.

Genau, ganz oft aus der Ecke eher.

Und die eher so, ja, ja, Analysten-Dinge tun, oft viel SQL schreiben und so.

Und das ist irgendwie ein bisschen anders als bei den Softwareentwicklern und die haben auch meistens oft so ein bisschen so, ja, Produkte entwickeln oder so, ist jetzt eigentlich nicht so unser Ding.

Genau.

Und das ist irgendwie eine etwas andere Welt.

Also da gibt es oft eine Trennung zwischen Softwareentwicklung und in diesem ganzen.

Da wolltest du ja auch nochmal was zu sagen, wie du das so findest, mit so Softwareentwicklern zusammenzuarbeiten.

Aber vielleicht nur erst natürlich, ich glaube, wir sind da irgendwie so dazwischen, weil wir eben ja schon Datenprodukte bauen wollen.

Also es gibt auch mal ein POC oder irgendwie so eine einzelne Analyse, wo wir dann sagen, so und das sind die Ergebnisse und hier sind die Zusammenhänge, aber normalerweise sind das dann schon, also schreiben wir auch Software, aber wir schreiben Software, die was mit Daten macht.

Also ist ja eigentlich dann zwei Sachen zusammen.

Und BI-Abteilungen sind, glaube ich, auch nochmal mehr, ja, die sind halt besonders gut darin, dann auch ganz viel visuell zu analysieren und fokussieren sich sehr stark darauf.

Und ich glaube, die sind auch nochmal so ein

bisschen, vielleicht

noch ein bisschen weniger nerdig, hätte ich jetzt so gedacht.

So Mitte.

Das klingt, als wäre es kein Kompliment.

Ich weiß nicht, je nachdem, ne?

Ja.

Ja, aber was du eben gefragt hättest, so, das ist auch jetzt ganz spannend.

Ich bin jetzt im Team, wo eigentlich relativ klar zugeordnet ist, wer ist Data Scientist und wer ist Software-Engineer.

Und natürlich arbeiten wir alle an dem Code, aber es gibt irgendwie so ein paar Klischees oder so Dinge, die man vielleicht beobachtet, wenn jemand, der vor allem einen Software-Entwicklungshintergrund hat, jetzt zum ersten Mal versucht, Daten zu analysieren und Data Science zu machen.

Wir haben auch mal ein Projekt übernommen, wo wir entsprechenden Code dann, tatsächlich sollte man ja refactoren und wir haben auch viel Refactored, aber da haben wir einen Teil wirklich neu geschrieben, weil das

erste Mal.

Und am Coding-Stil hat man schon gesehen, dass der einfach gar nicht wusste, dass man mit Datensätzen Sachen machen kann.

Der hat halt immer ganz viel geloopt über Zeilen und Spalten und so, weil er halt einfach diese ganzen Sachen nicht kannte, die man mit Datensätzen machen kann, vor allem mit Pandas.

Und was sonst auch, wenn man zusammenarbeitet, halt oft passiert, is that jemand who not feel with data had the error so nimmt wie they are, and that's uncritical is and got when ironic comes out.

And manchmal is the code garnished falsch, but there's a denkfehler drin.

The code macht, what they'll do, what they're viellect so correct.

Or man has a missverständnis with the data, man hat irgendeine annabe, but in wirklich is this and this is was, was dann glaube ich schwerfällt.

Also ich glaube, das fällt einem als Data Scientist auch schon manchmal schwer, so richtig dieses Business Understanding aufzubauen.

Aber ja, also wenn man so reine Softwareentwicklung macht, das glaube ich nochmal schwieriger, in den Daten drin zu sein und die zu interpretieren und sagen, Moment mal, also die Kurve sieht ja auch echt komisch aus.

Aber also eigentlich mag ich es total gerne, wenn das hingemischt ist, weil auch nicht alle Data Scientists so richtig auf guten Code achten.

Also es ist uns sehr wichtig und wenn jemand halt noch nicht so gut programmieren kann und aus dem Studium kommen, weil es einsteigt, dann ist es das, was die Person dann lernt, so wie ich damals.

Aber ich glaube, das ist auch nicht überall so verbreitet, weil manche haben dann eher einen Schwerpunkt auf so Datenanalysen, sind viele Notebooks unterwegs und wenn sie dann fertig sind, dann wird das Notebook in irgendeinen Job eingebunden und das ist dann die Automatisierung und das kann manchmal funktionieren, aber oft ist es auch ziemlich wackelig.

Ja, interessant.

Also da ist auf jeden Fall oft so ein bisschen ein Graben zwischen den Welten.

Also wenn ich das immer sehe, was so Data Scientists schreiben, dann steige ich mir die Hände beim Kopf.

Also ich habe es so gerade plakativ, es gibt natürlich Unterschiede.

Alles immer so im Vergleich eher anders, als ich das machen würde wahrscheinlich.

Also man schreibt als Data Science oft wohl die ganzen Prozesse untereinander und musste erstmal

lernen die Methoden

zu definieren und so, ja.

Und warum soll man denn, also wenn man das nur einmal macht, warum soll man dann eine Funktion schreiben?

Man kann es ja Zeile für Zeile ausführen und die Funktion braucht man ja nur, wenn man zweimal dasselbe macht.

So ist dann, glaube ich, manchmal die Denkweise, wenn man eben mehr aus der Analyse kommt und da so quer einsteigt.

Könnte das man einfach manchmal, weil Leute schon promoviert haben und das ist, die haben total krasse Sachen gemacht, aber können dann halt noch keinen guten Code schreiben, weil es für die Doktorarbeit eben ganz andere Anforderungen hat.

Ja, da ist auch oft, also gerade du sprachst eben, Physiker, die sind da ja oft eher so verdorben, die haben dann irgendwie Vortrag geschrieben oder sowas.

Oder C<unk>, ist aber auch nicht viel besser.

Und dann, ja genau, bringen sie da so schlechte Gewohnheiten mit.

Das ist natürlich oft irgendwie so ein bisschen, ja, aber ja, ja.

Aber das ist auch so ein bisschen, man lernt das ja auch irgendwo, außer wenn man jetzt irgendwie quasi bei einer Firma anfängt, die das halt auch irgendwie täglich macht oder so.

Bei den meisten Firmen gibt es ja da gar keine Kultur.

Und ja, also es ist irgendwie, ja, es ist irgendwie, also dieses Handwerkszeug ist ein Problem oft.

Das denke

ich auch.

Was nervt dich denn an Leuten, die Softwareentwicklung gemacht haben und jetzt Data Scientists sind?

Ja, das ist auch interessant, ja.

Also ja, also die Sachen, die ich gerade genannt habe, also es ist oft so, die Ergebnisse so unkritisch beurteilt werden, dass man eigentlich nur guckt, ob der Code richtig läuft und das macht, was man implementieren wollte.

Und dass eben, ja, man dann nicht unbedingt erkennt, dass die Ergebnisse eigentlich unplausibel sind.

Zum Beispiel, dass das Modell viel zu gut ist und da muss irgendwo was falsch sein.

Die Kirchturmspitze

ist 245 Meter im Minus.

Bitte?

Könnte es, dass wenn man die Kirchtumspitze ausrechnet,

dass die Höhe dann

245 im Minus ist?

Und wenn man das dann einfach so übernimmt und daran glaubt.

Ja, genau.

Also das ist ein gutes Beispiel.

Und manchmal habe ich auch den Eindruck, dass dann wiederum, wenn man sehr, sehr stolz auf seine Software-Entwicklungskills ist, dass dann auch unnötig komplizierte Patterns auf irgendwelche Sachen geworfen werden und es dann auch wieder durch pragmatisch ist und sehr schwer wartbar.

Ja, klar, weil die Leute, die das dann letztlich irgendwie ja benutzen müssen, müssen das ja auch lesen und verstehen können und so.

Und wenn man dann irgendwas im kleinen Vision helfen bei einem Turm baut, dann war das vielleicht auch einfach so.

Ja, das ist dann vorbei.

Wenn man auch neue Pattern gelernt hat, muss man die auch erstmal überall anwenden, ja.

Ja, klar, das natürlich auch immer.

Ja, aber grundsätzlich macht man das eigentlich total Spaß, mit Software-EntwicklerInnen zusammenzuarbeiten.

Du hast gesagt, er visualisiert irgendwie Sachen.

Zwar nicht so oft, nicht so gerne, aber er macht das.

Wie denn?

Also ich kenne irgendwie so eine coole Seite, die wollte ich irgendwie nochmal sind, so wie datatuwists.com oder sowas.

Die benutze ich immer, wenn ich

nicht weiß.

Aber die sagen sich so gerne.

Also es macht es nicht die ganze Zeit, aber es ist an verschiedenen Stellen eigentlich total wichtig.

Also zuerst mal, wenn man die Daten reinbekommt, damit sind wir jetzt eigentlich schon so mitten im typischen Ablauf, aber ich kann da, da wollen wir zwar noch drüber sprechen, da kann da gerne nochmal vorgreifen.

Also wenn die Daten reinkommen und man gucken will, ob die sinnvoll sind, wenn man die Daten kennenlernen will, Zusammenhänge prüfen und so, dann ist natürlich Visualisierung einfach das allerbeste Klass, auch ganz nett so Mittelwerte und Ausweis haben Minimum und so sich anzugucken.

Zum Beispiel, ob der kleinste Kirchturm auch wirklich größer als null Meter ist.

Aber es macht natürlich auch total Sinn, sich da die Verteilung mal zu plotten und Zusammenhänge.

Und das sind auch die Sachen, die wir dann oft mit unseren Kunden wiederum anschauen und sagen, guck mal hier, die Verteilung macht die Sinn.

Und merken dann vielleicht, dass da irgendwas in den Daten unsauber ist, was halt oft vorkommt, womit man dann aber irgendwie umgehen muss.

Und natürlich auch dann später, wenn wir zum Beispiel ein Modell gebaut haben und die Ergebnisse untersuchen wollen, wie sind unsere Prognosen verteilt, welche Zusammenhänge hat das Modell gefunden, auch da ist dann natürlich die Visualisierung total wichtig und sinnvoll.

Man kann es einfach viel, viel, viel schneller erfassen, als wenn man das irgendwie alles versucht, in Tabellen zu vermitteln.

Wie visualisiert ihr denn am liebsten?

Ja, es ist irgendwie ganz witzig, weil ich in Python noch nie so richtig ja gut so ein bisschen habe ich auch in Python, aber wir haben früher sehr viel, als auch da waren auch weniger mit Dashboards und so weiter, da war es auch noch zu, dass wir so einen Datendumpf bekommen haben und haben damit dann was gemacht und da waren wir noch in R unterwegs und haben viel ggplot 2 benutzt.

Und inzwischen sind wir dann meistens in einem Dashboard-System unterwegs, das halt beim Kunden einfach genutzt wird, sodass wir dann in dem Tool, was der benutzt, das implementieren, weil das jetzt in ABS oder Azure oder was auch immer die nutzen und wir machen dann da das, was da in dem System gewünscht ist.

Wir haben auch ein paar Dashboards mal gebaut in, wie heißt das denn jetzt noch?

Ich habe

den Namen.

Redash, genau, Redash ist ein Open Source Tool.

Das benutzen wir dann auch ganz gerne.

Da kann man dann auch gerade praktischerweise noch Alarme dazu definieren, um seine Daten zu überwachen.

Das benutzen wir auch sehr gerne.

Okay.

Und wie läuft denn so ein Prozess bei euch ab?

Ihr habt jetzt irgendwie die Daten, ich glaube, du wolltest da auch nochmal drauf eingehen.

Ja, das ist ja auch.

Und so einen

Auftrag und dann?

Also klar, manchmal schlagen wir auch mittendrin ein, aber ich fange jetzt trotzdem mal vorne an, oft sind wir auch vorne dabei.

Das ist jetzt vor allem aus meiner Sicht als Beraterin.

Das fühlt sich natürlich ein bisschen anders an, wenn man ihm unternehmen als Data Science die ganze Zeit ist.

Aber für mich als Beraterin sind das so, ja, eigentlich so sieben Schritte.

Erstmal das Problemverständnis, dann die Daten einzusammeln und zu verstehen, dann in Datenaufbereitung, dann kommt die Modellierung.

Man merkt, das ist nur ein Schritt, diese Modellierung.

Oft denkt man, das ist zu viel, aber es ist nur ein kleiner Schritt.

Dann die Evaluation des Modells und dann gehört eigentlich dazu ja auch noch eine Automatisierung und Monitoring und Wartung, wobei die letzten zwei Schritte natürlich vom Aufwand her nochmal einen sehr, sehr großen Teil einnehmen.

Das ist auch jetzt angelehnt an den CRISP-DM, wenn du das was sagt.

Das ist der Cross-Industry Standard Process for Data Mining.

Data Mining klingt so ein bisschen angestaubt der Briff, aber man könnte es halt einfach Datenprojekte nennen.

Und ja, am Anfang ist es bei uns dann tatsächlich oft so, dass KundInnen zu uns kommen und schon was haben, was sie also sagt schon das, was sie brauchen.

Das geht dann auch in die richtige Richtung.

Manchmal macht es aber trotzdem Sinn, sich das nochmal genauer anzuschauen und toch, why they this brauchen and what they really brauchen.

And vielleicht is it then does so a bit and I mean to this thing can manage workshops, mehr täggige workshops, and it's a need, they need to make as use cases to identify and to prüfen.

This can

we auch ein Stück weit mitmachen, aber das ist nicht unser Schwerpunkt.

Also it's meistens eher so that there should be ideas.

We are this challenge and a kick-off have, wounds mit densprechen, um das Geschäftsmodell zu verstehen, um genau zu verstehen, wer das eigentlich nutzen wird, was die genau machen wollen.

Das ist natürlich total wichtig, dass wir eben prüfen, was brauchen die wirklich genau.

Und brauchen die zum Beispiel vielleicht was in Echtzeit, dann ist es natürlich ganz anders, als wenn das ausreicht, dass man jeden Morgen einmal aktuelle Werte berechnet.

Und wer sitzt da und wo benutzen wir es genau?

Ist das irgendwo an einem Counter oder ist es am Telefon oder ist es irgendwo, wo es kein gutes Internet gibt und so und all das muss man natürlich wissen, um auch rauszufinden, was die brauchen.

Und dann ist der nächste Schritt, sich zu überlegen, wie können wir das machen und haben wir eigentlich auch die passenden Daten.

Und dann haben wir vielleicht die notwendigen Daten und ein paar andere Sachen sind vielleicht nicht ganz so notwendig.

Man kann trotzdem anfangen.

Ja, das ist der erste Schritt und den sollte man sich unterschätzen.

Besorgt ihr die dann auch?

Also baut ihr irgendwo neue Sensoren ein oder sowas und kümmere euch darum, dass ihr in irgendwelchen Datenbanken landen, die ihr dann zur Auswertung mit benutzt oder geht ihr davon

aus, dass das

das Business alles mit besorgt?

Es ist normalerweise so, dass die Daten schon da sind und dadurch, dass wir ja auch eher komplexe Fragestellungen beantworten, sind das in der Regel halt auch Kunden, die schon mit den Daten irgendwas gemacht haben.

Natürlich kennen die nicht jede Datenquelle von vorn bis hinten auswendig und man findet immer noch Überraschungen.

Aber das ist dann normalerweise nicht so, dass sie sagen, wir wollen hier dieses super komplexe Modell, aber wir haben noch gar keine Daten, wir müssen die erstmal sammeln.

Normalerweise sind die da schon relativ weit oben auf der Datenreife Skala.

Und selbst wenn nicht, sind die Daten meistens schon da, weil ganz viele Daten einfach automatisch mitgesammelt werden.

Zum Beispiel im Online-Shop hat man natürlich jede Menge Daten über vergangene Bestellungen und so weiter.

Also die Daten sind eigentlich immer schon da.

Die Frage ist nur, wie, also sind die Daten da, die man braucht und wenn sie nicht da sind, dann ist es erstmal noch ein weiter Weg normalerweise.

Vielleicht ist man nicht mal ein richtiges Data-Warehouse da oder man kann die noch nicht zusammenführen.

Das ist oft, dann ist es noch ein weiterer Weg, bis wir dann tatsächlich loslegen können.

Wie würdest du denn so ein neues Unternehmen strukturieren, wenn du darauf achten würdest, dass du ordentliche Daten irgendwann brauchst?

Würdest du direkt hingehen und das alles vom Scratch implementieren mit dem, was du am besten hältst, oder würdest du das erstmal egal, das wachsen lassen und dann irgendwie zusammenflanschen?

Also ich glaube, das kommt drauf an, wie sehr das Geschäftsmodell von Daten abhängt.

Also wenn das ein Unternehmen ist, das irgendwelche Gegenstände produziert, dann denke ich, ist es nicht ganz so wichtig, dass man ganz viele Daten sammelt.

Dann kann man sich erstmal darauf konzentrieren und danach und nach einsteigen.

Aber es gibt ja auch Geschäftsmodelle, die eigentlich nur so gut funktionieren, weil mit Daten gearbeitet wird und dann muss es wahrscheinlich von Anfang an auch berücksichtigen.

Also ich habe hier so nie Unternehmen gegründet, ich bin ja geschickt erst eingestiegen, als das Unternehmen schon da war.

Aber ich vermute, wenn man sowas wie Amazon oder so, da wurde ja von Anfang an wahrscheinlich mitgedacht, was man da mit Daten machen kann.

Oder zumindest relativ früh dann.

Und was für Technologie benutzt ihr so?

Mit Python für diese einzelnen Schritte?

Ja, also wir sind natürlich ganz viel mit Pandas unterwegs, von der Datenaufbereitung über die Modellierung.

Da kommt dann auch sowas wie Citekit Learn dazu oder TensorFlow, Keras, PyChops, ein zu die Klassiker.

Pandas ist ein interessantes Thema, weil Pandas, also wer schon mal mit Pandas und größeren Daten gearbeitet hat, denkt sich jetzt, um wir mitzwingen, ich will es nicht mehr hören, weil Pandas halt sehr, sehr viel Arbeitsspeicher braucht, wenn die Datensätze größer sind.

Es ist aber natürlich zu Prototypen oder generell für kleine Datensätze total super, weil es ganz, ganz viel kann und weil man auch ganz viel im Netz findet.

Also genau, wenn die Daten aber größer werden, dann hat man natürlich das Arbeitsspeicherproblem und dann ist der Klassiker natürlich auf Spark, Pi Spark umzusteigen.

Was auch jetzt in letzter Zeit ganz, also das ist natürlich dann richtig toll, weil es ganz verteilt ist.

Wobei es immer nicht unbedingt schnell ist, aber es kann halt eben mit großen Datensätzen umgehen und man halt erstmal dieses Arbeitsspeicherproblem gelöst, was man eben mit Pandas irgendwann eigentlich gar nicht mehr lösen kann.

Und dann gibt es jetzt natürlich noch seit.

Aber ich

meine, eine Erfahrung, die ich oft

mache, ist, dass man die, weil viele so kategoriale Variablen oder so, die kann man dann halt auf irgendwie ein kleineres, einen kleinen Datentyp irgendwie runterkomprimieren.

Oder halt oft hat man dann halt irgendwie für viele, oder wenn man jetzt nur Flex hat, irgendwie ja oder nein oder so, wenn man da nur ein Bit nimmt, ist halt sehr viel weniger, als wenn man da irgendwie ein volles Integer oder so für nimmt.

Ja, das ist hilft.

Oft hilft das dann schon.

Aber ja, stimmt.

Aber manchmal dann, wenn man die Daten einliest, dann je nachdem, kann man das, glaube ich, gar nicht unbedingt spezifizieren am Anfang und dann sind die echt so groß.

Oder auch selbst wenn, also ich meine, du hast irgendwie so mehrere Jahre stündliche Verkaufsdaten von ganz vielen Artikeln aus ganz vielen Filialen aus mehreren Ländern, dann wird es irgendwie schwierig und dann ist das Verteilte schon gut.

Und dann gibt es halt noch Polars, womit man dann auch oft schneller ist und halt auch weniger Arbeitsspeicher braucht.

Also wenn die sich nicht kennt, vorher ist das dann Rust nachgeschrieben, denkt gleich ein API, so ein bisschen wie Pandas.

Ja, es ist,

nö, es

hat eine sehr viel saubere, also kleinere, also es hat weniger Funktionen, aber es ist halt auch ein bisschen konsistenter, weil Pandas ist halt auch irgendwie sehr stark historisch gewachsen und man wusste noch nicht genau, wo man hin will und dann teilweise inkonsistent.

Und ja, ja, Pandas ist halt.

Wie das halt so ist.

Genau, wie

das halt

so ist.

Ich habe noch gar nicht so viel mit Polas gearbeitet.

Ich weiß gar nicht, ob die eigentlich schon das Ziel haben, da die meisten Funktionen aus Pandas aufzuimplementieren oder ob die vielleicht sogar sagen, es soll schlanker bleiben, weil es nicht mehr so gut ist.

Genau, nee, ich meine, also sie sind absichtlich, wollen sie nicht komplett irgendwie alles machen, was Pandas halt kann, sondern quasi bei den Basisgeschichten so schnell sein, dass man halt daraus alles bauen kann, aber dann halt nicht so eine Spezialsyntax dafür hat.

Benutzt ihr auch dann zwischendurch noch Pure NumPy?

Ja, immer mal so für kleine Sachen, wo es gerade Sinn macht.

Oft ist man mit Datensätzen unterwegs und dann passiert es halt meistens in Pandas.

Vielleicht, du hast eben gesagt, man muss erstmal wissen, was ein Datensatz ist, bevor man jetzt drüber redet.

Du meinst halt irgendwie, du hast eine Maske auf, mit der du guckst oder was ist ein Datensatz in Pandas?

Das ist jetzt eine Wissensfrage.

Ja, doch, so müssen wir vielleicht zum

Erklären, wie das funktioniert.

Ja, um die Daten anzugucken, würde

ich, na

gut, macht schon, es ist irgendwie schön, wenn man einmal so ein bisschen den Head anzeigt, also die ersten paar Zeilen und sieht, was da eigentlich so grundsätzlich, was das für Spalten sind, welche Namen die haben und welche Zahlen da so ungefähr drin stehen.

Und dann würde ich aber relativ schnell in eine deskriptive Analyse gehen und mir beispielsweise von jeder Spalte dann Summary-Statistics, also Minimum, Maximum, Mittelwert, Median, vielleicht Quantile anschauen oder eben auch Verteilungen plotten, sodass man das sieht oder Kategorien anzeigen, ja, was das so ist.

Sonst, ja, die ganze Tabelle, also man hat natürlich eine Tabelle als Pandas Data Frame, die könnte man theoretisch ja auch irgendwie als CSV speichern oder als Excel und da angucken.

Das ist auch ganz praktisch, um sich die mal anzugucken, wenn die Daten klein genug sind.

Manchmal ist es sogar wirklich ganz nett, um mal einfache Analysen zu machen zum Ausprobieren, um Gespür zu bekommen.

Aber es ist dann eher so ein manueller Schritt und um wirklich insights dann zu haben und die Daten zu verstehen, ja, muss man dann, wenn der Datensatz groß genug is, natürlich in die summary Statistics gehen.

Und das ist auch often, also selbst wenn man jetzt nach dieser ersten Datenanalyse aufhören würde, is it oft an sich schon ganz interessant.

Und oft have unsere KundInnen ja genau diese Analyse auch noch nicht gemacht und lernen dabei auch noch was Neues.

Einmal hatten wir aber sogar auch den Fall, dass

wir, ja,

dass sie dann gemerkt haben, dass da irgendwo ein Fehler im Data-Warehouse ist und da war irgendwie so ein riesiger Strukturbruch, der da eigentlich gar nicht sein sollte.

Und dann haben sie sich erstmal nochmal ein paar Monate zurückgezogen und haben das alles repariert und danach konnten wir das Projekt dann tatsächlich machen.

Aber das wussten sie vorher nicht und wir haben es dann gesehen durch unsere Datenvalidierung, dass da irgendwo ein Problem ist beim Zusammenführen.

Ja, spannend.

Also manchmal sagen sie mir jetzt, ich habe einmal den Fall gehabt, dann waren die ganze Zeit irgendwelche so Irregularitäten irgendwie in so einem Datenfond, die da gar nicht hingehörten.

Dann hat sich irgendetwas wundert, was ist denn das?

Und irgendwann ist jemand auf die Dinge gekommen, ist dann zum Förderband gegangen, hat in die Decke geguckt und da war oben Fenster auf und dann war dann die Temperatur immer anders, weil dann das Fenster aufgelassen worden ist und so.

Das war spannend, ja.

Wenn man dann sieht, ah ja, hier gehen die Sales hoch, da war unsere riesige Werbekampagne und das macht alles Sinn und das ist natürlich auch schön, wenn es einfach funktioniert und man das in den Daten sieht.

Ja.

Na, auf jeden Fall.

Ah, was mich noch interessieren würde, wenn ihr tatsächlich so Produkte baut mit Modellen drin und so und die irgendwie vielleicht Echtzeit irgendwas, wie deployt ihr eigentlich eure Modelle dann oder habt ihr da Präferenzen oder weil das ist immer so ein bisschen, das machen Leute unterschiedlich und ich weiß nicht, ob es da jetzt irgendwie so ein Standardding gibt, was man machen kann, aber ja, das ist auf jeden Fall immer irgendwie nicht so ganz einfach gewesen.

Also grundsätzlich gilt da natürlich, wir machen das, was die Kunden wollen.

Aber tatsächlich, wir sind ja dann auf einer Infrastruktur von Kunden unterwegs, aber nicht immer, weil manchmal zum Beispiel hatten wir ein Projekt, da darf ich zum Glück auch drüber reden, darf man ja das bei jedem Kunden, das war für die Berliner Senatsverwaltung, eine Luftschadstoffprognose, also die läuft auch noch, aber da sind wir jetzt nur noch Wartung, es ist so weit beschlossen.

Und die haben keine Vorgaben gemacht zur Infrastruktur.

Die haben halt kein ABS oder Azure und da konnten wir es halt so machen, wie wir wollten.

Und ich gucke mal gerade nebenbei in unseren Blogartikel rein dazu, weil ihr da, da kann ich mich alles nochmal wieder nachgucken, wie wir es gemacht haben.

Da hatten wir dann, konnten wir ganz frei entscheiden, was wir haben wollen und haben dann mit Kubernetes gearbeitet.

Das auch alles schön selbst aufgesetzt und da laufen dann automatisierte Jobs drin.

Und wir haben, na gut, das hat jetzt weniger mit Deployment zu tun, aber wir haben da dann im Hintergrund eine Clickhost-Datenbank, die ist ganz cool für große Datenmengen und haben dann Docker-Container, in denen unsere Prozesse dann laufen.

Da haben wir auch Redage benutzt, wie ich erwähnt habe.

Das benutzen wir dann auch für die Alerts, um zu gucken, sind alle Input-Daten da, sind alle Prognosen so erstellt worden, wie wir wollen, sind so viele Prognosen wie in der Tabelle, wie wir erwarten würden und so weiter.

Und in dem Projekt ist tatsächlich nur im Hintern haben wir Redage für die Visualisierung benutzt, nach außen gehen die Daten tatsächlich, unsere Prognosen gehen einfach über eine Rest-API raus und werden dann im Tool visualisiert, dass diese Nazverwaltung schon hatte.

Oder auch die API ist frei verfügbar, könnte auch jeder abrufen, haben auch schon ein paar andere dann mal gemacht.

Genau, mit Kubernetes ist natürlich immer ganz schön.

Ansonsten bei einigen Kunden läuft dann viel mit den Diensten von ABS.

Jetzt bei dem Kunden, wo ich bin, sind wir im Azure-Universum, wobei ich da mit dem Deployment nichts zu tun habe, weil das machen noch halt andere.

Das bin ich auch immer nur so am Rande natürlich dabei.

Also kann irgendwie in die Kubernetes kurz mal reingucken, aber ich kann das euch aufsetzen oder macht dann nicht die Deployments.

Ja, was mich da mal, oder das Problem, das ich da mal hatte, ist halt, dass wenn jetzt Leute quasi in Notebooks irgendwas modellieren oder so, wie kriegen sie denn dann, wenn sie jetzt rauskriegen, ah, wenn ich dieses Modell so parametrisiere oder so.

Oder ja, man hat dann normalerweise eine ganze Pipeline von Daten kommen rein, dann werden sie irgendwie transformiert und dann hat man halt hinterher irgendwie Predictions oder so.

Wie kriege ich das Ding denn jetzt quasi in das Produktionssystem integriert?

Und das, was wir dann gemacht hatten, war halt quasi aus dem Notebook direkt sozusagen ein Konterpaket zu bauen, das hochzuladen, in Django File Feel zu speichern und dann auch über eine JSON-AP dann die Ergebnisse wieder zurückzugeben.

Aber das fühlte sich so ein bisschen falsch an.

Oder also so auf jeden Fall nach, gibt es da nicht irgendeine einfache Möglichkeit, wie man das machen kann?

Also ich weiß noch nicht, ob es einfacher ist, aber wir sind auch ganz wenig eigentlich nur in Jupyter-Notebooks unterwegs, sondern ja, entweder wenn wir was schnell visualisieren wollen, geht es tatsächlich ja mit so einem Tool wie Redesh auch schneller, als wenn man dann anfängt, sein Matplotlib-Code zu schreiben.

Dann das Clicky-Bunti manchmal gar nicht so blöd und schlecht, wie es klingt.

Und dann, wenn wir dann die Code-Free-Modellierung haben, dann ist es halt

wirklich, das

ist ein Python-Paket.

Wir haben das dann automatisieren es dann meistens so, dass jedes Mal beim Push in den Main-Branch, wenn die Version zum Mat sich geändert hat, wird das dann über Jenkins Red and Job getriggert, der dann das Paket baut und in unser Repository hochlädt, das dann normalerweise nur intern verfügbar ist und dann können wir, ob das dann automatisch deployed wird oder wir das irgendwie manuell machen, können wir es dann halt überlegen.

Ja, aber dann kommen

wir einfach runtergeladen auf den Port

und dann aus.

Ja, aber dann brauchen ja die Leute, die quasi modellieren, Zugriff auf das Produktionssystem quasi oder können halt, es muss halt dann, die müssen den Code verändern, die müssen committen können.

Ja, ja, also die committen von morgens bis abends.

Ja.

Also das ist tatsächlich bei uns überhaupt nicht so, dass da irgendwie jemand sitzt, der nur in einem Notebook prototypt.

Gar nicht.

Also wenn das Projekt losgeht, dann muss man als erstes ein Repo anlegen, weil sonst kann man ja gar nichts machen.

Ja.

Und vielleicht startet man dann irgendwie mit ein paar Skripten, die dann später ordentlich in ein Paket überführt werden und in Funktionen und Klassen verpackt.

Das kann schon sein, aber grundsätzlich ist es halt eine Software und sonst auch oft in größeren Projekten mehrere Pakete, zum Beispiel zu dem Projekt für die Senatsverwaltung, sind es dann, wir haben da sehr viele verschiedene Datenquellen, zum Beispiel Verkehrsdaten, Wetterdaten und so.

Und dann haben wir für jede Datenquelle ein Paket, das nur dafür da ist, diese Datenquelle einzulesen und zu formatieren, in die Datenbank zu schreiben.

Das heißt, der Handshake ist dann über die Datenbank, dann kommt irgendwann das nächste Paket, das nächst sich die Daten dann und macht dann die Modellierung.

Und dann gibt es nochmal ein Paket, das halt, ob ich die Daten weiter aufbereite und dann gibt es ein Paket mit der API.

Und wenn ihr ein Modell daraus gebaut habt, irgendwie mit Torch oder sowas, was macht ihr dann?

Wo legt ihr das denn hin?

Wir haben das dann in dem Fall tatsächlich.

Ich liege gerade.

Also tatsächlich, im Kundenprojekt benutzen wir MLFlow und ich weiß nicht, ob, also ich hatte das vorher tatsächlich noch nicht benutzt, haben wir die Objekte dann abgelegt.

Ich glaube, es gibt, das ist ganz witzig, ja, es gibt tatsächlich, das war jetzt ein Projekt mit XGBoost, weiß ich nur, da haben wir, kann man die Projekte tatsächlich in Form eines Strings speichern und da haben wir die in der Datenbank gespeichert.

Das funktioniert gut.

Man kann aber natürlich auch das Modellobjekt irgendwo in einem Modellrepository dann ableden.

Also eigenes Modellrepot mit Branches oder irgendwie Tags oder sowas hier.

Ja, oder irgendwelche Tags muss man natürlich schon haben, damit man die dann nachher wieder identifizieren kann.

Ja.

Also gut, wenn jetzt die Mollierung total schnell geht, dann kann man natürlich auch das Modell einmal im Monat neu berechnen oder nee, dann einmal am Tag neu berechnen und sofort die Prognosen machen und das Modellobjekt überhaupt nicht speichern, aber das ist, glaube ich, eher so der seltene Fall.

Normalerweise kann man das ja schon speichern.

Wiederverwenden.

Also wir können uns auch gerne nochmal an dem Ablauf ein bisschen weiter entlang hangeln.

Ja, weil

wir jetzt schon vorgegriffen haben.

Also wenn wir das Problem verstanden haben, die Daten verstanden haben und die sehen soweit gut aus, dass wir und unser Kunde gemeinsam sagen, okay, damit können wir jetzt wirklich starten.

Da ist kein Problem drin.

Dann passiert natürlich erstmal ganz viel Daten, Aufbereitung und Bereinigung.

Oft muss man verschiedene Datensätze zusammenführen.

Da haben wir dann natürlich vorher schon geprüft, ob es auch eine gemeinsame ID gibt, um die zusammenzuführen.

Sonst wird es schwierig.

Oft muss man auch Sachen aggregieren.

Zum Beispiel hat man vielleicht einzelne Zeilen für jedes Produkt, das gekauft wurde von einem Kunden.

Wir wollen aber eigentlich nur eine Zeile pro Kunde.

Dann muss ich irgendwas überlegen, wie man das denn voll aufaggregieren kann.

Manchmal macht man Transformationen oder berechnet eine neue Spalte aus anderen Spalten.

Also das ist das, was man als Feature Engineering kennt.

Wir bauen also Features, die ja einfach sinnvolle Inhalte haben, mit denen das Modell dann später gut umgehen kann.

Macht ihr das dann immer live in Pandas oder schreibt ihr das doch in eine Datenbank rein?

Es kommt drauf an, aber meistens haben wir dann schon eigentlich ein separates Modul, das die Features berechnet und irgendwo hinschreibt, weil das meistens dann einfach schöner ist, das zu modular signalisieren, weil es sonst ein bisschen zu viel wird.

Was ist aber die Datenbank für?

Ich überlege

gerade, wir bauen früher viele auf MariaDB unterwegs, jetzt sind wir ja viele Clickhaus, also Clickhouse, teilweise verhält es sich unerwartet, finde ich.

Aber es ist halt schon sehr cool mit großen Datenmengen.

Da kannst du davon die sind anders machen.

Das ist diese Geschichte,

Yandex hat es, glaube ich, mal gebaut, ne?

Und dann haben sie es irgendwie Open Source veröffentlicht.

Das weiß ich nicht.

Aber ich meine, ich weiß es nicht genau.

Ja, aber habe ich auch schon ein gutes Früh gehört.

Ja, also da haben wir ja, wir haben so am Anfang dieses Projekts überlegt, okay, machen wir das jetzt.

Wir hatten einmal was damit ausprobiert und wir wussten, wenn es jetzt nicht gut funktioniert, dann müssen wir natürlich irgendwie auf eigene Kappe nochmal ein paar Tage investieren, um das umzustellen.

Aber es war so eine gute Entscheidung, weil wir gemerkt haben, mit den Datenmengen würde in anderen Datenbanken überhaupt nicht gehen.

Ja.

Ja, und wenn wir dann so Features haben und die stehen dann vielleicht auch in der Clickhaus-Datenbank oder vielleicht stehen sie auch in der Postgres oder RedShift-Datenbank, dann geht es dann erst mit der Modellierung los.

Und zum Glück haben die meisten Leute von Grund auch Spaß an den anderen Sachen, weil wie gesagt die Modellierung meistens wirklich nur ein kleiner Teil ist.

Man muss sich natürlich genau überlegen, was ist überhaupt das passende Modell.

Im Moment, wenn man Prognosen machen will, ist immer noch in G-Boost einfach sehr, sehr gut.

Ein baumbasiertes Modell.

Aber es kommen gerade Sachen, zum Beispiel, gibt es da TabPFN, das ist klingt auch

sehr interessant, ja.

Es ist ein Transformer-Modell und es ist irgendwie total verrückt, weil dieses Modell

hat, also

ich finde es immer noch total beeindruckt, das sind irgendwie so Magic.

Also das hat gelernt, wie Datensätze, wie die Zusammenhänge in Datensätzen, Entschuldigung, wie die Zusammenhänge in Datensätzen normalerweise so sind.

Und dann gibt man dem nochmal so ähnlich wie so ein Feintuning, den Datensatz, den man halt da selbst hat, der einen interessiert.

Und dann kann man nämlich total gute Prognosen machen, auch wenn der Datensatz nicht besonders groß ist und das Verrückte ist, diese Datensätze anhand derer das gelernt hat, das sind künstliche Daten.

Also es sind nicht mal echte Daten, weil da gibt es ja gar nicht so viele im Netz verfügbar, es ja anders ist, wenn man Sprachmodell trainieren will und das ganze Internet besteht aus Sprache.

Aber es funktioniert trotzdem richtig beeindruckend.

Also ich glaube, das ist sowas, was sich gerade so anfühlt wie, okay, da passiert jetzt wirklich mal wieder was Neues, auch im Bereich Prognose.

Ja, ja, auch diese ganzen Pre-Trained, das gibt es ja im LNM-Bereich, gibt es das ja alles, oder halt auch bei so Vision-Modellen, wo dann alles auf ImageNet oder so trainiert ist.

Aber bei tabularen Daten hätte ich jetzt überhaupt gar nicht gedacht, dass das überhaupt möglich ist oder dass das irgendwie, dass das, und ja, das hat mich auch total gewundert.

Ihr müsst ja vielleicht jetzt noch ein bisschen kurz nochmal erklären, bitte so die Grundlagen.

Ich glaube, das war ein bisschen komplex vielleicht für einen Einstieg.

Also TabTFN hast du gesagt?

Und XG-Boost, also

Gradient Boosting, ja.

Ja, XG-Boost ist ein Gradient-Boosting und das ist halt eigentlich einfach dazu da, um eine Tabelle von Daten zu nehmen und die Zusammenhänge zu lernen, die in diesen Daten vorkommen.

Zum Beispiel will ich vielleicht vorher sagen, wie viel verkauft will da an einem bestimmten Tag und in den Daten hätte ich zum Beispiel die Info, welcher Wochentag ist denn das eigentlich und ist dann vielleicht davor oder danach ein Feiertag und um welches Produkt geht es und so weiter.

Wie ist das Wetter?

Vielleicht verkaufe ich ja bei Hitze Meerwassermelonen.

Und das ist so der Klassiker, das würde man auch mit einer linearen Regression machen können, die ist aber weniger flexibel und normalerweise dann auch weniger genau.

Und XG-Boost ist da halt deutlich komplexer.

Und XG-Boost macht das dann quasi über die, weiß ich nicht, Backpropagation-Mechanismen, die nehmen.

Nee, das ist eine Art Decision-Tree.

Also es ist eine andere Art, andere Art, grundsätzlich andere Art von Modell.

Das ist im Zip so eine Kombination aus ganz, ganz vielen kleinen, nicht besonders schlauen Entscheidungsbäumen, aber dadurch, dass die alle hintereinander geschaltet werden, ergänzen sie sich ja gut und dann wird es am Ende auch ziemlich gut.

Ja.

Und das war jetzt über Jahre eigentlich für jedes typische Predictive-Projekt oder für jede Predictive-Fragestellung war HT-Boost, war schon fast langweilig.

Ja, es gibt da noch so ein paar Varianten.

Es gibt zum Beispiel Catboost, das ist so ähnlich, hat aber halt schon irgendwie ganz schlaue Mechanismen implementiert, um mit kategorialen Variablen umzugehen und manchmal das eine oder das andere so ein bisschen besser oder performanter, aber das ist kein Riesenunterschied.

Da gab es dann nicht auch noch irgendwas von Microsoft Lightboost oder sowas, aber ich weiß gar nicht, was da ausgeht.

LightGBM ist oder LightGBM, genau.

Ich weiß gar nicht,

was daraus geworden ist.

Benutzen wir auch gerade in dem Projekt.

Und ja, witzigerweise, wir haben auch schon, ich glaube vor einem Jahr oder so haben wir gedacht, kann man eigentlich auch LLMs zur Prognose benutzen?

Ich möchte kein LM ja sagen, guck mal hier, das und das und das sind meine Daten, was denkst du, wie teuer ist dieser Gebrauchtwagen?

Und wir haben da einen Datensatz bekommen von einem Unternehmen, die genau solche Daten eben aus dem Internet crawlen und die das, also haben wir natürlich so ein bisschen Informationen mitgeben und das hat aber schon ganz gut funktioniert.

Also wir haben

da, ja

da, da weiß ich jetzt die Details natürlich noch nicht alle auswendig, aber wir haben sowohl mit GPT-Modellen als auch mit Open Source Modellen das ausprobiert, es macht schon Sinn, die zu feintunen.

Und dann kann man aber relativ gut sagen, mein Auto oder das Auto, das ist die Marke, das hat so viele Kilometer, das ist so und so alt und das hat, hier ist noch der Freitext mit der Beschreibung dazu.

Da steht dann vielleicht irgendwas Spannendes drin, wie das hat eine Beule, vielleicht steht da aber auch nichts Spannendes drin.

Und dann fragt man wie, teuer ist das Auto, bitte antwortet nur in einer Zahl, in Euro oder irgendwie sowas.

Und das funktioniert schon erstaunlich gut vor allem, wenn man sich so viele Trainingsdaten hat.

Weil ich glaube, dann kann das halt die Stärke ausspielen, dass das Sprachmodell eben schon Vorwissen hat zu Autopreisen, weil es das Internet kennt.

Also Transformers meinen wir

jetzt tatsächlich, also die großen LLMs und nicht nur Transformers hätte, weil ich hätte mich halt gefragt, ob das in dem Transformers-Modell durch das, weiß ich nicht, dadurch, dass es halt Nodes sind und Candidation Trees, dass es da irgendeine andere Art gibt, dass Daten aus den tabulärischen Daten rauszuziehen.

Ja, das hier ist jetzt so, dass die klassischen LLMs, die man so kennt und dann kam eben jetzt dieses Neue mit Tab-PFN, das ist ein Transformer, ist, das halt wie speziell für tabulare Daten wieder gemacht ist, weil wir haben ja die LLMs eigentlich so ein bisschen zweckentfremdet, indem wir die dann da nach dieser Puppe machen.

Was meintest du denn da

überhaupt mit Feintuning?

Was habt ihr denn da gemacht?

Ich weiß

gerade, also ich weiß nicht, wie das eigentlich im Detail dort funktioniert, aber es ist so, dass das Modell ja eben schon ganz viel weiß von den Sprachdaten, die es aus dem Netz kennt.

Und wir haben ihn dann nochmal, ja gut, das beschreibt es wahrscheinlich abdentlich ziemlich komplett.

Wir haben dem dann nochmal, wir haben einen Trainingsdatensatz, wo wir ganz viele Gebrauchswagen schon drin haben mit dem Preis und den ganzen Eigenschaften.

Und dann haben wir ihm halt immer so ganz viele Texte gegeben, zu jedem Auto einen Text.

Das Auto so und so alt, sieht so und so aus, das ist die Marke und es kostet das.

Und das nächste Auto so und so und so und kostet das.

Und das ist dann nochmal ein zusätzlicher Text.

Und damit trainiert man das Modell nochmal spezifisch auf diesen einen Task.

Also wie das jetzt im Hintergrund genau passiert, kann ich tatsächlich euch gerade gar nicht erklären.

Weil ich in dem LM-Thema weniger drin bin, als in sowas wie XG-Boost.

Aber ja, dadurch ist das Modell dann nochmal, man kriegt nochmal so eine Spezialausbildung quasi für das Thema Autogebrauchtwagenpreise.

Und dann wird es nochmal besser, wenn man ihm dann so eine Frage später stellt.

Ja, man trainiert es quasi nochmal ein Stückchen weiter, gibt es unterschiedliche Ansätze, wie man das dann macht.

Ob man nur Layer einfriert, bestimmte Gewichte halt nicht neu setzt und dann vielleicht nur die letzten irgendwie anpasst oder ob man so Low-Rank-Adaption-Geschichten macht oder da gibt es ganz unterschiedliche.

Da kommen ja an die Gewichte gar nicht dran von den großen LMs zum Beispiel.

Nee, das kannst du auch nicht mit, das kannst du natürlich dann nur, also du kommst, du kannst mit den OpenAI-Modellen und so auch machen, über deren Apis, aber wenn du das auf einem quasi, wenn du das selber machen willst, dann musst du ein Modell nehmen, wo du Gewichte hast.

Ja, genau.

Ich glaube, wir haben auch, ja, wir haben da beides gemacht.

Also einmal über OpenAI, da kann man einfach mal die Apis sein, hier ist mein Feintuning-Datensatz, machen wir mal.

Und aber auch mit den Open Source Modellen, wenn da nochmal ein Feintuning dran gehängt haben, damit die eben speziell auch.

Bei Tuning und Autos fällt mir jetzt erst auf, dass es eigentlich total gut passt.

Ja.

Okay, das ist halt Tab-TFN, ja.

Ja, wobei das ist jetzt noch relativ neu und da ja nicht jedoch neue Projekte losgehen, sondern die meisten Projekte schon länger laufen, sind die meisten Projekte, die wir haben, dann auch mit sowas wie XG-Boost oder teilweise auch mit irgendwelchen ausgefeilten statistischen Ansätzen oder Kombinationen, je nachdem, was man macht.

Ja, das fand ich dann spannend.

Und wie viel kann denn jemand, der richtig gut in Statistik oder in klassischer Statistik ist, rausholen im Vergleich zu diesen, ich beschieße das einfach mit so einem Modell.

Ich würde sagen, es gibt auch die Fragestellung an.

Bei so einem relativ klassischen Task wie irgendwelchen Verkaufszahlen geht es, glaube ich, auch mit einem Modell, also XGBUS ganz gut, wenn man es natürlich richtig macht.

Und zum Beispiel noch, es gibt da ja eine Menge Hyperparameter, die bestimmen, wie flexibel ist das Modell ist.

Und wenn man das Modell zu flexibel sein lässt, dann lernst du die kleinsten Wacker auf den Trainingsdaten und auf neuen Daten erzählt es dann nur Mist.

Das heißt, dann hat man ein Overfitting und das muss man verhindern.

Es gibt natürlich schon ein paar Sachen, die man falsch machen könnte.

Aber wenn man da alles nach State of the Art macht, kommt man bei so einfachen Aufgaben mit einem ECG-Boost meistens ziemlich weit.

Aber ja, zum Beispiel im Sportwettenbereich gibt es ja manchmal dann wirklich komplizierte Sachen.

Also wenn ich jetzt vorhersagen will, wie die Tore sich verteilen, dann kommt man da dann schon nochmal weiter, wenn man wirklich darüber nachdenkt, theoretisch, was ist denn das jetzt eigentlich für eine Verteilung?

Das sind Anzahlen, also es ist eine Poisson-Verteilung, aber die ist ja irgendwie bivariat, weil es sind ja zwei Mannschaften und zwei Teams, die Tore machen.

Und da weiß ich, dass meine Kolleginnen und Kollegen sich schon einige ziemlich verrückte Sachen ausgehört haben.

Und dann umgekehrt manchmal ist es am Ende auch irgendwie doch nur eine einfache Heuristik, die einen ziemlich weit bringt.

Er hat

also nicht die Ernährung

der Spiele am Morgen vor mit einfließen lassen können in sowas.

Das weiß ich nicht.

Ich müsste mal fragen, ob sie das Feature drin haben.

Es gibt auf jeden Fall spannende Sachen.

Ja, also ich würde mich halt tatsächlich interessieren, was man aus Statistik irgendwie daraus lernen kann, weil ich weiß, ich verstehe nicht genau, wie jetzt in so einem Transformers-Modell die einzelnen Gewichte bei den Neuronzustande kommen.

Also weil ich stelle mir das so vor, der muss versuchen, diese Features rauszufinden und die irgendwie so linear unabhängig wie möglich voneinander zu gestalten, dass er irgendwie den Erklärungsgrad dann da rausfindet, der dann halt gut ist, damit er halt gute Prognosen hinkriegt.

Aber so richtig klar wird das nicht.

Ja, Neuronaliste sind deutlich eher Blackbox, aber das ist Extreme Boost auch, natürlich, du kriegst bei beiden auch so ein bisschen raus, was da der Grund ist, warum das jetzt irgendwie so oder so entschieden oder vorher gesagt hat.

Aber es ist schon eher so Blackbox-Modelle.

Ja, man kann jetzt nachträglich dann.

Also das wäre jetzt vielleicht für mich auch nochmal einer der Punkte, der für dieses Data-Cleasing spricht.

Ja, also wenn ich jetzt die Daten da einfach so reinkippe oder am Anfang schon so aufteile, dass ich jetzt Clusterbilde oder Kategorien bilde oder sowas und die halt nochmal damit annotiere oder so, ob das halt eine deutliche Verbesserung bringt, also weil die ein bisschen reiner sind vielleicht oder halt, ne, oder schon mal irgendwie die Daten wie eine Zusammenfassung oder eine Summe oder sowas da schon drinsteht mit.

Ja, in irgendeiner Extraspalte, dass das dann halt das Ergebnis zum Beispiel nochmal deutlich bessere

Güter kriegt.

Du beschreibst, glaube ich, Feature Engineering gerade, oder?

Ja, vielleicht.

Also zum Beispiel, viele Modelle sind ja auch dazu in der Lage, Interaktionen zu erkennen.

Also beispielsweise, weißt du, hätte man gerade gar kein gutes Beispiel.

Nein, ja, vielleicht aus der Luftschallstoffprognose, über die ich gerade ist, wenn der irgendwie was.

Ja, also mittags ist die Luft schlechter, weil wir Autos rumfahren, aber nur wenn wir keinen Wind haben.

Wenn wir viel Wind haben, wird nämlich, wenn die Schadstoffe halt weggepustet.

Das ist halt die Interaktion.

Also die Effekt, mittags ist es schlechter, der ist nur da, wenn die Windstärke gering ist.

Und so eine Interaktion können die Modelle auch lernen, aber manchmal sind die Interaktionen ja vielleicht auch nochmal komplexer von drei oder vier Sachen.

Und wenn man da schon so eine Idee hat, sachlogisch, dann macht man es dem Modell halt schon deutlich leichter, wenn man das vorher schon mal explizit zusammenbaut.

Also dann vielleicht irgendwas, was würde dann sagen, es ist Mittag und es ist kein Wind, es ist Windstill.

Jetzt in diesem sehr einfachen Beispiel.

Und das ist dann, glaube ich, auch wieder sowas, wo es dann wirklich viel bringt, immer mal wieder mit den Leuten zu reden, die sich fachlich damit auskennen.

Ja, also dann hat

man quasi tatsächlich schon das Wissen, was man aus den Daten ziehen kann, so ein bisschen annotiert reingegeben, dass das Modell dann damit besser arbeiten kann.

Also als eigene Funktion irgendwie so, ja.

Ja, und oft musst du auch.

Oft musst du auch Daten erstmal transformieren, damit die überhaupt von dem Modell verwendet werden können.

Also wenn du zum Beispiel Text hast, kannst du den nicht einfach so bei XG-Boost sozusagen reinkippen, weil das kann halt bloß irgendwie eine fixe Anzahl von Spalten.

Und dann muss man das irgendwie erstmal einen Text runterprojizieren mit Singular Value Deck Composition oder so auf, weiß ich nicht, ein paar hundert Dimensionen oder so.

Und das kann man in den XG-Boost reinpacken.

Sozusagen, solche Sachen hat man halt auch immer.

Ja, das war auch tatsächlich so ein Grund, weshalb wir das auch mal ausprobieren wollten mit den LLMs zur Vorhersage, weil wie du sagst, wenn wir einen Text haben und wollen aber XG-Boost machen, wie eben dieser Freitext mit der Autobeschreibung, da musste man sich ja erstmal irgendwie was überlegen, wie man den dann in ein sinnvolles Format bringt, sodass XG-Boost, das kennt halt nur eigentlich nur Spalten bezahlen.

Kategorien kann man ja im Prinzip auch doch in Zahlen überführen.

Und einen Text, naja, ist halt erstmal durch so einfach.

Was man jetzt natürlich auch noch machen kann, ist, dass man das LLM benutzt, um Features zu generieren, indem man sagt, hier ist der Text, hat das Auto einen Schaden, ja nein.

Ja.

Also es ist dann auch nochmal so eine Hybridlösung, die, glaube ich, gar nicht so dumm ist.

Und halt auch, man kann natürlich auch, je nachdem, wie genau man das machen will, Leute hinsetzen, die dann wirklich viel Zeit damit verbringen, die Texte durchzugucken und das zu labeln, dann ist es bestimmt nochmal ein bisschen genauer.

Ist halt die Frage, ob sich es lohnt.

Muss ich mich immer überlegen.

Ja.

Okay, ja, gut, aber wir werden, dadurch kann man schon viel rausholen, ja, durch diese Modellierung dann und so.

Okay.

Dann sind wir in diesen Datenprozessen.

Wie nennt man diese Datenprozesse E-Till, E-Till?

Da gibt es ja verschiedene Art und Weisen.

Ach, du meinst jetzt Extract Transform Load?

Ja, genau.

Das ist, glaube ich, aber nicht unbedingt was mit, oder,

aber wir sind jetzt da irgendwo in diesem Workflow, also es ging ja um dies CRISPR, ne?

Achso, ja.

Ja, ich glaube ja, also ETL, Extract Transform Load ist ja, beschreibt ja einfach den Prozess, dass man Daten irgendwo rauszieht, dann irgendwas damit macht, also sie transformiert und sie dann irgendwo hinlädt, obwohl man sagt, Daten laden für Daten kriegen, in dem Fall ist es aber Datenladen, die irgendwo hinladen.

Das ist auch ein bisschen verwirrend, auch im Naming finde ich in den Code dann, wenn man irgendwann überall Load stehen hat, egal ob man Daten zieht oder Daten wegschiebt.

Ja, das ist, so hängt das im Prinzip zusammen, aber oft benutzt man ja den Begriff ETL auch einfach für jeden Prozess, der irgendwie Daten nimmt, verarbeitet und so, die es ohne Strecke schiebt.

Außerhalb vom Data Science-Bereich halt auch ganz oft.

Genau, jeder Bissungsprozess, den man irgendwie halt automatisieren kann.

Aber ich glaube, es ist schon oft so, dass man auch sagen würde, nachher in dem fertigen Datenprodukt, okay, hier ist der ETL, jetzt kommt der ETL und dann kommt der Teil mit dem Modell.

Also oft nutzt man den Begriff eigentlich auch, um das aufeinander abzugrenzen.

Okay.

Also ich verstehe jetzt, also wir haben okay verstanden, was das Geschäft macht und was wir da lösen wollen für Daten.

Und dann haben wir verstanden, welche Daten wir denn haben und was wir damit machen wollen.

Dann haben wir die so transformiert und umgebaut, dass wir die in ein Modell kippen können, was wir uns dann ausdenken oder ausgedacht haben.

Und was machen wir dann?

Dann gucken wir uns an, was dabei rauskommt.

Ja, dann haben wir ein Modell und dann machen wir Prognosen und gucken, wie gut die sind.

Und da muss man natürlich verschiedene Sachen beachten.

Also wenn ich die Prognosen auf denselben Daten mache, die ich fürs Modelltraining benutzt habe, das ist natürlich für das Modell relativ einfach.

Und deswegen ist es wichtig, dass ich mir vorher einen Teil der Daten weglege.

Und nur die übrigen Daten kriegt das Modell zum Lernen.

Und danach mache ich auf diesen weggelegten Daten die Prognosen.

Und dann gucke ich, was tatsächlich die Werte waren und vergleiche die mit den Prognosen von dem Modell.

Und das Modell ist halt ja natürlich in dem Moment blind.

Es kriegt halt nur die ganzen Features, aber es kriegt wirklich die Zielvariable.

Es muss dann seine Prognosen blind machen und wir können dann gucken und sagen, ja, wir kennen die Bahnwerte aber schon und vergleichen das jetzt.

Da gibt es dann verschiedene Kernwerte, die man berechnen kann, kommt es halt total auf die Fragestellung an.

Man könnte zum Beispiel eine mittlere prozentuale Abweichung berechnen, man kann ein Bias berechnen, liegen wir Mitteln drüber oder drunter, man kann eine erklärte Varianz, einen Varianzanteil berechnen, man kann, je nachdem, vielleicht wollen wir auch gar nicht numerische Daten vorher sagen sollen, nur ein Ja, nein, dann könnte man gucken, wie viele False Positive, False Negative und so weiter habe ich.

Das kommt ja stark auf den Use Case an.

Auf jeden Fall kann ich das dann berechnen.

Schön out of sample, also mit diesem separaten Datensatz.

Und das ist natürlich besonders gut, wenn man zwei Modelle vergleichen will.

Wenn man nur eins hat, dann ist da, ist es, glaube ich, auch gar nicht so leicht zu sagen, was ist denn jetzt ein guter Wert für dich irgendwie 20, 50 oder 90 Prozent erklärte Varianz.

Das kommt auch stark auf die Fragestellung an.

Wenn ich zum Beispiel individuelles Verhalten von Menschen erklären will, dann kann ich das natürlich nicht so genau vorhersagen wie aggregierte Verkaufszahlen, weil da einfach so viele other Einflüsse sind.

Und ja, nochmal zu diesem Split, zu den Trainingsdaten und den Testdaten.

In den allermeisten Fällen have unsere Daten ja eigentlich eine Zeitliche Struktur.

Man kann jetzt natürlich die Testdaten zufällig rausziehen und zur Seite legen, aber am besten ist es when man immer die nimmt, die sightlich am Ende liegen.

Weil manchmal ändern sich eben Zusammenhänge und das eigentlich passiert ständig, dass sich Zusammenhänge ändern.

Und deswegen ist es halt sinnvoll, so ein Szenario zu bauen, wo das Modell quasi auf der Vergangenheit lernt und dann auf Daten, die danach passiert sind, auch tatsächlich evaluiert wird.

Sonst kann es halt passieren, dass man sich da verschätzt und dann denkt, das Modell wäre besser, als es tatsächlich ist.

Und nachher im Betrieb, dann muss es ja tatsächlich Prognosen für die Zukunft machen und dann ist die Enttäuschung dann irgendwie da, wenn es dann doch schlechter funktioniert, als man dachte.

Aber man muss natürlich auch immer auffassen, dass man dann halt die neuen Zusammenhänge dachten Erinnerungen dann irgendwie auch trotzdem mit reinkriegt.

Das ist natürlich regelmäßiges Neutraining, ja.

Also das ist dann auch total wichtig, dass man das Modell nicht einmal trainiert und dann fünf Jahre lang benutzt.

Trotzdem, solange die Zusammenhänge noch nicht da sind, die neuen und man die noch nicht kennt, muss man halt zumindest mit dem leben, was man bis dahin hat.

Also man könnte ja vielleicht auch diese Zusammenhänge irgendwie als, ich sag mal, Liste, ne, dem Geschäft zurückgeben, hey, hier, das sind unsere Annahmen.

Guckt doch mal bitte, dass die noch stimmen.

Und wenn ihr merkt, irgendwie da ändert sich irgendwas an den Annahmen, dann müssen wir halt da nochmal was auch anpassen.

Ja, also zumindest, ich glaube, so direkt geht es gar nicht so gut, weil das ist ja was, was das Modell findet und wo die dann eher auch sagen, ah ja, cool, ja, das passt so ungefähr zu dem, was wir erwartet haben, aber die können sich wirklich sagen, oh, das ändert sich jetzt, weil jetzt ist, keine Ahnung, zum Beispiel der Zusammenhang von Autoanzahl zu Stickoxiden, der wird schwächer, weil mehr E-Autos unterwegs sind und die stoßen keine Stickoxide aus.

Ja, okay, aber wie viel schwächer der jetzt wird, das kann uns diese NAS-Verwaltung hier für Umwelt und so weiter ja auch nicht sagen.

Also sie können uns sagen, ja, das wird wahrscheinlich schwächer mit der Zeit.

Also klar, solltet ihr das Modell regelmäßig neu trainieren, aber die können uns doch sagen, so und jetzt, jetzt ist aber so viel Schwächer geworden, so müsst ihr mal neu trainieren.

Das kann mir auch gar nicht sehen.

Aber deswegen ist es halt meistens so, dass man einfach sagt, wir trainieren unser Modell zum Beispiel einmal im Monat neu.

Und dann wissen wir, dass wir halt eigentlich immer neueren Zusammenhänge abgedeckt haben.

Deswegen ist es auch manchmal gar nicht so nützlich, ganz, ganz viel Datenhistorie zu haben, weil vielleicht das vor allem jetzt, wo auch noch Corona war, dass die Zusammenhänge und die Muster während Corona in irgendwelchen Verkaufszahlen oder menschlichen Verhalten, die sind natürlich jetzt halt anders.

Das wäre mein nächster Punkt gewesen.

Also wenn ich jetzt

Statistik nehme, ja, oder von Statistik irgendwo abhängige Modelle, um Prognosen zu machen für die Zukunft, dann bin ich ja immer nur, also auf den, ich sage jetzt mal den Normalfall trainiert, ja, oder den Alltag.

Und diese ganzen Schocksituationen, die kann ich ja immer ganz schlecht irgendwie abbilden, weil ich ja dafür auch keine Beispiele

oft habe, ja.

Also wenn der Schock gerade erst passiert ist, dann ist es echt schwierig.

Man kann vergangene Schocks noch mit reinnehmen und sagen, okay, hier war ein Strukturbruch, da hat sich jetzt irgendwie was geändert, das nehmen wir als Feature mit rein.

Geht manchmal, geht auch nicht immer.

Also ich glaube, wir haben tatsächlich, in dem Luftbruchmodell-Projekt haben wir, glaube ich, einfach die Zeiträume definiert, hier war Lockdown, hier war kein Lockdown.

Damit das Modell zumindest weiß, ah, deswegen war hier so viel weniger Luftverschmutzung.

Ja, okay.

Das erste Gedanke, oh, das ist eine gute Sache, ja.

Aber ich habe, ich habe nochmal, ich würde mal kurz, ganz kurz einen Schritt zurückgehen, weil ich habe eine Frage, die mich doch jetzt schon interessieren würde, weil ich jetzt auch gar nicht so wirklich Ahnung von diesem PFN oder so habe.

Weil in den anderen Bereichen haben ja die, also normalerweise hat man neuronale Netze für solche tabularischen Daten, das hat nichts, also funktioniert auch, aber halt nicht so gut wie die anderen Arten von Modellen oft.

Und die Frage wäre jetzt, was einen ja die Transformer bzw.

überhaupt irgendwie die ganze Deep Learning-Geschichte oder so in anderen Bereichen gebracht hat, ist ja, dass man nicht mehr so viel Feature-Engineering machen musste.

Oder eigentlich ist man ja am Feature-Engineering mehr oder weniger vorher gescheitert.

Und dann jetzt kann man halt inzwischen einfach die Rohdaten da so, naja, mehr oder weniger reinkippen und das neuronale Netz macht das Feature Engineering vor einen sozusagen.

Und die Frage wäre halt, macht es das möglicherweise, ist es bei Taphef auch so, dass ich da jetzt quasi auch relativ rohe Daten irgendwie verwenden kann oder muss ich das erstmal auch irgendwie eben in eine Struktur bringen, so ähnlich wie bei XGBoost?

Du fragst eigentlich die falsche.

Ich glaube aber, dass man da nicht viel vorbereiten musste.

Aber würde ich tatsächlich auch auf unsere Podcast-Folge mit dem Auto von TabM verweisen?

Muss ich mal anhören.

Klingt ja nicht.

Ja, also genau, die ist dann wahrscheinlich für dich die richtige.

Ja.

Aber vielleicht nochmal zu dem Modelltraining.

Wo trainiert ihr denn das?

Wie macht ihr das?

Meistens auft auf ABS-Maschinen zum Beispiel.

Wir haben auch selbst ein paar fette Server, die sind jetzt im Rechenzentrum in Nürnberg seit Neuestem und haben dort unter ihresgleichen.

Vorher haben sie so ein bisschen das Bürobeheizt nochmal zu Winters.

Jetzt haben sie ja einen besseren Ort gefunden.

Also die benutzen wir auch manchmal, aber viel läuft jetzt natürlich inzwischen in der Cloud und auch das ist dann auch kundenabhängig.

Also zum Beispiel Azure, was auch immer dann.

Aber das sind oft Sachen, die dann doch lokal ein bisschen zu lang dauern würden und dann besser auf einer größeren Maschine laufen.

Also irgendwie, ja.

Und also die klassischen Sachen sind halt normalerweise einfach auf der CPU natürlich und wenn wir dann aber zu LLMs kommen, dann geht es natürlich in Richtung GPU und wir haben uns auch da was zugelegt vor einigen Monaten, sodass wir unsere eigene GPU haben und auch mal selbst das aussetzen konnten auf einer eigene GPU, was natürlich

auch ganz

spannend ist.

Also habt

ihr eine eigene Maschine geschätzt oder habt ihr irgendwie bei Hetzner oder was gemietet?

Die haben wir tatsächlich gekauft physisch.

Die sitzt auch im Rechenzentrum.

Und dann irgendwann haben wir auch mal was ausprobiert, da war die dann doch zu klein, da haben wir das dann über AWS gemacht.

Okay.

Das ist auch schwierig, gerade vielleicht zu kaufen.

Und das ist sehr teuer.

Ja, das ist ja nicht.

Also mit dem Gegner kommen, das macht jetzt schon Sinn.

Wir kaufen die.

Aber ich glaube, sie war dann irgendwie zwei Monate später wieder deutlich günstiger als.

Wenn man die mietet, irgendwie, dann kosten die irgendwie so 1000 Euro im Monat oder sowas.

Ja, also wenn du die viel Hauptspeicher, wenn du zum Beispiel LLMs feinschulen willst, dann zahlst du eher 1000 Euro am Tag.

Ja, das ist richtig teuer.

Ja, okay, kommt auch wahrscheinlich davon, wie viel man braucht, ja.

Ich glaube, es hat auch ein paar Leuten einfach Spaß gemacht, das Ding halt eben auszuwählen und zu kaufen und dann wirklich mehr selber sowas komplett aufzusetzen.

Ja, das macht auch Spaß.

Ist ja auch cool, wenn man das dann mal kann.

Kommt der Operator

durch doch.

Ja, ich habe das auch gemacht.

Ich mag das auch.

Brauchen wir einen Grund.

Gib mir doch einen Grund dafür.

Also vielleicht wollt ihr ein unbezahltes Praktikum.

Wenn wir da ganz viel große Hafen gehabt haben, können wir nur mal nach dem machen.

Das könnten wir mal nutzen.

Aber ja.

Vielleicht nochmal zu der Modellbewertung.

Ich hätte ja schon gesagt, dass man natürlich Kennzahlen ausbrechnen kann für die Modellgenauigkeit so insgesamt.

Wie viele Fälle werden richtig vorher gesagt oder wie weit sind wir im Mittel daneben.

Aber dann macht es halt auch Sinn, diese Blackbox nochmal aufzubrechen, wie ihr eben erwähnt habt, dass man guckt, was hat das Modell eigentlich für Zusammenhänge gefunden.

Und das ist bei einer linearen Regression natürlich leicht, weil man sich einfach die Koeffizienten anguckt und guckt, wie hoch die sind und hat noch welche signifikant sind.

Aber das geht dann bei XG-Boost nicht mehr so leicht, sich irgendwelche Splits anzugucken, die das Modell gefunden hat oder so.

Aber da gibt es ganz tolle Methoden, die nennen sich SHEP.

Und die

kann man dann danach auf die, also man braucht das Modell und auch nochmal einen Datensatz, mit dem man Prognosen macht.

Und wenn man das hat, dann kann man diese Methoden darauf werfen und kriegt dann ganz praktische Visualisierungen auch.

Also erstmal eine Feature Importance, also wie viel wurde welches Feature vom Modell eigentlich genutzt.

Auch das ist ja schon mein erster Plausibilitätscheck, wenn da irgendwas ganz am Anfang steht, was sehr überrascht ist, sollte man nochmal überlegen, was da los ist.

Und dann kann man sich auch die Form der Zusammenhänge angucken.

Zum Beispiel, ich glaube, da haben wir auch gesehen, je weniger, desto weniger Schadstoff, aber irgendwo gibt es dann so eine Sättigung, dann sind die Schadstoffe halt irgendwie einfach so weggewegt, wie es nur geht.

Und das ich glaube, es war sogar, nee, ich glaube, das war nichts Interessante, irgendwann wurde es halt wieder schlechter, weil dann der Staub aufgewirbelt wird.

Wenn es so windig ist, dann hat man immer nur den Staub in der Luft, dass es wieder schlechter wird.

Und da war ich so, okay, was ist das für ein komisches Muster?

Und haben das mit Kunden angeguckt, die meinten so, ja, das haben wir auch schon beobachtet.

Wir denken, das liegt daran, dass dann irgendwann, der mit zu stark ist, das halt nicht.

Der Abrief von der ganzen Straße, der kommt nochmal mit hoch, ja.

Ja, ist

natürlich, wenn dann, wenn es regnet, dann halt eben wieder das, weil dann halt das eben weggespült.

Und dann die Temperaturen.

Und solche Sachen kann man dann halt eben sich angucken und überlegen, ob die plausibel sind.

Und man kann mit den Methoden sogar ganz einzelne Vorhersagen auch nochmal analysieren.

Und dann sagt die einem quasi, okay, wir haben jetzt hier 3,5 mehr gesagt, weil es ist Montag und dann haben wir aber nochmal 1,2 weniger gesagt, weil es ist in den Ferien oder sowas.

Und das ist natürlich auch sehr gut, um wirklich erklären zu können, warum man genau diese Prognose macht und was das Modell findet und um sich sicher zu sein, dass man auch irgendwie ein sinnvolles und gutes Modell gefunden hat.

Und es klingt jetzt alles so linear, als wenn man da so durchgehen, aber das ist dann auch manchmal ein Moment, wo man nochmal Ideen hat und neue Features baut oder nochmal Ideen hat und die Daten bereinigt, weil einem irgendwas ganz Komisches auffällt, irgendein Artefakt, das man loswerden muss.

Dass egal wie toll man sich die Daten vorher anguckt, manche Sachen, finde ich, sieht man einfach erst nach der Modellierung und muss dann irgendwie nochmal ein Schritt zurückgehen.

Das ist ja kein Problem.

Okay.

Dass er dieser Eval-Step dann, der dann guckt, ob das, was man da macht, auch dem entspricht, was man so möchte.

Oder ja, es gibt ein Alert, ja.

Oh, irgendwas bestimmt hier nicht.

Aber das kann natürlich auch sein, dass eine Realität

irgendwas ist.

Das kommt erst später, weil in dem Moment haben wir noch gar kein Alerting-System, da haben wir irgendwie noch gar nichts.

Wir haben jetzt vielleicht eine Pipeline, die die Tests laufen lässt, wenn wir was pushen, aber mehr ist in dem Moment normalerweise noch nicht automatisiert.

Und ja, wir schreiben auch sehr gerne Tests.

In was schreibt ihr die Tests?

Ich glaube, es ist eigentlich immer ein Py-Test unterwegs.

Ja.

Wir lieben PyTests.

Wobei Tests mit Daten ja auch manchmal ganz witzig sind, weil man ja nimmt man, baut man sich dann einen kleinen Testdatensatz, ist ja dann realistisch, macht man vielleicht sogar Tests gegen die echten Daten, die dürfen, die können natürlich keine einzelnen Werte prüfen, aber man kann damit testen, ob es überhaupt durchläuft.

Also ja, das ist ein ganz eigenes Thema.

Ja.

Tests mit Daten.

Ja, also tatsächlich schon, ja.

Also ich würde auch dazu tendieren, irgendwie aus der Realität irgendwas rauszuschneiden und dann zu gucken, ob das dann so läuft.

Weil also so Daten mocken ist immer so ein bisschen.

Och, naja gut, ja.

Ja, es geht auch mal, aber schwer.

Ja, also in dem Moment wäre man ja eigentlich nur beim POC, beim Proof of Concept und so ein richtiges Produkt oder ein MVP, ein Minimum Viable Product kriegt man ja erst, wenn man dann das Ganze auch deployt und automatisiert.

Und wir, ja, wir stellen unsere Prognosen oder Klassifikationen oder was auch immer, oft über APIs zur Verfügung, über Rest APIs.

Oft machen wir aber auch nochmal schon ein Frontend dazu, also eine Web-App, wo die dann angezeigt werden, wo zum Beispiel unser Kunde sich dann die Alarme angucken kann von irgendwelchen Käufen, die irgendwie suspekt aussehen.

Mit was macht ihr mit der Event-App?

Mit was macht ihr die Web-Apps?

Meistens mit Vue.js und historisch auch noch häufiger mit R-Shiny.

Aber das geht natürlich weg.

Da haben wir ein Projekt, das ist eigentlich ganz cool.

Da geht es gar nicht darum, irgendwelche Prognosen zur Verfügung zu stellen, sondern da haben wir Shiny-Apps gebaut, damit Leute Modellierungsalgorithmen anwenden können, ohne dass sie selbst R-Code schreiben können müssen.

Weil das ist für ganz viele Forschende, die aber nicht gut selbst coden können und dann wäre die Hürde natürlich total riesig.

Aber die brauchen eigentlich diese ziemlich komplexen Methoden und deswegen haben wir da dann für ein Forschungsinstitut einige Apps gebaut, wo die dann eben über eine Click-Oberfläche können sie ihre Daten hochladen und können dann die Analyse fahren mit bestimmten Einstellungen und kriegen dann Ergebnisse und Visualisierungen.

Das finde

ich natürlich auch sehr praktisch.

Und schreiben die dann mit ihre Doktorarbeiten.

Ja, aber zurück zu unseren Prognoseergebnissen.

Genau, oft stellen wir die über eine API zur Verfügung oder wir schreiben sie irgendwo in eine Datenbank und der Kunde nutzt sie dann halt so.

Das ist tatsächlich auch was, was man vorher wirklich klären muss.

Reicht das denen, wenn das eine API ist?

Oder sitzen da dann Leute, die damit überhaupt nichts anfangen können und sagen, ja, was sind denn jetzt lange zahlt?

Also, genau, das muss man natürlich auch vorher wirklich bis zum Ende denken.

Und unsere Erfahrung ist auch, dass es, auch wenn der Kunde dann irgendwie vorhat, doch das selbst zu machen, sagt, yeah, schreibt das in die Datenbank und dann benutzen wir es einfach so weiter, dann trotzdem lohnt es sich oft, dass wir das dann doch mitdenken und zumindest irgendwie eine kleine Web-Anwendung schreiben, weil sonst die Hürde doch groß ist und dann hat der NIT halt eben auch total viel zu tun.

Und dann ist es richtig schade, wenn das Projekt nachher in der Schublade

landet und

fällt dann ja am Ende irgendwie auch auf uns zurück.

Also dann lieber nochmal was Kleines bauen, damit die dann doch was sehen können.

Aber wenn die Farben dann auch richtig sind, dass das wichtig ist, dann vielleicht.

Das kann man auch durch unterschätzen sollen.

Ja, was ist sau hässlich.

Und ja, üblicherweise, das hat man eben schon gesagt, Modell muss man natürlich regelmäßig neu trainieren, weil sich Zusammenhänge in der Regel in allen Bereichen immer mal wieder ändern.

Und das ist dann oft so was wie einmal im Monat.

Ab und zu sollte man sich das Modell sogar auch nochmal ganz genau anschauen, zum Beispiel nochmal diese ganzen Chefsorten berechnen und gucken, ist das eigentlich noch plausibel?

Das kann man vielleicht einmal im Jahr machen.

Und die

Prognoseerstellung kommt halt darauf an, wie oft die benötigt wird und auch wie schnell sich die Sachen ändern.

Also in vielen Projekten ist es, dass das einmal am Tag passiert, aber manchmal ist es dann auch wirklich in Echtzeit, dass dann der Ehrenfall reinkommt und dann wird die Prognose für diesen einen ganz konkreten Fall erstellt.

Und oft kann man die auch noch nicht vorberechen, weil man die Daten vielleicht dann einfach noch nicht hat, sondern kommen dann rein die Daten und dann braucht man eine Prognose.

Zum Beispiel kommt ein neuer Kauf rein oder eine Anfrage und man muss in dem Moment entscheiden, ist das irgendwie verdächtig, könnte das Betrug sein oder ist alles okay.

Und ja, man sollte das natürlich auch überhaupt nicht unterschätzen, weil vom PUC zum MVP und das ist dann ja noch ein simples Produkt, das ist oft nochmal Faktor 10 vom Aufwand her.

Ich glaube, das ist halt total schwer, kennen wir vor allem, wenn man am Anfang so ein bisschen geprototyped hat oder vielleicht mit kleineren Daten gearbeitet hat und dann muss man auf einmal vermitteln, ja, jetzt brauchen wir aber nochmal ganz viel Zeit und die denkst du, hey, ihr habt uns doch gerade die Ergebnisse gezeigt, die sind doch da.

Und ja klar, das ist natürlich auch schon nachvollziehbar von außen, deswegen ist es einfach wichtig, das richtig zu kommunizieren.

Ja, ich wollte gerade sagen, schwer zu

kommunizieren, das finde ich auch ein Hauptproblem, gerade bei so Kunden und Technologie.

Ich meine, kann man ja verstehen, dass jemand sich dann ein bisschen an der Nase rumgeführt fühlt oder einfach schlecht informiert fühlt.

Ja, ja, ja, schwierig.

Ja.

Ja, und dann gibt es natürlich auch immer noch den Bereich Monitoring und Wartung.

Also das, wo wir jetzt auch gerade in dem Projekt mit der Senatsverwaltung drinstecken, seit schon einigen Monaten, da haben wir natürlich Alerts, wenn irgendwo ein Prozess abbricht, wenn es irgendwo einen Fehler in einem Pod gibt, dann müssen wir das natürlich wissen.

Aber es kann auch sein, dass die durchlaufen ohne Fehler, aber trotzdem irgendwas, das stimmt und vielleicht nur für halb Berlin Prognosen erstellt werden oder nur für einen halben Tag.

Und deswegen sind dann da auch Alarme definiert, die gucken, ist die Anzahl, entspricht die Anzahl der Prognosen in der Datenbank auch tatsächlich unserer Erwartung.

Man kann auch definieren, gibt es irgendwelche unerwarteten Werte, extrem hohe Prognosen beispielsweise oder gibt es unerwartete Werte in den Input-Daten, Werte, die vielleicht überhaupt nicht definiert sind.

Und dann auch wichtig ist der Model Drift oder Data Drift.

Das heißt, dass die Daten so nach und nach irgendwie in eine andere Richtung driften und sich verändern oder das Modell so nach und nach immer so ein bisschen schlechter wird.

Aber irgendwann, wenn es das lange genug gemacht hat, dann ist es halt irgendwann nicht mehr gut genug.

Und dann möchte man das ja auch mitbekommen.

Und zum Beispiel bei jedem monatlichen Modellneutraining will man auch mal nochmal die ganzen KPIs, also die ganzen Gütemase sehen.

Oder vielleicht will man sie nicht angucken, sondern möchte halt einfach informiert werden, ob die sich nach einer Weile vielleicht zu stark verschlechtert haben und dann muss man sich einfach nochmal angucken, was los ist.

Was halt eben auch nochmal Zeit, das ist halt nicht ganz fertig und da kann man es für immer benutzen, aber gut, das ist ja auch in der klassischen Software-Entwicklung oft so, dass das so ein bisschen unterschätzt wird, wie viel dann doch noch gemacht werden muss, obwohl es doch fertig ist.

Macht ihr dann eigene Monitoring-Tools oder nutzt ihr da auch eins von den Sachen, die es da so gibt?

Ja, so Redage benutzen wir in dem einen Projekt ja ganz gerne und sonst, ja, wie das, was ich, was ich gerade dann anbietet, ich überlege gerade, was wir sonst auch so haben.

Ja, es gibt ja normalerweise dann Tools, die man da benutzen kann und die man dann zum Beispiel auch an Slack anschließen kann und kriegt dann da Nachrichten.

Weiß ich gerade gar nicht so genau aus dem Schluss.

Es nutzt noch jemand.

Doch, doch, es gibt ganz viele.

Ich versuche gerade meinen Discord anzubinden.

Ah, okay.

Also was ich empfehlen kann für so Monitoring-Geschichten, ist Telegram, weil das halt sehr einfach ist, da irgendwie über die API Dinge zu verschicken.

Also Telegram kriege ich auch Nachrichten für meine Server, falls da irgendwas passiert, was ich will.

Ah ja, cool.

Gut zu wissen.

Ist ja auch nochmal so ein spannendes Thema weg von US-Diensten und so.

Ja, wahrscheinlich, genau.

Das ist natürlich nicht

mehr großen, wenn man kommt, irgendwie an

der richtigen Linse.

Man soll ja sträumen.

Oder breit sträuben.

Ja, das sind eigentlich meistens immer so ein eigenes Server oder sowas, aber wenn die halt dann weg sind, ist halt auch blöd, dann merkt man es halt sonst nicht.

Ja, du musst halt irgendwo anders noch Dinge haben.

Aber ja, klar, es wird dann auch teuer.

Monitoring ist jetzt so ruhig, was passiert denn da jetzt?

Endlich sind alle Bugs weg.

Eigentlich ist alles gut.

Hat jemand den Nähenserver mit in die Tasche gesteckt und drunter gemacht.

Ja, also noch ein ganz wichtiges Stichwort in dem Bereich ist natürlich ML-Ops, also Machine Learning Operations, also eine Mischung aus DevOps und Machine Learning ist das Wort.

Kurzvortrick Cerceratops, oder?

Ja, genau.

Und ja, es ist im Prinzip DevOps, aber Anpassung auf den Datencase, also auf die Arbeit mit Daten.

Das heißt, es kommen noch so ein paar Sachen dazu, wie zum Beispiel, dass man nicht nur Code versionieren muss, sondern auch Modelle oder vielleicht Experimente versionieren.

Und ja, es gibt halt nicht nur Code-Änderungen, die dazu führen, dass die Ergebnisse anders sind, sondern auch jeder neue Datenpunkt kann die Ergebnisse verändern.

Das heißt, da kommt es dann nochmal so mal die Komplexitätsebene mit rein.

Ja, das ist auch eine ganz wichtige Geschichte.

Also ich finde das immer dann schwierig, wenn das halt so verteilte Systeme sind, die gleichzeitig irgendwie rechnen und dann die Sachen wieder zusammenführen müssen.

Da steige ich auch nicht so genau durch, wie man das ordentlich machen will.

Aber dass wenn das so distributed ist, was halt beim Machine Learning auch mal passieren kann, ja?

Ja, aber also würde ich jetzt, also aus meiner Erfahrung, also bei mir ist das eigentlich, also das letzte Mal, dass ich den Fall hatte, dass wir irgendwie sowas verteilen mussten, dann war das wegen, weil die Maschinen 32 Bit waren und nicht mehr als 4 Gigabyte,

wie man auf eine Stadt Maschine kriegte.

Und dann brauchte man mehrere Maschinen, aber danach ist das eigentlich, ehrlich gesagt, also mir nicht mehr passiert, weil.

Das kann schon sein, ja.

Aber ich meine, man kriegt heute so große Maschinen.

Ja, die Preise haben wir uns ja gerade unterhalten, ja.

Ja, aber wenn man CPU,

CPU, die meisten Sachen brauchen auch immer eher CPU, dann das ist nicht so teuer.

Okay.

Und wenn du dann so eine ganz große Maschine hast und die ist teuer und dann kannst du den Code so optimieren, dass es viel, viel billiger wird, dann ist das doch auch ein tolles Erfolgsergebnis.

Ja, wir gerade schon mal optimieren sind, wie ist das denn mit Performance zum Beispiel?

Ich glaube, das ist noch was gewesen, wo wir sprechen wollten.

Ja, also da könnte man natürlich auch eine ganz separate Folge dazu machen, aber grundsätzlich ist es auch natürlich ein spannendes Thema.

Also was mir da immer mal wieder auffällt, das ist das manchmal, ja wenn man eben die Funktionen durchkennt, die eigentlich dafür da sind, mit Datensätzen zu arbeiten, dann kann es etwas methodenperformant werden, weil man zum Beispiel über den ganzen Datensatz loopt, obwohl man Sachen auf die ganze Spalte anwenden könnte und die sind dann in NumPy und sind halt total optimiert.

Und da

gibt es eine Menge Sachen.

Also natürlich, ich glaube, treffen alle Sachen zu, die generell auf Softwareentwicklung zutreffen.

Die treffen natürlich auch bei Daten zu und dann kommen noch ein paar Sachen dazu.

Also zum Beispiel Umgang mit großen Datensätzen.

Da hat man eben schon mal angeschnitten, dass das natürlich Spark gibt, aber es auch nicht unbedingt total schnell immer ist.

Und manchmal ist es aber auch echt ausreichend, auf einem Sample zu arbeiten, weil wenn ich eh schon Millionen von Zeilen habe, dann werden die weiteren zehn Millionen von Zeilen meistens auch nicht mehr so viel zusätzliche Informationen liefer.

Und dann kann ich mein Modell auch auf einem Sample trainieren.

Ich kann ja immer mal noch das checken, ob es wirklich nicht immer viel besser wird.

Das ist sowas, was man im Blick haben sollte.

Ich gucke mal gerade noch, ich hätte damals so eine Liste.

Ja, Polers ist eben auch schneller als Pandas.

Es gab auch vorher noch ein, also es gibt auch immer noch das Paket Data Table, aber ich glaube, das ist einfach gar nicht mehr so interessant, jetzt wo es Polers gibt.

Dann ja bei der Datenbank ist es auch manchmal ganz interessant, weil die sind oft eher darauf optimiert, dass man kleine Mengen von Daten abruft oder hinschreibt.

Und wenn man dann auf einmal mehrere Millionen Zeilen hat, dann werden die so Stück für Stück abgerufen und hingeschrieben, je nachdem welchen Treiber man nutzt.

Und da gibt es dann auch Hacks, wie zum Beispiel, dass man es erst in ein Paket-File oder ein CSV schreibt und dann das im Badge hochlädt.

Da gibt es, das wird jetzt schon ziemlich.

Ja, mit dem

Paket-Files, da wollten

wir aber noch ein paar bisschen drüber reden, wie man das machen kann und auch decktivieren.

Ja, aber genau wenn wir bei Performance sind, so ein ganz generelles Ding, was ich häufig sehe, also gerade auch im Zusammenhang mit irgendwie Dinge verteilen oder so, was ich ganz oft sehe, ist, dass Leute halt grundsätzlich erstmal der Meinung sind, wenn man Dinge verteilt, dann wird es halt schneller.

Und ist aber oft nicht so.

Weil ganz oft ist halt CPU möglicherweise gar nicht das Bottleneck.

Also wenn man, bevor man, bevor man sowas macht, wie Dinge dann verteilen oder so, sollte man vielleicht mal gucken, wo ist denn eigentlich das Bottleneck?

Und da, das ist, ich sehe das so oft, ich sehe das so oft, dass Leute sagen so, ja, das wird nicht schneller oder so, und dann ist es halt I.O.

Und dann ist es halt so, dass Verteilen macht das alles noch schlimmer, weil irgendwie ein Netzwerk ist halt noch viel langsamer als irgendwie quasi lokale SSDs.

Und wenn man halt die Daten in der richtigen Reihenfolge lädt, sozusagen, und nicht zufällig die ganze Zeit auf dem, wenn man sehr große Datenmengen hatte, also so groß, dass sie nicht in den Hauptschlechter passen, wenn die dann sozusagen richtig, also sich jedes, alle Daten immer nur einmal anguckt, dann kann es sein, dass es super schnell ist.

Während wenn

man halt

zufällig auf einem großen Paket-File beispielsweise dann irgendwie immer ein Stückchen hier liest, ein Stückchen da liest, die ganze Zeit random irgendwie zwei Gigabyte I.O.

macht, dann ist das alles total langsam und sieht so aus, als ob es nicht schneller gehen würde.

Und tatsächlich ist es aber eine ganz einfache Optimierung, die dazu führt, dass es halt schnell genug ist.

Also ich würde mal sagen, wenn man so ein MacBook nimmt und das richtig benutzt, sehr schwer, das mit einem Cluster zu schlagen.

Wirklich, sehr schwer.

Also und das ist, glaube ich, auch vielen Leuten nicht so bewusst.

Also das ist halt oft, wird da mit Kanonen auf Spatzen geschossen.

Und das eigentliche Problem gar nicht, äh, wird gar nicht erkannt, sondern ja.

Jetzt wollte ich gerade mit Ibis anfangen, was ja auch so ein bisschen größer ist als ein Spatz, aber

ja, aber gut, das ist ja sozusagen, dass man halt quasi ein Data Frame-Interface hat für irgendwie Sachen, die hinten dran SQL sprechen, oder?

Ja, oder zum Beispiel verteilte Datenbanken oder sowas, ja.

Ja.

Genau, also aber genau, also oft ist es dann halt so, wenn man dann halt irgendwie irgendwas benutzt, was halt SQL spricht, aber hinten dran total verteilt ist, dass das dann halt sehr langsam ist und Leute nicht wissen, warum das langsam ist und sich dann irgendwie genau dran gewöhnen und dann halt, wenn sie ihre Jobs losschicken, halt dann Mittagessen gehen oder so.

Aber und wenn man wenn sie sich vor die Daten irgendwie halt geholt hätten und hätten das auf dem Laptop mit Pandas gemacht, also wäre es viel schneller gewesen.

Naja, solche Sachen.

Aber Ivis, ja, ist gerade

benutzt ihr das?

Nee, habe ich tatsächlich noch nie gehört.

Okay.

Was ich nochmal wiederholen will, ist einfach dieses, ja, guck dir erstmal an, was eigentlich gerade langsam ist, wo dein Standportelneck, weil da sind ja manchmal die Annahmen einfach nicht richtig.

Ja.

Das ist so witzig, dass du sagst, ich habe gerade, ich glaube, letzte Woche habe ich gerade was parallelisiert und dadurch sehr, sehr, sehr, sehr, sehr viel schneller gemacht.

Ja gut, das geht schon

auch, ne?

Das kann natürlich schon manchmal der Punkt sein.

Aber eben das Beispiel war ja eben gerade, dass es dann an der Kommunikation in der Datenbank liegt.

Und wenn man dann.

Also eigentlich ist es trivial, dass man erstmal profilen muss und gucken muss, was langsam ist.

Wenn man es mal gesagt hat, klingt es ja trivial, aber ich glaube, wenn man es zum ersten Mal vergessen ist.

Ich glaube auch,

dass viele Leute, viele Leute halt nicht so bewusst ist, die profilen dann vielleicht auch und sehen dann vielleicht sogar noch irgendwie, wo Zeit verloren geht.

Aber gucken halt nicht auf sowas, wie ist denn jetzt eigentlich, wenn ich jetzt einfach mal ein paar CPUs nehme, kriege ich denn tatsächlich, wird es schneller oder nicht?

Wenn es nicht schneller wird, okay, gibt es vielleicht irgendeine andere Komponente im System, die halt irgendwie dicht ist.

Und dass es halt da Unterschiede gibt, dass halt nicht alles CPU ist.

Das ist oft, habe ich das Gefühl, nicht so, keine weit verbreitete Erkenntnis.

Und ja, aber ja, genau, das ist ganz wichtig, dass man das halt sich einfach so ein Gesamtsystem mal anguckt.

Beim Modelltraining ist es dann tatsächlich schon oft sinnvoll zu parallelisieren, wenn das lang dauert.

Und das ist aber dann auch in den meisten Paketen schon so eingebaut, dass man dann nur irgendwie die Anzahl der Kerne übergeben muss, die das nutzen soll und dann läuft das einfach.

Das ist ganz praktisch.

Genau, aber ich weiß jetzt nicht, also das war jedenfalls, ich habe das auch schon lange nicht mehr gemacht, aber das war zu der Zeit, wo ich solche Sachen gemacht habe, war das halt schwer, das auf mehrere Rechner zu verteilen.

Also auf einem Rechner, ja, genau.

Mehrere Kane, kein Problem.

Aber auf mehrere Maschinen, XV Boost, ja, ja, nicht.

Die Frage ist, wie sehr man das auch manuell machen muss, weil man ja meistens dann sich sein Cluster in Databreaks oder so hochfährt und muss sich darüber gar keine Gedanken machen eigentlich.

Also zumindest als Data Scientist ist das wirklich das, was man irgendwie erwartet wird, dass man da verschiedene Rechner zusammenschließt.

Und dann ist es natürlich manchmal irgendwie schon so, dass man doch wieder auf andere Programmiersprachen ausweichen muss, weil Python and R nicht unbedingt dafür bekannt sind, dass sie total schnell sind.

But I glau, also my erfahren nach is es shown of so that man sehr viel rausholen kann when man sich den Python or R-code nochmal genau anschaut, profiled and then vielleicht irgendwo auch mal die Daten vorher klug filtered or sinnvolles If-Statement verschiebt, weil man auf einmal merkt, oh Moment, oder in einem Loop irgendwas rauszieht, was eigentlich nur einmal passieren muss.

Das sind ja so Sachen, die dann doch schnell passieren.

Wenn man den Code irgendwann so geschrieben und ein paar Mach verändert hat, dann ist da vielleicht irgendwas, was man, also so eine Low-Hanging-Food, was man schon leicht optimieren kann.

Python könnte man ja auch noch schneller kriegen, wenn man will.

Ja, wobei, also ich meine, das ist halt immer die Frage, wenn man es halt, wenn es halt schnell sein soll, dann nimmt man am besten was, was nicht halt.

In Python sind halt was halt langsam halt Funktionsaufrufe schleifen, das ist halt extrem langsam.

Weil wenn man die Schleifen halt in NumPy, nicht als Schleife, sondern irgendwie vektorisiert auf den Daten macht, dann ist es halt schnell.

Und ob man das

jetzt von Python aus aufgeht.

Das ist dann auch dieses Stichwort, dass jemand, der das nicht weiß, eben über den Data Frame drüber loopst du.

Ja, ja, gut.

Das sind schlechter DFI-Terroast.

Ja, aber deswegen, ja, genau, einfach dann eine Maske drauf und dann machst du es halt unten drunter an Pai hier.

Ja.

Ja, also warum ich Ibis eben sagte, du weißt auch, von Wes McKinney ist halt dem Pandasmenschen, der.

Ja, der hat ja eine ganze Menge, der hat auch, der ist auch hinter dem, hinter Arrow, das ist halt so seit einiger Zeit so sein Hauptprojekt.

Ja, genau.

Vielleicht nochmal, was macht Arrow, wenn wir schon dabei sind?

Achso, ja, das ist eigentlich im Grunde so die Grundidee dabei ist halt, dass man vielleicht aus unterschiedlichen, also das ist halt das Problem bei NumPy oder Pandas-Geschichten, also man hat das dann halt in Python, aber wenn man jetzt eine andere Programmiersprache hat und darauf zugreifen will, dann geht das halt nicht.

Und die Idee bei Arrow ist halt, dass man das halt, dass man eine gemeinsamen Daten in Hauptspeicherladeninfrastruktur hat und dann halt Paket-Files quasi oder was auch immer, man lässt halt einen Hauptsprecher und kann dann halt von unterschiedlichen Sprachen auch drauf zugreifen und das funktioniert dann halt.

Genau.

Und ja, ist halt nicht an sowas wie Numper gebunden, was es halt nur für Python gibt im Grunde.

Und ja, das ist jetzt inzwischen, aber glaube ich, liegt das auch unter Pandas drunter und zu größeren Teilen, aber ehrlich gesagt bin ich da in letzter Zeit nicht so viel Data Sans gemacht.

Ja.

Mit Ibis kann man zum Beispiel auch da Pi Spark oder sowas dann berechnen, dass man dann.

Ja, also alles, was irgendwie SQL spricht, kannst du da, soweit ich weiß, ist einfach nur ein Layer, wo du halt ein Data Frame-Interface hast nach außen hin, sodass du es benutzen kannst wie einen normalen Data Frame, aber nach hinten raus spricht es dann halt SQL.

Was halt, ja, wenn ein System hast, das kann, dann ist es.

Ja.

Ja, ich glaube, wir haben schon viel über diesen Prozess zumindest gesprochen.

Mit Crisp sind wir durch.

Ja, eigentlich sind wir durch und dann kann man ja wieder von Anfang an anfangen und den nächsten Next Best Use Case schon unter.

Oder alles, was man schon hart-type nochmal erweitern, über die Gaufanwo anders anwenden kann und so weiter.

Also du

würdest zum Beispiel

sagen, aus deiner Perspektive, es gibt gar keinen großen Unterschied zwischen Data Science und Machine Learning Operations oder Engineering mehr heutzutage.

Oder so.

Ja, also es sind halt alles irgendwie so verschiedene Schwerpunkte.

Bei uns sind jetzt, wir haben schon Leute, die eher Data Science machen, die eher modellieren und andere Leute, die eher in dem DevOps, MLOps-Bereich unterwegs sind oder auch Data Engineering machen, die sich besser mit Datenbanken auskennen.

Aber wir

haben bei uns jetzt nicht so die klare Trennung, du musst das eine oder das andere machen.

Es gibt auch Leute, die machen beides, gehen dann halt eben nicht ganz so krass in die Tiefe, aber haben halt ein breiteres Profil und das ist ja natürlich auch total wertvoll.

Es gibt diese Schwerpunkte,

aber greift

ja alles ineinander.

Und es

ist ja auch so, dass es halt Sinn macht, so ein T-Shape-Profile aufzubauen.

Also dass man in einer Sache schon wirklich gut ist, aber viele von vielen anderen Sachen auch Ahnung hat und da auch was machen kann, dann ist man eben auch flexibler, auch wenn vielleicht ein Reich auf einmal nicht mehr so gefragt ist aus irgendwelchen Gründen, ob das AI den übernimmt.

Macht es natürlich auch Sinn, wenn ich als Data Scientist jetzt nicht weigere, mal das Jenkins-File zu updaten.

Da macht es ja schon Sinn, sich dann mit einem ein bisschen auszukennen.

Ja.

Okay.

Ja, so aus meiner Perspektive ist das, ich meine, das mag jetzt etwas ketzerisch klingen, oder sich vielleicht so Hot Take vorwart.

Ich bin gespannt.

Ich würde sagen, das ist alles Programmieren.

Oder sag mal, so das, was praktisch oft das sozusagen Bottleneck ist bei Leuten, die versuchen, irgendwas zu tun, ob es Produkt umsetzen, irgendwas analysieren oder Modelle bauen oder was auch immer ist, ist halt normalerweise das Programmieren.

Ist halt das Bottleneck aus sowas.

Ja, wenn du so ein bisschen statistisches Grundverständnis schadet vielleicht auch nicht.

Ja, aber du brauchst oft, oder gut, das mag, das mag, das mag dann irgendwie, das mag daran liegen, dass ich das halt, dass ich die Feinheiten dann oft nicht so sehe, aber und dass man da vielleicht Feinheiten machen kann, aber oft scheitert es halt schon an so groben Dingen und dann kommt es auf die Feinheiten auch nicht mehr an.

Ich würde sagen, alle bei uns können programmieren und wenn man jetzt ein Projekt hat, wo alle programmieren können, aber nur die Hälfte hat Statistikverständnis, ist okay.

Wenn aber alle Statistik können und die Hälfte kann programmieren, dann lang halt sich die eine Hälfte der Leute, die halt nicht programmieren können, weil die können da ja immer nur Ergebnisse angucken und irgendwas dazu sagen.

Oder genau, so kann

man das auch aus funktionieren.

Man ist halt hart davon abhängig, dass man, dass irgendwie dieses Programmierdings halt auch funktioniert, weil ansonsten kommt man mit den anderen Sachen.

Es ist halt sozusagen die Infrastruktur, die man braucht für fast alles andere, ja.

Ja, natürlich gibt es halt auch so Programme wie SPSS, womit man Statistikanalysen machen kann.

Das würde ich ganz am Anfang sagen.

Ja, das hat ja auch seine Daseinsberechtigung, weil wenn jemand nur alle drei Monate mal eine Analyse fährt, dann lohnt sich halt eben nicht sicher.

Ja, auch da, da mache ich mir ein Notebook für halt

dann, oder?

Ne, aber die Person macht alle drei Monate irgendwas anderes.

Genau, wie alle drei Monate wieder sich erinnern, wie man eigentlich Variable zuweist.

Und das macht man.

Dann lieber das angestaubte SPSS klicken.

Also ja, mich hat SPSS auch ziemlich schnell genervt, aber ich kann, also es hat schon seine Daseinsberechtigung für bestimmte Dinge.

Oder vielleicht das SPSS des kleinen Mannes so, ich meine, das ist halt auch das, womit man täglich zu tun hat.

Excel.

Ja, ich meine, es gibt ganz viele Leute, die machen halt einen Großteil von dem Zeugs halt mit Excel.

Alle Leute nur in Excel.

Leute machen alles mit Excel, genau.

Ja, natürlich.

Man kommt auch ein gewisses Stück weit schon.

Das ist richtig, aber.

Eine Million Zeichen.

Ich glaube, man hat als Data Scientist auch manchmal so eine Arroganz, dass man Excel überhaupt gerne nicht öffnet, weil man bisher betätig.

Ja, und manchmal

Sachen ist es vielleicht gar nicht so schlecht.

Pelerize.

Ja.

Es hat nicht jemand Excel gesagt, jetzt kriege ich ein komisches Gefühl.

Es ist halt einfach fürchterlich, es ist halt hässlich und dann wollen Leute auch noch, dass man dann in Excel-Spalten dann färbt, weil man macht ja Data Science sowas mit Daten und dann soll das alles so aussehen wie vorher und

es wird alles, ich habe da kein Problem mit.

Ich generiere auch Excel-Output und ich lese auch Excel ein.

Ja, also in schönen Output.

Machst du, machst du?

Ich hab dann eine Aufgabe für dich.

Jetzt, wenn es dann so konkret wird, da weiß ich nicht.

Ich glaube, wir haben sogar so ein Mini-Open-Source-Projekt auf GitHub liegen, für Excel, also um Excel-Files schön zu formatieren und das hat auch geschrieben.

Sehr gut.

Ja, schon.

Ja, das war tatsächlich ein Projekt, da wurden halt die Reports, das war so ein Banking-Kontext und die haben halt die Reports als Excel-File gebraucht, um wahrscheinlich damit die weiterzuschicken, weiter zu verzogen.

Ja, weil denen auch den ganzen Tag das halt

schon kennen, die haben halt ihren Prozess, der ist immer schon so und dann ist es super, wenn dann da die Sachen einfach dann neu sind oder Daten drin sind, aber es soll genauso aussehen mit Condition Formatting und so.

Ja, oder dass man halt Leute, die können halt solche programmieren, ist auch ungefähr nicht okay, weil sie ganz andere Sachen machen, aber trotzdem müssen wir die irgendwie Ergebnisse liefern.

Ja.

Ich glaube, wir sind bei den Picks angekommen, oder?

Ich glaube, Mira, du hattest noch einen, wolltest du was picken, was auch noch mit Data Science zu tun hat.

Vielleicht fangen wir damit doch direkt an.

Ja, also wir haben es schon so ein bisschen angestritten, ich hatte ja eben erwähnt, dass ich was parallelisiert habe und das war total cool, weil diese Prognosen, also das Modelltraining und Prognosen erstellen, das hat halt Stunden gedauert und auf wahnsinnig hohe Kosten verursacht, weil anderes Thema, Pandas, wo er hoher RAM verbraucht.

Das heißt, man braucht einen riesen Cluster.

Und dann ist es aber auch noch total lang gelaufen auf diesem riesigen Cluster, also total teuer.

Und dann habe ich festgestellt, dass die Prognosen alle nacheinander erstellt wurden und alles nur auf dem Driver Node leaf.

Also diese ganz vielen Nodes auf diesem riesigen Cluster, die wurden überhaupt gar nicht benutzt.

Und dann durfte ich das parallelism.

In dem fall with Pandas UDFs, Pandas User Defined Functions.

Also it's not a mic, even that it's in Pandas, but it's a Light GBM Modell and this can im Moment noch kein PySpark Data Frame oder Spark Data Frame nehmen, deswegen muss man den in Pandas given.

Oder wahrscheinlich geht auf Polas, da sind wir jetzt gerade dran.

Aber ja, und man kann dann diese Prognosen in Pandas auf diese Art und Weise parallelisieren und es war einfach so schön und so geil, weil es einfach so viel schneller geworden ist.

Und ich habe mich sehr wie eine Heldin gefühlt.

Ja, Erfolgsstory ist immer schön, ja.

Dann komme ich auch direkt zu meiner Erfolgsstory.

Ich hatte nämlich auch so einen Moment, ich habe nämlich Hinux neues Video gesehen und das ist Just Love.

Also ich habe Just Files für mich entdeckt.

Die hatte

ich vorher nicht so auf dem Schirm, dass das so ein bisschen was ähnliches wie eine Make-File, nur dass man halt in einer Just-File, das ist auch ein Rust-geschriebenes Tool, definiert, wie so die Projektkommandos eigentlich alle sind.

Und dann kann man, dass die sind wundervoll mit Variablen und so.

Es funktioniert toll.

Henix-Video dazu zu gucken, glaube ich, ist sehr hilfreich.

Und ich habe alles umgestellt bei mir.

Ich benutze fast meine Commands nicht mehr, also meine Commands-Py noch ein bisschen selten, sondern einfach nur Just, Just Run und das

heißt, der Server läuft.

Oder Just Connect für DevServer oder sowas.

Oder für auch Pod-Server, dann kann ich sagen Just Connect Production und dann noch den Podnamen oder sowas, was ich auf den Kubernetes muss.

Oder ich kann sagen, Just Lint oder Just Test und so.

Es ist toll.

Ich liebe es.

Das ist ja auch echt eine gute Entscheidung für den Namen.

Also ich finde es auch.

Ja, ja,

voll gut.

Finde ich auch.

Deswegen Just Love.

Okay.

Ja, ja, ich habe ja auch tatsächlich, nachdem ich das Video von Hünder gesehen habe, habe ich mir auch gedacht, so, vielleicht muss ich das auch mal ausprobieren.

Ja, ich meine.

Das ist toll.

Du kannst danach ein Justbild und der machst mit UV, macht deine Direktpaketinstallation, Paket Sync, du kannst ein Upgrade machen, alle Sachen mit den Kommandozeilen, die du sonst immer nutzt, reinschreiben.

Und wenn du das über so eine Command-Spiel geregelt hättest oder sowas, musst du halt immer dann einen Supprozess bauen und so, ah, ich weiß nicht.

Das ist eine Just weiß schon sehr schön.

Ja, nee, was ich häufig mache in letzter Zeit, ist halt einfach Entry Points im, weil meistens hat man ja ein Paket, das man installiert.

Das würde ich jetzt nicht so sehen.

Ja, kommt drauf an, aber also ich habe das halt oft und dann kann ich halt auch irgendwie in PyProject Tummel halt unter Scripts halt andere Entry Points definieren und dann habe ich halt Funktionen.

Dann habe ich es jetzt nicht in der Command-QI, sondern ich schreibe dann halt einfach Python.

Aber ja, es gibt natürlich Dinge, wo man nicht einfach Python schreiben kann, wenn man Datenbank hoch und runterfährt oder solche Sachen.

Ja klar, dann muss man irgendwie das machen.

Also das dB zum Beispiel ist das andere oder Shell-Skripte da reinschreiben, wenn du willst, dir dann Sachen hintereinander machen und so.

Oder Tests machen oder gucken.

Du kannst Environment-Variablen da reinladen oder spezifisch, wenn das da irgendwie passt.

Und du hast gerade eine Sache gesagt, Pakete, also du könntest ja auch einfach aus der Pipe-Dock tun mal das Py-Skript dann ausfüllen lassen.

Und bei mir ist zum Beispiel so, dass die Dinge im Python in einem anderen Verzeichnis liegen als das Projekt und die Dokumentation oder sowas.

Und trotzdem, wenn ich das Just benutze, benutze es halt dann auch den Kontext.

Du kannst Work and Directory essen.

Toll.

Ja, okay.

Also ich muss mir vielleicht auch nochmal angucken, was ich.

Ja, mach das.

Breaking.

Misockzeit.

Geht nicht mehr weg.

Okay.

Naja.

Ja, genau.

Ich habe gerade überlegt, was ich picken könnte.

Ich habe mir gar keine Gedanken gemacht, aber ich bin ja jetzt in letzter Zeit so ein bisschen besessen von nur ein bisschen.

Von besessen oder das Besessen.

Ja, ich mache ganz einfach Cloud-Code und Dinge mit LLMs irgendwie programmieren.

Das ist schon verrückt.

Also ich weiß nicht, ob du das ausmachst, Mira, aber die Kosten sind halt krass.

Wir benutzen jetzt halt Max.

Das ist halt das Abo, wie du das 200 Euro?

Ja.

Ja gut, es gibt auch 1200, aber.

Ja, okay, aber das ist halt das 20.

Normalerweise müsst ihr halt 3000, 4000 Euro Token-Kosten zahlen im Monat dafür.

Ja, aber das würde ich jetzt dann picken.

Es gibt da ein NPM-Paket, CC-Usage nennt sich das, kann man per NPX zum Beispiel installieren.

Und dann sagt einem das quasi, für wie viel Geld man Tokens verbraucht hat.

Und damit kann man sich sehr schön rationalisieren, dass das gar nicht so viel ist, wenn man 200 Dollar im Monat zahlt.

Weil ja.

Wie viel hast du diesen Monat?

Auf dem Rechner hier 2000 Dollar Tokens.

Und ich habe aber auch noch andere Rechner auf denen auch.

Und das ist erst der 17.

heute, glaube ich.

Die sind gefährlich, die Dinger, die machen uns alle obsolet.

Wir werden sehen.

Ah, das glaube ich nicht.

Man sitzt dann am Strand und nimmt an seinem Schirmchen und redet dann mit seinem, keine Ahnung, kleinen Roboter, der neben einem herläuft, der nebenbei noch unterhält, dass man weiterentwickelt und unterhält sich dann wie im Podcast.

Da haben wir jetzt schon mal gut

geübt jetzt.

Also ja, man muss so ein bisschen vorsichtig sein, weil natürlich wird man halt irgendwie so ein bisschen zu so mal, man schreibt dann halt nur noch so Anforderungen hin und so versucht das genau zu spezifizieren.

Man befördert sich selbst zu so einer Art Projektmanager.

Und dann macht man einen ganz anderen Job und da muss man so ein bisschen aufpassen, dass das, weil dann nachher, weil eigentlich, also ich mache das nicht so gut.

Was ist denn mit Programming for

Page, ja.

Genau.

Und ja, wenn es keinen Spaß mehr macht, weil ja, es ist halt, dann hat man sich irgendwie.

Doch, was wird Holz machen.

Mein Freund nutzt tatsächlich für die privaten Projekte auch viel Cursor und er sagt so, ja, das, worauf ich Bock habe, das schreibe ich da trotzdem selbst.

Ja, das ist auf jeden Fall

eine hart die Idee wahrscheinlich.

Und sonst ist er halt ja der Projektmanager, der seinen Julia quasi immer gucken, was der macht.

Ja, also bei mir hat auch Cursors raus, hat Winterfort eh verkaufen, aber Cursor ist raus, nur noch Cloud Code, also nur noch Kommandoteile und ich bin wie jetzt Code.

Das ist super.

Das also kann ich nur empfehlen.

Das ist verrückt.

Ist gerade verrückt.

Es macht halt so viel schneller und dann reicht das so nervige Sachen ab.

Aber ja, man wird irgendwie mit einem Projektmanager, Projektmanagerin und ich glaube, das Thema Kommunikation wird halt immer noch wichtig bleiben.

Ich hoffe

ja, dass das Ding auch meine Stimme hat und dann bessere Kommunikation

mit den anderen Leuten.

Das wäre, genau, das habe ich ja auch mal gehofft, dass ich irgendwie, warum, genau, während meine Cloud Code-Jobs da halt laufen, kann ich dann habe ich mehr Zeit, um irgendwie Meetings mit Kollegen irgendwie da irgendwie Pläne zu besprechen.

Das sollte umgekehrt sein.

Ich will lieber programmieren und dann kann irgendwie, was ich nicht, in so ein Avatar, in so ein Meeting auftauchen und immer sagen, das ist eine super Idee.

Voll gut.

Genauso machen wir das.

Kann doch kluge Dinge sagen, jo.

Du kannst das Training unsere Podcast-Folgen eingeben.

Ja, ja, okay.

Ja, es ist einiges ungekremt.

Ja, so könnten wir, wir haben halt manche Leute, die hätten wirklich was Spannendes zu erzählen, aber trauen sich nicht so richtig im Podcast, kann ich verstehen, ist okay.

Aber wenn man dann die Stimme einfach nehmen könnte, dann können sie einen Text schreiben und dann könnte man den Podcast einfach generieren.

Ja, das geht.

Das kann man ja eigentlich auch schon.

Also die neuen Modelle von

Jamie dazu, die ich gehört habe, ich glaube, es gibt ja noch andere, die wissen wir ja jetzt ersetzen, dass das verrückt, wie gut die sind und wie natürlich die auf einmal klingen, ja, dass das.

Also Stimme LM Labs hat da supermodelle, aber fürs Generieren von Podcasts, Notebook-LLM, da geht einiges.

Das ist crazy, ja.

Danke, Mira, dass du da warst.

Ja, sehr gerne, hat Spaß gemacht.

Also denk dran, Hörertreffen am 20.

September.

Ja.

Und ja, kommt vorbei, hört uns.

Hallo at Python Podcast.de, alles Feedback, alles und so weiter.

Vielen Dank, bis bald.

Alles klar.

Und hört auch gerne meine Data Science Deep Live rein.

Genau.

Großempfehlung.

Bis bald.

Bitte.

Sein Tal.

Tschüss.

Tschüss.