Model Registry

A model registry organizes model identities, versions, and related metadata. It can link a version to its artifact, training run, evaluation evidence, and intended use. Supported records and approval workflows vary by implementation.

A name must resolve to a specific version

Suppose a team records versions 7 and 8 of a recommendation model. An alias such as champion may point to version 7 today and version 8 after approval. The alias is a convenient reference, while the resolved version identifies what was selected. MLflow documents model versions, tags, and aliases as registry features.

If a prediction service loads version 7 at startup, moving an alias does not necessarily reload that running process. Deployment or reload logic must apply the change, and monitoring should report the version actually serving requests.

Registration is not approval

A registered model may still be an experiment. Quality tests, compatibility checks, access policy, and release decisions remain necessary. Merely labeling a version approved does not demonstrate that those checks occurred.

The registry is also not the inference engine. It can help a runtime locate a model, but the runtime performs predictions. For a rollback, retain the compatible preprocessing and execution environment as well as the earlier artifact; a version number alone cannot restore missing dependencies.

Reference: MLflow: Model registry.


Discover more from Insightful Data Lab

Subscribe to get the latest posts sent to your email.

Similar Posts

Questions, corrections, or additional insights?

This site uses Akismet to reduce spam. Learn how your comment data is processed.