Retrieval-Based Consistency Checks

A retrieval-augmented support bot is given a policy document and asked whether a customer can get a refund after 45 days. The document says: "Refunds are available within 30 days of purchase. Enterprise customers may request an extension of up to 60 days, subject to approval."

The bot answers: "Yes, refunds are available for up to 60 days, so a 45-day-old purchase is eligible."

Every fact in that sentence appears in the source. The number 60 is there. The word "refunds" is there. A similarity metric scores this answer highly, because it overlaps heavily with the document. A human reads it and immediately sees the failure: the 60-day extension is conditional on being an Enterprise customer and on approval, and the bot dropped both conditions. The answer is unsupported despite being made entirely of supported pieces.

This is the gap that retrieval-based consistency checking exists to close. The question is not "does this text look like the source" — it is "does the source entail this specific claim". Those are different relations, and only the second one is what grounding actually promises.

The core relation: entailment, not similarity

Natural language inference (NLI) is the task of deciding, given a premise and a hypothesis, which of three relations holds:

Apply it to the opening failure. Premise: the policy paragraph. Hypothesis: "A 45-day-old purchase is eligible for a refund." A decent NLI model returns neutral or contradiction, because the premise only licenses that conclusion under conditions the hypothesis does not state. Cosine similarity between the two texts, meanwhile, is around 0.8. The two methods disagree, and the entailment answer is the correct one.

Similarity asks whether two texts are about the same thing. Entailment asks whether one guarantees the other. Grounding is a promise about the second, so measuring the first is measuring the wrong relation.

The models used are typically RoBERTa or DeBERTa fine-tuned on MNLI, or a purpose-trained faithfulness model. They cost a few milliseconds per pair on a GPU, which is what makes checking every claim in every response affordable.

The pipeline

Response   |[1] Decompose into atomic claims   |     "Refunds up to 60 days" + "45-day purchase is eligible"   |     (a compound sentence hides which half is unsupported)   v[2] Retrieve evidence per claim, k passages   |     query = the claim itself, not the original user question   v[3] Score each (passage, claim) pair with NLI   |     keep max entailment and max contradiction across passages   v[4] Decide: SUPPORTED / CONTRADICTED / NOT_ENOUGH_INFO   |[5] Aggregate to response-level and corpus-level rates

Three of those five steps are where the errors come from.

Step 1: decomposition is not optional

Run NLI on a whole paragraph and you get one label for a text containing six claims, five supported and one fabricated. The label will usually be "neutral", which tells you nothing. Atomic decomposition is what turns a vague verdict into a specific, fixable finding — and it also fixes the partial-truth problem, where a claim is 80% right.

Decompose so that each unit contains one predicate and its arguments, with any conditions attached:

BAD  (one claim):  "Refunds are available for up to 60 days, so a 45-day-old                    purchase is eligible."GOOD (three claims):  c1  Refunds have a standard window of 60 days.              -> CONTRADICTED (it is 30)  c2  A 60-day window requires Enterprise status and approval. -> not asserted; omission  c3  A 45-day-old purchase is eligible for a refund.          -> NOT ENTAILED

Step 2: retrieve with the claim, not the question

A common bug: the pipeline retrieves once using the user's question and reuses those passages to verify every claim. But the claims a model produces often concern details the question did not mention. Re-retrieving per claim, using the claim text as the query, typically raises evidence recall by 10 to 20 points on any realistic corpus. It costs one extra search per claim, which is cheap relative to the generation that produced it.

Step 3: the retriever bounds everything downstream

This is the most under-appreciated fact in the whole area. Your verification recall cannot exceed your retrieval recall. If the retriever finds the relevant passage 82% of the time and your NLI model is 91% accurate given the right passage, the end-to-end ceiling is:

You can spend a month upgrading the NLI model from 91% to 95% and gain $0.82 \times 0.04 = 3.3$ points. Raising retrieval recall from 82% to 92% gains $0.10 \times 0.91 = 9.1$ points, for less work. Measure recall@k on a labelled evidence set before you touch anything else, because it tells you which half of the system to invest in.

