2.6.3 · D3Model Evaluation & Selection

Worked examples — Training, validation, and test error

3,857 words18 min readBack to topic

This page is a workout. The parent note told you what the three errors are and why they exist. Here we take that machinery and run it through every kind of situation it can meet — big data, tiny data, the overfitting trap, the underfitting trap, the "gap goes negative" oddity, a real-world word problem, and the sneaky exam twist where someone tunes on the test set and gets a lie for an answer.

Before any example, let us make one promise: no symbol appears before it is earned. So a 30-second refresher on the four quantities we will keep computing.

Here "average mistake" means: take every example, measure how wrong the prediction is (that per-example wrongness is called the loss ), and average. Suppose the set we are scoring holds examples — here is simply the count of examples in whatever set we are averaging over (it will be the training-set size when we score training data, the validation-set size when we score validation data, and so on). Then:

where is the true answer for example number , is the model's guess for it, and ("sum over ") just means "add these up for ". For classification we will use the misclassification loss: if the guess is wrong, if right — so becomes simply the fraction of examples gotten wrong. For regression we use squared error , because it punishes big misses much harder than small ones (and because its derivative is clean for gradient descent — that is why squares and not absolute value here).

Two named quantities we will re-use, defined here once so no symbol is used unearned:


The scenario matrix

Every case this topic can throw is one of these cells. The examples below are labelled with the cell they cover, and together they cover every row.

# Case class The defining feature Covered by
C1 Large data split huge → tiny % validation is still thousands of points Ex 1
C2 Medium data split 80/10/10, straightforward Ex 2
C3 Small data → k-fold one split too noisy; rotate folds Ex 3
C4 Overfitting () train error low, val error high Ex 4
C5 Underfitting (, both high) model too weak; both errors bad Ex 4
C6 Negative gap () val easier than train (noise / unlucky split) Ex 5
C7 Degenerate: interpolation, capacity = data Ex 6
C8 Limiting behaviour () val error converges to true error Ex 7
C9 Word problem (real world) translate a business story into a split Ex 8
C10 Exam twist: leakage tuning on the test set fakes a good score Ex 9
Figure — Training, validation, and test error

The figure above is the map of this whole page. As model complexity grows left→right, training error keeps falling but validation error dips then rises. Read it as a tour of the examples:

  • Ex 4's underfit model P sits at the far left (both curves high).
  • Ex 4's good model Q sits at the violet sweet-spot dot (validation minimum).
  • Ex 4's overfit model R and Ex 6's degree-9 interpolator live at the far right, where the training curve has crashed toward zero but the validation curve has climbed back up.
  • Ex 7 is about how tightly the validation curve itself can be pinned down as its sample count grows.

Keep glancing back at this map; every example is a point on it.


The worked examples

Example 1 — Large dataset split (cell C1)

Forecast: guess — is 1% of two million a laughably small validation set, or actually plenty?

  1. Compute each slice. train; val; test. Why this step? Percentages of the whole tell us the raw counts, and raw counts — not percentages — are what determine estimate stability.
  2. Judge stability by count, not fraction. Use the standard error formula defined just above the scenario matrix, , where is the true error rate and is the validation-set size. Even at the worst-case (which maximises ), with we get . Why this step? We want to know how much jitters just from which 20k samples we drew. Using the worst-case gives a safe upper bound on that jitter. If even the bound is tiny compared to the differences between models, 1% is enough.

Verify: ✓ (all samples accounted for, none double-counted). Worst-case standard error , so estimates are stable. → See Model Selection for how these compare candidates.


Example 2 — Medium dataset split (cell C2)

Forecast: will the "combine train+val for the final fit" step give you back the full 40,000, or only part?

  1. Split. train; val; test. Why this step? 10% of 40k is 4,000 — comfortably above the ~1,000-sample floor where fraction estimates get noisy.
  2. Combine after tuning. Once hyperparameters are chosen, val is no longer needed as a referee. Merge it back: final training samples. Why this step? Every held-out point you stop holding out is extra fuel for the final model — you only kept val separate to make an honest choice, and that choice is now made.
  3. Test stays sacred. The 4,000 test points are never merged in. They score the finished model once. Why this step? The moment test data influences any decision, its score stops being unbiased — that is Data Leakage.

