把工作从查询时挪到摄入时：'LLM Wiki' 路线撞上了约 100 个信息源的天花板

你大概有过这种体验：让一个 AI 助手查一下公司内部的某份文档，它每次都把同一批 PDF 从头读一遍，不变得更便宜，也不更聪明。Andrej Karpathy 在 2026 年 4 月发在 GitHub 上的一份 Gist 里，把这种架构命名为「LLM Wiki」，并提出一个反向做法：把「知识查询-检索-拼接-推理」这条 RAG（retrieval-augmented generation，即「检索增强生成」）流水线整个倒过来，在摄入阶段就让大模型把原始文档编译成结构化的 Markdown 维基页面，查询时直接定位页面，不再每次重读。

在四个月内，这个想法从 Karpathy 的个人 Gist 变成了一类产品。Mem0 在 X 上发布的专栏 把这条路统称为 Agent Wikis，并梳理出三支几乎同步落地的团队：Cognition 推出的 DeepWiki、Factory 的 AutoWiki、LangChain 的 OpenWiki，以及投资人 Garry Tan 的个人项目 GBrain。Mem0 的系统综述 把所有这些项目放在同一张架构图里比较，是目前对这件事最完整的一份二手拆解。

Karpathy 的 Gist 把这套架构拆成三层：最底层是「原始文档层」，只读、不可改，是事实的唯一来源；中间是「维基内容层」，由 LLM 一次性通读文档后提炼出的 Markdown 页面集合，自带摘要、分类和互相之间的内链；最上层是「规则文件层」，像 AGENTS.md、CLAUDE.md 这类维护规则，由人来写。三件事每天在被反复执行：摄入（ingest，把新文档编译成新页面）、查询（query，按页面导航回答问题）、校验（verify，定期扫描矛盾、过期、孤立页面并自动修正或标记）。Mem0 把这一整套机制称为「compile at ingest, not at query」，核心就是一次编译、多次查询。

Karpathy 在 Gist 里 给了一个具体的规模边界：纯靠页面导航、不带向量检索的方案只适合约 100 个信息源、几百个页面的中等规模。超过这条线，页面之间的链接结构会变得太稀疏、太不一致，必须补回 BM25 关键词检索（一种经典的信息检索打分方法，按词频给文档排序）、向量检索（把文本变成数字向量、按相似度查找）和 LLM 重排序（用大模型对候选结果再排一遍）的混合检索。雷峰网的解读 把它讲成「淘汰 RAG」，但 Karpathy 自己描述的更准确：维基接管了 RAG 在中等规模下的那一段，更大的规模需要把维基和经典检索拼起来用。

维护成本没有消失，只是被搬了家，从人手里挪到了模型手里。人类维基从 1945 年范内瓦·布什的 Memex 算起，维护失败过 80 年，失败的不是存储或检索，而是人不愿意持续改。LLM Wiki 把这个失败模式从「废弃的人类页面」换成了「静默过期、相互冲突的模型页面」。Karpathy 在 Gist 里 单独把 verify 列为三大核心操作之一，正是为了应对这一点：定期扫描、自动修正或标记冲突，本质上是把「谁来改」这个老问题，改写成了「模型在什么时间点自检」。

对正在做 AI 助手的团队来说，这条路给了一个可以马上试的小判断：在自己的语料规模落在约 100 个信息源、几百页以内时，编译一份由模型维护的维基，确实比每次查询都跑 RAG 更便宜、答案更稳定；超过这条线，把它当 RAG 之上的「组织层」来用，而不是替代。Karpathy 的那个比喻（「Obsidian 是 IDE，LLM 是程序员，维基就是代码库」）精确地划出了这条线：维基不是被读的资料，是被维护的产物。维基好不好用，取决于它有没有被持续地编译。