9. Model Registry

Duration45min
Learning Objectives

Apply:
[BC07] multiple model versions managed so that production code always points reliably at the current one, without hardcoding which version that is
[BC04] test-driven development to build a reusable model-registration tool

Analyze:
[BC07] comparing two candidate models on the same evidence to decide which one deserves to be promoted

Prerequisites

Introduction

Modules 6 and 7 gave you logged runs and a real Pipeline worth reusing — but neither tells calling code which logged version to actually use. Today that would mean hardcoding a run ID or a version number, and changing it by hand every time a better model comes along. This module adds the missing piece: a name calling code can always ask for (“give me the current model”), that you can repoint to a different version whenever you want, without touching any code that loads it.

Notebook

Files: notebooks/session3/09_model_registry.ipynb

Open it and select the same .venv kernel as your other notebooks. It is short and entirely self-contained — two unrelated toy models, no air_quality code needed until the “Now do it for real” section. Work through the cells in order:

  1. Register two toy models as two versions of the same registered model name
  2. See why MLflow’s old stage system is deprecated, and what replaces it: an alias
  3. Set an alias on one version, then load a model purely by name and alias — no run ID, no version number
  4. Move the alias to the other version, reload with the exact same call, and confirm the loaded model changed
  5. Once scripts/register_champion.py has been run (see Implementation below), load the champion it promoted with air_quality.registry.load_champion("air_quality_model")

Implementation

Files: src/air_quality/registry.py, scripts/register_champion.py

  • Open src/air_quality/registry.py — register_pipeline, promote_to_champion and load_champion are already scaffolded, each wrapping exactly the calls you just made by hand in the notebook. Run uv run pytest tests/test_registry.py -v until it passes.
  • Complete the TODO in scripts/register_champion.py: rebuild Module 7’s chained Pipeline (AirQualityCleaner + RFE + a model) twice — once with LinearRegression, once with Ridge — register both as versions of air_quality_model, and promote whichever scores better on cross_val_score to champion. Run it with uv run python scripts/register_champion.py.

Reflection

Files: reflection/session_3/module_9.md

Details

Question:

  1. Which model ended up as champion in your own run, LinearRegression or Ridge? Does that match what you found in Module 7’s own reflection question?
  2. If the code that loads this model for predictions hardcoded models:/air_quality_model/2 — a fixed version number — instead of models:/air_quality_model@champion, what would break the next time a better model is registered? What does the alias indirection buy you that a version number alone does not?