Hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, heute Episode 67, wir reden über Data Science.
Hallo Dominik und herzlich willkommen.
Hi Mira.
Mira, hallo.
Schön, dass du da bist.
Normalerweise fangen wir immer mit News an, da hat doch gesagt, haben wir heute gar nicht so viele und die letzten sind auch 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 du aber erstmal was über dich und stellst dich kurz vor und dann sprechen wir über 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.
Man muss auch sagen, dass man in der Psychologie schon auch Fehler haben, Analyse und Statistik macht.
Und da hat es mir noch nicht gereicht.
Deswegen habe ich dann noch einen Statistik-Master dran gehängt und bin dann so in der Statistik-Beratung 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 erinnern sich die Begriffe ein bisschen und es 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 ein bisschen mehr mit R unterwegs.
Ja.
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.
Ich glaube, dass man 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.
Wir haben ja noch ein paar, 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 auch 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 Body Leasing mäßig dort mit im Team.
Und bin dann klassisch als Data Scientist im Team drin und das macht mir auch ganz großen Spaß.
Wir haben teilweise länger laufende Projekte, aber auch manchmal Einzelprojekte, die nur ein paar Monate sind.
Und das ist natürlich auch total spannend, weil man dann sehr viel Abwechslung hat und in verschiedene Themen reinkommt.
Und wir haben auch einen Podcast, das ist der Grund, warum ich jetzt hier sitze und ihr mich kennt.
Ein Unternehmenspodcast, in dem ich manchmal, aber auch nicht immer zuhören bin, wo wir ganz viele Themen rund um Data Science besprechen, den Data Science Deep Dive.
Genau, das war sehr spannend.
Ja, habe ich auch schon reingehört, fand ich sehr gut.
Ja.
Ja, gut.
Also, was ist denn eigentlich Data Science?
Ja, also ganz geschwollen 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 vorlehr 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 Gynämetrie oder so.
Ja, also Statistik ist auf jeden Fall, ja, ein Teil ist ja auch so, manche sagen, ja, Statistik oder Machine Learning, das überschneidet sich aber an ganz vielen Stellen.
Ja, klar.
Ja, man sagt ja auch oft, man braucht so drei Bereiche.
Das eine ist die fachliche Expertise, also ich kenne mich zum Beispiel aus mit, ja, einfach 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 Statistik und Machine Learning 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 eine neue.
Wir haben in unserem 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 dem man darüber reden kann.
Gemeinsame Sprache zu finden.
Genau, 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, sind auf der anderen Seite vielleicht ein bisschen schwieriger.
Aber ihr seid dann auch meistens tatsächlich, du hast es eben schon angesprochen, Body Leasing, also quasi in den Teams selber unterwegs.
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, sehr, sehr unterschiedlich.
Also wir sind für einen langjährigen Kunden sind wir eigentlich fast so wie eine zweite Data Science Abteilung.
Wir haben auch selbst eine Data Science Abteilung, aber die Aufgaben sind dann so 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 Body Leasing.
Das war früher irgendwie kaum, weil früher hatten viele Unternehmen auch selbst keine Data Science Abteilung.
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.
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 einfaches 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 weiter empfohlen werden.
Wir haben zum Beispiel was im Sportwettenbereich und da kann man sich ja vorstellen, wenn man mal überlegt, wie sag ich eigentlich vorher, wie viele Tore von diesen beiden Mannschaften in diesem 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 Statistik hintergrund auch ganz schön Spaß.
Manchmal sind die Sachen halt noch ein bisschen sinnvoll.
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 vor allem auch Wirtschaft.
Ich habe ja Lehre 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 Statistikmaß, da waren viele, die vorher Mathe gemacht haben, aber auch viele mit ganz anderen Hintergründen.
Viele Wirtschaftswissenschaften, aber auch KollegInnen mit Soziologie Hintergrund oder Physik.
Ich glaube, das ist sogar so ein bisschen ein Klassiker, dass die Physiker sich irgendwie dann in die Statistik und Machine Learning,
in die Machine Learning Welt verirren.
Und wir haben noch gar nicht so lange, haben wir auch jemanden mit Informatik Hintergrund.
Das klingt irgendwie witzig.
Wow, das hat er jetzt auch.
Nur Leute, also der ist jetzt schon, ich glaube schon drei Jahre bei uns, aber ja, vorher hatten wir 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 Studiengänge 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, 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,
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 dann da probibliert haben oder so, dann da probibliert haben, genau, ganz oft aus der Ecke eher.
Und die eher so, 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 eben in diesem ganzen.
Und da wolltest du ja auch nochmal was zu sagen.
Wie du das so findest mit den Softwareentwicklern zusammenzuarbeiten.
Aber vielleicht noch erst dazu.
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 dann sind zwei Sachen zusammen und BI-Abteilungen sind, glaube ich, auch nochmal,
aber 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, ich dachte eben, ne.
Ohne Wertung zu sagen.
Oh, 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 Softwareentwicklungshintergrund 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.
Und das, also, 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 gedubt ü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, ist,
dass jemand, der nicht viel mit Daten gearbeitet hat,
muss halt so nimmt, wie sie sind und da irgendwie ganz unkritisch ist
und gar nicht sieht, wenn irgendwelche Zahlen ganz komisch aussehen.
Und manchmal ist ja vielleicht der Code gar nicht falsch,
aber es ist irgendwo ein Denkfehler drin.
Also der Code macht, was er soll, nur das, was er soll, ist halt vielleicht gar nicht so korrekt.
Oder man hat ein Missverständnis zu den Daten, man hat irgendeine Annahme,
aber in Wirklichkeit ist das ein bisschen anders.
Und das ist was, was dann, glaube ich, schwer fällt.
Also ich glaube, das fällt einem als Data Scientist auch schon,
manchmal schwer, so richtig dieses Business Understanding aufzubauen.
Aber ja, wenn man so reine Softwareentwicklung macht,
ist es, glaube ich, noch mal schwieriger, in den Daten drin zu sein und die zu interpretieren
und zu sagen, Moment mal, also die Kurve sieht ja echt komisch aus.
Aber also eigentlich mag ich es total gerne, wenn das Team gemischt 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 kommt, 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 vielen 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 mal sehe,
was so Data Scientists schreiben,
dann steige ich mir die Hände über den Kopf.
Es gibt natürlich Unterschiede,
aber das ist immer so im Vergleich eher anders,
als ich das machen würde wahrscheinlich.
Also man schreibt als Data Scientist oft so die ganzen Prozesse untereinander
und muss erst mal lernen, die Methoden zu definieren und so.
Und warum soll man denn, also wenn man das nur einmal macht,
warum soll man denn eine Funktion schreiben?
Man kann es ja Zeit für Zeit 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,
wenn man einfach mehr aus der Analyse kommt
und da so quer einsteigt.
Ich finde das immer einfach manchmal,
wenn Leute schon promoviert haben
und das ist,
die haben total krasse Sachen gemacht,
aber können dann halt auch keinen guten Code schreiben,
weil es für die Doktorarbeit eben ganz andere Anforderungen hat.
Ja, da ist auch oft,
also gerade Physiker,
die sind da ja oft eher so verdorben.
Die haben dann irgendwie Vortragen geschrieben oder sowas.
Oder C++,
das ist 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 nirgendwo,
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,
die 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?
Du könntest erst mal die Kirchturmspitze ausrechnen,
dass die Höhe dann 245 Minus ist.
Und wenn man das dann einfach so übernimmt
und daran glaubt.
Ja, genau.
Also, das ist natürlich ein gutes Beispiel.
Manchmal habe ich auch den Eindruck,
dass dann wiederum,
wenn man sehr,
sehr stolz auf seine Software-Entwicklung-Skills ist,
dass dann auch unnötig komplizierte Patterns
auf irgendwelche Sachen geworfen werden
und das dann auch wieder so 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
in einem Elfenbeinturm baut,
dann, ja,
war das vielleicht auch einfach am Ziel vorbei.
Wenn man auch neue Pattern gelernt hat,
muss man die auch erst mal,
überall anwenden, ja.
Ja, klar,
das sollte ich auch machen, ja.
Ja, aber grundsätzlich machen das eigentlich total Spaß,
mit Software-Entwicklern 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 nochmals hin,
das ist irgendwie datatowiz.com oder sowas.
Die benutze ich immer,
wenn ich nicht weiß.
Ich kann nicht sagen,
dass ich so gerne.
Also,
er macht es durch die ganze Zeit,
aber es ist an verschiedenen Stellen eigentlich,
total wichtig,
also zuerst mal,
wenn man die Daten reinbekommt,
dann sind wir jetzt eigentlich schon so mitten im typischen Ablauf,
aber ich kann da,
da wollen wir zwar noch darüber sprechen,
da kann er gerne mal 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,
klar,
ist auch ganz nett,
so Mittelwerte und Ausgleichsmaßnahmen
und Minimum zu sich anzugucken,
zum Beispiel,
ob der kleinste Kirchturm auch wirklich größer als 0 Meter ist,
aber es macht natürlich auch total Sinn,
sich da die Verteilung mal zu gucken,
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
oder das einfach,
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,
da waren auch weniger mit Dashboards und so weiter,
da war es oft noch so,
dass wir so einen Datendump bekommen haben
und hatten damit dann was gemacht
und da waren wir noch in R unterwegs
und haben für ggplot2,
ggpl 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 AWS 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 leider vergessen.
Notley Dash,
oder?
Das ist 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 nutzen wir auch sehr gerne.
Okay.
Und wie läuft denn so ein Prozess bei euch ab?
Ihr habt jetzt irgendwie Daten,
ich glaube, du wolltest auch noch mal drauf eingehen.
Ja, gerne.
Und so einen Auftrag und dann?
Also klar, manchmal steigen wir auch mittendrin ein,
aber ich fange jetzt trotzdem mal vorne an.
Oft sind wir auch vorne dabei.
Das ist jetzt so ein bisschen
vor allem aus meiner Sicht als Beraterin.
Das fühlt sich natürlich ein bisschen anders an,
wenn man im 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 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 das was sagt.
Das ist der Cross-Industry Stand-Up Process
for Data Mining.
Data Mining klingt so ein bisschen angestaubt,
der Begriff,
aber man könnte es halt einfach
Datenprojekte nennen.
Und ja, am Anfang,
es ist bei uns dann tatsächlich auch so,
dass KundInnen zu uns kommen
und schon was haben,
was sie haben,
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 zu verstehen, warum sie das brauchen
und was sie wirklich brauchen.
Und vielleicht ist es dann doch so ein bisschen anders.
Und ich meine,
zu diesem Thema kann man ganze Workshops,
mehrtägige Workshops machen.
Es gibt ganze Unternehmen, die nichts anderes machen,
als Use Cases zu identifizieren und zu prüfen.
Das können wir auch ein Stück weit mitmachen,
aber das ist nicht unser Schwerpunkt.
Also ist das meistens dann schon
eher so, dass da schon Ideen da sind.
Wir aber das auch alles nochmal so ein bisschen challengen
und einen Kick-Off haben,
wo wir mit den Kunden sprechen,
um das Geschäftsmodell zu verstehen,
um genau zu verstehen,
wer das eigentlich nutzen wird,
was die genau machen wollen.
Es 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 genauer?
Ist es 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.
Braucht ihr die dann auch?
Also baut ihr irgendwo neue Sensoren ein oder sowas
und kümmert euch darum,
dass sie in irgendwelchen Datenbanken landen,
die ihr dann zur Auswertung mit benutzt
oder geht ihr davon aus,
dass 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
so, dass sie sagen,
wir wollen hier dieses superkomplexe Modell,
aber wir haben noch gar keine Daten,
wir müssen die erstmal sammeln.
Normalerweise sind die da schon
relativ weit oben auf der Datenreifeskala
und selbst wenn nicht,
sind die Daten meistens schon da,
weil ganz viele Daten ja 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,
sind die Daten da, die man braucht
und wenn sie nicht da sind,
dann ist das erstmal noch ein weiter Weg normalerweise,
weil vielleicht ist es nicht mehr ein richtiges Ding,
da ist ein weiterer Warehouse da
oder man kann die nochmal zusammenführen.
Das ist oft dann,
dann ist es noch ein weiterer Weg,
bis wir da 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 darauf 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 dann nach und nach einsteigen.
Aber es gibt ja auch Geschäftsmodelle,
die eigentlich nur so gut funktionieren,
weil mit Daten gearbeitet wird
und dann muss das wahrscheinlich von Anfang an
auch berücksichtigt werden.
Also ich habe ja noch nie ein 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,
also 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 Technologien 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 Scikit-Learn dazu
oder TensorFlow, Keras, PyTrips,
eigentlich so die Klassiker.
Pandas ist ein interessantes Thema,
weil Pandas,
also wer schon mal mit Pandas im Kurs ist,
man Daten gearbeitet hat,
denkt sich jetzt um Himmels Willen,
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, PySpark umzusteigen,
was auch jetzt in letzter Zeit
ganz gut funktioniert.
Also das ist natürlich toll,
weil es ganz verteilt ist,
wobei es nicht unbedingt schnell ist,
aber es kann halt eben
mit großen Datensätzen umgehen
und man hat 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 so halt...
Aber ich meine,
die Erfahrung, die ich oft mache,
ist, dass man die,
bei vielen so kategorialen Variablen oder so,
die kann man dann halt auf irgendwie
einen kleineren Datentyp
irgendwie runter komprimieren
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.
Oft hilft das
dann schon, aber ja, stimmt.
Aber manchmal, wenn man die Daten einliest, dann
je nachdem kann man das, glaube ich, gar nicht unbedingt
spezifizieren am Anfang und dann sind die
einfach groß.
Oder auch selbst wenn, also ich meine,
so mehrere Jahre stündliche Verkaufsdaten
von ganz vielen Artikeln aus ganz vielen Filialen
aus mehreren Ländern.
Dann, ja,
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 du das nicht kennst, Polars, das ist ein Rust
nachgeschrieben mit der gleichen API, so ein bisschen wie Pandas.
Ja, es ist, ne, es hat
sehr viel saubere, also kleinere,
es hat weniger Funktionen, aber es ist halt
auch ein bisschen konsistenter, weil
Pandas ist halt auch irgendwie sehr stark
so historisch gewachsen
und man wusste noch nie genau, wo man hin will
und dann teilweise inkonsistent und
ja,
ja, Pandas ist halt, ja.
Wie das halt so ist. Genau, wie das halt so ist.
Ich habe noch gar nicht so viel mit Polars
gearbeitet. Ich weiß gar nicht, ob die
eigentlich schon das Ziel haben, da die
meisten Funktionen aus Pandas
auch zu implementieren oder ob die vielleicht sogar
sagen, es soll schlanker bleiben, weiß ich gar nicht.
Ich meine, also sie sind absichtlich,
wollen sie nicht komplett irgendwie alles
machen, was Pandas halt kann, sondern
ja, 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 oder?
Ja, manchmal so für kleine Sachen,
wo es gerade Sinn macht.
Oft
sind ja, ist man mit Datensätzen unterwegs
und dann passiert es halt meistens
in Pandas.
Vielleicht hast du eben gesagt, man muss
erstmal wissen, was ein Datensatz ist, bevor man jetzt drüber
redet. Du meinst jetzt irgendwie, du hast eine Maske auf,
mit der du guckst oder
was?
Was ist ein Datensatz in Pandas?
Ist das jetzt eine Wissensfrage?
Ja doch, du müsst ja vielleicht schon erklären,
wie das funktioniert.
Ja, um die Daten
anzugucken, würde ich,
na gut, 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 drinstehen 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, je nachdem, 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ürt 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 ist, natürlich
in die Summary Statistics
gehen. Und es ist auch oft,
also selbst wenn man jetzt nach
dieser ersten Datenanalyse aufhören
würde, ist es oft an sich schon
ganz interessant und
oft haben unsere
KundInnen ja genau diese Analyse
auch noch nicht gemacht und lernen dabei auch noch was Neues.
Einmal hatten wir aber sogar
auf den Fall, dass wir, ja,
dass sie dann gemerkt haben, dass da irgendwo viel
an 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 haben es dann
gesehen durch unsere Datenvalidierung,
dass da irgendwo ein Problem ist beim Zusammenführen.
Ja, spannend.
Also manchmal sagen sie mir das. Ich habe einmal den Fall
gehabt, dann waren die ganze Zeit irgendwelche
so Irregularitäten irgendwie,
in so einem Datenflur, die da gar nicht hingehörten.
Man hat irgendwie was bewundert, was ist denn das?
Irgendwann ist jemand auf die Decke gekommen, ist dann zum Förderbank gegangen,
hat in die Decke geguckt und da war
oben ein Fenster auf und dann war dann die
Temperatur immer anders, weil dann das Fenster
aufgelassen worden ist und so. Das war spannend, ja.
Cool ist natürlich auch, 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, 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 begleut 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 Standard
Ding 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.
Ja, aber tatsächlich, wir sind ja dann
oft eine Infrastruktur von den Kunden unterwegs,
aber nicht immer, weil manche, zum Beispiel hatten wir
ein Projekt, da darf ich zum Glück auch
drüber reden, darf man ja nicht bei jedem Kunden, das war für die
Berliner Senatsverwaltung, eine Luftschadstoffprognose,
also die läuft auch noch, aber das
machen wir jetzt nur noch Wartung, das ist soweit 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 mir gerade nebenbei in unseren
Blogartikel rein dazu,
weil da
kann ich mich alles nochmal wieder nachgucken,
wie wir es gemacht haben.
Da haben wir,
konnten wir ganz frei entscheiden, was wir
haben wollen und haben
dann mit
Kubernetes gearbeitet,
das ist 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 in der Grunde eine Clickhouse-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 Relash 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 in der Tabelle,
wie wir erwarten würden und so weiter
und in dem Projekt ist tatsächlich
nur, im Hintern haben wir Relash
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 Nats-Verweigerungen
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 es natürlich immer ganz
schön, ansonsten
bei einigen Kunden läuft dann viel
mit den Diensten von AWS,
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 nachher andere, deshalb bin ich
auch immer nur so am Rande natürlich dabei,
kann irgendwie in die Kubernetes-Codes mal reingucken,
aber ich kann,
kann das nicht 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 Filefield 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 so
auf jeden Fall nach, gibt es da nicht irgendeine
einfache Möglichkeit, wie man das machen kann?
Ich weiß nicht, ob es einfacher ist, aber
wir sind auch ganz wenig eigentlich
mal in Jupyter-Notebooks unterwegs,
sondern
ja, entweder, wenn wir was schnell visualisieren
wollen, geht das tatsächlich ja mit so einem Tool wie
Redash auch schneller, als wenn man dann anfängt,
mal Plotlip-Code
zu schreiben,
dann das Clicky-Bunty 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 das dann meistens
so, dass jedes Mal beim Push in den
Main-Branch,
wenn die, zum Beispiel, wenn die Versionssumme sich geändert hat,
wird das dann, wie bei Jenkins,
wird ein 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 uns dann halt überlegen.
Ja, aber dann brauchen wir einfach,
ja, aber dann brauchen ja die
Leute, die quasi modellieren, Zugriff
auf das Produktionssystem
quasi oder können halt,
die müssen den Code verändern, die müssen
committen können.
Ja, also die committen von
morgens bis abends.
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
ja, ist es halt
eine Software und sonst
auch oft in größeren Projekten mehrere Pakete.
Zum Beispiel in dem
Projekt für die Senatsverwaltung sind das 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
einzulegen und zu formatieren, die Datenbank
zu schreiben. Das heißt, der Handshake ist dann über die Datenbank,
dann kommt irgendwann das nächste Paket,
das liest sich die Daten dann und macht dann die
Modellierung. Und dann gibt es nochmal ein Paket,
das halt irgendwelche Daten
weiter aufbereitet und dann gibt es ein Paket mit der
API. Und das, also wenn
ein Modell daraus gebaut habt, irgendwie mit
Torch oder sowas, was macht ihr dann?
Wo legt ihr das dann hin?
Ja, wenn das dann in dem Fall
tatsächlich,
also tatsächlich
im Kundenprojekt benutzen
wir MLflow und ich weiß
nicht, ob, also ich hatte das vorher
tatsächlich noch nicht benutzt, wo 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 ganz gut, man kann aber
natürlich auch das Modellobjekt irgendwo
in
Modellrepository dann ablegen.
Also eigenes Modellrepo mit
Branches oder irgendwie Tags oder
sowas hier. Ja, oder
ähm,
ja, irgendwelche Tags muss man natürlich
schon haben, damit man die dann nachher wieder identifizieren kann.
Ja. Also gut, wenn
jetzt die Modellierung total schnell geht,
dann kann man natürlich auch das Modell einmal im Monat
neu berechnen, oder nee, dann
einmal im Tag neu berechnen, sofort die Prognosen machen
und das Modellobjekt überhaupt nicht speichern, aber das
ist, glaube ich, eher so ein seltener Fall. Normalerweise
muss man das ja schon speichern.
Wiederverwenden.
Also, wir können uns auch gerne
nochmal an dem Ablauf ein bisschen
weiter entlanghangeln. Ja, gerne.
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 Datenaufbereitung 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's
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 man
sich halt irgendwas überlegen, wie man das
dann voll aufaggregieren kann. Manchmal
macht man Transformationen oder berechnet
eine neue Spalte aus
anderen Spalten. Also, das
ist das, was man immer 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 auch
in eine Datenbank rein?
Es kommt darauf 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 modulisieren, weil es sonst
ein bisschen zu viel wird.
Was ist da eure Datenbank für?
Ich überlege gerade, wir waren
früher viel auf MariaDB unterwegs,
jetzt sind wir
viel in Clickhouse, also Clickhouse
teilweise verhält es sich unerwartet,
finde ich. Aber es ist
halt schon sehr cool mit großen Datenmengen,
da kannst du einfach die
anpassen.
Das ist diese Geschichte,
Yandex hat das glaube ich mal gebaut
und dann haben sie es irgendwie Open Source
veröffentlicht. Das weiß ich nicht.
Ich weiß es nicht genau.
Ja, das ist aber, habe ich auch schon
ein gutes Mal 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 das 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
Clickhouse-Datenbank oder vielleicht stehen sie auch in der
Postgres oder Redshift-Datenbank,
dann geht's
dann erst mit der Modellierung los und
zum Glück
haben die meisten Leute
von uns 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
G-Boost einfach sehr, sehr gut.
Bomber sieht das Modell.
Aber es kommen gerade Sachen,
zum Beispiel gibt es da
PFN-Less. Ja, das klingt auch sehr
interessant, ja.
Es ist ein
Transformer-Modell und das ist irgendwie
total verrückt, weil dieses Modell hat
also ich finde es immer noch
total beeindruckend, es ist irgendwie so Magic.
Also das hat gelernt,
wie Datensätze, wie die Zusammenhänge
in Datensätzen,
wie die Zusammenhänge in Datensätzen
normalerweise so sind.
Und dann gibt man dem nochmal so ähnlich
wie so ein Fine-Tuning den Datensatz,
den man halt da selbst hat,
der einen interessiert. Und
dann kann man damit 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 es gibt ja
gar nicht so viele im Netz verfügbar ist.
Das heißt, wenn man ein Sprachmodell trainieren will, das ganze Internet
besteht aus Sprache.
Aber es funktioniert trotzdem, es ist richtig beeindruckend.
Also ich glaube, das ist sowas, was sich gerade
so anfühlt wie, okay, da passiert jetzt
wirklich mal wieder was Neues
in der Bereich-Prognose.
Jaja, auch diese ganzen Pre-Trends, das gibt's ja
im LLM-Bereich, gibt's 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,
und ja, das hat mich auch
total gewundert, dass,
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?
Ja, also XGBoost, also Gradient Boosting.
Ja, XGBoost 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 wird 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 mehr Wassermelonen
und das ist so der Klassiker, das würde man
auch mit einer
linearen Regression machen können.
Die ist aber, ja, weniger flexibel
und normalerweise dann auch weniger genau
und XGBoost ist da halt deutlich komplexer.
Und XGBoost macht das dann quasi
über die, weiß ich nicht,
Backpropagation-Mechanismen?
Nee, nee, das ist eine Art Decision Tree.
Also es ist eine andere Art, grundsätzlich
eine andere Art von Modell.
Ja, das ist im Prinzip 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, ziemlich gut.
Und das heißt,
über Jahre eigentlich
für jedes typische
Predictive-Projekt
oder für jede Predictive-Fragestellung
war XGBoost, es war schon fast
langweilig. Ja, es gibt dann noch so ein paar
Varianten. Es gibt zum Beispiel Catboost, das es so
ähnlich hat, aber halt schon irgendwie ganz
schlaue Mechanismen implementiert,
um mit kategorialen Variablen umzugehen
und manchmal ist das eine oder das andere dann so ein bisschen besser
oder performanter, aber das ist kein Riesenunterschied.
Da gab es ja nicht auch noch irgendwas von Microsoft
Lightboost oder sowas, aber ich weiß gar nicht, was da rausgeworden ist.
Oder LightGBM. Oder LightGBM, genau. Ich weiß gar nicht, was
da rausgeworden ist.
Benutzen wir auch gerade in dem Projekt.
Ah ja.
Und ja,
witzigerweise, wir haben auch schon
vor einem Jahr oder so, haben wir gedacht, kann man
eigentlich auch LLMs zur Prognose benutzen?
Ich möchte kann dem LLM 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, sagen wir natürlich,
so ein bisschen Informationen mitgeben
und das hat aber schon funktioniert.
Also wir haben da,
da weiß ich jetzt die Details natürlich
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 aber auch nichts Spannendes drin.
Und dann fragt man, wie teuer ist
das Auto? Bitte antwortet mich nur
in einer Zahl, in Euro oder irgendwie sowas.
Und das funktioniert schon erstaunlich
gut, vor allem, wenn man nicht 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 meinst du jetzt tatsächlich
also die großen LLMs und nicht nur Transformers
selbst, 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 Canisian Trees, dass es da irgendeine andere
Art gibt, dass Daten aus den tabellarischen
Daten rausziehen.
Ja, das hier ist jetzt so, dass
das, ja,
die klassischen LLMs, die man so kennt
und dann kam eben jetzt dieses neue
mit TabPFN, das ist ein Transformer,
ist das halt, wie speziell für tabellare Daten
wieder gemacht ist, weil wir haben ja die LLMs eigentlich so ein bisschen
zweckentfremdet, indem wir die dann da
nach dieser Probe machen. Was meintest du denn da überhaupt mit
Feintuning, was habt ihr denn da gemacht?
Ich weiß gerade nicht, 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 ihm dann nochmal
ja gut, das beschreibt es
wahrscheinlich ab dann schon komplett,
wir haben dem dann nochmal, wir haben einen
Trainingsdatensatz, wir ganz viele
Gebrauchtwagen 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 ein Text, das Auto ist so und so
alt, sieht so und so aus, ist die
Marke und es kostet das und das
nächste Auto ist 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
Thema weniger drin bin, als in so was wie
XG Boost, aber ja, dadurch ist das
Modell dann nochmal, kriegt nochmal so eine Spezialausbildung
quasi für das Thema Auto
Gebrauchtwagenpreise und
dann wird es nochmal besser, wenn man ihm dann so eine Frage
später stellt. Ja, man trainiert
das 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. Ich komme mir an die Gewichte
gar nicht dran von den großen LMs zum Beispiel.
Ne, 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, das
natürlich, ja.
Ich glaube, wir haben da beides gemacht, also
einmal über OpenAI, da kann man einfach über die API sein,
die ist mit Fine-Tuning-Datensatz, machen wir mal
und aber auch mit
den Open-Source-Modellen,
wo wir dann nochmal ein Fine-Tuning drangehängt haben,
damit die eben speziell auf Autoprise
die haben halt so selber ihre, ja.
Bei Tuning und Autos
fällt mir jetzt erst auf, dass es echt total gut
passt. Ja.
Okay, das
ist also Tab-TFN, ja.
Ja, wobei
das ist jetzt noch relativ neu
und da ja nicht
jede Woche neue Projekte losgehen, sondern die
meisten Projekte schon länger laufen,
sind die meisten Projekte, die wir haben, dann auch
mit sowas wie XGBoost oder teilweise auch mit
irgendwelchen ausgefeilten
statistischen Ansätzen
oder Kombinationen, je nachdem, was man
Ja, das finde ich dann spannend. Wie viel kann denn jemand, der
richtig gute 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 kommt auf die
Fragestellung an. Bei so einem relativ
klassischen Task wie
in welchen Verkaufszahlen
geht es, glaube ich,
auch mit einem Modell
XGBoost 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 und wenn man das
Modell zu flexibel sein lässt, dann lernst du auch
die kleinsten Wackler auf den
Trainingsdaten und auf neuen Daten
erzählt es dann nur Mist. Das heißt,
dann hat man 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 XGBoost meistens
ziemlich weit, aber
ja, zum Beispiel
im Sportwettenbereich gibt es ja manchmal
wirklich komplizierte Sachen, also wenn ich jetzt
vorher sagen 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 Holgerstick, die einen ziemlich weit
bringt. Ja, ihr habt also nicht
die Ernährung der Spiele am Morgen zuvor mit einfließen
lassen können und sowas. Das weiß ich nicht,
ich müsste mal fragen, ob sie das in der
Feature drin haben.
Es gibt auf jeden Fall spannende Sachen.
Ich würde mich halt tatsächlich
interessieren, was man aus Statistik irgendwie daraus lernen kann,
weil ich verstehe nicht genau,
wie jetzt in so einem Transformers-Modell die einzelnen
Gewichte bei den Neuronen zustande 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, Neuronalisten sind deutlich eher
Blackbox, aber das ist extrem gut 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 vorhergesagt 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 Cleansing spricht. Ja, also wenn ich jetzt
die Daten da einfach so reinkippe oder
am Anfang schon so aufteile,
dass ich jetzt Cluster bilde 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üte 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,
ich, ähm,
vielleicht aus der
Luftschadstoff-Prognose überlege ich gerade,
ist, ähm,
irgendwie was, ja, also mittags ist
die Luft schlechter, weil mehr Autos rumfahren,
aber nur, wenn wir keinen Wind haben.
Wenn wir viel Wind haben, wird nämlich wenig Schadstoff
halt weggepustet. Das ist halt eine 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, sag ich logisch,
dann macht man es dem Modell halt schon deutlich
leichter.
Wenn man das vorher schon mal explizit zusammenbaut, also dann vielleicht irgendwas, das würde dann sagen, es ist Mittag und es ist kein Wind und es ist windstill. Jetzt in diesem sehr einfachen Beispiel. Und das ist dann, glaube ich, auch wieder so was, wo es dann wirklich viel bringt, immer mal wieder mit den Leuten zu reden, die sich fachlich damit auskennen.
Und 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, und 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 XGBoost sozusagen reinkippen, weil das kann halt bloß irgendwie eine fixe Anzahl von Spalten.
Und dann muss man das irgendwie.
Erstmal den Text runter projizieren mit Singular Value Decomposition oder so auf, weiß ich nicht, ein paar hundert Dimensionen oder so. Und das kann man in XGBoost reinpacken, sozusagen. Solche Sachen hat man halt auch immer.
Ja, das war 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 XGBoost machen, wie in dieser Freitext mit der Autobeschreibung, dann muss man sich ja erstmal irgendwie was überlegen, wie man den dann in ein sinnvolles Format bringt.
Also das XGBoost, das kennt halt nur.
Man kann eigentlich nur Spalten bezahlen.
Kategorien kann man ja im Prinzip auch doch in Zahlen überführen.
Und ein Text, naja,
ist halt erstmal nicht 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,
Texte durchzugucken und das zu labeln,
dann ist das bestimmt nochmal ein bisschen genauer.
Das ist halt die Frage, ob es sich lohnt.
Muss man sich immer überlegen.
Okay, ja gut, aber 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?
ETIL? ETIL, 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... Ja, aber wir sind jetzt da
irgendwo in diesem Workflow,
also es ging ja um dieses CRISP, ne?
Ach so, ja. Ja.
Also ich glaube, ja, also die ETIL,
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 aber Daten laden, 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.
Und, ja, das ist,
so hängt das im Prinzip zusammen,
aber oft benutzt man ja den Begriff
ETIL auch einfach für jeden
Prozess, der irgendwie Daten nimmt,
verarbeitet und so durch so eine Strecke schiebt.
Außerhalb vom Data Science-Bereich halt auch ganz oft.
Ja, genau. Also jeder Business-Prozess,
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 ETIL,
jetzt kommt der ETIL und dann kommt
der Teil mit dem Modell. Also oft nutzt
man den Begriff eigentlich auch, um das so voneinander,
da 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, dann ist das 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. Das kriegt halt nur
die ganzen Features, aber es kriegt nicht die Zielvariable.
Es muss dann seine Prognosen blind machen und wir
können dann gucken und dann sagen, ja, wir
kennen die Warenwerte aber schon und vergleichen das
jetzt. Da gibt es dann verschiedene Kennwerte,
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 mittel drüber oder drunter.
Man kann eine erklärte
Varianzanteil berechnen. Man kann
je nachdem, vielleicht wollen wir auch gar nicht
numerische Daten vorher sagen, sondern nur ein Ja-Nein.
Dann könnte man gucken, wie viele
Falsch-Positiv, Falsch-Negativ 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, es ist glaube
ich auch gar nicht so leicht zu sagen, was ist denn jetzt ein guter
Wert? Finde ich 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 nicht, dass
ich natürlich nicht so genau vorher sagen, wie
aggregierte Verkaufszahlen,
weil da einfach so
viele andere Einflüsse sind.
Und ja, nochmal zu diesem
Split, zu den
Trainingsdaten und den Testdaten.
In den allermeisten Fällen
haben 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, wenn man immer die
zeitlich, die nimmt, die zeitlich am Ende
liegen, weil manchmal ändern sich eben Zusammenhänge
und
es 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ängigen Daten, Änderungen dann irgendwie auch trotzdem mit
reinkriegt, ne? Weil wenn sich halt irgendwas...
Ja, 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, wenn 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, so 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 Nase
Verwaltung hier für Umwelt und
so weiter ja auch nicht sagen. Also die 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
sagen, so und jetzt, jetzt ist es aber so viel schwächer
geworden, so müsst ihr mal neu trainieren. Das kann die
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
neue 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 menschlichem Verhalten,
die sind natürlich jetzt, die sind 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 sag 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 kein
Beispiel gehabt habe, ja.
Wenn der Schock gerade erst passiert ist,
dann ist das echt schwierig. Man kann,
vergangene Schocks kann man halt 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 der
Luftfahrtschiff-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, sonst hättest du gedacht, oh, das ist eine gute Sache.
Aber ich hab nochmal,
ich würde mal ganz kurz einen Schritt
zurückgehen, weil ich hab eine Frage,
die mich noch jetzt schon interessieren würde,
weil ich jetzt auch gar nicht so wirklich Ahnung von diesem
TAP-PFN oder so habe, weil
in den anderen Bereichen haben ja die,
also normalerweise hat man neuronale Netze für solche
tabularischen Daten.
Das funktioniert auch, aber
halt nicht so gut wie die anderen Arten von Modellen.
Oft, und
die Frage wäre jetzt, was einen, ja,
die,
die Transformer, beziehungsweise überhaupt irgendwie
das ganze Deep Learning, 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 für einen sozusagen,
und die Frage wäre halt, macht es das
möglicherweise, ist es bei TAP-PFN
auch so, dass ich da jetzt quasi
...
auch relativ rohe Daten
irgendwie verwenden kann, oder muss ich das
erstmal auch irgendwie in eine Struktur bringen,
so ähnlich wie bei XGBoost?
Da fragst du eigentlich die falsche, ich glaube
aber, dass man da
nicht viel vorbereiten musste.
Aber da würde ich
tatsächlich auch
auf unsere Podcast-Folge mit dem Autor
von TAP-PFN verweisen.
Muss ich mal anhören.
Klingt gut. Ja, also, genau, die ist dann
wahrscheinlich für dich die richtige.
Ja, aber vielleicht noch mal
zu dem Modelltraining. Wo trainiert
ihr denn das, und wie macht ihr das?
Meistens
auf
...
also oft auf ABS-Maschinen
zum Beispiel. Wir haben auch
selbst ein paar
fette Server, die sind jetzt im Rechenzentrum
in Nürnberg. Seit neuestem haben sie dort
unter ihresgleichen. Vorher haben wir
so ein bisschen das Büro beheizt, damals wie
Winters. Jetzt haben wir 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, ja, 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's natürlich in Richtung GPU, und
wir haben uns auch da was
zugelegt vor einigen Monaten, sodass wir uns
auch eine eigene GPU haben, und auch mal selbst
das aussetzen konnten auf einer eigenen
GPU, was natürlich auch
ganz spannend ist. Also habt ihr eine eigene Maschine
hingestellt, oder habt ihr irgendwie bei Hetzner oder was gemietet, oder?
Die haben wir tatsächlich gekauft
physisch, die sitzt auch im Rechenzentrum,
und dann irgendwann
haben wir auch mal was ausprobiert, oder weil die dann
doch zu klein, da haben wir das dann über AWS gemacht.
Okay.
Ja, ist schwierig. Es ist auch schwierig, gerade welche zu
kaufen, aber, und das ist sehr teuer. Ja, es ist teuer.
Mieten ist auch sehr teuer.
Ja, das macht jetzt schon Sinn.
Wir kaufen die, aber ich glaube,
die war dann irgendwie zwei Monate später wieder
deutlich günstiger.
Ich glaube, also, wenn man die mietet irgendwie, dann kostet die
irgendwie so 1.000 Euro im Monat, oder sowas.
Also, wenn du viel Hauptspeicher,
wenn du zum Beispiel LLMs feintunen willst,
dann zahlst du eher 1.000 Euro am Tag.
Ja, das ist richtig teuer.
Ja, okay, kommt auch wahrscheinlich darauf an, wie viel man braucht, ja.
Ich glaube, es hat auch ein paar
Leuten einfach Spaß gemacht, das Ding halt
auszuwählen und zu kaufen, und dann wirklich
selber sowas komplett aufzusetzen.
Ja, ja.
Das macht auch Spaß, ja.
Ist ja auch gut, wenn man das dann mal kann.
Kommt ja der Operator durch auch.
Ja, ich würde das auch machen.
Braucht man einen Grund. Gib mir doch einen Grund dafür.
Also, vielleicht wollt ihr ein unbezahltes Praktikum.
Wenn wir dann ganz viel große Hardware
in die Hand nehmen, können wir nun mal nachdenken.
Ich denke,
das könnten wir mal nutzen.
Vielleicht nochmal zu der
Modellbewertung. Ich hätte ja schon gesagt,
dass man natürlich Kennzahlen ausbrechen 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 oder ob welche signifikant sind.
Aber das geht dann bei
XGBoost nicht mehr so leicht, sich irgendwelche
Splits anzugucken, wie das Modell gefunden hat.
Aber da gibt es ganz
tolle Methoden, die nennen sich SHAP
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 Visualisierung.
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 auch überlegen, was da los ist.
Und da kann man sich auch die Form der
Zusammenhänge angucken. Zum Beispiel,
ich glaube, da haben wir auch gesehen,
je windiger, desto weniger Schadstoff, aber irgendwo
gibt es dann so eine Sättigung, dann sind die Schadstoffe halt
irgendwie einfach so weggeweht, wie es nur geht.
Und
das, ich glaube,
es war sogar, nee, ich glaube, das
war das Interessante, irgendwann wurde es halt wieder schlechter,
weil dann der Staub
aufgewirbelt wird. Wenn es so wenig ist, dann hat man
immer nur den Staub in der Luft, dass es wieder schlechter wird.
Und da habe 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, wenn es zu stark ist,
der Abrief von der ganzen Straße,
der kommt nochmal mit hoch.
Ist natürlich, wenn es regnet,
dann halt eben wieder nicht, weil dann wird
das eben weggespült. Und dann die Temperatur wieder.
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 so, 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 das klingt jetzt alles so linear,
als würde 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.
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 Stück zurückgehen. Das ist ja kein Problem.
Okay.
Das ist ja dieser jeweils Step, der dann
guckt, ob das, was man da macht, auch
dem entspricht, was man so möchte.
Oder ja, es gibt
ein Alert. Oh, irgendwas
stimmt hier nicht. Aber das kann natürlich auch sein, dass in der Realität
irgendwas nicht stimmt. Das kommt erst später.
Ja.
Da 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 Tests?
Ich glaube, es ist eigentlich immer
ein Pytest unterwegs.
So. Wir lieben
Pytests.
Wobei Tests mit Daten ja auch manchmal ganz witzig
sind, weil man
ja, braucht man sich dann
keinen Testdatensatz. Ist der 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, es ist
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...
Naja, gut, ja.
Ja, es geht auch mal, aber...
Schwer. Ja, also in dem Moment
wäre man ja eigentlich nur bei einem POC,
bei einem 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 noch mal
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
eine Vent-App? Mit was macht ihr
die Web-Apps?
Meistens mit Vue.js
und
historisch auch noch häufiger mit
Asshiny, aber das...
Da haben wir
ein Projekt, das ist eigentlich ganz cool, da haben wir
das, da geht es gar nicht mehr um 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 für ein
Forschungsinstitut einige Apps gebaut, wo
die dann eben über eine Klick-Oberfläche
können sie ihre Daten hochladen und können dann
die Analyse fahren mit bestimmten Einstellungen und
kriegen dann Ergebnisse und Visualisierungen des
Dienstes, die natürlich auch sehr praktisch
und schreiben die dann mit ihre Doktorarbeiten.
Ja, aber
zurück zu
unseren Prognosergebnissen.
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 meine Zahlen?
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, ja, schreib 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 Löhne doch
groß ist und dann hat der in IT 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
noch.
noch mal was Kleines bauen, damit
die dann doch was sehen können.
Aber wenn die Farben dann auch richtig sind,
das ist das Wichtigste an Flickung.
Ja, das kann man auch durch
unterschätzen. Das sieht ja alles
sauhässlich aus.
Ja.
Und
ja, üblicherweise, das hat man eben
schon gesagt, ein Modell muss man natürlich regelmäßig neu
trainieren, weil sich Zusammenhänge in der Regel
in allen Bereichen immer
mal wieder ändern. Das ist dann oft so
was wie einmal im Monat ab und
so sollte man sich das Modell sogar auch noch mal
ganz genau anschauen, zum Beispiel noch mal diese ganzen
Chefsachen 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 es einmal am Tag passiert, aber
manchmal ist es dann auch wirklich in Echtzeit, dass dann der
Anfall reinkommt und dann wird die
Prognose für diesen einen
ganz konkreten Fall erstellt und oft kann man
die auch noch nicht vorbereiten, weil man die Daten vielleicht dann
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
man sollte das natürlich auch überhaupt nicht
unterschätzen, weil vom POC
zum MBP 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, vor allem wenn man
am Anfang so ein bisschen geprototypt 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 ich denke so,
hey, ihr habt uns doch gerade die Ergebnisse gezeigt, die sind doch
da.
Ja, klar, das ist natürlich auch
schwer nachvollziehbar von außen, deswegen ist es einfach
wichtig, das richtig zu kommunizieren.
Ja, ich wollte gerade sagen, schwer zu kommunizieren, das ist, 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, 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 stimmt
und vielleicht nur für Halbbelly,
in 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 Modell-Neutraining will man auch mal
die ganzen KPIs, also die ganzen
Gütemaße sehen und
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 zeigt,
es ist halt nicht ganz fertig und dann kann man es für immer
benutzen, aber gut, das ist ja auch in der klassischen
Softwareentwicklung 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 denn eigene
Monitoring-Tools oder nutzt ihr ja auch eins von den Sachen,
die es da so gibt? Ja, also
ReDash benutzen wir in dem einen Projekt
ja ganz gerne und
sonst, ja, wie das,
was ich gerade dann
anbiete, die 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, was die
in anderen Projekten benutzen.
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.
Telegram kriege ich auch Nachrichten für meine Server, falls da
irgendwas passiert, was ich will, ja.
Ja, cool.
Zu wissen.
Ist ja auch immer mal so ein spannendes Thema,
weg von US-Diensten und so.
Ja, wahrscheinlich, genau, das ist natürlich
wenn ich über die Russen nehme.
Weil Telegram irgendwie an der richtigen Adresse ist.
Man soll ja streuen.
Ja, ja, genau.
Ja, das ist das eigene.
Wir nehmen meistens immer so eigene Server oder sowas, aber wenn die halt
dann wechseln, ist halt auch blöd, dann merkt man es halt sonst nicht.
Ja, dann musst du halt irgendwo anders noch
Dinge haben.
Ja, aber ja, klar, es wird dann auch
teurer. Monitoring ist ja zu ruhig,
was passiert denn da jetzt, ne, genau.
Endlich sind alle Bugs
weg. Ja.
Eigentlich ist alles gut.
Hat jemand den Nähenzuhörer mit in die Tasche gesteckt und drunter gemacht?
Ja.
Ja, so, noch ein ganz
wichtiges Stichwort in dem Bereich ist natürlich
ML Ops, also Machine Learning
Operations, also Mischung aus DevOps
und Machine Learning ist das Wort.
Der Kurzvortritt ist der Rathops,
oder?
Ja, genau.
Und, ja, es ist
im Prinzip DevOps, aber
Anpassung auf diesen, auf den Datencase,
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, ja, die Ergebnisse
verändern, das heißt, da kommt dann
nochmal so eine zusätzliche Komplexität,
ebene mit rein naja das ist auch ja also
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 wenn das so
distributed ist, was halt beim Machine Learning
auch mal passieren kann, ja?
Ja, 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 Maschine kriegte, und dann brauchte man
mehrere Maschinen, aber danach ist das
eigentlich, ehrlich gesagt, also mir nicht mehr
passiert, weil...
Ich hab meine Daten zu klein, das kann schon sein,
aber
man kriegt heute so große Maschinen, also...
Ja,
die Preise haben wir uns ja gerade unterhalten, ja.
Ja, aber wenn man CPU,
die meisten Sachen brauchen wir mal eher CPU,
dann das ist nicht so toll.
Okay.
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 Erfolg.
Ja.
Ja, wo wir jetzt 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 das 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 nicht kennt, die eigentlich
dafür da sind, mit Datensätzen zu arbeiten, dann
kann es etwas unperformant
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
nur so viel zusätzliche Information
liefern. 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.
Aber das ist so
sowas, was man
im Blick haben sollte.
Ich gucke mal gerade noch. Ich hätte da mal
so eine Liste.
Ja,
Polar 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, dass es einfach gar nicht mehr so
interessant ist, wo es Polar gibt.
Und dann, ja,
bei Datenbanken ist es auch manchmal ganz
interessant, weil die
sind oft eher darauf optimiert,
dass man eine kleine Menge 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,
wie hat der 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 Batch hochlädt.
Das wird jetzt schon ziemlich
detailliert. Ja, mit dem Paket-File, da wollten wir
noch ein paar bisschen drüber reden, wie man das machen
kann.
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.
Ist aber oft
nicht so.
Weil ganz oft ist halt CPU
möglicherweise gar nicht das Bottleneck. Also wenn man,
bevor man sowas macht, wie Dinge dann
verteilen oder so, sollte man vielleicht mal gucken, wo ist denn eigentlich
das Bottleneck.
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 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, wenn man sehr große Datenmengen hat,
also so groß, dass sie nicht in den Hauptschleifer 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 dem, auf dem, auf einem
großen Paketpfeil 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, 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, wenn man, wenn man so ein MacBook nimmt
und das richtig benutzt, ist es 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, 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 DataFrame-Interface
hat für irgendwie
Sachen, die hintendran SQL sprechen, oder?
Ja, oder zum Beispiel verteilte Datenbanken oder
sowas, ja. Ja.
Äh, genau, also
aber, genau, also
oft, oft ist es dann halt so,
wenn man dann halt irgendwie irgendwas
benutzt, was halt SQL spricht, aber
hintendran total verteilt ist,
dass das dann halt sehr langsam ist
und Leute nicht wissen, warum das langsam ist und sich
dann irgendwie dran gewöhnen und dann halt,
wenn sie ihre Jobs losschicken, halt dann Mittagessen
gehen oder so, aber, und wenn
sie sich vor die Daten irgendwie, äh,
halt geholt hätten und hätten das auf dem Laptop
in Pandas gemacht oder so, wäre es viel schneller gewesen.
Naja, so, solche Sachen, äh,
ja. Aber IBIS,
ja, es ist grad, ähm,
benutzt ihr das?
Nee, hab ich tatsächlich noch nie gehört.
Okay, ich glaube, das ist auch von dem...
Was ich noch mal
wiederholen will, ist einfach dieses, ja, guck
dir erstmal an, was eigentlich gerade langsam ist,
wo ist eigentlich dein Bottleneck, weil da sind ja
manchmal die Annahmen einfach nicht richtig.
Ja. Ich hab, das ist so witzig,
dass du's sagst, ich hab gerade, ich glaub,
letzte Woche hab 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 mit der Datenbank liegt
und wenn man dann...
Das ist, also eigentlich ist es trivial, dass man
erstmal profilen muss und gucken muss, was langsam
ist. Wenn man's mal gesagt hat, klingt's ja trivial,
aber ich glaube, wenn man's
zum ersten Mal macht, dann vergisst man es. Ich glaube auch, dass
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, krieg ich dann
tatsächlich, wird's schneller oder nicht? Wenn's nicht
schneller wird, okay, gibt's vielleicht irgendeine andere
Komponente im System, die halt
irgendwie, die halt dicht ist
und dass es halt da Unterschiede
gibt, dass halt nicht alles CPU ist, das ist
oft, hab ich das Gefühl, nicht so
keine weit verbreitete sozusagen
Erkenntnis und ja,
aber ja, genau, das ist ganz wichtig, dass man das
halt sich einfach so
im Gesamtsystem mal anguckt, ja.
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 dieses nutzen soll und dann läuft das
einfach, das ist ganz praktisch. Genau, aber ich weiß
jetzt nicht, also das war jedenfalls, ich hab das ja auch schon lange
nicht mehr gemacht, aber das war
zu der Zeit, wo ich solche Sachen gemacht hab, war das
halt schwer, das auf mehrere Rechner zu verteilen, also auf
einem Rechner, ja, genau, mehrere Kerne, kein Problem.
Aber auf mehrere Maschinen, XY-Boost,
ja, eher nicht.
Ja, die Frage ist, wie
sehr man das auch manuell machen
muss, weil man ja meistens dann
sich sein Cluster in Databricks oder so
hochfährt und muss sich darüber gar keine Gedanken
machen eigentlich. Ja.
Also zumindest als Data Scientist ist das
nicht das, was man irgendwie
das erwartet wird, dass
dann da verschiedene Rechner zusammenfließt.
Ja, ja.
Und dann ist natürlich manchmal irgendwie
schon so, dass man doch wieder auf
andere Programmiersprachen
ausweichen muss, weil Python
und R nicht unbedingt dafür bekannt sind, dass
sie total schnell sind.
Aber ich glaube, also meiner Erfahrung
nach ist es schon oft so, dass man schon sehr
viel rausholen kann, wenn man sich den Python
oder R-Code nochmal genau anschaut, profilt
und dann vielleicht irgendwo
auch mal die Daten vorher
klug filtert oder
ein sinnvolles If-Statement
irgendwie so ein bisschen 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 Mal verändert hat,
dann ist da vielleicht irgendwas, was
man, also so eine Low-Hang-In-Food, was man
schon leicht optimieren kann.
Python könnte man ja auch noch schneller kriegen, wenn man will, ja.
Ja, wobei, also ich meine, das ist halt immer die Frage,
wenn es halt schnell sein soll, dann nimmt man am besten
was, was nicht halt,
in Python sind halt, was halt langsam sind, 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 aufruft oder nicht.
Das ist dann auch dieses Stichwort, dass
jemand, der das durchweist, eben über den Data-Frame
drüber loopst, das einfach so verfolgt ist.
Das ist dann schlecht, ja.
Ja, aber
deswegen ja genau, einfach dann eine Maske drauf
und dann machst du es halt drunter
in NumPy, ja.
Ja, also warum ich
Ibis eben sagte, weißt du auch von Wes McKinney,
das ist halt dem Pandas-Menschen,
der da war.
Ja, der hat ja eine ganze Menge, der ist auch hinter dem,
Arrow, das ist halt so seit einiger Zeit
sein Hauptprojekt.
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 gemeinsame
Daten-in-Hauptspeicher-
Laden-Infrastruktur hat
und dann halt Paket-Files
quasi, oder was auch immer, man lässt
halt einen Hauptspeicher und kann dann halt von
unterschiedlichen Sprachen auch
darauf zugreifen und das
funktioniert dann halt.
Genau, und ja,
ist halt nicht an sowas wie NumPy 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. Ehrlich gesagt bin ich da,
in letzter Zeit nicht so viel Interessanz gemacht.
Ja.
Genau, ja, also mit Ibis kann man
zum Beispiel auch da PaceBug 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 DataFrame-Interface
hast nach außen hin, sodass du es benutzen kannst
wie einen normalen DataFrame, aber nach hinten raus
spricht es dann halt SQL.
Was halt, ja,
wenn du ein System hast, das das kann, dann ist es...
Ja.
Okay. Ja,
ich glaube, wir haben schon viel
über diesen Prozess zumindest gesprochen.
In CRISP sind wir durch,
wenn wir das... Ja, eigentlich sind wir durch und dann kann man
ja wieder von Anfang an anfangen und sich den
nächsten, next best use case
oder das, was man schon
hat, halt nochmal erweitern,
überlegen, ob man es auch irgendwo 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
natürlich auch total wertvoll.
Ja, es gibt
diese Schwerpunkte, aber
greift ja auch alles ineinander.
Also es ist ja auch so, dass
es Sinn macht, so ein T-Shape-Profile
aufzubauen, also dass man in einer Sache
schon wirklich gut ist, aber von
vielen anderen Sachen auch Ahnung hat und da auch
was machen kann. Dann ist man eben auch flexibler, auch wenn
vielleicht ein Bereich auf einmal nicht mehr
so gefragt ist aus irgendwelchen Gründen,
ob das AI den überkommen hat oder
weil wir alle ersetzt werden.
Genau.
Es macht natürlich auch Sinn, wenn ich als
Data Scientist jetzt mich
nicht weigere, mal das Jenkins-File
zu updaten.
Da macht es ja schon Sinn,
sich dann mit allem ein bisschen auszukennen.
Ja, okay.
Also aus meiner Perspektive ist das, ich meine, das mag
jetzt etwas ketzerisch klingen oder ich weiß nicht, vielleicht
so Hot-Take-Verwandlung.
Ich bin gespannt. Ich würde sagen, das ist alles
Programmieren. Oder sagen wir so,
das, was praktisch oft
sozusagen ein 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.
Das ist halt das Bottleneck aus
sowas.
Ein bisschen statistisches Grundverständnis schadet
vielleicht auch nicht. Ja, aber du brauchst oft
oder gut, 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 langweilt sich die eine Hälfte
der Leute, die halt nicht programmieren können, weil die können
dann ja immer nur Ergebnisse angucken und irgendwas dazu
sagen. Oder genau, so kommt man jetzt auch aus,
man ist halt hart davon abhängig,
dass man, dass irgendwie dieses
Programmierdings halt auch funktioniert, weil ansonsten
kommt man mit den anderen Sachen, ist halt sozusagen
die Infrastruktur, die man braucht für fast alles andere.
Ja, natürlich gibt es halt auch
so Programme wie SPSS, wo man
Statistikanalysen machen kann.
Das wollte ich ganz am Anfang sagen.
Das hat ja auch
seine Daseinsberechtigung, weil wenn jemand nur
alle drei Monate mal eine Analyse fährt,
dann lohnt sich halt eben nicht.
Ja, aber auch da,
da mache ich mir einen Notebook für halt dann, oder?
Nee, aber die Person macht
alle drei Monate irgendwas anderes.
Dann müssen sie alle drei Monate wieder
sich erinnern, wie man eigentlich
Variable zuweist.
Und 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, 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 machen alles mit Excel, genau.
Ja, natürlich. Man kommt auch
ein gewisses Stück weit schon, das ist richtig,
aber. Eine Million Zeit.
Ja, ich glaube, man hat als Data Scientist auch manchmal
so eine Arroganz, dass man Excel überhaupt gar nicht
öffnet.
Ja, und bei manchen Sachen ist es vielleicht gar nicht so schlecht.
Ja.
Aha, jetzt hat jemand Excel gesagt.
Jetzt kriege ich ein komisches Gefühl.
Ich bin zu cool dafür.
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 oder was mit Daten
und dann soll das alles so aussehen wie vorher und
Das geht alles, ich habe da kein Problem
damit. Ich generiere auch Excel Output
und ich lese auch Excel ein.
Ja, also in schönen Output machst du das?
Ich habe da eine Aufgabe für dich.
Oh, ja, so.
Okay, jetzt, wenn es dann so konkret wird,
dann 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 man 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.
Ja, weil die auch den ganzen Tag das halt schon kennen, ne?
Die haben halt ihren Prozess, der ist immer schon so
und dann ist es halt super, wenn dann die Sachen einfach
dann neu sind oder Daten drin sind, aber es soll genauso
aussehen mit Condition Formatting und so.
Ja, oder es sind halt Leute, die können halt
sich programmieren, das ist auch irgendwie völlig okay,
weil sie ganz andere Sachen machen, aber trotzdem
müssen wir denen irgendwie die Ergebnisse
liefern.
Ja.
Ich glaube, wir sind bei den Picks angekommen, oder?
Ich glaube, Miriam, du hattest noch einen, wolltest
was picken, was auch noch mit Data Science zu tun hat, vielleicht
fangen wir damit doch direkt an.
Ja, also wir haben schon so ein bisschen angeschnitten, ich hatte ja eben erwähnt,
dass ich was parallelisiert habe und das war
total cool, weil
diese Prognosen,
also dieses Modelltraining und Prognosen
erstellen, das hat halt Stunden
gedauert und auch wahnsinnig hohe Kosten
verursacht, weil, anderes Thema,
Pandas haben hohe Rampe
gebraucht, 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 lief, also diese ganzen
vielen Nodes auf diesem riesigen Cluster,
die wurden alle überhaupt gar nicht benutzt und
dann dürfte ich das parallelisieren,
in dem Fall
mit Pandas UDFs, Pandas
User-Defined Functions, also es ist dann eine Möglichkeit
eben, dass das, es läuft halt in
Pandas, weil es ist ein Light-GBM-Modell
und es kann im Moment noch keinen
High-Spark-Data-Frame oder Spark-Data-Frame
nehmen, deswegen muss man den
in Pandas geben oder wahrscheinlich
geht auch Polars, 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, so ein Erfolgstor ist immer schön, ja.
Dann komme ich auch direkt zu meiner
Erfolgstor, ich hatte nämlich auch so einen
Moment, ich habe nämlich Hinnicks neues Video gesehen
und das ist
Rustlove, also ich habe Just-Files für mich
entdeckt, die hatte ich vorher
nicht so auf dem Schirm, das ist 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 Projekt-Kommandos eigentlich
alle sind und dann kann man
das diesen wundervoll mit Variablen und so,
es funktioniert toll, Hinnicks 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-File noch ein bisschen selten,
sondern einfach nur Just, Just Run
und der Server läuft oder
Just Run und der Server läuft oder
Just Connect für Dev-Server oder
sowas oder für auch Prod-Server,
dann kann ich sagen Just Connect Production und
dann noch den Pod-Namen oder sowas, falls ich öffnen
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 richtig schlau, oder?
Ja, voll gut, finde ich auch, deswegen Just Love.
Okay, ja, ja, ich habe
ja auch tatsächlich, nachdem ich das
Video von Hinnicks gesehen habe, habe ich mir auch gedacht, so,
vielleicht muss ich das auch mal ausprobieren,
ja, ich,
ich meine, das ist toll,
du kannst auch nach dem Just Build und du, der macht mit
UV, macht dein Direkt-Paket-Installation, Paket-Sync,
du kannst Upgrade machen,
alle Sachen mit den
Kommandozeilen, die du sonst immer nutzt, reinschreiben
und wenn du das über so eine Commands-File geregelt hättest oder sowas,
musst du halt immer dann einen Subprozess spawnen
und so, ah, ich weiß nicht, das
war schon sehr schön. Ja, ne, 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,
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
halt unter Scripts halt
andere Entry Points definieren und da habe ich halt Funktionen,
dann habe ich es jetzt nicht in der Command-File, 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 runter fährt oder
solche Sachen, ja klar, dann muss man irgendwie das
Anlass machen. Also, das DB zum Beispiel ist das andere oder
eine Katakombe, also, ne,
Shell-Skripte da reinschreiben, wenn du willst,
die dann Sachen hintereinander machen
und so oder Tests machen oder
oder
gucken, du kannst Environment-Variablen da reinladen oder
spezifisch, wenn das irgendwie passt und
du hast gerade eine Sache gesagt,
Pakete, also, du könntest ja auch einfach aus der PyProject
das PyScript dann ausfüllen lassen und bei mir ist zum Beispiel
so, dass die Dinge
im Python und im 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 in Directory setzen. Toll.
Mhm. Ja, okay.
Also, ich muss mir vielleicht auch nochmal
angucken. Ja, mach das.
Tracking. Wie Sockzeit.
Mhm. Geht nicht mehr weg. Okay.
Naja. Äh, ja,
genau, was, ich hab grad überlegt, was ich picken könnte,
hab mir grad keine Gedanken gemacht, aber ich bin ja
jetzt in letzter Zeit so ein bisschen besessen von,
ähm, nur ein bisschen.
Du bist besessen oder das
bist du besessen? Ja,
ich mach ganz, einfach
Cloud-Code und Dinge mit,
ähm, mit LLMs
irgendwie programmieren und
Das ist schon verrückt, also, ich weiß nicht, ob
du das auch noch, Mira, aber, ähm, die Kosten sind halt
krass und wir, wir nutzen jetzt halt Max.
Ja. Das ist halt das Abo,
wie teuer ist das, 200 Euro? Ja.
Ja, gut, es gibt auch eins für 100, aber. Ja,
okay, aber das ist halt das 20, normalerweise musst du halt 3000,
4000 Euro Tokenkosten zahlen
im Monat dafür. Ja,
so, aber das, genau,
das würde ich jetzt dann picken, es gibt da ein,
äh, ein NPM-Paket,
äh, CC-Usage, äh,
äh, nennt sich das, äh, kann man per MPX zum Beispiel
installieren und dann sagt einem das
quasi, wie viel, für wie viel Geld
man Tokens verbraucht hat und,
ähm, damit kann man sich sehr schön rationalisieren,
dass das gar nicht so viel ist, wenn man 200 Euro,
200 Dollar im Monat zahlt.
Weil, äh, ja.
Ähm. Wie viel hast du diesen Monat?
Auf dem Rechner hier, 2000 Dollar
Tokens, ja. Okay. Und ich hab aber auch
noch andere Rechner auf denen auch. Ja.
Und das ist der 17. heute, glaube ich, ne?
Ja. Ja.
Ha. Die, die sind
gefährlich, die Dinger, die machen uns alle obsolet.
Wir werden sehen.
Ah, das glaub ich nicht. Ach, ja. Man sitzt dann
am Strand und nimmt dann sein Schirmchen und redet
dann mit seinem, keine Ahnung, kleinen
Roboter neben einem herläuft, der nebenbei noch unterhält,
dass man weiterentwickelt und unterhält
sich dann wie im Podcast. Da haben wir ja schon mal gut geübt jetzt.
Also, ja, man muss so ein bisschen, bisschen
vorsichtig sein, weil natürlich wird man halt irgendwie so
ein bisschen zu so, man, man schreibt dann halt nur noch so Anforderungen
hin und so versucht das genau zu spezifizieren
und das, man, man befördert sich selbst
zu so einer Art Projektmanager. Ja.
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 mach das mit der Familie nur, weil es Spaß macht.
Ja. Genau. Und,
ja, wenn es keinen Spaß mehr macht, weil,
ja, es ist halt, dann hat man sich irgendwie
doch was mit Holz machen. Ja.
Mein Freund nutzt tatsächlich, also
für die privaten Projekte auch viel Cursor
und er sagt so, ja, das, worauf ich Bock
hab, das schreibe ich da trotzdem selbst.
Ja, das ist auf jeden Fall eine Art Idee wahrscheinlich.
Und sonst ist er halt, ja, der Projektmanager,
der seinen
Julia quasi immer
mal gucken muss, was der macht.
Ja, also bei mir hat auch Cursor jetzt raus, Adventure
von E verkauft, aber Cursor ist raus, nur noch
Code, also nur noch Kommandoteile und ich bin wie
jetzt Code und das ist super.
Das, also, kann ich nur empfehlen.
Ist verrückt. Ja.
Ist grad verrückt, ja.
Es macht also viel schneller und
dann mache ich so nervige Sachen ab.
Aber ja, man wird irgendwie mehr zum
Projektmanager, Projektmanagerin und
ich glaube, das Thema Kommunikation wird halt
immer noch wichtig bleiben.
Ich hoffe ja, dass das Ding über meine Stimme hat und dann bessere
Kommunikation mit den anderen Leuten.
Das wäre, genau, das habe ich ja auch mal gehofft, ne,
dass ich irgendwie, warum ich, genau,
während meine
Cloud-Jobs halt laufen, kann ich dann
halbwegs mehr Zeit, um irgendwie Meetings mit
Kollegen irgendwie da, irgendwie Pläne zu
besprechen, so. Das sollte umgekehrt sein.
Das sollte, ich will lieber programmieren
und dann kann irgendwie, weiß ich nicht,
so ein Avatar in so einem Meeting auftauchen und immer
sagen, das ist eine super Idee, voll
gut. Genauso machen wir das.
Kann auch Kluge Dinge sagen, Jo.
Du kannst das Training, kannst dann unsere Podcast-Folgen
eingeben dann. Ja, ja, okay.
Muss man, ja, ist
einiges umgekrempelt. Ja, wir haben unbedingt, so könnten
wir, wir haben halt manche Leute, die hätten wirklich,
das Spannende ist 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 geht. Also das kann man ja eigentlich auch schon.
Also die neuen Modelle von Gemini dazu, die ich gehört habe,
ich glaube, es gibt noch andere, die
Wisp-LS ersetzen, das ist verrückt, wie gut
die sind und wie natürlich die auf einmal klingen, ja,
das ist schon crazy. Ja, also Stimme, LMLabs hat da super
Modelle, aber fürs Generieren
von Podcasts, Notebook-LLM,
das, ja, da kann, 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, Hörertreffen.
Ja.
Und
ja, kommt vorbei, hört uns, hallo at
peißenpodcast.de, alles Feedback, alles und so weiter.
Ja, vielen Dank, bis bald.
Alles klar. Und hört auch gerne meine
Datasign-Steepdive rein. Auf jeden Fall,
große Empfehlung. Bis bald.
Tschüss. Tschüss.