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.

Mira, hallo.

Schön, dass du da bist.

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

Wir reden über Data Science. Wir wollten, glaube ich, nochmal ganz von vorne anfangen, weil wir noch nicht so viele Data Science Folgen hatten

oder uns vorgenommen hatten, noch einige mehr davon aufzunehmen, als wir das 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 Spezialität.

Ich habe da auch ein Projekt. 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.

Immer auf Hesche-Stick.

Und da hat mir auch 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 ich glaube 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.

Zum Hörertreffen wird es dann wahrscheinlich auch nichts für mich, wenn es ein bisschen zu weit ist, um mal kurz vorbeizukommen.

Und die Deutsche Bahn hatte ich letztes Wochenende wieder von Berlin hierher. Das war wieder hervorragend.

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

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 Projekte.

Ich bin dann immer mehr in die Projektleitung gegangen und da passt es dann ja auch wieder mit der Psychologie.

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 einzelne Projekte, 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 große Projekte.

Warum ich jetzt hier sitze und ihr mich kennt.

Ein Unternehmenspodcast, in dem ich manchmal, aber auch noch 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, gut.

Also, was ist denn eigentlich Data Science?

Ja, also ganz gefolgen 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 vorhersagt und dass man teilweise sogar entscheidet.

Und dann trifft entweder manuell oder sogar automatisiert auf Basis von Daten.

Oder anders gesagt, man will halt aus großen und auf 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 so.

Ja, also Statistik ist auf jeden Fall.

Ja, ein Teil ist ja auch so, manche sagen ja Statistik oder Maschinen.

Ja.

Das überschneidet sich aber 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 den Bereichen, in denen 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 das, was aus der Informatik kommt, damit man seine Analysen irgendwie programmieren kann.

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

Also, dass ich super gut coden kann, dass ich auch noch super gut in Statistiken und Maschinen bin.

Und dann gleichzeitig auch 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 davon gewöhnt, dass wir uns schnell...

Ja.

... neue Themen reinfinden.

Trotzdem brauchen wir in einem neuen 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.

Genau.

Das ist sehr schwierig.

Auf dem Level, dass man halt versteht, was man gegenseitig voneinander will oder was man bereitstellen kann oder wie lange das dauert.

Und Sachen, die man auf der einen Seite für einfach hält, sind auf der anderen Seite vielleicht ein bisschen schwieriger.

Aber...

Aber ihr seid dann auch meistens tatsächlich...

Du hast es eben schon angesprochen.

Body Leasing, also quasi in den Teams selber unterwegs und...

Unterschiedlich.

Ach so.

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

Ja.

Das gibt es auch.

Wir sind...

Ja, sehr, sehr unterschiedlich.

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

Die haben auch selbst eine Data Science Abteilung, aber die Aufgaben sind dann so verteilt.

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

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

Ich bin aber mehr im Data Science-Bereich unterwegs.

Und wir haben eben ja auch zunehmend das Thema Body Leasing.

Das war früher irgendwie kaum.

Weil früher hatten viele Unternehmen auch selbst keine Data Science Abteilung.

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

Und inzwischen ist es eher so, dass die Unternehmen, die groß sind...

und die überhaupt von der Kultur her in Richtung datenbasiertes Unternehmen gehen,

die haben jetzt eine Data Science Abteilung, aber die haben dann halt hier und da mal Lücken und finden niemanden.

Und nehmen uns dann dann dazu.

Mhm.

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,

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 weiterempfohlen 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 nicht so gut.

Ein bisschen simpler, aber auch wird es dann doch irgendwie schon ein bisschen komplexer.

Wir sind aber auch tatsächlich darauf spezialisiert.

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

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

Ja, wie kommt man denn eigentlich zur Data Science?

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

Ich habe...

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

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

Ja, auf jeden Fall. Also das ist auch so ein typischer Hintergrund.

Ich habe ja in dem Statistikmaß, da waren viele, die vorher Mathe gemacht haben, aber auch viele mit ganz anderen Hintergründen,

viele Wirtschaftswissenschaften, aber auch KollegInnen mit Soziologie Hintergrund oder Physik.

Ich glaube, das ist sogar so ein bisschen ein Klassiker, dass die Physiker sich irgendwie dann in die Statistik,

in die Machine Learning Welt verirren.

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

Das klingt irgendwie witzig.

Ich habe jetzt auch...

Nur Leute, also jetzt sind es schon, ich glaube schon drei Jahre bei uns, aber ja, vorher hatten wir 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.

Naja, BWL ist ja auch nicht VWL zum Beispiel.

Ja, scheiße.

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...

Interessante Geschichte.

Das habe ich auf jeden Fall, auf jeden Fall in den Data Science Projekten, in denen ich so unterwegs war,

halt auch irgendwie immer wieder gesehen, dass halt oft die Leute...

Also ich weiß nicht, wie das bei euch ist, ob ihr...

Weil normalerweise Softwareentwicklungsgeschichten, die ich so mache,

da habe ich dann halt eben mit Abteilungen zu tun, die halt irgendwie Softwareentwicklung machen oder so.

Aber bei den Data Science Geschichten ist es immer sowas wie Business Intelligence oder so.

Und das sind andere Leute.

Das sind ein bisschen so...

Die sind so ähnlich...

Also das sind oft irgendwie Leute, die was Naturwissenschaftliches studiert haben oder so,

dann da promoviert haben.

Genau.

Das ist oft aus der Ecke eher.

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

Und das ist irgendwie ein bisschen anders als bei den Softwareentwicklern.

Und die haben auch meistens oft so ein bisschen so, ja, Produkte entwickeln oder so,

das ist jetzt eigentlich nicht so unser Ding.

Genau.

Und das ist irgendwie eine etwas andere Welt.

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

Und da wollte ich dir auch nochmal was zu sagen, wie du das so findest, mit der Softwareentwicklung zusammenzuarbeiten.

Ja, 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 es hängt dann halt von zwei Sachen zusammen.

Und BI-Abteilungen sind, glaube ich, auch nochmal mehr...

Ja, sie 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 nerd.

Ohne Wertung zu sagen.

Oh, ja.

Ja, aber was du eben gefragt hattest...

Das ist auch jetzt ganz spannend.

Ich bin jetzt im Team, wo eigentlich...

relativ klar zugeordnet ist, wer ist Data Scientist und wer ist Software Engineer.

Und natürlich arbeiten wir alle an dem Code.

Aber es gibt eben so ein paar Klischees oder so Dinge, die man vielleicht beobachtet,

wenn jemand, der vor allem einen Softwareentwicklungshintergrund hat,

jetzt zum ersten Mal versucht, Daten zu analysieren und Data Science zu machen.

Wir haben auch mal ein Projekt übernommen, wo wir entsprechenden Code dann...

Tatsächlich sollte man ja refactoren und wir haben auch viel refactoren.

Aber da haben wir einen Teil wirklich neu geschrieben.

Und das...

Am Coding-Stil hat man schon gesehen, dass der einfach gar nicht wusste,

dass man mit Datensätzen Sachen machen kann.

Der hat halt immer ganz viel geloopt über Zeilen und Spalten und so,

weil er halt einfach diese ganzen Sachen nicht kannte,

die man mit Datensätzen machen kann, vor allem mit Pandas.

Und was sonst auch, wenn man zusammenarbeitet, halt oft passiert,

ist, dass jemand, der nicht viel mit Daten gearbeitet hat,

die Ergebnisse halt so nimmt, wie sie sind und da irgendwie ganz unkritisch...

Und gar nicht sieht, wenn irgendwelche Zahlen ganz komisch aussehen.

Und manchmal ist ja vielleicht der Code gar nicht falsch,

aber es ist irgendwo ein Denkfehler drin.

Also der Code macht, was er soll, nur das, was er soll,

das 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 reines Softwareentwicklung macht,

ist es, glaube ich, noch mal schwieriger, in den Daten drin zu sein und die zu interpretieren

und zu sagen, Moment mal, also die Kurve sieht ja echt komisch aus.

Aber also eigentlich mag ich es total gerne, wenn das Team gemischt ist,

