Seven Levels of RAG and the Failure Each One Fixes

Chase AI has a video that lays out seven levels of memory and retrieval for Claude Code, running from built-in auto-memory up to agentic multimodal RAG. The easy way to read a list like that is as a ranking, where a higher number means a better system.

I read it another way. Each level exists because the one below it failed at something specific. If you have not hit that failure, the level is overhead. It also tells a solo builder where to stop.

The ladder with the failures attached

Chase AI describes the levels and the limits of each. The pairing in the third column is mine: I lined each level up against the limit of the one before it.

Level	What it is	The failure it fixes
1	Auto-memory the harness writes for you	The agent starts every session knowing nothing
2	One rules file loaded on every prompt	You had no say in what was remembered
3	The rules file becomes an index to several files	One file bloats and pollutes every prompt
4	A vault: raw sources, a compiled wiki, an index	Knowledge is stuck inside a single project
5	Naive RAG: chunk, embed, vector search	Too much text to navigate and read whole
6	Graph RAG	Chunks know nothing about how documents relate
7	Agentic, multimodal RAG	Sources are not all text, and one store cannot answer everything

Levels one to four are file management

Nothing below level five is retrieval in the usual sense. It is deciding which markdown files exist and which ones get loaded.

Each step is still a response to a failure. Auto-memory needs no setup, and Chase AI's complaint is that people stay there and never clear a session, so quality sinks as the window fills. A rules file gives control, with a strict rule attached: if something does not apply to nearly every prompt, it does not belong there. Level three turns that file into an index.

Level four is where he tells most people to stop. His phrase is "the 80% solution that is actually a 99% solution for most people." It is a vault with raw sources, articles the model compiles from them, and an index the agent reads first.

My own vault sits at this level. It holds roughly 600 research notes, and the retrieval index is generated from note frontmatter. There is no vector database. The agent reads the index, then opens the few notes it needs.

Level five, and the rung the list leaves out

Naive RAG splits documents into chunks, turns each chunk into a vector, and pulls the nearest chunks for a query. It fixes the scale problem and fails in well-documented ways.

Chase AI's verdict is to skip it, on the grounds that real-world accuracy is about 25 percent without rerankers. He gives no source for that figure, and I would not repeat it as fact. His description of the failure is more useful: chunk boundaries are arbitrary, and a retrieved chunk can depend on one that was not retrieved.

Paulo Dichone's production RAG course on freeCodeCamp is more precise. He names five failures: bad chunking, embedding mismatch, retrieval noise, context overflow, and hallucination. His embedding example is a user asking how to cancel an account when the docs say "account termination procedure." Vector search does not connect the two. He also claims that 90 percent of RAG systems fail in production, which is his framing and not a cited study.

This is where I think the seven-level list misleads. Between naive RAG and graph RAG there is a rung that IBM's video on the evolution of retrieval calls advanced RAG: keyword and vector search combined, a reranker, and query rewriting. Two of those pieces map directly onto Dichone's failures. Hybrid search is for embedding mismatch. Reranking is for retrieval noise. The retrieval funnel in Code with Lucian's walkthrough of a ten-million-document system sits on this rung: exact SQL filters cut the set to about 100,000, hybrid search cuts that to 100, and a heavier reranker picks five.

So skipping naive RAG is reasonable advice for someone choosing between a vault and a graph. As far as I can tell from these sources, it also skips past the rung where most production effort goes.

Levels six and seven

Graph RAG extracts entities and relationships at ingestion and stores them as a graph. The failure it fixes is narrow: questions about how documents relate when they never mention each other, at a size too large to load into context. The benchmark gains Chase AI shows come from the graph project's own repository. They are self-reported, so I hold them loosely.

Level seven adds ingestion of images, scanned PDFs, and video, plus an agent that decides per question whether to hit the graph, run SQL, or read a markdown file. IBM's video lists the price of handing retrieval to an agent as cost, latency, and reasoning errors. Chase AI adds the unglamorous part that decides real deployments: versioning, deduplication, access control, and keeping the index in sync with the source.

Where a solo builder stops

Climb when a failure shows up, and climb one rung.

The diagnostic I would use comes from Dichone. Before blaming the model, log exactly what was retrieved for a failing question and look at it.

I have not built a production RAG system, and my vault is still at level four. One signal I am watching for is the one Chase AI names for level six. The other is cost. He cites a 2025 study, without naming it, that found retrieval far cheaper than having a model read text directly, and he admits there is no clear document count where an index-first vault stops being the sensible choice. So level four can return the right answer while costing more tokens than it should.

Key Takeaways

Read the levels as fixes. Each one answers a specific failure in the level below, and without that failure it is overhead.
Levels one to four are file organization. For a solo builder with hundreds of notes, a vault with a generated index is a legitimate stopping point.
The seven-level list leaves out hybrid search and reranking, which is where the documented failures of naive RAG get fixed.
Several headline numbers here are unsourced or self-reported. The failure descriptions are more reliable than the percentages.

Sources

The open question I want to answer for my own vault: at what note count does reading an index stop being cheaper than building retrieval?