别再跟我提Demo 跑通这种话了。如果你正在做 RAG并且已经意识到单次检索-生成根本扛不住真实业务的复杂指令那你应该对 Agentic RAG 这个名字不陌生。我过去半年把三个 RAG 项目从原型拖进了生产环境最大的体会是凡是把 agentic RAG 当作魔法补丁的团队基本都在上线后一个月内开始返工凡是把它当作一套需要重新设计的系统的团队反而走得稳。这篇文章不聊 PPT 架构图只聊我在 production 环境里实际跑过的 agentic RAG 设计、拆解过的瓶颈、以及踩过的坑。适合已经跑通过基础 RAG、正打算引入 Agent 编排的开发者也适合刚接手知识库项目、想知道该不该上知识图谱的同学。1. 从检索增强到推理增强Agentic RAG 到底解决了什么问题1.1 传统 RAG 的隐形天花板传统 RAG 的流程大家都很熟用户提问系统把问题向量化从向量数据库里召回 Top-K 相关片段拼进 prompt交给大模型生成答案。这个流程在文档质量高、问题类型单一的场景下表现不错但一旦进入生产你会遇到三类用户根本不会同情你的问题。第一类是多跳问题。比如用户问我们上季度营收增长最快的产品线它的负责人是谁这个问题的答案分散在三份文档里一份是季度财报一份是组织架构调整通知。单次检索最多只能命中其中一个片段大模型拿到不完整信息只能硬编。第二类是带约束的问题。用户说不要用 2023 年之前的数据也不要考虑已经停产的SKU传统 RAG 的检索器根本不理解这个约束照旧把过期文档捞上来。第三类是需要对比分析的问题。用户拿两份合同让你找差异传统流程需要先定位两份文档再逐条比这不是一次向量检索能完成的。这些问题的共性是单次检索-生成循环表达能力不够。传统的做法是通过更复杂的 prompt 硬撑或者把检索到的更多片段一次性塞进去但前者不稳定后者不但成本高而且超过上下文窗口后反而引入噪声。本质上传统 RAG 是一个开环系统——检索完就生成没有校验没有反馈错了就错了。1.2 Agentic RAG把一次问答变成多步工作流Agentic RAG 的核心变化是给 RAG 加上了推理、规划、决策和验证的循环。它不再是一次检索就收工而是把用户问题拆解成子任务按需调用不同的工具向量检索、知识图谱查询、SQL 查询、外部 API每拿到一步结果先判断信息够不够、冲不冲突再决定是继续检索还是直接回答。我用一个实际例子说明。用户的问题是对比 A 和 B 两份合同在付款条款上的差异并指出对我方不利的地方。在 Agentic RAG 架构下系统首先规划出三个子任务定位合同 A、定位合同 B、提取并比对付款条款。然后它调用检索工具分别找到两段文本再交给大模型做结构化对比。如果比对过程中发现某段原文缺失或模糊Agent 会主动发起补充检索而不是硬着头皮生成。这个主动补充检索的能力就是关键。传统 RAG 是被动的用户给什么就答什么Agentic RAG 是主动的系统自己评估当前信息是否充分再决定下一步动作。这个动作可能是一次新的检索可能是一个知识图谱查询也可能只是向用户确认意图。1.3 哪些场景真正需要 Agentic RAG不是所有场景都值得上 Agentic RAG。我在实际项目中总结过一个判断清单问题是否天然多跳如果 80% 的问题都能靠单次检索命中那你需要的不是 Agentic RAG而是更好的分块和 embedding 调优。是否涉及多个异构数据源比如同时要查文档库、数据库、API 接口这类场景适合用 Agent 做统一的路由和调度。是否需要多轮交互澄清如果用户的问题常常信息不全Agent 可以通过反问来补全信息这是传统 RAG 做不到的。答案的准确率要求有多高如果错误答案会造成严重业务影响那 Agent 的验证和纠错环节就是刚需。我的建议是先用普通 RAG 跑通基线把能优化的问题都优化一遍分块策略、embedding 模型、重排序发现仍有 15%-20% 的难题解不掉再引入 Agentic 编排。直接一上来就做 Agentic RAG等于在没学会走之前先学跑后面排查问题会非常痛苦。2. 核心设计思路拆解Agent 如何会查资料、会判断、会兜底2.1 检索策略从单路召回到多路融合Agentic RAG 的检索层和传统 RAG 有个本质区别它不是一次检索就把所有希望寄托在上面而是每次检索都带着明确的任务目标。我在生产项目里的做法是设计一个多路召回 重排的检索策略。多路召回一般包含三路关键词检索BM25向量检索Embedding如果接入了知识图谱还有图谱查询。BM25 保证精确匹配向量检索保证语义泛化图谱查询保证关系推理。三路结果拿回来后用一个重排模型cross-encoder做融合。我测试下来这个策略对比单纯向量检索在真实业务数据上的 Recall10 能提升 12-18 个百分点。但多路召回也带来一个头疼的问题延迟。三路查询如果串行跑一次检索就是三次响应时间。我的优化方案是使用并行调用asyncio.gather同时发起三路查询取最慢的一路作为总延迟基准。实测下来在单路 200ms 的典型耗时下并行多路召回的总延迟可以控制在 280-350ms几乎和单路向量检索差不多但召回质量提升明显。2.2 路由与工具调用别让 Agent 瞎拿锤子Agentic RAG 里最容易被忽视的是路由器Router。路由器决定了一个问题该走哪条工具链——是直接向量检索还是先做 SQL 查询还是调外部 API还是干脆不需要检索大模型直接回答比如闲聊类问题。我在生产环境踩过一次大坑最初我用一个大模型 prompt 同时做路由和回答结果复杂问题来了模型经常图省事只做一次向量检索就急着回答导致答案质量大幅下降。后来我把路由独立出来成了一个专门的小模型任务——一个参数只有 70 亿的模型专门用来做意图分类和工具选择效果反而比大模型混合路由稳定得多。关于工具设计我给一个建议工具的粒度要中等。工具太粗比如只提供一个搜索全部资料Agent 无法精细控制工具太细比如提供 20 个细分类别的检索工具Agent 的决策空间太大容易选错。我最终收敛到 4-6 个工具比如检索产品文档检索合同条款查询数据库指标获取实时价格每个工具的 description 写清楚它擅长什么、不擅长什么。这个 description 比工具本身还重要因为大模型是靠 description 来选工具的。2.3 推理循环与控制设置刹车别让 Agent 无限跑Agentic RAG 引入了一个传统 RAG 没有的问题你的 Agent 可能陷入死循环。比如它反复检索同一份文档或者在一个问题上无限细化每次都生成再查一下的结论。这不仅浪费 token更糟糕的是会把延迟拖到用户无法忍受。我给生产环境设定的控制参数是最大迭代步数 5 步。每步到达后系统会做一个信息充分度判断——把当前所有检索到的上下文拿到大模型那里让它判断这些信息是否足以回答用户问题输出 yes/no。如果 yes停止循环进入生成阶段如果 no才继续下一步检索。为什么要设 5 步因为我在离线评测里统计过95% 的测试问题都能在 3 步内解决5 步是留的缓冲。超过 5 步的问题大多数是检索策略不对靠无限循环解决不了。另外每个 Agent 循环步都有一个证据覆盖检查检查当前答案的每一个陈述点是否对应上了某段检索到的原文。如果某个陈述点找不到原文支撑就标记为unverified并要求 Agent 补充检索。这个检查就像一个工程质量检查员能够显著降低幻觉比例。2.4 记忆与上下文管理别把上下文窗口当仓库Agentic RAG 每多跑一步就会多产生一些中间结果。如果不加管理几轮迭代下来上下文里全塞满了检索片段到最后一步真正重要的信息可能只占很小一部分。我的做法是引入上下文压缩器context compressor。每一轮检索完所有新检索到的片段不是直接追加到对话历史里而是经过一个压缩步骤把可能相关的关键句提取出来去掉无关部分只保留与当前任务相关的 2-3 个片段。压缩器本身可以用一个小模型或者复用路由器的模型。实测这个做法能把最终生成阶段的上下文缩减 60% 以上而且答案质量不降反升——因为噪声少了。另外一个经验是关于长期记忆与短期记忆的区分。短期记忆是当前任务的查询历史和中间结果长期记忆可以是用户的历史偏好或项目级知识库。Agentic RAG 生产系统应该把这两者分开存储否则长期记忆的噪声会影响短期任务的判断。我在项目里用的是向量库存长期偏好用 Redis 存短期会话状态两者不混用。3. 生产环境实战从 Demo 到线上系统的关键一跃3.1 延迟预算与异步架构设计Agentic 四步循环每步涉及一次 LLM 调用 一次检索叠加起来最坏情况可能超过 15 秒。用户根本等不了。生产环境必须做延迟预算管理。我的经验是按照用户预期把延迟分成三档简单问题需要 2 秒内回答中等问题 5 秒内复杂问题可以接受 10 秒但要有流式输出兜底。为此我在路由阶段就根据意图打了复杂度预估标签不同复杂度走不同策略简单问题直接走单次检索不做循环中等问题最多跑 2 步复杂问题才允许完整的 5 步循环。另一个关键技术是流式输出。Agent 在执行循环时前端可以先把正在检索合同一……正在比对条款……这样的事件流推给用户。用户看到的不是一片空白而是 Agent 的工作过程。体感上就算总延迟 8 秒有流式中间态也比什么都没看到等 5 秒强得多。这个实现不算复杂本质是后端从 REST 换成 WebSocket 或 SSE把 Agent 的每一步状态作为事件推送。3.2 评测体系没有指标别谈上线生产环境的 Agentic RAG 必须做评测。但评测维度和传统 RAG 不太一样我把它拆成三层指标。第一层是检索指标RecallK、MRR。第二层是生成指标答案的忠实度faithfulness找出答案中哪些陈述没有得到原文支持、答案完整性completeness对比参考答案检查是否漏掉了关键点、答案有用性helpfulness人工标注或 LLM-as-judge 打分。第三层是流程指标平均迭代步数、工具调用成功率、死循环率、超时率。这里我想提一个坑。最初我们用 LLM-as-judge 做生成质量打分结果得分虚高——大模型给同为大模型的回答手下留情。后来我们引入了参考标准答案用 RAGAS 框架的忠实度指标做自动化评测再配合每个月人工抽检 100 条才得到真实的质量数据。建议所有做 agentic RAG 的团队至少搭一个 200 条以上的回归测试集每次改动知识库或 prompt 后跑一遍全量回归防止按下葫芦浮起瓢。3.3 性能优化缓存、并发与资源控制Agentic RAG 的生产成本是普通 RAG 的 3-5 倍。一个查询可能产生 8-10 次大模型调用如果遇到恶意刷接口账单直接起飞。我的第一道防线是缓存。对检索结果做语义缓存如果用户的新问题和某个历史问题的 embedding 相似度超过 0.92可以直接复用当时的回答。实测下来这类重复问题的命中率在 10%-20% 之间能省不少 token。第二道防线是并发控制。Agent 的每一步都可能调 LLM而 LLM 接口有 QPS 限制。我用的是令牌桶算法做限流每个用户的并发 Agent 执行数不超过 2全局并发不超过 20。超出限制直接排队而不是让用户无限等下去。第三道防线是成本告警。对每个 Agent 循环的 token 消耗做追踪当单次查询的 token 数超过预设阈值比如 5000时自动降级为精简模式——跳过压缩器缩短最大步数甚至直接走单次 RAG 兜底保证用户能拿到答案而不是吞掉一个超贵账单。3.4 Embedding 与知识库运维上线之后才是开始很多团队的 RAG 项目死在上线后没人管。文档更新了、旧版本内容变了但向量库里的 embedding 还是旧的。用户问的都是新内容检索出来的全是旧片段。对这个问题我现在的运维标配是定时重建增量更新两条腿走路对于新增文档走增量管道做 embedding 入库对于大规模改版比如季度文档整体更新每月做一次全量重建。同时给每个 embedding 打上版本号知识库的每条记录都记录是哪个 embedding 模型生成的。这样模型升级时能精确找出需要重新 embedding 的记录而不是盲目全量重建省下大量算力。Mac 本地搭建时同样的思路也适用。我有段时间在 MacBook Pro 上直接跑知识库测试用 Ollama 跑 embedding 模型比如 nomic-embed-text加 SQLite-VSS 做向量存储几百条测试文档完全跑得动。所以如果你只是验证 RAG 逻辑先在 Mac 本地用小规模数据把链路跑通再上云扩展这比一上来就搭分布式向量库要务实得多。4. 知识库选型RAG、知识图谱与结构化知识库到底怎么选4.1 RAG 知识库最适合非结构化文本的默认选择项目里最常被问到的一个问题RAG 知识库到底能存图片吗答案是——能但不是你以为的那种存法。向量库存图片的思路是图生文先让一个多模态模型把图片转成文本描述caption再把这个描述文本 embedding 入库。查询时用户用自然语言检索命中文本描述再把原图返回给用户展示。这种方案的优点是实现简单缺点是精度受限于模型对图片的理解能力。如果你的场景是按内容搜图片这个方式基本够用但如果你要按像素特征搜图比如找相似 logo那就该用真正的多模态 embedding 模型了比如 CLIP 这类模型直接对图片和文本做联合向量化。做 RAG 知识库时文档类PDF、Word、网页永远是主力图片和音频只能算附件型知识。4.2 知识图谱KG知识库多跳关系的救星知识图谱和 RAG 的区别在哪里一句话RAG 是找一段话KG 是找一条关系路径。当你的业务问题集中在关系推理上比如某供应商还给我们哪些项目供过货两个部门之间有哪个项目重叠这个异常指标是否和近期的组织调整有关RAG 往往会因为信息分散而答得模模糊糊而知识图谱可以直接沿着关系边做多跳查询给出精确路径。但知识图谱有个生产环境的大坑构建和维护成本极高。你需要从非结构化文档里抽取实体和关系做实体对齐解决张三和张总是同一个人的问题、做关系消歧、设计本体ontology。我在项目里给客户做过一个供应商关系图谱光实体抽取和清洗就跑了两周后续每次新文档进来还要跑增量抽取和冲突检测。我的建议是RAG 和 KG 不是替代关系而是配合关系。当问题是一个纯文本理解型问题比如合同条款的含义走 RAG当问题是一个关系查询型问题比如组织架构里的汇报关系走 KG。在 Agent 的工具列表里同时挂上这两个工具让路由器决定调用哪个。这个方案业内有个名字叫 GraphRAG本质就是非结构化文档做索引 结构化关系做推理的混合架构。4.3 结构化知识库为什么我还是留了一张 SQL 表这里要提醒一件事不要什么知识都往向量库里塞。我看到太多团队把业务数据库里的表格数据比如销售明细、库存数量也做 embedding 进 RAG然后让大模型做计算。先不说计算的准确性没有保障单是哪个月销量最高这类问题向量检索根本不适合——它适合文本相似度不适合数值聚合。正确的做法是能查结构化数据库的直接让 Agent 生成 SQL 查询。我的工具列表里始终保留一个数据库查询工具Agent 根据用户问题生成 SQL执行后把结果集交给大模型做总结。实测这个方案查上季度销量 Top3 的产品这类问题的准确率接近 100%而走向量检索的方案正确率只有 60% 左右还得靠大模型硬算。所以分清楚场景精确查询走 SQL非结构化理解走 RAG关系路径走 KG。三者通过 Agent 统一编排才是一个生产级系统该有的形态。4.4 本体Ontology设计给知识图谱套上骨架知识图谱里的本体设计很容易被忽略但很关键。ontology 其实就是知识图谱的类型系统——规定有哪些实体类型人、组织、产品、项目、哪些关系类型属于、负责、参与、供应以及每种关系连接哪些实体类型。没有 ontology知识图谱就是一团乱麻用 ontology 约束知识图谱才能稳定成长。一个实用的最小化 ontology 设计案例供应商项目场景可以用四类实体供应商、项目、产品、区域、五种关系供应商供应产品、项目使用产品、项目归属区域、供应商负责区域、产品属于产品线。就这么简单的本体配合 LLM 从文档中抽取知识图谱就能回答某区域下用到的所有产品有哪些供应商这类问题。Agent 与知识图谱的交互方式我用了两种。一种是先让 Agent 把自然语言问题转成图谱查询语句比如 Cypher 查询直接查询。另一种是把图谱的 schema 描述给大模型大模型根据 schema 自己决定怎么遍历。前者精确但依赖转换质量后者灵活但容易跑偏。生产我推荐前一种为主加上 schema 描述作为 Agent 的上下文让转换质量更高一些。5. 常见问题排查实录与避坑清单5.1 检索召回率低多半不是模型问题是切分问题如果你发现检索出来的片段和问题有关系但不精准八成问题出在 chunk 切分上。我在项目里的经验是chunk 切分必须考虑文档结构而不是按固定字数硬切。对于合同类文档按条数和章节切对于技术文档按标题层级切对于 FAQ按问答对切。另一个容易被忽视的是元数据。给每个 chunk 打上文档来源、章节标题、页码、更新时间等元数据检索时就可以做前置过滤。举个例子用户查 2024 年的政策检索时直接通过元数据过滤掉 2023 年的 chunk比纯靠语义匹配精准得多。这类以metadata 为主的过滤比多塞几个 chunk 更好用既省钱又提升精度。5.2 幻觉控制不住引入引用溯源和忠实度检查关于幻觉控制我会坦诚我试过很多土办法都不算太理想。如果你用的是普通 RAG幻觉的发生是因为大模型生成时带着上下文不自觉补充细节。在 Agentic 循环里我们可以多做两个动作生成前要求模型只根据检索到的内容作答禁止引入外部知识的表述生成后用忠实度检查模型用一个独立小模型对比生成答案中每个陈述和检索片段的匹配度自动重查一遍。这两招能显著压低幻觉率但没法归零。若业务要求零幻觉恐怕只能在工具设计上做硬约束比如要求以原文引用为主、把需要推理的部分交给确定性代码而不是模型拿主意。5.3 Mac 本地搭建 RAG 知识库的神坑与捷径很多同学在 Mac 上搭建 RAG 知识库卡住的通常不是思路而是环境细节。这里分享几个我试出来的贴合 Mac 的要点embedding 模型建议选小一点的比如 nomic-embed-text 或 bge-small我的 MacBook Air 实测跑几百个文档毫无压力。向量库先用 SQLite-VSS 或 Chroma 就能起步别一上来就上 Milvus 这类重组件。另外一个 Mac 特有问题有些原生库比如某些分词器在 arm64 架构下编译很慢甚至失败。我的建议是尽量用 Python 3.10 的预编译 wheel避免从源码编译。实测这样能把搭环境时间从一晚上缩短到半小时。还有一点Mac 上跑本地 LLMOllama做生成速度和 API 差距很大建议 Mac 上验证逻辑生产还是得用 GPU 推理。5.4 效果不稳定Agentic RAG 的薛定谔问题你可能会发现同一个问题跑十次五次答案很好五次非常差。这种不稳定大多数时候源自 LLM 的随机性。我的对策是把大模型的 temperature 降到 0.1 以下特别是做工具选择和路由的模型直接设 0。另外prompt 里的工具描述必须写得非常明确不能让模型自由发挥。如果你发现某些问题经常走错工具就去检查工具 description 是不是有歧义。还有一个团队容易犯的错Agentic RAG 上线后还要持续维护 prompt。每周用真实用户 query 跑一遍评测集看看路由准确率有没有下降。LLM 服务提供商更新模型后哪怕版本号不变行为也可能漂移。如果不做持续评测你很难发现为什么这周答案突然变差了。5.5 我最后悔的一次架构决策最后分享一个真实教训我曾在一个项目里把用户是否满意当前答案的判断完全交给大模型自己没加任何规则兜底。结果 Agent 非常自信地回答了错误答案而且因为信息充分度判断给了 yes循环直接终止用户拿到一个漂亮但错误的结论。后来我加了一条硬规则凡是涉及数字、日期、金额的答案必须经过一层确定性校验——用正则或代码把关键数值抽取出来和原文片段比对不一致就强制进入补充检索环节。这个经历让我意识到Agentic RAG 的生产质量不是靠模型自觉而是靠模型做决策、代码兜底线这套组合。现在的架构里凡是能写进代码的硬逻辑格式校验、数值比对、超时控制我绝不丢给模型模型只做它擅长的事——语义理解、意图判断、文本生成。基于这个原则重构之后系统的稳定性提升非常明显我建议每个做 Agent 应用的团队都把这条写在架构原则里。 
长河君 · 2026/10/7 17:26:46 · 阅读 1.2k Agentic RAG实战：从检索增强到推理增强的生产级架构设计
别再跟我提Demo 跑通这种话了。如果你正在做 RAG并且已经意识到单次检索-生成根本扛不住真实业务的复杂指令那你应该对 Agentic RAG 这个名字不陌生。我过去半年把三个 RAG 项目从原型拖进了生产环境最大的体会是凡是把 agentic RAG 当作魔法补丁的团队基本都在上线后一个月内开始返工凡是把它当作一套需要重新设计的系统的团队反而走得稳。这篇文章不聊 PPT 架构图只聊我在 production 环境里实际跑过的 agentic RAG 设计、拆解过的瓶颈、以及踩过的坑。适合已经跑通过基础 RAG、正打算引入 Agent 编排的开发者也适合刚接手知识库项目、想知道该不该上知识图谱的同学。1. 从检索增强到推理增强Agentic RAG 到底解决了什么问题1.1 传统 RAG 的隐形天花板传统 RAG 的流程大家都很熟用户提问系统把问题向量化从向量数据库里召回 Top-K 相关片段拼进 prompt交给大模型生成答案。这个流程在文档质量高、问题类型单一的场景下表现不错但一旦进入生产你会遇到三类用户根本不会同情你的问题。第一类是多跳问题。比如用户问我们上季度营收增长最快的产品线它的负责人是谁这个问题的答案分散在三份文档里一份是季度财报一份是组织架构调整通知。单次检索最多只能命中其中一个片段大模型拿到不完整信息只能硬编。第二类是带约束的问题。用户说不要用 2023 年之前的数据也不要考虑已经停产的SKU传统 RAG 的检索器根本不理解这个约束照旧把过期文档捞上来。第三类是需要对比分析的问题。用户拿两份合同让你找差异传统流程需要先定位两份文档再逐条比这不是一次向量检索能完成的。这些问题的共性是单次检索-生成循环表达能力不够。传统的做法是通过更复杂的 prompt 硬撑或者把检索到的更多片段一次性塞进去但前者不稳定后者不但成本高而且超过上下文窗口后反而引入噪声。本质上传统 RAG 是一个开环系统——检索完就生成没有校验没有反馈错了就错了。1.2 Agentic RAG把一次问答变成多步工作流Agentic RAG 的核心变化是给 RAG 加上了推理、规划、决策和验证的循环。它不再是一次检索就收工而是把用户问题拆解成子任务按需调用不同的工具向量检索、知识图谱查询、SQL 查询、外部 API每拿到一步结果先判断信息够不够、冲不冲突再决定是继续检索还是直接回答。我用一个实际例子说明。用户的问题是对比 A 和 B 两份合同在付款条款上的差异并指出对我方不利的地方。在 Agentic RAG 架构下系统首先规划出三个子任务定位合同 A、定位合同 B、提取并比对付款条款。然后它调用检索工具分别找到两段文本再交给大模型做结构化对比。如果比对过程中发现某段原文缺失或模糊Agent 会主动发起补充检索而不是硬着头皮生成。这个主动补充检索的能力就是关键。传统 RAG 是被动的用户给什么就答什么Agentic RAG 是主动的系统自己评估当前信息是否充分再决定下一步动作。这个动作可能是一次新的检索可能是一个知识图谱查询也可能只是向用户确认意图。1.3 哪些场景真正需要 Agentic RAG不是所有场景都值得上 Agentic RAG。我在实际项目中总结过一个判断清单问题是否天然多跳如果 80% 的问题都能靠单次检索命中那你需要的不是 Agentic RAG而是更好的分块和 embedding 调优。是否涉及多个异构数据源比如同时要查文档库、数据库、API 接口这类场景适合用 Agent 做统一的路由和调度。是否需要多轮交互澄清如果用户的问题常常信息不全Agent 可以通过反问来补全信息这是传统 RAG 做不到的。答案的准确率要求有多高如果错误答案会造成严重业务影响那 Agent 的验证和纠错环节就是刚需。我的建议是先用普通 RAG 跑通基线把能优化的问题都优化一遍分块策略、embedding 模型、重排序发现仍有 15%-20% 的难题解不掉再引入 Agentic 编排。直接一上来就做 Agentic RAG等于在没学会走之前先学跑后面排查问题会非常痛苦。2. 核心设计思路拆解Agent 如何会查资料、会判断、会兜底2.1 检索策略从单路召回到多路融合Agentic RAG 的检索层和传统 RAG 有个本质区别它不是一次检索就把所有希望寄托在上面而是每次检索都带着明确的任务目标。我在生产项目里的做法是设计一个多路召回 重排的检索策略。多路召回一般包含三路关键词检索BM25向量检索Embedding如果接入了知识图谱还有图谱查询。BM25 保证精确匹配向量检索保证语义泛化图谱查询保证关系推理。三路结果拿回来后用一个重排模型cross-encoder做融合。我测试下来这个策略对比单纯向量检索在真实业务数据上的 Recall10 能提升 12-18 个百分点。但多路召回也带来一个头疼的问题延迟。三路查询如果串行跑一次检索就是三次响应时间。我的优化方案是使用并行调用asyncio.gather同时发起三路查询取最慢的一路作为总延迟基准。实测下来在单路 200ms 的典型耗时下并行多路召回的总延迟可以控制在 280-350ms几乎和单路向量检索差不多但召回质量提升明显。2.2 路由与工具调用别让 Agent 瞎拿锤子Agentic RAG 里最容易被忽视的是路由器Router。路由器决定了一个问题该走哪条工具链——是直接向量检索还是先做 SQL 查询还是调外部 API还是干脆不需要检索大模型直接回答比如闲聊类问题。我在生产环境踩过一次大坑最初我用一个大模型 prompt 同时做路由和回答结果复杂问题来了模型经常图省事只做一次向量检索就急着回答导致答案质量大幅下降。后来我把路由独立出来成了一个专门的小模型任务——一个参数只有 70 亿的模型专门用来做意图分类和工具选择效果反而比大模型混合路由稳定得多。关于工具设计我给一个建议工具的粒度要中等。工具太粗比如只提供一个搜索全部资料Agent 无法精细控制工具太细比如提供 20 个细分类别的检索工具Agent 的决策空间太大容易选错。我最终收敛到 4-6 个工具比如检索产品文档检索合同条款查询数据库指标获取实时价格每个工具的 description 写清楚它擅长什么、不擅长什么。这个 description 比工具本身还重要因为大模型是靠 description 来选工具的。2.3 推理循环与控制设置刹车别让 Agent 无限跑Agentic RAG 引入了一个传统 RAG 没有的问题你的 Agent 可能陷入死循环。比如它反复检索同一份文档或者在一个问题上无限细化每次都生成再查一下的结论。这不仅浪费 token更糟糕的是会把延迟拖到用户无法忍受。我给生产环境设定的控制参数是最大迭代步数 5 步。每步到达后系统会做一个信息充分度判断——把当前所有检索到的上下文拿到大模型那里让它判断这些信息是否足以回答用户问题输出 yes/no。如果 yes停止循环进入生成阶段如果 no才继续下一步检索。为什么要设 5 步因为我在离线评测里统计过95% 的测试问题都能在 3 步内解决5 步是留的缓冲。超过 5 步的问题大多数是检索策略不对靠无限循环解决不了。另外每个 Agent 循环步都有一个证据覆盖检查检查当前答案的每一个陈述点是否对应上了某段检索到的原文。如果某个陈述点找不到原文支撑就标记为unverified并要求 Agent 补充检索。这个检查就像一个工程质量检查员能够显著降低幻觉比例。2.4 记忆与上下文管理别把上下文窗口当仓库Agentic RAG 每多跑一步就会多产生一些中间结果。如果不加管理几轮迭代下来上下文里全塞满了检索片段到最后一步真正重要的信息可能只占很小一部分。我的做法是引入上下文压缩器context compressor。每一轮检索完所有新检索到的片段不是直接追加到对话历史里而是经过一个压缩步骤把可能相关的关键句提取出来去掉无关部分只保留与当前任务相关的 2-3 个片段。压缩器本身可以用一个小模型或者复用路由器的模型。实测这个做法能把最终生成阶段的上下文缩减 60% 以上而且答案质量不降反升——因为噪声少了。另外一个经验是关于长期记忆与短期记忆的区分。短期记忆是当前任务的查询历史和中间结果长期记忆可以是用户的历史偏好或项目级知识库。Agentic RAG 生产系统应该把这两者分开存储否则长期记忆的噪声会影响短期任务的判断。我在项目里用的是向量库存长期偏好用 Redis 存短期会话状态两者不混用。3. 生产环境实战从 Demo 到线上系统的关键一跃3.1 延迟预算与异步架构设计Agentic 四步循环每步涉及一次 LLM 调用 一次检索叠加起来最坏情况可能超过 15 秒。用户根本等不了。生产环境必须做延迟预算管理。我的经验是按照用户预期把延迟分成三档简单问题需要 2 秒内回答中等问题 5 秒内复杂问题可以接受 10 秒但要有流式输出兜底。为此我在路由阶段就根据意图打了复杂度预估标签不同复杂度走不同策略简单问题直接走单次检索不做循环中等问题最多跑 2 步复杂问题才允许完整的 5 步循环。另一个关键技术是流式输出。Agent 在执行循环时前端可以先把正在检索合同一……正在比对条款……这样的事件流推给用户。用户看到的不是一片空白而是 Agent 的工作过程。体感上就算总延迟 8 秒有流式中间态也比什么都没看到等 5 秒强得多。这个实现不算复杂本质是后端从 REST 换成 WebSocket 或 SSE把 Agent 的每一步状态作为事件推送。3.2 评测体系没有指标别谈上线生产环境的 Agentic RAG 必须做评测。但评测维度和传统 RAG 不太一样我把它拆成三层指标。第一层是检索指标RecallK、MRR。第二层是生成指标答案的忠实度faithfulness找出答案中哪些陈述没有得到原文支持、答案完整性completeness对比参考答案检查是否漏掉了关键点、答案有用性helpfulness人工标注或 LLM-as-judge 打分。第三层是流程指标平均迭代步数、工具调用成功率、死循环率、超时率。这里我想提一个坑。最初我们用 LLM-as-judge 做生成质量打分结果得分虚高——大模型给同为大模型的回答手下留情。后来我们引入了参考标准答案用 RAGAS 框架的忠实度指标做自动化评测再配合每个月人工抽检 100 条才得到真实的质量数据。建议所有做 agentic RAG 的团队至少搭一个 200 条以上的回归测试集每次改动知识库或 prompt 后跑一遍全量回归防止按下葫芦浮起瓢。3.3 性能优化缓存、并发与资源控制Agentic RAG 的生产成本是普通 RAG 的 3-5 倍。一个查询可能产生 8-10 次大模型调用如果遇到恶意刷接口账单直接起飞。我的第一道防线是缓存。对检索结果做语义缓存如果用户的新问题和某个历史问题的 embedding 相似度超过 0.92可以直接复用当时的回答。实测下来这类重复问题的命中率在 10%-20% 之间能省不少 token。第二道防线是并发控制。Agent 的每一步都可能调 LLM而 LLM 接口有 QPS 限制。我用的是令牌桶算法做限流每个用户的并发 Agent 执行数不超过 2全局并发不超过 20。超出限制直接排队而不是让用户无限等下去。第三道防线是成本告警。对每个 Agent 循环的 token 消耗做追踪当单次查询的 token 数超过预设阈值比如 5000时自动降级为精简模式——跳过压缩器缩短最大步数甚至直接走单次 RAG 兜底保证用户能拿到答案而不是吞掉一个超贵账单。3.4 Embedding 与知识库运维上线之后才是开始很多团队的 RAG 项目死在上线后没人管。文档更新了、旧版本内容变了但向量库里的 embedding 还是旧的。用户问的都是新内容检索出来的全是旧片段。对这个问题我现在的运维标配是定时重建增量更新两条腿走路对于新增文档走增量管道做 embedding 入库对于大规模改版比如季度文档整体更新每月做一次全量重建。同时给每个 embedding 打上版本号知识库的每条记录都记录是哪个 embedding 模型生成的。这样模型升级时能精确找出需要重新 embedding 的记录而不是盲目全量重建省下大量算力。Mac 本地搭建时同样的思路也适用。我有段时间在 MacBook Pro 上直接跑知识库测试用 Ollama 跑 embedding 模型比如 nomic-embed-text加 SQLite-VSS 做向量存储几百条测试文档完全跑得动。所以如果你只是验证 RAG 逻辑先在 Mac 本地用小规模数据把链路跑通再上云扩展这比一上来就搭分布式向量库要务实得多。4. 知识库选型RAG、知识图谱与结构化知识库到底怎么选4.1 RAG 知识库最适合非结构化文本的默认选择项目里最常被问到的一个问题RAG 知识库到底能存图片吗答案是——能但不是你以为的那种存法。向量库存图片的思路是图生文先让一个多模态模型把图片转成文本描述caption再把这个描述文本 embedding 入库。查询时用户用自然语言检索命中文本描述再把原图返回给用户展示。这种方案的优点是实现简单缺点是精度受限于模型对图片的理解能力。如果你的场景是按内容搜图片这个方式基本够用但如果你要按像素特征搜图比如找相似 logo那就该用真正的多模态 embedding 模型了比如 CLIP 这类模型直接对图片和文本做联合向量化。做 RAG 知识库时文档类PDF、Word、网页永远是主力图片和音频只能算附件型知识。4.2 知识图谱KG知识库多跳关系的救星知识图谱和 RAG 的区别在哪里一句话RAG 是找一段话KG 是找一条关系路径。当你的业务问题集中在关系推理上比如某供应商还给我们哪些项目供过货两个部门之间有哪个项目重叠这个异常指标是否和近期的组织调整有关RAG 往往会因为信息分散而答得模模糊糊而知识图谱可以直接沿着关系边做多跳查询给出精确路径。但知识图谱有个生产环境的大坑构建和维护成本极高。你需要从非结构化文档里抽取实体和关系做实体对齐解决张三和张总是同一个人的问题、做关系消歧、设计本体ontology。我在项目里给客户做过一个供应商关系图谱光实体抽取和清洗就跑了两周后续每次新文档进来还要跑增量抽取和冲突检测。我的建议是RAG 和 KG 不是替代关系而是配合关系。当问题是一个纯文本理解型问题比如合同条款的含义走 RAG当问题是一个关系查询型问题比如组织架构里的汇报关系走 KG。在 Agent 的工具列表里同时挂上这两个工具让路由器决定调用哪个。这个方案业内有个名字叫 GraphRAG本质就是非结构化文档做索引 结构化关系做推理的混合架构。4.3 结构化知识库为什么我还是留了一张 SQL 表这里要提醒一件事不要什么知识都往向量库里塞。我看到太多团队把业务数据库里的表格数据比如销售明细、库存数量也做 embedding 进 RAG然后让大模型做计算。先不说计算的准确性没有保障单是哪个月销量最高这类问题向量检索根本不适合——它适合文本相似度不适合数值聚合。正确的做法是能查结构化数据库的直接让 Agent 生成 SQL 查询。我的工具列表里始终保留一个数据库查询工具Agent 根据用户问题生成 SQL执行后把结果集交给大模型做总结。实测这个方案查上季度销量 Top3 的产品这类问题的准确率接近 100%而走向量检索的方案正确率只有 60% 左右还得靠大模型硬算。所以分清楚场景精确查询走 SQL非结构化理解走 RAG关系路径走 KG。三者通过 Agent 统一编排才是一个生产级系统该有的形态。4.4 本体Ontology设计给知识图谱套上骨架知识图谱里的本体设计很容易被忽略但很关键。ontology 其实就是知识图谱的类型系统——规定有哪些实体类型人、组织、产品、项目、哪些关系类型属于、负责、参与、供应以及每种关系连接哪些实体类型。没有 ontology知识图谱就是一团乱麻用 ontology 约束知识图谱才能稳定成长。一个实用的最小化 ontology 设计案例供应商项目场景可以用四类实体供应商、项目、产品、区域、五种关系供应商供应产品、项目使用产品、项目归属区域、供应商负责区域、产品属于产品线。就这么简单的本体配合 LLM 从文档中抽取知识图谱就能回答某区域下用到的所有产品有哪些供应商这类问题。Agent 与知识图谱的交互方式我用了两种。一种是先让 Agent 把自然语言问题转成图谱查询语句比如 Cypher 查询直接查询。另一种是把图谱的 schema 描述给大模型大模型根据 schema 自己决定怎么遍历。前者精确但依赖转换质量后者灵活但容易跑偏。生产我推荐前一种为主加上 schema 描述作为 Agent 的上下文让转换质量更高一些。5. 常见问题排查实录与避坑清单5.1 检索召回率低多半不是模型问题是切分问题如果你发现检索出来的片段和问题有关系但不精准八成问题出在 chunk 切分上。我在项目里的经验是chunk 切分必须考虑文档结构而不是按固定字数硬切。对于合同类文档按条数和章节切对于技术文档按标题层级切对于 FAQ按问答对切。另一个容易被忽视的是元数据。给每个 chunk 打上文档来源、章节标题、页码、更新时间等元数据检索时就可以做前置过滤。举个例子用户查 2024 年的政策检索时直接通过元数据过滤掉 2023 年的 chunk比纯靠语义匹配精准得多。这类以metadata 为主的过滤比多塞几个 chunk 更好用既省钱又提升精度。5.2 幻觉控制不住引入引用溯源和忠实度检查关于幻觉控制我会坦诚我试过很多土办法都不算太理想。如果你用的是普通 RAG幻觉的发生是因为大模型生成时带着上下文不自觉补充细节。在 Agentic 循环里我们可以多做两个动作生成前要求模型只根据检索到的内容作答禁止引入外部知识的表述生成后用忠实度检查模型用一个独立小模型对比生成答案中每个陈述和检索片段的匹配度自动重查一遍。这两招能显著压低幻觉率但没法归零。若业务要求零幻觉恐怕只能在工具设计上做硬约束比如要求以原文引用为主、把需要推理的部分交给确定性代码而不是模型拿主意。5.3 Mac 本地搭建 RAG 知识库的神坑与捷径很多同学在 Mac 上搭建 RAG 知识库卡住的通常不是思路而是环境细节。这里分享几个我试出来的贴合 Mac 的要点embedding 模型建议选小一点的比如 nomic-embed-text 或 bge-small我的 MacBook Air 实测跑几百个文档毫无压力。向量库先用 SQLite-VSS 或 Chroma 就能起步别一上来就上 Milvus 这类重组件。另外一个 Mac 特有问题有些原生库比如某些分词器在 arm64 架构下编译很慢甚至失败。我的建议是尽量用 Python 3.10 的预编译 wheel避免从源码编译。实测这样能把搭环境时间从一晚上缩短到半小时。还有一点Mac 上跑本地 LLMOllama做生成速度和 API 差距很大建议 Mac 上验证逻辑生产还是得用 GPU 推理。5.4 效果不稳定Agentic RAG 的薛定谔问题你可能会发现同一个问题跑十次五次答案很好五次非常差。这种不稳定大多数时候源自 LLM 的随机性。我的对策是把大模型的 temperature 降到 0.1 以下特别是做工具选择和路由的模型直接设 0。另外prompt 里的工具描述必须写得非常明确不能让模型自由发挥。如果你发现某些问题经常走错工具就去检查工具 description 是不是有歧义。还有一个团队容易犯的错Agentic RAG 上线后还要持续维护 prompt。每周用真实用户 query 跑一遍评测集看看路由准确率有没有下降。LLM 服务提供商更新模型后哪怕版本号不变行为也可能漂移。如果不做持续评测你很难发现为什么这周答案突然变差了。5.5 我最后悔的一次架构决策最后分享一个真实教训我曾在一个项目里把用户是否满意当前答案的判断完全交给大模型自己没加任何规则兜底。结果 Agent 非常自信地回答了错误答案而且因为信息充分度判断给了 yes循环直接终止用户拿到一个漂亮但错误的结论。后来我加了一条硬规则凡是涉及数字、日期、金额的答案必须经过一层确定性校验——用正则或代码把关键数值抽取出来和原文片段比对不一致就强制进入补充检索环节。这个经历让我意识到Agentic RAG 的生产质量不是靠模型自觉而是靠模型做决策、代码兜底线这套组合。现在的架构里凡是能写进代码的硬逻辑格式校验、数值比对、超时控制我绝不丢给模型模型只做它擅长的事——语义理解、意图判断、文本生成。基于这个原则重构之后系统的稳定性提升非常明显我建议每个做 Agent 应用的团队都把这条写在架构原则里。