LLM Wiki vs Semantic RAG
A comparison framework for choosing between two knowledge-base architectures: the Karpathy LLM Wiki Pattern (markdown + index + LLM reader) and semantic RAG (embeddings + vector database + similarity search).
Comparison
| Dimension | LLM Wiki | Semantic RAG |
|---|---|---|
| Infrastructure | Zero (flat files) | Vector DB, embedding model |
| Cost | Free (storage only) | Per-query embedding cost + DB cost |
| Token usage | High per query (reads full pages) | Low per query (top-k chunks) |
| Best scale | Up to ~hundreds of pages | Millions of documents |
| Accuracy | High (full-page context) | Medium (chunk context loss) |
| Setup time | Minutes | Hours to days |
| Maintenance | Manual ingest | Pipeline automation required |
Key points
- "One X user turned 383 scattered files and over 100 meeting transcripts into a compact wiki and dropped token usage by 95% when querying with Claude." [src-013]
- The 95% reduction is relative to unstructured context dumps, not vs semantic RAG — the wiki compacts raw content into dense indexed pages [src-013]
- Semantic RAG wins above millions of documents where the LLM cannot hold the index in context [src-013]
- For personal knowledge bases and team wikis under ~hundreds of pages, LLM wiki delivers better answers with simpler infrastructure [src-013]
- The crossover point depends on corpus size and query frequency; there is no universal threshold [src-013]
- Herk adds a question-led selection rule: choose markdown, wiki, vectors, or graph based on the question the system must answer later, not based on which retrieval technology feels more advanced [src-103].
- Semantic search is strong when the wording of the query differs from the wording of the source, but weak when the answer requires full-document or full-table context, such as summarizing an entire meeting or finding the maximum value across all rows [src-103].
- A single second brain can mix architectures. Durable decisions and project context may stay in markdown, transcript search may use vectors, and relationship-heavy client or business data may justify a graph [src-103].
Related entities
- Andrej Karpathy — originator of the LLM wiki pattern
- Pinecone — representative vector DB for semantic RAG
- Obsidian — visual layer for the LLM wiki
Related concepts
- Karpathy LLM Wiki Pattern — detailed architecture of the left column
- Retrieval-Augmented Generation (RAG) — the right column
- LLM Knowledge Bases (Karpathy pattern) — umbrella concept covering both approaches
- Claude Code Token Economics — token cost profile differs significantly between the two
- AI Second Brain Maturity Model — practical maturity framing for when to add semantic search or graph relationships
Source references
- [src-013] Nate Herk — "Build & Sell Claude Code Operating Systems (2+ Hour Course)" (2026-05-01)
- [src-103] Nate Herk – "Every Level of a Claude Second Brain Explained" (2026-06-17)
Recommended next
Keep reading from this thread
From 491 indexed pages and articles.
- Wiki concept Karpathy LLM Wiki Pattern A knowledge-base architecture popularised by Andrej Karpathy in April 2026 as a RAG alternative for small-to-medium personal corpora. Related by retrieval
- Wiki concept Retrieval-Augmented Generation (RAG) The mainstream pattern for answering questions over a document collection: index the documents as vector embeddings, retrieve the most similar chunks at query Related by retrieval
- Insight Generative Engine Optimization for AI Search A practical GEO guide for becoming visible in AI-generated answers through machine-scannable content, authority, schema, and monitoring Readers have engaged with this next