Karpathy扔了一篇gist，想干掉RAG？

LLM Wiki：把RAG从主角降级为配角

Karpathy三个月前在GitHub扔了篇gist，叫《LLM Wiki》。没代码，没论文，就一页纯文字。结果获得5000多颗星，评论区炸成黑客松，一堆人排着队晒自己的实现。这戳中了一个忍了五年的痛点：LLM每次回答问题，都是从零开始重新发现知识，答完就忘，没有一丁点积累。以后检索只是导航，真正值钱的资产，是一份LLM替你持续维护的、会自己生长的知识库。

三层架构，权责分明

Karpathy换了个方向：别让LLM在提问时才去读原始文档，让它平时就把知识“编译”成一份持续维护的Wiki。

• 原始层：你喂进去的论文、文章、数据。不可变，LLM只读不写。这是事实源头。
• Wiki层：一堆互相链接的Markdown文件。实体页、概念页、对比页、综述页。LLM全权拥有这一层，建页面、改页面、维护交叉引用。你只负责读。
• Schema层：一个约定文件（比如CLAUDE.md），告诉LLM这个Wiki的目录结构、命名规范、收录流程。Karpathy原话：没有它，LLM就是个通用聊天机器人；有了它，LLM才是个“懂规矩的Wiki维护者”。

三个核心操作，闭环运转

收录：丢一份新资料进原始层。LLM读完一口气干这些事——写摘要页、更新总索引、更新所有相关实体页、标注和旧结论冲突的地方、往日志里追加一条记录。一份资料可能动10-15个页面。你可以一篇篇喂、全程盯着，也可以批量灌、事后抽查。

提问：基于已综合好的Wiki提问，LLM先查索引找到相关页，读完再答，附引用。关键设计是：好答案可以归档回Wiki变成新页面。一次深度对比、一个意外发现的关联，不该消失在聊天记录里——这样你的探索本身也在给知识库复利。

体检：定期让LLM给Wiki做健康检查。查什么？页面间的矛盾、被新资料推翻的过时结论、没有入链的孤儿页、被反复提到却没有自己页面的概念、缺失的交叉引用。LLM还擅长建议“下一步该找什么资料、该问什么问题”。这是Wiki不烂尾的续命机制。

两个关键文件，替代向量索引

Wiki长大的过程中，靠两个特殊文件导航，不需要embedding基础设施：

• index.md：内容导向的总目录。每个页面一行——链接加一句话摘要，按类别分组。每次收录必更新。提问时LLM先读索引锁定相关页，再钻进去细读。实测在约100份资料、几百个页面的规模下好使得很。
• log.md：时间线日志，只追加不修改。记录每次收录、提问、体检。小技巧：每条目用统一前缀，这样 grep "^## \[" log.md | tail -5 就能查最近动态，也让LLM知道最近干过什么。

Karpathy原话很精辟：“Obsidian是IDE，LLM是程序员，Wiki是代码库。”知识在这套体系里是编译产物，不是运行时临时算的。交叉引用已经建好了，矛盾已经标注了，综述已经反映了所有读过的资料。每多一份资料、每问一个问题，Wiki就厚一层。这才是“积累”该有的样子。

维护成本归零，Wiki才能活下来

泼一盆历史的冷水：个人知识库这想法一点不新。1945年，Vannevar Bush就提出了Memex构想。之后几十年，无数人尝试建个人Wiki，绝大多数都烂尾了。为啥烂尾？不是读不动，是记账记不动。更新交叉引用、同步摘要、标注新数据推翻了哪些旧结论——维护成本的增长速度远超Wiki价值的增长速度。人会烦，会懒，会放弃。

但LLM不会烦。它不会在周五晚上六点说“这周太累了引用下周再补”。一次更新15个文件，眼都不眨。维护成本约等于零，Wiki就能一直活着。

Google下场：OKF给这个模式定标准

如果说Karpathy给的是“民间偏方”，那么Google Cloud六月份干的事就是“收编正规军”：发布Open Knowledge Format（OKF），把LLM Wiki模式正式化成一个开放规范。

OKF的设计克制得让人感动：就是Markdown加YAML frontmatter，唯一必填字段是 type。没有SDK，没有运行时，没有专用数据库。你能 cat 一个文件，就能读OKF；你能 git clone，就能分发它。

