NCA-ADS - Introductory MLOps Practices (10% of the exam) - Section 6.2
Track experiments with MLflow and Weights & Biases.
Track experiments using MLflow and Weights & Biases to log hyperparameters, metrics, and artefacts for each training run. Compare runs systematically to identify the configuration that produces the best validated performance before promoting a model.
A data scientist runs 20 training jobs with different hyperparameter combinations and wants to compare their validation loss curves side by side before choosing a model for deployment. Which capability of MLflow supports this workflow directly?
ALogging model artefacts to the MLflow Model Registry so deployment-ready versions are centralised
BCalling mlflow.autolog to capture the environment and automatically pick the best-performing run without manual review
CTagging each run with a parent run ID so MLflow aggregates all child metrics into a single averaged metric entry
DUsing the MLflow Tracking UI to select multiple runs within an experiment and plot their logged metrics on a shared chartcheck_circle Correct
Identify how MLflow experiments and the Tracking UI enable comparison of metrics across multiple training runs. In MLflow, an experiment is a named container for related runs. Each run logs its own parameters, metrics and artefacts independently. The Tracking UI exposes a run-comparison view where a user can select two or more runs from the same experiment and overlay their metric histories on a single chart, making it straightforward to evaluate which hyperparameter configuration produced the best validation loss trajectory. This experiment-vs-run model is the core organisational primitive that gives MLflow its reproducibility and comparison utility.
Why A is wrong: The Model Registry stores versioned models for deployment governance, but it does not provide run-comparison views of metrics across multiple training runs.
Why B is wrong: mlflow.autolog records parameters, metrics and artefacts automatically, but it does not evaluate or select the best run; that judgement remains with the practitioner.
Why C is wrong: Parent-child run nesting organises hierarchical sweeps visually but does not average or aggregate child metrics; each run retains its own independent metric logs.
Why D is correct: MLflow groups runs under a named experiment; the Tracking UI lets you select several runs and render their logged metric histories as overlapping time-series charts, directly enabling side-by-side comparison.
Answers that look right on this material and are not. Each one is a distractor from a different question in the NCA-ADS bank for this domain.
The live system metrics panel, because it records GPU utilisation per epoch and the lowest-utilisation epoch corresponds to the best checkpoint.
errorWhy it is wrong: GPU utilisation is captured automatically and looks like useful run detail, but it has no relationship to validation loss, so it cannot identify which checkpoint performed best.
Log every job to the same single MLflow run, calling the metric-logging API once per job with a different step value for each.
errorWhy it is wrong: It is tempting because steps do let one run hold a sequence of values, but a single run cannot represent 60 independent jobs with their own parameter sets and final metrics, so per-job inspection and grouping are lost.
Log the learning rate as a metric, the per-epoch validation loss as a parameter, and the 'baseline' label as a metric.
errorWhy it is wrong: The categories are real MLflow concepts so this looks coherent, but it inverts them: a fixed configured value is a parameter and a value that changes per epoch is a metric, so the mapping is wrong.