Data Science Deep Dive

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


 


**Zusammenfassung**


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


**Links**


#47: Von Prognosen und Prompts: Data Science trifft generative KI mit Tobias Sterbak https://www.podbean.com/ew/pb-dkyex-1613842 Tobias Sterbak auf LinkedIn: https://www.linkedin.com/in/tobias-sterbak/


 


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

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


 


**Zusammenfassung**


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


 


**Links**


Buch "Queer Data" von Kevin Guyan: https://kevinguyan.com/queer-data/ Buch "Rainbow Trap" von Kevin Guyan: https://kevinguyan.com/rainbow-trap/ Buch "Data Feminism" von Catherine D'Ignazio und Lauren F. Klein (MIT Press, frei verfügbar): https://data-feminism.mitpress.mit.edu/ Episode #40: Sonderfolge: Frauen in Data Science und Tech mit Catrin & Isa von Mind the Tech https://www.podbean.com/eas/pb-ypy32-15747e6 Episode #93: Bayesianische Statistik: Vorwissen und Daten kombinieren https://www.podbean.com/eas/pb-crgji-1ab8218


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

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


 


**Zusammenfassung**


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


**Links**


ArgoCD: https://argo-cd.readthedocs.io FluxCD: https://fluxcd.io ArgoCD Image Updater: https://argocd-image-updater.readthedocs.io Sealed Secrets: https://github.com/bitnami-labs/sealed-secrets External Secrets Operator: https://external-secrets.io Helm: https://helm.sh Kustomize: https://kustomize.io Kubernetes: https://kubernetes.io


Fragen, Feedback oder Themenwünsche?


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

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


 


**Zusammenfassung**


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


 


**Links**


Predictive LLMs: Die Rolle multimodaler Daten bei der Preisprognose https://www.inwt-statistics.de/blog/predicitve-llms-rolle-multimodaler-daten HyperAgents (Zhang et al., 2026): Paper unter https://arxiv.org/abs/2603.19461, Code unter https://github.com/facebookresearch/Hyperagents Feitelberg, J., Saha, D., Choi, K., Ahmad, Z., Agarwal, A. & Dwivedi, R.: TabImpute: Universal Zero-Shot Imputation for Tabular Data. https://arxiv.org/pdf/2510.02625 TabICL GitHub Repo https://github.com/soda-inria/tabicl OpenAI Developers: Vision fine-tuning https://developers.openai.com/api/docs/guides/vision-fine-tuning


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