MLOps und ML-Pipelines: Von der Entwicklung zur Produktion

• Tag 1: Experiment Tracking, Reproduzierbarkeit und Feature Engineering
• 1. Das MLOps-Problem: Warum Notebooks nicht reichen
  • Der ML-Lifecycle: Daten sammeln -> Feature Engineering -> Modell trainieren -> Evaluieren -> Deployen -> Monitoren -> Retraining. In der Praxis: die ersten 3 Schritte passieren, der Rest nicht.
  • MLOps-Reifegrade: Stufe 0 (manuell: Notebook, Copy-Paste, E-Mail an IT), Stufe 1 (Pipeline: automatisiertes Training, manuelles Deployment), Stufe 2 (CI/CD für ML: automatisiertes Training + Deployment + Monitoring), Stufe 3 (vollautomatisch: Drift erkannt -> Retraining -> Deployment ohne menschlichen Eingriff).
  • MLOps vs. DevOps: Was ist gleich (CI/CD, Versionierung, Monitoring, Automatisierung)? Was ist anders (Daten als zusätzliche Dimension, Experiment Tracking, Feature Stores, Data/Model Drift)?
  • Praxis-Übung: Demo-ML-Projekt (Churn Prediction) als Jupyter Notebook - alles manuell, nichts reproduzierbar. Die Probleme identifizieren: welche Datenversion? Welche Hyperparameter? Welche Python-Version? Funktioniert das Notebook auf einem anderen Rechner?

• 2. Experiment Tracking: MLflow und Weights & Biases
  • Warum Experiment Tracking? Hunderte Trainingsläufe mit verschiedenen Hyperparametern, Features und Datenversionen - ohne Tracking ist nach einer Woche unklar, welcher Lauf das beste Ergebnis lieferte und warum.
  • MLflow Tracking: Experiments, Runs, Parameter, Metriken, Artefakte loggen. MLflow UI: Läufe vergleichen, beste Konfiguration finden, Modelle als Artefakte speichern.
  • MLflow Model Registry: Modelle versionieren (v1, v2, v3), Stages zuweisen (Staging -> Production -> Archived), Transitions mit Genehmigung.
  • Weights & Biases als Alternative: Reichere Visualisierung, Team-Collaboration, Hyperparameter-Sweeps, System-Metriken (GPU-Auslastung). Cloud-basiert vs. Self-Hosted.
  • Reproduzierbarkeit sicherstellen: Datenversion + Code-Version + Umgebung (Python, Pakete) + Hyperparameter + Zufalls-Seed = reproduzierbares Experiment. MLflow + Git + Docker/Conda als Kombination.
  • Praxis-Übung: MLflow in das Churn-Prediction-Projekt integrieren: 5 Trainingsläufe mit verschiedenen Hyperparametern loggen, in der MLflow UI vergleichen, bestes Modell im Model Registry registrieren und auf Staging" setzen.

• 3. Daten-Management und Feature Engineering für Produktion
  • Daten-Versionierung: DVC (Data Version Control - Git für Daten), LakeFS (Git-artige Branches für Data Lakes). Warum Daten versioniert werden müssen: Modell v3 wurde auf Datenstand Januar trainiert, Modell v4 auf Februar - ohne Daten-Versionierung ist der Unterschied nicht nachvollziehbar.
  • Feature Stores: Zentrale Speicherung von Features, die von mehreren Modellen und Teams genutzt werden. Feast (Open Source), Hopsworks, Tecton. Zwei Perspektiven: Offline Feature Store (für Training - historische Daten) und Online Feature Store (für Inference - aktuelle Werte mit niedriger Latenz).
  • Feature Engineering für Produktion: Training-Serving Skew (Features werden im Training anders berechnet als in der Inference - der häufigste und gefährlichste MLOps-Bug). Lösung: Feature-Transformationen einmal definieren, für Training und Serving identisch ausführen.
  • Praxis-Übung: DVC für das Churn-Projekt einrichten: Trainingsdaten versionieren, Datenänderung simulieren (neue Monatsdaten), neuen Trainingsstand als DVC-Version taggen. Feature Store mit Feast: 5 Features definieren, für Offline-Training und Online-Inference bereitstellen.

