Ask how to give a model knowledge and you will get half a dozen answers in one breath: vector RAG, RAGFlow, GraphRAG, PageIndex, an LLM wiki, Obsidian. People toss them into the same bucket, as though you were choosing between competing products. You are not, because they do not even sit at the same layer, and sorting that out is most of the work.
So start with the layers. Vector RAG is a method. RAGFlow is a product that implements that method. GraphRAG is the same method with a knowledge graph added on top. PageIndex is a different method that skips vectors entirely. LLM wiki is another method again. Obsidian is a format, plus a viewer.
The real rivalry is between two philosophies. Either you chop the documents up and reassemble an answer on every question, or you have a model digest them once into pages a human can read. Everything else is an instance of one of those two, or the substrate underneath.
Vector RAG: the warehouse
Slice documents into chunks, turn each chunk into a coordinate in meaning-space, and at query time grab the chunks nearest to your question. This is the workhorse, and it is genuinely good at one shape of problem: a large pile of documents, with users asking pointed questions. “What’s our refund window?” “Which clause covers termination?” Support desks, internal document search, and compliance lookup are its home.
What vector RAG cannot do is accumulate. Every query starts from scratch, and nothing it learns sticks. A request to “summarize the themes across everything” defeats it, because that answer was never sitting in any single chunk.
RAGFlow: the warehouse, industrial grade
RAGFlow is vector RAG, with two additions that matter in the real world. It has a very strong document parser that handles filthy PDFs, scanned tables, and OCR output. And it produces citations that point back to the source line. If your documents are messy and your domain is audited — banking, insurance, contracts — that combination is the entire attraction. The cost is weight. RAGFlow is overkill for a personal project, and it inherits the amnesia of ordinary RAG.
GraphRAG: the warehouse with a map of who’s who
GraphRAG is vector RAG with a preparation step. Before answering anything, a model reads the whole corpus, extracts the entities and their relationships into a graph, and writes a summary of each cluster. This lets it answer questions that a bag of chunks never could: “what do all these contracts have in common,” “how are these two people connected,” “what are the themes across everything.” Microsoft open-sourced it, and it is the standard choice for connect-the-dots and whole-corpus questions.
The price is steep. Building the graph consumes a large number of LLM calls, and every update threatens to ripple through it. Reach for GraphRAG when the answer lives in the relationships rather than in any single passage, and never for simple lookups, where it is pure overhead.
PageIndex: read it like a book, with no vectors at all
PageIndex is the odd one out: no embeddings and no vector store. It builds a table of contents for a long document, as a tree, and lets the model navigate that tree the way you would flip through a book’s index, reasoning its way down to the right chapter before it reads a word of the actual text.
It works well on a single, very long, well-structured document such as a 300-page annual report, a textbook, or a regulation, where vector chunks lose the thread and where you want to see why the answer came from section 4.2. It is weak when there is no structure to navigate, and when you need millisecond answers at scale, because reasoning down a tree is slower than a vector lookup.
LLM wiki: the notebook
Instead of re-deriving answers, a model digests your sources once into deduplicated, cross-linked pages, and keeps tidying those pages. Knowledge compounds instead of resetting. This is the approach Karpathy persuaded everyone to try in 2026, and it fits a specific shape: knowledge you want to keep and revisit, such as a personal second brain, a research base, a team’s living documentation, or a codebase explained as a navigable wiki. It is also the pattern I think has already won.
Its weakness is the other side of its strength. The digest layer can be wrong, and it goes stale when the sources change frequently. An LLM wiki is excellent for low-stakes accumulation and risky anywhere every claim has to be airtight.
Obsidian: the paper
Obsidian is not an engine at all. It is a folder of Markdown files with [[links]], stored locally and owned by you, with AI added as a plugin. Its real contribution is the format: plain text in git that any tool, or any model, can read, with no lock-in. That is exactly why it keeps appearing as the place an LLM wiki lives. The model writes the pages, and you browse them in Obsidian.
What each one is actually for
RAG finds answers. An LLM wiki turns answers into an asset. Obsidian makes the asset something you can keep and carry.
| The job | Reach for |
|---|---|
| Messy enterprise docs, pointed questions, audit trail | Vector RAG / RAGFlow |
| Connect-the-dots or whole-corpus questions | GraphRAG |
| One very long, structured document, read precisely | PageIndex (no vectors) |
| A second brain, research, knowledge that should compound | LLM wiki + Obsidian |
| Understanding a codebase or a dependency | LLM wiki (DeepWiki-style) |
| Just storing knowledge without lock-in | Obsidian (Markdown + git) |
| High-stakes, every claim must be airtight | Vector RAG (strong citations); be wary of a wiki |
The mistake is picking by novelty. Pick by the shape of the job instead. A pile of messy documents with pointed questions wants the warehouse. Relationships across the whole corpus want the graph. One long document read precisely wants the tree. Knowledge you want to compound and read wants the notebook. And whichever one you choose, plain text in git is the format you will not regret.