Information in this post reflects publicly available sources as of November 1, 2026.
In 2022, a passenger asked Air Canada's website chatbot about bereavement fares after a death in his family. The chatbot told him he could book at full price and claim the discount afterward. The airline's actual policy required the request before travel. When he was refused, he took the airline to a Canadian tribunal, which in 2024 ruled that the airline was responsible for what its chatbot said and ordered it to pay.
The chatbot did not malfunction in any visible way. It gave a fluent, specific, helpful-sounding answer that happened to be false. That is what a hallucination looks like in practice: not gibberish, but a confident statement with nothing behind it. Lawyers keep learning the same lesson: one public database had recorded more than 1,200 instances of AI-fabricated citations in US court filings by mid-2026.
You cannot train hallucinations out of a model you only call through an API. You can design around them. This post covers why they happen, how grounding ties answers to real sources, and how to check that it worked.
The problem: plausible is not the same as true
A language model generates the most plausible continuation of its input. Most of the time, plausible and true coincide, because true statements dominate the text it learned from. When the model lacks the fact, it does not go silent. It produces something shaped like the right answer: a policy that sounds like a policy, a case name that sounds like a case.
Hallucinations come in two kinds. A factual error contradicts the world, such as a wrong date or an invented paper. A faithfulness error contradicts the material the model was given, such as a summary that adds a claim the document never made. Grounding mostly targets the second kind, by turning "is this true?" into the more checkable question "does the source say this?"
Faithfulness errors are more common than many builders assume. Vectara's leaderboard, which measures how often models add unsupported content when summarizing a document they were handed, put most models between about 5% and 12% in its May 2026 update. The best were under 4%, and some reasoning-heavy models exceeded 20%. Having the source in context reduces hallucination; it does not eliminate it.
Why models make things up
A 2025 paper from OpenAI researchers, "Why Language Models Hallucinate," offers a useful explanation in two parts. The first is about knowledge. Some facts follow patterns a model can learn, such as spelling or grammar. Others, such as a particular person's birthday, are arbitrary and may appear only once in the training data.
The paper argues that for facts seen only once, errors are statistically unavoidable: roughly, if a fifth of such facts appear a single time in training, a base model should be expected to get at least a fifth of them wrong. No amount of polish removes that floor, which is why the fix has to come from outside the model.
The second part is about incentives. Most benchmarks grade answers as simply right or wrong, with no credit for "I don't know." Under that scoring, a model that guesses always beats one that admits uncertainty, just as a student guessing on a multiple-choice exam beats one who leaves blanks. Models are tuned to do well on those benchmarks, so they learn to guess.
Both parts point to practical moves. If the model lacks a fact, supply it. If the model is rewarded for guessing, change the reward: tell it explicitly that a wrong answer is worse than no answer, and design your product so that "not found" is an acceptable outcome rather than a failure.
How grounding works
Grounding is not one technique but a pipeline. Each stage closes a different gap, and a weak stage shows up as hallucinations no matter how strong the others are.
Supply the facts
The first stage puts the relevant facts in front of the model: retrieved documents, search results, database records, or tool output. This is what retrieval-augmented generation is for. A model answering from a current policy document no longer needs to remember the policy, and it can be updated by changing the document rather than the model.
Retrieval quality is grounding quality. If the search misses the relevant section, the model will often fill the gap from memory, producing an answer that looks grounded but is not. Most "the model ignored the documents" complaints turn out to be "the documents never reached the model."
Make "not found" an answer
Instruct the model to answer only from the provided material, and to say plainly when the material does not cover the question. The OpenAI paper suggests going further by stating the stakes: tell the model that a wrong answer costs more than declining, so it should answer only when confident.
The instruction only works if the product honors it. A support flow where "I can't find that in our policies" leads to a human, a search link, or a clarifying question will get honest abstentions. A flow where an abstention looks like a broken product will push teams to tune prompts until the model stops abstaining, which is how the guessing comes back.
Require citations
A citation links each claim in the answer to the passage that supports it. Citations help in two ways. They let users check answers themselves, and they give your code something concrete to verify: an uncited claim is a red flag before anyone reads it.
Asking for citations in the prompt works, but models can invent citations as easily as facts. Native citation features are more reliable because the API ties the cited text to the actual input. Anthropic's Citations feature, for example, returns the exact passage each part of the answer relies on:
import anthropic
client = anthropic.Anthropic()
policy = open("refund_policy.txt").read()
resp = client.messages.create(
model="claude-sonnet-5-5",
max_tokens=1024,
system="Answer only from the documents. If they do not cover the question, say so.",
messages=[{"role": "user", "content": [
{"type": "document",
"source": {"type": "text", "media_type": "text/plain", "data": policy},
"title": "Refund policy",
"citations": {"enabled": True}},
{"type": "text", "text": "Can I claim a bereavement fare after my trip?"},
]}],
)
for block in resp.content:
if block.type != "text":
continue
cited = [c.cited_text for c in (block.citations or [])]
flag = "" if cited or not block.text.strip() else " <-- no source
print(block.text + flag)
for passage in cited:
print(" cites:", passage.strip())
The response arrives as a series of text blocks, each with the passages it relies on. The loop prints every block with its sources and flags substantive text that cites nothing. That flag is a cheap first check: if the answer's key sentence has no citation, it should not reach a customer unchecked.
Verify the claims
A citation proves that a passage exists, not that it supports the claim. A model can cite the refund policy while misstating what it says. The final stage checks each claim against its source, a step usually called a groundedness check.
Checks come in three strengths. Exact checks are deterministic: every case name exists in the legal database, every order number matches a real order, every URL resolves, every number appears in the source. Classifier checks use a small model trained to judge whether a passage supports a statement, which is fast and cheap. Model-based checks ask a second model to compare each claim with its source, which handles nuance but costs a full call.
Use the strongest check the content allows. Names, numbers, identifiers, and links should get exact checks wherever possible, because those are where hallucinations do the most damage and are easiest to verify mechanically. Reserve model-based checks for claims that need judgment.
Measure it
Grounding needs its own eval, because a general quality score hides the failures that matter. Build a test set with two kinds of questions: ones the corpus answers, and ones it deliberately does not. The second kind is the only way to see whether the system abstains or invents.
Then track four numbers. The supported-claim rate is the share of claims backed by their sources. Citation precision is the share of citations that actually support the sentence they are attached to.
The abstention rate on unanswerable questions should be high, and on answerable ones low. The wrong-answer rate is the one users feel, so watch it after every change to prompts, retrieval, or models.
When to use it, and when not
Not every output needs the full pipeline. A brainstorm, a first draft, or a list of name ideas will be reread and edited by a person, and an invented detail costs little. Grounding there adds latency for no benefit.
The more a wrong answer would cost, and the less likely a person is to catch it, the more grounding it deserves. Internal question answering benefits from retrieval and citations so employees can check sources. Customer-facing answers about policies, prices, or eligibility need claim checks and honest abstention, because the Air Canada ruling made clear that the company owns what its bot says. Legal, medical, and financial content needs exact checks and a person in the loop.
Questions about general knowledge sit in between. For those, grounding with web search adds current sources and citations users can follow, but search results can be wrong too, so treat them as evidence rather than truth.
What goes wrong
Citations that do not support the claim. Users and reviewers see a citation and stop checking. The cited passage may be related but say something different. Spot-check citations in evals, and treat a cited but unsupported claim as a failure, not a pass.
Silent retrieval misses. The right document was never retrieved, so the model answered from memory in a grounded-looking format. Log what was retrieved for every answer, and include eval cases where the answer is absent from the corpus so you can measure whether the model abstains.
Stale or conflicting sources. The model faithfully cites last year's policy, or two documents disagree and it picks one silently. Grounding is only as good as the corpus. Version documents, remove superseded ones, and instruct the model to surface conflicts rather than resolve them.
Over-abstention. A strict prompt or checker turns every slightly uncertain answer into "I can't help with that." Users route around the product or stop trusting it. Measure the abstention rate alongside the error rate, and tune for both.
A checker with the same blind spots. A judge model from the same family may accept the same plausible mistake the answering model made. Use a different model or a dedicated classifier for checking, and calibrate it against human-labeled examples, as described in the evals post.
Cost, latency, and complexity
Each stage has a price. Retrieval adds a search and more input tokens. Citations add a little input overhead; Anthropic, for instance, does not bill the returned cited text as output. Verification is the expensive stage: a model-based check can add a second call per answer, roughly doubling latency on that route.
Tiering keeps this affordable. Run exact checks on everything, because they cost almost nothing. Run classifier checks on answers that contain factual claims. Reserve model-based verification for high-stakes routes, or for answers the cheaper checks flag as uncertain.
Streaming complicates verification. If the answer streams to the user as it is generated, there is no moment to check it first. High-stakes routes may need to generate, verify, and then display, accepting a slower first token in exchange for never showing an unchecked claim.
The current landscape
The major model APIs now offer native citation features. Anthropic's Citations works with plain text, PDF, and custom-chunked documents and with search results, returning the exact cited passage; it cannot currently be combined with structured outputs in the same request. OpenAI's web search and file search tools return citation annotations that mark which span of the answer each source supports, and OpenAI requires that web citations be shown as visible, clickable links. Google's grounding with Google Search returns metadata linking response spans to sources, and requires displaying its search suggestions.
For checking, Amazon Bedrock Guardrails offers contextual grounding checks that score answers for grounding and relevance against a source. Vectara publishes HHEM, an open model for judging whether a summary is consistent with its source, and evaluation libraries such as Ragas include faithfulness metrics for RAG pipelines. For measurement, Vectara's leaderboard tracks summarization hallucination rates across models.
None of these features change the core design. They make citations easier to collect and checks easier to run, but deciding what counts as supported, and what happens when an answer is not, remains the builder's job.
Summary
Hallucinations are not a bug that the next model release will remove. They follow from how models learn and how they are rewarded: fill every gap with something plausible, and never leave a question blank. Grounding works by removing the gaps and changing the reward.
So supply the facts, make "not found" an acceptable answer, require citations, and check claims against their sources with the cheapest check that works. Scale that effort to the cost of being wrong. The goal is not a model that never errs, but a system where every claim that reaches a user has something real behind it, or is clearly marked as not having it.
Part of the Applied AI series: AI from the builder's side.