7.3 Google Cloud's RAG Offerings and Grounding Services
Key Takeaways
- The exam guide names three Google Cloud grounding offerings: prebuilt RAG with Agent Search, RAG APIs, and Grounding with Google Search.
- Prebuilt RAG with Agent Search is the managed path - Google handles ingestion, chunking, embedding, indexing, and retrieval so a team ships in days rather than months.
- RAG APIs and the RAG Engine give builders component-level control over chunking, embedding models, and ranking when the managed defaults are not sufficient.
- Grounding with Google Search connects a model to fresh public web information and returns supporting search results, which addresses the knowledge cutoff rather than private data.
- Choosing between them is a build-versus-buy decision: managed for speed and lower operating burden, component APIs for control, Google Search grounding for public currency.
7.3 Google Cloud's RAG Offerings and Grounding Services
Executive Summary: Knowing what retrieval-augmented generation is does not answer the question a leader is actually asked: which Google Cloud service should we use, and what will it cost us in effort? The exam guide names three offerings explicitly - prebuilt RAG with Agent Search, RAG APIs, and Grounding with Google Search. They sit at different points on a build-versus-buy curve, and they solve two genuinely different problems: grounding in your data versus grounding in current public data.
The Three Offerings
| Offering | What Google manages | What you manage | Grounds the model in |
|---|---|---|---|
| Prebuilt RAG with Agent Search | Ingestion, chunking, embedding, indexing, retrieval, ranking, citations | Pointing it at your data and setting permissions | Your private enterprise data |
| RAG APIs / RAG Engine on Agent Platform | The individual components, offered as building blocks | Orchestration, chunking strategy, embedding choice, ranking, evaluation | Your private enterprise data |
| Grounding with Google Search | The entire retrieval path against Google Search | Enabling it and handling the returned supporting results | Current public web information |
Prebuilt RAG With Agent Search
Agent Search on Gemini Enterprise Agent Platform - the service formerly called Vertex AI Search - is the managed, end-to-end path. You connect a data source: a Cloud Storage bucket, a BigQuery table, a website, or a connected business system. Agent Search then handles the entire retrieval pipeline:
- Ingestion and parsing, including layout-aware handling of PDFs and tables
- Chunking documents into retrievable passages
- Embedding those chunks into vectors
- Indexing them for fast semantic retrieval
- Retrieval and ranking at query time, blending semantic and keyword signals
- Citation of the passages that supported the answer
Why this is usually the right default. Every one of those six steps is a place a hand-built pipeline goes wrong, and chunking strategy in particular is a subtle, high-impact choice that teams routinely get wrong on the first three attempts. A managed service ships a working grounded assistant in days. It also inherits enterprise essentials that hand-built pipelines frequently omit: entitlement-aware retrieval, so results respect each user's existing permissions.
RAG APIs and the RAG Engine
Some requirements exceed what a managed service exposes. RAG APIs and the RAG Engine on Gemini Enterprise Agent Platform provide the pipeline as composable components, letting a team choose its own chunking strategy, select or tune an embedding model, insert a custom re-ranking stage, or retrieve from a store it already operates such as Agent Platform Vector Search, AlloyDB, or Cloud SQL with vector extensions.
Choose this rung when:
- Documents have unusual structure that default chunking handles badly, such as deeply nested legal instruments or scientific papers with critical tables.
- A domain-tuned embedding model measurably outperforms the general one.
- Retrieval must join a pre-existing vector store the organization already runs.
- The team needs to instrument and evaluate each pipeline stage independently.
The trade-off to state plainly: component control transfers the operating burden - re-embedding on model upgrades, index freshness, retrieval quality regression testing - from Google to your team. That is a permanent staffing commitment, not a one-time build cost.
Grounding With Google Search
Grounding with Google Search solves a different problem. It does not connect the model to your documents; it connects the model to current public information, addressing the knowledge cutoff limitation. When enabled, the model can issue searches, incorporate the results, and return supporting links alongside its answer.
Use it when the question depends on public facts that change: current regulations, competitor announcements, market prices, recent events, published standards.
Do not use it for confidential internal questions. It cannot see your contracts, and routing internal queries through public search is both useless and a poor governance signal.
A mature architecture frequently uses both: Agent Search for the organization's own policies and contracts, and Google Search grounding for the current external context those policies must be applied against.
Choosing Between Them
| Scenario | Correct offering |
|---|---|
| "Ground an assistant in 200,000 internal documents; ship this quarter" | Prebuilt RAG with Agent Search |
| "Our documents are deeply nested regulatory filings and default chunking loses the hierarchy" | RAG APIs / RAG Engine |
| "The answer must reflect this week's published guidance" | Grounding with Google Search |
| "We already operate a vector database and must retrieve from it" | RAG APIs / RAG Engine |
| "Each user must see only documents they are permitted to see" | Prebuilt RAG with Agent Search, with entitlement-aware retrieval |
| "We need both internal policy and current external regulation" | Agent Search plus Grounding with Google Search |
The Requirements That Decide Production Success
Whichever offering is chosen, three questions determine whether a grounded system survives contact with production:
- Who owns freshness? An index is a cache of a moving corpus. Without a named owner and a refresh cadence, the assistant will confidently quote retired policy. This is the most common cause of grounded-system failure after launch.
- How are permissions enforced? Retrieval must filter to the asking user's entitlements. Enforcing this in the prompt is not a control.
- How is retrieval quality measured? Answer quality is bounded by retrieval quality. Teams should measure whether the correct passage was retrieved at all, separately from whether the generated answer read well - because a fluent answer built on the wrong passage is the most dangerous failure mode in the entire system.
Strategic Leadership Guidance: Exam Tips and Common Pitfalls
[!TIP] Exam Tip: Read the scenario for whose data grounds the answer. Private enterprise data points to Agent Search or the RAG APIs; current public information points to Grounding with Google Search. Scenarios often include a distractor that swaps the two.
Pitfall 1: Building a custom pipeline by default. Prebuilt RAG with Agent Search is the correct starting recommendation unless the scenario names a specific limitation the managed service cannot meet.
Pitfall 2: Believing Grounding with Google Search reaches internal data. It grounds in the public web. It has no visibility into your Drive, your database, or your contracts.
Pitfall 3: Treating grounding as a one-time build. Index freshness is an ongoing operational obligation with a named owner, not a launch task.
A compliance team needs an assistant that answers questions about regulations published in the last two weeks, citing the current public guidance. The organization's own documents are irrelevant to this use case. Which Google Cloud offering fits?
A team has spent four months hand-building an ingestion, chunking, embedding, and retrieval pipeline for 200,000 standard PDF policy documents, and retrieval quality is still poor. What should a Generative AI Leader recommend?
Which requirement most strongly justifies choosing the RAG APIs and RAG Engine over prebuilt RAG with Agent Search?