Data Science Deep Dive

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- und Lag-Features gegen getuntes XGBoost, Prophet, TabICL out-of-the-box sowie Naive und Seasonal-Naive; stündliche NO2-Daten, 24-Stunden-Horizont, Metrik MASE.

Ergebnisse: Bei zwei Jahren Historie liegt TabICL klar vorn, bei rund 8.000–9.000 Trainingsbeobachtungen ist XGBoost praktisch gleichauf, bei drei Monaten Historie noch etwa 4 % schlechter; ohne jedes Feature-Engineering schlägt TabICL Prophet und die naiven Baselines deutlich.

Kosten: Die Kreuzvalidierung mit TabICL auf einer L40S-GPU dauert etwa 17-mal länger als mit XGBoost, auf CPU ist das Modell nicht praktikabel – Caching dürfte diesen Nachteil künftig verkleinern.

 

**Links**

Link zum begeleitenden Blogartikel "TabICL v2 für Zeitreihen: Das In-Context-Learning-Modell im Vergleich mit XGBoost und Meta's Prophet" https://www.inwt-statistics.de/blog/tabicl_v2_fuer_zeitreihen

#72: TabPFN: Die KI-Revolution für tabulare Daten mit Noah Hollmann https://www.podbean.com/ew/pb-94ri2-18aca83

#57: Mehr als heiße Luft: unsere Berliner Luftschadstoffprognose mit Dr. Andreas Kerschbaumer https://www.podbean.com/ew/pb-u6xwt-16ff139

TabPFN-3 Technical Report: https://priorlabs.ai/technical-reports/tabpfn-3

TabPFN auf GitHub: https://github.com/PriorLabs/TabPFN

Google Research zu TabFM: https://research.google/blog/introducing-tabfm-a-zero-shot-foundation-model-for-tabular-data/

TabFM in BigQuery: https://cloud.google.com/blog/products/data-analytics/tabfm-adds-predictive-ml-to-bigquery

TiRex-2 (NXAI): https://www.nx-ai.com/en/tirex-2 | Code: https://github.com/NX-AI/tirex-2 | Paper: https://arxiv.org/abs/2607.01204

STRIDE – Reasoning-Aware Training for Time Series Forecasting: https://arxiv.org/abs/2605.08625

Time Series LLMs am Beispiel t0-alpha: https://towardsdatascience.com/time-series-llms-explained-with-t0-alpha/

ClickHouse MCP Server: https://github.com/ClickHouse/mcp-clickhouse

EU AI Act nach dem Digital Omnibus (Überblick): https://www.deloitte.com/de/de/issues/innovation-ai/eu-ai-act-digital-omnibus.html

TabICL v2 auf GitHub: https://github.com/soda-inria/tabicl

TabICL-Dokumentation: https://tabicl.readthedocs.io/en/latest/

Tutorial zum TabICLForecaster: https://tabicl.readthedocs.io/en/latest/tutorials/time_series_forecasting.html

Meta Prophet: https://github.com/facebook/prophet

GIFT-Eval Leaderboard: https://huggingface.co/spaces/Salesforce/GIFT-Eval

TabArena Leaderboard: https://huggingface.co/spaces/TabArena/leaderboard

 

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

Keine reguläre Folge, sondern eine Stellenausschreibung zum Hören: Wir suchen eine*n MLOps Engineer (all genders) für unser Team in Teil- oder Vollzeit, mit oder ohne Berufserfahrung. Michelle arbeitet selbst in diesem Bereich und erzählt, wie der Alltag zwischen Modell-Pipelines, Deployment und Kund*innenprojekten tatsächlich aussieht. Wir gehen kurz durch, was zu den Aufgaben gehört, was wir uns fachlich wünschen und was wir bieten. Bewerbungsschluss ist der 13. September 2026.

 

Link zur Stellenausschreibung: https://www.inwt-statistics.de/career/mlops-engineer

Bewerbung und Fragen bitte an: jobs@inwt-statistics.de

Ansprechpartnerin: Rebekka Krause, Referentin People & Culture, +49 30 1208231-54

