LLM Wiki 很优雅，但它替代不了 RAG

Karpathy 最近发了一个 gist，描述了一种叫「LLM Wiki」的知识管理模式。核心思路：不再让 LLM 每次查询时从零检索拼凑答案，而是让它充当编辑，持续维护一个结构化的 markdown wiki。

Twitter 上照例炸了。「RAG 已死」的声音又来了一波。有人开始讨论怎么把这个方案搬进企业知识库。

我想说：这个方案确实精妙。我自己的个人站 ziut.cn 用的几乎是一模一样的架构。但如果你准备拿它替代企业级 RAG——请先读完这篇文章。

先说好的：这个架构为什么值得认真对待

传统 RAG 的核心问题不是检索不准。是没有持久的综合层。

每次查询，LLM 都在从零开始拼凑答案。今天问和明天问，即使检索到完全相同的文档片段，综合结果可能完全不同。知识没有积累，理解没有沉淀，每次都是即兴表演。

Karpathy 的方案翻转了这个模型。LLM 不再是查询时的「临时工」，而是 ingest 时的「编辑」——读完原始材料后，主动更新 wiki 里的实体页面、概念页面、综述页面，维护交叉引用，标注矛盾。

三层架构很干净：

Raw Sources — 不可变的原始材料，你的 source of truth
Wiki — LLM 维护的编译层，所有综合都在这里
Schema — 操作规范，你和 LLM 共同演化的「编辑指南」

最精妙的洞察是：知识管理中真正让人放弃的不是阅读和思考，而是 bookkeeping。 更新交叉引用、保持摘要一致、标注新旧矛盾——这些苦力活恰好是 LLM 最擅长的。人类做编辑会累、会忘、会偷懒。LLM 不会。

这让我想到 Vannevar Bush 1945 年的 Memex 构想——一个私人的、主动策展的知识库，文档间的关联和文档本身一样有价值。他没解决的问题是谁来做维护。八十年后，LLM 补上了这最后一块拼图。

我在个人站上用的几乎是同一套

我的个人站 ziut.cn 在 Karpathy 发这个 gist 之前就在跑几乎一样的架构。

具体来说：原始素材（文章、研究笔记、行业报告）存在本地 Obsidian vault 里，不可变。所有面向读者的内容——博文、资源页、主题页——由 LLM 基于这些素材生成和维护。每次有新内容加入，相关页面会被级联更新。交叉引用是自动的，一致性由 LLM 在每次编辑时负责维护。

这套方案在个人规模下效果极好。我管理几十篇深度博文和上百个知识节点，从来不需要手动维护交叉引用。LLM 做这种 bookkeeping 确实比人靠谱——它不会忘记更新某个页面，不会因为懒而跳过某个交叉链接。

但正是因为我自己在用，我才清楚它的边界在哪。

五个结构性挑战：不是工程问题，是架构约束

最近看到不少讨论要用 LLM Wiki 替代企业级 RAG。对这种思路，我有五个结构性的担忧。

请注意：这些不是「加点代码就能解决」的工程问题，而是架构层面的根本约束。

1. 幻觉从感冒变成了慢性病

这是最反直觉的一点。直觉上「wiki 有持久化、有交叉引用，应该更准」。事实恰恰相反。

RAG 的幻觉是随机噪声。这次查询幻觉了，下次检索到不同的 chunk，可能就对了。幻觉不会沉淀，不会传染，是一次性的。

LLM Wiki 的幻觉是系统性偏差。一旦 LLM 在某次 ingest 时产生幻觉，这个错误被「编译」进 wiki 页面，成为持久化的「知识」。然后通过交叉引用网络，一个错误级联扩散：

一篇论文说「药物 A 在特定条件下可能有效」，LLM 错误编译成「药物 A 有效」。接下来：

药物A.md 写入了「有效」
疾病X.md 级联更新：「药物 A 是治疗选项之一」
药物对比.md 对比表里药物 A 标为有效
治疗指南综述.md 引用了上述所有页面

一个点状错误，通过交叉引用变成了面状的。每经过一层引用，离原始 source 就远一步，溯源就难一分。

RAG 的幻觉像感冒——不舒服但自限性的。LLM Wiki 的幻觉像慢性病——一旦写入就持续影响，而且会扩散。

更微妙的是「权威性洗白」效应。LLM 查询 wiki 时，读到的是格式工整、交叉引用完备的页面——但这些是它自己之前写的。LLM 对自己生成内容的质疑阈值天然偏低。人类读者也有同样的问题：一个有目录、有链接的 wiki 页面看起来比一堆原始 PDF 更可信，但它的底层可能建立在层层失真之上。

2. 规模天花板不是工程问题

Karpathy 说 ~100 个 source、几百页 wiki 时靠 index.md 就够用。需要更大？加搜索引擎。

但真正的瓶颈不在搜索，在 ingest 的复杂度随 wiki 规模超线性增长。

每次 ingest 新 source，LLM 需要找到所有相关页面、读它们、更新它们、确保更新后的页面之间仍然一致。最后这步是隐藏炸弹——更新了 A 页面后，要确保它和引用 A 的 B、C、D 页面说法一致。B、C、D 之间可能也互相引用。

问题在于 context window 是固定的：

