Handling Imbalanced Datasets: SMOTE, Cost-Sensitive Learning and Evaluation

Working with imbalanced datasets is one of those problems that looks trivial on paper and becomes painful in production. I have seen models hit 99.2% accuracy while completely failing to detect the very events they were built to catch — fraud, churn, diagnostic positives, or equipment failure. When one class outnumbers another by 50:1 or 1,000:1, your model will learn to ignore the minority class unless you intervene deliberately. In this article, I will walk through the three levers I actually use in practice — resampling with SMOTE and its variants, cost-sensitive learning, and evaluation design — and show how to wire them together without leaking information or fooling yourself with the wrong metrics.

Why Accuracy Collapses When Minority Classes Starve

Class imbalance is not just a data skew; it creates an optimization bias. Most loss functions, like cross-entropy, minimize average error. If 98% of your training examples belong to class 0, a model that always predicts class 0 achieves 98% accuracy and a very low loss, so gradient descent has little incentive to learn the boundary around class 1. The result is a classifier with high accuracy and near-zero recall for the minority class.

In my experience, the failure mode is consistent across tabular, text, and even image problems. On a manufacturing defect detection project with a 120:1 imbalance, our initial XGBoost baseline achieved 0.97 ROC-AUC but only 0.08 precision-recall AUC for the defective class. The model had learned the prior, not the pattern. This is why resampling, reweighting, or threshold tuning is mandatory, not optional.

Before you apply any technique, quantify the imbalance properly. Look beyond the raw ratio:

Diagnosing the Imbalance Regime

I categorize imbalance into three regimes because each demands a different strategy. Mild (1:10 to 1:30) often responds to class weighting alone. Moderate (1:30 to 1:200) usually requires a combination of resampling and weighting. Severe (>1:200) almost always needs data-level generation, careful validation, and often anomaly detection framing. Also examine intra-class imbalance — within your minority class, there may be sub-clusters where some sub-concepts have only a handful of examples. SMOTE will struggle there without modification.

Another diagnostic I run early is to check feature overlap. Plot distributions of your most predictive features conditioned on class. If the minority class is heavily overlapped with the majority in feature space, synthetic oversampling will generate noisy, borderline points that hurt generalization. In those cases, I lean harder on cost-sensitive methods and on improving the representation itself, for instance through better Feature Engineering for Tabular Data: Encoding, Scaling and Selection Techniques before any resampling.

Finally, establish a baseline that is honest. Use stratified cross-validation and report a dummy classifier that predicts the majority class. If your model cannot beat a stratified dummy on PR-AUC or F2, you have not learned anything yet.

SMOTE Mechanics: Interpolating the Minority Manifold

SMOTE (Synthetic Minority Over-sampling Technique) does not simply duplicate minority examples. It creates new synthetic points by interpolating between a minority instance and its k-nearest minority neighbors. For a given minority sample x_i, SMOTE selects one of its k neighbors x_zi at random and generates a new point x_new = x_i + λ * (x_zi - x_i), where λ is sampled uniformly from [0, 1]. This linear interpolation assumes the space between nearby minority points still belongs to the minority class — a manifold assumption that holds well for dense, continuous feature spaces but breaks for categorical or highly discontinuous data.

In practice, SMOTE works best on tabular data with scaled numerical features after proper encoding. I have found that applying SMOTE directly on raw, unscaled data with mixed categorical variables produces synthetic samples that are nonsensical, especially if you one-hot encode without care. Use a variant like SMOTENC for mixed types, which handles categorical features by majority vote among neighbors.

from imblearn.over_sampling import SMOTE, SMOTENC
from sklearn.preprocessing import StandardScaler
from sklearn.model_selection import StratifiedKFold

# Assume X_train, y_train are your training split only
# Scale BEFORE SMOTE distance computations
scaler = StandardScaler()
X_train_scaled = scaler.fit_transform(X_train)

# For purely numeric data
smote = SMOTE(
    sampling_strategy=0.3,  # minority/majority ratio after resampling
    k_neighbors=5,
    random_state=42
)
X_res, y_res = smote.fit_resample(X_train_scaled, y_train)

