What Is Grounding? | TMA Glossary

Grounding means tying a model’s answer to a real, checkable source. Instead of answering from memory, the model answers from documents, records, or search results you supply, and it shows where each claim came from.

It is the main practical defense against hallucination.

The definition vendors use

Google Cloud’s documentation defines grounding as the ability to connect model output to verifiable sources of information. If you give a model access to specific data sources, grounding tethers its output to that data and reduces the chance of inventing content. Google lists three benefits: fewer hallucinations, answers anchored to your data, and auditability through links to sources. It supports several source types, including web search, your own search indexes, and a RAG engine.

I use the same short test for any system: can a reviewer click from a claim to the passage that supports it?

How it works

Most grounded systems follow the same steps:

Retrieve. Find the most relevant passages, records, or pages for the question.
Supply. Put them in the model’s context.
Constrain. Tell the model to answer only from that material.
Attribute. Return the answer with references to the passages used.
Verify. Check, in code where possible, that quotes and IDs match the source.

The retrieval step usually relies on semantic search over a vector database, as part of a RAG system. The foundational RAG paper (Lewis et al., 2020) combined a pre-trained generator with a retriever over a Wikipedia index. Its authors noted that providing provenance for decisions and updating knowledge were open problems for models that rely only on stored parameters. Grounding addresses both.

Grounding sources are not only documents. Agents also ground on live system state. A tool call that fetches the current order status is grounding. So is a database lookup before quoting a price.

Grounding versus RAG

They overlap, but they are not the same thing. RAG is a technique: retrieve, then generate. Grounding is the goal: answers anchored to sources. You can run RAG badly and end up with an ungrounded answer. You can also ground without RAG, by calling a tool or by pasting a short document into the prompt.

Why OpenAI’s finding matters here

OpenAI’s research on why language models hallucinate says models guess when they face arbitrary facts and when evaluations reward guessing. Grounding changes the situation. The fact is now in front of the model, so it does not need to guess. But the model can still ignore the source or misread it, which is why the verify step matters.

How to test grounding

Build three kinds of test questions:

Answerable. The source has the answer. Check that the answer is right and the cited passage supports it.
Unanswerable. The source lacks it. The right output is “I could not find this.”
Conflicting. Two sources disagree. The right output flags the conflict or follows your stated precedence rule.

Then measure the share of claims that trace to a real passage. Model-based graders can help with this at scale, as long as you check them against human labels. See LLM as a judge.

A short example

Say a procurement assistant answers questions about supplier contracts. A user asks about the termination notice period for one supplier. The system retrieves that contract’s termination clause, passes it to the model, and returns the answer with a link to the clause and page. A check confirms the quoted sentence appears in the contract text. If the contract is not in the index, the assistant says so instead of guessing from similar contracts.

Common mistakes

Weak retrieval. The right passage is never fetched, so the model fills the gap.
Stuffing the context. Too many passages bury the useful one. See LLM context window.
Citations without checks. A link is not proof the passage says what the model claims.
Stale sources. The index is months old and nobody owns refresh.
No abstain path. The system always answers, even with nothing to ground on.
Mixed permissions. The retriever returns documents the asking user should not see.

A grounding checklist

Every factual claim can be traced to a passage, record, or tool result.
The answer shows the source to the user.
The system can say “not found.”
Quotes and IDs are checked against the source in code.
The index has an owner and a refresh schedule.
Retrieval respects the asking user’s permissions.
Test cases cover answerable, unanswerable, and conflicting sources.

If any line is missing, you have partial grounding. That may be acceptable for low-risk drafts. It is not enough for answers people will act on without checking.

RAG system is the usual implementation. Hallucination is the problem grounding solves. Semantic search finds the passages. For choosing a retrieval store, see best vector databases for production RAG.