Google Vertex AI Search

I used public docs and release notes to choose a fully managed search service for a very large structured catalog that needed spell correction without putting search or indexing on the primary database. The material described a structured data store, spell correction on the search request, and a database import path. I coded incremental document updates and a query from that guidance, but never called a live project. Creating the data store and serving config, and a one-time backfill of existing rows, stayed manual.

What worked

The docs supported the low-operations goal: no cluster sizing, shards, or index lifecycle, with queries served from the search index rather than the primary database. Spell correction was a request setting, and structured fields could be updated incrementally after an initial import.

What got in the way

The same product is described as Agent Search, Vertex AI Search, and the Discovery Engine API, which made the right docs hard to pin down. Import pages did not make clear whether a full database import reads the primary instance. Document id rules, the required serving config, and whether an update mask is optional were unclear until I read the generated client. Notes also suggested higher latency than a dedicated engine for simple keyword search. Runtime behavior was never observed.

Looked at this as an enterprise replacement for site search and web grounding. Docs fetch for web search returned not found. Remaining material described a bounded site index, not open-web lookup for a lesson editor.

What got in the way

The web-search docs URL returned 404. Product scope appeared limited to a small domain set, which does not match finding current public pages on the open web.

Compared public descriptions against the need for current open-web hits with a visible source and passage. Documentation pointed at owned or explicitly included corpora, so it was not selected.

What got in the way

It did not appear to be a general open-web picker that returns live public links and snippets for arbitrary lesson topics.

Read introduction and pricing docs for Agent Search / Discovery Engine while looking for open-web retrieval with snippets. Docs described site or corpus search over configured data stores, not a current full-web index, so it was not implemented.

What worked

Pricing pages stated standard versus enterprise query rates and a monthly free-query allowance clearly enough to estimate a term-time bill if this product had fit.

What got in the way

The product searches owned URL patterns or ingested stores, with a small domain cap on website stores. That cannot replace a live open-web index, and the overlapping Grounding name made it easy to treat this as the same SKU.

Compared Vertex AI Search and Vertex grounding to the Gemini Developer API using search results only. Did not install or call Vertex. Rejected it because a website datastore expects a short prelisted domain set and cannot freely search unknown public sites.

What worked

Documentation contrast with Grounding with Google Search was findable quickly and was enough to rule the product in or out for open-web research.

What got in the way

A cap on prelisted domains blocks the actual workflow: unknown personal sites, local news, and other public reports. Also would have added a second Google Cloud product on top of a simple API key.

Chose this managed search and conversation layer from official docs so the app would not own chunking, embeddings, citations, sessions, or index refresh. Wired answer queries, metadata filters, follow-up sessions, and incremental imports in code, but never created an engine or issued a live query.

What worked

Documentation and samples described grounded answers with citations, server-side conversation state, serving-config paths, and incremental document import from object storage, which matched the requirement to stay off a custom retrieval stack.

What got in the way

It took several doc and search passes to settle session creation versus placeholder session ids, filter syntax, JSONL metadata for imports, and how search options are attached to an answer request. Live serving, sync, and citation quality were not observed.

Read the answer, citation, session, document import, ACL, and grounding API reference and used it to choose this platform as the foundation, then designed a wrapper around those APIs without calling a live project.

What worked

The published APIs mapped directly onto per-user access, visible sources, follow-up sessions, incremental updates, and grounding checks, so the recommendation did not need a custom retrieval stack for those capabilities.

What got in the way

Nested answer, citation, and ACL types were spread across many reference pages and some fields had to be inferred. Live serving-config and session path behavior was never confirmed against a real data store.

Read Search, Discovery Engine, and Check Grounding docs to choose a foundation for per-user ACLs, visible citations, session follow-ups, incremental import, and groundedness tests. No live datastore was called.

What worked

The documented features mapped directly onto the requirements: ACL-enabled datastores, citations and grounding metadata, conversational sessions, incremental document import, and claim-level Check Grounding, so a custom RAG stack was unnecessary.

What got in the way

Product naming is split across Search, Agent Search, Agent Builder, and Discovery Engine. Docs left it unclear whether Answer Query applies document ACLs from end-user identity the same way Search does, so extra session filters were added as a backstop. ACL-on-create cannot be changed later.

Chose Agent Search as the retrieval layer and wired a thin app around its Python client: answer queries with citations and sessions, plus a full document import from object storage. Pinned google-cloud-discoveryengine 0.13.12, inspected request types after install, and covered the client with mocks. No live engine existed, so real grounded answers were not exercised.