• Tag 2: Pipelines, CI/CD und Model Serving
• 4. ML-Pipelines: Training automatisieren
  • Warum Pipelines? Manuelles Training (Notebook öffnen, Zellen ausführen, Ergebnis prüfen) skaliert nicht. Pipelines automatisieren den gesamten Ablauf: Daten laden -> Preprocessing -> Feature Engineering -> Training -> Evaluation -> Modell registrieren.
  • Pipeline-Frameworks: Kubeflow Pipelines (Kubernetes-nativ, DAG-basiert), MLflow Projects + Recipes (leichtgewichtiger, kein K8s nötig), Airflow + ML (allgemeiner Workflow-Orchestrator mit ML-Tasks), Metaflow (Netflix, Python-nativ), ZenML (MLOps-Framework, orchestrator-agnostisch).
  • Pipeline-Design: Steps als wiederverwendbare Komponenten (Data Loader, Preprocessor, Trainer, Evaluator), Parameter-Passing zwischen Steps, Caching (unveränderte Steps nicht erneut ausführen), Trigger (manuell, zeitgesteuert, event-basiert).
  • CI/CD für ML: Code-Änderung -> automatisch: Linting + Unit Tests + Integration Tests + Training auf Testdaten + Modell-Evaluation -> wenn besser als aktuelles Produktionsmodell -> Deployment. GitHub Actions oder GitLab CI als Pipeline-Runner.
  • Praxis-Übung: ML-Pipeline für das Churn-Projekt bauen: 4 Steps (Data Load, Preprocess, Train, Evaluate), MLflow-Integration (jeder Run wird geloggt), Pipeline per Kommando ausführen. Dann: GitHub-Actions-Workflow, der bei Push auf main die Pipeline triggert.

• 5. Model Serving: Modelle als API bereitstellen
  • Serving-Optionen: Batch Inference (Vorhersagen für alle Kunden einmal pro Nacht - einfach, aber nicht echtzeitfähig), Online Inference (Vorhersage per API-Call in Millisekunden - für Echtzeit-Anwendungen), Streaming Inference (Vorhersage auf Event-Streams - für Kafka/Flink-Szenarien).
  • Serving-Frameworks: FastAPI + uvicorn (einfachster Start: Modell laden, API-Endpoint definieren, fertig), BentoML (Modell-Packaging, API-Generierung, Containerisierung in einem Tool), Seldon Core (Kubernetes-nativ, Canary Deployments, A/B-Testing), KServe (Kubernetes, Serverless Inference, Multi-Framework), MLflow Serving (MLflow-Modelle direkt als REST API).
  • Containerisierung: Modell + Dependencies in Docker-Container -> überall deploybar (lokal, Cloud, Kubernetes). Reproducibility: exakt dieselbe Umgebung in Entwicklung und Produktion.
  • Skalierung: Horizontal (mehr Replicas bei mehr Last), GPU-Inference (für große Modelle), Batching (mehrere Anfragen bündeln -> GPU-Effizienz), Auto-Scaling (Kubernetes HPA oder Cloud-native Skalierung).
  • Praxis-Übung: Churn-Modell als API bereitstellen: (1) FastAPI-Endpoint (10 Zeilen Code -> Modell läuft als API). (2) BentoML-Packaging (Modell + Dependencies -> Container -> deployen). (3) Testanfragen senden und Latenz messen. Load-Test: 100 gleichzeitige Anfragen -> skaliert die API?

