Principle:Mlflow Mlflow Metric Logging
| Knowledge Sources | |
|---|---|
| Domains | ML_Ops, Experiment_Tracking |
| Last Updated | 2026-02-13 20:00 GMT |
Overview
Recording numeric performance measurements over the course of a training run to enable evaluation, comparison, and convergence monitoring.
Description
Metrics are the quantitative observations that measure how well a model performs. They are the primary output of the training process from an experiment tracking perspective: loss values, accuracy scores, F1 measures, AUC, RMSE, and any other numeric indicator that reflects model quality or training progress. Unlike parameters (which are fixed inputs), metrics are dynamic outputs that may change at every training step or evaluation checkpoint.
A distinguishing feature of metrics in experiment tracking is their temporal dimension. Metrics are not merely point-in-time values; they form time series indexed by a step counter and a timestamp. This allows practitioners to visualize training curves, detect overfitting by comparing training and validation metrics over epochs, and identify the point at which convergence occurs. The step dimension is particularly important for iterative training algorithms where the metric value at step 100 has a fundamentally different meaning than the value at step 1000.
Metric logging also supports comparison across runs. By recording the same metric keys across multiple runs with different configurations, practitioners can build comparison tables and charts that reveal which hyperparameter settings produce the best outcomes. This cross-run comparison is one of the most valuable capabilities of any experiment tracking system.
Usage
Log metrics after computing them during or after training. For iterative training, log metrics at each epoch or evaluation interval with an appropriate step value to build training curves. Log final evaluation metrics at the end of the run for summary comparison. Use batch metric logging when multiple metrics are computed simultaneously. Enable asynchronous logging in performance-sensitive training loops where blocking on network I/O is unacceptable.
Theoretical Basis
Metric logging implements a time-indexed observation record pattern:
Multi-dimensional Identity: Each metric observation is identified by a composite key: the metric name, the step number, and the timestamp. This allows the same metric name to carry multiple values over time without overwriting previous observations. The step typically corresponds to a training epoch, batch number, or evaluation iteration.
Numeric Constraint: Metric values are restricted to floating-point numbers. This constraint enables the tracking system to provide aggregation functions (min, max, mean), sorting, and chart rendering without needing to handle arbitrary data types. Special values such as positive and negative infinity may be clamped to the representable range of the backend store.
Append-Only Semantics: Unlike parameters, metrics support multiple values for the same key within a single run (distinguished by step). Each logging call appends a new observation rather than replacing the previous one. This append-only model naturally captures the training trajectory.
Model and Dataset Association: Metrics can optionally be associated with a specific model version or dataset, enabling fine-grained performance tracking across different model checkpoints and evaluation datasets within the same run.
Batch and Asynchronous Operations: Multiple metrics can be logged in a single batch call, reducing overhead. Asynchronous logging decouples the training loop from the I/O latency of the tracking backend, returning a future that the caller can optionally await.