Unit 10 · AI research · Lesson 4 of 9
Experimental controls for ML research
Step 1: Learn the ideas
- Data contamination and leakage in web-scale training data
- Test-set reuse and adaptive overfitting to benchmarks
- Tuning-matched and compute-matched baselines
- Training and inference budgets, including test-time compute
- Seeds, sources of variance and reporting spread
- Ablations: one change at a time, capacity matching and interactions
- Evaluation representation: prompt format, decoding, answer extraction, normalization
- Reproducibility: configs, versions, determinism and artifacts
Why it matters
Many published ML improvements shrink or vanish when baselines receive the same tuning budget, when more seeds are run, or when overlap between training and test data is removed. Research groups know this, so research interviews ask you to critique a results table or to design the experiment for your own idea. The shared research-methods topics cover general design and statistics; this topic covers failure modes specific to ML: contamination in huge corpora, hyperparameter search as hidden compute, seed variance, and evaluation choices that quietly change the answer.
Core ideas
Contamination and leakage. The test set must be unseen in every sense: no near-duplicates in training data, no hyperparameter or prompt tuning against it, and no future information in time-ordered data. With web-scale pretraining, benchmark items often appear verbatim or paraphrased in the corpus. Useful checks include n-gram or embedding overlap between benchmark items and training data, comparing performance on items created after the training cutoff with older items, and keeping a private held-out split. Report which checks you ran rather than saying "we deduplicated".
Baselines matched on effort. A new method tuned over dozens of configurations, compared with a baseline run once with defaults, measures tuning budget rather than method quality. Give every arm the same search space size or number of trials, the same training steps or FLOPs and the same data. Published baseline numbers from other codebases differ in preprocessing, evaluation scripts and compute; rerun baselines in your own pipeline when possible and say when you could not. Several re-evaluations, in language modeling, recommendation and metric learning, found that well-tuned older or simpler methods matched or beat newer ones.
Budgets. State training compute (tokens or FLOPs), tuning compute and inference compute. Methods that sample many candidates and pick the best, retrieve documents or use longer prompts spend test-time compute; compare them against a baseline allowed the same budget, for example best-of-n sampling from the baseline. Budget-aware reporting, such as expected best validation score as a function of the number of tuning trials, shows whether a conclusion flips between small and large budgets.
Seeds and variance. Variance comes from initialization, data order, data sampling and the hyperparameter search itself. Run several seeds per configuration, report a mean with a bootstrap or t-based interval, and pair seeds across arms so per-seed differences can be analyzed. Picking the best seed, or the best checkpoint on the test set, inflates results.
Ablations and representation choices. An ablation removes or replaces one component while holding everything else fixed, ideally including parameter count and tuning effort. Evaluation choices are part of the experiment: prompt template, few-shot examples, answer extraction, decoding temperature and metric normalization can reorder models. Fix them before looking at results, report them, and test sensitivity to the ones that plausibly matter.
Reproducibility. Store config, code commit, data version and environment with every result, log seeds and keep evaluation deterministic. Determinism helps debugging; it does not replace multiple seeds.
Common misconceptions
- "Removing exact duplicates removes contamination." Paraphrases, translations and partial overlaps remain; combine fuzzy matching with time-based held-out sets.
- "Our baseline numbers come from the original paper, so the comparison is fair." Preprocessing, evaluation code, tuning effort and compute differences can each exceed the claimed gain.
- "Overlapping ranges over three seeds show there is no effect." Range overlap is not a test; use paired differences or intervals, and remember three seeds estimate variance poorly.
- "Best-of-n with a verifier beats the baseline, so the model is better." It may only spend more inference compute; compare under an equal sampling budget.
- "An ablation that hurts shows the component works as claimed." Removal can hurt for unrelated reasons such as lost capacity or stale tuning; match capacity, retune, or test the mechanism directly.
- "Reproducible means deterministic." Bitwise repeatability on one machine is useful, but reproducibility means independent reruns reach the same conclusion within the reported variance.
How to approach it
Practise on papers: for each paper in the AI route, list its baselines, tuning budgets, seeds, contamination checks and evaluation choices, plus one experiment you would add. Then run a small audit yourself: a baseline and a variant, five or more paired seeds each, equal tuning budgets, plotted with intervals. In interviews, when asked to evaluate an idea, state the comparison, the controls and how you would notice you were fooling yourself before talking about metrics.
Suggested order
- 1Re-read "Show Your Work" and "Accounting for Variance in Machine Learning Benchmarks" from the shared research-methods topics with an ML lens: budgets and variance sources.
- 2Read "A Metric Learning Reality Check" and list each uncontrolled factor it identifies in earlier comparisons.
- 3Read "Are We Really Making Much Progress?" for reproducibility failures and tuned simple baselines.
- 4Read "Do ImageNet Classifiers Generalize to ImageNet?" for what test-set reuse does and does not do to rankings.
- 5Read the benchmark-contamination parts of the C4 documentation paper and the scikit-learn common pitfalls page; write a contamination checklist for an LLM benchmark.
- 6Read "Deep Reinforcement Learning that Matters" for seed variance and reporting recommendations.
- 7Apply your checklist to the LoRA, DPO and RAG paper guides, then run the seed-and-budget audit project.
Paper guides: LoRA: Low-Rank Adaptation of Large Language Models, Direct Preference Optimization: Your Language Model is Secretly a Reward Model, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
Step 2: Check off what you can do
Tap each one you can genuinely do or explain. Each earns 10 XP.
Step 3: Go deeper
A Metric Learning Reality CheckStart here
arXivDetailed case study of how unmatched architectures, embedding sizes and test-set feedback inflated reported gains.
Open(opens in a new tab)Link responded, 5 Oct 2026Deep Reinforcement Learning that MattersStart here
arXivSeed variance, implementation sensitivity and reporting recommendations, with lessons that transfer beyond RL.
Open(opens in a new tab)Link responded, 5 Oct 2026Are We Really Making Much Progress? A Worrying Analysis of Recent Neural Recommendation Approaches
arXivReproducibility failures and well-tuned simple baselines beating newer methods.
Open(opens in a new tab)Link responded, 5 Oct 2026Do ImageNet Classifiers Generalize to ImageNet?
arXivTest-set reuse and distribution shift from re-collected test data.
Open(opens in a new tab)Link responded, 5 Oct 2026Documenting Large Webtext Corpora: A Case Study on the Colossal Clean Crawled Corpus
arXivHow to audit a pretraining corpus, including for benchmark contamination.
Open(opens in a new tab)Link responded, 5 Oct 2026
Step 4: Practice
Before running anything, write a short plan: hypothesis, arms, tuning budget per arm, seeds, metric, decision rule. Keep seeds paired across arms, report intervals and end with one paragraph on threats to validity. Opening a paper is not practice; producing a critique or a plotted result is.
- Seed and tuning-budget audit of a two-arm comparisonOpen(opens in a new tab)Not attemptedSelf-directed project (budget-aware reporting as the method)
- Optimizer and learning-rate schedule study on a small modelOpen(opens in a new tab)Not attemptedSelf-directed project (Dive into Deep Learning code as a starting point)
Record attempts on each problem’s page (+15 XP, +10 more when solved on your own).
Step 5: Test yourself
Answer each one out loud or on paper before you finish the lesson.
- Question 1What is the difference between a tuning-matched and a compute-matched baseline?
- Question 2Why does choosing the best checkpoint on the test set inflate results, and what should you select on instead?
- Question 3Which sources of variance remain uncovered if you rerun seeds on a fixed data split?
- Question 4How can the prompt template or answer extraction change a benchmark ranking?
- Question 5When is it acceptable to reuse a published baseline number?
- Question 6What must an ablation hold fixed to isolate a mechanism?
You’re done when you can
- Critique a results table from a recent paper in 10 minutes, naming at least four specific controls that are present or missing.
- Run a two-arm comparison with at least five paired seeds and equal tuning budgets, reporting intervals.
- Describe three independent contamination checks for an LLM benchmark.
- Explain how inference-time compute can confound a comparison and how to equalize it.
- Produce a run record (config, commit, data version, seed, environment) that lets someone else rerun one of your results.
Finish the lesson
Unlocks next: Interpretability methods (optional)


