How would you detect unsupported claims across production RAG traffic on a budget?

## Framing: detection is a portfolio, not a metric Scoring every production answer with a full claim-decomposition pipeline roughly doubles or triples the cost of the system and adds latency you cannot spend online. Scoring nothing means you learn about hallucinations from customers. The engineering answer is a portfolio of detectors with different cost, coverage and precision, arranged so that expensive signals only run where they pay. ## The cost ladder **Deterministic checks (cents per million answers).** Extract numbers, dates, monetary amounts, identifiers, and named entities from the answer and confirm each appears in — or is derivable from — the retrieved context. Verify that anything presented as a quotation is a literal span of a retrieved passage. These checks are cheap, deterministic, explainable and run inline. Their precision on numeric fabrication is high, which matters because the fabrications that cause real damage in enterprise RAG are overwhelmingly numeric or nominal: an invented amount, an invented deadline, an invented product name. Their recall on soft claims is poor, and they produce false alarms on legitimate arithmetic or unit conversion, so treat a hit as a flag rather than a verdict. **Small entailment models (fractions of a cent).** A compact natural-language-inference model over answer sentences against context passages. Fast, deterministic, cheap enough to run on a large fraction of traffic. Weak on multi-hop support spread across passages and on heavy paraphrase, so calibrate its threshold to favour recall and let the next tier arbitrate. **Judge models with a claim-level rubric (cents per answer).** The most accurate automated tier and the most expensive by one to two orders of magnitude, plus non-trivial latency. Reserve it for flagged answers, for the highest-stakes query classes, and for an offline sample. Any judge you rely on needs its own validity work — agreement against human labels on a slice — before its numbers carry weight. **Human adjudication (dollars per answer).** Not a monitoring tier; a calibration tier. Its job is to produce the ground truth that tells you what the automated tiers are missing. ## Sampling that actually finds things Uniform random sampling is the default and usually the wrong one. Hallucination risk is concentrated: queries with thin retrieval, queries whose context passages contradict each other, long answers, low-similarity top results, novel or out-of-distribution phrasing, and high-stakes query classes. Stratify by these and oversample the risky strata, then reweight when you report an overall rate so the headline number stays unbiased. A 1% uniform sample of mostly-easy traffic tells you almost nothing about the 0.2% of queries that generate incidents. Also sample the *passing* population deliberately. A detector whose false-negative rate you never measure will quietly degrade — new content types, a model upgrade, a prompt change — and only a labelled slice of answers it cleared will reveal it. ## Turning a score into an action Detection is worthless without a policy, and the policy should scale with blast radius: - **Advisory.** Log and dashboard only. Right for low-stakes informational queries where a false alarm costs more than a rare bad answer. - **Degrade.** Strip the unsupported sentence, or fall back to quoting the source passage instead of paraphrasing it. - **Regenerate.** One retry with the flagged claim named and a tighter grounding instruction. Bounded — a single retry, never a loop, or tail latency and cost become unpredictable. - **Abstain.** Return "I could not verify this in the available documents." Honest, and it converts a wrong answer into a mild disappointment. - **Escalate.** Route to a human before the answer is shown. Only affordable for narrow, high-stakes classes. Each step costs latency, cost or usefulness, so tie the choice to the query class rather than applying one policy to all traffic. And keep the abstention rate on a dashboard: aggressive detection policies push a system toward refusing, which looks excellent on grounding metrics and terrible to users. ## Operating it over time Three things drift and each needs a watch. **The corpus** changes, so a detector tuned on last quarter's content classes may misfire on new ones. **The generator** changes with every model or prompt update, shifting the mix of failure modes. **The judge** changes when its underlying model is upgraded, which silently moves your thresholds — pin versions where the provider allows it, and re-run a frozen labelled slice after any judge change so you can tell a real quality shift from a measurement shift. Finally, budget honestly. Detection is a fixed percentage tax on the system, and it is worth stating that percentage explicitly — say, five to ten percent of inference spend — so the tiering is designed to a number rather than discovered when the bill arrives. That framing also makes the tradeoff legible to non-engineers: you are buying a known reduction in undetected wrong answers for a known cost, and the right point on that curve is a business decision about the domain's tolerance for a confidently wrong answer, not a purely technical one.