Modular RAG: Composable, Plug-and-Play Pipelines

From a fixed chain to a set of modules

Naive and advanced RAG are both, structurally, one fixed chain: chunk, embed, retrieve, (optionally) rewrite and re-rank, generate. Modular RAG reframes the whole system as a set of independent, swappable modules, a routing module that decides which retrieval strategy a given question needs, a retrieval module (which could be a vector search, a keyword search, or a call to an external API), a re-ranking module, and a generation module, wired together in whatever order a given use case needs.

Why this matters more than it sounds

The practical payoff is routing: a real production system rarely faces one kind of question. "What's your refund policy" is answerable from a document store; "what's the account balance for customer 4471" is answerable only from a live database call; "summarize our Q3 performance versus Q2" might need no retrieval at all if both quarters' numbers are already in context. A modular router classifies the incoming question and sends it to the right module, or combination of modules, rather than forcing every question through the same document-search pipeline regardless of fit.

Modular RAG as the umbrella, not a rival

It is useful to think of modular RAG less as a ninth technique alongside the others in this course, and more as the architectural pattern that lets several of them coexist in one system. A production RAG deployment commonly is modular RAG on the outside, with a router directing traffic between a hybrid-search module (Lesson 11), a graph-query module (Lesson 12), and a plain vector-search module, chosen per question rather than committed to as a single global architecture.