Grounding on a corpus you don't own

Building an index is tedious work, and it is easy to read that tedium as pure overhead. Point the retriever at a search engine instead and the ingestion pipeline, the chunker, the embedding bill and the freshness problem all disappear at once.

What also disappears is curation, and curation was doing more jobs than it looked like. Every one of them now has to be done somewhere else, at query time, on results a third party assembled for you moments ago.

What curation was actually doing

When you built the index, approving each document was a single decision that quietly settled four separate questions.

Authority. You put the employee handbook in and left the forum thread out. Relevance ranking never had to distinguish a definitive source from a plausible one, because you had already removed the second kind.

Access. Everything in the index was something someone was allowed to read, and you attached the rules saying who. An open-web result has no such marking — the question of who may see it is either trivially “everyone” or, worse, not something you thought about.

Stability. A chunk retrieved today is the chunk you’d retrieve tomorrow. That is what makes a bad answer reproducible.

Adversarial control. Nobody could get text into your prompt without getting a document into your corpus first. That barrier is the reason prompt injection in retrieved documents is usually a supply-chain worry rather than an open door. With a search retriever, the barrier is ranking for a query — which is an entire industry.

Notice that only the first of those is about quality. The other three are about control, and losing them is what actually changes how the system must be operated.

Scoping is the cheapest thing you can get back

The most effective single move is to stop searching the open web. Search operators let you restrict a query to one domain, and a domain you chose is a corpus you curated — just curated at the granularity of a whole site, evaluated at query time rather than at ingest time.

This is a real architecture, not a mitigation. Serply’s write-up of a support agent built on live site-scoped documentation search describes exactly the pattern: search your own documentation domain live, fetch the page, extract the relevant section, then answer — no index and no crawl schedule, and therefore no window in which a docs deploy has silently made your retrieval wrong. Their stated cost for it is two or three HTTP round trips per question instead of one embedding lookup, which is the honest shape of the trade: you pay in latency and you are billed per question rather than per document.

The reason it works is that the trust problem mostly evaporates. Results from a domain you control are as authoritative as your index was, because they are the same content — you have simply stopped keeping a copy of it.

Allow-lists, deny-lists, and the middle

Between one domain and the whole web there is a spectrum, and it is worth being deliberate about where you sit.

Allow-list. A handful of domains you trust: your own docs, a regulator, a standards body. Applied as operators in the query, or as a filter on results before they reach the prompt.

Deny-list. Everything except a set of known-bad hosts. Weak — the failure mode of an open-web retriever is not famous spam sites but the plausible unknown one — but cheap and worth having.

Tiering. No filtering, but pass a trust level with each passage and instruct the model to prefer higher tiers and to name the tier when it cites. More work, and it degrades gracefully when the trusted sources have nothing.

Filtering at the query is cheaper than filtering at the adapter: an operator costs nothing, whereas discarding results after the fact means you paid for them and may now have too few passages left to answer with.

Tell the generate stage what it’s holding

Whatever survives the filter, the model should be able to tell the sources apart. Pass the domain with each passage, not just the URL buried in a metadata line, and say in the prompt that sources are not equally reliable.

The instructions in grounding instructions that work mostly carry over, with two additions that only matter when the corpus is open:

Name the source in the answer, not just the citation. “According to the vendor’s documentation” and “according to a discussion forum” are different claims, and a reader can weigh them. A bare footnote number cannot be weighed.

Require agreement for anything consequential. One page asserting a number is a lead. Three independent domains asserting it is a fact. This is the same corroboration test that answer boxes are somebody else’s extraction applies to featured snippets, generalised to every passage in an uncurated result set.

Log the results, not just the query

The habit that makes an open-corpus system debuggable is storing what came back.

With an index, what to log about a RAG answer can lean on chunk IDs, because re-running the retrieval reproduces the passages. With a live search retriever it does not: the ranking changes, the pages change, and the answer box may simply not appear. A complaint about yesterday’s answer is uninvestigable unless you kept the actual result set — URLs, snippets, and any fetched text — alongside the query.

Store it, and a bad answer stays a diagnosable engineering problem. Skip it, and every incident report ends with someone re-running the query, getting a different and perfectly reasonable answer, and closing the ticket.