A training run is one execution of model training, recorded as a connected set of inputs, environment details, outputs, and metrics. Capturing a run makes model results reproducible, comparable, and easier to troubleshoot rather than treating a trained model file as an isolated artifact. section 8.2.1 section 8.2.2
Record a run with enough information to recreate and assess it:
- Dataset identity and version, so the training input is unambiguous. section 8.2.1
- Hyperparameters, including learning rate and epoch count. section 8.2.1
- Training-code version and execution-environment configuration, such as conda.yml, Dockerfile, or requirements.txt. section 8.2.1
- Allocated and consumed CPU, GPU, TPU, memory, and disk resources. section 8.2.1
- Training-progress metrics and evaluation metrics, such as epoch loss, F-score, or RMSE. section 8.2.1
Store run metadata centrally and link it to models, pipelines, and artifacts. These relationships let a user start from a model or run, retrieve its parameters, datasets, and metrics, and determine model lineage without understanding the underlying training or serving infrastructure. section 8.2.2 section 8.3.2
Comparing past runs
A data scientist lists models and training runs, opens a past run, and retrieves its input parameters, dataset, and training metrics to evaluate the model. A metadata UI can also visualize performance metrics and differences across runs. section 8.2.2 section 8.3.2
This reference architecture shows a client SDK sending metadata from workflow components to a server that aggregates, stores, queries, and visualizes run-linked information. section 8.3.2