# For mixed numeric + categorical (e.g., last 3 cols are categorical)
cat_features = [X_train.shape[1]-3, X_train.shape[1]-2, X_train.shape[1]-1]
smotenc = SMOTENC(
    categorical_features=cat_features,
    sampling_strategy=0.5,
    k_neighbors=5,
    random_state=42
)
# X_res2, y_res2 = smotenc.fit_resample(X_train, y_train)

Where SMOTE Fails Silently

SMOTE has two predictable failure modes I watch for. First, it can bridge across majority regions if minority points are isolated, generating synthetic points that invade majority territory. This increases false positives. Second, it densifies the minority region without adding new information — if your minority class has only 30 examples spanning several sub-concepts, SMOTE will amplify sampling noise rather than true variation. I mitigated this on a credit risk model by first clustering the minority class with k-means (k=4) and applying SMOTE within each cluster, which preserved sub-concept structure better than global interpolation.

For related generative thinking, the principles in Data Augmentation Techniques: From Image Transforms to Synthetic Generation are useful: the goal is plausible variance, not just more points. Always validate that synthetic samples improve recall at a fixed precision, not just recall in isolation.

Beyond Vanilla SMOTE: Borderline, ADASYN and Tomek Hybrids

Vanilla SMOTE treats all minority points equally. Several extensions adjust where synthesis happens, and choosing among them is where most of the engineering leverage lies.

Borderline-SMOTE focuses synthesis on minority points near the decision boundary — those that have a large fraction of majority neighbors. This is effective when you care about pushing the boundary outward without over-generalizing safe minority regions. I use it when my initial model shows the minority class is well-separated in some regions but confused in others.

ADASYN (Adaptive Synthetic Sampling) generates more synthetic points for minority samples that are harder to learn, weighted by the density of majority neighbors. It adaptively shifts the class distribution toward difficult examples. In my experience, ADASYN can be aggressive; on noisy datasets it will generate a lot of points around mislabeled or outlier minority examples and amplify noise. I prefer it when label quality is high and I have verified that hard examples are not mislabeled.

Hybrid resampling combines oversampling with cleaning. SMOTE + Tomek Links and SMOTE + ENN (Edited Nearest Neighbours) first oversample, then remove ambiguous points — Tomek Links are pairs of nearest neighbors from opposite classes, and cleaning them removes overlapping points. On a telecom churn dataset with 1:85 imbalance, SMOTE-Tomek reduced false positives by 18% relative to plain SMOTE at the same recall, because it cleaned up the synthetic points that had bled into the majority region.

from imblearn.combine import SMOTETomek
from imblearn.over_sampling import BorderlineSMOTE, ADASYN

# Borderline-SMOTE for boundary-focused synthesis
bl_smote = BorderlineSMOTE(
    sampling_strategy=0.4,
    k_neighbors=5,
    m_neighbors=10,
    kind="borderline-1",
    random_state=42
)
X_bl, y_bl = bl_smote.fit_resample(X_train_scaled, y_train)

# Hybrid: SMOTE + Tomek Links cleaning
smt = SMOTETomek(
    sampling_strategy=0.5,
    smote=SMOTE(k_neighbors=5, random_state=42),
    random_state=42
)
X_hybrid, y_hybrid = smt.fit_resample(X_train_scaled, y_train)

# ADASYN - use when minority examples are clean
adasyn = ADASYN(sampling_strategy=0.5, n_neighbors=5, random_state=42)
X_ada, y_ada = adasyn.fit_resample(X_train_scaled, y_train)

Practical Rules for Choosing a Variant

My decision heuristic is pragmatic: if your t-SNE or UMAP projection shows tight minority clusters, start with vanilla SMOTE with k=5. If minority points are strung along the boundary, try Borderline-SMOTE. If you have confirmed noisy overlap after oversampling, move to SMOTE-Tomek. And if your minority class is extremely small (<50 samples), consider skipping resampling entirely and using cost-sensitive learning instead, because any synthetic generation will be fragile. For a deeper view on how projection methods can expose these structures, see Dimensionality Reduction: PCA, t-SNE and UMAP Compared.

