Communicating confidence and uncertainty

Why this matters #

Every AI feature is sometimes wrong. What decides whether users keep trusting it is whether the feature seemed sure when it was wrong. An assistant that confidently gives a wrong refund policy damages trust far more than one that says “I’m not certain; here’s the policy page.”

Communicating uncertainty well is hard, because models don’t reliably know when they’re wrong, and the obvious solution, showing a confidence percentage, usually backfires. This article explains why, which signals work better, and how to design an answer that says “I’m not sure” and still helps.

Why model confidence is hard to show #

It’s tempting to ask the model “how confident are you, from 0 to 100?” and display the number. The problems:

• Self-reported confidence isn’t reliable. A model’s stated confidence can be poorly matched to how often it’s actually right. A “90% confident” label that’s right half the time is worse than no label.
• Users read numbers as precise. “87% confident” sounds measured. Users either over-trust it or learn to ignore it, and both are bad.
• One number hides the reason. Is the answer uncertain because the sources conflict, because the question is ambiguous, or because the information isn’t there? Each needs a different response from the user.
• It doesn’t say what to do. A percentage leaves users to decide whether 72% is good enough, without the information to decide.

Confidence numbers can work when they come from a measured process, such as a classifier calibrated on your own data, and when users are trained to use them. For most product features, there are better signals.

Better signals than percentages #

Instead of asking “how sure is the model?”, show users the evidence behind an answer and the reason for any doubt:

The last row is the most practical starting point. Instead of a continuous confidence score, have the model classify its own answer into a few statuses, each tied to something it can check: did the sources contain the answer, part of it, or none of it?

Abstaining well #

Abstaining means the feature declines to answer, or answers only part of the question, when it doesn’t have what it needs. Done badly, it’s a dead end. Done well, it’s one of the most trust-building things a feature can do.

A helpful abstention has three parts:

1. What’s missing: “Your documents don’t include the 2027 pricing.”
2. What is known: “They do include 2026 pricing, if that helps.”
3. What to do next: “You could upload the 2027 price list, or ask sales.”

Here’s a way to make that structure explicit. The model answers through a schema that includes a status and a list of what’s missing, so your interface can treat each case differently instead of guessing from the prose:

import Anthropic from '@anthropic-ai/sdk';
import { zodOutputFormat } from '@anthropic-ai/sdk/helpers/zod';
import { z } from 'zod';

const client = new Anthropic();

const AnswerSchema = z.object({
  status: z.enum(['answered', 'partial', 'not_enough_information']),
  answer: z.string().describe('The answer, using only the context. Empty if nothing can be answered.'),
  missing: z.array(z.string()).describe('Specific information the context lacks, if any'),
});

export type Answer = z.infer<typeof AnswerSchema>;

export async function answerOrAbstain(question: string, context: string): Promise<Answer | null> {
  const response = await client.messages.parse({
    model: 'claude-opus-5-5',
    max_tokens: 4096,
    output_config: { effort: 'low', format: zodOutputFormat(AnswerSchema) },
    system:
      'Answer only from the context. Use "partial" if the context answers part of the question, and ' +
      '"not_enough_information" if it answers none of it. List exactly what is missing. Never fill gaps from memory.',
    messages: [{ role: 'user', content: `<context>\n${context}\n</context>\n\nQuestion: ${question}` }],
  });

  // Refused, truncated or otherwise unfinished: the caller shows its error state rather than a guess.
  if (response.stop_reason !== 'end_turn') return null;
  return response.parsed_output;
}

The interface then has three designed states instead of one ambiguous one: a normal answer; an answer with a clearly marked “not covered” note listing missing; and an abstention that shows what’s missing with next steps. Combined with citations, users always know what the answer rests on.

Calibrating with evals #

Statuses are only useful if they’re right. “Partial” should mean the answer really is incomplete; “answered” should be wrong rarely. Check that with your eval set:

• Include unanswerable and partly answerable questions alongside answerable ones, with the correct status for each.
• Measure two failure types separately: confident wrong answers (status “answered” but incorrect), which are the dangerous ones, and unnecessary abstentions (status “not enough information” when the answer was there), which make the feature feel useless.
• Tune the trade-off for your context. For a medical or legal feature, prefer more abstentions. For a brainstorming tool, prefer fewer.

Over time, these numbers let you say something precise and honest to users and stakeholders: “when the assistant says it has answered, it’s correct in our evals 96% of the time.” That’s a far better confidence signal than any percentage the model reports about itself. Rubrics and human grading covers how to grade answers consistently.

Common mistakes #

Try it #

Check your understanding #

Key takeaways #