Data Science Deep Dive

Data Science Deep Dive

INWT Statistics GmbH

Wir machen Data Science. Und in unserem Podcast Data Science Deep Dive reden wir darüber.

Du bist ebenfalls Data Scientist oder interessierst dich für Daten, ML und AI? Dann ist dieser Podcast für dich. Wir teilen unsere Learnings aus über 180 Projekten, du bekommst Infos und Anregungen zu spannenden Themen rund um Daten.

Wir klären auf, geben Hinweise und teilen unsere Erfahrungen, die wir in über 10 Jahren als Data Scientists im B2B Bereich gesammelt haben.
Wir decken auf, was wirklich hinter den Hypes und Trends der Data Science Branche steckt.
Wir hinterfragen, was ein Data Science Projekt erfolgreich macht und welche Faktoren es zum Scheitern verurteilen.

  • Anzahl der Folgen: 80
  • Letzte Folgen: 2025-08-21
  • Technologie

Wo kannst du zuhören?

Apple Podcasts Logo Spotify Logo Podtail Logo Google Podcasts Logo RSS

Folgen

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

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

2025-08-21

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 werdenOffline-Serving ist der einfachste Fall, während Online-Serving komplexere Anforderungen hatLatenz ist ein kritischer Faktor bei der Nutzung von Edge-DevicesDatenbeschaffung kann über Push- oder Pull-Ansätze erfolgenFeature Engineering muss an die Einschränkungen von Edge-Devices angepasst werdenModelltraining kann sowohl zentral als auch lokal auf Edge-Devices erfolgenCI/CD-Prozesse müssen an die spezifischen Anforderungen von Edge-Devices angepasst werdenMonitoring ist entscheidend, um die Leistung von Modellen auf Edge-Devices zu bewertenDie Qualität der Daten und der Sensoren hat einen direkten Einfluss auf die ModellleistungEin 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

56:04
#78: Der Use-Case-Guide: Navigationshilfe für echten Mehrwert

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

2025-08-07

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 sollteAusgangssituation: Entweder besteht noch keine Idee, oder es gibt bereits eine Idee, deren Umsetzbarkeit geprüft werden sollBeteiligte Rollen: Entscheider*innen, Fachexpert*innen, Anwender*innen sowie Data- & IT-Personal sollten früh eingebunden werdenIdeation-Phase: Kreative Suche nach Problemen mit Hebelwirkung mit Fokus auf Pain Points, Engpässe, repetitive Tätigkeiten und Business ValueNutzer*innenzentrierung: Anforderungen, Nutzungskontext und Entscheidungsprozesse der Anwender*innen bestimmen, was ein Use Case leisten mussTechnische Implikationen: Die Form der Ergebnisausspielung (z. B. Dashboard, API, E-Mail) hängt direkt vom Nutzungskontext abMachbarkeitsprüfung: Datenlage, methodische Passung und technische Umsetzbarkeit werden realistisch bewertetDatenstruktur: "Must-have" vs. "Nice-to-have"-Daten, typische Hürden wie fehlende IDs, Möglichkeiten zur VerknüpfungReifegrad beachten: Nicht zu groß denken, sowohl Überforderung bei geringer Reife als auch Overengineering bei hoher Reife vermeidenDienstleisterfrage: 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

46:09
#77: Uplift Modeling: Der kausale Effekt von Rabatten, Retargeting & Co.

#77: Uplift Modeling: Der kausale Effekt von Rabatten, Retargeting & Co.

2025-07-24

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) vorherzusagenWichtige 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 bauenEs braucht Daten mit Variation im Treatment (z. B. unterschiedliche Gutscheinzeiträume)Kausalität ist essenziell, sonst liefert das Modell verzerrte EffekteA/B-Tests sind nötig, um den tatsächlichen Mehrwert des Modells zu überprüfenBaseline-Modelle und deskriptive Analysen sind wertvolle Vorstufen mit eigenem NutzenHerausforderung: 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

33:51
#76: Digitale Souveränität: Risiken verstehen, souverän handeln

#76: Digitale Souveränität: Risiken verstehen, souverän handeln

2025-07-10

Wer seine gesamte Infrastruktur in US-Clouds betreibt, begibt sich in gefährliche Abhängigkeiten. Im Podcast diskutieren wir, wie real die Risiken internationaler Machtspiele und Datenschutzprobleme sind und was Unternehmen dagegen tun können. Zwischen Know-how-Drain, geopolitischen Spannungen und drohenden Exportstopps braucht es einen klaren Blick auf die eigene IT-Landschaft. Unser Fazit: Resilienz beginnt mit bewusstem Design, nicht mit blindem Aktionismus.**Zusammenfassung**

Digitale Souveränität ist für Unternehmen essenziell, um geopolitische Risiken und Lock-in-Effekte zu minimierenAktuelle Gefahren entstehen durch internationale Konflikte, politisch motivierte Eingriffe in IT-Infrastruktur und den Weggang von Know-howBesonders kritisch: die Abhängigkeit von US-Clouds und SaaS-Lösungen – auch in puncto Datenschutz und ComplianceDie DSGVO-Lage ist trotz "EU-U.S. Data Privacy Framework" instabil und hängt stark von politischen Entwicklungen in den USA abUnternehmen sitzen oft tiefer in der Abhängigkeit, als sie denken – selbst intern ist oft alles von wenigen Cloud-Anbietern abhängigLösungsansätze sind u.a. europäische Cloud-Angebote, Open Source Software und Infrastructure as Code – allerdings mit vielen praktischen GrenzenEin sofortiger Komplettausstieg ist unrealistisch, sinnvoller sind inkrementelle Anpassungen bei neuen ProjektenWichtig: Risiken realistisch bewerten und bewusste Designentscheidungen treffen, statt nur auf Komfort und Geschwindigkeit zu optimieren

**Links**

