RAG Decisions: Choosing Between the Options
The comparisons that come up before you build anything, each answered with the condition that decides it.
RAG decisions are the comparisons that come up before you build — RAG versus fine-tuning, long context, prompt engineering, memory, tools, graphs, and the stack you run on. Each comparison has a condition that decides it. Match your gap to the condition, then open the page that owns the verdict.
When should you use RAG?
Use RAG when the gap is knowledge the model does not already have in its weights — especially knowledge that changes, that must be cited back to a source, or that must stay inside your environment rather than enter a training run. HackerNoon’s production guide (captured July 2026) states the same applicability rule: RAG is the default when knowledge updates frequently, answers must be auditable, sensitive data cannot leave your store, or agents need grounded current context before they act.
The inverse cases are real, and they are where teams waste months building retrieval they did not need. Applied AI’s enterprise architecture brief (November 2025) lists the main ones: a small corpus that still fits the model’s context window at low query volume; narrow knowledge that barely changes (fine-tuning may win); exact lookups better served by SQL or classical search; live prices or system status better served by APIs and tools; highly structured query patterns better served by parameterized queries. The full anti-cases live on when you should not use RAG; the long-context size and cost comparison lives on RAG vs long context.
If the gap is behaviour — a fixed format, tone, or skill — rather than knowledge, the deciding page is RAG vs fine-tuning, not this hub’s applicability section. Named patterns (naive through agentic) belong on RAG architectures; stage mechanics on the pipeline (including build and cost); symptom diagnosis on why RAG systems fail; measurement on how to evaluate a RAG system.
Which RAG decision are you making?
Match the question you are actually asking to a comparison below. Each card names the condition that decides it; the leaf page carries the verdict, the table and the edge cases. This hub only routes.
Applicability — should you use RAG at all?
Technique — RAG vs another way to give the model knowledge
Stack — what you build RAG on
Don’t know which comparison first?
Start with applicability. If retrieval does not belong, every pairwise fight is premature. If it does, the most common next question is knowledge versus behaviour — RAG vs fine-tuning →
When should I use RAG?
When the gap is knowledge the model does not have in its weights — especially knowledge that changes, that must be cited to a source, or that must stay in your environment. If the gap is a fixed behaviour (format, tone, skill), start with fine-tuning instead. If the corpus is tiny, static, or an exact lookup, RAG may add cost without accuracy — see when you should not use RAG.
Should I use RAG or fine-tuning?
They solve different problems. A knowledge gap — facts, documents, data that changes — points to RAG. A behaviour gap — output format, tone, or a skill the model should always apply — points to fine-tuning. Production systems often need both: fine-tune for consistent behaviour, retrieve for current facts. The deciding question and scored factor table live on the RAG vs fine-tuning page.
Is RAG still relevant with long context windows?
Yes for corpora that grow, change, or must stay cheaper than stuffing the full window on every query. Long context can replace retrieval when the whole knowledge base still fits and query volume stays low; at larger size or higher volume, retrieval usually wins on cost and focus. The size-by-size comparison is on RAG vs long context.
What are the alternatives to RAG?
Long context, fine-tuning, prompt engineering, semantic caching, tool or MCP access, knowledge graphs, and structured queries (SQL or classical search). Each replaces a different part of what RAG does and fails at a different boundary. The alternatives page maps what each option substitutes and what it cannot.