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 dran gehängt und bin dann so in der Statistik-Beratung damals gelandet.

Da hieß es noch mehr Statistik.

Inzwischen würden wir natürlich sagen, wir machen Data Science oder aktuell sagt man wahrscheinlich am besten noch AI, damit halt auch wirklich klar ist, was eigentlich gemeint ist.

So erinnern sich die Begriffe ein bisschen und es ist natürlich über die Zeit auch total viel dazugekommen.

Machine Learning, was ja vor einigen Jahren eben noch nicht so da war.

Vor einigen Jahren haben wir noch ganz viel mit R gemacht.

Am Anfang inzwischen ist eigentlich fast alles in Python, bis auch so ein paar einzelne Projekte, vor allem im Forschungsbereich, da sind die Leute ein bisschen mehr mit R unterwegs.

Ja.

Und ja, ich kann gerne noch ganz kurz was über mein Unternehmen sagen.

Wir sind eine Data Science Beratung, haben also sehr viele wechselnde Projekte, sind 17 Leute, sind in Berlin, das heißt zum Hörertreffen wird es dann wahrscheinlich auch nichts für mich.

Ich glaube, dass man ein bisschen zu weit ist, um mal kurz vorbeizukommen.

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

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

Wir haben ja noch ein paar, vielleicht habt ihr noch nicht alle gehört.

Ja, da kann man dann schon noch ein bisschen länger Bahn fahren.

Ja, und aktuell bin ich witzigerweise, also ich habe erst viel Data Science gemacht, bin dann immer mehr auch in die Projektleitung gegangen.

Und da passt es dann ja auch wieder.

Mit der Psychologie.

Und jetzt bin ich aber witzigerweise so ein bisschen back to the roots, bin im Kundenprojekt drin, so Body Leasing mäßig dort mit im Team.

Und bin dann klassisch als Data Scientist im Team drin und das macht mir auch ganz großen Spaß.

Wir haben teilweise länger laufende Projekte, aber auch manchmal Einzelprojekte, die nur ein paar Monate sind.

Und das ist natürlich auch total spannend, weil man dann sehr viel Abwechslung hat und in verschiedene Themen reinkommt.

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

Ein Unternehmenspodcast, in dem ich manchmal, aber auch nicht immer zuhören bin, wo wir ganz viele Themen rund um Data Science besprechen, den Data Science Deep Dive.

Genau, das war sehr spannend.

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

Ja.

Ja, gut.

Also, was ist denn eigentlich Data Science?

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

Das ist jetzt auch irgendwie ziemlich allgemein, aber es geht darum, dass man Dinge versteht, dass man auch Dinge vorlehr sagt und dass man teilweise sogar Entscheidungen dann trifft.

Entweder noch manuell.

Oder sogar automatisiert auf Basis von Daten.

Oder anders gesagt, man will halt aus großen und oft komplexen Datensätzen Muster erkennen, die man jetzt mit bloßem Auge überhaupt nicht erkennen könnte und nur erkennt, wenn man eine Analyse macht.

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

Ja, also Statistik ist auf jeden Fall, ja, ein Teil ist ja auch so, manche sagen, ja, Statistik oder Machine Learning, das überschneidet sich aber an ganz vielen Stellen.

Ja, klar.

Ja, man sagt ja auch oft, man braucht so drei Bereiche.

Das eine ist die fachliche Expertise, also ich kenne mich zum Beispiel aus mit, ja, einfach mit dem Bereich, in dem ich gerade was mache, zum Beispiel Umweltdaten oder Verkaufsdaten, Online-Shopping, was auch immer.

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

Manche sind mehr mit Bilddaten unterwegs, mit Text, mit tabularen Daten, da bin ich vor allem unterwegs.

Und das dritte ist, dass man natürlich auch Coding-Kenntnisse braucht, also so das, was aus der Informatik kommt.

Damit man seine Analysen irgendwie programmieren kann.

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

Also, dass ich super gut coden kann, dass ich auch noch super gut in Statistik und Machine Learning bin und dann gleichzeitig noch in dem Fachbereich so lange unterwegs bin, dass ich mich da wahnsinnig gut auskenne.

Ist ja doch ziemlich viel, das schafft man vielleicht nach ein paar Jahren.

Aber deswegen sind wir auch meistens in Teams unterwegs oder wir als Beratung.

Wir sind natürlich daran gewöhnt, dass wir uns schnell neue Themen reinfinden.

Trotzdem brauchen wir eine neue.

Wir haben in unserem neuen Projekt natürlich ganz viel Kommunikation mit unseren KundInnen, die uns auch ihre Fachexpertise dann mitgeben, weil wir dann vor allem die methodischen Kenntnisse und das Coding mitbringen.

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

Gemeinsame Sprache zu finden.

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

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

Unterschiedlich.

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

Ja, sehr, sehr unterschiedlich.

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

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

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

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

Ich bin aber mehr im Data Science-Bereich unterwegs.

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

Das war früher irgendwie kaum, weil früher hatten viele Unternehmen auch selbst keine Data Science Abteilung.

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

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

Die überhaupt von der Kultur her in Richtung datenbasiertes Unternehmen gehen.

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

Wenn du jetzt Methoden angesprochen hast, was würdest du denn sagen, wie ist das denn in der Praxis?

Habt ihr da viel mit sophisticated Methoden noch zu tun, die ihr jetzt aus der Uni oder so noch kennt?

Oder ist das meistens dann schon einfaches Zeugs, weil einfach die Datenprobleme andere sind?

Als jetzt gute Methoden auszusuchen.

Es ist tatsächlich oft ziemlich anspruchsvoll.

Ich glaube, das sind aber auch so die Projekte, die wir uns rauspicken oder für die wir dann auch weiter empfohlen werden.

Wir haben zum Beispiel was im Sportwettenbereich und da kann man sich ja vorstellen, wenn man mal überlegt, wie sag ich eigentlich vorher, wie viele Tore von diesen beiden Mannschaften in diesem Spiel fallen und wie viel in der ersten und zweiten Halbzeit und so.

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

Manchmal sind die Sachen halt noch ein bisschen sinnvoll.

Aber oft wird es dann doch irgendwie schon ein bisschen komplexer.

Wir sind aber auch tatsächlich darauf spezialisiert.

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

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

Ja, wie kommt man denn eigentlich zur Data Science?

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

Ich habe vor allem auch Wirtschaft.

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

Es hat bei mir noch ein bisschen Umweg gebraucht.

Aber ich glaube, auch da hätte man direkt den Weg Richtung Data Science finden können.

Ja, auf jeden Fall.

Also das ist auch so ein typischer Hintergrund.

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

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

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

in die Machine Learning Welt verirren.

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

Das klingt irgendwie witzig.

Wow, das hat er jetzt auch.

Nur Leute, also der ist jetzt schon, ich glaube schon drei Jahre bei uns, aber ja, vorher hatten wir nur Leute mit einem anderen Hintergrund.

Ich glaube, es ist aber ein bisschen schwieriger geworden, quer einzusteigen, weil es inzwischen ja sehr viele tatsächlich Data Science Studiengänge gibt

oder Informatik mit ganz starkem Machine Learning Schwerpunkt.

Und wenn man dann sagt, ja, ich habe da, also ich habe BWL studiert und ich finde Statistik gut und habe ein paar Kurse gemacht,

dann konkurriert man halt inzwischen mit Leuten, die da leider dann schon viel, viel mehr mitbringen.

Also ich glaube, das ist schon schwieriger geworden.

Der BWL ist ja auch nicht VWL zum Beispiel.

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

Ja, also Ökonometrie kann man schon tief reingehen, glaube ich da.

Es ist halt die Frage, wie gut man dann in das Programmieren reinkommt und in das, was man da an Methoden noch so mitbringt.

Ja, aber das ist auf jeden Fall eine interessante Geschichte.

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

halt auch irgendwie immer wieder gesehen, dass halt oft die Leute, also ich weiß nicht, wie das bei euch ist,

weil normalerweise Softwareentwicklungsgeschichten, die ich so mache, da habe ich dann halt eben mit Abteilungen zu tun,

die halt irgendwie Softwareentwicklung machen oder so.

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

Und das sind andere Leute, das sind ein bisschen so, die sind so ähnlich, also das sind oft irgendwie Leute,

die dann da probibliert haben oder so, dann da probibliert haben, genau, ganz oft aus der Ecke eher.

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

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

Und die haben auch meistens oft so ein bisschen so, ja, Produkte entwickeln oder so, ist jetzt eigentlich nicht so unser Ding.

Genau, und das ist irgendwie eine etwas andere Welt.

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

Und da wolltest du ja auch nochmal was zu sagen.

Wie du das so findest mit den Softwareentwicklern zusammenzuarbeiten.

Aber vielleicht noch erst dazu.

Ich glaube, wir sind da irgendwie so dazwischen, weil wir eben ja schon Datenprodukte bauen wollen.

Also es gibt auch mal ein POC oder irgendwie so eine einzelne Analyse, wo wir dann sagen,

so und das sind die Ergebnisse und hier sind die Zusammenhänge.

