Back

Explore every episode of the podcast Data Science Deep Dive

Dive into the complete episode list for Data Science Deep Dive. Each episode is cataloged with detailed descriptions, making it easy to find and explore specific topics. Keep track of all episodes from your favorite podcast and never miss a moment of insightful content.

Rows per page:

1–50 of 100

TitlePub. DateDuration
#98: Risiken bei der Softwareentwicklung mit AI Agents16 Jul 202600:49:17

Sebastian und Liel setzen die Folge #91 zur Zukunft der Softwareentwicklung fort und widmen sich diesmal den Risiken beim Einsatz von AI Agents. Sie ordnen ein, welche Gefahren beim lokalen Arbeiten mit Agents tatsächlich bestehen – von autonom ausgeführten Befehlen mit Datenverlust über Prompt Injection bis zur Weitergabe sensibler Daten an externe Modelle. Im zweiten Teil geht es um konkrete Strategien zur Risikominimierung: durchdachte Berechtigungen, Repository-scoped Tokens, isolierte Workspaces mit Dev-Containern oder Mini-VMs sowie eine bewusste Auswahl der eingesetzten Modelle. Zum Abschluss diskutieren die beiden, wohin sich die Arbeit mit Coding-Agents entwickelt und welche Rolle Reviews und Wartbarkeit dabei spielen. Ein "sicher" gibt es dabei nicht, wohl aber ein "sicherer".

 

**Zusammenfassung**

  • AI Agents führen im YOLO-Mode Code direkt auf dem eigenen System aus – Datenverlust durch unbedachte Befehle ist ein reales Risiko.
  • Prompt Injection kommt über README-Anweisungen, MCP-Server und Webfetch ins System; halluzinierte Library-Namen lassen sich durch Squatting für Schadcode ausnutzen.
  • Die "lethal trifecta" beschreibt die kritische Kombination aus Zugriff auf private Daten, Verarbeitung nicht vertrauenswürdiger Inhalte und Möglichkeit zur Kommunikation nach außen.
  • Kompromittierung betrifft Credentials, proprietären Code und personenbezogene Daten – jede Query an ein extern gehostetes Modell verlässt das eigene System.
  • Default-Konfigurationen (OpenCode, VSCode + GitHub Copilot) sind ein häufiger Stolperstein, da Daten oft standardmäßig zum Training genutzt werden.
  • Zur Absicherung helfen fein eingestellte Berechtigungen, Repository-scoped Tokens, Provisionierung im Unternehmen und isolierte Workspaces (Dev-Container, VibePod, nono).
  • Bei der Modellauswahl lohnt der Blick auf Selfhosting sowie europäische bzw. offene Alternativen wie Mistral und das Schweizer Apertus.
  • Traceability, Live- und Kostenmonitoring werden wichtiger, da Agents Tokenverbrauch und Aktionen kaum noch kontrollierbar machen.

 

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#97: Die Güte von Gen-AI-Projekten bewerten mit Tobias Sterbak02 Jul 202600:47:57

Wie misst man die Qualität von Gen-AI-Projekten, wenn der Output selten eindeutig richtig oder falsch ist und ein Ground Truth oft fehlt? Auf Anregung unserer Hörerin Andrea sprechen Mira und Tobias darüber, warum die Evaluation generativer Anwendungen ein Umdenken gegenüber klassischen ML-Projekten erfordert. Sie stellen verschiedene Ansätze vor – von klassischem Testen über Goldstandard-Datensätze und "LLM as a Judge" bis zu Similarity-Metriken und User Testing – und ordnen deren Stärken und Schwächen ein. Außerdem geht es um den Umgang mit Spezial- und Off-Topic-Fällen, Manipulationsversuche, Red-Teaming und die Frage, wie groß ein Goldstandard eigentlich sein sollte. Das Fazit: Es gibt keine Faustformel, dafür rücken Domänenverständnis, Produktfokus und Risikomanagement stärker in den Mittelpunkt.

 

**Zusammenfassung**

  • Umdenken nötig: Bei Gen-AI ist der Output oft nicht klar richtig oder falsch, was klassische Evaluationslogik an ihre Grenzen bringt
  • Frühe Validierung mit Endnutzenden ist sinnvoll und oft erforderlich, weil man schnell etwas Vorzeigbares hat
  • Klassisches Testen funktioniert weiterhin, wo es fixe Metriken oder einen Goldstandard gibt; ein schrittweiser oder verdeckter Rollout liefert früh Ergebnisse
  • LLM as a Judge: gut automatisierbar, aber korreliert oft schlecht mit menschlicher Einschätzung; ein Ensemble mehrerer Modelle kann helfen
  • Similarity-Metriken wie Cosine Similarity eignen sich als günstiger Vorfilter, bevor der teure LLM-Judge läuft
  • User Testing über Testmatrix, Testszenarien und Testpersonas ist aussagekräftig, aber aufwändig und bei jeder Änderung erneut nötig
  • Spezialfälle absichern: Umgang mit Off-Topic-, Nonsense- und Manipulationsversuchen, Red-Teaming und ein kleiner Standard-Datensatz als Sanity-Check
  • Fazit: keine Faustformel – das Skillset wird breiter, Domänenverständnis und Produktfokus wichtiger, Risikomanagement rückt in den Vordergrund

**Links**

 

 Fragen, Feedback oder Themenwünsche?

Schreibt uns gern an: podcast@inwt-statistics.de
#96: Queer Data: Wie erfasst, bereinigt und analysiert man sensible Daten?18 Jun 202600:32:09

