Choosing a RAG Architecture: A Decision Framework

From nine names to one decision procedure

This course has covered nine named architectures. In a real project, the useful skill is not reciting all nine, it is a short sequence of questions that narrows down to the one, or two, actually worth building. This lesson lays out that sequence.

The questions, in order

1. Is the knowledge base clean, narrow, and self-contained? If yes, start with naive RAG (Lesson 4) and only add complexity once a real failure appears. Most systems should start here, not with the most sophisticated architecture available.

2. Are retrieval results noisy, or is the raw data messy or unstructured? Add advanced RAG's pre- and post-retrieval optimizations (Lessons 6 to 7): query rewriting, better chunking, re-ranking.

3. Does the knowledge base contain exact terms, codes, or names that must be matched precisely? Add hybrid RAG (Lesson 11).

4. Do real questions require connecting facts across multiple entities or documents? Add graph RAG (Lesson 12), or, if a knowledge graph is too costly to build and maintain for your case, consider agentic RAG's multi-step retrieval (Lesson 17 to 18) as an alternative path to the same multi-hop capability.

5. Does retrieval quality need an explicit trust check before generation? Add corrective RAG's grading step (Lesson 14), especially where a wrong, confidently-stated answer carries real cost.

6. Does the knowledge base include images, audio, or video that text-only retrieval cannot reach? Add multimodal RAG (Lesson 19).

7. Does question complexity vary a lot, such that a single fixed architecture is either overkill for simple questions or insufficient for hard ones? Wrap the whole system in adaptive routing (Lesson 20), and modular routing (Lesson 8) if multiple data sources are involved too.

The habit this builds

Notice that this sequence starts from the simplest architecture and adds capability only in response to a specific, named gap, the same failure-diagnosis habit built in Lesson 16, applied prospectively instead of retrospectively. Reaching for agentic or graph RAG by default, before naive RAG has even been tried, is the single most common way real projects overbuild.