ML Pipelines: Definition, Bausteine, MLOps-Abgrenzung

Eine ML Pipeline (Machine-Learning-Pipeline) ist eine Kette aus automatisierten Arbeitsschritten, die ein Vorhersage-Modell aus Rohdaten baut, prüft und produktiv verfügbar macht. Sie verbindet die typischen Bausteine zu einem wiederholbaren Prozess: Daten laden, Merkmale berechnen (die Eingabegrössen für das Modell), Modell trainieren, Qualität prüfen, Modell freigeben und an eine Anwendung ausliefern.

Was ist eine ML Pipeline?

Eine ML Pipeline ist die technische Umsetzung dieses Modell-Lebenszyklus als Ablauf aus einzelnen Schritten (in der Fachsprache Steps oder Components), bei dem das Ergebnis eines Schritts direkt in den nächsten fliesst. Der Begriff kommt ursprünglich aus der Python-Bibliothek scikit-learn, in der eine Pipeline-Klasse mehrere Datenvorbereitungs-Schritte und einen Lern-Algorithmus in einem einzigen Objekt bündelt. Mit Werkzeugen wie TFX (TensorFlow Extended), Kubeflow Pipelines, MLflow Recipes, Metaflow, Vertex AI Pipelines und Databricks Workflows für ML hat sich der Begriff in den vergangenen zehn Jahren auf grosse, verteilte Trainings- und Auslieferungs-Prozesse ausgeweitet.

Die typischen Schritte einer produktiven ML Pipeline sind Data Ingestion aus einer oder mehreren Quellen, Data Validation gegen ein Schema, Feature Engineering mit Persistenz in einem Feature Store, Trainings-Split, Training mit optionaler Hyperparameter-Suche, Evaluation gegen Test-Daten, Registrierung des Modells in einer Model Registry und Deployment als Batch- oder Realtime-Endpoint. Monitoring auf Datendrift und Modell-Degradation schließt den Kreis und triggert bei Bedarf einen Retraining-Lauf.

ML Pipelines existieren in mehreren Ausführungs-Varianten. Die Trainings-Pipeline läuft offline, meist periodisch oder auf Abruf, und produziert ein neues Modell-Artefakt. Die Inference-Pipeline liest ein registriertes Modell und wendet es im Batch auf einen Datenbestand an (Batch-Scoring); Realtime-Serving ist dagegen ein Endpoint, der einzelne Requests bedient. Die Retraining-Pipeline wird durch Drift-Signale oder einen Zeit-Schedule getriggert und läuft die Trainings-Pipeline mit aktuellen Daten erneut durch. Bei Foundation Models ist die Fine-Tuning-Pipeline eine Sonderform, die ein vortrainiertes Modell mit domänen-spezifischen Daten anpasst.

Der Begriff existiert, weil er den orchestrierten Modell-Prozess vom reinen Trainings-Skript trennt. Ein Notebook oder ein Trainings-Skript produziert ein Modell, aber ohne Reproduzierbarkeit, Lineage und wiederanlaufbare Schritt-Grenzen. Eine ML Pipeline stellt diese Eigenschaften her: parametrisierbare Steps, versionierte Artefakte pro Run, deterministische Trainings-Datensätze über Time-Travel-Queries und eine durchgängige Ableitungskette vom Rohdaten-Input bis zum registrierten Modell. Ohne diese Disziplin bleibt ein Modell im Notebook-Zustand und lässt sich weder auditieren noch nachbauen.

Abgrenzung zu Data Pipeline, MLOps, LLMOps und Feature Pipeline

Der Begriff wird häufig mit einer benachbarten Ebene oder Disziplin verwechselt. Die folgende Tabelle sortiert die vier häufigsten Verwechslungen.

