The LLM Wiki Pattern: Personal Knowledge Bases Without RAG
Andrej Karpathy popularized an approach to personal knowledge bases: dump raw material into a folder, have an LLM read and organize it into interlinked markdown wiki pages with an auto-maintained index. No vector database, no embeddings, no RAG pipeline — just markdown files and links. Simpler and cheaper than RAG for personal-scale knowledge (hundreds of pages), with deeper relationship understanding through explicit backlinks.
Andrej Karpathy popularized a pattern for building personal knowledge bases using LLMs without any of the typical RAG (Retrieval-Augmented Generation) infrastructure. The approach: dump raw source material into a folder, have an LLM (such as Claude Code) read it and organize it into an interlinked wiki of markdown files. ## Architecture The typical structure uses a raw folder for source material and a wiki folder for organized output: - **raw/** — PDFs, articles, transcripts, any unprocessed source material - **wiki/index.md** — auto-maintained index of all pages, the entry point for queries - **wiki/sources/** — source summaries - **wiki/concepts/** — extracted concepts - **wiki/entities/** — people, organizations, systems - **wiki/analysis/** — cross-cutting analysis The LLM ingests raw material, creates multiple wiki pages per source (one article can produce 20+ pages), automatically builds backlinks between related pages using `wikilink` syntax, and updates the index. ## Querying To answer a question, the LLM reads the index first, follows links to relevant pages, and synthesizes an answer. This is fundamentally different from semantic search: instead of finding chunks by embedding similarity, it navigates an explicit relationship graph. ## LLM Wiki vs Traditional RAG For personal-scale knowledge (hundreds of pages), the wiki approach is simpler, cheaper, and often produces better results: - **Infrastructure:** Just markdown files vs. embedding model + vector database + chunking pipeline - **Understanding:** Deep relationships via explicit backlinks vs. surface-level chunk similarity - **Maintenance:** Run a periodic "lint" (health check for inconsistencies, missing data, broken links) vs. re-embed when content changes - **Cost:** Token costs only vs. ongoing compute and storage - **Scale limit:** Hundreds of pages (sufficient for personal use) vs. millions of documents (where RAG becomes necessary) ## Maintenance: Linting Periodic health checks over the wiki: find inconsistent data, impute missing information with web searches, discover interesting cross-document connections, and suggest new pages to fill gaps. This is analogous to the editorial review process in larger knowledge systems. ## Optional: Hot Cache A `hot.md` file (~500 words) with the most frequently accessed context. Saves tokens by avoiding full wiki traversal for common queries. Useful for executive assistant use cases; unnecessary for research wikis. ## When RAG Is Still Necessary The wiki pattern breaks down at enterprise scale — thousands of documents, multiple contributors, real-time updates. At that point, embedding-based retrieval becomes necessary because the index becomes too large for an LLM context window. The wiki pattern is best understood as the personal/small-team solution, not a RAG replacement for production systems.