Cost-Sensitive Learning Without Touching the Data Distribution

Cost-sensitive learning keeps the data distribution intact and instead tells the optimizer that mistakes on the minority class are more expensive. I prefer this approach when the dataset is large, when synthetic data risks violating feature constraints, or when operating in frameworks where resampling complicates the pipeline, such as streaming or on-device training.

There are three dominant mechanisms. At the loss level, you weight the loss contribution of each class. At the algorithm level, some models like tree ensembles allow direct class weights or balanced subsampling per leaf. At the decision level, you move the threshold after training based on calibrated probabilities. In practice, I often combine loss weighting with threshold tuning.

For logistic regression, SVM, and tree models in scikit-learn, class_weight='balanced' sets weights inversely proportional to class frequencies: w_j = n_samples / (n_classes * n_samples_j). For severe imbalance, I manually increase the minority weight beyond balanced, treating it as a hyperparameter. For XGBoost and LightGBM, the scale_pos_weight parameter plays the same role; a common starting point is scale_pos_weight = negative_count / positive_count, then tune around it.

import torch
import torch.nn as nn
from sklearn.ensemble import RandomForestClassifier
from sklearn.linear_model import LogisticRegression

# 1. Scikit-learn: balanced class weights
rf = RandomForestClassifier(
    n_estimators=500,
    class_weight="balanced_subsample",  # weights recomputed per bootstrap
    min_samples_leaf=5,
    random_state=42,
    n_jobs=-1
)
# rf.fit(X_train, y_train)

# 2. Manual weight tuning for severe imbalance (e.g., 1:100)
# Start at sqrt(neg/pos) to avoid over-penalizing, then grid search
logreg = LogisticRegression(
    class_weight={0:1, 1:10},  # tuned, not just balanced
    max_iter=1000
)

# 3. PyTorch: weighted cross-entropy
# See PyTorch Documentation for nn.CrossEntropyLoss weight semantics:
# https://pytorch.org/docs/stable/generated/torch.nn.CrossEntropyLoss.html
pos_weight = torch.tensor([25.0])  # for BCEWithLogitsLoss on binary task
criterion_bce = nn.BCEWithLogitsLoss(pos_weight=pos_weight)

class_weights = torch.tensor([1.0, 15.0])  # for multi-class
criterion_ce = nn.CrossEntropyLoss(weight=class_weights)

# Focal Loss variant (down-weights easy negatives) - often better than plain weighting
# when negatives are overwhelming and many are easy

Focal Loss and Effective Number of Samples

When the minority class is overwhelmed by easy majority examples, focal loss as described in the original RetinaNet work and widely documented in the PyTorch Documentation ecosystem helps by down-weighting well-classified examples: FL(p_t) = -α_t (1 - p_t)^γ log(p_t). With γ=2, a model that predicts 0.95 probability for a majority example contributes almost nothing to the loss, forcing focus onto hard, often minority, examples. I have found focal loss particularly useful for deep models on tabular and text data with 1:200+ imbalance where plain weighting still yields many false negatives.

Another principled weighting scheme is class-balanced loss based on the effective number of samples, where weights are proportional to (1 - β) / (1 - β^{n_j}). This avoids the extreme weights that inverse frequency can produce when n_minority is very small, and in my experiments it stabilizes training more than raw inverse counts. The original formulation is available via arXiv Machine Learning recent papers on class-balanced learning.

Evaluation That Actually Reflects Imbalanced Performance

If you evaluate an imbalanced model with accuracy or ROC-AUC alone, you will ship broken models. I have learned to treat evaluation as the most important part of the workflow — no amount of SMOTE or weighting matters if you cannot measure the trade-off you care about.

