Overfitting

Early practice was to grade a model on the very data used to teach it. The first model Pagedeck built to catch spam accounts was scored that way and came back at 98 percent. The week after it shipped, spam reports went up rather than down. Nobody had been careless about it; scoring on the training set was simply what everyone did.

The conversation that followed always came apart in the same place. Theo would bring the 98 percent, Mia would ask why reports were climbing, and Theo could recheck the figure all day and still get 98 percent with no way to say where the fault lay. The score wasn't wrong. It just answered a different question than anyone assumed: not "can this model judge a new account" but "can it remember the accounts it already saw."

So the habit of splitting the data up front took hold. The training data teaches the model, a separate slice is reserved for scoring, and the scoring slice is never shown during training. Put the two numbers side by side and the problem becomes visible: 98 on the training slice, 71 on the held-back one. Overfitting is the name for that 27-point gap.

A model only ever adjusts in the direction that reduces its errors on the training data. That is why it absorbs coincidences in that data as if they were rules. If 340 of the 400 accounts labeled spam happen to share one free mail domain, the model will invent a rule that says the domain means spam, and that rule buys it a few points. Nothing inside the training data ever signals that the rule is wrong.

It's the difference between understanding the material and memorizing the answer key from past exams. Every question you've seen comes back right, and every new one comes back wrong.

Three conditions push a model this way.

1. Too little data. Teach on 500 accounts and the coincidences specific to those 500 look like general rules. Feed the same model 50,000 and the coincidences cancel each other out.
2. Too many features. A feature is one input value pulled out of a record — for an account, days since signup or average documents per day. Supply 40 of those for only 500 accounts and the model has room to memorize the accounts one by one.
3. Too much flexibility. A model with a lot of freedom to bend will draw a line that passes through every point it's given, however the points are scattered. With 500 points and enough freedom, that line ends up describing those 500 accounts rather than describing spam.

Fixes usually start with the data. Collect more if you can, cut features if you can't, and simplify the model if the gap survives both. The diagnosis itself is just the distance between two scores. Ninety-eight on training against 71 on the held-back slice is overfitting; 68 against 68 is the opposite failure, a model too simple to have found the rule at all.

It's the first question asked whenever someone presents a model score. Any model built with supervised learning — taught on data that already carries the right answers — gets the question without exception, and the higher the score the harder the question. A report of 99 percent on the training data reads less as evidence of good work than as a prompt to check how the scoring was done.

The same question follows anywhere a score gets split into parts, as with precision and recall. Which data the two values were measured on comes first, because if they were measured on the training slice, neither number means anything.

The word travels outside machine learning too. Someone looking at a rule built by staring at last quarter's data will say the rule is overfit to last quarter. Picking out churn-risk accounts is a good example: gather every trait shared by the 30 teams that churned last quarter and you end up with a rule carrying ten conditions, and whether that bundle also catches this quarter's churn is a separate matter. Analysis that slices one dataset in many directions until an interesting combination appears has the same flaw. The remedy is the one models use: hold back a period the rule was never built on, and see whether it still catches anything there.

"Ninety-eight on training, 71 on validation. Let's look at overfitting first."

The gap between the two scores is wide, which means the model isn't usable on new data.

"Forty features for 500 accounts? It would be strange if it weren't overfit."

The input count is too high for the amount of data, so the cause is structural rather than a tuning mistake.

"I think this rule is overfit to last quarter. Let's check whether it still catches anything this quarter."

Hand-written rules have the same problem as models, so the rule needs testing on a different period.

Reviews of Pagedeck's spam model are the standard setting for this. When Theo brings the score for a new version, the first thing Mia asks is not the number but which data it came from. If training and validation sit within ten points of each other the review moves on; past twenty points, the feature list gets opened on the spot. Last time the culprit was a feature for account creation time. The work of labeling spam accounts had been concentrated in a few particular weeks, so the model had learned to read any account created in those weeks as spam.

The most common mistake is treating a high score as a good model. A score exists to measure how well the work went, so higher looking better is a natural reading. But a score can't be read at all without knowing which data produced it. A perfect 100 on the training data means nothing, and may well be a signal that the model memorized instead of learning. The useful question is what it scored on records it had never been shown. Skip that distinction in reporting and you will wave through a model whose performance collapses the week it ships.

The other frequent mistake is assuming simplification is the cure. Excess flexibility is one cause, so moving the other way sounds like the answer — except that a model too simple never finds the rule. Cut the spam model down to a single feature and training and validation both settle at 62. The gap is gone and so is the model's usefulness. Hold on to simplification as the answer and a shrinking gap starts to look like progress, which is how a model nobody can deploy ends up in a release meeting.