Ask how to give a model knowledge and you’ll get half a dozen answers in one breath: vector RAG, RAGFlow, GraphRAG, PageIndex, an LLM wiki, Obsidian. They get tossed in the same bucket, as if you’re choosing between competing products. You aren’t — they don’t even sit at the same layer, and sorting that out is most of the battle.
So, the layers first. Vector RAG is a method. RAGFlow is a product that implements it; GraphRAG is that same method with a knowledge graph bolted on top. PageIndex is a different method that skips vectors entirely. LLM wiki is another method again. Obsidian is a format (and a viewer). The real rivalry is between two philosophies: chop the documents up and reassemble an answer on every question, or have a model digest them once into pages a human can read. Everything else is an instance of one of those, or the paper underneath.
Vector RAG — the warehouse
Slice documents into chunks, turn each into a coordinate in meaning-space, and at query time grab the chunks nearest your question. It’s the workhorse, and it’s genuinely good at one shape of problem: a large pile of documents and users asking pointed questions. “What’s our refund window?” “Which clause covers termination?” Support desks, internal doc search, compliance lookup — this is its home.
What it can’t do is accumulate. Every query starts from scratch; nothing it learns sticks. And “summarize the themes across everything” defeats it, because the answer was never sitting in any single chunk.
RAGFlow — the warehouse, industrial grade
RAGFlow is vector RAG, with two things bolted on that matter in the real world: a very strong document parser — it eats filthy PDFs, scanned tables, OCR — and 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 whole draw. The cost is weight: it’s overkill for a personal project, and it inherits RAG’s amnesia.
GraphRAG — the warehouse with a map of who’s who
Vector RAG with a twist: before answering anything, a model reads the whole corpus, pulls the entities and how they relate into a graph, and writes a summary of each cluster. Now it can answer the questions 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’s the standard reach for connect-the-dots and whole-corpus questions.
The price is steep: building the graph burns a lot of LLM calls, and every update threatens to ripple through it. Reach for it when the answer lives in the relationships, not in any single passage — and never for simple lookups, where it’s pure overhead.
PageIndex — read it like a book, no vectors at all
The odd one out: no embeddings, no vector store. PageIndex builds a table of contents for a long document — a tree — and lets the model navigate it the way you’d flip through a book’s index, reasoning its way down to the right chapter before it reads a word of the actual text.
It shines on a single, very long, well-structured document — a 300-page annual report, a textbook, a regulation — where vector chunks lose the thread and you want to see why the answer came from §4.2. It’s weak where there’s no structure to navigate, or when you need millisecond answers at scale: 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 them. Knowledge compounds instead of resetting. This is the one Karpathy talked everyone into in 2026, and it fits a specific shape: knowledge you want to keep and revisit — a personal second brain, a research base, a team’s living docs, a codebase explained as a navigable wiki. It’s also the pattern I think already won.
Its weakness is the flip side of its strength: the digest layer can be wrong, and it goes stale when the sources churn. Great for low-stakes accumulation; risky anywhere every claim has to be airtight.
Obsidian — the paper
Obsidian isn’t an engine at all. It’s a folder of Markdown files with [[links]], local and yours, with AI bolted on as a plugin. Its real contribution is the format: plain text in git that any tool — or any model — can read, with zero lock-in. That’s exactly why it keeps showing up as the place an LLM wiki lives: the model writes the pages, you browse them in Obsidian.
What each 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: a pile of messy documents and 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 you choose, plain text in git is the format you won’t regret.