[Artikel] Strafgerichtshof: Microsofts E-Mail-Sperre als Weckruf für digitale Souveränität https://www.heise.de/news/Strafgerichtshof-Microsofts-E-Mail-Sperre-als-Weckruf-fuer-digitale-Souveraenitaet-10387368.html[Artikel] Tagesschau-Artikel zu US-Exportbeschränkungen für KI-Chips https://www.tagesschau.de/wirtschaft/unternehmen/ki-chips-export-usa-nvidia-biden-100.html[Tool] FreeIPA Projekt (Open Source Identity Management) https://www.freeipa.org/[Tool] Pangolin Projekt (Open Source API Gateway / Identity) https://github.com/fosrl/pangolin[Podcast] #29: Die Qual der Wahl: Data Science Plattform vs. Customized Stack https://inwt.podbean.com/e/29-die-qual-der-wahl-data-science-plattform-vs-customized-stack/

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

38:06
#75: Refactoring done right: Strategien, Risiken und Best Practice

#75: Refactoring done right: Strategien, Risiken und Best Practice

2025-06-26

Refactoring ist ein Begriff, der oft missverstanden wird. Er bedeutet nicht, dass etwas kaputt war, sondern dass man Code strukturell verbessert, ohne sein Verhalten zu verändern. In dieser Folge sprechen wir darüber, warum Refactoring im Alltag oft notwendig ist, wie man es erkennt und richtig angeht. Wir diskutieren, wann es sinnvoll ist, Refactoring gezielt zu planen oder spontan umzusetzen – und warum Tests dabei eine zentrale Rolle spielen. Außerdem werfen wir einen Blick auf die speziellen Herausforderungen im Data-Science-Kontext und wie man Stakeholder überzeugt. Refactoring ist kein Selbstzweck, sondern ein strategischer Hebel für bessere, wartbare Software.

**Zusammenfassung**

Refactoring verbessert die Code-Struktur ohne das Verhalten zu verändern für bessere Wartbarkeit und LesbarkeitTypische Ursachen für unübersichtlichen Code: Zeitdruck, sich ändernde Anforderungen, wenig einheitliche Standards im TeamRefactoring ist kein Zeichen für Fehler, sondern für evolutionäre WeiterentwicklungGelegenheits- vs. geplantes Refactoring: vom schnellen Umbau beim Feature-Entwickeln bis hin zum langfristigen RedesignGute Tests sind essenziell, um unbeabsichtigte Nebeneffekte zu vermeidenRisiken: beschädigte Funktionalität, Zeitaufwand, technische Schulden bei unvollständigem RefactoringRefactoring im Data-Science-Kontext oft besonders notwendig, da Entwicklung häufig in Skripten startetErfolgsfaktor: Refactoring verständlich kommunizieren als Investition in Qualität, nicht als "Schuldenbegleichung"

**Links**

[Buch] Refactoring: Improving the Design of Existing Code. M. Fowler. Addison-Wesley, Boston, MA, USA, (2019).[Blog] Definition Of Refactoring by Martin Fowler https://martinfowler.com/bliki/DefinitionOfRefactoring.html[Blog] Refactoring: Einführung von Antonia Runge https://www.inwt-statistics.de/blog/refactoring-einfuehrung [Podcast] #23: Unsexy aber wichtig: Tests und Monitoring https://www.podbean.com/ew/pb-vxp58-13f311a

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

50:35
#74: [PAIQ1] Predictive AI Quarterly

#74: [PAIQ1] Predictive AI Quarterly

2025-06-12

Predictive AI Quarterly ist unser neues Format im Data Science Deep Dive. Alle 3 Monate sprechen wir über Entwicklungen im Bereich Predictive AI - kompakt, kritisch und praxisnah.Wir starten mit einem Überblick zu den aktuellen News und Trends, danach wird's hands-on: Wir berichten, was wir selbst ausprobiert haben, was gut funktioniert hat und was nicht.

**Zusammenfassung**

TabPFN ist ein Foundation-Modell speziell für tabulare Daten, das Prognose- und Klassifikationsaufgaben ohne Finetuning lösen kannFinetuning-Optionen: Neben dem kostenpflichtigen Angebot von PriorLabs existiert ein Open-Source-Repo zum Finetuning von TabPFN, das aktiv weiterentwickelt wirdmit TabICL gibt es ein weiteres Foundation-Modell für tabulare Daten, das synthetisch trainiert ist, sich auf Klassifikation konzentriert und auch bei großen Datensätzen (bis 500k Zeilen) schnelle Inferenz versprichtFoundation-Modelle für Zeitreihen: Unternehmen wie IBM, Google und Salesforce entwickeln eigene Foundation-Modelle für Time-Series Forecasting (z. B. TTMs, TimesFM, Moirai), diese werden bislang auf echten Zeitreihen trainiertder GIFT-Benchmark dient als Standard zum Vergleich von Zeitreihenmodellen – hier zeigt sich, dass ein angepasstes TabPFN auch für Zeitreihen überraschend leistungsfähig ist

Hands On:

TabPFN lässt sich analog zu scikit-learn einsetzen und ist besonders dann praktisch, wenn eine GPU vorhanden ist, die Einstiegshürde ist sehr niedrigin Zukunft wird mit multimodalen Erweiterungen (z. B. Bilder), quantisierten Varianten und weiteren Alternativen zu TabPFN gerechnet, der Bereich Foundation Models für strukturierte Daten entwickelt sich rasant

**Links**

Podcastfolge #72: TabPFN: Die KI-Revolution für tabulare Daten mit Noah HollmannTabPFN:Finetuning Angebot von Prior LabsGitHub-Repo: Finetune TabPFN v2GitHub-Repo: Zero-Shot Time Series Forecasting mit TabPFNv2TabICL:GitHub-Repo: TabICL – Tabular In-Context LearningWorkshop @ ICML 2025: Foundation Models for Structured Data (18. Juli 2025 in Vancouver)Blogartikel & Studien:Tiny Time Mixers (TTMs) von IBM ResearchMoirai: A Time Series Foundation Model by SalesforceBlogartikel von inwt: "TabPFN: Die KI-Revolution für tabulare Daten"Huggingface Spaces & Modelle:TimesFM Foundation Model für Zeitreihen von Google ResearchGIFT-Eval Forecasting Leaderboard

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

