Benchmark Data Contamination

Benchmark data contamination occurs when test items, answers, or highly similar material appear in a model's training data. This can make a benchmark score look better without representing genuine generalization.

Contamination can arise from public benchmark datasets, scraped web pages, derivative datasets, or repeated discussions of test items. Detecting it may require exact matching, similarity analysis, provenance records, and controlled evaluation sets.

As models are trained on increasingly broad web corpora, contamination has become a central concern in interpreting benchmark claims. Transparent evaluation should disclose known risks and use fresh or protected tests where possible.

See also Data Provenance, MMLU, HELM, and Safety Evaluation.

When a question or answer appears in candidate training material, check whether the model actually trained on it, when it was collected and whether the match covers the item or only a common phrase. Inspect exact matches, reordered or paraphrased choices, explanations and translations separately. A matching string alone does not prove every model memorized the answer.

The Deng et al. investigation ↗ examines contamination risk through corpus-overlap retrieval and testset slot guessing for open and proprietary models.^[1] Read each method within its observation limits and alternative explanations. Failure to detect overlap does not prove an item was unseen. Collection dates and training-data paths help define the evidence available for judgment.

These counts are fictional. Among 200 evaluation questions, exact-match checks flag 30 and similarity checks flag 20, with ten shared items. Unique flagged items total 30 + 20 - 10 = 40. The unflagged remainder is 160, not 150. Form unions using stable item IDs and record automated flags separately from human findings.

If the model answers 170 questions correctly overall and 38 of the 40 flagged items correctly, total accuracy is 170 / 200 = 85%. Accuracy on unflagged items is (170 - 38) / 160 = 82.5%. This describes the observed subset. It neither confirms contamination of every flagged item nor makes the filtered score an unbiased capability estimate. Removing items can also change difficulty and subject composition.

Retain evaluation version, original IDs and variant/translation relationships, publication and collection dates, overlap rules and exclusion reasons. Dataset documentation clarifies why the evaluation was collected and composed. The Datasheets study ↗ proposes documenting motivation, composition, collection process and recommended uses.^[2]

A fresh private set loses independence if repeatedly used for configuration selection. Separate development data from final evaluation and define access/publication scope. Newly written questions are not automatically equivalent in difficulty or representativeness to the previous set.

For MMLU or HELM, state the investigated corpus and judgment rules rather than claiming a complete absence of contamination. If training material is private and unavailable, retain that uncertainty. High scores or matching answer wording alone do not establish contamination.

Link observed overlap and evaluation limitations through a model card, and check remaining errors on new task-specific questions. Keep automated signals, manual review and filtered evaluation distinct so the improvement is reproducible without overstating it.

Oren et al. ↗, sections 2–3, compare log probabilities of canonical and shuffled example orderings. Their false-positive control relies on assumptions including model/dataset independence under the null and exchangeability of example order.^[3] Difficulty- or time-sorted data require checking those assumptions. Black-box access is not no access: without arbitrary-sequence log probabilities, do not claim to have directly applied this test.

The paper's limitations state that reported p-values are not corrected for multiple testing and real-data exchangeability can be difficult to establish.^[3] Here is an independent teaching calculation: eight prespecified tests with family error level 0.05 under Bonferroni give 0.05/8=0.00625 per test. A p-value of 0.01 passes an individual 0.05 threshold but not this corrected threshold. Do not hide additional explored models, datasets or prompts by declaring only eight tests. A small p-value is not a contamination probability or an effect-size estimate.

This is an ORBiS Tree review ledger proposal. Record dataset version/publication, evidence for canonical ordering, accessible score types, hypotheses/test counts, transformations, negative controls and alternative explanations for non-detection. Do not merge similar answer wording with results whose test assumptions were met. Non-detection does not prove absence from training. Link data lineage, evaluation results and reporting scope, explicitly retaining what private data prevented you from checking.