Adjust the class distribution to see why Accuracy is a dangerously misleading metric when dealing with imbalanced datasets like fraud detection or rare diseases.
In many real-world scenarios, the data we care about is rare. Think of credit card fraud, rare disease detection, or critical system failures. In these datasets, the "normal" class vastly outnumbers the "anomaly" class. This is called Label Imbalance, and it creates a dangerous trap for machine learning models: The Accuracy Paradox.
In many real-world scenarios, the data we care about is rare. Think of credit card fraud, rare disease detection, or critical system failures. In these datasets, the "normal" class vastly outnumbers the "anomaly" class. This is called Label Imbalance, and it creates a dangerous trap for machine learning models: The Accuracy Paradox.
The Accuracy Paradox occurs when a model achieves a very high accuracy score but is completely useless in practice. This happens because the model learns to simply predict the majority class every single time. In a dataset with 99% normal transactions and 1% fraudulent ones, a model that always guesses "normal" will be 99% accurate. It sounds great, but it has failed at its one important job: detecting fraud.
This visualization demonstrates the paradox by comparing two models:
This is a deliberately dumb model. Its only rule is: always predict Class 0 (the majority class). It never predicts an anomaly. As you'll see, its accuracy is deceptively high.
This is a standard Logistic Regression model. It tries to learn a decision boundary to separate the two classes based on the data. Watch how its behavior and metrics change as the dataset becomes more imbalanced.
Take a fraud dataset: 100,000 transactions, 500 of them fraudulent. That is 0.5% positive.
Now write the laziest possible model — return "not fraud" — and evaluate it:
This is the accuracy paradox in its purest form. The number is excellent and the model is worthless, because accuracy is dominated by the class you did not care about. Worse, a real model trained with a standard loss will drift towards this behaviour on its own: predicting the majority class is genuinely the fastest way to reduce average error, so that is where the optimiser goes.
The confusion matrix tells the true story instantly:
| Predicted fraud | Predicted legitimate | |
|---|---|---|
| Actually fraud | 0 | 500 |
| Actually legitimate | 0 | 99,500 |
An empty column is the signature of a model that has learned to abstain. If you never look past accuracy, you will never see it.
Two mechanisms do the damage, and they are worth separating because they suggest different fixes.
The loss function is an average. Cross-entropy sums equally over rows, so 99,500 easy negatives contribute far more total loss than 500 hard positives. Reducing the loss on the many is simply the better deal for the optimiser.
There is not enough of the minority to learn from. Even a perfectly balanced loss cannot conjure a pattern out of 500 examples spread across a complicated feature space. This is a data problem, not a weighting problem, and no amount of reweighting fixes it.
Distinguishing the two is diagnostic. If the model does well on the training minority and poorly on the test minority, you have too few examples. If it does badly on both, the loss is drowning the signal and reweighting should help.
class_weight="balanced" multiplies each class's loss contribution by the inverse of its frequency, so 500 fraud cases count as much as 99,500 legitimate ones. Supported by most scikit-learn estimators and by the boosting libraries via scale_pos_weight.Two warnings that cost people weeks. Resample only the training set — a balanced test set measures a world that does not exist. And apply SMOTE inside the cross-validation fold, never before splitting, or synthetic points derived from test rows leak straight into training.
On a 1% positive rate, a model that predicts "no" every time scores 99%. This measures what that model is worth, and what the useful metrics say instead.
Use the interactive panel to build a strong intuition for this problem.
The paradox teaches us a critical lesson: accuracy is not the right metric for imbalanced datasets. We need to look at metrics that tell us how well the model performs on the minority class.
When dealing with imbalanced data, always evaluate your model using a Confusion Matrix, and pay close attention to Precision, Recall, and the F1-Score, especially for the rare class you are trying to find.
The right operating point is a business question with a numerical answer. Put pounds on each cell of the confusion matrix and it stops being a judgement call.
Suppose a missed fraud costs £200 on average, and a false alarm costs £5 in review time and customer annoyance. Then:
The first model is better despite raising six times as many false alarms, because the asymmetry in costs is 40 to 1. Compute this curve across thresholds and the optimum is a number rather than an argument.
This framing also settles the perennial "which metric?" debate. When you can put costs on the errors, expected cost is the metric, and precision, recall and F1 are just proxies for it.
How imbalanced is too imbalanced? There is no threshold, but rough bands help: up to 1:10 usually needs nothing but sensible metrics; 1:100 needs weighting or resampling; beyond 1:1000, consider anomaly detection.
Does SMOTE actually work? Sometimes. It helps most with moderate imbalance and continuous features, and it can hurt with high-dimensional or categorical data, where interpolating between two points produces something that is not a plausible record.
Should I balance the validation set? Never. Evaluate on the real distribution or your estimates are fiction.
Is class weighting the same as oversampling? Mathematically close — both increase the minority's influence on the loss — but weighting does not duplicate rows, so it is cheaper and does not encourage memorising specific examples.
My PR-AUC is 0.3. Is that bad? Compare it with the base rate. On a dataset with 0.5% positives, random guessing gives a PR-AUC of 0.005, so 0.3 is sixty times better than chance. PR-AUC must always be read against the prevalence.
Can I just collect more data? If the extra data contains more of the rare class, yes — it is the best fix available. More majority-class rows make the imbalance worse.
Numbers make the threshold argument concrete. Take a fraud model scored on 100,000 transactions containing 500 frauds, and read what happens as the threshold falls:
| Threshold | Alerts raised | Frauds caught | Precision | Recall |
|---|---|---|---|---|
| 0.90 | 120 | 95 | 0.79 | 0.19 |
| 0.50 | 610 | 280 | 0.46 | 0.56 |
| 0.20 | 2,400 | 420 | 0.18 | 0.84 |
| 0.05 | 11,000 | 480 | 0.04 | 0.96 |
Nothing about the model changed across those four rows. Only the bar moved.
Which row is best depends entirely on what happens after the alert. If a human reviews every alert and can handle 500 a day, row two is the only feasible option. If the alert triggers an automatic extra verification step that costs pennies and annoys the customer slightly, row three catches 140 more frauds for a cost most businesses would accept. If a missed fraud costs £200 and a review costs £5, row three's expected cost is 80×200 + 2,400×5 = £28,000 against row two's 220×200 + 610×5 = £47,050 — and the eager model wins clearly.
Produce this table before you produce a model comparison. It is usually more decision-relevant than any single metric, and it costs one line of code from a probability column.
Say the answer out loud before you reveal it — recalling it is what makes it stick, and rereading it is not.
What does this module say about “Overview”?
In many real-world scenarios, the data we care about is rare. Think of credit card fraud, rare disease detection, or critical system failures. In these datasets, the "normal" class vastly outnumbers the "anomaly" class. This is called Label Imbalance , and it creates a dangerous trap for machine learning models: The Accuracy Paradox .
What does this module say about “What is the Accuracy Paradox”?
The Accuracy Paradox occurs when a model achieves a very high accuracy score but is completely useless in practice. This happens because the model learns to simply predict the majority class every single time. In a dataset with 99% normal transactions and 1% fraudulent ones, a model that always guesses "normal" will be 99% accurate. It sounds great, but it has failed at its one important job: detecting fraud.
What does this module say about “The "Naive" Model”?
This is a deliberately dumb model. Its only rule is: always predict Class 0 (the majority class) . It never predicts an anomaly. As you'll see, its accuracy is deceptively high. 2. The Standard Trained Model
In many real-world scenarios, the data we care about is rare. Think of credit card fraud, rare disease detection, or critical system failures. In these datasets, the "normal" class vastly outnumbers the "anomaly" class. This is called Label Imbalance, and it creates a dangerous trap for machine learning models: The Accuracy Paradox.