Pünktlich zum Pride Month widmen sich Mira und Liel der Frage, was bei der Arbeit mit sensiblen personenbezogenen Daten am Beispiel queerer Daten zu beachten ist. Sie gehen die drei Phasen Datenerfassung, -bereinigung und -analyse durch und zeigen, wie schon die Wahl von Kategorien die Realität beeinflusst und wie sich Diskriminierung in Daten und Algorithmen fortschreibt. Ein Schwerpunkt liegt auf dem Umgang mit sehr kleinen Gruppen, für die sich statistisch oft wenig ableiten lässt, und auf möglichen Lösungen wie Oversampling oder qualitativen Methoden. Die Episode macht deutlich, dass es keine einzelne richtige Lösung gibt, sondern bewusste Entscheidungen und Mitdenken gefragt sind. Die besprochenen Überlegungen gelten über Queerness hinaus auch für andere Kategorien sozialer Ungleichheit und das Thema Intersektionalität.

 

**Zusammenfassung**

  • Begriffsklärung: Was "queer" bedeutet, von der ursprünglichen Beleidigung zur positiven Selbstbezeichnung, und der Bezug zu LGBTQIA+
  • Datenerfassung: Was man erfasst, hängt vom Kontext ab (Sex in der Medizin, Gender beim Verhalten, sexuelle Orientierung im Marketing)
  • Kategorien sind nicht neutral: Sie prägen, wie Menschen sich wahrnehmen, wie Umfragen ankommen und ob man Diskriminierung überhaupt messen kann
  • Repräsentativität: Wie prüft man sie, wenn die Gruppengröße unbekannt ist – etwa über bayesianische Ansätze mit Annahmen, die durch Daten aktualisiert werden
  • Datenbereinigung: Schon wenige Fehleingaben verzerren kleine Gruppen stark, wie das Beispiel der US-Zensusdaten zeigt
  • Umgang mit kleinen Gruppen: Optionen sind große Datenmengen, Oversampling, qualitative Methoden oder zumindest transparentes Berichten
  • Analyse: Algorithmen reproduzieren und skalieren bestehende Biases und sind nicht automatisch neutral; das Weglassen einzelner Merkmale löst das Problem nicht (Proxy-Variablen)
  • Fazit: Es gibt keine technische Patentlösung gegen Diskriminierung – entscheidend sind bewusste Entscheidungen, Mitdenken und der Blick auf Intersektionalität

 

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#95: GitOps: Deployments mit Ruhepuls04 Jun 202600:27:57

GitOps ist ein DevOps-Ansatz, bei dem der Betrieb von Services als Code in Git abgelegt und versioniert wird, statt Deployments manuell über Oberflächen zusammenzuklicken. In dieser Episode erklären Mira und Andreas, was GitOps ausmacht, wie sich der deklarative Ansatz vom klassischen imperativen Vorgehen unterscheidet und wo die Abgrenzung zu Infrastructure as Code verläuft. Sie sprechen über die Vorteile – etwa Nachvollziehbarkeit, Versionskontrolle, Automatisierung und geringere Fehleranfälligkeit – ebenso wie über Herausforderungen rund um Secrets-Management und das nötige Umdenken. Außerdem ordnen sie ein, wann sich der Einsatz lohnt und wann manuelles Vorgehen sinnvoller bleibt. Den Abschluss bildet ein Hands-on-Teil mit konkreten Einstiegsschritten und Werkzeugen wie ArgoCD.

 

**Zusammenfassung**

  • Was GitOps ist: Betrieb von Services als versionierter Code in Git, inklusive Konfiguration und laufender Versionen
  • Beispiel API-Deployment: früher alles in der Pipeline, heute ein separates Repo, das den gewünschten Zustand beschreibt und von Tools wie ArgoCD mit dem Cluster abgeglichen wird
  • Abgrenzung zu Infrastructure as Code: GitOps fokussiert die laufenden Services statt der Infrastruktur und gleicht Änderungen aktiv und kontinuierlich an
  • Vorteile: Dokumentation, Rollback per Versionskontrolle, Automatisierung, weniger Fehler, Review-Möglichkeit und gemeinsame Verwaltung mehrerer Service-Versionen
  • Herausforderungen: Umstieg von imperativ auf deklarativ, schwierigeres Debugging, alles muss in Git liegen, Secrets brauchen ein zusätzliches Tool
  • Wann sinnvoll: ab MVP fast immer; bei kurzlebigen PoCs ruhig manuell oder per Pipeline
  • Einstieg: mit neueren, einfacheren Projekten starten, ArgoCD installieren und schrittweise komplexer werden (dev/prod, mehrere Services)
  • Fazit: kurze Einarbeitung, dann lohnt es sich – inzwischen etablierter Standard und "Deployments mit Ruhepuls"

**Links**

📬 Fragen, Feedback oder Themenwünsche?

Schreibt uns gern an: podcast@inwt-statistics.de

#94: [PAIQ4] Predictive AI Quarterly21 May 202600:37:41

In dieser Ausgabe des Predictive AI Quarterly geben Till und Amit einen Überblick über die wichtigsten Entwicklungen des letzten Quartals im Bereich Predictive AI. Themen sind unter anderem Hyper-Agents von Meta, praktische Herausforderungen beim Einsatz von Coding-Agents sowie neue Foundation-Modelle für tabellarische Daten wie TabImpute und TabICL v2. Im Praxisteil teilen die beiden ihre Erfahrungen aus einem Experiment zur Preisprognose von Autos, bei dem GPT-4o mit Bildern und Freitext gegen TabPFN antritt. Im Zentrum stehen dabei der Mehrwert unstrukturierter Daten, Fragen der Generalisierbarkeit und der Tradeoff zwischen Erklärbarkeit und Prognosegüte.

 

