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 bis jetzt haben.

Und mit Python macht man ja recht viel Data Science.

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

Ja, gerne. Also praktischerweise bin ich Data Scientist.

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

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

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

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

Man muss auch sagen, dass man in der Psychologie schon auch Fehler haben, Analyse und Statistik macht.

Und da hat es mir noch nicht gereicht.

Deswegen habe ich dann noch einen Statistik-Master 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 erinnert sich die Begriffe ein bisschen und ist natürlich

über die Zeit auch total viel dazugekommen,

Machine Learning, was ja

vor einigen Jahren eben noch nicht so

da war. Vor einigen Jahren haben wir noch

ganz viel mit R gemacht, am Anfang,

inzwischen ist eigentlich fast alles

in Python, bis auch so ein paar einzelne

Projekte, vor allem im Forschungsbereich,

da sind die Leute ein bisschen mehr mit R unterwegs.

Und ja, ich kann gerne

auch ganz kurz was über mein Unternehmen sagen,

wir sind eine Data Science Beratung,

haben also sehr viele wechselnde Projekte,

sind 17 Leute,

in Berlin. Das heißt,

zum Hörertreffen wird es dann wahrscheinlich auch

nichts für mich, weil es ein bisschen zu weit ist,

um mal kurz vorbeizukommen.

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

Das war wieder hervorragend.

Ja, sollte man sich einfach

ein paar gute Podcasts vorher mitnehmen.

Wir haben ja noch ein paar.

Vielleicht habt ihr noch nicht alle gehört.

Ja, da kann man

dann schon noch ein bisschen länger Bahn fahren.

Ja, und

aktuell bin ich

witzigerweise, also ich habe

erst viel Data Science gemacht, bin dann immer mehr

auch in die Projektleitung gegangen und da

passt es dann ja auch wieder mit der Psychologie

und jetzt bin ich aber witzigerweise

so ein bisschen back to the roots, bin im

Kundenprojekt drin, so Body Leasing mäßig

dort mit im Team und

bin dann klassisch als Data Scientist im Team

drin und das macht mir auch ganz großen Spaß.

Wir haben teilweise länger

laufende Projekte, aber auch manchmal Einzelprojekte,

die nur ein paar Monate sind und das ist natürlich auch total spannend,

weil man dann sehr viel Abwechslung

hat und in verschiedene Themen

reinkommt und

Und wir haben auch einen Podcast, das ist der Grund, warum ich jetzt hier sitze und ihr mich kennt.

Ein Unternehmenspodcast, in dem ich manchmal, aber auch noch immer zuhören bin,

wo wir ganz viele Themen rund um Data Science besprechen, den Data Science Deep Dive.

Genau, das war sehr spannend.

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

Ja, gut.

Also, was ist denn eigentlich Data Science?

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

Das ist jetzt auch irgendwie ziemlich allgemein, aber es geht darum, dass man Dinge versteht,

dass man auch Dinge vorher sagt und dass man teilweise sogar Entscheidungen dann trifft,

entweder noch manuell oder sogar automatisiert auf Basis von Daten.

Oder anders gesagt, man will halt aus großen und oft komplexen Datensätzen Muster erkennen,

die man jetzt mit bloßem Auge überhaupt nicht erkennen könnte, nur erkennt, wenn man eine Analyse macht.

Also tatsächlich Statistik im weiteren Sinne, wie man das halt dann in der Psychologie oder in der Geometrie oder so.

Auf jeden Fall, ja, ein Teil ist ja auch so, manche sagen, Statistik oder Machine Learning, 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 dem Bereich, in dem ich gerade was mache, zum Beispiel Umweltdaten oder Verkaufsdaten, Online-Shopping, was auch immer.

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

Also 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 noch in dem Fachbereich so lange unterwegs bin, dass ich mich da wahnsinnig gut auskenne.

Ist ja doch ziemlich viel, das schafft man vielleicht nach ein paar Jahren, aber deswegen sind wir auch meistens in Teams unterwegs oder wir als Beratung.

Wir sind natürlich daran gewöhnt, dass wir uns schnell in neue Themen reinfinden, trotzdem brauchen wir in einem neuen Projekt natürlich ganz viel Kommunikation mit unseren KundInnen, die uns auch ihre Fachexpertise dann mitgeben, wenn wir dann vor allem die methodischen Kenntnisse und das Coding mitbringen.

Das finde ich auch immer am schwierigsten mit Kunden, also die Domain-Knowledge dann zu haben oder jemanden zu haben, mit dem man darüber reden kann.

Gemeinsame Sprache zu finden.

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

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

Unterschiedlich.

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

Ja, sehr, sehr unterschiedlich.

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

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

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

Also wir machen nicht nur die reine Data Science, sondern auch alles, was im DevOps-Bereich anfällt. Ich bin aber mehr im Data Science-Bereich unterwegs. Und wir haben eben ja auch zunehmend das Thema Body Leasing. Das war früher irgendwie kaum, weil früher hatten viele Unternehmen auch selbst keine Data Science-Abteilung.

Und da gab es eine Zeit, da waren die halt alle irgendwie ganz verzweifelt und waren dann total froh, dass es jemand für sie macht. Und inzwischen ist es eher so, dass die Unternehmen, die groß sind und die überhaupt von der Kultur her in Richtung datenbasiertes Unternehmen gehen, die haben jetzt eine Data Science Abteilung, aber die haben dann halt hier und da mal Lücken und finden niemanden und nehmen uns dann dann dazu.

Wenn du jetzt Methoden angesprochen hast, was würdest du denn sagen, wie ist das denn in der Praxis? Habt ihr da viel mit sophisticated Methoden noch zu tun, die ihr jetzt aus der Uni oder so noch kennt? Oder ist das meistens dann schon einfaches Zeugs, weil einfach die Datenprobleme andere sind, als jetzt gute Methoden auszusuchen?

Es ist tatsächlich oft ziemlich anspruchsvoll. Ich glaube, das sind aber auch so die Projekte, die wir uns rauspicken oder für die wir dann auch weiter empfohlen werden. Wir haben zum Beispiel was im Sportwettenbereich und da kann man sich ja vorstellen, wenn man mal überlegt, wie sag ich eigentlich vorher, wie viele Tore von diesen beiden Mannschaften in diesem Spiel fallen und wie viel in der ersten und zweiten Halbzeit und so.

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

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

Wir sind aber auch tatsächlich darauf spezialisiert.

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

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

Ja, wie kommt man denn eigentlich zur Data Science? Du hast gesagt, du hast Psychologie studiert und dann fandst du Statistik spannend. Ich habe vorher auch Wirtschaftslehre studiert und da fand ich auch Statistik eigentlich spannend. Es hat bei mir noch ein bisschen Umweg gebraucht, aber ich glaube auch da hätte man direkt den Weg Richtung Data Science finden können.

Ja, auf jeden Fall. Also das ist auch so ein typischer Hintergrund. Ich habe ja in dem Statistikmaß, da waren viele, die vorher Mathe gemacht haben, aber auch viele mit ganz anderen Hintergründen, viel Wirtschaftswissenschaften. Ich habe auch KollegInnen mit Soziologie-Hintergrund oder Physik. Ich glaube, das ist sogar so ein bisschen ein Klassiker, dass die Physiker sich irgendwie dann in die Statistik- und Machine Learning-Welt verirren.

Und wir haben noch gar nicht so lang, haben wir auch jemanden mit Informatik-Hintergrund. Das klingt irgendwie witzig, aber tatsächlich habe ich vorher nur Leute, also der ist jetzt schon, ich glaube schon drei Jahre bei uns, aber ja, vorher hatten wir nur Leute mit einem anderen Hintergrund.

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

Ja, aber der BWL ist ja auch nicht VWL zum Beispiel.

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

Ja, also Ökonometrie kann man schon tief reingehen, glaube ich da. Es ist halt die Frage, wie gut man dann in das Programmieren reinkommt und in das, was man da an Methoden noch so mitbringt.

Ja, aber das ist auf jeden Fall eine interessante Geschichte. Das habe ich auf jeden Fall, 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, ganz oft

aus der Ecke eher.

Und die eher so, ja,

Analysten

Dinge tun, oft viel

SQL schreiben und so.

Und das ist irgendwie ein bisschen anders

als bei den Softwareentwicklern.

Und die haben auch meistens oft so ein bisschen so,

ja, Produkte entwickeln oder so,

ist jetzt eigentlich nicht so unser Ding.

Genau, und das ist irgendwie eine etwas andere Welt.

Also da gibt es oft eine Trennung

zwischen Softwareentwicklung und eben in diesem ganzen...

Und da wolltest du ja auch noch mal was zu sagen,

wie du das so findest,

mit so Softwareentwicklern zusammenzuarbeiten.

Aber vielleicht noch erst dazu,

ich glaube, wir sind da irgendwie so dazwischen,

weil wir eben ja schon Datenprodukte bauen wollen.

Also es gibt auch mal ein POC oder irgendwie so eine einzelne Analyse,

wo wir dann sagen, so und das sind die Ergebnisse

und hier sind die Zusammenhänge, aber normalerweise

sind das dann schon, also

schreiben wir auch Software,

aber wir schreiben Software, die was mit Daten macht.

Also dann

sind zwei Sachen zusammen

und BI-Abteilungen

sind, glaube ich, auch noch mal mehr,

ja, die sind halt besonders gut darin,

dann auch ganz viel visuell

zu analysieren und fokussieren