Aber normalerweise sind das dann schon, also schreiben wir auch Software,

aber wir schreiben Software, die was mit Daten macht.

Also dann sind zwei Sachen zusammen und BI-Abteilungen sind, glaube ich, auch nochmal,

aber mehr, ja, die sind halt besonders gut darin, dann auch ganz viel visuell zu analysieren

und fokussieren sich sehr stark darauf.

Und ich glaube, die sind auch nochmal so ein bisschen, vielleicht noch ein bisschen weniger nerdig,

hätte ich jetzt so gedacht, so Mitte.

Das klingt, als wäre es kein Kompliment.

Ich weiß nicht, ich dachte eben, ne.

Ohne Wertung zu sagen.

Oh, ja.

Ja, aber was du eben gefragt hättest, so,

das ist auch jetzt ganz spannend, ich bin jetzt im Team, wo eigentlich relativ klar zugeordnet ist,

wer ist Data Scientist und wer ist Software Engineer.

Und natürlich arbeiten wir alle an dem Code, aber es gibt irgendwie so ein paar Klischees

oder so Dinge, die man vielleicht beobachtet, wenn jemand, der vor allem einen Softwareentwicklungshintergrund hat,

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

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

tatsächlich sollte man ja refactoren und wir haben auch viel refactored,

aber da haben wir einen Teil wirklich neu geschrieben.

Und das, also, am Coding-Stil hat man schon gesehen, dass der einfach gar nicht wusste,

dass man mit Datensätzen Sachen machen kann.

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

weil er halt einfach diese ganzen Sachen nicht kannte, die man mit Datensätzen machen kann,

vor allem mit Pandas.

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

dass jemand, der nicht viel mit Daten gearbeitet hat,

muss halt so nimmt, wie sie sind und da irgendwie ganz unkritisch ist

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

Und manchmal ist ja vielleicht der Code gar nicht falsch,

aber es ist irgendwo ein Denkfehler drin.

Also der Code macht, was er soll, nur das, was er soll, ist halt vielleicht gar nicht so korrekt.

Oder man hat ein Missverständnis zu den Daten, man hat irgendeine Annahme,

aber in Wirklichkeit ist das ein bisschen anders.

Und das ist was, was dann, glaube ich, schwer fällt.

Also ich glaube, das fällt einem als Data Scientist auch schon,

manchmal schwer, so richtig dieses Business Understanding aufzubauen.

Aber ja, wenn man so reine Softwareentwicklung macht,

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

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

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

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

Also es ist uns sehr wichtig und wenn jemand halt noch nicht so gut programmieren kann

und aus dem Studium kommt, weil es einsteigt, dann ist es das,

was die Person dann lernt, so wie ich damals.

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

weil manche haben dann eher einen Schwerpunkt auf so Datenanalysen,

sind vielen Notebooks unterwegs und wenn sie dann fertig sind,

dann wird das Notebook in irgendeinen Job eingebunden

und das ist dann die Automatisierung und das kann manchmal funktionieren,

aber oft ist es auch ziemlich wackelig.

Ja, interessant.

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

Also wenn ich das mal sehe,

was so Data Scientists schreiben,

dann steige ich mir die Hände über den Kopf.

Es gibt natürlich Unterschiede,

aber das ist immer so im Vergleich eher anders,

als ich das machen würde wahrscheinlich.

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

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

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

warum soll man denn eine Funktion schreiben?

Man kann es ja Zeit für Zeit ausführen

und die Funktion braucht man ja nur, wenn man zweimal dasselbe macht.

So ist dann, glaube ich, manchmal die Denkweise,

wenn man eben,

wenn man einfach mehr aus der Analyse kommt

und da so quer einsteigt.

Ich finde das immer einfach manchmal,

wenn Leute schon promoviert haben

und das ist,

die haben total krasse Sachen gemacht,

aber können dann halt auch keinen guten Code schreiben,

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

Ja, da ist auch oft,

also gerade Physiker,

die sind da ja oft eher so verdorben.

Die haben dann irgendwie Vortragen geschrieben oder sowas.

Oder C++,

das ist auch nicht viel besser.

Und dann, ja genau,

bringen sie da so schlechte Gewohnheiten mit.

Das ist natürlich oft,

irgendwie so ein bisschen,

ja, aber,

ja, ja.

Aber das ist auch so ein bisschen,

man lernt das ja auch nirgendwo,

außer wenn man jetzt irgendwie quasi bei einer Firma anfängt,

die das halt auch irgendwie täglich macht oder so.

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

Und ja, also es ist irgendwie,

ja, es ist irgendwie,

also dieses Handwerkszeug ist ein Problem oft.

Das denke ich auch.

Was nervt dich denn an Leuten,

die Softwareentwicklung gemacht haben,

die jetzt Data Scientists sind?

Ja, das ist auch interessant, ja.

Also, ja, also die Sachen,

die ich gerade genannt habe,

also es ist oft so,

die Ergebnisse so unkritisch beurteilt werden,

dass man eigentlich nur guckt,

ob der Code richtig läuft

und das macht,

was man implementieren wollte.

Und dass eben,

ja, man dann nicht unbedingt erkennt,

dass die Ergebnisse eigentlich unplausibel sind.

Zum Beispiel,

dass das Modell viel zu gut ist

und da muss irgendwo was falsch sein.

Die Kirchturmspitze ist 245 Meter im Minus.

Bitte?

Du könntest erst mal die Kirchturmspitze ausrechnen,

dass die Höhe dann 245 Minus ist.

Und wenn man das dann einfach so übernimmt

und daran glaubt.

Ja, genau.

Also, das ist natürlich ein gutes Beispiel.

Manchmal habe ich auch den Eindruck,

dass dann wiederum,

wenn man sehr,

sehr stolz auf seine Software-Entwicklung-Skills ist,

dass dann auch unnötig komplizierte Patterns

auf irgendwelche Sachen geworfen werden

und das dann auch wieder so pragmatisch ist

und sehr schwer wartbar.

Ja, klar,

weil die Leute,

die das dann letztlich irgendwie ja benutzen müssen,

müssen das ja auch lesen und verstehen können und so.

Und wenn man dann irgendwas

in einem Elfenbeinturm baut,

dann, ja,

war das vielleicht auch einfach am Ziel vorbei.

Wenn man auch neue Pattern gelernt hat,

muss man die auch erst mal,

überall anwenden, ja.

Ja, klar,

das sollte ich auch machen, ja.

Ja, aber grundsätzlich machen das eigentlich total Spaß,

mit Software-Entwicklern zusammenzuarbeiten.

Du hast gesagt,

er visualisiert irgendwie Sachen zwar nicht so oft,

nicht so gerne,

aber er macht das.

Wie denn?

Also, ich kenne irgendwie so eine coole Seite,

die wollte ich irgendwie nochmals hin,

das ist irgendwie datatowiz.com oder sowas.

Die benutze ich immer,

wenn ich nicht weiß.

Ich kann nicht sagen,

dass ich so gerne.

Also,

er macht es durch die ganze Zeit,

aber es ist an verschiedenen Stellen eigentlich,

total wichtig,

also zuerst mal,

wenn man die Daten reinbekommt,

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

aber ich kann da,

da wollen wir zwar noch darüber sprechen,

da kann er gerne mal vorgreifen,

also wenn die Daten reinkommen

und man gucken will,

ob die sinnvoll sind,

wenn man die Daten kennenlernen will,

Zusammenhänge prüfen und so,

dann ist natürlich Visualisierung einfach das Allerbeste,

klar,

ist auch ganz nett,

so Mittelwerte und Ausgleichsmaßnahmen

und Minimum zu sich anzugucken,

zum Beispiel,

ob der kleinste Kirchturm auch wirklich größer als 0 Meter ist,

aber es macht natürlich auch total Sinn,

sich da die Verteilung mal zu gucken,

Plotten und Zusammenhänge

und das sind auch die Sachen,

die wir dann oft mit unseren Kunden wiederum anschauen

und sagen,

guck mal hier,

die Verteilung,

macht die Sinn

und merken dann vielleicht,

dass da irgendwas in den Daten unsauber ist,

was halt oft vorkommt,

womit man dann aber irgendwie umgehen muss

und natürlich auch dann später,

wenn wir zum Beispiel ein Modell gebaut haben

und die Ergebnisse untersuchen wollen,

wie sind unsere Prognosen verteilt,

welche Zusammenhänge hat das Modell gefunden,

auch da ist dann natürlich die Visualisierung total wichtig

und sinnvoll

oder das einfach,

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

als wenn man das irgendwie alles versucht,

in Tabellen zu vermitteln.

Wie visualisiert ihr denn am liebsten?

Ja, es ist irgendwie ganz witzig,

weil ich in Python noch nie so richtig,

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

aber wir haben früher sehr viel,

da waren auch weniger mit Dashboards und so weiter,

da war es oft noch so,

dass wir so einen Datendump bekommen haben

und hatten damit dann was gemacht

und da waren wir noch in R unterwegs

und haben für ggplot2,

ggpl benutzt