Ein Geschäftsführer will im Quartalsmeeting wissen, welche Kundengruppe die profitabelste ist – der Vertrieb antwortet mit einer Zahl aus Excel, das Controlling mit einer anderen aus SAP, und das Meeting endet ohne Entscheidung. Mit dieser Szene startet der "Data Strategy Kompass", eine vierteilige Serie über Datenstrategie im Mittelstand. In Teil 1 klären Mira und Amit, was eine Datenstrategie ist und was sie nicht ist: keine Software-Entscheidung und kein Data-Warehouse-Projekt, sondern die Frage, welche Entscheidungen ein Unternehmen künftig besser treffen will. Sie gehen die Bestandteile durch – von der Anbindung an die Unternehmensstrategie über Datenhaltung und Governance bis zum menschlichen Faktor – und diskutieren, wann sich eine Datenstrategie lohnt und wann eher nicht. Anhand von Beispielen und Gegenbeispielen aus über 15 Jahren Projektarbeit zeigen sie, woran es in der Praxis meist hängt: selten an der Technik.

**Zusammenfassung**

Datenstrategie beantwortet die Frage "Welche Entscheidungen wollen wir besser treffen?" und nicht "Welche Software kaufen wir?"

Erst Use Cases, dann Infrastruktur: Alles zu speichern und später zu schauen, wofür man es braucht, ist ein Relikt der Big-Data-Zeit

Bestandteile: Verbindung zur Unternehmensstrategie, Priorisierung von Use Cases, Datenhaltung und Architektur, Governance, Organisation und Kultur

Kein isoliertes Projekt einer Datenabteilung: Es braucht die Führungsebene, mehrere Fachbereiche und kontinuierliche Anpassung

Personalbedarf wird unterschätzt: gebraucht werden vor allem Menschen, die Pipelines bauen und Daten aufbereiten, nicht nur Data Scientists

Wann es sich nicht lohnt: zehn Mitarbeitende und ein Excel; niemand ist bereit, datenbasiert zu entscheiden; Daten dienen nur der Rechtfertigung ohnehin gefasster Meinungen

Datenbasiert heißt nicht "alle Entscheidungen datenbasiert": Strategische Weichenstellungen kommen oft ohne belastbare Datenbasis aus

Typische Stolpersteine aus der Praxis: SaaS-Tool ohne Datenexport, parallele Excel-Welten ohne Dokumentation, Compliance-Lücken bereits bei der Datenerhebung

**Zum Mitnehmen: vier Fragen für den nächsten Führungskreis**

Welche Entscheidung wurde in den letzten drei Monaten aus dem Bauch heraus getroffen, weil die Zahlen fehlten? 

Wenn du heute drei wichtige Fragen an deine Daten stellen könntest, welche wären das? 

Wer würde der KI (z.B. eine Prognose, nicht Chatbot ist gemeint) vertrauen, wenn sie ihr/ihm widerspricht?

Die Datenprojekte, die wir schon machen - wissen wir, wie viel sie uns eigentlich bringen?

**Links**

#33: Data Science bei Zalando – Dr. Claudia Baldermann im Gespräch über Product Development & Organisation https://www.podbean.com/ew/pb-q25zg-14b82e0

#5: Data Warehouse vs. Data Lake vs. Data Mesh https://www.podbean.com/ew/pb-a4xzx-127be01

#36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1

Data Mesh Principles and Logical Architecture (Zhamak Dehghani): https://martinfowler.com/articles/data-mesh-principles.html

INWT Website: https://www.inwt-statistics.de/

**Ausschreibung MLOps Engineer**

https://www.inwt-statistics.de/career/mlops-engineer

 

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

