Why Specialize Retrieval Beyond Modular RAG

Modular RAG solves routing, not retrieval quality itself

Modular RAG (Lesson 8) solves the problem of sending different questions to different retrieval strategies. It does not, by itself, make any single strategy better at the specific kind of question it was routed to handle. A router can correctly identify that a question needs keyword precision, connected-entity reasoning, or a self-check on the retrieved evidence, but it still needs a retrieval strategy purpose-built for each of those, which is what the rest of this tier covers.

Three specific gaps that motivate this tier

Semantic (embedding) search is excellent at "what is this about," and comparatively weak at exact terms: a product SKU, an error code, a person's name, an acronym. A pure vector search can rank a chunk containing the exact SKU a user typed lower than a chunk that is merely topically similar, because embeddings compress exact tokens into fuzzy meaning. This gap motivates hybrid RAG (Lesson 11), which restores keyword precision alongside semantic recall.

Vector search also has no native concept of a relationship. It can find chunks about "Company A" and, separately, chunks about "Company B," but it cannot natively answer "which companies did the same person found," because that requires traversing an explicit connection between two entities, not measuring how semantically similar two pieces of text are. This gap motivates graph RAG (Lesson 12).

Finally, every architecture covered so far trusts whatever the retrieval step returns. None of them ask "was that actually good evidence?" before generating an answer from it. This gap motivates corrective RAG (Lesson 14), which adds an explicit grading step before generation.