Transcript: Data Science

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,

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.

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