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, schön, dass du da bist.
Normalerweise fangen wir immer mit News an, da hat Jochen 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 viel Datenanalyse und Statistik macht.
Und da hat es mir noch nicht gereicht.
Deswegen habe ich dann noch einen Statistik-Master drangehä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 dann 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.
Weil es dann 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.
Und jetzt bin ich aber witzigerweise 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.
Ja.
Ein Unternehmenspodcast, in dem ich manchmal, aber auch nicht immer zu hören bin, wo wir ganz viele Themen rund um Data Science besprechen, den Data Science Deep Dive.
Genau, das ist 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 Technologie oder in der Geometrie oder so.
Auf jeden Fall, ja, ein Teil ist ja auch so, manche sagen ja Statistik oder Machine Learning, das überschneidet sich auch an ganz vielen Stellen.
Ja, klar.
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.
Das ist natürlich auch ein Projekt, natürlich ganz viel Kommunikation mit unseren Kunden, 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.
Jemanden so eine Sprache zu finden, das ist schwierig oft.
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.
Du hast 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,
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 und die überhaupt von der Kultur her in Richtung,
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 simpel, aber oft wird es dann doch irgendwie schon ein bisschen kompliziert.
Wir sind aber auch tatsächlich darauf spezialisiert.
Also es gibt ja auch ganz viele Sachen, wo vielleicht auch erstmal eine gute Visualisierung ausreicht.
Visualisierung machen wir natürlich auch mit, aber ein Projekt, wo es nur um Dashboard mit Visualisierung geht, landet seltener bei uns.
Ja, wie kommt man denn eigentlich zur Data Science?
Du hast gesagt, du hast Psychologie studiert und dann fandst du Statistik spannend.
Ich habe vorher auch Wirtschaftslehre 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 Statistik-Master war ich ja, da waren viele, die vorher Mathe gemacht haben, aber auch viele mit ganz anderen Hintergründen,
viel Wirtschaftswissenschaften, aber auch KollegInnen mit Soziologie-Hintergrund oder Physik.
Ich glaube, das ist sogar so ein bisschen Klassiker, dass die Physiker sich irgendwie dann in die Statistik- und Machine Learning-Welt verirren.
Und wir haben noch gar nicht so lange, haben wir auch jemanden mit Informatik-Hintergrund.
Das klingt irgendwie witzig.
Ich habe jetzt auch.
Nur Leute, also die sind 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.
In den Data-Science-Projekten, in denen ich so unterwegs war, halt auch irgendwie immer wieder gesehen, dass halt oft die Leute,
also ich weiß nicht, wie das bei euch ist, ob ihr, weil normalerweise Software-Entwicklungsgeschichten, die ich so mache,
da habe ich dann halt eben mit Abteilungen zu tun, die halt irgendwie Software-Entwicklung machen oder so,
aber bei den Data-Science-Geschichten ist es immer sowas wie Business Intelligence oder so.
Und das sind andere Leute, das ist ein bisschen so, die sind so ähnlich, also das sind oft irgendwie Leute,
die was Naturwissenschaftliches studiert haben oder so, dann da promoviert haben, genau, ganz oft aus der Ecke eher.
Und die eher so, ja, Analysten-Dinge tun, oft viel SQL schreiben und so.
Und das ist irgendwie ein bisschen anders als bei den Software-Entwicklern.
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 Software-Entwicklung und eben in diesem ganzen…
Und da wolltest du ja auch nochmal was zu sagen, wie du das so findest, mit der Software-Entwicklung 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 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 mit der…
Das klingt, als wäre es kein Kompliment.
Ich weiß nicht, ich dachte eben, ne.
Das ist das, 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,
wie es Data Science ist.
Und wer ist Software-Engineer?
Und natürlich arbeiten wir alle an dem Code, aber es ist, also es gibt eben so ein paar Klischees oder so Dinge, die man vielleicht beobachtet,
wenn jemand, der vor allem einen Software-Entwicklungshintergrund hat, jetzt zum ersten Mal versucht, Daten zu analysieren und Data Science zu machen.
Wir haben auch mal ein Projekt übernommen, wo wir entsprechenden Code dann, tatsächlich sollte man ja refactoren und wir haben auch viel refactored,
aber da haben wir einen Teil wirklich neu geschrieben.
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, die Ergebnisse halt so nimmt, wie sie sind und da irgendwie ganz unkritisch ist.
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 es 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, nochmal schwieriger, in den Daten drin zu sein und die zu interpretieren und zu sagen, Moment mal, also die Kurve sieht ja eigentlich 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...
Also verbreitet, weil manche haben dann eher einen Schwerpunkt auf so Datenanalysen, sind viel in 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, ja, interessant. Also da ist auf jeden Fall oft so ein bisschen ein Graben zwischen den Welten.
Also wenn ich das immer sehe, was so Data Scientists schreiben, dann stag ich immer die Hände über dem Kopf.
Also jetzt ist es gerade packativ, es gibt natürlich Unterschiede.
Das war so im Vergleich eher anders, als ich das machen würde wahrscheinlich.
Also man schreibt als Data Science oft so die ganzen Prozesse untereinander und muss erst mal lernen, die Methoden zu definieren und so, ja.
Und warum soll man denn, also wenn man das nur einmal macht, warum soll man denn eine Funktion schreiben?
Und man kann es ja Zeile für Zeile ausführen und die Funktion braucht man ja nur, wenn man zweimal dasselbe macht.
So ist dann, glaube ich, manchmal die Denkweise, wenn man eben mehr aus der Analyse kommt und da so quer einsteigt.
Ich finde das einfach manchmal, weil Leute...
Die Leute, die sich 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++, 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, ne, außer wenn man...
Wenn man jetzt irgendwie quasi bei einer Firma anfängt, die das halt auch irgendwie täglich macht oder so.
Bei den meisten Firmen gibt es ja da gar keine Kultur und, ja, also es ist irgendwie, ja, es ist irgendwie...
Also dieses Handwerkszeug ist ein Problem oft, das denke ich auch.
Was nervt dich denn an Leuten, die Softwareentwicklung gemacht haben und jetzt Data Scientists sind?
Ja, das ist auch interessant, ja.
Also, ja, also die Sachen, die ich gerade genannt habe, also es ist oft so, die Ergebnisse so unkritisch beurteilt werden, dass man eigentlich nur guckt, ob der Code richtig läuft und das macht, was man implementieren wollte.
Und das 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 ja erst mal die Kirchturmspitze ausrechnen, dass die Höhe dann 245 im Minus ist.
Und wenn man das dann einfach so übernimmt und daran glaubt.
Ja, genau.
Also, das ist natürlich ein gutes Beispiel.
Und manchmal habe ich auch den Eindruck, dass dann wiederum, wenn man sehr, sehr stolz auf seine Software...
Software-Entwicklungsskills ist, dass dann auch unnötig komplizierte Patterns auf irgendwelche Sachen geworfen werden und das dann auch wieder durch pragmatisch ist und sehr schwer wartbar.
Ja, klar, weil die Leute, die das dann letztlich irgendwie ja benutzen müssen, müssen das ja auch lesen und verstehen können und so.
Und wenn man dann irgendwas mit einem Elfenbeinturm baut, dann war das vielleicht auch einfach ein 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, aber grundsätzlich macht mir 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.
Also, datatowiss.com oder sowas.
Die benutze ich immer, wenn ich nicht weiß.
Ich kann euch sagen, nicht 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.
Damit sind wir jetzt eigentlich schon...
So mitten im typischen Ablauf, aber ich kann da, da wollen wir zwar noch drüber sprechen, da kann 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 im 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 plotten und Zusammenhänge.
Und das sind auch die Sachen, die wir dann oft mit unseren Kunden wiederum anschauen und sagen,
ja, guck mal hier, die Verteilung, macht die Sinn?
Und merken dann vielleicht, dass da irgendwas in den Daten unsauber ist, was halt oft vorkommt, womit man dann aber irgendwie umgehen muss.
Und natürlich auch dann später, wenn wir zum Beispiel ein Modell gebaut haben und die Ergebnisse untersuchen wollen,
wie sind unsere Prognosen verteilt, welche Zusammenhänge hat das Modell gefunden?
Auch da ist dann natürlich die Visualisierung total wichtig und sinnvoll.
Man kann es einfach viel, viel, viel schneller erfassen, als wenn man das irgendwie alles versucht in Tabellen,
in Tabellen zu vermitteln.
Wie visualisiert ihr denn am liebsten?
Ja, das ist irgendwie ganz witzig, weil ich in Python noch nie so richtig, ja gut, so ein bisschen habe ich auch in Python.
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 haben damit dann was gemacht.
Und da waren wir noch in R unterwegs und haben für ggplot2 benutzt.
Ja, super.
Und inzwischen sind wir dann meistens,
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,
was ist das denn jetzt noch?
Ich habe den Namen nicht vergessen.
Notly Dash oder Detroit Dash.
Genau, Redash ist ein Open-Source-Tool.
Das 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 da auch nochmal 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 vor allem aus meiner Sicht als Beraterin.
Das fühlt sich natürlich ein bisschen anders an,
wenn man die im Unternehmen erzählt.
Das heißt,
die ganze Zeit ist.
Aber für mich als Beraterin sind das eigentlich so sieben Schritte.
Erstmal das Problemverständnis,
dann die Daten einzusammeln und zu verstehen,
dann die 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 Standard 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 ist es bei uns dann tatsächlich auch so,
dass KundInnen zu uns kommen und schon was haben,
was sie, also sagt schon das, was sie brauchen.
Das geht dann auch in die 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 es meistens dann schon eher so, dass da schon Ideen da sind.
Wir aber das auch alles nochmal so ein bisschen challengen.
Wenn wir 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 die das genau?
Ist das irgendwo an einem Counter oder ist es am Telefon?
Oder ist es irgendwo, wo es kein gutes Internet gibt und so?
Und all das muss man natürlich wissen, um auch rauszufinden, was die brauchen.
Und dann ist der nächste Schritt, sich zu überlegen, wie können wir das machen?
Und haben wir eigentlich auch die passenden Daten?
Und dann haben wir vielleicht die notwendigen Daten und ein paar andere Sachen sind vielleicht nicht ganz so notwendig.
Man kann trotzdem anfangen.
Ja, das ist der erste Schritt und den sollte man nicht unterschätzen.
Besorgt ihr die dann auch?
Also baut ihr irgendwo neue Sensoren ein oder sowas und kümmert euch darum, dass ihr 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 wir nicht jede Datenquelle von vorne bis hinten auswendig
und man findet immer noch Überraschungen.
Aber das ist dann normalerweise nicht so, dass sie sagen,
wir wollen hier dieses super komplexe Modell, aber wir haben noch gar keine Daten.
Wir müssen die erstmal suchen.
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.
Vielleicht ist mal ein richtiges Data Warehouse da oder man kann die nochmal nicht 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 es wahrscheinlich von Anfang an auch berücksichtigt werden.
Also ich habe jetzt 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,
da wurde ja von Anfang an wahrscheinlich mitgedacht, was man da mit Daten machen kann.
Oder zumindest relativ früh.
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 von Daten gearbeitet hat,
denkt sich jetzt unbedingt, ich will es nicht mehr hören, weil Pandas halt sehr, sehr viel,
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, 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 seit...
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
ein kleineres, 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.
Ja. 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 dann Rust
nachgeschrieben mit der gleichen API, so ein bisschen wie
Pandas. Ja, es ist, ne, es hat
eine 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 nicht 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. Genau, ne, 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, immer mal 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
erst mal 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?
Ähm, 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
und vielleicht Quantile anschauen
oder eben auch Verteilungen plotten,
so dass man das sieht oder Kategorien
anzeigen, je nachdem, was das so ist.
Ähm, sonst, ja,
die ganze Tabelle, also man hat
natürlich eine Tabelle als Pandas DataFrame,
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, wirklich Insights
dann zu haben und die Daten zu verstehen,
ja, muss man dann, wenn der Datensatz
groß genug ist, natürlich irgendwie
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 auch den Fall,
dass wir, ja, dass sie dann
gemerkt haben, dass da irgendwo ein Fehler im Data Warehouse
ist und da war irgendwie so ein riesiger Strukturbruch,
der da eigentlich gar nicht sein sollte und dann haben sie
sich erstmal nochmal ein paar Monate zurückgezogen und
haben das alles repariert und danach konnten
wir das Projekt dann tatsächlich machen, aber das
wussten sie vorher nicht und 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? Und 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.
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
vielleicht Echtzeit irgendwas, wie deployed ihr
eigentlich eure Modelle dann
oder habt ihr da Präferenzen
oder, weil das ist immer so
ein bisschen, das machen Leute unterschiedlich und
ich weiß nicht, ob es da jetzt irgendwie
so ein Standardding gibt, was man machen kann, aber
ja, das ist auf jeden Fall immer
irgendwie nicht so ganz einfach gewesen.
Also grundsätzlich
gilt da natürlich, wir machen das
was die Kunden wollen.
Aber tatsächlich, wir sind ja dann 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 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
ihr da, da kann ich mich
alles nochmal genau 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
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-Verwaltung schon hatte
oder auch die API ist frei
verfügbar, könnte auch jeder abrufen, haben auch schon
ein paar andere dann mal gemacht, genau
mit Kubernetes ist natürlich immer ganz schön, ansonsten
bei einigen
Kunden läuft dann viel mit den
Diensten von 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 wir halt
andere, deshalb bin ich auch immer nur so am Rande
natürlich dabei, also kann irgendwie
in die Kubernetes kurz mal reingucken, aber ich
kann die nicht,
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, 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 Note,
aber wir sind auch ganz wenig eigentlich mal in Jupyter Note,
auf dem 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 Plotlib-Code zu schreiben,
dann ist 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 es dann meistens
so, dass jedes Mal,
beim Push in den Main-Branch,
wenn die, zum Beispiel, wenn die Versionsnummer
sich geändert hat, wird das dann
über 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, wird runtergeladen auf den Pod und dann
Ja, aber dann brauchen ja die Leute, die quasi
modellieren Zugriff auf das Produktionssystem
quasi oder können halt
es muss halt dann, die müssen den Code
verändern, die müssen committen können.
Ja, also die
committen von morgens bis abends.
Ja. Also das ist tatsächlich
bei uns überhaupt nicht so, dass
da irgendwie jemand sitzt, der nur in einem Notebook
prototypt. Gar nicht.
Also, wenn das Projekt
losgeht, dann muss man als erstes ein Repo
anlegen, weil sonst kann man ja gar nichts machen.
Ja.
Und vielleicht startet man dann
irgendwie mit ein paar Skripten, die dann später
ordentlich in ein Paket überfüllen,
wird 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 zu einem
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
und die Datenbank zu schreiben. Das heißt, der Handschick 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 wenn ihr ein Modell daraus gebaut habt,
irgendwie mit einem Torch oder sowas, was macht ihr dann?
Wo legt ihr das dann hin?
Wir haben ja das dann in dem
Fall tatsächlich,
ich verlege gerade, 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
deinem Modellrepository dann ablegen.
Also eigenes
Modellrepo mit Branches oder
irgendwie Tags oder sowas hier.
Ja, oder
irgendwelche Tags muss man natürlich schon haben, damit man
die einmal heimlich identifizieren kann.
Also gut, wenn jetzt die Modellierung
total schnell geht, dann kann man natürlich auch
das Modell einmal im Monat neu berechnen
oder nee, einmal im Tag neu berechnen
und sofort die Prognosen machen und das Modellobjekt
überhaupt nicht speichern, aber das ist, glaube ich, eher so
ein seltener Fall normalerweise, wenn man es ja schon
speichert, 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 es schwierig.
Oft muss man auch Sachen aggregieren.
Zum Beispiel hat man vielleicht einzelne
Zeilen für jedes Produkt,
das gekauft wurde von einem Kunden.
Wir wollen aber eigentlich nur eine Zeile pro
Kunde. Dann muss man sich halt irgendwas überlegen,
wie man das denn voll aufaggregieren kann.
Manchmal macht man Transformationen
oder berechnet eine neue
Spalte aus anderen Spalten.
Also das ist das, was man 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 modularisieren,
weil es sonst ein bisschen zu viel wird.
Was ist da eure Lieblingsdatenbank für?
Ich überlege gerade,
wir waren früher viel auf MariaDB
unterwegs, jetzt sind wir
ja 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...
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 habe ich auch schon ein gutes Mal gehört.
Ja, also
da haben wir 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.
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 es 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.
Ein bombasites Modell. Aber
es kommen gerade Sachen, zum Beispiel
gibt es da P-F-Enders.
Ja, das klingt auch sehr interessant, ja.
Geil, ne?
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 klingt irgendwie so magic. Also das hat,
hat gelernt, wie
Datensätze, wie die Zusammenhänge in
Datensätzen, Entschuldigung, wie die Zusammenhänge
in Datensätzen normalerweise
so sind und dann gibt man
dem nochmal so ähnlich wie so
ein Feintuning den Datensatz, den man halt
da selbst hat, der einen interessiert
und dann kann man 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 gibt es ja gar nicht so
viele im Netz verfügbar, es ist ja anders, als wenn man
ein Sprachmodell trainieren will und das ganze Internet
besteht aus Sprache, aber es funktioniert
trotzdem, es ist richtig beeindruckend. Also ich glaube,
das ist so was, was sich gerade so anfühlt
wie, okay, da passiert jetzt wirklich mal
wieder was Neues in der
Bereichprognose. Ja, ja, auch diese
ganzen Pre-Trend, das gibt es ja im
LNM-Bereich, gibt es das ja alles oder halt auch bei
so Vision-Modellen,
wo dann alles auf ImageNet oder so trainiert ist, aber
bei tabularen Daten hätte ich jetzt überhaupt gar
nicht gedacht, dass das überhaupt möglich ist oder dass
das irgendwie, dass das, und ja,
das hat mich auch total gewundert, dass
Ihr müsst ja vielleicht jetzt noch ein bisschen kurz
nochmal erklären, bitte, so die Grundlage, ich glaube,
das war ein bisschen komplex vielleicht für
einen Einstieg. Also
TabTFN hast du gesagt?
Und 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 da an einem
bestimmten Tag und in den Daten hätte ich zum Beispiel
die Info, welcher Wochentag ist denn das eigentlich
und ist dann vielleicht davor oder danach ein
Feiertag und um welches Produkt geht es und so
weiter. Wie ist das Wetter? Vielleicht verkaufe ich
ja bei Hitze mehr Wassermelonen
und das ist so der Klassiker,
das würde man auch mit einer
linearen Regression
machen können, die ist aber
weniger flexibel und normalerweise dann auch
weniger genau und XGBoost ist da
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 ein anderes
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 gut.
Ja. 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
lang,
weil ich, ja, es gibt da 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
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.
Ja.
Und ja, witzigerweise,
wir haben auch schon,
ich glaube, vor einem Jahr oder so haben wir gedacht, kann man eigentlich
auch LLMs zur Prognose benutzen? Ich möchte kein
LLM-Jahr 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.
Wir haben da,
ja, 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 da aber auch
nichts Spannendes drin. Und dann fragt
man, wie teuer ist das Auto?
Bitte antworte 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?
Genau. 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
die klassischen LLMs, die man so kennt, und dann
kam eben jetzt dieses Neue mit
TabPFN, das ist ein Transformer, das halt
wie speziell für tabulare Daten wieder gemacht ist,
weil wir haben ja die LLMs eigentlich so ein bisschen zweckentfremdet,
indem wir die dann da nach dieser
Probe-Modell-Sprache haben. 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 ihn dann nochmal,
ja gut, das beschreibt es wahrscheinlich ab dann schon
komplett, wir haben den 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 noch
mal 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 sowas wie XGBoost,
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.
Nee, das kannst du auch nicht mit, das kannst du natürlich dann nur,
also 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.
Ich glaube, wir haben da
beides gemacht, also einmal über OpenAI, da
kann man einfach über die API sein, hier ist mit Fine-Tuning
ein 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... Genau, die haben halt so selber ihre
Ja, mhm.
Bei Tuning und Autos fällt mir jetzt erst auf,
dass das echt total gut passt.
Ja.
Okay, das ist halt so Tab-DFN,
ja? 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
Boost 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
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ählst du 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
XG-Boost meistens ziemlich weit,
aber ja,
zum Beispiel im Sportwettenbereich
gibt es ja manchmal dann wirklich komplizierte Sachen,
also wenn ich jetzt vorhersagen will, wie
die Tore sich
verteilen, dann
kommt man da dann schon nochmal weiter,
wenn man wirklich darüber nachdenkt, theoretisch,
was ist denn das jetzt eigentlich für eine Verteilung?
Das sind Anzahlen, also
ist das 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
Holperstick, die einen ziemlich weit bringt.
Ihr habt also nicht die Ernährung der Spieler
am Morgen zuvor mit einfließen lassen können in sowas?
Das weiß ich nicht, ich müsste mal fragen, ob
sie das Feature drin haben.
Es gibt auf jeden Fall spannende Sachen.
Ja, also ich würde
mich halt tatsächlich interessieren, was man
aus Statistik irgendwie daraus lernen kann, weil ich weiß nicht,
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 Extribus 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
so gesagt hat, aber es ist
schon eher so Blackbox-Modelle.
Ja, man kann jetzt
nachträglich dann...
Also das wäre jetzt vielleicht für mich auch noch mal
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 noch mal 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 noch mal deutlich
bessere Güte kriegt. Das du beschreibst, glaube ich,
Feature-Engineering gerade, oder? Ja, vielleicht.
Ich hoffe es auch, ja.
Also zum Beispiel, viele Modelle
sind ja auch dazu in der Lage, Interaktionen
zu erkennen, also beispielsweise
weißt du, ich
fällt mir gerade gar kein gutes Beispiel an,
ja, vielleicht aus der Luftschadstoff-Prognose
überlege ich gerade, ist
da 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 noch mal 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 ins Windstill. Jetzt in diesem sehr einfachen Beispiel. Und das ist dann, glaube ich, auch wieder sowas, wo es dann wirklich viel bringt, immer mal wieder mit den Leuten zu reden, die sich fachlich damit auskennen.
Ja, also dann hat man quasi tatsächlich schon das Wissen, was man aus den Daten ziehen kann, so ein bisschen annotiert, reingegeben, dass das Modell dann damit besser arbeiten kann. Also als eigene Funktion irgendwie so, ja.
Ja, und oft musst du auch 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.
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, so das XGBoost.
Das kennt halt nur.
Eigentlich nur spaltende Zahlen.
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 noch mal ein bisschen genauer.
Das ist halt die Frage, ob es sich lohnt, muss man sich immer überlegen.
Ja.
Okay, ja gut, aber wir werden, dadurch kann man schon viel rausholen, ja, durch diese Modellierung dann und so.
Okay, dann sind wir in diesen Datenprozessen. Wie nennt man diese Datenprozesse? 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 es 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.
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, ja. Also jeder Business-Prozess, den man irgendwie halt automatisieren kann, ja.
Aber ich glaube, es ist schon oft so, dass man auch sagen würde nachher in einem fertigen Datenprodukt, okay, hier ist der ETIL, jetzt kommt der ETIL und dann kommt der Teil mit dem Modell.
Ja, ja, ja.
Also oft nutzt man den Begriff eigentlich auch, um das so voneinander anzusprechen.
Ja, zu grenzen.
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ür das 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 dann habe 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 Varianz, einen Varianzanteil berechnen.
Man kann, je nachdem, vielleicht wollen wir auch gar nicht mehrische Daten vorher sagen, sondern nur ein Ja, Nein.
Dann könnte man gucken, wie viele Folgen...
Falls positive, falls negative und so weiter habe ich...
Das kommt, ja, stark auf den Use Case an.
Auf jeden Fall kann ich das dann berechnen.
Schön out of sample, also mit diesem separaten Datensatz.
Und das ist natürlich besonders gut, wenn man zwei Modelle vergleichen will.
Wenn man nur eins hat, dann ist da...
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 man...
Ich will nicht so genau vorhersagen 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 es nimmt, die zeitlich am Ende liegen,
weil manchmal ändern sich eben Zusammenhänge.
Und das...
Eigentlich passiert es 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ängenden Erinnerungen
dann irgendwie auch trotzdem mit reinkriegt.
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 dem Geschäft zurückgeben.
Hey, hier, das sind unsere Annahmen.
Guckt doch mal bitte, dass die noch stimmen.
Und wenn ihr merkt, irgendwie da ändert sich irgendwas an den Annahmen,
dann müssen wir halt da nochmal was auch anpassen.
Und 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 nicht 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 die Senatsverwaltung,
hier für Umwelt und so weiter, ja auch nicht sagen.
Also sie können uns sagen, ja, das wird wahrscheinlich schwächer mit der Zeit.
Also klar, solltet ihr das Modell regelmäßig neu trainieren, aber die können uns nicht 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 neuere Zusammenhänge abgedeckt haben.
Deswegen ist es auch manchmal gar nicht so nützlich, ganz, ganz viel Datenhistorie zu haben,
dass 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 keine,
Beispiele 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,
wir 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.
Ja, Luftverschmutzung.
Ja, okay, sonst hätte ich gedacht, oh, das ist eine gute Sache, ja.
Aber ich habe nochmal, ich würde mal kurz, ganz kurz einen Schritt zurückgehen,
weil ich habe 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 hat nicht, 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 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.
Vielleicht nochmal zu dem Modell.
Modell-Training.
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
Azure, was auch immer dann.
Aber das sind oft Sachen,
die dann doch lokal ein bisschen zu lang dauern würden
und dann besser auf einer größeren Maschine laufen.
Also irgendwie, ja.
Und also die klassischen Sachen sind halt
normalerweise einfach auf der CPU natürlich.
Und wenn wir dann aber zu LLMs kommen,
dann geht es natürlich in Richtung GPU.
Und wir haben uns auch da
was zugelegt vor einigen Monaten,
sodass wir uns auch eigene GPUs
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 gestellt
oder habt ihr irgendwie bei Hetzner oder was gemietet?
Die haben wir tatsächlich gekauft physisch.
Die sitzt auch im Rechenzentrum.
Und dann irgendwann haben wir auch mal was ausprobiert
oder weil die dann doch zu klein,
da haben wir das dann über AWS gemacht.
Das ist auch schwierig, gerade welche zu kaufen.
Und das ist sehr teuer.
Mieten ist auch sehr teuer.
Das macht jetzt schon Sinn.
Aber ich glaube, sie war dann irgendwie
zwei Monate später wieder deutlich günstiger.
Ich glaube, wenn man die mietet,
dann kostet die irgendwie so 1.000 Euro im Monat oder sowas.
Naja, 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 drauf 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 mal selber sowas zu machen.
Und das komplett aufzusetzen.
Das macht auch Spaß, ja.
Ist ja auch gut, wenn man das dann mal kann.
Kommt ja der Operator durch.
Ja, ich würde das auch machen.
Ich brauche nur einen Grund.
Gib mir doch einen Grund dafür.
Also vielleicht wollt ihr ein unbezahltes Praktikum.
Wenn wir dann ganz viel
große Hardware nicht haben, können wir nur mal nachdenken.
Richtig.
Das könnten wir mal nutzen.
Vielleicht noch mal
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 wären richtig vorher gesagt
oder wie weit sind wir im Mittel daneben.
Aber dann macht es halt auch Sinn,
diese Blackbox noch mal 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 man das Modell gefunden hat.
Aber da gibt es ganz tolle Methoden,
die nennen sich Shep
und die kann man dann
danach auf die, also man braucht
das Modell und auch noch mal 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 mal ein erster Plausibilitätscheck,
wenn da irgendwas ganz am Anfang steht,
was sehr überrascht ist, sollte man auch überlegen, was da los ist
und dann kann man sich auch die Form der
Zusammenhänge angucken. Zum Beispiel
glaube ich, 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 dann 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, dass wir denken, das liegt
daran, dass dann irgendwann der Wind zu stark ist,
dass halt Staub in der Luft...
Der Abrief von der ganzen Straße, der kommt nochmal mit hoch, ja.
Ja, ist natürlich, wenn dann, wenn es regnet,
dann halt eben wieder nicht, weil dann wird
das eben weggespült. Und dann die Temperatur wieder...
Genau, 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,
dass, egal wie toll
man sich die Daten vorher anguckt, manche Sachen
finde ich, sieht man einfach erst nach der Modellierung
und muss dann irgendwie nochmal ein Stück zurückgehen,
das ist ja kein Problem.
Das ist ja dieser Eval-Step dann,
der dann guckt, ob das, was man da macht,
auch dem entspricht, was man so
möchte. Oder ja,
es gibt ein Alert, ja.
Irgendwas stimmt hier nicht, aber das kann natürlich auch sein,
dass in der Realität irgendwas nicht stimmt.
Das kommt erst später. In dem Moment haben wir noch gar kein Alert,
im 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.
Wir lieben Pytests.
Wobei Tests mit Daten ja auch manchmal
ganz witzig sind, weil
man, ja,
baut man sich dann einen kleinen 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
nochmal schon ein Frontend
dazu, also eine Web-App, wo
die dann angezeigt werden, wo zum Beispiel
unser Kunde sich dann die Alarme
angucken kann von irgendwelchen
Käufen, die irgendwie
suspekt aussehen.
Mit was macht ihr die Web-Apps?
Meistens mit
Vue.js
und historisch auch noch
häufiger mit Asshiny.
Aber das geht natürlich
weg. Da haben wir ein Projekt, das ist eigentlich ganz
cool, da haben wir, da geht's
gar nicht darum, irgendwelche Prognosen zur Verfügung zu stellen,
sondern
da haben wir ja 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.
Das ist natürlich auch sehr praktisch.
Ja, und schreiben die dann mit ihre Doktorarbeiten.
Ja.
Ja, aber zurück
zu unseren Prognoseergebnissen.
Genau, oft stellen
wir die über eine API zur Verfügung oder wir
schreiben sie irgendwo in eine Datenbank und der Kunde
nutzt sie dann halt so. Das ist tatsächlich ja 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
nochmal was Kleines bauen, damit die
dann doch was sehen können.
Aber wenn die Farben dann auch richtig sind,
das ist das Wichtigste an Flickrücken.
Ja, das kann man auch durch
unterschätzen. Man sieht ja alles, ja,
das ist sau hässlich.
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 zu
sollte man sich das Modell sogar auch nochmal ganz genau
anschauen, zum Beispiel nochmal diese ganzen
CHAP-Sorten 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
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.
Und
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
Halb-Berlin-Prognosen erstellt werden
oder nur für einen halben Tag und deswegen
sind dann da auch Alarme definiert,
die gucken, ist die Anzahl,
entspricht die Anzahl der Prognosen in der Datenbank
auch tatsächlich unserer Erwartung?
Man kann auch definieren, gibt es irgendwelche
unerwarteten Werte, extrem hohe Prognosen
beispielsweise oder gibt es
unerwartete Werte in den Input-Daten,
Werte, die vielleicht überhaupt nicht definiert
sind und dann
auch wichtig ist der
Model-Drift oder Data-Drift,
das heißt, dass die Daten
so nach und nach irgendwie in eine andere Richtung
driften und sich verändern
oder das Modell so nach
und nach immer so ein bisschen schlechter wird,
aber irgendwann, wenn es das lange genug
gemacht hat, dann ist es halt irgendwann nicht mehr gut genug
und dann möchte man das ja auch mitbekommen
und zum Beispiel bei jedem monatlichen Modell-Neutraining
will man auch mal die ganzen
KPIs, also die ganzen Gütemaße sehen
oder vielleicht will man
sie nicht angucken, sondern möchte halt einfach informiert
werden, ob die sich nach einer Weile
vielleicht zu stark verschlechtert haben und dann muss man
sich einfach nochmal angucken, was los ist.
Was halt eben auch nochmal zeigt, das 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 Reader benutzen
wir in einem Projekt ja ganz
gerne und sonst
ja, wie das, was ich gerade
dann anbiete, ich überlege
gerade, was wir sonst noch 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, weil 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. Ja, also Telegram kriege ich auch Nachrichten
für meine Server, falls da irgendwas passiert,
was ich will, ja.
Ja, cool.
Gut zu wissen.
Ja, das ist ja auch nochmal so ein spannendes
Thema, weg von US-Diensten
und so. Ja, wahrscheinlich
genau, das ist natürlich
wenn Telegram irgendwie an der richtigen
Adresse ist.
Man soll ja streuen.
Ja, ja, genau.
Ja, 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, man braucht irgendwie so ein Referent, ja.
Ja, aber ja, klar, es wird dann auch teuer.
Monitoring ist ja zu ruhig, was passiert denn da jetzt?
Ja, 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, also noch ein ganz wichtiges Stichwort
in dem Bereich ist natürlich MLOps,
also Machine Learning Operations, also
Mischung aus DevOps und Machine Learning
ist das Wort.
Der Kurzvortritt ist ja Rathops, oder?
Ja, genau.
Und
ja,
ja, es ist ja im Prinzip
DevOps, aber Anpassung auf diesen,
auf den Datenkäse, auf die Arbeit mit Daten.
Das heißt, es kommen noch so ein paar Sachen
dazu, wie zum Beispiel, dass man nicht nur
Code versionieren muss, sondern auch
Modelle oder vielleicht Experimente
versionieren.
Und ja, es gibt halt nicht nur
Code-Änderungen, die dazu führen, dass die
Ergebnisse anders sind, sondern auch jeder
neue Datenpunkt kann
die Ergebnisse verändern.
Das heißt, da kommt dann nochmal so eine
Zusätzlich-Komplexitätsebene mit rein.
Ja, das
ist auch, 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... Du hast halt einfach viel zu kleine
Adventures. Meine Daten sind zu klein, das kann schon sein,
ja, aber ich meine,
man kriegt heute so große Maschinen, also...
Ja, über die Preise haben wir uns
ja gerade unterhalten, ja.
Ja, ja, aber wenn man CPU,
die meisten Sachen brauchen wir mal eher CPU,
dann das ist nicht so toll.
Okay. Aber 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
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,
was 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.
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,
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 man den 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 bisschen drüber reden, wie man das machen
kann und auch aktivieren 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. Und
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? Und
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 Paket-File beispielsweise
dann irgendwie immer ein Stückchen hier liest, ein Stückchen
da liest,
die ganze Zeit random irgendwie
zwei Gigabyte I.O. macht, dann
ist das alles total langsam und sieht so aus,
als ob es nicht schneller gehen würde.
Und tatsächlich
ist es aber, ist es aber
eine ganz einfache Optimierung, die dazu
führt, dass es halt,
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 sowas, 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. Das, ich glaube, das ist doch von dem...
Was, was, 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 es sagst, ich hab gerade, ich glaube,
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 es mal gesagt hat, klingt's ja trivial,
aber ich glaube, wenn man
es zum ersten Mal macht, dann vergisst man es.
Ich glaube auch, dass viele Leute halt nicht so bewusst sind.
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, X-Wing-Boost,
ja, eher nicht.
Ja, die Frage ist, wie
sehr man das auch manuell machen
muss, weil man ja meistens dann
sich seinen Class-Data-Breaks 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 beschrieben 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, 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 durch Mais eben über den Data-Frame
drüber loopst, einfach so verweilt.
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, weil es auch von Wes McKinney
ist halt dem Pandas-Menschen,
der...
Ja, der hat ja eine ganze Menge, der ist auch hinter dem,
äh, Arrow, das ist halt so seit einiger Zeit
sein Hauptprojekt.
Ja, 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
drauf 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 Peiss-Bug oder sowas dann berechnen,
dass man dann... Ja, also alles, was
irgendwie SQL spricht, kannst du da,
soweit ich weiß, ist einfach nur ein Layer, wo du
halt ein Data-Frame-Interface
hast nach außen hin, sodass du es benutzen kannst
wie einen normalen Data-Frame, aber nach hinten raus
spricht es dann halt SQL.
Was halt, ja,
wenn du ein System hast, das das kann, dann ist es...
Ja.
Ich glaube, wir haben schon viel
über diesen Prozess, wie wir das gesprochen haben,
Crisp, sind wir durch?
Ja, eigentlich sind wir durch und dann kann man ja wieder von Anfang
an anfangen und sich den nächsten
Next-Best-Use-Case-Schlamm unternehmen.
Oder das, was man schon hat, halt noch mal
erweitern, überlegen, ob man es
auch 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 halt natürlich auch total wertvoll.
Ja, es gibt
diese Schwerpunkte, aber
greift ja auch alles ineinander und
es ist ja auch so, dass
es halt Sinn macht, so ein T-Shape-
Profile aufzubauen, also dass man in einer
Sache schon wirklich gut ist, aber
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 übertroffen hat oder
weil wir alle ersetzt werden durch
sowas, genau.
Ja, 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.
So aus meiner Perspektive ist das, ich meine, das mag
jetzt etwas ketzerisch klingen, oder ich weiß nicht, vielleicht
so Hot-Take-Verwandlung.
Ich würde sagen, das ist alles
Programmieren. Oder, sag mal 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.
Ist halt das Bottleneck aus
sowas.
Also 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
da 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
Programmier-Dings 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, womit 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 die 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 so, ich meine, das ist halt auch das,
womit man täglich zu tun hat. Excel.
Ja, ich meine, es gibt ganz viele Leute, die machen halt einen Großteil
von dem Zeugs halt mit Excel.
Alle Leute 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 für manche Sachen ist es vielleicht gar nicht so schlecht.
Pederize ist heuer.
Ja.
Aha, jetzt hatte ich mit 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.
Das geht alles, ich habe da kein Problem
mit.
Ich generiere auch Excel-Output und ich lese
auch Excel ein.
Ja, also einen schönen Output machst du.
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
habe ich 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.
Die haben halt ihren Prozess, der ist immer schon so und dann ist es
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
die irgendwie die Ergebnisse liefern.
Ja.
Ich glaube,
wir sind bei den Picks angekommen, oder?
Ich glaube, Mira, du wolltest noch 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, ob sie 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 das
kann im Moment noch kein
High Spark DataFrame oder Spark DataFrame
nehmen, deswegen muss man dem
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 Hynix neues Video gesehen
und das ist Just Love
also ich habe Just Files für mich entdeckt,
die hatte ich vorher
nicht so auf dem Schirm, dass das so ein bisschen
was ähnliches wie eine Makefile nur, dass man halt
in einer Just File, das ist auch ein Rust geschriebenes
Tool, definiert, wie so die
Projektkommandos eigentlich alle sind
und dann kann man, das ist
wundervoll mit Variablen und so, es funktioniert
toll, Hynix 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 bei ihnen noch ein bisschen selten, sondern
einfach nur Just, 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 können, wenn ich das 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 toll, oder? Ja, voll gut,
finde ich auch, deswegen Just Love.
Okay, ja, ja, ich habe ja auch tatsächlich
nachdem ich das Video
gesehen habe, habe ich mir auch gedacht, so, ha, vielleicht muss ich
das auch mal ausprobieren.
Hm, ja, ich,
ich meine, das ist toll, du kannst auch
nach dem Just Build und du, der macht mit UV, macht
dann direkt Paketinstallation, Paket Sync,
kannst Upgrade machen,
alle Sachen mit den
Kommandozeilen, die du sonst immer nutzt, reinschreiben und wenn du das
über so eine Commands-Pi geregelt hättest oder sowas, musst du halt
immer dann einen Subprozess spawnen und so,
ah, ich weiß nicht, das war jetzt 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 so sehen.
Ja, kommt drauf an, aber, also ich
hab das halt oft und dann kann ich halt auch
irgendwie in PyProject, Project Terminal
halt unter Scripts halt andere Entry Points
definieren und da hab ich halt Funktionen, dann hab ich's
jetzt nicht in der Command UI, sondern
ich schreib 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
anmachen. 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, äh,
gucken, du kannst Environment-Variablen da reinladen
oder spezifisch, wenn das da irgendwie passt und
ähm, du hast grad eine Sache
gesagt, Pakete, also du könntest ja auch einfach aus der
PyProject Terminal das PyScript dann ausführen lassen und bei mir ist
zum Beispiel so, dass die Dinge
im Python und im anderen Verzeichnis liegen
als das Projekt und, äh, die Dokumentation
oder sowas und trotzdem,
wenn ich das Just benutze, benutzt es halt dann auch
den Kontext, du kannst Work in Directory setzen.
Toll.
Ja, okay, also ich muss mir vielleicht auch
nochmal angucken.
Ja, mach das, das ist, äh, ja.
Backing. Wie Sockzeit.
Geht nicht mehr weg. Okay.
Naja, äh, ja, äh, genau,
was, äh, 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, das
bist du besessen? Ja, das ist ja, ich mach
ganz, äh, Cloud-Code
und Dinge mit, äh,
äh, mit LLMs
irgendwie programmieren und
Das ist schon verrückt, also ich weiß nicht, ob
du hast auch noch mehrere, aber, ähm, die Kosten sind halt
krass und wir, wir benutzen jetzt halt Max.
Ja. Das ist halt das Abo,
wie teuer ist das, 200 Euro? Ja.
Ja, gut, es gibt auch 1 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, weil, genau, das würde ich
jetzt dann picken, es gibt da ein,
äh, ä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, 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, ja.
Ja. Ja.
Ha. Die, die
sind gefährlich, die Dinger, die machen uns alle obsolet.
Wir werden sehen.
Ah, das glaube 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 jetzt 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 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 mache das jetzt bei mir, 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
habe, 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
gucken muss, was der macht.
Ja, also bei mir hat auch Cursor jetzt raus, Adventure
von Eva kauft, aber Cursor ist raus, nur noch
Code, also nur noch Kommandoteile und ich bin wieder
wie das Code und das ist super.
Das, also, kann ich nur empfehlen.
Ist verrückt. Ja, ist grad,
ist grad verrückt, ja.
Es macht halt so 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,
dass ich irgendwie, warum ich, genau,
während meine, meine, meine
die, die, die 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 ist so, also 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
etwas Spannendes zu erzählen, aber trauen sich nicht so
richtig im Podcast, kann ich verstehen, ist okay.
Aber wenn man dann die Stimme einfach nehmen könnte,
dann können sie einen Text schreiben und dann könnte man
den Podcast einfach generieren. Ja, das geht,
das 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 leider 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, LLM Labs 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örerintreffen.
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 meinen
Data Science Deep Dive rein. Genau.
Große Empfehlung. Bis bald.
Tschüss. Tschüss.