28:06
#73: Korrelation vs. Kausalität: Was braucht es für fundierte Entscheidungen?

#73: Korrelation vs. Kausalität: Was braucht es für fundierte Entscheidungen?

2025-05-29

Korrelation ist nicht gleich Kausalität, und wer fundierte Entscheidungen treffen will, braucht mehr als gute Vorhersagen. In dieser Folge geht es um Confounder, Spurious Correlations und die Frage, wann Machine Learning kausale Einsichten liefern kann. Mit dabei: DoubleML als Brücke zwischen klassischer Statistik und Machine Learning.

**Zusammenfassung**

Unterscheidung zwischen Vorhersage und Intervention: Nur Kausalität beantwortet die "Was-wäre-wenn?"-FragePraxisbeispiele: Bugs & Discounts, Eiskonsum & Kriminalität, Salzgehalt & FlussmengeWichtig: Confounder identifizieren und herausrechnen, z. B. durch ZeitreihenzerlegungEinführung in Double ML: ML-Modelle für Response und Treatment, Effektschätzung über ResiduenHerausforderungen: Overfitting-Bias, Regularisierung, verzerrte Effekte bei hoher KomplexitätAlternativen & Ergänzungen: A/B-Tests, strukturelle Gleichungsmodelle, KausaldiagrammeFazit: Vorsicht bei Spurious Correlations, Ceteris-paribus-Fallen und Feature-Interpretation - Kausalität braucht Kontext und Methode

**Links**

Blogartikel von Scott Lundberg:Be Careful When Interpreting Predictive Models in Search of Causal Insightshttps://medium.com/data-science/be-careful-when-interpreting-predictive-models-in-search-of-causal-insights-e68626e664b6ICECREAM-Datensatz (verfügbar über das tsapp R-Paket):https://search.r-project.org/CRAN/refmans/tsapp/html/ICECREAM.htmlVictor Chernozhukov et al. (2018):Double/debiased machine learning for treatment and structural parameters, The Econometrics Journal, Volume 21, Issue 1https://doi.org/10.1111/ectj.12097Matheus Facure Alves (2022):Causal Inference for The Brave and True (kostenfreies Online-Buch)https://matheusfacure.github.io/python-causality-handbook/landing-page.htmlDoubleML (Python & R):https://docs.doubleml.org/stable/index.htmlEconML (Microsoft Research):https://econml.azurewebsites.net/index.htmlCausal ML (Uber Engineering):https://causalml.readthedocs.io/en/latest/Vortragsfolien von Prof. Dr. Steffen Wagner:"Navigating the Ocean of Correlations to the Islands of Causality – Time Series Analyses at its Best", gehalten bei der Machine Learning Week München 2024https://de.slideshare.net/secret/aArFURFQSBxrzB

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

44:49
#72: TabPFN: Die KI-Revolution für tabulare Daten mit Noah Hollmann

#72: TabPFN: Die KI-Revolution für tabulare Daten mit Noah Hollmann

2025-05-15

Wir sprechen mit Noah Hollman von Prior Labs, einem der Schöpfer von TabPFN (Tabular Prior Fitted Network), über dieses bahnbrechende Foundation-Modell für tabulare Daten. In der Diskussion geht es um die Funktionsweise von TabPFN, die Rolle von In-Context Learning, die Herausforderungen bei der Anwendung der Transformer-Architektur auf tabulare Daten sowie die Generierung synthetischer Daten mit strukturellen kausalen Modellen (SCMs). Darüber hinaus beleuchten wir die beeindruckenden Benchmarking-Ergebnisse und zusätzliche Features des Modells. Zum Ende hin sprechen wir über die offenen Herausforderungen von Prior Labs und welche "Moonshots" sie für die Zukunft planen.

**Zusammenfassung:**

TabPFN ist ein Modell für Vorhersagen auf tabellarischen Daten, entwickelt von Prior LabsEs nutzt In-Context Learning, um Aufgaben durch Sequenzen von Daten zu lernen, und wurde speziell für die Transformer-Architektur angepasstTabPFN wurde mit 100 Millionen synthetischen Datensätzen, die durch strukturelle kausale Modelle (SCMs) generiert wurden, trainiertEs stellt einen neuen Benchmark dar und liefert starke Leistungen über verschiedene Domänen hinwegDas Modell kann Unsicherheiten quantifizieren, mit fehlenden Werten umgehen und Outlier erkennenTabPFN ist auf Consumer-Hardware trainierbar, was die Entwicklung auch auf kleinen GPUs ermöglichtZukünftige Entwicklungen fokussieren sich auf Zeitreihen, Kausalität und multimodale Modelle

**Links:**

Blog: TabPFN: Die KI-Revolution für tabulare Daten https://www.inwt-statistics.de/blog/tabpfn-die-ki-revolution-fuer-tabulare-datenNature Publikation zu tabPFN aus 2025: https://www.nature.com/articles/s41586-024-08328-6Artikel über tabPFN in Fortune: https://fortune.com/2025/02/05/prior-labs-9-million-euro-preseed-funding-tabular-data-ai/Nature News & views von Duncan C. McElfresh: https://www.nature.com/articles/d41586-024-03852-xZeit für Unternehmer: https://www.zeit.de/zeit-fuer-unternehmer/2025/01/kuenstliche-intelligenz-tabpfn-tabellen-daten?freebie=a67d9166Publikation zu tabICL: https://arxiv.org/abs/2502.05564früher Hintergrund-Artikel zur Transformers Architektur für Bayesianische Inferenz : https://arxiv.org/abs/2112.10510früheres Working Paper zu tabPFN: https://arxiv.org/abs/2207.01848GitHub Repo zu tabPFN: https://github.com/PriorLabs/TabPFNHomepage Prior Labs: https://priorlabs.ai/#71: Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek https://www.podbean.com/ew/pb-p2wjd-1897b7eFeedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de
50:40
#71: Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek

#71: Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek

2025-05-01

In dieser Folge geht's um die Frage: Macht Größe von Large Language Models (LLMs) bei Predictive Analytics wirklich einen Unterschied? Wir vergleichen Open-Source-Modelle mit bis zu 70 Milliarden Parametern – und siehe da, das 8B-Modell schlägt das große Schwergewicht. Außerdem berichten wir vom Finetuning auf einer AWS-Maschine mit 8 A100-GPUs und den Herausforderungen in Bezug auf die Reproduzierbarkeit. Auch das viel diskutierte DeepSeek-Modell haben wir im Autopreis-Benchmark antreten lassen. Und wie immer fragen wir uns: Was ist praktisch und was ist overkill?

**Zusammenfassung**

Modellgröße ≠ bessere Prognosen: Das Llama-3.1-8B übertraf das größere 70B-Modell bei der FahrzeugpreisprognoseDeepSeek im Benchmark: Das chinesische Modell zeigt bei größeren Trainingsmengen eine ähnlich gute Performance wie das Llama-3.1-8B, ist bei kleinen Datensätzen aber schwächerFinetuning mit Multi-GPU auf AWS: Für das 70B-Modell war ein Setup mit 8 A100-GPUs nötigReproduzierbarkeit bleibt schwierig: Trotz Seed erzeugen wiederholte Finetuning-Runs unterschiedliche ErgebnisseModellselektion empfohlen: Um zuverlässige Prognosen zu erhalten, sollte aus mehreren Finetuning-Durchläufen das beste Modell ausgewählt werdenCPU-Inferenz möglich, aber langsam: Im Vergleich zur GPU war die Vorhersage auf der CPU ca. 30-mal langsamer, Quantisierung könnte künftig Abhilfe schaffenAusblick auf TabPFN & Quantisierung: Kommende Beiträge widmen sich Erfahrungen mit TabPFN und der praktischen Umsetzung von quantisierten LLMs auf kleineren Maschinen

**Links**

[Begleitender Blogartikel] Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek https://www.inwt-statistics.de/blog/predictive-llms-skalierung-reproduzierbarkeit-und-deepseek#50: Predictive Analytics mit LLMs: ist GPT3.5 besser als XGBoost? https://inwt.podbean.com/e/50-predictive-analytics-mit-llms-ist-gpt35-besser-als-xgboost/#64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen https://inwt.podbean.com/e/64-predictive-llms-ubertreffen-open-source-modelle-jetzt-openai-und-xgboost-bei-preisprognosen/vLLM Framework für schnelle Inferenz: https://github.com/vllm-project/vllm?tab=readme-ov-filetorchtune Finetuning-Framework von PyTorch: https://github.com/pytorch/torchtunePyTorch Reproducibility: https://pytorch.org/docs/stable/notes/randomness.htmlPaper zur Reproduzierbarkeit von QLoRA-Finetuning: S. S. Alahmari, L. O. Hall, P. R. Mouton and D. B. Goldgof, "Repeatability of Fine-Tuning Large Language Models Illustrated Using QLoRA," in IEEE Access, vol. 12, pp. 153221-153231, 2024, doi: 10.1109/ACCESS.2024.3470850 https://ieeexplore.ieee.org/document/10700744heise online: Komprimierte KI: Wie Quantisierung große Sprachmodelle verkleinert von René Peinl https://www.heise.de/hintergrund/Komprimierte-KI-Wie-Quantisierung-grosse-Sprachmodelle-verkleinert-10206033.htmldeepseek-ai/DeepSeek-R1-Distill-Llama-8B auf Huggingface https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Llama-8B#6-how-to-run-locallyTabPFN: Hollmann, N., Müller, S., Purucker, L. et al. Accurate predictions on small data with a tabular foundation model. Nature 637, 319–326 (2025). https://doi.org/10.1038/s41586-024-08328-6 Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de
26:20
#70: Der Aufstieg zur Datenreife – Stufe für Stufe zur Data Maturity

#70: Der Aufstieg zur Datenreife – Stufe für Stufe zur Data Maturity

2025-04-17

Wie datenreif ist dein Unternehmen eigentlich? Wir sprechen über die fünf Stufen der Data Maturity – von manueller Datensammlung bis zur KI als Teil der Unternehmenskultur. Dabei geht es auch um die Rolle der Organisation, warum viele beim „Death by Dashboards“ hängenbleiben und wie man echte Fortschritte macht. Und wir diskutieren, welche Abkürzungen auf diesem Weg funktionieren – und welche eher nach hinten losgehen.

**Zusammenfassung**

