Data Science Deep Dive

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: [email protected]

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

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: [email protected]

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