Folge 100 bündelt, was Entscheider*innen über Data Science wissen sollten – aufgeteilt in vier Blöcke: Begriffsklärung, Datenqualität, Modellgüte und Erfolgsfaktoren. Mira und Amit ordnen ein, wie KI, Machine Learning und Statistik zusammenhängen, was supervised von unsupervised Learning unterscheidet und welche der vier Stufen der Datenanalyse für welche Fragestellung überhaupt nötig ist. Beim Thema Daten geht es um Validierung vor der eigentlichen Analyse, fehlende Zielvariablen und typische Formatprobleme, bei der Modellgüte um passende Gütemaße, Benchmarks, Overfitting, Explainability und die Evaluation von GenAI. Der letzte Teil behandelt die Frage, warum Datenprojekte in der Schublade landen: Auswahl des Use Cases, der Aufwandssprung von PoC zu MVP und Produkt sowie der eigene Data-Maturity-Level. Zum Abschluss stehen die fünf häufigsten Fehler.

 

**Zusammenfassung**

 

Begriffe sortieren: KI ist als Überbegriff meist unscharf gemeint, zwischen Statistik und ML gibt es einen fließenden Übergang – entscheidend ist, ob Zusammenhänge verstanden oder Prognosen erstellt werden sollen.

Vier Stufen der Datenanalyse: deskriptiv, diagnostisch, prädiktiv, präskriptiv – oft liefert schon die erste Stufe den Großteil der Erkenntnisse, Stufen lassen sich schlecht überspringen.

Datenqualität vor Datenquantität: viele korrekte, aber irrelevante Spalten verbessern keine Prognose; fehlerhafte Daten sind das größere Problem – gilt für tabulare Daten wie für RAG-Dokumente.

Validierung zuerst: explorative Analysen, Verteilungen und Ausreißerprüfung deckt Datenprobleme auf und erzeugt selbst schon Erkenntnisse.

Das Gütemaß hängt vom Use Case ab: Kosten von False Positives und False Negatives unterscheiden sich, ein einfaches Benchmark-Modell zeigt, ob der Aufwand sich lohnt.

Overfitting vermeiden: immer out-of-sample auf einem Testdatensatz evaluieren und zeitliche Struktur berücksichtigen – sonst sind Prognosen ungenauer als erwartet und man sieht Zusammenhänge, die es nicht gibt.

GenAI-Evaluation ist der Engpass: ein PoC entsteht schnell, das MVP wird durch Bewertungsfragen (LLM as a Judge, User Testing) deutlich aufwändiger.

Erfolgsfaktoren: konkreter Use Case mit messbarem Hebel, frühe Einbindung der Nutzer*innen, Implementierung von Anfang an mitdenken und Projekte zum eigenen Reifegrad wählen.

 

**Links**

Blogartikel zu Erfolgsfaktoren für Data-Science-Projekte https://www.inwt-statistics.de/blog/erfolgsfaktoren-fuer-data-science-projekte

Folge #6: Statistik vs. Machine Learning https://www.podbean.com/ew/pb-ewip2-128c6f8

Folge #83: Wie gut ist gut genug? Modellgütemaße richtig verstehen https://www.podbean.com/eas/pb-8q2a8-19a0252

Folge #89: ROC around the clock – Alles rund um Gütemaße für Klassifikationsmodelle https://www.podbean.com/eas/pb-6jfj7-1a6a8ba

Folge #43: Damit es im Live-Betrieb nicht kracht: Vermeidung von Overfitting & Data Leakage https://www.podbean.com/ew/pb-vw736-15baac0

Folge #86: "Garbage In, Garbage Out" verhindern: Datenvalidierung richtig gemacht https://www.podbean.com/eas/pb-5kyzq-1a305ed

Folge #2: Erfolgsfaktoren für Predictive Analytics Projekte https://www.podbean.com/ew/pb-kdcmd-12460ab

Folge #78: Der Use-Case-Guide: Navigationshilfe für echten Mehrwert https://www.podbean.com/ew/pb-s5e2r-1928b4f

Folge #21: Machine Learning Operations (MLOps) https://www.podbean.com/ew/pb-taen7-13ce0fa

Folge #23: Unsexy aber wichtig: Tests und Monitoring https://www.podbean.com/ew/pb-vxp58-13f311a

Folge #24: Explainable AI: Entscheidungen von Black-Box-Modellen verstehen https://www.podbean.com/ew/pb-kn67b-1403089

Folge #47: Von Prognosen und Prompts: Data Science trifft generative KI mit Tobias Sterbak https://www.podbean.com/ew/pb-dkyex-1613842