und inzwischen sind wir dann meistens

in einem Dashboard-System unterwegs,

das halt beim Kunden einfach genutzt wird,

sodass wir dann in dem Tool,

was der benutzt, das implementieren,

weil das jetzt in AWS oder Azure

oder was auch immer die nutzen

und wir machen dann da das,

was da in dem System gewünscht ist.

Wir haben auch ein paar Dashboards mal gebaut

in,

wie heißt das denn jetzt noch?

Ich habe den Namen leider vergessen.

Notley Dash,

oder?

Das ist Redash, genau.

Redash ist ein Open-Source-Tool.

Das benutzen wir dann auch ganz gerne.

Da kann man dann auch gerade praktischerweise

noch Alarme dazu definieren,

um seine Daten zu überwachen.

Das nutzen wir auch sehr gerne.

Okay.

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

Ihr habt jetzt irgendwie Daten,

ich glaube, du wolltest auch noch mal drauf eingehen.

Ja, gerne.

Und so einen Auftrag und dann?

Also klar, manchmal steigen wir auch mittendrin ein,

aber ich fange jetzt trotzdem mal vorne an.

Oft sind wir auch vorne dabei.

Das ist jetzt so ein bisschen

vor allem aus meiner Sicht als Beraterin.

Das fühlt sich natürlich ein bisschen anders an,

wenn man im Unternehmen als Data Science

die ganze Zeit ist.

Aber für mich als Beraterin sind das so,

ja, eigentlich so sieben Schritte.

Erstmal das Problemverständnis,

dann die Daten einzusammeln und zu verstehen,

dann Datenaufbereitung,

dann kommt die Modellierung.

Man merkt, das ist nur ein Schritt,

diese Modellierung.

Oft denkt man, das ist zu viel,

aber es ist nur ein kleiner Schritt.

Dann die Evaluation des Modells

und dann gehört eigentlich dazu ja auch

noch eine Automatisierung und Monitoring

und Wartung.

Wobei die letzten zwei Schritte

natürlich vom Aufwand her

nochmal einen sehr, sehr großen Teil einnehmen.

Das ist auch jetzt angelehnt

an den CRISP-DM, wenn das was sagt.

Das ist der Cross-Industry Stand-Up Process

for Data Mining.

Data Mining klingt so ein bisschen angestaubt,

der Begriff,

aber man könnte es halt einfach

Datenprojekte nennen.

Und ja, am Anfang,

es ist bei uns dann tatsächlich auch so,

dass KundInnen zu uns kommen

und schon was haben,

was sie haben,

also sagt schon das, was sie brauchen.

Das geht dann auch in die richtige Richtung.

Manchmal macht es aber trotzdem Sinn,

sich das nochmal genauer anzuschauen

und zu verstehen, warum sie das brauchen

und was sie wirklich brauchen.

Und vielleicht ist es dann doch so ein bisschen anders.

Und ich meine,

zu diesem Thema kann man ganze Workshops,

mehrtägige Workshops machen.

Es gibt ganze Unternehmen, die nichts anderes machen,

als Use Cases zu identifizieren und zu prüfen.

Das können wir auch ein Stück weit mitmachen,

aber das ist nicht unser Schwerpunkt.

Also ist das meistens dann schon

eher so, dass da schon Ideen da sind.

Wir aber das auch alles nochmal so ein bisschen challengen

und einen Kick-Off haben,

wo wir mit den Kunden sprechen,

um das Geschäftsmodell zu verstehen,

um genau zu verstehen,

wer das eigentlich nutzen wird,

was die genau machen wollen.

Es ist natürlich total wichtig,

dass wir eben prüfen,

was brauchen die wirklich genau

und brauchen die zum Beispiel vielleicht was in Echtzeit.

Dann ist es natürlich ganz anders,

als wenn das ausreicht,

dass man jeden Morgen einmal aktuelle Werte berechnet.

Und wer sitzt da

und wo benutzen wir es genauer?

Ist es irgendwo an einem Counter

oder ist es am Telefon

oder ist es irgendwo,

wo es kein gutes Internet gibt und so.

Und all das muss man natürlich wissen,

um auch rauszufinden, was die brauchen.

Und dann ist der nächste Schritt,

sich zu überlegen, wie können wir das machen

und haben wir eigentlich auch die passenden Daten.

Und dann haben wir vielleicht die notwendigen Daten

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

Man kann trotzdem anfangen.

Ja, das ist der erste Schritt

und den sollte man sich unterschätzen.

Braucht ihr die dann auch?

Also baut ihr irgendwo neue Sensoren ein oder sowas

und kümmert euch darum,

dass sie in irgendwelchen Datenbanken landen,

die ihr dann zur Auswertung mit benutzt

oder geht ihr davon aus,

dass das Business alles mit besorgt?

Es ist normalerweise so,

dass die Daten schon da sind

und dadurch, dass wir ja auch eher komplexe Fragestellungen beantworten,

sind das in der Regel halt auch Kunden,

die schon mit den Daten irgendwas gemacht haben.

Natürlich kennen die nicht jede Datenquelle von vorn bis hinten auswendig

und man findet immer noch Überraschungen.

Aber das ist dann normalerweise

so, dass sie sagen,

wir wollen hier dieses superkomplexe Modell,

aber wir haben noch gar keine Daten,

wir müssen die erstmal sammeln.

Normalerweise sind die da schon

relativ weit oben auf der Datenreifeskala

und selbst wenn nicht,

sind die Daten meistens schon da,

weil ganz viele Daten ja einfach

automatisch mitgesammelt werden.

Zum Beispiel im Online-Shop

hat man natürlich jede Menge Daten

über vergangene Bestellungen und so weiter.

Also die Daten sind eigentlich immer schon da.

Die Frage ist nur,

sind die Daten da, die man braucht

und wenn sie nicht da sind,

dann ist das erstmal noch ein weiter Weg normalerweise,

weil vielleicht ist es nicht mehr ein richtiges Ding,

da ist ein weiterer Warehouse da

oder man kann die nochmal zusammenführen.

Das ist oft dann,

dann ist es noch ein weiterer Weg,

bis wir da tatsächlich loslegen können.

Wie würdest du denn

so ein neues Unternehmen strukturieren,

wenn du darauf achten würdest,

dass du ordentliche Daten irgendwann brauchst?

Würdest du direkt hingehen

und das alles vom Scratch implementieren

mit dem, was du am besten hältst

oder würdest du das erstmal egal,

das wachsen lassen

und dann irgendwie zusammenflanschen?

Also ich glaube,

das kommt darauf an,

wie sehr das Geschäftsmodell von Daten abhängt.

Also wenn das ein Unternehmen ist,

das irgendwelche Gegenstände produziert,

dann denke ich,

ist es nicht ganz so wichtig,

dass man ganz viele Daten sammelt.

Dann kann man sich erstmal darauf konzentrieren

und dann nach und nach einsteigen.

Aber es gibt ja auch Geschäftsmodelle,

die eigentlich nur so gut funktionieren,

weil mit Daten gearbeitet wird

und dann muss das wahrscheinlich von Anfang an

auch berücksichtigt werden.

Also ich habe ja noch nie ein Unternehmen gegründet.

Ich bin ja geschickt erst eingestiegen,

als das Unternehmen schon da war.

Aber ich vermute,

wenn man sowas wie Amazon oder so,

also da wurde ja von Anfang an wahrscheinlich mitgedacht,

was man da mit Daten machen kann

oder zumindest relativ früh dann.

Und was für Technologien benutzt ihr so

mit Python für diese einzelnen Schritte?

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

Von der Datenaufbereitung über die Modellierung,

da kommt dann auch sowas wie Scikit-Learn dazu

oder TensorFlow, Keras, PyTrips,

eigentlich so die Klassiker.

Pandas ist ein interessantes Thema,

weil Pandas,

also wer schon mal mit Pandas im Kurs ist,

man Daten gearbeitet hat,

denkt sich jetzt um Himmels Willen,

ich will es nicht mehr hören,

weil Pandas halt sehr, sehr viel Arbeitsspeicher braucht,

wenn die Datensätze größer sind.

Es ist aber natürlich zu Prototypen

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

weil es ganz, ganz viel kann

und weil man auch ganz viel im Netz findet.

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

dann hat man natürlich das Arbeitsspeicherproblem

und dann ist der Klassiker natürlich

auf Spark, PySpark umzusteigen,

was auch jetzt in letzter Zeit

ganz gut funktioniert.

Also das ist natürlich toll,

weil es ganz verteilt ist,

wobei es nicht unbedingt schnell ist,

aber es kann halt eben

mit großen Datensätzen umgehen

und man hat erstmal

dieses Arbeitsspeicherproblem gelöst,

was man eben mit Pandas

irgendwann eigentlich gar nicht mehr lösen kann.

Und dann gibt es jetzt natürlich noch so halt...

Aber ich meine,

die Erfahrung, die ich oft mache,

ist, dass man die,

bei vielen so kategorialen Variablen oder so,

die kann man dann halt auf irgendwie

einen kleineren Datentyp

