LLM Hallucination: Causes, Examples, and How to Reduce It

A support bot should not invent a policy exception. A reporting assistant should not improvise a total. An agent, software that uses a model to choose actions and call tools, should not guess which customer record to change. The practical goal is to stop an unsupported answer or action from leaving your application.

Verified on 17 October 2026 against the linked model-maker guidance, API documentation, research examples, and court record. The examples below are attributed observations; the validator and weekly checklist are implementation recommendations, not production results.

What LLM Hallucination Is and Why It Happens

An LLM hallucination is a false or unsupported statement produced as though it were an answer. LLM means large language model: a model trained to generate language from patterns in text. A statement can also be unsupported relative to the documents you supplied, even if it happens to be true elsewhere.

Think of a model as a skilled writer completing a briefing from the material on its desk. It can produce a convincing missing paragraph. That does not establish that the paragraph belongs in your company's record.

Predicting Plausible Text Is Not Checking a Fact

OpenAI's research post on why language models hallucinate, published on September 5, 2025, explains that pretraining learns to predict text without a true-or-false label attached to every statement. Rare, arbitrary facts are especially hard to recover from patterns. Later training improves behavior, but fluency does not become a guarantee of truth.

For a builder, the consequence is straightforward: product policy, account status, and inventory belong in authoritative sources your application can read. Treating the model's remembered answer as the database creates an avoidable failure path.

Missing or Stale Context Leaves a Gap

Your model may never have received the fact the customer needs. An uploaded document may be obsolete; a search may retrieve the wrong product edition; an account lookup may fail. Anthropic's explanation of incorrect Claude responses explicitly identifies missing recent information as a source of confusion.

Distinguish two incidents. If the assistant invents a policy, generation failed. If it accurately repeats an expired policy, source management failed. Customers receive a wrong answer in either case, but changing the prompt fixes neither an expired document nor a broken account query.

Pressure to Answer Rewards the Wrong Behavior

OpenAI argues that accuracy-only evaluations can reward guessing over admitting uncertainty. Your own success metric can repeat that mistake if every completed answer counts as success and every handoff counts as failure.

A customer asking for a guaranteed delivery date needs an authoritative shipment estimate. If the carrier has not supplied one, a targeted explanation of what is missing is the useful result. Reward that outcome in your tests and your operating dashboard.

LLM Hallucination Examples: Four Failures to Catch

Classify failures by what your application must verify. These categories overlap, but they give a small team concrete places to add checks.

Invented facts: the dissertation examples come from OpenAI's own research account. A familiar name did not supply the missing title. The business equivalent is inventing a product capability because similar products have it.

Wrong numbers: the birthday examples in that same account show why precise-looking dates are not evidence. In your application, distinguish unsupported figures from calculation mistakes. Pull quantities from records and calculate totals with ordinary code; require the model to explain the result it receives.

Fake citations: the March 20, 2024 opinion in United States v. Cohen describes three nonexistent cases obtained from Google Bard, Google's then-named generative assistant. One purported citation was United States v. Figueroa-Florez. A plausible case name and citation format did not identify a real authority.

Wrong tool arguments: the Berkeley Function Calling Leaderboard authors show a call with annual_interest_rate: 5 for a requested rate of 5%, alongside the correct decimal representation, 0.05. Both values are numbers. A type check alone cannot distinguish them. This is a semantic argument error; not every wrong tool call is a fabricated fact, but it belongs in the same pre-execution review.

How to Reduce Hallucinations Before Customers See Them

Put evidence and validation around generation, then decide what your system should do when either is missing. Builders own the checks; operators own the source of truth and escalation path.

Ground Answers in Current, Relevant Sources

Retrieval-augmented generation, or RAG, searches external material and supplies relevant passages to the model. It gives the writer material to work from. Anthropic's Contextual Retrieval explanation shows why preserving the surrounding meaning of a retrieved passage matters: an isolated excerpt can omit the company, period, or subject it describes.

For a support feature, choose the authoritative policy collection and attach product, region, effective-date, and access metadata. Filter using those fields before generation. Retrieve the cancellation rule and its exceptions together; a paragraph separated from its qualification can support the wrong promise.

For live account facts, read the application database or service. A document search is a poor substitute for whether this customer's order has shipped. If that lookup fails, return an unavailable state rather than silently substituting general knowledge.

Start with a straightforward retrieval flow. Use agentic RAG, where the model can choose additional retrieval steps, when questions need follow-up searches across sources. Extra searches need stopping rules and the same source checks.

The useful diagnostic is whether the right evidence reached the model. Save the source IDs and versions alongside the answer so an operator can distinguish a retrieval miss from an unsupported addition.

Make “I Don't Know” an Application State

Anthropic's guide to reducing hallucinations recommends allowing uncertainty, grounding work in quotations, citing support, and removing unsupported claims. Translate that guidance into a response contract.

Give the model explicit outcomes such as answered, needs_clarification, and insufficient_evidence. Do not require an invented answer to fill a mandatory field when no answer exists. The interface should turn each outcome into something useful: a focused follow-up question, an explanation of the missing record, or a handoff with the retrieved context attached.

A useful instruction is: “Use only the supplied policy and account records. If the records do not establish the answer, identify the missing information. Do not infer eligibility from similar cases.” Test that instruction with missing evidence, not just easy questions.

