Saltar al contenido
Data Science Deep Dive
PodcastTecnologíaAlemán

Data Science Deep Dive

de INWT Statistics GmbH

Nuevo#106: Die AI Pill im Realitätscheck: Agentic Programming und Produktivität5 de noviembre de 2026 · 51 min
Episodios
100
Se publica
cada dos semanas
Último episodio
5 Nov 2026
Sitio webFeed RSS

Sobre el podcast

Hacemos Data Science. Y en nuestro podcast Data Science Deep Dive hablamos de ello. ¿Tú también eres Data Scientist o te interesan los datos, el ML y la IA? Entonces este podcast es para ti. Compartimos lo aprendido en más de 180 proyectos y te ofrecemos información e ideas sobre temas apasionantes en torno a los datos. Aclaramos dudas, damos consejos y compartimos las experiencias que hemos acumulado en más de 10 años como Data Scientists en el ámbito B2B. Desvelamos qué hay realmente detrás de los hypes y las tendencias del sector de la Data Science. Analizamos qué hace que un proyecto de Data Science tenga éxito y qué factores lo condenan al fracaso.

Episodios 100

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

    51 minEpisodio 109

    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 …

    Notas del episodio

    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 Agenten nur an günstigen Feedback-Schleifen lernen, während Expert*innen diese als Proxy für teure Schleifen einordnen können.
    • Arbeitsmarkt: In Deutschland steigt die IT-Arbeitslosigkeit, liegt aber weiterhin unter 4 %. Besonders Berufseinsteiger:innen haben es schwerer. In den USA liegt sie bei etwa 3,5 %, bei Entry-Level-Softwareentwickler*innen bei rund 7 %.
    • Essay-Studie mit EEG: Die kleine Studie mit 54 Teilnehmenden zeigt, dass LLM-Nutzer*innen homogene, gut bewertete Aufsätze schreiben, daraus aber kaum zitieren können. Ohne Tools war die neuronale Vernetzung am stärksten.
    • Fazit: Goodhart’s Law gilt auch für Produktivitätsmetriken. KI hilft, wenn sie Menschen ermöglicht, ihre Arbeit selbstbestimmt zu verbessern (Zentaur). Sie schadet, wenn sie vor allem mehr Output mit weniger Qualität erzwingt (Reverse Zentaur).

    **Links**


    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    45 minEpisodio 108

    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 …

    Notas del episodio

    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.
    • Empfehlung: immer nur eine Stufe auf einmal nach oben gehen. Gute Ideen auf hoher Stufe lassen sich herunterbrechen, und die Erkenntnisse auf niedrigeren Stufen decken Datenprobleme auf und liefern Input für spätere Modelle.

    **Übersichtstabelle für den Selbst-Check**

    Dimension Status quo Chancen / Hebel Konfliktpotenzial Strategische Entscheidungen Welche Entscheidungen basieren heute auf Daten? Welche Entscheidungen sollten datenbasiert verbessert werden? Wer müsste Entscheidungsbefugnisse teilen oder anpassen? Ownership & Governance Gibt es klare Data Owner? Sind Berechtigungen klar geregelt? Wo könnte klare Ownership Effizienz schaffen? Wo droht Kontrollverlust? Daten Welche Daten existieren wo? In welcher Qualität? Welche Kombinationen könnten neuen Mehrwert schaffen? Wer „besitzt“ die Daten? Externe Partner? Architektur Sind Systeme verbunden oder isoliert? Wo kann Modularität Skalierung ermöglichen? Bestehen Abhängigkeiten von Dienstleistern? Use Cases & Projekte Welche PoCs / Projekte gab es? Was wurde skaliert? Wo liegt ein Hebel >100.000 €/Jahr? Wo konkurrieren Projekte um Budget? Organisatorische Beteiligte Wer ist beteiligt? Wo entstehen Synergien? Wo entstehen Zielkonflikte? Kultur & HR Wie ist die generelle Einstellung der Mitarbeitenden ggü. Neuerungen, Daten & KI? Wer sind die Antreiber*innen? Wer übernimmt Verantwortung für Leuchtturmprojekte? Wo entstehen Missverständnisse oder Ängste? („KI nimmt den Job weg“)
    Welche Skills fehlen?


    **Links**

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    41 minEpisodio 107

    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 …

    Notas del episodio

    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 Fehlerkultur, in der auch "wirkt nicht" ein wertvolles Ergebnis ist, sind entscheidend für glaubwürdige Evaluation.

    **Links**

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    47 minEpisodio 106

    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 …

    Notas del episodio

    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 (C2PA) markieren, Texte über eine subtile Beeinflussung der Token-Auswahl wie bei SynthID – beide Ansätze haben aber klare Grenzen bei Erkennung und Manipulationssicherheit.
    • Bedeutung für die Praxis: Wichtig sind die Risikoeinordnung eines Projekts, eingebaute Transparenzmechanismen etwa bei Chatbots und dokumentierte Maßnahmen zur KI-Kompetenz – vieles davon entspricht ohnehin guter Praxis.

    **Links**

    Lust auf einen Schnack bei der goto; Konferenz in Kopenhagen?

    Sebastian auf LinkedIn: https://www.linkedin.com/in/sebastianwarnholz

    goto; Konferenz in Kopenhagen: https://gotocph.com/2026

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

  5. #102: [PAIQ5] Predictive AI Quarterly

    37 minEpisodio 105

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    43 minEpisodio 103

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    56 minEpisodio 102

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?

    Schreibt uns gern an: [email protected]

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

    1 hEpisodio 101

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

  9. #98: Risiken bei der Softwareentwicklung mit AI Agents

    49 minEpisodio 100

    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 …

    Notas del episodio

    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 und Aktionen kaum noch kontrollierbar machen.

    **Links**

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    48 minEpisodio 99

    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 …

    Notas del episodio

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

    Fragen, Feedback oder Themenwünsche?

    Schreibt uns gern an: [email protected]

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

    32 minEpisodio 98

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

  12. #95: GitOps: Deployments mit Ruhepuls

    28 minEpisodio 97

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?

    Schreibt uns gern an: [email protected]

  13. #94: [PAIQ4] Predictive AI Quarterly

    38 minEpisodio 96

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

  14. #93: Bayesianische Statistik: Vorwissen und Daten kombinieren

    34 minEpisodio 95

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

  15. #92: Anomaly Detection von Produktbildern mit ClickHouse

    47 minEpisodio 94

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    47 minEpisodio 93

    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 …

    Notas del episodio

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


    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    46 minEpisodio 91

    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 …

    Notas del episodio

    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: < 10 % MAPE erreicht für bis zu fünf Werktage im Voraus
    • Corona-Effekte über Dummy-Variablen berücksichtigt, besonders relevant für Gastronomie-Fässer
    • Wechsel von AWS Custom Stack (SageMaker, MLflow, API) zu Databricks zur besseren Skalierbarkeit und Wartbarkeit
    • Zentrale Learnings: Domänenwissen > Modellkomplexität, Use Case klar definieren, Datenqualität als Fundament

    **Links**

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    37 minEpisodio 92

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    50 minEpisodio 90

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

  20. #87: [PAIQ3] Predictive AI Quarterly

    33 minEpisodio 89

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    39 minEpisodio 88

    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 …

    Notas del episodio

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

  22. #85: Technologieauswahl im Dschungel der Möglichkeiten

    47 minEpisodio 87

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    1 minEpisodio 86

    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 …

    Notas del episodio

    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!

  24. #84: Body Leasing: Zwischen Beratung, Teamkultur und Erwartungsmanagement

    31 minEpisodio 85

    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 …

    Notas del episodio

    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

  25. #83: Wie gut ist gut genug? Modellgütemaße richtig verstehen

    34 minEpisodio 84

    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 …

    Notas del episodio


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

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

    44 minEpisodio 83

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

  27. #81: [PAIQ2] Predictive AI Quarterly

    26 minEpisodio 82

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    36 minEpisodio 81

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    56 minEpisodio 80

    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 …

    Notas del episodio

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


    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

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

    46 minEpisodio 79

    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 …

    Notas del episodio

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

    📬 Fragen, Feedback oder Themenwünsche?
    Schreibt uns gern an: [email protected]