irgendwie runter komprimieren

oder halt oft hat man dann

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

Flex hat, irgendwie ja oder nein

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

sehr viel weniger, als wenn man da irgendwie ein volles

Integer oder so für nimmt.

Oft hilft das

dann schon, aber ja, stimmt.

Aber manchmal, wenn man die Daten einliest, dann

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

spezifizieren am Anfang und dann sind die

einfach groß.

Oder auch selbst wenn, also ich meine,

so mehrere Jahre stündliche Verkaufsdaten

von ganz vielen Artikeln aus ganz vielen Filialen

aus mehreren Ländern.

Dann, ja,

dann wird es irgendwie schwierig

und dann ist das Verteilte schon gut.

Und dann gibt es halt noch Polars,

womit man dann auch

oft schneller ist und halt auch weniger

Arbeitsspeicher braucht.

Also wenn du das nicht kennst, Polars, das ist ein Rust

nachgeschrieben mit der gleichen API, so ein bisschen wie Pandas.

Ja, es ist, ne, es hat

sehr viel saubere, also kleinere,

es hat weniger Funktionen, aber es ist halt

auch ein bisschen konsistenter, weil

Pandas ist halt auch irgendwie sehr stark

so historisch gewachsen

und man wusste noch nie genau, wo man hin will

und dann teilweise inkonsistent und

ja,

ja, Pandas ist halt, ja.

Wie das halt so ist. Genau, wie das halt so ist.

Ich habe noch gar nicht so viel mit Polars

gearbeitet. Ich weiß gar nicht, ob die

eigentlich schon das Ziel haben, da die

meisten Funktionen aus Pandas

auch zu implementieren oder ob die vielleicht sogar

sagen, es soll schlanker bleiben, weiß ich gar nicht.

Ich meine, also sie sind absichtlich,

wollen sie nicht komplett irgendwie alles

machen, was Pandas halt kann, sondern

ja, quasi bei den

Basisgeschichten so schnell sein, dass man

halt daraus alles bauen kann, aber

dann halt nicht so eine Spezialsyntax dafür hat.

Benutzt ihr auch dann

zwischendurch noch Pure NumPy oder?

Ja, manchmal so für kleine Sachen,

wo es gerade Sinn macht.

Oft

sind ja, ist man mit Datensätzen unterwegs

und dann passiert es halt meistens

in Pandas.

Vielleicht hast du eben gesagt, man muss

erstmal wissen, was ein Datensatz ist, bevor man jetzt drüber

redet. Du meinst jetzt irgendwie, du hast eine Maske auf,

mit der du guckst oder

was?

Was ist ein Datensatz in Pandas?

Ist das jetzt eine Wissensfrage?

Ja doch, du müsst ja vielleicht schon erklären,

wie das funktioniert.

Ja, um die Daten

anzugucken, würde ich,

na gut, es ist irgendwie schön, wenn man einmal

so ein bisschen den Head anzeigt,

also die ersten paar Zeilen und sieht, was da eigentlich so

grundsätzlich, was das für Spalten sind, welche Namen die

haben und welche Zahlen da so

ungefähr drinstehen und dann würde ich aber

relativ schnell in eine deskriptive Analyse

gehen und mir beispielsweise von jeder Spalte

dann Summary Statistics, also

Minimum, Maximum, Mittelwert,

Median, vielleicht Quantile

anschauen oder eben auch Verteilungen

plotten, sodass man das

sieht oder Kategorien anzeigen, je nachdem, was das so ist.

Sonst,

ja, die ganze Tabelle,

also man hat natürlich eine Tabelle als Pandas Data Frame,

die könnte man theoretisch ja auch irgendwie

als CSV speichern oder als Excel und da

angucken. Das ist auch ganz praktisch,

um sich die mal anzugucken, wenn die Daten klein genug

sind. Manchmal ist es sogar wirklich ganz

nett, um mal einfache Analysen zu machen,

zum Ausprobieren, um gespürt zu bekommen,

aber es ist dann eher so ein manueller

Schritt und um wirklich

Insights dann zu haben und die Daten zu

verstehen, ja, muss man dann, wenn

der Datensatz groß genug ist, natürlich

in die Summary Statistics

gehen. Und es ist auch oft,

also selbst wenn man jetzt nach

dieser ersten Datenanalyse aufhören

würde, ist es oft an sich schon

ganz interessant und

oft haben unsere

KundInnen ja genau diese Analyse

auch noch nicht gemacht und lernen dabei auch noch was Neues.

Einmal hatten wir aber sogar

auf den Fall, dass wir, ja,

dass sie dann gemerkt haben, dass da irgendwo viel

an Data Warehouse ist und da war irgendwie so ein riesiger

Strukturbruch, der da eigentlich gar nicht sein sollte

und dann haben sie sich erstmal nochmal ein paar Monate zurückgezogen

und haben das alles repariert und

danach konnten wir das Projekt dann tatsächlich machen,

aber das wussten sie vorher nicht und haben es dann

gesehen durch unsere Datenvalidierung,

dass da irgendwo ein Problem ist beim Zusammenführen.

Ja, spannend.

Also manchmal sagen sie mir das. Ich habe einmal den Fall

gehabt, dann waren die ganze Zeit irgendwelche

so Irregularitäten irgendwie,

in so einem Datenflur, die da gar nicht hingehörten.

Man hat irgendwie was bewundert, was ist denn das?

Irgendwann ist jemand auf die Decke gekommen, ist dann zum Förderbank gegangen,

hat in die Decke geguckt und da war

oben ein Fenster auf und dann war dann die

Temperatur immer anders, weil dann das Fenster

aufgelassen worden ist und so. Das war spannend, ja.

Cool ist natürlich auch, wenn man dann sieht, ah ja,

hier gehen die Sales hoch, da war unsere riesige Werbekampagne

und das macht alles Sinn und das ist natürlich

auch schön, wenn es einfach funktioniert und man

das in den Daten sieht.

Ja, auf jeden Fall.

Ah, was mich noch interessieren würde,

wenn ihr tatsächlich so

Produkte baut

mit Modellen

drin und so und die irgendwie vielleicht

Echtzeit irgendwas, wie begleut ihr eigentlich eure

Modelle dann

oder habt ihr da Präferenzen oder

weil das ist immer so ein bisschen, das

machen Leute unterschiedlich und ich weiß nicht,

ob es da jetzt irgendwie so ein Standard

Ding gibt, was man machen kann, aber

ja, das ist auf jeden Fall immer irgendwie nicht so ganz

einfach gewesen.

Also grundsätzlich gilt da natürlich,

wir machen das, was die Kunden wollen.

Ja, aber tatsächlich, wir sind ja dann

oft eine Infrastruktur von den Kunden unterwegs,

aber nicht immer, weil manche, zum Beispiel hatten wir

ein Projekt, da darf ich zum Glück auch

drüber reden, darf man ja nicht bei jedem Kunden, das war für die

Berliner Senatsverwaltung, eine Luftschadstoffprognose,

also die läuft auch noch, aber das

machen wir jetzt nur noch Wartung, das ist soweit beschlossen

und die haben

keine Vorgaben gemacht zur Infrastruktur,

die haben halt kein ABS oder Azure und da konnten

wir es halt so machen, wie wir wollten und

ich gucke mir gerade nebenbei in unseren

Blogartikel rein dazu,

weil da

kann ich mich alles nochmal wieder nachgucken,

wie wir es gemacht haben.

Da haben wir,

konnten wir ganz frei entscheiden, was wir

haben wollen und haben

dann mit

Kubernetes gearbeitet,

das ist auch alles schön selbst aufgesetzt

und da laufen dann automatisierte Jobs

drin und

wir haben, na gut,

das hat jetzt weniger mit Deployment zu tun, aber wir haben da

dann in der Grunde eine Clickhouse-Datenbank,

die ist ganz cool für große Datenmengen

und haben

dann Docker-Container, in denen

unsere Prozesse dann laufen,

da haben wir auch Relash benutzt, wie ich erwähnt habe,

das benutzen wir dann auch für die Alerts,

um zu gucken, sind alle Input-Daten da,

sind alle Prognosen so erstellt worden, wie wir wollen,

sind so viele Prognosen in der Tabelle,

wie wir erwarten würden und so weiter

und in dem Projekt ist tatsächlich

nur, im Hintern haben wir Relash

für die Visualisierung benutzt, nach außen

gehen die Daten tatsächlich,

unsere Prognosen gehen einfach über eine Rest-API

raus und werden dann

im Tool visualisiert, dass diese Nats-Verweigerungen

schon hatte oder auch

die API ist frei verfügbar, könnte auch jeder abrufen,

haben auch schon ein paar andere dann mal gemacht.

Genau, mit Kubernetes ist es natürlich immer ganz

schön, ansonsten

bei einigen Kunden läuft dann viel

mit den Diensten von AWS,

jetzt bei dem Kunden, wo ich bin,

sind wir im Azure-Universum,

wobei ich da mit dem

Deployment nichts zu tun habe, weil

das machen nachher andere, deshalb bin ich