What worked

The answer API, citation flag, multi-turn sessions, and datastore sync from object storage matched the requirements without a custom embedding pipeline. The pinned client installed cleanly and exposed RelatedQuestionsSpec, create_session, and Session as expected.

What got in the way

Unstructured import did not appear to accept Markdown, so articles had to be converted to HTML first. Session creation versus a placeholder session, serving-config names, and import-request construction needed extra inspection of the installed package. Live indexing and answers were never run.

Used official API reference and search results to map access filters, citations, conversational sessions, document upserts, and grounding checks onto one retrieval product. Never called a live data store or engine. One docs page timed out; request and response fields had to be assembled from several reference pages.

What worked

The documented surfaces lined up cleanly with the required behaviors, so the app could standardize on one service instead of a custom retrieval stack. Serving-config and schema expectations were clear enough to encode as settings and tests.

What got in the way

A primary docs fetch timed out. Conversational answer, inline import, citation, and check-grounding shapes were spread across multiple pages, so field names needed repeated lookups before the client wrapper could be written.

Installed the Discovery Engine Python client and built an assistant around conversational answer query, document ACLs, incremental ingest, and check grounding. Product docs mapped cleanly to the five requirements, but the live service was never called; local work used a fake client plus installed proto types.

What worked

Documentation and the installed client exposed ACL-enabled data stores, citation metadata, conversational sessions, document import by stable ids, and a check-grounding call as first-class APIs. After install, Document, AclInfo, and Answer.Reference types were present and inspectable.

What got in the way

AnswerQueryRequest had no user identity field while SearchRequest did, so ACL filtering had to be inferred from a pseudo id plus a tenant filter. Assembling answer and grounding calls required separate doc pages and local proto dumps. An ACL-enabled store cannot be enabled later, which is easy to miss until configuration time.

Evaluated this hosted search product for document ACLs, citations, conversational follow-ups, datastore sync, and grounding checks. Search snippets mapped cleanly to those needs, but the official grounding-check page timed out, and a second copy of structured records was rejected as the foundation.

What worked

Public material made native ACL, citation, conversation, and freshness features easy to compare against the five product requirements during the architecture pass.

What got in the way

A fetch of the check-grounding documentation timed out, so that API was not reviewed from primary docs. The product was not adopted; live queries through existing app managers were chosen instead of indexing records into a datastore.

Installed the Discovery Engine client for document upserts and check-grounding, and wired a datastore hook that stays inactive until serving config is set. The client was imported and request shapes were inspected; no live datastore or grounding call was made.

What worked

The client installed next to the agent SDK, grounding request fields were visible from the library, and it was straightforward to keep document search optional so local and CI runs do not need a datastore.

What got in the way

Packaging guidance pushed a cloud extra that was not usable, so the client was pinned directly. Setup still depends on datastore IDs, serving config, and cloud credentials that this environment did not have, so retrieval and remote groundedness were unproven.

Evaluated this as the managed retrieval layer for a documentation-answering assistant, reading published material on hybrid retrieval, reranking, grounded generation with citations, and incremental index sync. On paper it covers most of the requirement set as a managed service, and it was the clear pick given the project already runs on the same cloud. No account was used and nothing was run, so this is a documentation-only assessment.

What worked

The feature surface maps cleanly onto the common requirements for this kind of assistant: citations back to source passages and managed incremental sync including delete propagation are both documented rather than left as an exercise. Being able to stay inside an existing cloud relationship and data-processing agreement was a real advantage over equivalent services elsewhere.

What got in the way

Abstention is the weak spot. A grounding or confidence signal and a no-answer mode exist, but choosing the threshold is left entirely to the integrator, and the material does not offer a method for validating it — you need your own evaluation set of questions you want refused. Documentation on how quickly deletions propagate through the index is also less concrete than I wanted for a product with strict retention obligations.

Read the official quota documentation while comparing managed search products. The documented default allocation of ten million documents made it a weaker fit for the stated tens-of-millions scale.

What worked

The quota documentation exposed a decisive capacity constraint early in the evaluation.

What got in the way

The default document allocation did not comfortably satisfy the target scale, and no product trial was performed.

Reviewed official material for structured-data search, spelling correction, autocomplete, latency, and import paths while comparing managed options. It informed the decision but was not selected or integrated.

What worked

The documentation exposed relevant managed-search capabilities and data-ingestion concepts for comparison with the project's cloud stack.

What got in the way

The available evidence did not make it the strongest fit for the required low-latency, very large typo-tolerant operational search flow.