weil auch nicht alle Data Scientist so richtig auf guten Code achten.

Also das ist uns sehr wichtig.

Und wenn jemand halt noch nicht so gut programmieren kann

und aus dem Studium kommt und dort jetzt einsteigt,

dann ist das das, was die Person dann lernt, so wie ich damals.

Ja.

Aber ich glaube, das ist auch nicht überall so verbreitet,

weil manche haben dann eher einen Schwerpunkt auf 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, ja, interessant.

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

Ja.

Also wenn ich das immer sehe, was so Data Scientist schreiben,

dann stag ich immer die Hände über dem Kopf.

Smarties.

Ja.

Also das ist ja auch relativ, es gibt natürlich Unterschiede.

Ja.

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

Also man schreibt als Data Scientist oft so die ganzen Prozesse untereinander

und muss erst mal lernen, die Methoden zu definieren und so, ja.

Und warum soll man denn, also wenn man das nur einmal macht,

warum soll man denn eine Funktion schreiben?

Und man kann ja Zeit für Zeit ausführen und die Funktion braucht man ja nur,

wenn man zweimal dasselbe macht.

So ist dann glaube ich manchmal die Denkweise, wenn man eben mehr aus der Analyse kommt

und da so quer einsteigt.

Ja.

Und dann kann man das einfach manchmal, wenn Leute schon promoviert haben und das ist,

die haben total krasse Sachen gemacht, aber können dann halt auch keinen guten Code schreiben,

weil das für die Doktorarbeit eben ganz andere Anforderungen hat.

Ja, da ist auch oft, also gerade, Spaß, Physiker, die sind da ja oft eher so verdorben.

Die haben dann irgendwie Vortragen geschrieben oder sowas.

Oder C++, das war auch nicht viel besser.

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

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

Aber das ist auch so ein bisschen, ja.

Aber das ist auch so ein bisschen, man lernt das ja auch nirgendwo, ne?

Außer wenn man jetzt irgendwie quasi bei einer Firma anfängt, die das halt auch irgendwie täglich macht oder so.

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

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

Das denke ich auch.

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

Ja, das ist auch interessant, ja.

Also, ja, also die Sachen, die ich gerade genannt habe, also es ist oft so, die Ergebnisse so unkritisch beurteilt werden,

dass man eigentlich nur guckt, ob der Code richtig läuft.

Und das macht, was man implementieren wollte.

Und das eben, ja, man dann nicht unbedingt erkennt, dass die Ergebnisse eigentlich implausibel 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 sagen, wenn man die Kirchturmspitze ausrechnet, dass die Höhe dann 245 im Minus ist.

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

Ja, genau.

Also, das ist natürlich ein gutes Beispiel.

Und manchmal habe ich auch den Eindruck, dass, ja, ich glaube, dass das Modell, das ist ja auch ein gutes Beispiel.

Ja, genau.

Und dass dann wiederum, wenn man sehr, sehr stolz auf seine Software-Entwicklungskills ist,

dass dann auch unnötig komplizierte Patterns auf irgendwelche Sachen geworfen werden.

Und das dann auch wieder so pragmatisch ist und sehr schwer wartbar.

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

Und wenn man dann irgendwas in einem Elfenbeinturm baut, dann, ja, war das vielleicht auch einfach am Ziel vorbei.

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

Ja, klar, das sollte ich auch machen, ja.

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 nochmal als Hint, also irgendwie datatowiz.com oder sowas.

Die benutze ich immer, wenn ich nicht weiß.

Das kann man nicht sagen, weil ich so gerne.

Also, er macht es natürlich die ganze Zeit, aber es ist an verschiedenen Stellen eigentlich total wichtig.

Also, zuerst mal, wenn man die Daten reinbekommt, dann sind wir jetzt eigentlich schon so mitten im typischen Ablauf,

aber ich kann da, wollen wir zwar noch vorgesprochen haben, kann da noch mal vorbeikommen.

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 zu machen.

Und das sind auch die Sachen, die wir dann oft mit unseren Kunden wiederum anschauen.

Und so, dann gucken wir 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 uns auch sehr wichtig.

Ja, das ist auch ein sehr guter Punkt.

Ja, das ist auch ein sehr guter Punkt.

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

Und 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 auch noch so, dass wir so einen Datendump bekommen haben.

Und hatten damit dann was gemacht.

Und da waren wir noch in R unterwegs und haben 4G-Plot 2 benutzt.

Und inzwischen sind wir dann meistens in einem Dashboard-System unterwegs, das halt beim Kunden einfach genutzt wird.

So dass wir dann in dem Tool, was der benutzt, das implementieren.

Sei 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...

Ja, genau.

Wie heißt das denn jetzt noch?

Ich habe den Namen nicht...

Not-lead-dash oder detray-dash.

Readash, genau.

Readash ist ein Open-Source-Tool.

Das nutzen 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.

Ja.

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

Ihr habt jetzt irgendwie die Daten.

Ich glaube, du wolltest auch nochmal darauf 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 dem Unternehmen als Data Science die ganze Zeit ist.

Aber für mich als Beraterin sind das so...

Ja, eigentlich so sieben Schritte.

Erstens das Problemverständnis.

Dann die Daten einzusammeln und zu verstehen.

Dann die Datenaufbereitung.

Dann kommt die Modellierung.

Man merkt schon, es 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 man das so 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...

Es ist bei uns dann tatsächlich überhaupt so, dass KundInnen zu uns kommen und schon was haben, was sie...

Also sagt schon das, was sie brauchen.

Das geht dann auch in die richtige Richtung.

Manchmal macht es aber trotzdem Sinn, sich das nochmal genauer anzuschauen und 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 und einen Kick-off haben, wo wir mit den Kunden sprechen, um das Geschäftsmodell zu verstehen,

um genau zu verstehen, wer das eigentlich nutzen wird, was die genau machen wollen.

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

Brauchen die zum Beispiel etwas in Echtzeit, dann ist es ganz anders, als wenn man jeden Morgen eine aktuelle Konsequenz berechnet,

und wer sitzt da und wo benutzen die das genau?

Ist es irgendwo an einem Kounter, oder ist es am Telefon, oder ist es irgendwo, wo es kein gutes Internet gibt und so

und all das muss man natürlich, um herauszufinden, was die brauchen, und dann ist der nächste Schritt, sich zu überlegen, wie können wir das machen und haben wir eigentlich auch die passenden Daten,

Und dann haben wir vielleicht die notwendigen Daten und ein paar andere Sachen sind vielleicht nicht ganz so notwendig, man kann trotzdem anfangen.

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

Besorgt ihr die dann auch? Also baut ihr irgendwo neue Sensoren ein oder sowas und kümmert euch darum, dass sie in irgendwelchen Datenbanken landen, die ihr dann zur Auswertung mit benutzt?

Oder geht ihr davon aus, dass das Business alles mit besorgt?

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

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

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

Normalerweise sind die da schon relativ weit oben auf der Datenreifeskala.

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

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

Also die Daten sind eigentlich immer schon da.

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

Weil vielleicht ist man ein richtiges Data Warehouse da oder man kann die nochmal zusammenführen.

Dann ist es noch ein weiterer Weg, bis wir da tatsächlich loslegen können.

Wie würdest du denn...

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 man es wahrscheinlich von Anfang an auch berücksichtigen.

Ich habe ja noch nie ein Unternehmen gegründet.

Ich bin ja geschickt erst eingestiegen, als das Unternehmen schon da war.

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

Oder zumindest relativ früh dann.

Und was für Technologien benutzt ihr so mit Python für diese einzelnen Schritte?

Ja, also wir sind natürlich ganz viel mit Pandas unterwegs.

Von der Datenaufbereitung über die Modellierung.

Da kommt dann auch sowas wie Scikit-Learn dazu oder TensorFlow, Keras, PyTrips, eigentlich so die Klassiker.

Pandas ist ein interessantes Thema.

Weil Pandas, also wer schon mal mit Pandas im Kurs von Daten gearbeitet hat, denkt sich jetzt unbedingt, ich will es durch mich hören, weil Pandas halt sehr, sehr viel Arbeitsspeicher braucht, wenn die Daten so zu größer sind.