Folge #70: Der Aufstieg zur Datenreife – Stufe für Stufe zur Data Maturity https://www.podbean.com/ew/pb-a7663-1882b25

Folge #32: Brauche ich Data-Science-Berater*innen und wenn ja wie viele? https://www.podbean.com/ew/pb-eaekc-14a6bbe

Folge #69: AI Agents verstehen und evaluieren mit Matthäus Deutsch https://www.podbean.com/ew/pb-cq7xp-186d96d

Folge #80: Willkommen an Bord: Wie wir neue Kolleg*innen begleiten https://www.podbean.com/ew/pb-232sr-1953fe6

Folge #51: Wer rastet, rostet: Die Rolle von Weiterbildung in Data Science https://www.podbean.com/ew/pb-czpd3-16716c0

Folge #97: Die Güte von Gen-AI-Projekten bewerten mit Tobias Sterbak https://www.podbean.com/eas/pb-7fhem-1b0096c

📬 Fragen, Feedback oder Themenwünsche?

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

Sebastian und Michelle sprechen in dieser Folge über Cluster-Architektur mit Kubernetes: was das Tool leistet, welche Betriebsvarianten es gibt und für wen sich der Einsatz überhaupt rechnet. Ausgangspunkt sind die typischen Gründe für k8s – Skalierung, Ausfallsicherheit durch Health Checks und Rolling Updates sowie Infrastructure as Code. Danach geht es um die Frage self-hosted (k8s, k3s) oder managed (AWS, GCP, Azure) und um den Unterschied zwischen plain Kubernetes und Red Hat OpenShift. Ein zweiter Schwerpunkt liegt auf dem Zuschnitt der Umgebung: wie viele Cluster sinnvoll sind (pro Stage, pro Produkt) und wie innerhalb eines Clusters mit Namespaces und Network Policies getrennt wird. Zum Schluss diskutieren die beiden Alternativen ohne Kubernetes und die Voraussetzungen, die im Team erfüllt sein müssen.

 

**Zusammenfassung**

Kubernetes verwaltet containerisierte Anwendungen und arbeitet mit Docker zusammen – die beiden Tools sind keine Konkurrenz

Hauptargumente für k8s: Skalierung und Ressourcennutzung, Verfügbarkeit über Health Checks (Liveness, Readiness), Rolling Updates und Rollbacks, Konfiguration als Code in YAML

Self-hosted (k8s, k3s) bedeutet eigene Versions-Updates und Skills in Systemadministration und Provisionierung; Managed Cluster kosten mehr, reduzieren aber Maintenance und erhöhen die Verfügbarkeitsgarantie

OpenShift bringt eigene CLI, UI, Monitoring und Enterprise Support mit (Open-Source-Variante: OKD), plain k8s läuft dafür auf schlankerer Hardware

Anzahl der Cluster: mindestens eine Trennung von DEV und PRD, größere Organisationen provisionieren pro Produkt x Stage – jedes zusätzliche Cluster bedeutet mehr Aufwand für Updates, Monitoring und Provisionierung

Trennung nach Produkt statt nach Team, weil Zuständigkeiten sich ändern; Namespaces sind die leichtgewichtige Alternative zur vollen Isolation

Network Policies funktionieren wie Firewall-Regeln für Pods (Ziel/Quelle, ingress/egress); standardmäßig ist alles erlaubt, sobald ein Pod eine Policy hat, gilt für ihn Deny-All – ein Deny-All pro Namespace ist deshalb Pflicht

Alternative für kleine Setups: ein oder zwei VMs mit mehreren Instanzen hinter einem Loadbalancer, Rolling Updates per Skript; entscheidend sind Produkt, Verfügbarkeitsanspruch und vorhandenes Know-how

 

**Links**

Episode #14: Kubernetes https://inwt.podbean.com/e/14-kubernetes/

Training Course by The Linux Foundation: Introduction to Kubernetes (LFS158) https://training.linuxfoundation.org/training/introduction-to-kubernetes/ 

Kubernetes: https://kubernetes.io/

k3s: https://k3s.io/

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