sich sehr stark darauf.

Und ich glaube, die sind auch noch mal so ein bisschen,

vielleicht noch ein bisschen weniger nerdig,

hätte ich jetzt so gedacht.

so Mitte.

Das klingt, als wäre es kein Kompliment.

Ich weiß nicht, ich dachte eben, ne.

Das ist das, ohne Wertung zu sagen.

Oh, ja.

Ja, aber, was du eben

gefragt hattest, so,

das ist auch jetzt ganz spannend, ich bin jetzt im

Team, wo eigentlich relativ klar

zugeordnet ist, wer ist Data Scientist und wer

ist Software Engineer

und natürlich arbeiten wir alle an dem

Code, aber

es gibt

irgendwie so ein paar Klischees oder so Dinge,

die man vielleicht beobachtet, wenn

jemand, der vor allem einen

Softwareentwicklungshintergrund hat, jetzt zum ersten

Mal versucht, Daten zu analysieren

und Data Science zu machen.

Wir haben auch mal ein Projekt übernommen, wo

wir entsprechenden Code

dann, tatsächlich sollte man ja refactoren

und wir haben auch viel refactored, aber da haben wir

einen Teil wirklich neu geschrieben.

Und

das, also

am Coding-Stil hat man schon gesehen, dass der einfach

gar nicht wusste, dass man mit Datensätzen

Sachen machen kann. Der hat halt immer ganz

viel gedubt über Zeilen und Spalten

und so, weil er halt einfach diese ganzen

Sachen nicht kannte, die man mit Datensätzen

machen kann, vor allem mit Pandas.

Und was sonst auch, wenn man zusammenarbeitet

halt oft passiert, ist,

dass jemand, der nicht viel mit Daten gearbeitet

hat, die Ergebnisse halt so nimmt, wie sie

sind und da irgendwie ganz unkritisch ist

und gar nicht sieht, wenn

irgendwelche Zahlen ganz komisch aussehen.

Und manchmal ist ja vielleicht

der Code gar nicht falsch, aber

irgendwo ein Denkfehler drin, also der Code

macht, was er soll, nur das, was er soll, ist halt vielleicht

gar nicht so korrekt oder man hat

ein Missverständnis zu den Daten, man hat

irgendeine Annahme, aber in Wirklichkeit

ist es ein bisschen anders

und das ist was, was

dann, glaube ich, schwer fällt, also ich glaube,

das fällt einem als Data Scientist auch schon

manchmal schwer, so richtig dieses

Business Understanding aufzubauen,

aber ja, also

wenn man so reine Softwareentwicklung macht, ist es, glaube ich,

nochmal schwieriger, in den Daten drin zu sein

und die zu interpretieren und zu sagen, Moment mal,

also die Kurve sieht auch echt komisch aus.

Aber also eigentlich mag ich es

total gerne, wenn das Team gemischt ist,

weil

auch nicht alle Data Scientists so richtig

auf guten Code achten. Also es ist

uns sehr wichtig und wenn jemand

halt noch nicht so gut programmieren kann

und aus dem Stream kommt und bald einsteigt, dann ist

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

Aber ich glaube, das ist auch nicht überall so

verbreitet, weil manche haben dann eher einen Schwerpunkt auf

so Datenanalysen, sind viel Notebooks unterwegs

und wenn sie dann fertig sind, dann wird das Notebook

in irgendeinen Job eingebunden und das ist

dann die Automatisierung und das

kann manchmal funktionieren, aber oft ist

es auch ziemlich wackelig.

Ja,

interessant. Also da ist auf jeden Fall

oft so ein bisschen

ein Graben zwischen den

Welten. Also wenn ich

das immer sehe, was so Data Scientists schreiben,

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

Es gibt natürlich Unterschiede,

aber das ist immer so im Vergleich eher

anders

als ich das machen würde wahrscheinlich.

Also man schreibt als Data Science oft so die ganzen Prozesse

untereinander und muss erst mal lernen,

die Methoden zu definieren und so, ja.

Und warum soll man denn, also wenn man

das nur einmal macht, warum soll man denn eine Funktion schreiben?

Und man kann es ja 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.

Ich finde das immer einfach, wenn Leute schon promoviert

haben und das ist, die haben

total krasse Sachen gemacht, aber können dann halt

auch keinen guten Code schreiben, weil es für die

Doktorarbeit eben ganz andere Anforderungen hat.

Ja, da ist auch oft, also

gerade Physiker, die sind

da ja oft eher so verdorben, die haben dann irgendwie

Vortragen geschrieben oder sowas.

Oder C++, ist 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, man lernt

das ja auch nirgendwo, außer wenn man jetzt irgendwie

quasi bei einer Firma anfängt, die das halt

auch irgendwie täglich macht oder so. Bei den meisten

Firmen gibt es ja da gar keine Kultur und

ja, also es ist irgendwie

ja, es ist irgendwie, also dieses

Handwerkszeug ist ein Problem oft, das denke

ich auch. Was nervt dich denn an Leuten, die

Softwareentwicklung gemacht haben und jetzt Data Scientist

sind? Ja, das ist auch interessant.

Also ja, also die Sachen, die ich gerade

genannt habe, also es ist oft so,

die Ergebnisse so unkritisch beurteilt werden,

dass man eigentlich nur guckt, ob der Code richtig

läuft und das

macht, was man implementieren wollte.

Und dass eben, ja, man dann nicht unbedingt erkennt, dass die Ergebnisse eigentlich unplausibel sind, zum Beispiel, dass das Modell viel zu gut ist und da muss irgendwo was falsch sein.

Die Kirchturmspitze ist 245 Meter im Minus.

Bitte?

Du könntest erst mal die Kirchturmspitze ausrechnen, dass die Höhe dann 245 im Minus ist. Und wenn man das dann einfach so übernimmt und daran glaubt.

Ja, genau. Das ist natürlich ein gutes Beispiel. Und manchmal habe ich auch den Eindruck, dass dann wiederum, wenn man 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 war das vielleicht auch einfach am Ziel vorbei.

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

Ja klar, das sollte ich auch machen.

Ja, aber grundsätzlich macht mir das eigentlich total Spaß, mit Mitarbeiterentwicklern zusammenzuarbeiten.

Du hast gesagt, er visualisiert 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 senden, das ist irgendwie datatowiss.com oder sowas. Die benutze ich immer, wenn ich nicht weiß.

Das sagen sie so gerne.

Aber man macht es sich die ganze Zeit.

Aber es ist an verschiedenen Stellen eigentlich total wichtig.

Also zuerst mal, wenn man die Daten reinbekommt,

dann sind wir jetzt eigentlich schon so mitten im typischen Ablauf.

Aber ich kann da, da wollen wir zwar noch drüber sprechen,

aber ich kann da gerne mal vorgreifen.

Also wenn die Daten reinkommen und man gucken will,

ob die sinnvoll sind, wenn man die Daten kennenlernen will,

Zusammenhänge prüfen und so,

dann ist natürlich Visualisierung einfach das Allerbeste.

Klar ist auch ganz nett, so Mittelwerte und Ausgleichsabmessungen

Minimum zu sich anzugucken.

Zum Beispiel, ob der kleinste Kirchturm auch wirklich

größer als 0 Meter ist. Aber es macht natürlich

auch total Sinn, sich da die Verteilung mal zu

plotten und Zusammenhänge. Und das sind auch die Sachen,

die wir dann oft mit unseren Kunden wiederum anschauen

und sagen, guck mal hier, die Verteilung, macht die Sinn?

Und merken dann vielleicht, dass

da irgendwas in den Daten unsauber ist, was

halt oft vorkommt, womit man dann aber

irgendwie umgehen muss. Und

natürlich auch dann später, wenn wir

zum Beispiel ein Modell gebaut haben und

die Ergebnisse untersuchen wollen, wie

sind unsere Prognosen verteilt, welche

Zusammenhänge hat das Modell gefunden, auch da

ist dann natürlich die Visualisierung total

wichtig und sinnvoll

oder das einfach,

man kann es einfach viel, viel, viel schneller erfassen,

als wenn man das irgendwie alles versucht

in Tabellen zu vermitteln.

Wie visualisiert ihr denn am liebsten?

Ja,

es ist irgendwie ganz witzig,

weil ich in

Python noch nie so richtig,

ja gut, so ein bisschen habe ich auch in Python,

wir haben früher sehr viel

als doch, da waren auch weniger

mit Dashboards und so weiter, da war es auch noch so, dass wir

so einen Datendump bekommen haben und haben damit dann was

gemacht und da waren wir noch in R unterwegs und haben

für ggplot2 benutzt

und

inzwischen sind wir dann meistens

in einem Dashboard-System

unterwegs, das halt beim Kunden

einfach genutzt wird, sodass wir dann

in dem Tool, was der

benutzt, das implementieren,

weil das jetzt in AWS oder Azure oder was

auch immer nutzen und wir machen dann da

das, was da in dem System gewünscht ist.

Wir haben auch

ein paar Dashboards mal gebaut in

ähm, wie heißt das denn jetzt noch?

Ich hab den Namen lange vergessen.

Not Lead Dash oder Detail.

ReDash, genau. ReDash ist ein Open Source

Tool. Das

benutzen wir dann auch ganz gerne. Da kann man

dann auch gerade praktischerweise noch Alarme dazu

definieren, um seine Daten zu überwachen.

Das nutzen wir auch sehr gerne.

Okay.

Und wie läuft denn so ein