**Zusammenfassung**

  • Hyper-Agents von Meta: selbstevaluierende Agenten mit Potenzial für schnelleren Fortschritt, aber auch Risiken durch fehlende Kontrolle und verstärkte Biases
  • Praktischer Einsatz von Coding-Agents: Subscriptions, Sandboxing, Audit Logs und Ausschluss kritischer Artefakte als Voraussetzungen
  • Erfahrungen mit dem GitHub Cloud Agent, insbesondere bei der Überarbeitung bestehenden Codes
  • TabImpute als neues Foundation-Modell für Imputation auf Basis von TabPFN inklusive eigenem Benchmark
  • TabICL v2 als offen lizenzierte Alternative zu TabPFN mit schnellerer Inferenz
  • Praxis-Experiment zur Preisprognose von Autos: GPT-4o mit Bildern erzielt die besten Ergebnisse, deutlich vor TabPFN
  • Generalisierbarkeit bestätigt durch 30-fache Kreuzvalidierung mit einem aus Bildern erzeugten Score-Feature
  • Tradeoff zwischen Erklärbarkeit (Feature-Generierung) und Prognosegüte (Finetuning) als zentrale Erkenntnis

 

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#93: Bayesianische Statistik: Vorwissen und Daten kombinieren07 May 202600:33:31

In dieser Episode sprechen Mira und Amit über die Grundlagen der bayesianischen Statistik und zeigen anhand der Wahlprognose für die Bundestagswahl, wie sich Vorwissen und neue Daten zu einer aussagekräftigen Posterior-Verteilung kombinieren lassen. Sie erklären die zentralen Begriffe Prior, Likelihood und Posterior und ordnen ein, wie sich Kredibilitätsintervalle von klassischen Konfidenzintervallen unterscheiden. Außerdem gehen sie auf praktische Anwendungsfälle wie A/B-Testing ein und diskutieren, warum der bayesianische Ansatz trotz seiner Vorteile nicht immer die erste Wahl ist.

**Zusammenfassung**

  • Einstiegsbeispiel Wahlprognose: Stichprobenunsicherheit trifft auf Vorwissen über realistische Stimmanteile
  • Bayes-Theorem als Grundlage: Posterior ist proportional zu Likelihood mal Prior
  • Prior-Verteilungen: informative Priors aus Vorwissen vs. nicht-informative Priors
  • Interpretation der Posterior: Erwartungswert, Wahrscheinlichkeit für Effekte über einem Schwellenwert, Kredibilitätsintervalle
  • Unterschied zur frequentistischen Statistik: p-Werte und Konfidenzintervalle vs. intuitiv interpretierbare Wahrscheinlichkeitsaussagen
  • Praxisbeispiele: A/B-Testing mit Vorwissen aus früheren Tests, Robustheitsprüfungen, Einsatz bei Google
  • Vorteile: intuitive Interpretation, Nutzung von Vorwissen, sinnvolle Ergebnisse auch bei kleinen Stichproben
  • Nachteile: hoher Rechenaufwand durch Monte-Carlo-Simulationen, geringere Verbreitung, nicht immer existiert ein sinnvoller Prior

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#92: Anomaly Detection von Produktbildern mit ClickHouse23 Apr 202600:46:51

In dieser Episode geht es um die Anomaly Detection von Produktbildern in einem realen Produktions-Use-Case – von der Problemstellung bis zur Umsetzung in ClickHouse. Wir zeigen, wie sich fehlerhafte Produkterkennungen mithilfe von Embeddings und Distanzmaßen identifizieren lassen, ohne auf aufwendige gelabelte Daten angewiesen zu sein. Der Fokus liegt auf einer pragmatischen, performanten Lösung direkt in der ClickHouse-Datenbank, die Anomalien in Millisekunden erkennt und gleichzeitig die Datenqualität für das Modelltraining verbessert. Außerdem diskutieren wir Trade-offs zwischen Einfachheit, Performance und Entwicklungsaufwand sowie Learnings aus dem Projekt.

 

**Zusammenfassung**

  • Use Case: Automatische Produkterkennung auf Basis von Videostreams mit Fehlerquote (~ 5%)
  • Problem: Falsche Zuordnungen durch Störkörper, Überlagerungen und ungünstige Perspektiven
  • Ziel: Identifikation unsicherer Vorhersagen zur manuellen Prüfung und sauberen Trainingsdaten
  • Ansatz: Unsupervised Anomaly Detection mittels Embeddings und Distanz zum Clusterzentrum
  • Methode: K-Means-Logik – große Distanz --> geringe Zuordnungs-Sicherheit
  • Threshold: 2 x Standardabweichung identifiziert ~ 90% der Anomalien (bewusster Trade-off)
  • Umsetzung: Echtzeit-Berechnung direkt in ClickHouse über Materialized Views
  • Vorteil: Keine zusätzliche Infrastruktur (z.B. Kafka), sehr geringe Latenz (< 1 Sekunde)
  • Nachteil: Trennung zwischen Entwicklung (Python) und Produktion (SQL/ClickHouse)

 

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#91: Software ohne Entwickler*innen? Wie AI Agents unsere Arbeit neu definieren09 Apr 202600:46:55

Agentic AI verändert die Art, wie Software entsteht und stellt bestehende SaaS- und Subscription-Modelle zunehmend infrage. Im Fokus stehen AI-Agents, die in Think-Act-Observe-Loops eigenständig handeln und Entwicklungsprozesse automatisieren. Besonders im Data-Science-Umfeld zeigen sich Chancen im Prototyping, aber auch Herausforderungen durch langsame Tests, komplexe Datenpipelines und fehlende Qualitätsmetriken. Entscheidend für den erfolgreichen Einsatz sind klare Aufgabenabgrenzung, kleine Iterationen und robuste Guardrails wie Tests und Linter. Gleichzeitig verschieben sich Rollenprofile hin zu mehr konzeptioneller Arbeit, während Fragen zu Sicherheit, Souveränität und langfristiger Wartbarkeit offen bleiben.

 

