When the exam becomes part of the textbook

An examination becomes less informative if its questions and answer key are included in the material a student studies. The student might still understand the subject, but the result no longer cleanly separates understanding from familiarity with that particular test. Language-model evaluation faces a related problem on a much less inspectable scale.

The analogy has limits. A model does not prepare for an exam in the same way a person does, and its training corpus may contain trillions of tokens from many sources. Exposure can be indirect, partial or uncertain. A benchmark score alone cannot identify the relevant history. The evaluation problem begins when a result is interpreted more broadly than its evidence permits.

Three terms need to remain separate: contamination, memorization and generalization. Confusing them encourages both exaggerated accusations and exaggerated confidence. Separating them produces better questions about what a test actually demonstrates.

Contamination concerns the path into the evaluation

Contamination generally refers to evaluation material or closely related information entering a stage that is supposed to remain separate from the test. The relevant stage could be pretraining, later training, development or another part of a particular evaluation setup. A report should say what kind of exposure it is investigating rather than assume every use of the word describes the same event.

Public availability makes exposure possible, not proven. A dataset can be online before a model is trained without necessarily being included in that training run. Conversely, a test question can appear through a copied discussion or worked solution even if the original benchmark repository was excluded. Searching for one exact URL is therefore an incomplete account of the possible routes.

The 2023 paper Proving Test Set Contamination in Black Box Language Models compares the likelihood of a benchmark’s canonical order with shuffled orders. Its key condition is exchangeability: in the absence of contamination, changing example order should not make one ordering inherently more probable. A model’s unusual preference for the published sequence then supplies evidence different from its ability to answer individual questions.

The condition is doing real work. As an illustrative counterexample, take paragraphs forming a continuous story. Their original order can be easier to predict because each continues the previous paragraph; shuffling destroys that structure. A preference for the original order would not by itself prove training inclusion. This is an explanation of the assumption, not a claim that the paper used such a dataset.

The method needs likelihood measurements, not just an ordinary chat answer. Avoiding access to weights or training data does not remove that interface requirement. Before borrowing its guarantee, establish that the required measurements and exchangeability assumption fit the system and dataset being examined.

Memorization concerns what was retained and used

Exposure and memorization are not interchangeable. Encountering material during training does not mean every detail can be reproduced or that the material determines a later answer. A model can also recognize a question’s form while solving it through more general patterns. The path from training inclusion to a particular test success requires more than a binary seen-or-unseen label.

Detecting Pretraining Data from Large Language Models, also introduced in 2023, approaches membership from another signal. Its Min-K% Prob method examines the lower-probability tokens in a passage, motivated by the hypothesis that unseen text is more likely to contain improbable outliers. Its WIKIMIA benchmark uses text created before and after model training to study detection.

This signal answers a membership question under a tested arrangement. It does not establish that a model used memorized answers to obtain a particular capability score, or that every likely passage must have been in training. A familiar topic, easy wording and an exact retained text are not equivalent evidence. The investigator still needs to connect the detection question to the accusation being made.

There are several possible demonstrations of retention, and they should be described precisely. Reproducing a distinctive passage is different from solving a common algebraic form. Recognizing an answer option is different from generating a correct explanation without options. A test may reveal one behavior without settling all questions about the model’s internal representation or the cause of every correct response.

This is why an accusation of deliberate cheating needs evidence about an actor and an action, not just an unexpectedly good score. Contamination can arise from broad data collection without a person intentionally inserting a test. An evaluation can be compromised without establishing dishonest intent by the model developer. Precision about the failure makes the criticism more credible.

Generalization concerns the new case the score is meant to predict

A benchmark usually matters because people want to know how a system will perform elsewhere. That elsewhere needs a definition: new questions in the same format, a different domain, unfamiliar interfaces or real work with additional constraints. A cleanly held-out test can support an estimate for one target distribution while providing little evidence about another.

Common background knowledge should not be confused with leaked answers. A model solving a new geometry question is expected to use learned geometry. The relevant concern is whether task-specific exposure makes the test easier in a way that defeats its intended comparison. Demanding that a model have no related prior knowledge would make most useful capability evaluation impossible.

The same distinction applies to code. Learning a widely used algorithm is not automatically contamination of every programming task that uses it. Encountering an exact contest problem and solution can raise a different issue. A rigorous evaluation describes what kind of novelty it seeks and what prior knowledge remains legitimate, rather than relying on the dramatic image of an entirely blank examination room.

