RESEARCH · RETRIEVAL

Three kinds
of RAG.

Retrieval-augmented generation connects a model to your data, so it answers from what is true for you and not just what it memorized. There is not one way to do it. There are at least three, they fail in different places, and picking the wrong one is how a promising demo dies in production.

RESEARCH NOTE · RETRIEVAL ARCHITECTURES · RAG / GRAPH RAG / AGENTIC RAG · 2026-07-03

THE SHAPE OF IT

Same goal, three architectures.

Every kind of RAG does the same job: fetch relevant context, put it in the prompt, and let the model answer grounded in it. The difference is how it decides what is relevant, and how many chances it gets to decide.

Q top-k LLM

CLASSIC RAG

Embed and fetch.

Turn the query into a vector, return the top matching chunks, answer. One retrieval, one shot.

Q LLM

GRAPH RAG

Follow the links.

Walk a knowledge graph, return a connected subgraph. Sees relationships a flat vector search misses.

Q agent retrieve ↻ check LLM

AGENTIC RAG

Retrieve, then decide.

An agent plans, retrieves, checks the result, and retrieves again until it has what the answer needs.

Three retrieval architectures, one goal

THE TRADEOFFS

When each one wins.

Retrieval architectures compared
Classic RAGGraph RAGAgentic RAG
Best forLookup, FAQ, single-fact answersRelationships, multi-hop questionsOpen-ended, multi-step research
How it retrievesEmbed the query, return top-k similar chunksTraverse a knowledge graph, return a subgraphPlan, retrieve, check, retrieve again
StrengthSimple, fast, cheapFollows connections vectors missAdapts when one retrieval is not enough
Fails whenThe answer spans many documentsThe graph is stale or badly builtLoops run long; cost and latency climb
Cost$$$ · graph build + storage$$$ · many model calls

HOW TO CHOOSE

Cheapest thing that works.

Start with classic RAG. Most real questions are lookups, and it answers them at a fraction of the cost of anything fancier. Adding architecture you do not need is not sophistication, it is latency and spend.

Reach for Graph RAG when the questions are about relationships: which contracts reference this clause, which customers touch this account, how these entities connect. Reach for Agentic RAG when a single retrieval genuinely cannot know what to fetch until it has read something first. Complexity is a cost you pay only when the question demands it.

HOW MILLIE MEASURES THIS

We do not benchmark RAG in the abstract. We take your questions and your corpus, run each architecture against the same task packet, and report accuracy against cost.

Often the finding is that classic RAG wins on the routine majority of questions and Agentic RAG earns its cost only on the hard minority. Knowing where that line sits, for your data, is the design. See what we measure.

Retrieve what's true for you.

See what we measure