Data Maturity Skala: Fünf Stufen von manueller Datennutzung bis zu datengetriebener Kultur mit AI/ML – viele Unternehmen stecken noch in den unteren Bereichen festOrganisationskultur als Schlüssel: Kultur bestimmt maßgeblich, wie datenreif ein Unternehmen wird – HiPPO-Denke (Highest Paid Person's Opinion), Risikoaversion und fehlende Offenheit sind häufige BremsklötzeTypische Hürden: Datensilos, fehlendes Qualitätsbewusstsein, "Death by Dashboards" und Projekte ohne echten ErkenntnisgewinnAufbau von Datenreife: Kombination aus Top-Down-Initiativen und Bottom-up-Leuchtturmprojekten, ergänzt durch agile VorgehensweisePoC → MVP → Produkt: Datenprojekte sollten in kurzen, klar umrissenen Phasen geplant und bei fehlendem Nutzen auch konsequent gestoppt werdenAbkürzungen und Workarounds: Externe Daten, simulierte Daten oder cloudbasierte Infrastruktur können helfen – bergen aber auch Risiken für Aussagekraft und AkzeptanzData Mesh & Self-Service BI: Nur sinnvoll bei entsprechender Datenkultur – sonst droht mehr Chaos als Erkenntnisgewinn

**Links**

Maturity Model mit 5 Stufen von Gartner: Gartner Survey Shows Organizations Are Slow to Advance in Data and Analytics https://www.gartner.com/en/newsroom/press-releases/2018-02-05-gartner-survey-shows-organizations-are-slow-to-advance-in-data-and-analytics#61: Technologische Must-Haves: Unser Survival-Guide für Data-Science-Projekte https://www.podbean.com/ew/pb-k6fx5-175ea51#36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de
46:07
#69: AI Agents verstehen und evaluieren mit Matthäus Deutsch

#69: AI Agents verstehen und evaluieren mit Matthäus Deutsch

2025-04-03

AI Agents sind mehr als nur Chatbots – aber wie bewertet man sie richtig? Wir sprechen über die Herausforderungen beim Testen von AI im Kundenservice, warum falsche API-Parameter ins Chaos führen und wieso "mysteriöser Fleischeintopf" ein PR-Desaster wurde. Matthäus Deutsch von Parloa berichtet, wie flexible Plattformintegrationen und evaluative Ansätze (z.B. assertion-based Testing und Simulationen) den Einsatz von AI Agents vorantreiben. Außerdem: welche Metriken wirklich zählen, was Multi-Agent-Setups leisten und warum der Preisverfall bei Open-Source-Modellen das Game verändert.

Zusammenfassung

AI Agents erweitern klassische Chatbots im Kundenservice, insbesondere im Telefonbereich, durch GenAI-basierte, dynamische LösungenParloa demonstriert flexible Plattformintegrationen und den Einsatz von Evaluationsmethoden wie assertion-based Testing und SimulationenDie Evaluation von AI Agents erfordert spezielles Benchmarking auf Plattform- und individueller EbeneTypische Herausforderungen sind Integrationsprobleme, fehlerhafte API-Calls und unzureichendes Instruction FollowingTests erfolgen sowohl auf Konversationsebene als auch durch deterministische Ansätze und LLMs als JudgeEs müssen komplexe Metriken und Trade-offs beachtet werden, wobei häufig binäre Testansätze aggregiert werdenSchnelle Updates auf neue Modellversionen sind möglich, allerdings steigen langfristig die Kosten durch umfangreiche TestzyklenInnovationen wie optimierte Speech-to-Speech-Technologien und Open-Source-Lösungen (z. B. DeepSeek) bieten Potenzial zur KostenreduktionDer Einsatz von Operatoren-Modellen und Tool-Integrationen ermöglicht auch die Anbindung an Legacy-Systeme, z.B. SAPZiel ist es, den Automatisierungsanteil im Kundenservice zu erhöhen und eine Balance zwischen bewährter Qualität und neuen Features zu finden

Links

Matthäus Deutsch auf LinkedIn: https://www.linkedin.com/in/matth%C3%A4us-d-928864ab/Parloa Contact-Center-AI-Plattform https://www.parloa.com/de/Stellenangebote bei Parloa https://www.parloa.com/company/careers/#jobs#55: Alle machen XGBoost, aber was macht eigentlich XGBoost? Mit Matthäus Deutsch https://www.podbean.com/ew/pb-6gvc6-16d5018#64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen? https://www.podbean.com/ew/pb-m5qr2-17c425dheise online: "Aromatisches" Chloramingas, Eintopf aus Menschenfleisch: KI-Rezepte irritieren https://www.heise.de/news/Aromatisches-Chlorgas-Eintopf-aus-Menschenfleisch-KI-irritiert-mit-Rezepten-9242991.htmlFeedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de
47:22
#68: CI/CD für Daten: Datenversionierung für stabile & nachvollziehbare Systeme

#68: CI/CD für Daten: Datenversionierung für stabile & nachvollziehbare Systeme

2025-03-20

Daten(banken) versionieren – klingt maximal unsexy, spart aber Stress im Deployment. Warum ohne Schema-Versionierung selbst kleine Änderungen große Probleme verursachen und was ORMs, Flyway oder Liquibase damit zu tun haben, erfahrt ihr hier. Daten historisieren ist ein Must-have für Compliance, Reproduzierbarkeit und Modellierung. Aber Achtung: Nicht jede Lösung passt für jede Datenbank und den Live-Betrieb. Wir geben Tipps, wie ihr eure Datenprodukte systematisch und effizient im Griff behaltet.

**Zusammenfassung**

Schema-Versionierung ist essenziell, um Änderungen an Datenbanken nachvollziehbar und reibungslos ins Deployment einzubindenFehlende Versionierung kann zu kaputten Prozessen führen, wenn Schema-Änderungen nicht dokumentiert und automatisiert umgesetzt werdenWerkzeuge wie ORMs, Flyway oder Liquibase helfen dabei, Änderungen an Datenbankschemata strukturiert zu verwaltenHistorisierung von Daten ist für Compliance, Reproduzierbarkeit und Modellierung entscheidend Ansätze zur Datenhistorisierung: Append-only-Strategien vs. System-VersionierungHerausforderungen: Performance-Engpässe, hohe Pflegekosten und Kompatibilitätsprobleme je nach Datenbank und Migrationstool Best Practices: Versionierung systematisch einführen, Automatisierung priorisieren und sicherstellen, dass Downgrades funktionieren.

**Links**

#58: Arm, aber sexy: Data Warehousing at Scale ohne Budget https://www.podbean.com/ew/pb-gywt4-1719aef#52: In-process Datenbanken und das Ende von Big Data https://www.podbean.com/ew/pb-tekgi-16896e4#36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1Flyway: https://www.red-gate.com/products/flyway/Liquibase: https://www.liquibase.com/Alembic (für SQLAlchemy): https://alembic.sqlalchemy.org/en/latest/MariaDB: https://mariadb.org/ClickHouse: https://clickhouse.com/Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de
41:29
#67: "It works on my machine" war gestern – Docker Best Practices für Data Science

#67: "It works on my machine" war gestern – Docker Best Practices für Data Science

2025-03-06

Dieser Satz "it works on my machine" hat IT-Teams und Data Scientists lange Nerven gekostet. Früher war Deployment ein mühsames Zusammenspiel aus Setup-Anleitungen, inkompatiblen Umgebungen und endlosen Rückfragen. Docker bringt endlich Ordnung ins Chaos: Anwendungen laufen isoliert, reproduzierbar und unabhängig vom Host-System. Warum Containerisierung für Data Science ein echter Gamechanger ist und welche Best Practices du kennen solltest, erfährst du in dieser Folge!

Zusammenfassung

Früher war Deployment umständlich: lange Setup-Anleitungen, inkompatible Umgebungen, viele Rückfragen Virtuelle Maschinen haben das Problem teilweise gelöst, sind aber ressourcenintensiv und unflexibelData Scientists arbeiten oft mit R/Python, was IT-Abteilungen vor Herausforderungen stelltFehlende Reproduzierbarkeit führt zu Stress, Verzögerungen und hohem KommunikationsaufwandDocker schafft eine standardisierte, isolierte und reproduzierbare Umgebung für AnwendungenContainer laufen direkt auf dem Host-OS, sind schlanker als VMs und starten schnellerMit Dockerfiles lassen sich Umgebungen als Code definieren und automatisch deployenBest Practices: schlanke Base-Images, .dockerignore, nur benötigte Abhängigkeiten installierenAutomatisierung mit CI/CD-Pipelines beschleunigt den Entwicklungs- und Deploy-ProzessContainerisierung ist für moderne Data-Science-Workflows unverzichtbar und spart IT sowie Data Science viel Zeit

Links

Offizielle Docker Dokumentation https://docs.docker.com/Docker Hub https://hub.docker.com/[Blog] Die Welt der Container: Einführung in Docker https://www.inwt-statistics.de/blog/die-welt-der-container-einfuehrung-in-docker[Podcast] #14: Kubernetes https://www.podbean.com/ew/pb-m5ggz-13454c7[Podcast] #59: Besser mit Helm: komplexe Deployments einfach(er) umsetzen https://www.podbean.com/ew/pb-txhnf-17314de[Video] Solomon Hykes stellt Docker vor (2013) "The future of Linux Containers" https://www.youtube.com/watch?v=wW9CAH9nSLs&t=158sFragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de
34:53
#66: Developer vs. Data Scientist mit Andy Grunwald und Wolfgang Gassler

#66: Developer vs. Data Scientist mit Andy Grunwald und Wolfgang Gassler

2025-02-20

Warum knirscht es immer wieder zwischen Data Scientists und Developern? In dieser Episode holen wir uns Verstärkung von Andy und Wolfi vom Engineering Kiosk Podcast um dieser Frage auf den Grund zu gehen. Wir reden über typische Klischees und warum diese zu Konflikten führen. Gemeinsam sprechen wir darüber, welche Skills helfen, damit beide Spezies am Ende harmonisch zusammenarbeiten können – statt sich gegenseitig auszubremsen.

Zusammenfassung

Klischees und Konflikte: Stereotype über Data Scientists (Jupyter-Fans, Doktortitel) und Developer (Perfektionismus, Black-Box-Furcht)Teamorganisation: Cross-funktionale Teams vs. getrennte Abteilungen (Vor- und Nachteile, Agenturmodell)Typische Herausforderungen: Übergabe von Prototypen an die Entwicklung, Verständnis von SLAs/Responsezeiten, DatenbankauswahlSkill-Set und Zusammenarbeit: Generalistisches Grundwissen in DevOps und Softwarearchitektur, offenes Mindset

Links

Engineering Kiosk Podcast: https://engineeringkiosk.dev/Andy Grunwald auf LinkedIn: https://www.linkedin.com/in/andy-grunwald-09aa265a/Wolfgang Gassler auf LinkedIn: https://www.linkedin.com/in/wolfganggassler/[Engineering Kiosk] #179 MLOps: Machine Learning in die Produktion bringen mit Michelle Golchert und Sebastian Warnholz https://engineeringkiosk.dev/podcast/episode/179-mlops-machine-learning-in-die-produktion-bringen-mit-michelle-golchert-und-sebastian-warnholz/[Engineering Kiosk] #178 Code der bewegt: Infotainmentsysteme auf Kreuzfahrtschiffen mit Sebastian Hammerl https://engineeringkiosk.dev/podcast/episode/178-code-der-bewegt-infotainmentsysteme-auf-kreuzfahrtschiffen-mit-sebastian-hammerl/[Engineering Kiosk] #177 Stream Processing & Kafka: Die Basis moderner Datenpipelines mit Stefan Sprenger https://engineeringkiosk.dev/podcast/episode/177-stream-processing-kafka-die-basis-moderner-datenpipelines-mit-stefan-sprenger/[Data Science Deep Dive] #30: Agile Softwareentwicklung im Data-Science-Kontext https://www.podbean.com/ew/pb-mvspn-1482ea4[Data Science Deep Dive] #23: Unsexy aber wichtig: Tests und Monitoring https://www.podbean.com/ew/pb-vxp58-13f311a[Data Science Deep Dive] #20: Ist Continuous Integration (CI) ein Muss für Data Scientists? https://www.podbean.com/ew/pb-4mkqh-13bb3b3Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de
01:03:42
#65: Sicher ist nur die Unsicherheit: Unsicherheitsintervalle erklärt

#65: Sicher ist nur die Unsicherheit: Unsicherheitsintervalle erklärt

2025-02-06

Punktprognosen sind was für Leute, die gerne enttäuscht werden ;) Wir befassen uns in dieser Episode mit der Quantifizierung und Kommunikation von Unsicherheit bei Prognosen. Dabei gehen Mira und Amit auf klassische Statistik, Bayes-Methoden, Machine Learning, Bootstrapping und Conformal Predictions ein. Außerdem gehen sie auf Herausforderungen der Data Literacy und bei rechenintensiven Ansätzen zur Bestimmung der Unsicherheit ein.

