QR-03

RAG Architecture Decision Tree

Match the retrieval pattern to the question. Read down until you hit YES.
Last verified 2026-07-09

Core Principles

Ground before you generateThe LLM only knows what you fetch. Retrieve first, write second
Retrieval is where RAG breaks73% of failures are retrieval, not generation. Fix that first
The chunk is your unit of truthIf the fact spans two chunks, no model can save you
Rerank before you scaleCheapest quality win there is. Ships in an afternoon
Measure it, or it degradesRetrieval quality decays silently. Evals catch it early

Know The Limits read this first

RAG fixesMissing facts, freshness, private knowledge, source citations
RAG cannot fixBad reasoning, tone, or task behaviour. That is prompting or fine-tuning
RAG is not a silver bulletBad chunks in, bad answers out. No amount of prompting recovers it

The Pipeline know what breaks where

StepWhat it doesWhere it breaks
ChunkSplit docs into passagesToo big misses the point; too small loses context. Splits mid-sentence lose meaning
EmbedTurn chunks into vectorsWrong embedding model gives you wrong meaning. Domain mismatch hurts
IndexStore vectors for fast similarity searchNo metadata means no filtering, no citations, no debugging
RetrieveFetch top-k similar chunksSimilarity is not relevance. Vocabulary mismatch (query vs docs) kills recall
RerankRe-score the top 50 by true relevance, keep top 5Skipping this is the single most common miss. Free 15 to 30% quality lift
GenerateModel writes the answer using the retrieved chunksIt will happily ignore chunks or invent past them, unless told not to

The Decision Tree pick your pattern in 30 seconds

▶ You have documents. You want the LLM to use them.
Q1Can a single document contain the whole answer?FAQs, manuals, contract lookups, single-report Q&A
YES ▶
Naive RAG+ reranker. Simplest thing that works
NO ▼   needs facts from multiple documents
Q2Do relationships between entities matter?customer → order → product · gene → drug → disease · person → company → filing
YES ▶
Graph RAGEnterprise knowledge, investigations, multi-hop entity questions
NO ▼   multi-doc, but no entity graph
Q3Does the question need multi-step reasoning or iterative retrieval?"compare", "why", "what changed", questions that fan out into sub-questions
YES ▶
Agentic RAGResearch, deep analysis. 3 to 10x more LLM calls per query
NO ▼
Q4Is your traffic mixed, easy and hard queries together?Enterprise chat, support systems, general Q&A
YES ▶
Adaptive RAGA classifier routes each query to the right pattern above
▼ Everything else
DEFAULT ▶
Hybrid + RerankThe right answer for most production apps. Start here, not with the exotic stuff
Before you go exotic, try Contextual Retrieval. Anthropic's technique prepends a short LLM-generated context line to each chunk before embedding, and cuts top-20 retrieval failures by 49%, or 67% with a reranker. One-time build cost per document, no architecture change. (Anthropic, Sept 2024)

Patterns At A Glance

PatternWhat it addsCostUse whenWatch out for
Naiveembed + top-k + generate$Demos, single-doc lookupFails around 40% in production. Skip it
Hybrid + rerankBM25 + dense (RRF), then cross-encoder rerank, plus query rewrite$$Most production apps. This is the defaultRerank latency. Cache aggressively
ContextualLLM-augmented chunk prefixes before embedding$$Sparse corpora, vocabulary mismatchOne-time cost per doc. Re-run on updates
GraphKnowledge graph layered over entities and relationships$$$Connect-the-dots questions across many docsBuild and maintenance overhead
AgenticReasoning loop controls retrieval; iterative, self-correcting$$$$Multi-step, high-stakes, non-negotiable accuracySlow and expensive on easy queries. Loop caps mandatory
AdaptiveQuery classifier routes to the right pattern above$$ - $$$$Mixed workloads. Best cost-quality trade at scaleThe router needs its own eval set
QR-03

RAG Architecture Decision Tree

The 2026 default recipe, chunking, evaluation, and when not to reach for RAG at all.
Last verified 2026-07-09

The 2026 Default Recipe start here, tune from here

