TechByteByByte

Underfitting

When a model never learns the real pattern well enough in the first place — performing poorly even on its own training data, let alone anything new.

#underfitting#generalization#training#generalization-phase

The Overfitting article covered a model that learns its training data too well. This article covers the opposite, equally real failure: a model that never learns it well enough. That’s underfitting.

The simple definition

Underfitting happens when a model fails to learn the underlying pattern in the data well enough — performing poorly not just on new data, but even on the training data it was directly shown. Where an overfit model does great on training data and poorly on new data, an underfit model does poorly on both, because it never actually captured the real pattern to begin with.

Why this happens: too little capacity, or too little learning

There are two distinct routes to underfitting, both worth naming clearly since they call for different fixes. The first is insufficient model capacity — recall from the Parameters article that a model with too few parameters for a genuinely complex task simply lacks the room to represent the real pattern, no matter how well it’s trained; trying to fit a single straight line to data that actually curves will always underfit, regardless of how carefully that line is positioned. The second is insufficient training — too few epochs (as covered in the Epoch article), a learning rate poorly suited to the problem (as covered in the Learning Rate article), or simply not enough good training data (as covered throughout the Data Handling phase) to let the model discover the pattern that’s genuinely there to be found.

flowchart LR
    A[Model capacity too small, or training stopped too early] --> B[Model never captures the real pattern]
    B --> C[Poor performance on training data]
    C --> D[Poor performance on new data too]

ANALOGY vs. TECHNICAL REALITY

Analogy: Think of a student who only skims a textbook chapter once, briefly, the night before an exam. They haven’t memorized specific answers (that would be overfitting) — they simply never learned the material well enough at all, and it shows on the exam itself, not just on questions styled differently from what they briefly skimmed.

Where this breaks down: A student’s “not enough studying” is a matter of time and effort. A model’s underfitting can come from either insufficient training or an architecture that’s fundamentally too simple for the task — a distinction with no clean equivalent in the studying analogy, since a student’s brain doesn’t have a fixed, adjustable “capacity” the way a model’s parameter count does.

Underfitting and overfitting on the same chart

This is genuinely useful to see side by side, since the two failure modes sit at opposite ends of the same spectrum, with good generalization in between. Recall the training-versus-validation loss picture from the Overfitting article: an underfit model shows both training loss and validation loss staying stubbornly high, with neither improving much even as training continues — a very different, and honestly easier to diagnose, signature than the “diverging lines” pattern of overfitting.

flowchart LR
    A[Underfitting: both losses high, barely improving] --> B[Good fit: both losses low, close together]
    B --> C[Overfitting: training loss low, validation loss high]

A concrete example, layered

For a simple beginner example: trying to predict house prices using only a single straight-line relationship with square footage, when real prices actually depend on a more complex combination of location, age, and condition too, will underfit — the straight line simply can’t capture the real, more complex pattern, and will predict badly even for houses in the training set. For a production example: a fraud detection model trained for only a handful of epochs, or built with far too few parameters for the genuine complexity of real fraud patterns, might flag almost nothing as fraud and almost nothing as legitimate correctly, even on transactions it was directly trained on — a clear, measurable sign that the model simply hasn’t captured the real distinguishing pattern between fraudulent and legitimate transactions yet.

See underfitting with numbers

Suppose the task is to classify cats and dogs:

Model stateTraining accuracyValidation accuracyMeaning
Underfitting58%56%Poor on both known and unseen images.
Useful fit91%89%Learns the pattern and transfers it well.
Overfitting99%72%Excellent on training images, weak on unseen images.

The important clue for underfitting is low training performance. If the model cannot handle examples it already studied, we should not expect it to handle new examples.

Diagnose the cause before choosing a fix

flowchart TD
    A[Training performance is poor] --> B{Has training clearly converged?}
    B -->|No| C[Train longer or adjust learning rate]
    B -->|Yes| D{Can the model represent the pattern?}
    D -->|No| E[Use a more capable model or better features]
    D -->|Yes| F[Inspect data quality, labels and preprocessing]
  • If training stopped too early, add suitable epochs.
  • If the model is too simple, increase capacity or use a more suitable algorithm.
  • If useful information is missing, improve the Features.
  • If regularization is too strong, reduce it carefully.
  • If labels or preprocessing are wrong, fix the data pipeline before enlarging the model.

More training is not always the answer. A straight line cannot learn a circle-shaped boundary merely by seeing the same data for another thousand epochs.

Why underfitting is, in a sense, the easier problem

It’s worth being honest about a genuine asymmetry between these two failure modes. Underfitting is usually easier to both detect (poor performance shows up immediately, even on training data, with no need to wait and compare against a separate validation set) and fix (train longer, use a larger or more capable model, or improve the features available, as covered in the Feature Engineering article). Overfitting is often the trickier, more insidious problem in practice, precisely because a model that’s overfitting can look deceptively excellent right up until you specifically check its performance on new data — which is exactly why so much of this glossary’s Data Handling phase was built around making sure that check actually happens.

Common misconception

A frequent assumption, especially among beginners eager to avoid overfitting: that a smaller, simpler model is always the “safer” choice. As this article has shown, that’s not quite right — an unnecessarily small or simple model doesn’t dodge risk, it trades the risk of overfitting for the near-certainty of underfitting instead. Good generalization, as the Generalization article established, sits in a genuine middle ground between these two failure modes, not at either extreme, and finding that middle ground — the right capacity, trained for the right amount of time — is the actual goal, not defaulting to “small and simple” out of caution.

Where this fits in what comes next

You now have the complete picture of what can go wrong on either side of good generalization: overfitting (too closely fit to training data) and underfitting (not fit closely enough to anything). The next article, Regularization, covers a family of concrete techniques specifically designed to help a model land in the productive middle ground between these two extremes, rather than drifting toward either one.

In one sentence

Underfitting is what happens when a model never learns the real pattern well enough — showing up as poor performance even on its own training data — and it sits as the mirror-image failure mode to overfitting, with genuinely good generalization living in the balance between the two.

Author
TechByteByByte Editorial Team
Reviewed by
TechByteByByte Admin
Published
Last reviewed