Class Imbalance
When positives are one in a thousand, always predicting negative is almost perfectly accurate and completely useless. Imbalance decides the metric, the split, the threshold, and whether the probabilities can be trusted.
The problem, the obvious approach, and why it breaks
Every lesson starts where the work starts: someone has a problem, and the first model that comes to mind looks fine offline.
Positives are rare. Which metric, split and threshold still say something about the decision, and what does rebalancing the training data do to the model's probabilities?
A card issuer sees fraud on about one authorisation in a thousand. The first model reported very high accuracy in the review, and the fraud operations lead asked why it had flagged nothing all week.
Train a classifier, report accuracy, and threshold the probability at 0.5. A model with very high accuracy is a good model, and 0.5 is the natural boundary between the classes.
A model that predicts "not fraud" for everything is right on 999 of every 1000 rows. The reported accuracy is a statement about the base rate, not about the model, and the naive model achieves it by never flagging anything.
- A model that predicts "not fraud" for everything is right on 999 of every 1000 rows. The reported accuracy is a statement about the base rate, not about the model, and the naive model achieves it by never flagging anything.
- At a 0.5 threshold, almost no authorisation crosses the line — the prior alone puts most probabilities near zero — so the model that scored well offline blocks nothing. The threshold, not the model, produced the empty week.
- When the team rebalances the training set to fix the empty queue, the probabilities inflate, every score is now far above the real risk, and the calibration the step-up logic relied on is gone.
What is being predicted, and from what data
This domain leads with these two. A target nobody defined precisely is a label nobody can trust, and a dataset nobody can describe is a model nobody can debug.
- Predict whether an authorisation will be disputed as fraud. Positives are around one in a thousand; the model's output is a probability that a threshold turns into a block, a step-up challenge, or an approval.
- The costs are asymmetric: a false negative is the fraud amount plus the chargeback fee; a false positive is an annoyed cardholder and, for repeat false positives, a lost customer.
- One example is one authorisation with cardholder trailing aggregates and merchant features. Labels arrive up to 60 days later as disputes.
- Ten million rows contain roughly ten thousand positives. A uniform random split of a tenth for validation contains about a thousand of them, and any slice of validation by merchant category contains a few dozen.
- The positive rate itself varies by channel, from near zero for some card-present merchants to several percent for a few online categories.
How it actually works
Precisely enough to predict its behaviour — not a framework API.
- Accuracy weights every row equally, and when one class is 999 in 1000, the metric is dominated by that class. Any metric that averages over rows inherits the base rate; metrics computed within the positive class — recall — or within the flagged set — precision — do not (Accuracy Under Imbalance).
- A well-calibrated model on a 0.1% base rate emits probabilities mostly near 0.001; a threshold of 0.5 is a request for cases the model is five hundred times more sure of than average. The operating threshold has to be chosen from the cost of each mistake and the capacity of the review queue, not from symmetry (Threshold Selection).
- Resampling or class weights change the effective prior the model is trained under. The learned log-odds shift by the log of the rebalancing ratio; the ranking may barely change, but the outputs no longer estimate the true probability until corrected (Calibration).
- Splits inherit the imbalance too: a random validation fold of a small dataset can hold too few positives to estimate recall to any useful precision, so the fold is stratified to fix the positive count (Stratified Split, Metric Uncertainty).
The confusion matrix the accuracy hid
Lay out one day of a million authorisations at a one-in-a-thousand fraud rate, for a model at its operating threshold. The matrix below is illustrative, but its shape is the general one: the true-negative cell is enormous, and accuracy is almost entirely that cell.
The two cells that cost money are the off-diagonal ones, and they have different prices. Accuracy adds them as if they were the same; the business does not.
Accuracy here is above 99.8% and the do-nothing model scores 99.9%. Recall is 0.6 and precision is 0.3, and those two numbers — with the cost of each cell — are the entire conversation about whether to ship.
What rebalancing does to the probabilities
Training on a set where negatives were downsampled by a factor of a hundred, or with a class weight of a hundred on positives, shifts the model's learned prior. The log-odds it outputs are offset by the log of that factor. Ranking may be nearly unchanged; the numbers themselves are wrong until corrected.
The correction is one line, and it is the line that is forgotten when the serving code is rewritten. A step-up rule that fires above a probability of 0.1 was designed against real probabilities, and against rebalanced ones it fires on everything.
1import math2 3def sigmoid(z): return 1 / (1 + math.exp(-z))4def logit(p): return math.log(p / (1 - p))5 6# The model was trained with negatives downsampled by NEG_KEEP7# (or, equivalently, positives weighted by 1/NEG_KEEP).8NEG_KEEP = 0.019 10def true_probability(p_rebalanced):11 # shift the log-odds back by the log of the rebalancing factor12 return sigmoid(logit(p_rebalanced) + math.log(NEG_KEEP))13 14# A rebalanced 0.5 is a real probability of about 0.01.15# Thresholds, step-up rules and expected-loss maths must use the corrected value.16# Then verify: mean(true_probability(p)) over production traffic ~= base rate.The correction is exact for downsampling and approximately right for class weights; either way, the check is the same — the mean corrected probability on unbalanced data should equal the base rate. If it does not, something else is also wrong.
The base rate is an assumption too
Every decision downstream of the model — the threshold, the queue size, the expected-loss maths, the PR-AUC on the dashboard — was made against a base rate. When the rate moves, from a new fraud ring or a seasonal shift, those decisions are wrong even if the model's ranking is unchanged.
So the base rate needs a monitor of its own, and a prevalence shift needs to be distinguished from model decay before anyone retrains.
The positive rate in production traffic is close to the rate the threshold, queue capacity and calibration were set against, per channel.
holds when Prevalence is tracked as labels mature and the operating threshold is re-derived when it moves; probabilities are calibrated on production-like data so the threshold has a stable meaning.
breaks when A fraud ring raises the rate in one channel; a product launch changes the merchant mix; a rebalanced model is redeployed without its correction; the label definition changes what counts as a dispute.
respond Re-derive the threshold from the current prevalence and costs first. Retrain only if precision at a re-chosen threshold has also fallen, which is decay rather than a prior shift.
How to build it
Most important first.
- Choose the metric from the decision: precision and recall at the operating threshold, and the precision-recall curve for comparing models; PR-AUC over ROC-AUC when the positive class is what matters (PR AUC).
- Stratify the split so every fold has a known positive count, and report the number of positives in the evaluation set beside every metric.
- Pick the threshold by sweeping it against the confusion matrix priced in business terms and against queue capacity; never inherit 0.5.
- If rebalancing is used for optimisation reasons, recalibrate on an unbalanced held-out set afterwards, and test that the mean predicted probability matches the base rate.
- Report metrics per channel, because the base rate differs by channel and a single number hides a channel where the model is useless.
What to measure
Which number actually maps to the decision — and which numbers look relevant and are not.
- Precision and recall at the deployed threshold, with the positive count in the evaluation set beside them. These map to the review queue and the missed fraud; accuracy maps to nothing.
- The mean predicted probability against the observed positive rate on production-like data — the calibration check that rebalancing breaks.
- The positive count per evaluation slice. A slice with twelve positives cannot distinguish two models, whatever the metric says.
What must stay true after deployment
The field this whole domain exists for. A model is a set of assumptions with weights attached; these are the ones a monitor or a test should be checking.
- The base rate in production is close to the one the threshold was chosen on, or the threshold is revisited when it moves; PR-based metrics and the operating point both depend on it.
- If training used rebalancing or class weights, the deployed probabilities have been corrected back to the true prior, and a calibration check confirms it before any probability is consumed as a probability.
- The evaluation set holds enough positives, overall and per slice, for the reported metric to distinguish the candidate models at all.
- Offline: compute the majority-class baseline's accuracy and the model's precision-recall curve on a stratified fold; a model that only beats the baseline on accuracy has not been shown to do anything.
- Online: on rollout, compare the daily flagged volume to the planned queue size and the mean score to the base rate; a threshold chosen on the wrong prevalence shows up on day one.
- Over time: as disputes mature, track precision and recall at the operating threshold per channel, alongside the base rate, so a prevalence shift is not misread as decay.
What can go wrong
- The threshold is tuned on a stratified validation set whose positive rate was raised to a tenth, then applied to production traffic at one in a thousand; the queue is ten times smaller than planned and recall collapses.
- The class-weighted model is deployed with the step-up logic that assumed calibrated probabilities; every cardholder above a trivial score gets challenged.
- PR-AUC is adopted, then compared across months as the base rate drifts; the metric moves with the prevalence and is read as model decay.
- Precision-recall metrics are harder to explain to stakeholders than accuracy and move with the base rate, which makes month-over-month comparison a conversation rather than a number.
- Stratifying the split fixes positive counts but is one more constraint alongside time and entity grouping, and the three can conflict on a small dataset.
- Class weights and resampling can improve the ranking on the rare class; the price is a calibration step that has to be built, tested and kept, and that silently breaks when someone changes the weights.
- "Very high accuracy means the model is good." Very high accuracy at a very low base rate is what the do-nothing model gets. Accuracy is a statement about the prior until it is compared to that baseline.
- "ROC-AUC is high, so the ranking is good." ROC-AUC counts true negatives, which are nearly the whole dataset, and can look strong while precision at any usable recall is poor. The PR curve is the one that sees the positives.
- "Oversampling fixed the recall problem." It moved the operating point. The same recall was available from the original model at a lower threshold, with probabilities that still meant something.
Where this applies
ML advice is stated as universal far more often than it is. These labels say what each claim is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThat row-averaged metrics inherit the base rate and that rebalancing shifts the learned prior are arithmetic facts, independent of model family or domain.
- SIMPLIFIEDThe one-in-a-thousand fraud rate and the accuracy figures quoted here are illustrative; they are for the shape of the argument, not measurements of any real portfolio.
- CONTESTEDPractitioners disagree about whether to rebalance at all. One camp holds that tree ensembles and neural networks with a well-chosen loss handle extreme imbalance without resampling, and that every resampling or weighting step is a calibration bug waiting to ship. The other holds that at very low positive counts, weighting or focal-style losses materially improve the ranking on the rare class and that recalibration on a held-out set is cheap; both agree the probabilities must be corrected before they are used as probabilities.
Where the depth lives
This domain teaches the model and hands the rest off by name.