Es ist aber natürlich zu Prototypen oder generell für kleine Daten.

Das ist 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 halt...

Aber ich meine, die Erfahrung, die ich oft mache, ist, dass man die, bei vielen so kategorialen Variablen oder so, die kann man dann halt auf irgendwie einen kleineren Datentyp irgendwie runter komprimieren.

Oder halt oft hat man dann halt irgendwie für viele oder wenn man jetzt nur Flex hat, irgendwie ja oder nein oder so.

Wenn man da nur ein Bit nimmt, ist halt sehr viel weniger, als wenn man da irgendwie ein volles Integer oder so für nimmt.

Und 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, wenn du so mehrere Jahre stündliche Verkaufsdaten von ganz vielen Artikeln aus ganz vielen Filialen aus mehreren Ländern hast, dann wird es irgendwie schwierig.

Und dann ist das Verteilte schon gut.

Und dann gibt es halt noch Polars.

Womit man dann...

Wo man auch oft schneller ist und halt auch weniger Arbeitsspeicher braucht.

Also vielleicht ist es nicht, Herr Polars, das ist ein Rust nachgeschrieben mit der gleichen API, so ein bisschen wie Pandas.

Ja, es hat eine sehr viel saubere, also kleinere.

Es hat weniger Funktionen, aber es ist halt auch ein bisschen konsistenter.

Bei Pandas ist halt auch irgendwie sehr stark historisch gewachsen.

Und man wusste noch nicht genau, wo man hin will.

Und dann teilweise inkonsistent.

Und ja, Pandas ist halt...

Wie das halt so ist.

Genau, wie das halt so ist.

Ja.

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 aufzuimplementieren.

Oder ob die vielleicht sogar sagen, es soll schlanker bleiben.

Genau.

Ich meine, 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 Prio NumPy?

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

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

Vielleicht 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 ist ein Datensatz in Pandas?

Ist das jetzt eine Wissensfrage?

Ja doch, wir müssen ja vielleicht schon erklären, wie das funktioniert.

Ja, um die Daten anzugucken, würde ich...

Na gut, es ist irgendwie schön, wenn man einmal so ein bisschen den Head anzeigt, also die ersten paar Zeilen,

und sieht, was da eigentlich so grundsätzlich, was das für Spalten sind, welche Namen die haben und welche Zahlen da so ungefähr drinstehen.

Und dann würde ich aber relativ schnell in eine deskriptive Analyse gehen und mir beispielsweise von jeder Spalte dann Summary Statistics,

also Minimum, Maximum, Mittelwert, Median, vielleicht Quantile anschauen oder eben auch Verteilungen plotten,

sodass man das sieht, Kategorien anzeigen, je nachdem, was das so ist.

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, um wirklich Insights dann zu haben und die Daten zu verstehen.

Ja, muss man dann, wenn der Datensatz groß genug ist, natürlich in die Summary Statistics gehen.

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

Und oft haben unsere KundInnen ja genau diese Analyse auch noch nicht gemacht und laden dabei auch mal 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.

Da eigentlich gar nichts 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 dann haben sie es dann gesehen durch unsere Datenvalidierung, dass da irgendwo ein Problem ist beim Zusammenführen.

Ja, spannend.

Also manchmal sagt man, ich habe einmal den Fall gehabt, dann waren die ganze Zeit irgendwelche so Irregularitäten irgendwie in so einem Datenfoto, die da gar nicht hingehörten.

Und dann hat man eben gewundert, 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.

Das ist natürlich auch, wenn man dann sieht, ah ja, hier gehen die Sales hoch, da war unsere riesige Werbekampagne und das macht alles Sinn.

Und das ist natürlich auch schön, wenn es einfach funktioniert und man das in den Daten sieht.

Ja, auf jeden Fall.

Was mich noch interessieren würde, wenn ihr tatsächlich so Produkte baut mit Modellen drin und so und die vielleicht Echtzeit irgendwas.

Wie?

Wie?

Wie?

Wie pläut ihr eigentlich eure Modelle?

Oder habt ihr da Präferenzen?

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.

Ja, klar.

Aber tatsächlich, wir sind ja dann auf einer Infrastruktur von Kunden unterwegs.

Aber manchmal zum Beispiel hatten wir ein Projekt, da darf ich zum Glück auch drüber reden, dass man ja was bei jedem, was man macht,

das war für die Berliner Senatsverwaltung, eine Luftscharstockprognose.

Also es läuft auch noch, aber das sind ja einfach nur noch Wartungen, das ist so weit beschlossen.

Und die haben keine Vorgaben gemacht zur Infrastruktur.

Die haben halt kein ABS oder Älter.

Und da konnten wir es halt so machen, wie wir wollten.

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

Da 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 im Hintergrund 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.

Da 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 die API ist frei verfügbar, könnte auch jeder abrufen.

Haben auch schon ein paar andere dann mal gemacht.

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

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

Jetzt bei den Kunden, wo ich bin, sind wir im Azure-Universum.

Wobei ich da mit dem Deployment nichts zu tun habe, weil das machen dann halt andere.

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

Also kann irgendwie in die Kubernetes-Codes mal reingucken.

Aber ich kann das nicht aufsetzen oder mache dann nicht die Deployments.

Das Problem, das ich da mal hatte, ist,

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.

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 Kontrapaket zu bauen, das hochzuladen,

in Django Filefield zu speichern und dann auch über eine JSON-API dann die Ergebnisse wieder zurückzugeben.

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

Also 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 nur in Jupyter-Notebooks unterwegs.

Sondern ja, entweder, wenn wir was schnell visualisieren wollen,

geht es tatsächlich ja mit so einem Tool wie Relash auch schneller,

als wenn man dann anfängt,

dann, ähm,

mal Plot-Lib-Code zu schreiben.

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

Ähm, 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,

äh, wenn die, zum Beispiel, wenn die Versionsnummer sich geändert hat,

wird es dann, über Jenkins wird ein Job getriggert,

äh, der dann das Paket baut.

Und eben unser Repository hochlädt,

das dann, man weiß nicht, intern verfügbar ist.

Und, äh, dann können wir,

ob das dann automatisch deployed wird,

oder wir das irgendwie manuell machen können,

ist dann halt nur liegen.

Ja, aber dann brauchen,

aber dann brauchen ja die Leute,

die quasi modellieren Zugriff auf, äh,

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.

Äh, ja.

Also, die, die committen von morgens bis abends.

Ja.

Also, das ist,

das ist tatsächlich bei uns überhaupt nicht so,

dass da irgendwie jemand sitzt, der nur in einem Notebook prototypt.

Mhm.

Gar nicht.

Also, wenn das Projekt losgeht,

dann muss man als erstes ein Repo anlegen,

weil sonst kann man ja gar nichts machen.

Ähm, ja.

Ja.

Und vielleicht startet man dann irgendwie mit ein paar Skripten,

die dann später ordentlich in ein Paket überführt werden

und in Funktionen und Klassen verpackt.

Das kann schon sein, aber grundsätzlich,

ja, ist es halt,

eine Software,

und sonst auch oft,

mit mehreren Paketen,

zum Beispiel so einem, ähm,

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 einzulehnen,

um zu formatieren, die Datenband zu starten.

Das heißt, der Handshake ist dann über die Datenbank,

dann kommt irgendwann das nächste Paket,

das liest sich die Daten dann,

und macht dann die Modellierung.

Und dann gibt's nochmal ein Paket, das halt, ähm,

irgendwelche Daten weiter aufbereitet,

und dann gibt's ein Paket mit der API.

Und das, also, wenn ihr ein Modell daraus gebaut habt,

irgendwie mit einem Tort oder sowas,

was, was macht ihr dann?

Wo, wo legt ihr das dann hin?

Ähm, ja, wenn das dann in dem Fall tatsächlich,

wo liege gerade, also tatsächlich, ähm,

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,

ja, das ist ganz witzig,

ja, es gibt tatsächlich,

das war jetzt so ein, ein Projekt mit XGBoost, weiß ich nur,

da haben wir,

