Reference：“无状态"是 RAG 的护栏

Karpathy 最近提了一个很有意思的方案叫 LLM Wiki —— 与其每次查询都重新检索一堆原始资料，不如让 LLM 先把所有文档读一遍，整理成一个结构化的知识库。以后有新文档进来，LLM 自动找出受影响的页面然后更新。查询的时候直接读 wiki，不用再翻原始材料了。

说实话我第一反应是：这不就是我理想中的知识管理吗？干净、有序、能自己生长。比 RAG 那种每次都从头翻文档的"笨办法"优雅太多了。

但仔细想想，这套方案的代价其实挺大的。而且有意思的是，这些代价恰恰是 RAG 那个"笨办法"天然避开的。

错误会滚雪球

RAG 拿给你的是原始文档的片段，你可以自己判断靠不靠谱。LLM Wiki 拿给你的是 LLM 写出来的东西——它理解错了、漏了关键信息、过度压缩导致失真，这些偏差会直接变成 wiki 里的"事实”。

更要命的是，错误会繁殖。LLM 处理第 15 篇论文的时候，参考了第 3 篇的摘要，而那个摘要本身就有偏差。基于偏差做了交叉引用，错误没被修正反而被放大了。后面所有查询都在这个有问题的基底上回答，lint 检查也是——lint 本身也是 LLM 跑的，它在有偏差的 wiki 上做检查，能查出什么？

这让我想到一个词：有状态的错误传播。一旦错误进入系统，它不是静止的，它会沿着依赖链扩散，而且你很难定位是哪个环节出了问题。

RAG 之所以没有这个问题，恰恰因为它每次都从源头重新来——上一次的错不会留给下一次。我们一直说 RAG"无状态"是局限，但换个角度看，这是道护栏。

写入成本膨胀

Karpathy 估算一篇新文档可能涉及 10-15 个 wiki 页面。听起来不多，但跑一下流程就知道了：LLM 先读完整篇新文档，再翻 index.md 找相关页面，然后读这十几页的内容判断怎么改，最后逐个重写。一篇文档的摄入就是几万到十几万 token。

更关键的是，这个成本不是恒定的。wiki 页面越来越多、越来越长，摄入第 101 篇时 LLM 要读的上下文比第 1 篇大得多。而 RAG 的摄入成本基本是恒定的——切分、embedding，完事，知识库再大也不会越来越贵。

两种模式的成本节奏也完全不同：RAG 是查询时花钱，按次付费；LLM Wiki 是写入时花钱，而且账单随规模往上走。对于查询量不大但资料持续涌入的场景，这个成本结构很致命。

分布式一致性的老问题

当 wiki 到了 200 个页面，一个新事实进来，LLM 怎么确保找全了所有该更新的地方？没法确保。更新了 mixture-of-experts.md 忘了改 training-cost-comparison.md，两个页面矛盾了，你大概率要碰巧都读到才能发现。

这本质上是分布式系统的一致性问题——只不过节点换成了 Markdown 文件。CAP 定理 告诉我们这类问题没有银弹，交给 LLM 来扛，说实话我不太放心。

审计也是。RAG 能清楚告诉你答案来自哪几个 chunk，鼠标一点就能核对。LLM Wiki 呢？一个结论在第 5、12、18、23 次摄入时被改过，每次都是 LLM 当时理解的产物，原始信息在多次"传话"后溯源链早就断了。除非你给 wiki 上 git 版本控制并且每次 diff 审查——但真这么干，省下来的精力又贴回去了。

还有冷启动。开头最痛苦——你不知道该定什么结构，LLM 也不知道。如果方向错了，前几十篇的产物可能得推倒重来。后续理解深入了发现分类方式有问题要大规模重组，这跟代码重构一样疼，但这次是让 LLM 来重构，你对结果没有完全的把握。

适用场景较窄

LLM Wiki 最适合的其实是 Karpathy 自己的场景——个人研究笔记，几十到一两百篇材料，容错率高，错了也没什么大不了。结构化、知识密度高的内容（论文、技术报告）也还行。

但现实中大量场景不太适合：会议纪要和对话记录信息密度低、上下文咬合紧，拆成独立页面很勉强；代码仓库变化太快 wiki 追不上；法律合规文档一个字都不能动，摘要就有遗漏风险；实时数据根本没有"编译"的时间窗口。

写在最后

RAG 的"无状态"不是缺陷，是护城河。它保证了每一轮问答都能回溯到原始材料，不会把 LLM 的理解偏差一层层叠加上去。

但这不代表只能二选一。更务实的路线是把 LLM Wiki 定位成缓存层和知识导航——用它建立高层知识地图，帮你快速定位该看的范围，真正作答时还是回到原始文档做最终核验。

编译是为了提速和导航，不是为了取代信源。