Grounding gets talked about as if it were a property of the model — something you buy, or a switch you flip, or a claim on a pricing page. It is none of those. It is a rule about where answers are allowed to come from, and whether the product enforces that rule when the material is thin.
The glossary definition of grounding is blunt on purpose: constrain the answer to supplied source material, and decline when nothing relevant was retrieved. Everything else — embeddings, chunk boundaries, citation chips — exists to make that rule cheap to follow and cheap to check.
What grounding is actually doing
A language model predicts likely text. Asked about your refund window, it will produce a refund window that sounds like the kind of policy shops usually have. That is not a bug in the model; it is the model doing its job. Grounding changes the job: retrieve passages from your content, put them in context, and require the answer to come from those passages alone.
That is retrieval-augmented generation in one sentence. The mystique arrives when teams treat “grounded” as a badge rather than a pipeline you can inspect — retrieval quality, prompt constraints, and a refusal path when retrieval comes up empty.
Three places grounding quietly fails
- Retrieval returns a near-miss page — related topic, wrong fact — and the model answers faithfully from the wrong passage.
- Retrieval returns nothing useful, but the prompt still allows a “helpful” guess from training patterns.
- The UI shows a citation chip that points at a homepage or category page that never contained the claim.
Only the second one feels like classic hallucination. The first is a retrieval failure that looks identical to the customer. The third is theatre: it looks like accountability and provides none. Debugging means opening the citation, not arguing with the prose.
How to verify without a research team
Pick ten questions you already know the answers to. For each answered response, open every citation. Ask two things only: does the link resolve to a real page on your site, and does that page contain the claim? If either fails, the answer was not grounded in the sense that matters to a customer.
Then ask something your site does not cover. The grounded behaviour is a plain decline and a path to a person. A fluent invention delivered in the same register as true answers means the constraint is optional — which means it is not a constraint.
| Check | Pass | Fail |
|---|---|---|
| Citation resolves | Real page on your domain | 404, homepage, or unrelated hub |
| Page supports the claim | Same fact, same numbers | Topic match only |
| Gap question | Declines, offers a human | Invented policy in confident prose |
What grounding does not buy you
It does not fix missing documentation. If the refund rule lives only in a Slack thread, no architecture will retrieve it. It does not fix bad chunking that splits a table from its header. It does not make clinical, legal, or account-specific judgements safe — those need a person, and a grounded product should say so.
It also does not make answer rate a quality metric. A system that answers everything scores high and tells you nothing about whether the answers were allowed by the material. Prefer the refusal list and citation audits over a single percentage.
The shortest version
- Grounding means: answer from retrieved passages, or refuse.
- Check citations, not vibes — the page must contain the claim.
- Wrong-page retrieval and empty retrieval fail differently; both need fixes.
- Missing content is a publishing problem, not a model upgrade.
If you want the operational loop after the audit, the guide on reducing hallucinations walks the same checks from the inbox side — what to fix in content first, and when the product behaviour is the actual leak.