**Zusammenfassung**

  • SaaS- und Subscription-Modelle geraten durch AI-getriebene Eigenentwicklung unter Druck
  • Evolution: Chat --> Copilot --> Agentic AI mit autonomen Fähigkeiten
  • AI-Agents arbeiten in Think-Act-Observe-Loops und können aktiv handeln
  • Aktuelle Tools vor allem in Terminal-Umgebungen (CLI-basiert)
  • Kleine, klar definierte Aufgaben erhöhen Erfolgswahrscheinlichkeit
  • Guardrails (Tests, Linter, Typisierung) sind essenziell für Qualität
  • Prototyping funktioniert gut, produktiver Einsatz noch eingeschränkt
  • Data Science leidet unter langsamen Tests und langen Iterationszyklen
  • Custom Stacks aktuell im Vorteil gegenüber Plattformlösungen
  • Offene Themen: Sicherheit, Datenzugriff, Abhängigkeit von LLM-Anbietern

 

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#90: Demand Forecasting bei Krombacher – Mit Dr. Max Schüssler26 Mar 202600:45:37

In dieser Episode sprechen wir mit Max, Team Lead Data Science bei der Krombacher Brauerei, über Demand Forecasting in der Konsumgüterindustrie. Gemeinsam beleuchten wir, wie Krombacher die tägliche Nachfrageprognose für Bier und weitere Produkte modelliert, von Vorbestellungen über Feature Engineering bis hin zu Gauß-Prozess-Modellen. Außerdem geht es um Modellgüte, den Umgang mit Corona-Effekten, Unsicherheitsintervalle und die Bedeutung von Domänenwissen. Ein weiterer Schwerpunkt liegt auf der Infrastruktur: vom Custom-Stack auf AWS hin zu einer skalierbaren Databricks-Plattform.

**Zusammenfassung**

  • Ziel: Kurzfristige Prognose der täglichen Auslieferungsmenge (Hektoliter) für die nächsten Werktage
  • Starker Einfluss von Vorbestellungen, ergänzt durch Features wie Arbeitsstunden-Abstand, Wochentag und Öffnungszeiten
  • Einsatz von Gauß-Prozess-Modellen für nichtlineare Zusammenhänge und perspektivisch Unsicherheitsintervalle
  • Sliding Window mit 365 Tagen Trainingsdaten und täglichem Retraining
  • Benchmark: < 10 % MAPE erreicht für bis zu fünf Werktage im Voraus
  • Corona-Effekte über Dummy-Variablen berücksichtigt, besonders relevant für Gastronomie-Fässer
  • Wechsel von AWS Custom Stack (SageMaker, MLflow, API) zu Databricks zur besseren Skalierbarkeit und Wartbarkeit
  • Zentrale Learnings: Domänenwissen > Modellkomplexität, Use Case klar definieren, Datenqualität als Fundament

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#89: ROC around the clock – Alles rund um Gütemaße für Klassifikationsmodelle12 Mar 202600:36:37

In dieser Episode des Data Science Deep Dive sprechen Mira und Amit über Modellgütemaße für binäre und kategoriale Zielvariablen. Sie erklären zentrale Kennzahlen wie Accuracy, Precision, Recall, F1-Score, AUC und Log Loss und zeigen, welche Vor- und Nachteile diese im praktischen Einsatz haben. Dabei geht es auch um typische Herausforderungen, etwa bei unbalancierten Daten oder der Wahl des richtigen Schwellenwerts. Anhand von Beispielen aus Betrugserkennung, Medizin und Spam-Filtering wird deutlich, warum die Wahl des passenden Gütemaßes immer vom konkreten Use Case abhängt. Ergänzend geben sie Tipps zur Interpretation von Modellergebnissen und zur Auswahl eines geeigneten Hauptgütemaßes.

**Zusammenfassung**

  • Überblick über Modellgütemaße für binäre und kategoriale Klassifikationsprobleme
  • Einordnung: Klassifikation basiert meist auf Scores bzw. Wahrscheinlichkeiten und einem gewählten Schwellenwert
  • Konfusionsmatrix als Grundlage zur Berechnung vieler Klassifikationsmetriken (TP, TN, FP, FN)
  • Accuracy als einfache Kennzahl – jedoch problematisch bei stark unbalancierten Datensätzen
  • Precision, Recall und Spezifität zur Bewertung verschiedener Fehlertypen und deren Kosten
  • F1-Score als harmonisches Mittel von Precision und Recall, häufiges Hauptmaß bei unbalancierten Daten
  • AUC als schwellenwertunabhängige Bewertung der Trennfähigkeit eines Modells
  • Log Loss zur Bewertung der vorhergesagten Wahrscheinlichkeiten und als häufige Loss-Funktion beim Modelltraining
  • Praktische Tipps: Wahl des Thresholds, Nutzung von Benchmarks, Analyse von Subgruppen und ggf. Rekalibrierung von Wahrscheinlichkeiten

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#88: Anomalie-Erkennung im Loyalty-Programm bei Krombacher – Mit Fabian Wörenkämper26 Feb 202600:50:18

In dieser Episode des Data Science Deep Dive spricht Mira mit Fabian Wörenkämper, Data Scientist bei der Krombacher Brauerei, über Anomalie-Erkennung im Loyalty-Programm. Im Fokus steht die Frage, wie auffällige Punkteaktivitäten erkannt werden, ohne ehrliche Power User zu benachteiligen. Fabian erklärt, wie ein Trust Score mithilfe eines Isolation Forests berechnet wird und welche Rolle Feature Engineering und Fachbereichsfeedback dabei spielen. Außerdem geht es um die technische Umsetzung auf Databricks und die tägliche Aktualisierung der Scores. Zum Abschluss gibt Fabian einen Ausblick auf zukünftige Entwicklungen, etwa GenAI-Projekte und die Verbindung von Trust Score und Customer Value.

