What grounding is

A language model knows the world through its training data. It knows nothing about your catalogue, today’s prices or the stock in your warehouse — and without external data it answers with a plausible guess, which is to say it hallucinates. Grounding ties the answer to verifiable data passed to the model at request time. An answer is grounded when every claim in it can be confirmed by a source: a product page, a database record, a policy page.

Grounding methods

Method How it works Which data
RAG Search over a knowledge-base index; the retrieved fragments go into the model’s context Specifications, descriptions, FAQ, return rules
Tool and API calls The model calls a function (function calling) and receives the system’s response Price, availability, delivery times — anything that changes during the day
Web search Web search results with links go into the context External facts; in the Gemini API the feature is literally called Grounding with Google Search
Session data Cart, the open product page, order history go into the prompt The individual shopper’s context

RAG is the most common method but not a synonym for grounding: an assistant can take descriptions from RAG and the price from a direct API request at the moment of answering.

How to tell that an answer is grounded

  • Source links. The answer shows the product pages it was built from, so the shopper and the support agent can check it.
  • Faithfulness (groundedness) metric. The share of claims in the answer supported by the supplied context. It is usually computed automatically: a separate model splits the answer into claims and checks each one against the context.
  • Retrieval recall. If the right product never made it into the context, even a grounded answer will be incomplete, so retrieval is checked separately.

Important: stale data “grounds” an answer too. If yesterday’s price is in the index, the model will state it confidently, with a source to back it.

Grounding in a store: a checklist

  1. Assign a source of truth to each type of fact: specifications come from the product feed, prices and stock from an API at answer time, delivery and returns from the knowledge base.
  2. Update the index as the feed changes, not on a once-a-day schedule.
  3. In the system prompt, require answers based only on the context and an “I don’t know” when the data is missing.
  4. Show product cards with links in the answer, not just text.
  5. Measure faithfulness on reference conversations before every release as part of LLM evaluation, and catch the remaining errors with guardrails.