Data Science Deep Dive

In dieser Episode sprechen wir darüber, wie es ist, im Body Leasing als externer Data Scientist direkt im Kund*innenteam zu arbeiten. Mira und Andreas teilen ihre Erfahrungen zu Rollenwechseln, Erwartungen im Projekt und dem Umgang mit Druck und neuen Teamkulturen. Wir geben praktische Tipps für Onboarding, Kommunikation und Beziehungspflege, damit die Zusammenarbeit für alle Seiten gut funktioniert. Außerdem beleuchten wir die Chancen und Risiken für Beratungen, Freelancer*innen und Auftraggeber*innen. Am Ende zeigt sich: erfolgreich wird Body Leasing vor allem über gute Beziehungen und gute Selbstorganisation.   **Zusammenfassung** Was Body Leasing bedeutet und warum es eine besondere Form der Beratung ist Erfahrungen von Mira und Andreas: Rollen, Herausforderungen und Chancen im Kund*innenteam Tipps für den Einstieg: Onboarding ernst nehmen, Erwartungen klären, Ergebnisse gut präsentieren Bedeutung von Beziehungsebene, Teamkultur und Kommunikation im täglichen Miteinander Umgang mit Druck, Bewertung und wechselnden Anforderungen Vorteile für Berater*innen: neuer Input, externe Validierung, Einblick in andere Unternehmen Chancen und Risiken für Beratungsunternehmen und Freelancer*innen Sicht der Auftraggeber*innen: schnelle Verfügbarkeit, Know-how-Gewinn, aber auch On-/Offboarding-Aufwand

In dieser Folge sprechen Mira und Amit über Modellgütemaße für kontinuierliche Zielvariablen – also darüber, wie man die Qualität von Vorhersagen richtig bewertet. Von MAE und RMSE bis hin zu R² und AIC/BIC: Wir erklären, was die einzelnen Kennzahlen aussagen, wo ihre Grenzen liegen und welche typischen Fallen es gibt. Außerdem geht's um Bias, Robustheit und warum der Kontext entscheidend ist. Und natürlich um die Frage: Welches Gütemaß passt eigentlich zu meinem Modell?   **Zusammenfassung** Überblick über Gütemaße für kontinuierliche Zielgrößen Bias, MAE, MAPE, sMAPE, MSE, RMSE, R², AIC/BIC im Vergleich Vor- und Nachteile der einzelnen Metriken Typische Fallstricke: Ausreißer, kleine Werte, verzerrte Interpretation Tipps zur Auswahl des passenden Gütemaßes für den Use Case Bedeutung von Repräsentativität, Validierung und Gewichtung Fazit: Kombination mehrerer Gütemaße ist meist die beste Wahl   **Links** Blogserie zum Bestimmtheitsmaß (R²): https://www.inwt-statistics.de/blog/bestimmtheitsmass_r2-teil1 #26: A/B-Testing: Erkenntnisse statt Bauchgefühl https://www.podbean.com/ew/pb-6fzpj-143cfb1 #43: Damit es im Live-Betrieb nicht kracht: Vermeidung von Overfitting & Data Leakage https://www.podbean.com/ew/pb-vw736-15baac0

Wie behält man eigentlich den Überblick, wenn Data Science Services in Produktion laufen? In dieser Folge sprechen Sebastian und Michelle darüber, wie man einen sinnvollen Monitoring-Stack aufsetzt – von Logs und Metriken bis hin zu Alerts und Dashboards. Wir schauen uns Tools wie Prometheus, Grafana, Loki und ELK an und klären, worin sie sich unterscheiden. Außerdem geht's um Best Practices fürs Alerting, sinnvolle Feedbackschleifen und die Frage, wann und wie man Monitoring in den Entwicklungsprozess integriert. **Zusammenfassung** Ziel von Monitoring: schnelle Feedbackschleifen zwischen Entwicklung und Produktion Unterschied zwischen CI/CD und Monitoring, letztere liefert Feedback nach dem Deployment Planung des Monitorings idealerweise schon bei der Architektur berücksichtigen Überblick über Monitoring-Ziele: Services, Infrastruktur, Daten, Modelle Vergleich Cloud vs. Self-Hosted Monitoring (Aufwand, Flexibilität, Kosten) Wichtige Tools: Prometheus/Grafana/Loki, ELK-Stack, Nagios/Icinga/Zabbix, Great Expectations, Redash/Metabase Best Practices fürs Alerting: sinnvolle Schwellenwerte, Vermeidung von "Alert Fatigue", klare Zuständigkeiten Fazit: Monitoring braucht klare Ziele, sinnvolle Alerts und gute Visualisierung, um echten Mehrwert zu liefern   **Links** #23: Unsexy aber wichtig: Tests und Monitoring https://www.podbean.com/ew/pb-vxp58-13f311a Prometheus – Open-Source Monitoring-System: https://prometheus.io Grafana – Visualisierung von Metriken und Logs: https://grafana.com Loki – Log-Aggregation für Grafana: https://grafana.com/oss/loki/ ELK Stack (Elasticsearch, Logstash, Kibana): https://www.elastic.co/elastic-stack Great Expectations – Datenvalidierung und Monitoring: https://greatexpectations.io Redash – SQL-basierte Dashboards und Visualisierungen: https://redash.io Metabase – Self-Service BI-Tool: https://www.metabase.com Nagios – klassisches System-Monitoring-Tool: https://www.nagios.org Icinga – moderner Nagios-Fork: https://icinga.com Zabbix – Monitoring-Plattform für Netzwerke & Server: https://www.zabbix.com Prometheus Alertmanager: https://prometheus.io/docs/alerting/latest/alertmanager/ PagerDuty – Incident Response Management: https://www.pagerduty.com   📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

