# Test Set

> Source: https://aiwiki.ai/wiki/test_set
> Updated: 2026-07-30
> Fact-checked: 2026-07-30
> Categories: Machine Learning, Model Evaluation
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "Test Set." aiwiki.ai, 30 Jul 2026. https://aiwiki.ai/wiki/test_set
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

A **test set** is a collection of examples reserved from model fitting and model selection so that it can evaluate a fixed [machine learning](https://aiwiki.ai/wiki/machine_learning) model or a fully specified learning procedure. In the familiar three-way split for [supervised learning](https://aiwiki.ai/wiki/supervised_learning), the [training set](https://aiwiki.ai/wiki/training_set) fits parameters, the [validation set](https://aiwiki.ai/wiki/validation_set) guides choices such as architecture and [hyperparameter](https://aiwiki.ai/wiki/hyperparameter) values, and the test set measures performance after those choices have been fixed [1].

A test score is not automatically an unbiased forecast of real-world performance. It estimates performance for the population, sampling process, labels, metric, and evaluation protocol represented by that test set. The estimate is credible only to the extent that the test data are independent of development, sufficiently representative and large, and free of leakage or damaging label errors. Once test feedback changes the model or workflow, the set has become part of development and a fresh assessment is needed [1][2].

## Role in model development

### Training, validation, and testing

The three partitions differ by what decisions they are allowed to influence:

| Partition | Primary role | May influence model development? | Typical uses |
|---|---|---:|---|
| Training set | Fit learned parameters | Yes | Weights, coefficients, representations, and training-time preprocessing |
| Validation set | Compare candidates during development | Yes | Architecture, features, regularization, early stopping, thresholds, and other model choices |
| Test set | Assess a frozen model or procedure | No | Final metrics, uncertainty estimates, subgroup analysis, and error characterization defined in advance |

The important boundary is procedural, not merely a filename. If a practitioner inspects test errors, changes features, adjusts a threshold, rewrites a prompt, or chooses between models based on the resulting score, that test set has served as validation data. Conversely, a final model may be refit on the combined training and validation data after the selection rule is fixed, then evaluated on an untouched test set. The test result then applies to that refitted model and its declared pipeline [1][2].

In standard statistical learning notation, a fixed model \(f\), loss \(L\), and target distribution \(P\) have risk

$$
R_P(f) = E_{(X,Y) \sim P}[L(f(X),Y)].
$$

For \(n\) independent test examples sampled from \(P\), the mean test loss

$$
\hat{R}_{test}(f) = \frac{1}{n}\sum_{i=1}^{n}L(f(x_i),y_i)
$$

estimates that risk. This statement is conditional on the model being fixed independently of the test observations. It does not make the estimate valid for a different population, a later time period, corrupted labels, dependent rows, or a model chosen after looking at test results.

### What a test score does and does not estimate

A single test score usually estimates the performance of one trained model on one target distribution. It does not by itself establish:

- performance after the deployment population changes;
- expected performance across retraining runs;
- reliability for a rare subgroup with few test examples;
- causal effects or safety in conditions absent from the test data;
- that the selected metric captures every consequential failure.

A high test score and a large training-to-test gap can be useful diagnostic evidence. Strong training performance with weak held-out performance is consistent with [overfitting](https://aiwiki.ai/wiki/overfitting), while weak performance on both may be consistent with [underfitting](https://aiwiki.ai/wiki/underfitting). These patterns are not complete diagnoses, because distribution shift, label problems, or a mismatched metric can produce similar observations.

## Designing a test set

### Start with the target population

Test-set construction begins by specifying the claim the evaluation is meant to support. That specification should identify the prediction task, target population, time horizon, evaluation unit, outcome definition, and conditions under which predictions will be made. A random split from one pooled dataset is appropriate only when those examples are exchangeable enough for the intended claim and the future setting resembles the source data.

The evaluation unit is especially important. Ten images from one patient are not necessarily ten independent patients, and many transactions from one account are not independent accounts. If deployment will encounter new patients, users, documents, devices, or sites, all records from one such unit should generally remain in the same partition. Leakage research has documented how inappropriate splitting, preprocessing, and feature construction can produce overly optimistic results across scientific applications [3].

### Choose a split that matches deployment

| Data structure or deployment question | Suitable test design | Main failure prevented |
|---|---|---|
| Independent examples from a stable source | Random holdout | Accidental imbalance from an arbitrary manual split |
| Rare or imbalanced classes | Stratified holdout, with enough cases per reported class | Empty or imprecise class-specific estimates |
| Repeated measurements or related entities | Grouped split by the independent entity | Identity and near-duplicate leakage |
| Forecasting or changing systems | Test on later periods than training | Learning from future information |
| Geographic, institutional, or device transfer | Hold out entire sites or domains | Claiming transfer from an in-source random split |
| Spatially autocorrelated observations | Spatial blocks or buffered separation | Nearby train and test rows sharing local structure |

Stratified sampling preserves chosen class proportions across partitions, but it does not solve leakage or distribution shift. If the test set deliberately oversamples rare outcomes, aggregate metrics may need weights to represent deployment prevalence, while class-specific metrics can be reported directly.

For a [time series](https://aiwiki.ai/wiki/time_series), random shuffling can place future observations in training and earlier observations in testing. For spatial, temporal, hierarchical, or phylogenetically structured data, ordinary random cross-validation can substantially underestimate prediction error when dependence crosses fold boundaries. The separation distance or time horizon should reflect how far the deployed model must extrapolate [4].

### Split before learning from the data

The split should be established before any operation that learns from the full dataset. The following steps belong inside the development data or inside each resampling fold:

- imputation and normalization;
- vocabulary building and token filtering;
- feature selection and dimensionality reduction;
- target encoding and supervised representation learning;
- oversampling, undersampling, or synthetic example generation;
- duplicate removal rules whose decisions depend on labels or model outputs.

The fitted transformation is then applied unchanged to the test data. Deduplication also needs entity-aware rules: exact or near-duplicate content across partitions can allow memorization even when row identifiers differ. Kapoor and Narayanan define leakage broadly as a spurious relationship between inputs and labels created by the sampling and preprocessing strategy, and report documented leakage in at least 294 studies across 17 fields [3].

### How large should the test set be?

There is no universal 70/15/15 split, 10 percent test fraction, or minimum count that works across tasks. The absolute number and composition of test units matter more than the percentage alone. Test size should be chosen for the desired precision of the primary metrics and important subgroup estimates, subject to the amount of development data the model needs. External-validation guidance likewise recommends calculations tailored to the model, setting, outcome prevalence, and desired confidence-interval width instead of a single rule of thumb [5].

For illustration, if \(n\) independent test cases each produce a correct or incorrect classification and accuracy is the prespecified metric, a rough standard error is

$$
SE(\hat{p}) \approx \sqrt{\frac{\hat{p}(1-\hat{p})}{n}}.
$$

This approximation shows why uncertainty shrinks with the square root of the number of independent cases, not with the test percentage. It can be misleading for small samples or accuracies near zero or one. Brown, Cai, and DasGupta found poor coverage for the familiar Wald interval and recommended better-behaved alternatives such as Wilson or Jeffreys intervals in relevant settings [6]. Clustered observations require cluster-aware uncertainty estimates, and rare-class metrics require enough positive and negative examples for their own precision targets.

## Keeping evaluation independent

### Leakage pathways

Test independence can be broken without explicitly training on the test labels:

| Leakage pathway | Example | Prevention |
|---|---|---|
| Direct use | Test examples or labels enter training | Enforce split-level access controls and provenance |
| Preprocessing | Scaling or imputation is fitted on all rows | Fit transformations only on development data |
| Selection | The best model is chosen by test score | Select on validation data or inner resampling |
| Entity overlap | One patient, user, or document appears in multiple splits | Split by the independent entity and deduplicate |
| Temporal leakage | Future information predicts the past | Reproduce the real prediction cutoff |
| Target leakage | A feature is created after or because of the outcome | Audit feature availability at prediction time |
| Human feedback | Test errors inspire data or prompt changes | Record every evaluation and retire compromised sets |

Preventing leakage is a property of the complete pipeline, including data collection, feature engineering, prompt templates, retrieval corpora, post-processing, thresholding, and human review. A reproducible split seed is useful, but it cannot repair a split made at the wrong unit or against the wrong target population.

### Cross-validation and nested assessment

When data are scarce, [cross-validation](https://aiwiki.ai/wiki/cross-validation) can use observations more efficiently than reserving a large permanent holdout. Each fold is held out from the fit that predicts it. However, ordinary cross-validation becomes optimistic if the same fold results are used both to choose a model and to report its expected performance.

Nested cross-validation separates these roles. Inner folds select hyperparameters or algorithms, while outer folds assess the entire selection procedure. Varma and Simon demonstrated substantial bias when cross-validation error was reported after using the same cross-validation results for model selection; nested cross-validation reduced that bias in their experiments [7]. Cawley and Talbot likewise showed that variance in a model-selection criterion can itself be overfit, so evaluating only the fitted parameters while ignoring the selection procedure can favor an inferior algorithm [2].

An outer-fold estimate evaluates a learning procedure that includes tuning. It is not the performance of one immutable final model, because a different model is fitted in each outer fold. After assessment, a model can be trained on all available development data using the fixed procedure. A genuinely external or later test set may still be needed when the deployment claim extends beyond the dataset used for resampling.

### Reuse and adaptive feedback

"Use the test set once" is a useful discipline, but the underlying rule is more precise: no information derived from the test set should change the system whose performance it is meant to estimate. Recomputing prespecified metrics from stored predictions does not create new model feedback. Changing the model after seeing any result does.

This distinction becomes difficult on public leaderboards. Even if labels remain hidden, scores reveal information. Blum and Hardt showed that adaptive leaderboard submissions can overfit a holdout and proposed the Ladder mechanism, which limits the feedback released for non-improving submissions [8]. Dwork and colleagues formalized how adaptively chosen statistical queries can break ordinary holdout guarantees and introduced reusable-holdout methods that add carefully controlled disclosure [9].

Practical controls include submission limits, delayed or coarse feedback, private final test sets, prespecified analysis plans, and periodically refreshed evaluation data. A benchmark score can still be useful after repeated use, but it should no longer be described as if it came from an untouched final exam.

## Interpreting and reporting results

### Metrics must match the decision

Metrics should be selected before test evaluation and should correspond to the deployment objective and error costs. Typical choices include:

| Task | Example metrics | Important qualification |
|---|---|---|
| Classification | [Accuracy](https://aiwiki.ai/wiki/accuracy), [precision](https://aiwiki.ai/wiki/precision), [recall](https://aiwiki.ai/wiki/recall), [F1 score](https://aiwiki.ai/wiki/f1_score), area under an ROC curve | Class prevalence, threshold, and error costs can change the interpretation |
| Regression | [Mean squared error](https://aiwiki.ai/wiki/mean_squared_error_mse), [mean absolute error](https://aiwiki.ai/wiki/mean_absolute_error_mae), calibration | Large errors affect squared loss more strongly than absolute loss |
| Ranking or retrieval | NDCG, mean average precision, recall at \(k\) | The candidate pool and relevance judgments define the task |
| Generation | Exact match, task-specific execution tests, BLEU, ROUGE, or human ratings | Prompting, decoding, judge design, and reference quality are part of the protocol |

Reporting several complementary metrics can expose tradeoffs, but choosing the most favorable metric after seeing the test results is another form of selection. Thresholds, subgroup definitions, prompt templates, decoding parameters, and stopping rules should be frozen with the primary model.

### Two distinct sources of uncertainty

A reported number can vary because the finite test sample differs from the target population and because training itself is stochastic. These are different questions:

- **Test-sample uncertainty** asks how the metric would change with another sample of independent test units from the same target population.
- **Training uncertainty** asks how performance would change if the learning pipeline were rerun with different sampled training data, initialization, augmentation, or optimization randomness.

A confidence interval from one fixed test set addresses the first source under its sampling assumptions. A standard deviation across random seeds on that same test set addresses part of the second, but repeated predictions on identical test cases are not fresh test samples. Bouthillier and colleagues found that data sampling, initialization, and hyperparameter choices can all materially affect benchmark comparisons and argued for accounting for the full experimental pipeline [10].

Comparisons between two models evaluated on the same test cases should preserve that pairing in a paired test or paired resampling procedure. If observations are clustered by user, site, or time block, the resampling unit should be the independent cluster. Reports should state the number of test units, metric definitions, uncertainty method, number of training runs, and whether test feedback influenced any decision.

### Distribution shift and external tests

An in-distribution test set supports a claim only about conditions represented by that distribution. Real deployments can differ by time, location, device, institution, language, user group, or label prevalence. The [distribution shift](https://aiwiki.ai/wiki/distribution_shift) matters even when the internal test was constructed correctly.

The WILDS benchmark assembled ten datasets with real distribution shifts across domains including hospitals, camera traps, poverty mapping, toxic-comment subpopulations, and molecular scaffolds. Its baseline experiments found substantially lower out-of-distribution than in-distribution performance in most cases [11]. This illustrates why one clean random holdout cannot substitute for tests targeted at anticipated shifts.

A robust evaluation may therefore include several named sets: an internal random test for same-source performance, temporal or geographic tests for specified shifts, stress tests for known hazards, and an external test collected independently. Results from these sets answer different questions and should not be silently averaged into one universal score.

## Benchmark test sets

Shared benchmarks make model comparisons reproducible, but their split names and access rules differ:

| Benchmark | Test-set arrangement | Interpretive point |
|---|---|---|
| [ImageNet](https://aiwiki.ai/wiki/imagenet) ILSVRC classification | The challenge paper lists 1,281,167 training images, 50,000 validation images, and 100,000 test images across 1,000 classes for ILSVRC 2012-2014 [12] | The widely reported 50,000-image split is the validation set, not the test set |
| [GLUE benchmark](https://aiwiki.ai/wiki/glue_benchmark) | Nine language-understanding tasks; the paper states that four use private test data and submissions are scored through an evaluation platform [13] | A server can hide labels while exposing aggregate feedback |
| [LiveBench](https://aiwiki.ai/wiki/livebench) | Questions are added and updated monthly, with automatic scoring against objective ground truth [14] | The authors describe it as contamination-limited, not guaranteed contamination-free |

Benchmark labels and examples also need auditing. Northcutt, Athalye, and Mueller examined ten widely used vision, language, and audio test sets and estimated at least 3.3 percent label errors on average; their lower-bound estimate for the ImageNet validation set was at least 6 percent [15]. Model rankings on the studied benchmarks were unchanged after the identified errors were removed or corrected, but controlled analyses in the same study showed that the preferred model could change as the prevalence of mislabeled examples increased. A precise leaderboard therefore does not imply a perfectly measured construct.

Recht and colleagues constructed new CIFAR-10 and ImageNet test sets using the original collection procedures. They observed accuracy drops of 3 to 15 percentage points on CIFAR-10 and 11 to 14 points on ImageNet, while model rankings remained largely stable [16]. Their analysis attributed the gaps mainly to the new samples being somewhat harder and found little evidence that adaptive reuse caused the drop. A replication gap therefore does not, by itself, prove leaderboard overfitting.

## Test-set contamination in large language models

For a [large language model](https://aiwiki.ai/wiki/large_language_model), benchmark contamination commonly means that evaluation examples or close answer-bearing variants occur in pretraining, instruction tuning, retrieval data, or other development corpora. Because web-scale training data may be incompletely disclosed, absence of detected overlap is not proof of absence.

Detection methods answer different questions. Exact or fuzzy text search tests for observable overlap in accessible corpora. Sequence-likelihood and ordering tests look for behavioral evidence that a model has unusual familiarity with a benchmark. Performance comparisons between suspected and cleaner subsets test whether detected overlap is associated with a score change. None of these alone establishes a universal contamination rate.

Li and colleagues searched public corpora for overlaps with six language-model benchmarks and reported benchmark-level contamination estimates ranging from about 1 percent to 45.8 percent under their method [17]. They also found that measured performance effects varied by dataset, so overlap did not produce the same score inflation everywhere. Those figures describe that study's corpora, benchmarks, and detection rule, not all models or all test sets.

Mitigations include private evaluation sets, documented corpus filtering, delayed release, newly collected time-sensitive tasks, and rotating question pools [13][14][17]. LiveBench draws questions from recently released sources, updates them monthly, and uses objective automatic scoring to reduce both contamination exposure and judge subjectivity [14]. Its peer-reviewed title uses the deliberately narrower phrase "contamination-limited," reflecting that dynamic construction reduces risk rather than proving perfect independence.

## Practical workflow

| Stage | Safeguard |
|---|---|
| Define | State the target population, prediction time, evaluation unit, labels, primary metrics, and required precision |
| Partition | Split at the independent entity and preserve temporal, spatial, or domain boundaries relevant to deployment |
| Develop | Fit every learned transformation and make every model choice without test information |
| Freeze | Record the model artifact, code, threshold, prompt, decoding settings, and analysis plan |
| Evaluate | Run the frozen pipeline, save per-example predictions, and log who accessed the results |
| Quantify | Report sample and training variability with methods that respect pairing and clustering |
| Diagnose | Examine prespecified subgroups and failure categories without presenting follow-up changes as test-validated |
| Refresh | Replace or supplement a set when feedback, contamination, label drift, or deployment shift compromises its claim |

A school-exam analogy captures the basic separation. Training data are study problems, validation data are practice exams used to change how one studies, and test data are the final exam. The analogy has limits: a real test score is trustworthy only if the exam covers the material and students the claim concerns, is scored correctly, contains enough questions, and is not reused to coach the next attempt.

## See also

- [Generalization](https://aiwiki.ai/wiki/generalization)
- [Benchmark](https://aiwiki.ai/wiki/benchmark)
- [CIFAR-10](https://aiwiki.ai/wiki/cifar_10)

## References

1. Goodfellow, I., Bengio, Y., and Courville, A. (2016). "Machine Learning Basics." In Deep Learning, Chapter 5. https://www.deeplearningbook.org/contents/ml.html
2. Cawley, G. C., and Talbot, N. L. C. (2010). "On Over-fitting in Model Selection and Subsequent Selection Bias in Performance Evaluation." Journal of Machine Learning Research, 11, 2079-2107. https://www.jmlr.org/papers/v11/cawley10a.html
3. Kapoor, S., and Narayanan, A. (2023). "Leakage and the Reproducibility Crisis in Machine-Learning-Based Science." Patterns, 4(9), 100804. https://doi.org/10.1016/j.patter.2023.100804
4. Roberts, D. R., et al. (2017). "Cross-Validation Strategies for Data with Temporal, Spatial, Hierarchical, or Phylogenetic Structure." Ecography, 40(8), 913-929. https://doi.org/10.1111/ecog.02881
5. Riley, R. D., et al. (2024). "Evaluation of Clinical Prediction Models (Part 3): Calculating the Sample Size Required for an External Validation Study." BMJ, 384, e074821. https://www.bmj.com/content/384/bmj-2023-074821
6. Brown, L. D., Cai, T. T., and DasGupta, A. (2001). "Interval Estimation for a Binomial Proportion." Statistical Science, 16(2), 101-133. https://doi.org/10.1214/ss/1009213286
7. Varma, S., and Simon, R. (2006). "Bias in Error Estimation When Using Cross-Validation for Model Selection." BMC Bioinformatics, 7, 91. https://bmcbioinformatics.biomedcentral.com/articles/10.1186/1471-2105-7-91
8. Blum, A., and Hardt, M. (2015). "The Ladder: A Reliable Leaderboard for Machine Learning Competitions." Proceedings of the 32nd International Conference on Machine Learning, 1006-1014. https://proceedings.mlr.press/v37/blum15.html
9. Dwork, C., Feldman, V., Hardt, M., Pitassi, T., Reingold, O., and Roth, A. (2015). "Generalization in Adaptive Data Analysis and Holdout Reuse." Advances in Neural Information Processing Systems, 28. https://papers.nips.cc/paper_files/paper/2015/hash/bad5f33780c42f2588878a9d07405083-Abstract.html
10. Bouthillier, X., et al. (2021). "Accounting for Variance in Machine Learning Benchmarks." Proceedings of Machine Learning and Systems, 3, 747-769. https://proceedings.mlsys.org/paper_files/paper/2021/file/0184b0cd3cfb185989f858a1d9f5c1eb-Paper.pdf
11. Koh, P. W., et al. (2021). "WILDS: A Benchmark of in-the-Wild Distribution Shifts." Proceedings of the 38th International Conference on Machine Learning, 5637-5664. https://proceedings.mlr.press/v139/koh21a.html
12. Russakovsky, O., et al. (2015). "ImageNet Large Scale Visual Recognition Challenge." International Journal of Computer Vision, 115, 211-252. https://doi.org/10.1007/s11263-015-0816-y
13. Wang, A., et al. (2018). "GLUE: A Multi-Task Benchmark and Analysis Platform for Natural Language Understanding." EMNLP Workshop BlackboxNLP, 353-355. https://aclanthology.org/W18-5446/
14. White, C., et al. (2025). "LiveBench: A Challenging, Contamination-Limited LLM Benchmark." International Conference on Learning Representations. https://proceedings.iclr.cc/paper_files/paper/2025/file/e4a46394ba5378b3f9a186a5b4c650d1-Paper-Conference.pdf
15. Northcutt, C. G., Athalye, A., and Mueller, J. (2021). "Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks." NeurIPS Datasets and Benchmarks. https://datasets-benchmarks-proceedings.neurips.cc/paper/2021/hash/f2217062e9a397a1dca429e7d70bc6ca-Abstract-round1.html
16. Recht, B., Roelofs, R., Schmidt, L., and Shankar, V. (2019). "Do ImageNet Classifiers Generalize to ImageNet?" Proceedings of the 36th International Conference on Machine Learning, 5389-5400. https://proceedings.mlr.press/v97/recht19a.html
17. Li, Y., Guo, Y., Guerin, F., and Lin, C. (2024). "An Open-Source Data Contamination Report for Large Language Models." Findings of the Association for Computational Linguistics: EMNLP 2024, 528-541. https://aclanthology.org/2024.findings-emnlp.30/