Grounding with enterprise data and Google Search

The two failures left over from the sixth session had the same cause. Both questions asked about stock at stores that had changed their opening hours the week before, and the assistant answered with the old hours. The model had not invented them: they were in the product data Jules had pasted into the prompt for testing, which was a month old. "The model was faithful to bad data," Farah said. "Grounding is only as good as what you ground on. Today we look at how to connect the assistant to the right data, fresh, every time."

GCP-110 introduced grounding: anchoring a model's output in specific, verifiable sources so that answers reflect real, current facts rather than only what the model absorbed in training. This lesson covers the Google Cloud offerings for grounding that the exam guide names: Agent Search on Gemini Enterprise Agent Platform, prebuilt retrieval-augmented generation, the RAG APIs, Agent Platform Feature Store and grounding with Google Search, and how a leader chooses between them.

Why models need grounding

A foundation model learns from a huge amount of text up to a training cut-off date. It does not know Birchline's prices, this week's stock, the returns policy updated last month, or anything that happened after its training. Asked about those things without grounding, it may say it does not know, or it may produce a plausible but wrong answer, which GCP-110 called a hallucination. Grounding supplies the relevant facts with each request and asks the model to answer from them, ideally citing which source supported each claim.

Retrieval-augmented generation

The most common grounding pattern is retrieval-augmented generation (RAG). When a question arrives, the system first retrieves the most relevant passages from a collection of sources, then adds those passages to the prompt and asks the model to answer using them. The model's general language skill does the writing; the retrieved passages provide the facts.

Behind the scenes, RAG depends on preparation done before any question is asked. Documents are split into passages, often called chunks. Each chunk is turned into an embedding, a list of numbers that captures its meaning, so that a question and a passage about the same idea land close together even if they use different words. The embeddings go into an index that can be searched quickly. Access information travels with each chunk, so retrieval can respect permissions.

# A toy retrieval step: score passages against a question by shared meaningful words.
# Real systems use embeddings; this shows the idea of "retrieve, then generate".
passages = {
    "store-hours-S014": "Riverside store hours from November 2: Monday to Saturday 9 to 8, Sunday 10 to 6.",
    "returns-policy": "Unused items can be returned within 60 days with a receipt.",
    "drybag-40": "40-litre roll-top dry bag, welded seams, available in yellow and blue.",
}
stop = {"the", "is", "a", "to", "and", "with", "in", "on", "what", "are", "from"}

def words(text):
    return {w.strip(".,:?").lower() for w in text.split()} - stop

question = "What are the Riverside store hours on Sunday?"
scores = {k: len(words(question) & words(v)) for k, v in passages.items()}
best = max(scores, key=scores.get)
print("scores:", scores)
print("retrieved:", best)
print("prompt sent to model: answer using only ->", passages[best])

scores: {'store-hours-S014': 4, 'returns-policy': 0, 'drybag-40': 0}
retrieved: store-hours-S014
prompt sent to model: answer using only -> Riverside store hours from November 2: Monday to Saturday 9 to 8, Sunday 10 to 6.

Agent Search: prebuilt RAG

Building a RAG system from scratch means handling document parsing, chunking, embeddings, indexing, ranking, permissions and freshness. Agent Search on Gemini Enterprise Agent Platform, formerly Vertex AI Search, provides this as a managed, prebuilt service. A team points it at data, such as a website, documents in Cloud Storage, structured product records in BigQuery, or other connected sources, and it builds and maintains the index. Applications and agents then query it to get relevant results, summaries and grounded answers with citations.

Agent Search serves two purposes that the exam guide mentions separately. It is a grounding source for apps and agents, as in the shopping assistant. It is also an external search offering, powering search and recommendations for a company's own customers, such as the search box and "you may also like" panel on birchline.example. Lesson 3 explained that Gemini Enterprise is for employees; Agent Search is how a company builds the equivalent experience for the public.

The last row answered Farah's opening problem. Store stock and hours change daily, sometimes hourly. Rather than indexing them, the assistant should call a function that reads the store system directly at the moment of the question, as lesson 7 described. Slower-changing material, such as buying guides and manuals, suits an index. Most real systems combine both: indexed sources for knowledge and live tools for facts that must be current to the minute.

