Agentic RAG 实战：让 Agent 自己决定怎么检索、检索几次

个人主页 for_ever_love__ 欢迎各位大佬莅临其他栏目: 大模型开发从0到1 其他栏目: iOS项目总结大全 其他栏目: 我想学python了 其他栏目: iOS UI 文章目录Agentic RAG 实战让 Agent 自己决定怎么检索、检索几次一、从流水线到循环范式差异二、最小实现一个带工具的检索 Agent三、工具设计检索能力的拆法四、三个最容易翻车的地方4.1 无限循环与重复检索4.2 检索结果不可控地撑爆上下文4.3 幻觉引用五、评估Agentic RAG 怎么测六、渐进落地路线七、落地检查清单八、小结Agentic RAG 实战让 Agent 自己决定怎么检索、检索几次传统 RAG 是一条流水线查询 → 检索 → 拼 prompt → 生成一步都不能少、一步都不会多。现实里的问题可没这么规矩“对比 A 和 B 的优缺点再结合去年财报下结论”——这种查询需要先查 A、再查 B、发现财报数字不够再补一轮、最后综合。流水线结构答不了它Agentic RAG 可以把检索从固定步骤变成 Agent 的可选动作由模型自己决定检索什么、检索几次、什么时候收手。这篇文章讲透它和传统 RAG 的边界、怎么搭、以及最容易翻车的三个地方。一、从流水线到循环范式差异把两种结构并排放一眼看懂传统 RAG固定管线 用户问题 → 检索一次 → prompt 组装 → LLM 生成 → 答案 ↑ 无论问题难易都是这一步一次检索 Agentic RAG控制循环 用户问题 → Agent 主循环 ├─ 思考我现在缺什么信息 ├─ 行动调检索工具关键词/向量/时间过滤… ├─ 观察拿到结果够了吗 └─ 循环 或 生成最终答案核心差异不是用了 Agent这个形式而是三个控制权转移控制权传统 RAGAgentic RAG检索什么用户原始查询Agent 改写后的子查询检索几次固定一次动态视信息缺口而定何时停检索完就生成Agent 判断信息够了才生成什么时候需要 Agentic RAG问题本身是复合的多实体、多步骤、答案需要迭代收敛先粗后细、或者查询意图一开始不明确要拆解。简单事实查询用 Agentic 是杀鸡用牛刀——还更贵更慢。二、最小实现一个带工具的检索 Agent用 OpenAI Function Calling 搭一个最小可用版本fromopenaiimportOpenAI clientOpenAI()TOOLS[{type:function,function:{name:search_docs,description:在企业知识库中检索相关文档。输入具体查询词返回相关段落,parameters:{type:object,properties:{query:{type:string,description:检索查询词},year:{type:integer,description:限定年份可选},},required:[query]}}}]defagent_answer(question,max_steps5):messages[{role:system,content:你是知识库问答助手。 规则 1. 先用 search_docs 查最关键的实体不要一次查太宽 2. 每轮观察结果缺什么补什么不要重复查同样的内容 3. 信息够了直接给答案答案必须标注引用来源 4. 最多查 %d 次超了就基于已有信息作答%max_steps},{role:user,content:question}]forstepinrange(max_steps):respclient.chat.completions.create(modelgpt-4o,messagesmessages,toolsTOOLS,tool_choiceauto)msgresp.choices[0].message messages.append(msg)ifnotmsg.tool_calls:returnmsg.content# 没有工具调用 给出最终答案fortcinmsg.tool_calls:iftc.function.namesearch_docs:argsjson.loads(tc.function.arguments)resultsrag_search(args[query],yearargs.get(year))messages.append({role:tool,tool_call_id:tc.id,content:format_results(results)})return已达最大检索步数基于已有信息作答...跑起来的行为链用户对比 A、B 两家公司 2026 年的营收增速并分析原因 Step1: search_docs(A公司 2026 营收) Step2: search_docs(B公司 2026 营收) Step3: search_docs(A公司 增长 原因 新产品) Step4: search_docs(B公司 增长 放缓 竞争) Step5: 信息够了生成答案带四段引用五个工具调用全部由模型自己发起查询词也是自己改写的。这就是 Agentic RAG 的最小形态。三、工具设计检索能力的拆法Agent 的能力上限 工具集的质量。检索工具拆分的原则是和用户问题的常见维度对齐而不是把整个检索系统塞一个工具里工具职责适用维度search_semantic向量语义检索概念、主题类查询search_keywordBM25 精确匹配型号、代码、专有名词search_structuredSQL/元数据过滤时间、部门、类型带明确约束的查询get_document按 ID 取全文/章节二次深挖看全上下文search_graph图谱关系查询多跳关系问题关键设计工具描述description就是 Agent 的路由指南。写得含糊Agent 就乱选写清楚什么时候用这个准确率立刻上一个台阶。比如# 差 description: 检索文档 # 好 description: 对知识库做语义相似度检索返回最相关的 5 个段落。 适合概念性、描述性问题。不要用它查精确的型号/编号/代码—— 那些请用 search_keyword。返回格式为带 [1][2] 编号的段落列表。**再强调一遍工具描述不是文档是 prompt 工程。**每个工具的参数、返回格式、适用边界、不适用场景都要写在 description 里。四、三个最容易翻车的地方4.1 无限循环与重复检索Agent 抽风的表现反复搜同一个词、或者在信息不够的错觉里出不来。必须有硬性护栏MAX_STEPS5# 最多工具调用轮数MAX_SAME_QUERY2# 同一查询词最多出现 2 次超限后强制进入生成prompt 里注明已达步数上限基于现有信息作答。护栏不是限制能力是防止一次故障烧掉几百次 API 调用。4.2 检索结果不可控地撑爆上下文Agent 循环 5 轮、每轮 5 个 chunk、每 chunk 500 字 一万多字塞进上下文token 费用爆炸而且生成质量反而下降。控制手段单轮结果限量每轮最多 3~5 个 chunk宁可多轮结果压缩工具返回的不是全文是编号 摘要一两百字Agent 要深挖再调get_document取全文历史结果滑窗超过 N 轮的旧结果压缩成一句总结原文丢掉token 预算硬顶上下文接近上限时强制收尾。4.3 幻觉引用Agentic RAG 的引用标注比传统 RAG 更容易出错——模型在多轮交织的信息里可能把 [1] 的结论安到 [3] 头上。缓解引用强制格式生成规则每个论断后用 [n] 标注来源n 必须是本轮或历史工具返回中出现过的编号不许编造生成后校验用一个小模型/规则校验答案里每个 [n] 编号是否真实存在于本轮上下文不存在的标红丢弃记离线评估专门构造多轮检索后引用准确性的测试集这是 Agentic RAG 的专属评估维度传统 RAG 用不到。五、评估Agentic RAG 怎么测传统 RAG 的评估集问题 → 文档 → 答案不够用了Agentic 要测四个维度维度指标怎么测答案质量正确率/人工评分和传统 RAG 共用测试集检索效率平均步数、重复检索率日志统计4 步内答对是优秀引用准确性[n] 编号有效率程序化校验成本单次问答 token 消耗和传统 RAG 对比必须回答的问题Agentic 比传统 RAG 好在哪拿测试集跑两版对比——如果 Agentic 在简单问题上没有优势大概率事件、在复合问题上有明显优势预期事件才值得上线。为了先进而先进地上 Agentic是用五倍成本换一成提升还引入不可控风险。六、渐进落地路线别一上来全量 Agentic三步走影子模式Agentic 和传统 RAG 并行跑人工对比答案——只读不写零风险分类启用简单问题走传统 RAG快且便宜复合问题多实体/多步骤/对比类才走 Agentic——查询路由器分流成本收益比最优全量 监控稳定后放开监控步数分布、引用准确率、单次成本异常回退。路由器的实现可以很简单问题长度/实体个数/关键词规则也可以训练分类模型——从规则起步数据攒够了再升级。七、落地检查清单工具集按查询维度拆分每个工具的 description 写清适用/不适用场景护栏三件套MAX_STEPS、重复查询上限、token 预算硬顶工具返回用编号 摘要模式全文深挖走独立工具引用编号存在性程序化校验四维评估集答案/步数/引用/成本上线前跑一遍查询路由器分流简单问题到传统 RAG影子模式先行日志分析步数分布再全量。八、小结Agentic RAG 的三句话本质是把检索从固定步骤变成 Agent 的可选动作——检索什么、几次、何时停三个控制权从管线转移给模型工具描述就是 prompt 工程工具拆分对齐查询维度写好 description 比换模型收益大护栏-first步数上限、重复查询限制、token 预算、引用校验——没有这四样一次 Agent 抽风就是一次成本事故。上线前先跑影子模式用四维评估证明收益再全量。下一篇讲检索工具化的封装怎么把内部数据源ES、SQL、Confluence包装成 Agent 能调用的统一检索接口。