MLflow tracking and registry

MLflow Tracking logs parameters, code versions, metrics, and artifacts for each experiment run, with a UI to compare results. The Model Registry then manages lifecycle: versions, aliases, tags, lineage, and deployment pointers. Together they answer: what did we try, what won, and what’s in prod?

<!-- IMAGE: experiment → runs → registered model@champion -->

Without tracking, “best model” is folklore. Without a registry, rollback is archaeology. Production MLOps (Google Cloud level 2) explicitly includes experiment/metadata stores and a model registry.

1. Start a run inside an experiment.
2. Log params, metrics, and artifacts (including models).
3. Compare runs in the UI or API.
4. Register the chosen model; assign aliases like champion.
5. Deploy/load via models:/Name@champion; reassign alias to roll forward/back.

A lab notebook with dated pages (tracking) plus a locked cabinet labeled “current reagent” (registry).

Log three toy runs that differ by one parameter. Pick a winner by a metric. Write the registry alias you would point production to.

⚠️ Myth: Local mlruns/ folders are enough for a team.

✓ Reality: Fine for solo; teams need a tracking server + shared artifact store.

⚠️ Myth: Registry stages replace eval gates.

✓ Reality: Stages/aliases are pointers—your tests still decide promotion.

• MLflow Tracking: https://mlflow.org/docs/latest/ml/tracking/ ↗
• MLflow Model Registry: https://mlflow.org/docs/latest/ml/model-registry/ ↗
• Google Cloud MLOps (metadata + registry): https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning ↗