Part II · ML foundations · Chapter 11

Generalisation, overfitting and regularisation

A model is only useful if it works on examples it has never seen. This chapter is about the gap between training performance and real performance: how to measure it with held-out data, why it opens, and the regularisation tricks that close it.

Training, validation and test sets

Split your labelled examples into three groups before you start:

• Training set (often about 80%): the model's parameters are fitted to these.
• Validation set (about 10%): used to choose settings that are not learned by gradient descent, called hyperparameters: the learning rate, the size of the model, how long to train, how strong the penalty.
• Test set (about 10%): looked at once, at the end, to report how well the finished model does. If you go back and change things after seeing the test score, it has become a second validation set and no longer measures anything honest.

Shuffle before splitting, unless the data has an order that matters. For anything that changes over time, like prices or news, train on the past and test on the future; a random split would let the model peek at tomorrow.

Underfitting and overfitting

Fit polynomials of different degrees to ten noisy points that come from a smooth curve:

• Degree 1, a straight line, is too simple. It misses the curve, so its error is high on both the training points and new points. This is underfitting.
• Degree 3 or 4 follows the trend and ignores the noise. Training error is moderate, validation error is lowest.
• Degree 9 has ten parameters for ten points, so it can pass through every training point exactly: training error near zero. Between the points it swings wildly, and its validation error is the worst of all. This is overfitting: the model has learned the noise.

The U-shape of validation error against model complexity is the picture to remember. Older textbooks call the two sides bias (too simple, systematically wrong) and variance (too flexible, changing a lot with every new sample of training data).

Regularisation

Regularisation means any change that makes a model prefer simpler explanations. The main tools:

L2 penalty (weight decay)

Add the sum of squared weights to the loss, scaled by a strength λ (lambda):

Wild curves need huge weights that cancel each other out; the penalty makes those expensive. The gradient of the penalty is 2λw, so each update becomes

Worked: with η = 0.1 and λ = 0.05 the factor is 1 − 0.01 = 0.99, so every step first shrinks each weight by 1% and then applies the usual gradient. A weight of 3 that the data does not support decays to 3 × 0.99¹⁰⁰ = 1.10 after 100 steps. Hence the other name, weight decay. (The AdamW optimiser applies this shrinking directly rather than through the loss; chapter 13.)

L1 penalty

Penalise λΣ|w_i| instead. Its push towards zero is the same size however small the weight is, so it drives unhelpful weights to exactly zero. That makes L1 useful when you want the model to ignore most of its inputs.

Early stopping

Check validation loss as you train. Training loss keeps falling, but validation loss eventually turns upwards as the model starts memorising. Keep the parameters from the point where validation loss was lowest and stop. It is free, and almost every serious training run does it.

More data, and augmentation

The surest cure for overfitting is more examples, because noise averages out while the real pattern does not. When real data is scarce, augmentation makes new examples from old ones: flipped or cropped images, paraphrased sentences. Dropout (chapter 13) is a regulariser built into the network itself.

Leakage: the silent failure

Leakage is when information from the validation or test set reaches training. The scores look wonderful and mean nothing. Common causes:

• Duplicates or near-duplicates across the split, so the "unseen" example was seen.
• Normalising with the mean and standard deviation of all the data, test set included. Compute them on the training set only.
• A feature that secretly contains the answer, such as a "closed account" flag when predicting who will close their account.
• For language models, contamination: benchmark questions that appear somewhere in the web text the model was trained on. A model that has read the answers scores well on that benchmark without being able to do the task.

In AI applications

When you build on a hosted model, you rarely train it, but you still tune: prompts, retrieval settings, which model to call. Each tweak that makes a fixed set of test questions pass is a step of fitting, and you can overfit your prompts to your eval set exactly as a degree-9 polynomial fits ten points. The defence is the same: keep some cases you never tune against, and be suspicious of a change that helps the eval but has no clear reason to help users.

Keep the eval data as carefully as code. Build the question bank from its sources with a script that drops any question already in the bank and prints each one it drops, so a duplicate cannot quietly count twice. Give the script a --check mode that exits with an error when the built file is out of date, so a stale bank fails in review.

Test data for a grader should be built to measure, not to tune. Start from good answers and deliberately plant defects in them (a wrong figure, a missing caveat), so that a grader that passes everything is caught. And split the question bank into a tuning half and a held-out half before you start tuning prompts against it: that is the first safeguard this chapter recommends.