Let Classifiers Abstain with Selective Prediction

A classifier does not have to answer every case. In many systems, forcing a prediction on an ambiguous input is worse than sending that input to a human, requesting more information, or falling back to a safer workflow.

Selective prediction gives a model that option. The classifier produces its usual prediction, but the system accepts it only when a selection rule considers the case reliable enough. Otherwise, the system abstains.

The idea is simple; evaluating it correctly is less obvious. Raising a confidence threshold can improve accuracy on accepted cases while also rejecting more traffic. This article builds a practical mental model for that trade-off, shows how to measure it with risk and coverage, and explains how to choose and validate an abstention policy without confusing confidence with correctness.

The mental model: prediction and acceptance are separate decisions

Suppose a support system classifies incoming tickets as billing, account, or technical. The model returns:

billing:   0.82
account:   0.11
technical: 0.07

The predicted class is billing. A normal classifier stops there.

A selective classifier adds another decision:

predicted class: billing
selection score: 0.82
threshold:       0.75
result:          accept prediction

For a harder ticket, the scores might be:

billing:   0.41
account:   0.35
technical: 0.24

With the same rule, the system abstains because the largest score is below 0.75.

This creates two logically separate components:

1. the predictor, which chooses an output;
2. the selection rule, which decides whether to use that output.

Keeping them separate is useful. You can change the abstention threshold without retraining the classifier, and you can evaluate whether the selection score actually distinguishes easier cases from harder ones.

An abstention is not a fourth class such as unknown. The classifier may still assign one of the original labels internally. Abstention is a decision not to act on that prediction under the current policy.

Coverage measures how often the system answers

The first quantity to track is coverage: the fraction of examples for which the system accepts a prediction.

If a validation set contains 1,000 tickets and the selection rule accepts 760, then:

coverage = 760 / 1000 = 0.76

So the system covers 76% of the evaluated traffic and abstains on 24%.

Coverage matters because selective prediction can produce misleadingly impressive accuracy if you ignore how much work was rejected. A system that answers only the easiest 5% of requests may be highly accurate on those requests while providing little operational value.

The threshold controls this trade-off. For a rule that accepts examples when a confidence score is at least t:

higher t -> usually lower coverage
lower t  -> usually higher coverage

That direction follows from the threshold rule itself: increasing t can only remove accepted examples when the scores are fixed. It does not guarantee that accuracy will improve smoothly, because confidence scores are imperfect and finite evaluation sets can behave irregularly.

Selective risk measures errors among accepted predictions

Coverage tells you how often the system answers. You also need to know how often those accepted answers are wrong.

For ordinary classification with zero-one error, selective risk can be written as:

selective risk = errors among accepted examples
                 / accepted examples

If the system accepts 760 tickets and misclassifies 38 of them:

selective risk = 38 / 760 = 0.05

The corresponding accuracy on accepted examples is 95%.

The word risk is broader than classification error. In a real application, the loss for an accepted prediction could represent monetary cost, severity-weighted mistakes, or another task-specific penalty. The core idea stays the same: evaluate loss on the subset the system chooses to handle.

Be explicit about the denominator. Overall error divided by all examples answers a different question from error among accepted examples. Once abstention exists, both can be useful, but they should not be mixed.

Read the risk-coverage curve instead of one threshold

A single threshold shows one operating point. A risk-coverage curve shows what happens across many possible thresholds.

To build one, evaluate the model on held-out examples, calculate a selection score for each prediction, and vary the acceptance threshold. For every threshold, record:

coverage
selective risk

A simplified result might look like this:

These numbers are only a teaching example, not expected values for a particular model. They show the decision you actually face: reducing risk consumes coverage.

The curve is more informative than asking whether one model has “good confidence.” For example, model A may have lower risk than model B at 90% coverage but higher risk at 50% coverage. If your application needs to automate roughly 80% of traffic, performance near that region matters more than performance at an arbitrary threshold.

Compare models at a shared operating constraint

When comparing selective systems, hold something meaningful constant. Two common questions are:

At 80% coverage, which model has lower selective risk?

or:

To keep selective risk below 2%, how much coverage can each model provide?

Comparing risk at unrelated thresholds is usually unhelpful because different models can assign scores on very different numerical scales.

Confidence is a selection score, not a correctness guarantee

For a softmax classifier, the maximum predicted probability is a convenient selection score. It is not proof that a prediction is correct.

A model can be confidently wrong on inputs that differ from its training distribution, contain misleading patterns, or fall into regions where its learned representation generalizes poorly. A threshold of 0.9 therefore does not imply that every accepted prediction has a 90% chance of being correct.

This distinction is especially important because calibration and ranking for abstention are related but different properties.

Calibration asks whether numerical probabilities match observed frequencies. Selective prediction mainly needs the score to rank risky examples below safer ones. A score can be imperfectly calibrated yet still rank examples well enough to support useful abstention. Conversely, a globally reasonable probability estimate may fail to separate a particular failure mode that matters in production.

If the product needs probabilities with a probabilistic interpretation, evaluate calibration separately. Do not assume that a good risk-coverage curve establishes calibration.

Choose a selection score that reflects the failure you care about

Maximum class probability is a reasonable baseline because it requires no additional model. It is not the only possible selection score.

For a multiclass classifier, the gap between the top two class scores can capture a different signal:

score = probability(top class) - probability(second class)

A prediction of 0.51, 0.49, 0.00 has a small margin even though one class technically wins. A prediction of 0.51, 0.25, 0.24 has the same maximum probability but a larger margin.

Other systems may use an uncertainty estimate from an ensemble, a separately trained error detector, or a score designed for a particular model family. Those methods add complexity and must be validated against the actual errors you want to reject.

