A classifier that predicts the majority class every single time, on data that is 90% majority, scores 90% accuracy. It has also learned nothing. That's the whole problem with imbalanced learning in one sentence — and the uncomfortable part is that a model doesn't have to be that degenerate to fail the same way. It only has to be a little lazy, and a skewed loss function will reward the laziness.
The lab above retrains the same linear classifier five ways on the same 9:1 training split — once untouched, then under class weighting, random oversampling, random undersampling, and SMOTE — and evaluates all five on the same held-out test set. Switch strategies and watch the accuracy bar barely move while the minority-recall bar swings.
The loss function doesn't know your class balance matters #
Logistic regression, like most classifiers, is fit by minimizing average loss over the training set. With 126 majority points and 14 minority points in the training split, a model that gets every majority point right and every minority point wrong still has a lower average loss than one that trades a few majority mistakes for a lot of minority correctness — because the average is dominated by whichever class has more rows. Nothing in the optimization objective knows that the minority class is the one you're building the system for. If it's fraud, tumor, or defect detection, the minority class is usually the expensive one to miss, and the loss function has no idea.
This is why "class imbalance" isn't really a data problem to be fixed once and forgotten — it's a mismatch between what the training objective optimizes and what the deployed system needs to get right, and every technique on this page is a different way of forcing that mismatch into the open.
Class weighting changes the loss, not the data #
The most direct fix leaves the dataset untouched and reweights the loss: multiply each minority example's contribution by , so the gradient from fourteen minority points carries as much total weight as the gradient from a hundred and twenty-six majority points. This is the strategy to reach for first, for a reason that has nothing to do with accuracy: it doesn't fabricate or discard a single observation. Every gradient step is still computed from real, measured data — the only thing that changes is how much each row's error counts.
It's also computationally free compared to the resampling alternatives — no new rows, no larger training set, no synthetic point generation. class_weight='balanced' in scikit-learn's classifiers, and the scale_pos_weight or is_unbalance parameters in XGBoost and LightGBM, are this exact idea, and they should usually be the first thing you try before reaching for a resampling library.
Oversampling and undersampling change the data, not the loss #
Random oversampling duplicates minority rows until the classes balance; random undersampling discards majority rows until they do. Both leave the loss function's arithmetic untouched — a plain average over a training set — and instead change what's in that average.
They fail differently. Oversampling by duplication doesn't add information: the classifier sees the same fourteen minority points repeated roughly nine times each, so its decision boundary can still only respond to fourteen distinct locations in feature space, weighted more heavily. It's mathematically close to class weighting for a linear model trained on the full-batch gradient — which is worth confirming yourself in the lab: switch between "Class weights" and "Random oversampling" and watch how close the decision surface and the metrics land. The two are not identical (oversampling's repeated rows interact with any per-example regularization or with mini-batch sampling in a way weighting doesn't), but for full-batch linear regression the closeness is not a coincidence.
Undersampling is the one to be careful with. Dropping majority points to match fourteen minority points throws away real, informative examples of the majority class — in this lab, roughly 112 of them. For a linear boundary in two dimensions that's rarely fatal, but scale this up to a high-dimensional feature space and undersampling can quietly erase the majority class's boundary regions, the examples that would have taught the model where the true decision surface bends. Undersampling is the right call when the majority class is so large that keeping all of it is a computational problem, not a statistical one — and a bad default otherwise.
SMOTE synthesizes new points instead of repeating old ones #
SMOTE — Synthetic Minority Oversampling Technique — targets the specific weakness of duplication: instead of copying an existing minority row, it interpolates between two of them, generating a new point somewhere on the line segment connecting them. Toggle "Show synthetic points" in the lab and the dashed rings are exactly that: none of them are measurements, all of them are linear interpolations between real minority observations.
This genuinely adds coverage that duplication can't — the classifier now sees minority-labeled examples in the gaps between the original fourteen points, not just repeated copies of them. It is also exactly where SMOTE can go wrong on real data: if the two interpolated points straddle a region where the true minority manifold is actually curved, concave, or interrupted by majority territory, the synthetic point can land somewhere the minority class never actually occurs. On this lab's two well-separated Gaussian-ish blobs that risk is low — the interpolated points stay inside a plausible minority region. On real, high-dimensional, non-convex class distributions, "SMOTE and hope" is a documented way to manufacture data that quietly misleads the classifier, which is why serious use of it comes with nearest-neighbor variants (Borderline-SMOTE, ADASYN) that are more careful about where they interpolate.
The metric you optimize for is a decision, not a default #
Every strategy here was evaluated on accuracy, balanced accuracy, minority precision, minority recall, and F1 — deliberately, because accuracy alone is close to useless on a 9:1 split and the lab's bar chart is built to make that visible directly. Balanced accuracy — the average of recall on each class — doesn't collapse the way plain accuracy does when the majority class is trivial to predict. Precision and recall on the minority class tell you two different kinds of expensive mistake: recall answers "of the real positives, how many did the model catch," precision answers "of the positives the model flagged, how many were real." Which one costs more in production is a business question, not a modeling one, and it should be decided before you pick a resampling strategy, not after — because oversampling, undersampling, weighting, and SMOTE each move the precision/recall trade-off in a different direction, and "which technique is best" has no answer independent of which of those two mistakes you're trying to avoid.