为什么 LLM Wiki 那么火，MrDoc 还是选择了 RAG

这两年，AI 知识库领域几乎每隔一段时间就会冒出一个新的热门概念。

从早期的向量检索、Embedding，到后来的 Agent、GraphRAG、Agentic RAG，再到最近刷屏的 LLM Wiki，每个一段时间，整个行业都要重新回答同一个问题：

> AI 到底怎样才能真正“理解知识”。

尤其是 LLM Wiki 的出现，让很多人第一次感觉，AI 知识库似乎终于开始摆脱传统 RAG 的限制。

不少此类产品都会强调：

> 不再像传统 RAG 那样，每次提问都临时检索、临时拼接上下文，而是在文档导入阶段，就利用大模型对知识进行理解和 Wiki 化，让系统自动建立知识之间的长期关联。

这个概念之所以会迅速流行，并不是因为它包装得多么新潮，而是因为它确实击中了传统 RAG 最明显的痛点。

在传统 RAG 体系里，AI 更像一个“临时查资料的人”。每次提问，系统都会重新检索相关内容，再把这些片段交给大模型生成答案。即便用户连续询问同一个主题，模型依然像第一次接触这些知识一样，需要重新阅读、重新组织、重新理解。

换言之，传统 RAG 产生的知识往往随用随弃，知识并没有真正沉淀下来。

而 LLM Wiki 想解决的，恰恰就是RAG这个「平时不学习不认真，只会考场翻书找答案」的问题。

它希望在用户提问之前，系统就已经“读懂”了知识库。文档导入之后，大模型会主动分析内容之间的关联关系，自动生成摘要、概念索引、Wiki 链接、主题分类以及文档之间的引用关系，甚至进一步形成一个持续演化的知识网络。

从产品演示的角度来看，这种效果非常惊艳。

AI 不再只是一个“搜索工具”，而开始呈现出一种类似百科系统的结构感。很多时候，你甚至会产生一种错觉：系统似乎真的已经“理解”了整个知识库。

但真正开始工程化落地之后，我们很快发现：

> LLM Wiki的理想很美好，但它对大模型的依赖——无论是能力、成本还是确定性，都远比很多人想象得更高。

这种缺陷，也是 MrDoc 最终依然选择以 RAG 为基础路线的核心原因。

---

# LLM Wiki，本质是在“提前构建认知”

为了理解这个问题，我们需要先看清楚，LLM Wiki 到底在做什么。

传统 RAG 的逻辑非常简单：用户提问之后，系统通过向量检索找到相关 Chunk，再把这些内容拼接到上下文中交给大模型生成答案。整个过程中，大模型只是一次性地“阅读资料”，并不会长期维护知识结构。

而 LLM Wiki 则完全不同。

它把“理解知识”这件事，从查询阶段提前到文档导入阶段。

在文档真正进入知识库之前，LLM Wiki 会先调用大模型对内容进行一次 Wiki化的深度分析，让 AI 提前完成“阅读”和“理解”的过程。这样做的目的，是希望系统后续不再只是依赖临时检索，而是已经拥有了一套长期存在的知识结构。

于是，它会自动提取主题、生成摘要、分析概念之间的关系，并尝试建立文档之间的双向关联。

这已经不是简单的信息检索，这种处理方式更接近于一种“认知构建”。

而问题恰恰也出在这里，因为“认知构建”本身的代价远超想象。

---

# 一旦开始“理解知识”，成本就会指数级上升

很多人第一次接触 LLM Wiki 时，会下意识地把它理解成：

> “比 RAG 更聪明的AI知识库”。

但实际上，两者背后的计算复杂度根本不是一个级别。

传统 RAG 更多是在做“检索”，而 LLM Wiki 做的，是“知识组织”。

这意味着，系统不只是简单判断文本相关性，而是需要进一步理解：哪些概念属于核心主题，哪些内容之间存在上下级关系，哪些文档应该建立关联，哪些只是偶然提及，哪些知识会影响整个 Wiki 网络的结构。

而这些能力，恰恰是当前大模型最昂贵、也最不稳定的部分。

尤其当知识库规模逐渐扩大之后，问题会迅速放大。

因为系统不仅需要更长的上下文窗口，还需要具备更稳定的长链理解能力、多文档关联能力以及结构化输出能力。很多时候，它甚至已经接近于在“提前运行一次大型 Agent”。

于是，一个非常现实的问题就出现了：

> Token 消耗会迅速膨胀。

传统 RAG 的主要成本，大多发生在查询阶段。只有用户真正提问时，系统才会进行检索和生成。

