Mosaic AI Model Registry: Wie Unity Catalog Modellverwaltung und Audit verbindet
Die Kernaussagen auf einen Blick.
- Die Mosaic AI Model Registry verwaltet Modelle als Unity-Catalog-Objekte im Namensraum catalog.schema.model_name. Berechtigungen, Lineage und Audit folgen denselben Regeln wie für Tabellen und Funktionen.
- Stages werden durch Aliases ersetzt. @champion und @challenger steuern Rollouts und Rollbacks, ohne dass Anwendungen, Jobs oder Endpoints geändert werden müssen.
- Die Migration aus der Workspace Registry läuft in drei Schritten: Stages auf Aliases übertragen, Aufrufer auf den neuen Registry-URI umstellen, Namens- und Strukturkonventionen vorher festlegen.
- Dev- und Prod-Modelle gehören in getrennte Catalogs (dev_models, prd_models) und in den Besitz einer technischen Identität. Vor dem Go-live muss nachvollziehbar sein, welche Modellversion welche Antwort erzeugt hat.
Inhaltsverzeichnis
Hundert Modelle registriert, fünf in Produktion
Die Ausgangslage ähnelt sich in vielen Unternehmen. In der Workspace Registry liegen zahlreiche Modelle, aber nur wenige werden produktiv genutzt. Welche das sind, lässt sich oft nicht ohne Weiteres beantworten. Bei einer Prüfung muss nachvollziehbar sein, welche Modellversion zu einem bestimmten Zeitpunkt verwendet wurde und welche Daten in ihr Training eingeflossen sind. Die benötigten Informationen sind jedoch häufig auf MLflow-Runs, Notebooks und nicht ausreichend versionierte Tabellen verteilt. Die Migration zu Unity Catalog ist zwar beschlossen, doch der Wechsel von Stages zu Aliases ist organisatorisch und technisch noch nicht geklärt. Ohne verbindliche Namenskonventionen entstehen zudem Modelle mit identischen oder missverständlichen Bezeichnungen.
Genau hier setzt die Mosaic AI Model Registry an. Die reine Verwaltung von Versionsnummern ist dabei nur ein kleiner Teil der Aufgabe. Entscheidend sind vielmehr die zugehörigen Verantwortlichkeiten, Berechtigungen und Herkunftsinformationen: Welche Nutzer oder Anwendungen dürfen das Modell verwenden? Aus welchem Trainingslauf ist die Modellversion entstanden? Welche Daten und Merkmale wurden für das Training verwendet? Welche Modellversion wird aktuell über den Endpunkt bereitgestellt? Wer hat die produktive Freigabe geprüft und genehmigt? Die Model Registry kann diese Fragen beantworten, wenn sie als zentraler Bestandteil der Modell-Governance aufgebaut wird. Wird sie nur als Ablage für Modellversionen genutzt, bleibt ein großer Teil ihres Nutzens ungenutzt.
Es sollte jederzeit erkennbar sein, welche Modelle produktiv genutzt werden und welche nicht mehr benötigt werden. Ebenso sollte sich eine produktive Modellantwort bis zum Trainingslauf und den verwendeten Tabellen zurückverfolgen lassen. Beim Wechsel der Verantwortung zwischen Teams müssen die zugehörigen Berechtigungen eindeutig geregelt sein. Ein Versionswechsel sollte ohne unnötige Unterbrechung des Endpunkts möglich sein. Für eine Übergangsphase mit beiden Registries braucht es eine klar definierte Reihenfolge für Migration und Umstellung der Verbraucher.
Diese Fragen lassen sich nicht allein durch Implementierung lösen. Sie müssen bereits bei der Architektur und den Betriebsprozessen vor der ersten produktiven Registrierung berücksichtigt werden.
Was ist die Databricks Mosaic AI Model Registry?
Die Mosaic AI Model Registry verwaltet den Lebenszyklus und die Governance von Modellen innerhalb der Databricks-Plattform. Modelle werden in einem dreistufigen Namensraum aus Catalog, Schema und Modellname abgelegt. Damit folgen sie derselben grundlegenden Organisationsstruktur wie Tabellen und Volumes. Für jedes registrierte Modell werden fortlaufende Versionen angelegt (1, 2, 3 …). Jede Version kann mit Aliases (zum Beispiel @champion, @challenger), Metadaten und einer Ein- und Ausgabesignatur versehen werden. Der Zugriff wird über die Berechtigungen von Unity Catalog gesteuert (USE CATALOG, USE SCHEMA, EXECUTE auf das Modell). Die Lineage kann eine Modellversion mit dem Trainingslauf, dem ausführenden Notebook oder Job sowie den verwendeten Daten- und Inferenztabellen verbinden (Databricks-Dokumentation zu Models in Unity Catalog).
Technisch baut die Lösung auf der MLflow Model Registry auf, die seit MLflow 1.4 als OSS-Komponente existiert. Databricks hat diese Funktionen in Unity Catalog integriert und damit zwei Verbesserungen mitgebracht: Dadurch lassen sich Daten- und Modellobjekte mit einem einheitlichen Berechtigungsmodell verwalten. Zusätzlich kann die Datenherkunft über einzelne Workspace-Grenzen hinaus nachvollzogen werden. Die ältere Workspace Registry mit ihren festen Stages (None, Staging, Production, Archived) bleibt für bestehende Lösungen verfügbar. Neue Implementierungen sollten jedoch in der Regel die Registry in Unity Catalog verwenden (Databricks-Dokumentation zum Upgrade aus dem Workspace-Registry).
Innerhalb einer MLOps-Architektur verbindet die Model Registry das Training mit der späteren Bereitstellung des Modells. Modelle können beispielsweise aus Mosaic AI Training, AutoML oder einem eigenen MLflow-Trainingslauf stammen. Managed MLflow dokumentiert den Trainingslauf. Die Model Registry verwaltet Versionen, Aliases und Zugriffsrechte. Model Serving stellt anschließend eine bestimmte Version oder einen Alias über einen Endpunkt bereit. Wie Foundation Models, Fine-Tuning, Registrierung und Bereitstellung zusammenspielen, klären wir im Überblick zu Artificial Intelligence auf Databricks. Die vorgelagerte Modellanpassung, samt Datenbasis und Verfahren, klären wir im Überblick zu Mosaic AI Training auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
MLflow Aliases statt Model Registry Stages: Was ändert sich?
Die Workspace Registry ordnete jede Modellversion einem von vier festen Zuständen zu. Zur Verfügung standen die Stages None, Staging, Production und Archived. Eine Stage war innerhalb eines Modells jeweils einer bestimmten Version zugeordnet. Bei einer produktiven Freigabe wurde beispielsweise Version 3 von Staging nach Production verschoben und die bisherige Produktionsversion entsprechend zurückgestuft oder archiviert. Dieses feste Modell ist einfach verständlich, stößt aber bei flexibleren Rollout-Verfahren an Grenzen: Parallele Rollen wie Champion, Challenger oder Shadow lassen sich damit nur eingeschränkt abbilden, jede Freigabe ist an einen Wechsel zwischen vordefinierten Zuständen gebunden, und außerdem ist dieses Stage-Modell nicht in die Berechtigungsstruktur von Unity Catalog eingebettet.
Aliases ermöglichen stattdessen frei definierbare Bezeichnungen für die Rolle einer Modellversion. Eine Version kann mehrere Aliases wie @champion, @challenger, @shadow oder @eu_region erhalten. Ein Alias kann auf eine neue Version gesetzt werden, ohne die übrigen Versionen oder Aliases zu verändern. Verbraucher, die über einen Alias auf das Modell zugreifen, verwenden anschließend die neu zugeordnete Version. Dadurch lässt sich ein Versionswechsel ohne separate Anpassung der Modelladresse umsetzen (MLflow-Dokumentation zu Model Registry Aliases). Alte Versionen bleiben erhalten, bis sie bewusst entfernt oder über Berechtigungen und Tags aus der aktiven Nutzung genommen werden. Nicht mehr benötigte Versionen können weiterhin zu Dokumentations- und Audit-Zwecken aufbewahrt werden.
| Aspekt | Workspace-Registry (Stages) | UC-Registry (Aliases) |
|---|---|---|
| Namensraum | flach pro Workspace | dreistufig (catalog.schema.model) |
| Promotion-Mechanik | Stage-Wechsel, Version-1-pro-Stage | Alias-Zuweisung, Version-N-pro-Alias möglich |
| Permissions | Workspace-ACLs, modell-lokal | UC-Privilegien, vererbt über Catalog/Schema |
| Lineage | run-zentriert, workspace-lokal | UC-Lineage über Daten, Features, Inference |
| Parallel-Rollouts | nicht vorgesehen | Champion und Challenger nebeneinander |
| Multi-Workspace | manuelles Sync | inhärent über UC-Metastore |
| Audit | MLflow-Tabellen pro Workspace | Audit-Log im Account |
Für die Benennung von Aliases empfiehlt sich eine einfache Regel: Jeder Alias sollte eine klare Funktion im Modelllebenszyklus beschreiben. Aliases sollten nicht lediglich eine Versionsnummer oder ein Datum wiederholen. @champion kann die derzeit freigegebene Produktionsversion kennzeichnen, @challenger kann auf eine mögliche Nachfolgeversion verweisen, @last_known_good kann eine geprüfte Version für ein schnelles Rollback markieren. Bezeichnungen wie @v3 oder @2026-06 bieten dagegen wenig zusätzlichen Nutzen, weil sie die technische Version nur erneut abbilden.
Wie steuert Unity Catalog den Modellzugriff?
In der Workspace Registry wurden Modellberechtigungen getrennt von den Zugriffsrechten auf Daten und andere Plattformobjekte verwaltet. In Unity Catalog sind Modelle reguläre, berechtigungsfähige Objekte. Für sie gelten damit dieselben grundlegenden Berechtigungsmechanismen wie für Tabellen, Volumes und Funktionen. Für den Zugriff sind insbesondere drei Berechtigungen relevant: USE CATALOG und USE SCHEMA ermöglichen den Zugriff auf den jeweiligen Namensraum. Mit EXECUTE wird die Nutzung des Modells in Anwendungen oder Inferenzprozessen erlaubt.
Die Eigentümerschaft sollte getrennt von den reinen Nutzungsrechten betrachtet werden. Produktive Modelle sollten nach Möglichkeit einer technischen Identität oder einer klar verantwortlichen Gruppe gehören. Ein Service Principal als Owner bietet zwei wesentliche Vorteile: Die Verantwortung bleibt unabhängig von personellen Veränderungen bestehen, und Zugriffe und Änderungen lassen sich einer eindeutig definierten technischen Identität zuordnen. Für Experimente in einer Entwicklungsumgebung kann eine persönliche Eigentümerschaft ausreichend sein. Bei produktiv bereitgestellten Modellen sollte die Verantwortung dagegen nicht an einer einzelnen Person hängen.
In produktiven Umgebungen haben sich drei Berechtigungsmuster bewährt:
Vererbung über Schema-Grenzen
Berechtigungen werden auf Schemaebene für eine Gruppe zusammengehöriger Modelle vergeben. Neu registrierte Versionen übernehmen die bestehende Berechtigungsstruktur.
Lese-Zugriff für Eval-Teams
Evaluationsjobs erhalten Ausführungsrechte auf das zu prüfende Modell, aber keine Berechtigung zur Änderung der Registry.
Strikte Trennung zwischen Dev und Prod
Entwicklungs- und Produktionsmodelle werden organisatorisch und technisch getrennt verwaltet. Die Übernahme in den Produktions-Catalog läuft als kontrollierter Prozess mit Prüfung und Freigabe.
Die UC-Mechanik im Detail, samt Catalog-Bindung und Privilege-Vererbung, klären wir im Überblick zu Unity-Catalog-Permissions.
Wie registriert man Modelle in Unity Catalog?
Die Registrierung eines Modells erfolgt über MLflow. Dazu wird im Trainingsjob zunächst Unity Catalog als Ziel-Registry konfiguriert: mlflow.set_registry_uri("databricks-uc"). Anschließend kann das Modell direkt beim Logging oder in einem separaten Registrierungsschritt angelegt werden, entweder über mlflow.<framework>.log_model() mit registered_model_name="catalog.schema.model_name" oder einen expliziten mlflow.register_model()-Aufruf. Für verbreitete Frameworks unterstützt MLflow eine weitgehend automatische Erfassung (scikit-learn, XGBoost, PyTorch, TensorFlow). Eigene Modelle und Wrapper können über die generische pyfunc-Schnittstelle eingebunden werden.
Für eine nachvollziehbare Registrierung sollten mindestens drei Arten von Informationen gepflegt werden:
Signatur
Beschreibt erwartete Eingaben und erzeugte Ausgaben. Ohne Signatur fehlt die Grundlage für spätere Qualitäts- und Drift-Prüfungen. MLflow kann sie aus Beispieldaten ableiten.
Tags
Frei definierbare Metadaten zur Modellversion: Anwendungsfall, Datenbereich, Lizenzstatus, Evaluationslauf, Verweis auf die Modellkarte.
Beschreibung
Erläutert Zweck und wichtigste Änderungen auf Modell- und Versionsebene. Macht aus einer Versionsnummer eine dokumentierte Modelländerung.
Automatisches Logging ersetzt keine verbindlichen Vorgaben für Dokumentation und Metadaten. Es erfasst technische Trainingsinformationen, ergänzt aber nicht automatisch alle fachlichen, organisatorischen und regulatorischen Angaben. Ohne diese Ergänzungen bleiben selbst sauber versionierte Modelle nur eingeschränkt nachvollziehbar.
Wie reicht Lineage von Training bis Inferenz?
Der besondere Nutzen der Registry in Unity Catalog zeigt sich in der durchgängigen Nachverfolgbarkeit. Eine registrierte Modellversion kann mit dem zugehörigen MLflow-Run, Notebook und Job verknüpft werden. Werden die Trainingsdaten aus Unity-Catalog-Tabellen gelesen, kann auch diese Datenherkunft Teil der Lineage werden. Sind für den Serving-Endpunkt Inference Tables aktiviert, lassen sich produktive Anfragen und Antworten mit der verwendeten Modellversion dokumentieren. So kann eine nachvollziehbare Kette entstehen: Von einer Modellantwort über den Endpunkt und die Modellversion bis zum Trainingslauf und den verwendeten Daten (Databricks-Dokumentation zu Model Lineage).
In der Praxis entstehen während einer Migration häufig drei Lücken in dieser Kette:
Daten außerhalb Unity Catalog
Direkte Zugriffe auf DBFS-Pfade oder externe Objektspeicher ohne Katalogisierung: Die Datenherkunft lässt sich dann nicht automatisiert nachvollziehen.
Extern trainierte Modelle
Wird nur das fertige Modell registriert, fehlt die Verbindung zum Trainingsprozess. Die Registry dokumentiert die Registrierung, nicht die Entstehung.
Features ohne Feature-Store-API
Werden Features außerhalb der vorgesehenen Feature-Engineering-Schnittstellen geladen, kann die Verbindung zwischen Feature-Tabelle und Modell fehlen.
Die Lineage-Mechanik im Detail klären wir im Überblick zu Unity-Catalog-Lineage. Eine vollständige Lineage sollte als Voraussetzung für die produktive Freigabe gelten. Bei einem produktiven Modell ohne nachvollziehbare Verbindung zu den Trainingsdaten bleibt eine wesentliche Lücke für Audit und Governance.
Wie benennt man Modelle, Catalogs und Schemas?
Namenskonventionen wirken zunächst nebensächlich, haben aber langfristig großen Einfluss auf Wartbarkeit und Migration. Da Modellnamen nicht einfach umbenannt werden können, sind spätere Korrekturen aufwendig. Auch Änderungen an Catalog- und Schemastrukturen erfordern häufig Anpassungen in Endpoints, Jobs und Anwendungen. Für die Struktur sind insbesondere drei Ebenen relevant:
Umgebung im Catalog
Getrennte Catalogs für Dev, Test und Prod (dev_models, stg_models, prd_models) trennen Lebenszyklen und Berechtigungen. Oft sinnvoll: Umgebung im Catalog, fachlicher Bereich im Schema.
Use Case im Schema
Schemas bündeln Modelle eines Anwendungsfalls oder einer Domäne. Berechtigungen werden zentral auf Schemaebene vergeben, neue Modelle erben die Struktur.
Modell-Name als Funktion
Der Name beschreibt die fachliche Aufgabe (intent_classifier), nicht Verfahren oder Version. Die gehören in Tags und Beschreibung.
Eine mögliche Konvention sieht wie folgt aus:
| Achse | Konvention | Beispiel |
|---|---|---|
| Catalog | Umgebung | prd_models |
| Schema | Use Case oder Domäne | customer_intelligence |
| Model Name | Funktion, kein Verfahren | intent_classifier |
| Version | automatisch (1, 2, 3 …) | Version 7 |
| Alias | Rolle im Lifecycle | @champion, @challenger |
Besonders aufwendig sind spätere Änderungen an Catalog-, Schema- und Modellnamen (Konsumenten-Code; kein Rename in UC, nur Kopie). Aliases, Tags, Beschreibungen und Berechtigungen lassen sich dagegen vergleichsweise einfach anpassen. Die grundlegende Namensstruktur sollte vor der ersten produktiven Registrierung feststehen. Eine spätere Umstellung verursacht meist deutlich mehr Aufwand.
Wie migriert man von Workspace Registry zu Unity Catalog?
Die Migration von der Workspace Registry in die Registry von Unity Catalog erfordert mehrere vorbereitete Schritte. Eine Aufteilung in drei aufeinanderfolgende Phasen hat sich dabei bewährt.
Bestand aufnehmen und Zielstruktur festlegen
Erfassen, welche Modelle produktiv genutzt werden und welche Stages aktuell gelten. Stages werden auf passende Aliases abgebildet (@champion, @challenger), Verantwortlichkeiten stehen vor der Übernahme fest.
Modelle in Unity Catalog neu registrieren
Ein definierter Prozess übernimmt die Modellversionen in den Ziel-Catalog, überträgt Metadaten und ordnet die festgelegten Aliases zu. Der MLflow-Client braucht ein Update auf die Registry-URI databricks-uc.
Verbraucher auf die neue Registry umstellen
Serving-Endpunkte, Jobs, Batch-Scoring und Notebooks wechseln zu eindeutig festgelegten Zeitpunkten auf den neuen Registry-URI. Endpoints mit Alias-Bindung vertragen den Wechsel besser als fest verdrahtete Versionen.
Drei Probleme treten bei Migrationen besonders häufig auf:
Versionsnummern driften auseinander
Die UC-Versionsnummer ergibt sich aus der Reihenfolge der Registrierungen. Verbraucher mit fest eingetragenen Versionsnummern müssen gezielt angepasst werden.
Trainingsläufe fehlen nachträglich
Bei älteren oder manuell übertragenen Modellen fehlt oft die Verknüpfung zum Trainingslauf. Die Herkunft muss über zusätzliche Metadaten dokumentiert werden.
Berechtigungen übersetzen sich nicht automatisch
Workspace-ACLs werden nicht automatisch in eine UC-Struktur übertragen. Zugriffsrechte müssen für alle Gruppen und Identitäten neu eingerichtet werden.
Ein langer Parallelbetrieb beider Registries führt häufig zu unklaren Zuständigkeiten und widersprüchlichen Informationsständen. Was zunächst risikoarm erscheint, schafft in der Praxis zwei konkurrierende Quellen für Versionen und Freigaben. Dadurch wird die angestrebte einheitliche Nachvollziehbarkeit erneut geschwächt.
Model Serving mit Aliases: Champion, Challenger und Rollback
Model Serving gehört zu den wichtigsten Verbrauchern registrierter Modelle. Ein Endpunkt kann auf eine konkrete Modellversion oder auf einen Alias verweisen. Die Wahl beeinflusst, wie Versionswechsel, Rücksetzungen und Freigaben umgesetzt werden.
Alias wählen, wenn
- Versionswechsel zentral gesteuert werden sollen, ohne die Endpunkt-Config zu ändern
- Ein schnelles Rollback über Alias-Rücksetzung möglich sein muss
- Ein geregelter Freigabeprozess für Alias-Änderungen existiert (Deployment- oder IaC-Pipeline mit Review)
Feste Version wählen, wenn
- Jeder Versionswechsel durch Code-Review und Deploy laufen soll
- Sehr direkte, nachvollziehbare Kontrolle über den Endpunkt gefragt ist
- Konfigurationsänderungen bei jedem Wechsel akzeptabel sind
In produktiven Umgebungen sollte die Flexibilität von Aliases mit einem kontrollierten Freigabeprozess kombiniert werden. Die Änderung eines produktiven Alias sollte über eine geprüfte Deployment- oder Infrastructure-as-Code-Pipeline erfolgen. Drei Bereitstellungsmuster sind besonders verbreitet:
Single-Alias-Endpoint
Ein Produktionsalias für stabile Anwendungsfälle mit klar definiertem Champion. Freigabe und Rücksetzung laufen über die Alias-Zuordnung.
Split-Traffic-Endpoint
Champion und Challenger laufen parallel mit festgelegtem Traffic-Anteil (z. B. 95/5), ein produktionsnaher Vergleich bei kontrolliertem Risiko.
Shadow-Endpoint
Neue Versionen laufen intern mit, ohne Antworten an externe Nutzer auszuliefern. Evaluationslast bleibt von produktiven Antwortzeiten getrennt.
Die Endpoint-Mechanik im Detail, samt Durchsatz (englisch throughput, Anzahl der Anfragen pro Zeiteinheit) und Inference Tables, klären wir im Überblick zu Model Serving auf Databricks.
Wie stützt die Registry die AI Governance?
Die Model Registry kann als zentrale Informationsquelle für Prüfungen und Governance-Prozesse dienen. Für regulatorische Anforderungen sind insbesondere Herkunft, Trainingsdaten und produktive Verwendung eines Modells relevant (Europäische Kommission zum AI Act): Es sollte dokumentiert sein, wie und aus welchem Basismodell eine Version entstanden ist. Die verwendeten Trainings- und Evaluationsdaten müssen nachvollziehbar beschrieben werden. Produktive Ergebnisse sollten einer konkreten Modellversion und ihrem Freigabestand zugeordnet werden können.
Die Model Registry allein stellt noch keine regulatorische Konformität her. Sie kann jedoch wichtige Nachweise und Verknüpfungen für Prüfungen bereitstellen.
Vom Registry-Eintrag zum Audit-Nachweis.
Unity Catalog, Lineage, Managed MLflow und die Model Registry liefern zusammen die Nachweise für EU-AI-Act- und DSGVO-Anforderungen.
In produktiven Umgebungen sollten mindestens drei Arten von Governance-Informationen gepflegt werden:
Versionierte Modellkarte
Dokumentiert Trainingsdaten, Qualitätsmessungen, Einschränkungen und vorgesehene Einsatzbereiche, verlinkt an der Modellversion, z. B. als Dokument in einem UC-Volume.
Goldset und Evaluationslauf
Goldset-Version, Evaluationslauf und wichtigste Ergebnisse werden an der Modellversion dokumentiert, die Grundlage für die Auswahl dieser Version.
Lizenz bei Foundation Models
Bei angepassten Foundation Models wird die zugrunde liegende Lizenz festgehalten (Llama Community License, Apache 2.0, DBRX Open Model License).
Wie sich diese Anker zu einer durchgängigen AI-Governance-Schicht verbinden, samt Klassifikation der Risiko-Stufen und der Rolle des Model Risk Management, klären wir im Überblick zu AI Governance auf Databricks.
Wie dokumentiert man Modelle in der Registry?
Tags ermöglichen frei definierbare Metadaten auf Modell- und Versionsebene. Ohne verbindliche Regeln entstehen jedoch uneinheitliche und schwer auswertbare Angaben. Mit einer klaren Konvention können Tags Prüfungen und den laufenden Betrieb deutlich erleichtern. Drei Kategorien sind für viele Plattformen sinnvoll:
Tags zum Anwendungsfall
Beschreiben Zweck, Domäne und fachliche Verantwortung (use_case, domain, business_owner): wofür das Modell eingesetzt wird und welches Team verantwortlich ist.
Qualitätsbezogene Tags
Verweisen auf Evaluationslauf, Goldset und zentrale Kennzahlen (eval_run_id, goldset_version, accuracy), die Testgrundlage der Freigabe.
Compliance-bezogene Tags
Verweisen auf Modellkarte, Datenschutzstatus und Lizenz (model_card_url, pii_status, license), Prüfungsinformationen direkt an der Modellversion.
Tags können entweder für das gesamte Modell oder gezielt für eine einzelne Version gesetzt werden. Als einfache Zuordnungsregel gilt: Versionsabhängige Informationen wie Evaluationsergebnisse und Goldset-Versionen sollten an der jeweiligen Modellversion gepflegt werden. Stabile Angaben wie Anwendungsfall oder grundsätzlich verantwortliches Team gehören auf die Modellebene.
Ein häufiges Problem besteht darin, Metadaten erst kurz vor einer Prüfung nachzupflegen. Zu diesem Zeitpunkt sind die benötigten Angaben für viele ältere Versionen oft nicht mehr vollständig rekonstruierbar. Die Vergabe zentraler Tags sollte deshalb direkt in Trainings- und Registrierungsprozesse integriert werden. Eine spätere manuelle Bereinigung verursacht deutlich mehr Aufwand und bleibt häufig unvollständig.
Externe Model Registries anbinden oder konsolidieren?
In Multi-Cloud-Umgebungen bestehen häufig weitere Modellregistries neben Unity Catalog. SageMaker Model Registry, Vertex Model Registry und produkt-eigene Registries (zum Beispiel in MLOps-Plattformen wie Dataiku oder DataRobot) existieren parallel. Drei typische Betriebsmodelle sind möglich:
Föderation über Inventory-Tags
Externe Modelle werden über Referenzen und Metadaten in Unity Catalog sichtbar gemacht, ohne erneute Bereitstellung in Databricks, praktikabel als Übergangslösung.
Konsolidierung auf UC
Bei stark fragmentierter Registry-Landschaft vereinfacht die Migration auf Unity Catalog Freigaben, Berechtigungen und Prüfungen im laufenden Betrieb.
Beibehaltung externer Registries
Bleibt sinnvoll, wenn der Anwendungsfall komplett im jeweiligen Cloud-Stack läuft. Dafür müssen getrennte Governance- und Audit-Prozesse dauerhaft bestehen.
In einer überwiegend auf Databricks ausgerichteten Plattform ist die Registry in Unity Catalog häufig die naheliegende Hauptlösung. Externe Sonderfälle können ergänzend über Referenzmodelle dokumentiert werden. Eine dauerhaft verteilte Registry-Landschaft erschwert eine einheitliche Rückverfolgbarkeit von Daten, Modellen und Freigaben.
Grenzen der Mosaic AI Model Registry
Die Mosaic AI Model Registry unterstützt die Verwaltung und Governance von Modellen zwischen Training und produktiver Nutzung. Sie ersetzt weder eine Evaluationspipeline noch Drift-Monitoring oder einen reproduzierbaren Trainingsprozess und hat klare Grenzen.
Kein automatischer Übernahme-Prozess
Bestehende Modelle in der Workspace Registry werden nicht automatisch übernommen. Planung, Zuordnung und Umstellung liegen beim verantwortlichen Team.
Namen sind nachträglich schwer änderbar
Catalog-, Schema- und Modellnamen lassen sich nicht ohne Weiteres ändern. Eine Korrektur erfordert in der Regel ein neues Objekt und die Anpassung aller Verbraucher.
Lineage-Vollständigkeit hängt vom Setup ab
Die Registry stellt nur Beziehungen dar, die während Training und Registrierung tatsächlich technisch erfasst wurden.
Evaluation läuft außerhalb der Registry
Modell-Karten, Goldset-Ergebnisse und Drift-Monitoring sind eigene Schichten. Die Registry speichert Verweise und Ergebnisse, führt die Prüfung aber nicht selbst aus.
Aliases ersetzen keinen Freigabeprozess
Wird ein produktiver Alias ohne Prüfung geändert, kann sofort eine andere Modellversion aktiv sein. Freigaben müssen in Deployment- und Review-Prozessen erzwungen werden.
Diese Einschränkungen sprechen nicht grundsätzlich gegen die Model Registry. Sie sollten jedoch bei der Planung der Modellverwaltung berücksichtigt werden. Es muss klar sein, welche Aufgaben die Registry übernimmt und welche zusätzlichen Prozesse für Training, Evaluation und Betrieb erforderlich sind. Ebenso braucht es verbindliche Regeln, damit technische Funktionen und organisatorische Prozesse zuverlässig zusammenspielen.
Fazit
Die Mosaic AI Model Registry in Unity Catalog verbindet die technische Modellverwaltung mit Anforderungen an Governance und Audit.
Aliases ersetzen die festen Stages durch flexible Rollenbezeichnungen und ermöglichen zentral gesteuerte Versionswechsel. Unity Catalog vereinheitlicht die Berechtigungsverwaltung für Daten- und Modellobjekte. Die Lineage kann eine produktive Antwort mit der verwendeten Modellversion, dem Trainingslauf und den zugrunde liegenden Daten verknüpfen. Damit verbessert die Registry die Nachvollziehbarkeit gegenüber einer isolierten Workspace-basierten Modellverwaltung.
Die größten Probleme entstehen häufig bereits vor der ersten produktiven Registrierung: Namenskonventionen werden erst eingeführt, nachdem bereits mehrere Modelle registriert wurden. Catalog- und Schemastrukturen werden während des laufenden Betriebs mehrfach angepasst. Metadaten werden erst nachträglich und häufig unvollständig ergänzt. Solche Korrekturen verursachen später deutlich mehr Aufwand als eine frühzeitige Festlegung der grundlegenden Struktur.
Empfehlenswert ist folgender Ansatz: Für jeden produktiven Anwendungsfall sollten eindeutige Aliases wie @champion und @challenger definiert werden. Entwicklungs- und Produktionsmodelle sollten in getrennten Catalogs verwaltet werden (dev_models, prd_models). Die Eigentümerschaft produktiver Modelle sollte bei technischen Identitäten oder klar verantwortlichen Gruppen liegen. Namens- und Strukturkonventionen sollten vor der ersten Registrierung beschlossen und dokumentiert werden. Die Migration aus der Workspace Registry sollte für jeden Anwendungsfall einen eigenen getesteten Umstellungszeitpunkt haben. Eine produktive Freigabe sollte erst erfolgen, wenn sich eine Modellantwort über Endpunkt und Modellversion bis zu Trainingslauf und Trainingsdaten zurückverfolgen lässt. Mit diesen Regeln entsteht eine nachvollziehbare und dauerhaft betreibbare ML-Plattform. Wird die Registry dagegen nur zur Ablage von Versionsnummern verwendet, bleibt sie eine technische Bestandsliste ohne belastbare Governance.
FAQ
Der Mosaic AI Model Registry im Unity Catalog ist die Lifecycle- und Governance-Schicht für Modelle auf Databricks. Modelle leben als UC-Objekte in einem dreistufigen Namensraum (catalog.schema.model_name) mit Versionen, Aliases, Tags und Signaturen. Berechtigungen erben über UC-Privilegien, Lineage hängt am Trainings-Run und an den Daten. Der Registry ersetzt das ältere Workspace-Model-Registry mit seinen Stages.
