Three years ago "RAG" meant one thing: chunk your documents, embed the chunks, retrieve the similar ones, and let the model answer from them. In 2026 the word covers at least five meaningfully different architectures, and procurement conversations that treat them as one product keep ending in the same place — a system that demos beautifully on the handbook and fails quietly on the questions the business actually asks.
The distinction that matters is not which embedding model. It is what kind of thing your questions are.
Five patterns, briefly
Naive RAG is the original shape: documents become vectors, similarity finds the candidates. It is fast to stand up and genuinely good at questions whose answer lives inside one document. Its failure mode is structural: the copy drifts from the source, and relationships between records — the thing enterprise answers are made of — do not survive chunking.
Advanced RAG keeps the shape and sharpens the parts: re-ranking, query rewriting, hypothetical-answer retrieval. It recovers a lot of recall on messy corpora. It remains a copy of the documents, ageing from the day it was built.
Modular RAG treats retrieve, re-rank and generate as separate, measurable stages. This is less a technique than a discipline — each stage can be evaluated and swapped independently — and it is the minimum seriousness for a system you intend to operate rather than demo.
Graph RAG retrieves structure instead of passages: entities, and the relationships between them, so a question that spans a customer, their contracts and their payment history is answered from the joins, not from three nearby paragraphs. Where it fits, nothing else comes close. Where it does not — and there are honest analyses arguing it is over-applied — it is an expensive way to answer questions a table would have handled.
Agentic RAG lets an agent plan retrieval as a sequence of calls: decompose the question, fetch, notice what is missing, fetch again. It handles the hardest, least-specified questions, at compound cost and latency — which is why it belongs behind a budget, on the question classes that justify it.
The technical detail
Two engineering truths sit underneath the taxonomy.
The first: evaluation has to be per-pattern and per-question-class, on your questions. "Which RAG is best" is a leaderboard question. "Which retrieval architecture answers our reconciliation questions defensibly, at what cost per answer" is an engineering question, and it has a different answer for the policy library than for the ledger.
The second: the corpus problem and the engine problem look identical from outside. When answers are poor, either retrieval and generation are weak, or the answer simply is not in the material. These need opposite fixes, and teams routinely rebuild the engine when the corpus was the problem. Before changing any architecture, separate the two with a labelled question bank — fifty questions whose answers you know, annotated with where the answer lives. It is a week's work and it has saved our clients entire rebuilds.
Where we land
Most enterprise questions worth asking span more than one record. "Which suppliers are exposed to both sanctions risk and a contract renewal this quarter" is not a passage-retrieval question; it is a question about relationships over live records, with entitlement applied to the asker.
That is why our platform resolves questions against an ontology over records rather than a vector copy of documents — retrieval as query, not as search. We hold it as a position tested on every engagement, and we read what argues against it — the failure analyses of graph approaches included. But the direction of travel in the field — from passages toward structure, and from structure toward agents that plan — is the direction we started from.
Choose the pattern by the question, not the brochure.