Prozess bei euch ab? Ihr habt jetzt irgendwie

Daten, ich glaube, du wolltest auch nochmal drauf eingehen.

Ja, gerne. Und so einen Auftrag und dann?

Also klar, manchmal

steigen wir auch mittendrin ein, aber ich fange jetzt

trotzdem mal vorne an, oft sind wir auch vorne

dabei. Das ist jetzt vor allem aus meiner

Sicht als Beraterin, das fühlt sich natürlich ein bisschen

anders an, wenn man im Unternehmen als Data Science

die ganze Zeit ist, aber für mich als

Beraterin sind das so

ja eigentlich so sieben Schritte. Erstmal

das Problemverständnis, dann die

Daten einzusammeln

und zu verstehen, dann Datenaufbereitung,

dann kommt die Modellierung. Man merkt 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

was sagt. Das ist der Cross-Industry

Standard Process for Data Mining.

Data Mining klingt so ein bisschen angestaubt.

Aber man könnte es halt einfach Datenprojekte nennen.

Und ja, am Anfang ist es bei uns dann tatsächlich auch so, dass KundInnen zu uns kommen und schon was haben, was sie 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 dem Kunden sprechen,

um das Geschäftsmodell zu verstehen,

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

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

und brauchen die zum Beispiel vielleicht was in Echtzeit, dann ist es natürlich ganz anders,

als wenn das ausreicht, dass man jeden Morgen einmal aktuelle Werte berechnet.

Und wer sitzt da und wo benutzen die das genau?

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

Und all das muss man natürlich wissen, um auch rauszufinden, was die brauchen.

Und dann ist der nächste Schritt, sich zu überlegen, wie können wir das machen

und haben wir eigentlich auch die passenden Daten?

Und dann haben wir vielleicht die notwendigen Daten

und ein paar andere Sachen sind vielleicht nicht ganz so notwendig,

man kann trotzdem anfangen.

Ja, das ist der erste Schritt und den sollte man 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 die nicht jede Datenquelle von vorn bis hinten auswendig

und man findet immer noch Überraschungen.

Aber das ist dann normalerweise nicht so, dass sie sagen,

wir wollen hier dieses super komplexe Modell,

aber wir haben noch gar keine Daten, wir müssen die erstmal sammeln.

Normalerweise sind die da schon relativ weit oben

auf der datenreifen Skala.

Und selbst wenn nicht, sind die Daten meistens schon da,

weil ganz viele Daten ja einfach automatisch mitgesammelt werden.

Zum Beispiel im Online-Shop hat man natürlich jede Menge Daten

über vergangene Bestellungen und so weiter.

Also die Daten sind eigentlich immer schon da.

Die Frage ist nur, sind die Daten da, die man braucht?

Und wenn sie nicht da sind,

dann ist das erstmal noch ein weiter Weg normalerweise.

Vielleicht ist mal ein richtiges Data Warehouse da

oder man kann die nochmal zusammenführen.

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

Wie würdest du denn so ein neues Unternehmen strukturieren,

wenn du darauf achten würdest, dass du ordentliche Daten irgendwann brauchst?

Würdest du direkt hingehen und das alles vom Scratch implementieren,

mit dem, was du am besten hältst,

oder würdest du das erstmal egal, das wachsen lassen und dann irgendwie zusammenflanschen?

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

Also wenn das ein Unternehmen ist, das irgendwelche Gegenstände produziert,

dann denke ich, ist es nicht ganz so wichtig, dass man ganz viele Daten sammelt.

Da kann man sich erst mal darauf konzentrieren und dann nach und nach einsteigen.

Aber es gibt ja auch Geschäftsmodelle, die eigentlich nur so gut funktionieren,

weil mit Daten gearbeitet wird und dann muss es wahrscheinlich von Anfang an auch berücksichtigt werden.

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

und größeren Daten gearbeitet hat,

denkt sich jetzt, um Himmels Willen,

ich will es nicht mehr hören,

weil Pandas halt sehr, sehr viel Arbeitsspeicher braucht,

wenn die Datensätze größer sind.

Es ist aber natürlich zu Prototypen

oder generell für kleine Datensätze total super,

weil es ganz, ganz viel kann

und weil man auch ganz viel im Netz findet.

Also genau, wenn die Daten aber größer werden,

dann hat man natürlich das Arbeitsspeicherproblem

und dann ist der Klassiker natürlich,

auf Spark, PySpark umzusteigen,

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

Wobei es nicht unbedingt schnell ist, aber es kann halt eben mit großen Datensätzen umgehen.

Und man hat erstmal dieses Arbeitsspeicherproblem gelöst, was man eben mit Pandas irgendwann eigentlich gar nicht mehr lösen kann.

Und dann gibt es jetzt natürlich noch seit...

Aber ich meine, eine Erfahrung, die ich oft mache, ist, dass man die, bei vielen so kategorialen Variablen oder so,

die kann man dann halt auf irgendwie ein kleineres,

äh, einen kleineren Datentyp irgendwie

runter, äh, komprimieren oder

halt oft hat man dann halt

halt irgendwie für viele, oder wenn man jetzt nur

Flex hat, irgendwie ja oder nein

oder so, wenn man da nur ein Bit nimmt, ist halt

sehr viel weniger, als wenn man da irgendwie ein volles

Integer oder so für nimmt.

Oft hilft das

dann schon, aber ja, stimmt.

Aber manchmal, wenn man die Daten einliest, dann

je nachdem kann man das, glaube ich, gar nicht unbedingt

spezifizieren am Anfang und dann sind die

einfach groß.

Oder auch selbst wenn, also ich meine,

so mehrere Jahre stündliche Verkaufsdaten

von ganz vielen Artikeln aus ganz vielen Filialen

aus mehreren Ländern.

Dann wird es irgendwie schwierig

und dann ist das Verteidige schon gut.

Und dann gibt es halt noch Polars,

womit man dann auch oft schneller ist

und halt auch weniger Arbeitsspeicher braucht.

Also wenn du das nicht kennst,

Polars ist ein Rust-nachgeschrieben-Tag-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,

weil Pandas ist halt auch irgendwie sehr stark

so historisch gewachsen

und man wusste noch nicht genau, wo man hin will und dann

teilweise inkonsistent und ja.

Ja, Pandas

ist halt, ja. Wie das halt so ist.

Genau, wie das halt so ist.

Ich habe noch gar nicht so viel mit Polars gearbeitet.

Ich weiß gar nicht, ob die eigentlich schon

das Ziel haben, da die meisten Funktionen

aus Pandas auch zu implementieren

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

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

Pure NumPy oder?

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 ein paar anders.

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, du müsst ja vielleicht schon erklären, wie das funktioniert.

Ja, um die Daten anzugucken, würde ich, na gut, es ist irgendwie schön, wenn man einmal so ein bisschen den Head anzeigt, also die ersten paar Zeilen und sieht, was da eigentlich so grundsätzlich, was das für Spalten sind, welche Namen die haben und welche Zahlen da so ungefähr drinstehen.

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

Sonst, ja, die ganze Tabelle, also man hat natürlich eine Tabelle als Pandas DataFrame, die könnte man theoretisch ja auch irgendwie als CSV speichern oder als Excel und da angucken. Das ist auch ganz praktisch, um sich die mal anzugucken, wenn die Daten klein genug sind.

Manchmal ist es sogar wirklich ganz nett, um mal einfache Analysen zu machen, zum Ausprobieren, um gespürt zu bekommen. Aber es ist dann eher so ein manueller Schritt und um wirklich Insights zu haben und die Daten zu verstehen, muss man dann, wenn der Datensatz groß genug ist, natürlich in die Summary-Statistics gehen.

Und es ist auch oft, also selbst wenn man jetzt nach dieser ersten Datenanalyse aufhören würde, ist es oft an sich schon ganz interessant und oft haben unsere KundInnen ja genau diese Analyse auch noch nicht gemacht und lernen dabei auch noch was Neues.

Einmal hatten wir aber sogar auch den Fall, dass wir, ja, dass sie dann gemerkt haben, dass da irgendwo ein Fehler im Data Warehouse ist und da war irgendwie so ein riesiger Strukturbruch, der da eigentlich gar nicht sein sollte und dann haben sie sich erstmal nochmal ein paar Monate zurückgezogen und haben das alles repariert und danach konnten wir das Projekt dann tatsächlich machen, aber das wussten sie vorher nicht und haben es dann gesehen durch unsere Datenvalidierung, dass da irgendwo ein Problem ist beim Zusammenführen.

Ja, spannend. Also manchmal sagen sie mir das. Ich habe einmal den Fall gehabt, dann waren die ganze Zeit irgendwelche so Irregularitäten irgendwie in so einem Datenflur, die da gar nicht hingehörten. Man hat irgendwie was bewundert, was ist denn das? Und irgendwann ist jemand auf die Decke gekommen, ist dann zum Förderbank gegangen, hat in die Decke geguckt und da war oben ein Fenster auf. Und dann war dann die Temperatur immer anders, weil dann das Fenster aufgelassen worden ist und so. Das war spannend, ja.

Gut 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 begleitet ihr eigentlich

eure Modelle dann

oder habt ihr da Präferenzen oder

weil das ist immer so ein bisschen,

das machen Leute unterschiedlich und

ich weiß nicht, ob es da jetzt irgendwie so

ein Standardding gibt, was man machen kann, aber

ja, das ist auf jeden Fall immer irgendwie

nicht so ganz einfach gewesen.

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

