Train, Validation, Test

Split your data into three parts with three different jobs. Confuse them and your model looks great in development and fails in the real world.

Because a model can overfit — memorize its training data and fail on new data — you cannot judge it by how it does on what it was trained on. The fix is a discipline: split your data into three parts, each with a distinct job, and never let them leak into each other. Get this right and your development numbers predict reality. Get it wrong and you ship a model that looked excellent and performs terribly.

Three sets, three jobs

Training set — the model learns from this. Gradient descent uses these examples to adjust the weights. Usually the largest slice, often around 70-80%.

Validation set — you use this to make decisions about the model without training on it. How many layers? What learning rate? When to stop training? You try options, check them on the validation set, and keep what works best. The model never learns from these examples, but you do.

Test set — locked away until the very end. Used exactly once, to estimate how the finished model will perform on genuinely new data. It is your stand-in for the real world.

The reason there are three, not two, is subtle and important. The training set measures nothing useful about generalization. The validation set does — but the moment you start tuning against it, you begin fitting to it indirectly. So you need a third set that has touched neither the learning nor the tuning to give an honest final number.

Why the validation set gets “used up”

Here is the trap that catches people. Suppose you try fifty model variations and pick the one that scores best on the validation set. That winning score is now optimistic. With fifty tries, some model looked good on that particular set partly by luck, and you selected exactly for that luck.

This is overfitting one level up — not the model overfitting the training data, but you overfitting the validation set through repeated choices. The more decisions you make against a validation set, the less trustworthy its numbers become. That is precisely why the test set exists and why it must stay untouched: it is the one measurement no selection pressure has contaminated. Peek at it during development and you destroy the only honest estimate you have.

The cardinal sin: leakage

Data leakage is when information from validation or test sneaks into training, and it produces the most dangerous kind of failure — one that hides until deployment.

Concrete ways it happens:

• Duplicate or near-duplicate examples split across sets. The model effectively sees test examples during training, so the test score is inflated.
• Normalizing using the whole dataset before splitting. The scaling then encodes information about the test set. Compute normalization statistics on the training set only, then apply them to the others.
• Time-ordered data split randomly. If you are predicting the future, training on examples from after your test period lets the model peek ahead. Time-series data must be split by time, not shuffled.

Leakage always makes your development numbers look better than reality. That asymmetry is what makes it so dangerous: it never warns you by looking bad. The gap only reveals itself when the model meets real data and disappoints.

Where the split points

For the split to mean anything, the three sets must resemble the data the model will actually face. A few consequences:

Split randomly, usually — so each set is a fair sample. But when structure exists, respect it: split time series by time, and keep grouped examples (all records from one patient, all frames from one video) entirely within one set so the model cannot memorize a group and get quizzed on the same group.

Keep proportions honest. If one class is rare, ensure it appears in all three sets in similar proportion, or your validation and test numbers wobble on tiny samples.

When data is scarce: cross-validation

A single split wastes data — a fifth of it never trains the model — and a small validation set gives a noisy score. Cross-validation addresses both. Split the data into k folds, then train k times, each time holding out a different fold for validation and training on the rest. Average the k scores.

Every example gets used for both training and validation across the rounds, and averaging smooths out the luck of any single split. The cost is training k times over, so cross-validation is common with modest datasets and impractical at the scale of LLM pretraining, where a single held-out set is enough. A separate test set still stays locked away on top of it.

This is the ground truth for evaluation

Every honest claim about model quality traces back to this discipline. When you read that a model scores some number on a benchmark, the question that determines whether the number means anything is: was the benchmark truly held out, or did it leak into training? That exact concern — benchmark contamination — is the train/test boundary violated at the scale of the whole field. The entire evaluation layer is built on the foundation laid here.

What to remember

• Training teaches the model, validation guides your choices about it, test gives one honest final estimate.
• You gradually overfit the validation set by tuning against it, which is why an untouched test set is necessary.
• Data leakage — duplicates across sets, whole-dataset normalization, peeking ahead in time — inflates your numbers and hides until deployment.
• Split so the sets resemble real data: randomly in general, by time for time series, by group for grouped data.
• Cross-validation reuses scarce data by rotating the held-out fold; it is standard for small datasets, impractical at pretraining scale.

Next: Probability for AI — the language models use to express uncertainty and produce their outputs.