The practical test is not whether a score sounds like uncertainty. Ask whether lower-ranked cases are in fact more error-prone on representative held-out data.

Set the threshold from an operational requirement

Picking 0.8 because it feels conservative is not a defensible threshold-selection method. The numerical scale of a model’s confidence is model- and data-dependent.

Start with the constraint imposed by the application. Imagine that automatically misrouting a support ticket is costly, but a review team can manually handle at most 20% of daily traffic.

That gives a coverage requirement near 80%. On a validation set that represents expected traffic, choose a threshold that produces the required coverage, then measure the selective risk at that operating point.

Another application may work in the opposite direction. If accepted predictions must remain below a chosen error rate, search the validation curve for thresholds that satisfy that risk target and select the one providing useful coverage.

There is an important statistical caveat: an observed validation risk below a target is an estimate, not a guarantee about future traffic. Small accepted subsets can make the estimate noisy. If a hard risk guarantee is required, a plain empirical threshold is not enough; the system needs an appropriate statistical procedure and assumptions for that guarantee.

Keep a final test set separate from threshold tuning. If you repeatedly inspect the test set while adjusting the threshold, the reported risk and coverage become part of the tuning process rather than an independent estimate.

Abstention only helps when the fallback is useful

Selective prediction moves difficult cases somewhere else. That “somewhere else” is part of the system and should be designed explicitly.

For the support classifier, an abstained ticket might enter a human triage queue. For document extraction, the application might ask the user to confirm a field. For an automated workflow, it might use a conservative default action.

The value of abstention depends on the relative costs:

cost of a wrong accepted prediction
cost of the fallback path
capacity of the fallback path
cost of delaying a decision

If every abstention requires expensive expert review, aggressively lowering risk may overload the reviewers. Once that happens, queue delays can erase the benefit of a stricter threshold.

This is why coverage is not merely a model metric. It translates directly into fallback volume. At 70% coverage, roughly 30% of matching traffic reaches the fallback path, assuming deployment traffic resembles the evaluation distribution.

Evaluate the cases that selective prediction can hide

Aggregate risk and coverage can conceal uneven behavior.

Suppose a classifier achieves 85% overall coverage, but coverage is 95% for common English-language tickets and 45% for a smaller language segment. The system has not simply become “more cautious.” It has shifted much more work from one group to the fallback process.

Inspect coverage and accepted-case error across segments that matter to the application. The relevant segments depend on the domain: input source, device type, document format, product area, language, or other operational categories.

Also inspect the abstained examples themselves. If they are mostly genuinely ambiguous cases, the selection rule may be doing useful work. If they cluster around a formatting artifact or a data pipeline bug, fixing that issue may recover coverage without accepting more model risk.

Distribution shift can break a threshold that worked yesterday

A threshold is selected against a distribution of scores and errors. If production inputs change, the same threshold can produce different coverage and different selective risk.

Consider a classifier deployed on scanned forms. A new scanner introduces blur that was rare in the validation data. The model might respond in several ways:

• confidence could fall, causing coverage to drop sharply;
• confidence could remain high while errors increase;
• only certain document types could be affected.

The first case is visible in the abstention rate. The second is more dangerous because the selection score fails to identify the new errors.

Monitor both coverage and downstream quality after deployment. A stable acceptance rate does not prove that accepted predictions remain reliable, and a sudden increase in abstention is itself a useful signal that the input distribution or model behavior may have changed.

Thresholds may need reevaluation after model updates, label changes, calibration changes, or material shifts in traffic. A threshold is part of a particular model-and-data operating point, not a universal constant.

Common mistakes make abstention look better than it is

The most common evaluation mistake is reporting only accepted-case accuracy. Saying “the classifier is 99% accurate after abstention” is incomplete without coverage. A model that reaches that number by answering 10% of examples is very different from one that answers 90%.

Another mistake is choosing the threshold on the same data used for the final performance claim. Threshold selection is a form of model selection. Reserve independent data for the final estimate when the distinction matters.

A third mistake is treating a confidence threshold as an out-of-distribution detector. Low confidence may catch some unfamiliar inputs, but neural classifiers can also produce high scores on inputs they handle badly. If detecting distribution shift or unsupported inputs is a requirement, evaluate that requirement directly rather than assuming abstention solves it.

Finally, avoid sending abstentions into an undefined queue. A mathematically sensible selection rule can still make the product worse if rejected cases have no timely or reliable fallback.

When selective prediction is a good fit

Selective prediction is useful when three conditions line up: some errors are costly enough to avoid, the system has a meaningful fallback, and the selection score can rank at least some risky cases below safer ones.

It is particularly natural for workflows that already include review, confirmation, escalation, or retry paths. The model can automate the easier portion while preserving a route for ambiguous cases.

It is less useful when every input requires an immediate model decision and no fallback exists. In that setting, abstention does not remove the decision; it merely postpones the question of what to do. Improving the underlying predictor, changing the task, or adding information may be more productive.

Selective prediction also cannot repair a systematically wrong model if its mistakes receive high selection scores. Abstention works only to the extent that the selection rule can identify cases worth rejecting.

Treat abstention as an operating policy, not a confidence trick

A useful selective classifier is not defined by a magic probability threshold. It is defined by a measurable policy: which cases are accepted, how much traffic that covers, what risk remains among accepted predictions, and what happens to everything else.

Start with the simplest credible score, plot risk against coverage on representative held-out data, and choose an operating point from real capacity or error-cost constraints. Then test the fallback and monitor the same quantities in production.

That process turns “the model seems uncertain” into a decision you can evaluate, tune, and operate.