Verify: ✓. Final model sees , i.e. of all data ✓, test untouched at ✓.


Example 3 — Small data, k-fold cross-validation (cell C3)

Forecast: guess the average error and whether each round trains on more or fewer points than a plain 80/20 split.

Figure — Training, validation, and test error
  1. Fold size. points per fold. Why this step? We chop the data into equal blocks so each block gets one turn as the validation fold.
  2. Per-round training count. Each round holds out one 200-point fold and trains on the other four: . Why this step? Rotating which fold sits out means every point is used for validation exactly once and for training four times — no point is wasted.
  3. Average the fold errors. . Why this step? Averaging five independent-ish estimates cancels the luck of any single split — that is the whole point of cross-validation (see Cross-Validation).

Verify: fold size ✓ (); per-round train ✓; mean error ✓.


Example 4 — Overfitting vs underfitting from a table (cells C4 & C5)

Forecast: which model is memorising, which is too weak, and which do you ship?

  1. Compute gaps. ; ; . Why this step? The gap isolates overfitting specifically — how much worse new data is than studied data.
  2. Read the gaps together with the level. P: tiny gap but both errors highunderfitting (cell C5): the model is too simple to even fit the training data (far left of the map figure). R: huge gap, near-zero train error → overfitting (cell C4): memorised noise (far right of the map). Q: small gap and low errors → good fit (the violet sweet-spot dot). Why this step? A small gap alone is not enough — an underfit model also has a small gap. You must check whether the level of error is acceptable, not just the gap.
  3. Deploy Q. Lowest (0.15) among all three. Why this step? Validation error is our proxy for real-world error; we pick the smallest. Regularizing R (see Overfitting and Regularization) could also rescue it, but Q already wins.

Verify: ✓; smallest is Q's ✓; P has both errors (underfit) ✓.


Example 5 — Negative gap (cell C6)

Forecast: is a negative gap always a bug, or can it happen honestly?

  1. Compute the gap. . Why this step? We first confirm the sign is genuinely negative, not a typo.
  2. List honest causes. (i) The validation fold, by luck of the draw, contains easier examples than training. (ii) Regularization/dropout is active during training (raising ) but switched off at validation. (iii) The training set carries more label noise. Why this step? is rare but legal. Before blaming a bug, we check whether a benign explanation fits.
  3. The real red flag to rule out — leakage in the wrong direction. If validation somehow leaked into training or the split isn't i.i.d., that's a genuine bug. Here, with dropout on, cause (ii) fully explains it → not broken. Why this step? We separate "surprising but fine" from "actually wrong" so we don't waste hours debugging a healthy run.

Verify: ✓; sign is negative and a valid non-bug explanation (dropout on during train) exists ✓.


Example 6 — Degenerate case: perfect interpolation (cell C7)

Forecast: what training error does a curve with as many free knobs as data points achieve?

Figure — Training, validation, and test error
  1. Count knobs vs points. A degree-9 polynomial has coefficients — exactly the number of data points. Why this step? When free parameters equal samples , the curve can thread through every point exactly. This is the boundary case .
  2. Training error is exactly zero. Each prediction equals its target, so every loss term , and . Why this step? This is the algebraic meaning of "interpolation": zero residual at every fitted point.
  3. Why validation still suffers. Between the fitted points, the wiggly curve swings wildly up and down (look at the violet overshoot in the figure). New validation -values land between the training points, right on those wild swings, so the curve's prediction there is far from the true trend — hence each validation loss is large and is large. The model spent all its capacity memorising the 10 training points, none of it on capturing the smooth underlying pattern that would generalise. Why this step? Zero training error is the most misleading possible number — this is the clearest warning that low alone means nothing (see Generalization Error).

Verify: coefficients ✓; interpolating fit → ✓ (checked numerically by fitting and evaluating).