kann man die,

Projekte tatsächlich in,

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,

ähm,

in einem Modellrepository dann ablegen.

Also eigenes Modellrepo mit, äh,

Branches oder irgendwie Tags oder sowas hier.

Ja, oder, ähm,

ja, irgendwelche Tags muss man natürlich schon haben,

damit man die dann nachher wieder identifizieren kann.

Ja.

Also gut, wenn jetzt die Modellierung total schnell geht,

dann kann man natürlich auch,

das Modell einmal im Monat neu berechnen,

oder nee, dann einmal im Tag neu berechnen,

sofort die Prognosen machen und das Modellobjekt überhaupt nicht speichern.

Aber das ist, glaube ich, eher so ein seltener Fall.

Normalerweise kann man das ja schon speichern.

Ja.

Wiederverwenden.

Ja.

Also, wir können uns auch gerne nochmal an dem,

an dem Ablauf ein bisschen weiter entlanghangeln.

Ja, ja.

Weil wir jetzt schon vorgegriffen haben,

also wenn wir die, das, 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, was man als Feature Engineering kennt.

Wir bauen also Features, die ja einfach sinnvolle Inhalte haben,

mit denen das Modell dann später gut umgehen kann.

Macht ihr das dann immer live in Pandas

oder schreibt ihr das auch in eine Datenbank rein?

Es kommt drauf an.

Aber meistens haben wir dann schon eigentlich ein separates Modul,

das die Features berechnet und irgendwo hinschreibt, weil das meistens dann,

ähm, ja, das ist dann so.

Einfach schöner ist es, das Modell zu signalisieren,

weil es sonst ein bisschen zu viel wird.

Was ist da eigentlich die Datenbank für?

Ähm, ich überlege gerade.

Wir waren früher viel auf meinem IADB 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 kann man sich was von die...

Das ist diese Geschichte, diese...

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

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

Das weiß ich nicht.

Ich weiß es nicht genau.

Ja, aber da habe ich auch schon ein gutes Roll 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 richtig 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 nichts gehen.

Ja.

Und wenn wir dann so viele Charts 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 Grund auf 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 Intrigue Boost einfach sehr, sehr gut.

Das ist ein bombasites Modell.

Aber es kommen gerade Sachen, zum Beispiel gibt es da TabPFN.

Ja, das klingt auch sehr interessant.

Es ist ein Transformer-Modell und das ist irgendwie total verrückt,

weil dieses Modell hat, also ich finde es immer noch total beeindruckend,

es ist irgendwie so Magic.

Also das hat gelernt, wie Datensätze, wie die Zusammenhänge in Datensätzen,

wie die Zusammenhänge in Datensätzen, wie die Daten sind,

wie die Daten sind, wie die Daten sind, wie die Daten sind, wie die Daten sind,

wie die Daten sind, wie die Daten sind, wie die Daten sind,

wie die Daten sind, wie die Daten sind,

da selbst hat der einen interessiert

und dann kann man

total gute Prognosen machen, auch wenn

der Datensatz nicht besonders groß ist

und das Verrückte ist, diese Datensätze,

anhand derer das gelernt hat, das sind

künstliche Daten, also es sind nicht mal

echte Daten, weil es gibt ja gar nicht so

viele im Netz verfügbar. Es ist ja anders, als wenn man

ein Sprachmodell trainieren will und das ganze Internet

besteht aus Sprache, aber es funktioniert

trotzdem richtig beeindruckend. Also ich glaube,

das ist so etwas, was sich gerade so anfühlt

wie, okay, da passiert jetzt wirklich mal

wieder was Neues im Datenbereich

Prognose. Ja, ja, auch diese ganzen

Pre-Trends, das gibt es ja im LLM-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, das hat

mich auch total gewundert.

Ihr müsst ja vielleicht noch ein bisschen kurz

erklären, bitte, so die Grundlage. Ich glaube, das war

ein bisschen komplex vielleicht für

einen Einstieg. Also

TapDFN hast du gesagt?

Und XGBoost, also Creative...

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 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 auch weniger

genau und XGBoost ist da halt

deutlich komplexer. Und XGBoost macht das dann

quasi über die

Backpropagation-Mechanismen?

Nee, das ist eine Art Decision Tree.

Also es ist eine grundsätzlich

andere Art von Modell.

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,

ist es ja gut und dann wird es am Ende auch

ziemlich gut.

Und das heißt, über Jahre

eigentlich für

jedes typische

Predictive-Projekt

oder für jede Predictive-Fragestellung

war XGBoost, es war schon fast langweilig.

Ja, es gibt dann noch so ein paar Varianten,

es gibt zum Beispiel Catboost, das ist so ähnlich,

hat aber halt schon irgendwie ganz schlaue

Mechanismen implementiert, um mit

kategorialen Variablen umzugehen und

manchmal ist das eine oder das andere 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 daraus geworden ist.

Oder LightGBM, genau. Ich weiß gar nicht, was daraus geworden ist.

Ich habe nur...

Benutzen wir auch gerade in dem Projekt.

Ah ja, okay.

Und ja, witzigerweise,

wir haben auch schon, ich glaube,

vor einem Jahr oder so haben wir gesagt, kann man eigentlich

auch LLMs zur Prognose benutzen? Ich möchte ja

dem LLM ja sagen, guck mal hier, das und das

und das sind meine Daten, was denkst du, wie

teuer ist dieser Gebrauchtwagen?

Und wir haben da einen Datensatz bekommen

von einem

Unternehmen, die

genau solche Daten eben aus dem Internet

crawlen und die

das, sagen wir natürlich,

so ein bisschen Informationen mitgeben

und das hat aber schon funktioniert.

Wir haben da,

da weiß ich jetzt die Details natürlich

nicht alle auswendig, aber wir haben sowohl mit

GPT-Modellen

als auch mit Open-Source-Modellen

das ausprobiert. Das macht schon Sinn,

die zu feintunen.

Und dann kann man aber leicht und 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 Antwort

nur in einer Zahl, in Euro oder irgendwie so was

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 ist

Internet-Kennung. Also Transformers meint man jetzt

tatsächlich, also die großen LLMs und nicht nur

Transformers, 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 kann ich jetzt entwiesen, dass es da irgendeine

andere Art gibt, dass Daten aus den

tabularischen 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,

ist das halt wie speziell für tabulare Daten

wieder gemacht ist, weil wir haben ja die LLMs eigentlich

so ein bisschen zweckentfremdlich, wie man die dann

da nach dieser Probe-Modell-Tab-Tab haben.

Was meinst 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 noch mal

ja gut, das

beschreibt es wahrscheinlich ab, das ist schon komplett

wir haben den dann noch mal, wir haben

einen Trainingsdatensatz, wir ganz viele

Gebrauchtwagen schon drin haben

mit dem Preis und den ganzen

Eigenschaften und dann

haben wir ihm ganz viele Texte

gegeben, zu jedem Auto ein Text, das Auto

so und so alt, sieht so und so aus,

ist die Marke und es kostet das

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

und das ist dann noch mal 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 so etwas wie

XGBoost, aber ja,

ich ist das Modell, dann noch mal kriegt man so eine

Spezialausbildung quasi für das Thema

Auto-Gebrauchtwagenpreise

und dann wird es noch mal besser, wenn man ihm dann

so eine Frage später stellt.

Ja, man trainiert es quasi noch mal 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, das kannst du natürlich,

du kannst es mit den OpenAI-Modellen

und so auch machen, über deren APIs, aber

wenn du das auf einem

quasi, wenn du das selber machen willst,

dann musst du ein Modell nehmen, wo du Gewichte hast.

Ja, genau.

Ich glaube, wir haben

da beides gemacht, also einmal über OpenAI,

da kann man einfach über die APIs sein, die es mit

Feintuning-Datensatz machen,

aber auch mit den

Open-Source-Modellen, wo wir da noch mal

Feintuning drangehängt haben, damit die eben

speziell auf der Preise

verwendet werden.

Ja.

Bei Tuning und Autos fällt mir jetzt erst auf,

dass es echt total gut passt.

Ja.

