An HR assistant answers policy questions from one index that holds global policies and country addenda. The chunks store text and embeddings but no country field. Employees in Germany sometimes receive the French parental-leave rule, which is worded almost identically and scores higher. Which change makes only applicable policies eligible as evidence?
Raise the similarity threshold until the French rule no longer passes
Rerank the candidates to place the German rule above the French one
Record each chunk’s country at ingestion and filter on it at retrieval
Instruct the model to prefer the policy for the employee’s country
Applicability is a structured fact, not a degree of similarity: two near-identical rules from different countries can both be strong matches, so a threshold or a reranker only changes which one scores higher, and a prompt instruction acts after the wrong rule is already in context. The chunk has to carry its country from ingestion so that retrieval can exclude ineligible chunks before they become evidence — metadata the ingestion flow discarded cannot be filtered on later.
Reviewing failed answers, a team finds that the retrieved chunks contained the correct policy clause and ranked it first, yet the answer added a refund deadline that appears in none of the supplied chunks. Which change targets the stage that failed?
Retrieve more candidates for each query
Rerank the retrieved candidates with a cross-encoder
Re-chunk the policy documents at clause boundaries
Check the answer’s claims against the supplied chunks
Retrieval and ranking did their job: the right clause arrived, first. The failure is in generation — a claim with no support in the supplied evidence. Checking the answer’s claims against the supplied facts flags the unsupported one, so the pipeline can revise the answer or abstain; retrieving more, reordering or re-chunking works on stages that were not failing.
An IT assistant always passes its top 5 retrieved chunks to the model. For questions the knowledge base does not cover, those chunks are weak matches, and the model answers from them anyway. The required behavior is to say that no approved source covers the question and to open a ticket. Which change enables that?
Lower top-k from 5 to 3 for every query
Add a score threshold and escalate on empty results
Rerank the five chunks before generation
Raise top-k from 5 to 10 for every query
Top-k limits how many candidates pass relative to each other, so it returns k chunks even when all of them are poor, and a reranker only reorders the same weak chunks. A minimum score — validated on labeled queries for this model and scoring setup — can return zero results, and an empty result is the signal the lifecycle needs to abstain and escalate instead of answering without evidence.
A compliance assistant indexes policies in fixed 256-token windows with no overlap. Answers often state a rule but omit the exception that follows it in the source, and evaluation shows that the rule and its exception usually land in different chunks. Which change addresses the cause?
Chunk along document structure, keeping each rule with its exceptions
Switch to an embedding model that scores higher on public benchmarks
Raise the chunk size to the embedding model’s maximum input length
Rerank retrieved chunks with a more precise relevance model
The evidence unit is broken: an arbitrary token boundary splits a rule from the exception that qualifies it, so no model or ranker can return them as one piece. Parsing by structure first and applying a size limit second keeps the exception with its rule. Filling chunks to the embedding input limit only moves the arbitrary boundary, dilutes each vector and spends context, while a better embedding model or a reranker works on chunks that are already split.
A team wants to replace its embedding model with a newer one that produces vectors of the same dimension. The index serves production traffic and already receives streaming upserts for changed documents. How should the team move to the new model?
Stream re-embedded chunks into the existing index as documents change
Re-embed every chunk and upsert all of them into the existing index
Build a separate index with the new model, validate it, then switch
Embed queries with the new model and keep the existing corpus vectors
Vectors from a different model belong to a different learned space even when their dimension matches, so they must never be compared with vectors or queries from the old model. A representation change is a new corpus version: build it in full beside the current index, validate it on the evaluation set, then switch query embedding and traffic together. Upserting in place, all at once or as documents change, mixes the two spaces while it runs and leaves nothing to fall back to.
Safety bulletins must become retrievable within ten minutes of approval. The ingestion job runs every five minutes, so the team reports the target as met. Which measurement shows whether it actually is?
The interval between two scheduled ingestion runs
The time from approval to a bulletin’s first retrieval
The p95 latency of retrieval queries for bulletins
The time the index takes to acknowledge an upsert
Freshness is visibility lag, measured end to end: parsing, embedding, queueing and index propagation all sit between approval and the moment retrieval can return the bulletin. A five-minute schedule says how often work starts, not when its result becomes searchable, and an acknowledged update can still take time to reach query results; query latency measures a different dimension entirely.
A team keeps raising Vector Search’s approximateNeighborsCount. Approximate results now match exact search on 99% of queries, but labeled relevant chunks are still missing from the candidates for a third of the evaluation queries, and exact search misses them too. Where is the problem?
In the approximate search settings of the index
In the ordering of the candidates sent to the model
In the serving capacity of the deployed index
In the chunks and embeddings that represent the corpus
When exact search also misses the labeled chunks, approximation is not what loses them. ANN recall measures agreement with exact search, and it is already 99%; relevance recall asks whether the evidence is found at all. The nearest neighbors themselves are wrong, so the fix lies in representation — the embedding model and its configuration, or chunks that do not form usable evidence units. More search effort only spends latency and cost, a reranker cannot reorder absent chunks, and capacity does not change results.
A pipeline retrieves 200 candidates, reranks them, and sends the top 5 to the model. The reranker improved grounded-answer quality, but p95 latency now exceeds its budget, and most of the added time is spent scoring candidates. Evaluation shows that Recall@40 is already 95%, almost the same as Recall@200. Which change best restores the latency budget while keeping the quality gain?
Pass the top 40 retrieved candidates to the reranker
Remove the reranker and send the top 5 retrieved candidates
Add replicas to the vector index that serves retrieval
Send the top 10 reranked candidates to the model
The reranker scores every candidate it receives, so K drives its cost. Because nearly all relevant evidence already sits in the first 40 candidates, the other 160 add scoring work without raising the recall ceiling. Removing the reranker gives up the measured quality gain, more index replicas speed up a stage that is not the bottleneck, and a larger N adds context without reducing reranking work.
A retrieval endpoint meets its 90% Recall@20 floor exactly, and its p95 latency target at normal traffic. Traffic bursts arrive within seconds, and p95 latency breaks the target during each burst while autoscaling is still adding replicas. Autoscaling never reaches its maximum replica count, and the budget has room for more always-on capacity. Which change fits?
Lower approximateNeighborsCount to reduce work per query
Raise the maximum replica count of the deployed index
Raise the minimum replica count of the deployed index
Autoscaling reacts after load arrives, so a burst that lands within seconds is served by whatever capacity is already running. The minimum replica count keeps that ready capacity in place, at a cost the budget allows. The maximum is never reached, so raising it changes nothing, and less search effort would push recall below a floor that is only just met.
A retailer wants “similar products” recommendations. Its own pipeline already produces product embeddings with a custom model, the catalog holds hundreds of millions of items, and the team requires explicit control over index configuration and endpoint deployment. No generated answer is involved. Which option meets these requirements with the least operational effort?
RAG Engine with a corpus on RagManagedDb
Vector Search with an index the team configures and deploys
An Agent Retrieval collection that manages the index for the team
A self-hosted vector database operated by the application
This is vector matching with no RAG workflow: the embeddings exist, and the requirement is explicit, high-scale control over the ANN index and its endpoint — the boundary Vector Search exposes. RAG Engine manages a document-to-context pipeline this workload does not have, and Agent Retrieval deliberately takes index management off the team’s hands. A self-hosted database would also give control, but adds infrastructure that the managed service already runs.
A maintenance agent answers from manuals already indexed in RAG Engine. It must now also tell technicians whether a spare part is in stock right now; stock levels live in a Cloud SQL database and change with every order. Which design fits this second source?
Index inventory rows in the RAG corpus and stream every change
Give the agent a tool that runs any SQL against the database
Export inventory nightly to BigQuery and retrieve it from there
Query the database at request time through a narrow read-only tool
Stock is changing transactional state with an authoritative system of record, so the agent should read it there, at request time, through a tool that exposes one business operation with read-only permission. Copying rows into a document corpus duplicates state that is stale the moment an order lands — streaming narrows the lag but never removes it — and a nightly export is staler still. An arbitrary-SQL tool reads the same data but lets the model author database queries and widens the blast radius of a wrong call.
An attacker copies a Google Cloud access token from an agent’s logs and tries to use it from their own machine a few minutes later. The agent runs with Agent Identity. Which property stops the replay?
The agent’s X.509 certificate is valid for only 24 hours
The token is bound to the agent’s X.509 certificate
The agent has a SPIFFE ID unique to its hosting resource
The agent’s IAM roles are granted to its own principal
A certificate-bound token is usable only by a client that proves possession of the matching private key over mTLS, and the attacker copied the token, not the key. A 24-hour validity still leaves minutes-old material inside its window, a unique SPIFFE ID improves attribution rather than preventing reuse, and per-agent IAM bindings limit what a replay could do rather than whether it works.
A team deletes an agent and deploys a replacement with the same display name. The replacement now gets a permission error on the BigQuery dataset it needs, although the IAM policy still contains the roles granted to the original agent. What should the team do?
Wait for the platform to renew the replacement’s certificate
Copy the original agent’s certificate into the replacement
Grant the roles to the new principal and remove the stale bindings
Give the replacement a user-managed service account key
A replacement agent is a new resource and therefore a new principal; the display name carries no identity. Bindings that named the original agent do not apply to it, and deleting an agent does not remove them, so grant the replacement explicitly and clean up the inactive grants. Certificates prove identity rather than grant permission, and a long-lived key reintroduces the shared credential that Agent Identity exists to avoid.
An agent with its own Agent Identity finds a Google Cloud remote MCP server through Agent Registry, but every tools/call to it fails with a permission error. The server was registered automatically when its API was enabled. Which change lets the agent call the tool?
Grant the agent’s principal MCP tool call and resource permissions
Register the server manually with its tool specifications
Give the agent write access to the server’s registry entry
Authenticate the agent with a service account key instead
Registration is discovery, not permission: the registry told the agent where the server is, but the server still authorizes each call. Google Cloud remote MCP servers require the MCP tool call permission plus the service’s own permissions on the resources a tool touches, and they accept Agent identities. Re-registering changes the catalog, registry write access lets an agent rewrite discovery, and a key changes the credential without granting anything.
A team connects its agent to a third-party remote MCP server it has not reviewed. Every tool on the server carries a read-only annotation, and the team must ensure that the agent cannot change data in the SaaS account behind it. What provides that guarantee?
The read-only annotations on the server’s tools
An instruction telling the agent to use only read tools
A read-only credential enforced by the SaaS system’s authorization
The server’s tool specifications registered in Agent Registry
Tool annotations are descriptive hints, and the MCP specification tells clients to treat them as untrusted unless the server is trusted — this one is unreviewed. A guarantee has to come from enforcement the agent cannot talk its way past: a credential limited to reads, checked by the destination system. An instruction is not enforcement, and a registry entry catalogs what the server claims rather than restricting what it does.