# RAG vs Markdown wiki > The same knowledge base built twice: a RAG index, and a Markdown LLM Wiki linked by hand. Neither method won outright. - Site: isnan lab (https://lab.falah-isnan.com/experiments/rag-vs-markdown-wiki) - Author: Falah Isnan (https://falah-isnan.com/) - Published: 2026-09-23 - Updated: 2026-09-23 - Stack: Obsidian / Markdown / Vector search - Access: Research note - Interim result: RAG leads on token efficiency and speed, and that lead widens as the knowledge base grows. The Markdown LLM Wiki leads on maintainability and predictability. For a low-to-mid knowledge base that you wrote yourself, the Markdown approach was the more effective of the two: the relationships are explicit, so what the model will read is something you can anticipate. ## The question Which method suits a knowledge base better: a RAG system, or the Markdown LLM Wiki idea used through Obsidian? Both methods end the same way: the model reads some text and answers. They disagree about who decides which text. RAG decides by similarity at query time. A Markdown wiki decides by the relationships someone wrote down in advance. So the comparison is not really about storage. It is about whether a knowledge base is better served by search it cannot see, or by links it can. ## How it ran 1. **Write the knowledge once.** The same notes, written by hand, in plain Markdown. Nothing is generated, so both paths start from identical material and any difference belongs to the method rather than the content. 2. **Path A — chunk it and embed it.** Split the notes into chunks, embed each one, and keep the vectors in an index. Retrieval is a similarity lookup: the question decides what comes back, and nothing has to be linked by hand. 3. **Path B — link it and index it.** Leave the files alone and write the relationships between them by hand, with index files at each level. Retrieval is a walk: read the index, follow the link, arrive at the note. 4. **Ask both the same questions.** Same questions, same model, both paths. What gets read back is the context that reached the model, how much of it there was, and how long it took to get there. ## The approaches ### RAG with vector search The notes are chunked, embedded, and stored as vectors. Each question retrieves its own nearest few chunks, so the model only ever sees the part of the knowledge base that looked relevant. - Context is assembled per question, not read whole. - Relevance is decided by similarity, not by an author. - Scales with the index rather than with the reading. - Chunking, embeddings, and semantic search are each their own thing to get right. ### Markdown LLM Wiki, through Obsidian Plain Markdown files with the relationships between them written by hand, reached through index files. The path to any note is something a person chose, so it can be read, checked, and corrected directly. - Every relationship is explicit and human-readable. - The route to an answer is predictable before you ask. - Editing the knowledge is editing a file — no re-indexing step. - Every index level has to be read before the note underneath it. ## What came out Four aspects, read qualitatively across the two builds. No benchmark figures are cleared for publication yet. - **Token efficiency** — Favours: RAG with vector search (clear). RAG gets more targeted context for the same budget. The wiki has to read a large Markdown index before it reaches the note that actually answers the question, and the index is spent context. - **Maintainability** — Favours: Markdown LLM Wiki, through Obsidian (clear). The files stay readable by a person, and hand-written relationships are easier to predict than a similarity score. Changing the knowledge means editing a file, not rebuilding an index. - **Speed** — Favours: RAG with vector search (clear). Vector search is faster on a large knowledge base. On the wiki the index files grow too large, and every index level has to be read first before anything useful comes back. - **Effectiveness for low-to-mid knowledge** — Favours: Markdown LLM Wiki, through Obsidian (clear). More predictable at that size, especially when the knowledge is self-written. RAG feels like overkill there, and semantic search plus vectors make it trickier for no gain you can point at. ## Trade-offs - Gain: Vector search keeps the context small and the lookup fast, and it keeps working as the knowledge base grows. Cost: Retrieval becomes a second system to get right. Chunking, embeddings, and semantic search each have their own failure modes, and none of them are visible in the answer. - Gain: Hand-written relationships make the route to an answer predictable, and a wrong route is something you can see and fix. Cost: Every index level has to be read before the note underneath it, and those index files grow with the knowledge until they are the expensive part. - Gain: Plain Markdown stays readable and editable by the person who wrote it, with no build step between an edit and the next answer. Cost: That readability is maintained by hand. Nothing keeps the relationships correct once the knowledge base gets past the size one person can hold. ## What is not solved 1. The comparison was read qualitatively. No benchmark numbers are cleared for publication. 2. Only tested up to a low-to-mid, self-written knowledge base. The size at which the Markdown approach stops being the better choice was not measured. 3. A hybrid — hand-written relationships with vector retrieval underneath them — was not built, so the obvious third option is untested. ## Interim conclusion RAG leads on token efficiency and speed, and that lead widens as the knowledge base grows. The Markdown LLM Wiki leads on maintainability and predictability. For a low-to-mid knowledge base that you wrote yourself, the Markdown approach was the more effective of the two: the relationships are explicit, so what the model will read is something you can anticipate. ## Process notes - RAG led on token efficiency and speed; the Markdown wiki led on maintainability and predictability. - For a low-to-mid knowledge base written by hand, the wiki was the more effective of the two. - No benchmark figures are cleared for publication, so the comparison is stated qualitatively.