Okay, das ist halt der 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 XT-Boost oder teilweise auch mit

irgendwelchen ausgefeilten statistischen

Ansätzen oder

Kombinationen, je nachdem, was man

hat. Ja, das finde ich dann spannend. Wie viel kann denn jemand,

der richtig gute Statistik oder in klassischer Statistik

ist, rausholen im Vergleich zu diesem

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,

XT-Boost 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 lernt es noch

die kleinsten Wackler auf

den Trainingsdaten und auf neuen Daten

erzählt es dann nur Mist. Das heißt,

dann hat man Overfitting und das

muss man verhindern. Es gibt natürlich schon ein paar Sachen, die man

falsch machen könnte, aber

wenn man da alles nach State of

the Art macht, kommt man bei so einfachen

Aufgaben mit einem XT-Boost meistens

ziemlich weit, aber

ja, zum Beispiel

im Sportwettenbereich gibt es ja manchmal

wirklich komplizierte Sachen. Also wenn ich jetzt

vorher sein will, wie die

Tore sich verteilen,

dann kommt man da

dann schon nochmal weiter, wenn man wirklich darüber

nachdenkt, theoretisch, was ist denn das jetzt eigentlich

für eine Verteilung? Das sind

Anzahlen, also es ist eine Poisson-Verteilung,

aber die ist ja irgendwie bivariat, weil es sind

ja zwei Mannschaften

und zwei Teams, die Tore machen und

da weiß ich, dass meine

Kolleginnen und Kollegen sich schon

einige ziemlich verrückte Sachen ausgehört haben.

Und dann umgekehrt, manchmal ist es am Ende auch irgendwie doch nur

eine einfache Heuchelstück, die einen ziemlich

weit bringt.

Die Ernährung der Spiele am Morgen zuvor mit einfließen

lassen können und sowas. Das weiß ich nicht,

ich müsste mal fragen, ob wir so ein Feature

drin haben.

Ja, da gibt es auf jeden Fall spannende Sachen.

Ich würde mich halt tatsächlich interessieren,

was man aus Statistik irgendwie daraus lernen kann,

weil ich verstehe nicht genau, wie

jetzt in so einem Transformers-Modell die einzelnen

Gewichte bei den Neuronen zustande kommen.

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 es nicht.

Neuronale sind deutlich eher

Blackbox, aber das ist XGBoost auch.

Natürlich kriegst du bei beiden auch so ein bisschen raus,

was da der Grund ist, warum das

jetzt irgendwie so oder so

entschieden oder vorhergesagt hat.

Aber es ist schon eher so Blackbox-

Modelle.

Ja, man kann jetzt nachträglich dann...

Also das wäre jetzt vielleicht

für mich auch noch mal einer der Punkte, der für

dieses Data Cleasing spricht. Ja, also wenn ich jetzt

die Daten da einfach so reinkippe

oder am Anfang schon so

aufteile, dass ich jetzt 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.

Du beschreibst glaube ich Feature Engineering gerade, oder?

Ja, vielleicht.

Ja, ich habe es noch nicht mehr.

Ja. Also zum Beispiel,

viele Modelle sind ja auch dazu in der Lage,

Interaktionen zu erkennen, also beispielsweise

weißt du, ich

hätte mir gerade da ein gutes Beispiel

erinnert, vielleicht aus der Luftschallstoffprognose

ü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 Schallstoff weit weggepustet.

Das ist halt die Interaktion, also die Effekt,

mittags ist es schlechter, der ist nur da,

wenn die Windstärke gering ist. Und so

Interaktionen 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, es ist windstill.

Jetzt mit diesem sehr einfachen Beispiel.

Das ist dann glaube ich auch wieder so was, wo es

dann wirklich viel bringt, immer mal

wieder mit den Leuten zu reden,

die sich fachlich damit auskennen.

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...

Ja, du erst.

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ß

eine fixe Anzahl von Spalten.

Und dann muss man das irgendwie erstmal

den Text runterprojizieren mit

Singular Value Decomposition oder so,

auf, weiß ich nicht, ein paar hundert Dimensionen oder so.

Und das kann man in XGBoost reinpacken.

Sozusagen solche Sachen hat man halt auch immer.

Ja, das war auch tatsächlich

so ein Grund, weshalb wir das auch mal

ausprobieren wollten mit den LLMs zur Vorhersage.

Weil, wie du sagst, wenn wir einen Text haben

und wollen aber 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,

die Texte durchzugucken und das zu labeln,

dann ist das bestimmt nochmal ein bisschen genauer.

Das ist halt die Frage, ob es sich lohnt,

zu überlegen.

Ja, gut, aber

dadurch kann man schon viel rausholen, ja, durch diese Modellierung

dann und so, okay.

Dann sind wir in diesen Datenprozessen. Wie nennt man

diese Datenprozesse? ETIL?

Da gibt es ja verschiedene Art und Weisen.

Ach, du meinst jetzt

Extract Transform Loads?

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 das CRISP, ne?

Ach so, ja.

Also ich glaube, ja, also ETIL,

Extract Transform Load,

beschreibt ja einfach den Prozess,

dass man Daten irgendwo rauszieht,

dann irgendwas damit macht, also sie transformiert

und sie dann irgendwo lädt, obwohl man

immer 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 dem Code dann,

wenn man irgendwann überall Load stehen hat,

egal ob man Daten zieht oder Daten wegschiebt.

Und ja, das ist...

So hängt das im Prinzip zusammen,

aber oft benutzt man ja den Begriff

ETIL auch einfach für jeden

Prozess, der irgendwie Daten nimmt,

verarbeitet und so durch so eine Strecke schiebt.

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

Ja, genau. Also jeder Business-Prozess,

den man irgendwie halt automatisieren kann.

Aber ich glaube, es ist schon oft so,

dass man auch sagen würde,

nachher in einem fertigen Datenprodukt,

okay, hier ist der ETIL, jetzt kommt der ETIL

und dann kommt der Teil mit dem Modell.

Also oft nutzt man den Begriff eigentlich auch,

um das voneinander abzugrenzen.

Okay.

Also ich verstehe jetzt, 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 kriege das Modell zum Lernen.

Und danach mache ich auf diesen weggelegten Daten die Prognosen

und dann gucke ich, was tatsächlich die Werte waren

und vergleiche die mit den Prognosen von dem Modell.

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

Es kriegt halt nur die ganzen Features,

aber es kriegt nicht die Zielvariable.

Es muss dann seine Prognosen blind machen

und wir können dann gucken und sagen,

ja, wir kennen die Warenwerte, aber schon vergleichen das.

Jetzt gibt es dann verschiedene Kernwerte,

die man berechnen kann,

kommt es halt total auf die Fragestellung an.

Man könnte zum Beispiel eine mittlere prozentuale Abweichung berechnen.

Man kann den Bias berechnen,

liegen wir mittel drüber oder drunter.

Man kann eine erklärte Varianzanteil berechnen.

Man kann, je nachdem,

vielleicht wollen wir auch gar nicht mehrische Daten,

vorher sagen, es soll nur ein Ja oder Nein sein.

Dann könnte man gucken,

wie viele false positive, false negative und so weiter habe ich.

Das kommt 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 es, glaube ich, auch gar nicht so leicht zu sagen,

was ist denn jetzt ein guter Wert?

Für dich irgendwie 20, 50 oder 90 Prozent erklärte Varianz,

das kommt auch stark auf die Fragestellung an.

Wenn ich zum Beispiel individuelles Verhalten von Menschen erklären will,

dann,

kann ich das natürlich nicht so genau vorhersagen,

wie aggregierte Verkaufszahlen,

weil da einfach so viele andere Einflüsse sind.

Und nochmal zu diesem Split,

zu den Trainingsdaten und den Testdaten.

In den allermeisten Fällen haben unsere Daten ja eigentlich eine zeitliche Struktur.

Man kann jetzt natürlich die Testdaten zufällig rausziehen und zur Seite legen.

Aber am besten ist es, wenn man immer die zeitlich,

die nimmt, die zeitlich am Ende liegen,

weil manchmal ändern sich eben Zusammenhänge.

