Did people actually stop using RAG?

Not really. What they stopped using is naive single-vector RAG, a lone embedding index with top-k search. The file and folder approach they switched to is still retrieval, the agent just finds knowledge by navigating directories instead of querying vectors. Retrieval did not go away. The retrieval method changed, and both methods have blind spots.

Is an Open Knowledge Format better than RAG?

Neither is strictly better. A file and folder format wins on transparency: your knowledge stays readable, versionable, and portable. It loses at scale, where crawling directories is slow and misses knowledge no file name hints at. A single vector index has the opposite tradeoff. The strongest setup keeps files you own and retrieves across several methods, which is what stacked retrieval does.

What is actually wrong with single-vector RAG?

One vector has to summarize a whole chunk, so distinct ideas blur. Nearest-neighbor search returns what is close in embedding space, not always what answers the question, so an important keyword can be outranked by a passage that merely feels similar. There is no source authority, freshness, or exact match, and when it returns the wrong chunk the index cannot tell you why.

How does RDK keep the benefits of both approaches?

RDK keeps your knowledge as files in a local vault, so you retain the transparency the file-based camp wants. It indexes those files as encrypted private chunks and uses stacked retrieval: a private layer answers 40 to 65 percent of queries, a public network adds 15 to 20 percent, and the LLM is the last resort. You get file ownership plus retrieval precision, cutting token spend 80 to 90 percent.

Open Knowledge Format vs RAG: What "We Stopped Using RAG" Really Means

The "we stopped using RAG" argument rejects naive single-vector RAG, not retrieval itself. An Open Knowledge Format stores knowledge as plain files and folders an agent reads directly, which is still retrieval, just by navigation instead of embeddings. The real upgrade is stacked retrieval: keep the retrieval win, drop the brittle single index.

What "we stopped using RAG" actually claims

A wave of builders now say they have stopped using RAG. The argument, popularized by videos pairing an Open Knowledge Format with agents like Claude, runs like this: instead of chunking your documents and loading embeddings into a vector database, keep your knowledge as plain files and folders and let the agent read them directly. No pipeline, no index to maintain, no retrieval step that returns the wrong chunk. The model walks the folder tree the way a developer opens files in a repository.

It is a real reaction to real pain. Anyone who has shipped a vector-database RAG system knows the failure modes: a query returns three chunks that look relevant and miss the one that mattered, an embedding model that cannot separate two similar passages, a reindex job that silently breaks. When the alternative is "the agent just reads the files," the simplicity is genuinely attractive.

But the claim hides a category error. Reading files from a folder is retrieval. The agent still has to find the right file before it can answer. What changed is the retrieval method, not whether retrieval happens. So the honest version of the argument is narrower and more useful: naive single-vector RAG is often the wrong tool, not retrieval as a whole.

What an Open Knowledge Format actually is

An Open Knowledge Format, in the sense this debate uses it, is knowledge stored as human-readable files in a structured folder tree. Markdown notes, docs, and code, organized by directory, with names and paths that carry meaning. There is no separate embedding store. The knowledge is the files, and the folder structure is the index.

An agent uses it the way a coding agent uses a repository. It lists directories, reads file names, opens the ones that look relevant, and follows references between them. Retrieval here is navigation: grep, glob, directory listing, and the model's own judgment about which path to open next. Because the files are plain text a human can read and edit, the format is transparent and portable in a way a vector index is not. You can diff it, version it in git, and move it between tools without an export step.

That transparency is the format's real strength. Your knowledge stays in a form you own and can inspect, instead of dissolving into a matrix of floating-point numbers you cannot read. The disagreement is not about whether files are a good way to store knowledge. They are. It is about how an agent should find the right knowledge once you have a lot of it.

The critique targets naive single-vector RAG, not retrieval

Strip the rhetoric and the target is specific: a single embedding index, one vector per chunk, top-k nearest-neighbor search, and nothing else. That is naive single-vector RAG, and it does deserve the criticism.

Its weaknesses are structural. One vector has to summarize a whole chunk, so distinct ideas in the same passage blur together. Nearest-neighbor search returns what is close in embedding space, which is not always what answers the question, so a keyword the user clearly cares about can be outranked by a passage that merely feels similar. There is no notion of source authority, freshness, or exact match. And the index is opaque, so when it returns the wrong chunk you cannot see why.