wiki 50 页 → 所有相关页面都能装进 context → 一致性有保障
wiki 300 页 → 部分相关页面要分批处理 → 一致性开始降级
wiki 1000 页 → 大量互相依赖的页面无法同时在 context 里 → 一致性无法保证

「预编译全量综合」这个核心优势本身有规模上限。 超过这个规模，你要么放弃全量级联更新（退化回延迟综合，本质就是 RAG），要么接受日益增长的不一致性。

企业知识库动辄几万到几十万篇文档。这不是甜蜜点，这是悬崖。

3. 语义漂移：比幻觉更隐蔽的定时炸弹

幻觉好歹能被检测到——某个页面写错了，lint 或人工可以发现。

语义漂移是没有任何单个页面是错的，但整体不一致。这比幻觉更难被发现。

LLM 没有跨 session 的记忆。每次 ingest 时的「理解框架」取决于当次 context 里装了哪些页面、prompt 的微妙差异、模型的随机性。

第一周 ingest，LLM 把某个定价策略描述为「premium positioning」。第三周换了一批 context 页面，同样的概念变成了「value-based pricing」。第五周又变成「高端市场策略」。

三个说法都不算错。但 wiki 里对同一件事有三种不同的描述方式。交叉引用、对比表、综述页——到处都是这种微妙不一致。

Schema 能约束格式和流程（「每个实体页面要有 summary 段落」），但很难约束语义表达的一致性。除非你把 schema 写成一本术语词典——但那本身就是一个需要维护的知识工件，循环依赖了。

4. 成本结构根本不同

这不是「谁更贵」的问题，而是钱花在什么时候。

LLM Wiki 是前端重——每次 ingest 一篇 source，LLM 要读写多个页面，token 消耗 $0.50-2.00。RAG 是后端重——ingest 只是做 embedding，几分钱；每次 query 才消耗 token。

如果你的场景是「积累知识后反复查阅」——LLM Wiki 划算，ingest 成本被大量 query 摊薄。

如果你的场景是「大量文档持续灌入，偶尔查询」——这恰恰是大多数企业知识库的模式——LLM Wiki 的经济性远不如 RAG。

更关键的是，LLM Wiki 没有降级空间。用便宜模型做 ingest，综合质量直接崩溃——因为 wiki 的价值就建立在综合质量上。RAG 可以用便宜模型做 embedding、贵模型做 query，成本和质量可以分层优化。这个灵活性在企业场景里至关重要。

5. 多人协作不是「还没做」，是核心假设不支持

LLM Wiki 的架构假设是单一策展人 + 单一编辑。这不是遗漏，是设计前提。

多人场景下，这个假设直接崩塌：

意图冲突。 Alice ingest 一篇文章，让 LLM 着重提取技术架构。Bob ingest 同领域的文章，让 LLM 着重商业模式。wiki 里同一个 entity 的页面，变成了两种视角的缝合怪。

Schema 所有权。 Schema 是「你和 LLM 共同演化的操作规范」。两个人对 wiki 结构的想法不同怎么办？没有治理机制。

并发语义冲突。 两个人同时 ingest 不同 source，两个 LLM session 同时更新同一个 wiki 页面。Git 能解决文本冲突，但解决不了知识冲突。

Wikipedia 花了 20 年建立了 talk pages、编辑方针、管理员层级、争议解决流程。LLM Wiki 的设计里没有这些。这不是加个 feature 能解决的——这需要从根本上改变架构假设。

所以我把它开源了：Accrete LLM Wiki

分析完这五个结构性约束，一个自然的问题是：那 LLM Wiki 在它的甜蜜点里，能不能做得更好？

我整理成了一个开源项目：Accrete LLM Wiki。

Accrete 的设计思路不是「解决上面五个问题然后替代 RAG」——而是在承认这些约束的前提下，把 LLM Wiki 模式做到工程上可用：

Lint 健康检查——定期扫描 wiki，检测幻觉级联和语义漂移。不能根治，但能早发现、早修正
多 LLM 适配——支持 Claude、GPT、通义千问、DeepSeek、Ollama 本地模型，不同环节选不同模型，成本和质量可以分层优化
多租户隔离——即使不是企业级 RAG 替代品，也能在小团队规模下安全共用
Docker 一键部署——docker compose up，跳过从零搭建的阶段，直接开始积累知识

如果你的场景落在甜蜜点里——个人研究、小团队知识库、读多写少——Accrete 可以帮你把 LLM Wiki 的优雅从概念变成日常工具。

顺便一提，Accrete 本身就是用 AI Agent 多角色协作开发的——产品设计、架构、TDD、代码审查、安全扫描全部由 Agent 流水线完成。这套开发框架我也开源了：az-delivery-team。

知道工具的边界，比知道工具的能力更重要

LLM Wiki 是一个 elegantly scoped 的方案。Karpathy 把它定位为个人知识管理，不是因为视野不够——而是他清楚这个架构的边界在哪。

它的甜蜜点：

个人深度研究（论文、竞品分析、写书）
长期知识积累（健康追踪、自我提升、读书笔记）
小规模、单人、读多写少的场景

在这些场景下，它比 RAG 好一个量级。我自己在用，效果很好。

但企业知识库需要的是：大规模文档处理、多人并发、严格的准确性、成本可控。这些恰恰是 LLM Wiki 的结构性短板——不是今天做不到明天能优化的工程问题，而是架构设计本身决定的约束。