Agentic RAG

给你的知识库问一个问题:“我们去年 Q3 的退款政策,跟今年比有什么变化?” 朴素 RAG 会怎么做?它把这一整句话拿去向量库里查一次,取回 5 个最相似的片段,塞进 prompt,让大模型生成。结果大概率是:它检索到了"今年的退款政策",但没检索到"去年 Q3 的",因为这句话作为一个整体,语义上离"今年的政策文档"更近。于是模型用今年的政策,回答了一个关于"变化"的问题——而且它不会告诉你它只看到了一半。 这就是朴素 RAG 的根本毛病。它把检索当成一个一次性的、无脑的前置步骤:查一次,查到什么算什么,然后生成。它不会判断"我查到的东西够不够",不会发现"这个问题其实要查两次",更不会在检索失败时重来。它失败的时候不会报错,会编。 2026 年,生产环境里真正能扛住复杂问题的,已经不是这条流水线了。这篇讲清楚它怎么一步步长成 Agentic RAG,以及——这是重点——多出来的延迟和成本,什么时候值,什么时候是浪费。 朴素 RAG 到底卡在哪 先把它失败的几类问题说具体,不然后面所有"改进"都是空的。 多跳问题。“写《三体》的作者还写过哪些小说?"——这要先查”《三体》的作者是谁"(刘慈欣),再用这个答案去查"刘慈欣的其他作品"。一次检索拿不到第二跳需要的关键词,因为第二跳的查询词(“刘慈欣”)根本不在原始问题里。 **模糊 / 措辞错位。**用户问"那个会自动重试的配置项叫什么",知识库里写的是"retry_policy 重试策略"。用户的口语和文档的术语对不上,向量相似度也救不回来。 问题里藏着多个子问题。“对比一下 A 方案和 B 方案的成本和上线周期”——这是四个检索意图揉在一句话里,一次检索只会取回一堆"半相关"的片段,哪个都不深。 需要计算或外部数据。“我们这个季度的获客成本环比涨了多少”——答案不在任何一个文档片段里,它需要先取两个数,再算个除法。文本检索给不了。 这些问题的共同点是:正确答案不是"检索一次就能拿到的那 5 个片段"。要么得检索多次,要么得换个查法,要么检索根本不是最后一步。朴素 RAG 的架构里没有"再来一次"这个动作,所以它只能在第一次的结果上硬生成。 演进的主线:从「流水线」到「控制循环」 把朴素 RAG 和 Agentic RAG 摆在一起看,差别不是"加了几个模块",是控制权交给了谁。 朴素 RAG 是一条固定流水线:检索 → 生成,顺序写死,模型只负责最后那步生成,没有决策权。 Agentic RAG 是一个控制循环:大模型坐在中间当指挥,它拿到问题后自己决定下一步干什么——要不要检索、检索什么、查到的东西够不够、要不要换个查询词再来一次、还是已经可以回答了。检索从"前置步骤"变成了模型手里的一个工具,跟计算器、SQL 查询、API 调用平级。 flowchart TB subgraph naive[朴素 RAG:固定流水线] direction LR Q1[问题] --> R1[检索一次] --> G1[生成] --> A1[答案] end subgraph agentic[Agentic RAG:控制循环] direction LR Q2[问题] --> AG{Agent决策} AG -->|要查| R2[检索/改写/计算] R2 --> EV[评估结果够不够?] EV -->|不够| AG EV -->|够了| G2[生成] --> A2[答案] end style AG fill:#fde7c2,stroke:#e8b23c style EV fill:#fde7c2,stroke:#e8b23c 橙色的两块——决策和评估——是朴素 RAG 里完全没有的。整个演进,本质上就是把这两个能力一点点加进来。下面拆成四个阶段讲。 ...