None of that is an indictment of retrieval. It is an indictment of using one blunt retrieval method for every query. The fix is not to delete the index and read files by hand. The fix is to retrieve better: combine methods, rank across sources, and fall back deliberately. The "we stopped using RAG" crowd rediscovered this by accident. They did not stop retrieving. They replaced a bad single retriever with folder navigation, which is just a different retriever with its own blind spots.

Where file and folder knowledge breaks at scale

Folder navigation works beautifully up to a point, then quietly falls apart. In a small vault the agent can list a directory and read the three files that matter. At ten thousand files across hundreds of folders, listing and opening is no longer cheap. The agent burns tokens crawling the tree, reads whole files to find one paragraph, and still misses knowledge whose file name does not hint at its contents.

File names and paths are a coarse index. They capture how you happened to organize things, not every question someone might ask. Knowledge that lives in the middle of a long document, or that spans several files, is exactly what navigation is worst at finding, because no path points straight to it. This is the same recall problem naive RAG has, arriving from the other direction.

There is also a cost asymmetry. Reading a file into the prompt so the model can decide whether it is relevant means paying for the whole file, every time, on every query. Embedding-based retrieval at least loads only the passages that matched. Pure navigation trades the vector index's precision problem for a token and latency problem that grows with your knowledge base.

Stacked retrieval: keep the retrieval win, drop the naive index

The resolution is not RAG or files. It is better retrieval over files you still own. RDK takes that position directly. Your knowledge stays as files in a local vault, Obsidian, docs, a codebase, so you keep the transparency and portability the Open Knowledge Format is right to want. RDK then indexes those files as encrypted private chunks and retrieves across several methods instead of one.

This is stacked retrieval. A private layer of your own encrypted chunks answers first and handles 40 to 65 percent of queries. A public network of chunks other builders have published answers next and adds another 15 to 20 percent. The LLM is the fallback for the remaining 5 to 10 percent, the genuinely novel questions no stored knowledge covers. Each layer catches what the previous one missed, so you are not betting every query on a single nearest-neighbor lookup or a single folder path.

That is the evolved version of the argument. The "stop using RAG" instinct is right that a lone vector index is fragile and that knowledge should live in files you control. It is wrong that the answer is to abandon retrieval and let the model crawl a folder tree. Keep the retrieval win, because recall is far cheaper and more accurate than regeneration or brute-force file reading. Just stop relying on one retriever. Stack them, rank across them, and fall back to the LLM last. That is how you get the simplicity the file-based camp wants and the precision and cost control naive RAG never delivered.

Frequently asked questions

Did people actually stop using RAG?: Not really. What they stopped using is naive single-vector RAG, a lone embedding index with top-k search. The file and folder approach they switched to is still retrieval, the agent just finds knowledge by navigating directories instead of querying vectors. Retrieval did not go away. The retrieval method changed, and both methods have blind spots.
Is an Open Knowledge Format better than RAG?: Neither is strictly better. A file and folder format wins on transparency: your knowledge stays readable, versionable, and portable. It loses at scale, where crawling directories is slow and misses knowledge no file name hints at. A single vector index has the opposite tradeoff. The strongest setup keeps files you own and retrieves across several methods, which is what stacked retrieval does.
What is actually wrong with single-vector RAG?: One vector has to summarize a whole chunk, so distinct ideas blur. Nearest-neighbor search returns what is close in embedding space, not always what answers the question, so an important keyword can be outranked by a passage that merely feels similar. There is no source authority, freshness, or exact match, and when it returns the wrong chunk the index cannot tell you why.
How does RDK keep the benefits of both approaches?: RDK keeps your knowledge as files in a local vault, so you retain the transparency the file-based camp wants. It indexes those files as encrypted private chunks and uses stacked retrieval: a private layer answers 40 to 65 percent of queries, a public network adds 15 to 20 percent, and the LLM is the last resort. You get file ownership plus retrieval precision, cutting token spend 80 to 90 percent.

Key takeaways

"We stopped using RAG" is a critique of naive single-vector RAG, not of retrieval. Reading files from a folder is still retrieval, just done by navigation instead of embeddings.
An Open Knowledge Format stores knowledge as plain files and folders an agent reads directly. Its real strength is transparency and portability, not the retrieval method itself.
Naive single-vector RAG earns its criticism: one vector per chunk, top-k nearest-neighbor search, no source ranking, and an opaque index that fails silently.
Folder navigation breaks at scale. At thousands of files the agent crawls the tree, reads whole files to find one paragraph, and pays for every file on every query.
Stacked retrieval keeps the retrieval win without the naive index. RDK indexes your own files as encrypted private chunks, then layers private, public, and LLM fallback so recall does the work.