auch immer nur so am Rande natürlich dabei,

kann irgendwie in die Kubernetes-Codes mal reingucken,

aber ich kann,

kann das nicht aufsetzen oder

macht dann nicht die Deployments.

Ja, was mich da mal, oder das

Problem, das ich da mal hatte, ist halt,

dass wenn jetzt Leute quasi

in Notebooks irgendwas modellieren oder so, wie kriegen

sie denn dann, wenn sie jetzt rauskriegen, ah,

wenn ich dieses Modell so parametrisiere

oder so, oder ja, man hat

dann normalerweise eine ganze Pipeline von

Daten kommen rein, dann werden sie irgendwie transformiert

und dann hat man halt hinterher

irgendwie Predictions oder so.

Wie kriege ich das Ding denn jetzt

quasi in

das Produktionssystem integriert

und das, was wir dann

gemacht hatten, war halt

quasi aus dem Notebook direkt

sozusagen ein

Konterpaket zu bauen, das hochzuladen,

in Django Filefield zu speichern

und dann auch über eine JSON-AP dann die Ergebnisse wieder

zurückzugeben, aber das

fühlte sich so ein bisschen falsch an oder so

auf jeden Fall nach, gibt es da nicht irgendeine

einfache Möglichkeit, wie man das machen kann?

Ich weiß nicht, ob es einfacher ist, aber

wir sind auch ganz wenig eigentlich

mal in Jupyter-Notebooks unterwegs,

sondern

ja, entweder, wenn wir was schnell visualisieren

wollen, geht das tatsächlich ja mit so einem Tool wie

Redash auch schneller, als wenn man dann anfängt,

mal Plotlip-Code

zu schreiben,

dann das Clicky-Bunty manchmal gar nicht

so blöd und schlecht, wie es klingt

und dann, wenn

wir dann die Code-Free-Modellierung haben,

dann ist es halt wirklich,

das ist ein Python-Paket,

wir haben das dann,

automatisieren das dann meistens

so, dass jedes Mal beim Push in den

Main-Branch,

wenn die, zum Beispiel, wenn die Versionssumme sich geändert hat,

wird das dann, wie bei Jenkins,

wird ein Job getriggert, der dann

das Paket baut und in unser Repository

hochlädt, das dann

normalerweise nur intern verfügbar ist und

dann können wir, ob das dann

automatisch deployed wird oder wir das irgendwie manuell machen,

können wir uns dann halt überlegen.

Ja, aber dann brauchen wir einfach,

ja, aber dann brauchen ja die

Leute, die quasi modellieren, Zugriff

auf das Produktionssystem

quasi oder können halt,

die müssen den Code verändern, die müssen

committen können.

Ja, also die committen von

morgens bis abends.

Also das ist tatsächlich

bei uns überhaupt nicht so, dass da irgendwie jemand

sitzt, der nur in einem Notebook prototypt.

Gar nicht. Also

wenn das Projekt losgeht, dann

muss man als erstes ein Repo anlegen, weil sonst

kann man ja gar nichts machen.

Ja.

Und vielleicht startet man dann irgendwie mit ein paar

Skripten, die dann später ordentlich

in ein Paket überführt werden und in

Funktionen und Klassen verpackt. Das kann

schon sein, aber grundsätzlich

ja, ist es halt

eine Software und sonst

auch oft in größeren Projekten mehrere Pakete.

Zum Beispiel in dem

Projekt für die Senatsverwaltung sind das dann,

wir haben da sehr viele verschiedene Datenquellen, zum Beispiel

Verkehrsdaten, Wetterdaten und so

und dann haben wir für jede Datenquelle ein

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

einzulegen und zu formatieren, die Datenbank

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

dann kommt irgendwann das nächste Paket,

das liest sich die Daten dann und macht dann die

Modellierung. Und dann gibt es nochmal ein Paket,

das halt irgendwelche Daten

weiter aufbereitet und dann gibt es ein Paket mit der

API. Und das, also wenn

ein Modell daraus gebaut habt, irgendwie mit

Torch oder sowas, was macht ihr dann?

Wo legt ihr das dann hin?

Ja, wenn das dann in dem Fall

tatsächlich,

also tatsächlich

im Kundenprojekt benutzen

wir MLflow und ich weiß

nicht, ob, also ich hatte das vorher

tatsächlich noch nicht benutzt, wo wir die

Objekte dann abgelegt,

ich glaube,

es gibt, das ist ganz witzig,

ja, es gibt tatsächlich, das war jetzt

ein Projekt mit XGBoost, weiß ich nur, da haben

wir, kann man die Projekte tatsächlich

in Form eines Strings

speichern und da haben wir die in der Datenbank

gespeichert.

Das funktioniert ganz gut, man kann aber

natürlich auch das Modellobjekt irgendwo

in

Modellrepository dann ablegen.

Also eigenes Modellrepo mit

Branches oder irgendwie Tags oder

sowas hier. Ja, oder

ähm,

ja, irgendwelche Tags muss man natürlich

schon haben, damit man die dann nachher wieder identifizieren kann.

Ja. Also gut, wenn

jetzt die Modellierung total schnell geht,

dann kann man natürlich auch das Modell einmal im Monat

neu berechnen, oder nee, dann

einmal im Tag neu berechnen, sofort die Prognosen machen

und das Modellobjekt überhaupt nicht speichern, aber das

ist, glaube ich, eher so ein seltener Fall. Normalerweise

muss man das ja schon speichern.

Wiederverwenden.

Also, wir können uns auch gerne

nochmal an dem Ablauf ein bisschen

weiter entlanghangeln. Ja, gerne.

Weil wir jetzt schon vorgegriffen haben,

also,

wenn wir das Problem

verstanden haben, die Daten verstanden haben und die

sehen soweit gut aus, dass wir und

unser Kunde gemeinsam sagen, okay, damit können wir jetzt wirklich

starten, da ist kein Problem drin,

dann passiert natürlich erstmal

ganz viel Datenaufbereitung und Bereinigung.

Oft muss man verschiedene Datensätze

zusammenführen. Da haben wir dann natürlich

vorher schon geprüft, ob es auch eine gemeinsame

ID gibt, um die zusammenzuführen, sonst wird's

schwierig. Oft muss man

auch Sachen aggregieren, zum Beispiel hat man

vielleicht einzelne Zeilen

für jedes Produkt, das gekauft wurde,

von einem Kunden. Wir wollen aber eigentlich

nur eine Zeile pro Kunde, dann muss man

sich halt irgendwas überlegen, wie man das

dann voll aufaggregieren kann. Manchmal

macht man Transformationen oder berechnet

eine neue Spalte aus

anderen Spalten. Also, das

ist das, was man immer als Feature Engineering

kennt. Wir bauen also Features,

die ja einfach sinnvolle Inhalte

haben, mit denen das Modell dann später

gut umgehen kann.

Macht ihr das dann immer live in Pandas oder schreibt ihr das auch

in eine Datenbank rein?

Es kommt darauf an, aber meistens haben

wir dann schon eigentlich ein separates

Modul, das die Features berechnet

und irgendwo hinschreibt, weil das meistens dann

einfach schöner ist,

das zu modulisieren, weil es sonst

ein bisschen zu viel wird.

Was ist da eure Datenbank für?

Ich überlege gerade, wir waren

früher viel auf MariaDB unterwegs,

jetzt sind wir

viel in Clickhouse, also Clickhouse

teilweise verhält es sich unerwartet,

finde ich. Aber es ist

halt schon sehr cool mit großen Datenmengen,

da kannst du einfach die

anpassen.

Das ist diese Geschichte,

Yandex hat das glaube ich mal gebaut

und dann haben sie es irgendwie Open Source

veröffentlicht. Das weiß ich nicht.

Ich weiß es nicht genau.

Ja, das ist aber, habe ich auch schon

ein gutes Mal gehört.

Ja, also da haben wir ja, wir haben so

am Anfang dieses Projekts überlegt, okay, machen wir das jetzt?

Wir hatten einmal was damit ausprobiert

und wir wussten, wenn das jetzt

nicht gut funktioniert, dann müssen wir natürlich

irgendwie auf eigene Kappe nochmal

ein paar Tage investieren, um das umzustellen.

Aber es war so eine gute Entscheidung,

weil wir gemerkt haben, mit den Datenmengen

würde in anderen

Datenbanken überhaupt nicht gehen.

Ja.

Ja, und wenn wir dann so

Features haben und die stehen dann vielleicht auch in der

Clickhouse-Datenbank oder vielleicht stehen sie auch in der

Postgres oder Redshift-Datenbank,

dann geht's

dann erst mit der Modellierung los und

zum Glück

haben die meisten Leute

von uns auch Spaß an den anderen Sachen, weil wie gesagt,

die Modellierung meistens wirklich nur ein kleiner Teil ist.

Man muss sich natürlich genau überlegen,

was ist überhaupt das passende Modell.

Im Moment,

wenn man Prognosen machen will, ist immer noch

G-Boost einfach sehr, sehr gut.

Bomber sieht das Modell.

Aber es kommen gerade Sachen,

