W
AI-Wiki
CONCEPT

RAG

定义

RAG（Retrieval-Augmented Generation，检索增强生成）本义是：在回答问题时，先从外部资料中检索相关内容，再把检索结果拼接进模型上下文，由模型基于这些补充材料生成答案。

但在本文语境中，RAG 不是被当作中性、完整的技术百科定义来展开，而是作为 LLM Wiki Layer 的对照项出现：它代表一种“按次检索、按次读取、按次理解”的工作方式。

在本文档中的语境

本文批评的不是所有 RAG 用法，而是一个特定场景下的使用后果：当用户经常围绕同一批资料反复提问、写作、研究、汇总时，模型每次都要重新读取同样的 PDF、笔记、网页、截图或其他原始材料。

原文对这个问题的描述非常直接：用户其实在“一直重复上传同样的文件”。这意味着模型每次提问都要重新读取、重新理解、重新处理同样内容。同一批资料会被一遍又一遍消费。

本文把这类现象视为 RAG 架构在长期重复协作场景中的根本缺陷之一：它擅长临时把外部材料塞进上下文，却不擅长把已经理解过的内容稳定沉淀为可复用的知识层。

本文对 RAG 的具体批评点

1. 重复读取同一批原始文件，造成重复付费

这里的核心批评不是“检索”本身，而是“反复重读原始资料”。每次问新问题，系统都可能再次把同样的原始文件送进模型上下文。只要资料没变，却仍然按次读取，就会持续产生重复 Token 成本。

原文将其总结为：每次都要为重复读取付费。这也是本文提出 Wiki 层之前的直接动机。

2. Token 消耗高

原文把第一个直接后果写得很明确：Token 疯狂消耗。因为重复读取不是一次性的预处理，而是每次交互都重新发生，所以费用与上下文开销会不断累积。

在本文对照中，LLM Wiki Layer 通过“一次性处理原始资料，再长期复用结构化结果”的方式，试图把这部分消耗前置并摊薄。原文给出的效果数字是：Token 消耗可减少 70% 到 90%。

3. 上下文丢失

本文认为，单纯依赖按次检索的 RAG，很难让模型在多个文件之间建立持久联系。即使某次回答里临时拼进了几段材料，这种联系通常也只存在于那次上下文窗口中，不会自动沉淀为长期可复用结构。

因此，跨文档关系、前后轮次积累、主题之间的稳定连接都容易丢失。原文直接将这一点表述为：模型无法在多个文件之间建立持久联系。

4. 答案质量下降

原文进一步指出，重复处理会导致信息碎片化，重要关系被忽略。也就是说，问题不只是“贵”，还是“答得不稳”。

当系统每次都从零开始切片、检索、拼接，模型更容易只看到局部片段，而不是已经整理好的全局结构；于是答案可能遗漏关键依赖、文档间因果、版本关系或主题脉络，最终表现为答案质量下降。

5. 效率低

本文把最后一个后果归纳为：同样的问题，每次都要从头推理。这不仅拖慢人机协作速度，也会让“持续围绕同一主题工作”的场景变得非常低效。

所以本文对 RAG 的质疑，本质上是对“每次从头开始”的质疑，而不是对检索动作本身的否定。

RAG 与 Wiki 层的关系

本文提出的 LLM Wiki Layer，不是简单把 RAG 整体废弃，而是替代其中“反复读取原始文档”的部分流程。

它的核心转变是：

  • 传统做法更偏向从原始文件中按次检索
  • Wiki 层做法更偏向先把原始文件整理成结构化知识库，再从知识库中检索

也就是说，检索对象发生了变化：从原始文件转向结构化知识库。

在这种模式下，原始资料先被一次性读取、清理、结构化并建立链接；后续大多数问答与生成，都不再直接碰原始文件，而是基于已经维护好的 Wiki 层工作。

因此，RAG 与 LLM Wiki Layer 的关系更适合理解为：

两者并非绝对对立，而是服务于不同时间尺度与知识复用深度。

本文隐含的工作机制对照

结合原文，可把本文中的对照关系概括为两种路径。

路径一：按次 RAG

  1. 用户提出问题
  2. 系统重新从外部资料中找相关内容
  3. 模型再次读取这些原始片段
  4. 在当前上下文中临时生成答案
  5. 会话结束后，理解结果通常不会稳定沉淀

这种路径适合一次性查询，但在同主题反复协作时，会持续重复第 2 到第 4 步。

路径二：先建 Wiki 层，再面向 Wiki 检索

  1. 先一次性处理原始资料
  2. 清理噪声、转换为干净 Markdown、建立 双链 与元数据
  3. 形成持续维护的知识库
  4. 后续交互优先基于该知识库，而不是反复读取原始文件
  5. 新资料到来时做 增量更新，而不是整库重建

在这一路径里，RAG 仍然可以存在，但被检索的主要对象不再是未经整理的原始材料，而是 Wiki 化后的知识层。

细节与边界

本文不是在否定所有 RAG

这是最重要的边界。本文论点只针对一种场景：长期、重复、同主题资料协作。

例如：

  • 你手里有 10 到 20 份以上同一主题文档
  • 这些资料会不断更新或扩展
  • 你会持续生成报告、研究、分析或创意内容
  • 你经常反复围绕同一批资料提问

在这种情况下，按次重读原始文件会显得浪费且不稳定。

反过来说，如果只是临时问一次、资料规模很小、主题并不持续，或者根本没有必要维护长期知识库，那么 RAG 仍然是自然且有效的选择。本文并没有声称 RAG 在所有任务上都错误。

本文批评的是“原始文件反复进入上下文”，不是“检索”这个动作

很多读者容易把论点误解成“不要检索”。其实不是。本文真正提出的是：不要让模型每次都从未经整理的原始资料重新开始。

因此，这里的改进方向不是去掉检索，而是把检索前置到知识整理之后，让检索建立在更干净、更结构化、更有链接关系的知识层之上。

本文强调长期沉淀与增量维护

与一次性按需抓取相比，Wiki 层强调两个特征：