LLM Wiki vs. Traditional RAG
Type: analysis Tags: llm-wiki, token-efficiency, claude-code
Summary
Comparison of the llm-wiki approach (Karpathy pattern) vs. traditional semantic search RAG. Both solve the same problem — letting an AI answer questions about a large document corpus — but with different tradeoffs.
Comparison Table
| Dimension | LLM Wiki | Semantic Search RAG |
|---|---|---|
| Navigation | Reads index, follows [[links]] | Similarity search over embeddings |
| Relationships | Explicit [[backlinks]] | Implicit via chunk similarity |
| Infrastructure | Plain markdown files | Embedding model + vector DB + chunking pipeline |
| Cost | Tokens only | Ongoing compute + storage |
| Maintenance | Lint + add articles | Re-embed on change |
| Scale limit | ~hundreds of pages | Millions of documents |
When to Use LLM Wiki
- Personal or team-scale knowledge bases (<1,000 docs)
- When you want explicit, auditable relationships between concepts
- When you want zero infrastructure (just files + Claude)
- When token-efficiency matters and you want a hot cache option
When to Use RAG
- Enterprise scale (millions of documents)
- When semantic similarity is more useful than explicit links
- When you need sub-second retrieval across massive corpora
Key Insight
“If you have hundreds of pages with good indexes, you’re fine with wiki graph. But if you’re getting up to millions of documents, you’ll want a traditional RAG pipeline.” — yt-llm-wiki-knowledge-system
The LLM wiki doesn’t replace RAG — it’s the right tool at personal/team scale, and the wrong tool at enterprise scale.