**Zusammenfassung**

  • Loyalty-Programm: Kund*innen laden Kassenbons hoch und sammeln Punkte für Krombacher-Produkte
  • Auffälligkeiten reichen von ungewöhnlich vielen Belegen bis hin zu manipulierten Bons
  • Ziel ist es, Betrug zu erkennen, ohne wertvolle Kund*innen zu vergraulen
  • Trust Score dient als kontinuierliches Maß für Auffälligkeit statt einer binären Entscheidung
  • Modellbasis: Isolation Forest, ergänzt durch erklärbare Feature-Indikatoren
  • Enge Zusammenarbeit mit Customer Care und Fachabteilung ist entscheidend für sinnvolle Features
  • Infrastruktur wurde von einem Custom AWS-Stack zu Databricks migriert, tägliche Neuberechnung reicht aus

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#87: [PAIQ3] Predictive AI Quarterly12 Feb 202600:32:52

Im aktuellen Predictive AI Quarterly sprechen wir über zentrale Entwicklungen im Bereich Predictive AI und teilen Erfahrungen aus einem konkreten LLM-Projekt. Thema sind unter anderem TabPFN 2.5, neue Ansätze für Explainability sowie der wachsende Einfluss von AI-Agents auf Softwareentwicklung. Im Praxisteil berichten wir über ein mehrsprachiges Textanalyse-Projekt für den gemeinnützigen Verein Monda Futura. Dabei geht es um die strukturierte Auswertung von rund 850 Zukunftsvisionen mithilfe von LLMs. Abschließend diskutieren wir Learnings zu Modellwahl, Kosten und dem sinnvollen Zusammenspiel von Mensch und KI. **Zusammenfassung**

  • TabPFN 2.5: Skalierung, Distillation für produktive Nutzung und höhere Inferenzgeschwindigkeit
  • ExplainerPFN als Alternative zu SHAP für Feature Importance ohne Zugriff auf das Originalmodell
  • Trend zu AI-Agents, die große Teile der Softwareentwicklung übernehmen
  • Use Case Monda Futura: Analyse von 850 mehrsprachigen Zukunftsvisionen (DE/FR/IT)
  • Pipeline: Fragmentierung, Themenextraktion, Klassifikation und Szenarienerstellung
  • Effektiver Einsatz von GPT-5-Mini vs. GPT-5.2-Pro je nach Aufgabentyp
  • Zentrales Learning: Beste Ergebnisse durch Human-in-the-Loop statt Vollautomatisierung

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#86: "Garbage In, Garbage Out" verhindern: Datenvalidierung richtig gemacht29 Jan 202600:39:17

In dieser Episode dreht sich alles um Datenvalidierung und darum, wie sich das Prinzip "Garbage In, Garbage Out" vermeiden lässt. Mira und Michelle erklären, warum eine gründliche Prüfung der Datenqualität direkt zu Projektbeginn entscheidend ist. Im Fokus stehen typische Checks wie Schema-Validierung, Vollständigkeit, Konsistenz und statistische Auffälligkeiten. Außerdem geht es darum, wie Datenvalidierung hilft, Daten besser zu verstehen und Fehler frühzeitig aufzudecken. Abschließend werden praktische Techniken und Tools vorgestellt, die von manueller Analyse bis zur automatisierten Pipeline reichen.

**Zusammenfassung**

  • Datenvalidierung prüft die Datenqualität vor der Modellierung
  • Ziel: Probleme früh erkennen und Ressourcen sparen
  • Wichtige Aspekte: Datentypen, Duplikate, fehlende Werte
  • Logik- und Plausibilitätschecks (z.B. Alter nicht negativ, Prozentwerte im richtigen Bereich)
  • Statistische Methoden zur Erkennung von Anomalien und Verteilungen
  • Univariat: einfache Kennzahlen, Histogramme, Boxplots, Zeitreihenanalysen
  • Multivariat: Korrelationen, Scatterplots, Kreuztabellen, Multikollinearität
  • Tools reichen von Notebooks und Reports bis zu Dashboards und automatisierten Pipelines

**Links**

#85: Technologieauswahl im Dschungel der Möglichkeiten15 Jan 202600:46:43

Die Tech-Welt bietet heute mehr Auswahl denn je und damit auch viel mehr Möglichkeiten, genau die passende Lösung für den eigenen Kontext zu finden. Wir sprechen darüber, warum Entscheidungen nicht mehr über ein einzelnes Kriterium laufen, sondern vor allem vom Systemumfeld, Teamwissen und organisatorischen Rahmenbedingungen abhängen. Anhand praxisnaher Beispiele zeigen wir, wie man trotz Compliance, Cloud-Ökosystemen oder "Tool-Hype" zu soliden, nachhaltigen Entscheidungen kommt. Außerdem ordnen wir typische Kriterien ein und erklären, wie man mit kleinen Tests, klaren Prioritäten und Lernschleifen die Risiken reduziert. Das Fazit: Die Vielfalt ist ein Vorteil, aber nur wenn man strukturiert auswählt, ausprobiert und den Stack sehr bewusst weiterentwickelt.

**Zusammenfassung**

  • Früher waren Technologieentscheidungen oft simpel, weil es nur wenige Alternativen gab
  • Heute ist die Landschaft extrem breit, selbst innerhalb von Open Source
  • Stärken findet man schnell, Schwächen und Grenzen zeigen sich oft erst im Betrieb
  • Fehlentscheidungen wirken lange nach und können Teams über Jahre ausbremsen
  • Herstellerempfehlungen sind erwartbar parteiisch, Beratung bringt oft Erfahrungs-Bias mit
  • Der Kontext (System, Organisation, Restriktionen) ist entscheidender als eine "Feature-Liste"
  • Beispiele zeigen typische Fallen: Overengineering, Compliance-Zwänge, Cloud-Lock-in, "Tech ausprobieren"
  • Kriterien wie Kosten, Verfügbarkeit, Sicherheit, Support, Latenz und digitale Souveränität konkurrieren je nach Projekt unterschiedlich stark
  • Unerwartete Probleme entstehen oft außerhalb der Specs (Bugs, Release-Qualität, Support-Realität)
  • Ein Tech-Radar und iterative Weiterentwicklung des Stacks helfen, Entscheidungen robuster zu machen

