Hyperparameter Tuning
Scikit-learn Basics
3 min read
Published Nov 17 2025, updated Nov 19 2025
Guide Sections
Guide Comments
Every machine learning model in Scikit-learn has hyperparameters, configuration settings chosen before training.
They control the model’s structure or learning behavior (e.g., tree depth, regularisation strength, number of neighbours).
Unlike learned parameters (like weights or coefficients), hyperparameters are not learned from data.
Choosing them well can dramatically improve performance — and choosing them poorly can cause overfitting or underfitting.
Scikit-learn provides systematic, automated ways to search for optimal hyperparameter values:
- Grid Search (exhaustive search across predefined values)
- Randomised Search (sampling from parameter distributions)
- Bayesian Optimisation (via external libraries like Optuna — optional)
Parameters vs Hyperparameters
Type | Example | Set When | Learned By |
Model Parameter | Regression coefficients ( | During | The model |
Hyperparameter |
| Before training | You (via tuning) |
Example:
Here, max_depth and min_samples_split are hyperparameters that control model complexity.
Why Tune Hyperparameters?
Proper tuning ensures that:
- The model generalises better to unseen data
- Performance is optimised without overfitting
- You find the right bias-variance balance
Example:
A RandomForest with too few trees might underfit; too many could overfit or waste resources.
Hyperparameter tuning helps find the sweet spot.
Manual Search (Baseline Approach)
You can start by manually trying a few configurations and comparing validation scores:
Output:
This simple process can guide your initial hyperparameter ranges for grid or randomised search.
Grid Search (Exhaustive Search)
Grid Search evaluates every combination of parameter values across a specified grid. It’s thorough but can be slow on large grids.
Example: GridSearchCV
Output:
Notes:
cv=5→ 5-fold cross-validation.scoring='accuracy'can be replaced with any metric (f1,roc_auc,r2, etc.).n_jobs=-1uses all CPU cores for parallel computation.
After finding the best model:
Randomised Search (Efficient Sampling)
When the parameter space is large, RandomizedSearchCV samples random combinations instead of trying all possible ones.
This often finds good results faster and works well for large models (e.g., gradient boosting).
Example:
Output:
Notes:
n_itercontrols how many random samples to test.- You can pass distributions (
scipy.stats.randint,uniform) for continuous ranges. - Randomised search is ideal when grid search is too expensive.
Nested Cross-Validation (Advanced)
When hyperparameter tuning is part of model selection, nested cross-validation provides an unbiased estimate of generalisation.
It runs an inner loop for tuning and an outer loop for evaluation:
Output:
Why nested CV?
It avoids data leakage between tuning and validation by ensuring the outer test folds never influence hyperparameter choices.
Custom Scoring Functions
You can customise evaluation metrics for tuning by using make_scorer.
Example (optimise F1-score for binary classification):
Scikit-learn also provides built-in scoring names:
You’ll see metrics like 'accuracy', 'roc_auc', 'neg_mean_squared_error', etc.
Practical Tips for Efficient Tuning
- Start simple - Begin with a few important hyperparameters; expand only if needed.
- Use Randomised Search for large grids - Often finds comparable results much faster.
- Parallelise - Set
n_jobs=-1to use all available cores. - Use cross-validation - Ensures your tuning isn’t biased by a lucky train/test split.
- Cache results (optional) - Use
joblibto store models during search, especially for large datasets. - Monitor runtime - Some models (e.g., SVMs, gradient boosting) scale poorly with very large parameter grids.
Example: Full Tuning Workflow
Output:
When and How to Stop Tuning
- If tuning multiple algorithms, use a coarse search first to identify strong candidates.
- Once the best model type is known, refine with tighter parameter ranges.
- Avoid re-tuning endlessly, use validation performance as your stopping point.
- Keep test data fully unseen until final confirmation.