Ja, klar.

Aber tatsächlich, wir sind ja dann oft in der Infrastruktur von den Kunden unterwegs,

aber nicht immer, weil manche, zum Beispiel hatten wir ein Projekt,

da darf ich zum Glück auch drüber reden, darf man ja nicht bei jedem Kunden,

das war für die Berliner Senatsverwaltung, eine Luftschadstoffprognose,

also die läuft auch noch, aber das machen wir jetzt nur noch Wartung,

das ist soweit beschlossen.

Und die haben keine Vorgaben gemacht zur Infrastruktur,

die haben halt kein ABS oder Azure und da konnten wir es halt so machen,

wie wir wollten und ich gucke mir gerade

nebenbei in unseren Blogartikel

rein dazu, weil

da kann ich mich alles nochmal

wieder nachgucken, wie wir es gemacht haben.

Da haben wir,

konnten wir ganz

frei entscheiden, was wir haben wollen

und haben dann

mit Kubernetes

gearbeitet, das ist auch alles

schön selbst aufgesetzt und da laufen

dann automatisierte Jobs drin

und wir haben,

na gut, das ist jetzt weniger mit

Deployment zu tun haben. Wir haben da dann

eine Clickhouse-Datenbank, die ist ganz cool für

große Datenmengen und

haben dann

Docker-Container, in denen unsere Prozesse

dann laufen. Da haben wir auch

Releash benutzt, wie ich erwähnt habe. Das benutzen wir

dann auch für die Alerts, um zu gucken, sind

alle Input-Daten da, sind alle Prognosen

so erstellt worden, wie wir wollen, sind so viele

Prognosen in der Tabelle, wie wir erwarten

würden und so weiter.

Und in dem Projekt ist tatsächlich

nur, im Hintern haben wir Releash 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 Natsverwaltung 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 dem

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 die nicht,

kann das nicht aufsetzen oder

mache dann nicht die Deployments.

Ja, was mich da mal, oder das Problem,

das ich da mal hatte, ist halt,

dass wenn jetzt Leute quasi in Notebooks

irgendwas modellieren oder so, wie kriegen sie denn dann,

wenn sie jetzt rauskriegen, ah, wenn ich dieses

Modell so parametrisiere oder so,

oder, ja, man hat dann normalerweise

eine ganze Pipeline von Datenkomponenten,

rein, dann werden sie irgendwie transformiert und

dann hat man halt hinterher irgendwie

Predictions oder so.

Wie kriege ich das Ding denn jetzt

quasi in das Produktionssystem

integriert? Und das,

was wir dann gemacht hatten, war halt

quasi aus dem

Notebook direkt

sozusagen ein Konterpaket zu bauen,

das hochzuladen, in Django

Filefield zu speichern und dann auch über eine

JSON-API dann die Ergebnisse wieder zurückzugeben.

Aber das fühlte sich so ein bisschen

falsch an oder so auf jeden Fall nach

gibt es da nicht irgendeine einfache Möglichkeit, wie man

das machen kann? Ich weiß nicht, ob es einfacher

ist, aber wir sind auch

ganz wenig eigentlich nur in Jupyter-Notebooks

unterwegs,

sondern ja, entweder, wenn

wir was schnell visualisieren wollen, geht das tatsächlich

ja mit so einem Tool wie Redash auch schneller, als wenn man

dann anfängt,

mal Plot-Lib-Code zu schreiben.

Dann ist Clicky-Bunty

manchmal gar nicht so blöd und schlecht,

wie es klingt.

Und dann, wenn wir dann die

Code-Free-Modellierung haben, dann ist es halt wirklich

das ist ein Python-Paket,

wir haben das dann

automatisieren das dann meistens

so, dass jedes Mal beim Push

in den Main-Branch,

wenn die Versionsnummer sich geändert hat,

wird das dann, wie bei Jenkins

wird ein Job getriggert, der dann

das Paket baut und in unser

Repository hochlädt, das dann

normalerweise nur intern verfügbar ist und

dann können wir, ob das dann

automatisch deployed wird oder wir das irgendwie manuell machen,

können wir uns dann halt überlegen.

Ja, aber dann brauchen wir einfach runtergeladen

auf den Pott. Ja, aber dann brauchen ja

die Leute, die quasi modellieren, Zugriff

auf das Produktionssystem

quasi oder können halt,

es muss halt dann, die müssen den Code verändern, die müssen

committen können. Ja.

Also die committen von

morgens bis abends.

Also das ist tatsächlich

bei uns überhaupt nicht so, dass da irgendwie

jemand sitzt, der nur in einem Notebook prototypt.

Gar nicht. Also

wenn das Projekt losgeht, dann

muss man als erstes ein Repo anlegen, weil sonst

kann man hier gar nichts machen.

Ja.

Und vielleicht startet man dann irgendwie mit ein paar

Skripten, die dann später ordentlich

in ein Paket überführt werden und

in Funktionen und Klassen verpackt. Das kann

schon sein, aber grundsätzlich

ist es halt

eine Software und

sind auch oft in größeren Projekten mehrere Pakete.

Zum Beispiel in dem

Projekt für die Senatsverwaltung sind das dann,

wir haben da sehr viele verschiedene Datenquellen, zum Beispiel

Verkehrsdaten, Wetterdaten und so

und dann haben wir für jede Datenquelle ein

Paket, das nur dafür da ist, diese Datenquelle

einzulegen und zu formatieren, die Datenbank

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

dann kommt irgendwann das nächste Paket,

das liest sich die Daten dann und macht dann die

Modellierung. Und dann gibt es nochmal ein Paket,

das halt irgendwelche Daten

weiter aufbereitet und dann gibt es ein Paket mit der API.

Und wenn

ihr ein Modell daraus gebaut habt, irgendwie mit

Torch oder sowas, was macht ihr dann?

Wo legt ihr das dann hin?

Ja, wenn das dann in dem Fall

tatsächlich...

Ich verliere gerade. Also tatsächlich, im Kundenprojekt benutzen wir MLflow und ich weiß nicht, ob, also ich hatte das vorher tatsächlich noch nicht benutzt, wo wir die Objekte dann abgelegt. Ich glaube, es gibt, das ist ganz witzig, ja, es gibt tatsächlich, das war jetzt ein Projekt mit XGBoost, weiß ich nur, da haben wir, kann man die Projekte tatsächlich in Form eines Strings speichern und da haben wir die in der Datenbank gespeichert.

Das funktioniert ganz gut, man kann aber natürlich auch das Modellobjekt irgendwo in deinem Modellrepository dann ablegen.

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

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

Also gut, wenn jetzt die Modellierung total schnell geht, dann kann man natürlich auch das Modell einmal im Monat neu berechnen.

Einmal im Tag neu berechnen, sofort die Prognosen machen und das Modellobjekt überhaupt nicht speichern.

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

Normalerweise muss man es ja schon speichern und wiederverwenden.

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

ein bisschen weiter entlanghangeln.

Ja, gerne.

Weil wir jetzt schon vorgegriffen haben.

Also wenn wir das Problem verstanden haben,

die Daten verstanden haben und die sehen soweit gut aus,

dass wir und unser Kunde gemeinsam sagen,

okay, damit können wir jetzt wirklich starten.

Da ist kein Problem drin.

Dann passiert natürlich erstmal ganz viel Datenaufbereitung

und Bereinigung.

Oft muss man verschiedene Datensätze zusammenführen.

Da haben wir dann natürlich vorher schon geprüft,

ob es auch eine gemeinsame ID gibt, um die zusammenzuführen.

Sonst wird es schwierig.

Oft muss man auch Sachen aggregieren.

Zum Beispiel hat man vielleicht einzelne Zeilen für jedes Produkt,

das gekauft wurde von einem Kunden.

Wir wollen aber eigentlich nur eine Zeile pro Kunde.

Da muss man sich was überlegen, wie man das voll aufaggregieren kann.

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

Also das, was man immer als Feature Engineering kennt.

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

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

Macht ihr das dann immer live in Pandas

oder schreibt ihr das auch in eine Datenbank rein?

Es kommt drauf an,

aber meistens haben wir dann schon eigentlich ein separates Modul,

das die Features berechnet und irgendwo hinschreibt,

weil das meistens dann einfach schöner ist,

das zu modularisieren, weil es sonst ein bisschen zu viel wird.

Was ist da eure Lieblingsdatenbank für?

Ich überlege gerade, wir waren früher

viel auf MariaDB unterwegs, jetzt sind

wir, ja,

viel in ClickHouse, also ClickHouse

teilweise verhält es sich unerwartet, finde ich.

Aber es ist halt

schon sehr cool mit großen Datenmengen,

da kannst du einfach die...

Das ist diese Geschichte,

Yandex hat das, glaube ich, mal gebaut,

und dann haben sie es irgendwie Open Source

veröffentlicht. Das weiß ich nicht.

Ich weiß es nicht genau.

Ja, das habe ich auch schon

ein gutes Wort 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 es jetzt nicht gut funktioniert, dann müssen wir natürlich irgendwie auf eigene Kappe nochmal ein paar Tage investieren, um das umzustellen. Aber es war so eine gute Entscheidung, weil wir gemerkt haben, mit den Datenmengen würde in anderen Datenbanken überhaupt nicht gehen.

