做了几年 AI 应用在把 Agent 从 demo 推向真实业务的过程中我最常被问到的问题不是“怎么让模型更聪明”而是“为什么我的 Agent 一问到内部资料就开始胡说”。这其实是个信号你的 Agent 缺的不是推理能力而是一条稳定的知识获取管道。这篇是“走进 AI Agent”系列的第四篇专门把 RAG 基础讲透——它解决什么问题、管道里每个环节在干什么、落到 Agent 上要怎么设计和评估以及我踩过的那些坑。1. Agent 的认知边界RAG 解决的到底是谁的问题1.1 模型底座的知识是“静态的”Agent 任务却是“动态的”先说一个反直觉的事实大语言模型本质上是一个“压缩过的静态知识快照”。它知道的东西最远只到训练数据截止那一刻它回答问题时是在条件概率上生成最连贯的文本而不是像人一样去书房里翻一本书再告诉你答案。所以当你把 Agent 放在真实的业务环境里它面对的是每天都在变的私有文档、项目数据、故障记录和客户反馈模型根本不认识这些东西。这种“不认识”会导致两类很典型的表现。第一类是硬编造你问它上周线上事故的处理结论它没见过这份记录就会在概率空间里挑一个“看起来合理”的答案给你语气越自信越危险。第二类是答非所问你问“我们采购流程里金额超过五万需要谁审批”模型也许知道通用采购知识却不知道你们公司具体的审批链答出来的东西听着专业但根本没法执行。所以 RAGRetrieval-Augmented Generation检索增强生成之所以成为 Agent 基础设施的一部分不是因为它时髦而是因为它把“模型内化的知识”和“外部可控的知识”切开了。模型负责思考、归纳、生成外部索引负责提供事实依据。简单说RAG 让 Agent 在回答问题之前先去查一遍资料再基于查到的内容作答。就这么一个朴素的动作把幻觉问题从根上拆掉了大半——因为它不再逼迫模型“回忆”没学过的东西。1.2 为什么知识获取必须是“管道”而不只是“搜索”很多初学者会把 RAG 理解成“给 LLM 接一个搜索引擎”这个理解太简化了。如果你只把用户问题丢给搜索接口再把搜回来的网页塞进提示词你很快会遇到三个问题搜回来的内容太杂太冗余超出上下文窗口文档格式五花八门PDF、表格、扫描件里的信息根本提不出来检索结果和问题之间没有相关度排序模型被无关信息带偏。真正的知识获取管道是一个从原始文档到最终答案的完整流水线它至少包含四个环节摄取Ingestion、向量化Embedding、检索Retrieval、生成Generation。每个环节都有自己的参数、瓶颈和取舍任何一个环节偷懒最后的效果都会打折扣。用生活化的类比来解释整个过程相当于给 Agent 配了一个私人图书馆管理员。管理员先把散落各处的书籍原始文档买回来拆掉塑封、编好目录、按主题切成章节分块然后把每一章做一张带编号的摘要卡向量化摆进检索柜里。你提问时管理员先根据你的问题在卡片柜里快速定位相关章节检索把这几章原文搬到你桌上上下文拼接你再根据这些材料完成写作生成。如果管理员偷懒没编目录或者切书时把关键段落切断了后面查找质量一定崩。你应该把 RAG 当成 Agent 的一条“知识高速公路”来设计而不是一个临时拼接的搜索工具。这也是本系列到第四篇才讲它的原因前三篇我们解决了 Agent 的规划能力、工具调用和记忆机制但如果没有可靠的知识获取管道规划得再好也容易在事实性问题上翻车。1.3 RAG 在 Agent 体系中的位置记忆层与工具层的交界处在 Agent 的完整架构里RAG 处在两个关键位置的交叉点上。一个是记忆层长期记忆里最难办的不是对话历史而是“组织知识”即那些结构化的业务文档、规范流程和沉淀经验RAG 是对这类知识的标准化存取方式。另一个是工具层一次检索动作完全可以被封装成一个工具让 Agent 自行判断“这个问题需不需要去查资料库”而不是每次强制检索。这个定位决定了设计原则。第一知识获取管道必须被 Agent 主动调用而不是被动拼接在每一个对话前面否则既浪费 token 又可能引入噪音。第二检索结果要经过取舍不是越多越好Agent 需要学会在信息不足时发起二次检索。第三管道中每个环节都需要可观测的日志和指标否则你很难定位问题发生在“文档切得不好”还是“向量搜得不准”。把这三点先立住后面所有的实操参数和调优策略才有一个统一的决策依据。2. 拆开 RAG 的四段管道从原始文档到可用上下文2.1 摄取阶段分块质量决定了检索质量的“天花板”摄取是整个管道里最不起眼却最容易决定成败的环节。原始文档可能是 Word、PDF、Markdown、HTML 甚至是扫描图片第一步要做的是内容提取。PDF 要区分文字版和扫描版文字版直接用解析库提取扫描版得先走 OCR表格类内容要尽量保留结构不能把单元格文字连成一段PPT 和音视频转写则要按页面或时间轴加元数据。提取完成后紧接着就是分块chunking。这块有个很多人忽视的点检索的上限是在分块时就定死的。如果一块里只塞了半句话后面无论向量模型多好都搜不出完整含义如果一块里塞了一整章向量表达被稀释检索精度也会下降。常用的分块方式有三种固定长度分块按 token 数或字符数硬切实现最简单但很容易切断语义完整的句子中文里尤其明显。递归分块先按段落分再按句子分按优先级逐级降级是目前最通用的基线方案。语义分块借助 embedding 计算相邻句子相似度在语义断裂处切开质量最高但成本也最高。实际做业务落地我建议从递归分块入手把块大小控制在 300 到 800 个 token 左右重叠区域设 50 到 100。同时把元数据来源文件名、章节号、页码、更新时间跟着块一起存下来后面做引用溯源和过滤会非常方便。2.2 向量化embedding 模型选型与中文场景的注意点分完块之后每一块文本要变成一串向量也就是 embedding。这里要理解一个关键点向量空间里的“距离”并不等于语义的完美映射它只是模型训练出来的一个近似。所以 embedding 模型的选型非常重要。中文场景下常见的选项包括开源的中文向量模型例如 BGE 系列、M3E 系列和中英双语模型商用接口也有 text-embedding 系列可选。选型时不要只看榜单分数要关注三件事第一是否支持中文长文本。有些英文语料训练出来的模型对中文的支持很弱检索命中率会直接崩坏。第二向量维度。维度越高理论上表达能力越强但存储和计算成本也越高768 维和 1024 维在数据量大时差异不小。第三是否支持领域微调。如果你的文档领域很特殊比如医疗、法律、工业运维可以考虑基于小样本做 embedding 微调但这是后话初版别急着上。向量化之后每一块文本对应一个向量和原始文本、元数据一起存入向量数据库。注意向量数据库本身不产生搜索结果它只提供了一种高效的“按向量相似度找块”的能力。所以别把选哪个向量库想得太重pgvector、Milvus、Qdrant 都可以关键是看你的数据量、部署形态和是否需要混合检索。2.3 检索阶段向量相似度只是起点混合检索才是稳定解很多人第一次做 RAG检索阶段就直接“用户问题向量化然后最近邻搜索”这在简单问答上看起来效果不错但一旦遇到专业术语、专有名词、产品型号甚至是一串编号向量检索就会暴露出明显的盲区。为什么因为向量检索本质上是语义近似的匹配它会被同义词、改写和泛化表述影响却对“精确的字符串”不够敏感。举个真实的例子你问“PRD-2024-0817 这个版本的需求变更有哪些”查询里的核心是那串编号“PRD-2024-0817”。向量化之后模型可能更关注“需求变更”这类语义编号被稀释了结果搜出来的全是关于需求变更的文档反而没有精确匹配到那一条记录。这种时候传统的 BM25 关键词检索反而表现更好因为它在倒排索引里精确命中字符串。所以我在实际项目里几乎都会做混合检索向量检索负责语义召回BM25 负责精确匹配然后通过加权合并或 rerank 二次排序得到最终结果。这一招能显著提升长尾场景的稳定性。关于具体的权重和 re-rank 策略我会在第三章展开讲。2.4 生成阶段把检索到的内容变成可信答案检索完成之后系统把命中的若干文本块拼进提示词让 LLM 基于这些材料生成回答。这一步看起来只是拼字符串但其实有三个关键设计。第一要给模型明确的约束只能基于提供的上下文回答信息不足时直接承认不知道而不是强行推测。第二要在提示词里保留来源编号让模型在回答的句子后标注出处段落这既能帮助用户核对也能为后续评估提供依据。第三要在上下文里处理检索块之间的关系如果命中的几块内容互相矛盾最稳妥的做法是通过引用和检查机制让模型如实反映避免强行融合导致错误。生成阶段是 RAG 里最像“技术活”的部分吗恰恰相反。很多人花了大量精力调提示词却发现效果提升有限问题大多出在前面几环上下文里真正相关的信息根本没有被检索回来。这也是为什么我反复强调RAG 的重点在管道前半段生成只是最后一步的“临门一脚”。3. 让检索真正为 Agent 服务索引设计的实战参数3.1 chunk_size、overlap、top_k 到底怎么调这三个参数是 RAG 调优里最容易被反复拧的旋钮。先说 chunk_size块大小。块越小语义越聚焦检索精度越高但上下文碎片化模型可能只看到答案的一半。块越大上下文越完整但向量平均化会让精确匹配变差而且还容易撑爆上下文窗口。我的经验是不同文档类型用不同块大小。操作手册、合同条款这类内容建议 200-400 token因为信息点密集且互相独立项目报告、技术文章这类叙事型内容建议 400-800 token因为语义依赖长距离。overlap重叠长度的作用是把被切断的语义“缝回来”。如果一个段落的关键信息恰好横跨两个块的边界没有 overlap这一段就成了没头没尾的噪音。overlap 一般设为 chunk_size 的 10%-20%不要贪多否则块之间大量重复检索去重和存储成本都会上升。top_k返回块数量决定了每次生成时放入上下文的片段数。它和 chunk_size 共同决定了“喂给模型的证据量”。粗略计算chunk_size 取 500top_k 取 4上下文里就有约 2000 token 的检索内容加上问题、历史和指令总上下文量已经不小。top_k 太小会漏信息太大会引入噪音、拉长延迟、增加成本。一个可落地的调法是把 top_k 作为变量做小范围实验分别在 3、5、8 三个档位上对比输出质量而不是一开始就定一个拍脑袋的数。3.2 混合检索 rerank稳定性和成本之间怎么权衡上一章我提到了混合检索这里给出更具体的做法。混合检索的常见实现是向量检索得到一组候选结果BM25 得到另一组候选结果两组结果去重后利用分数融合算法例如 RRFReciprocal Rank Fusion对结果重新排序。RRF 的核心思想很简单每个文档在各自排序里的名次越靠前融合分越高它不依赖两个检索系统返回的原始分数体系是否可比。虽然 RRF 已经很稳定但在对精度要求更高的场景我还会加一个重排rerank环节把候选结果和用户问题一起交给一个交叉编码器模型cross-encoder逐对计算相关性输出一个高质量排序。如果说向量检索和 BM25 是“海选”rerank 就是“终审”。代价是延迟增加通常一次 rerank 要几十到几百毫秒而且候选太多时成本上升明显。所以实践里的做法是先用向量BM25 海选召回 Top 20-50再用 rerank 精排 Top 5-8最终把精排后的内容拼进上下文。这套组合拳打下来检索稳定性会明显上台阶。特别是遇到同义改写、近义表述、跨语言查询时两条召回路径能互相兜底不会一边倒。至于要不要上 rerank我的判断标准很简单如果 Top 1 命中率已经达到业务要求就先用 RRF别急着上 rerank当发现“搜得到但排不对”时再引入 rerank性价比最高。3.3 索引的生命周期更新、删除与版本管理如果说前三节是“把检索做对”那这一节是“把检索做稳”。很多 RAG 项目死在维护期文档一周更新一次旧版本没删干净索引里躺着互相矛盾的内容用户问的问题检索到了已经作废的流程文件Agent 还一本正经地念出来。这种问题不是调参能解决的是索引生命周期管理没做好。落地时至少要做这三件事。第一建立明确的更新策略。全量重建适合数据量小、更新频率低的场景增量更新适合业务文档频繁变化的场景你需要记录每个内容源的最后更新时间只对变化部分重新分块、向量化。第二实现可靠的删除机制。文档下线后别只删原始文件必须同步删除它在向量库里的对应向量否则“幽灵知识”会继续影响检索结果。第三给内容加版本字段。同一份文档在不同版本之间要能通过元数据区分检索时优先返回当前生效版本。这些机制看起来很基础但越基础越容易被开发初期的兴奋感掩盖。我见过不止一个项目demo 跑得飞起上线三个月后因为知识过期被用户投诉最后不得不回炉重建索引。4. 把 RAG 接进 Agent工具化、多跳与可观测性4.1 知识查询工具化Agent 自己决定何时查、查什么前面讲的都是传统 RAG 单轮问答的形态但放进 Agent 工作流之后整个交互逻辑要变。Agent 不是第一次提问就被动做一次检索它需要把“查询知识库”当成一个可调用的工具结合当前任务状态判断这个问题需要查吗查什么查完怎么用具体实现上可以把检索动作封装成一个 function calling 接口输入参数通常是查询语句、可选的过滤条件文档类型、部门、时间范围、以及期望命中的数量。Agent 在规划阶段生成一次检索工具的调用计划拿到检索结果后再决定是一次性生成答案还是发起二次检索补全细节。这个切换带来的好处是明显的。它让检索从“每次都强制发生”变成“只在需要时发生”既降低了 token 开销也避免无关检索噪音污染生成。更重要的是Agent 开始有“不知道自己不知道”的自觉当它发现提供的上下文不足以回答问题时可以主动再次调用检索工具而不是硬着头皮编。4.2 多跳检索与查询改写复杂问题不能只问一次真实业务里用户问题往往不是一个简单的单轮检索能解决的。比如“对比一下我们去年三个季度的故障处理时长并分析哪个季度的改进措施最有效”这个问题隐含两轮检索先查三个季度的故障记录再查对应的改进措施。如果只做一次向量检索基本会漏掉其中一部分。多跳拆解是 Agent 化 RAG 的关键增强。Agent 先把复杂问题拆成多个子问题逐个调用检索工具最后汇总推理。另一个常用技巧是查询改写原始的用户问题往往表述模糊直接拿去检索命中率低可以让 LLM 先把问题改写成若干个更具体、更适合检索的查询词再分头去检索。比如“咱们上个月为什么没达标”可以改写为“上个月 KPI 未达标原因”“质检合格率下降原因”“生产计划延误分析”三个检索方向命中率会明显提升。这里要控制好递归深度。每多一轮检索延迟和成本都会上升而且错误会在多跳里累积。我一般建议最大检索轮数控制在 3 到 5 轮并且在每一轮都做信息是否充分的判断避免 Agent 在无关分支里越挖越深。4.3 可观测性给 RAG 装上“仪表盘”把 RAG 接进 Agent 后最大的风险是它变成一个黑盒用户问了一个问题Agent 查了知识库但没人知道它查到了什么、为什么这么回答。遇到回答错误排查的人只能干瞪眼。这是工程化落地里最容易被低估的问题。所以我会强烈建议在上线前就给 RAG 管道加全链路日志。至少要记录这几个信息用户的原始问题、Agent 改写后的查询词、检索命中的文档块列表包括文件名、块内容、相似度或排名分、最终喂给 LLM 的提示词上下文、LLM 生成的答案、以及每一步的时间消耗。把这些日志存起来既可以做离线评估也可以在线上问题复盘时快速定位是哪一环出了错。有了这套仪表盘你很快会发现很多所谓“回答错误”根本不是模型能力问题而是检索环节把不相关的文本块排到了前面或者分块把关键段落切散了。没有可观测性这些问题会被误判成“需要换个更大的模型”花冤枉钱。5. 评估与翻车现场我的 RAG 落地经验和教训5.1 离线评估指标hit_rate、MRR、召回率到底怎么用很多团队在 RAG 项目开始时完全凭感觉调参改一个 chunk_size 就上线看效果。这是大忌。RAG 的系统性调优必须要有一组成体系的离线评估指标。最常用的三个指标里hit_rate 衡量的是“在 Top-k 检索结果里是否包含人工标注的正确文档”。它最直观特别适合快速验证分块和检索策略的改进方向。MRRMean Reciprocal Rank在此基础上更进一步它关心正确文档排在第几名排第一得 1 分排第二得 0.5 分越靠前分数越高非常考验排序质量。命中率只告诉你“找到没有”MRR 告诉你“找得准不准”。除此之外RAGAS 框架里常用的 faithfulness忠实度和 answer relevance答案相关性也很有参考价值。前者评估生成的答案是否忠于检索上下文不添油加醋后者评估答案是否有效回应了用户问题。这四个指标合起来基本能覆盖“搜得准不准”和“答得好不好”两个维度。做评估时要基于你的真实业务问题构造测试集至少准备 50 到 100 条带标准答案的问答对。构造测试集是件麻烦事但全是金矿每一次模型升级、分块调整、检索策略优化都能用这套集子快速做回归对比而不是靠“感觉好像变好了”。5.2 常见翻车现场为什么“什么都查到了”还是答错这几年我看了太多 RAG 项目调试现场以下翻车场景几乎每三个项目就能遇到一次值得你提前设防。第一个场景是“检索命中但上下文拼接错位”。问题问的是“退货流程”检索命中了产品说明里与退货相关的段落但同一块文本里还夹杂着售后的其他内容。模型被无关词干扰回答从退货偏向了维修。解决办法是提高分块精度或缩小返回块数。第二个场景是“相似度偏见”即向量检索过于偏好语义相近但实际答案缺失的文档。问“发票报销上限”搜出来的全是“差旅报销标准”看起来像但实际不是。这种情况要靠混合检索和关键词精确匹配来纠偏。第三个场景是“知识过时”索引里有 2023 年的旧版流程和 2024 年新版流程检索结果把两版都带了进来模型无法判断新旧关系。解决办法就是第三章提过的元数据版本过滤。第四个场景是结构化数据没有被正确处理。大量业务知识在数据库表格里而不在文档里纯文本 RAG 根本检索不到这时候需要把表格转成文本描述再进索引或者走 text-to-SQL 的路线。RAG 不是万能的认清边界才能选对方案。5.3 个人建议清单从零开始做 RAG 的极简检查项最后分享一份我在每个新项目里都会过的检查清单按优先级排序每条都值一次踩坑换来的经验。第一先框定边界不要想“做一个万能知识库”。明确知识范围和问题类型区分文档型知识、结构化数据、图片表格这三种形态分别设计不同的进入管道。第二分块和元数据优先优先于换模型和调提示词。上下文质量决定了 Agent 回答的天花板而上下文质量一半取决于分块另一半取决于元数据。第三混合检索和 rerank 要按需求分层引入。初期先用向量检索加 RRF命中率不足再上重排别一开始就把链路搞很高配。第四所有优化决策必须跑离线评估集。没有数字支撑的调优都是玄学有了数据支撑你可以清楚地知道每次改动到底提升了哪一项指标。第五日志和可观测性从第一天就接入。这不是上线前的动作而是开发期排错的基本功。第六给 Agent 留出“承认不知道”的出口。如果检索结果与问题相关性极低或为空宁可让 Agent 明确说“未找到相关信息”也不要逼着它在噪声上下文里生成一个看似精彩的错误答案。我在实际项目中体会过最深的一条是RAG 主打的是“工程确定性”而非“模型魔法”。把这个理念贯彻到管道设计、参数调优和评估体系的每个细节里AI Agent 才真正具备接住真实业务的能力。