StepDo thisWhy
ChunkRecursive, 512 tokens, 50-token overlapThe pragmatic baseline. Match to your query type, upgrade only if metrics justify
EnrichAdd source, date, page, section as metadataFiltering, citations, and debugging all need this. Later is too late
Embedtext-embedding-3-large or voyage-3-largeDomain-tuned beats generic on private corpora. Test both
StoreQdrant, Weaviate, or one you can operate (see QR-14)The best DB is the one your team can run at 3am
RetrieveHybrid: dense top-20 + BM25 top-20, fused with RRFDense catches meaning, BM25 catches exact terms. Together they beat either
RerankCross-encoder (Cohere Rerank 3, Voyage, or bge-reranker), keep top 515 to 30% quality lift on RAGAS. The cheapest big win in RAG
GenerateForce citations. Add the escape hatch (see QR-01)"If not in the context, say NOT FOUND." Kills most hallucinations
EvaluateRAGAS + a 100-question hand-labelled golden setIf you cannot measure it, you cannot ship it

Chunking Strategies

StrategyUse forThe trap
Fixed-sizeFast baseline, uniform textSplits mid-thought, loses context
RecursiveMost prose. Start hereConfig the separators for your docs
Document-awareManuals, code, structured docsOnly works if the doc has structure
SemanticLong articles, transcriptsSlow, uneven sizes
Contextual (Anthropic)Sparse vocabulary, weak keywordsLLM cost per chunk at build time
Late chunkingLong docs, boundary-sensitive factsNeeds a long-context embedding model

Query Transforms fix the question, not the model

TechniqueUse it when
RewritingChatty users, vague questions, follow-up turns
HyDESparse or technical queries. Generate a fake answer, embed that
DecompositionMulti-part questions with "and", "compare", multi-hop
Step-backDomain questions. Ask a broader question first, then narrow
Multi-queryFan out one query into 3 to 5, union the results

Best Practices

Do
Rerank. Every pipeline. Every time
Attach metadata (source, date, page) and cite it in the answer
Test on real user queries, not the clean ones
Log every retrieval with its query, for debugging
Version your index like code. A re-index is a deploy
Give the model permission to say "NOT FOUND"
Do not
Skip evaluation. RAG bugs hide until they embarrass you
Chunk by character count alone. Chunk by meaning
Trust embedding similarity as if it were relevance
Assume "more context is better". Long prompts dilute attention
Retrofit RAG onto a bad question. Rewrite the question first
Reach for agentic RAG when hybrid + rerank would do

Troubleshooting

ProblemFix
Retrieval missed the answerAdd hybrid search (BM25 + dense). Rewrite the query. Try HyDE for sparse terms
Right chunks, wrong answerForce citations. Add the escape hatch. Shorten the context to top 3
Model ignored the chunksMove retrieved passages after the question, not before. Explicitly instruct: cite only from these
Hallucinates despite retrievalEnforce per-claim citations. Drop any claim without a matching chunk
Lost in the middle (long context)Rerank harder, drop to top 3. Reorder chunks by relevance, most important first
Too slowCache embeddings and reranks. Reduce top-k. Batch reranker calls
Too expensiveRoute easy queries to a smaller model. Compress retrieved chunks. Cache repeat queries
Answers are staleAdd TTL to the index. Delta-reindex on doc changes. Scheduled re-embed
Fine on tests, fails on usersYour test set is not real. Build a golden set from actual user queries

Metrics That Matter RAGAS

FaithfulnessDid the answer stay grounded in the retrieved chunks?
Answer relevancyDid the answer actually address the question?
Context precisionWere the retrieved chunks relevant? (signal to noise)
Context recallDid retrieval get everything the answer needed?
Retrieval@kRecall@10 and MRR on your golden set. Watch these in CI

When To Skip RAG

Small, static referenceJust paste it into the system prompt. Cache the prefix
One-off analysis of one docLong-context model with the full doc. RAG is overkill
Behaviour or style problemsFine-tune, do not retrieve. See QR-06
Facts change every secondDirect API/tool call. RAG is stale by design