Ja, und wenn wir dann so Features haben und die stehen dann vielleicht auch in der Clickhouse-Datenbank oder vielleicht stehen sie auch in der Postgres- oder Redshift-Datenbank, dann geht es dann erst mit der Modellierung los und zum Glück haben die meisten Leute von uns auch Spaß an den anderen Sachen, weil wie gesagt, die Modellierung meistens wirklich nur ein kleiner Teil ist.

Man muss sich natürlich genau überlegen, was ist überhaupt das passende Modell. Im Moment, wenn man Prognosen machen will, ist immer noch G-Boost einfach sehr, sehr gut. Das ist ein bombasiertes Modell. Aber es kommen gerade Sachen, zum Beispiel gibt es da P-F-Enders.

Ja, das klingt auch sehr interessant, ja.

Es ist ein Transformer-Modell und das ist irgendwie total verrückt, weil dieses Modell hat, also ich finde es immer noch total beeindruckend, es ist irgendwie so Magic, also das hat gelernt, wie Datensätze, wie die Zusammenhänge in Datensätzen normalerweise so sind.

Und dann gibt man dem nochmal so ähnlich wie so ein Feintuning den Datensatz, den man halt da selbst hat, der einen interessiert. Und dann kann man damit total gute Prognosen machen, auch wenn der Datensatz nicht besonders groß ist. Und das Verrückte ist, diese Datensätze, anhand derer das gelernt wird, das sind künstliche Daten. Also es sind nicht mal echte Daten, weil es ja gar nicht so viele im Netz verfügt.

weil es ja anders ist, wenn man ein Sprachmodell trainieren will,

das ganze Internet besteht aus Sprache.

Aber es funktioniert trotzdem, es ist richtig beeindruckend.

Also ich glaube, das ist sowas, was sich

gerade so anfühlt wie, okay, da passiert

jetzt wirklich mal wieder was Neues

in der Bereich-Prognose.

Jaja, auch diese ganzen Pre-Trends,

das gibt 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,

Und ja, das hat mich auch total gewundert.

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

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

Also Tab-DFN hast du gesagt und XGBoost, also Gradient Boosting.

Ja, XGBoost ist ein Gradient Boosting und das ist halt eigentlich einfach dazu da,

um eine Tabelle von Daten zu nehmen und die Zusammenhänge zu lernen, die in diesen Daten vorkommen.

Zum Beispiel will ich vielleicht vorher sagen, wie viel verkauft wird 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 dann 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.

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

ergänzen sie sich 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 da noch so ein paar Varianten.

Es gibt zum Beispiel Catboost, das es so ähnlich hat,

aber halt schon irgendwie ganz schlaue

Mechanismen implementiert, um mit

kategorialen Variablen umzugehen und manchmal

das eine oder das andere dann so ein bisschen besser oder performanter,

aber das ist kein Riesenunterschied.

Da gab es ja nicht auch noch irgendwas für Microsoft Lightboost

oder sowas, aber ich weiß gar nicht, was da rausgeworden ist.

Oder LightGBM, genau. Ich weiß gar nicht, was da rausgeworden ist.

Ich habe nur irgendwann...

Benutzen wir auch gerade in dem Projekt.

Und ja, witzigerweise,

wir haben auch schon, gerade vor einem Jahr

oder so, haben wir gedacht, kann man eigentlich auch

LLMs zur Prognose benutzen? Ich möchte dem LLM ja

sagen, guck mal hier, das und das und das sind

meine Daten, was denkst du, wie

teuer ist dieser Gebrauchtwagen?

Und wir haben da einen Datensatz bekommen von

einem Unternehmen,

die genau solche

Daten eben aus dem Internet crawlen

und die, das

sagen wir natürlich so ein bisschen

Informationen mitgeben und das hat

aber schon funktioniert. Also wir haben da

ja, da weiß

ich jetzt die Details natürlich nicht alle auswendig,

aber wir haben sowohl mit

GPT-Modellen

als auch mit Open-Source-Modellen das ausprobiert.

Es macht schon Sinn, die zu freintunen

und dann kann man aber

relativ gut sagen, mein Auto oder

das Auto, das ist die Marke, das hat so

viele Kilometer, das ist so und so alt

und hier ist noch der Freitext mit der Beschreibung

dazu. Da steht dann

vielleicht irgendwas Spannendes drin,

wie das hat eine Beule, vielleicht steht aber auch nichts Spannendes

drin. Und dann fragt man, wie

teuer ist das Auto?

Bitte antworte mich nur in einer Zahl,

in Euro oder irgendwie sowas. Und das

funktioniert schon erstaunlich gut, vor allem, wenn man

nicht so viele Trainingsdaten hat. Weil ich glaube,

dann kann das halt die Stärke ausspielen, dass

das Sprachmodell eben

schon Vorwissen hat zu Autopreisen,

weil es das Internet kennt. Also Transformers

meinst du jetzt tatsächlich, also die großen LLMs

und nicht nur Transformers selbst? Genau. Weil ich hätte

mich halt gefragt, ob das in dem Transformers-Modell

durch das, weiß ich nicht, dadurch, dass es

halt Nodes sind und Canisian Trees,

dass es da irgendeine andere Art gibt,

dass Daten aus den 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, das halt wie speziell

für tabulare Daten wieder gemacht ist, weil wir haben

ja die LLMs eigentlich so ein bisschen zweckentfremdet,

indem wir die dann da nach dieser Probe-Modul gesagt haben.

Was meintest du denn da überhaupt mit Feintuning?

Was habt ihr denn da gemacht?

Also ich weiß nicht, wie das eigentlich im Detail dort funktioniert, aber es ist so, dass das Modell ja eben schon ganz viel weiß von den Sprachdaten, die es aus dem Netz kennt und wir haben ihm dann nochmal, ja gut, das beschreibt es wahrscheinlich ab dann schon komplett, wir haben dem dann nochmal, wir haben einen Trainingsdatensatz, wir ganz viele Gebrauchtwagen schon drin haben mit dem Preis und den ganzen Eigenschaften.

Und dann haben wir ihm ganz viele Texte gegeben, zu jedem Auto ein Text. Das Auto ist so und so alt, sieht so und so aus, ist die Marke und es kostet das. Und das nächste Auto ist so und so und so und kostet das. Und das ist dann nochmal ein zusätzlicher Text und damit trainiert man das Modell nochmal spezifisch auf diesen einen Task.

Also wie das jetzt im Hintergrund genau passiert, kann ich tatsächlich euch gerade gar nicht erklären, weil ich in dem Thema weniger drin bin als in so etwas wie XGBoost. Aber ja, dadurch ist das Modell dann nochmal, kriegt nochmal so eine Spezialausbildung quasi für das Thema Auto-Gebrauchtwagenpreise. Und dann wird es nochmal besser, wenn man ihm dann so eine Frage später stellt.

Ja, man trainiert es quasi nochmal ein Stückchen weiter, gibt es unterschiedliche Ansätze, wie man das dann macht, ob man nur Layer einfriert, bestimmte Gewichte halt nicht neu setzt und dann vielleicht nur die letzten irgendwie anpasst oder ob man so Low-Rank-Adaption-Geschichten macht oder da gibt es ganz unterschiedliche.

Ich komme mir an die Gewichte gar nicht dran von den großen NLMs zum Beispiel.

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

Ja, genau, das natürlich.

Ich glaube, wir haben da beides

gemacht. Also einmal über OpenAI, da kann man einfach

über die Abdesign-Dienst mit Fine-Tuning-Datensatz

machen, aber auch mit

den Open-Source-Modellen,

wo wir dann nochmal ein Fine-Tuning

drangehängt haben, damit die eben speziell

auf Autopreise...

Bei Tuning

und Autos fällt mir jetzt erst auf, dass das

echt total gut passt.

Ja.

Okay, das ist also Tab-DFN.

Ja.

Wobei, das ist jetzt noch relativ

neu und da

ja nicht jede Woche neue Projekte losgehen,

sondern die meisten Projekte schon länger laufen,

sind die meisten Projekte, die wir haben,

dann auch mit sowas wie XGBoost oder teilweise

auch mit irgendwelchen ausgefeilten

statistischen Ansätzen

oder Kombinationen, je nachdem,

was man macht. Ja, das finde ich dann spannend. Wie viel kann denn

jemand, der richtig gute Statistik oder in klassischer

Statistik ist, rausholen im Vergleich zu diesen

ich beschieße das einfach mit so einem Modell?

Ich würde sagen, es

kommt auf die Fragestellung an. Bei so einem

relativ klassischen Tasks

wie

Verkaufszahlen geht es, glaube

ich, auch mit einem Modell

ganz gut,

wenn man es natürlich richtig macht und

zum Beispiel noch,

es gibt da ja eine Menge Hyperparameter, die

bestimmen, wie flexibel ist das Modell und

wenn man das Modell zu flexibel sein lässt, dann

lernst du auch die kleinsten

Wackler auf den Trainingsdaten und auf neuen Daten

erzählst du dann nur Mist.

Das heißt, dann hat man Overfitting

und das muss man verhindern. Es gibt natürlich schon

ein paar Sachen, die man falsch machen könnte,

aber wenn man da alles

nach State of the Art macht, kommt man bei so

einfachen Aufgaben mit einem XG Boost

meistens ziemlich weit, aber

ja, zum Beispiel

im Sportwettenbereich gibt es ja

manchmal dann wirklich komplizierte Sachen, also wenn

ich jetzt vorher sagen will, wie

die Tore sich verteilen,

dann

kommt man da dann schon nochmal weiter, wenn man wirklich

darüber nachdenkt, theoretisch, was ist denn das