• 6. Deployment-Strategien und A/B-Testing
  • Deployment-Strategien: Shadow Deployment (neues Modell läuft parallel, bekommt echten Traffic, aber Ergebnisse werden nur geloggt - kein Impact auf Nutzer), Canary Deployment (10 % des Traffics an neues Modell, 90 % an altes -> Performance vergleichen -> bei Erfolg schrittweise erhöhen), Blue-Green (zwei identische Umgebungen, Traffic wird umgeschaltet - sofortiger Rollback möglich), A/B-Testing (zwei Modelle mit verschiedenen Features oder Algorithmen -> statistisch messen, welches besser performt).
  • Rollback: Wenn das neue Modell schlechter ist -> sofort auf die vorherige Version zurückrollen. Model Registry (MLflow, SageMaker) macht das trivial: Production-Stage auf vorherige Version setzen.
  • Praxis-Übung: Canary Deployment simulieren: Modell v1 (altes) und Modell v2 (neues) parallel deployen, Traffic-Split konfigurieren (90/10), Metriken vergleichen, v2 auf 100 % hochfahren oder zurückrollen.

• Tag 3: Monitoring, Retraining und Praxis-Workshop
• 7. Model Monitoring: Drift erkennen bevor es zu spät ist
  • Warum Monitoring? Ein ML-Modell, das heute 95 % Accuracy hat, kann in 3 Monaten nur noch 75 % liefern - ohne dass sich am Modell etwas geändert hat. Der Grund: die Welt hat sich geändert (Kundenverhalten, Marktbedingungen, Saisonalität, Pandemie, neue Produkte).
  • Data Drift: Die Verteilung der Eingabedaten ändert sich (Features haben plötzlich andere Werte als im Training). Erkennung: statistische Tests (Kolmogorov-Smirnov, Population Stability Index), Visualisierung (Feature-Verteilung Training vs. aktuell).
  • Concept Drift: Die Beziehung zwischen Features und Target ändert sich (was früher Churn-Indikatoren waren, ist es heute nicht mehr). Schwerer zu erkennen, erfordert Ground-Truth-Feedback.
  • Performance Monitoring: Wenn Ground Truth verfügbar (z.B. hat der Kunde tatsächlich gekündigt?") -> Accuracy, Precision, Recall live messen. Wenn nicht verfügbar -> Proxy-Metriken (Prediction Confidence, Feature Drift als Frühwarnung).
  • Monitoring-Tools: Evidently AI (Open Source, Drift-Reports und Dashboards), NannyML (CBPE - Confidence-Based Performance Estimation ohne Ground Truth), Whylogs (Lightweight Feature Logging), Grafana + Prometheus (Custom Metriken).
  • Praxis-Übung: Evidently AI für das Churn-Modell einrichten: Drift-Report generieren (Training vs. aktuelle Daten), Data-Drift-Dashboard aufsetzen, Schwellenwert für Alert konfigurieren (PSI > 0.2 -> E-Mail-Benachrichtigung). Drift simulieren: Feature-Verteilung absichtlich ändern -> Alert auslösen.

• 8. Retraining und Continuous Training
  • Retraining-Trigger: Zeitbasiert (jeden Monat neu trainieren - einfach, aber verschwendet Ressourcen wenn kein Drift), Drift-basiert (nur neu trainieren wenn Drift erkannt wird - effizienter), Performance-basiert (nur neu trainieren wenn Accuracy unter Schwellenwert fällt - ideal, aber erfordert Ground Truth).
  • Continuous Training Pipeline: Drift erkannt -> neue Daten laden -> Feature Engineering -> Training -> Evaluation -> wenn besser als Produktion -> Deployment (automatisch oder nach Approval) -> altes Modell archivieren. Die vollautomatische ML-Pipeline.
  • Datenqualitäts-Checks: Bevor ein Retraining startet: sind die neuen Daten vollständig? Gibt es Ausreißer? Fehlen Features? Great Expectations oder Pandera für automatisierte Datenvalidierung.
  • Praxis-Übung: Retraining-Pipeline aufbauen: Drift-Alert -> Datenqualitätsprüfung -> Retraining -> Evaluation -> wenn besser als aktuelles Modell -> automatisches Deployment -> Notification. End-to-End durchspielen: Drift simulieren -> Pipeline läuft automatisch -> neues Modell in Produktion.

• 9. MLOps-Architektur und Praxis-Workshop
• MLOps-Architektur-Patterns (20 Min):
  • Einfach starten: Git + MLflow + FastAPI + Evidently - kein Kubernetes nötig, läuft auf einem Server. Für kleine Teams (1-3 Data Scientists).
  • Skalieren: Kubernetes + Kubeflow/ZenML + Seldon/KServe + Feast + Evidently - für mittlere/große Teams (5+ Data Scientists, mehrere Modelle in Produktion).
  • Cloud-Managed: SageMaker Pipelines (AWS), Vertex AI Pipelines (GCP), Azure ML Pipelines - weniger Eigenverantwortung, mehr Vendor-Lock-in.
  • Build vs. Buy: Wann eigene Infrastruktur, wann Managed Services? Entscheidungskriterien: Team-Größe, Modell-Anzahl, Compliance, Budget, Cloud-Strategie.

• Praxis-Workshop (60 Min):
  • Phase 1 - Eigene MLOps-Architektur entwerfen (35 Min): Für das eigene ML-Projekt (oder vorgegebenes Szenario): ML-Lifecycle dokumentieren (welche Schritte, welche Tools), Toolauswahl treffen (Experiment Tracking, Pipeline, Serving, Monitoring), Deployment-Strategie wählen (Shadow/Canary/Blue-Green), Monitoring-Plan (welche Metriken, welche Schwellenwerte, welche Alerts), Retraining-Strategie (zeitbasiert/drift-basiert/performance-basiert).
  • Phase 2 - Peer-Review (15 Min): Architektur vorstellen. Stresstest: Euer Modell liefert plötzlich 30 % schlechtere Ergebnisse - wann bemerkt ihr das und was passiert automatisch?" Eine Data Scientistin verlässt das Team - kann ihr Nachfolger das letzte Experiment reproduzieren?" Das Training dauert 4 Stunden - was passiert wenn es mitten in der Nacht fehlschlägt?" Zwei Data Scientists trainieren gleichzeitig dasselbe Modell mit verschiedenen Features - wie verhindert ihr Konflikte?"

LernzieleJede teilnehmende Person verlässt das Seminar mit dem Verständnis des vollständigen ML-Lifecycle (Experiment -> Training -> Deployment -> Monitoring -> Retraining), der Fähigkeit, Experiment Tracking mit MLflow produktiv einzusetzen (Runs, Model Registry, Reproduzierbarkeit), der Kompetenz, ML-Pipelines zu bauen (automatisiertes Training, CI/CD für ML), dem Wissen über Model Serving (FastAPI, BentoML, Deployment-Strategien), der Fähigkeit, Model Drift zu erkennen und darauf zu reagieren (Evidently AI, Retraining-Trigger), einer funktionierenden End-to-End-MLOps-Pipeline (vom Experiment bis zum automatischen Retraining) und einer MLOps-Architektur für das eigene Projekt.Zielgruppen

• Data Scientists: Die Modelle in Jupyter Notebooks entwickeln, aber nicht wissen, wie sie diese reproduzierbar, versioniert und automatisiert in Produktion bringen.
• ML Engineers und Platform Engineers: Die ML-Infrastruktur für Data-Science-Teams aufbauen und betreiben.
• DevOps Engineers: Die CI/CD beherrschen, aber ML-spezifische Anforderungen (Daten-Versionierung, Experiment Tracking, Model Registry, Drift Monitoring) noch nicht kennen.
• Data-Science-Teamleiter: Die einen strukturierten MLOps-Prozess etablieren - statt Ad-hoc-Deployments per E-Mail.

Voraussetzungen: Machine-Learning-Grundkenntnisse (was ist Training, was ist Inference, was ist ein Modell). Python-Kenntnisse. Idealerweise Besuch eines ML-Grundkurses oder vergleichbare Praxiserfahrung. Keine MLOps-Vorkenntnisse nötig.