In dieser Folge des Predictive AI Quarterly sprechen wir über die Veröffentlichung von GPT-5 und was sich im Vergleich zu GPT-4 geändert hat. Wir schauen uns an, wie Reasoning jetzt funktioniert und welche Optionen Entwickler*innen bei der Nutzung haben. Außerdem geht's um neue Open-Source-Modelle von OpenAI, die Einführung von TabArena als dynamischem Benchmark für Tabulardaten und spannende Integrationen wie TabPFN in Sourcetable. Im Praxisteil nehmen wir QLoRA unter die Lupe und testen, ob Finetuning mit Quantisierung wirklich so effizient und verlustfrei ist, wie versprochen.   ** Zusammenfassung ** GPT-5 Release: Neues Reasoning-Feature, flexible Steuerung über Parameter und Empfehlungen für die Migration von GPT-4. Open-Source-Modelle von OpenAI: Veröffentlichung von 20B- und 120B-Modellen mit vergleichsweise moderatem Hardwarebedarf. TabArena: Dynamischer Benchmark für tabellarische Daten, der Ensembling und TabPFN bei kleinen Datensätzen hervorhebt. TabPFN in Sourcetable: Integration von Predictive AI direkt in Spreadsheets für nahtlose Nutzung. Praxis-Test QLoRA: Finetuning mit Quantisierung liefert gleiche Qualität wie LoRA, benötigt aber nur halb so viel Speicher.   ** Links ** OpenAI – GPT-5 für Entwickler*innen vorgestellt: https://openai.com/de-DE/index/introducing-gpt-5-for-developers/ OpenAI – API Responses Referenz: https://platform.openai.com/docs/api-reference/responses/create OpenAI – Guide: Reasoning in GPT: https://platform.openai.com/docs/guides/reasoning OpenAI – Modell-Migrationsempfehlungen: https://platform.openai.com/docs/guides/latest-model#migration-guidance Hugging Face – Open-Source GPT 20B: https://huggingface.co/openai/gpt-oss-20b Hugging Face – Open-Source GPT 120B: https://huggingface.co/openai/gpt-oss-120b OpenAI – Ankündigung OSS-Modelle: https://openai.com/de-DE/index/introducing-gpt-oss/ Hugging Face – TabArena Leaderboard: https://huggingface.co/spaces/TabArena/leaderboard arXiv – TabArena Paper: https://arxiv.org/abs/2506.16791 Sourcetable – Homepage / Tool: https://sourcetable.com/ Heise c’t – Artikel "Komprimierte KI" (Februar 2025): https://www.heise.de/select/ct/2025/2/2432617330867723674 Heise c’t – Artikel "Quantisierung": https://www.heise.de/select/ct/2025/7/2504911435670065158 arXiv – QLoRA Paper (Mai 2023): https://arxiv.org/abs/2305.14314 NeurIPS – QLoRA Veröffentlichung: https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract-Conference.html arXiv – Paper zu Quantisierung: https://arxiv.org/abs/2501.13787 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de  

Onboarding ist mehr als nur Laptop einrichten und Accounts anlegen, es ist der Startpunkt für alles, was danach kommt. In dieser Folge sprechen wir über die ersten Tage und Wochen, wie man neuen Kolleg*innen Orientierung gibt und warum Mentoring so wichtig ist. Wir diskutieren auch den Übergang von den Basics hin zu Projekten und wie man Schritt für Schritt Verantwortung übernimmt. Außerdem werfen wir einen Blick darauf, was langfristig zählt: Wissen teilen, Feedback geben und Raum für Entwicklung schaffen.   **Zusammenfassung** Technische Basics: Accounts, Laptop, Tools, Datenschutz etc. Mentoring als Anlaufstelle für Fragen und Kulturvermittlung Feedback- und Mitarbeitergespräche, am Anfang ganz besonders entscheidend Unterschiedliche Profile: Coding, Statistik, echte Daten – wie man Skills ausgleicht Einarbeitung in Projekte: zuerst im Hintergrund, dann mit wachsender Verantwortung Unterschied remote vs. vor Ort: passende Unterstützung finden Langfristig wichtig: Wissenstransfer, Weiterbildung und Raum für Eigeninitiative   **Links** #60: Job-Sicherheit als Data Scientist: Personalentwicklung in Zeiten von AI https://www.podbean.com/ew/pb-x68nz-1748acb #51: Wer rastet, rostet: Die Rolle von Weiterbildung in Data Science https://www.podbean.com/ew/pb-czpd3-16716c0   📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Modelle auf Edge-Devices zu bringen ist kein Standard-Deployment – das zeigt sich im gesamten Life-Cycle: von der Datenpipeline über das Feature-Engineering bis zur Modellüberwachung. In dieser Folge diskutieren wir, wie sich gängige MLOps-Ansätze verändern, wenn Netzwerk, Datenschutz oder Ressourcen limitiert sind. Wir sprechen über typische Architektur-Entscheidungen, sinnvolle Deployment-Strategien und warum Murphys Law auf Edge-Setups besonders gut zutrifft. Am Ende bleibt die Erkenntnis: ohne triftigen Grund bleibt man besser in der Cloud.   **Zusammenfassung** Edge Computing verändert die Art und Weise, wie Modelle in der Data Science implementiert werden Offline-Serving ist der einfachste Fall, während Online-Serving komplexere Anforderungen hat Latenz ist ein kritischer Faktor bei der Nutzung von Edge-Devices Datenbeschaffung kann über Push- oder Pull-Ansätze erfolgen Feature Engineering muss an die Einschränkungen von Edge-Devices angepasst werden Modelltraining kann sowohl zentral als auch lokal auf Edge-Devices erfolgen CI/CD-Prozesse müssen an die spezifischen Anforderungen von Edge-Devices angepasst werden Monitoring ist entscheidend, um die Leistung von Modellen auf Edge-Devices zu bewerten Die Qualität der Daten und der Sensoren hat einen direkten Einfluss auf die Modellleistung Ein erfolgreicher Einsatz von Edge Computing erfordert enge Zusammenarbeit zwischen Data Science und Engineering-Teams **Links** #54: Modell-Deployment: Wie bringe ich mein Modell in die Produktion? https://www.podbean.com/ew/pb-hhhwu-16b91f3 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