zum Beispiel gibt es da

PFN-Less. Ja, das klingt auch sehr

interessant, ja.

Es ist ein

Transformer-Modell und das ist irgendwie

total verrückt, weil dieses Modell hat

also ich finde es immer noch

total beeindruckend, es ist irgendwie so Magic.

Also das hat gelernt,

wie Datensätze, wie die Zusammenhänge

in Datensätzen,

wie die Zusammenhänge in Datensätzen

normalerweise so sind.

Und dann gibt man dem nochmal so ähnlich

wie so ein Fine-Tuning den Datensatz,

den man halt da selbst hat,

der einen interessiert. Und

dann kann man damit total gute Prognosen machen,

auch wenn der Datensatz nicht besonders

groß ist. Und das Verrückte ist, diese

Datensätze, anhand derer das gelernt hat,

das sind künstliche Daten.

Also es sind nicht mal echte Daten, weil es gibt ja

gar nicht so viele im Netz verfügbar ist.

Das heißt, wenn man ein Sprachmodell trainieren will, das ganze Internet

besteht aus Sprache.

Aber es funktioniert trotzdem, es ist richtig beeindruckend.

Also ich glaube, das ist sowas, was sich gerade

so anfühlt wie, okay, da passiert jetzt

wirklich mal wieder was Neues

in der Bereich-Prognose.

Jaja, auch diese ganzen Pre-Trends, das gibt's ja

im LLM-Bereich, gibt's das ja alles, oder halt

auch bei so Vision-Modellen,

wo dann alles auf ImageNet oder so trainiert ist.

Aber bei tabularen Daten hätte ich jetzt

überhaupt gar nicht gedacht, dass das überhaupt möglich ist.

Oder dass das irgendwie,

und ja, das hat mich auch

total gewundert, dass,

ihr müsst ja vielleicht jetzt noch ein bisschen kurz nochmal

erklären, bitte, so die Grundlagen. Ich glaube, das war ein bisschen

komplex vielleicht für einen Einstieg.

Also, TabTFN hast du

gesagt?

Ja, also XGBoost, also Gradient Boosting.

Ja, XGBoost ist

ein Gradient Boosting und das ist halt

eigentlich einfach dazu da, um eine Tabelle von Daten

zu nehmen und die Zusammenhänge zu lernen,

die in diesen Daten vorkommen.

Zum Beispiel will ich vielleicht vorher sagen,

wie viel verkauft wird an einem bestimmten Tag

und in den Daten hätte ich zum Beispiel die Info,

welcher Wochentag ist denn das eigentlich

und ist dann vielleicht davor oder danach ein Feiertag

und um welches Produkt geht es und so weiter.

Wie ist das Wetter? Vielleicht verkaufe ich ja bei

Hitze mehr Wassermelonen

und das ist so der Klassiker, das würde man

auch mit einer

linearen Regression machen können.

Die ist aber, ja, weniger flexibel

und normalerweise dann auch weniger genau

und XGBoost ist da halt deutlich komplexer.

Und XGBoost macht das dann quasi

über die, weiß ich nicht,

Backpropagation-Mechanismen?

Nee, nee, das ist eine Art Decision Tree.

Also es ist eine andere Art, grundsätzlich

eine andere Art von Modell.

Ja, das ist im Prinzip so eine

Kombination aus ganz, ganz

vielen kleinen,

nicht besonders schlauen Entscheidungsbäumen,

aber dadurch, dass die alle hintereinander geschaltet werden,

ergänzen sie sich ja gut und dann wird es am Ende

auch ziemlich, ziemlich gut.

Und das heißt,

über Jahre eigentlich

für jedes typische

Predictive-Projekt

oder für jede Predictive-Fragestellung

war XGBoost, es war schon fast

langweilig. Ja, es gibt dann noch so ein paar

Varianten. Es gibt zum Beispiel Catboost, das es so

ähnlich hat, aber halt schon irgendwie ganz

schlaue Mechanismen implementiert,

um mit kategorialen Variablen umzugehen

und manchmal ist das eine oder das andere dann so ein bisschen besser

oder performanter, aber das ist kein Riesenunterschied.

Da gab es ja nicht auch noch irgendwas von Microsoft

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

Oder LightGBM. Oder LightGBM, genau. Ich weiß gar nicht, was

da rausgeworden ist.

Benutzen wir auch gerade in dem Projekt.

Ah ja.

Und ja,

witzigerweise, wir haben auch schon

vor einem Jahr oder so, haben wir gedacht, kann man

eigentlich auch LLMs zur Prognose benutzen?

Ich möchte kann dem LLM ja sagen, guck mal hier,

das und das und das sind meine Daten, was denkst du,

wie teuer ist dieser Gebrauchtwagen?

Und wir haben da einen Datensatz

bekommen von einem

Unternehmen, die

genau solche Daten eben aus dem

Internet crawlen und die

das, sagen wir natürlich,

so ein bisschen Informationen mitgeben

und das hat aber schon funktioniert.

Also wir haben da,

da weiß ich jetzt die Details natürlich

nicht alle auswendig, aber wir haben sowohl mit

GPT-Modellen

als auch mit Open-Source-Modellen

das ausprobiert. Es macht schon Sinn,

die zu feintunen.

Und dann kann man aber relativ gut sagen,

mein Auto oder das Auto, das ist die

Marke, das hat so viele Kilometer, das ist so und so

alt und das hat, hier ist noch der Freitext

mit der Beschreibung dazu.

Da steht dann vielleicht irgendwas

Spannendes drin, wie das hat eine Beule,

vielleicht steht aber auch nichts Spannendes drin.

Und dann fragt man, wie teuer ist

das Auto? Bitte antwortet mich nur

in einer Zahl, in Euro oder irgendwie sowas.

Und das funktioniert schon erstaunlich

gut, vor allem, wenn man nicht so viele Trainingsdaten

hat, weil ich glaube, dann kann das halt die Stärke

ausspielen, dass das Sprachmodell

eben schon Vorwissen

hat zu Autopreisen, weil es das Internet

kennt. Also Transformers meinst du jetzt tatsächlich

also die großen LLMs und nicht nur Transformers

selbst, weil ich hätte mich halt gefragt, ob das

in dem Transformers-Modell durch das, weiß ich

nicht, dadurch, dass es halt Nodes sind

und Canisian Trees, dass es da irgendeine andere

Art gibt, dass Daten aus den tabellarischen

Daten rausziehen.

Ja, das hier ist jetzt so, dass

das, ja,

die klassischen LLMs, die man so kennt

und dann kam eben jetzt dieses neue

mit TabPFN, das ist ein Transformer,

ist das halt, wie speziell für tabellare Daten

wieder gemacht ist, weil wir haben ja die LLMs eigentlich so ein bisschen

zweckentfremdet, indem wir die dann da

nach dieser Probe machen. Was meintest du denn da überhaupt mit

Feintuning, was habt ihr denn da gemacht?

Ich weiß gerade nicht, also ich weiß nicht, wie das eigentlich

im Detail dort funktioniert, aber es ist

so, dass das Modell ja eben schon

ganz viel weiß von den Sprachdaten,

die es aus dem Netz kennt und

wir haben ihm dann nochmal

ja gut, das beschreibt es

wahrscheinlich ab dann schon komplett,

wir haben dem dann nochmal, wir haben einen

Trainingsdatensatz, wir ganz viele

Gebrauchtwagen schon drin haben, mit

dem Preis und den ganzen Eigenschaften

und dann haben wir

ihm halt immer so ganz viele Texte gegeben,

zu jedem Auto ein Text, das Auto ist so und so

alt, sieht so und so aus, ist die

Marke und es kostet das und das

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

und das ist dann nochmal ein zusätzlicher Text

und damit trainiert man

das Modell nochmal spezifisch auf diesen

einen Task, also wie das jetzt im

Hintergrund genau passiert, kann ich

tatsächlich euch gerade gar nicht erklären,

weil ich in dem

Thema weniger drin bin, als in so was wie

XG Boost, aber ja, dadurch ist das

Modell dann nochmal, kriegt nochmal so eine Spezialausbildung

quasi für das Thema Auto

Gebrauchtwagenpreise und

dann wird es nochmal besser, wenn man ihm dann so eine Frage

später stellt. Ja, man trainiert

das quasi nochmal ein Stückchen weiter, gibt es unterschiedliche

Ansätze, wie man das dann macht, ob man nur

Layer einfriert, bestimmte Gewichte halt nicht

neu setzt und

dann vielleicht nur die letzten

irgendwie anpasst oder ob man so Low-Rank

Adaption-Geschichten macht oder

da gibt es ganz unterschiedliche. Ich komme mir an die Gewichte

gar nicht dran von den großen LMs zum Beispiel.

Ne, das kannst du auch nicht mit, das kannst du natürlich

dann nur, also du kommst, du kannst mit

den OpenAI-Modellen und so auch machen, über

deren APIs, aber wenn du das

auf einem quasi, wenn

du das selber machen willst, dann musst du ein Modell

nehmen, wo du Gewichte hast. Ja, genau, das