Changing names or surface wording may help investigate familiarity, but it can also change difficulty. A rewritten problem might introduce ambiguity, remove a helpful cue or accidentally alter a requirement. If performance changes, the evaluator needs to distinguish reduced exposure from a changed task. A perturbation is an experiment with its own assumptions, not a magic test for genuine intelligence.

Keep the calendar, but do not ask it to prove everything

Time-separated evaluation can reduce some routes of contamination. LiveCodeBench uses newly collected programming problems and supports evaluating across publication windows. The methodological idea is useful: compare a model with tasks that become available at a relevant time, while preserving the test’s other requirements. It is not a guarantee that every task called live remains unseen by every later system.

A model’s announced knowledge cutoff is also an imperfect boundary for a complete product. The system may use retrieval, a browser or later adaptation. Those capabilities can be legitimate if the test allows them. The evaluation should record what information and tools were available instead of assuming that a date on a model card describes every path by which the running system can acquire an answer.

The test date matters too. A newly collected question can become familiar after repeated public use. A benchmark that was fresh when introduced may not retain the same protection indefinitely. Keeping a rolling collection can help, but the report should identify the collection version and the time window actually used. The word fresh has a short shelf life without those details.

A clean test can still become a development target

Even without direct training on the held-out questions, repeated optimization against a public score can narrow the meaning of improvement. Developers can adjust prompts, scaffolding or selection strategies based on aggregate feedback. That can produce a better system for the test while leaving uncertainty about performance on other tasks.

This is not an argument against using benchmarks during development. It is a reason to preserve an independent evaluation route for the claims made after development. If the same test supplies both the target and the final proof, the distinction between learning the intended capability and adapting to the measurement becomes harder to assess.

Private tests can help preserve separation but introduce other responsibilities. Who designed the tasks, what population do they represent and who can inspect the scoring? Secrecy can protect a question set while making errors or biases harder for outsiders to discover. A credible evaluation needs an account of both integrity and validity, not a claim that private automatically means better.

Human review can improve the interpretation of unusual outcomes. A model might exploit an unintended scoring loophole while failing the actual task, or satisfy the intended task through an unexpected valid route. The evaluator should distinguish those cases before deciding whether to change the test. Rewarding only the expected wording can punish genuine solutions; rewarding only a loose proxy can reward the wrong behavior.

What an evaluation report should let a reader reconstruct

The report should identify the model and surrounding system, the task collection, the scoring method and the allowed resources. It should explain relevant training-separation precautions and any contamination investigation actually performed. These details let the reader assess the result’s scope and intended audience without requiring an unsupported assurance that all possible leakage has been eliminated.

For a changing task collection, keep comparable versions or explain how comparisons are adjusted. A model tested on an easier month should not automatically outrank one tested on a harder month. Difficulty, task mix and sample size can move a score independently of model improvement. Updating a benchmark creates a maintenance problem as well as an integrity benefit.

Uncertainty deserves space next to the headline. A small difference can be sensitive to sampling, run variation or evaluator choices. More decimal places do not remove those issues. Where results depend on a particular setup, show that setup clearly enough that a buyer does not mistake a narrow lead for a universal ordering.

Deployment teams can add questions that reflect their actual work, provided they preserve a meaningful separation from development. They should include ordinary cases, relevant exceptions and tasks whose success can be checked. A small local test cannot replace broad research, but it can reveal that a public benchmark is measuring a capability different from the one the organization needs.

Preserve the failed examples as well as the successes. A final score can remain unchanged while the system begins solving different cases and failing others. If a new model improves common tasks but regresses on a small category essential to the service, the average may obscure an important purchasing consequence. Reviewing case-level changes helps connect the benchmark to its intended use without pretending that every example carries the same operational weight.

An evaluation also needs a rule for ambiguous tasks. A flawed question should be investigated and, when justified, corrected or excluded transparently. Removing only questions a favored system fails would create a different integrity problem. The correction record should explain what was wrong with the item and how comparable results were handled, so that maintaining a benchmark does not quietly become selecting a winner.

After the examination

There are two unhelpful endings to the contamination debate. One declares every impressive result memorization. The other declares that a model’s usefulness makes evaluation integrity irrelevant. Both abandon information that could improve decisions. The useful response is to investigate exposure, measure behavior and keep the intended generalization claim within reach of the evidence.

An evaluation report should leave a trail another researcher can follow: where the tasks came from, when they became public, how they were selected and how the model was scored. A fresh set of tasks can strengthen that trail; documenting exclusions and repeated attempts strengthens it further. The eventual score belongs beside those records. That is how an exam result becomes evidence about new work, rather than a number whose relationship to the training material remains anyone’s guess.