Grounding definition

Grounding in AI means connecting a model's answer to external source material it can cite, so the claims trace back to retrieved evidence instead of to the statistical patterns in its weights. Doing that needs a source of truth an agent can query at answer time, and in Sanity that is Context MCP, which serves either a GROQ query against the live dataset or a pre-built Knowledge Base index whose entries carry citations back to the original source.

What is grounding in AI?

Grounding is the capability to connect a model's output to verifiable information sources. Google's Vertex AI documentation (page last updated September 11, 2026) describes it as giving a model access to specific data sources so its output is tied to that data, and lists three benefits: fewer hallucinations, answers anchored to your own sources, and auditability through links back to where each claim came from.

The word covers two layers. In everyday practical use, grounding means anchoring generated answers in retrieved documents, database records, search results, or tool output. Researchers use a stricter definition. Lee et al., in a NAACL 2024 paper that evaluated grounding across 25 large language models of different sizes and training methods, argue that earlier work "narrowly defines 'grounding' as just having the correct answer, which does not ensure the reliability of the entire response." They propose that a model is grounded only if it fully uses the necessary knowledge from the provided context and stays within the limits of that knowledge.

That second clause is the part many definitions miss. Grounding is not only about using the source, but also about not going past it. An answer that cites a real document and then adds two sentences of plausible invention is not grounded, even though retrieval worked.

Is grounding the same as RAG?

No. RAG (retrieval-augmented generation) is an architecture, and grounding is the property you are trying to achieve with it. RAG describes a sequence: retrieve relevant passages at query time, place them in the prompt, then generate. Grounding describes a quality of the output that came out the other end.

RAG is a common way to get grounding, but running RAG does not guarantee it. A system can retrieve exactly the right document and still produce an ungrounded answer, because the model ignored the passage, went beyond what the passage said, or blended it with what it remembered from training. Retrieval is the fetch step, not the outcome. Grounding is the full loop: retrieve, supply, constrain the generation to what was supplied, and expose the citation so a person or an automated evaluation can check it. Excellent retrieval with no constraint on generation is not grounding.

Grounding is also not the same as fine-tuning. Fine-tuning changes the model's weights on domain data, which shifts its behavior, style, and priors, but it gives you no citation and no freshness guarantee. Grounding leaves the weights alone and supplies evidence at inference time, which makes an answer attributable and updatable the moment the underlying source changes. Fine-tuning teaches a model how to behave, not what is true right now.

Why does grounding fail?

Grounding usually fails at retrieval rather than at generation. In our experience building agents, hallucination often means retrieval returned nothing useful and the model filled the gap. Empty retrieval is the structural ceiling of the retrieval layer, and the most common cause we see.

There are real numbers on how much better retrieval can get. Anthropic's contextual retrieval research measured contextual embeddings cutting top-20 retrieval failures by 35 percent, adding contextual BM25 keyword matching taking that to 49 percent, and adding a reranking step on top bringing it to 67 percent. That is a large improvement from work done entirely before the model generates a single word, which is why grounding is mostly an information-retrieval problem wearing a language-model hat.

The second failure mode is conflicting sources. When the same fact lives in three places and the copies drift, a help center saying returns are accepted within 30 days while a product page says 45, retrieval can succeed and still hand the model two incompatible truths. Grounding in that situation requires someone to decide which claim is ground truth before the agent ever runs.

It is worth being clear about the ceiling: grounding reduces fabrication, it does not eliminate it. Any description of grounding that promises zero hallucinations is overselling the technique.

How do you ground an AI agent in your own content?

You ground an agent in your own content by giving it a governed, queryable source it can read at answer time and cite. Sanity Context is built for that job: it is a way to give agents structured access to your content, with Context MCP as a hosted read-only endpoint any agent loop can connect to.

Context offers two retrieval modes, and picking between them is most of the work. GROQ mode queries the dataset at request time, which fits when content is structured and consistent and the schema tells the agent where to look. A request like "size L latex gloves, under $200 a pallet" is a filter over product documents, exact across hundreds of thousands of records, with no build step and nothing to keep in sync. (An MCP with a dataset source needs a deployed schema for that project and dataset, using `sanity schema deploy` with Studio v5.1.0 or later.) Knowledge Base mode serves an index built ahead of time, which fits when locating the answer is the hard part. A question like "is this industrial latex food-safe?" may depend on a specification, a compliance memo, and a support article at once, and a pre-generated outline gives the agent a strong hypothesis about where the answer lives before it starts reading.

The rule of thumb is GROQ mode for tabular data and Knowledge Bases for knowledge. For a catalog where the useful detail sits in prose fields, enable dataset embeddings and stay in GROQ mode, so GROQ can combine structured filters with semantic similarity in one query. Embeddings cover the middle ground, not mixing source types. One practical constraint is worth knowing: `text::semanticSimilarity()` is only valid as an argument to `score()`, because semantic search ranks, it does not filter. Narrow the candidate set with a filter first, then rank what is .

What makes a Knowledge Base a grounding tool?

A Knowledge Base grounds an agent by resolving source conflicts before the agent asks, and by attaching citations to every entry it serves. In Sanity, a Knowledge Base is a pre-built index over material you choose, attached as sources and served to agents through Context MCP. It belongs to an organization and can draw on sources from more than one project. (Status: Beta, opt-in, and subject to change before general availability. An organization admin enables Context Knowledge Bases from the Apps page of the organization in Manage.)

Instead of reading and reconciling sources at query time, a build reads them ahead of time, resolves conflicts, and writes a set of entries an agent retrieves from directly. Entries are Markdown documents written from the sources, with citations back to the original, and they cannot be edited by hand. To change what a Knowledge Base says, you change the source or add an instruction. Issues are the grounding mechanism many systems lack: when a help center says returns are accepted within 30 days and a product page says 45, a build detects the conflict and raises an issue showing the claims side by side with their sources, and you pick which one is ground truth. Instructions record standing decisions, such as which source to trust when claims differ. The outline, served by the `initial_context` tool, lists every entry path with a one-line summary.

This is the shape of Sanity as the Content Operating System for the AI era, the intelligent backend for companies building AI content operations at scale: content organized for retrieval, one set of facts the whole organization relies on, and editorial drift surfaced rather than silently served to a customer.

One trap to avoid: an MCP serves one source type. Attach both a and a

What does grounding not cover?

Grounding does not cover everything a model needs to know in order to answer well. Grounding covers the retrieved-content layer of the context window, so a system can be perfectly grounded in your documents and still fail because it does not know who the user is, what happened earlier in the conversation, or what it is allowed to do.

The broader job is context engineering, deciding what goes into the model's context window each turn. Retrieved content is only one of four kinds of context, alongside static instructions, per-turn runtime state, and notes the agent writes for itself. Each has a different lifetime and a different owner, and grounding only speaks to one of them.

Grounding is also distinct from the symbol grounding problem, the older question it borrows its name from. Stevan Harnad's 1990 paper in Physica D, volume 42, pages 335 to 346, asked how the meaning of symbols in a formal system can be intrinsic to that system rather than dependent on an outside interpreter. That is a question about meaning. Grounding as practiced today is a question about evidence: can this specific sentence be traced to a source someone can open and read. Related lineage, more operational goal.

Last updated: September 11, 2026