但 LLM Wiki 不一样。

它在文档导入阶段，就已经开始大量消耗 Token。

因为它不仅需要切分 Chunk 和生成 Embedding，还需要阅读全文、分析结构、理解上下文关系、生成摘要、维护 Topic 关联，甚至持续调整整个 Wiki 网络。

尤其在文档更新时，这种成本会进一步扩大。

传统 RAG 更新文档时，很多情况下只需要重新向量化局部 Chunk；而 LLM Wiki 更新的，往往是整个知识关系网络。

例如新增一篇关于《安史之乱中的河北藩镇》的文档，系统理论上就需要重新考虑它与唐朝财政、节度使制度、河北道、藩镇割据以及唐玄宗时期政治结构等主题或相关文档之间的关系。

也就是说，用户只是新增了“一篇文档”，LLM Wiki却对整个知识网络进行一次‘牵一发而动全身’的重构。

这种重构，本质上已经开始接近“自动维护知识图谱”。

---

# 真正危险的，其实不是成本，而是“结构幻觉”

相比 Token 成本，更容易被忽视的问题，其实是结构失真。

因为大模型天然有一种倾向：

> 它会努力把一切内容组织成“看起来合理的结构”。

但问题在于，人类知识本身并不总是结构清晰的。

尤其是历史、人文、社会科学领域，很多内容本来就存在模糊性、争议性以及多种解释路径。很多时候，人类对某个问题的理解，本身就是开放和渐进的。

但大模型并不擅长处理这种“不确定性”。它更倾向于主动建立关系、主动归纳主题、主动形成结构。

于是，一些看似合理的问题就会逐渐出现。

例如错误的文档关联、过度推断的概念关系、虚假的 Wiki 链接，甚至是“看起来非常专业”的结构幻觉。

更麻烦的是，这些错误通常并不容易被察觉。因为它们往往不像普通幻觉那样明显，而是会以一种“逻辑完整”的形式存在。

这也是为什么很多 AI Wiki Demo 在小规模测试时效果惊艳，但真正进入生产环境之后，却容易逐渐出现关系漂移、结构污染以及知识失真的原因。

因为它已经不只是一个检索系统。

它实际上是在尝试：

> 自动维护一个不断演化的知识世界。

而这，本来就是一个极其困难的问题。

---

# 为什么 MrDoc 最终还是选择了 RAG

说到底，MrDoc 的核心定位始终不是“炫技型 AI Demo”，而是一个需要长期稳定运行的知识沉淀系统。

对于MrDoc来说，“稳定”和“确定性”，很多时候其实比“看起来聪明”更加重要。

因为企业知识库最怕的，并不是 AI 回答得不够惊艳。

而是知识关系在长期演化过程中逐渐漂移，文档结构开始被错误污染，最终让整个知识体系变得越来越不可控。

所以在 AI 知识库的设计上，MrDoc 更倾向于：

> 让结构来源于文档本身，而不是完全依赖 LLM 去“幻想结构”。

这也是 Markdown 文档体系一个非常重要的优势。

因为文档天然就已经具备大量确定性结构。

标题层级、文集目录、超链接、标签、引用关系，本身就已经是一种“弱知识图谱”。这些结构并不需要 AI 去猜测，而是天然存在于知识体系之中。

因此，MrDoc 当前更关注的是：

利用 AI 去增强已有结构，而不是让 AI 接管整个结构。

例如自动摘要、关键词提取、FAQ 生成、相关推荐以及结构化检索增强，本质上都是一种“轻量 AI 增强”。

它既能够提升知识库的智能化体验，又不会让整个系统完全建立在大模型的长期稳定性之上。

在我看来，至少现阶段，生成式 AI 更适合“辅助理解”，而不是“完全接管知识结构”。

---

# AI知识库的当下，还不是“全自动Wiki”

LLM Wiki 的方向其实是对的。它的价值在于它开始尝试解决一个更深层的问题：**AI 知识到底如何真正沉淀下来**。

这确实是下一代 AI 知识库的重要方向。

但至少在当前阶段，大模型的能力、成本、稳定性以及实时性，还远不足以支撑一个完全自动化、自演化的 AI Wiki 系统。

因此，比起“完全交给 AI 自动维护知识世界”，更现实的路线或许是：

利用文档自身的确定性结构，再结合适度的 AI 增强能力。

**让 AI 负责理解，让文档负责确定性。**

在现阶段，我们更倾向于让生成式模型作为知识的助手，而非接管整个体系的主宰。