Your Test Set Is Not a Feedback Loop: How to Keep Model Evaluation Honest

Quick answer

Training data fits the model. Validation data helps you choose between options. The test set is held back for one final check.

Picking settings by looking at test scores turns the test set into part of development, even if you never train on its rows.

If the test result disappoints, report it and investigate. Don't keep tuning against the same test set until the number looks better.

You're building a classifier. You split your data into training and test sets, train a model, and check the test score. It's a bit low, so you change a setting and check again. Then you change another setting and check again.

After a dozen rounds, you have a score you like. You report it. Everyone is happy.

But something has gone wrong, and it's easy to miss. The test set has stopped being a test. It has been helping you make decisions all along.

Why read this? Because this is one of the most common mistakes in machine learning, and it's exactly the kind of thing interviewers ask about. Getting it right is a quiet way to stand out.

Try this before reading on

Imagine this process:

Split the dataset into training and test data.
Train a model.
Measure its test score.
Change one of its settings.
Measure the test score again.
Repeat until you find a result you like.

You never pass the test rows into the training function. So the question is:

Has the test set stayed independent of your choices?

Write down your answer and your reason before reading on.

Check your thinking

No.

Each test result shaped which settings you kept. The model never trained directly on those rows, but your development process was using information from them. So the final test score is no longer a clean, independent check of how well your method works.

Scikit-learn's documentation makes this point clearly. Tuning settings against the test set risks "leaking" knowledge of that data into the model selection, and the test score stops reporting how well the model generalises.

Three roles, three jobs

It helps to give each part of your data one clear job.

Training data fits the model. The model learns its parameters from these examples.

Validation data helps you compare choices during development. For example, which setting to use, or which candidate model looks best.

Test data is held back for one final evaluation, after your development choices are finished.

Be careful with the names. Calling a variable X_test doesn't make it independent. What matters is the job the data is doing. If you keep checking results on it while you make choices, it's no longer a test.

Even validation data can be overused. If you compare hundreds of settings on the same validation set, you can overfit to it too. Treat validation feedback as a guide, not a guarantee.

Follow the arrows

Here's the loop to avoid:

Train a candidate
       ↓
Check the TEST result
       ↓
Change the settings
       ↓
Check the TEST result again
       ↓
Keep the best-looking candidate

Once the test results are part of the choosing, the final number can no longer be trusted as an honest estimate.

Here's a cleaner separation:

Training data        → fit the candidates
       ↓
Validation data      → compare and choose
       ↓
Finalise the approach
       ↓
Test data            → one final evaluation

The split still has to suit your task and data. The separation is the important part.

Where cross-validation fits

Instead of using one fixed validation split, cross-validation repeats the process on different portions of your development data.

In the basic version, called k-fold cross-validation:

You divide the development data into k folds.
You train on k minus 1 folds.
You validate on the one fold left out.
You repeat until each fold has been the validation fold once.
You average the results.

Cross-validation gives a more stable view of your options, especially with small datasets. You still hold back a separate test set for the final check.

Cross-validation doesn't give you permission to keep selecting models by looking at that final test set. It's a better tool for choosing, not a way to make the test set reusable.

A second scenario

You compare several settings using cross-validation on your development data. You pick one, then score it on the held-out test set. The result is lower than you hoped.

What should you do?

A. Hide the result.
B. Keep changing settings against the same test set until the score improves.
C. Report the result, and investigate the limitations.
D. Rename the test set and report your highest earlier score.

Choose before reading on.

The answer

C is the responsible starting point.

A disappointing result is still useful information. Investigate possibilities such as:

Differences between your development data and your test data.
A split strategy that doesn't match how the data really behaves.
Overfitting during model selection.
Problems with labels or preprocessing.
Uncertainty from having limited data.

These are paths to investigate, not causes that a single score can prove.

Now the important part. If you use the test findings to change your model, that test set has now helped shape development. Be open about this. If you need a fresh, honest estimate, you may need new held-out data.

Don't keep tuning and then describe the test set as untouched. That's the mistake this whole post is about.

Remember the earlier data-leakage post?

In the data leakage post, the concern was about preprocessing learning from the wrong rows. Here the concern is different. Even when preprocessing is done correctly, test results can still steer your choices.

So ask two questions:

Which data influenced the fitting?
Which results influenced my choices?

Both matter. A clean pipeline doesn't protect you from the second problem.

An interview follow-up

"Does cross-validation automatically solve leakage?"

No. Cross-validation helps with choosing and estimating performance, but you still need to check:

Whether preprocessing is fitted inside the training folds.
Whether every feature is available when you'd make a real prediction.
Whether related records cross the boundaries between folds.
Whether the split matches how the model will be used.

For example, time-ordered data needs a split that respects time. Grouped data, such as several records from the same customer, needs splits that keep each group together. Ordinary random folds can quietly inflate your score in both cases. Choose the method based on the problem, not on habit.

Explain it in your own words

Try this without looking:

"Training data fits the model. Validation results guide my choices. The test set is held back for the final check. If I keep choosing settings using test results, the test set has influenced development, even though I never trained on its rows."

The reasoning matters more than memorising the wording.

Apply it to your own project

Fill in this table for your current project:

Decision	Which data or results influenced it?
Model choice	Your answer
Hyperparameter settings	Your answer
Feature selection	Your answer
Preprocessing choices	Your answer
Final reported result	Your answer

Then ask yourself: have I used the same data both to choose my approach and to present an independent result?

If the answer is yes, review your evaluation design before you make any strong claim about performance.

A quick checklist

Is the test set used only once, at the end?
Do my choices come from validation results, not test results?
Did I report a disappointing test score, rather than tuning until it improved?
Does my split respect the time order or the groups in my data?
Have I checked that preprocessing and features only use what's available at prediction time?

A note on limits

A held-out test score is an estimate, not a promise about future performance. This post doesn't give one universal split ratio or cross-validation method. The right choice depends on your data, your task and how the model will be used. The scenarios here are fictional, and no experiment was run for this post.

Keep learning

Want to practise this until it feels natural?

Free machine learning practice sets: https://roy-s-ai-lab.vercel.app/topics/machine-learning. Set 3 covers evaluation and metrics, with an explanation for every answer.
Your model scored 95%. Better than what? https://roy-s-ai-lab.vercel.app/blog/your-model-scored-95-percent-better-than-what
Overfitting vs underfitting, explained simply: https://roy-s-ai-lab.vercel.app/blog/overfitting-vs-underfitting-interview
Full guides and scenario packs: https://roy-s-ai-lab.vercel.app/products

Try this: explain the three roles of data to a friend in one minute. If you can also say why a test score you've used to make decisions is no longer a fair test, you've got it.

Sources

Scikit-learn, "Cross-validation: evaluating estimator performance": https://scikit-learn.org/stable/modules/cross_validation.html
Scikit-learn, "Common pitfalls and recommended practices": https://scikit-learn.org/stable/common_pitfalls.html

The first source was checked for the test-set warning and the time-series and grouped-data guidance. The second was not opened during this check. The scenarios, checklist and project worksheet are original teaching material.

Ritesh Rai