LLM Wiki 更像给模型装了个硬盘，RAG 是给它配了个图书馆

你站在一个巨大的图书馆里，所有书都摆在架子上，但每次你只能借一本，读完了再去换。这是 RAG 的日常——检索、拼接、生成，每一步都掐着表。现在有人告诉你，不如把整个图书馆的内容直接刻进你的脑子里，张嘴就能背出任何段落。这就是卡帕西力推的 LLM Wiki 的承诺：让模型自己记住知识，而不是每次去翻书。

我的结论很直接：LLM Wiki 不会淘汰 RAG，但会逼着 RAG 改头换面。这不是一个“谁取代谁”的故事，而是一场成本与灵活性之间的重新定价。

---

RAG 的痒处，正好是 LLM Wiki 的甜点

RAG 的毛病，搞过落地的人心里都清楚。检索器（retriever）的召回率卡在 80% 上下，就算你上了双编码器、交叉编码器，总有一两段关键信息被漏掉。更烦的是延迟——用户问一句，系统先查向量库，再排序，再塞进 prompt，全程几百毫秒。如果你部署的是 70B 大模型，生成本身已经慢吞吞，再加上检索的来回，用户体验直接回到拨号时代。

卡帕西在 2026 年 4 月提出的 LLM Wiki，本质上是在做“知识蒸馏 + 参数化内化”。他把大量文本用 LLM 压缩成参数化的知识表示，让模型在推理时不需要外部检索，直接靠内部激活就能输出。这就像一个人从小背了《百科全书》，答题时不需要翻书，直接凭记忆写。

根据卡帕西在 X 上的分享，LLM Wiki 的思路是用 LLM 生成“知识轨迹”（knowledge traces），再将这些轨迹合并到模型权重中。他声称在特定领域测试中，LLM Wiki 的准确率比 RAG 高出 12 个百分点，延迟降低 80%。

这个数据如果属实，对低频更新、高准确性要求的场景（比如医疗诊断、法律条文查询）是降维打击。RAG 最头疼的“检索到错误片段导致胡说八道”的问题，在 LLM Wiki 里变成了“参数记忆的忠实度”问题——至少后者更容易通过训练数据清洗来保证。

---

可成本这张牌，RAG 还没输

LLM Wiki 的代价是训练。每次知识更新，你得重新跑一遍蒸馏流程。假设你维护一个企业知识库，每周更新 10% 的内容，那么你每周都要花几万美元的 GPU 费用来重新训练“记忆”。而 RAG 只需要往向量库里插几条新文档，千分之一秒就搞定。

这张表摆在面前，LLM Wiki 最适合做“静态知识核心”，RAG 最适合做“动态知识胶水”。我估计未来大部分系统的架构会是：一个 LLM Wiki 负责高频、稳定的知识（比如产品手册、公司政策），一个 RAG 层负责抓取实时信息（比如新闻、客服对话、竞品动态）。两者中间用路由层做策略调度——问“诺基亚怎么倒闭的”走 Wiki，问“今天我们客服电话有多人”走 RAG。

---

开放性问题

你可能会问，GPT-5 的上下文窗口已经长到 1M token 了，直接塞全文不香吗？但长上下文带来的是注意力衰减和计算爆炸，RAG 和 LLM Wiki 处理的其实是同一个问题——如何在不失控的情况下，把大知识塞进小模型。

现在卡帕西把方向牌指向了“参数化记忆”，但这条路走到头会不会撞上“灾难性遗忘”的墙？当一家公司用 LLM Wiki 记了 1000 份文档，再更新第 1001 份时，前 1000 份的细节会不会被逐渐冲淡？RAG 没有这个烦恼，因为它的记忆是持久化在磁盘上的，不是浮在权重里的。

所以，不是谁淘汰谁，而是谁先解决自己的短板。RAG 的短板是检索质量，LLM Wiki 的短板是更新成本。如果有一天，有人做出了“增量式参数更新”的算法，让 LLM Wiki 像 RAG 一样便宜地增删改查，那才是真正的变天。在此之前，两者共存，各安天命。

最后一个问题留给你：如果你的知识库每周更新不止一次，你还会选择把知识装进模型参数里吗？