**Links**

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Kurze Pause, frische Energie: Wir hören uns im neuen Jahr!18 Dec 202500:01:25

Wir möchten uns kurz mit einem Update in eigener Sache bei euch melden. Normalerweise erscheinen unsere Episoden alle zwei Wochen, aktuell sind wir jedoch stark in laufende Projekte eingebunden. Damit wir euch weiterhin qualitativ hochwertige und praxisnahe Inhalte rund um Data Science liefern können, legen wir im Dezember und über den Jahreswechsel eine kurze Podcast-Pause ein.

Gleichzeitig möchten wir die Gelegenheit nutzen, Danke zu sagen: Danke fürs Zuhören, fürs Weiterempfehlen und für euer Interesse an unseren Themen. ❤️

Ab Mitte Januar sind wir wieder zurück mit neuen Episoden, frischen Perspektiven und wie gewohnt spannenden Themen aus der Welt der Data Science.

Bis dahin wünschen wir euch entspannte Feiertage, eine gute Zeit zwischen den Jahren und einen großartigen Start ins neue Jahr. Bleibt gesund oder werdet gesund, bis bald!

#84: Body Leasing: Zwischen Beratung, Teamkultur und Erwartungsmanagement13 Nov 202500:30:42

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
#83: Wie gut ist gut genug? Modellgütemaße richtig verstehen23 Oct 202500:33:45

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

#82: Monitoring in MLOps: Tools, Tipps und Best Practices aus der Praxis09 Oct 202500:44:02

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

 

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#81: [PAIQ2] Predictive AI Quarterly25 Sep 202500:26:26

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

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

 

#80: Willkommen an Bord: Wie wir neue Kolleg*innen begleiten04 Sep 202500:36:18

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

 

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#79: Data Science on the Edge: Modelle in verteilten Umgebungen21 Aug 202500:56:04

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

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#78: Der Use-Case-Guide: Navigationshilfe für echten Mehrwert07 Aug 202500:46:09

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

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#77: Uplift Modeling: Der kausale Effekt von Rabatten, Retargeting & Co.24 Jul 202500:33:51

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

 

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#76: Digitale Souveränität: Risiken verstehen, souverän handeln10 Jul 202500:38:06

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

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#75: Refactoring done right: Strategien, Risiken und Best Practice26 Jun 202500:50:35

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

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#74: [PAIQ1] Predictive AI Quarterly12 Jun 202500:28:06

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

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#73: Korrelation vs. Kausalität: Was braucht es für fundierte Entscheidungen?29 May 202500:44:49

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

 

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

#72: TabPFN: Die KI-Revolution für tabulare Daten mit Noah Hollmann15 May 202500:50:40

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:**

#71: Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek01 May 202500:26:20

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

#70: Der Aufstieg zur Datenreife – Stufe für Stufe zur Data Maturity17 Apr 202500:46:07

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

#69: AI Agents verstehen und evaluieren mit Matthäus Deutsch03 Apr 202500:47:22

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

#68: CI/CD für Daten: Datenversionierung für stabile & nachvollziehbare Systeme20 Mar 202500:41:29

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

#67: "It works on my machine" war gestern – Docker Best Practices für Data Science06 Mar 202500:34:53

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

#66: Developer vs. Data Scientist mit Andy Grunwald und Wolfgang Gassler20 Feb 202501:03:42

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

#65: Sicher ist nur die Unsicherheit: Unsicherheitsintervalle erklärt06 Feb 202500:28:50

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

#64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen?23 Jan 202500:40:31

Teil 2 unseres Preisprognose-Experiments für Gebrauchtfahrzeuge: Können Open-Source-LLMs wie Llama 3.1, Mistral und Leo-HessianAI mit GPT-3.5 mithalten? Wir haben fleißig gefinetuned, bis die Motoren qualmten – und es zeigt sich, dass die Unterschiede gar nicht mehr so groß sind. Mit ausreichend vielen Trainingsbeobachtungen nähern sich die Open-Source-Modelle den Ergebnissen von GPT-3.5 an und können es in einzelnen Metriken sogar übertreffen. Für das Finetuning größerer Modelle sind jedoch auch leistungsfähige GPUs notwendig, was die Ressourcenanforderungen deutlich erhöht. In der Folge beleuchten wir, welchen Mehrwert diese Open-Source-LLMs für praxisnahe Use Cases liefern und welche Herausforderungen dabei auftreten.

Zusammenfassung:

  • Vergleich von OpenAI GPT-3.5 und drei Open-Source-LLMs (Llama 3.1, Mistral 7B, Leo-HessianAI)
  • Finetuning der Modelle auf lokalen Daten
  • Ergebnisse: Open-Source-LLMs sind bei größerem Trainingsdatensatz fast so gut wie GPT-3.5
  • XGBoost hinkt etwas hinterher, da Freitexte hier nicht einbezogen wurden
  • Wichtige Faktoren: Batchgröße, Trainingsschritte, Speicherbedarf und Nutzung von Lora-Finetuning
  • Beim Einsatz von Open Source ist mehr Handarbeit nötig, dafür bleibt alles on-premise
  • OpenAI punktet durch Einfachheit und hohe Qualität ohne großen Datenbedarf
  • Frameworks wie Huggingface, Mistral Codebase und Torchtune unterstützen das Finetuning
  • Ausblick: größere LLMs mit Multi-GPU, multimodale Daten und Unsicherheitsquantifizierung

 

***Links***

#63: Data Mining: der pragmatische Weg zu Datenreife & Datenkultur mit Prof. Dr. Ana Moya09 Jan 202500:42:39

