Managed MLflow auf Databricks: Tracking, Modellverwaltung und LLMOps
Die Kernaussagen auf einen Blick.
- Managed MLflow verwaltet in Databricks Experimente, Modellversionen und Lebenszyklus für klassische ML- und GenAI-Workloads in einer Plattform.
- Neue Modelle gehören in die Model Registry von Unity Catalog; die Workspace Registry trägt nur den laufenden Bestand weiter.
- Reproduzierbarkeit und Audit-Antworten brauchen früh gesetzte Standards für Tracking, Registrierung und (bei GenAI) Tracing.
- Mein Vorschlag: MLflow Tracking und Unity Catalog Registry als Plattform-Default setzen und Tracing für jede neue GenAI-Anwendung sofort mitkonfigurieren.
Inhaltsverzeichnis
Ohne Tracking ist euer Modell nicht reproduzierbar
Machine-Learning-Aktivitäten entstehen in vielen Unternehmen zunächst dezentral und schrittweise. Data Scientists entwickeln Modelle in eigenen Notebooks und Projektumgebungen. Dabei werden Parameter, Metriken und Artefakte häufig auf unterschiedliche Weise dokumentiert. Hyperparameter landen beispielsweise in Tabellen oder lokalen Notizen, Ergebnisse werden in Notebook-Zellen beschrieben, und Modellartefakte werden manuell in einen Objektspeicher kopiert. Bei wenigen Experimenten bleibt dieser uneinheitliche Umgang zunächst oft ohne sichtbare Folgen.
Mit dem ersten produktiven Modell steigen jedoch die Anforderungen an Nachvollziehbarkeit und Betrieb. Nach einiger Zeit lässt sich die ursprüngliche Trainingsumgebung möglicherweise nicht mehr vollständig wiederherstellen. Bibliotheksversionen, Trainingsdaten und Hyperparameter sind dann häufig nur unvollständig dokumentiert. Bei einer GenAI-Anwendung treten vereinzelt fehlerhafte oder unpassende Antworten auf. Ohne Tracing ist jedoch nicht nachvollziehbar, welche Prompts, Modelle und Werkzeuge an der Antwort beteiligt waren. Bei Fragen aus Datenschutz, Compliance oder Revision müssen Informationen aufwendig zusammengesucht werden oder bleiben lückenhaft.
Das Problem liegt dabei häufig weniger an fehlender Technologie als an fehlenden verbindlichen Standards für Tracking und Modellverwaltung. Einheitliches Tracking schafft die Grundlage dafür, Modelle reproduzierbar zu entwickeln, Versionen miteinander zu vergleichen und spätere Prüfungen zu unterstützen. Managed MLflow ist dafür die direkt in Databricks integrierte Lösung. Wird sie früh in Entwicklungs- und Betriebsprozesse aufgenommen, entfallen viele spätere Nacharbeiten und manuelle Rekonstruktionen. Wird Tracking erst nach dem Produktivstart eingeführt, sind wichtige Informationen aus früheren Trainings- und Bewertungsphasen oft nur noch teilweise verfügbar.
Im Betrieb müssen regelmäßig ähnliche Fragen beantwortet werden:
- Welche Modelle werden produktiv genutzt und welches Team ist für Betrieb und Freigabe verantwortlich?
- Welche Modellversion wurde für eine bestimmte Vorhersage oder Antwort verwendet?
- Welcher Trainingslauf hat die aktuell bereitgestellte Version erzeugt?
- Auf welcher fachlichen und technischen Bewertung basiert die Auswahl dieser Version?
- Wie kann eine neue Version eingeführt oder zurückgesetzt werden, ohne Anwendungen unnötig anzupassen oder Nachweislücken zu erzeugen?
Diese Informationen lassen sich nur zuverlässig bereitstellen, wenn sie während Entwicklung und Betrieb systematisch erfasst werden. Tracking, Modellregistrierung, Evaluation und Bereitstellung sollten deshalb als ein gemeinsamer Prozess organisiert werden.
Was ist Databricks Managed MLflow?
Managed MLflow ist die von Databricks im Workspace betriebene Variante des Open-Source-Projekts MLflow. Konzepte und APIs sind identisch zur OSS-Version: Experimente und Runs, MLflow Models, Model Registry, MLflow Tracing und MLflow Evaluate. Der Unterschied liegt nicht im SDK, sondern im Betrieb. Tracking-Server, Artefaktspeicher, Identitäten und Berechtigungen stellt die Databricks-Plattform bereit.
Damit ist Managed MLflow kein eigenständiges Produkt mit proprietärer API, sondern eine Tiefenintegration in Databricks. Die Model Registry läuft auf Unity Catalog, Artefakte liegen im Workspace-Storage, Authentifizierung übernimmt die Databricks-Identitätsverwaltung, und registrierte Modelle lassen sich direkt nach Model Serving deployen. Wer Databricks verlässt, kann Tracking- und Modellbestände auf einer eigenen OSS-Installation fortführen. Unity-Catalog-Lineage, Identitäts-Mapping und die Verzahnung mit Compute, Feature Store und Model Serving bleiben dabei zurück.
Damit ist das Lock-in unterschiedlich tief: Tracking und Modelle bleiben portabel, die Integration in Unity Catalog, Identitäten und Model Serving ist an Databricks gebunden.
Strukturell lässt sich das als dreischichtiger Stack denken: oben die Entwicklungsoberflächen (Notebooks, Jobs, MLflow SDK, MLflow UI), in der Mitte die sechs Managed-MLflow-Bausteine (Tracking, MLflow Models, Tracing und Evaluate portabel, Models in Unity Catalog und Deployments Databricks-gebunden), unten das Plattform-Fundament aus Unity Catalog, Identitäten, Compute, Workspace-Storage, Feature Store und Model Serving.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche Funktionen bietet Managed MLflow?
Managed MLflow gliedert sich in sechs Bausteine. Experimente und Runs erfassen Parameter, Metriken, Artefakte und Modelle. Die Model Registry verwaltet Modellversionen, Metadaten und Aliases. MLflow Tracing protokolliert zusätzliche Schritte in GenAI- und Agentenabläufen. Mit MLflow Evaluate lassen sich Modelle anhand festgelegter Qualitätskriterien vergleichen. Über Deployment-Schnittstellen können registrierte Modelle für die Nutzung in Model Serving vorbereitet werden.
Databricks ergänzt diese Funktionen um eine enge Integration in die bestehende Plattform. Nutzer und technische Identitäten werden über die vorhandene Databricks-Identitätsverwaltung authentifiziert. Zugriffsrechte auf Modelle und zugehörige Objekte lassen sich über Unity Catalog steuern. Artefakte werden über die von Databricks bereitgestellte Speicherintegration verwaltet, ein eigener Tracking- und Artefaktserver ist dafür nicht erforderlich. Notebooks, Jobs, Feature Engineering, Model Registry und Model Serving greifen auf dieselben Tracking- und Modellinformationen zu. Dadurch reduziert sich der Aufwand für zusätzliche Infrastruktur und eigene Integrationen.
Für die Architektur ergeben sich daraus vor allem zwei Vorteile. Ein eigener MLflow-Server mit Datenbank, Artefaktspeicher, Authentifizierung, Backup und Skalierung muss nicht selbst betrieben werden. Betrieb und Aktualisierung der Plattformkomponenten übernimmt Databricks. Die Integration mit Unity Catalog ermöglicht eine bessere Verbindung zwischen Daten, Runs, Modellversionen und Endpoints. In einer eigenständig betriebenen MLflow-Umgebung müssten diese Beziehungen separat hergestellt werden. So können Trainingsdaten, Modelle, Bereitstellung und produktive Nutzung innerhalb einer gemeinsamen Governance-Struktur betrachtet werden.
| Komponente | Funktion | Voraussetzung auf Databricks |
|---|---|---|
| MLflow Tracking | Experimente, Runs, Parameter, Metriken, Artefakte | Workspace |
| MLflow Models | Standardformat mit Signatur, Flavor, Feature-Bindings | Tracking-Run |
| Models in Unity Catalog | Registry mit Catalog-Schema-Modell-Namespace | Unity Catalog aktiv |
| MLflow Tracing | OpenTelemetry-Spans für Prompts, Tools, Agenten | MLflow 3, GenAI-SDK |
| MLflow Evaluate | Qualitäts-Metriken für ML und LLM | Tracking-Run, optional Datasets |
| MLflow Deployments | One-Click-Deploy auf Model Serving | UC-Modell-Eintrag |
Managed MLflow als Plattform-Default
Open Source als Basis
MLflow ist ein Open-Source-Projekt unter Apache-2.0-Lizenz. Tracking, Models, Registry und Tracing sind keine geschlossene Databricks-Komponente, sondern eine offene Referenz, die grundsätzlich auch außerhalb des Workspace betrieben werden kann.
Portabel, aber gebunden
Die MLflow-APIs sind in OSS und Managed identisch. Bei einem Wechsel bleiben Tracking und Modelle portabel. UC-Lineage, Workspace-Identitäten und die Verzahnung mit Compute, Feature Store und Model Serving bleiben dabei zurück.
Produktiv im Einsatz
MLflow wird in zahlreichen Unternehmen produktiv für klassische ML- und GenAI-Workloads betrieben. Reifegrad und Konzept stehen für eine Plattform-Default-Entscheidung nicht zur Diskussion.
Beobachtbarkeit als Standard
Tracking, Tracing, Lineage und Drift-Monitoring greifen ineinander. Daraus entsteht eine durchgängige Sicht von Trainingsdaten bis zur Inferenz-Antwort, ohne dass jedes Team eine eigene Observability-Schicht aufbauen muss.
Aktives Ökosystem
MLflow ist eines der aktivsten Projekte im MLOps-Umfeld (über 20.000 GitHub-Stars, mehrere hundert Contributors). Neue Frameworks und LLM-SDKs werden entsprechend schnell angebunden.
Framework-Anbindung ab Werk
MLflow integriert mit Scikit-learn, XGBoost, PyTorch, Spark MLlib, LangChain, OpenAI, Anthropic, LlamaIndex und weiteren. Für die meisten Workloads reicht `mlflow.autolog()` oder eine einzelne Auto-Instrumentation-Zeile.
Wie dokumentiert MLflow Trainingsläufe?
Ein Run ist die grundlegende Einheit des MLflow-Trackings. Er dokumentiert einen einzelnen Trainings-, Bewertungs- oder Verarbeitungslauf. Darin können alle relevanten technischen und fachlichen Informationen abgelegt werden: Konfigurationen und Hyperparameter, Trainings-, Test- und Validierungskennzahlen, Modelle, Diagramme, Berichte und weitere Artefakte, eine Beschreibung der erwarteten Ein- und Ausgabestruktur sowie Informationen zur verwendeten Laufzeit und Ausführungsumgebung. Mehrere zusammengehörige Runs werden in einem Experiment gebündelt. Ein Experiment kann beispielsweise einen Anwendungsfall, ein Modell oder eine bestimmte Forschungsfrage abbilden. Databricks kann Notebook-Runs automatisch einem passenden Experiment zuordnen. Dadurch steht eine grundlegende Tracking-Struktur bereits mit wenig Konfigurationsaufwand zur Verfügung.
Bei verbreiteten Frameworks kann ein großer Teil der Erfassung automatisiert werden. Mit mlflow.autolog() lassen sich unterstützte Bibliotheken automatisch instrumentieren. Abhängig vom Framework werden dabei unter anderem Parameter, Metriken, Artefakte und Modellinformationen protokolliert. Bei benutzerdefinierten Modellen können die benötigten Informationen gezielt über Framework-spezifische Logging-Funktionen oder pyfunc erfasst werden.
Für produktiv relevante Runs sollten mindestens drei Informationsbereiche verbindlich dokumentiert werden. Erstens Zweck, fachliches Ziel und verantwortliches Team, idealerweise als Beschreibung am Run oder über Tags. Zweitens technische Konfiguration, Laufzeit und Codebezug. Drittens Herkunft, Version und Auswahl der verwendeten Daten. Bei sauber eingebundenen Unity-Catalog-Tabellen kann ein Teil dieser Datenherkunft automatisch erfasst werden. Externe oder nicht katalogisierte Quellen müssen zusätzlich dokumentiert werden.
Der zentrale Nutzen liegt in der späteren Nachvollziehbarkeit. Welche Codebasis, Datenversion und Konfiguration haben zu einer bestimmten Modellversion geführt? Wer oder welcher technische Prozess hat den Lauf ausgeführt? Welche Compute- und Laufzeitumgebung wurde verwendet? Welche Metriken sind dabei entstanden? Diese Informationen werden sowohl bei Fehleranalysen als auch in Governance- und Auditprozessen benötigt. Tracking sollte deshalb für produktive Workflows verbindlich und nicht von der Arbeitsweise einzelner Personen abhängig sein.
Managed oder selbst betrieben?
Beide Varianten basieren auf denselben grundlegenden MLflow-Konzepten und APIs. Die Gegenüberstellung in der Databricks-Doku hebt mehrere Unterschiede hervor. Für eine Architekturentscheidung sind vor allem drei Bereiche relevant:
Auth & Mehrmandantenbetrieb
Eine selbst betriebene MLflow-Instanz benötigt eine eigene Lösung für Nutzer, Rollen und Zugriffsschutz. Managed MLflow greift auf die Identitäten und Berechtigungsmechanismen der Databricks-Plattform zurück.
Speicherung & Skalierung
Bei einer eigenen Installation liegt die Verantwortung für Datenbank, Artefaktspeicher, Backup, Verfügbarkeit und Skalierung beim Plattformteam. Managed MLflow verwendet die von Databricks betriebene Infrastruktur.
Datenherkunft & Governance
Mit Unity Catalog können Modellversionen mit Trainingsdaten und weiteren Plattformobjekten verknüpft werden. Eine vergleichbare Lineage muss in einer reinen Open-Source-Installation zusätzlich aufgebaut werden.
Der wesentliche Unterschied liegt damit weniger im Logging einzelner Runs als in Betrieb, Integration und Governance. Eine eigene Installation bietet mehr Kontrolle über Infrastruktur und Betrieb, dafür entstehen zusätzlicher Betriebsaufwand und eigene Integrationsaufgaben. In Databricks sind viele dieser Aufgaben bereits integriert; damit steigt jedoch auch die Abhängigkeit von der Databricks-Plattform.
Wie registriert man Modelle in Unity Catalog?
Für neue Modelle ist die Registry in Unity Catalog in der Regel der bevorzugte Ansatz. Modelle werden über einen dreistufigen Namen aus Catalog, Schema und Modellname adressiert (catalog.schema.model). Damit entspricht die Struktur den übrigen Objekten in Unity Catalog. Im Code wird Unity Catalog zunächst als Ziel für die Registry konfiguriert:
Das Modell wird unter dem angegebenen Catalog-, Schema- und Modellnamen registriert. Die Zugriffsrechte können über Catalog, Schema und Modellobjekt gesteuert werden. Bei korrekt eingebundenen Daten und Runs kann die Modellversion Teil der Lineage zwischen Training und Serving werden. Innerhalb des gemeinsamen Metastores kann sie von mehreren Workspaces genutzt werden. Die Doku zu Models in Unity Catalog beschreibt die Aliases wie @champion oder @challenger, die anstelle der festen Stages der Workspace Registry den Lifecycle steuern. Eine Modellversion kann mehrere frei definierte Aliases erhalten. Das ermöglicht flexiblere Rollout-, Test- und Rückfallmuster als die frühere Stage-Logik. Besser als ein Modellname mit eingebauter Version (etwa churn_v3) ist ein stabiler Funktionsname wie churn_model; die Versionierung übernimmt die Registry.
Wie die UC-Registry mit zusätzlichen Bewertungs- und Champion-Challenger-Funktionen umgeht, klären wir im Überblick zur Mosaic AI Model Registry. Wie Feature-Tabellen mit dem registrierten Modell verbunden werden, damit Trainings- und Serving-Pfad dieselbe Feature-Logik nutzen, zeigen wir im Feature Store auf Databricks.
Wozu noch die Workspace Registry?
Die Workspace Registry bleibt für bestehende Modelle verfügbar. Sie verwendet einen flachen Modellnamen und die früheren Stages wie Staging oder Production. Für bestehende Workloads kann sie vorübergehend weiterbetrieben werden, sollte aber nicht mehr die Grundlage neuer Modellprozesse sein. Für eine moderne, einheitliche Governance ist eine schrittweise Migration nach Unity Catalog sinnvoll. Unity Catalog bietet dabei insbesondere Vorteile bei Berechtigungen, Lineage und workspaceübergreifender Nutzung.
| Eigenschaft | Workspace-Registry | Models in Unity Catalog |
|---|---|---|
| Namespace | flach, pro Workspace | , global |
| Berechtigungen | ACLs pro Modell | UC-Permissions (Schema-vererbt) |
| Lifecycle-Steuerung | Stages (Staging/Production) | Aliases (mehrwertig, frei benennbar) |
| Lineage zu Tabellen | nein | ja |
| Cross-Workspace | nein | ja |
| Status | Legacy, Bestand pflegen | Default für Neuregistrierungen |
Neue Modelle sollten unmittelbar in Unity Catalog registriert werden. Bestehende Modelle können nach Relevanz und technischer Abhängigkeit schrittweise übernommen werden. Für die Migration können vorgesehene MLflow- und Databricks-Werkzeuge genutzt werden. Zunächst werden Zielstruktur, Namenskonventionen und Berechtigungen festgelegt. Anschließend werden Modelle und relevante Versionen kontrolliert übertragen. Danach werden Endpoints, Jobs und Anwendungen auf die neue Registry umgestellt.
Wie verfolgt MLflow Tracing GenAI-Abläufe?
GenAI-Anwendungen bestehen häufig aus mehreren abhängigen Schritten und benötigen deshalb eine detailliertere Beobachtung als klassische Einzelmodellaufrufe. Eine Antwort kann aus Retrieval, Promptaufbereitung, Modellaufrufen und Werkzeugnutzung zusammengesetzt sein. Zunächst kann ein Retrieval-System passende Informationen aus einer Wissensbasis suchen. Die gefundenen Inhalte werden anschließend zusammen mit Systemanweisung und Nutzerfrage an ein Sprachmodell gesendet. Je nach Aufgabe können zusätzliche Such-, Berechnungs- oder API-Funktionen aufgerufen werden. Die Qualität der finalen Antwort hängt damit von mehreren Komponenten ab.
MLflow Tracing bildet diese Verarbeitungsschritte als zusammenhängende Traces und einzelne Spans ab. Modell-, Retrieval- und Werkzeugaufrufe können separat erfasst werden. Untergeordnete Schritte bleiben innerhalb des Gesamtverlaufs sichtbar. Auch Suchanfragen und ihre Ergebnisse können im Ablauf dokumentiert werden. Die Tracing-Übersicht beschreibt die Auto-Instrumentation für gängige Frameworks wie LangChain, OpenAI, Anthropic oder LlamaIndex. Für unterstützte Frameworks lässt sich ein Teil der Instrumentierung mit wenig zusätzlichem Code aktivieren. Welche Details tatsächlich erfasst werden, hängt vom Framework und der Konfiguration ab.
Die Traces helfen dabei, die Entstehung einer Antwort Schritt für Schritt nachzuvollziehen. Welche Inhalte kamen aus Systemprompt, Nutzerfrage und Retrieval? Welche Quellen und Textabschnitte wurden an das Modell übergeben? Welcher Verarbeitungsschritt hat zu einem fehlerhaften oder unerwarteten Ergebnis beigetragen? Ohne einheitliches Tracing müssten solche Zusammenhänge aus verteilten Logs und Anwendungscode rekonstruiert werden. Tracing bündelt die relevanten Informationen in einer strukturierten Darstellung. Die erfassten Abläufe können zusätzlich als Grundlage für Evaluation und Fehleranalysen dienen.
Bei produktiv geplanten GenAI-Workflows sollte früh entschieden werden, welche Schritte aufgezeichnet werden müssen. Ohne diese Daten lassen sich Fehler in mehrstufigen Abläufen nur schwer reproduzieren. Dabei müssen Datenschutz, Aufbewahrung, Zugriffsschutz und Speicherbedarf berücksichtigt werden. Werden Traces mit Inferenzdaten und Modellversionen verknüpft, kann eine Antwort über Endpoint, Modell und Verarbeitungsschritte bis zu den verwendeten Quellen nachvollzogen werden.
Wie vergleicht MLflow Evaluate Modelle?
MLflow Evaluate ist die Auswertungsebene, mit der einem Tracking-Run Qualitätskennzahlen zugeordnet werden können. Für klassisches Machine Learning ist der typische Ablauf gut etabliert. Ein Testdatensatz wird gegen das Modell ausgewertet. Die Ergebnisse werden als Metriken wie Accuracy, F1, AUC, MSE oder RMSE protokolliert. Die gleiche Schnittstelle steht auch für GenAI-Workflows zur Verfügung, allerdings mit anderen Kennzahlen. Üblich sind unter anderem Faithfulness gegenüber den verwendeten Quellen, fachliche Korrektheit gegenüber Referenzantworten, Verständlichkeit, Toxizitätsbewertungen oder anwendungsspezifische Kriterien. Diese Metriken können regelbasiert berechnet oder mithilfe eines zweiten Sprachmodells als LLM-Judge ermittelt werden.
Wichtig ist, dass Auswertungen demselben Tracking-Run zugeordnet werden, in dem das Modell entstanden oder bewertet wurde. So bleiben Modell, verwendete Daten und Evaluationsergebnisse über den weiteren Lebenszyklus hinweg verbunden, auch nach einer Registrierung. Bei der Auswahl einer Modellversion können anhand der hinterlegten Bewertungsergebnisse verschiedene Versionen unter vergleichbaren Bedingungen miteinander verglichen werden. Aus einer reinen Versionsliste wird damit eine nachvollziehbare Bewertungsgrundlage.
In produktiven Umgebungen empfiehlt sich ein verbindlich definiertes Vorgehen. Für jeden neuen Anwendungsfall sollten Evaluationsmetriken, eine Testdatengrundlage (häufig Goldset genannt) und Akzeptanzschwellen vorab festgelegt werden. Jede neue Modellversion sollte die definierte Evaluation durchlaufen, bevor sie etwa als Challenger oder Champion gekennzeichnet wird. Ohne diese Disziplin bleibt die Auswahl der bevorzugten Version häufig schwer nachvollziehbar. Mit dokumentierten Evaluationsläufen entsteht hingegen eine belastbare Entscheidungsgrundlage.
Integration zwischen Model Training und Model Serving
Ein Modell kann erst dann zuverlässig produktiv betrieben werden, wenn Training und Serving dieselbe Feature-Logik verwenden. Werden Features im Training mit einer anderen Aufbereitungslogik erzeugt als im laufenden Betrieb, kann ein sogenannter Train/Serve-Skew entstehen. In diesem Fall werden im produktiven Einsatz andere Eingaben verarbeitet als beim Training. Feature Store unterstützt dabei, diese Diskrepanz zu vermeiden, indem Feature-Bindings beim Aufruf von log_model mitregistriert werden können. Beim Online-Serving bezieht die Plattform die erforderlichen Features automatisch aus dem Online-Store. Die aufrufende Anwendung muss dies nicht selbst übernehmen.
Der Bereitstellungspfad gestaltet sich anschließend relativ direkt. Ein Modell aus der Unity-Catalog-Registry kann über die mlflow.deployments-API oder direkt aus der Oberfläche an einen Model-Serving-Endpoint übergeben werden. Der erzeugte Endpoint übernimmt die Berechtigungen aus Unity Catalog, erscheint in der Lineage und kann seine Anfragen sowie Antworten in Inference Tables protokollieren. Diese Tabellen können als Grundlage für Drift-Erkennung, Qualitätsprüfungen und Audit-Auswertungen dienen.
Bei produktiven Anwendungen sollten einige Aspekte konsequent berücksichtigt werden. Erstens sollte je Endpoint klar dokumentiert sein, welche Modellversion oder welcher Alias bedient wird und welche Feature-Tabellen dabei genutzt werden. Zweitens sollten Berechtigungen für Endpoint, Modell und Features konsistent vergeben werden, damit die produktive Anwendung auf alle erforderlichen Objekte zugreifen kann. Drittens sollten Konfiguration und Berechtigungen idealerweise über Infrastructure-as-Code-Definitionen versionierbar sein. Änderungen am Endpoint bleiben so dokumentiert und reproduzierbar. Wie Agenten Teile dieser Lifecycle-Arbeit von Tracking bis Deployment übernehmen können, klären wir im Überblick zu ML-Engineering-Agents auf Databricks.
MLflow für Lineage und Governance
In Databricks dient MLflow als zentrale Informationsquelle, aus der Unity Catalog die Modell-Lineage ableiten kann. Damit lassen sich verschiedene Fragestellungen unterstützen. Aus welcher Trainingstabelle stammt ein Modell? Welcher Endpoint nutzt eine bestimmte Modellversion? Welcher Trainingslauf hat die aktuell als @champion gekennzeichnete Version erzeugt? Wenn Trainingsdaten, Features und Modellartefakte als Unity-Catalog-Objekte geführt werden, können diese Beziehungen weitgehend automatisch erfasst und in einer gemeinsamen Sicht dargestellt werden.
Für Governance-Prozesse ist dieser Aspekt aus mehreren Gründen relevant. Zum einen kann die Lineage die Bearbeitung typischer Audit-Fragen deutlich vereinfachen. Welche Datenversionen sind in eine produktive Modellversion eingeflossen? Welche Endpoints können von einer bestimmten Datenquelle beeinflusst sein? Welche Modelle sind potenziell von Änderungen an einer Tabelle betroffen? Zum anderen entsteht damit eine Grundlage, die zur Umsetzung regulatorischer Anforderungen beitragen kann. Der EU AI Act sieht für Hochrisiko-Systeme unter anderem eine umfassende Dokumentation von Trainingsdaten, Modellversionen und Leistungsmessungen vor. Eine maschinell auswertbare Lineage stellt dafür eine wichtige technische Voraussetzung dar.
Die Lineage allein ersetzt jedoch keine fachliche Dokumentation. Modellkarten, Lizenzhinweise, Evaluationsergebnisse und Beschreibungen vorgesehener Einsatzgebiete müssen weiterhin separat gepflegt werden. Tags und Beschreibungen an Modell und Modellversion können die technische Lineage um fachliche Informationen ergänzen, die für Freigaben und Audits relevant sind. Wie sich diese Bestandteile zu einer durchgängigen AI-Governance-Architektur fügen lassen, betrachten wir im Überblick zur AI-Governance auf Databricks.
Wie bleiben Änderungen nachvollziehbar?
Drift-Monitoring verbindet den produktiven Betrieb mit der Modellverwaltung. Lakehouse Monitoring kann die Inference Tables eines Serving-Endpoints auswerten und die Verteilungen von Eingaben und Ausgaben über einen definierten Zeitraum mit einer Baseline vergleichen. Verändert sich beispielsweise die thematische Zusammensetzung der Anfragen, die Verteilung relevanter Eingabemerkmale oder das Verhältnis bestimmter Antwortkategorien, kann eine Benachrichtigung ausgelöst werden. Die Auswahl der Metrik (zum Beispiel KL-Divergenz, Population Stability Index oder anwendungsspezifische Kennzahlen) und die zugehörigen Schwellenwerte sollten dabei auf die jeweilige Anwendung abgestimmt sein.
Die Verknüpfung zu MLflow entsteht durch die in den Inference Tables protokollierte Modellversion. Tritt eine Verschlechterung oder Verteilungsverschiebung auf, kann anhand der Versionsangabe nachvollzogen werden, mit welcher als @champion gekennzeichneten Version die betreffenden Anfragen verarbeitet wurden. Daraus lässt sich besser einschätzen, ob die Ursache eher in einer bestimmten Modellversion, in veränderten Eingabedaten oder in einer Kombination aus beidem liegt. Ein Rollback auf eine vorherige Modellversion lässt sich über die Alias-Mechanik in der Registry vergleichsweise unkompliziert vornehmen.
Im Betrieb empfiehlt es sich, Drift-Monitoring von Beginn an einzuplanen und nicht erst nach den ersten Auffälligkeiten zu ergänzen. Wesentliche Bestandteile sind eine konsistente Aktivierung der Inference Tables, dokumentierte Schwellenwerte, klare Verantwortlichkeiten für die Bewertung von Drift-Warnungen sowie ein definierter Eskalationspfad bis hin zu einem möglichen Re-Training. So entsteht aus einer rein technischen Möglichkeit ein nachvollziehbarer Betriebsprozess.
Was deckt MLflow nicht ab?
Ein verbreitetes Missverständnis ist die Annahme, MLflow trainiere Modelle selbst. Tatsächlich übernimmt es eine andere Rolle. Es erfasst Trainings- und Bewertungsläufe, verwaltet die entstehenden Modellartefakte, unterstützt die Evaluation, ermöglicht die Bereitstellung und liefert die Grundlage für die spätere Beobachtung im Betrieb. Das eigentliche Training erfolgt über Bibliotheken wie Scikit-learn, XGBoost, PyTorch, Spark MLlib, LangChain oder vergleichbare Frameworks. MLflow ist außerdem keine AutoML-Lösung und ersetzt keine Inferenzplattform. Model Serving stellt die Modelle bereit. MLflow liefert dazu das Artefakt, Versionsinformationen und den Auslöser für die Bereitstellung.
Gegenüber dedizierten Tracking-Werkzeugen wie Weights & Biases, Comet oder Neptune liegt der Schwerpunkt von MLflow auf Databricks weniger auf der Tiefe einzelner UI-Funktionen als auf der Verzahnung mit dem übrigen Plattform-Stack. Eine reine Tracking-Oberfläche ohne Anbindung an Unity Catalog und Model Serving lässt sich grundsätzlich auch mit einem dieser Drittwerkzeuge umsetzen. Sobald jedoch Lineage, Governance, einheitliche Berechtigungen und der Zugriff über mehrere Workspaces hinweg im Vordergrund stehen, wird die enge Integration mit der Databricks-Plattform zum wesentlichen Vorteil. Ein zusätzliches Werkzeug müsste in diesem Fall mehr leisten als reines Tracking. Es müsste eine vergleichbare Integration aufbauen.
Grenzen
Managed MLflow deckt einen großen Teil typischer MLOps- und LLMOps-Anforderungen ab, hat aber klare Einschränkungen, die vor einem produktiven Rollout berücksichtigt werden sollten.
Plattform-Bindung
Managed MLflow ist eng an Databricks gekoppelt. Wer Multi-Cloud-Portabilität auf der Tracking-Ebene benötigt, muss zusätzlich den Open-Source-Pfad einplanen und eine eigene Lineage-Absicherung aufbauen.
Reifegrad einzelner Funktionen
Bestimmte Bereiche von MLflow Tracing, automatischer LLM-Bewertung oder Auto-Instrumentation entwickeln sich schnell. Verfügbarkeit und Funktionsumfang können sich zwischen Modellen, Frameworks und Regionen unterscheiden.
Migration der Workspace Registry
Der Wechsel in Unity Catalog ist konzeptionell klar geregelt, kann bei einer größeren Zahl von Bestandsmodellen mit vielen Stage-Übergängen jedoch mehrere Wochen Aufwand verursachen.
Bewertungsmetriken für GenAI
Automatische Bewertungen durch Sprachmodelle (LLM-as-Judge) liefern Schätzwerte, ersetzen aber keine fachliche Qualitätsprüfung. Menschliche Stichproben und definierte Akzeptanzkriterien bleiben nötig.
Begriffliche Überschneidung mit Mosaic AI
Die in Unity Catalog integrierte Registry und das Marketingkonzept „Mosaic AI Model Registry” beschreiben oft denselben technischen Bereich. Vor Architekturdiskussionen sollte geklärt werden, welche Funktionen genau gemeint sind.
Diese Einschränkungen schränken die grundsätzliche Eignung von Managed MLflow als Plattform-Standard nicht ein. Sie verändern allerdings die Erwartungshaltung. Sie zeigen, was die Komponente selbst leistet und an welchen Stellen ergänzende Architektur- und Prozessentscheidungen erforderlich werden.
MLflow kann dabei als zentrale technische Klammer für MLOps und LLMOps in Databricks dienen. Feature Store, Model Serving, Unity Catalog und Monitoring werden über diese Schicht miteinander verbunden. Ohne eine solche gemeinsame Klammer besteht das Risiko, dass Modellaktivitäten als Einzelprojekte mit unterschiedlichen Werkzeugen und ohne durchgängige Sicht entstehen.
Fazit
Managed MLflow stellt in Databricks die Tracking- und Lifecycle-Schicht bereit, auf der MLOps- und LLMOps-Aufgaben zusammenlaufen können.
Wesentlicher als die grundsätzliche Entscheidung für oder gegen MLflow ist deshalb die Frage, in welcher Konfiguration und Einbettung die Komponente eingesetzt wird. Models in Unity Catalog können als zentrale Registry dienen. MLflow Tracing kann bei GenAI-Workflows von Beginn an mitgedacht und aktiviert werden, auch wenn klassische ML-Pipelines bisher mit weniger Detailtiefe ausgekommen sind. Evaluationsergebnisse können konsequent mit dem jeweiligen Modelleintrag verbunden werden, damit Bezeichnungen wie @champion oder @challenger mit fachlich nachvollziehbaren Informationen unterlegt sind. Eine durchgängige Lineage bis zur Quelldatentabelle kann dazu beitragen, dass spätere Audits nicht als aufwändige Sonderprojekte aufgesetzt werden müssen.
Empfehlenswert ist folgender Ansatz: Managed MLflow als Plattform-Standard etablieren, die Modellregistrierung konsequent in Unity Catalog führen, MLflow Tracing von Beginn an aktivieren und eine bestehende Workspace Registry geordnet migrieren. Diese Schritte sind eine bewusste Architektur-Entscheidung und keine reine Werkzeugwahl. Ihr Nutzen zeigt sich vor allem dort, wo Reproduzierbarkeit, Auditfähigkeit und Vergleichbarkeit nicht mehr von einzelnen Personen, sondern in der Plattform selbst verankert werden. Wie sich die einzelnen Bausteine zu einem Gesamtbild fügen, betrachten wir im Überblick zur Künstlichen Intelligenz auf Databricks.
FAQ
Managed MLflow ist die gehostete Variante von Open-Source-MLflow, die in den Databricks-Workspace integriert ist. Sie kombiniert die Tracking-, Models-, Registry-, Tracing-, Evaluate- und Deployments-Komponenten von MLflow mit Workspace-Auth, UC-Bindung und der direkten Verzahnung mit Compute, Feature Store und Model Serving. Das Ergebnis ist eine Plattform-Default-Schicht für ML- und GenAI-Lifecycle, die du nicht selbst betreiben musst.
