What if instead of making an AI search through your documents every time you ask a question, you had it read everything once and build an organized reference it maintains over time?
That's the core idea behind Andrej Karpathy's approach to LLM knowledge bases, detailed in a new writeup from DAIR.AI. It replaces the standard RAG setup (where a language model retrieves relevant document chunks from a vector database at query time) with something more like a personal research assistant that builds and curates a wiki for you.
How the Four Phases Work
The system runs in stages. First, raw data comes in from multiple sources: web articles clipped through Obsidian Web Clipper, academic papers from arXiv, GitHub repositories. Everything lands in a staging directory.
Then the LLM compiles it. Not into a database, but into structured markdown: index files with document summaries, roughly 100 concept articles spanning about 400,000 words, all cross-referenced. The model builds the connections between ideas automatically.
Phase three is where it gets interesting. You browse the compiled wiki through Obsidian, query it through a Q&A agent, or search it directly. But here's the key detail: outputs from every query get filed back into the wiki. Every time you ask a question, the answer becomes part of the knowledge base. The system compounds.
Finally, the LLM runs maintenance: scanning for inconsistencies, filling in gaps through web searches, identifying missing connections, and suggesting new research directions.
No Vector Database Required
At personal scale (around 100 articles), Karpathy's argument is that you don't need a vector database at all. A structured markdown wiki that the LLM incrementally compiles and maintains works better for most individual use cases. The LLM handles all the writing. You do minimal manual editing.
This is a meaningful departure from how most people think about giving AI access to their knowledge. The standard approach, RAG (where relevant chunks of text are pulled from a database and stuffed into the prompt alongside your question), works but has known problems: retrieved chunks can be out of context, the ranking isn't always right, and the system has no memory of past interactions.
Karpathy's wiki approach sidesteps these issues by doing the synthesis work upfront and treating the knowledge base as a living document rather than a static archive.
Practical Implications for Tool Users
The DAIR.AI writeup also describes a complementary approach using the qmd CLI tool for semantic search across hundreds of papers, then building interactive visualizations through MCP tools to explore the results.
For anyone managing a personal research library, competitive intelligence files, or a growing collection of technical notes, this is a concrete alternative to the vector-database-plus-RAG pattern that most AI knowledge tools default to. The tradeoff: it requires more compute upfront during compilation, and the LLM needs to be good enough to write accurate summaries without hallucinating. But the payoff is a knowledge system that gets more useful every time you interact with it, rather than one that stays static between manual updates.
Tools like Obsidian, Notion, and Coda could adopt this pattern. Some already have basic AI features, but none yet offer the full compile-maintain-compound loop Karpathy describes. That gap is probably temporary.