Data Science Deep Dive

All episodes.

100 episodes · showing the newest 100

#106: Die AI Pill im Realitätscheck: Agentic Programming und Produktivität

Nov 5, 2026 51 min

In dieser Folge geht es darum, wie Agentic Programming die Produktivität von Softwareentwickler*innen verändert und welche empirischen Zahlen es dazu gibt. Wir stellen optimistische und skeptische Stimmen gegenüber: Auf der einen Seite stehen Unternehmen mit vollständig agentischer Entwicklung, auf der anderen Kent Becks Sicht auf KI als Verstärker bestehender Stärken und Schwächen. Im Mittelpunkt stehen Studien wie das METR-Experiment, die DORA-Erhebungen und eine NBER-Arbeit zu verschiedenen Generationen von KI-Tools sowie Arbeitsmarktdaten aus Deutschland und den USA. Wir besprechen auch, warum sich Produktivität so schwer messen lässt und mit welchen methodischen Problemen neuere Studien zu kämpfen haben. Zum Schluss geht es darum, worauf Teams bei der Einführung von KI achten sollten, damit sie die Arbeit verbessert und nicht nur verdichtet. **Zusammenfassung** Mehr Code ist nicht gleich mehr Produktivität: 700 % mehr Codezeilen stehen nur rund 30 % mehr Produktivität gegenüber. Der Engpass ist das Code Review, und automatische Reviews reichen nicht aus, um Qualität zu sichern. METR-Studie 2025: Entwickler*innen erwarteten, mit KI 25 % schneller zu sein, und schätzten sich hinterher 20 % schneller ein. Tatsächlich waren sie 20 % langsamer. Die Folgestudie 2026 ist methodisch schwieriger, unter anderem wegen Selektionseffekten und weil sich die Arbeitszeit beim Betreuen von Agenten kaum messen lässt. DORA-Erhebungen: Die Umfragen zeigen positive Effekte von 5–10 % auf Team- und Organisationsebene und rund 15 % auf individueller Ebene. Gleichzeitig steigt die Instabilität um etwa 10 %, und es zeigen sich Effekte auf Burnout. NBER-Studie: Sie misst Produktivität über mehrere Generationen von KI-Tools hinweg. Dabei zeigt sich ein Engpass: Es entstehen viele neue Apps, aber viele davon finden nie genug Nutzer*innen. Skeptische Perspektiven: Kent Beck beschreibt KI als Verstärker, der Gutes wie Schlechtes verstärkt. Das „Expensive Loop Problem“ erklärt, warum Ag...

#105: [DSK2] Data Strategy Kompass – Die Bestandsaufnahme

Oct 22, 2026 44 min

In der zweiten Folge unserer Serie "Data Strategy Kompass" geht es um die Bestandsaufnahme: Wo steht ein Unternehmen aktuell beim Thema Daten? Dafür stellen wir eine Matrix mit sieben Dimensionen vor, von strategischen Entscheidungen über Governance, Daten und Architektur bis hin zu Kultur & HR, und betrachten jeweils Status quo, Hebel und typisches Konfliktpotenzial. Anschließend ordnen wir den eigenen Reifegrad mit dem Analytics-Modell von Gartner ein, das vier Stufen von deskriptiv bis präskriptiv unterscheidet. An den Beispielen Churn-Vermeidung und Predictive Maintenance zeigen wir, wie sich ambitionierte Ideen auf niedrigere Stufen herunterbrechen lassen und warum diese Vorarbeit oft schon eigene Quick Wins liefert. Die Übersichtstabelle für den Selbst-Check findet ihr unten. **Zusammenfassung** Ohne Bestandsaufnahme droht die Datenstrategie am Bedarf vorbeizugehen, zu klein oder zu groß gedacht zu sein oder unerreichbare Ziele zu setzen. Die Bestandsaufnahme erfolgt typischerweise in einem ein- bis zweitägigen Workshop anhand von sieben Dimensionen: Strategische Entscheidungen, Ownership & Governance, Daten, Architektur, Use Cases & Projekte, Organisatorische Beteiligte sowie Kultur & HR. Zu jeder Dimension werden drei Fragen gestellt: Was ist der Status quo, wo liegen ungenutzte Hebel und wo gibt es Konfliktpotenzial? Datenqualität ist auch eine geschäftliche Frage: Liefern verschiedene Abteilungen unterschiedliche Antworten auf dieselbe Frage (z.B. "Was ist ein*e aktive*r Kund*in?"), hat das politische Folgen. Ownership ist oft historisch gewachsen und undokumentiert, neue Verantwortlichkeiten und mehr Transparenz können auf Widerstand stoßen. Ängste wie "KI nimmt mir den Job weg" werden selten offen ausgesprochen, können eine Datenstrategie aber durch passive Verweigerung ausbremsen. Das Gartner-Modell (deskriptiv, diagnostisch, prädiktiv, präskriptiv) hilft bei der Einordnung. Wo man steht, zeigt sich an den bisher erfolgreich umgesetzten Projekten....