Zusammenfassung

Warum Unsicherheiten unverzichtbar sind (Beispiel Wetter-, Wahl-, Bewerberprognosen)Klassische Statistik: Konfidenzintervall vs. Prediction IntervallBayesianische Sicht: GlaubwürdigkeitsintervalleML-Methoden ohne Verteilungsannahmen: Bootstrapping & Conformal PredictionsRechenaufwand vs. ModellannahmenData Literacy als Schlüssel zum richtigen Interpretieren von PrognoseintervallenPraxisnahe Beispiele und Entscheidungshilfen

Links

#10: Signifikanz https://www.podbean.com/ew/pb-y25ti-12fab65#44: Lineare Regression in der Praxis – Oldie oder Goldie? https://www.podbean.com/ew/pb-jiecf-15d0ac1#56: Unsere Bundestagswahl-Prognose: Wer gewinnt die Wahl 2025? https://www.podbean.com/ew/pb-hwgnd-16e446eWer gewinnt die Bundestagswahl 2025? www.wer-gewinnt-die-wahl.deMolnar (2023): Introduction To Conformal Prediction With Python. A Short Guide For Quantifying Uncertainty Of Machine Learning Models.Sammlung von Ressourcen zu Conformal Predictions https://github.com/valeman/awesome-conformal-prediction/Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de
28:50
#64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen?

