尧图网站建设 
1. 从“检索增强”到“智能体驱动”RAG 的范式转移1.1 为什么传统 RAG 开始不够用了做过 RAG 项目的人大概都有过这种体验搭一个“向量库 相似度检索 大模型生成”的流水线第一天跑 demo 效果惊艳第二天接入真实业务数据就开始翻车。用户问“上季度华东区退货率最高的三个品类是什么”系统检索回来一堆包含“退货”“华东”“品类”字样的文档片段但没有任何一段能直接回答这个问题——因为答案需要跨文档聚合、需要按时间过滤、需要做数值排序而传统 RAG 的“一次检索、一次生成”根本扛不住这种复合型查询。这就是最近大家反复提到的rag瓶颈。瓶颈不在向量检索本身而在于整条链路缺少“思考”的环节。传统 RAG 把用户 query 当成一个静态字符串直接丢给 embedding 模型去匹配既没有理解 query 的真实意图也没有判断检索回来的证据是否充分更没有在证据不足时主动发起第二轮检索。它本质上是一个开环系统没有反馈、没有规划、没有自我修正。我自己的判断是RAG 正在经历从“检索管道”到“智能体”的范式转移。Agentic RAG这个词听起来新但拆开看就是三件事——查询分析搞懂用户到底要什么、任务规划把复杂问题拆成可执行的检索步骤、证据控制判断检索结果够不够、对不对、要不要再查。这三件事串起来才构成一个闭环的、有自主性的检索增强系统。1.2 这套东西适合谁、解决什么问题如果你正在做企业知识库问答、客服工单辅助、合同条款检索、技术文档助手这类场景并且已经踩过“检索不准、答案不全、多跳问题答不了”的坑那这套思路就是给你准备的。它不要求你推翻现有的向量库和 embedding 方案而是在检索和生成之间插入一个“智能体层”用 LLM 的推理能力去调度检索行为。适合的读者包括有一定 RAG 实战经验、想突破效果天花板的工程师正在做知识库产品、需要处理复杂查询的产品经理以及想理解 Agentic RAG 到底和普通 RAG 差在哪里的技术决策者。小白也能看但最好先跑通过一个最基础的 RAG demo否则有些痛点你感受不深。下面我会按“查询分析 → 任务规划 → 证据控制”这条主线把每个环节的原理、实现细节、踩坑经验拆开讲最后给一个可复现的 Agentic RAG 最小实现框架。2. 查询分析把“人话”翻译成“检索指令”2.1 查询分析到底在分析什么很多人以为查询分析就是“改写 query”其实远不止。一个完整的查询分析模块至少要输出四类信息意图类型是事实查询、比较、聚合、还是多跳推理、关键实体人名、产品名、时间、地区、约束条件时间范围、数据来源、格式要求、检索策略建议该用向量检索、关键词检索、还是结构化查询。举个例子用户问“对比一下 RAG 和微调在客服场景下的成本”。这句话里意图是“比较”实体是“RAG”“微调”“客服场景”约束是“成本维度”检索策略建议是“需要分别检索 RAG 成本相关文档和微调成本相关文档然后做对比”。如果直接把原句丢给向量库大概率检索回来的是一堆同时提到 RAG 和微调的泛泛文章而不是分别针对两者成本的细节。我通常的做法是让 LLM 输出一个结构化的 JSON包含上述字段。这里有个经验不要让 LLM 自由发挥写改写后的 query而是让它填一个固定 schema。自由发挥的改写往往不稳定今天改写成这样明天改写成那样下游检索逻辑没法复用。固定 schema 的好处是可测试、可缓存、可监控。# 查询分析输出的 schema 示例 { intent: comparison, entities: [RAG, 微调, 客服场景], constraints: {dimension: 成本, time_range: null}, sub_queries: [ RAG 在客服场景的成本构成, 微调在客服场景的成本构成 ], retrieval_strategy: multi_query_vector }2.2 查询改写与扩展的实操技巧查询分析里最实用的两个操作是改写和扩展。改写解决“用户用词和文档用词不一致”的问题比如用户说“怎么退钱”文档里写的是“退款流程”扩展解决“单一 query 覆盖不全”的问题比如把“RAG 瓶颈”扩展成“RAG 检索精度瓶颈”“RAG 多跳推理瓶颈”“RAG 上下文长度瓶颈”。我实测下来HyDE假设性文档嵌入在中文场景下效果不稳定因为让 LLM 凭空生成一段“假设的答案文档”再去做向量匹配生成的文档质量参差不齐反而引入噪声。更稳的做法是多查询扩展让 LLM 基于原 query 生成 3 到 5 个不同角度的子查询分别检索后做结果融合。融合策略我一般用 RRF倒数排名融合简单有效不需要调参。注意查询扩展不是越多越好。我试过生成 10 个子查询结果检索延迟翻了 4 倍召回率只提升了不到 3 个百分点。3 到 5 个是性价比最高的区间具体数量可以根据你的延迟预算调整。还有一个容易被忽略的点查询分析本身也要做缓存。很多业务场景下用户问的问题是高度重复的比如“怎么开发票”“退货政策是什么”。把查询分析的结果按 query 哈希缓存起来命中率能到 30% 以上直接省掉一次 LLM 调用。2.3 查询分析环节的常见坑第一个坑是过度分析。有些团队把查询分析做成了一个小型 NLP 流水线意图分类、实体识别、依存句法分析全上结果延迟爆炸效果还不如直接让 LLM 一次性输出结构化结果。我的建议是能用一次 LLM 调用解决的不要拆成多个模型串联。第二个坑是忽略查询的时效性。用户问“最新的 RAG 框架有哪些”这里的“最新”是个强约束但很多查询分析模块不提取时间信息导致检索回来的都是两年前的旧文章。解决办法是在 schema 里加一个time_sensitivity字段高时效性的查询走“时间过滤 向量检索”的混合策略。第三个坑是多语言混合查询。中文用户经常在 query 里夹杂英文术语比如“RAG 的 retriever 怎么选”。如果 embedding 模型对中英混合支持不好检索效果会明显下降。实测下来用支持多语言的 embedding 模型比如 BGE-M3比用纯中文模型效果好很多虽然向量维度高了、存储成本上去了但召回率的提升值得这个代价。3. 任务规划让 RAG 学会“分步走”3.1 什么查询需要任务规划不是所有查询都需要规划。简单的事实查询比如“RAG 的全称是什么”一次检索就够了硬加规划反而增加延迟。真正需要任务规划的是这三类多跳查询答案需要多个文档串联、聚合查询需要对多个结果做统计或排序、条件查询带复杂过滤条件的检索。判断标准很简单如果一个问题需要“先查 A再根据 A 的结果查 B”那它就需要规划。比如“OpenAI 的 CEO 在哪个大学读的本科”第一步查“OpenAI CEO 是谁”第二步查“这个人的本科院校”。传统 RAG 把整个问题丢给向量库检索回来的大概率是同时提到 OpenAI 和大学的泛泛文章而不是精确答案。任务规划的核心思路是让 LLM 把复杂 query 拆成一个有向无环图DAG每个节点是一个子任务边表示依赖关系。然后按拓扑顺序执行前一个节点的输出作为后一个节点的输入。3.2 规划器的实现方式对比目前主流的规划器实现有三种ReAct 风格边想边做、Plan-and-Execute 风格先规划再执行、混合风格先粗规划执行中动态调整。ReAct 的优点是灵活每一步都能根据上一步的结果调整方向缺点是 LLM 调用次数多延迟高而且容易陷入循环。Plan-and-Execute 的优点是规划一次、执行多次延迟可控缺点是规划时看不到中间结果遇到意外情况没法调整。混合风格是我目前最推荐的先让 LLM 生成一个粗粒度的计划3 到 5 步执行过程中如果某一步的检索结果置信度低于阈值再触发一次局部重规划。# 任务规划的 DAG 示例 { nodes: [ {id: n1, task: 检索 OpenAI CEO 姓名, type: retrieval}, {id: n2, task: 检索 {n1.result} 的本科院校, type: retrieval, depends_on: [n1]}, {id: n3, task: 生成最终答案, type: generation, depends_on: [n2]} ] }这里有个关键细节节点之间的参数传递要用占位符比如{n1.result}执行时动态替换。不要让 LLM 在规划阶段就猜出中间结果那样规划就变成了“幻觉生成”。3.3 规划粒度的权衡规划粒度太粗比如只规划“检索 → 生成”两步那和传统 RAG 没区别规划粒度太细比如把“检索”拆成“生成检索词 → 调用向量库 → 过滤结果 → 重排序”那 LLM 调用次数会多到不可接受。我的经验值是每个子任务对应一次工具调用。检索是一个工具生成是一个工具结构化查询是一个工具。规划器只负责决定“调用哪些工具、按什么顺序调用”不负责决定工具内部的实现细节。这样既保证了灵活性又控制了复杂度。还有一个实操技巧给规划器提供工具清单和示例。不要让它凭空想象有哪些工具可用而是在 prompt 里明确列出“你可以使用以下工具向量检索、关键词检索、SQL 查询、计算器、网页搜索”并给每个工具配一个使用示例。这样规划出来的 DAG 更靠谱不会出现“规划了一个不存在的工具”这种尴尬情况。注意任务规划不是越复杂越好。我见过一个团队把规划器做成了递归下降解析器支持嵌套子计划、条件分支、循环结果调试成本极高线上故障频发。对于 90% 的业务场景线性计划加一个条件分支就够了。4. 证据控制判断“够不够”和“对不对”4.1 证据充分性判断检索回来一堆文档怎么知道够不够回答用户的问题传统 RAG 的做法是“不管够不够先塞给 LLM 再说”结果要么是 LLM 基于不充分的证据胡编要么是塞了太多无关内容导致 LLM 迷失。证据控制的第一步是充分性判断让 LLM 评估“当前检索到的证据是否足以回答原问题”。如果不足输出“需要补充检索”以及“还需要什么信息”如果充足进入生成阶段。这个判断本身也是一次 LLM 调用但它的成本远低于生成一个错误答案的代价。我通常用 few-shot 的方式来做充分性判断给 LLM 看几个“证据不足”和“证据充足”的示例让它学会区分。实测下来准确率能到 85% 以上。剩下的 15% 误判主要出现在“证据部分充足”的灰色地带这种时候我倾向于保守策略宁可多检索一轮也不要基于不充分的证据生成。4.2 证据冲突消解比“证据不足”更麻烦的是“证据冲突”。检索回来的文档里A 文档说“RAG 的召回率是 80%”B 文档说“RAG 的召回率是 65%”LLM 该信谁如果不做处理LLM 可能会随机选一个或者把两个数字都列出来让用户自己判断体验很差。证据冲突消解的策略有三层来源可信度排序官方文档 技术博客 论坛帖子、时间新鲜度排序新文档 旧文档、交叉验证多个独立来源一致 单一来源。我一般让 LLM 先做来源和时间排序如果还是冲突就在生成阶段明确标注“不同来源存在差异”并给出各自的出处。这里有个实操心得给每个检索结果打一个可信度分数分数由来源类型、发布时间、引用次数等元数据计算得出。生成时按可信度排序LLM 优先使用高分证据。这个分数不需要很精确粗略的排序就能显著提升生成质量。4.3 证据压缩与上下文管理检索回来 20 个文档片段每个 500 字总共 10000 字全塞给 LLM 既贵又慢而且 LLM 的注意力会被稀释。证据控制的第三步是压缩把每个片段压缩成核心信息只保留和 query 相关的部分。压缩的方式有两种抽取式直接截取相关句子和生成式让 LLM 改写摘要。抽取式快但可能不连贯生成式连贯但可能引入幻觉。我通常用混合方式先用抽取式筛掉明显无关的句子再用生成式把剩下的内容改写成简洁的证据摘要。上下文管理的另一个技巧是分层组织。把证据按重要性分成“核心证据”“辅助证据”“背景信息”三层核心证据放在 prompt 最前面和最后面利用 LLM 的“首因效应”和“近因效应”辅助证据放中间背景信息如果太长就只保留标题。这样能在有限的上下文窗口里塞进最有价值的信息。5. Agentic RAG 的最小实现框架5.1 整体架构与数据流把上面三个模块串起来一个最小的 Agentic RAG 框架包含五个组件查询分析器、任务规划器、检索执行器、证据控制器、答案生成器。数据流是这样的用户 query 先经过查询分析器输出结构化查询意图和子查询任务规划器根据意图生成执行计划检索执行器按计划调用检索工具证据控制器评估检索结果决定是否补充检索最后答案生成器基于充分证据生成回答。这个框架和传统 RAG 最大的区别是多了两个反馈回路一个是证据控制到检索执行的回路证据不足时触发补充检索一个是证据控制到任务规划的回路证据冲突或缺失时触发重规划。这两个回路是 Agentic RAG “智能”的来源。# 伪代码Agentic RAG 主流程 def agentic_rag(query): analysis query_analyzer(query) plan task_planner(analysis) evidence [] for task in plan.tasks: result retriever.execute(task) evidence.extend(result) if not evidence_controller.is_sufficient(evidence, query): plan task_planner.replan(analysis, evidence) continue answer generator.generate(query, evidence) return answer5.2 关键参数与调优经验检索数量 top_k传统 RAG 一般设 3 到 5Agentic RAG 可以设大一点因为后面有证据控制做过滤。我通常设 10然后让证据控制器筛到 3 到 5 个核心证据。充分性判断阈值这个阈值决定了什么时候触发补充检索。设太高会导致检索轮次过多设太低会导致证据不足就生成。我的经验值是 0.7即 LLM 认为“70% 以上的问题能被当前证据回答”时就停止检索。最大检索轮次一定要设上限否则可能无限循环。我一般设 3 轮超过 3 轮还没找到充分证据就基于现有证据生成并在答案里标注“信息可能不完整”。重规划触发条件不是每次证据不足都要重规划。如果只是缺一个细节补充检索就够了如果是整个检索方向错了才需要重规划。判断标准是“当前计划的所有子任务是否都已完成但证据仍不足”如果是才触发重规划。5.3 和 KG 知识库、结构化知识库的配合最近很多人问rag知识库和结构知识库区分以及应用场景。简单说向量 RAG 知识库擅长处理非结构化文本文档、邮件、聊天记录结构化知识库SQL、图数据库擅长处理有明确 schema 的数据订单、库存、组织架构。Agentic RAG 的价值在于它能同时调度这两种知识库。比如用户问“上季度退货率最高的品类对应的客服工单里主要抱怨什么”。这个问题需要两步第一步查结构化数据库拿到“退货率最高的品类”第二步查向量知识库拿到“该品类的客服工单文本”。传统 RAG 做不了这种跨库查询Agentic RAG 的任务规划器可以生成一个包含 SQL 查询和向量检索的混合计划。KG 知识库知识图谱在这套框架里的角色是“关系推理”。向量检索擅长找相似文本但不擅长回答“A 和 B 是什么关系”这类问题。知识图谱可以把实体和关系显式存储Agentic RAG 在需要关系推理时调用图查询接口把结果作为证据补充进来。这就是ontology rag的思路用本体定义领域概念和关系用图谱存储实例用 RAG 做自然语言接口。注意不要为了用 KG 而用 KG。我见过一些团队把简单的文档问答硬套知识图谱结果图谱构建和维护成本极高效果还不如纯向量检索。KG 适合实体关系密集、需要多跳推理的场景比如医疗诊断、金融风控、供应链分析。6. 常见问题与排查技巧实录6.1 检索结果不相关怎么办这是最高频的问题。排查顺序是先看查询分析输出的子查询是否准确再看 embedding 模型是否适合你的领域最后看向量库的索引参数是否合理。如果子查询就不对那问题在查询分析环节需要调整 prompt 或换更强的 LLM。如果子查询对但检索结果不对那可能是 embedding 模型的问题——通用 embedding 模型在垂直领域医疗、法律、金融表现往往不好需要换领域微调过的模型。如果 embedding 没问题但排序不对那可能是向量库的相似度度量选错了余弦相似度和内积在不同场景下效果差异很大。我自己的排查清单是这样的现象可能原因排查方法检索结果完全不相关查询分析错误打印子查询人工检查检索结果部分相关embedding 模型不匹配换领域模型对比召回率相关文档排在后位相似度度量或索引参数问题调整度量方式重建索引多跳问题答不了缺少任务规划检查是否触发了多步检索6.2 延迟太高怎么优化Agentic RAG 的延迟天然比传统 RAG 高因为多了查询分析、任务规划、证据控制这几次 LLM 调用。优化手段有四个缓存查询分析结果、检索结果、甚至生成结果都可以缓存、并行没有依赖关系的子任务并行执行、小模型查询分析和证据控制用 7B 小模型生成用大模型、流式输出生成阶段流式返回降低用户感知延迟。我实测下来缓存能省 30% 到 50% 的延迟并行能省 20% 到 30%小模型能省 40% 左右。组合使用可以把端到端延迟从 8 秒压到 3 秒以内。6.3 证据控制误判怎么处理证据控制的误判主要有两种假阳性证据其实不够但判断为够和假阴性证据其实够了但判断为不够。假阳性的后果是生成错误答案假阴性的后果是多检索一轮、延迟增加。我的策略是宁可假阴性不要假阳性。因为多检索一轮的成本远低于生成错误答案的成本。具体做法是把充分性判断的阈值调低让 LLM 更容易说“不够”。同时在生成阶段加一个“置信度标注”如果证据确实不充分让 LLM 在答案里明确说“根据现有信息可能不完整”。还有一个技巧是用规则兜底。比如如果检索结果的数量少于 2 个直接判定为不充分不需要 LLM 判断。如果检索结果的来源全部相同也判定为不充分因为缺乏交叉验证。这些规则能覆盖 20% 左右的明显情况减少 LLM 调用。6.4 怎么在 Mac 上搭建本地 RAG 知识库最近怎么在mac上搭建rag知识库是个高频问题。Mac 的优势是本地开发体验好M 系列芯片跑小模型推理够用。我的推荐方案是用 Ollama 跑本地 LLM比如 Qwen2.5 7B 或 Llama 3.1 8B用 Chroma 或 LanceDB 做向量库都是本地文件存储不需要额外服务用 LangChain 或 LlamaIndex 做编排框架。具体步骤先装 Ollama 并拉取模型再装 Python 环境和向量库依赖然后把文档切块、嵌入、存入向量库最后写一个简单的检索加生成脚本。整个流程在 M1 MacBook Air 上跑通大概需要 30 分钟检索延迟在 1 到 2 秒左右生成延迟取决于模型大小7B 模型大概 3 到 5 秒。提示Mac 上跑本地 RAG最大的瓶颈是内存。7B 模型量化后大概占 4 到 5 GB 内存加上向量库和 Python 运行时8 GB 内存的机器会比较吃力。建议 16 GB 起步32 GB 更从容。7. 我踩过的坑和最后几条建议第一个坑是过早引入 Agentic 架构。我一开始做 RAG 的时候基础检索还没调好就急着上查询分析和任务规划结果整个系统复杂度爆炸出了问题根本不知道是哪个环节的锅。后来退回去先把基础 RAG 的召回率调到 80% 以上再逐步加 Agentic 模块效果才稳定下来。所以我的建议是先把传统 RAG 做到及格再考虑 Agentic 化。第二个坑是忽略评估。Agentic RAG 的链路长、变量多没有评估体系根本没法迭代。我后来搭了一个包含 200 条测试 query 的评估集每条 query 标注了标准答案和关键证据每次改动都跑一遍评估看召回率、准确率、延迟的变化。这个评估集花了我两天时间构建但后面省下的调试时间至少是它的十倍。第三个坑是把 LLM 当万能工具。查询分析、任务规划、证据控制、答案生成每个环节都用 LLM成本高不说延迟也受不了。后来我把一些确定性强的环节用规则替代比如“检索结果少于 2 个就判定不充分”“来源全部相同就判定不充分”这些规则覆盖了 20% 的情况省下了对应的 LLM 调用。最后分享一个我觉得最有用的技巧给每个环节加日志和可视化。Agentic RAG 的决策链路很长出了问题光看最终答案根本定位不到原因。我在每个环节都打印输入输出查询分析输出了什么子查询、任务规划生成了什么计划、证据控制判断了几次、每次的判断理由是什么。这些日志在调试的时候价值极高虽然看起来笨但比任何花哨的调试工具都管用。这套东西我目前在生产环境跑了三个月处理的是技术文档问答场景日均查询量在 5000 左右。相比之前的传统 RAG多跳问题的回答准确率从 40% 提升到了 75%聚合类问题的准确率从 30% 提升到了 65%代价是平均延迟从 1.5 秒增加到了 3.2 秒。这个 trade-off 在大多数业务场景下是值得的但如果你的场景对延迟极度敏感可能需要重新权衡哪些环节值得 Agentic 化。 Agentic RAG实战：从检索管道到智能体驱动的范式转移
1. 从“检索增强”到“智能体驱动”RAG 的范式转移1.1 为什么传统 RAG 开始不够用了做过 RAG 项目的人大概都有过这种体验搭一个“向量库 相似度检索 大模型生成”的流水线第一天跑 demo 效果惊艳第二天接入真实业务数据就开始翻车。用户问“上季度华东区退货率最高的三个品类是什么”系统检索回来一堆包含“退货”“华东”“品类”字样的文档片段但没有任何一段能直接回答这个问题——因为答案需要跨文档聚合、需要按时间过滤、需要做数值排序而传统 RAG 的“一次检索、一次生成”根本扛不住这种复合型查询。这就是最近大家反复提到的rag瓶颈。瓶颈不在向量检索本身而在于整条链路缺少“思考”的环节。传统 RAG 把用户 query 当成一个静态字符串直接丢给 embedding 模型去匹配既没有理解 query 的真实意图也没有判断检索回来的证据是否充分更没有在证据不足时主动发起第二轮检索。它本质上是一个开环系统没有反馈、没有规划、没有自我修正。我自己的判断是RAG 正在经历从“检索管道”到“智能体”的范式转移。Agentic RAG这个词听起来新但拆开看就是三件事——查询分析搞懂用户到底要什么、任务规划把复杂问题拆成可执行的检索步骤、证据控制判断检索结果够不够、对不对、要不要再查。这三件事串起来才构成一个闭环的、有自主性的检索增强系统。1.2 这套东西适合谁、解决什么问题如果你正在做企业知识库问答、客服工单辅助、合同条款检索、技术文档助手这类场景并且已经踩过“检索不准、答案不全、多跳问题答不了”的坑那这套思路就是给你准备的。它不要求你推翻现有的向量库和 embedding 方案而是在检索和生成之间插入一个“智能体层”用 LLM 的推理能力去调度检索行为。适合的读者包括有一定 RAG 实战经验、想突破效果天花板的工程师正在做知识库产品、需要处理复杂查询的产品经理以及想理解 Agentic RAG 到底和普通 RAG 差在哪里的技术决策者。小白也能看但最好先跑通过一个最基础的 RAG demo否则有些痛点你感受不深。下面我会按“查询分析 → 任务规划 → 证据控制”这条主线把每个环节的原理、实现细节、踩坑经验拆开讲最后给一个可复现的 Agentic RAG 最小实现框架。2. 查询分析把“人话”翻译成“检索指令”2.1 查询分析到底在分析什么很多人以为查询分析就是“改写 query”其实远不止。一个完整的查询分析模块至少要输出四类信息意图类型是事实查询、比较、聚合、还是多跳推理、关键实体人名、产品名、时间、地区、约束条件时间范围、数据来源、格式要求、检索策略建议该用向量检索、关键词检索、还是结构化查询。举个例子用户问“对比一下 RAG 和微调在客服场景下的成本”。这句话里意图是“比较”实体是“RAG”“微调”“客服场景”约束是“成本维度”检索策略建议是“需要分别检索 RAG 成本相关文档和微调成本相关文档然后做对比”。如果直接把原句丢给向量库大概率检索回来的是一堆同时提到 RAG 和微调的泛泛文章而不是分别针对两者成本的细节。我通常的做法是让 LLM 输出一个结构化的 JSON包含上述字段。这里有个经验不要让 LLM 自由发挥写改写后的 query而是让它填一个固定 schema。自由发挥的改写往往不稳定今天改写成这样明天改写成那样下游检索逻辑没法复用。固定 schema 的好处是可测试、可缓存、可监控。# 查询分析输出的 schema 示例 { intent: comparison, entities: [RAG, 微调, 客服场景], constraints: {dimension: 成本, time_range: null}, sub_queries: [ RAG 在客服场景的成本构成, 微调在客服场景的成本构成 ], retrieval_strategy: multi_query_vector }2.2 查询改写与扩展的实操技巧查询分析里最实用的两个操作是改写和扩展。改写解决“用户用词和文档用词不一致”的问题比如用户说“怎么退钱”文档里写的是“退款流程”扩展解决“单一 query 覆盖不全”的问题比如把“RAG 瓶颈”扩展成“RAG 检索精度瓶颈”“RAG 多跳推理瓶颈”“RAG 上下文长度瓶颈”。我实测下来HyDE假设性文档嵌入在中文场景下效果不稳定因为让 LLM 凭空生成一段“假设的答案文档”再去做向量匹配生成的文档质量参差不齐反而引入噪声。更稳的做法是多查询扩展让 LLM 基于原 query 生成 3 到 5 个不同角度的子查询分别检索后做结果融合。融合策略我一般用 RRF倒数排名融合简单有效不需要调参。注意查询扩展不是越多越好。我试过生成 10 个子查询结果检索延迟翻了 4 倍召回率只提升了不到 3 个百分点。3 到 5 个是性价比最高的区间具体数量可以根据你的延迟预算调整。还有一个容易被忽略的点查询分析本身也要做缓存。很多业务场景下用户问的问题是高度重复的比如“怎么开发票”“退货政策是什么”。把查询分析的结果按 query 哈希缓存起来命中率能到 30% 以上直接省掉一次 LLM 调用。2.3 查询分析环节的常见坑第一个坑是过度分析。有些团队把查询分析做成了一个小型 NLP 流水线意图分类、实体识别、依存句法分析全上结果延迟爆炸效果还不如直接让 LLM 一次性输出结构化结果。我的建议是能用一次 LLM 调用解决的不要拆成多个模型串联。第二个坑是忽略查询的时效性。用户问“最新的 RAG 框架有哪些”这里的“最新”是个强约束但很多查询分析模块不提取时间信息导致检索回来的都是两年前的旧文章。解决办法是在 schema 里加一个time_sensitivity字段高时效性的查询走“时间过滤 向量检索”的混合策略。第三个坑是多语言混合查询。中文用户经常在 query 里夹杂英文术语比如“RAG 的 retriever 怎么选”。如果 embedding 模型对中英混合支持不好检索效果会明显下降。实测下来用支持多语言的 embedding 模型比如 BGE-M3比用纯中文模型效果好很多虽然向量维度高了、存储成本上去了但召回率的提升值得这个代价。3. 任务规划让 RAG 学会“分步走”3.1 什么查询需要任务规划不是所有查询都需要规划。简单的事实查询比如“RAG 的全称是什么”一次检索就够了硬加规划反而增加延迟。真正需要任务规划的是这三类多跳查询答案需要多个文档串联、聚合查询需要对多个结果做统计或排序、条件查询带复杂过滤条件的检索。判断标准很简单如果一个问题需要“先查 A再根据 A 的结果查 B”那它就需要规划。比如“OpenAI 的 CEO 在哪个大学读的本科”第一步查“OpenAI CEO 是谁”第二步查“这个人的本科院校”。传统 RAG 把整个问题丢给向量库检索回来的大概率是同时提到 OpenAI 和大学的泛泛文章而不是精确答案。任务规划的核心思路是让 LLM 把复杂 query 拆成一个有向无环图DAG每个节点是一个子任务边表示依赖关系。然后按拓扑顺序执行前一个节点的输出作为后一个节点的输入。3.2 规划器的实现方式对比目前主流的规划器实现有三种ReAct 风格边想边做、Plan-and-Execute 风格先规划再执行、混合风格先粗规划执行中动态调整。ReAct 的优点是灵活每一步都能根据上一步的结果调整方向缺点是 LLM 调用次数多延迟高而且容易陷入循环。Plan-and-Execute 的优点是规划一次、执行多次延迟可控缺点是规划时看不到中间结果遇到意外情况没法调整。混合风格是我目前最推荐的先让 LLM 生成一个粗粒度的计划3 到 5 步执行过程中如果某一步的检索结果置信度低于阈值再触发一次局部重规划。# 任务规划的 DAG 示例 { nodes: [ {id: n1, task: 检索 OpenAI CEO 姓名, type: retrieval}, {id: n2, task: 检索 {n1.result} 的本科院校, type: retrieval, depends_on: [n1]}, {id: n3, task: 生成最终答案, type: generation, depends_on: [n2]} ] }这里有个关键细节节点之间的参数传递要用占位符比如{n1.result}执行时动态替换。不要让 LLM 在规划阶段就猜出中间结果那样规划就变成了“幻觉生成”。3.3 规划粒度的权衡规划粒度太粗比如只规划“检索 → 生成”两步那和传统 RAG 没区别规划粒度太细比如把“检索”拆成“生成检索词 → 调用向量库 → 过滤结果 → 重排序”那 LLM 调用次数会多到不可接受。我的经验值是每个子任务对应一次工具调用。检索是一个工具生成是一个工具结构化查询是一个工具。规划器只负责决定“调用哪些工具、按什么顺序调用”不负责决定工具内部的实现细节。这样既保证了灵活性又控制了复杂度。还有一个实操技巧给规划器提供工具清单和示例。不要让它凭空想象有哪些工具可用而是在 prompt 里明确列出“你可以使用以下工具向量检索、关键词检索、SQL 查询、计算器、网页搜索”并给每个工具配一个使用示例。这样规划出来的 DAG 更靠谱不会出现“规划了一个不存在的工具”这种尴尬情况。注意任务规划不是越复杂越好。我见过一个团队把规划器做成了递归下降解析器支持嵌套子计划、条件分支、循环结果调试成本极高线上故障频发。对于 90% 的业务场景线性计划加一个条件分支就够了。4. 证据控制判断“够不够”和“对不对”4.1 证据充分性判断检索回来一堆文档怎么知道够不够回答用户的问题传统 RAG 的做法是“不管够不够先塞给 LLM 再说”结果要么是 LLM 基于不充分的证据胡编要么是塞了太多无关内容导致 LLM 迷失。证据控制的第一步是充分性判断让 LLM 评估“当前检索到的证据是否足以回答原问题”。如果不足输出“需要补充检索”以及“还需要什么信息”如果充足进入生成阶段。这个判断本身也是一次 LLM 调用但它的成本远低于生成一个错误答案的代价。我通常用 few-shot 的方式来做充分性判断给 LLM 看几个“证据不足”和“证据充足”的示例让它学会区分。实测下来准确率能到 85% 以上。剩下的 15% 误判主要出现在“证据部分充足”的灰色地带这种时候我倾向于保守策略宁可多检索一轮也不要基于不充分的证据生成。4.2 证据冲突消解比“证据不足”更麻烦的是“证据冲突”。检索回来的文档里A 文档说“RAG 的召回率是 80%”B 文档说“RAG 的召回率是 65%”LLM 该信谁如果不做处理LLM 可能会随机选一个或者把两个数字都列出来让用户自己判断体验很差。证据冲突消解的策略有三层来源可信度排序官方文档 技术博客 论坛帖子、时间新鲜度排序新文档 旧文档、交叉验证多个独立来源一致 单一来源。我一般让 LLM 先做来源和时间排序如果还是冲突就在生成阶段明确标注“不同来源存在差异”并给出各自的出处。这里有个实操心得给每个检索结果打一个可信度分数分数由来源类型、发布时间、引用次数等元数据计算得出。生成时按可信度排序LLM 优先使用高分证据。这个分数不需要很精确粗略的排序就能显著提升生成质量。4.3 证据压缩与上下文管理检索回来 20 个文档片段每个 500 字总共 10000 字全塞给 LLM 既贵又慢而且 LLM 的注意力会被稀释。证据控制的第三步是压缩把每个片段压缩成核心信息只保留和 query 相关的部分。压缩的方式有两种抽取式直接截取相关句子和生成式让 LLM 改写摘要。抽取式快但可能不连贯生成式连贯但可能引入幻觉。我通常用混合方式先用抽取式筛掉明显无关的句子再用生成式把剩下的内容改写成简洁的证据摘要。上下文管理的另一个技巧是分层组织。把证据按重要性分成“核心证据”“辅助证据”“背景信息”三层核心证据放在 prompt 最前面和最后面利用 LLM 的“首因效应”和“近因效应”辅助证据放中间背景信息如果太长就只保留标题。这样能在有限的上下文窗口里塞进最有价值的信息。5. Agentic RAG 的最小实现框架5.1 整体架构与数据流把上面三个模块串起来一个最小的 Agentic RAG 框架包含五个组件查询分析器、任务规划器、检索执行器、证据控制器、答案生成器。数据流是这样的用户 query 先经过查询分析器输出结构化查询意图和子查询任务规划器根据意图生成执行计划检索执行器按计划调用检索工具证据控制器评估检索结果决定是否补充检索最后答案生成器基于充分证据生成回答。这个框架和传统 RAG 最大的区别是多了两个反馈回路一个是证据控制到检索执行的回路证据不足时触发补充检索一个是证据控制到任务规划的回路证据冲突或缺失时触发重规划。这两个回路是 Agentic RAG “智能”的来源。# 伪代码Agentic RAG 主流程 def agentic_rag(query): analysis query_analyzer(query) plan task_planner(analysis) evidence [] for task in plan.tasks: result retriever.execute(task) evidence.extend(result) if not evidence_controller.is_sufficient(evidence, query): plan task_planner.replan(analysis, evidence) continue answer generator.generate(query, evidence) return answer5.2 关键参数与调优经验检索数量 top_k传统 RAG 一般设 3 到 5Agentic RAG 可以设大一点因为后面有证据控制做过滤。我通常设 10然后让证据控制器筛到 3 到 5 个核心证据。充分性判断阈值这个阈值决定了什么时候触发补充检索。设太高会导致检索轮次过多设太低会导致证据不足就生成。我的经验值是 0.7即 LLM 认为“70% 以上的问题能被当前证据回答”时就停止检索。最大检索轮次一定要设上限否则可能无限循环。我一般设 3 轮超过 3 轮还没找到充分证据就基于现有证据生成并在答案里标注“信息可能不完整”。重规划触发条件不是每次证据不足都要重规划。如果只是缺一个细节补充检索就够了如果是整个检索方向错了才需要重规划。判断标准是“当前计划的所有子任务是否都已完成但证据仍不足”如果是才触发重规划。5.3 和 KG 知识库、结构化知识库的配合最近很多人问rag知识库和结构知识库区分以及应用场景。简单说向量 RAG 知识库擅长处理非结构化文本文档、邮件、聊天记录结构化知识库SQL、图数据库擅长处理有明确 schema 的数据订单、库存、组织架构。Agentic RAG 的价值在于它能同时调度这两种知识库。比如用户问“上季度退货率最高的品类对应的客服工单里主要抱怨什么”。这个问题需要两步第一步查结构化数据库拿到“退货率最高的品类”第二步查向量知识库拿到“该品类的客服工单文本”。传统 RAG 做不了这种跨库查询Agentic RAG 的任务规划器可以生成一个包含 SQL 查询和向量检索的混合计划。KG 知识库知识图谱在这套框架里的角色是“关系推理”。向量检索擅长找相似文本但不擅长回答“A 和 B 是什么关系”这类问题。知识图谱可以把实体和关系显式存储Agentic RAG 在需要关系推理时调用图查询接口把结果作为证据补充进来。这就是ontology rag的思路用本体定义领域概念和关系用图谱存储实例用 RAG 做自然语言接口。注意不要为了用 KG 而用 KG。我见过一些团队把简单的文档问答硬套知识图谱结果图谱构建和维护成本极高效果还不如纯向量检索。KG 适合实体关系密集、需要多跳推理的场景比如医疗诊断、金融风控、供应链分析。6. 常见问题与排查技巧实录6.1 检索结果不相关怎么办这是最高频的问题。排查顺序是先看查询分析输出的子查询是否准确再看 embedding 模型是否适合你的领域最后看向量库的索引参数是否合理。如果子查询就不对那问题在查询分析环节需要调整 prompt 或换更强的 LLM。如果子查询对但检索结果不对那可能是 embedding 模型的问题——通用 embedding 模型在垂直领域医疗、法律、金融表现往往不好需要换领域微调过的模型。如果 embedding 没问题但排序不对那可能是向量库的相似度度量选错了余弦相似度和内积在不同场景下效果差异很大。我自己的排查清单是这样的现象可能原因排查方法检索结果完全不相关查询分析错误打印子查询人工检查检索结果部分相关embedding 模型不匹配换领域模型对比召回率相关文档排在后位相似度度量或索引参数问题调整度量方式重建索引多跳问题答不了缺少任务规划检查是否触发了多步检索6.2 延迟太高怎么优化Agentic RAG 的延迟天然比传统 RAG 高因为多了查询分析、任务规划、证据控制这几次 LLM 调用。优化手段有四个缓存查询分析结果、检索结果、甚至生成结果都可以缓存、并行没有依赖关系的子任务并行执行、小模型查询分析和证据控制用 7B 小模型生成用大模型、流式输出生成阶段流式返回降低用户感知延迟。我实测下来缓存能省 30% 到 50% 的延迟并行能省 20% 到 30%小模型能省 40% 左右。组合使用可以把端到端延迟从 8 秒压到 3 秒以内。6.3 证据控制误判怎么处理证据控制的误判主要有两种假阳性证据其实不够但判断为够和假阴性证据其实够了但判断为不够。假阳性的后果是生成错误答案假阴性的后果是多检索一轮、延迟增加。我的策略是宁可假阴性不要假阳性。因为多检索一轮的成本远低于生成错误答案的成本。具体做法是把充分性判断的阈值调低让 LLM 更容易说“不够”。同时在生成阶段加一个“置信度标注”如果证据确实不充分让 LLM 在答案里明确说“根据现有信息可能不完整”。还有一个技巧是用规则兜底。比如如果检索结果的数量少于 2 个直接判定为不充分不需要 LLM 判断。如果检索结果的来源全部相同也判定为不充分因为缺乏交叉验证。这些规则能覆盖 20% 左右的明显情况减少 LLM 调用。6.4 怎么在 Mac 上搭建本地 RAG 知识库最近怎么在mac上搭建rag知识库是个高频问题。Mac 的优势是本地开发体验好M 系列芯片跑小模型推理够用。我的推荐方案是用 Ollama 跑本地 LLM比如 Qwen2.5 7B 或 Llama 3.1 8B用 Chroma 或 LanceDB 做向量库都是本地文件存储不需要额外服务用 LangChain 或 LlamaIndex 做编排框架。具体步骤先装 Ollama 并拉取模型再装 Python 环境和向量库依赖然后把文档切块、嵌入、存入向量库最后写一个简单的检索加生成脚本。整个流程在 M1 MacBook Air 上跑通大概需要 30 分钟检索延迟在 1 到 2 秒左右生成延迟取决于模型大小7B 模型大概 3 到 5 秒。提示Mac 上跑本地 RAG最大的瓶颈是内存。7B 模型量化后大概占 4 到 5 GB 内存加上向量库和 Python 运行时8 GB 内存的机器会比较吃力。建议 16 GB 起步32 GB 更从容。7. 我踩过的坑和最后几条建议第一个坑是过早引入 Agentic 架构。我一开始做 RAG 的时候基础检索还没调好就急着上查询分析和任务规划结果整个系统复杂度爆炸出了问题根本不知道是哪个环节的锅。后来退回去先把基础 RAG 的召回率调到 80% 以上再逐步加 Agentic 模块效果才稳定下来。所以我的建议是先把传统 RAG 做到及格再考虑 Agentic 化。第二个坑是忽略评估。Agentic RAG 的链路长、变量多没有评估体系根本没法迭代。我后来搭了一个包含 200 条测试 query 的评估集每条 query 标注了标准答案和关键证据每次改动都跑一遍评估看召回率、准确率、延迟的变化。这个评估集花了我两天时间构建但后面省下的调试时间至少是它的十倍。第三个坑是把 LLM 当万能工具。查询分析、任务规划、证据控制、答案生成每个环节都用 LLM成本高不说延迟也受不了。后来我把一些确定性强的环节用规则替代比如“检索结果少于 2 个就判定不充分”“来源全部相同就判定不充分”这些规则覆盖了 20% 的情况省下了对应的 LLM 调用。最后分享一个我觉得最有用的技巧给每个环节加日志和可视化。Agentic RAG 的决策链路很长出了问题光看最终答案根本定位不到原因。我在每个环节都打印输入输出查询分析输出了什么子查询、任务规划生成了什么计划、证据控制判断了几次、每次的判断理由是什么。这些日志在调试的时候价值极高虽然看起来笨但比任何花哨的调试工具都管用。这套东西我目前在生产环境跑了三个月处理的是技术文档问答场景日均查询量在 5000 左右。相比之前的传统 RAG多跳问题的回答准确率从 40% 提升到了 75%聚合类问题的准确率从 30% 提升到了 65%代价是平均延迟从 1.5 秒增加到了 3.2 秒。这个 trade-off 在大多数业务场景下是值得的但如果你的场景对延迟极度敏感可能需要重新权衡哪些环节值得 Agentic 化。