In dieser Folge sprechen wir darüber, wie man den nächsten sinnvollen Data-Science-Use-Case identifiziert. Egal ob man gerade erst mit Daten startet oder schon komplexe Produkte im Einsatz hat. Wir klären, wer in den Prozess einbezogen werden sollte, worauf man bei der Ideenfindung achten sollte und wie man Use Cases richtig bewertet. Ein besonderer Fokus liegt auf der Perspektive der Nutzer*innen und die Umsetzbarkeit in Bezug auf Daten, Methoden und Technik. Eine Folge für alle, die Orientierung suchen, um den weiteren Weg auf ihrer Data-Journey zu gestalten.   **Zusammenfassung** Zielgruppe: Organisationen, die mit Daten Mehrwert schaffen wollen, aber unklar sind, welcher Use Case der nächste sein sollte Ausgangssituation: Entweder besteht noch keine Idee, oder es gibt bereits eine Idee, deren Umsetzbarkeit geprüft werden soll Beteiligte Rollen: Entscheider*innen, Fachexpert*innen, Anwender*innen sowie Data- & IT-Personal sollten früh eingebunden werden Ideation-Phase: Kreative Suche nach Problemen mit Hebelwirkung mit Fokus auf Pain Points, Engpässe, repetitive Tätigkeiten und Business Value Nutzer*innenzentrierung: Anforderungen, Nutzungskontext und Entscheidungsprozesse der Anwender*innen bestimmen, was ein Use Case leisten muss Technische Implikationen: Die Form der Ergebnisausspielung (z. B. Dashboard, API, E-Mail) hängt direkt vom Nutzungskontext ab Machbarkeitsprüfung: Datenlage, methodische Passung und technische Umsetzbarkeit werden realistisch bewertet Datenstruktur: "Must-have" vs. "Nice-to-have"-Daten, typische Hürden wie fehlende IDs, Möglichkeiten zur Verknüpfung Reifegrad beachten: Nicht zu groß denken, sowohl Überforderung bei geringer Reife als auch Overengineering bei hoher Reife vermeiden Dienstleisterfrage: Strategisches Assessment und Umsetzung trennen oder vereinen, beide Varianten haben nachvollziehbare Vor- und Nachteile   **Links** Das Data & AI Design Thinking Workshop Canvas von Datentreiber https://www.datentreiber.com/de/data-and-ai-design-thinking-workshop-canvas/#canvas #70: Der Aufstieg zur Datenreife – Stufe für Stufe zur Data Maturity https://www.podbean.com/ew/pb-a7663-1882b25 #63: Data Mining: der pragmatische Weg zu Datenreife & Datenkultur mit Prof. Dr. Ana Moya https://www.podbean.com/ew/pb-d38qj-1799899 #36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1 #2: Erfolgsfaktoren für Predictive Analytics Projekte https://www.podbean.com/ew/pb-kdcmd-12460ab 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Uplift Modeling hilft dabei, den tatsächlichen Effekt von Maßnahmen wie Rabatten oder Gratisprodukten auf das Verhalten einzelner Kund*innen vorherzusagen, also: Wer hätte ohnehin gekauft und wen überzeugen wir wirklich? Statt bloßer Vorhersage steht die Frage im Mittelpunkt, wie wir Verhalten gezielt verändern können. Wir sprechen über Methoden, notwendige Daten, Herausforderungen bei der Modellierung und warum Kausalität hier entscheidend ist. Außerdem sprechen wir darüber warum ein A/B-Test trotz komplexer Modelle unverzichtbar bleibt. Und was du auch ohne vollständiges Uplift-Modell bereits tun kannst.   **Zusammenfassung** Uplift Modeling zielt darauf ab, den kausalen Effekt eines Treatments (z. B. Gutschein) vorherzusagen Wichtige Frage: Wie viel wahrscheinlicher ist ein bestimmtes Verhalten durch die Maßnahme? Zielgröße und Features müssen sorgfältig gewählt werden, um sinnvolle Modelle zu bauen Es braucht Daten mit Variation im Treatment (z. B. unterschiedliche Gutscheinzeiträume) Kausalität ist essenziell, sonst liefert das Modell verzerrte Effekte A/B-Tests sind nötig, um den tatsächlichen Mehrwert des Modells zu überprüfen Baseline-Modelle und deskriptive Analysen sind wertvolle Vorstufen mit eigenem Nutzen Herausforderung: Modellanpassung bei Änderungen der Treatment-Strategie und Exploration/Exploitation-Balance   **Links** [Podcast] #26: A/B-Testing: Erkenntnisse statt Bauchgefühl https://www.podbean.com/ew/pb-6fzpj-143cfb1   📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Wer seine gesamte Infrastruktur in US-Clouds betreibt, begibt sich in gefährliche Abhängigkeiten. Im Podcast diskutieren wir, wie real die Risiken internationaler Machtspiele und Datenschutzprobleme sind und was Unternehmen dagegen tun können. Zwischen Know-how-Drain, geopolitischen Spannungen und drohenden Exportstopps braucht es einen klaren Blick auf die eigene IT-Landschaft. Unser Fazit: Resilienz beginnt mit bewusstem Design, nicht mit blindem Aktionismus. **Zusammenfassung** Digitale Souveränität ist für Unternehmen essenziell, um geopolitische Risiken und Lock-in-Effekte zu minimieren Aktuelle Gefahren entstehen durch internationale Konflikte, politisch motivierte Eingriffe in IT-Infrastruktur und den Weggang von Know-how Besonders kritisch: die Abhängigkeit von US-Clouds und SaaS-Lösungen – auch in puncto Datenschutz und Compliance Die DSGVO-Lage ist trotz "EU-U.S. Data Privacy Framework" instabil und hängt stark von politischen Entwicklungen in den USA ab Unternehmen sitzen oft tiefer in der Abhängigkeit, als sie denken – selbst intern ist oft alles von wenigen Cloud-Anbietern abhängig Lösungsansätze sind u.a. europäische Cloud-Angebote, Open Source Software und Infrastructure as Code – allerdings mit vielen praktischen Grenzen Ein sofortiger Komplettausstieg ist unrealistisch, sinnvoller sind inkrementelle Anpassungen bei neuen Projekten Wichtig: Risiken realistisch bewerten und bewusste Designentscheidungen treffen, statt nur auf Komfort und Geschwindigkeit zu optimieren **Links** [Artikel] Strafgerichtshof: Microsofts E-Mail-Sperre als Weckruf für digitale Souveränität https://www.heise.de/news/Strafgerichtshof-Microsofts-E-Mail-Sperre-als-Weckruf-fuer-digitale-Souveraenitaet-10387368.html [Artikel] Tagesschau-Artikel zu US-Exportbeschränkungen für KI-Chips https://www.tagesschau.de/wirtschaft/unternehmen/ki-chips-export-usa-nvidia-biden-100.html [Tool] FreeIPA Projekt (Open Source Identity Management) https://www.freeipa.org/ [Tool] Pangolin Projekt (Open Source API Gateway / Identity) https://github.com/fosrl/pangolin [Podcast] #29: Die Qual der Wahl: Data Science Plattform vs. Customized Stack https://inwt.podbean.com/e/29-die-qual-der-wahl-data-science-plattform-vs-customized-stack/ 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Refactoring ist ein Begriff, der oft missverstanden wird. Er bedeutet nicht, dass etwas kaputt war, sondern dass man Code strukturell verbessert, ohne sein Verhalten zu verändern. In dieser Folge sprechen wir darüber, warum Refactoring im Alltag oft notwendig ist, wie man es erkennt und richtig angeht. Wir diskutieren, wann es sinnvoll ist, Refactoring gezielt zu planen oder spontan umzusetzen – und warum Tests dabei eine zentrale Rolle spielen. Außerdem werfen wir einen Blick auf die speziellen Herausforderungen im Data-Science-Kontext und wie man Stakeholder überzeugt. Refactoring ist kein Selbstzweck, sondern ein strategischer Hebel für bessere, wartbare Software.   **Zusammenfassung** Refactoring verbessert die Code-Struktur ohne das Verhalten zu verändern für bessere Wartbarkeit und Lesbarkeit Typische Ursachen für unübersichtlichen Code: Zeitdruck, sich ändernde Anforderungen, wenig einheitliche Standards im Team Refactoring ist kein Zeichen für Fehler, sondern für evolutionäre Weiterentwicklung Gelegenheits- vs. geplantes Refactoring: vom schnellen Umbau beim Feature-Entwickeln bis hin zum langfristigen Redesign Gute Tests sind essenziell, um unbeabsichtigte Nebeneffekte zu vermeiden Risiken: beschädigte Funktionalität, Zeitaufwand, technische Schulden bei unvollständigem Refactoring Refactoring im Data-Science-Kontext oft besonders notwendig, da Entwicklung häufig in Skripten startet Erfolgsfaktor: Refactoring verständlich kommunizieren als Investition in Qualität, nicht als "Schuldenbegleichung" **Links** [Buch] Refactoring: Improving the Design of Existing Code. M. Fowler. Addison-Wesley, Boston, MA, USA, (2019). [Blog] Definition Of Refactoring by Martin Fowler https://martinfowler.com/bliki/DefinitionOfRefactoring.html [Blog] Refactoring: Einführung von Antonia Runge https://www.inwt-statistics.de/blog/refactoring-einfuehrung  [Podcast] #23: Unsexy aber wichtig: Tests und Monitoring https://www.podbean.com/ew/pb-vxp58-13f311a 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Predictive AI Quarterly ist unser neues Format im Data Science Deep Dive. Alle 3 Monate sprechen wir über Entwicklungen im Bereich Predictive AI - kompakt, kritisch und praxisnah. Wir starten mit einem Überblick zu den aktuellen News und Trends, danach wird's hands-on: Wir berichten, was wir selbst ausprobiert haben, was gut funktioniert hat und was nicht.   **Zusammenfassung** TabPFN ist ein Foundation-Modell speziell für tabulare Daten, das Prognose- und Klassifikationsaufgaben ohne Finetuning lösen kann Finetuning-Optionen: Neben dem kostenpflichtigen Angebot von PriorLabs existiert ein Open-Source-Repo zum Finetuning von TabPFN, das aktiv weiterentwickelt wird mit TabICL gibt es ein weiteres Foundation-Modell für tabulare Daten, das synthetisch trainiert ist, sich auf Klassifikation konzentriert und auch bei großen Datensätzen (bis 500k Zeilen) schnelle Inferenz verspricht Foundation-Modelle für Zeitreihen: Unternehmen wie IBM, Google und Salesforce entwickeln eigene Foundation-Modelle für Time-Series Forecasting (z. B. TTMs, TimesFM, Moirai), diese werden bislang auf echten Zeitreihen trainiert der GIFT-Benchmark dient als Standard zum Vergleich von Zeitreihenmodellen – hier zeigt sich, dass ein angepasstes TabPFN auch für Zeitreihen überraschend leistungsfähig ist Hands On: TabPFN lässt sich analog zu scikit-learn einsetzen und ist besonders dann praktisch, wenn eine GPU vorhanden ist, die Einstiegshürde ist sehr niedrig in Zukunft wird mit multimodalen Erweiterungen (z. B. Bilder), quantisierten Varianten und weiteren Alternativen zu TabPFN gerechnet, der Bereich Foundation Models für strukturierte Daten entwickelt sich rasant **Links** Podcastfolge #72: TabPFN: Die KI-Revolution für tabulare Daten mit Noah Hollmann TabPFN: Finetuning Angebot von Prior Labs GitHub-Repo: Finetune TabPFN v2 GitHub-Repo: Zero-Shot Time Series Forecasting mit TabPFNv2 TabICL: GitHub-Repo: TabICL – Tabular In-Context Learning Workshop @ ICML 2025: Foundation Models for Structured Data (18. Juli 2025 in Vancouver) Blogartikel & Studien: Tiny Time Mixers (TTMs) von IBM Research Moirai:  A Time Series Foundation Model by Salesforce Blogartikel von inwt: "TabPFN: Die KI-Revolution für tabulare Daten" Huggingface Spaces & Modelle: TimesFM Foundation Model für Zeitreihen von Google Research GIFT-Eval Forecasting Leaderboard 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Korrelation ist nicht gleich Kausalität, und wer fundierte Entscheidungen treffen will, braucht mehr als gute Vorhersagen. In dieser Folge geht es um Confounder, Spurious Correlations und die Frage, wann Machine Learning kausale Einsichten liefern kann. Mit dabei: DoubleML als Brücke zwischen klassischer Statistik und Machine Learning.   **Zusammenfassung** Unterscheidung zwischen Vorhersage und Intervention: Nur Kausalität beantwortet die "Was-wäre-wenn?"-Frage Praxisbeispiele: Bugs & Discounts, Eiskonsum & Kriminalität, Salzgehalt & Flussmenge Wichtig: Confounder identifizieren und herausrechnen, z. B. durch Zeitreihenzerlegung Einführung in Double ML: ML-Modelle für Response und Treatment, Effektschätzung über Residuen Herausforderungen: Overfitting-Bias, Regularisierung, verzerrte Effekte bei hoher Komplexität Alternativen & Ergänzungen: A/B-Tests, strukturelle Gleichungsmodelle, Kausaldiagramme Fazit: Vorsicht bei Spurious Correlations, Ceteris-paribus-Fallen und Feature-Interpretation - Kausalität braucht Kontext und Methode **Links** Blogartikel von Scott Lundberg: Be Careful When Interpreting Predictive Models in Search of Causal Insights https://medium.com/data-science/be-careful-when-interpreting-predictive-models-in-search-of-causal-insights-e68626e664b6 ICECREAM-Datensatz (verfügbar über das tsapp R-Paket): https://search.r-project.org/CRAN/refmans/tsapp/html/ICECREAM.html Victor Chernozhukov et al. (2018): Double/debiased machine learning for treatment and structural parameters, The Econometrics Journal, Volume 21, Issue 1 https://doi.org/10.1111/ectj.12097 Matheus Facure Alves (2022): Causal Inference for The Brave and True (kostenfreies Online-Buch) https://matheusfacure.github.io/python-causality-handbook/landing-page.html DoubleML (Python & R): https://docs.doubleml.org/stable/index.html EconML (Microsoft Research): https://econml.azurewebsites.net/index.html Causal ML (Uber Engineering): https://causalml.readthedocs.io/en/latest/ Vortragsfolien von Prof. Dr. Steffen Wagner: "Navigating the Ocean of Correlations to the Islands of Causality – Time Series Analyses at its Best", gehalten bei der Machine Learning Week München 2024 https://de.slideshare.net/secret/aArFURFQSBxrzB   📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Wir sprechen mit Noah Hollman von Prior Labs, einem der Schöpfer von TabPFN (Tabular Prior Fitted Network), über dieses bahnbrechende Foundation-Modell für tabulare Daten. In der Diskussion geht es um die Funktionsweise von TabPFN, die Rolle von In-Context Learning, die Herausforderungen bei der Anwendung der Transformer-Architektur auf tabulare Daten sowie die Generierung synthetischer Daten mit strukturellen kausalen Modellen (SCMs). Darüber hinaus beleuchten wir die beeindruckenden Benchmarking-Ergebnisse und zusätzliche Features des Modells. Zum Ende hin sprechen wir über die offenen Herausforderungen von Prior Labs und welche "Moonshots" sie für die Zukunft planen.   **Zusammenfassung:** TabPFN ist ein Modell für Vorhersagen auf tabellarischen Daten, entwickelt von Prior Labs Es nutzt In-Context Learning, um Aufgaben durch Sequenzen von Daten zu lernen, und wurde speziell für die Transformer-Architektur angepasst TabPFN wurde mit 100 Millionen synthetischen Datensätzen, die durch strukturelle kausale Modelle (SCMs) generiert wurden, trainiert Es stellt einen neuen Benchmark dar und liefert starke Leistungen über verschiedene Domänen hinweg Das Modell kann Unsicherheiten quantifizieren, mit fehlenden Werten umgehen und Outlier erkennen TabPFN ist auf Consumer-Hardware trainierbar, was die Entwicklung auch auf kleinen GPUs ermöglicht Zukünftige Entwicklungen fokussieren sich auf Zeitreihen, Kausalität und multimodale Modelle   **Links:** Blog: TabPFN: Die KI-Revolution für tabulare Daten https://www.inwt-statistics.de/blog/tabpfn-die-ki-revolution-fuer-tabulare-daten Nature Publikation zu tabPFN aus 2025: https://www.nature.com/articles/s41586-024-08328-6 Artikel über tabPFN  in Fortune: https://fortune.com/2025/02/05/prior-labs-9-million-euro-preseed-funding-tabular-data-ai/ Nature News & views von Duncan C. McElfresh: https://www.nature.com/articles/d41586-024-03852-x Zeit für Unternehmer: https://www.zeit.de/zeit-fuer-unternehmer/2025/01/kuenstliche-intelligenz-tabpfn-tabellen-daten?freebie=a67d9166 Publikation zu tabICL: https://arxiv.org/abs/2502.05564 früher Hintergrund-Artikel zur Transformers Architektur für Bayesianische Inferenz : https://arxiv.org/abs/2112.10510 früheres Working Paper zu tabPFN: https://arxiv.org/abs/2207.01848 GitHub Repo zu tabPFN: https://github.com/PriorLabs/TabPFN Homepage Prior Labs: https://priorlabs.ai/ #71: Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek https://www.podbean.com/ew/pb-p2wjd-1897b7e Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de

