interviewpath
  • 0day streak
  • 10total XP
  • Level 1

Focus mode

Experimental controls for ML research

Read alongside

A Metric Learning Reality Check

Detailed case study of how unmatched architectures, embedding sizes and test-set feedback inflated reported gains.

Objectives

  • Identify contamination and leakage paths (duplicates, temporal leakage, benchmark text in pretraining data, tuning on the test set) and design checks for them.
  • Construct baselines matched on tuning effort, training compute and data, and explain when reusing published baseline numbers is unfair.
  • Report results over multiple seeds with a suitable interval and decide whether a difference is distinguishable from noise.
  • Account for training and inference budgets, including test-time compute such as sampling many candidates, when comparing methods.
  • Design ablations and evaluation-representation choices that test the specific mechanism claimed rather than the whole system.
  • Make an experiment reproducible by recording seeds, configuration, data version, code version and environment with every result.

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.

Self-check before you finish

  1. What is the difference between a tuning-matched and a compute-matched baseline?
  2. Why does choosing the best checkpoint on the test set inflate results, and what should you select on instead?
  3. Which sources of variance remain uncovered if you rerun seeds on a fixed data split?
  4. How can the prompt template or answer extraction change a benchmark ranking?
  5. When is it acceptable to reuse a published baseline number?
  6. What must an ablation hold fixed to isolate a mechanism?