Can a leaderboard cause peeking?

Yes. Repeated submissions and score-based choices can adapt a system to a benchmark, even when its labels are hidden.

Is validation-set tuning also prohibited?

No. Validation data are intended to guide development, although extensive tuning can overfit them and should be accounted for in final assessment.

Does nested cross-validation fix a poorly sampled dataset?

No. It separates tuning from assessment within a design; it cannot automatically repair unrepresentative data or an inappropriate split strategy.

AI Glossary / Graphs and symbolic AI / Intermediate

Peeking

Definition

Peeking, in machine-learning evaluation, means using information from a test set to influence model development or selection and then treating performance on that same set as an independent final evaluation. It can occur even when test examples never enter the model's direct training procedure.

What it means

A test set is intended to assess a chosen system on data that did not guide its development. If a team repeatedly checks test accuracy and keeps whichever settings score best, the test results become part of the selection process.

The resulting score can reflect both real predictive ability and adaptation to the particular test sample. This can create optimistic performance estimates. The size of the problem depends on the selection process, data and dependence among the tested alternatives; it is not a fixed penalty that can be subtracted afterward.

Peeking is therefore about the information used to make decisions, not simply the name of a dataset folder. Calling a development set “test” does not preserve independence when its feedback guides changes.

How it works

Development choices include hyperparameters, features, prompts, thresholds, preprocessing and which model version to retain. If final-test outcomes influence any of these, information can leak into the selected system indirectly.

Use training data for fitting and validation data or a suitable cross-validation procedure for development choices. Reserve final assessment data for evaluating the selected pipeline under a defined protocol. Nested cross-validation can evaluate a selection procedure by keeping its inner tuning separate from outer assessment.

Splitting must also respect the task: related entities, duplicates or future information can contaminate evaluation even without explicit test-score tuning. Conversely, an independent test is not guaranteed representative simply because nobody has inspected it.

After a test result motivates redesign, its evidence remains informative, but the redesigned system needs appropriately independent assessment before the same level of generalization claim is made.

Three practical examples

A team tries many classification thresholds against a nominal test set and reports only the best threshold's score on that set.
A prompt developer repeatedly edits instructions after inspecting benchmark failures, then presents the same benchmark as untouched evaluation.
An analyst selects features using all labeled rows before splitting, allowing assessment information to affect the fitted pipeline.

Think of it this way

Think of preparing for an exam after seeing its answer sheet, then using your score on that same exam to estimate performance on unseen questions. You may have learned useful material, but the score no longer measures the original independent test.

The analogy is limited because peeking can occur through aggregate scores without exposing individual answers. Even a single number can guide selection when many alternatives are compared against it.

Worked example

Consider an invented evaluation with 100 cases. Three model versions, developed using training data, obtain nominal test accuracies of 82%, 85% and 88%. The team chooses the 88% version because of these results and labels 88% its independent final score.

The test set has now influenced model selection. The 88% observation is still the accuracy of that version on those cases, but it is not an independent assessment of the version-selection process.

Suppose a separately held, appropriately sampled set of 100 new cases then gives 84% for the frozen selected version. This second result is independent of the earlier selection if no feedback from it shaped the choice. It need not always be lower; the example does not establish a universal four-point optimism correction.

The counts are constructed to illustrate data roles. They do not imply that the selected model's true accuracy is exactly 84% or that 100 cases provide adequate precision for every task.

Illustrative case study

The fictional Willow Prompts team maintains a benchmark for a document assistant. After each review, it adds rules addressing the benchmark's failures and celebrates the rising score as evidence of performance on unseen documents.

A reviewer records that the benchmark has become a development resource. Willow keeps it for regression checks and creates an appropriately independent assessment for the frozen candidate, with a documented evaluation procedure.

This fictional case distinguishes useful iterative improvement from an unsupported independence claim. A reused benchmark can remain valuable, but its role must be described honestly.

Common misconceptions and mistakes

Peeking requires copying test labels into training. Aggregate results and manual error review can also guide development.
A random split solves every evaluation problem. Leakage through groups, time or preprocessing can remain.
Looking at results makes the observed score numerically false. The score can be correct for those cases while its interpretation as independent evidence is compromised.
A fresh test must always produce a lower score. Sampling variation can move it either way.
The problem is cured by renaming the dataset. Its actual use determines its role.

Business use

Evaluation discipline matters when results support a launch decision, supplier comparison or claim of improvement. Document which data informed which decisions and keep assessment claims proportional to that history.

Set the evaluation protocol before examining final results, including metrics, subgroup analyses and how missing outputs are scored. Preserve the complete pipeline, not just model weights, because preprocessing and prompt choices can carry test-informed adaptation.

When development continues after assessment, acknowledge the new role of the old test set. Repeated benchmark use is not inherently useless; it becomes misleading when reported as fresh evidence of generalization. Independent assessment should reflect the intended deployment population and important operating conditions.

Check your understanding

Why is the chosen version's 88% score no longer an independent final assessment in the worked example?

Answer: The team used those test results to choose the version. The information served selection and evaluation, so the score does not independently assess the selection procedure.

Related terms

Learn next

Draw a timeline of model, prompt and threshold decisions for a small project. Mark every dataset consulted at each step. Identify which set could still assess the frozen pipeline independently and whether its sampling design matches the deployment question.

Sampling design

Sources

Scikit-learn explains cross-validation and the risk of test-set feedback leaking into model choices: https://scikit-learn.org/stable/modules/cross_validation.html

Cawley and Talbot analyze overfitting in model selection and resulting evaluation bias: https://jmlr.org/papers/v11/cawley10a.html

The three-version calculation and Willow Prompts case are original illustrations in the machine-learning evaluation sense.

Previous: Pedagogical agent Next: Penalty method