An unknown outcome is not the same as a safety refusal, a tool timeout, or an unauthorized request. Keep those states separate in your logs so the right owner can fix them.

Make Citations Verifiable by Code

A citation should identify evidence your application already knows about. Have retrieval assign source IDs; resolve those IDs to approved URLs on the server. Avoid asking the model to invent a bibliography or a destination URL from memory.

Check three different properties:

• Existence: the cited source ID belongs to the authorized material supplied for this request.
• Quotation: the quoted text occurs in the exact source version used to answer.
• Support: that passage establishes this claim for this customer's situation.

The first two are straightforward code checks. The third needs a domain rule, a trusted structured field, or a separate claim-support review. Finding the word “eligible” in a document does not prove that a particular customer is eligible.

Anthropic's citations documentation describes document-linked citations that help locate evidence. A source pointer helps audit an answer; it does not settle whether the source is current, authoritative, or correctly interpreted.

Use Structured Outputs, Then Validate the Values

Structured outputs constrain a response to a schema, a definition of allowed fields and value types. They make application checks easier to write. OpenAI's Structured Outputs guide explicitly warns that outputs can still contain mistakes and that incompatible input can prompt hallucinations if the response contract provides no suitable fallback.

For a tool call, validate the operation, required arguments, units, allowed values, record existence, and caller permission before execution. Resolve the tenant and authenticated user in application code. Let the model select among authorized records where appropriate; never treat a model-provided customer ID as proof of access.

A successful tool call also needs a truthful customer response. Do not say a cancellation completed when the tool returned a pending state or error. Use the returned status as the authority for the final message. The site's AI-agent guardrails guide covers the surrounding action boundaries.

LLM Hallucination Detection: A Check You Can Run

For a narrow factual field, verify the proposed value against an approved record and render the answer yourself. That gives you a stronger guarantee for that field than checking whether arbitrary prose sounds consistent.

The following Python example uses an illustrative support-policy fixture, not a real business policy. Save it as verify_answer.py and run python3 verify_answer.py. It uses only the standard library and makes no API calls.

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

The proposed chat answer fails even though its quotation is genuine. If the value is email, it passes this narrow check. The trusted field, not quote matching alone, establishes the answer.

The limit matters: this validator cannot establish the truth of a free-form explanation, whether your policy owner entered the correct fact, or whether the upstream access filter worked. Its unknown branch validates a permitted response shape, not whether abstaining was necessary. Keep those questions in separate checks and evals. For high-impact fixed facts, a template filled from trusted data may remove the need for generation entirely.

Evals That Reward Correct Answers and Correct Stops

An evaluation, or eval, is a repeatable test of your application against expected behavior. Build yours around customer failures and run it when the model, prompt, retrieval index, tool schema, or policy changes.

Record separate outcomes: correct supported answer, unsupported answer, appropriate abstention, unnecessary abstention, and invalid proposed action. A single average hides whether improvements came from better evidence or simply refusing more questions.

Use ordinary code for exact values, source membership, required fields, permissions, and tool results. Use a model judge for language-dependent questions such as whether a passage supports a paraphrase, with human-reviewed examples to calibrate its decisions. An LLM as a judge is another fallible model, not an independent source of facts.

Promptfoo is an evaluation tool whose model-graded assertions include factuality against a reference and faithfulness to supplied context. That distinction is useful: a response can match a stale document and still be wrong for today. Use the Promptfoo guide to build out the test harness after defining what a pass means.

Keep the request, retrieved evidence, proposed arguments, executed tool result, and final reply together in each test trace. When a case fails, that record tells you where to intervene. Give missing citations and invalid arguments explicit failures even if the prose receives a favorable judge score.

What Is Overhyped?

RAG does not make every answer true. A useful passage can be retrieved and misread; a stale passage can be quoted perfectly. Test retrieval and generation separately, and assign someone responsibility for the source collection.

A larger context window does not replace source selection. Anthropic's context-engineering guidance warns that recall and precision can degrade as context grows. Include the relevant rule, its exceptions, and necessary account evidence. Dumping every document into the prompt is not a freshness policy.

A second model saying “looks correct” is not verification by itself. Give reviewers the actual evidence and a clear criterion. Agreement without independent evidence can preserve the same unsupported assumption.

Valid JSON is not a correctness certificate. The schema can require a source ID and a numeric argument; your application must still establish that the source exists and that the number has the right meaning.

The limits that matter are the questions your sources cannot answer, the fields your checks cannot verify, and the actions you cannot safely reverse. There is no universal hallucination percentage that tells you whether your specific workflow is ready.

A Checklist Your Small Team Can Apply This Week

Act now if your feature makes factual promises to customers or changes business records. If it only drafts material that a responsible person already reviews against sources, start with the evaluation set and improve that review before adding an elaborate automated architecture. A deterministic lookup that already returns authoritative fields may need no model at all.

This is a suggested starter plan, not evidence that a week of work establishes production reliability.

The first Monday move is to take one recent wrong answer and preserve its entire trace. Identify whether the evidence was absent, outdated, misread, or bypassed. Add the smallest check that catches that failure, then make the incident a permanent regression case.

Questions About LLM Hallucinations

For practical guides to building dependable AI workflows, join the newsletter.