#64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen?

2025-01-23

Teil 2 unseres Preisprognose-Experiments für Gebrauchtfahrzeuge: Können Open-Source-LLMs wie Llama 3.1, Mistral und Leo-HessianAI mit GPT-3.5 mithalten? Wir haben fleißig gefinetuned, bis die Motoren qualmten – und es zeigt sich, dass die Unterschiede gar nicht mehr so groß sind. Mit ausreichend vielen Trainingsbeobachtungen nähern sich die Open-Source-Modelle den Ergebnissen von GPT-3.5 an und können es in einzelnen Metriken sogar übertreffen. Für das Finetuning größerer Modelle sind jedoch auch leistungsfähige GPUs notwendig, was die Ressourcenanforderungen deutlich erhöht. In der Folge beleuchten wir, welchen Mehrwert diese Open-Source-LLMs für praxisnahe Use Cases liefern und welche Herausforderungen dabei auftreten.

Zusammenfassung:

Vergleich von OpenAI GPT-3.5 und drei Open-Source-LLMs (Llama 3.1, Mistral 7B, Leo-HessianAI)Finetuning der Modelle auf lokalen DatenErgebnisse: Open-Source-LLMs sind bei größerem Trainingsdatensatz fast so gut wie GPT-3.5XGBoost hinkt etwas hinterher, da Freitexte hier nicht einbezogen wurdenWichtige Faktoren: Batchgröße, Trainingsschritte, Speicherbedarf und Nutzung von Lora-FinetuningBeim Einsatz von Open Source ist mehr Handarbeit nötig, dafür bleibt alles on-premiseOpenAI punktet durch Einfachheit und hohe Qualität ohne großen DatenbedarfFrameworks wie Huggingface, Mistral Codebase und Torchtune unterstützen das FinetuningAusblick: größere LLMs mit Multi-GPU, multimodale Daten und Unsicherheitsquantifizierung

***Links***

[Blog] Predictive LLMs: Übertreffen Open-Source-Modelle OpenAI bei Preisprognosen? https://www.inwt-statistics.de/blog/predictive-llms-uebertreffen-os-modelle-openai-bei-preisprognosen[Podcast] #50: Predictive Analytics mit LLMs: ist GPT3.5 besser als XGBoost? https://www.podbean.com/ew/pb-n6wem-165cb2c[Blog] Predictive LLMs: Kann GPT-3.5 die Prognosen von XGBoost verbessern? https://www.inwt-statistics.de/blog/predictive-llms-kann-gpt-xgboost-prognosen-verbessern[Podcast] #43: Damit es im Live-Betrieb nicht kracht: Vermeidung von Overfitting & Data Leakage https://www.podbean.com/ew/pb-vw736-15baac0[Link] Llama-3.1-8B-Instruct auf Huggingface https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct- [Link] Mistral-7B-Instruct-v0.3 auf Huggingface https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.3[Link] Mistral 7B Release Notes https://mistral.ai/news/announcing-mistral-7b/[Link] leo-hessianai-7b auf Huggingface https://huggingface.co/LeoLM/leo-hessianai-7b[Link] The Hessian Center for Artificial Intelligence https://hessian.ai/de/[Docs] LangChain: How to return structured data from a model https://python.langchain.com/docs/how_to/structured_output/#the-with_structured_output-method[Link] Wie hoch sind die Treibhausgasemissionen pro Person in Deutschland durchschnittlich? https://www.umweltbundesamt.de/service/uba-fragen/wie-hoch-sind-die-treibhausgasemissionen-pro-person#:~:text=Der%20deutsche%20Aussto%C3%9F%20an%20Treibhausgasen,sehr%20gro%C3%9Fe%20Unterschiede%20im%20Konsumniveau.
40:31
#63: Data Mining: der pragmatische Weg zu Datenreife & Datenkultur mit Prof. Dr. Ana Moya

#63: Data Mining: der pragmatische Weg zu Datenreife & Datenkultur mit Prof. Dr. Ana Moya

2025-01-09

