Table of Contents
What you are checking for and why it matters
In the first end to end models you build, the most common failure mode is not a crash, it is training that looks plausible but does not generalize. Basic overfitting and underfitting checks are quick, repeatable observations you can make from training and validation behavior to decide whether your model is too simple, too flexible, trained for too long, or trained with the wrong settings. You are not trying to perfectly diagnose everything yet, you are trying to answer a few practical questions: is the model learning anything, is it learning the training set only, and what simple change is most likely to help.
The core signal, compare training vs validation
The simplest check is to watch both training loss and validation loss across epochs, using the same loss function for both. A healthy pattern is that both decrease at first. After that, they may flatten. Overfitting shows up when training loss keeps decreasing while validation loss stops improving or starts increasing. Underfitting shows up when both training and validation losses remain high and improve slowly or not at all.
Rule of thumb: if training improves and validation worsens, suspect overfitting. If neither improves much, suspect underfitting or an optimization issue. Always compare training and validation on the same scale and computed the same way.
Accuracy and other metrics follow the same idea. Training accuracy rising while validation accuracy stalls or drops is the metric version of overfitting. For regression, look at metrics like MAE or RMSE in both splits, the gap between them is often more informative than the absolute number early on.
Reading the generalization gap
A useful quantity is the generalization gap, the difference between validation and training performance. For losses, you often look at
$$\text{gap} = L_{\text{val}} - L_{\text{train}}.$$
A small gap with high losses suggests underfitting. A large positive gap suggests overfitting. This is not a strict formula for decisions, but it helps you reason consistently when you change one thing at a time.
If $L_{\text{train}}$ is low and $L_{\text{val}}$ is much higher, do not celebrate the low training loss. Your model is likely memorizing patterns that do not hold in validation.
Common patterns you will see in curves
A frequent beginner pattern is rapid drop in training loss in the first few epochs, followed by steady improvement in training, while validation loss bottoms out early and then climbs. That is classic overfitting, and the fastest response is often to stop earlier and keep the best validation checkpoint.
Another pattern is both training and validation losses decreasing very slowly and staying high. That is often underfitting, but it can also be learning rate issues, incorrect labels, mismatched output and loss, or data preprocessing problems. At this stage, you can still treat it as underfitting until you have evidence of a bug, then try increasing model capacity or training longer.
A third pattern is noisy validation curves that bounce up and down. This can happen with small validation sets, small batch sizes, or high learning rates. In that case, focus on the trend over multiple epochs and consider averaging metrics over an epoch consistently.
Minimal interventions for overfitting
When you suspect overfitting, start with the interventions that keep your workflow simple. The first is early stopping by selecting the epoch with the best validation loss, not necessarily the last epoch. Another is reducing model capacity, for example fewer layers or fewer hidden units in an MLP. You can also add regularization such as weight decay or dropout, but those are covered in dedicated chapters, so for now treat them as options you can turn on and test.
Data also matters. More data, better augmentation for images, or cleaner labels usually helps, but for your first models the key check is whether the model is simply too flexible relative to the dataset size.
Do not tune on the test set to “fix” overfitting. Use only training and validation during development, and keep the test set for a final, one time evaluation.
Minimal interventions for underfitting
When you suspect underfitting, you are usually looking for more learning power. The simplest levers are to train longer, increase model capacity, or adjust the learning rate if training is barely moving. If both training and validation losses are high but decreasing steadily, training longer may be enough. If they plateau early at a high value, the model might be too small, the features might be poorly scaled, or the learning rate might be inappropriate.
A quick sanity step is to see whether the model can fit the training data at all. If you cannot get training loss down with enough epochs and a reasonable learning rate, that suggests underfitting or a setup issue.
A quick “can it memorize” check on a tiny subset
A powerful check that takes only minutes is to train on a very small subset of the training data, such as 32 to 256 examples, and see if the model can drive the training loss near zero or reach very high training accuracy. If it cannot, something is preventing learning, such as a bug in the training loop, wrong targets, wrong output shape, an unsuitable loss, or too strong regularization. If it can memorize the tiny subset but fails to generalize, that points back to overfitting rather than a fundamental learning bug.
If your model cannot overfit a tiny batch, do not start tuning architecture. First suspect a mistake in data, labels, loss, or the training loop.
Keep evaluation consistent, use the right model mode
When you compare training and validation, you must compute them under consistent conditions. In PyTorch, remember that some layers behave differently during training and evaluation, such as dropout and batch normalization. During validation you should switch to evaluation mode, then switch back to training mode afterward, otherwise your curves can lie to you.
Validation metrics should be computed with the model in evaluation mode, and without gradient tracking. Training metrics should be computed with the model in training mode.
Making the decision: what to try next
After you run your first model, summarize it with three observations: the best validation score, the epoch where it happens, and the gap between training and validation at that point. If the best validation happens early and then degrades, favor early stopping or reduced capacity. If both are poor, favor more capacity or better optimization settings. If curves are unstable, favor checking your data split size, batch size, and learning rate before making big architectural changes.
These checks are deliberately basic, but they are enough to keep you from wasting hours tuning in the wrong direction and to build the habit of using learning curves as a debugging tool, not just a progress indicator.