Und,

das eigentlich passiert ständig, dass sich Zusammenhänge ändern.

Und deswegen ist es halt sinnvoll, so ein Szenario zu bauen,

wo das Modell quasi auf der Vergangenheit lernt und dann auf Daten,

die danach passiert, sonst auch tatsächlich evaluiert wird.

Sonst kann es halt passieren, dass man sich da verschätzt und dann denkt,

das Modell wäre besser, als es tatsächlich ist.

Und nachher im Betrieb,

dann muss es ja tatsächlich Prognosen für die Zukunft machen.

Und dann ist die Enttäuschung dann irgendwie da,

wenn es dann doch schlechter funktioniert, als man dachte.

Aber man muss natürlich auch immer auffassen, dass man dann halt die neuen Zusammenhänge,

die wir dachten, Änderungen dann irgendwie trotzdem mit reinkriegt.

Weil wenn sich halt irgendwas...

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.

Genau.

Also man könnte ja vielleicht auch diese Zusammenhänge irgendwie als 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 ändert sich irgendwas an den Annahmen, dann müssen wir halt da nochmal

was auch anpassen.

Ja, also zumindest, ich glaube, so direkt geht es gar nicht so gut, weil das ist ja was, was das Modell findet.

Und wo die dann eher auch sagen, ah ja cool, ja, das passt so ungefähr zu dem, was wir erwartet haben.

Aber die können sich wirklich sagen, 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?

Das kann uns diese Naseverwaltung 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, sollte 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üssen wir mal neu trainieren.

Das kann nie auch damals fehlen.

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

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

Deswegen ist es auch manchmal gar nicht so nützlich.

Ganz viel Datenhistorie zu haben, weil vielleicht das vor allem jetzt, wo auch noch Corona war,

dass die Zusammenhänge und die Muster während Corona in irgendwelchen Verkaufszahlen oder menschlichem Verhalten,

die sind natürlich jetzt alles anders.

Das wäre mein nächster Punkt gewesen.

Also wenn ich jetzt Statistik nehme oder von Statistik irgendwo abhängige Modelle, um Prognosen zu machen für die Zukunft,

dann bin ich ja immer nur auf den, sag ich jetzt mal, den Normalfall trainiert oder den Alltag.

Und diese ganzen Schocksituationen, die kann ich ja immer ganz schlecht

abbilden, weil ich ja dafür auch keine Beispiele habe.

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

Man kann vergangene Schocks kann man halt noch mit reinnehmen und sagen Okay, hier war ein Strukturbruch.

Da hat sich jetzt irgendwie was geändert.

Das nehmen wir als Feature mit rein.

Geht manchmal, geht auch nicht immer.

Also ich glaube, wir haben tatsächlich

in der Luftfahrtschiffmodelprojekt haben wir, glaube ich, einfach die Zeiträume definiert.

Hier war hier war Lockdown, hier war kein Lockdown.

Damit das Modell zumindest weiß, ah,

deswegen war hier so viel weniger Luftverschmutzung.

Ja, okay, sonst hätte ich gedacht, das ist eine gute Sache.

Aber ich habe ich habe nochmal.

Ich würde mal kurz ganz kurz einen Schritt zurückgehen, weil ich habe eine Frage,

wenn ich mich noch jetzt schon interessieren würde, weil ich jetzt auch gar nicht so

wirklich Ahnung von diesem Tab-PFN oder so habe, weil in den anderen Bereichen haben

ja die also normalerweise neuronale Netze für solche tabularischen Daten.

Das hat nichts.

Es funktioniert auch, aber halt nicht so gut wie die anderen Arten von Modellen oft.

Und die Frage wäre ja,

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

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 Tab-FN auch so, dass ich da

jetzt quasi auch relativ rohe Daten irgendwie verwenden kann?

Oder muss ich das erst mal auch irgendwie in eine Struktur bringen?

So ähnlich wie bei XGBoost?

Du fragst eigentlich die falsche Frage.

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

Aber da würde ich tatsächlich auch auf unsere Podcast-Freunde mit dem Auto von Tab-PFN verweisen.

Muss ich mal anhören.

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

Ja.

Ja, vielleicht noch mal zu dem Modelltraining.

Wo trainiert ihr denn das und wie macht ihr das?

Meistens auf,

also oft auf ABS-Maschinen zum Beispiel.

Wir haben auch selbst ein paar fette Server, die sind jetzt im Rechenzentrum in Nürnberg.

Seit neuestem haben sie auch unter ihresgleichen.

Vorher haben sie so ein bisschen das Büro beheizt, damals die Winters.

Jetzt haben sie einen besseren Ort gefunden.

Also die benutzen wir auch manchmal.

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,

wir haben uns da was zugelegt vor einigen Monaten, sodass wir unsere eigenen GPU haben

und auch mal selbst das aussetzen konnten auf einer eigenen GPU.

Was natürlich auch ganz spannend ist.

Also habt ihr eine eigene Maschine 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.

Dabei dann doch zu klein.

Da haben wir das dann über ABS gemacht.

Okay.

Ja, schwierig. Das ist auch schwierig, gerade welche zu kaufen.

Aber und das ist sehr teuer.

Ja, das ist teuer.

Mieten ist auch sehr teuer.

Ja, das macht jetzt schon Sinn.

Wir kaufen die.

Ich glaube, die war dann irgendwie zwei Monate später wieder deutlich günstiger.

Okay.

Ja, ich glaube, wenn man die mietet irgendwie, dann kostet die irgendwie so 1000 Euro im Monat oder so was.

Naja, also die mit viel Hauptspeicher, wenn du zum Beispiel LLMs feintunen willst,

da zahlst du eher 1000 Euro am Tag.

Ja, das ist richtig teuer.

Ja, okay, kommt wahrscheinlich auch an, wie viel man braucht.

Ich glaube, es hat auch ein paar Leuten einfach Spaß gemacht,

das Ding halt auszuwählen und zu kaufen und dann wirklich selber sowas komplett aufzusetzen.

Ja, ja, ja, das macht auch Spaß.

Ist ja auch gut, wenn man das kann.

Komplett operated.

Ja, ich habe das auch gemacht.

Ja, ich mag das auch.

Brauch nur einen Grund.

Gib mir doch einen Grund dafür.

Also vielleicht wollt ihr ein unbezahltes Praktikum.

Wenn wir dann ganz viel große Hartz-X-Penny haben, können wir nur mal nach dem...

Richtig. Das könnten wir mal nutzen.

Aber ja.

Ja.

Noch vielleicht noch mal zu der Modellbewertung.

Ich habe ja schon gesagt, dass man natürlich Kennzahlen ausbrechen kann für die Modellgenauigkeit.

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

Aber dann macht es halt auch Sinn, diese Black-Bobs 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 auch welche signifikant sind.

Aber das geht dann bei XGBoost nicht mehr so leicht, sich irgendwelche Splits anzugucken, wie das Modell gefunden hat.

So, aber da gibt es ganz tolle Methoden, die nennen sich SHAP und die kann man dann danach auf die...

Also man braucht das Modell und auch nochmal einen Datensatz, mit dem man Prognosen macht.

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

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

Auch das ist jetzt schon mal ein erster Possibilitä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 haben wir auch gesehen, je windiger, desto weniger Schadstoff.

Aber irgendwo gibt es dann so eine Sättigung.

Dann sind die Schadstoffe irgendwie einfach so weggeweht, wie es nur geht.

Und das...

Ich glaube, es war sogar...

Ich glaube, das war das Interessante.

Irgendwann wird es halt wieder schlechter, weil dann der Staub aufgewirbelt wird.

Wenn es zu windig ist, dann...

Dann nimmt man 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.

Das wir denken, das liegt daran, dass dann irgendwann der Wind zu stark ist.

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

Ja, ist natürlich, wenn dann regnet, dann halt eben wieder ein bisschen.

Dann wird das eben weggespült.

Und dann die Temperatur wieder...

Genau, 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 von mir 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.

Das egal wie toll man sich die Daten vorher anguckt.

Manche Sachen, finde ich, sieht man einfach erst nach der Modellierung und muss dann