„Data Mining“ – klingt nach Staub und Schaufeln, ist aber der Schlüssel zur Mustererkennung in Daten! Wir diskutieren, warum einfache Methoden oft besser sind als fancy KI-Lösungen, besonders bei niedriger Datenreife. Außerdem: Wie man nachhaltigen Mehrwert schafft, ohne sich in Dashboards zu verlieren, und welche Skills und Tools wirklich zählen. Hilfreich für alle, die effektiv mit Daten arbeiten wollen.

Zusammenfassung

Data Mining: Definition und Bedeutung als pragmatischer Ansatz zur MustererkennungHerausforderungen: Niedrige Datenreife und der Druck, „fancy“ Methoden einzusetzenLösungsansätze: Bewährte Methoden wie Statistik, Visualisierungen und Anomaly DetectionNachhaltigkeit: Optimierte Prozesse und ressourcenschonende Lösungen als KernnutzenSkills und Tools: Analytisches Denken, Statistik, Programmierkenntnisse, sowie Tools aus dem Bereich Business Intelligence und Programmiersprachen wie R & PythonFehler vermeiden: Datenqualität, Vermeidung von Confirmation Bias und sinnvolle Nutzung von Dashboards

***Links***

Prof. Dr. Ana Moya auf LinkedIn: https://www.linkedin.com/in/doc-moya/International School of Management (ISM) https://en.ism.de/INFOMOTION GmbH https://www.infomotion.de/Power BI https://www.microsoft.com/de-de/power-platform/products/power-bi?market=deTableau https://www.tableau.com/Python https://www.python.org/R https://www.r-project.org/Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de
42:39
#62: Kafka und Datenströme erklärt – und wie das jetzt auch in R läuft

#62: Kafka und Datenströme erklärt – und wie das jetzt auch in R läuft

2024-12-19

Kafka, aber in R? Das geht jetzt! In dieser Folge klären wir, warum Kafka für schnelle Datenströme unverzichtbar ist und warum unser neuer R-Kafka-Client ein Gamechanger ist. Was ist Kafka, wofür braucht man es (oder auch nicht), und wie funktioniert unser Paket? Hört rein und probiert es aus!

Zusammenfassung

Apache Kafka als schnelles, ausfallsicheres System für Event-Streaming und DatenströmeEinsatzbereiche: Überall wo Daten fortlaufend und in Echtzeit verarbeitet werdenUnser R Kafka Client ermöglicht nun die direkte Nutzung von Kafka in R, ohne Umweg über PythonFeatures: Consumer/Producer-Modelle, asynchrone Datenverarbeitung, hohe Performance und AusfallsicherheitAusblick: Veröffentlichung auf CRAN, Admin-Client für Cluster-Management, Blogartikel mit Beispiel (siehe unten in den Links)

Links

Apache Kafka https://kafka.apache.org/Confluent https://www.confluent.io/Rcpp (CRAN) https://cran.r-project.org/web/packages/Rcpp/index.htmlreticulate (CRAN) https://cran.r-project.org/web/packages/reticulate/index.htmlR Paket kafka auf GitHub https://github.com/INWTlab/r-kafka Blogartikel zum R Paket kafka https://www.inwt-statistics.de/blog/r-paket-kafkanats https://nats.io/Azure EventHub https://azure.microsoft.com/de-de/products/event-hubsRedpanda https://www.redpanda.com/Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de
21:02
#61: Technologische Must-Haves: Unser Survival-Guide für Data-Science-Projekte

#61: Technologische Must-Haves: Unser Survival-Guide für Data-Science-Projekte

2024-12-05

Zusammenfassend unsere Must-Haves:

Datenbank / DWH Lösung zur DatenvisualisierungMöglichkeit, unkompliziert zu entwickeln (lokal oder im Web)Versionskontrolle / CI/CDDeployment-LösungTrennung von Entwicklungs- und ProduktivumgebungMonitoring für Modell & Ressourcen

Verwandte Podcast-Episoden

Folge #2: Erfolgsfaktoren für Predictive Analytics Projekte

Folge #5: Data Warehouse vs. Data Lake vs. Data Mesh

Folge #20: Ist Continuous Integration (CI) ein Muss für Data Scientists?

Folge #21: Machine Learning Operations (MLOps)

Folge #29: Die Qual der Wahl: Data Science Plattform vs. Customized Stack

Folge #35: Erfolgsfaktoren für Machine Learning Projekte mit Philipp Jackmuth von dida

Folge #43: Damit es im Live-Betrieb nicht kracht: Vermeidung von Overfitting & Data Leakage

Folge #54: Modell-Deployment: Wie bringe ich mein Modell in die Produktion?

Technologien & Tools

Datenvisualisierung: Azure Databricks, AWS Quicksight, Redash

Entwicklungsumgebung: VSCode, INWT Python IDE V2, Remote Explorer, Pycharm

Versionskontrolle: GitHub, GitLab, Azure DevOps

CI/CD: GitHub Actions, GitLab CI, Jenkins

Deployment: Kubernetes, Docker, Helm, ArgoCD

Experiment-Tracking: MLFlow, DVC, Tensorboard

Monitoring: Prometheus, Grafana, AWS Cloudwatch

42:04
#60: Job-Sicherheit als Data Scientist: Personalentwicklung in Zeiten von AI

#60: Job-Sicherheit als Data Scientist: Personalentwicklung in Zeiten von AI

2024-11-21

Die glorreichen Zeiten des Data Scientist scheinen vorbei zu sein – oder doch nicht? Warum stagnieren die Jobangebote? Und wie passt GenAI ins Bild? Wir sprechen über die neuen Herausforderungen am Arbeitsmarkt, was Unternehmen und Jobsuchende jetzt tun sollten, und warum Data Engineers irgendwie sexy, aber nie so richtig hot waren. Spoiler: Flexibilität und Generalismus sehen wir als wichtige Eigenschaften für die Zukunft!

***Links***

#4: Job-Profile & Arbeitsmarkt https://www.podbean.com/ew/pb-aurkr-126887d https://de.wikipedia.org/wiki/Hype-ZyklusFragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de
41:44