A fluent RAG answer can still be wrong because the right passage never reached the model. The retrieval engine comes first: inverted indexes, BM25, dense vectors and the ranking signals that decide what survives. One practical rule carries through the harder cases: inspect the bad queries before adding another layer. Filters, rerankers and query decomposition earn their place that way. Writer's graph work shows why repeated enterprise language can confuse vector similarity, while a FIFA corpus makes the case for text-to-SQL when the question asks for counts or comparisons across the whole collection. Agent search only helps once that retrieval layer works. Its tests catch web access that silently failed and require current evidence, so a bad score can suggest an actual repair.
Why first: Krenn strips retrieval back to the machinery beneath the current RAG vocabulary: analysis, inverted indexes, BM25, dense vectors and ranking. The point is not to crown one method, but to understand the signals each can recover. Liu then shows how those signals appear in a modern AI search system.
Why second: Krenn supplies the foundations; Liu assembles them into an application stack with semantic search, metadata filters, query decomposition and multimodal inputs. His overview makes the menu visible. Karam follows with the harder rule for choosing from it: add a technique only when a failing query earns it.
Why here: Liu describes the available layers. Karam orders them by evidence, starting with the simplest system and reading its losses before adding BM25, embeddings, rerankers, domain signals or query fan-out. Fernandes then turns that method into a close-up of one naive RAG stack failing and being repaired.
Why here: Karam gives a decision process; Fernandes shows the debugging experience it produces. Changing embedding models does not fix bad context, while a cross-encoder reranker finally moves the right passage into place. Belfer follows with a failure a reranker cannot repair: the chunk size chosen at indexing time can hide the answer.
Why here: Fernandes moves the right passage to the top with a reranker. Belfer shows that no fixed chunk size suits every question: a narrow Seinfeld question is found with 100-token chunks, while a question spread across a scene fails with them. Indexing several sizes and merging the rankings with reciprocal rank fusion improved recall by roughly 20 to 40 percent, at two to five times the memory. Ma then widens these local repairs into the economic and architectural choices of an enterprise retrieval stack.
Why here: Belfer improves one index by measuring recall question by question. Ma asks why an enterprise should retrieve at all, then covers access control, vector compression, hybrid search and multimodal documents. His warning that performance varies sharply by corpus sets up Julien's case, where dense repetitive documents make vectors unreliable.
Why here: Ma presents graph retrieval as one tool among several. Julien gives the failure that justifies it: enterprise documents reuse the same language while the answer depends on relationships spread across pages. Belfer and Granot then push the same challenge further, asking when retrieval should give way to a structured query.
Why here: Julien preserves relationships with graph-derived retrieval. Belfer and Granot show a different boundary: top-k chunks are a poor tool for counts, maxima and corpus-wide comparisons. Their text-to-SQL alternative makes the representation match the question. Bergum follows by returning to unstructured text, where an agent's own queries make plain BM25 more useful than it looks.
Why here: Belfer and Granot change the representation to fit the question. Bergum keeps the oldest retrieval function and points at its new user: a language model knows names, dates and identifiers, writes long exact queries and reformulates them after reading results. On BrowseComp, accuracy is high when the evidence is placed in context and falls when the model must find it, so retrieval stays the limit. Lichtenberg follows with the other side of that query habit: keyword-style queries make poor semantic searches.
Why here: Bergum shows an agent writing strong keyword queries for BM25. Lichtenberg shows the same habit hurting semantic search, then lets an agent choose among overview search, semantic search, metadata filters and grep, and trains it to describe evidence needs instead of guessing keywords. Levi follows with a prior condition this work assumes: the agent must reach the source at all.
Why here: Lichtenberg improves how an agent searches a corpus. Levi shows why a well-formed query can still produce fiction on the public web: the request hits a CAPTCHA, an empty page or stale training data, and the agent answers anyway. Neagu, Emery and Sher close the pack by making access, evidence and answer quality measurable.
Why last: Levi exposes the invisible failure of web retrieval. Neagu, Emery and Sher build the operating discipline around it: dynamic test sets for changing facts, separate measures for completeness, document relevance and hallucination, and results that point toward a repair. It ends the pack where production search must end, with evidence strong enough to change the system.