Data Science Deep Dive

Die Tech-Welt bietet heute mehr Auswahl denn je und damit auch viel mehr Möglichkeiten, genau die passende Lösung für den eigenen Kontext zu finden. Wir sprechen darüber, warum Entscheidungen nicht mehr über ein einzelnes Kriterium laufen, sondern vor allem vom Systemumfeld, Teamwissen und organisatorischen Rahmenbedingungen abhängen. Anhand praxisnaher Beispiele zeigen wir, wie man trotz Compliance, Cloud-Ökosystemen oder "Tool-Hype" zu soliden, nachhaltigen Entscheidungen kommt. Außerdem ordnen wir typische Kriterien ein und erklären, wie man mit kleinen Tests, klaren Prioritäten und Lernschleifen die Risiken reduziert. Das Fazit: Die Vielfalt ist ein Vorteil, aber nur wenn man strukturiert auswählt, ausprobiert und den Stack sehr bewusst weiterentwickelt.
**Zusammenfassung**
Früher waren Technologieentscheidungen oft simpel, weil es nur wenige Alternativen gab
Heute ist die Landschaft extrem breit, selbst innerhalb von Open Source
Stärken findet man schnell, Schwächen und Grenzen zeigen sich oft erst im Betrieb
Fehlentscheidungen wirken lange nach und können Teams über Jahre ausbremsen
Herstellerempfehlungen sind erwartbar parteiisch, Beratung bringt oft Erfahrungs-Bias mit
Der Kontext (System, Organisation, Restriktionen) ist entscheidender als eine "Feature-Liste"
Beispiele zeigen typische Fallen: Overengineering, Compliance-Zwänge, Cloud-Lock-in, "Tech ausprobieren"
Kriterien wie Kosten, Verfügbarkeit, Sicherheit, Support, Latenz und digitale Souveränität konkurrieren je nach Projekt unterschiedlich stark
Unerwartete Probleme entstehen oft außerhalb der Specs (Bugs, Release-Qualität, Support-Realität)
Ein Tech-Radar und iterative Weiterentwicklung des Stacks helfen, Entscheidungen robuster zu machen
**Links**
Thoughtworks Technology Radar (Adopt / Trial / Assess / Hold) https://www.thoughtworks.com/radar
Positionspapier: "Kriterien zur Identifikation und Auswahl von digitalen Schlüsseltechnologien" von bitkom https://www.bitkom.org/Bitkom/Publikationen/Kriterien-zur-Identifikation-und-Auswahl-von-digitalen-Schluesseltechnologien
Episode #29: Die Qual der Wahl: Data Science Plattform vs. Customized Stack https://www.podbean.com/ew/pb-pep8h-147029f
📬 Fragen, Feedback oder Themenwünsche?Schreibt uns gern an: podcast@inwt-statistics.de

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!

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

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

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

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

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

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

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

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