Reducing Unsupported Claims in Context-Based Answers

What Is an Unsupported Claim? An unsupported claim is a statement in an answer that the provided context does not support. In RAG systems, unsupported claims are especially harmful because they appear next to supported, cited statements, so users trust them too.

Unsupported claims are a form of what is often called hallucination: confident output that is not grounded in fact or in the given information. Lessons 104 and 105 focused on prompting for grounded answers and handling missing information. This lesson takes a complete approach to unsupported claims:

Prevent → prompt rules that make unsupported claims less likely Detect → code checks and model-based verification of each claim Correct → remove, revise, or escalate unsupported claims Measure → track the unsupported-claim rate over time The Six Common Types Recognizing the types makes prevention and detection far more effective.

Type Source Says Answer Says Added detail "Refunds reach the original payment method within 5–7 business days." "...within 5–7 business days, and you'll receive an email confirmation." Overgeneralization "Recordings of live classes are available." "Recordings are available for all course content." Certainty shift "Late applications may be considered." "Late applications will be accepted." Merged facts Source A: Django course is 6 weeks. Source B: React course costs ₹2,999. "The 6-week Django course costs ₹2,999." Outside knowledge (nothing about payment speed) "UPI refunds are usually instant." Wrong attribution Fact is in source B Fact is cited to source A Certainty shifts and merged facts are the hardest to notice, because every word in the claim appears in the sources. Only the meaning has changed.

Step 1: Prevent Add rules that target each type directly:

Rules for using the sources:

• Every factual sentence must be supported by the source it cites.
• Do not add details, even typical or likely ones, that the sources do not state.
• Keep the scope of each statement: do not turn "some" or "live classes" into "all" or "everything".
• Keep the certainty of each statement: "may" must stay "may", "usually" must stay "usually".
• Combine facts from different sources only when the sources are about the same thing.
• If the sources do not support a statement, leave it out. Why Naming the Types Helps General instructions such as "be accurate" do not tell the model what inaccuracy looks like. Naming scope and certainty explicitly draws attention to errors that otherwise feel like natural paraphrasing.

Shorter Answers Contain Fewer Unsupported Claims Every extra sentence is another opportunity for an unsupported claim. A clear length limit, such as "at most 4 sentences", reduces risk, as long as it does not force important information out.

Step 2: Detect Detection works in two layers.

Layer 1: Code Checks The grounding check from Lesson 104 catches sentences without citations, unknown source IDs, and changed numbers. It is fast, free, and should run on every answer.

Layer 2: Claim-Level Verification With a Model For claims that code cannot check, such as added details, certainty shifts, and merged facts, use a separate verification prompt that examines each claim individually.

Splitting the Answer Into Claims import re

def split_claims(answer: str) -> list[str]: """Treat each sentence of the answer as one claim.""" return [s.strip() for s in re.split(r"(?<=[.!?])\s+", answer.strip()) if s.strip()] Treating each sentence as one claim is a simple, practical approximation. Sentences that combine several facts with "and" can be split further, either by code or by a prompt that rewrites the answer as a list of single-fact claims.

The Verification Prompt For each numbered claim in , decide whether the sources in support it.

Labels:

• SUPPORTED: the sources state this, with the same meaning, scope, and certainty
• UNSUPPORTED: the sources do not state this, or state something different

For SUPPORTED claims, copy the exact sentence from the sources that supports it as "evidence". Pay special attention to added details, broader scope ("all" vs "some"), and stronger certainty ("will" vs "may").

Return only a JSON array: [{"claim": number, "label": "...", "evidence": "..."}] Why Verification Is a Separate Step The model that wrote the answer tends to believe its own sentences. A separate verification request, focused on one question per claim, judges more critically (Lesson 10, Tip 6). Requiring exact evidence quotes for supported claims adds a further check: code can confirm the quote exists in the sources (Lesson 70). A "supported" label with an invented quote is itself a sign of a problem.

Step 3: Correct Once each claim has a label, decide what to do with the answer. The policy below keeps supported claims, removes unsupported ones, and escalates when too much of the answer is unsupported.

import json

def apply_verdicts(claims: list[str], verdicts: list[dict], max_unsupported_share: float = 0.34) -> dict: """Remove unsupported claims, or escalate if too many are unsupported.""" by_number = {v["claim"]: v for v in verdicts} kept, removed = [], [] for number, claim in enumerate(claims, start=1): verdict = by_number.get(number, {"label": "UNSUPPORTED"}) (kept if verdict["label"] == "SUPPORTED" else removed).append(claim) share = len(removed) / len(claims) if claims else 0 if share > max_unsupported_share or not kept: action = "escalate" else: action = "revised" if removed else "ok" return {"action": action, "answer": " ".join(kept), "removed": removed, "unsupported_share": round(share, 2)}

answer = ("Refunds are available within 7 days of purchase [refund-policy#0]. " "Approved refunds reach the original payment method within 5 to 7 business days [refund-policy#1]. " "Refunds are processed faster for premium members.") claims = split_claims(answer) verdicts = [ {"claim": 1, "label": "SUPPORTED", "evidence": "Refunds are available within 7 days of purchase."}, {"claim": 2, "label": "SUPPORTED", "evidence": "Approved refunds reach the original payment method within 5 to 7 business days."}, {"claim": 3, "label": "UNSUPPORTED", "evidence": ""}, ]

