跳到主要内容

A3.3 Agentic RAG：检索也是工具

300 页的员工手册​

公司给智能体派了个活：回答员工提问「我们的差旅报销上限是多少？」

答案就躺在 300 页的员工手册里。全塞进上下文？且不说塞不塞得下——上一节刚讲过，就算塞得下也不该塞：又贵、又慢、还会「上下文腐烂」。何况手册每月更新，总不能每次改版都重训模型（上篇第 5 章说过，知识进参数要靠训练，成本完全不成比例）。

经典解法就是 RAG（检索增强生成）：先按问题从手册里检索出最相关的几段，塞进上下文，再让模型照着回答。 模型不用背下手册，只要「开卷考试」。

经典 RAG：一条固定流水线​

标准做法四步：

  1. 切块：把手册切成几百字一段的小块；
  2. 向量化：每块算一个向量存进向量库（又是上篇的词向量思想：意思相近、向量相近）;
  3. 检索：用户问题也变成向量，捞出最相似的 top-k 块；
  4. 生成：把这几块拼进上下文，模型据此回答。

注意它的结构：检索固定发生一次、固定在回答之前——用 A0 的话说，这是一条预定义的流水线（下一章会叫它「提示链」），不是智能体。

它便宜、快、大多数时候够用。但三个场景会翻车：

  • 措辞对不上：用户问「出差住宿标准」，手册写的是「差旅费用管理办法」——向量相似度救得了一部分，救不了全部；
  • 答案分散：「报销上限」在第 3 章、「特殊城市加成」在第 7 章附表——检索一次只能捞到一处，答案注定残缺；
  • 来者不拒：检回来的段落不相关，模型也会硬着头皮基于它回答——检索错误顺流而下变成回答错误。

Agentic 升级：把检索交给循环​

三个失灵场景有个共同病根：检索只有一发子弹，打偏了没有补救。

Agentic RAG 的升级思路简单到近乎显然——把检索从「固定的前置步骤」变成模型自主使用的工具（回扣 A1）：搜索工具进工具箱，循环开转（回扣 A0），于是模型可以：

  • 觉得问题措辞不好搜，先改写查询再搜（「出差住宿标准」→「差旅费用 住宿 限额」）；
  • 搜完发现信息不全，再搜一轮（先查到上限，再专门查「特殊城市」）;
  • 对检回内容存疑，交叉核对另一个来源，或者干脆回答「手册里没有明确规定」。

没有任何新机制——只是把检索工具交给了行动循环，查什么、查几轮、信不信，从写死的代码变成了模型的运行时决策（A0.2 光谱上往右挪了一格）。

和长上下文的关系也顺便理清：上一节说窗口有限，本节的 RAG 是「把对的东西放进窗口」，而上篇 8.2 的长上下文是「把窗口做大」。两者互补而非替代——窗口再大，也不该把 300 页手册的原文全款塞入；检索再准，多轮对话的工作记忆也得靠窗口本身。

升级不是免费的

Agentic RAG 更强，也更贵更慢：每多一轮检索决策就多一轮模型调用，简单问题上它和经典 RAG 效果一样、成本翻几倍——又是 A0.2 的老话：能简单就简单。更要紧的是，检索质量仍是地基：模型只能在检回来的内容里挑，库切得烂、索引建得差，再聪明的循环也是「垃圾进垃圾出」——上篇 4.1 数据清洗的教训，在这里换了个马甲重演。

小结​

本节要点
  • RAG = 开卷考试：知识放外部库，按题检索、塞进上下文再回答——知识更新不用动模型。
  • 经典 RAG 是固定流水线，措辞错位、答案分散、来者不拒三处会翻车。
  • Agentic RAG 把检索变成循环里的工具：改写重搜、多轮补搜、交叉核对——更强但更贵。
  • 检索质量是地基：库烂则全烂，聪明的循环救不了糟糕的索引。
📝 动手自测0/3
1. 公司知识每月更新，为什么用 RAG 而不是把知识训进模型参数？
2. 经典 RAG 和 Agentic RAG 的分界线是什么？
3. 「答案分散在手册第 3 章和第 7 章附表两处」，经典 RAG 为什么容易在这种问题上翻车？

延伸阅读​