natürlich, ja.

Ich glaube, wir haben da beides gemacht, also

einmal über OpenAI, da kann man einfach über die API sein,

die ist mit Fine-Tuning-Datensatz, machen wir mal

und aber auch mit

den Open-Source-Modellen,

wo wir dann nochmal ein Fine-Tuning drangehängt haben,

damit die eben speziell auf Autoprise

die haben halt so selber ihre, ja.

Bei Tuning und Autos

fällt mir jetzt erst auf, dass es echt total gut

passt. Ja.

Okay, das

ist also Tab-TFN, ja.

Ja, wobei

das ist jetzt noch relativ neu

und da ja nicht

jede Woche neue Projekte losgehen, sondern die

meisten Projekte schon länger laufen,

sind die meisten Projekte, die wir haben, dann auch

mit sowas wie XGBoost oder teilweise auch mit

irgendwelchen ausgefeilten

statistischen Ansätzen

oder Kombinationen, je nachdem, was man

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

richtig gute Statistik oder in klassischer Statistik

ist, rausholen im Vergleich zu diesen

ich beschieße das einfach mit so einem Modell?

Ich würde sagen, es kommt auf die

Fragestellung an. Bei so einem relativ

klassischen Task wie

in welchen Verkaufszahlen

geht es, glaube ich,

auch mit einem Modell

XGBoost ganz gut, wenn man

es natürlich richtig macht und

zum Beispiel noch, es gibt da ja

eine Menge Hyperparameter, die bestimmen,

wie flexibel ist das Modell und wenn man das

Modell zu flexibel sein lässt, dann lernst du auch

die kleinsten Wackler auf den

Trainingsdaten und auf neuen Daten

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

dann hat man Overfitting und das

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

falsch machen könnte, aber

wenn man da alles nach State of the Art

macht, kommt man bei so einfachen

Aufgaben mit einem XGBoost meistens

ziemlich weit, aber

ja, zum Beispiel

im Sportwettenbereich gibt es ja manchmal

wirklich komplizierte Sachen, also wenn ich jetzt

vorher sagen will, wie die

Tore sich verteilen,

dann kommt man da

dann schon nochmal weiter, wenn man wirklich darüber

nachdenkt, theoretisch, was ist denn das jetzt eigentlich

für eine Verteilung? Das sind

Anzahlen, also es ist eine Poisson-Verteilung,

aber die ist ja irgendwie bivariat, weil es sind ja

zwei Mannschaften und

zwei Teams, die Tore machen und

da weiß ich, dass meine

Kolleginnen und Kollegen sich schon

einige ziemlich verrückte Sachen ausgehört haben und dann

umgekehrt, manchmal ist es am Ende auch irgendwie doch nur eine

einfache Holgerstick, die einen ziemlich weit

bringt. Ja, ihr habt also nicht

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

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

ich müsste mal fragen, ob sie das in der

Feature drin haben.

Es gibt auf jeden Fall spannende Sachen.

Ich würde mich halt tatsächlich

interessieren, was man aus Statistik irgendwie daraus lernen kann,

weil ich verstehe nicht genau,

wie jetzt in so einem Transformers-Modell die einzelnen

Gewichte bei den Neuronen zustande kommen,

also weil, ich stelle mir das so vor, der muss

versuchen, diese Features rauszufinden und die

irgendwie so linear unabhängig wie möglich

voneinander zu gestalten, dass er irgendwie

den Erklärungsgrad dann da rausfindet,

der dann halt gut ist, damit er halt gute Prognosen hinkriegt,

aber so richtig

klar wird das nicht.

Ja, Neuronalisten sind deutlich eher

Blackbox, aber das ist extrem gut auch.

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

raus, was da der Grund ist, warum

das jetzt irgendwie so oder so

entschieden oder vorhergesagt hat,

aber es ist schon eher so Blackbox-

Modelle.

Ja, man kann jetzt nachträglich dann.

Also das wäre jetzt vielleicht für mich

auch nochmal einer der Punkte, der für dieses

Data Cleansing spricht. Ja, also wenn ich jetzt

die Daten da einfach so reinkippe oder

am Anfang schon so aufteile,

dass ich jetzt Cluster bilde oder

Kategorien bilde oder sowas und die halt

nochmal damit annotiere oder so,

ob das halt eine deutliche Verbesserung bringt,

also weil die ein bisschen reiner sind

vielleicht oder halt, ne, oder schon mal

irgendwie die Daten wie eine Zusammenfassung,

oder eine Summe oder sowas, da schon

drinsteht mit, ja, in irgendeiner Extraspalte,

dass das dann halt das Ergebnis zum Beispiel nochmal

deutlich bessere Güte kriegt.

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

Ja, vielleicht.

Also zum Beispiel

viele Modelle sind ja auch dazu in der Lage,

Interaktionen zu erkennen, also

beispielsweise, weißt du,

ich, ähm,

vielleicht aus der

Luftschadstoff-Prognose überlege ich gerade,

ist, ähm,

irgendwie was, ja, also mittags ist

die Luft schlechter, weil mehr Autos rumfahren,

aber nur, wenn wir keinen Wind haben.

Wenn wir viel Wind haben, wird nämlich wenig Schadstoff

halt weggepustet. Das ist halt eine Interaktion, also

die Effekt, mittags ist es schlechter, der ist nur

da, wenn die Windstärke gering ist.

Und so eine Interaktion können die Modelle

auch lernen, aber manchmal sind die

Interaktionen ja vielleicht auch nochmal komplexer von

drei oder vier Sachen, und wenn man da

schon so eine Idee hat, sag ich logisch,

dann macht man es dem Modell halt schon deutlich

leichter.

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

Und dann hat man quasi tatsächlich schon das Wissen, was man aus den Daten ziehen kann, so ein bisschen annotiert, reingegeben, dass das Modell dann damit besser arbeiten kann. Also als eigene Funktion irgendwie so.

Ja, und oft musst du auch Daten erstmal transformieren, damit die überhaupt von dem Modell verwendet werden können. Also wenn du zum Beispiel Text hast, kannst du den nicht einfach so bei XGBoost sozusagen reinkippen, weil das kann halt bloß irgendwie eine fixe Anzahl von Spalten.

Und dann muss man das irgendwie.

Erstmal den Text runter projizieren mit Singular Value Decomposition oder so auf, weiß ich nicht, ein paar hundert Dimensionen oder so. Und das kann man in XGBoost reinpacken, sozusagen. Solche Sachen hat man halt auch immer.

Ja, das war tatsächlich so ein Grund, weshalb wir das auch mal ausprobieren wollten mit den LLMs zur Vorhersage. Weil wie du sagst, wenn wir einen Text haben und wollen aber XGBoost machen, wie in dieser Freitext mit der Autobeschreibung, dann muss man sich ja erstmal irgendwie was überlegen, wie man den dann in ein sinnvolles Format bringt.

Also das XGBoost, das kennt halt nur.

Man kann eigentlich nur Spalten bezahlen.

Kategorien kann man ja im Prinzip auch doch in Zahlen überführen.

Und ein Text, naja,

ist halt erstmal nicht so einfach.

Was man jetzt natürlich auch noch machen kann, ist, dass man

das LLM benutzt, um Features zu generieren,

indem man sagt, hier ist der Text, hat das Auto

einen Schaden? Ja, nein.

Ja.

Also es ist dann auch nochmal so eine Hybridlösung,

die, glaube ich, gar nicht so dumm ist.

Und halt auch,

man kann natürlich auch, je nachdem, wie genau man

das machen will, Leute hinsetzen, die dann

wirklich viel Zeit damit verbringen,

Texte durchzugucken und das zu labeln,

dann ist das bestimmt nochmal ein bisschen genauer.

Das ist halt die Frage, ob es sich lohnt.

Muss man sich immer überlegen.

Okay, ja gut, aber dadurch kann man

schon viel rausholen, ja, durch diese Modellierung dann und so.

Okay, dann sind wir in diesen

Datenprozessen. Wie nennt man diese Datenprozesse?

ETIL? ETIL, da gibt es ja verschiedene

Art und Weisen.

Ach, du meinst jetzt Extract, Transform,

Load? Ja, genau.

Das ist, glaube ich, aber nicht unbedingt was mit,

oder... Ja, aber wir sind jetzt da

irgendwo in diesem Workflow,

also es ging ja um dieses CRISP, ne?

Ach so, ja. Ja.

Also ich glaube, ja, also die ETIL,

Extract, Transform, Load, ist ja,

beschreibt ja einfach den Prozess, dass man

Daten irgendwo rauszieht,

dann irgendwas damit macht, also sie transformiert

und sie dann irgendwo hinlädt, obwohl man

sagt, Daten laden für Daten kriegen. In dem Fall

ist aber Daten laden, die irgendwo hinladen.

Das ist auch ein bisschen verwirrend, auch im Naming

finde ich, in den

Code dann, wenn man

irgendwann überall Load stehen hat, egal ob man Daten

zieht oder Daten wegschiebt.

Und, ja, das ist,

