Manual hyperparameter optimization is the process of adjusting a model’s settings, training it, and comparing its results until you find a configuration that works well for your task. It can help improve predictive performance, control overfitting, and make training more efficient without requiring an automated search system.
Before you begin, define what “works well” means, prepare a reliable validation setup, and choose a small set of settings to investigate. Keep your test data separate until you have finished tuning; repeatedly checking it can make it part of the optimization process and leave you with an overly optimistic estimate of performance.
What You’ll Need
- A prepared dataset with separate training and validation data, or a suitable cross-validation plan.
- A baseline model and a working training pipeline that you can run consistently.
- A primary evaluation metric that matches the task, such as a loss, error measure, or classification score.
- A way to record each run’s settings, validation result, and relevant notes.
- Enough compute and time to train and compare several configurations.
- A final test set that will remain untouched during tuning, when the data setup allows one.
Step-by-Step
- Define the goal and constraints. Identify the outcome you need to improve, and decide which metric will guide decisions. For a classification problem, accuracy may be appropriate when classes are balanced and errors have similar costs; with class imbalance or different error costs, another measure may be more informative. For regression, choose a metric that reflects the size and type of errors that matter. Also note practical limits such as training time, memory, inference speed, and model complexity. A configuration that slightly improves a score but cannot run within your constraints may not be useful.
- Make the evaluation setup dependable. Split data before fitting preprocessing steps. Learn transformations such as scaling, imputation, or feature selection from training data only, then apply the fitted transformations to validation data. This prevents information from the validation set leaking into training. If observations are related, ordered in time, or grouped by subject, use a split strategy that respects that structure. A random split can give misleading results when related examples appear on both sides.
- Train a baseline. Start with a simple, reasonable configuration and run the full pipeline. Record the metric, training duration, and any signs of instability. This establishes a reference point and checks that the data, metric, and training code behave as expected. Save the model or its settings if you need to reproduce it. Avoid changing the data pipeline and model settings at the same time: if the result shifts, you will not know which change caused it.
- Choose a short list of influential hyperparameters. Hyperparameters are choices made before or during training rather than values learned directly from the training data. Depending on the model, examples include learning rate, regularization strength, tree depth, number of leaves, batch size, or the number of training rounds. Begin with settings that are known to have a substantial effect for your model family. Do not try to tune every available option at once. Fix settings that are not central to the current experiment, and write down the values you are holding constant.
- Set sensible candidate values. Use the model’s documentation and the scale of the problem to choose a few plausible values for each setting. For a setting that acts multiplicatively, such as a rate or penalty, compare values spread across a scale rather than only making tiny linear changes. For a setting that counts objects or layers, compare a small number of practical choices. Keep all other conditions consistent. If the model is stochastic, use the same seed where appropriate for a first comparison, then check promising configurations with more than one seed if run-to-run variation could affect the choice.
- Change one factor at a time at first. Run a controlled comparison in which one hyperparameter changes while the others stay fixed. This makes it easier to interpret the result and identify a useful direction. For example, if you are testing regularization, keep the data split, features, training budget, and other model settings unchanged. Once you understand the effect of individual settings, test combinations: some parameters interact, so the best value for one may depend on another.
- Keep a clear experiment log. For every run, record the exact settings, data split or fold, random seed if used, metric, training duration, and any warnings. A spreadsheet or plain-text table is enough. Label failed or interrupted runs too, so you do not accidentally repeat them. Save configuration files or scripts alongside results when possible. A brief note such as “validation loss rose while training loss fell” can be as useful as the final score.
- Use learning curves to diagnose behavior. Compare training and validation results over training, not just at the final step. If both results are poor, the model may be underfitting, the features may be weak, or the training setup may be inadequate. If training performance improves while validation performance stalls or worsens, overfitting may be occurring. Consider stronger regularization, a simpler model, more representative training data, or early stopping if supported. Do not automatically train longer when validation performance is already deteriorating.
- Narrow the search around promising settings. Once a candidate performs better than the baseline, test nearby values rather than restarting broadly. For example, if a moderate learning rate is more stable than a larger one, compare a couple of smaller alternatives. Keep a record of why you narrowed the range. If results are close, account for training noise and practical costs instead of declaring a meaningful winner based on a tiny, unstable difference.
- Confirm the leading configuration. Re-run the most promising settings under consistent conditions. If training is stochastic, compare results across several independent seeds or validation folds where feasible. Use the same evaluation procedure for each candidate, and report variation as well as the best observed result. This helps distinguish a reliably good configuration from one that won by chance. If you have made many comparisons on a small validation set, be cautious: repeated tuning can overfit that set, too.
- Evaluate once on the held-out test data. After selecting settings using training and validation data, fit the chosen pipeline according to your planned procedure and assess it on the untouched test set. Do not adjust hyperparameters in response to that test result and then present the same result as an independent final evaluation. If the test result reveals a problem that requires changes, treat the test set as no longer untouched and arrange a new independent evaluation if one is available.
- Save the full result so it can be reproduced. Store the hyperparameters, preprocessing choices, feature definitions, data split method, metric, random seed where relevant, and software or environment details needed to rerun the experiment. Keep the final model and its evaluation together. Reproducibility matters when the model is updated, reviewed, or used in a different environment.
Common Mistakes
- Tuning against the test set. Repeatedly checking test performance influences your choices, so it no longer provides a clean final check. Use validation data for tuning and reserve the test set for the end.
- Changing many things at once. Simultaneously altering the data split, feature processing, and several model settings makes cause and effect hard to identify. Change one factor during early experiments, then test combinations deliberately.
- Ignoring leakage. Fitting a scaler, feature selector, or imputer on all data before splitting can expose validation information to training. Fit each preprocessing step using training data within the evaluation pipeline.
- Choosing a metric by habit. A familiar metric may not reflect the actual task. Check whether class balance, unequal error costs, or the scale of regression errors makes another measure more appropriate.
- Trusting one lucky run. Random initialization, data order, and other stochastic elements can change a result. Repeat close comparisons or use cross-validation when practical.
- Overlooking resource costs. A model can score well but take too long to train or predict. Record time and memory alongside the metric when those constraints matter.
Tips
- Keep a baseline run and rerun it if you make substantial changes to the pipeline.
- Make a prediction about each experiment before running it. The result will teach you more if you know what question the run is meant to answer.
- Use the same data split and evaluation procedure when comparing candidates, unless the purpose of the experiment is to test a different validation strategy.
- Prioritize robust results over a tiny improvement that changes direction across seeds or folds.
- When compute is limited, use a smaller training budget to screen candidates, then fully train only the strongest ones. Confirm that the shorter budget does not systematically favor a different configuration.
- Check model-specific documentation for parameter definitions, valid ranges, and interactions. Defaults and parameter meanings differ across implementations.
Troubleshooting
Training fails or produces invalid values: Check input data for missing or non-finite values, confirm that labels and feature shapes match, and read the error or warning carefully. Verify that the selected setting is within the implementation’s accepted range. If a learning process is unstable, try a smaller learning rate or inspect feature scales, while changing only one likely cause at a time.
Training performance is good but validation performance is poor: This often points to overfitting, a mismatch between training and validation data, or leakage that has distorted earlier comparisons. Check the split and preprocessing pipeline, then consider stronger regularization, a simpler model, early stopping, or more representative training data. Make sure the validation set reflects the cases where the model will be used.
Both training and validation performance are poor: First confirm that the baseline can learn from the data and that the metric is calculated correctly. Inspect labels, feature usefulness, preprocessing, and whether the model is appropriate for the task. A larger model or longer training may help in some cases, but verify the learning curves before increasing complexity.
Results vary widely between runs: Record seeds and compare repeated runs under the same setup. Check whether the dataset is small or the validation split is unrepresentative. Use cross-validation or a more suitable structured split if appropriate, and prefer settings that perform consistently rather than relying on the best single score.
No setting clearly wins: The differences may be within normal variation, or the tested range may not include a useful value. Repeat the closest candidates, inspect the metric at an appropriate level of precision, and compare operational costs. If the results remain similar, choose the simpler or faster configuration and document the decision.
Frequently Asked Questions
What is the difference between a hyperparameter and a model parameter?
Model parameters are learned from training data, such as coefficients or split values. Hyperparameters are choices that shape the learning process or model structure, such as regularization strength or tree depth.
How many hyperparameters should I tune at once?
Start with one influential setting at a time so you can interpret the result. After identifying promising ranges, test a small number of combinations for settings that may interact.
Should I use a validation set or cross-validation?
A validation set is straightforward when you have enough representative data and a suitable split. Cross-validation can make better use of limited data, but it requires more training runs. For time-ordered or grouped data, use a split method that respects that structure.
When should I stop tuning?
Stop when further experiments do not produce a meaningful, repeatable improvement, or when additional gains are not worth the compute and complexity. Keep the test set reserved for the final evaluation.
Can I tune hyperparameters by looking only at accuracy?
Only if accuracy reflects the goal and the costs of different errors are comparable. Otherwise, choose a metric aligned with the task, and consider reporting additional measures to explain model behavior.
Is manual tuning better than an automated search?
Neither is always better. Manual tuning can be useful when you want to learn how settings affect a model or have limited compute. Automated methods can explore many candidates systematically, but still require a sound metric, data split, and experiment tracking.