jetzt eigentlich für eine Verteilung, das sind

Anzahlen, also es ist eine

Brosson-Verteilung, aber die ist ja irgendwie

bivariat, weil es sind ja zwei

Mannschaften und zwei Teams, die Tore

machen und da weiß ich, dass

meine Kolleginnen und Kollegen

sich schon einige ziemlich verrückte Sachen

ausgehört haben. Und dann umgekehrt, manchmal ist es am Ende

auch irgendwie doch nur eine einfache Heuristik,

die einen ziemlich weit bringt.

Ihr habt also nicht die Ernährung der Spieler am Morgen

zuvor mit einfließen lassen können in sowas?

Das weiß ich nicht, ich müsste mal fragen, ob sie das

in der Feature drin haben.

Es gibt auf jeden Fall spannende Sachen.

Ja, also ich würde mich halt tatsächlich interessieren, was man aus Statistik irgendwie daraus lernen kann, weil ich verstehe nicht genau, wie jetzt in so einem Transformers-Modell die einzelnen Gewichte bei den Neuronen zustande kommen, also ich stelle mir das so vor, der muss versuchen, diese Features rauszufinden und die irgendwie so linear unabhängig wie möglich voneinander zu gestalten, dass er irgendwie den Erklärungsgrad dann da rausfindet, der dann halt gut ist, damit er halt gute Prognosen hinkriegt, aber so richtig klar wird das nicht.

Ja, neuronale Liste sind deutlich eher Blackbox, aber das ist Extribus auch. Natürlich, du kriegst bei beiden auch so ein bisschen raus, was da der Grund ist, warum das jetzt irgendwie so oder so entschieden oder vorhergesagt hat, aber es ist schon eher so Blackbox-Modelle.

Ja, man kann jetzt nachträglich dann.

Also das wäre jetzt vielleicht für mich auch nochmal einer der Punkte, der für dieses Data Cleansing spricht. Ja, also wenn ich jetzt die Daten da einfach so reinkippe oder am Anfang schon so aufteile, dass ich jetzt Cluster bilde oder Kategorien bilde oder sowas und die halt nochmal damit annotiere oder so, ob das halt eine deutliche Verbesserung bringt, also weil die ein bisschen reiner sind vielleicht oder halt, ne, oder schon mal irgendwie die Daten wie eine Zusammenfassung oder eine Summe oder sowas da schon drin steht mit, ja, in irgendeiner extra Spalte, dass das dann halt das Ergebnis zum Beispiel nochmal deutlich verbessert.

bessere Güte kriegt.

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

Ja, vielleicht.

Also zum Beispiel,

viele Modelle sind ja auch dazu in der Lage,

Interaktionen zu erkennen. Also beispielsweise,

weißt du,

vielleicht mal gerade

ein gutes Beispiel. Ah ja, vielleicht aus der

Luftschallstoff-Prognose überlege ich gerade

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

Das ist halt die Interaktion, also die Effekt, mittags ist es schlechter, der ist nur da, wenn die Windstärke gering ist.

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

Und wenn man da schon so eine Idee hat, sag ich logisch, dann macht man es dem Modell halt schon deutlich leichter.

Wenn man das vorher schon mal explizit zusammenbaut, also dann vielleicht irgendwas, das würde dann sagen, es ist Mittag und es ist kein Wind und es ist windstill. Jetzt in diesem sehr einfachen Beispiel. Und das ist dann, glaube ich, auch wieder so was, wo es dann wirklich viel bringt, immer mal wieder mit den Leuten zu reden, die sich fachlich damit auskennen.

und das... 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... Ich würde sagen, eigentlich

ja, du erst. Oh, sorry.

Ja, 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 rein

kippen, weil das kann halt bloß

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

Ja, das war

tatsächlich so ein Grund, weshalb wir

das auch mal ausprobieren wollten mit den LLMs

zur Vorhersage, weil wie du sagst, wenn wir einen Text

haben und wollen aber XGBoost machen,

wie in dieser Freitext mit der Autobeschreibung,

da muss man sich ja erstmal irgendwie was überlegen,

wie man den dann in ein sinnvolles

Format bringst du das ins G-Boost. Das kennt halt

eigentlich nur spaltende Zahlen.

Kategorien kann man ja im Prinzip auch noch 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 noch mal ein bisschen genauer.

Das ist halt die Frage, ob es sich lohnt.

Das muss man sich mal überlegen.

Ja, gut, aber

dadurch kann man schon viel rausholen, durch diese Modellierung

dann und so.

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, Load?

Das ist, glaube ich, aber nicht unbedingt was mit

oder...

Ja, aber wir sind jetzt da irgendwo in diesem

Workflow, also es ging ja um

dieses CRISP, ne? Achso.

Ja, also ich glaube ja,

also die ETL, Extract, Transform,

Load, ist ja, beschreibt

ja einfach den Prozess, dass man

Daten irgendwo rauszieht, dann

irgendwas damit macht, also sie transformiert und sie dann

irgendwo hinlädt, obwohl man sagt, Daten laden

für Daten kriegen, in dem Fall ist aber Daten laden

sie irgendwo hinladen, das ist auch ein bisschen

verwirrend, auch im Naming finde ich,

in den

Code dann, wenn man irgendwann überall

Load stehen hat, egal ob man Daten zieht oder Daten

wegschiebt.

Ja, das ist, so hängt das

im Prinzip zusammen, aber oft benutzt

man ja den Begriff ETL

auch einfach für jeden Prozess,

der irgendwie Daten nimmt, verarbeitet und

so durch so eine Strecke schiebt.

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

Ja, 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 ETL,

Erst kommt der ETL 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 kriegt das Modell zum Lernen.

Und dann habe ich auf diesen weggelegten Daten die Prognosen.

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

Und das Modell ist halt ja natürlich in dem Moment blind, das kriegt halt nur die ganzen Features,

aber es kriegt nicht die Zielvariable, es muss dann seine Prognosen blind machen

und wir können dann gucken und sagen, ja, wir kennen die Warnwerte aber schon und vergleichen das jetzt.

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

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

man kann einen Bias berechnen, liegen Mittel drüber oder drunter,

Man kann einen erklärten Varianzanteil berechnen.

Man kann, je nachdem, vielleicht wollen wir auch gar nicht

numerische Daten vorher sagen, sondern nur ein Ja, Nein.

Dann könnte man gucken, wie viele 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?

Will ich irgendwie 20, 50 oder 90 Prozent erklärte Varianz?

Das kommt auch stark auf die Fragestellung an.

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

dann 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 sind, auch tatsächlich evaluiert wird.

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

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

Aber man muss natürlich auch immer auffassen, dass man dann halt die neuen Zusammenhänge nach den Änderungen dann irgendwie auch trotzdem mit reinkriegt, ne?

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

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

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

Also man könnte ja vielleicht auch diese Zusammenhänge irgendwie als, ich sag mal, Liste dem Geschäft zurückgeben, hey, hier, das sind unsere Annahmen, guckt doch mal bitte, dass die noch stimmen und wenn ihr merkt, irgendwie da ändert sich irgendwas an den Annahmen, dann müssen wir halt da nochmal was auch anpassen.

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

Ja, okay, aber wie viel schwächer der jetzt wird, das kann uns diese NAS-Verwaltung hier für Umwelt und so weiter ja auch nicht sagen. Also sie können uns sagen, ja, das wird wahrscheinlich schwächer mit der Zeit. Also klar, solltet ihr das Modell regelmäßig neu trainieren, aber die können uns nicht sagen, so und jetzt ist es aber so viel schwächer geworden, jetzt müsst ihr mal neu trainieren. Das kann die auch gar nicht sehen.

Aber deswegen ist es halt meistens so, dass man einfach sagt, wir trainieren unser Modell zum Beispiel einmal im Monat neu und dann wissen wir, dass wir halt eigentlich immer neue Zusammenhänge abgedeckt haben. Deswegen ist es auch manchmal gar nicht so nützlich, ganz, ganz viel Datenhistorie zu haben, weil vielleicht das vor allem jetzt, wo auch noch Corona war, dass die Zusammenhänge und die Muster während Corona in irgendwelchen Verkaufszahlen oder menschlichem Verhalten, die sind natürlich jetzt halt anders.

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 Normalfall trainiert oder den Alltag. Und diese ganzen Schock-Situationen, die kann ich ja immer ganz schlecht abbilden, weil ich ja dafür auch keine Beispiele gehabt habe.

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 dem Luftverschmutzungsprojekt, haben wir, glaube ich, einfach die Zeiträume definiert. Hier war Lockdown, hier war kein Lockdown. Damit das Modell zumindest weiß, ah, deswegen war hier so viel weniger Luftverschmutzung.

Ja, okay, sonst hättest du gedacht, oh, das ist eine gute Sache.

Aber ich habe nochmal, ich würde mal ganz kurz einen Schritt zurückgehen, weil ich habe eine Frage, die mich noch jetzt schon interessieren würde, weil ich jetzt auch gar nicht so wirklich Ahnung von diesem Tab-PFN oder so habe, weil in den anderen Bereichen haben ja die, also normalerweise hat man neuronale Netze für solche tabularischen Daten, das hat nicht, das funktioniert auch, aber halt nicht so gut wie die anderen Arten von Modellen oft.

