从RAG到LLM Wiki：大模型知识管理正在经历一场"编译革命"
一、先说痛点：你收藏了200篇文章，真正内化了多少？
刷到好文章，赶紧收藏；看到有用的文档，下载到本地；遇到精彩观点，复制进笔记软件。然后这些东西就静静地躺在那里，再也没被打开过。
如果你用过RAG方案来管理知识，情况可能更微妙——系统确实能回答问题了，但每次提问都要从头检索一遍原始文档，同一个问题问100次，就重复100次"检索-拼接-推理"的全流程，算力和Token成本随提问次数线性上涨。更要命的是，系统不会沉淀任何结论，第100次回答的质量和第1次没有任何区别。
2026年4月，AI领域知名研究者Andrej Karpathy在GitHub上发布了一篇技术Gist，提出了一个叫「LLM Wiki」的构想。短短数月内，Cognition、Factory、LangChain等团队几乎同步落地了同类产品。这篇文章要讲清楚的，就是这套方案到底在解决什么问题，以及它和传统RAG的本质区别在哪。
二、一个关键类比：解释器 vs 编译器
Karpathy在原文里用了一个计算机科学的类比来区分两种范式：
传统RAG像解释器——运行时重新求值一切。每次查询，系统都要实时定位、拼凑相关片段，没有任何东西积累下来，查询之间不存在持续构建的持久化结构。
LLM Wiki像编译器——预先将源材料处理成结构化中间表示（即wiki），后续所有推理都针对编译产物展开，而非反复阅读原始材料。
Wiki充当中间表示，index.md充当符号表，log.md充当构建日志，LLM agent充当编译器进程。
这个类比不只是修辞。它精确地描述了两者在计算时机上的根本差异：RAG把核心计算放在查询时完成，LLM Wiki把核心计算前移到摄取时完成。
三、LLM Wiki的工作机制
3.1 三层架构
Karpathy的设计最核心的贡献，是把知识系统干脆利落地切成三层：
第一层：Raw Sources（原始材料层）。 铁律只有一条——不可变。PDF、网页剪藏、代码文件、图片，统一进入raw/目录，LLM可以读取但没有写入权限。这是事实基准，如果wiki出了问题，可以从原始素材重建。
第二层：Wiki（派生知识层）。 LLM消化后产出的概念页、实体页、对比页、综合页。一个Markdown文件目录，包含实体页面（人物、公司、论文）、概念页面（思想、方法、框架）、主题摘要、对比表格和综合概述。LLM创建、更新、维护全部内容，人来阅读。
第三层：Schema（行为约束层）。 即CLAUDE.md或AGENTS.md，一份配置文档，告诉LLM wiki的结构规范、约定和工作流。没有Schema，LLM只是写作者；有了Schema，LLM才是知识库维护者。
3.2 Ingest不是"丢篇文章写个摘要"
很多人以为摄入就是"给一篇文章生成一个摘要页"。实际上，单个来源进入后往往触达8-15个页面——更新概念页、新建实体页、建立冲突页、刷新索引和日志。
一个成熟的摄入管线大致有八个步骤：接收 → 规范化 → 读取Schema → 分析 → 生成 → 交叉引用 → 更新控制面 → 进review队列。
这才是整个范式里最被低估的部分——把"生成"工程化成一条可增量、可缓存、可审计的流水线。
3.3 复利效应：第100个来源站在前99个的肩膀上
Karpathy反复提到"compounding"（复利）这个词，它在这里承担的是真正的概念工作，不是包装话术。
在标准的个人知识管理工具（Notion、Roam、普通Obsidian仓库）里，添加第100条笔记不会让第50条笔记变得更聪明。但LLM Wiki模式下会——因为wiki本身是被持续更新的产物，也是所有后续推理的依据。第100个来源的处理建立在一个已经蒸馏了前99个来源知识的wiki之上，不会从零起步。
具体来说，模型不只是写一个摘要页面，它会通读整个现有wiki，找出新内容与已有实体页面、概念页面和主题摘要的交集，然后更新所有相关内容。一个新来源可能触及10到15个现有页面，矛盾被标记，交叉引用被添加，综合页面被修订。
3.4 让Wiki"活起来"的四个机制
除了摄入和查询，一套完整的LLM Wiki还需要四个持续运行的机制：
- Query：查编译结果而非原始文档
- Save：将高价值对话结论回写为Wiki页——不做这一步，LLM Wiki就退化回带日志的聊天系统
- Lint：结构检查 + 语义检查，发现断链、孤儿页、矛盾和过时声明
- Research：自动发现知识缺口并补充
四、和传统RAG到底有什么本质区别？
这是最容易被误解的地方。很多人看到LLM Wiki就说"这不就是多绕了几步的RAG吗"。实际上，两者在架构哲学上有根本差异。
核心对比表
| 维度 | 传统RAG | LLM Wiki |
|---|---|---|
| 核心范式 | 查询时做功 | 摄入时编译 |
| 核心比喻 | 解释器 | 编译器 |
| 知识沉淀 | 无持久化中间产物 | 结构化Wiki持续积累 |
| 重复成本 | 每次查询重检索，线性增长 | 知识编译一次，查询只读 |
| 回答质量 | 第100次≈第1次 | 第100次优于第1次（复利） |
| 知识冲突处理 | 无机制，靠模型自行判断 | 显式标注矛盾，触发页面更新 |
| 事实精度保障 | 基于原始片段，召回准确则精度高 | 基于编译产物，需信任编译质量 |
| Token消耗 | 每次查询消耗检索+拼接的Token | 摄入时消耗大，查询时消耗小 |
| 冷启动成本 | 低（分块+向量化即可） | 高（需LLM通读并生成结构化页面） |
| 适用场景 | 简单文档问答、客服、实时检索 | 持续知识沉淀、研究助手、个人Wiki |
更深层的差异：谁在做"综合"这件事
RAG的逻辑是查询驱动：你问一次，它现场检索、现场拼接、现场回答。下一次问类似的问题，全过程还得从头来。
LLM Wiki把逻辑反了过来——将"综合"从查询阶段前移到摄入阶段。新资料一进来，模型立刻将其编译成结构化、可导航的知识页面。等你要用时，查的是这份被反复消化过的知识资产，而不是原始文档堆。
用一句话概括：LLM是编译器，聊天是入口，Wiki是产品。
五、LLM Wiki在实践中怎么落地？
5.1 已有开源实现
目前GitHub上已经有多个基于Karpathy构想的开源项目：
- ddsyasas/llm-wiki：从零实现的完整版，支持文章、论文、笔记、PDF、URL的摄入，输出可直接作为Obsidian vault打开。包含三维图谱视图、Schema编辑器、聊天回写等功能。
- my-llm-wiki：Python包，支持19种编程语言的代码解析（通过Tree-sitter AST），以及PDF、DOCX、PPTX、EPUB等多种格式。
- llm-wiki-compiler：npm包，新增了"可配置生命周期Profile"机制，将LLM Wiki转化为可复用的领域知识基座。
5.2 手动搭建的最小路径
如果你想从零开始体验，Karpathy本人的实践路径是这样的：
- 用Obsidian Web Clipper浏览器插件把网页文章一键转成Markdown
- 把素材统一放入
raw/目录 - 编写
CLAUDE.md定义wiki的结构规范和页面命名规则 - 让LLM执行摄入：读取原始材料 → 生成概念页和实体页 → 建立交叉引用 → 更新索引
- 后续提问时，LLM直接从wiki页面读取结构化内容
5.3 一个容易忽视的关键点
LLM Wiki和"AI记忆"（Agent Memory）是两回事。Agent Wiki解决的是团队或个人的显性知识资产化问题，而Agent Memory解决的是单次会话内的上下文延续问题。把这两个概念混为一谈，是很多知识库项目落地失败的原因。
六、LLM Wiki会淘汰RAG吗？
不会。但它们会走向分工。
RAG的核心优势在于始终基于原始文档片段作答，只要召回的片段准确，事实精度就有保障。这个特性在需要严格溯源和实时性的场景下不可替代——比如客服系统需要实时查询订单状态，或者合规审查需要精确引用原文条款。
LLM Wiki的核心优势在于知识的持久沉淀和复利增长。它更适合那些"知识本身需要被反复消化、交叉关联、持续更新"的场景——个人学习系统、研究知识库、企业技术文档体系。
目前更务实的做法可能是混合方案：用RAG处理需要高精度溯源的实时查询，用LLM Wiki维护长期积累的结构化知识层。事实上，2026年的RAG技术本身也在演进——Agentic RAG、GraphRAG等新范式正在弥补传统RAG在复杂推理和关系型问题上的短板。
Karpathy的贡献不在于发明了一个"替代RAG的方案"，而在于指出了一种被长期忽视的知识管理可能性：让LLM不只是回答问题，而是持续地建构和维护知识本身。
本文基于Andrej Karpathy于2026年4月发布的LLM Wiki技术Gist及相关开源实现整理撰写。