In dieser Folge geht's um die Frage: Macht Größe von Large Language Models (LLMs) bei Predictive Analytics wirklich einen Unterschied? Wir vergleichen Open-Source-Modelle mit bis zu 70 Milliarden Parametern – und siehe da, das 8B-Modell schlägt das große Schwergewicht. Außerdem berichten wir vom Finetuning auf einer AWS-Maschine mit 8 A100-GPUs und den Herausforderungen in Bezug auf die Reproduzierbarkeit. Auch das viel diskutierte DeepSeek-Modell haben wir im Autopreis-Benchmark antreten lassen. Und wie immer fragen wir uns: Was ist praktisch und was ist overkill?   **Zusammenfassung** Modellgröße ≠ bessere Prognosen: Das Llama-3.1-8B übertraf das größere 70B-Modell bei der Fahrzeugpreisprognose DeepSeek im Benchmark: Das chinesische Modell zeigt bei größeren Trainingsmengen eine ähnlich gute Performance wie das Llama-3.1-8B, ist bei kleinen Datensätzen aber schwächer Finetuning mit Multi-GPU auf AWS: Für das 70B-Modell war ein Setup mit 8 A100-GPUs nötig Reproduzierbarkeit bleibt schwierig: Trotz Seed erzeugen wiederholte Finetuning-Runs unterschiedliche Ergebnisse Modellselektion empfohlen: Um zuverlässige Prognosen zu erhalten, sollte aus mehreren Finetuning-Durchläufen das beste Modell ausgewählt werden CPU-Inferenz möglich, aber langsam: Im Vergleich zur GPU war die Vorhersage auf der CPU ca. 30-mal langsamer, Quantisierung könnte künftig Abhilfe schaffen Ausblick auf TabPFN & Quantisierung: Kommende Beiträge widmen sich Erfahrungen mit TabPFN und der praktischen Umsetzung von quantisierten LLMs auf kleineren Maschinen **Links** [Begleitender Blogartikel] Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek https://www.inwt-statistics.de/blog/predictive-llms-skalierung-reproduzierbarkeit-und-deepseek #50: Predictive Analytics mit LLMs: ist GPT3.5 besser als XGBoost? https://inwt.podbean.com/e/50-predictive-analytics-mit-llms-ist-gpt35-besser-als-xgboost/ #64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen https://inwt.podbean.com/e/64-predictive-llms-ubertreffen-open-source-modelle-jetzt-openai-und-xgboost-bei-preisprognosen/ vLLM Framework für schnelle Inferenz: https://github.com/vllm-project/vllm?tab=readme-ov-file torchtune Finetuning-Framework von PyTorch: https://github.com/pytorch/torchtune PyTorch Reproducibility: https://pytorch.org/docs/stable/notes/randomness.html Paper zur Reproduzierbarkeit von QLoRA-Finetuning: S. S. Alahmari, L. O. Hall, P. R. Mouton and D. B. Goldgof, "Repeatability of Fine-Tuning Large Language Models Illustrated Using QLoRA," in IEEE Access, vol. 12, pp. 153221-153231, 2024, doi: 10.1109/ACCESS.2024.3470850 https://ieeexplore.ieee.org/document/10700744 heise online: Komprimierte KI: Wie Quantisierung große Sprachmodelle verkleinert von René Peinl https://www.heise.de/hintergrund/Komprimierte-KI-Wie-Quantisierung-grosse-Sprachmodelle-verkleinert-10206033.html deepseek-ai/DeepSeek-R1-Distill-Llama-8B auf Huggingface https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Llama-8B#6-how-to-run-locally TabPFN: Hollmann, N., Müller, S., Purucker, L. et al. Accurate predictions on small data with a tabular foundation model. Nature 637, 319–326 (2025). https://doi.org/10.1038/s41586-024-08328-6  Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de

