1. Agent 场景下 RAG 的定位为什么变了过去两年RAG 这个词被讲得太多以至于很多人一听到就默认是向量库 检索 拼上下文那套老三样。但真正把 RAG 接进 Agent 系统之后你会发现它的角色发生了根本性变化它不再是给大模型喂资料的辅助模块而是 Agent 感知外部世界、做决策、执行动作的核心基础设施之一。这个变化不是概念炒作而是工程上被逼出来的。传统 RAG 的调用链路是线性的用户提问 → 检索 → 拼接 → 生成 → 返回。整个流程里检索是一次性的模型是被动的。但 Agent 不一样Agent 会自己决定我现在需不需要查资料我要查什么查到的结果够不够不够我再换个角度查。也就是说检索从被动触发变成了主动决策从单轮变成了多轮从固定流程变成了动态编排。这就带来一个很现实的问题你原来那套为问答场景设计的 RAG 方案直接搬到 Agent 里大概率会翻车。翻车的表现通常有三种一是检索延迟拖垮整个 Agent 的响应速度因为 Agent 一轮任务可能触发五六次检索二是检索结果质量不稳定Agent 拿到模糊甚至错误的信息后会沿着错误方向继续推理越走越偏三是上下文窗口被检索内容塞满导致 Agent 的推理能力反而下降。所以这篇文章想解决的问题很明确在 Agent 时代RAG 到底该怎么选、怎么搭、怎么调。我会从架构选型、检索策略、知识库组织、性能优化、常见坑这几个维度把我在实际项目里踩过的经验和验证过的方案讲清楚。不管你是刚接触 RAG 的新手还是已经在做 Agent 项目的开发者都能从里面找到可以直接抄作业的部分。提示本文讨论的 RAG 方案适用于企业知识库、文档问答、智能客服、代码助手、数据分析 Agent 等场景不涉及任何敏感领域。2. 先搞清楚你的 Agent 到底需要哪种 RAG选型之前必须先做一件事明确你的 Agent 任务类型。不同类型的 Agent对 RAG 的需求差异极大用错方案比不用还糟糕。2.1 三类 Agent 任务对应的 RAG 需求我把常见的 Agent RAG 组合分成三类你可以对号入座。第一类是事实查询型 Agent。典型场景是智能客服、政策问答、产品手册查询。这类 Agent 的核心诉求是准确检索到的内容必须和用户问题高度相关宁可少答也不能答错。对这类 AgentRAG 的关键指标是召回准确率和答案忠实度检索策略上更适合用混合检索向量 关键词 重排序。第二类是任务执行型 Agent。比如帮你操作数据库、调用 API、生成报表的 Agent。这类 Agent 需要 RAG 提供的是操作知识和参数说明比如某个接口怎么调、某个字段什么含义。它对检索速度要求高因为 Agent 在执行过程中会频繁查询而且检索结果需要结构化最好能直接解析成参数。第三类是推理分析型 Agent。比如做竞品分析、财报解读、技术调研的 Agent。这类 Agent 需要 RAG 提供的是多源、多跳、有关联关系的知识。普通向量检索往往不够用需要引入 GraphRAG 或者本体Ontology结构把实体之间的关系也检索出来。下面这张表可以帮你快速判断Agent 类型核心诉求推荐检索方式关键指标事实查询型准确、忠实混合检索 重排序召回率、忠实度任务执行型快、结构化向量检索 结构化索引延迟、解析成功率推理分析型多跳、关联GraphRAG / 本体检索多跳召回、关系覆盖2.2 为什么不能一套方案打天下我见过太多项目上来就搭一个向量库把所有文档切块丢进去然后指望它什么都能查。结果就是简单问题答得还行稍微复杂一点就开始胡编。原因很简单向量检索的本质是语义相似度匹配它擅长找相似不擅长找关系找精确值找多跳路径。举个例子用户问我们公司去年 Q3 的营收比 Q2 增长了多少这个问题需要的是先找到 Q3 的数据再找到 Q2 的数据然后做减法。向量检索可能只能召回一段包含Q3 营收的文本Q2 的数据如果没被召回Agent 就会瞎猜。这种场景下你需要的是结构化查询或者多跳检索而不是单纯的向量相似度。所以选型的第一步不是选工具而是选策略。工具是策略的载体策略错了工具再好也白搭。2.3 一个实用的判断流程我在实际项目里总结了一个简单的判断流程你可以直接套用先问用户的问题是不是单跳事实型如果是向量检索 重排序基本够用。再问问题里有没有比较计算关联这类词如果有考虑结构化检索或多跳检索。再问Agent 会不会在一轮任务里多次检索如果会必须做检索缓存和延迟优化。最后问知识库里的内容是不是高度结构化表格、图谱、代码如果是别硬塞向量库用对应的结构化方案。这个流程看起来简单但能帮你避开 80% 的选型错误。3. 检索策略的取舍向量、关键词、图谱到底怎么配确定了 Agent 类型之后接下来就是具体的检索策略设计。这部分是 RAG 的核心也是最容易出问题的地方。3.1 向量检索的边界在哪里向量检索的原理是把文本映射成高维向量然后通过余弦相似度找最接近的。它的优势是能理解语义比如用户问怎么退款文档里写的是如何申请退货向量检索能匹配上关键词检索就不行。但向量检索有三个明显的边界。第一它对精确匹配不敏感。比如用户问订单号 12345 的状态向量检索可能召回一堆讲订单状态的文档但就是找不到那个具体订单号。第二它对数值和表格不友好。表格里的数据被切成文本后语义信息大量丢失。第三它的召回质量高度依赖 embedding 模型和切块策略调不好就是看起来能用实际一塌糊涂。我的经验是向量检索适合处理自然语言描述型的知识比如产品说明、政策条款、操作指南。对于编号、日期、金额、代码这类精确信息一定要配合关键词检索或结构化查询。3.2 混合检索为什么是当前最稳的方案混合检索就是把向量检索和关键词检索通常是 BM25的结果融合起来取长补短。它的逻辑是向量负责语义召回关键词负责精确召回两者互补。具体怎么做常见的有两种融合方式。一种是加权求和给向量得分和关键词得分各分配一个权重然后加总排序。另一种是倒数排名融合RRF不看具体得分只看排名把两个列表的排名做融合。RRF 的好处是不用调权重鲁棒性更好我一般优先推荐。实际配置上我通常这样设向量检索召回 top 20关键词检索召回 top 20融合后取 top 10 送重排序重排序后取 top 3 到 5 条拼进上下文。这个参数不是固定的要根据你的知识库规模和 Agent 的上下文预算来调。注意混合检索的收益在知识库越大、问题越多样时越明显。如果你的知识库只有几十篇文档单纯向量检索可能就够了上混合检索反而增加复杂度。3.3 GraphRAG 和本体 RAG 适合什么场景GraphRAG 这两年被讨论得很多它的核心思路是把知识抽成实体和关系构建成图检索时不仅找相关文本还找实体之间的关联路径。本体 RAG 类似但更强调预先定义好的本体结构比如产品-属性-值这种 schema。它们适合什么场景我总结下来是三种一是需要多跳推理的比如A 公司的 CEO 之前在哪家公司任职二是需要全局摘要的比如这份报告的主要结论有哪些三是知识之间有强关联的比如医疗、法律、金融领域的知识图谱。但 GraphRAG 的代价也很明显构建成本高需要做实体抽取和关系抽取抽取质量直接决定效果更新维护麻烦知识一变图就要重建检索延迟通常比向量检索高。所以我的建议是除非你的场景确实需要多跳和关联否则别一上来就上 GraphRAG。先用混合检索跑通遇到瓶颈再考虑升级。3.4 检索策略对比表策略优势劣势适用场景纯向量语义理解好、实现简单精确匹配弱、表格不友好自然语言问答纯关键词精确、快语义理解差编号、代码查询混合检索互补、鲁棒需要调参大多数通用场景GraphRAG多跳、关联强构建维护成本高推理分析型 Agent本体 RAG结构清晰、可控需要预定义 schema垂直领域知识库4. 知识库组织切块、索引、更新的实操细节检索策略定了接下来是知识库本身怎么组织。这部分看起来是脏活累活但实际上决定了 RAG 效果的上限。检索策略再好知识库组织得烂也救不回来。4.1 切块策略不是越小越好切块chunking是 RAG 里最容易被忽视、又最影响效果的环节。很多人默认按固定字数切比如每 500 字一块结果切出来的块要么语义不完整要么包含多个主题。我的经验是切块要跟着文档结构走。如果文档有标题层级就按标题切每个小节一块如果文档是问答对就按问答对切如果文档是代码就按函数或类切。固定字数切块只适合那种没有明显结构的纯文本。块的大小也有讲究。太小语义不完整检索出来断章取义太大包含噪声多检索精度下降。我一般把块控制在 200 到 500 字之间同时保留一定的重叠overlap通常是块大小的 10% 到 20%避免边界信息丢失。还有一个技巧给每个块加上上下文头比如所属文档标题、章节路径。这样即使块本身语义不完整检索时也能通过上下文头补全信息。4.2 元数据设计让检索多一层过滤元数据是提升检索精度的利器。所谓元数据就是给每个块附加的结构化信息比如来源文档、创建时间、文档类型、所属部门、权限等级。有了元数据检索时就可以先过滤再检索。比如用户问最新的退款政策你可以先用元数据过滤出政策类 最近半年的文档再在里面做向量检索。这样既提升了精度又减少了检索范围速度也更快。元数据设计的原则是只加真正会用到的字段。加太多字段维护成本高而且很多字段根本用不上。我通常至少会加这几个来源、时间、类型、权限。权限这个尤其重要Agent 如果接入了多部门知识库必须做权限隔离否则会泄露信息。4.3 增量更新别每次都全量重建知识库不是一次建好就完事的它会不断更新。如果每次更新都全量重建索引成本高、耗时长而且期间服务不可用。正确的做法是做增量更新。具体来说给每个文档记录一个版本号或更新时间戳更新时只处理变化的文档删除旧索引插入新索引。向量库一般支持按 ID 删除和插入所以增量更新是可行的。但增量更新有个坑如果文档的切块策略变了或者 embedding 模型换了那就必须全量重建因为新旧向量不在同一个语义空间里混在一起检索会出问题。所以每次改切块策略或换模型都要规划好重建窗口。4.4 知识库组织的常见错误我列几个我见过最多的错误你可以对照检查切块按固定字数不考虑文档结构导致语义断裂。不加元数据检索时无法过滤精度上不去。全量重建太频繁服务不稳定。不做去重同一内容多个版本都在库里检索结果重复。不做质量过滤把 OCR 错误、乱码、无关内容也塞进库。这些问题看起来小但每一个都会实打实地拉低 RAG 效果。5. Agent 场景下的性能与延迟优化Agent 和普通问答最大的区别之一就是它会频繁调用检索。一轮任务下来检索可能被触发好几次。如果每次检索都要几百毫秒甚至几秒整个 Agent 的体验就会非常差。所以性能优化在 Agent 场景下不是可选项是必选项。5.1 检索缓存最直接有效的优化缓存是性价比最高的优化手段。Agent 在任务执行过程中经常会重复查询相似甚至相同的内容。比如它先查退款流程过一会儿又查退款需要多久这两个查询的检索结果高度重叠。缓存的设计有两种粒度。一种是查询级缓存把用户查询的 embedding 或查询文本作为 key检索结果作为 value 缓存起来。另一种是块级缓存把常用的块缓存在内存里检索时优先从内存取。查询级缓存要注意失效策略。如果知识库更新了缓存必须失效否则会返回旧结果。我一般给缓存设一个较短的 TTL比如 5 到 10 分钟同时监听知识库更新事件更新时主动清缓存。5.2 并行检索与预取Agent 有时候会同时需要多个来源的信息。比如它要对比两个产品的参数就需要分别检索两个产品的文档。这种情况下串行检索会很慢应该改成并行。并行检索的实现不难把多个检索请求同时发出去等所有结果回来再合并。但要注意控制并发数并发太高会打爆向量库或 embedding 服务。我一般把并发控制在 4 到 8 之间根据后端承载能力调。预取是另一个技巧。如果 Agent 的任务流程是可预测的比如它一定会先查产品信息再查价格那就可以在查产品信息的同时提前把价格信息也检索出来。这样等 Agent 真正需要时结果已经在缓存里了。5.3 上下文预算管理Agent 的上下文窗口是有限的检索结果塞太多会挤占推理空间。所以必须做上下文预算管理。我的做法是给检索结果分配一个固定的 token 预算比如总窗口的 30%。然后在这个预算内按相关性排序优先放最相关的块。如果预算不够就截断或摘要。摘要是个好办法。对于长文档可以先让模型生成一个摘要检索时返回摘要而不是全文。这样既保留了关键信息又节省了 token。但摘要会损失细节所以适合那种只需要大概了解的场景不适合需要精确引用的场景。5.4 性能优化对照表优化手段收益代价适用场景查询缓存高需要失效策略重复查询多块级缓存中内存占用热点知识集中并行检索高并发控制多源检索预取中可能浪费流程可预测上下文预算高可能丢信息上下文紧张结果摘要中损失细节长文档场景6. 踩坑实录那些让我熬夜排查的 RAG 问题这部分我讲几个真实踩过的坑都是文档里不会写、但实际项目中一定会遇到的。6.1 检索命中率忽高忽低有一次上线后发现检索命中率白天正常晚上就掉得厉害。排查了半天最后发现是 embedding 服务在高峰期被限流导致部分查询的 embedding 质量下降检索结果自然就差了。这个坑的教训是embedding 服务必须做监控和降级。监控要覆盖延迟、错误率、限流次数。降级方案可以是切换到备用模型或者临时降级为关键词检索。千万别让 embedding 服务成为单点。6.2 Agent 拿到错误信息后越走越偏Agent 有个特点它会基于检索结果继续推理。如果检索结果错了它会沿着错误方向一路走下去最后给出一个看起来很有道理、但完全错误的答案。这个问题很难完全避免但可以缓解。我的做法是在 Agent 的提示词里明确要求它对检索结果保持怀疑如果多个来源冲突要指出冲突而不是随便选一个。另外可以加一个置信度检查步骤如果检索结果的相似度得分普遍偏低就让 Agent 主动说我不确定而不是硬答。6.3 知识库更新后旧答案还在这个坑很典型。知识库更新了但用户还是收到旧答案。排查发现是缓存没失效而且向量库里旧块没删干净。解决方法是更新流程必须包含删旧 插新 清缓存三步缺一不可。而且要有校验机制更新后随机抽几个查询验证结果是否更新。我一般会写一个自动化脚本每次更新后跑一遍回归测试。6.4 上下文被检索结果塞爆有一次 Agent 突然开始胡言乱语排查发现是检索返回了太多块把上下文窗口塞满了导致模型没有空间做推理。这个问题的根源是检索返回的块数没有上限。解决方法是给检索结果设一个硬上限比如最多返回 5 个块每个块最多 500 token。超过就截断。同时监控上下文的 token 占用超过阈值就告警。6.5 多轮检索时结果重复Agent 多轮检索时经常会召回相同的块导致上下文里重复内容很多浪费 token。解决方法是在检索层做去重。可以按块 ID 去重也可以按内容相似度去重。我一般用块 ID 去重简单可靠。如果块 ID 不稳定就用内容哈希去重。7. 从零搭一个 Agent 可用的 RAG 的完整路径讲了这么多原理和坑最后给一个可落地的搭建路径。这套路径我在多个项目里验证过适合大多数 Agent RAG 场景。7.1 环境与组件选型组件选型上我的建议是向量库中小规模用 FAISS 或 Chroma大规模用 Milvus 或 Qdrant。Embedding 模型中文场景优先选中文优化过的模型英文场景选通用模型。如果对延迟敏感选小模型如果对精度敏感选大模型。关键词检索BM25 是标配Elasticsearch 或 OpenSearch 都支持。重排序用 cross-encoder 类模型效果比向量相似度好很多。编排框架LangChain、LlamaIndex 都可以选你团队熟悉的。选型的原则是先用最简单的组件跑通遇到瓶颈再换。别一上来就堆最复杂的架构那样调试成本太高。7.2 搭建步骤文档预处理解析文档PDF、Word、HTML 等提取文本和结构信息。切块按文档结构切块加元数据和上下文头。向量化用 embedding 模型把块转成向量存入向量库。建关键词索引把块存入 BM25 索引。实现混合检索向量检索 关键词检索用 RRF 融合。加重排序对融合结果做重排序取 top N。接入 Agent把检索封装成 Agent 可调用的工具支持多轮调用。加缓存和监控查询缓存、延迟监控、命中率监控。回归测试建一个测试集每次更新后跑一遍。7.3 上线后的持续优化上线不是终点是起点。持续优化要关注几个指标检索命中率、答案忠实度、平均延迟、缓存命中率、上下文占用率。这些指标要建 dashboard定期看。优化的方向通常是调切块策略、换 embedding 模型、调检索参数、加元数据过滤、优化缓存策略。每次只改一个变量改完跑回归测试确认有效再继续。8. 一些个人体会做 Agent RAG 这几年我最大的体会是RAG 不是一个装好就能用的组件它是一个需要持续调优的系统。同样的方案在不同的知识库、不同的 Agent 任务上效果可能差很多。所以别指望抄一套配置就万事大吉一定要结合自己的场景去调。另一个体会是简单方案往往比复杂方案更稳。我见过太多项目一上来就上 GraphRAG、上多路召回、上各种花哨的重排序结果调都调不动。反而是那些老老实实用混合检索 重排序的项目跑得最稳。复杂方案不是不能用而是要在简单方案遇到瓶颈之后再上。最后一个建议一定要建测试集。没有测试集你所有的优化都是盲调。测试集不用很大几十到几百个问题就够但要覆盖你的核心场景。每次改动都跑一遍看指标是涨是跌。这个习惯能帮你省下大量排查时间。