Putting the three core architectures side by side

Lessons 1 through 8 built up, one piece at a time, from why RAG exists to the three architectures generally described as "core": naive, advanced, and modular. Before this course moves on to specialized retrieval strategies, it is worth holding all three in view at once.

Naive RAGAdvanced RAGModular RAG
StructureOne fixed chainOne fixed chain, tuned at both endsIndependent, swappable modules
Query handlingUsed as-isRewritten or expanded (HyDE)Routed to the right module first
ChunkingFixed-sizeStructure-awareChosen per module/source
Result quality controlNoneRe-ranking, compressionDelegated to whichever module handled it
Best fitClean, narrow, well-scoped dataNoisy or loosely-structured documentsMultiple data sources or question types in one system

Why this ordering matters

Each architecture in this row is a superset in ambition, not a replacement: advanced RAG is naive RAG with two extra optimization stages, and modular RAG is advanced RAG's toolkit reorganized so it can be assembled differently per question. None of the three, though, has an answer for questions that genuinely require connecting facts across documents or that need more than one retrieval pass to answer, which is exactly where Lesson 10 picks up.

Try this yourself

  • Pick a real system you use or have built (a support chatbot, a documentation search, an internal wiki assistant) and classify it: is it naive, advanced, or modular RAG, based on what you can observe or infer about its behavior?
  • For that same system, name one failure mode from Lesson 5 you would expect it to hit, and which of the three architectures' techniques (query rewriting, re-ranking, routing) would most directly address it.
  • Write, in one sentence, the rule you would use to decide between naive and advanced RAG for a brand-new project with clean, single-source data.

If you can answer these confidently, you're ready for the Intermediate tier, starting at Lesson 10.