# Is it OK to use the testing sample to compare algorithms?

I'm working on a little project where my dataset have 6k lines and around 300 features, with a simple binary outcome.

Since I'm still learning ML, I want to try all the algorithms I can manage to find and compare the results.

As I've read in tutorials, I split my dataset into a training sample (80%) and a testing sample (20%), and then trained my algorithms on the training sample with cross-validation (5 folds).

My plan is to train all my models this way, and then measure their performance on the testing sample to chose the best algorithm.

Could this cause overfitting? If so, since I cannot compare several models inside model_selection.GridSearchCV, how can I prevent it to overfit?

Basically, every time you use the results of a train/test split to make decisions about a model- whether that's tuning the hyperparameters of a single model, or choosing the most effective of a number of different models, you cannot infer anything about the performance of the model after making those decisions until you have "frozen" your model and evaluated it on a portion of data that has not been touched.

The general concept addressing this issue is called nested cross validation. If you use a train/test split to choose the best parameters for a model, that's fine. But if you want to estimate the performance of that, you need to then evaluate on a second held out set.

If you then repeat process for multiple models and choose the best performing one, again, that's fine, but by choosing the best result the value of your performance metric is inherently biased, and you need to validate the entire procedure on yet another held out set to get an unbiased estimate of how your model will perform on unseen data.

• Great answer too! So since this seems like an order 2 cross-validation (a cross-validation of cross-validations), should I pool my samples (70+15 according to Simon's answer) before I evaluate my final algorithm on the test sample? – Dan Chaltiel Apr 21 at 20:01
• With so few samples and features (relatively speaking) personally I would use multiple rounds of stratified k-fold cross validation, rather than holding a fixed set or sets out. The theoretical guarantees of evaluating on held out data only hold in the limit of the number of samples. I'm working under the assumption that training and testing your model is not a huge deal in terms of time. I would do something like shuffling the samples within each class and setting aside each fold in turn, and for the inner loop, combine it all, split again, do your model selection, then yes, pool. – Cameron King Apr 21 at 20:48
• I forgot to mention here, this means that you are setting aside, say, 1/k points to test on, and dividing the 1-1/k remaining points into an inner cross validation run, but repeating this so that you are training, validating, and testing on every single data point at least once. With larger datasets and more time consuming models, deciding on splitting the data once into 3 partitions makes sense, but it will always be less robust than k-fold cross validation. develop with that method to save yourself time, that's a good idea, but when it comes to making decisions, don't cut corners. – Cameron King Apr 21 at 20:59
• This makes perfect sense, but have you ever heard of a standard way to automate this (like sklearn's GridSearchCV)? Doing it by hand seems quite tedious and error-prone to me. – Dan Chaltiel Apr 22 at 5:22
• Sklearn can absolutely do this, and their examples are pretty good for understanding how this is going to go for you. The link at the end uses KFold, and if you look at thedocs for that class you can set shuffle=True to randomize the splits. scikit-learn.org/stable/auto_examples/model_selection/… – Cameron King Apr 22 at 19:49

No, that is not the purpose of the test set. Test set is only for final evaluation when your model is done. The problem is that if you include the test set in your decisions your evaluation will no longer be reliable.

To compare algorithms you instead set aside another chunk of your data called the validation set.

Here is some info about good splits depending on data size:

Train / Dev / Test sets from Improving Deep Neural Networks: Hyperparameter tuning, Regularization and Optimization by Prof. Andrew Ng.

(Andrew uses the word dev set instead of validation set)

• I thought so but I couldn't read anything about this. Could you provide some material on which I could learn? Like about what a common splitting would be (70/10/20) ? – Dan Chaltiel Apr 21 at 16:22
• Depends on the size of your dataset. But I would say 70/15/15 would be good in your case. – Simon Larsson Apr 21 at 16:25
• I added a video on the subject. – Simon Larsson Apr 21 at 16:28