„Data Mining“ – klingt nach Staub und Schaufeln, ist aber der Schlüssel zur Mustererkennung in Daten! Wir diskutieren, warum einfache Methoden oft besser sind als fancy KI-Lösungen, besonders bei niedriger Datenreife. Außerdem: Wie man nachhaltigen Mehrwert schafft, ohne sich in Dashboards zu verlieren, und welche Skills und Tools wirklich zählen. Hilfreich für alle, die effektiv mit Daten arbeiten wollen.

 

Zusammenfassung

  • Data Mining: Definition und Bedeutung als pragmatischer Ansatz zur Mustererkennung
  • Herausforderungen: Niedrige Datenreife und der Druck, „fancy“ Methoden einzusetzen
  • Lösungsansätze: Bewährte Methoden wie Statistik, Visualisierungen und Anomaly Detection
  • Nachhaltigkeit: Optimierte Prozesse und ressourcenschonende Lösungen als Kernnutzen
  • Skills und Tools: Analytisches Denken, Statistik, Programmierkenntnisse, sowie Tools aus dem Bereich Business Intelligence und Programmiersprachen wie R & Python
  • Fehler vermeiden: Datenqualität, Vermeidung von Confirmation Bias und sinnvolle Nutzung von Dashboards

 

***Links***

#62: Kafka und Datenströme erklärt – und wie das jetzt auch in R läuft19 Dec 202400:21:02

Kafka, aber in R? Das geht jetzt! In dieser Folge klären wir, warum Kafka für schnelle Datenströme unverzichtbar ist und warum unser neuer R-Kafka-Client ein Gamechanger ist. Was ist Kafka, wofür braucht man es (oder auch nicht), und wie funktioniert unser Paket? Hört rein und probiert es aus!

 

Zusammenfassung

  • Apache Kafka als schnelles, ausfallsicheres System für Event-Streaming und Datenströme
  • Einsatzbereiche: Überall wo Daten fortlaufend und in Echtzeit verarbeitet werden
  • Unser R Kafka Client ermöglicht nun die direkte Nutzung von Kafka in R, ohne Umweg über Python
  • Features: Consumer/Producer-Modelle, asynchrone Datenverarbeitung, hohe Performance und Ausfallsicherheit
  • Ausblick: Veröffentlichung auf CRAN, Admin-Client für Cluster-Management, Blogartikel mit Beispiel (siehe unten in den Links)

Links

#61: Technologische Must-Haves: Unser Survival-Guide für Data-Science-Projekte05 Dec 202400:42:04

Zusammenfassend unsere Must-Haves:

  • Datenbank / DWH 
  • Lösung zur Datenvisualisierung
  • Möglichkeit, unkompliziert zu entwickeln (lokal oder im Web)
  • Versionskontrolle / CI/CD
  • Deployment-Lösung
  • Trennung von Entwicklungs- und Produktivumgebung
  • Monitoring für Modell & Ressourcen

 

Verwandte Podcast-Episoden

Folge #2: Erfolgsfaktoren für Predictive Analytics Projekte

Folge #5: Data Warehouse vs. Data Lake vs. Data Mesh

Folge #20: Ist Continuous Integration (CI) ein Muss für Data Scientists?

Folge #21: Machine Learning Operations (MLOps)

Folge #29: Die Qual der Wahl: Data Science Plattform vs. Customized Stack

Folge #35: Erfolgsfaktoren für Machine Learning Projekte mit Philipp Jackmuth von dida

Folge #43: Damit es im Live-Betrieb nicht kracht: Vermeidung von Overfitting & Data Leakage

Folge #54: Modell-Deployment: Wie bringe ich mein Modell in die Produktion?

 

Technologien & Tools

Datenvisualisierung: Azure Databricks, AWS Quicksight, Redash

Entwicklungsumgebung: VSCode, INWT Python IDE V2, Remote Explorer, Pycharm

Versionskontrolle: GitHub, GitLab, Azure DevOps

CI/CD: GitHub Actions, GitLab CI, Jenkins

Deployment: Kubernetes, Docker, Helm, ArgoCD

Experiment-Tracking: MLFlow, DVC, Tensorboard

Monitoring: Prometheus, Grafana, AWS Cloudwatch

#60: Job-Sicherheit als Data Scientist: Personalentwicklung in Zeiten von AI21 Nov 202400:41:44

Die glorreichen Zeiten des Data Scientist scheinen vorbei zu sein – oder doch nicht? Warum stagnieren die Jobangebote? Und wie passt GenAI ins Bild? Wir sprechen über die neuen Herausforderungen am Arbeitsmarkt, was Unternehmen und Jobsuchende jetzt tun sollten, und warum Data Engineers irgendwie sexy, aber nie so richtig hot waren. Spoiler: Flexibilität und Generalismus sehen wir als wichtige Eigenschaften für die Zukunft!

 

***Links***

#59: Besser mit Helm: komplexe Deployments einfach(er) umsetzen07 Nov 202400:18:00

Helm auf und los geht’s! In dieser Episode zeigen wir euch wie wir ein Fraud-Detection-Projekt mit komplexen Deployments mithilfe von Kubernetes und Helm in den Griff bekommen haben – Spoiler: Copy-Paste hatte hier keine Chance! ;) Warum Helm ein Gamechanger für eure Kubernetes-Configs sein kann und was es mit diesen ominösen Charts auf sich hat, erfahrt ihr hier. Für alle, die mehr Ordnung im Deployment-Chaos suchen, ist das die perfekte Folge.

 

***Links***

#58: Arm, aber sexy: Data Warehousing at Scale ohne Budget24 Oct 202400:37:32

Dies ist ein Gedankenexperiment, das euch zeigt, wie man mit wenig Budget und minimaler Hardware eine clevere self-service Umgebung bastelt, die auf dem Laptop oder einer günstigen Cloud-Instanz läuft.  Wir sprechen darüber wie so ein Stack aussehen kann (Storage Layer, Data Layer, Compute Layer) und welche Anwendungsszenarien es gibt, aber auch wo die Grenzen bei einem solchen Szenario liegen. 

 