Wie datenreif ist dein Unternehmen eigentlich? Wir sprechen über die fünf Stufen der Data Maturity – von manueller Datensammlung bis zur KI als Teil der Unternehmenskultur. Dabei geht es auch um die Rolle der Organisation, warum viele beim „Death by Dashboards“ hängenbleiben und wie man echte Fortschritte macht. Und wir diskutieren, welche Abkürzungen auf diesem Weg funktionieren – und welche eher nach hinten losgehen.   **Zusammenfassung** Data Maturity Skala: Fünf Stufen von manueller Datennutzung bis zu datengetriebener Kultur mit AI/ML – viele Unternehmen stecken noch in den unteren Bereichen fest Organisationskultur als Schlüssel: Kultur bestimmt maßgeblich, wie datenreif ein Unternehmen wird – HiPPO-Denke (Highest Paid Person's Opinion), Risikoaversion und fehlende Offenheit sind häufige Bremsklötze Typische Hürden: Datensilos, fehlendes Qualitätsbewusstsein, "Death by Dashboards" und Projekte ohne echten Erkenntnisgewinn Aufbau von Datenreife: Kombination aus Top-Down-Initiativen und Bottom-up-Leuchtturmprojekten, ergänzt durch agile Vorgehensweise PoC → MVP → Produkt: Datenprojekte sollten in kurzen, klar umrissenen Phasen geplant und bei fehlendem Nutzen auch konsequent gestoppt werden Abkürzungen und Workarounds: Externe Daten, simulierte Daten oder cloudbasierte Infrastruktur können helfen – bergen aber auch Risiken für Aussagekraft und Akzeptanz Data Mesh & Self-Service BI: Nur sinnvoll bei entsprechender Datenkultur – sonst droht mehr Chaos als Erkenntnisgewinn   **Links** Maturity Model mit 5 Stufen von Gartner: Gartner Survey Shows Organizations Are Slow to Advance in Data and Analytics https://www.gartner.com/en/newsroom/press-releases/2018-02-05-gartner-survey-shows-organizations-are-slow-to-advance-in-data-and-analytics #61: Technologische Must-Haves: Unser Survival-Guide für Data-Science-Projekte https://www.podbean.com/ew/pb-k6fx5-175ea51 #36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1 Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de

AI Agents sind mehr als nur Chatbots – aber wie bewertet man sie richtig? Wir sprechen über die Herausforderungen beim Testen von AI im Kundenservice, warum falsche API-Parameter ins Chaos führen und wieso "mysteriöser Fleischeintopf" ein PR-Desaster wurde. Matthäus Deutsch von Parloa berichtet, wie flexible Plattformintegrationen und evaluative Ansätze (z.B. assertion-based Testing und Simulationen) den Einsatz von AI Agents vorantreiben. Außerdem: welche Metriken wirklich zählen, was Multi-Agent-Setups leisten und warum der Preisverfall bei Open-Source-Modellen das Game verändert.    Zusammenfassung AI Agents erweitern klassische Chatbots im Kundenservice, insbesondere im Telefonbereich, durch GenAI-basierte, dynamische Lösungen Parloa demonstriert flexible Plattformintegrationen und den Einsatz von Evaluationsmethoden wie assertion-based Testing und Simulationen Die Evaluation von AI Agents erfordert spezielles Benchmarking auf Plattform- und individueller Ebene Typische Herausforderungen sind Integrationsprobleme, fehlerhafte API-Calls und unzureichendes Instruction Following Tests erfolgen sowohl auf Konversationsebene als auch durch deterministische Ansätze und LLMs als Judge Es müssen komplexe Metriken und Trade-offs beachtet werden, wobei häufig binäre Testansätze aggregiert werden Schnelle Updates auf neue Modellversionen sind möglich, allerdings steigen langfristig die Kosten durch umfangreiche Testzyklen Innovationen wie optimierte Speech-to-Speech-Technologien und Open-Source-Lösungen (z. B. DeepSeek) bieten Potenzial zur Kostenreduktion Der Einsatz von Operatoren-Modellen und Tool-Integrationen ermöglicht auch die Anbindung an Legacy-Systeme, z.B. SAP Ziel ist es, den Automatisierungsanteil im Kundenservice zu erhöhen und eine Balance zwischen bewährter Qualität und neuen Features zu finden Links Matthäus Deutsch auf LinkedIn: https://www.linkedin.com/in/matth%C3%A4us-d-928864ab/ Parloa Contact-Center-AI-Plattform https://www.parloa.com/de/ Stellenangebote bei Parloa https://www.parloa.com/company/careers/#jobs #55: Alle machen XGBoost, aber was macht eigentlich XGBoost? Mit Matthäus Deutsch https://www.podbean.com/ew/pb-6gvc6-16d5018 #64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen? https://www.podbean.com/ew/pb-m5qr2-17c425d heise online: "Aromatisches" Chloramingas, Eintopf aus Menschenfleisch: KI-Rezepte irritieren https://www.heise.de/news/Aromatisches-Chlorgas-Eintopf-aus-Menschenfleisch-KI-irritiert-mit-Rezepten-9242991.html Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de

Daten(banken) versionieren – klingt maximal unsexy, spart aber Stress im Deployment. Warum ohne Schema-Versionierung selbst kleine Änderungen große Probleme verursachen und was ORMs, Flyway oder Liquibase damit zu tun haben, erfahrt ihr hier. Daten historisieren ist ein Must-have für Compliance, Reproduzierbarkeit und Modellierung. Aber Achtung: Nicht jede Lösung passt für jede Datenbank und den Live-Betrieb. Wir geben Tipps, wie ihr eure Datenprodukte systematisch und effizient im Griff behaltet. **Zusammenfassung** Schema-Versionierung ist essenziell, um Änderungen an Datenbanken nachvollziehbar und reibungslos ins Deployment einzubinden Fehlende Versionierung kann zu kaputten Prozessen führen, wenn Schema-Änderungen nicht dokumentiert und automatisiert umgesetzt werden Werkzeuge wie ORMs, Flyway oder Liquibase helfen dabei, Änderungen an Datenbankschemata strukturiert zu verwalten Historisierung von Daten ist für Compliance, Reproduzierbarkeit und Modellierung entscheidend   Ansätze zur Datenhistorisierung: Append-only-Strategien vs. System-Versionierung Herausforderungen: Performance-Engpässe, hohe Pflegekosten und Kompatibilitätsprobleme je nach Datenbank und Migrationstool   Best Practices: Versionierung systematisch einführen, Automatisierung priorisieren und sicherstellen, dass Downgrades funktionieren.   **Links** #58: Arm, aber sexy: Data Warehousing at Scale ohne Budget https://www.podbean.com/ew/pb-gywt4-1719aef #52: In-process Datenbanken und das Ende von Big Data https://www.podbean.com/ew/pb-tekgi-16896e4 #36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1 Flyway: https://www.red-gate.com/products/flyway/ Liquibase: https://www.liquibase.com/ Alembic (für SQLAlchemy): https://alembic.sqlalchemy.org/en/latest/ MariaDB: https://mariadb.org/ ClickHouse: https://clickhouse.com/ Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

Dieser Satz "it works on my machine" hat IT-Teams und Data Scientists lange Nerven gekostet. Früher war Deployment ein mühsames Zusammenspiel aus Setup-Anleitungen, inkompatiblen Umgebungen und endlosen Rückfragen. Docker bringt endlich Ordnung ins Chaos: Anwendungen laufen isoliert, reproduzierbar und unabhängig vom Host-System. Warum Containerisierung für Data Science ein echter Gamechanger ist und welche Best Practices du kennen solltest, erfährst du in dieser Folge!   Zusammenfassung  Früher war Deployment umständlich: lange Setup-Anleitungen, inkompatible Umgebungen, viele Rückfragen  Virtuelle Maschinen haben das Problem teilweise gelöst, sind aber ressourcenintensiv und unflexibel Data Scientists arbeiten oft mit R/Python, was IT-Abteilungen vor Herausforderungen stellt Fehlende Reproduzierbarkeit führt zu Stress, Verzögerungen und hohem Kommunikationsaufwand Docker schafft eine standardisierte, isolierte und reproduzierbare Umgebung für Anwendungen Container laufen direkt auf dem Host-OS, sind schlanker als VMs und starten schneller Mit Dockerfiles lassen sich Umgebungen als Code definieren und automatisch deployen Best Practices: schlanke Base-Images, .dockerignore, nur benötigte Abhängigkeiten installieren Automatisierung mit CI/CD-Pipelines beschleunigt den Entwicklungs- und Deploy-Prozess Containerisierung ist für moderne Data-Science-Workflows unverzichtbar und spart IT sowie Data Science viel Zeit Links Offizielle Docker Dokumentation https://docs.docker.com/ Docker Hub https://hub.docker.com/ [Blog] Die Welt der Container: Einführung in Docker https://www.inwt-statistics.de/blog/die-welt-der-container-einfuehrung-in-docker [Podcast] #14: Kubernetes https://www.podbean.com/ew/pb-m5ggz-13454c7 [Podcast] #59: Besser mit Helm: komplexe Deployments einfach(er) umsetzen https://www.podbean.com/ew/pb-txhnf-17314de [Video] Solomon Hykes stellt Docker vor (2013) "The future of Linux Containers" https://www.youtube.com/watch?v=wW9CAH9nSLs&t=158s Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

Warum knirscht es immer wieder zwischen Data Scientists und Developern? In dieser Episode holen wir uns Verstärkung von Andy und Wolfi vom Engineering Kiosk Podcast um dieser Frage auf den Grund zu gehen. Wir reden über typische Klischees und warum diese zu Konflikten führen. Gemeinsam sprechen wir darüber, welche Skills helfen, damit beide Spezies am Ende harmonisch zusammenarbeiten können – statt sich gegenseitig auszubremsen. Zusammenfassung Klischees und Konflikte: Stereotype über Data Scientists (Jupyter-Fans, Doktortitel) und Developer (Perfektionismus, Black-Box-Furcht) Teamorganisation: Cross-funktionale Teams vs. getrennte Abteilungen (Vor- und Nachteile, Agenturmodell) Typische Herausforderungen: Übergabe von Prototypen an die Entwicklung, Verständnis von SLAs/Responsezeiten, Datenbankauswahl Skill-Set und Zusammenarbeit: Generalistisches Grundwissen in DevOps und Softwarearchitektur, offenes Mindset Links Engineering Kiosk Podcast: https://engineeringkiosk.dev/ Andy Grunwald auf LinkedIn: https://www.linkedin.com/in/andy-grunwald-09aa265a/ Wolfgang Gassler auf LinkedIn: https://www.linkedin.com/in/wolfganggassler/ [Engineering Kiosk] #179 MLOps: Machine Learning in die Produktion bringen mit Michelle Golchert und Sebastian Warnholz https://engineeringkiosk.dev/podcast/episode/179-mlops-machine-learning-in-die-produktion-bringen-mit-michelle-golchert-und-sebastian-warnholz/ [Engineering Kiosk] #178 Code der bewegt: Infotainmentsysteme auf Kreuzfahrtschiffen mit Sebastian Hammerl https://engineeringkiosk.dev/podcast/episode/178-code-der-bewegt-infotainmentsysteme-auf-kreuzfahrtschiffen-mit-sebastian-hammerl/ [Engineering Kiosk] #177 Stream Processing & Kafka: Die Basis moderner Datenpipelines mit Stefan Sprenger https://engineeringkiosk.dev/podcast/episode/177-stream-processing-kafka-die-basis-moderner-datenpipelines-mit-stefan-sprenger/ [Data Science Deep Dive] #30: Agile Softwareentwicklung im Data-Science-Kontext https://www.podbean.com/ew/pb-mvspn-1482ea4 [Data Science Deep Dive] #23: Unsexy aber wichtig: Tests und Monitoring https://www.podbean.com/ew/pb-vxp58-13f311a [Data Science Deep Dive] #20: Ist Continuous Integration (CI) ein Muss für Data Scientists? https://www.podbean.com/ew/pb-4mkqh-13bb3b3 Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

Punktprognosen sind was für Leute, die gerne enttäuscht werden ;) Wir befassen uns in dieser Episode mit der Quantifizierung und Kommunikation von Unsicherheit bei Prognosen. Dabei gehen Mira und Amit auf klassische Statistik, Bayes-Methoden, Machine Learning, Bootstrapping und Conformal Predictions ein. Außerdem gehen sie auf Herausforderungen der Data Literacy und bei rechenintensiven Ansätzen zur Bestimmung der Unsicherheit ein. Zusammenfassung Warum Unsicherheiten unverzichtbar sind (Beispiel Wetter-, Wahl-, Bewerberprognosen) Klassische Statistik: Konfidenzintervall vs. Prediction Intervall Bayesianische Sicht: Glaubwürdigkeitsintervalle ML-Methoden ohne Verteilungsannahmen: Bootstrapping & Conformal Predictions Rechenaufwand vs. Modellannahmen Data Literacy als Schlüssel zum richtigen Interpretieren von Prognoseintervallen Praxisnahe Beispiele und Entscheidungshilfen Links #10: Signifikanz https://www.podbean.com/ew/pb-y25ti-12fab65 #44: Lineare Regression in der Praxis – Oldie oder Goldie? https://www.podbean.com/ew/pb-jiecf-15d0ac1 #56: Unsere Bundestagswahl-Prognose: Wer gewinnt die Wahl 2025? https://www.podbean.com/ew/pb-hwgnd-16e446e Wer gewinnt die Bundestagswahl 2025? www.wer-gewinnt-die-wahl.de Molnar (2023): Introduction To Conformal Prediction With Python. A Short Guide For Quantifying Uncertainty Of Machine Learning Models. Sammlung von Ressourcen zu Conformal Predictions https://github.com/valeman/awesome-conformal-prediction/ Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de