A tracking server gives ML experiments a shared record. Instead of relying on periodically committed parameter files and instructions for reproducing a notebook, teams can collect hyperparameters, data references, metrics, and artifacts under named experiments. Runs provide individual records that can be compared or revisited later. section 4.1 section 4.1.2
A local MLflow workflow has three parts:
- Start the server outside the notebook with `mlflow ui`; the local UI listens on port 5000. section 4.1.2
- Set the tracking URI and experiment name once in the notebook, then use `mlflow.start_run()` around work you want to record. section 4.1.2
- Log outputs to the run. For example, `mlflow.log_artifacts("categorical_variable_plots")` attaches saved exploratory plots; the run page then exposes artifacts alongside parameters and metrics. section 4.1.2
mlflow.set_tracking_uri("http://localhost:5000")
mlflow.set_experiment("income-classifier")
Use this notebook configuration to point MLflow at the local server and group subsequent runs under the `income-classifier` experiment. section 4.1.2
In training code, the same tracking approach can record input hyperparameters, train/test losses, model summaries, model signatures, and models. A run ID can also identify a model to load for validation or a warm restart. Artifact routing needs a deliberate choice: proxied access lets training code communicate only with the server, but large uploads can bottleneck there; direct storage access can perform better when training nodes have the necessary credentials. section 9.3.4
