Class Imbalance
A dataset where one category vastly outnumbers the rest
- Class imbalance is when one of the categories you need to sort completely overwhelms the others in number.
- In that state, answering "the common one" every single time scores extremely high, even while missing the very thing you were trying to find.
- That's why accuracy, which only looks at the share correct, is nearly useless on imbalanced data.
- Training tilts the same way. The easiest route to a lower penalty is often giving up on the rare category entirely.
- Fixes exist on both the data side and the training side: match the counts, weight mistakes on the rare side more heavily, or shift the cutoff.
Contents
1The analogy
You're handed a bin of parts. Inside, it's mostly small screws, with a couple of thick bolts mixed in somewhere. Your job is to pick out the bolts hiding among them.
There's a very lazy way to do this. Without even looking in the bin, write down "all 100 are screws." Do that, and 98 out of 100 come out right. Judged purely on the share correct, that's an excellent score. But the actual job was picking out the bolts, and not a single one got done.
This is what happens with data where one category vastly outnumbers the rest. This kind of skew is called class imbalance.
The cost of missing that bolt shows up later. Put a bolt where a screw belongs and that one spot throws off the whole assembly. A score based purely on the count correct doesn't capture that cost at all.
2In detail
Why the score comes out so high
The share correct puts the whole set in the denominator. If there are 98 screws and 2 bolts, almost the entire denominator is screws. Get every screw right and the score climbs sky-high, and the cost of missing the bolts barely registers inside that denominator.
The more real-world the problem, the sharper this skew tends to be. Card fraud shows up in a handful of transactions out of ten thousand; machine failure is a tiny sliver of running time; a rare condition is what most people who get tested don't have. Often, the very thing that makes something worth catching is that it's rare.
Training leans toward the lazy route too
It isn't just people who go lazy. Training moves in whatever direction cuts the penalty fastest, and giving up on the rare category entirely is often that shortcut. Push hard to catch one bolt, and calling a few screws bolts by mistake actually raises the penalty instead.
So a model trained on imbalanced data looks like it learned well on the surface, but freezes up the moment the rare category shows up. Feed it anything, and it just names the common category, and a model like that hasn't learned so much as hardened into one answer.
What to look at besides the share correct
Pull the category you're actually hunting for out and look at two separate numbers. One is: of everything called a bolt, how much really was a bolt. The other is: of all the bolts actually in the bin, how many got found. The first is precision, the second is recall.
The lazy "all screws" answer bottoms out on both. Nothing was called a bolt, so the first number doesn't even exist; nothing was found, so the second number is zero. A failure that a single share-correct number hid entirely becomes obvious right away.
The two numbers pull against each other. Call anything even slightly thick a bolt, and recall goes up while plenty of perfectly good screws get flagged too. So the two get combined into one score, or weighed against each other based on which mistake actually hurts more.
Ways to ease the skew
Fixes exist on the data side. Gathering more of the rare category is best; when that's hard, lightly varying the rare examples already on hand to make more of them works too. Going the other way, taking only some of the common category to match the count, throws away information the common category holds, so it's only worth doing when data is plentiful.
Fixes exist on the training side too. Weighting mistakes on the rare category several times heavier means training can no longer take the shortcut of giving up on it. Lowering the cutoff for "let's call this a bolt" is another option, and it's the lightest touch of all, since it adjusts only the output, not the training itself.
3More precisely
Imbalance itself isn't a flaw. It's natural for a rare event to occur rarely, and forcing the ratio to look even actually makes the data less like the real world. The real problem comes from treating imbalanced data as if it were balanced, and grading it against a balanced yardstick.
That's why count-matching fixes belong to training data only. Touch the ratio in the grading data too, and the score is being measured against a stage that doesn't match the real situation. It won't hold up once it's out in the field.
The analogy breaks in one place. A screw and a bolt look obviously different, but in real data, the correct answer itself is often blurry. Because there are so few rare-category examples to begin with, a wrong label on even a handful of them does outsized damage. Getting the labels right on the rare-category examples one by one often matters more than growing their count.
The degree of imbalance also matters more than whether it exists at all. A split of 60 to 40 barely changes how a model needs to be handled, while a split of 999 to 1 demands real countermeasures. Checking the actual ratio before reaching for a fix keeps the effort proportionate to the problem.
4Try it yourself
5Common misconceptions
It's easy to think high accuracy means a well-trained model, but actually when one category overwhelms the other, an answer that does nothing at all scores a high accuracy.
It's easy to assume copying the rare category to match the count solves it, but actually a model that sees the same handful of examples repeated ends up memorizing those exact examples.
It's easy to think forcing the ratio to fifty-fifty is the right move, but actually leaving the ratio as it is in grading and real use is what keeps the score honest about reality.
7One-line summary
In shortClass imbalance is like a bin of screws with a few bolts hidden in it, one category overwhelms the rest, and it calls for a separate yardstick that checks the rare category directly, not just the share correct.
Spotted an error or have a better analogy? Suggest an edit · Last updated2026-09-02