***Links***

#57: Mehr als heiße Luft: unsere Berliner Luftschadstoffprognose mit Dr. Andreas Kerschbaumer10 Oct 202400:51:20

In dieser Episode sprechen wir mit Dr. Andreas Kerschbaumer, Umweltexperte beim Berliner Senat, über unsere Luftschadstoffprognose und warum Berlin immer noch dringend sauberere Luft braucht. Andreas erklärt, wie Machine Learning hilft, die Luftverschmutzung vorherzusagen und welche Rolle klassische Methoden (CTMs) dabei spielen. Wir vergleichen den neuen Machine-Learning-Ansatz mit dem traditionellen und diskutieren, welche Vor- und Nachteile sie mit sich bringen. Außerdem verraten Mira und Andreas, was sie in diesem spannenden Projekt gelernt haben.

 

***Links***

 

#56: Unsere Bundestagswahl-Prognose: Wer gewinnt die Wahl 2025?26 Sep 202400:25:16

Vor der Bundestagswahl 2017 haben wir begonnen, ein Prognosemodell für den Wahlausgang zu entwickeln – und seitdem ständig verbessert. Heute präsentieren wir täglich aktualisierte Prognosen, die Verzerrungen einzelner Wahlumfragen korrigieren und das Wahlverhalten am Wahltag vorhersagen. Mit bayesianischen Modellen liefern wir Wahrscheinlichkeiten zur Regierungsbeteiligung und anderer Ereignisse und stellen sie auf wer-gewinnt-die-wahl.de bereit. 

 

***Links***

#55: Alle machen XGBoost, aber was macht eigentlich XGBoost? Mit Matthäus Deutsch16 Sep 202400:42:35

Warum ist XGBoost seit Jahren das Tool der Wahl, wenn es um tabulare Daten geht? Mira spricht zusammen mit Matthäus Deutsch darüber, warum  XGBoost State of the Art ist und was es so erfolgreich macht. Außerdem: Wie schlägt sich XGBoost im Vergleich zu Deep Learning? Und gibt es überhaupt bessere Alternativen?

**Links**

#54: Modell-Deployment: Wie bringe ich mein Modell in die Produktion?29 Aug 202400:51:12

Online vs. Offline Serving – welcher Ansatz ist besser? Wir besprechen, wie du dein Modell erfolgreich in die Produktion bringst und eine passende Datenschnittstelle deployst. Dazu gibt’s Tipps zu den Tools, die uns dabei helfen, wie FastAPI, Docker und Kubernetes. Außerdem erfährst du, worauf du bei der Automatisierung und beim Handling vieler Modelle achten solltest.

**Links**

#53: Agilität à la carte: Das Agile Fluency Model mit Dr. Wolf-Gideon Bleek15 Aug 202401:12:58
In dieser Episode von Data Science Deep Dive sprechen Mira und Wolf-Gideon über das Agile Fluency Model und dessen Bedeutung im Data-Science-Kontext. Im Fokus stehen die verschiedenen Stufen der Agilität sowie die damit verbundenen Vorteile und notwendigen Investitionen. Wolf-Gideon erklärt, wie man den optimalen Agilitätsgrad für ein Team ermittelt und welche Praktiken dabei relevant sind.    ***Links***
#52: In-process Datenbanken und das Ende von Big Data01 Aug 202400:41:04

In dieser Episode sprechen wir über die in-process Datenbank DuckDB, die im Juni Version 1.0.0 erreicht hat und einen innovativen Ansatz verfolgt. DuckDB wird direkt aus dem Code heraus gestartet und benötigt keine Berechtigungen oder User-Management, was an SQlite erinnert. Außerdem beleuchten wir die These, dass die "Big Data" Ära vorbei ist, warum das so ist und was das eigentlich mit DuckDB zu tun hat. 

 

***Links***

#51: Wer rastet, rostet: Die Rolle von Weiterbildung in Data Science18 Jul 202400:46:22

Data Science entwickelt sich ständig und schnell weiter, was kontinuierliche Weiterbildung unerlässlich macht. In dieser Episode diskutieren wir, wie Arbeitgeber*innen ihre Mitarbeitenden unterstützen können und welche organisatorischen und projektbezogenen Formate sich für uns als effektiv erwiesen haben. Zudem sprechen wir über private Fortbildungsmaßnahmen und geben Tipps zur Auswahl geeigneter Kurse und Konferenzen.

***Links***

Ankündigung: Unser Podcast bekommt einen neuen Namen!11 Jul 202400:01:52

Ab der nächsten Episode ist "In Numbers We Trust - Der Data Science Podcast" Geschichte. Wir benennen unseren Podcast um in "Data Science Deep Dive". Aber keine Sorge, ansonsten wird sich nichts ändern. Auf die nächsten 50 Episoden!

Vielen Dank an alle treuen Hörer*innen und herzlich willkommen an alle, die neu dabei sind.

Wir sind INWT und wir machen Data Science, von der ersten Idee bis zum fertigen Produkt, und in diesem Podcast sprechen wir darüber. Es ist unser Anspruch, Data Science-Themen tiefgehend zu besprechen und praxisorientiert zu vermitteln. Wir sprechen über alles, was wir spannend finden, mit Leuten, die wir kennen und mögen.

Wir freuen uns, wenn ihr auch beim Data Science Deep Dive mit dabei seid!

Und wie immer könnt ihr eure Fragen, Anmerkungen und Themenwünsche gern an podcast@inwt-statistics.de schreiben.

© My Podcast Data · Independent project · Data from Apple & Spotify
AboutMethodologyContactSupport mePrivacy PolicyLegal Notice