Getting a model to say “I don’t know”

Confident but unsupported answers are a failure worth designing for. Their frequency and cost depend on the task.

A confident tone can accompany a correct, stale or fabricated answer. Models can also abstain or express doubt, but tone alone is not a reliable way to decide which claims deserve trust.

People and models can both sound certain while being wrong. With generated answers, assess evidence and task-level performance rather than treating fluent wording as a calibrated confidence score.

Asking for uncertainty is a start

Ask the model to state when evidence is missing, then check whether that instruction helps on your cases.

Explicitly allow the model to say it cannot answer. This can help avoid forced guesses, but the result depends on the model, task and instructions; evaluate it rather than assuming the wording fixes the behavior.

The model’s explanation of its own confidence is another generated output. Do not treat it as a direct measurement of whether a fact was retrieved, inferred or invented; inspect sources and test answers against known outcomes.

Make not-knowing a concrete option

Give the model an explicit alternative when evidence is missing, and evaluate when it chooses it.

Not: “Do not make things up.” Instead: “If the supplied documents do not contain the answer, reply exactly: NOT IN SOURCES.”

A defined output makes abstention easier for your application to recognize and handle. It does not prove the model has correctly judged whether the answer is in the sources.

Specify a clear abstention response and when it should be used, then include both answerable and unanswerable cases in testing. A permitted alternative is useful only if the model selects it appropriately.

Separate the answer from the confidence

Asking for both in one piece of prose produces hedging language sprinkled through a confident answer, which is the worst of both — it reads as uncertain without telling you which part is uncertain.

Ask for them as distinct fields instead. The answer. Then, separately: which parts of this are you least confident about, and what would you need to be sure?

Separate the answer, evidence and unresolved questions for easier review. Those fields can still be incomplete or wrong, so compare them with the source rather than trusting the uncertainty field to identify every weak sentence.

Ground it, then the question becomes answerable

The deepest fix is structural rather than conversational.

With supplied material, ask whether the answer is supported by those documents. Check the relevant passages and the completeness of the source set; a “not found” response can itself be mistaken.

Without inspectable evidence, an abstention may be appropriate, but a confident answer is not proof of reliable recall. Important claims need an external check.

Supplying inspectable material makes claims easier to check. It remains one part of reliability, alongside source quality, model behavior and validation.

Require evidence, not assertion

“For each claim, quote the sentence from the source that supports it.”

Ask for a short supporting quote and its location, then verify both. This makes review concrete, but fabricated quotes and misleading selections remain possible.

Make the check part of the workflow: find the quoted words and inspect the context. Requiring a quote only helps if someone or a suitable verification process actually checks it.

Make refusing cheap

A subtle point about how you frame the request.

A schema that requires every field to contain a substantive answer may encourage unsupported filling. Where the task permits it, represent unknown or unsupported values explicitly.

Define what null, “unknown” and “not applicable” mean, and check that they are used correctly. Allowing missing values makes honest uncertainty representable; it does not guarantee honest use.

What this costs

Being balanced: a model tuned toward caution will sometimes decline when it could have answered, and users find that frustrating in a different way.

Choose the review path according to risk. A low-stakes draft may tolerate uncertainty that a financial, security or operational action cannot; route unresolved consequential claims to a qualified reviewer.

That is the same question as deciding what a human still has to approve, and it deserves a deliberate answer per task rather than a default that came from a prototype.

Three checks that work without changing anything

If you cannot modify the system — you are using a chat assistant as a person rather than building on an API — these still work.

If repeated answers conflict, investigate the disagreement against evidence. One answer may be correct; inconsistency alone does not tell you which one, and agreement does not prove truth.

Ask for the strongest counterargument, but test its premises too. A persuasive alternative is something to investigate, not proof that the original answer was baseless.

Ask where it came from. Not the formal citation — just “how do you know that?” Answers that point at something specific and checkable are in a different class from answers that restate the claim in different words. The second kind is a tell worth learning to notice.

Designing the system around it

If you are building rather than chatting, three structural choices carry most of the benefit.

Validate structure and claims. Parsing can catch malformed output, while factual checks may need a rule, authoritative lookup or reviewer. Each check has implementation and maintenance cost; a well-formed answer can still be wrong.

Make abstention a first-class output. Not an error, not an exception — a normal, expected result your code handles by routing to a person. Systems that treat “I cannot answer this” as a failure pressure the model into answering anyway, which is precisely the behavior you were trying to prevent.

Track correct answers, incorrect answers, appropriate abstentions and unnecessary abstentions on representative cases. A low abstention rate is not automatically bad; interpret it alongside answerability and the cost of errors.

What to tell people who use these tools

Treat confidence in prose as presentation, not a substitute for evidence. The relevant question is whether the answer is supported and useful for the decision.

Verify the important claims and make unresolved questions visible. That habit works whether the model sounds cautious or certain, and it remains necessary when a prompt explicitly asks for honesty.

Technical review, October 10, 2026. References: Anthropic: reduce hallucinations; OpenAI: evaluation best practices.

Try this

Use a fictional question with a deliberately missing fact, plus a similar question whose answer is supplied. Compare several responses: does the model answer when supported and abstain when not? Do not use a real private fact or treat one test as an overall reliability score.