ML Workflows: Tracking, Registry, and Feature Store
MLflow tracking
Every training attempt is a run inside an experiment. You log params (hyperparameters, one value per key per run), metrics (numeric, optionally with a step for curves), tags (free text), and artifacts (files, plots, models). Use with mlflow.start_run(): so the run closes even on failure. Nested runs (nested=True) let a parent run group child runs, for example one child per hyperparameter trial, and compare them together.
Autologging
mlflow.<flavor>.autolog() captures params, metrics, and the model automatically. It must be enabled before training, is flavor-specific, and can be turned off with mlflow.autolog(disable=True).
Models, signatures, registry
mlflow.<flavor>.log_model() stores the model as an artifact under a flavor; infer_signature records the input/output schema, which reliable serving depends on. Registering a model creates a registered model with versions 1..N. Older MLflow used stages (Staging/Production); current practice is aliases such as champion, set through the MLflow client, and deployment code resolves the alias rather than a version number.
Feature Store
FeatureEngineeringClient creates feature tables, writes them with write_table, builds create_training_set with a label and lookups, and logs models with the training set for lineage. Point-in-time lookups prevent label leakage.
Rule of thumb
Params are the choices you made, metrics are what you measured, artifacts are the files. To compare runs, filter with MLflow search on metrics; never loop notebooks manually.