Und die Frage wäre jetzt, was einem ja die Transformer beziehungsweise überhaupt irgendwie das ganze Deep Learning, die ganze Deep Learning Geschichte oder so in anderen Bereichen gebracht hat, ist ja, dass man nicht mehr so viel Feature Engineering machen musste oder eigentlich ist man ja am Feature Engineering mehr oder weniger vorher gescheitert und dann jetzt kann man halt inzwischen einfach die Rohdaten da so, naja, mehr oder weniger reinkippen und das neuronale Netz macht das Feature Engineering für einen sozusagen.

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

Da fragst du eigentlich die falsche. Ich glaube aber, dass man da nicht viel vorbereiten musste. Aber da würde ich tatsächlich auch auf unsere Podcast-Folge mit dem Autor von Tapping FM verweisen.

Muss ich mal anhören. Klingt gut.

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

Ja. Aber vielleicht nochmal zu dem Modelltraining. Wo trainiert ihr denn das und wie macht ihr das?

auf

also oft auf

ABS-Maschinen zum Beispiel.

Wir haben auch selbst ein paar

fette Server, die sind

jetzt im Rechenzentrum in Nürnberg. Seit neuestem

haben sie dort unter ihresgleichen.

Vorher haben sie so ein bisschen das Büro beheizt,

sag mal, es gewinnt das. Jetzt haben

sie einen besseren Ort gefunden. Also die benutzen wir auch

manchmal, aber viel läuft jetzt natürlich

inzwischen in der Cloud und auch das ist dann auch

kundenabhängig. Also zum Beispiel

Azure, was auch immer dann.

Aber das sind

auf Sachen, die dann doch lokal

ein bisschen zu lang dauern würden und dann besser

auf einer größeren Maschine laufen.

Also irgendwie, ja.

Und also die klassischen

Sachen sind halt normalerweise

einfach auf der CPU natürlich

und wenn wir dann aber zu

LLMs kommen, dann geht es natürlich in Richtung

GPU und wir haben uns auch da

was zugelegt vor einigen

Monaten, sodass wir unsere eigene GPU haben

und auch mal selbst das

aussetzen konnten auf einer 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, wir haben ja auch

mal was ausprobiert, war die dann doch zu klein,

da haben wir das dann über Abyss gemacht.

Okay.

Das ist auch schwierig, gerade welche zu kaufen,

und das ist sehr teuer.

Ja, es ist teuer.

Ja, komm, das macht jetzt schon Sinn.

Wir kaufen die, aber

ich glaube, sie war dann irgendwie zwei Monate

später wieder deutlich günstiger.

Ich glaube, wenn man die mietet, dann kostet die

irgendwie so 1.000 Euro im Monat oder sowas.

Also mit viel Hauptspeicher,

wenn du zum Beispiel LLMs feintunen willst,

dann zahlst du eher 1.000 Euro am Tag.

Ja, das ist richtig teuer.

Ja, okay, kommt wahrscheinlich darauf 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, das macht auch Spaß.

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

Dann kommt ja der Operator durch auch.

Ja, ich würde das auch machen.

Ich brauche nur einen Grund. Gib mir doch einen Grund dafür.

Also vielleicht wollt ihr ein unbezahltes

Praktikum.

Wenn wir dann ganz viel

große Hardware in die Hand nehmen, können wir nur mal nachdenken.

Richtig.

Das könnten wir mal nutzen.

Aber ja.

Vielleicht noch mal zu

der Modellbewertung. Ich hatte ja schon

gesagt, dass man natürlich Kennzahlen ausbechern kann

für die Modellgenauigkeit so

insgesamt. Wie viele

Fälle werden richtig vorher gesagt, oder wie weit sind wir

im Mittel daneben. Aber dann

macht es halt auch Sinn, diese Blackbox

nochmal aufzubrechen, wie ihr

eben erwähnt habt. Dass man guckt, was hat

das Modell eigentlich für Zusammenhänge gefunden.

Und das ist

bei einer linearen Regression natürlich leicht,

weil man sich einfach die Koeffizienten anguckt,

wie hoch die sind und hat noch welche signifikant sind.

Aber das geht dann

bei XGBoost nicht mehr so leicht,

irgendwelche Splits anzugucken, wie das Modell gefunden hat.

Aber da gibt es

ganz tolle Methoden, die nennen sich

Shep und die

kann man dann danach auf die,

also man braucht das Modell und auch 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 auch. Also erstmal eine

Feature Importance, also wie viel

wurde welches Feature vom Modell eigentlich genutzt.

Auch das ist ja schon mein erster

Plausibilitätscheck, wenn da irgendwas ganz am Anfang

steht, was dir überrascht ist, sollte man auch überlegen,

was da los ist. Und dann kann man sich

auch die Form der Zusammenhänge angucken. Zum Beispiel

Beispiel, ich glaube, da haben wir auch gesehen, je windiger, desto weniger Schadstoff, aber irgendwo gibt es dann so eine Sättigung, dann sind die Schadstoffe halt irgendwie einfach so weggeweht, wie es nur geht. Und das, ich glaube, es war sogar, nee, ich glaube, das war das Interessante, irgendwann wurde es halt wieder schlechter, weil dann der Staub aufgewirbelt wird. Wenn es so wenig ist, dann hat man immer nur den Staub in der Luft, dass es wieder schlechter wird.

Und da dachte ich so, okay, was ist das für ein komisches Muster? Und haben das mit Kunden angeguckt. Die meinten so, ja, das haben wir auch schon beobachtet. Wir denken, das liegt daran, dass dann irgendwann der Wind zu stark ist, dass das halt stoppt.

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

Ja, ist natürlich, wenn es regnet, dann halt eben wieder das, wenn dann wird das eben weggespült. Und solche Sachen kann man dann halt eben sich angucken und überlegen, ob die plausibel sind. Und man kann mit den Methoden sogar ganz einzelne Vorhersagen auch nochmal analysieren.

Und dann sagt die einem quasi so, okay, wir haben jetzt hier 3,5 mehr gesagt, weil es ist Montag und dann haben wir aber nochmal 1,2 weniger gesagt, weil es ist in den Ferien oder sowas. Und das ist natürlich auch sehr gut, um wirklich erklären zu können, warum man genau diese Prognose macht und was das Modell findet und um sich sicher zu sein, dass man auch irgendwie ein sinnvolles und gutes Modell gefunden hat.

und das klingt jetzt alles so

lineal, es soll nur mal da so durchgehen, aber

das ist dann auch manchmal ein Moment, wo man noch mal

Ideen hat und neue Features baut

oder noch mal Ideen hat und die Daten bereinigt,

weil einem irgendwas ganz komisches auffällt, irgendein

Artefakt, das man loswerden muss,

dass egal wie toll

man sich die Daten vorher anguckt, manche Sachen

finde ich, sieht man einfach erst nach der Modellierung

und muss dann irgendwie noch mal ein Stück zurückgehen,

das ist ja kein Problem.

Das ist ja dieser Eval-Step dann,

der dann guckt, ob das, was man da macht,

auch dem entspricht, was man so

möchte. Oder ja,

es gibt ein Alert.

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 sind eigentlich immer ein paar Tests unterwegs.

Ja, wir lieben

FI-Tests.

Wobei Tests mit Daten ja auch manchmal ganz witzig

sind, weil man

ja, braucht man sich

dann einen kleinen Testdatensatz, ist der

dann realistisch,

macht man vielleicht sogar Tests gegen die

echten Daten, die können natürlich

keine einzelnen Werte prüfen, aber man kann damit

testen, ob es überhaupt durchläuft, also ja,

das ist ein ganz eigenes Thema, Tests mit Daten.

Ja, es ist

tatsächlich schon, ja, also ich würde

auch dazu tendieren, irgendwie aus der Realität irgendwas rauszuschneiden

und dann zu gucken, ob das dann so läuft.

Weil also so Daten

mocken ist immer so ein bisschen...

Naja gut, ja.

Ja, es geht auch mal, aber

schwer. Ja, also in dem Moment

wäre man ja eigentlich nur 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 stellen unsere

Prognosen oder Klassifikationen

oder was auch immer

oft über APIs zur Verfügung,

über Rest-APIs.

Oft machen wir aber auch nochmal

schon ein Frontend dazu,

also eine Web-App, wo die dann angezeigt

werden, wo zum Beispiel unser Kunde sich dann

die Alarme angucken kann

von irgendwelchen

Käufen, die irgendwie suspekt aussehen.

Mit was macht ihr

eine Vent-App? Mit was macht ihr

die Web-Apps?

Meistens mit Vue.js

und

historisch auch noch häufiger mit

R-Shiny.

Da haben wir

ein Projekt, das ist eigentlich ganz cool.

Da geht es gar nicht darum,

irgendwelche Prognosen zur Verfügung zu stellen, sondern

da haben wir Shiny-Apps gebaut, damit

Leute Modellierungsalgorithmen

anwenden können, ohne dass sie selbst

R-Code schreiben können müssen.

Das ist für ganz viele Forschende, die

aber nicht gut selbst coden können.

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

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

Das ist natürlich auch sehr praktisch und schreiben die dann mit ihre Doktorarbeiten.

Ja, aber zurück zu unseren Prognoseergebnissen.

Genau, oft stellen wir die über eine API zur Verfügung

oder wir schreiben sie irgendwo in eine Datenbank

und der Kunde nutzt sie dann halt so.

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

Reicht das denen, wenn das eine API ist?

Oder sitzen da dann Leute, die damit überhaupt nichts anfangen können

und sagen, ja, was sind denn jetzt meine Zahlen?

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

Und unsere Erfahrung ist auch, dass es,

