读完 Karpathy 的 LLM Wiki，我不再把 RAG 当默认答案

速读#

Karpathy 在 2026 年 4 月 4 日发布的 LLM Wiki 不是一个完成的软件，也不是证明 Wiki 优于 RAG 的基准测试，而是一份可以交给 Coding Agent 继续实现的模式说明。它建议保留不可变的原始资料，让 LLM 持续维护一层相互链接的 Markdown Wiki，再用 CLAUDE.md 或 AGENTS.md 约束摄入、查询和维护流程。

我读完后真正改变的不是“从 RAG 阵营换到 Wiki 阵营”，而是停止把向量库当成个人知识库的默认起点。我的资料整理后大约百来份，当前更需要可读、可修订和有来源的综合页面，而不是先维护 embedding、向量库和检索服务。最低成本的方案是先建 Wiki，用文件搜索或 BM25 解决召回；等真实问题证明它不够，再增加向量或混合检索。

LLM Wiki 实际提出了什么#

原始方案分成三层。raw/ 保存文章、论文、笔记、图片和转录等原始资料，LLM 只读不改，把它们当作事实来源；wiki/ 保存由 LLM 生成和持续更新的摘要、实体页、概念页、比较与综合结论；schema 文件则规定目录、命名、引用和工作流，让 Agent 知道新资料进来后应该更新哪些页面。Karpathy 把这种关系比作 Obsidian 是 IDE、LLM 是程序员、Wiki 是代码库。

围绕三层有三种主要操作。ingest 读取一个新来源，把要点合并到已有页面，补交叉链接并记录本次变化；query 先从索引或搜索结果找到相关 Wiki 页面，再读取并回答，值得保留的比较或分析可以经过确认后写回；lint 定期寻找候选矛盾、过期说法、孤立页面和缺失链接。这里的 lint 不是编译器那种确定性校验，它只能提出需要人工或原始资料复核的问题，不能因为 Agent 没报错就认定知识库一致。

index.md 与 log.md 分别承担内容索引和时间记录。原文认为一个维护良好的索引在约 100 个来源、数百个页面的中等规模下仍然有效，也明确建议规模继续增长后增加真正的搜索工具，例如支持 BM25、向量与重排的 qmd。这一点很重要：LLM Wiki 从来没有宣布“永远不需要检索”，它只是不要求从第一天就搭向量数据库。

Wiki 预先积累了综合结果，但查询仍然要检索#

我原来把两者写成“Wiki 查询前已经读完，RAG 每次现场拼装”，这个说法过头了。Wiki 的确把一部分理解工作前移到了摄入阶段：同一个人物、系统或概念已经有持续更新的页面，矛盾与关联也可以预先记录；但回答问题时，Agent 仍要通过 index.md、全文搜索或其他检索工具找到相关页面，再把它们放进上下文。页面一多，同样会遇到召回、上下文长度和排序问题。

RAG 也不等于“每次从零”。一个成熟系统可以保存层级摘要、结构化元数据、查询缓存、知识图谱和人工整理的专题页，检索也不只限于向量相似度，还可以组合关键词、过滤条件、权限和重排。Wiki 更像一组由 LLM 维护的可读物化视图，RAG 更强调按查询从较大语料中找到证据；两者可以共享原始资料，也可以组合使用。

这张表也不是胜负表。规模只是一个因素，资料更新速度、问题类型、引用精度、权限隔离、延迟和维护人力都会改变选择。几十份法规文件也可能因为需要精确召回而适合 RAG，几千篇长期研究笔记也可能因为重视综合脉络而保留 Wiki；固定的文档数或 Token 阈值无法替所有场景决定架构。

回头量自己的知识库#

我之前搭过 embedding、向量库和检索链路，能把资料放进去，也能得到看起来合理的回答。但当时有一个问题始终没回答好：我的知识量是否真的需要这套基础设施。重新整理后，资料大约是百来份，主题又相对集中，索引和相关页面仍然可以由人直接阅读；我更常问的是“这些运维经历之间有什么共同模式”，而不是从几十万份陌生文档中寻找一个精确片段。

在这个量级下，RAG 不是错，而是它增加的服务、切分策略、embedding 版本和召回调参暂时没有换回足够收益。我也无法清楚解释某次召回为什么漏掉关键段落，这意味着系统虽然能跑，维护能力却没有跟上。先退回 Markdown 不是反技术，而是把问题缩到我能观察的范围：每次 ingest 改了哪些页面，引用指向哪份原始资料，冲突为何保留，都可以通过 Git diff 检查。

不过，可读不等于正确。LLM 可能在综合时丢掉限定条件、把两份来源拼成不存在的结论，或者一次错误更新污染多个页面。Wiki 页面必须保留来源链接、最后核对时间和不确定性，关键判断还要回到 raw/；自动把每次聊天答案写回也不安全，我只会保存经过复核、确实值得长期保留的内容。

我准备怎样做最小实验#

第一版不搭向量库，只保留下面这些文件：

knowledge-base/
├─ AGENTS.md        # 目录、引用、ingest/query/lint 规则
├─ raw/             # 不可变原始资料
├─ wiki/            # LLM 维护的综合页面
├─ index.md         # 页面目录和一句话说明
└─ log.md           # ingest、query、lint 的追加记录

每张 Wiki 页面至少记录来源、最后更新时间和仍有冲突的结论；摄入新资料时先提交原始文件，再让 Agent 修改 Wiki，这样一次错误综合可以单独回滚。查询先读 index.md，再使用 rg 或本地全文搜索找页面，不把整个仓库一次塞进上下文。lint 只生成待核对清单，不允许在无人复核时批量“修正事实”。如果资料包含私人日志或内部文档，还要先确认所用模型和工具会把数据发送到哪里，Markdown 放在本地并不代表推理过程也留在本地。

为了避免凭感觉宣布成功，我会准备一组代表性问题，覆盖单来源事实、多来源比较、时间变化和找不到答案四类。每次记录是否找全关键来源、引用是否支持结论、回答用了多少上下文、摄入和纠错花了多久。如果文件搜索开始频繁漏召回、index.md 大到 Agent 难以稳定使用，或者查询需要跨大量原始资料找精确片段，再引入 BM25、qmd 或向量检索，而不推倒已有 Wiki。

这个升级路径允许两种结构共存：Wiki 继续保存已经形成的综合理解，检索层负责从 Wiki 和原始资料中找证据。届时增加的不是“另一套知识库”，只是为现有文件补一条更强的查询入口。

最后留下的判断#

LLM Wiki 最吸引我的不是“纯 Markdown”这个形式，而是它把知识库看成一个需要持续维护的产物。原始资料不会自动变成理解，聊天里形成的好答案也不该只能留在会话历史；把综合结果写成可读页面、保留来源并持续修订，确实能产生积累。

它的成本同样真实：每次摄入都要消耗模型调用，错误也可能随着交叉链接一起扩散，团队场景还会遇到权限、并发修改和责任归属。RAG 则继续适合需要大范围动态召回、严格过滤和证据检索的场景。两者不是替代关系，甚至可以是同一系统的写入侧和查询侧。

我这次真正撤掉的是“知识库就该先上 RAG”的默认答案。先量资料、问题和维护能力，用最简单的可读结构跑出真实瓶颈，再为已经出现的召回问题增加检索层；这比先搭完整 pipeline、最后才发现自己没有足够语料和评估问题，更符合我当前的规模。