nochmal ein Stück zurückgehen, ist ja kein Problem.

Okay.

Das ist dieser jeweils 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.

Oh, irgendwas stimmt hier nicht.

Aber das kann natürlich auch sein, dass

in der Realität irgendwas nicht stimmt.

Das kommt erst später.

In dem Moment haben wir noch gar kein Alerting-System.

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 Paltest unterwegs.

So, wir liegen Paltest.

Wobei Tests mit Daten ja auch manchmal ganz witzig sind.

Weil

man, ja, nimmt man, baut man sich dann einen kleinen Testdatensatz, ist ja dann realistisch.

Macht man vielleicht sogar Tests gegen die echten Daten.

Die dürfen, 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, ja, ja.

Ja, es ist tatsächlich schon.

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.

Oh, na ja, gut.

Ja, es geht auch mal, aber schwer.

Ja, also in dem Moment wäre man ja eigentlich nur beim POC, beim Proof of

Concept und so ein richtiges Produkt oder MVP, 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.

Und oft machen wir aber auch nochmal schon 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.

Also mit was macht ihr die Web Apps?

Meistens mit Vue.js und historisch auch noch häufiger mit Arschweini.

Aber das

meinte ich.

Und da haben wir ja, da haben wir ein Projekt, das eigentlich ganz cool.

Da haben wir, da geht es gar nicht darum, irgendwelche Prognosen zur Verfügung zu

stellen, sondern da haben wir Shiny Apps gebaut, damit Leute Modellierungsalgorithmen

anwenden können, ohne dass sie selbst R-Code schreiben können müssen.

Weil das ist für ganz viele Forschende, die aber nicht gut selbst coden können.

Und dann wäre die Hürde natürlich total riesig.

Aber die brauchen eigentlich diese ziemlich komplexen Methoden.

Und deswegen haben wir da dann für ein

Forschungsinstitut einige Apps gebaut, wo die dann eben über eine Klick-Oberfläche

können sie ihre Daten hochladen und können

die Analyse fahren mit bestimmten Einstellungen und kriegen dann Ergebnisse und Visualisierung.

Das ist natürlich auch sehr praktisch.

Und schreiben damit ihre Doktorarbeiten.

Ja, aber zurück zu unseren Prognose-Ergebnissen.

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

Das ist tatsächlich auch etwas, das 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 eine kleine Web-Anwendung schreiben,

weil sonst die Hürde 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 vielleicht 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 am Flickrücken.

Ja, das finde ich schon.

Das kann man auch durch unterschätzen.

Das ist ja alles ehress-sau-hässlich.

Ja, ja.

Und ja, üblicherweise, das hat man eben schon gesagt, ein Modell muss man natürlich regelmäßig neu trainieren,

weil sich Zusammenhänge in der Regel in allen Bereichen immer mal wieder ändern.

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

Ab und zu sollte man sich das Modell sogar auch nochmal ganz genau anschauen.

Zum Beispiel nochmal diese ganzen Chef-Sachen berechnen und gucken, ist das eigentlich noch plausibel?

Das kann man vielleicht einmal im Jahr machen.

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

Also in vielen Projekten ist es, dass das einmal am Tag passiert.

Aber manchmal ist da noch wirklich ein Echtzeit, dass dann der Ehranfall reinkommt.

Und dann wird die Prognose für diesen einen ganz konkreten Fall erstellt.

Und oft kann man die auch noch vorbereiten.

Weil man die Daten vielleicht dann einfach noch nicht hat.

Sondern kommen dann rein die Daten und dann braucht man eine Prognose.

Zum Beispiel kommt ein neuer Kauf rein oder eine Anfrage.

Und man muss in dem Moment entscheiden, ist das irgendwie verdächtig?

Könnte das Betrug sein oder ist alles okay?

Und man sollte sich 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.

Ja, kann man 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 dann denkst du, hey, wir haben uns doch gerade die Ergebnisse gezeigt.

Die sind doch da.

Ja, klar.

Das ist natürlich auch schwer nachvollziehbar von außen.

Deswegen ist es einfach wichtig, das richtig zu kommunizieren.

Ja, ich wollte gerade sagen, schwer zu kommunizieren.

Das ist, finde ich, auch ein Hauptproblem.

Gerade bei so Kunden und Technologie.

Das sollte man natürlich auch vorher sagen.

Und was ich dann danach meine, kann man ja verstehen,

dass jemand sich dann ein bisschen an der Nase rumgeführt fühlt.

Oder einfach schlicht.

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 unsere 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 Modell.

Modelldrift oder Datadrift.

Das heißt, dass die Daten nach und nach in eine andere Richtung driften und sich verändern.

Oder das Modell nach und nach immer so ein bisschen schlechter wird.

Aber irgendwann, wenn es das lange genug gemacht hat,

dann ist es halt irgendwann nicht mehr gut genug.

Und dann möchte man das ja auch mitbekommen.

Und zum Beispiel bei jedem monatlichen Modellneutraining

will man auch mal 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,

ein Stück 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 da 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 dann eigene Monitoring-Tools

oder nutzt ihr ja auch eins von den Sachen, die es da so gibt?

Ja, also Relash benutzen wir in dem einen Projekt ganz gerne.

Und sonst, ja, wie das, was ich gerade dann anbiete,

die 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.

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.

Ist ja auch nochmal so ein spannendes Thema,

weg von US-Diensten und so.

Ja, wahrscheinlich, genau.

Das ist natürlich...

Wenn ich mir die Russen nehme.

Genau.

Man soll ja streuen.

Ja, ja.

Oder weit streuen.

Ja, das ist eigentlich...

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, muss halt irgendwo anders noch Dinge haben.

Ja, braucht irgendwie so...

Ja, aber ja, klar.

Es wird dann auch teurer.

Ja, das Monitoring ist jetzt so ruhig.

Was passiert denn da jetzt?

Genau.

Ja.

Endlich sind alle Bugs weg.

Ja.

Eigentlich ist alles gut.

Hat jemand den Nameserver mit in die Tasche gesteckt

und schon...

Ja.

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 Kurzvortrag ist der Rathops, oder?

Ja.

Ja, genau.

Und ja, es ist eher im Prinzip DevOps,

aber Anpassung auf den Datencase,

also auf die Arbeit mit Daten.

Das heißt, es kommen so ein paar Sachen dazu,

wie zum Beispiel,

dass man nicht nur Code versionieren muss,

sondern auch Modelle oder vielleicht Experimente versionieren.

Ja.

Und ja, es gibt halt nicht nur Codeänderungen,

die dazu führen, dass die Ergebnisse anders sind,

sondern auch jeder neue Datenpunkt

kann...

Ja.

...die Ergebnisse verändern.

Das heißt, da kommt dann nochmal so eine zusätzliche Komplexitätsebene mit rein.

Ja.

Ja, das ist auch eine ganz wichtige Geschichte.

Also ich finde das immer dann schwierig,

wenn das halt so verteilte Systeme sind,

die gleichzeitig irgendwie rechnen

und dann die Sachen wieder zusammenführen müssen.

Da steige ich auch nicht so genau durch,

wie man das ordentlich machen will.

Aber wenn das so distributed ist,

was halt beim Machine Learning auch mal passieren kann, ja?

Ja, aber also würde ich jetzt...

Also aus meiner Erfahrung...

Also...

Bei mir ist das eigentlich...

Also das letzte Mal,

dass ich den Fall hatte,

dass wir irgendwie sowas verteilen mussten,

dann war das wegen,

weil die Maschinen 32 Bit waren

und nicht mehr als 4 Gigabyte,

wie man auch eine Maschine kriegte.

Ja.

Und dann brauchte man mehrere Maschinen.

Aber danach ist das eigentlich,

ehrlich gesagt,

also mir nicht mehr passiert,

weil...

Du hast einfach viel zu kleine Daten.

Ich habe keine Daten,

die sind zu klein.

Das kann schon sein, ja.

Aber ich meine,

man kriegt heute so große Maschinen.

Also...

Ja.

Du, die Preise haben wir gerade unterhalten.

Ja.

Ja, ja.