print(json.dumps(apply_verdicts(claims, verdicts), indent=2)) print(apply_verdicts(claims, verdicts[:1])["action"]) Output:

{ "action": "revised", "answer": "Refunds are available within 7 days of purchase [refund-policy#0]. Approved refunds reach the original payment method within 5 to 7 business days [refund-policy#1].", "removed": [ "Refunds are processed faster for premium members." ], "unsupported_share": 0.33 } escalate Code Explanation Missing verdicts count as unsupported by_number.get(number, {"label": "UNSUPPORTED"}) treats any claim the verifier did not label as unsupported. This is a safe default: if verification is incomplete, nothing unverified is kept.

Removal The invented claim about premium members is removed. The remaining answer still makes sense, because each claim is a complete sentence.

Escalation If more than about a third of the claims are unsupported, or nothing is left, the answer is not repaired but escalated, for example to regeneration with stricter instructions or to a human agent. In the second call, only one verdict was provided, so two of three claims count as unsupported (67%), and the result is escalate.

Removing vs Rewriting Approach Advantage Risk Remove unsupported sentences Simple and safe; cannot introduce new errors The answer may become incomplete or awkward Ask the model to rewrite Fluent result The rewrite can introduce new unsupported claims, so it must be verified again Escalate Safe for high-stakes answers Slower; requires a fallback path For most help assistants, removing unsupported sentences and escalating heavily affected answers is a good default.

Step 4: Measure To know whether your changes help, measure the unsupported-claim rate on a fixed set of test questions (Lessons 115 and 119):

unsupported-claim rate = unsupported claims / total claims, across all test answers Track it alongside other metrics:

Metric Why Unsupported-claim rate The main measure of faithfulness Answers escalated How often the system cannot produce a clean answer Correct "not found" rate Whether the system admits missing information (Lesson 105) Answer completeness Whether reducing unsupported claims made answers too short or unhelpful The last metric matters: a system that answers almost nothing has few unsupported claims but is not useful. Improvements should reduce unsupported claims without a large drop in completeness (Lesson 117).

When to Use Each Layer Situation Recommended Layers Low-risk answers, such as general study tips Prevention rules + code checks Policy, pricing, or schedule answers Prevention + code checks + claim verification Legal, financial, or health-related information All layers, strict grounding (Lesson 104), and human review for escalations High-volume, cost-sensitive systems Prevention + code checks on all answers; verify a sample, plus answers that fail code checks Claim verification costs an extra model call per answer, so apply it where the risk justifies the cost.

Common Mistakes Mistake 1: Checking Only Whether Citations Exist What it is: Treating any cited sentence as supported.

Why it happens: Citations look like proof.

What it causes: Wrong attributions, certainty shifts, and added details pass unnoticed.

How to fix it: Verify that the cited source actually supports each claim.

Mistake 2: Self-Verification in the Same Response What it is: Asking the model to "double-check your answer" at the end of the same prompt.

Why it happens: It seems efficient.

What it causes: The model usually confirms its own claims.

How to fix it: Verify in a separate request, claim by claim, with evidence quotes.

Mistake 3: Rewriting Without Re-Verifying What it is: Asking the model to fix unsupported claims and publishing the rewrite directly.

Why it happens: The fix seems complete.

What it causes: New unsupported claims in the rewritten answer.

How to fix it: Verify rewritten answers again, or remove claims instead of rewriting.

Mistake 4: Optimizing Only for Fewer Unsupported Claims What it is: Making the assistant so cautious that it rarely answers.

Why it happens: The unsupported-claim rate is the only metric tracked.

What it causes: Users stop using an unhelpful assistant.

How to fix it: Track completeness and correct answers alongside unsupported claims.

Best Practices Know the six types. Added detail, overgeneralization, certainty shift, merged facts, outside knowledge, wrong attribution.

Prevent with specific rules. Name scope, certainty, and combination rules explicitly.

Detect in layers. Code checks for every answer; claim verification where risk justifies it.

Require evidence quotes, and check them. A supported label needs a real supporting sentence.

Correct safely. Remove unsupported claims, escalate heavily affected answers, and re-verify rewrites.

Measure faithfulness and usefulness together. Fewer unsupported claims must not mean fewer useful answers.

Try It Yourself Exercise 1: Classify Unsupported Claims Write one source paragraph about live class recordings, and six answer sentences, each demonstrating one type of unsupported claim. Run the verification prompt and record which types it detects and which it misses.

Exercise 2: Verify and Correct Generate answers for ten questions with your RAG prompt. Split each answer into claims, verify them with the verification prompt, check every evidence quote against the sources in code, and apply apply_verdicts(). Count how many answers were ok, revised, or escalated.

Exercise 3: Measure an Improvement Calculate the unsupported-claim rate for your ten answers. Then add the prevention rules from Step 1 to your answer prompt, regenerate the answers, and measure again. Also check whether any answers became less complete.