If you have ever asked a large language model a complex question that required synthesizing five different documents, you likely watched it stumble—rediscovering the same fragmented connections on every single query. This is the fundamental flaw in standard Retrieval Augmented Generation (RAG) architectures. The system treats knowledge as isolated vectors waiting to be retrieved, rather than as an interconnected web of understanding.

Enter the LLM Wiki, a concept popularized by Andrej Karpathy that flips this paradigm on its head. Instead of relying on retrieval at query time, an LLM Wiki is a persistent, interlinked collection of Markdown files that an AI agent incrementally builds and maintains over months or years. It transforms your Obsidian vault from a passive note-taking app into an active, compounding intelligence layer.

Synthesized from community practice; verified with primary docs.

#TL;DR: Key Takeaways

• Compounding Knowledge: An LLM Wiki replaces ephemeral chat histories with a persistent Markdown knowledge base that grows richer every time you ingest a new source or ask a question.
• Three-Layer Architecture: The system consists of immutable Raw Sources, an LLM-generated Wiki layer for cross-referenced synthesis, and a Schema file (like CLAUDE.md) that governs agent behavior.
• Beyond Standard RAG: By maintaining entity relationships and contradictions explicitly rather than relying on vector similarity alone, the LLM Wiki excels at answering complex, multi-hop questions.

What Exactly Is an LLM Wiki?

An LLM Wiki is a structured knowledge graph built on simple Markdown files that serves as persistent shared memory for AI agents. Unlike traditional RAG systems that index raw documents and retrieve chunks dynamically, the LLM Wiki compiles information into curated entity pages, concept summaries, and interconnected notes that persist across sessions.

The architecture was formalized by Andrej Karpathy in a widely circulated GitHub Gist, where he described it as an “idea file” for agentic knowledge work. The core insight is simple but profound: the AI should do the grunt work of summarizing, cross-referencing, and filing information so that you can focus on exploration and questioning.

Karpathy’s model relies on three distinct layers:

1. Raw Sources: Your curated collection of immutable documents—articles, research papers, meeting transcripts—that serve as the ground truth.
2. The Wiki Layer: A directory of LLM-generated Markdown files containing entity pages (e.g., specific people or tools), concept summaries, and comparison tables. The AI owns this layer entirely, creating and updating it automatically.
3. The Schema: A configuration file such as CLAUDE.md or AGENTS.md that defines the conventions for how the agent should organize information, maintain cross-references, and handle contradictions.

When you add a new source to your Raw Sources folder, the AI does not simply index it for later retrieval. It reads the material, identifies key entities, updates relevant pages across the wiki, flags any contradictions with existing knowledge, and strengthens or challenges evolving syntheses. The result is a living document that compounds in value over time.

The Architecture of Structured Knowledge

To understand why an LLM Wiki outperforms standard approaches, we must examine how structured information differs from unstructured retrieval. At the atomic level, every piece of knowledge in a graph-based system consists of triples: Subject, Predicate, and Object. These are the building blocks that allow computers to represent relationships rather than mere keyword proximity.

Google has utilized Knowledge Graph technology for over a decade to populate its search result panels with structured data like reviews, directions, and summaries. Wikipedia functions as an even more massive knowledge graph where articles act as nodes and hyperlinks serve as edges. The LLM Wiki applies this same principle to personal and professional knowledge management.

Visualizing Complexity Through Graph Views

Obsidian provides the visualization layer that makes this concept tangible. When you open your vault in Obsidian’s Graph View, you can see thousands of individual connections rendered as a network diagram. After three years of consistent use, many practitioners report seeing hundreds or even thousands of interconnected nodes revealing patterns and insights that linear notes simply cannot surface.

This visualization capability addresses one of the biggest pain points in knowledge management: information silos. When notes exist as isolated Markdown files with no links between them, discovering how concept A relates to concept B requires manual searching or brute-force reading. A graph-based wiki makes these relationships visible and navigable.

The Reference Librarian Model

Traditional RAG operates like a keyword search engine. You submit a query, the system finds semantically similar text chunks based on vector embeddings, and passes those chunks to the LLM for synthesis. This approach fails when questions require connecting information across multiple documents or understanding how different entities relate to each other.

