1. 为什么能检索不等于能干活Agentic RAG 的定位问题很多人第一次听到 Agentic RAG脑子里浮现的画面是给 RAG 加个 Agent 壳子。这个理解不算错但太浅了。真正落地过一两个项目之后你会发现Agentic RAG 要解决的根本不是检索得更准这件事而是检索这件事本身该不该发生、发生几次、什么时候停。传统 RAG 的链路是死的用户提问 → 向量化 → 召回 Top-K → 拼进 Prompt → 生成。这条链路里检索是一个无条件执行的固定步骤。问题在于真实业务里至少有一半的 query 根本不需要检索——帮我改写这段话、把上面的结论翻译成英文、这个报错是什么意思这些请求走检索纯属浪费 Token 和时间。反过来另一些 query 一次检索根本不够——对比 A 产品和 B 产品在售后政策上的差异这需要先查 A、再查 B、再对比是一个多跳推理过程。Agentic RAG 的核心变化是把检索从一个固定步骤变成一个由模型自主决策的动作。模型手里握着一组工具检索、计算、调用外部 API、读文件等它自己判断这个问题我要不要检索检索什么检索结果够不够不够要不要换个 query 再来一次什么时候可以收手给答案这就引出了本文要讲的核心——八条工程硬规则。它们不是理论是我在把 Agentic RAG 从 Demo 推到生产环境过程中被线上问题反复教育之后沉淀下来的。关键词里的 ReAct、GraphRAG、上下文工程、Token 用量都会在这八条规则里逐一落地。这篇文章适合两类人一是已经跑通过基础 RAG、想往 Agent 方向演进的同学二是正在做 Agent 产品、被检索失控和Token 爆炸折磨的工程师。我会尽量把每条规则的为什么讲透因为只抄配置不理解原理换个场景就会翻车。2. 规则一先判断要不要检索再谈怎么检索2.1 无脑检索是最大的成本黑洞我见过太多项目上来就是所有 query 先检索一遍再说。这个做法在 Demo 阶段没问题因为 Demo 的 query 都是精心设计的知识问答。但一上生产用户什么都会问。我统计过我们线上一个月的 query 分布真正需要外部知识检索的只占43%剩下 57% 里有闲聊、有指令类请求、有纯推理题、有对上一轮回答的追问。这 57% 的请求如果都走一遍检索代价是什么按每次检索召回 5 个 chunk、每个 chunk 平均 300 Token 算光是把检索结果塞进上下文就是 1500 Token。加上 embedding 调用、向量库查询的延迟单次请求平白多出 300-800ms 和一笔 Token 开销。用户量一上来这就是真金白银。2.2 判断逻辑怎么设计才不误伤判断要不要检索这件事最忌讳用一堆 if-else 硬编码规则。我早期试过关键词匹配包含是什么怎么就检索结果被这个方案怎么优化这种纯推理问题打脸——它不需要检索但命中了关键词。比较稳的做法是让模型自己判断但要给它一个结构化的判断框架。我在 Prompt 里用的是这个三段式在决定是否检索前请依次判断 1. 这个问题是否依赖我训练数据之外、且可能随时间变化的私有知识 2. 如果我不检索直接回答是否会因为信息缺失而给出错误或过时的答案 3. 用户是否明确要求基于某个文档/资料回答 只有第 1 或第 3 条为真时才触发检索。这个框架的关键在于第 2 条是一个反向验证。很多模型倾向于能检索就检索加上这条不检索会不会错的自问能显著降低过度检索率。实测下来过度检索率从 38% 降到了 11% 左右。注意判断这一步本身也要花 Token。如果你的场景 query 量极大、单次价值很低可以考虑用一个更小的模型比如 7B 级别专门做这个路由判断把大模型留给真正需要推理的环节。这是典型的用小模型省钱、用大模型保质的分层策略。2.3 一个容易被忽略的中间态判断不是二元的检索/不检索。我后来加了一个中间态澄清式追问。当模型判断这个问题可能需要检索但当前 query 信息不足以确定检索什么时它应该先反问用户而不是瞎检索一通。比如用户问这个政策什么时候生效模型不知道这个政策指哪个直接检索只会召回一堆不相关文档。正确做法是追问您指的是哪份政策文件。这一步能砍掉大量无效检索代价只是多一轮对话。3. 规则二检索次数必须有硬上限且要能刹车3.1 ReAct 循环失控是 Agentic RAG 的头号事故ReActReasoning Acting范式让模型可以想一步、做一步、再看结果想下一步。这个循环很强大但它的致命问题是模型可能永远停不下来。我遇到过最夸张的一次模型为了回答一个简单的产品参数问题连续检索了 17 次每次换个 query 角度最后 Token 烧了 4 万多答案还是错的。为什么会这样因为 ReAct 的每一步都是模型基于当前上下文做决策而检索回来的内容往往会引入新的待确认信息模型就会想我再查一下这个。这是一个正反馈循环没有外力干预就会一直转下去。3.2 刹车机制的三层设计我的做法是给检索循环设三道刹车任何一道触发就强制收敛刹车层触发条件触发后的动作次数刹车检索调用达到 N 次我设的是 5强制进入生成阶段用已有信息作答收益刹车连续 2 次检索召回内容与已有上下文重复度 70%判定为检索无新增信息停止时间刹车单次请求总耗时超过 T 秒我设的是 15s中断循环返回当前最优答案次数刹车最好理解但 N 设多少有讲究。设太小比如 2多跳问题答不好设太大比如 10成本和延迟失控。我试过 3、5、8 三档5 是复杂问答场景的甜点值——足够覆盖大部分 2-3 跳的问题又不至于让简单问题被拖累。收益刹车是最有价值的一道。它的逻辑是如果新检索回来的东西和已经有的信息差不多那再检索下去也没意义。实现上可以用一个简单的相似度计算把新召回的 chunk 和上下文里已有的 chunk 做比对。这道刹车能砍掉大量无效勤奋。3.3 刹车不是粗暴截断要留体面退出强制刹车之后不能让模型直接吐一个我查不到了。正确做法是在刹车触发时给模型注入一条系统提示检索预算已用尽。请基于当前已获取的信息给出最佳答案 并明确标注哪些部分是基于已有信息的推断、哪些部分信息不足。 不要编造未检索到的内容。这样即使信息不全用户也能得到一个诚实的、有边界感的回答而不是一个自信的幻觉。这一点在客服、医疗、法律这类场景里尤其重要。4. 规则三上下文工程决定成败而不是模型能力4.1 检索回来的东西怎么摆比摆什么更重要上下文工程Context Engineering这个词这两年很火但很多人把它理解成写 Prompt 的技巧。在 Agentic RAG 里它的核心是如何把多轮检索的结果、推理过程、工具返回组织成一个模型能高效利用的上下文结构。我做过一个对比实验同样的检索结果、同样的模型只是改变上下文的组织方式答案准确率差了23 个百分点。这个差距比换个更强的模型带来的提升还大。4.2 我的上下文分层结构经过反复调整我固定下来一套四层结构从下到上依次是系统层角色定义、行为约束、输出格式要求。这部分固定不变放在最前面。任务层当前用户 query 对话历史摘要。注意是摘要不是原始历史否则上下文会被历史撑爆。证据层检索回来的文档片段。每个片段必须带来源标记文档名、段落位置方便模型引用和用户溯源。推理层模型自己的思考过程ReAct 的 Thought 部分。这部分要保留因为它帮助模型保持推理连贯性。关键细节在证据层。我要求每个检索片段都带上一个相关性标注——是模型在检索后自己打的高/中/低。生成时模型会优先使用高相关片段中相关作为补充低相关直接忽略。这个小小的标注让模型在信息过载时有了取舍依据。4.3 Token 预算的分配艺术上下文窗口是有限的Token 是要花钱的。我给自己定的预算是系统层不超过 500 Token任务层不超过 1000 Token证据层不超过 3000 Token推理层不超过 1500 Token给输出留 2000 Token。加起来 8000 Token 左右是一个成本和效果的平衡点。证据层这 3000 Token 怎么分如果召回了 10 个片段不能平均分。我的做法是按相关性加权分配高相关的片段给足空间每个 500 Token中相关的压缩每个 200 Token低相关的直接截断到 100 Token 或丢弃。这样保证最有价值的信息不被稀释。提示Token 用量监控一定要做。我见过团队上线后才发现单次请求平均消耗 1.2 万 Token成本是预算的 3 倍。建议在每次请求结束时记录 input/output Token 数按天聚合设一个告警阈值。5. 规则四GraphRAG 不是万能药用错场景就是负优化5.1 什么时候该上 GraphRAGGraphRAG 这两年被吹得很凶好像不做图谱就落伍了。但我踩过的坑告诉我大部分场景用不上 GraphRAG硬上只会增加复杂度和成本。GraphRAG 真正发挥价值的场景有一个共同特征问题需要跨多个文档、多个实体做关联推理。比如我们公司哪些供应商同时给 A 部门和 B 部门供货且这些供应商里有财务风险的这种问题需要把供应商、部门、财务状态三类实体连起来看纯向量检索很难搞定因为答案不在任何一个文档里而在文档之间的关系里。反过来如果你的场景是查一下 XX 产品的保修政策这就是一个单点查询向量检索又快又准上 GraphRAG 纯属杀鸡用牛刀。5.2 图谱构建的成本账GraphRAG 的成本主要在构建阶段。你需要实体抽取用 LLM 跑一遍所有文档、关系抽取、图谱存储、社区检测用于生成摘要。我做过一个测算10 万篇文档的图谱构建光 LLM 调用成本就是纯向量索引的8-15 倍构建时间从几小时变成几天。而且图谱不是建完就完事文档更新时图谱要增量维护实体消歧、关系更新都是麻烦事。所以我的建议是先用向量检索跑通业务当且仅当发现关联推理类问题占比超过 20% 且向量方案明显答不好时再考虑引入 GraphRAG。5.3 混合检索向量 图谱的务实组合如果确实需要图谱能力也不必全盘替换。我现在的做法是混合检索向量检索负责语义相似召回图谱检索负责关系推理召回两路结果在证据层合并由模型判断用哪路。具体实现上我会在路由阶段加一个判断如果 query 里出现关系关联同时对比这类词或者涉及多个实体就同时触发两路检索否则只走向量。这样既拿到了图谱的能力又没让所有请求都背上图谱的开销。6. 规则五工具设计要窄而深不要宽而浅6.1 工具太多模型会选错Agentic RAG 里检索只是工具之一。你可能会给模型配向量检索、关键词检索、图谱查询、数据库查询、计算器、外部 API 等等。工具一多模型的选择困难症就来了。我早期给模型配了 8 个工具结果发现它经常选错——该用向量检索的时候用了关键词检索该查数据库的时候去查了向量库。后来我把工具精简到 4 个并且每个工具的描述写得极其明确选择准确率立刻上来了。6.2 工具描述要写什么时候用而不是是什么这是很多人写工具定义时的通病。看这个反例工具名vector_search 描述向量检索工具用于语义相似度搜索。这个描述只说了是什么模型不知道什么时候该用它。改成这样工具名vector_search 描述当用户问题涉及概念性、描述性、开放性的知识查询时使用 例如XX 是什么XX 的原理关于 XX 的介绍。 不适合精确的数值查询或结构化数据查询。加上什么时候用和什么时候不用模型的选择准确率能提升一大截。这本质上是在帮模型做决策而不是让它猜。6.3 工具返回结果要自解释工具返回给模型的内容不能是一堆裸数据。比如数据库查询返回一个 JSON模型可能看不懂字段含义。我的做法是让工具返回带自然语言说明的结构化结果{ summary: 查询到 3 条订单记录均为 2024 年 3 月创建, data: [...], note: 金额单位为元状态字段 1 表示已完成、2 表示进行中 }这个summary和note字段是给模型看的能显著降低它理解数据的难度减少后续追问。7. 规则六把幻觉当成一等公民来治理7.1 Agentic RAG 的幻觉更隐蔽传统 RAG 的幻觉好识别——答案和检索内容对不上。但 Agentic RAG 的幻觉更隐蔽因为它有推理过程。模型可能检索到了正确信息但在推理环节想歪了得出一个看似有依据、实则错误的结论。我遇到过最典型的一次检索到了A 产品保修 2 年和B 产品保修 3 年模型推理出B 产品保修比 A 产品长 1 年——这个没错。但用户问的是哪个更划算模型接着推理保修长的更划算这就把保修时长和划算划了等号是一个没有依据的推断。7.2 强制引用与溯源治理幻觉的第一招是强制引用。我要求模型在给出任何事实性陈述时必须标注来源片段编号。比如根据 [3]A 产品保修 2 年。这个要求有两个好处一是逼模型确认自己的话有依据二是方便用户和开发者核查。实现上在证据层给每个片段编号然后在输出格式要求里明确每个事实陈述后必须跟 [编号]。如果模型给不出编号说明这个陈述没有依据应该被质疑。7.3 区分事实和推断第二招是要求模型显式区分事实和推断。我在输出格式里规定【事实】基于检索内容可直接得出... 【推断】基于事实的合理推断可能不准确... 【未知】检索内容未覆盖无法回答...这个格式强制模型把不同确定性的内容分开。用户一眼就能看出哪些是可靠的、哪些要打个问号。这个做法在专业场景法律、医疗、金融里几乎是刚需。7.4 检索不到时的诚实兜底最容易被忽略的是当检索确实没找到相关信息时模型应该老实说没找到而不是硬编一个答案。我在系统提示里加了一条硬约束如果检索结果与问题无关或信息不足必须明确告知用户 当前资料中未找到相关信息并建议用户补充信息或换个问法。 严禁在信息不足时编造答案。这条约束配合前面的刹车机制能挡掉大部分一本正经胡说八道的情况。8. 规则七评估体系要能测过程不能只测结果8.1 只看最终答案你永远不知道哪里坏了传统 RAG 评估看的是答案对不对。但 Agentic RAG 是一个多步骤系统最终答案错了可能是判断错了不该检索却检索了、可能是检索错了召回不相关、可能是推理错了信息对但结论错。只看结果你根本不知道优化哪里。我的评估体系分三层决策层检索决策是否正确该检索的检索了、不该检索的没检索。用人工标注一批 query 做基准算准确率。检索层召回内容的相关性。用命中率Hit Rate和 MRR平均倒数排名衡量。生成层最终答案的准确性、完整性、引用正确性。用 LLM-as-Judge 加人工抽检。8.2 决策层的评估最容易被跳过大部分团队只评估检索层和生成层跳过决策层。但决策层恰恰是 Agentic RAG 区别于传统 RAG 的地方。我建议至少标注 200 条 query覆盖需要检索不需要检索需要多跳检索三类定期跑一遍决策准确率。这个指标掉了说明路由 Prompt 或模型出了问题。8.3 用轨迹而不是答案做回归测试每次改 Prompt 或换模型我都会跑一遍回归测试。但测试的不是答案而是完整的执行轨迹模型做了几次检索、每次检索用了什么 query、什么时候刹的车。对比新旧轨迹能看出改动到底影响了哪个环节。这个做法帮我抓到过好几次隐蔽的回归。有一次换了个模型答案准确率没变但平均检索次数从 2.1 涨到了 3.8Token 成本涨了 60%。如果只看答案这个问题根本发现不了。9. 规则八上线不是终点监控和迭代才是9.1 必须监控的四个核心指标Agentic RAG 上线后我盯的是这四个指标指标含义健康区间我的经验值平均检索次数单次请求触发检索的平均次数1.5 - 2.5刹车触发率触发次数/收益/时间刹车的比例 15%平均 Token 消耗单次请求 inputoutput Token按业务定波动 20%无答案率返回未找到相关信息的比例 10%刹车触发率突然升高说明模型陷入了无效检索循环要检查 Prompt 或检索质量。无答案率升高说明知识库覆盖不足或检索召回变差。这些指标比单纯的用户满意度更早暴露问题。9.2 建立坏案例回流机制我要求团队每周整理一批坏案例——用户点了差评的、或者人工抽检发现问题的。每个坏案例都要归因到具体环节是决策错、检索错、还是生成错。归因之后针对性地改 Prompt、补知识库、或者调参数。这个机制的价值在于让优化有方向。没有坏案例回流优化就是拍脑袋。我们靠这个机制三个月把整体准确率从 71% 提到了 86%。9.3 版本管理Prompt 也是代码最后一条经验把 Prompt 当代码管理。每次改 Prompt 都要有版本号、有变更说明、有回归测试结果。我见过团队因为某个人随手改了一句 Prompt导致线上效果集体下滑还找不到是谁改的。我的做法是把所有 Prompt 存在 Git 里每次变更走 Code Review上线前跑回归测试。听起来有点重但比起线上事故的代价这点流程成本完全值得。10. 我在实际落地中踩过的几个具体坑规则讲完了再分享几个具体的、文档里不会写的坑。第一个坑检索 query 的改写被忽略。用户问它多少钱模型直接拿它多少钱去检索召回一堆无关内容。正确做法是让模型在检索前先把 query 改写成自包含的形式比如iPhone 15 Pro 的价格是多少。这个改写步骤能显著提升召回质量但很多人忘了加。第二个坑多轮对话里的指代消解。用户先问A 产品怎么样再问那 B 呢。第二轮的B如果不结合上下文检索会跑偏。我的做法是在任务层维护一个对话实体表把提到的实体记下来检索前做指代替换。第三个坑检索结果的时效性。知识库里有旧版本文档和新版本文档检索时可能召回旧的。我在证据层加了时间戳并在 Prompt 里要求优先使用时间较新的文档。对于政策、价格这类强时效内容这个处理很关键。第四个坑并发下的上下文串扰。早期我们没做好会话隔离高并发时出现过 A 用户的检索结果串到 B 用户上下文里的严重问题。后来给每个会话加了独立的上下文空间才解决。这个坑不踩一次很难想到。Agentic RAG 这个方向工程细节远比概念重要。八条规则说到底就是一句话让模型在该检索的时候检索、该停的时候停、该诚实的时候诚实。听起来简单但每一条背后都是一堆线上事故换来的。你在落地时如果能把这几条守住基本就能避开 80% 的坑。剩下的 20%就得靠你自己的业务场景去磨了。
Agentic RAG 工程落地八条硬规则：从检索决策到上下文工程与幻觉治理
1. 为什么能检索不等于能干活Agentic RAG 的定位问题很多人第一次听到 Agentic RAG脑子里浮现的画面是给 RAG 加个 Agent 壳子。这个理解不算错但太浅了。真正落地过一两个项目之后你会发现Agentic RAG 要解决的根本不是检索得更准这件事而是检索这件事本身该不该发生、发生几次、什么时候停。传统 RAG 的链路是死的用户提问 → 向量化 → 召回 Top-K → 拼进 Prompt → 生成。这条链路里检索是一个无条件执行的固定步骤。问题在于真实业务里至少有一半的 query 根本不需要检索——帮我改写这段话、把上面的结论翻译成英文、这个报错是什么意思这些请求走检索纯属浪费 Token 和时间。反过来另一些 query 一次检索根本不够——对比 A 产品和 B 产品在售后政策上的差异这需要先查 A、再查 B、再对比是一个多跳推理过程。Agentic RAG 的核心变化是把检索从一个固定步骤变成一个由模型自主决策的动作。模型手里握着一组工具检索、计算、调用外部 API、读文件等它自己判断这个问题我要不要检索检索什么检索结果够不够不够要不要换个 query 再来一次什么时候可以收手给答案这就引出了本文要讲的核心——八条工程硬规则。它们不是理论是我在把 Agentic RAG 从 Demo 推到生产环境过程中被线上问题反复教育之后沉淀下来的。关键词里的 ReAct、GraphRAG、上下文工程、Token 用量都会在这八条规则里逐一落地。这篇文章适合两类人一是已经跑通过基础 RAG、想往 Agent 方向演进的同学二是正在做 Agent 产品、被检索失控和Token 爆炸折磨的工程师。我会尽量把每条规则的为什么讲透因为只抄配置不理解原理换个场景就会翻车。2. 规则一先判断要不要检索再谈怎么检索2.1 无脑检索是最大的成本黑洞我见过太多项目上来就是所有 query 先检索一遍再说。这个做法在 Demo 阶段没问题因为 Demo 的 query 都是精心设计的知识问答。但一上生产用户什么都会问。我统计过我们线上一个月的 query 分布真正需要外部知识检索的只占43%剩下 57% 里有闲聊、有指令类请求、有纯推理题、有对上一轮回答的追问。这 57% 的请求如果都走一遍检索代价是什么按每次检索召回 5 个 chunk、每个 chunk 平均 300 Token 算光是把检索结果塞进上下文就是 1500 Token。加上 embedding 调用、向量库查询的延迟单次请求平白多出 300-800ms 和一笔 Token 开销。用户量一上来这就是真金白银。2.2 判断逻辑怎么设计才不误伤判断要不要检索这件事最忌讳用一堆 if-else 硬编码规则。我早期试过关键词匹配包含是什么怎么就检索结果被这个方案怎么优化这种纯推理问题打脸——它不需要检索但命中了关键词。比较稳的做法是让模型自己判断但要给它一个结构化的判断框架。我在 Prompt 里用的是这个三段式在决定是否检索前请依次判断 1. 这个问题是否依赖我训练数据之外、且可能随时间变化的私有知识 2. 如果我不检索直接回答是否会因为信息缺失而给出错误或过时的答案 3. 用户是否明确要求基于某个文档/资料回答 只有第 1 或第 3 条为真时才触发检索。这个框架的关键在于第 2 条是一个反向验证。很多模型倾向于能检索就检索加上这条不检索会不会错的自问能显著降低过度检索率。实测下来过度检索率从 38% 降到了 11% 左右。注意判断这一步本身也要花 Token。如果你的场景 query 量极大、单次价值很低可以考虑用一个更小的模型比如 7B 级别专门做这个路由判断把大模型留给真正需要推理的环节。这是典型的用小模型省钱、用大模型保质的分层策略。2.3 一个容易被忽略的中间态判断不是二元的检索/不检索。我后来加了一个中间态澄清式追问。当模型判断这个问题可能需要检索但当前 query 信息不足以确定检索什么时它应该先反问用户而不是瞎检索一通。比如用户问这个政策什么时候生效模型不知道这个政策指哪个直接检索只会召回一堆不相关文档。正确做法是追问您指的是哪份政策文件。这一步能砍掉大量无效检索代价只是多一轮对话。3. 规则二检索次数必须有硬上限且要能刹车3.1 ReAct 循环失控是 Agentic RAG 的头号事故ReActReasoning Acting范式让模型可以想一步、做一步、再看结果想下一步。这个循环很强大但它的致命问题是模型可能永远停不下来。我遇到过最夸张的一次模型为了回答一个简单的产品参数问题连续检索了 17 次每次换个 query 角度最后 Token 烧了 4 万多答案还是错的。为什么会这样因为 ReAct 的每一步都是模型基于当前上下文做决策而检索回来的内容往往会引入新的待确认信息模型就会想我再查一下这个。这是一个正反馈循环没有外力干预就会一直转下去。3.2 刹车机制的三层设计我的做法是给检索循环设三道刹车任何一道触发就强制收敛刹车层触发条件触发后的动作次数刹车检索调用达到 N 次我设的是 5强制进入生成阶段用已有信息作答收益刹车连续 2 次检索召回内容与已有上下文重复度 70%判定为检索无新增信息停止时间刹车单次请求总耗时超过 T 秒我设的是 15s中断循环返回当前最优答案次数刹车最好理解但 N 设多少有讲究。设太小比如 2多跳问题答不好设太大比如 10成本和延迟失控。我试过 3、5、8 三档5 是复杂问答场景的甜点值——足够覆盖大部分 2-3 跳的问题又不至于让简单问题被拖累。收益刹车是最有价值的一道。它的逻辑是如果新检索回来的东西和已经有的信息差不多那再检索下去也没意义。实现上可以用一个简单的相似度计算把新召回的 chunk 和上下文里已有的 chunk 做比对。这道刹车能砍掉大量无效勤奋。3.3 刹车不是粗暴截断要留体面退出强制刹车之后不能让模型直接吐一个我查不到了。正确做法是在刹车触发时给模型注入一条系统提示检索预算已用尽。请基于当前已获取的信息给出最佳答案 并明确标注哪些部分是基于已有信息的推断、哪些部分信息不足。 不要编造未检索到的内容。这样即使信息不全用户也能得到一个诚实的、有边界感的回答而不是一个自信的幻觉。这一点在客服、医疗、法律这类场景里尤其重要。4. 规则三上下文工程决定成败而不是模型能力4.1 检索回来的东西怎么摆比摆什么更重要上下文工程Context Engineering这个词这两年很火但很多人把它理解成写 Prompt 的技巧。在 Agentic RAG 里它的核心是如何把多轮检索的结果、推理过程、工具返回组织成一个模型能高效利用的上下文结构。我做过一个对比实验同样的检索结果、同样的模型只是改变上下文的组织方式答案准确率差了23 个百分点。这个差距比换个更强的模型带来的提升还大。4.2 我的上下文分层结构经过反复调整我固定下来一套四层结构从下到上依次是系统层角色定义、行为约束、输出格式要求。这部分固定不变放在最前面。任务层当前用户 query 对话历史摘要。注意是摘要不是原始历史否则上下文会被历史撑爆。证据层检索回来的文档片段。每个片段必须带来源标记文档名、段落位置方便模型引用和用户溯源。推理层模型自己的思考过程ReAct 的 Thought 部分。这部分要保留因为它帮助模型保持推理连贯性。关键细节在证据层。我要求每个检索片段都带上一个相关性标注——是模型在检索后自己打的高/中/低。生成时模型会优先使用高相关片段中相关作为补充低相关直接忽略。这个小小的标注让模型在信息过载时有了取舍依据。4.3 Token 预算的分配艺术上下文窗口是有限的Token 是要花钱的。我给自己定的预算是系统层不超过 500 Token任务层不超过 1000 Token证据层不超过 3000 Token推理层不超过 1500 Token给输出留 2000 Token。加起来 8000 Token 左右是一个成本和效果的平衡点。证据层这 3000 Token 怎么分如果召回了 10 个片段不能平均分。我的做法是按相关性加权分配高相关的片段给足空间每个 500 Token中相关的压缩每个 200 Token低相关的直接截断到 100 Token 或丢弃。这样保证最有价值的信息不被稀释。提示Token 用量监控一定要做。我见过团队上线后才发现单次请求平均消耗 1.2 万 Token成本是预算的 3 倍。建议在每次请求结束时记录 input/output Token 数按天聚合设一个告警阈值。5. 规则四GraphRAG 不是万能药用错场景就是负优化5.1 什么时候该上 GraphRAGGraphRAG 这两年被吹得很凶好像不做图谱就落伍了。但我踩过的坑告诉我大部分场景用不上 GraphRAG硬上只会增加复杂度和成本。GraphRAG 真正发挥价值的场景有一个共同特征问题需要跨多个文档、多个实体做关联推理。比如我们公司哪些供应商同时给 A 部门和 B 部门供货且这些供应商里有财务风险的这种问题需要把供应商、部门、财务状态三类实体连起来看纯向量检索很难搞定因为答案不在任何一个文档里而在文档之间的关系里。反过来如果你的场景是查一下 XX 产品的保修政策这就是一个单点查询向量检索又快又准上 GraphRAG 纯属杀鸡用牛刀。5.2 图谱构建的成本账GraphRAG 的成本主要在构建阶段。你需要实体抽取用 LLM 跑一遍所有文档、关系抽取、图谱存储、社区检测用于生成摘要。我做过一个测算10 万篇文档的图谱构建光 LLM 调用成本就是纯向量索引的8-15 倍构建时间从几小时变成几天。而且图谱不是建完就完事文档更新时图谱要增量维护实体消歧、关系更新都是麻烦事。所以我的建议是先用向量检索跑通业务当且仅当发现关联推理类问题占比超过 20% 且向量方案明显答不好时再考虑引入 GraphRAG。5.3 混合检索向量 图谱的务实组合如果确实需要图谱能力也不必全盘替换。我现在的做法是混合检索向量检索负责语义相似召回图谱检索负责关系推理召回两路结果在证据层合并由模型判断用哪路。具体实现上我会在路由阶段加一个判断如果 query 里出现关系关联同时对比这类词或者涉及多个实体就同时触发两路检索否则只走向量。这样既拿到了图谱的能力又没让所有请求都背上图谱的开销。6. 规则五工具设计要窄而深不要宽而浅6.1 工具太多模型会选错Agentic RAG 里检索只是工具之一。你可能会给模型配向量检索、关键词检索、图谱查询、数据库查询、计算器、外部 API 等等。工具一多模型的选择困难症就来了。我早期给模型配了 8 个工具结果发现它经常选错——该用向量检索的时候用了关键词检索该查数据库的时候去查了向量库。后来我把工具精简到 4 个并且每个工具的描述写得极其明确选择准确率立刻上来了。6.2 工具描述要写什么时候用而不是是什么这是很多人写工具定义时的通病。看这个反例工具名vector_search 描述向量检索工具用于语义相似度搜索。这个描述只说了是什么模型不知道什么时候该用它。改成这样工具名vector_search 描述当用户问题涉及概念性、描述性、开放性的知识查询时使用 例如XX 是什么XX 的原理关于 XX 的介绍。 不适合精确的数值查询或结构化数据查询。加上什么时候用和什么时候不用模型的选择准确率能提升一大截。这本质上是在帮模型做决策而不是让它猜。6.3 工具返回结果要自解释工具返回给模型的内容不能是一堆裸数据。比如数据库查询返回一个 JSON模型可能看不懂字段含义。我的做法是让工具返回带自然语言说明的结构化结果{ summary: 查询到 3 条订单记录均为 2024 年 3 月创建, data: [...], note: 金额单位为元状态字段 1 表示已完成、2 表示进行中 }这个summary和note字段是给模型看的能显著降低它理解数据的难度减少后续追问。7. 规则六把幻觉当成一等公民来治理7.1 Agentic RAG 的幻觉更隐蔽传统 RAG 的幻觉好识别——答案和检索内容对不上。但 Agentic RAG 的幻觉更隐蔽因为它有推理过程。模型可能检索到了正确信息但在推理环节想歪了得出一个看似有依据、实则错误的结论。我遇到过最典型的一次检索到了A 产品保修 2 年和B 产品保修 3 年模型推理出B 产品保修比 A 产品长 1 年——这个没错。但用户问的是哪个更划算模型接着推理保修长的更划算这就把保修时长和划算划了等号是一个没有依据的推断。7.2 强制引用与溯源治理幻觉的第一招是强制引用。我要求模型在给出任何事实性陈述时必须标注来源片段编号。比如根据 [3]A 产品保修 2 年。这个要求有两个好处一是逼模型确认自己的话有依据二是方便用户和开发者核查。实现上在证据层给每个片段编号然后在输出格式要求里明确每个事实陈述后必须跟 [编号]。如果模型给不出编号说明这个陈述没有依据应该被质疑。7.3 区分事实和推断第二招是要求模型显式区分事实和推断。我在输出格式里规定【事实】基于检索内容可直接得出... 【推断】基于事实的合理推断可能不准确... 【未知】检索内容未覆盖无法回答...这个格式强制模型把不同确定性的内容分开。用户一眼就能看出哪些是可靠的、哪些要打个问号。这个做法在专业场景法律、医疗、金融里几乎是刚需。7.4 检索不到时的诚实兜底最容易被忽略的是当检索确实没找到相关信息时模型应该老实说没找到而不是硬编一个答案。我在系统提示里加了一条硬约束如果检索结果与问题无关或信息不足必须明确告知用户 当前资料中未找到相关信息并建议用户补充信息或换个问法。 严禁在信息不足时编造答案。这条约束配合前面的刹车机制能挡掉大部分一本正经胡说八道的情况。8. 规则七评估体系要能测过程不能只测结果8.1 只看最终答案你永远不知道哪里坏了传统 RAG 评估看的是答案对不对。但 Agentic RAG 是一个多步骤系统最终答案错了可能是判断错了不该检索却检索了、可能是检索错了召回不相关、可能是推理错了信息对但结论错。只看结果你根本不知道优化哪里。我的评估体系分三层决策层检索决策是否正确该检索的检索了、不该检索的没检索。用人工标注一批 query 做基准算准确率。检索层召回内容的相关性。用命中率Hit Rate和 MRR平均倒数排名衡量。生成层最终答案的准确性、完整性、引用正确性。用 LLM-as-Judge 加人工抽检。8.2 决策层的评估最容易被跳过大部分团队只评估检索层和生成层跳过决策层。但决策层恰恰是 Agentic RAG 区别于传统 RAG 的地方。我建议至少标注 200 条 query覆盖需要检索不需要检索需要多跳检索三类定期跑一遍决策准确率。这个指标掉了说明路由 Prompt 或模型出了问题。8.3 用轨迹而不是答案做回归测试每次改 Prompt 或换模型我都会跑一遍回归测试。但测试的不是答案而是完整的执行轨迹模型做了几次检索、每次检索用了什么 query、什么时候刹的车。对比新旧轨迹能看出改动到底影响了哪个环节。这个做法帮我抓到过好几次隐蔽的回归。有一次换了个模型答案准确率没变但平均检索次数从 2.1 涨到了 3.8Token 成本涨了 60%。如果只看答案这个问题根本发现不了。9. 规则八上线不是终点监控和迭代才是9.1 必须监控的四个核心指标Agentic RAG 上线后我盯的是这四个指标指标含义健康区间我的经验值平均检索次数单次请求触发检索的平均次数1.5 - 2.5刹车触发率触发次数/收益/时间刹车的比例 15%平均 Token 消耗单次请求 inputoutput Token按业务定波动 20%无答案率返回未找到相关信息的比例 10%刹车触发率突然升高说明模型陷入了无效检索循环要检查 Prompt 或检索质量。无答案率升高说明知识库覆盖不足或检索召回变差。这些指标比单纯的用户满意度更早暴露问题。9.2 建立坏案例回流机制我要求团队每周整理一批坏案例——用户点了差评的、或者人工抽检发现问题的。每个坏案例都要归因到具体环节是决策错、检索错、还是生成错。归因之后针对性地改 Prompt、补知识库、或者调参数。这个机制的价值在于让优化有方向。没有坏案例回流优化就是拍脑袋。我们靠这个机制三个月把整体准确率从 71% 提到了 86%。9.3 版本管理Prompt 也是代码最后一条经验把 Prompt 当代码管理。每次改 Prompt 都要有版本号、有变更说明、有回归测试结果。我见过团队因为某个人随手改了一句 Prompt导致线上效果集体下滑还找不到是谁改的。我的做法是把所有 Prompt 存在 Git 里每次变更走 Code Review上线前跑回归测试。听起来有点重但比起线上事故的代价这点流程成本完全值得。10. 我在实际落地中踩过的几个具体坑规则讲完了再分享几个具体的、文档里不会写的坑。第一个坑检索 query 的改写被忽略。用户问它多少钱模型直接拿它多少钱去检索召回一堆无关内容。正确做法是让模型在检索前先把 query 改写成自包含的形式比如iPhone 15 Pro 的价格是多少。这个改写步骤能显著提升召回质量但很多人忘了加。第二个坑多轮对话里的指代消解。用户先问A 产品怎么样再问那 B 呢。第二轮的B如果不结合上下文检索会跑偏。我的做法是在任务层维护一个对话实体表把提到的实体记下来检索前做指代替换。第三个坑检索结果的时效性。知识库里有旧版本文档和新版本文档检索时可能召回旧的。我在证据层加了时间戳并在 Prompt 里要求优先使用时间较新的文档。对于政策、价格这类强时效内容这个处理很关键。第四个坑并发下的上下文串扰。早期我们没做好会话隔离高并发时出现过 A 用户的检索结果串到 B 用户上下文里的严重问题。后来给每个会话加了独立的上下文空间才解决。这个坑不踩一次很难想到。Agentic RAG 这个方向工程细节远比概念重要。八条规则说到底就是一句话让模型在该检索的时候检索、该停的时候停、该诚实的时候诚实。听起来简单但每一条背后都是一堆线上事故换来的。你在落地时如果能把这几条守住基本就能避开 80% 的坑。剩下的 20%就得靠你自己的业务场景去磨了。
