Experiments
Every training run is recorded as an experiment: an immutable record of the parameters used, the metrics achieved, the logs produced, the artifacts created, and the exact dataset and feature set versions it consumed. An experiment produces one candidate model.
Why immutability matters
Because experiments can never be edited and are fully linked to their inputs, three things become possible that spreadsheets and notebooks never deliver:
- Compare. Put runs side by side and see which settings actually made the difference — not which ones you remember trying.
- Reproduce. Any result can be re-created, because its inputs are pinned: the same dataset version, the same feature set version, the same parameters.
- Trace. Any model in production can be walked back to the run that created it, and from there to the exact rows it learned from. When someone asks "why did the model say that?", the answer starts here.
An experiment moves through: Queued → Running → Succeeded / Failed / Cancelled.
Working with experiments in the Studio
- The Training page lists your workspace's runs; each row links to its experiment.
- An experiment's detail page shows the full record: status, parameters, metrics from the held-out data, timing, and the candidate model it produced.
- Select experiments to open the compare view — parameters and metrics in aligned columns, so a hyperparameter sweep reads as a table rather than a memory exercise.
Reading a comparison honestly
- Metrics on held-out data are the only ones that count. A model can score perfectly on data it memorized.
- Small differences are noise. Two runs that differ by a fraction of a percent are the same run wearing different seeds; prefer the simpler configuration.
- Check the inputs before crediting the settings. If two runs used different dataset versions, the data — not the hyperparameters — may be the real story. The compare view shows both, so this mistake is easy to avoid.
Next
- Where the candidate goes: Models & evaluation.