AI confidence explained: what does 90% mean?

In that illustrative sample, 35 requests would go to the wrong queue if the application accepted every prediction. Adding more decimal places would not change that. Before using a threshold, establish what the returned number means and whether it predicts the mistakes you care about.

Find out what the number measures#

A sentence saying “I am 90% confident,” a classifier’s estimated probability and a statistic computed from several probabilities are different outputs. A shared label does not make them interchangeable. Record the field definition before designing a policy around it.

TypeSafe’s confidence documentation describes Jev’s confidence as a statistic derived from the distribution returned for Choice or Score. A more concentrated distribution signals greater certainty by that measure. The field is not itself a measurement of how often that answer is correct; Noul does not carry the same field.

Do not invent a formula for an undocumented statistic or assume it equals the largest probability. Nor should an application transfer a threshold unchanged between a different model, question or option set merely because each field is named confidence.

The example below uses an explicitly stated predicted probability for the selected answer, not Jev’s separate confidence statistic. Decision models explained introduces where those structured results fit in a program.

Compare predictions with checked answers#

Suppose our constructed classifier gives a probability of 0.90 to its selected queue for each of 100 requests. Review the requests against agreed queue definitions without treating the model’s choice as the answer key. In this invented example, 65 choices are correct.

The observed accuracy is 65 divided by 100, or 65%. The predicted probability was 90%. The difference is 25 percentage points. That is evidence of overconfidence on this sample, not a measured error rate for Jev or any other product.

Calibration asks whether probability estimates agree with outcome frequencies over comparable predictions. Guo and colleagues’ calibration paper studies this property in neural-network classifiers. It does not evaluate the particular support workflow or current decision model described here.

With varied predictions, group cases by predicted probability and compare the average prediction with the fraction correct in each group. A reliability diagram plots those comparisons. The scikit-learn calibration guide explains this method and the need to separate calibration fitting from evaluation.

A group averaging 90% prediction with roughly 90% correct would agree better on that sample. It would still contain mistakes. It also would not establish a precise population rate from a small or unrepresentative set. Keep the number and kind of cases visible beside the percentage.

Look beyond the average#

Split results by distinctions that matter to the application: queue, language, missing information or request type. A good overall result can conceal an unacceptable failure on a less common category. This is a proposed evaluation practice, not a claim that a particular subgroup always performs worse.

For an illustrative extreme, 990 of 1,000 requests belong to the routine queue. A system that always chooses that queue is 99% accurate overall while missing every one of the ten exceptional requests. Overall accuracy answers a different question from “Did we catch the exceptions?”

Also inspect confident mistakes. A policy that reviews only uncertain cases never directly checks its most confident errors. Preserve a suitable sample of automatically handled cases for independent checking, with appropriate access controls and without repeating their real-world actions.

A maintained evaluation set helps make comparisons repeatable. Add discovered failures, but keep separate evaluation cases so tuning a threshold does not become testing on the answers already used to choose it.

Choose thresholds for a specific action#

Define the action before choosing its threshold. Suggesting a support queue, moving a request and deleting its attachments have different consequences. A confidence signal is one input to that decision; permissions and required confirmations remain separate rules.

For a proposed routing policy, compare candidate thresholds on held-out cases. Report how many requests are handled automatically, how many of those are wrong, which important requests are missed and how much work is referred to people. Raising the threshold may reduce automatic coverage without removing the serious errors.

Set limits for review capacity as well. An unavailable reviewer is not evidence that a doubtful classification became safe. Define a waiting or fallback path and report it accurately. Stopping and asking explains how a missing decision connects back to saved work.

Recheck after the task changes#

Version the model, instructions, option definitions and evaluation data. Repeat the relevant comparison after changing them. New request types or a different language mix can also make an earlier measurement a poor description of today’s work.

Use a confidence signal when it demonstrably helps control mistakes and review effort. Keep checking the underlying decisions. A correctly shaped result helps software consume an answer; a validated confidence signal may help decide which answers need more work. Neither establishes that a particular answer is correct.