Making retrieval good enough

Sparse, dense, and why you want both

Fact-checking queries are unusually adversarial for dense retrieval, because the highest-risk claims are exactly the ones full of numbers and identifiers — the case where sparse retrieval is much stronger. So combine them with reciprocal rank fusion, which needs no score calibration:

Worked example with two documents:

D1 wins despite never being either retriever's top hit, because it is consistently good. That is the behaviour you want when the two retrievers have complementary blind spots. The constant $k = 60$ damps the influence of the top rank so a single retriever's confident mistake cannot dominate.

1from collections import defaultdict23def rrf(ranked_lists, k: int = 60, top_n: int = 10):4    """ranked_lists: list of lists of doc ids, each already in rank order."""5    scores = defaultdict(float)6    for lst in ranked_lists:7        for rank, doc_id in enumerate(lst, start=1):8            scores[doc_id] += 1.0 / (k + rank)9    return sorted(scores.items(), key=lambda kv: -kv[1])[:top_n]

Chunking decides what can be verified

If a claim requires two sentences that your chunker split apart, no retriever can supply entailing evidence and the claim will be labelled NEI forever. Practical rules: chunk on semantic boundaries rather than fixed token counts; overlap chunks by 15–20%; and keep a parent-document reference so the verifier can widen its window when the top chunk is nearly sufficient.

Turning NLI scores into verdicts

The NLI model returns a distribution over three labels. Turning that into a verdict requires thresholds, and the thresholds are a genuine engineering decision, not a default to accept.

1from dataclasses import dataclass23@dataclass4class Check:5    claim: str6    verdict: str7    entail: float8    contradict: float9    evidence_id: str | None1011def check_claim(claim, retriever, nli, k=5, tau_e=0.75, tau_c=0.70) -> Check:12    passages = retriever.search(claim, k=k)13    if not passages:14        return Check(claim, "NOT_ENOUGH_INFO", 0.0, 0.0, None)1516    best_e, best_c, best_id = 0.0, 0.0, None17    for p in passages:18        s = nli(premise=p.text, hypothesis=claim)19        if s["entailment"] > best_e:20            best_e, best_id = s["entailment"], p.id21        best_c = max(best_c, s["contradiction"])2223    if best_c >= tau_c and best_c > best_e:24        return Check(claim, "CONTRADICTED", best_e, best_c, best_id)25    if best_e >= tau_e:26        return Check(claim, "SUPPORTED", best_e, best_c, best_id)27    return Check(claim, "NOT_ENOUGH_INFO", best_e, best_c, best_id)

Note that contradiction is checked first. A claim with entailment 0.78 and contradiction 0.85 against different passages means your corpus disagrees with itself, or the claim is subtly wrong in a way one passage catches. Treating it as supported because the entailment threshold was met would hide the more important signal.

Choosing the threshold with data, not intuition

Label 200 claims by hand, then sweep:

Pick the row by asking what happens to a false SUPPORTED in your product. If it goes straight to a customer as a policy statement, take 0.85 and staff the review queue. If it feeds an internal quality dashboard, take 0.65 and keep the noise floor low.

The metrics, computed on a real batch

One batch: 40 responses, decomposed into 168 claims. Verdicts: 141 supported, 9 contradicted, 18 not enough info.

Report all three. They point at different bugs: contradiction rate is a generator problem, unverifiable rate is usually a retrieval or corpus-coverage problem, and only their sum shows up in faithfulness.

Response-level metrics matter too, because a user experiences responses, not claims. If 31 of the 40 responses have every claim supported:

The gap between 83.9% of claims and 77.5% of responses is informative: unsupported claims are somewhat concentrated, but not entirely — they are spread across 9 responses rather than clustered in 2.

The interval, computed correctly

The 168 claims come from 40 responses, so they are clustered and the naive standard error understates the noise. With average cluster size $m = 4.2$ and intra-cluster correlation $\rho = 0.25$:

So faithfulness is $83.9\% \pm 7.5\%$ at 95% confidence, roughly $[76.4\%,\ 91.4\%]$. Anyone comparing this to a 87.5% run from last week and declaring a regression is reading noise. To resolve a 4-point difference in faithfulness at this variance you need roughly $n_{\text{eff}} \approx 1{,}300$, meaning about 2,300 raw claims, meaning about 550 responses per arm.

Every consistency metric you compute is a proportion over clustered units. If your dashboard shows faithfulness to one decimal place with no interval, it is showing precision it does not have.

Self-consistency: checking without any source

Sometimes there is no document to check against. A useful proxy — the idea behind SelfCheckGPT — is that a model producing a fact it actually encoded will reproduce it across independent samples, while a fabrication will vary.

Sample the same prompt $k$ times at non-zero temperature, then measure agreement between the samples using the same NLI machinery, one sample as premise and the target claim as hypothesis.

Worked example with $k = 5$ samples, checking one claim against the other four, plus all pairwise comparisons — 10 pairs in total. If 7 pairs are mutually entailing:

Claims below about 0.5 consistency are strong hallucination candidates. Two hard limits, though:

• Cost. $k$ samples means $k$ times the generation spend. Practical only on a sample of traffic or on flagged responses.
• Stable falsehoods pass. A misconception the model has firmly encoded reproduces perfectly across samples and scores 1.0 consistency. Self-consistency detects uncertainty, not error, and those overlap only partially.

Multi-hop claims, where the arithmetic turns against you

Some claims cannot be verified by any single passage. "The company's current CTO previously worked at the firm that acquired our largest supplier" requires three separate retrievals chained together. Two things go wrong.

Retrieval cannot find the second hop from the original query. The passage naming the acquirer contains none of the terms in the claim about the CTO. You need iterative retrieval: verify hop one, extract the entity it resolves, use that entity as the query for hop two.

Errors compound multiplicatively. If each hop is verified correctly with probability 0.85:

At three hops your verifier is right about six times in ten — barely better than a coin flip on a binary decision. This is not fixable by improving the NLI model; going from 0.85 to 0.92 per hop still only reaches $0.92^3 = 0.779$. The practical response is to report multi-hop claims as a separate category with their own (much wider) uncertainty, rather than pooling them into a single faithfulness number where they silently degrade it.

1def verify_chain(claim_steps, retriever, nli):2    """Verify a multi-hop claim step by step, carrying resolved entities forward."""3    context, trace = {}, []4    for step in claim_steps:5        query = step["query_template"].format(**context)6        result = check_claim(query, retriever, nli)7        trace.append(result)8        if result.verdict != "SUPPORTED":9            return {"verdict": "UNVERIFIED", "failed_at": step["name"], "trace": trace}10        context[step["binds"]] = step["extract"](result)11    return {"verdict": "SUPPORTED", "trace": trace}

The failed_at field is the part worth keeping. "This claim failed at hop 2 because we could not establish who acquired the supplier" is actionable; "unverified" is not.

What this means when you run grounded generation in production

Instrument the retriever separately from the verifier, and put both on the same chart. Recall@k on a frozen labelled evidence set is a leading indicator: when it drops after a corpus re-index or an embedding-model upgrade, your faithfulness numbers will drop a week later and look like a model regression. Teams without retriever metrics reliably spend that week debugging the generator.

Return evidence identifiers with every verdict and store them. A faithfulness rate you cannot drill into is a number you cannot act on; a stored evidence trace lets you answer "why did we mark this unsupported" months later, when someone challenges a flagged response. It also gives you the labelled data for your next threshold sweep, essentially for free.

Finally, decide what the system does when a claim fails, before you build the checker. The options are: block the response, strip the unsupported sentence, append a hedge, or log and pass through. Each is right somewhere, and each implies a different threshold. A checker built without that decision made tends to end up as a dashboard nobody acts on — measuring, precisely and continuously, a problem that nothing in the system is empowered to fix.