The LLM Personal Knowledge Base Pattern

Andrej Karpathy’s architecture idea for an LLM personal knowledge base.

Core Idea

Traditional RAG: upload documents → retrieve relevant chunks at query time → the LLM derives the answer from scratch. Every question rediscovers knowledge all over again; nothing accumulates.

Karpathy’s approach: the LLM actively integrates knowledge into a persistent wiki at ingest time, rather than just indexing it. Cross-references, contradiction flags, and synthesis all happen at ingest time, and knowledge compounds over time.

The Three-Layer Architecture

Raw Sources          Wiki              Schema
(原始文档)    →    (LLM维护的md)  →   (CLAUDE.md/AGENTS.md)
- 不可变                      - LLM 完全拥有      - 指导 LLM 如何
- 只读                        - 创建/更新/维护     维护 wiki 的配置
- 来源信任                    - 跨引用/一致性      - LLM 遵守的规范

1. Raw Sources

• Articles, papers, images, data files
• Immutable — the LLM only reads, never modifies
• This is your root of trust

2. Wiki (knowledge layer)

• A collection of LLM-generated markdown files
• Entity pages, concept pages, comparison pages, overviews, synthesis
• The LLM fully owns this layer: creating, updating, cross-referencing, and maintaining consistency

3. Schema (configuration layer)

• CLAUDE.md / AGENTS.md, etc.
• Defines the wiki structure, conventions, and workflows
• With this in place, the LLM becomes a disciplined wiki maintainer instead of a general-purpose chatbot

The Three Core Operations

Ingest

1. Drop new documents into the raw collection
2. Tell the LLM to process them
3. The LLM reads the documents and discusses the key points with you
4. It writes summary pages, updates the index, and updates the relevant entity/concept pages
5. Appends to the log

The key: a single document may touch 10–15 wiki pages, rather than just being indexed and stored.

Query

1. The LLM searches for relevant pages, reads them, and synthesizes an answer
2. The answer can be presented as: an md page, a comparison table, slides, a chart, a canvas
3. Important insight: valuable answers/analyses should be written back into the wiki, so that exploration output compounds too

Lint

Periodic health checks:

• Contradictions between pages
• Stale content superseded by newer sources
• Orphan pages (no inbound links)
• Important concepts that are mentioned but don’t have their own page
• Missing cross-references
• Data gaps (that can be filled by searching)

Two Special Navigation Files

index.md (content-oriented)

• A wiki table of contents: a link to every page + a one-line summary + metadata
• Organized by category (entities/concepts/sources, etc.)
• Updated by the LLM on every ingest
• At query time, the LLM reads the index first to locate relevant pages, then digs in
• Works well at medium scale (~100 sources, a few hundred pages), with no embedding RAG infrastructure needed

log.md (time-oriented)

• An append-only record in chronological order
• Records what happened and what the source was
• Immutable, a pure timeline

Use Cases

Comparison: The Wiki Approach vs Traditional RAG

How Mousebomb’s Current Setup Maps to This

Mousebomb’s Obsidian journal vault + knowledge base is already putting a similar approach into practice:

• Raw Sources → the /mnt/obsidian journal vault (immutable raw records)
• Wiki → workspace/知识库/ (structured documents the LLM helps organize and maintain)
• Schema → SOUL.md + AGENTS.md (configuration that guides how the LLM works)
• Ingest → the knowledge base write workflow
• Query → knowledge base retrieval
• Lint → still to be put into practice (periodically checking wiki health)

What could be added:

• A regular Lint routine (a weekly health check)
• log.md timeline records (right now there’s only an index, no activity log)
• Encourage the habit of “storing valuable conversation conclusions in the wiki too”