MLflow for Experiment Tracking
The 2026 Skills Guide

ML development is fundamentally experimental. Training a model involves dozens of decisions — hyperparameters, data preprocessing steps, feature engineering choices, architecture variants — each of which affects model quality in ways that are often non-obvious. Without systematic tracking, it is impossible to answer basic questions: which configuration produced the best model? What was different between the model we deployed last month and the one we're deploying now? Why did model quality drop when we changed the training data pipeline?

MLflow solves this by providing a structured store for every experiment run: the code version, environment, input parameters, output metrics, and the trained model artifact — all linked together and searchable. This transforms ML development from ad hoc experimentation into a reproducible, auditable engineering process.

MLflow Tracking organises runs into experiments (typically one experiment per model or project). Within a run:

• mlflow.log_param(key, value) — Log a single hyperparameter (learning rate, batch size, model architecture). Parameters are fixed values that describe the run configuration; they don't change during training.
• mlflow.log_metric(key, value, step=None) — Log a numeric metric, optionally at a specific training step. Metrics are time-series: calling log_metric with step allows tracking train_loss and val_loss curves across epochs. The MLflow UI plots these as interactive charts.
• mlflow.log_artifact(local_path) — Log a file (confusion matrix image, feature importance plot, evaluation CSV) to the artifact store.
• mlflow.log_dict(dictionary, artifact_file) — Log a Python dict as a JSON file. Useful for logging classification reports or nested config objects.
• Context manager pattern — with mlflow.start_run() as run: automatically ends the run even if an exception occurs. run.info.run_id gives the run ID for later reference.

Tags are free-form string key-value pairs stored with a run. Useful for: git commit SHA, developer name, data version, environment (dev/staging/prod), and any categorical metadata that isn't a hyperparameter.

Autologging — mlflow.sklearn.autolog(), mlflow.pytorch.autolog(), mlflow.transformers.autolog() automatically capture hyperparameters, metrics, and models from supported frameworks without explicit log calls. Enable at the start of your script before training. This is the recommended approach for standard workflows.

The Model Registry provides a centralised store for managing the lifecycle of models across development, staging, and production environments. It addresses the operational question: how do we know which model is deployed in production, who approved it, and what training run produced it?

Model lifecycle stages:

• None → A model version exists in the registry but has not been formally assigned a deployment stage.
• Staging → The model is being evaluated for production deployment. In most teams, this triggers automated integration tests, comparison against the current production model, and human review.
• Production → The model is actively serving in production. A new version moves to Production only after review; the previous Production version is automatically archived.
• Archived → The model is no longer in active use but its lineage is preserved for audit purposes.

Aliases (introduced in MLflow 2.x) provide a more flexible alternative to stages: assign named aliases (e.g., champion, challenger) to specific model versions. This decouples deployment semantics from fixed stage names and supports more complex deployment patterns like A/B testing.

Model flavors define how a model can be loaded and served. A model may have multiple flavors — e.g., a scikit-learn model has sklearn (load as an sklearn estimator) and python_function (load as a generic callable) flavors. MLflow's model serving infrastructure uses the python_function flavor by default, making it framework-agnostic.