LLM Wiki：基于预编译的下一代知识库，如何解决RAG的多跳查询与维护难题？

技术领域的轮子总在推陈出新，“下一代”的话题也从未停止。

最近，一个新的构想——“LLM Wiki”引起了广泛讨论，而提出它的是 Andrej Karpathy（OpenAI联合创始人、前特斯拉AI总监）。他在一个公开的“创意文件”中阐述了这一想法，没有附带任何代码、库或SaaS产品，纯粹是一种知识库设计模式的探讨。

“LLM Wiki”不是一个新应用、一个库或SaaS产品，而是一个“创意文件”，一种知识库设计模式。
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

这个看似简单的构想，却在评论区引发了热烈讨论。它究竟解决了什么痛点？

LLM Wiki 要解决什么问题？

“Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up.”

如果你构建或使用过基于 RAG（检索增强生成）的知识库，很可能经历过这样的场景：你上传了二十篇论文，问了一个问题，系统给出了一个不错的答案。第二天，当你换了个角度问一个相关问题时，系统会重新把那二十篇文档扫描一遍，再给你一个“不错”的答案。

传统RAG的工作方式是：用户提问时，系统从原始文档中实时检索相关片段，拼接成上下文，然后生成答案。每次查询都是从零开始的，系统不会保留任何对内容的结构化理解，回答完毕后相关上下文即被丢弃。这意味着相同或相似的复杂问题，每次都需要重新推理，无法累积知识。

核心思想：从运行时检索到“预编译”维护

LLM Wiki 的核心创新在于，它将知识工作的重心从查询时的实时检索，转移到了数据摄入时的“预编译”和持续维护上。

你可以把 LLM 看作一个“编译器”。它的任务是读取原始数据（文章、论文、对话记录等），然后输出一个结构化的 Wiki 知识库。这个 Wiki 不是简单的内容堆砌，而是包含了LLM生成的摘要、识别出的关键概念、撰写的综合性文章，以及在相关概念间建立的反向链接网络。

Obsidian是IDE，LLM是程序员，Wiki是代码库。—— Karpathy

三层架构设计

LLM Wiki 的典型架构包含三个核心层次：

1. Raw Sources（原始来源层）

• 功能：不可变的源文档库，存放文章、论文、抓取的数据、会议记录等。
• 约束：LLM 对此层只有读取权限，永不修改；通过 Git 等进行版本控制。
• 定位：可信的、唯一的真相来源。

实践中，你可以将各种来源的文档放入 raw/ 目录，并使用 Obsidian Web Clipper 等工具将网页文章转为 Markdown。同时，将相关图片下载到本地，以便具备视觉能力的 LLM 可以直接引用。

2. Wiki（维基层）
这一层完全由 LLM 生成和维护，内容类型包括：

• 实体页面：人物、组织、技术概念的权威定义。
• 概念页面：对特定主题的综合阐述、比较分析或演进叙事。
• 来源摘要：从原始文档中提取出的结构化信息。
• 关联网络：页面间的类型化引用关系（如：支持、矛盾、扩展、派生）。

3. Schema（模式层）

• 载体：类似 Claude Code 使用的 CLAUDE.md 或 OpenAI Codex 使用的 AGENTS.md 文件。
• 内容：定义页面类型与模板、摄入工作流、查询策略、领域特定约定等。
• 演进：随着领域知识的深化，由人和 LLM 协作迭代更新。

关键运行机制

1. 摄取（Ingest）
当新的源文档加入原始层时，触发以下流程：

新的源文档加入原始层
  1）LLM读取并提取关键实体、主张、关系
  2）创建新实体页面或更新现有页面（标注来源）
  3）修订相关概念页面（识别新旧矛盾）
  4）更新索引（index.md）和日志（log.md）
  5）[可选] 人工审核关键更新

一次摄取可能会级联更新 10-15 个维基页面，但一旦建立，这些结构化的理解便成为持久化的知识资产。

2. 查询（Query）
用户提出问题时，系统并非直接检索原始文档，而是：

用户问题
  1）LLM读取 index.md 定位入口页面（2-3个）
  2）沿关联网络钻取相关实体/概念页面
  3）综合答案（带精确来源引用）
  4）将答案归档为新维基页面（查询即贡献）

这是与 RAG 最根本的区别。在 RAG 中，一个好的问答只存在于聊天历史里；而在 LLM Wiki 中，这个高质量的答案可以直接沉淀为一个新的 Wiki 页面，未来所有涉及此主题的查询都可以直接利用这份“预编译”的理解。

3. 整理（Lint）
知识库会随着时间“腐化”：三个月前的笔记可能与新论文矛盾；某些页面再也无人引用，成了信息孤岛；标签体系变得混乱不堪。
定期让 LLM 扫描整个 Wiki 进行“整理”（Lint），就像代码检查一样。具体任务包括：找出前后矛盾的内容、标记孤立页面、发现被高频提及但尚未建立独立页面的重要概念，甚至通过网络搜索填补数据缺口。

局限性不容忽视

LLM Wiki 并非银弹，它也存在明显的局限性。

最突出的风险是幻觉固化。在 RAG 中，LLM 犯的错误是“临时性”的，下次检索可能就纠正了。但在 Wiki 中，错误会被写进一个具名的页面，后续所有读到这个页面的查询都会受到污染。更糟糕的是，后续的摄入流程可能会基于这个错误页面进行“调和”，导致错误自我强化。Lint 流程可以部分缓解，但不能根除。

其次是规模问题。Karpathy 提到，在大约 100 篇文章、40 万词的规模上，基于索引文件的导航是有效的。超过这个规模，可能需要引入 Qdrant 这类本地搜索引擎，系统复杂度会显著增加。

精确的源引用本身也是个挑战：

场景	问题
合成摘要	LLM 将多个来源信息压缩成流畅文字，导致观点归属模糊。
跨页更新	源文档修订后，维基中多个引用它的页面需要同步更新，但引用粒度不清。
多层编译	A引用B，B引用C和D，当C被证伪时，难以判断A的哪部分失效。
隐性知识	LLM 的“理解”嵌入在页面间的关联网络中，而非显式语句。

其他潜在问题：	方面	描述
Token 成本	每次更新可能触及10-15个页面，重写的累积开销较高。
认知负荷	需要持续监控LLM的“整理”行为，防止过度归并或错误关联。
版本焦虑	维基变大后，用户会担忧“这个页面现在还是准确的吗？”。
清理债务	错误不会自动消失，需要主动的 Lint 和人工干预来清理。

总结与适用场景

维护知识库的真正难点，往往不在于初期的阅读和录入，而在于日复一日的维护工作：更新交叉引用、保持摘要最新、标注新旧矛盾、在数十个页面间维护一致性。很多人最终放弃 Wiki，正是因为维护成本与收益不成正比。

而 AI 在这方面具有天然优势（如果不考虑 Token 成本）。它不会感到厌烦，不会忘记某个交叉引用，可以一次性修改几十个文件，让 Wiki 始终处于良好状态。

LLM Wiki 这种 设计模式 非常适合需要深度、持续构建领域知识的场景，例如个人学术研究、团队技术知识沉淀、复杂项目管理等。它本质上是用前期的“编译”成本，换取后续查询的高效与深度。

当然，如果你只是想快速从一批文档中检索出答案，传统的 RAG 仍然是更轻量、更直接的选择。LLM Wiki 和 RAG 代表了两种不同的知识管理哲学，它们或许会长期共存，服务于不同的需求。

对这类前沿的 AI 应用模式感兴趣？欢迎到 云栈社区 的开发者论坛参与更多讨论。