Personal

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.

Interim resultRAG 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.

Back to the index

Stack: Obsidian / Markdown / Vector search
Aspects compared: 4
Open limits: 3

READ THE RESULT

01 / 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.

FIG. — THE QUESTION

02 / How it ran

Step through the run.

Four moves, in the order they happened.

FIG. 01 — 02 / HOW IT RAN

02 / How it ran / step 01 of 04

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.

03 / The approaches

Two builds, one question.

Switch between them. Same slots, same order, so the difference is the content.

FIG. — RAG INDEX

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.

04 / What came out

Aspect by aspect.

Choose a row to read why it went the way it did.

RAG index — clear

Token efficiency

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.

Four aspects, read qualitatively across the two builds. No benchmark figures are cleared for publication yet.

05 / Trade-offs

Nothing here was free.

What each gain cost, on the same row as the gain.

What it bought
Vector search keeps the context small and the lookup fast, and it keeps working as the knowledge base grows.
What it 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.
What it bought
Hand-written relationships make the route to an answer predictable, and a wrong route is something you can see and fix.
What it 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.
What it bought
Plain Markdown stays readable and editable by the person who wrote it, with no build step between an edit and the next answer.
What it cost
That readability is maintained by hand. Nothing keeps the relationships correct once the knowledge base gets past the size one person can hold.

06 / Still open

What is not solved.

3 limits the experiment has not answered.

The comparison was read qualitatively. No benchmark numbers are cleared for publication.
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.
A hybrid — hand-written relationships with vector retrieval underneath them — was not built, so the obvious third option is untested.

FIG. — STILL OPEN

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.