Testing Honestly

You have built a model, trained it for many epochs, and watched the loss fall. Now comes the moment of truth: how well will it actually perform when it meets data it has never seen before? Answering that question honestly — without accidentally cheating — turns out to require careful discipline. This lesson is about why honest evaluation is harder than it looks, and how to do it right.

The Three Splits: Train, Validation, Test

Most machine learning projects divide their labeled data into three non-overlapping parts, each with a distinct role. Training set: the data the model learns from. Weights are updated based entirely on this set. It is typically the largest portion — often 70-80% of all data. Validation set (also called the development set or dev set): a held-out slice the model never trains on, used during development to check for overfitting and to make decisions like when to stop training, or which hyperparameters to try next. Typically 10-15% of data. Test set: the final exam. The model sees this data exactly once — after all training decisions have been made and the model is declared done. Its performance here is the honest, reported result. Typically 10-15% of data. The critical rule: the test set must never influence any training decision. The moment you look at test-set performance and use it to adjust anything — you have contaminated the test set, and your reported result is no longer honest.

Here is a concrete scenario showing how cheating sneaks in. You train a model. You evaluate it on the test set — 72% accuracy. You feel it is not good enough, so you adjust a hyperparameter and retrain. You check the test set again — 75%. You keep iterating until the test set shows 91%. Here is the problem: those 91% means almost nothing now. By repeatedly checking the test set and making decisions based on it, you have effectively trained on the test set. The model has been indirectly optimized for those specific examples. When it meets truly unseen data in production, it will likely perform far worse than 91%. The solution is the validation set: make all tuning decisions based on validation performance. Save the test set for a single final evaluation. Report that number. Done.

Data Leakage: A Subtler Contamination

Data leakage is when information from the test set (or future data) sneaks into the training process in a way you did not intend. It is the most dangerous trap in applied machine learning — because the model looks great until it hits the real world. Example: you have medical data. Before splitting into train/test, you compute the average age across all patients and use it as a feature. The average includes test-set patients, so the test set has quietly influenced the training features. Result: inflated performance that disappears in production. Prevention: always split your data first. Only then compute statistics, normalize features, or perform any processing — and compute them using only the training set. Apply the same transformation to the validation and test sets, but never fit those transformations on them.