Hallucination reduction

Beginner

Models do not retrieve truth the way a database does. They predict likely next tokens. That makes them good at producing fluent answers, but fluency can hide the fact that a claim is unsupported. Hallucination reduction is the discipline of making the system prefer grounded, checkable, and sometimes incomplete answers over polished guesses.

What counts as a hallucination?

• Fabricated fact: the model invents a date, number, person, policy, or event.
• Fabricated source: it cites a paper, URL, quote, or section that does not exist.
• Unsupported synthesis: it combines true fragments into a new claim the evidence does not actually justify.
• Overstated certainty: the answer sounds definitive even though the evidence is weak, ambiguous, or missing.

What hallucination is not

Why hallucinations happen

• The model is rewarded for producing a continuation, not for proving a claim.
• The prompt asks for specifics that were never supplied.
• The task is too broad, ambiguous, or under-constrained.
• The system makes guessing feel cheaper than abstaining.
• Long answers create more opportunities for unsupported details to slip in.

First-line reduction tactics

• Ask the model to answer only from supplied evidence or known inputs.
• Require a fallback such as "I do not have enough evidence" when support is missing.
• Constrain output shape so unsupported fields are easier to detect.
• Prefer short, source-tethered answers for high-risk questions.
• Request explicit support for each important claim instead of one long free-form paragraph.

Real-world example: an internal assistant is asked for the current expense reimbursement limit. If the model cannot find a trusted policy excerpt, the safe behavior is to abstain or escalate, not to guess a number that sounds normal.

def build_safe_prompt(question, evidence):
    return f"""
Answer the question using only the evidence below.
If the evidence is insufficient, reply exactly: I do not have enough evidence.

Question: {question}
Evidence:
{evidence}
"""

print(build_safe_prompt(
    "What is the reimbursement cap?",
    "Policy excerpt: travel meals are reimbursed up to the approved daily allowance."
))

Intermediate

Effective hallucination reduction usually comes from a layered design. You prevent unsupported claims when possible, detect them when prevention fails, and recover safely when uncertainty stays high.

A practical defense stack

Claim-level thinking

Do not judge a long answer only at the paragraph level. A response can be mostly good but contain one invented number, one fake citation, or one unjustified causal statement. In practice, important claims should be isolated and checked individually.

def unsupported_claims(claims, evidence_text):
    unsupported = []
    normalized_evidence = evidence_text.lower()

    for claim in claims:
        if claim.lower() not in normalized_evidence:
            unsupported.append(claim)

    return unsupported

claims = [
    "Employees may carry over five vacation days",
    "Unused sick leave is paid out annually"
]

evidence = "Employees may carry over five vacation days into the next calendar year."

print(unsupported_claims(claims, evidence))

Common failure patterns and fixes

• Ambiguous question: ask a clarifying question before answering.
• Missing support: abstain rather than filling gaps with background knowledge.
• Too much freedom in the response: switch to structured output with required support fields.
• Long synthesis over many facts: generate a short answer first, then expand only if each claim remains supported.
• Policy or legal answers: require human review when the answer would trigger action.

User request
  -> classify risk and ambiguity
  -> answer only within allowed scope
  -> attach support for each important claim
  -> verify or flag unsupported content
  -> answer, abstain, or escalate

Advanced

At advanced maturity, hallucination reduction becomes a selective-generation problem: the system should answer when support is strong, refuse when support is weak, and surface uncertainty in ways the product and user can act on. The goal is not merely fewer false statements. The goal is better decision behavior under uncertainty.

High-value advanced patterns

• Schema-constrained generation: force the answer into fields like answer, support, uncertainty, and needs_review.
• Verifier models or rule checks: run a second pass that inspects whether each claim is actually supported.
• Selective abstention: accept lower answer rate if it sharply improves supported-answer quality.
• Human-in-the-loop thresholds: send high-impact or contradictory cases to a reviewer instead of pushing automation too far.
• Product-level honesty: expose uncertainty, sources, and caveats instead of presenting one polished sentence as ground truth.

Decision gating

def should_answer(evidence_score, verifier_passed, high_risk=False):
	if high_risk and not verifier_passed:
		return False
	if evidence_score < 0.75:
		return False
	return verifier_passed

decision = should_answer(
	evidence_score=0.68,
	verifier_passed=False,
	high_risk=True,
)

print(decision)

What strong systems optimize for

• Supported claim rate: how often important claims can be backed by trusted evidence.
• Abstention quality: whether the system refuses in the right cases instead of over-refusing or guessing.
• Citation correctness: whether the cited support really justifies the claim, not merely overlaps with it.
• Recovery behavior: whether the system asks clarifying questions, narrows scope, or escalates appropriately.

Safe answer policy

1. Is the question within scope?
2. Is there enough trusted support?
3. Does each critical claim have backing?
4. Did a verifier or rule check pass?
5. If any answer is no: abstain, clarify, or escalate

One recurring mistake is treating the model's own confidence as if it were a calibrated probability of truth. It is not. Self-reported confidence can be useful as a weak feature, but external support and post-generation checks are much stronger signals.

Another mistake is optimizing only for helpfulness. If the product punishes abstention too aggressively, the system will learn to answer uncertain questions anyway. Good hallucination reduction accepts a trade-off: sometimes the correct output is a refusal, a follow-up question, or a handoff.