基本单位叫 Bundle（知识包）——一个自包含的Markdown文件目录树。里面每个知识点叫 Concept（概念），一个概念一个文件，文件路径去掉 .md 后缀就是它的概念ID。每个概念文件就两部分：frontmatter和正文。规则就三条硬性的，其他全是软性建议。消费方必须容忍未知类型、未知字段、断链——宽容到这个份上，就是为了让任何生产者、任何消费者都能即插即用。

真正有意思的是7月25日刚发的v0.2，解决一个扎心问题：当Wiki是AI写的，你凭啥信它？人写的Wiki出了错，可以找人背锅。AI一晚上生成一万个概念，出了错找谁？v0.2的答案是五组字段，全部写在frontmatter里，让你在读正文之前就能判断这页可不可信：

• 溯源：这页内容从哪些材料提炼的，正文里具体某句话的出处用Markdown脚注逐条归因。
• 信任：generated 记谁生成的、何时；verified 记谁核验过、何时。核验者带 human: 前缀的就是“人工复核”档。三个信任等级，一句frontmatter过滤就搞定。
• 新鲜度：一个绝对日期，过期判断就是日期比大小。
• 生命周期：draft → stable → deprecated。废弃页面保留不删，历史查询可复现。
• 算数担保：一个指标页不只说“营收是这个数”，还带一段被认可的计算方式（如SQL）和配套检验程序。执行后验证实际跑的SQL和被认可的SQL是否一致，不一致则数字拒展。

注意一个设计哲学：OKF只记录信号，不打“可信度评分”。评分是主观的、会过期的；信号是客观的，谁拿到都能自己算。

缺点：别急着把向量库删了

想法很丰满，落地写代码，全是坑。评论区里真刀真枪干过的人已经踩出来了：

• 第一，漂移。 收录新资料时agent漏更新交叉引用，页面悄悄过期。体检不是可选项，是续命项。有团队直接挂定时任务跑矛盾检测。
• 第二，规模天花板。 纯index.md导航在几百个页面内好使得很，到几千个页面就开始喘。过了这个量级，还是得加搜索引擎——绕了一圈，检索又回来了。
• 第三，写入时的实体对齐。 新资料里提到的“张伟”，到底是已有实体还是同名新人？这个去重判断目前没有优雅解法，恰恰是这个模式“要么复利、要么蔓生”的分水岭。
• 第四，贵。 收录一份资料要动10-15个页面，token烧得比RAG检索猛多了。一次性问答场景，RAG便宜得多。
• 第五，垃圾进，垃圾复利。 LLM写错的东西也会被“编译”进Wiki，还会被后续页面引用。没有人工抽检，错误会利滚利。这也是Google火急火燎给v0.2加信任信号的原因。

所以我的判断是：一次性查资料的薄场景，RAG照旧；需要长期深耕的领域，Wiki碾压。 二者不是替代关系，是分层关系——检索退化为导航层，Wiki才是沉淀层。

知识库的定义正在改变

[偏激观点]：我赌两年内，“知识库”这个词的定义会变。今天它等于“向量数据库 + 检索器”，两年后它会等于“一个git仓库，里面装着AI维护的Markdown”。向量库不会消失，但会缩回基础设施层，像今天的倒排索引一样，没人再拿它当卖点。

当年我们做高并发游戏服务器，就是这么被坑惨的。2013年底，缓存设计偷懒，以为缓存是优化项，后来才发现缓存即架构。RAG是查询，Wiki是缓存。查询谁都会写，能活过三年的缓存设计才是本事。

真不行。那种每次从零检索的方式，太原始了。你的文档库，打算继续每次从零检索，还是今晚就开始让AI给你攒一份会自己复利的Wiki？

JOTO 企业落地观察

• 对企业部署意味着：Wiki模式要求组织将知识资产从“可检索”升级为“可演化”，需配套建立面向Git的权限治理、CI/CD式体检流水线与人工抽检SOP，而非仅替换检索组件。
• 对智能体工程而言：LLM Wiki天然适配Agent的长期记忆与自我反思能力，但需重构Agent的工具调用范式——从“调用检索API”转向“提交Wiki编辑请求+等待合并”，引入类似Pull Request的协同机制。
• 对RAG知识工程构成范式迁移：传统RAG依赖高质量chunking与embedding调优，而Wiki模式将工程重心转向Schema设计、frontmatter信号定义与矛盾检测规则编写，知识质量保障从后置校验前移到结构契约。
• 对AI安全治理提出新挑战：OKF v0.2的信任信号虽提供可观测性，但企业仍需自主定义“human:”核验者的准入门槛、freshness阈值及deprecated页面的归档策略，不能仅依赖格式规范。