Aber wenn man CPU...

CPU...

Die meisten sagen,

warum immer 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, also wir haben jetzt gerade schon mal optimiert.

Wie ist das denn mit Performance zum Beispiel?

Ich glaube,

das ist noch was gewesen,

wo wir sprechen würden.

Ja, also da könnte natürlich auch

eine ganz separate Folge sein.

Aber grundsätzlich ist das auch

natürlich ein spannendes Thema.

Also was mir da immer mal wieder auffällt,

das ist,

dass 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...

Ja, gibt es noch...

Ja.

Ja, gibt es noch 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 10 Millionen von Zeilen

meistens auch nur so viel zusätzlicher,

wie Informationen liefern.

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

Ich kann ja immer mal noch checken,

ob es wirklich nicht mehr 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...

Das Paket Datatable,

aber ich glaube,

das ist einfach gar nicht mehr so interessant,

jetzt wo es Polars gibt.

Und dann, ja, bei Datenbanken

ist es auch manchmal ganz interessant,

weil die sind oft eher darauf optimiert,

dass man eine kleine Menge von Daten

abruft oder hinschreibt.

Und wenn man dann auf einmal mehrere Millionen Zeilen hat,

dann werden die so Stück für Stück

abgerufen und hingeschrieben,

wie man den welchen Treiber benutzt.

Und da gibt es dann auch Hacks,

wie zum Beispiel, dass man es erst

in ein Parquet-File oder ein CSV schreibt

und dann das im Batch hochlegt.

Das wird jetzt schon ziemlich...

Ja, mit dem Parquet-File

wollten wir noch ein paar bisschen drüber reden,

wie man das machen kann.

Ja, aber genau,

Performance sind so ein ganz generelles Ding,

was ich häufig sehe, also gerade auch

im Zusammenhang mit 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,

was man verteilt.

Also 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,

dass Leute sagen,

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 Netzwerk ist halt noch viel langsamer

als 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

erfassen, wenn die dann sozusagen richtig

also sich

alle Daten immer nur einmal anguckt,

dann kann es sein, dass es super schnell ist.

Während wenn man halt zufällig

auf einem großen Paketfeil

beispielsweise dann irgendwie immer ein Stückchen

hier liest, ein Stückchen da liest,

die ganze Zeit random

irgendwie zwei Gigabyte I.O. macht,

dann ist das alles total langsam

und sieht so aus, als ob es nicht schneller gehen würde.

Und tatsächlich

ist es aber

eine ganz einfache Optimierung,

die dazu führt, dass es halt

schnell genug ist. Also ich würde mal

sagen, wenn man so ein MacBook nimmt

und das richtig benutzt, ist es sehr schwer,

das mit einem Cluster zu schlagen. Wirklich, sehr schwer.

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 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, also zum Beispiel verteilte Datenbanken

oder sowas, ja.

Ja, genau.

Also, aber genau,

also oft ist es dann halt

so, wenn man dann halt irgendwie

irgendwas benutzt, was halt SQL spricht,

aber hintendran total verteilt ist,

dass das dann halt sehr langsam ist

und Leute nicht wissen, warum das langsam ist

und sich dann irgendwie daran gewöhnen und dann halt,

wenn sie ihre Jobs losschicken, halt dann

Mittagessen gehen oder so, aber

und wenn sie sich vorher die Daten irgendwie

halt geholt hätten und hätten das auf dem

Laptop in Pandas gemacht, wäre es viel schneller gewesen.

Naja, solche Sachen.

Aber IBIS,

ja, es ist gerade...

Benutzt ihr das?

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

Okay.

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.

Das ist so witzig, dass du es sagst.

Ich glaube, letzte Woche habe ich

gerade was parallelisiert und dadurch

sehr, sehr, sehr, sehr viel schneller gemacht.

Ja gut, das geht schon auch.

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...

Also eigentlich ist es trivial,

dass man erstmal profilen muss und gucken muss,

was langsam ist.

Wenn man es mal gesagt hat, klingt es ja trivial.

Aber ich glaube, wenn man es zum ersten Mal macht...

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,

kriege ich dann tatsächlich,

wird es schneller oder nicht?

Wenn es nicht schneller wird, okay, gibt es vielleicht

irgendeine andere Komponente im System,

die halt dicht ist.

Und dass es halt

da Unterschiede gibt.

Was halt nicht alles CPU ist.

Oft habe ich das Gefühl,

keine weit verbreitete Erkenntnis.

Aber ja, genau, das ist ganz wichtig,

dass man sich einfach

so ein Gesamtsystem mal anguckt.

Beim Modelltraining ist es dann tatsächlich

schon oft sinnvoll zu parallelisieren,

wenn das lang dauert.

Und das ist aber dann auch

in den meisten Paketen schon so eingebaut,

dass man dann nur irgendwie die Anzahl der Karte

übergeben muss, die dieses nutzen soll.

Und dann läuft das einfach.

Das ist ganz praktisch.

Genau, aber ich weiß jetzt nicht,

ich habe das auch schon lange nicht mehr gemacht,

aber zu der Zeit, wo ich solche Sachen gemacht habe,

war das halt schwer, das auf mehrere Rechner zu verteilen.

Also auf einem Rechner, ja, genau.

Aber auf mehrere Maschinen,

ja.

Die Frage ist, wie sehr man das auch

manuell machen muss, weil man ja meistens dann

sich seinen Data-Bridge oder so

hochfährt und muss sich darüber gar keine Gedanken

machen eigentlich.

Also zumindest als Data-Scientist ist es

nicht das, was man irgendwie,

was erwartet wird, dass man da verschiedene

Rechner zusammen schließt.

Ja, ja.

Und dann ist es natürlich manchmal irgendwie schon so,

dass man doch wieder auf einer

programmierten Sprache 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 sinnvolle

If-Statements irgendwie so ein bisschen verschiebt,

weil man auf einmal merkt, oh Moment,

oder in einem Loop irgendwas rauszieht, was eigentlich nur einmal

passieren muss. Das sind ja so Sachen, die dann

doch schnell passieren,

wenn man den Code irgendwann so beschrieben und ein paar

was verändert hat, dann ist da vielleicht irgendwas,

was man, also so eine Low-Hand-Input,

was man schon leicht optimieren kann.

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

Ja, wobei, ich meine,

das ist halt immer die Frage, wenn es halt schnell sein

soll, dann nimmt man am besten was, was nicht halt

in Python-Sinn hat, was halt langsam

sind, halt Funktionsaufrufe, Schleifen,

das ist halt extrem langsam,

weil wenn man die Schleifen halt in NumPy

nicht als Schleife, sondern irgendwie

vektorisiert auf den Daten macht, dann ist es halt

schnell. Und ob man das jetzt von Python aus

aufruft oder nicht.

Das ist dann auch dieses Stichwort, dass jemand, der das durch Weiß

eben über den Data-Frame drüberloopt,

einfach über das Beispiel.

Ja, aber deswegen ja genau, einfach dann

eine Maske drauf und dann machst du es halt

drunter, NumPy, ja.

Ja.

Ja, also warum ich Ibis eben sagte,

von Wes McKinney,

dem Pandas-Menschen, der

Ja, der hat ja eine ganze Menge, der hat auch,

der ist auch hinter dem Arrow,

das ist halt so seit einiger Zeit sein Hauptprojekt.

Ja, vielleicht nochmal, was macht Arrow?

Wenn wir schon dabei sind.

Achso, ja, das ist eigentlich im Grunde so,

die Grundidee dabei ist halt,

dass man vielleicht aus unterschiedlichen,

also das ist halt das Problem bei NumPy

oder Pandas-Geschichten,

also man hat

das dann halt in Python, aber wenn man jetzt

eine Programmiersprache hat und darauf zugreifen will,

dann geht das halt nicht.

Und die Idee bei Arrow ist halt,

dass man das halt, dass man eine gemeinsame

Daten-Hauptspeicher-Laden-Infrastruktur hat

und dann halt

Paketfiles quasi, oder was auch immer,

man lässt halt einen Hauptspeicher und kann dann halt

von unterschiedlichen