How should teams evaluate models when the positive class is rare?

How to evaluate rare-positive models without fooling yourself

When the positive class is scarce, the model can look excellent while missing most of the cases you care about. Evaluation needs to separate minority-class detection from overall correctness, because accuracy can stay high simply by predicting the majority class well. The key question is not “How often is the model right?” but “How reliably does it find the rare outcome, and at what cost?”

Which metrics matter when prevalence is low?

Start with metrics that describe minority-class behaviour directly. NIST Cybersecurity Framework 2.0 is a useful reminder that measurement should support governance decisions, not just produce a comforting score. In rare-event settings, recall shows how many positives were found, precision shows how many predicted positives were real, and F1 gives a single view of the trade-off between the two.

A confusion matrix is usually more revealing than any single aggregate number because it shows false negatives and false positive side by side. That matters when missed positives are expensive, such as fraud, fraud-like abuse, safety events, or security incidents. Threshold analysis adds another layer by showing how the decision boundary changes precision, recall, and operational load.

ROC-AUC can still be useful, but it can hide the practical pain of extreme imbalance. Precision-recall curves are often more decision-relevant because they show whether the model maintains acceptable precision as recall rises. If the positive class is very rare, the baseline rate itself becomes part of the interpretation, because even a modest-looking precision score may be meaningful relative to prevalence.

How should teams choose the decision threshold?

Teams should tune the threshold to the cost of the two error types, not to a default 0.5 cut-off. If missing a positive is far worse than raising a false alarm, the threshold should favour recall. If investigations are expensive or disruptive, the threshold should favour precision. NIST Privacy Framework is a useful external reference point for the broader idea that risk-based measurement should reflect impact, not just detection volume.

In practice, the best threshold is the one that makes the model usable in the downstream workflow. A security analyst queue, a claims review team, or a fraud operations team can only absorb so many alerts. A model with high recall but unmanageable false positives may be worse than a more selective model that operators can actually act on consistently.

Teams should also compare performance against a simple baseline, such as always predicting the negative class, a rule-based filter, or a prior production model. If the new model only improves headline accuracy, it is probably not solving the imbalance problem. If it improves recall at an acceptable precision level, it is creating real value even when overall accuracy barely moves.

What does good evaluation look like in practice?

Good evaluation uses stratified splits or time-aware validation so the rare class is represented in both training and test data. It reports class-specific metrics, the confusion matrix, and threshold curves together so stakeholders can see both model quality and operational consequences. For rare positives, teams should also inspect the top false negatives and false positives manually, because a small number of misses can reveal a systematic blind spot.

NIST Cybersecurity Framework 2.0 and NIST Privacy Framework both reinforce the same practical rule: measure what changes decisions. For rare-class problems, that means reporting the minority-class metrics, validating the threshold against business cost, and avoiding any single-score view that hides missed positives.

Practitioner Guidance

What to prioritise: Put recall, precision, and the confusion matrix ahead of aggregate accuracy when the positive class is rare. Accuracy can be a distraction if the negative class dominates the dataset.

What to verify: Check the model at the operating threshold the team will actually use, not just at the best-looking threshold from experimentation. If the threshold changes, the operational meaning of the model changes too.

Decision rule: If false negatives are costly, optimise for recall first and then manage precision to a workable level. If alert fatigue or review cost is the bottleneck, tighten the threshold until precision is acceptable.

Practitioner takeaway: Rare-positive evaluation is really a cost-and-workflow problem, so the “best” model is the one that finds enough true positives to matter without overwhelming the people or systems that must respond.

Related resources from NHI Mgmt Group

• What should IAM teams evaluate before moving to ledger-based identity models?
• How should security teams evaluate GenAI models before production?
• How should teams evaluate machine learning models when classes are highly imbalanced?
• How should teams evaluate machine learning models beyond a single aggregate metric?