从RAG到知识编译
RAG 的工作方式是每次提问都重新检索、重新拼接、重新推理。问一个需要综合五篇文档才能回答的问题，模型每次都得从头找到这五篇，拼起来，再给你答案。问十次，找十次。什么都没积累下来。
Karpathy 前两天发了一个叫 LLM Wiki 的 gist，提了一个不同的思路：别让模型每次现场检索了，让它把知识预先编译成一个结构化的 wiki，查询的时候直接查编译好的结果。
RAG的问题
RAG 不是没用，但它的工作模式有一个根本性的效率问题。
你往 RAG 系统里扔了 200 篇论文。问"这个领域最近三年的研究趋势是什么？"模型去向量数据库里检索，拿回相关性最高的 10 个 chunk，拼进 prompt，然后生成答案。听起来合理，但仔细想想：回答这个问题需要的信息散布在几十篇论文里，10 个 chunk 大概率覆盖不全。就算你把 k 调到 50，chunk 之间的关系、矛盾、演进脉络，模型都得在一次推理里临时搞清楚。
第二天你换个角度再问一遍，模型又从头来一次。昨天已经做过的综合分析，一个字都没留下来。
NotebookLM、ChatGPT 的文件上传、各种 RAG 框架，本质上都是这个模式：原始文档 → 检索 → 临时拼接 → 生成。知识停留在原始文档里，从来没有被结构化地整理过。有意思的是，已经有产品在绕开这条路了：Claude Code 的检索没有向量数据库也没有 embedding 索引，靠的是关键词搜索加文件结构推理，在百万行代码库里照样能精准定位。这至少说明向量检索不是唯一解。
加上向量检索的理论天花板里讨论的问题：单向量模型能表示的 top-k 组合数量有硬性上限，十万文档、k=100 的场景下理论下界就逼近主流模型的最大维度 4096。查询越复杂，检索就越不可靠，这不是模型不够好的问题。
编译而不是解释
Karpathy 的思路换了一个角度：与其每次查询时临时检索和推理，不如让 LLM 在文档入库时就做一次深度处理，把知识"编译"成一个持久化的 wiki。
类比编程语言的话，RAG 是解释执行，每次运行都重新解析源码。LLM Wiki 是编译执行，源码只处理一次，之后直接跑编译好的产物。
具体来说有三层：
最底层是原始文档，论文、文章、会议记录、播客笔记，只读不改。中间层是 LLM 生成和维护的 wiki，包括摘要页、实体页、概念页、对比分析、综述。最上层是一个 schema 文件（比如 CLAUDE.md），告诉 LLM 这个 wiki 的结构规范和工作流程。
每次你加入一篇新文档，LLM 不只是把它存起来等着被检索。它会读这篇文档，写一个摘要页，然后去更新所有相关的实体页和概念页，标注新数据和旧结论之间的矛盾，补充交叉引用。一篇文档可能触发 10-15 个 wiki 页面的更新。
知识只编译一次，之后持续更新。
查询变成了查 wiki
编译完之后，查询的方式也变了。模型不再去原始文档里捞 chunk，而是先读 wiki 的索引文件，找到相关页面，再综合这些已经整理好的内容来回答。
关键区别是：交叉引用已经建好了，矛盾已经标注过了，综合分析已经做过了。模型不需要在一次推理里临时完成所有这些工作。
Karpathy 自己的用法是一边跑 LLM Agent，一边在 Obsidian 里看 wiki 的实时更新。LLM 写文件，Obsidian 渲染，用图谱视图看哪些概念连在一起、哪些页面是孤岛。他的比喻很到位：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。
查询的结果也可以反哺 wiki。你问了一个对比分析的问题，答案本身就是有价值的内容，可以作为新页面存回 wiki。这样你的每次提问都在让知识库变得更丰富，而不是消失在聊天记录里。
谁来做维护
知识库这东西，人人都知道好，但很少有人能维护下去。不管是团队 wiki 还是个人笔记，衰败的原因都一样：维护成本比使用价值增长得快。你写了 50 页笔记之后，每加一页就得检查跟前面的内容有没有矛盾，交叉引用有没有更新，旧的结论有没有被新数据推翻。这些活又琐碎又无聊，大多数人坚持不了几周。
LLM 恰好擅长这些事：不会忘记更新交叉引用，不会嫌一次改 15 个文件麻烦，不会因为维护工作太无聊就放弃。Karpathy 还建议定期做 lint，让 LLM 检查 wiki 的健康度，找出矛盾、孤立页面、缺失的概念页、可以用搜索补充的数据空白。
维护就是知识管理的瓶颈，LLM 把这个成本降到了接近零。
适合什么场景
Karpathy 列了几个方向：个人知识管理（日记、文章、播客笔记），研究深挖（几周到几个月的论文阅读），读书（按章节建 wiki，角色、主题、情节线索互相链接），团队知识库（Slack 对话、会议记录、客户通话自动整理）。
我觉得最有说服力的场景是长期研究。你花三个月读一个方向的论文，前面读的到后面就记不清了。RAG 能帮你找到某篇论文里的某段话，但没法告诉你这段话跟三周前读的另一篇有什么关系。wiki 可以，因为这些关系在入库时就已经被建好了。
团队场景也有意思。每个团队都有那种"这个事情之前讨论过，结论在某个 Slack 频道的某条消息里"的问题。如果有一个 LLM 在持续把这些碎片信息编译成结构化 wiki，信息损耗会小很多。
RAG 就没用了吗
说回开头的问题。LLM Wiki 的存在是不是意味着向量检索 RAG 没意义了？
不是。两者解决的问题不一样。
RAG 解决的是"在大量文档中快速定位相关片段"的问题，适合一次性查询、文档量大但不需要深度综合的场景。你有 10 万篇客服对话记录，用户问一个具体产品问题，RAG 能在毫秒内找到最相关的几条。这个场景下你不需要也不可能预先编译一个完整的 wiki。
LLM Wiki 解决的是"在有限文档中持续积累和综合知识"的问题。文档量相对可控（几十到几百篇），但每篇之间的关系很复杂，需要长期维护和深度整合。
换个说法：RAG 是搜索引擎，LLM Wiki 是百科全书。你不会用百科全书的方式来组织 10 万条客服记录，也不会用搜索引擎的方式来做三个月的文献综述。
其实 RAG 社区也在往"预处理"的方向走。微软的 GraphRAG 在检索前先构建知识图谱，本质上就是一种知识编译。LLM Wiki 走得更远，编译的产物不是图谱而是人类可读的文档。两者的共同判断是：光靠查询时检索不够，得在入库时就做结构化处理。
真正的启示可能是：RAG 不应该是知识管理的终点。很多人把文档往向量数据库一扔就觉得搞定了，但检索只是第一步。对于需要深度理解的场景，检索之后的知识编译才是关键。
幻觉、规模和成本
Karpathy 的 gist 很坦诚地说了这是一个"idea file"，只描述模式不提供实现。实际跑起来有几个明显的坑。
LLM 的幻觉问题在 wiki 场景下会被放大。RAG 里幻觉只影响一次回答，下次重新检索还有机会纠正。wiki 里如果某个实体页的一个事实写错了，后续所有引用这个页面的分析都会基于错误信息。错误会编译进知识库，越积越深。这大概是最需要 lint 机制的原因：不只是找孤立页面，更得找编译进去的错误。
规模也是个问题。Karpathy 说中等规模（约 100 篇文档、几百个页面）用索引文件就够了，再大就需要搜索引擎。不过搜索结构化的 wiki 页面和搜索原始文档的 chunk 是两回事：wiki 页面有标题、有分类、有交叉引用，搜索的精度和召回都会好得多。真正的风险在别处：wiki 页面越多，LLM 更新时需要检查的关联页面也越多，维护一次的成本会逐渐上升。
成本也不低。每篇文档入库时可能触发十几个页面的更新，每次更新都是 LLM 调用。100 篇文档的编译成本远高于向量化入库。不过换个角度想，这些成本花在入库阶段，省下来的是每次查询时的重复推理。如果你的查询频率远高于入库频率，编译在经济上是划算的。
一个老想法的新实现
Karpathy 在文末提到了 Vannevar Bush 1945 年的 Memex 构想：一个私人的、主动策展的知识仓库，文档之间的关联和文档本身一样有价值。Bush 解决不了的问题是谁来做维护。八十年过去了，LLM 补上了这块。
从 Memex 到 wiki 到 Notion 到 RAG 到 LLM Wiki，知识管理的历史就是在"存储容易、整理难"这个矛盾上反复挣扎。LLM Wiki 不是终极答案，但它第一次让"自动整理"变得可行了。至于整理的质量够不够好，大概得等用了三个月之后才知道。