Begriff	Verhältnis zur ML Pipeline	Kern-Unterschied
Data Pipeline	Vorstufe und angrenzender Begriff	Verkettet Datenbewegung und -transformation ohne Trainings- oder Modell-Schritt. Liefert die Trainingsdaten und Features, aus denen die ML Pipeline lernt.
MLOps	Umgebende Disziplin	Der operative Rahmen um ML Pipelines (Praktiken, Werkzeuge, Governance, CI/CD für ML, Monitoring, Rollback). Die ML Pipeline ist ein Artefakt daraus, kein Ersatz für die Disziplin.
LLMOps	Nachbar-Disziplin ohne eigenes Training	Betreibt LLM-Anwendungen aus Prompt + gehostetem Modell ohne Trainings-Schritt. Bei Fine-Tuning oder Continued Pretraining eines Foundation Models entsteht wieder eine ML Pipeline (Fine-Tuning-Pipeline).
Feature Pipeline	Sub-Pipeline	Nur der Feature-Engineering-Teil, schreibt in einen Feature Store. Kann als eigenständige Feeder-Pipeline laufen oder als Schritt innerhalb einer vollen ML Pipeline.
Workflow / DAG	Orchestrierungs-Objekt	Der Airflow-DAG oder Databricks Workflow ist das Ausführungs-Gerüst, auf dem die ML Pipeline läuft. Derselbe Workflow kann mehrere Pipelines starten; dieselbe Pipeline lässt sich von unterschiedlichen Workflows triggern.

Zwei Trennlinien sind für die Architektur-Entscheidung zentral. Erstens die inhaltliche: Eine Data Pipeline bewegt Daten, eine ML Pipeline trainiert und deployt Modelle. Beide leben oft auf derselben Plattform (Databricks, Snowflake mit Snowpark ML, Vertex AI, Azure ML) und teilen sich Orchestrator und Compute; die Verantwortung liegt jedoch bei unterschiedlichen Teams (Data Engineering für die Datenstrecke, ML Engineering für den Modell-Prozess). Zweitens die Ebene: MLOps ist die Disziplin, die ML Pipelines diszipliniert baut, prüft, ausrollt und überwacht. Der Feature Store, das Model Registry und die Monitoring-Ebene gehören zur MLOps-Umgebung; die Pipeline selbst ist der ausführbare Prozess, der diese Bausteine nutzt.

Beispiel: Trainings-Pipeline für ein Churn-Modell im Lakehouse

Ein Handelsunternehmen betreibt eine ML Pipeline für die Churn-Prognose auf Databricks. Der Prozess ist als Databricks Workflow mit sechs Tasks modelliert und läuft wöchentlich sowie On-Demand.

Task eins berechnet Kunden-Features aus Silver-Tabellen im Lakehouse und schreibt sie versioniert in den Feature Store. Task zwei erzeugt den Trainings-DataFrame per Time-Travel-Query auf den Feature Store, sodass ein späterer Re-Run mit demselben Zeitstempel exakt dieselben Trainingsdaten liefert. Task drei trainiert ein LightGBM-Modell mit stratified k-fold Cross-Validation und einer Hyperparameter-Suche über Optuna; jeder Run wird in MLflow getrackt, inklusive Trainings-Metriken, Feature-Set-Version und Umgebungs-Fingerprint. Task vier evaluiert die beste Kandidaten-Version gegen einen Test-Split und berechnet F1-Score und PR-AUC, weil die Kündigungsrate im niedrigen einstelligen Prozent-Bereich liegt. Task fünf registriert das Modell im Mosaic AI Model Registry und setzt es bei erfüllten Schwellenwerten auf Stage Production. Task sechs rollt die neue Version als Realtime-Serving-Endpoint aus, den das CRM für Scoring-Aufrufe nutzt.

Die gesamte Kette ist die ML Pipeline. Der Databricks Workflow ist ihr Ausführungs-Objekt, das Feature Store, MLflow Tracking, Model Registry und Model Serving als Bausteine verwendet. Ein separater Databricks Workflow überwacht den Serving-Endpoint auf Feature-Drift und Kalibrierungs-Fehler und triggert die Retraining-Variante der Pipeline, sobald ein Schwellenwert überschritten wird. Data Pipeline (Silver-Tabellen, die Features speisen) und ML Pipeline (Training, Registry, Deployment) laufen nebeneinander und teilen sich Compute, Katalog und Governance im Lakehouse.