Aquí están los 40 episodios más recientes de 100. Los anteriores están en el feed del podcast.

Podcasts similares

Más podcasts de Tecnología
¿Es tu podcast?

Confírmalo con una entrada en tu feed: aquí recibes un código, lo añades como podcast:txt en el canal de tu feed y nosotros lo comprobamos. Después tu podcast aparecerá como «verificado» en SoundNode.

Géneros populares

PopOldiesHip hopRockLos 80SchlagerNoticiasAlternativaDanceMetalTechnoLos años 90ElectroHouse

Ajustes

Visualización

Idioma

DeutschEnglishEspañolFrançaisPortuguês

Determina qué emisoras ves primero en la página de inicio.

Historial

Las emisoras y episodios escuchados recientemente y tus últimas búsquedas solo se guardan en este navegador.

Avisos

Un breve aviso cuando un pódcast que sigues tiene un episodio nuevo. Puedes desactivar pódcast concretos con la campana de su página.

Cuenta

Guarda tus favoritos: en la app y en la web.

App StoreGoogle PlayAmazon Fire TVSonos

Atajos de teclado

/
Abrir búsqueda
Espacio
Reproducir o pausar
← →
En el reproductor: 15 s atrás, 30 s adelante (episodios) · en una fila: siguiente tarjeta
↑ ↓
En una fila: destino dentro de la tarjeta
Inicio / Fin
En una fila: primera o última tarjeta
Esc
Cerrar ventana o menú
?
Este resumen
Reproduciendo ahora

Ir a la emisora

A continuación

    Añade episodios con «A continuación»: sonarán después del episodio actual.