Mosaic AI Model Registry: Definition und Abgrenzung

Die Mosaic AI Model Registry ist das zentrale Verzeichnis für KI-Modelle auf Databricks, also für die trainierten Vorhersage-Modelle klassischer Machine-Learning-Verfahren und großer Sprachmodelle (Large Language Models, LLMs). Sie legt jedes Modell als berechtigungspflichtiges Objekt im Unity Catalog (dem zentralen Rechte- und Datenverzeichnis von Databricks) ab, nummeriert jede neue Version fortlaufend (1, 2, 3 …) und steuert den produktiven Wechsel über frei benannte Rollen-Zeiger, sogenannte Aliases wie @champion (aktuell live) und @challenger (Kandidat), statt über feste Reifegrade.

Was ist die Mosaic AI Model Registry?

Die Mosaic AI Model Registry ist der Verzeichnis-Baustein innerhalb von Databricks Mosaic AI, dem Bereich der Databricks-Plattform, der alle KI-Werkzeuge für Training, Modellablage und Bereitstellung bündelt. Technisch baut sie auf der [MLflow Model Registry](https://mlflow.org/docs/latest/ml/model-registry/) auf, einem quelloffenen Baustein zur Modellverwaltung (verfügbar seit MLflow 1.4), und hängt diese Verwaltung an Unity Catalog (den zentralen Rechte- und Datenkatalog von Databricks). Modelle liegen dadurch im gleichen Katalog wie Tabellen, Dateibereiche (Volumes) und Funktionen und werden über dieselben Berechtigungen gesteuert.

Ein registriertes Modell besitzt einen dreistufigen Namen (catalog.schema.model_name), eine fortlaufende Versionsnummer (1, 2, 3 …) je Ausprägung und optionale Aliases als frei benannte Rollen-Zeiger auf konkrete Versionen. Jede Version kann eine Signatur (Input-/Output-Schema), Tags und Beschreibungen tragen. Der Zugriff wird über UC-Privilegien gesteuert: USE CATALOG und USE SCHEMA für den Namensraum, EXECUTE für die produktive Nutzung des Modells in Anwendungen und Inferenz-Prozessen ([Databricks-Dokumentation zu Models in Unity Catalog](https://docs.databricks.com/aws/en/machine-learning/manage-model-lifecycle/)).

Der Begriff wurde 2023 im Zuge der Umbenennung der akquirierten MosaicML-Suite zu „Mosaic AI" geprägt und bezeichnet seither die UC-Variante der Registry. Die ältere Workspace Registry mit ihren festen Zuständen (None, Staging, Production, Archived) existiert weiter für Bestandslösungen; für neue Implementierungen ist die UC-Registry die von Databricks empfohlene Voreinstellung. Der MLflow-Client spricht sie über mlflow.set_registry_uri("databricks-uc") an. Modelle werden dann entweder direkt beim Logging (mlflow.<framework>.log_model(..., registered_model_name="catalog.schema.model_name")) oder in einem separaten Schritt (mlflow.register_model(...)) registriert.

Der Nutzen liegt in drei zusammengeführten Ebenen: einheitliches Berechtigungsmodell für Daten und Modelle, durchgängige Lineage von Trainingsdaten über Modellversion bis Inference-Anfrage und produktiver Versionswechsel per Alias-Zuweisung ohne Endpoint-Änderung. Für Freigabe-Prozesse und regulatorische Nachweise nach EU AI Act und ISO/IEC 42001 wird die Registry zum zentralen Anker: Wer welche Version wann freigegeben hat und aus welchen Daten sie entstanden ist, ist ohne separates Tooling nachvollziehbar.

Abgrenzung: Model Serving, Model Card, Feature Store, MLflow-Vorgänger

Die Registry wird häufig mit Nachbar-Bausteinen im MLOps-Stack vermischt. Fünf Begriffe stehen typischerweise im Umfeld.

Begriff	Ebene	Verhältnis zur Mosaic AI Model Registry
Model Serving	Endpoint-Schicht	Konsument der Registry. Lädt eine Version oder folgt einem Alias (models:/catalog.schema.model_name@champion) und stellt das Modell hinter einem HTTP-Endpoint bereit.
Model Card	Dokumentations-Artefakt	Inhalt an der Modellversion (Zweck, Trainingsdaten, Grenzen, Fairness-Metriken). Die Registry ist die System-Ebene, die Karte ist das kuratierte Dokument.
Feature Store	Feature-Schicht	Verwaltet Features und Feature-Tabellen in UC. Trainings- und Inferenz-Features werden aus dem Feature Store gezogen; das trainierte Modell landet in der Registry, dessen Lineage per UC auf die Feature-Tabellen verweist.
Managed MLflow	Tracking-/Registry-Produkt	Databricks' verwaltete MLflow-Instanz insgesamt. Die Mosaic AI Model Registry ist der Registry-Teil davon in der UC-Variante; das Experiment-Tracking bleibt daneben bestehen.
Workspace Model Registry	Vorgänger-Registry	Workspace-lokale MLflow-Registry mit festen Stages (None, Staging, Production, Archived). Läuft außerhalb der UC-Objektwelt, mit Workspace-ACLs und ohne cross-workspace-Lineage.

Model Serving ist der häufigste Verwechslungspunkt: Aus Sicht des Clients erscheint ein produktives Modell als HTTP-Endpoint, während der Registry-Eintrag im Hintergrund die Artefakte hält. Die Registry verwaltet die versionierten Artefakte und Rollen-Zeiger, Serving liefert Vorhersagen. Ein Endpoint verweist entweder fest auf eine Version (.../3) oder folgt einem Alias (.../@champion); Alias-basierte Endpoints entkoppeln den Versionswechsel vom Deployment.

Eine Model Card lebt an der Registry als angehängtes Dokumentations-Artefakt. In der Mosaic AI Model Registry wird sie typischerweise als Beschreibung am Modell-Objekt oder als Verweis auf ein versioniertes Dokument in einem UC-Volume gepflegt. Die Registry liefert die Infrastruktur (Version, Berechtigung, Lineage), die Karte den auditierbaren Inhalt.

Der Feature Store verwaltet keine Modelle. Er liefert die Feature-Werte, die während Training und Inferenz mit identischer Semantik konsumiert werden. In einem sauberen Setup verweist die Registry per Lineage auf die verwendeten Feature-Tabellen; dadurch ist rückverfolgbar, welche Feature-Version in eine Modellversion eingeflossen ist. Umgekehrt kennt der Feature Store das Modell nicht.

Die Workspace Model Registry ist der direkte Vorgänger und läuft technisch auf denselben MLflow-APIs. Der Unterschied liegt im Governance-Fundament: Aliases statt Stages, UC-Privilegien statt Workspace-ACLs, ein Metastore statt getrennter Workspace-Silos. Für Bestandsartefakte bleibt die Workspace-Variante nutzbar; für den produktiven Neuaufbau ist die UC-Variante der Standard.

Beispiel: Intent-Klassifikator und produktiver Alias-Wechsel

Ein Kunden-Intent-Klassifikator für einen Service-Assistenten wird auf Databricks trainiert und in der Mosaic AI Model Registry unter prd_models.customer_intelligence.intent_classifier registriert. Der Trainings-Job setzt vor dem Logging mlflow.set_registry_uri("databricks-uc") und ruft mlflow.sklearn.log_model(model, "model", registered_model_name="prd_models.customer_intelligence.intent_classifier", signature=signature). Die neue Version 7 landet mit Trainings-Metadaten, Signatur und Verweis auf den MLflow-Run in der Registry.

Ein nachgelagerter Evaluations-Job zieht die Version 7, prüft sie gegen ein Goldset und schreibt die Ergebnisse als Tags an die Modellversion (eval_run_id, goldset_version, accuracy). Nach bestandener Prüfung setzt ein CI-Prozess über die UC-CLI den Alias @champion auf Version 7; der bisherige Champion (Version 6) erhält den Alias @last_known_good als Rollback-Anker. Ein Model-Serving-Endpoint spricht das Modell über den URI models:/prd_models.customer_intelligence.intent_classifier@champion an. Der Versionswechsel ist damit eine Alias-Zuweisung, keine Endpoint-Änderung; ein Rollback setzt den Alias zurück auf Version 6.

UC-Lineage verknüpft die Modellversion mit dem MLflow-Run, dem ausführenden Notebook und den Silber-Tabellen, aus denen die Trainingsdaten stammen. Sind Inference Tables am Serving-Endpoint aktiviert, schließt sich die Kette bis zur produktiven Anfrage: Von einer konkreten Modellantwort führt der Pfad über die Inference-Tabelle zur Modellversion, zum Trainingslauf und zu den Eingangs-Tabellen. Für eine Prüfung nach EU AI Act oder ISO/IEC 42001 ist damit ohne zusätzliches Werkzeug nachvollziehbar, welche Version welche Antwort produziert hat und auf welchen Daten sie trainiert wurde.