#104: Treatment-Effekte messen: Was hat eine Maßnahme wirklich gebracht?

Oct 8, 2026 41 min

Ob in der Entwicklungszusammenarbeit, im Online-Marketing oder beim Pricing: Wer wissen will, was eine Maßnahme bewirkt hat, steht vor dem Problem, dass sich immer nur eine Welt beobachten lässt. In dieser Folge sprechen Mira und Amit darüber, wie sich trotzdem ein belastbares Counterfactual konstruieren lässt und warum Korrelation dafür nicht ausreicht. Sie gehen Studiendesigns von RCTs über Difference-in-Differences, Regression Discontinuity und Propensity Score Matching bis hin zu Instrumentvariablen, Synthetic Control und Panel-Methoden durch. Außerdem geht es um die Frage, welche Variablen in die Auswertung gehören, wie man Ergebnisse auf Robustheit prüft und was Dosis-Wirkungs-Beziehungen zusätzlich verraten. Ein Plädoyer dafür, die Auswertung schon vor Beginn einer Maßnahme mitzudenken. **Zusammenfassung** Das Kernproblem der Evaluation: Das Counterfactual ist unbeobachtbar, und ein statistischer Zusammenhang belegt noch keine Kausalität. Vor jeder Analyse steht die Wirkkette: Ohne logisches Verständnis, wie eine Maßnahme wirken soll, drohen falsche Metriken, übersehene Einflüsse und schlechte Vergleichsgruppen. Metriken sollten das messen, was wirklich zählt (z.B. Gewinn statt Auslastung, CLV statt Click-Through-Rate), und die Frage der Generalisierbarkeit gehört von Anfang an dazu. RCTs und A/B-Tests gelten als Goldstandard, setzen aber eine Poweranalyse vorab und eine saubere Auswertung voraus. Wenn Randomisierung nicht möglich ist, helfen DiD, RDD, Propensity Score Matching, Synthetic Control, Interrupted Time Series oder Fixed-Effects-Modelle, je nach Datenlage und Selektionsprozess. Instrumentvariablen lösen das Problem unbeobachteter Confounder wie Motivation, liefern aber nur einen lokalen Effekt (LATE), und die Ausschlussrestriktion lässt sich nicht statistisch testen. In der Analyse gehören Confounder ins Modell, Mediatoren nicht; Double ML, Causal Forests und Dosis-Wirkungs-Analysen erweitern das Werkzeugset. Robustheitschecks und eine Fehlerk...

#103: EU AI Act: Risikostufen, Pflichten und Watermarking mit SynthID

Sep 24, 2026 46 min