RAG APIs: building your own pipeline

Some teams need more control than a prebuilt service offers, for example to use a particular chunking method, a specific embedding model or a vector database they already run. The RAG APIs on the platform provide the building blocks, such as managing a document corpus, choosing how documents are split and embedded, and retrieving context for a prompt, so developers can assemble a custom pipeline. Farah's rule was the same as elsewhere: start with the prebuilt option and move to custom building blocks only when there is a specific need.

Agent Platform Feature Store

The exam guide mentions Agent Platform Feature Store in its section on improving model output. A feature is a piece of data prepared for a model, such as a customer's number of orders last year or a product's average rating. Feature Store keeps such values organized, up to date and quickly retrievable, so models and agents use the same consistent data in training and in live use. For generative AI, it can supply facts about a customer or product to a prompt at the moment of a request, for example the customer's preferred store or past purchases, under appropriate privacy rules. For a leader, the key point is consistency: the same definitions of data, kept fresh, used everywhere.

Grounding with Google Search

Some questions need public, current information rather than company data: tomorrow's weather forecast for a hiking area, a park's current fire restrictions, or this season's trail closures. Grounding with Google Search lets a model on the platform use Google Search results to answer such questions and cite the web pages it used. It is useful when freshness and breadth of public information matter. It is not a substitute for company data, and it brings considerations of its own: web results vary in reliability, citations should be shown, and some organizations limit which questions may use web grounding.

Jules liked the idea of the assistant checking National Park Service alerts before recommending a route. Teresa asked that web-grounded answers always show their sources and that safety-critical advice, such as whether a trail is open, always tell the customer to check the official source before setting out. Both rules went into the system instructions.

Measuring grounding quality

Grounding reduces errors but does not remove them. Retrieval can miss the right passage, return an outdated one, or return a passage that the model then misreads. The platform's evaluation tools include measures of groundedness, whether each claim in an answer is supported by the retrieved sources, alongside accuracy and relevance. Farah added two practical checks: test questions whose correct answers recently changed, to catch stale data, and test questions whose answers are not in any source, to make sure the assistant says it does not know rather than guessing.

# Groundedness check: is each claim in the answer supported by a retrieved passage?
retrieved = ["Riverside store: Sunday 10 to 6.", "Dry bag 40 litres, welded seams."]
answer_claims = [
    "The Riverside store is open Sunday 10 to 6.",
    "The dry bag has welded seams.",
    "The dry bag comes with a lifetime warranty.",
]
def supported(claim):
    key = [w.strip(".,").lower() for w in claim.split() if len(w) > 3]
    return any(sum(k in p.lower() for k in key) >= 2 for p in retrieved)
ok = [supported(c) for c in answer_claims]
for c, s in zip(answer_claims, ok):
    print("supported  " if s else "UNSUPPORTED", c)
print(f"groundedness: {sum(ok)} of {len(ok)} claims")

supported   The Riverside store is open Sunday 10 to 6.
supported   The dry bag has welded seams.
UNSUPPORTED The dry bag comes with a lifetime warranty.
groundedness: 2 of 3 claims

Keeping grounding sources healthy

A grounding source is a living thing. Products are added and discontinued, policies are rewritten, and buying guides go out of date when gear changes. Ravi set up three routines. The catalog index refreshes automatically from BigQuery every night. Each policy and guide in the index has an owner and a review date, and a monthly report lists anything past its date. And a short list of questions whose answers recently changed is added to the evaluation set every month, so stale answers are caught quickly.

Ravi also added a simple rule for conflicting sources. When two documents disagree, the assistant should not choose between them silently. Its instructions tell it to give the answer from the newer approved document and to flag the conflict in the logs, so a content owner can resolve it. Conflicts found this way go straight to the content owner's queue.

Ravi's data engineer connected the catalog table in BigQuery to Agent Search the next morning. The store hours moved behind a function that read the store system. When the two failing test questions were rerun, both passed.