Example 7 — Limiting behaviour of the validation estimate (cell C8)

Forecast: does the estimate keep getting better forever, and how fast?

  1. Recall what one sample contributes. Each validation example scores a loss that is either (wrong) or (right). Its long-run average is exactly , the true error rate. Such a single 0/1 outcome is a Bernoulli draw, and a fact about Bernoulli draws is that its variance (the average squared distance from its mean) equals . Why this step? We must know the spread of one sample before we can know the spread of an average of many — this is the fact the standard-error formula above the matrix was built on.
  2. Standard error of the average. is the average of independent such 0/1 losses. For an average of independent things, variance shrinks by a factor , so the standard error (its square root) is — the very formula stated earlier. This is why the Law of Large Numbers works: the wobble carries a factor that drives it to zero. Why this step? This turns the vague promise "more data → better estimate" into an exact, computable rate.
  3. Plug in. With :
    • Why this step? Concrete numbers show the law: multiply by 100, the error shrinks by 10.
  4. Take the limit. As , , so . Why this step? This is the precise sense in which validation error "approximates generalization" — it converges to the truth as the held-out set grows.

Verify: , , ✓; each in gives a smaller SE ✓; the limit as is , so ✓.


Example 8 — Real-world word problem (cell C9)

Forecast: will random shuffling over- or *under-*estimate the model's real 2024 performance?

  1. Assign records by year. Train 2019–2022 ; validate early-2023 (half of 2023); test late-2023 . Why this step? Deployment is in the future, so the honest test is "train on the past, predict the future" — exactly what a time split simulates.
  2. Why random shuffling lies. Random mixing lets the model train on late-2023 records and be tested on early-2023 records — it peeks at the future. That is a subtle form of Data Leakage, and it makes optimistically low. Why this step? If evaluation conditions don't match deployment conditions, the reported score is a fantasy.
  3. Conclusion. The senior's time split gives a realistic (higher, honest) error estimate. Why this step? An honest-but-worse number beats an optimistic-but-fake one, because reality won't be fooled.

Verify: ✓; train fraction ✓; each of val and test ✓.


Example 9 — Exam twist: tuning on the test set (cell C10)

Forecast: is reporting the best-of-50 test scores an honest estimate — and if not, which way does it lie?

  1. Spot the mechanism. With 50 models each scored on the same test set, some model gets a lucky draw of easy test points by pure chance. Picking the minimum of 50 noisy estimates is systematically below the average. Why this step? Choosing the best-looking of many random results biases you toward flukes — the "winner's curse."
  2. Quantify the underestimate. Reported vs true : underestimate , i.e. the score is understated by . Why this step? Naming the gap makes the danger concrete: a claimed 18% error is really 25%.
  3. The fix. Use a validation set for the 50-way comparison, then touch the test set once on the single chosen model. The test set stays an unbiased referee. Why this step? This is the entire reason the three-way split exists — the moment the test set influences model choice, it becomes a second validation set and its number stops being trustworthy.

Verify: underestimate ✓; relative ✓.


Recall

Recall Which single number tells you a model is overfitting — and its trap?

The gap . Trap: a small gap can also mean underfitting if both errors are high — always check the error level too. ::: gap plus level

Recall Why is 1% validation fine for 2 million samples but not for 1 thousand?

Stability depends on the absolute count ( of 2M 20,000 points, worst-case SE ), not the percentage. For , 1% is 10 points — useless. ::: absolute size rules

Recall What is the standard error of a fraction-of-wrong estimate, and why?

, because averages independent 0/1 (Bernoulli) losses, each with variance ; averaging shrinks variance by . ::: Bernoulli over n

Recall What happens to

as the validation set grows without bound? Its standard error , so (Law of Large Numbers). ::: converges to truth

Recall When may

be exactly 0 yet the model be terrible? When parameters samples (interpolation): the curve threads every point but wiggles wildly between them, so is large. ::: interpolation degeneracy

Recall Reporting the best-of-many

test errors — which way does it lie? Optimistically (too low) — the winner's curse. Use validation to choose, test once at the end. ::: understates true error