Nested Cross-Validation

Searching many model settings is itself a form of learning from data. Even when every candidate uses cross-validation, choosing the candidate with the best score favors settings that benefited from random variation in those validation folds. Reporting that winning score as a fresh performance estimate can therefore be optimistic. Nested cross-validation separates selection from evaluation. Start with an outer split. Set aside its test fold and conduct the entire search using only the outer training data. Inner cross-validation compares the candidate settings. Refit the selected configuration on the outer training data, evaluate it once on the outer test fold, and repeat this process for the other outer folds. The outer scores evaluate a procedure: the model family, search space, preprocessing and selection rule used together. Different outer folds may select different settings. That is expected, because their training data differ. The result is not a competition in which you simply deploy whichever outer-fold model achieved the highest test score. Preprocessing belongs inside the procedure. A scaler, imputer or feature selector fitted on all examples before splitting can leak information. Scikit-learn's Pipeline helps keep these operations attached to model fitting, while GridSearchCV can perform the inner search. The split strategy must also match the intended use. Repeated records from one customer may need group separation. Forecasting requires respect for time order. Nesting an unsuitable random split does not repair that design problem. After evaluating the fixed procedure, perform its selection step on the available development data and fit a final model. Preserve a separate test set if the project uses one. Repeatedly changing the procedure after inspecting outer scores can turn the outer evaluation into another tuning process.