RAG Classifications, Architectures: A Field Guide for Produc | Coderz Club

RAG Classifications, Architectures: A Field Guide for Production-Grade Systems

If you've shipped a "chat with your docs" prototype in a weekend, congratulations — you've built Naive RAG. If you've then watched it hallucinate on multi-hop questions, choke on tables, and confidently cite the wrong PDF in production... also congratulations. You've discovered why "RAG" is not a single architecture. It's a design space. This article is the map I wish I had before I rebuilt the same pipeline four times. TL;DR Naive RAG (retrieve → stuff context → generate) breaks down fast: bad chunking, semantic drift, no query understanding, no self-correction. Advanced RAG fixes retrieval quality with pre/post-retrieval optimizations (query rewriting, HyDE, re-ranking). Modular RAG treats retrieval as a composable, routable pipeline — not a fixed chain. There are 8 architectural patterns worth knowing: Standard, Hybrid, GraphRAG, CRAG, Self-RAG, Adaptive RAG, Agentic RAG, and Multi-Modal RAG. Pick based on your failure mode, not hype. A decision matrix is included at the bottom. Let's get into it. Why Vanilla RAG Falls Over in Production The "hello world" RAG loop looks like this: User Query → Embed → Vector Search (top-k) → Stuff into Prompt → LLM → Answer It works great in a demo with 20 PDFs. Then someone asks a real question and things fall apart: Failure Mode What Actually Happens Chunking artifacts A table gets split mid-row; the answer is technically "retrieved" but semantically garbage Semantic drift The query embedding is close to lexically similar chunks, not answer-relevant ones Multi-hop failure "Compare Q3 revenue to Q2 and explain the delta" needs two retrievals and a reasoning step — vanilla RAG does one retrieval, once No relevance filtering Top-k always returns k chunks, even if none of them are actually relevant No verification The LLM generates fluently even when the retrieved context doesn't support the claim — silent hallucination Static k A simple FAQ question and a complex synthesis question get the same fixed number of retrieved chunks None of this means "RAG is broken." It means naive RAG is the MVP, not the destination. Everything below is what production teams reach for next. The 3 Paradigms of RAG Before the architecture zoo, it helps to zoom out. Most RAG systems fall into one of three evolutionary stages. 1. Naive RAG — Retrieve → Read → Generate ┌─────────┐ ┌──────────┐ ┌────────────┐ ┌──────────┐ │ Query │ --> │ Embed │ --> │ Vector DB │ --> │ LLM │ --> Answer └─────────┘ └──────────┘ │ (top-k) │ └──────────┘ └────────────┘ Single embed → single retrieve → single generate. No feedback loops, no query understanding, no correction. This is your baseline, not your product. 2. Advanced RAG — Optimize Before and After Retrieval Advanced RAG keeps the linear shape but adds two optimization stages: Pre-retrieval: improve the query before it hits the index. Query rewriting / expansion HyDE (Hypothetical Document Embeddings) — generate a fake "ideal answer," embed that, and search with it instead of the raw question Query decomposition for multi-part questions Post-retrieval: improve the context before it hits the LLM. Re-ranking (cross-encoders, e.g. Cohere Rerank, BGE-reranker) Contextual compression / filtering Redundancy removal (MMR — Maximal Marginal Relevance) Query --> [Rewrite / HyDE] --> Retrieve --> [Re-rank / Filter] --> LLM --> Answer This is the single highest-ROI upgrade most teams should make before reaching for anything fancier. 3. Modular RAG — Composable, Routable, Non-Linear Modular RAG stops treating the pipeline as a fixed chain and starts treating it as a graph of interchangeable modules: retrieval, routing, memory, fusion, task adapters — wired together however the problem demands, including loops. ┌─────────────┐ │ Router │ └──────┬───────┘ ┌──────────────┼──────────────┐ v v v ┌───────────┐ ┌───────────┐ ┌───────────┐ │ Vector DB │ │ Graph DB │ │ Web/API │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ └──────────────┼──────────────┘ v ┌───────────────┐ │ Fusion/Rerank │ └───────┬───────┘ v ┌───────────────┐ │ Memory Store │◄──┐ (feedback loop) └───────┬───────┘ │ v │ ┌───────────────┐ │ │ LLM │───┘ └───────────────┘ Every pattern in the next section is really a specific configuration of Modular RAG's building blocks. 8 Modern RAG Architectural Patterns 1. Standard (Dense) RAG The classic. Pure dense vector similarity search — embeddings in, cosine/dot-product similarity out. [Query] --embed--> [Query Vector] │ v ┌──────────────────┐ │ Vector Index │ │ (HNSW / IVF) │ └─────────┬─────────┘ v top-k chunks v [LLM] --> Answer Use when: semantically rich, unstructured text corpora (docs, wikis, support articles) where exact keyword matches don't matter much. Pros: simple, fast to stand up, well-supported tooling (pgvector, Pinecone, Qdrant, Weaviate). Cons: blind to exact-match needs (SKUs, error codes, acronyms); no relevance guarantee; single-shot. 2. Hybrid RAG Dense search alone fail