LLM Wiki

Definition

LLM Wiki（又称 AI Knowledge Base、AI KB）是由 Andrej Karpathy 于 2026 年 4 月提出的一种基于 LLM 的个人知识库构建模式。它的核心思想是：让 LLM Agent 增量式地构建和维护一个持久化的、结构化的、相互关联的 Markdown 文件集合——而不是像传统 RAG 那样每次查询时从零检索原始文档。

与传统 RAG 的"查询时检索→生成"不同，LLM Wiki 的范式是"一次性编译，持续维护"：当新数据源加入时，LLM 读取、提取关键信息，并将其整合进已有的 wiki 体系——更新实体页面、修订主题摘要、标注新旧数据之间的矛盾、强化或挑战既有综合结论。知识被编译一次后就保持最新，而非每次查询都重新推导。

核心差异：RAG vs LLM Wiki

维度	传统 RAG	LLM Wiki
知识持久性	查询后丢弃，无积累	知识被编译并持续维护
交叉引用	查询时动态发现	已预先建立，随时可用
矛盾处理	每次查询可能得出不同结论	矛盾已被标注和解决
综合深度	受限于检索片段数量	反映所有已读内容的综合
维护成本	低（仅更新索引）	需要 LLM 持续维护 wiki
查询延迟	检索 + 生成	直接搜索 wiki 页面 + 生成
适用规模	任意规模文档集	中等规模（~100 源，~数百 页）

三层架构

1. 原始数据源（Raw Sources）

• 用户精心策划的源文档集合：论文、文章、图片、数据文件
• 不可变——LLM 只读取，不修改
• 这是整个知识库的"真相来源"

2. Wiki 层（The Wiki）

• 由 LLM 生成的 Markdown 文件目录
• 包含：摘要页、实体页、概念页、对比页、总览、综合结论
• LLM 完全拥有这一层：创建页面、更新页面、维护交叉引用、保持一致性
• 用户阅读；LLM 写作

3. Schema 层（The Schema）

• 配置文件（如 CLAUDE.md、AGENTS.md）
• 定义 wiki 的结构、约定、工作流
• 告诉 LLM 如何摄取源、回答问题、维护 wiki
• 这是让 LLM 成为"有纪律的 wiki 维护者"而非"通用聊天机器人"的关键
• 用户与 LLM 共同演进这一文件

核心操作

摄取（Ingest）

将新源放入 raw 集合并让 LLM 处理。典型流程：

1. LLM 读取源文档
2. 与用户讨论关键要点
3. 在 wiki 中撰写摘要页
4. 更新索引
5. 更新相关实体和概念页面
6. 追加日志条目

一个源可能触及 10-15 个 wiki 页面。可以逐一手动监督摄取，也可以批量无监督摄取。

查询（Query）

向 wiki 提问。LLM 搜索相关页面、阅读、合成带引用的回答。回答形式多样：Markdown 页面、对比表、幻灯片（Marp）、图表（matplotlib）。

关键洞察：优质回答可以归档回 wiki 作为新页面。一次对比分析、一个发现、一个关联——这些都有价值，不应消失在聊天记录中。

清理（Lint）

定期让 LLM 健康检查 wiki：

• 页面之间的矛盾
• 被新源取代的陈旧论断
• 无入站链接的孤立页面
• 被提及但缺少独立页面的重要概念
• 缺失的交叉引用
• 可通过网络搜索填补的数据缺口

索引与日志

index.md（内容导向）

• wiki 中所有内容的目录
• 每页列出链接、一行摘要、可选元数据（日期、源数量）
• 按类别组织（实体、概念、源等）
• LLM 每次摄取后更新
• 查询时 LLM 先读索引找相关页面，再深入阅读
• 在中等规模下效果出奇地好，无需嵌入式 RAG 基础设施

log.md（时间导向）

• 追加式记录：发生了什么、何时发生
• 摄取、查询、清理 pass
• 技巧：使用统一前缀（如 ## [2026-04-02] ingest | Article Title）
• 可用简单 Unix 工具解析：grep "^## \[" log.md | tail -5

工具生态

工具	作用	与 LLM Wiki 的关系
Obsidian	Markdown 笔记 + 图谱视图	LLM Wiki 的"IDE"——实时浏览链接、图谱、更新
Obsidian Web Clipper	浏览器扩展，网页转 Markdown	快速将源加入 raw 集合
qmd	本地 Markdown 搜索引擎（BM25 + 向量 + LLM 重排）	wiki 规模扩大后的搜索工具，支持 CLI 和 MCP
Marp	Markdown 幻灯片格式	直接从 wiki 内容生成演示文稿
Dataview	Obsidian 插件，查询 frontmatter	基于 YAML 元数据生成动态表格和列表
Git	版本控制	wiki 就是 git 仓库，免费获得版本历史、分支、协作

为什么有效

维护知识库最繁琐的部分不是阅读或思考，而是簿记工作：更新交叉引用、保持摘要最新、标注新旧数据矛盾、维护数十个页面的一致性。人类放弃 wiki 是因为维护负担增长快于价值增长。

LLM 不会厌倦、不会忘记更新交叉引用、可以一次触及 15 个文件。wiki 保持维护是因为维护成本趋近于零。

人类的职责：策划源、指导分析、提出好问题、思考意义。LLM 的职责：其他一切。

历史渊源

这一理念在精神上与 Vannevar Bush 的 Memex（1945）相关——一个私人的、精心策划的知识存储，文档之间有联想轨迹。Bush 的愿景比后来的万维网更接近 LLM Wiki：私有、主动策划、文档之间的连接与文档本身同等价值。他没能解决的是谁来维护。LLM 解决了这个问题。

与本知识库的关系

本 AI Knowledge Base（AIKB）正是 LLM Wiki 模式的一个实践实例：

• 原始层：raw/ 目录下的论文、文章、官方文档
• Wiki 层：wiki/ 目录下的实体、概念、对比页面
• Schema 层：schema/SCHEMA.md 定义内容规范
• 索引：wiki/index.md 作为内容目录
• 日志：schema/log.md 记录演进历程

具体搭建方法参见：LLM-Wiki 知识库搭建指南 — 从数据摄取到部署的完整实践指南。

相关概念

• Retrieval Augmented Generation — 传统 RAG 方法，LLM Wiki 的对比基准
• AI Agents — LLM Wiki 的维护者通常是 AI Agent（如 Claude Code、Codex）
• Semantic Search — 传统 RAG 的核心召回技术
• Vector Databases — RAG 系统的存储层
• Model Context Protocol (MCP) — AI Agent 与外部系统交互的标准化协议
• LLM-Wiki 知识库搭建指南 — 基于 VitePress 搭建 LLM Wiki 的完整指南

Sources

• Karpathy, A. (2026). LLM Wiki: A pattern for building personal knowledge bases using LLMs. GitHub Gist. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f