How machines learn
Experiments, Randomness, and Reproducibility
Design controlled machine-learning experiments with versioned evidence, repeated runs, uncertainty, and a clear record of what changed.
By the end you can
- Distinguish a training run from a controlled experiment
- Explain how random initialization, sampling, and data partitioning create variation
- Record the artifacts and decisions needed to reproduce a result
- Interpret gains using repeated runs, uncertainty, and predeclared comparisons
Example
The leaderboard jump that vanished the next morning
A team changed a feature pipeline and saw validation F1, a single score that combines precision and recall (higher is better), rise from 0.71 to 0.74. A rerun with a different seed returned 0.70. The old system sometimes reached 0.73.
- The original comparison used one run per configuration.
- Random initialization and batch order were not recorded.
- The feature change also altered missing-value handling.
- The validation set was small in the rare positive slice.
- No expected effect or minimum meaningful gain was written before the experiment.
- After repeated matched runs, the evidence did not support a stable improvement.
Comparison
Execution produces a number; an experiment tests a claim
A logged run can still be scientifically weak if the comparison is confounded.
A training run is one execution with a particular dataset, configuration, seed and environment. It produces artifacts and metrics, it may be useful for debugging, it can be lucky or unlucky, and on its own it does not identify a cause.
A controlled experiment is a planned comparison that changes a defined factor while holding relevant conditions stable. It starts from a hypothesis, uses comparable evidence and budget, accounts for randomness, and ends with a bounded conclusion.
Exploratory search is a third thing: many changes tried at once to discover promising directions. It is useful for ideation, it increases selection bias, it needs fresh confirmation, and it should not be reported as one preplanned test.
Training run
One execution with a particular dataset, configuration, seed, and environment.
- Produces artifacts and metrics
- May be useful for debugging
- Can be lucky or unlucky
- Does not identify a cause alone
Controlled experiment
A planned comparison that changes a defined factor while holding relevant conditions stable.
- Starts from a hypothesis
- Uses comparable evidence and budget
- Accounts for randomness
- Ends with a bounded conclusion
Exploratory search
Many changes are tried to discover promising directions.
- Useful for ideation
- Increases selection bias
- Needs fresh confirmation
- Should not be reported as one preplanned test
Visual
Why identical code can produce different results
Randomness enters through more than a single seed. Data sampling decides which examples enter a split, batch, bootstrap sample or augmentation. Initialization sets the starting parameter values and so the optimization path. Execution order covers batch order, asynchronous updates and parallel operations. Hardware and libraries contribute numerical kernels, precision and implementation versions. And the measurement sample — a finite validation or test set — creates uncertainty even for a model that never changes.
The hardware-and-library source is not folklore. The two most widely used pieces of deep-learning infrastructure say so in their own documentation. PyTorch's reproducibility note opens with the warning itself: “Completely reproducible results are not guaranteed across PyTorch releases, individual commits, or different platforms. Furthermore, results may not be reproducible between CPU and GPU executions, even when using identical seeds.”
NVIDIA's cuDNN developer guide is equally plain. Across different GPU architectures, no cuDNN routine guarantees bitwise reproducibility. Even on one architecture the guide names the exceptions: cudnnConvolutionBackwardFilter (ALGO_0 or ALGO_3), cudnnConvolutionBackwardData (ALGO_0), cudnnPoolingBackward (CUDNN_POOLING_MAX), cudnnSpatialTfSamplerBackward and cudnnCTCLoss. They are nondeterministic “because they use atomic operations in a way that introduces truly random floating point rounding errors”. Most of them are backward-pass kernels, which training calls on every step whenever they are selected. A seed cannot reach them.
Data sampling
Which examples enter a split, batch, bootstrap sample, or augmentation.
Initialization
Starting parameter values influence the optimization path.
Execution order
Batch order, asynchronous updates, and parallel operations can differ.
Hardware and libraries
Numerical kernels, precision, and implementation versions affect results.
Measurement sample
Finite validation or test sets create uncertainty even for a fixed model.
Steps
What must be captured to rerun the evidence
Reproducibility is a property of the whole experimental procedure, not only the model file. It also has a written definition rather than a house preference. The U.S. National Academies of Sciences, Engineering, and Medicine wrote it in a congressionally mandated report in 2019: “Reproducibility is obtaining consistent results using the same input data; computational steps, methods, and code; and conditions of analysis.” NISO adopted that exact definition in 2021 and turned it into four badges a publisher can award: Open Research Objects (ORO), Research Objects Reviewed (ROR), Results Reproduced (ROR-R) and Results Replicated (RER). Reproducing and replicating are separate achievements. The badge list keeps them apart.
The six steps that follow are that definition made operational. Version the question: record hypothesis, primary metric, slices and decision rule. Freeze the evidence: identify dataset snapshot, split logic, labels and feature code. Freeze the procedure: store model, hyperparameters, seed policy, budget and stopping rule. Record the environment: capture code commit, dependencies, hardware and execution settings. Preserve outputs: keep logs, curves, checkpoints, predictions and analysis artifacts. Rebuild independently: rerun from the recorded inputs and compare the result within expected variation.
NeurIPS 2019 ran that request as an experiment on a whole field. All 6,743 submissions had to answer the Machine Learning Reproducibility Checklist. The code policy told authors what was expected: “In short, we expect (but not require) accompanying code to be submitted with accepted papers that contribute and present experiments with a new algorithm.” About 40% of papers linked code at submission and 74.4% did by the camera-ready deadline, against under 50% at NeurIPS 2018. Surveyed at the end of the review period, reviewers answered yes 5,298 times when asked whether code had been provided, and 2,255 times when asked whether they had looked at it. Then 173 accepted papers were claimed for independent reproduction by participants at 73 institutions, producing 84 reviewed reports. Eight authors published the tally in 2021. The written request coincided with a sharp rise in shared code.
1. Version the question
Record hypothesis, primary metric, slices, and decision rule.
2. Freeze the evidence
Identify dataset snapshot, split logic, labels, and feature code.
3. Freeze the procedure
Store model, hyperparameters, seed policy, budget, and stopping rule.
4. Record the environment
Capture code commit, dependencies, hardware, and execution settings.
5. Preserve outputs
Keep logs, curves, checkpoints, predictions, and analysis artifacts.
6. Rebuild independently
Rerun from recorded inputs and compare the result within expected variation.
Key idea
Fixing one seed is useful but insufficient
A fixed seed helps reproduce one execution. It can also conceal instability by making every comparison depend on one favorable random path.
Ten runs of one configuration can disagree with themselves. Six researchers showed it in 2018: ten TRPO trials on HalfCheetah-v1, identical hyperparameters, only the random seed varying. Then they split the ten arbitrarily into two groups of five and averaged each group. The two averages — of the same algorithm, the same hyperparameters, the same task — differed at t = -9.0916, p = 0.0016. A configuration had come out statistically significantly better than itself. The only thing that decided the winner was which seeds landed in which group. Henderson and his co-authors state it directly: “it is possible to get learning curves that do not fall within the same distribution at all, just by averaging different runs with the same hyperparameters, but different random seeds”.
An independent team reached the same conclusion for the few-run regime three years later, in a NeurIPS 2021 Outstanding Paper, across Atari 100k, ALE, Procgen and DeepMind Control Suite.
Use fixed paired seeds for controlled comparisons, then repeat across several seeds when randomness materially affects conclusions, and report central tendency and variation rather than only the best run.
Reproducibility asks whether the procedure is stable and recoverable, not whether one random trajectory can be replayed.
Example
The lucky run, rerun on five paired seeds
The five F1 scores per system below are invented, though they include the figures the opening reported: the team from the start of this lesson reruns its comparison properly.
- One change at a time. The new pipeline had also changed how missing values were handled. That part is restored to the old behaviour, so only the feature change is tested.
- Five paired seeds. Both systems are trained with the same five seeds, the same split and the same evaluation code. Old system: 0.71, 0.73, 0.70, 0.72, 0.71, average 0.714. New system: 0.74, 0.70, 0.71, 0.72, 0.72, average 0.718.
- Differences, seed by seed. +0.03, −0.03, +0.01, 0.00, +0.01. The average gain is +0.004. Between seeds, the gain swings by 0.03 in either direction.
- The verdict. Five pairs cannot tell a gain of 0.004 from none. This is not evidence that the change helped, and not proof that it did nothing. The first comparison, 0.71 against 0.74, looks like the new system’s luckiest run set beside an ordinary run of the old one.
- The decision. The template at the end of this lesson asks for a minimum meaningful effect written in advance. If the team had set it at 0.02, the change is not adopted. If 0.004 would matter, the team needs many more seeds and a larger slice of rare positives before deciding.
The jump from 0.71 to 0.74 was one seed against another. Paired and repeated, the gain was 0.004, inside the noise.
Case
Ten thousand seeds, and a spread wider than most published gains
Somebody ran the scan nobody runs. Train a ResNet-9 on CIFAR-10 under one fixed short schedule, change nothing but the random seed, and sweep the first 10,000 of them. David Picard did exactly that in 2021, and published the result. He reports that “the minimum and maximum accuracy among all run (obtained at the end of training) … go from 89.01% to 90.83%, that is, a 1.82% difference”. On ImageNet, starting from pretrained models, “we found a difference between the maximum and the minimum accuracy of around 0.5%, which is commonly accepted as significant by the community for this dataset”. Both margins fall inside the range that computer-vision venues routinely accept as evidence of an improvement. One lucky seed can therefore manufacture a publishable result. One unlucky seed can bury a real one.
FigureInteractive
A range strip on an accuracy window from 88.5 to 91.5 per cent, showing the span of final CIFAR-10 accuracy across the first 10,000 random seeds under one fixed short schedule: the worst seed gives 89.01 per cent and the best 90.83, a spread of 1.82 points. It is drawn as a range on a windowed axis rather than as a bar rising from zero, because both numbers are accuracies near ninety. Below, three spreads on a zero-based axis in percentage points: 1.82 for the CIFAR-10 seed scan, one point of F1 for two named-entity systems drawn from an evaluation of 50,000 LSTM networks on five sequence-tagging tasks, and around 0.5 on ImageNet from pretrained weights. The CIFAR-10 spread is 3.64 times the ImageNet one and 1.82 times the named-entity one, both derived, and the seed-driven differences reached p below 0.0001; modelling the whole benchmarking process instead reached a comparable estimator at a 51 times reduction in compute cost.
Model variation and evaluation uncertainty are different
Repeated training runs estimate variation caused by fitting randomness. Confidence intervals or resampling over held-out examples estimate uncertainty from the finite evaluation sample. A project may face both.
The second source is easy to confuse with a third: a change in what is being sampled. For ICML 2019, Recht and three co-authors rebuilt the CIFAR-10 and ImageNet test sets by repeating the original collection protocol, then re-measured fixed, already-trained models on the new samples. Every model lost accuracy. Their introduction: “The accuracy drops range from 3% to 15% on CIFAR-10 and 11% to 14% on ImageNet. On ImageNet, the accuracy loss amounts to approximately five years of progress in a highly active period of machine learning research.” No model changed. Only the sample it was judged on changed. Model rankings were almost exactly preserved, which is why adaptivity to the old test set was not the explanation; the authors pointed instead to new images slightly “harder” than the originals — a shift in the sample, not the finite-sample error that confidence intervals describe.
Then the measurement itself was audited. An independent group at MIT and Berkeley corrected statistical bias in the replication procedure and found that only 3.6% ± 1.5% of the original 11.7% ± 1.0% ImageNet drop remained unaccounted for. Even the measured drop had to be re-measured.
When data contains groups or time dependence, ordinary independent resampling can be misleading. The resampling unit should respect users, sites, sessions, or periods.
Bouthillier and sixteen co-authors modelled the whole benchmarking pipeline for MLSys 2021. They found that “variance due to data sampling, parameter initialization and hyperparameter choice impact markedly the results”. Their recommendation runs against instinct. Instead of freezing everything except the factor under test, randomise more of it. Holding the extra sources fixed narrows the spread you measure without making the estimate any more honest. The paper reports that “adding more sources of variation to an imperfect estimator approaches better the ideal estimator at a 51 times reduction in compute cost”. They then measured the error rate of detecting improvements “on five different deep-learning tasks/architectures”, before turning any of it into advice. The two pieces of advice in this lesson answer different questions: pairing the seeds of two systems removes noise from the comparison between them, while randomising more sources gives an honest estimate of how far any one result could move.
Analogy
An analogy: a laboratory notebook with sealed samples
A material is tested, and the recipe, instruments, sample batch, temperature, and acceptance rule all go into the notebook; without those details, another laboratory cannot tell whether a different result comes from the material or the procedure.
Machine-learning experiments require the same traceability. Models are sensitive to high-dimensional data selection and to software nondeterminism, neither of which an ordinary laboratory control covers.
Key idea
Trying many ideas makes one winner easier to find by chance
If a team evaluates hundreds of configurations and reports only the best validation score, some apparent gain may reflect noise. The more often evidence guides choices, the less independent it becomes.
The rebuilt CIFAR-10 and ImageNet test sets make a different point, since their authors found the ranking of models almost unchanged rather than lucky winners: a leaderboard number is not a property of the model alone but of the model and the particular sample it was scored on, which is why every model moved when the sample was rebuilt.
Exploration is legitimate. Confirm the selected idea on fresh data or a predeclared comparison and report the search process honestly.
A result discovered through broad search needs stronger confirmation than a result from one planned comparison.
Case
50,000 LSTMs: one point of F1, decided by the seed
One percentage point of F1 can live entirely inside the seed. Nils Reimers and Iryna Gurevych found it by brute force in 2017, basing their recommendations on “the evaluation of 50.000 LSTM-networks for five sequence tagging tasks”. Their finding is that “the seed value for the random number generator can result in statistically significant (p < 10^-4) differences for state-of-the-art systems”. For two contemporary named-entity-recognition systems they observed “an absolute difference of one percentage point F1-score depending on the selected seed value, making these systems perceived either as state-of-the-art or mediocre”. Their proposal was not to run fewer experiments. It was to publish the distribution rather than the winner.
Example
Write the conclusion before seeing the result—then fill in the evidence
A concise experiment record reduces retrospective storytelling. Declaring the hypothesis, the metric and the decision rule before the result is visible has a measurable price, and another field has already paid it in public.
Large cardiovascular trials stopped finding what they used to find. Kaplan and Irvin reviewed all 55 large NHLBI-funded cardiovascular randomized trials from 1970-2012 with direct costs over $500,000 a year, and published the count in 2015. Their Results section: “17 of 30 studies (57%) published prior to 2000 showed a significant benefit of intervention on the primary outcome in comparison to only 2 among the 25 (8%) trials published after 2000” (chi-square = 12.2, df = 1, p = 0.0005). Of the variables they examined, one tracked the shift: pre-registration on ClinicalTrials.gov, which requires the outcome to be declared before the data are seen. It was strongly associated with the trend toward null findings. Industry co-sponsorship was not. The authors' own conclusion is careful: prospective declaration of outcomes “may have contributed” to that trend.
If predeclaration is the reason, it did not make the interventions worse. It removed the room to choose a positive outcome after the fact. A template like the one below is the same instrument at project scale.
- Hypothesis: which mechanism should improve which error pattern and why.
- Controlled change: the exact feature, model, data, loss, or policy modification.
- Constants: split, budget, preprocessing, evaluation code, and paired seeds.
- Primary evidence: metric, slice, confidence method, and minimum meaningful effect.
- Secondary checks: latency, calibration, fairness, resource use, and new failure modes.
- Decision: adopt, reject, rerun, narrow the claim, or collect more evidence.
Key takeaways
- A training run produces an outcome; a controlled experiment tests a specific claim under comparable conditions — ten TRPO runs of one configuration, split into two groups of five, differed at t = -9.0916, p = 0.0016.
- Random variation can arise from data sampling, initialization, execution order, hardware, libraries, and finite evaluation samples; PyTorch and cuDNN both state in their own documentation that bit-identical results are not guaranteed.
- Reproducibility has a written definition — the National Academies' 2019 formulation, adopted by NISO in 2021 — and requires versioning the question, evidence, procedure, environment, and outputs.
- Fixed seeds help replay and paired comparison, while repeated seeds reveal instability: 10,000 seeds on CIFAR-10 spanned 89.01% to 90.83%, and 50,000 LSTMs put one point of F1 inside the seed.
- Exploratory search increases selection bias and should be followed by fresh confirmation; predeclaring the primary outcome coincided with positive findings in large NHLBI trials falling from 57% to 8%.
- Conclusions should report central tendency, variation, minimum meaningful effects, and operational side effects rather than a single best score — a rebuilt test set cost fixed ImageNet models 11% to 14% without changing a weight, and most of that drop was later traced to statistical bias in the rebuild itself.