auch wenn der Kunde dann irgendwie vorhat,

doch das selbst zu machen,

sagt, ja, schreib das in die Datenbank

und dann benutzen wir es einfach so weiter,

dann trotzdem lohnt es sich oft,

dass wir das dann doch mitdenken

und zumindest irgendwie eine kleine Web-Anwendung schreiben,

weil sonst die Löhne doch groß ist

und dann hat der in IT halt eben auch total viel zu tun

und dann ist es richtig schade,

wenn das Projekt nachher in der Schublade landet

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

Also dann lieber nochmal was Kleines bauen,

damit die dann doch was sehen können.

Aber wenn die Farben dann auch richtig sind,

ist das das Wichtigste an der Flickung.

Ja, irgendwie schon.

Das kann man auch durch unterschätzen.

Man sieht ja alles, ja, das ist sauhässig.

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

Das ist dann oft sowas wie einmal im Monat.

Ab und zu sollte man sich das Modell

sogar auch noch mal ganz genau anschauen,

zum Beispiel nochmal diese ganzen CHAP-Sorten berechnen und gucken,

ist das eigentlich noch plausibel?

Das kann man vielleicht einmal im Jahr machen.

Und die Prognoseerstellung kommt halt darauf an,

wie oft die benötigt wird und auch wie schnell sich die Sachen ändern.

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

aber manchmal ist es dann auch wirklich in Echtzeit,

dass dann der Anfall reinkommt und dann wird die Prognose

für diesen einen ganz konkreten Fall erstellt.

Und oft kann man die auch noch nicht vorbereiten,

weil man die Daten vielleicht dann auch 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 das natürlich auch überhaupt nicht unterschätzen, weil vom POC zum MVP und das ist dann ja noch ein simples Produkt, das ist oft nochmal Faktor 10 vom Aufwand her.

Ich glaube, das ist halt total schwer erkennbar, 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 noch mal ganz viel Zeit.

Und die denken so, hey, wir hatten es 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 dann danach.

Ich meine, kann man ja verstehen,

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

oder einfach schlecht informiert fühlt.

Ja, schwierig.

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

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

Aber es kann auch sein, dass die durchlaufen ohne Fehler, aber trotzdem irgendwas stimmt und vielleicht nur für halb Berlin Prognosen erstellt werden oder nur für einen halben Tag und deswegen sind dann da auch Alarme definiert, die gucken, ist die Anzahl, entspricht die Anzahl der Prognosen in der Datenbank auch tatsächlich unserer Erwartung?

Man kann auch definieren, gibt es irgendwelche unerwarteten Werte, extrem hohe Prognosen beispielsweise oder gibt es unerwartete Werte in den Input-Daten, Werte, die vielleicht überhaupt nicht definiert sind. Und dann auch wichtig ist der Model-Drift oder Data-Drift.

Das heißt, dass die Daten so nach und nach irgendwie in eine andere Richtung driften und sich verändern oder das Modell so nach und nach immer so ein bisschen schlechter wird. Aber irgendwann, wenn es das lange genug gemacht hat, dann ist es halt irgendwann nicht mehr gut genug und dann möchte man das ja auch mitbekommen.

Und zum Beispiel bei jedem monatlichen 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 zu stark verschlechtert haben. Und dann muss man sich einfach nochmal angucken, was los ist. Was halt eben auch nochmal zeigt, das ist halt nicht ganz fertig und dann kann man es für immer benutzen. Aber gut, das ist ja auch in der klassischen Softwareentwicklung oft so, dass das so ein bisschen unterschätzt wird, wie viel dann doch noch gemacht werden muss, obwohl es doch fertig ist.

Macht ihr dann eigene Monitoring-Tools

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

Ja, also

Redash benutzen wir in einem Projekt

ja ganz gerne und

sonst, ja, wie das, was ich

gerade dann

anbiete, die ich überlege gerade, was wir sonst

auch so haben, ja, es gibt ja normalerweise

dann Tools, die man da

benutzen kann und die man dann zum Beispiel

auch an Slack anschließen kann und kriegt dann da

Nachrichten.

Weiß ich gerade gar nicht so genau, was die

in anderen Projekten benutzen.

Doch, doch, es gibt ganz viele.

Ich versuche gerade, meinen Discord anzubinden.

Ah, okay. Also was ich empfehlen kann

für so Monitoring-Geschichten

ist Telegram, weil das halt sehr einfach

ist, da irgendwie

über die API Dinge zu verschicken.

Also Telegram kriege ich auch Nachrichten für meine Server,

falls da irgendwas passiert, was ich will, ja.

Ja, cool.

Wollte wissen.

Ist ja auch immer mal so ein spannendes Thema,

weg von US-Diensten und so.

Ja, wahrscheinlich, genau.

Das ist natürlich...

weil das Ende-Kram irgendwie an der richtigen Adresse ist.

Man soll ja streuen.

Ja, ja, genau.

Wir nehmen meistens immer so eigene Server oder sowas,

aber wenn die halt dann wechseln, ist halt auch blöd,

dann merkt man es halt sonst nicht.

Ja, dann musst du halt irgendwo anders noch Dinge haben.

Ja, man braucht irgendwie so ein Workaround, ja.

Aber ja, klar, es wird dann auch teurer.

Ein Monitoring ist jetzt so ruhig.

Was passiert denn da jetzt?

Endlich sind alle Bugs weg.

Eigentlich ist alles gut.

Hat jemand den Nameserver mit in die Tasche gesteckt

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

Der Kurzvortritt Ceratops, oder?

Ja, genau.

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

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

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

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

auch eine ganz wichtige Geschichte.

Also ich finde das immer dann schwierig, wenn das halt so

verteilte Systeme sind, die gleichzeitig irgendwie rechnen

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

Da steige ich auch nicht so genau

durch, wie man das ordentlich machen will.

Aber wenn das so

distributed ist, was halt beim Machine Learning

auch mal passieren kann, ja?

Ja, also würde ich jetzt, also aus meiner Erfahrung,

also bei mir ist das eigentlich,

also das letzte Mal, dass

ich den Fall hatte, dass

wir irgendwie sowas verteilen

mussten, dann war das wegen, weil

die Maschinen 32-Bit waren und

nicht mehr als 4 Gigabyte, wie man auf eine

Maschine kriegte. Und dann brauchte man mehrere

Maschinen. Aber danach ist das eigentlich

ehrlich gesagt, also mir nicht mehr passiert,

weil... Du hast einfach viel zu kleine

Elemente. Meine Daten sind zu klein, das kann schon sein.

Aber ich meine, man kriegt

heute so große Maschinen, also...

Ja, über die Preise haben wir uns ja gerade

unterhalten, ja.

Ja, aber wenn man CPU,

die meisten Sachen brauchen wir mal eher CPU,

dann das ist nicht so toll.

Okay.

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

Ja, wo wir gerade schon mal optimieren sind, wie ist das denn mit Performance zum Beispiel? Ich glaube, das ist noch was gewesen, wo wir sprechen wollten.

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

Also was mir da immer mal wieder auffällt, ist, dass manchmal, 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 es gibt eine Menge Sachen.

Also natürlich, ich glaube, treffen alle Sachen zu,

die generell auf Softwareentwicklung zutreffen.

Die treffen natürlich auch bei Daten zu.

Und dann kommen noch ein paar Sachen dazu,

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

Da hat man eben schon mal angeschnitten,

dass das natürlich Spark gibt,

aber es auch nicht unbedingt total schnell immer ist.

Und manchmal ist es aber auch echt ausreichend,

auf einem Sample zu arbeiten,

weil wenn ich eh schon Millionen von Zeilen habe,

dann werden die weiteren zehn Millionen von Zeilen

meistens auch nur so viel zusätzliche Informationen liefern.

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

Ich kann ja immer mal noch checken,

ob es wirklich nicht immer viel besser wird.

Das ist so was, 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 das Paket-Data-Table,

aber ich glaube, das ist einfach gar nicht mehr so interessant jetzt, wo es Pollers gibt.

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

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

Da gibt es, das wird jetzt schon ziemlich detailliert.

Ja, mit dem Paket-File, da wollten wir noch ein paar bisschen drüber reden, wie man das machen kann und auch aktivieren kann.

Ja, aber genau, wenn wir bei Performance sind, so ein ganz generelles Ding, was ich häufig sehe, also gerade auch im Zusammenhang mit irgendwie Dinge verteilen oder so.

Was ich ganz oft sehe, ist, dass Leute halt

grundsätzlich erstmal der Meinung sind, wenn man Dinge

verteilt, dann wird es halt schneller.

Ist aber

oft nicht so.

Weil ganz oft ist halt

CPU möglicherweise gar nicht das Bottleneck.

Bevor man sowas macht, wie Dinge

dann verteilen oder so, sollte man vielleicht mal gucken, wo ist

eigentlich das Bottleneck.

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,

verteilen macht das alles noch schlimmer, weil

irgendwie Netzwerk

ist halt noch viel langsamer als irgendwie

quasi lokale SSDs und

wenn man halt die Daten

in der richtigen Reihenfolge lädt sozusagen

und nicht zufällig die ganze

Zeit, wenn man sehr große Datenmengen hat, also

so groß, dass sie nicht in den Hauptschlechter passen,

wenn man die dann sozusagen richtig, also

sich jedes, alle Daten

immer nur einmal anguckt, dann kann es sein, dass

es super schnell ist, während wenn man halt

zufällig auf einem großen

Paketfile 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