Data Science Deep Dive

INWT Statistics GmbH

Wir machen Data Science. Und in unserem Podcast Data Science Deep Dive reden wir darüber.

Du bist ebenfalls Data Scientist oder interessierst dich für Daten, ML und AI? Dann ist dieser Podcast für dich. Wir teilen unsere Learnings aus über 180 Projekten, du bekommst Infos und Anregungen zu spannenden Themen rund um Daten.

Wir klären auf, geben Hinweise und teilen unsere Erfahrungen, die wir in über 10 Jahren als Data Scientists im B2B Bereich gesammelt haben.
Wir decken auf, was wirklich hinter den Hypes und Trends der Data Science Branche steckt.
Wir hinterfragen, was ein Data Science Projekt erfolgreich macht und welche Faktoren es zum Scheitern verurteilen.

Play

Open in

21 episodes
fortnightly
Avg 40 min
German

Episodes 21

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

#103
Thursday · 43 min
#101: [DSK1] Data Strategy Kompass – Was Datenstrategie ist & was nicht
Ein Geschäftsführer will im Quartalsmeeting wissen, welche Kundengruppe die profitabelste ist – der Vertrieb antwortet mit einer Zahl aus Excel, das Controlling mit einer anderen aus SAP, und das Meeting endet ohne Entscheidung. Mit dieser Szene startet der "Data Strategy Kompass", eine vierteilige Serie über Datenstrategie im Mittelstand. In Teil 1 klären Mira und Amit, was eine Datenstrategie ist und was sie nicht ist: keine Software-Entscheidung und kein Data-Warehouse-Projekt, sondern die Frage, welche Entscheidungen ein Unternehmen künftig besser treffen will. Sie gehen die Bestandteile durch – von der Anbindung an die Unternehmensstrategie über Datenhaltung und Governance bis zum menschlichen Faktor – und diskutieren, wann sich eine Datenstrategie lohnt und wann eher nicht. Anhand von Beispielen und Gegenbeispielen aus über 15 Jahren Projektarbeit zeigen sie, woran es in der Praxis meist hängt: selten an der Technik. **Zusammenfassung** Datenstrategie beantwortet die Frage "Welche Entscheidungen wollen wir besser treffen?" und nicht "Welche Software kaufen wir?" Erst Use Cases, dann Infrastruktur: Alles zu speichern und später zu schauen, wofür man es braucht, ist ein Relikt der Big-Data-Zeit Bestandteile: Verbindung zur Unternehmensstrategie, Priorisierung von Use Cases, Datenhaltung und Architektur, Governance, Organisation und Kultur Kein isoliertes Projekt einer Datenabteilung: Es braucht die Führungsebene, mehrere Fachbereiche und kontinuierliche Anpassung Personalbedarf wird unterschätzt: gebraucht werden vor allem Menschen, die Pipelines bauen und Daten aufbereiten, nicht nur Data Scientists Wann es sich nicht lohnt: zehn Mitarbeitende und ein Excel; niemand ist bereit, datenbasiert zu entscheiden; Daten dienen nur der Rechtfertigung ohnehin gefasster Meinungen Datenbasiert heißt nicht "alle Entscheidungen datenbasiert": Strategische Weichenstellungen kommen oft ohne belastbare Datenbasis aus Typische Stolpersteine aus der Praxis: SaaS-Tool ohne Datenexport, parallele Excel-Welten ohne Dokumentation, Compliance-Lücken bereits bei der Datenerhebung **Zum Mitnehmen: vier Fragen für den nächsten Führungskreis** Welche Entscheidung wurde in den letzten drei Monaten aus dem Bauch heraus getroffen, weil die Zahlen fehlten? Wenn du heute drei wichtige Fragen an deine Daten stellen könntest, welche wären das? Wer würde der KI (z.B. eine Prognose, nicht Chatbot ist gemeint) vertrauen, wenn sie ihr/ihm widerspricht? Die Datenprojekte, die wir schon machen - wissen wir, wie viel sie uns eigentlich bringen? **Links** #33: Data Science bei Zalando – Dr. Claudia Baldermann im Gespräch über Product Development & Organisation https://www.podbean.com/ew/pb-q25zg-14b82e0 #5: Data Warehouse vs. Data Lake vs. Data Mesh https://www.podbean.com/ew/pb-a4xzx-127be01 #36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1 Data Mesh Principles and Logical Architecture (Zhamak Dehghani): https://martinfowler.com/articles/data-mesh-principles.html INWT Website: https://www.inwt-statistics.de/ **Ausschreibung MLOps Engineer** https://www.inwt-statistics.de/career/mlops-engineer 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#102
August 13 · 56 min
#100: Crash Course Data Science: Was Entscheider*innen wissen müssen
Folge 100 bündelt, was Entscheider*innen über Data Science wissen sollten – aufgeteilt in vier Blöcke: Begriffsklärung, Datenqualität, Modellgüte und Erfolgsfaktoren. Mira und Amit ordnen ein, wie KI, Machine Learning und Statistik zusammenhängen, was supervised von unsupervised Learning unterscheidet und welche der vier Stufen der Datenanalyse für welche Fragestellung überhaupt nötig ist. Beim Thema Daten geht es um Validierung vor der eigentlichen Analyse, fehlende Zielvariablen und typische Formatprobleme, bei der Modellgüte um passende Gütemaße, Benchmarks, Overfitting, Explainability und die Evaluation von GenAI. Der letzte Teil behandelt die Frage, warum Datenprojekte in der Schublade landen: Auswahl des Use Cases, der Aufwandssprung von PoC zu MVP und Produkt sowie der eigene Data-Maturity-Level. Zum Abschluss stehen die fünf häufigsten Fehler. **Zusammenfassung** Begriffe sortieren: KI ist als Überbegriff meist unscharf gemeint, zwischen Statistik und ML gibt es einen fließenden Übergang – entscheidend ist, ob Zusammenhänge verstanden oder Prognosen erstellt werden sollen. Vier Stufen der Datenanalyse: deskriptiv, diagnostisch, prädiktiv, präskriptiv – oft liefert schon die erste Stufe den Großteil der Erkenntnisse, Stufen lassen sich schlecht überspringen. Datenqualität vor Datenquantität: viele korrekte, aber irrelevante Spalten verbessern keine Prognose; fehlerhafte Daten sind das größere Problem – gilt für tabulare Daten wie für RAG-Dokumente. Validierung zuerst: explorative Analysen, Verteilungen und Ausreißerprüfung deckt Datenprobleme auf und erzeugt selbst schon Erkenntnisse. Das Gütemaß hängt vom Use Case ab: Kosten von False Positives und False Negatives unterscheiden sich, ein einfaches Benchmark-Modell zeigt, ob der Aufwand sich lohnt. Overfitting vermeiden: immer out-of-sample auf einem Testdatensatz evaluieren und zeitliche Struktur berücksichtigen – sonst sind Prognosen ungenauer als erwartet und man sieht Zusammenhänge, die es nicht gibt. GenAI-Evaluation ist der Engpass: ein PoC entsteht schnell, das MVP wird durch Bewertungsfragen (LLM as a Judge, User Testing) deutlich aufwändiger. Erfolgsfaktoren: konkreter Use Case mit messbarem Hebel, frühe Einbindung der Nutzer*innen, Implementierung von Anfang an mitdenken und Projekte zum eigenen Reifegrad wählen. **Links** Blogartikel zu Erfolgsfaktoren für Data-Science-Projekte https://www.inwt-statistics.de/blog/erfolgsfaktoren-fuer-data-science-projekte Folge #6: Statistik vs. Machine Learning https://www.podbean.com/ew/pb-ewip2-128c6f8 Folge #83: Wie gut ist gut genug? Modellgütemaße richtig verstehen https://www.podbean.com/eas/pb-8q2a8-19a0252 Folge #89: ROC around the clock – Alles rund um Gütemaße für Klassifikationsmodelle https://www.podbean.com/eas/pb-6jfj7-1a6a8ba Folge #43: Damit es im Live-Betrieb nicht kracht: Vermeidung von Overfitting & Data Leakage https://www.podbean.com/ew/pb-vw736-15baac0 Folge #86: "Garbage In, Garbage Out" verhindern: Datenvalidierung richtig gemacht https://www.podbean.com/eas/pb-5kyzq-1a305ed Folge #2: Erfolgsfaktoren für Predictive Analytics Projekte https://www.podbean.com/ew/pb-kdcmd-12460ab Folge #78: Der Use-Case-Guide: Navigationshilfe für echten Mehrwert https://www.podbean.com/ew/pb-s5e2r-1928b4f Folge #21: Machine Learning Operations (MLOps) https://www.podbean.com/ew/pb-taen7-13ce0fa Folge #23: Unsexy aber wichtig: Tests und Monitoring https://www.podbean.com/ew/pb-vxp58-13f311a Folge #24: Explainable AI: Entscheidungen von Black-Box-Modellen verstehen https://www.podbean.com/ew/pb-kn67b-1403089 Folge #47: Von Prognosen und Prompts: Data Science trifft generative KI mit Tobias Sterbak https://www.podbean.com/ew/pb-dkyex-1613842 Folge #70: Der Aufstieg zur Datenreife – Stufe für Stufe zur Data Maturity https://www.podbean.com/ew/pb-a7663-1882b25 Folge #32: Brauche ich Data-Science-Berater*innen und wenn ja wie viele? https://www.podbean.com/ew/pb-eaekc-14a6bbe Folge #69: AI Agents verstehen und evaluieren mit Matthäus Deutsch https://www.podbean.com/ew/pb-cq7xp-186d96d Folge #80: Willkommen an Bord: Wie wir neue Kolleg*innen begleiten https://www.podbean.com/ew/pb-232sr-1953fe6 Folge #51: Wer rastet, rostet: Die Rolle von Weiterbildung in Data Science https://www.podbean.com/ew/pb-czpd3-16716c0 Folge #97: Die Güte von Gen-AI-Projekten bewerten mit Tobias Sterbak https://www.podbean.com/eas/pb-7fhem-1b0096c 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#101
July 30 · 1 hr
#99: Cluster-Architektur mit Kubernetes: self-hosted, managed oder gar nicht?
Sebastian und Michelle sprechen in dieser Folge über Cluster-Architektur mit Kubernetes: was das Tool leistet, welche Betriebsvarianten es gibt und für wen sich der Einsatz überhaupt rechnet. Ausgangspunkt sind die typischen Gründe für k8s – Skalierung, Ausfallsicherheit durch Health Checks und Rolling Updates sowie Infrastructure as Code. Danach geht es um die Frage self-hosted (k8s, k3s) oder managed (AWS, GCP, Azure) und um den Unterschied zwischen plain Kubernetes und Red Hat OpenShift. Ein zweiter Schwerpunkt liegt auf dem Zuschnitt der Umgebung: wie viele Cluster sinnvoll sind (pro Stage, pro Produkt) und wie innerhalb eines Clusters mit Namespaces und Network Policies getrennt wird. Zum Schluss diskutieren die beiden Alternativen ohne Kubernetes und die Voraussetzungen, die im Team erfüllt sein müssen. **Zusammenfassung** Kubernetes verwaltet containerisierte Anwendungen und arbeitet mit Docker zusammen – die beiden Tools sind keine Konkurrenz Hauptargumente für k8s: Skalierung und Ressourcennutzung, Verfügbarkeit über Health Checks (Liveness, Readiness), Rolling Updates und Rollbacks, Konfiguration als Code in YAML Self-hosted (k8s, k3s) bedeutet eigene Versions-Updates und Skills in Systemadministration und Provisionierung; Managed Cluster kosten mehr, reduzieren aber Maintenance und erhöhen die Verfügbarkeitsgarantie OpenShift bringt eigene CLI, UI, Monitoring und Enterprise Support mit (Open-Source-Variante: OKD), plain k8s läuft dafür auf schlankerer Hardware Anzahl der Cluster: mindestens eine Trennung von DEV und PRD, größere Organisationen provisionieren pro Produkt x Stage – jedes zusätzliche Cluster bedeutet mehr Aufwand für Updates, Monitoring und Provisionierung Trennung nach Produkt statt nach Team, weil Zuständigkeiten sich ändern; Namespaces sind die leichtgewichtige Alternative zur vollen Isolation Network Policies funktionieren wie Firewall-Regeln für Pods (Ziel/Quelle, ingress/egress); standardmäßig ist alles erlaubt, sobald ein Pod eine Policy hat, gilt für ihn Deny-All – ein Deny-All pro Namespace ist deshalb Pflicht Alternative für kleine Setups: ein oder zwei VMs mit mehreren Instanzen hinter einem Loadbalancer, Rolling Updates per Skript; entscheidend sind Produkt, Verfügbarkeitsanspruch und vorhandenes Know-how **Links** Episode #14: Kubernetes https://inwt.podbean.com/e/14-kubernetes/ Training Course by The Linux Foundation: Introduction to Kubernetes (LFS158) https://training.linuxfoundation.org/training/introduction-to-kubernetes/ Kubernetes: https://kubernetes.io/ k3s: https://k3s.io/ 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#100
July 16 · 49 min
#98: Risiken bei der Softwareentwicklung mit AI Agents
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** #91: Software ohne Entwickler*innen? Wie AI Agents unsere Arbeit neu definieren https://www.podbean.com/ew/pb-2if5e-1a90f94 The lethal trifecta for AI agents: private data, untrusted content, and external communication (Simon Willison): https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ The Vulnerable MCP Project (Übersicht zu MCP-Schwachstellen): https://vulnerablemcp.info/index.html Cory Doctorows Blog (Quelle zum Halluzinations-Beispiel): https://pluralistic.net VibePod CLI - The zero-config CLI for running AI coding agents locally https://vibepod.dev/ nono - Run AI agents in a zero-latency sandbox in seconds, with zero setup. https://nono.sh/ Docker Sandboxes https://docs.docker.com/ai/sandboxes/ Agentlytics https://agentlytics.io/ Apertus, das offene Schweizer Sprachmodell (Hugging Face): https://huggingface.co/collections/swiss-ai/apertus-llm Mistral (europäischer Modellanbieter): https://mistral.ai 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#99
July 2 · 47 min
#97: Die Güte von Gen-AI-Projekten bewerten mit Tobias Sterbak
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** #47: Von Prognosen und Prompts: Data Science trifft generative KI mit Tobias Sterbak https://www.podbean.com/ew/pb-dkyex-1613842 Tobias Sterbak auf LinkedIn: https://www.linkedin.com/in/tobias-sterbak/ Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#98
June 18 · 32 min
#96: Queer Data: Wie erfasst, bereinigt und analysiert man sensible Daten?
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** Buch "Queer Data" von Kevin Guyan: https://kevinguyan.com/queer-data/ Buch "Rainbow Trap" von Kevin Guyan: https://kevinguyan.com/rainbow-trap/ Buch "Data Feminism" von Catherine D'Ignazio und Lauren F. Klein (MIT Press, frei verfügbar): https://data-feminism.mitpress.mit.edu/ Episode #40: Sonderfolge: Frauen in Data Science und Tech mit Catrin & Isa von Mind the Tech https://www.podbean.com/eas/pb-ypy32-15747e6 Episode #93: Bayesianische Statistik: Vorwissen und Daten kombinieren https://www.podbean.com/eas/pb-crgji-1ab8218 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#97
June 4 · 27 min
#95: GitOps: Deployments mit Ruhepuls
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** ArgoCD: https://argo-cd.readthedocs.io FluxCD: https://fluxcd.io ArgoCD Image Updater: https://argocd-image-updater.readthedocs.io Sealed Secrets: https://github.com/bitnami-labs/sealed-secrets External Secrets Operator: https://external-secrets.io Helm: https://helm.sh Kustomize: https://kustomize.io Kubernetes: https://kubernetes.io 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#96
May 21 · 37 min
#94: [PAIQ4] Predictive AI Quarterly
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** Predictive LLMs: Die Rolle multimodaler Daten bei der Preisprognose https://www.inwt-statistics.de/blog/predicitve-llms-rolle-multimodaler-daten HyperAgents (Zhang et al., 2026): Paper unter https://arxiv.org/abs/2603.19461, Code unter https://github.com/facebookresearch/Hyperagents Feitelberg, J., Saha, D., Choi, K., Ahmad, Z., Agarwal, A. & Dwivedi, R.: TabImpute: Universal Zero-Shot Imputation for Tabular Data. https://arxiv.org/pdf/2510.02625 TabICL GitHub Repo https://github.com/soda-inria/tabicl OpenAI Developers: Vision fine-tuning https://developers.openai.com/api/docs/guides/vision-fine-tuning 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#95
May 7 · 33 min
#93: Bayesianische Statistik: Vorwissen und Daten kombinieren
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** #56: Unsere Bundestagswahl-Prognose: Wer gewinnt die Wahl 2025? https://www.podbean.com/ew/pb-hwgnd-16e446e #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
#94
April 23 · 46 min
#92: Anomaly Detection von Produktbildern mit ClickHouse
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** #54: Modell-Deployment: Wie bringe ich mein Modell in die Produktion? https://www.podbean.com/ew/pb-hhhwu-16b91f3 ClickHouse https://clickhouse.com/ ClickHouse Docs: Can you use ClickHouse for vector search? https://clickhouse.com/docs/knowledgebase/vector-search 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#93
April 9 · 46 min
#91: Software ohne Entwickler*innen? Wie AI Agents unsere Arbeit neu definieren
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** #29: Die Qual der Wahl: Data Science Plattform vs. Customized Stack https://www.podbean.com/ew/pb-pep8h-147029f The Pragmatic Engineer: When AI writes almost all code, what happens to software engineering? by Gergely Orosz https://newsletter.pragmaticengineer.com/p/when-ai-writes-almost-all-code-what Conductor Extension for Gemini CLI https://github.com/gemini-cli-extensions/conductor 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#91
March 26 · 45 min
#90: Demand Forecasting bei Krombacher – Mit Dr. Max Schüssler
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** Krombacher Brauerei https://www.krombacher.de/ Dr. Max Schüssler auf LinkedIn https://www.linkedin.com/in/dr-max-schuessler/ databricks https://www.databricks.com/ #88: Anomalie-Erkennung im Loyalty-Programm bei Krombacher – Mit Fabian Wörenkämper https://www.podbean.com/ew/pb-apyrq-1a577b8 #29: Die Qual der Wahl: Data Science Plattform vs. Customized Stack https://www.podbean.com/ew/pb-pep8h-147029f ML Tutorial: Gaussian Processes (Richard Turner) auf YouTube https://www.youtube.com/watch?v=92-98SYOdlY 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#92
March 12 · 36 min
#89: ROC around the clock – Alles rund um Gütemaße für Klassifikationsmodelle
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** #83: Wie gut ist gut genug? Modellgütemaße richtig verstehen https://www.podbean.com/ew/pb-8q2a8-19a0252 Wikipedia – Confusion Matrix: https://en.wikipedia.org/wiki/Confusion_matrix Wikipedia – Precision und Recall: https://en.wikipedia.org/wiki/Precision_and_recall Wikipedia – Receiver Operating Characteristic (ROC) / AUC: https://en.wikipedia.org/wiki/Receiver_operating_characteristic Wikipedia – Cross Entropy / Log Loss: https://en.wikipedia.org/wiki/Cross_entropy Scikit-learn Guide zu Klassifikationsmetriken: https://scikit-learn.org/stable/modules/model_evaluation.html#classification-metrics 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#90
February 26 · 50 min
#88: Anomalie-Erkennung im Loyalty-Programm bei Krombacher – Mit Fabian Wörenkämper
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** Guinness und die Statistik von Karolin Breitschädel auf detektor.fm https://detektor.fm/wissen/geschichten-aus-der-mathematik-statistik-aus-der-brauerei Krombacher Loyalty-Programm: https://plus.krombacher.de/ Isolation Forest (Anomaly Detection): https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.IsolationForest.html Databricks Plattform: https://www.databricks.com/ Streamlit (interaktive Modell-Iteration): https://streamlit.io/ 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#89
February 12 · 32 min
#87: [PAIQ3] Predictive AI Quarterly
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** Prior Labs TabPFN-2.5 Model Report https://priorlabs.ai/technical-reports/tabpfn-2-5-model-report ExplainerPFN Forschungs-Paper (zero-shot Feature Importance) https://arxiv.org/abs/2601.23068 OpenCode – Open Source AI Coding Agent https://opencode.ai/ Monda Futura https://mondafutura.org/ OpenAI API & GPT-Modelle Überblick https://platform.openai.com/docs/models OpenAI Structured Output Guide https://platform.openai.com/docs/guides/structured-outputs 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#88
January 29 · 39 min
#86: "Garbage In, Garbage Out" verhindern: Datenvalidierung richtig gemacht
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** Great Expectations (Datenvalidierung in Python): https://greatexpectations.io/ Pandera (Schema-Validierung für Pandas): https://pandera.readthedocs.io/ dataMaid (Datenvalidierung in R): https://cran.r-project.org/web/packages/dataMaid/index.html Pydantic (Datenvalidierung & Settings in Python): https://docs.pydantic.dev/ Wikipedia-Eintrag zum Prinzip "Garbage In, Garbage Out": https://de.wikipedia.org/wiki/Garbage_In,_Garbage_Out
#87
January 15 · 46 min
#85: Technologieauswahl im Dschungel der Möglichkeiten
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** Thoughtworks Technology Radar (Adopt / Trial / Assess / Hold) https://www.thoughtworks.com/radar Positionspapier: "Kriterien zur Identifikation und Auswahl von digitalen Schlüsseltechnologien" von bitkom https://www.bitkom.org/Bitkom/Publikationen/Kriterien-zur-Identifikation-und-Auswahl-von-digitalen-Schluesseltechnologien Episode #29: Die Qual der Wahl: Data Science Plattform vs. Customized Stack https://www.podbean.com/ew/pb-pep8h-147029f 📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de
#86
Dec 18, 2025 · 1 min
Kurze Pause, frische Energie: Wir hören uns im neuen Jahr!
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!
#85
Nov 13, 2025 · 30 min
#84: Body Leasing: Zwischen Beratung, Teamkultur und Erwartungsmanagement
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
#84
Oct 23, 2025 · 33 min
#83: Wie gut ist gut genug? Modellgütemaße richtig verstehen
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

Showing 1–20 of 21 episodes