The LLM Wiki shifts toward what practitioners call the “reference librarian” model. Instead of retrieving isolated fragments, the system understands that answering “how does X relate to Y?” requires traversing actual paths through the knowledge graph rather than calculating cosine similarity between unrelated paragraphs.

RAG vs. GraphRAG vs. LLM Wiki: A Performance Breakdown

The distinction between these three approaches is not merely semantic—it reflects fundamentally different engineering strategies for handling knowledge retrieval. Here is how they compare across critical parameters:

When GraphRAG Shines—and Where It Struggles

Microsoft’s BenchmarkQED evaluation suite revealed that GraphRAG significantly outperforms standard RAG on large-scale tasks requiring comprehensive summarization and complex reasoning across thousands of documents. The system extracts entities, builds a graph structure, and performs community detection to understand how different clusters of information relate.

However, this advantage comes with substantial overhead. For small datasets containing fewer than a few hundred documents, GraphRAG often underperforms standard RAG because the computational cost of constructing and querying the knowledge graph exceeds the benefit. The system essentially wastes resources building connections that do not exist in sparse data.

The LLM Wiki occupies a middle ground. It does not require specialized vector databases or graph query engines like Neo4j. Instead, it leverages the ubiquity of Markdown files and Obsidian’s built-in linking capabilities to achieve similar results at a fraction of the infrastructure cost. The trade-off is that as your wiki grows beyond a few hundred pages, you eventually need proper search tools rather than relying on a single index.md file.

Implementation: Building Your Own LLM Wiki

Constructing an LLM Wiki requires selecting the right agent framework and configuring your Obsidian vault for agentic interaction. The process follows a straightforward ingest-query-lint workflow.

Step 1: Setting Up the Schema Layer

Your schema file (CLAUDE.md, AGENTS.md, or similar) serves as the instruction manual that transforms a generic chatbot into a disciplined wiki maintainer. It should define:

• The directory structure for entity pages versus concept summaries
• Naming conventions for Markdown files
• Protocols for flagging contradictions when new information conflicts with existing entries
• Instructions for maintaining cross-references between related pages

Karpathy emphasizes that you and the LLM co-evolve this schema over time. Do not attempt to perfect it on day one.

Step 2: Ingesting Sources

Drop a new document into your Raw Sources folder and instruct the agent to process it. The expected workflow looks like this:

1. The LLM reads the source material in its entirety.
2. It identifies key entities, concepts, and relationships.
3. It creates or updates entity pages (e.g., a dedicated page for “Obsidian” or “GraphRAG”).
4. It revises concept summaries to reflect new findings.
5. It appends an entry to a chronological log.md file tracking all activity.

A single source might touch ten to fifteen different wiki pages. You can process sources one at a time while remaining actively involved, or batch-ingest multiple documents with reduced supervision depending on your workflow preferences.

Step 3: Querying the Wiki

When you ask questions against the wiki, the agent searches for relevant pages rather than retrieving vector-similar text chunks. It reads those pages and synthesizes an answer with proper citations. The critical insight here is that good answers should be filed back into the wiki as new pages rather than disappearing into ephemeral chat histories.

For moderate-scale wikis containing roughly one hundred sources and several hundred pages, a content-oriented index.md file listing all entries with summaries and metadata works surprisingly well. At larger scales, you will need dedicated search tools like qmd—a local hybrid BM25 and vector search engine specifically designed for Markdown files with on-device LLM re-ranking.

Step 4: Periodic Linting

Knowledge bases degrade without maintenance. Periodically instruct the agent to perform health checks that look for:

• Contradictions between pages where sources disagree
• Stale claims superseded by newer information
• Orphan pages with no inbound links indicating they may have been integrated elsewhere
• Important concepts mentioned across multiple pages but lacking dedicated entries
• Missing cross-references that could strengthen connections

This linting step transforms your wiki from a static archive into an evolving synthesis that actively improves as new data arrives.

Human-in-the-Loop: Separating Thought from Synthesis

A critical design pattern in the LLM Wiki paradigm involves separating your personal thinking space from the AI-maintained knowledge base. Many practitioners maintain two distinct vaults or directories:

The Human Vault: Your private, unstructured notes, journal entries, and raw thinking where exploration happens without judgment or formatting constraints.

The Agentic Vault (LLM Wiki): The structured, cross-referenced knowledge base that the AI maintains for retrieval purposes. This space contains synthesized entity pages, verified facts, and established connections rather than speculative thoughts.

This separation serves multiple purposes. It prevents data leakage where unstructured personal notes accidentally contaminate your AI-generated knowledge base. It establishes clear ground truth boundaries so you know which information has been vetted through synthesis versus which represents raw intuition. And it mirrors how professional reference libraries operate—maintaining both working drafts and curated catalogs.

Trade-offs: When to Reject the LLM Wiki Approach

The LLM Wiki pattern is not a universal solution. Several constraints warrant careful consideration before committing resources to this architecture.

First, the approach requires consistent participation over months or years to realize its compounding benefits. The value proposition emerges only after you have accumulated sufficient cross-references and entity pages for the graph structure to become meaningful. If your goal is quick answers to isolated questions without long-term investment, standard RAG or even simple keyword search may serve you better.

Second, maintaining accuracy in a growing knowledge base demands human oversight. As Karpathy acknowledges, “a small misunderstanding can quietly propagate across linked pages” if the AI agent hallucinates relationships or misinterprets source material. The linting process mitigates this risk but does not eliminate it entirely. You remain responsible for verifying critical claims.

Third, infrastructure limitations may emerge at scale. While Obsidian handles hundreds of interconnected Markdown files comfortably, wikis approaching thousands of pages will eventually require dedicated search infrastructure beyond simple index.md files or basic grep commands. The transition from lightweight personal knowledge management to enterprise-grade information retrieval introduces complexity that may not justify the marginal gains for most individual users.

When to Use This Approach

The LLM Wiki paradigm excels in scenarios where knowledge accumulation and synthesis matter more than instant retrieval. It is particularly well-suited for:

• Deep research projects spanning weeks or months where building a comprehensive understanding of a topic provides compounding returns
• Competitive analysis and due diligence requiring tracking relationships between multiple companies, products, or market trends over time
• Personal knowledge management for professionals seeking to connect insights across disparate domains like psychology, technology, and business strategy
• Team wikis maintained by LLM agents fed by meeting transcripts, Slack threads, and project documentation

Conversely, reject this approach if you need immediate factual answers without long-term investment, operate with extremely limited computational resources, or prefer ephemeral conversational interactions over structured knowledge building.

Quick FAQ

What AI agent frameworks are best for the maintenance layer of an LLM Wiki?

Karpathy’s original implementation uses Claude Code and OpenAI Codex, both of which excel at long-context document processing and structured Markdown generation. Community implementations also leverage Cursor, Windsurf, and custom Python scripts with LangChain or LlamaIndex for more granular control over the linting and ingestion workflows.

How do I prevent data leakage between my Human Vault and Agentic Vault?

Maintain physically separate directory structures or vaults in Obsidian. Configure your agent schema to restrict read access to only designated Raw Sources folders, never exposing unstructured personal notes to the AI. Implement explicit deny rules in your CLAUDE.md that prohibit referencing files outside the approved knowledge base.

Does GraphRAG offer benefits for small datasets?

Generally no. Microsoft’s benchmarks show GraphRAG incurs significant computational overhead during graph construction that provides minimal advantage on fewer than a few hundred documents. Standard RAG typically outperforms it in this range because vector similarity search is faster and less prone to the noise introduced by forced entity extraction from sparse data.

Can I use an LLM Wiki without Obsidian?

Yes, but Obsidian’s graph visualization and native Markdown support make it uniquely suited for this paradigm. Alternative platforms like Logseq or standard Git repositories with custom tooling can work, though you will lose the immediate visual feedback that helps users discover unexpected connections between concepts.

References

• Andrej Karpathy - LLM Wiki GitHub Gist
• Microsoft BenchmarkQED: Automated benchmarking of RAG systems
• GraphRAG-Bench: Comprehensive Analysis for Graph Retrieval-Augmented Generation
• RAG vs. GraphRAG: A Systematic Evaluation and Key Insights - arXiv