ROC-AUC is optimistic under imbalance because the false positive rate is computed over a huge number of true negatives. A model can have ROC-AUC of 0.90 while delivering precision of 0.12 at 0.80 recall. Precision-Recall AUC (average precision) is far more sensitive to the minority class. I report PR-AUC as the primary metric and supplement it with F-beta scores where beta reflects business cost. For fraud or disease detection where misses are far more costly than false alarms, I optimize for F2 (which weights recall higher than precision) rather than F1.

Always look at the confusion matrix at multiple thresholds, not just at 0.5. A good diagnostic is the precision-recall curve with the operating point annotated for each proposed threshold. I also run a cost curve: define Cost = C_FN * FN + C_FP * FP and plot how cost changes with the threshold. This makes the business trade-off explicit to stakeholders.

Calibrated Threshold Tuning

Resampling and weighting shift predicted probabilities. After applying SMOTE, your model will output probabilities that are no longer calibrated to the original prevalence — it will overestimate minority probability. If you need probabilities for downstream decisions, recalibrate with isotonic regression or Platt scaling on a held-out validation set that has not been resampled. Then tune the decision threshold on that same unaltered validation set using the F-beta or cost metric you care about. I have seen teams tune thresholds on SMOTE-augmented validation data and then be surprised when live precision collapses; that is textbook leakage.

Building a Leak-Free Imbalanced Learning Pipeline

The single most common technical error I see is leakage from applying SMOTE before the train-validation split. If you oversample and then split, synthetic points derived from validation-adjacent training points bleed information across the fold, and your cross-validation scores become unrealistically high. The rule is non-negotiable: split first, then resample only the training folds inside the cross-validation loop.

This is where pipelines matter. Use imbalanced-learn’s Pipeline, which correctly applies resampling only to training splits during cross-validation. Also ensure that all preprocessing that learns parameters — scaling, imputation, encoding — is fitted only on training data inside the same pipeline. That includes Missing Data Imputation: Statistical, ML-Based and Multiple Imputation Methods; fitting an imputer on the full dataset before splitting leaks minority distribution information just as surely as premature SMOTE does.

from imblearn.pipeline import Pipeline as ImbPipeline
from sklearn.preprocessing import StandardScaler
from sklearn.impute import SimpleImputer
from sklearn.ensemble import HistGradientBoostingClassifier
from sklearn.model_selection import StratifiedKFold, cross_validate
from imblearn.over_sampling import SMOTE

# Leak-free pipeline: impute -> scale -> SMOTE -> model
# SMOTE is only applied to training folds during CV
pipe = ImbPipeline(steps=[
    ("imputer", SimpleImputer(strategy="median")),
    ("scaler", StandardScaler()),
    ("smote", SMOTE(sampling_strategy=0.4, k_neighbors=5, random_state=42)),
    ("clf", HistGradientBoostingClassifier(
        class_weight="balanced",  # combine resampling + weighting carefully
        learning_rate=0.05,
        max_depth=6,
        random_state=42
    ))
])

cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
scoring = {
    "pr_auc": "average_precision",
    "f2": "fbeta_score",  # configure beta=2 via make_scorer in practice
    "roc_auc": "roc_auc"
}
results = cross_validate(
    pipe, X, y,
    cv=cv,
    scoring=scoring,
    n_jobs=-1
)
# Aggregate: results["test_pr_auc"].mean() is your honest estimate

When Not to Oversample at All

In my experience, there are cases where the best action is to not oversample. If you have high-cardinality categorical features, very high dimensional sparse data, or extremely few minority samples (under 20), SMOTE-style interpolation produces artifacts. If temporal structure matters — for example, fraud sequences — synthetic interpolation breaks temporal coherence. In those settings I rely on cost-sensitive loss, legitimate data collection strategies, or anomaly detection framing, and invest heavily in evaluation design rather than synthetic data volume.

Finally, document your sampling strategy and random seeds. Resampling introduces stochasticity, and without a fixed pipeline your results will not reproduce. I log the final minority ratio, the resampler parameters, the validation PR-AUC before and after calibration, and the chosen operating threshold alongside the business cost assumptions that justified it. That audit trail is what turns an experimental notebook into a deployable system.

Frequently Asked Questions