so hängt das im Prinzip zusammen,

aber oft benutzt man ja den Begriff

ETIL auch einfach für jeden

Prozess, der irgendwie Daten nimmt,

verarbeitet und so durch so eine Strecke schiebt.

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

Ja, genau. Also jeder Business-Prozess,

den man irgendwie halt automatisieren kann.

Aber ich glaube, es ist schon oft so,

dass man auch sagen würde, nachher

in dem fertigen Datenprodukt, okay, hier ist der ETIL,

jetzt kommt der ETIL und dann kommt

der Teil mit dem Modell. Also oft nutzt

man den Begriff eigentlich auch, um das so voneinander,

da abzugrenzen.

Okay. Also ich verstehe jetzt, also wir haben

okay verstanden, was das Geschäft

macht und was wir da lösen

wollen für Daten. Und dann haben wir

verstanden, welche Daten wir denn haben und was wir damit machen

wollen. Dann haben wir die so transformiert

und umgebaut, dass wir die

in ein Modell kippen können, was wir uns

dann ausdenken oder ausgedacht haben.

Und was machen wir dann? Dann gucken wir

uns an, was dabei rauskommt.

Ja, dann haben wir ein Modell

und dann machen wir Prognosen und gucken,

wie gut die sind. Und

da muss man natürlich verschiedene Sachen beachten.

Also wenn ich

die Prognosen auf denselben

Daten mache, die ich fürs Modelltraining benutzt

habe, dann ist das natürlich für das Modell relativ

einfach. Und

deswegen ist es wichtig, dass ich mir vorher

einen Teil der Daten weglege und nur die

übrigen Daten kriegt das Modell

zum Lernen. Und danach mache ich auf diesen

weggelegten Daten die Prognosen

und dann gucke ich, was tatsächlich

die Werte waren und vergleiche die mit den

Prognosen von dem Modell. Und das Modell

ist halt ja natürlich in dem Moment blind. Das kriegt halt nur

die ganzen Features, aber es kriegt nicht die Zielvariable.

Es muss dann seine Prognosen blind machen und wir

können dann gucken und dann sagen, ja, wir

kennen die Warenwerte aber schon und vergleichen das

jetzt. Da gibt es dann verschiedene Kennwerte,

die man berechnen kann, kommt es halt total auf

die Fragestellung an. Man könnte zum Beispiel

eine mittlere prozentuale Abweichung

berechnen. Man kann ein Bias berechnen,

liegen wir mittel drüber oder drunter.

Man kann eine erklärte

Varianzanteil berechnen. Man kann

je nachdem, vielleicht wollen wir auch gar nicht

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

Dann könnte man gucken, wie viele

Falsch-Positiv, Falsch-Negativ und so weiter

habe ich. Das kommt, ja, stark

auf den Use-Case an. Auf jeden Fall kann ich das dann

berechnen. Schön out of sample,

also mit diesem separaten

Datensatz. Und

das ist natürlich besonders gut,

wenn man zwei Modelle vergleichen will. Wenn man

nur eins hat, dann ist da, es ist glaube

ich auch gar nicht so leicht zu sagen, was ist denn jetzt ein guter

Wert? Finde ich irgendwie 20, 50 oder 90

Prozent erklärte Varianz? Das kommt auch

stark auf die Fragestellung an. Wenn ich zum Beispiel

individuelles Verhalten von Menschen

erklären will, dann nicht, dass

ich natürlich nicht so genau vorher sagen, wie

aggregierte Verkaufszahlen,

weil da einfach so

viele andere Einflüsse sind.

Und ja, nochmal zu diesem

Split, zu den

Trainingsdaten und den Testdaten.

In den allermeisten Fällen

haben unsere Daten ja eigentlich eine zeitliche

Struktur. Man kann jetzt natürlich die Testdaten

zufällig rausziehen und zur Seite legen, aber am besten

ist es, wenn man immer die

zeitlich, die nimmt, die zeitlich am Ende

liegen, weil manchmal ändern sich eben Zusammenhänge

und

es eigentlich passiert ständig, dass sich Zusammenhänge

ändern. Und deswegen ist es halt sinnvoll,

so ein Szenario zu bauen, wo das Modell quasi auf der

Vergangenheit lernt und dann auf Daten,

die danach passiert sind, auch tatsächlich

evaluiert wird. Sonst kann es halt passieren, dass

man sich da verschätzt und

dann denkt, das Modell wäre besser, als

es tatsächlich ist. Und nachher im Betrieb,

dann muss es ja tatsächlich Prognosen

für die Zukunft machen und dann ist die Enttäuschung

dann irgendwie da, wenn es dann doch schlechter funktioniert,

als man dachte. Aber man muss

natürlich auch immer auffassen, dass man dann halt die

neuen zusammenhängigen Daten, Änderungen dann irgendwie auch trotzdem mit

reinkriegt, ne? Weil wenn sich halt irgendwas...

Ja, das ist natürlich regelmäßiges

Neutraining, ja. Also das

ist dann auch total wichtig, dass man das Modell nicht einmal

trainiert und dann fünf Jahre lang benutzt.

Trotzdem, solange die Zusammenhänge

noch nicht da sind, die neuen, wenn man die noch nicht kennt,

muss man halt zumindest mit dem leben, was man

bis dahin hat.

Also man könnte ja vielleicht auch diese Zusammenhänge

irgendwie als, ich sag mal, Liste, ne, dem

Geschäft zurückgeben, so hey, hier, das sind unsere Annahmen,

guckt doch mal bitte, dass die noch stimmen. Und wenn ihr merkt,

irgendwie da ändert sich irgendwas an den Annahmen, dann müssen wir

halt da nochmal was auch anpassen.

Ja, also zumindest,

ich glaube, so direkt geht es gar nicht so gut,

weil das ist ja was, was das Modell findet

und wo die dann eher auch sagen, ah ja, cool, ja, das

passt so ungefähr zu dem, was wir erwartet haben.

Aber die können sich wirklich sagen, oh, das ändert sich

jetzt, weil jetzt ist, keine Ahnung, zum Beispiel

der Zusammenhang

von Autoanzahl

zu Stickoxiden,

der wird schwächer, weil

mehr E-Autos unterwegs sind

und die stoßen keine Stickoxide aus.

Ja, okay, aber wie viel

schwächer der jetzt wird, das kann uns diese Nase

Verwaltung hier für Umwelt und

so weiter ja auch nicht sagen. Also die können

uns sagen, ja, das wird wahrscheinlich schwächer

mit der Zeit. Also klar, solltet ihr das Modell

regelmäßig neu trainieren, aber die können uns

sagen, so und jetzt, jetzt ist es aber so viel schwächer

geworden, so müsst ihr mal neu trainieren. Das kann die

auch gar nicht sehen. Aber deswegen

ist es halt meistens so, dass man einfach sagt,

wir trainieren unser Modell zum Beispiel einmal

im Monat neu und

dann wissen wir, dass wir halt eigentlich immer

neue Zusammenhänge abgedeckt haben.

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

ganz, ganz viel Datenhistorie zu haben,

weil vielleicht das, vor allem jetzt, wo auch noch

Corona war, dass die Zusammenhänge und

die Muster während Corona in

irgendwelchen Verkaufszahlen

oder menschlichem Verhalten,

die sind natürlich jetzt, die sind jetzt halt

anders. Das wäre mein nächster Punkt gewesen. Also wenn

ich jetzt Statistik nehme, ja, oder von

Statistik irgendwo abhängige Modelle, um

Prognosen zu machen für die Zukunft, dann

bin ich ja immer nur, also auf den,

ich sag jetzt mal, den Normalfall trainiert,

ja, oder den Alltag und diese ganzen

Schocksituationen, die kann ich ja immer ganz

schlecht irgendwie abbilden, weil ich ja dafür auch kein

Beispiel gehabt habe, ja.

Wenn der Schock gerade erst passiert ist,

dann ist das echt schwierig. Man kann,

vergangene Schocks kann man halt noch mit reinnehmen und

sagen, okay, hier war ein Strukturbruch, da hat sich jetzt irgendwie

was geändert, das nehmen wir als Feature mit rein.

Geht manchmal, geht auch nicht immer.

Also

ich glaube, wir haben tatsächlich

in der

Luftfahrtschiff-Projekt haben wir, glaube ich,

einfach die Zeiträume definiert.

Hier war Lockdown, hier war kein Lockdown.

Damit das Modell zumindest weiß,

ah, deswegen war hier so viel weniger.

Luftverschmutzung.

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

Aber ich hab nochmal,

ich würde mal ganz kurz einen Schritt

zurückgehen, weil ich hab eine Frage,

die mich noch jetzt schon interessieren würde,

weil ich jetzt auch gar nicht so wirklich Ahnung von diesem

TAP-PFN oder so habe, weil

in den anderen Bereichen haben ja die,

also normalerweise hat man neuronale Netze für solche

tabularischen Daten.

Das funktioniert auch, aber

halt nicht so gut wie die anderen Arten von Modellen.

Oft, und

die Frage wäre jetzt, was einen, ja,

die,