Several people posting lately about how RAG + search is not enough:
"All the model gets is a list of links and snippets. It's not enough to make sense of most real business questions."
Agreed. If your pipeline stuffs ten search snippets into a prompt and hopes, you get confident mush. A snippet is a pointer to evidence, not the evidence. The fix is a step most RAG setups skip: page fetch plus a reader. Three parts.
1. Fetch the page, not the snippet
The search result is a pointer. So before generating, SWIRL fetches the actual page or document behind each top hit. Now the pipeline is working from the full source, not the 200 characters a search API happened to return.
2. Read it with a reader LLM
This is the part that matters. Some model reads each fetched page against the question and pulls out the passages that actually answer it, marking and scoring them. The chaff never reaches the expensive answering model.
Do extraction before generation, not instead of it.
3. Budget the context
Real pages do not fit neatly into a context window, so the reader either truncates to the highest-signal passages or marks them in place, best first, until the budget is spent. The answering model gets curated, ranked evidence instead of a pile of chunks competing for attention.
The result is the difference between "here are some links" and an answer you can act on. Same retrieval, far better grounding, because something actually read the sources before the model spoke.
That take is exactly why the reader step exists. Naive RAG earns its bad reputation. This is how you avoid it.
(And don't get me started about not having to put it all in a vector database first!)
Top comments (1)
The core is right, snippets are pointers to evidence, not the evidence, and doing extraction before generation instead of dumping links on the model is a real improvement. But the reader LLM step quietly relocates the exact failure you are fixing, and I do not think the piece grapples with that. A snippet is dumb but verbatim: a mechanical slice of the source, wrong only by being truncated. A reader LLM that extracts and scores answer-relevant passages is smart but fallible, and it fails in two directions that are worse than truncation. It can drop the one passage that actually answers the question, a recall miss, or confidently keep a passage that sounds relevant but is not, a precision miss. Either way your generator is now grounded on a curated subset that a model chose, and you trust it more precisely because it looks clean. That is confident mush moved one stage upstream, from the generator to the reader, and hidden behind tidy extraction.
Which means the claim "this improves grounding" is exactly the kind that has to be measured, and the measurement is specific: reader recall of the answer-bearing span. Build a small set of questions where you have marked the exact span in the source that answers each one, then check whether the reader's extracted output still contains that span. If it does not, your reader is silently dropping answers while looking better than snippets, and no amount of context budgeting downstream recovers a passage the reader already threw away. That number is also the only honest way to know whether two extra LLM passes earned their latency and cost. And it connects to the vector-database aside: you did not remove the retrieval problem by skipping the vector store, you moved it into the reader, which is more expensive and harder to measure than the recall@k you could have benchmarked cheaply. If you cannot cite recall for the retrieval you dropped, you certainly cannot cite it for the reader that replaced it.