Training and Test Sets

Imagine a model that gets every single training example right. It feels like a success, and it is tempting to call the job finished. In supervised learning, that feeling is misleading. A model exists to make predictions about cases it has never seen, and a perfect score on the cases it already studied says little about that goal.

The belief behind the temptation goes like this: if a model is 100 percent accurate on the training set, it will also work well on new data. The belief feels reasonable because we normally build a model so that it predicts the training data accurately, and we hope that accuracy carries over. That hope is often justified when the training data and the new data have enough in common. The trouble is that the training score alone cannot tell us whether the hope is justified in a particular case. This article shows how to tell the difference.

The practical response to the problem is to keep some data out of training. The data we have is divided into two parts. The training set is the part the model learns from. The test set is held back, so the model never sees it during learning. The test set plays the role of unseen data, which lets us measure performance on examples the model has not been shown.

The diagram shows the flow. The model learns only from the training side. The test side waits until evaluation, where the model's predictions are compared with answers it has not seen. Only the test side can tell us whether the model's behavior carries over beyond the examples it studied.

To see the problem in action, consider a model that does nothing clever. It stores each training customer's age together with the answer. When asked about an age it does not recognize, it simply says no. Before reading on, make a prediction about this model's score on the training data.

The memorizer scored perfectly, yet it has learned nothing that would help with a customer it has not seen. This is the core of the correction. A training score measures how well a model reproduces answers it was shown. Generalization measures how well it predicts answers it was not shown. The two can differ enormously.

Generalization is a property the training score cannot report on its own. A model can be flawless on the examples it studied and still have no ability to predict new cases. For that reason, a model is judged on examples held back from training, not on the examples it already knows.

A novice data scientist wants to predict whether a customer will buy a boat, using records of past boat buyers and customers known not to be interested. The goal is to send promotional emails only to people who are likely to purchase. After studying the records, the scientist proposed this rule: if the customer is older than 45 and has fewer than 3 children or is not divorced, then they want to buy a boat. Asked how well it works, the scientist said it is 100 percent accurate.

There is also a way to fit the table perfectly without finding any real rule. Because no age appears twice in the data, one could list the ages of the boat buyers and declare that exactly those people want a boat. That rule is also perfectly accurate on the table, but it is memorization with a different label on it. Many rules can explain the training data perfectly, and perfect explanation of the training data is not the same as a rule that works on new customers.

Model complexity is the lever that connects these ideas. The source explains that if we allow ourselves to build very complex models, we can always be as accurate as we like on the training set. The complexity needed to chase every training answer is exactly what can break generalization. The two failures below sit at opposite ends of a complexity range, and a model that generalizes well lies somewhere between them.

The comparison below lays the two failures side by side. Read each column from top to bottom: the model's complexity, how well it fits the training data, and how well it predicts new data. Judge the model by the new-data column, not the training column alone.