During model development, what is the main purpose of a validation set?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Train, validate, test — don't mash them together. Training is where the model actually learns weights. Validation is your practice exam while you're still studying: pick learning rates, model size, features, early-stop epoch. Test is the sealed final you open once. If you peek at the test over and over to tune, you've basically studied the final — scores look great and then production hurts. Boss walks in asking why metrics collapsed live? Often someone overused the test set. Deduping rows? Different problem. Exam answer: validation tunes hyperparameters and model complexity decisions without burning the test set. Lock that triad in your head.
Full explanation below image
Full Explanation
A standard supervised workflow partitions data into training, validation, and test subsets, or uses cross-validation equivalents. The training set updates model parameters. The validation set estimates performance for model selection: comparing architectures, choosing regularization strength, selecting features, setting decision thresholds, and deciding when to stop training. Because many decisions are made using validation feedback, that estimate is mildly optimistic relative to truly unseen data—but it is far better than repeatedly consulting the final test set.
The test set should remain untouched until development choices are frozen, providing a one-shot estimate of generalization for reporting. Using the test set for tuning leaks information and invalidates the claim of an unbiased evaluation. Deduplicating warehouse records is a data-quality task performed before or during dataset construction; it is not the purpose of a validation split.
In practice, teams may use k-fold cross-validation when data are scarce, nested cross-validation when both model selection and evaluation must be rigorous, and time-based splits for temporal problems to avoid leakage. Regardless of mechanics, the conceptual role of validation remains intermediate evaluation for design decisions. Exam stems that mention hyperparameter tuning or complexity choices without contaminating the test set are pointing at validation. Stems about fitting parameters point at training; stems about final unseen performance after lock-in point at testing. Keeping those three jobs separate is both a best practice and a frequent multiple-choice target.
A concise checklist helps under time pressure: train to fit parameters; validate to choose among models and hyperparameters; test once to report honest generalization. Any option that assigns training, final scoring, or data cleaning to the validation set is mixing roles and should be rejected. Remember that validation is for decisions during development, not for the final published score and not for learning the weights themselves.