In dieser Folge sprechen wir über den EU AI Act: was er unter einem KI-System versteht, welche Risikostufen er unterscheidet und welche Regeln bereits gelten. Wir gehen auf die kurzfristigen Änderungen durch den EU AI Omnibus ein, unter anderem die verschobenen Fristen für Hochrisiko-Systeme. Außerdem erklären wir, welche Pflichten für Anbieter von General-Purpose-AI-Modellen gelten und welche Rolle der Code of Practice dabei spielt. Im Deep Dive zur Transparenzpflicht geht es darum, wie sich KI-generierte Inhalte kennzeichnen lassen und wie Text-Watermarking mit SynthID technisch funktioniert. Zum Schluss ordnen wir ein, was die Regulierung für Data-Science-Projekte in der Praxis bedeutet. **Zusammenfassung** Stand der Umsetzung: Verbotene Praktiken und die Pflicht zur KI-Kompetenz gelten seit dem 2.2.2025, die Transparenzpflichten seit dem 2.8.2026. EU AI Omnibus: Die Fristen für Hochrisiko-Systeme wurden auf den 2.12.2026 (Stand-alone) bzw. 2.12.2027 (eingebettet) verschoben, zudem kam ein Verbot nicht einvernehmlicher sexualisierter Deepfakes hinzu. Definition von KI: Der AI Act beschreibt KI-Systeme als maschinengestützte Systeme mit unterschiedlichem Autonomiegrad, die aus Eingaben ableiten, wie sie Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen erzeugen. Risikostufen: Unterschieden werden verbotene Praktiken (z. B. Manipulation, Social Scoring), Hochrisiko-Anwendungen (z. B. kritische Infrastruktur, Gesundheit, Bildung, Justiz) und die Restkategorie mit geringem Risiko. General-Purpose-AI: Große Foundation-Modelle unterliegen Dokumentations- und Informationspflichten, etwa zu Trainingsdaten und Urheberrecht; ab 10^25 FLOPs Trainingsaufwand wird ein systemisches Risiko vermutet. Code of Practice: Anbieter*innen können Compliance über den Code of Practice mit den Kapiteln Transparenz, Urheberrecht sowie Sicherheit und Gefahrenabwehr nachweisen. Kennzeichnung von KI-Inhalten: Bilder, Videos und Audio lassen sich per Wasserzeichen oder Metadaten (C2P...

#102: [PAIQ5] Predictive AI Quarterly

Sep 10, 2026 37 min

Die letzten Monate waren geprägt von neuen Foundation Models für tabellarische und sequentielle Daten: TabPFN 3 skaliert auf eine Million Beobachtungen, Google stellt mit TabFM ein eigenes Modell samt BigQuery-Integration vor, NXAI veröffentlicht TiRex-2 mit Kovariaten-Unterstützung, und an der Spitze von GIFT-Eval steht mit STRIDE eine Kombination aus LLM-Reasoning und Time Series Foundation Model. Dazu kommen der ClickHouse-MCP-Server und der Stand der Umsetzung des EU AI Act nach dem Digital Omnibus. Im Praxisteil vergleichen wir TabICL v2 mit einem getunten XGBoost, Meta Prophet und naiven Baselines auf stündlichen NO2-Messwerten von fünf Messstationen, ausgewertet über ein Jahr rollierender Kreuzvalidierung mit dem Mean Absolute Scaled Error. Wir zeigen, welches Feature-Engineering nötig ist, wie sich der Vorteil von TabICL mit der Länge der Historie verändert und was das an Rechenzeit kostet. Zum Schluss ordnen wir ein, wann sich ein Foundation Model für Zeitreihen anbietet und wann XGBoost die pragmatischere Wahl bleibt. **Zusammenfassung** TabPFN 3 (Mai 2026) skaliert auf einer H100 auf bis zu 1 Mio. Beobachtungen; verbessertes KV-Caching senkt die Prognosezeit auf 0,1–3 ms pro Testbeobachtung und macht das Modell für schnelle Batch-Prognosen nutzbar. Googles TabFM ist von TabPFN und TabICL inspiriert, liegt im TabArena-Benchmark vor TabPFN 3 und ist direkt in BigQuery integriert. TiRex-2 von NXAI setzt auf eine xLSTM- statt Transformer-Architektur und kann jetzt zusätzliche Kovariate einbeziehen – ein Test steht bei uns noch aus. STRIDE führt den GIFT-Eval-Benchmark an: Das LLM prognostiziert nicht selbst, sondern steuert über destillierte Embeddings ein Time Series Foundation Model. Kurz notiert: Der ClickHouse-MCP-Server (v0.4.1) erlaubt LLM-Abfragen ohne SQL, etwa zur Log-Diagnose; beim EU AI Act gelten die Transparenzpflichten seit August, die Kennzeichnung von Bestandssystemen greift ab dem 2.12.2026. Praxis-Setup: TabICL v2 mit Kalender-, Fourier...

#101: [DSK1] Data Strategy Kompass – Was Datenstrategie ist & was nicht

Aug 27, 2026 43 min

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

#100: Crash Course Data Science: Was Entscheider*innen wissen müssen

Aug 13, 2026 56 min

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

#99: Cluster-Architektur mit Kubernetes: self-hosted, managed oder gar nicht?

Jul 30, 2026 1 hr 0 min

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

#98: Risiken bei der Softwareentwicklung mit AI Agents

Jul 16, 2026 49 min

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

#97: Die Güte von Gen-AI-Projekten bewerten mit Tobias Sterbak

Jul 2, 2026 47 min

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

#96: Queer Data: Wie erfasst, bereinigt und analysiert man sensible Daten?

Jun 18, 2026 32 min

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

#95: GitOps: Deployments mit Ruhepuls

Jun 4, 2026 27 min

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

#94: [PAIQ4] Predictive AI Quarterly

May 21, 2026 37 min

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

#93: Bayesianische Statistik: Vorwissen und Daten kombinieren

May 7, 2026 33 min

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

#92: Anomaly Detection von Produktbildern mit ClickHouse

Apr 23, 2026 46 min

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

#91: Software ohne Entwickler*innen? Wie AI Agents unsere Arbeit neu definieren

Apr 9, 2026 46 min

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

#90: Demand Forecasting bei Krombacher – Mit Dr. Max Schüssler

Mar 26, 2026 45 min

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

#89: ROC around the clock – Alles rund um Gütemaße für Klassifikationsmodelle

Mar 12, 2026 36 min

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

#88: Anomalie-Erkennung im Loyalty-Programm bei Krombacher – Mit Fabian Wörenkämper

Feb 26, 2026 50 min

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

#87: [PAIQ3] Predictive AI Quarterly

Feb 12, 2026 32 min

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

#86: "Garbage In, Garbage Out" verhindern: Datenvalidierung richtig gemacht

Jan 29, 2026 39 min

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

#85: Technologieauswahl im Dschungel der Möglichkeiten

Jan 15, 2026 46 min

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/Kri...

Kurze Pause, frische Energie: Wir hören uns im neuen Jahr!

Dec 18, 2025 1 min

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 Erwartungsmanagement

Nov 13, 2025 30 min

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 verstehen

Oct 23, 2025 33 min

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

#82: Monitoring in MLOps: Tools, Tipps und Best Practices aus der Praxis

Oct 9, 2025 44 min

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

#81: [PAIQ2] Predictive AI Quarterly

Sep 25, 2025 26 min

In dieser Folge des Predictive AI Quarterly sprechen wir über die Veröffentlichung von GPT-5 und was sich im Vergleich zu GPT-4 geändert hat. Wir schauen uns an, wie Reasoning jetzt funktioniert und welche Optionen Entwickler*innen bei der Nutzung haben. Außerdem geht's um neue Open-Source-Modelle von OpenAI, die Einführung von TabArena als dynamischem Benchmark für Tabulardaten und spannende Integrationen wie TabPFN in Sourcetable. Im Praxisteil nehmen wir QLoRA unter die Lupe und testen, ob Finetuning mit Quantisierung wirklich so effizient und verlustfrei ist, wie versprochen. ** Zusammenfassung ** GPT-5 Release: Neues Reasoning-Feature, flexible Steuerung über Parameter und Empfehlungen für die Migration von GPT-4. Open-Source-Modelle von OpenAI: Veröffentlichung von 20B- und 120B-Modellen mit vergleichsweise moderatem Hardwarebedarf. TabArena: Dynamischer Benchmark für tabellarische Daten, der Ensembling und TabPFN bei kleinen Datensätzen hervorhebt. TabPFN in Sourcetable: Integration von Predictive AI direkt in Spreadsheets für nahtlose Nutzung. Praxis-Test QLoRA: Finetuning mit Quantisierung liefert gleiche Qualität wie LoRA, benötigt aber nur halb so viel Speicher. ** Links ** OpenAI – GPT-5 für Entwickler*innen vorgestellt: https://openai.com/de-DE/index/introducing-gpt-5-for-developers/ OpenAI – API Responses Referenz: https://platform.openai.com/docs/api-reference/responses/create OpenAI – Guide: Reasoning in GPT: https://platform.openai.com/docs/guides/reasoning OpenAI – Modell-Migrationsempfehlungen: https://platform.openai.com/docs/guides/latest-model#migration-guidance Hugging Face – Open-Source GPT 20B: https://huggingface.co/openai/gpt-oss-20b Hugging Face – Open-Source GPT 120B: https://huggingface.co/openai/gpt-oss-120b OpenAI – Ankündigung OSS-Modelle: https://openai.com/de-DE/index/introducing-gpt-oss/ Hugging Face – TabArena Leaderboard: https://huggingface.co/spaces/TabArena/leaderboard arXiv – TabArena Paper: https://arxiv.org/abs/2...

#80: Willkommen an Bord: Wie wir neue Kolleg*innen begleiten

Sep 4, 2025 36 min

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

#79: Data Science on the Edge: Modelle in verteilten Umgebungen

Aug 21, 2025 56 min

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

#78: Der Use-Case-Guide: Navigationshilfe für echten Mehrwert

Aug 7, 2025 46 min

In dieser Folge sprechen wir darüber, wie man den nächsten sinnvollen Data-Science-Use-Case identifiziert. Egal ob man gerade erst mit Daten startet oder schon komplexe Produkte im Einsatz hat. Wir klären, wer in den Prozess einbezogen werden sollte, worauf man bei der Ideenfindung achten sollte und wie man Use Cases richtig bewertet. Ein besonderer Fokus liegt auf der Perspektive der Nutzer*innen und die Umsetzbarkeit in Bezug auf Daten, Methoden und Technik. Eine Folge für alle, die Orientierung suchen, um den weiteren Weg auf ihrer Data-Journey zu gestalten. **Zusammenfassung** Zielgruppe: Organisationen, die mit Daten Mehrwert schaffen wollen, aber unklar sind, welcher Use Case der nächste sein sollte Ausgangssituation: Entweder besteht noch keine Idee, oder es gibt bereits eine Idee, deren Umsetzbarkeit geprüft werden soll Beteiligte Rollen: Entscheider*innen, Fachexpert*innen, Anwender*innen sowie Data- & IT-Personal sollten früh eingebunden werden Ideation-Phase: Kreative Suche nach Problemen mit Hebelwirkung mit Fokus auf Pain Points, Engpässe, repetitive Tätigkeiten und Business Value Nutzer*innenzentrierung: Anforderungen, Nutzungskontext und Entscheidungsprozesse der Anwender*innen bestimmen, was ein Use Case leisten muss Technische Implikationen: Die Form der Ergebnisausspielung (z. B. Dashboard, API, E-Mail) hängt direkt vom Nutzungskontext ab Machbarkeitsprüfung: Datenlage, methodische Passung und technische Umsetzbarkeit werden realistisch bewertet Datenstruktur: "Must-have" vs. "Nice-to-have"-Daten, typische Hürden wie fehlende IDs, Möglichkeiten zur Verknüpfung Reifegrad beachten: Nicht zu groß denken, sowohl Überforderung bei geringer Reife als auch Overengineering bei hoher Reife vermeiden Dienstleisterfrage: Strategisches Assessment und Umsetzung trennen oder vereinen, beide Varianten haben nachvollziehbare Vor- und Nachteile **Links** Das Data & AI Design Thinking Workshop Canvas von Datentreiber https://www.datentreiber.com/de/data-an...

#77: Uplift Modeling: Der kausale Effekt von Rabatten, Retargeting & Co.

Jul 24, 2025 33 min

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

#76: Digitale Souveränität: Risiken verstehen, souverän handeln

Jul 10, 2025 38 min

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

#75: Refactoring done right: Strategien, Risiken und Best Practice

Jun 26, 2025 50 min

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

#74: [PAIQ1] Predictive AI Quarterly

Jun 12, 2025 28 min

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

#73: Korrelation vs. Kausalität: Was braucht es für fundierte Entscheidungen?

May 29, 2025 44 min

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

#72: TabPFN: Die KI-Revolution für tabulare Daten mit Noah Hollmann

May 15, 2025 50 min

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

#71: Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek

May 1, 2025 26 min

In dieser Folge geht's um die Frage: Macht Größe von Large Language Models (LLMs) bei Predictive Analytics wirklich einen Unterschied? Wir vergleichen Open-Source-Modelle mit bis zu 70 Milliarden Parametern – und siehe da, das 8B-Modell schlägt das große Schwergewicht. Außerdem berichten wir vom Finetuning auf einer AWS-Maschine mit 8 A100-GPUs und den Herausforderungen in Bezug auf die Reproduzierbarkeit. Auch das viel diskutierte DeepSeek-Modell haben wir im Autopreis-Benchmark antreten lassen. Und wie immer fragen wir uns: Was ist praktisch und was ist overkill? **Zusammenfassung** Modellgröße ≠ bessere Prognosen: Das Llama-3.1-8B übertraf das größere 70B-Modell bei der Fahrzeugpreisprognose DeepSeek im Benchmark: Das chinesische Modell zeigt bei größeren Trainingsmengen eine ähnlich gute Performance wie das Llama-3.1-8B, ist bei kleinen Datensätzen aber schwächer Finetuning mit Multi-GPU auf AWS: Für das 70B-Modell war ein Setup mit 8 A100-GPUs nötig Reproduzierbarkeit bleibt schwierig: Trotz Seed erzeugen wiederholte Finetuning-Runs unterschiedliche Ergebnisse Modellselektion empfohlen: Um zuverlässige Prognosen zu erhalten, sollte aus mehreren Finetuning-Durchläufen das beste Modell ausgewählt werden CPU-Inferenz möglich, aber langsam: Im Vergleich zur GPU war die Vorhersage auf der CPU ca. 30-mal langsamer, Quantisierung könnte künftig Abhilfe schaffen Ausblick auf TabPFN & Quantisierung: Kommende Beiträge widmen sich Erfahrungen mit TabPFN und der praktischen Umsetzung von quantisierten LLMs auf kleineren Maschinen **Links** [Begleitender Blogartikel] Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek https://www.inwt-statistics.de/blog/predictive-llms-skalierung-reproduzierbarkeit-und-deepseek #50: Predictive Analytics mit LLMs: ist GPT3.5 besser als XGBoost? https://inwt.podbean.com/e/50-predictive-analytics-mit-llms-ist-gpt35-besser-als-xgboost/ #64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognose...

#70: Der Aufstieg zur Datenreife – Stufe für Stufe zur Data Maturity

Apr 17, 2025 46 min

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

#69: AI Agents verstehen und evaluieren mit Matthäus Deutsch

Apr 3, 2025 47 min

AI Agents sind mehr als nur Chatbots – aber wie bewertet man sie richtig? Wir sprechen über die Herausforderungen beim Testen von AI im Kundenservice, warum falsche API-Parameter ins Chaos führen und wieso "mysteriöser Fleischeintopf" ein PR-Desaster wurde. Matthäus Deutsch von Parloa berichtet, wie flexible Plattformintegrationen und evaluative Ansätze (z.B. assertion-based Testing und Simulationen) den Einsatz von AI Agents vorantreiben. Außerdem: welche Metriken wirklich zählen, was Multi-Agent-Setups leisten und warum der Preisverfall bei Open-Source-Modellen das Game verändert. Zusammenfassung AI Agents erweitern klassische Chatbots im Kundenservice, insbesondere im Telefonbereich, durch GenAI-basierte, dynamische Lösungen Parloa demonstriert flexible Plattformintegrationen und den Einsatz von Evaluationsmethoden wie assertion-based Testing und Simulationen Die Evaluation von AI Agents erfordert spezielles Benchmarking auf Plattform- und individueller Ebene Typische Herausforderungen sind Integrationsprobleme, fehlerhafte API-Calls und unzureichendes Instruction Following Tests erfolgen sowohl auf Konversationsebene als auch durch deterministische Ansätze und LLMs als Judge Es müssen komplexe Metriken und Trade-offs beachtet werden, wobei häufig binäre Testansätze aggregiert werden Schnelle Updates auf neue Modellversionen sind möglich, allerdings steigen langfristig die Kosten durch umfangreiche Testzyklen Innovationen wie optimierte Speech-to-Speech-Technologien und Open-Source-Lösungen (z. B. DeepSeek) bieten Potenzial zur Kostenreduktion Der Einsatz von Operatoren-Modellen und Tool-Integrationen ermöglicht auch die Anbindung an Legacy-Systeme, z.B. SAP Ziel ist es, den Automatisierungsanteil im Kundenservice zu erhöhen und eine Balance zwischen bewährter Qualität und neuen Features zu finden Links Matthäus Deutsch auf LinkedIn: https://www.linkedin.com/in/matth%C3%A4us-d-928864ab/ Parloa Contact-Center-AI-Plattform https://www.parloa.com/de/ Stellen...

#68: CI/CD für Daten: Datenversionierung für stabile & nachvollziehbare Systeme

Mar 20, 2025 41 min

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

#67: "It works on my machine" war gestern – Docker Best Practices für Data Science

Mar 6, 2025 34 min

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

#66: Developer vs. Data Scientist mit Andy Grunwald und Wolfgang Gassler

Feb 20, 2025 1 hr 3 min

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

#65: Sicher ist nur die Unsicherheit: Unsicherheitsintervalle erklärt

Feb 6, 2025 28 min

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

#64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen?

Jan 23, 2025 40 min

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*** [Blog] Predictive LLMs: Übertreffen Open-Source-Modelle OpenAI bei Preisprognosen? https://www.inwt-statistics.de/blog/predictive-llms-uebertreffen-os-modelle-openai-bei-preisprognosen [Podcast] #50: Predictive Analytics mit LLMs: ist GPT3.5 besser als XGBoost? https://www.podbean.com/ew/pb-n6wem-165cb2c [Blog] Predictive LLMs: Kann GPT-3.5 die Prognosen von XGBoost verbessern? https://www.inwt-statistics.de/blog/predictive-llms-kann-gpt-xgboost-prognosen-verbessern [Podcast] #43: Damit es im Liv...

#63: Data Mining: der pragmatische Weg zu Datenreife & Datenkultur mit Prof. Dr. Ana Moya

Jan 9, 2025 42 min

„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*** Prof. Dr. Ana Moya auf LinkedIn: https://www.linkedin.com/in/doc-moya/ International School of Management (ISM) https://en.ism.de/ INFOMOTION GmbH https://www.infomotion.de/ Power BI https://www.microsoft.com/de-de/power-platform/products/power-bi?market=de Tableau https://www.tableau.com/ Python https://www.python.org/ R https://www.r-project.org/ Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

#62: Kafka und Datenströme erklärt – und wie das jetzt auch in R läuft

Dec 19, 2024 21 min

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 Apache Kafka https://kafka.apache.org/ Confluent https://www.confluent.io/ Rcpp (CRAN) https://cran.r-project.org/web/packages/Rcpp/index.html reticulate (CRAN) https://cran.r-project.org/web/packages/reticulate/index.html R Paket kafka auf GitHub https://github.com/INWTlab/r-kafka Blogartikel zum R Paket kafka https://www.inwt-statistics.de/blog/r-paket-kafka nats https://nats.io/ Azure EventHub https://azure.microsoft.com/de-de/products/event-hubs Redpanda https://www.redpanda.com/ Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

#61: Technologische Must-Haves: Unser Survival-Guide für Data-Science-Projekte

Dec 5, 2024 42 min

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 AI

Nov 21, 2024 41 min

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*** #4: Job-Profile & Arbeitsmarkt https://www.podbean.com/ew/pb-aurkr-126887d https://de.wikipedia.org/wiki/Hype-Zyklus Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

#59: Besser mit Helm: komplexe Deployments einfach(er) umsetzen

Nov 7, 2024 18 min

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*** #14: Kubernetes https://www.podbean.com/ew/pb-m5ggz-13454c7 #28: Unsere Erkenntnisse aus einem Fraud-Detection-Projekt mit Echtzeitdaten https://www.podbean.com/ew/pb-we2f3-145e5fe #38: Im Rennen gegen die Zeit: Echtzeitprognosen mit komplexen statistischen Modellen https://www.podbean.com/ew/pb-u5qsn-1548784 https://helm.sh/ https://kubernetes.io/ https://argo-cd.readthedocs.io/en/stable/ Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

#58: Arm, aber sexy: Data Warehousing at Scale ohne Budget

Oct 24, 2024 37 min

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*** #52: In-process Datenbanken und das Ende von Big Data https://www.podbean.com/ew/pb-tekgi-16896e4 Engineering Kiosk - #129 Simplify Your Stack: Files statt Datenbanken! https://engineeringkiosk.dev/podcast/episode/129-simplify-your-stack-files-statt-datenbanken/ https://delta.io/ https://ibis-project.org/ https://duckdb.org/