MLflow Model Registry
The tracker holds hundreds of churn runs. Only one of them should answer real users today. The serving code must not care which run that is — it should just ask for "the current churn model". A model registry is the place that answers that question, and lets you change the answer safely.
The rule
Name the model, number the versions, point an alias at the live one.
A registered model has a name, like churn-model. Each time you register a run's model under that name, it becomes the next version: 1, 2, 3… Each version remembers the run it came from, so you can always walk back to its parameters, metrics and data.
import mlflow
from mlflow import MlflowClient
result = mlflow.register_model(f"runs:/{run_id}/model", "churn-model")
print(result.version) # e.g. 8
client = MlflowClient()
client.set_registered_model_alias("churn-model", "champion", result.version)An alias is a movable label pointing at exactly one version. The serving code loads by alias, not by version or file path:
model = mlflow.pyfunc.load_model("models:/churn-model@champion")Now the deploy decision is separated from the code:
- Promote: move
championfrom version 7 to version 8. - Roll back: move
championback to version 7. Old versions are kept, so this is one quick change plus a reload of the serving pods. - Test: point a second alias, such as
challenger, at a candidate so a shadow or canary deployment can load it.
Older MLflow guides use fixed stages (Staging, Production) instead of aliases; newer releases deprecate stages in favour of aliases, which work the same way but let you choose the names.
The shortcut
Every registry action is one sentence: "Move alias X to version N." Promote, roll back and test are all that sentence with different values.
Register
The winning run's model becomes
churn-modelversion 8, linked to its run.
The trap is loading a model by file path, like /models/final_v2_REAL.pkl. Then every promotion is a code or config change, and nobody can say which version is live.
Drills
Answer fast — trust the rule.
Registering a model under an existing name, churn-model, creates what?
Which URI loads whatever version is currently live?
Version 8 is misbehaving in production. What is the fastest safe rollback?
From a registered version, how do you find the parameters that trained it?
Remember
- Name the model, number the versions, point an alias at the live one.
- Every action is "move alias X to version N".
- Trap: serving from a file path, which hides which version is live.