RAG与Agent：构建知识获取管道的落地实践

1. 为什么 Agent 需要一条知识获取管道开始聊 RAG 之前我想先说清楚一个很多人绕了很久才想明白的问题Agent 为什么要跟 RAG 绑定在一起如果你只是用大模型做单轮对话、写文案、改代码那 RAG 不是必需品直接怼 Prompt 就完事了。但一旦你想让 Agent 自主完成一个真实任务——比如帮我查一下公司最近一个季度的销售数据整理成报告并发到群里情况就变了。这时候 Agent 光靠模型本身学到的知识是不够的它必须能拿到你自己系统里的数据。我举一个最直白的例子大模型的训练数据是有截止时间的你问它上个月的行业政策、你公司内部的流程文档、某个私有系统的字段含义它要么胡编要么说不知道。RAG 干的事情就是让模型在回答之前先去一个外部知识库里把相关资料捞回来再基于这些资料组织答案。很多人第一次接触 RAG 是在 LangChain 或 LlamaIndex 的教程里跑通一个 PDF 问答 Demo 就觉得哦就是向量检索嘛。这么说没错但只说到了一小半。我的理解更偏向一个词知识获取管道。RAG 不是一次查询而是一条从原始文档到模型可读上下文再到可信回答的流水线。Agent 在这个管道里拿到的是经过筛选、压缩、排序的知识碎片而不是把整个知识库都塞给它。这也决定了 RAG 的设计重心——它的难点不在检索这个单点动作上而在整条管道每一段的衔接与质量损耗控制。这一篇我打算按实操的视角把 RAG 切开先讲它在 Agent 体系里的定位再逐个拆索引、检索、生成这三个阶段最后重点说落地时最容易翻车的几个坑。目标是让看完这篇的人不只是会调一个向量数据库的 API而是能自己判断一个 RAG 项目哪里会失效、该怎么修。如果你正打算从 0 到 1 搭一个带知识库的 AI Agent或者已经在某个项目里用 RAG 但总感觉效果不稳定这篇文章应该能给你一些排查问题的思路。2. RAG 之前先看清 Agent 的知识困境2.1 模型知道什么不知道什么大模型的知识本质上是训练语料里的统计规律。它知道巴黎是法国首都因为互联网上有大量文本在反复讲述这件事它知道Spring Boot 的常见注解有哪些因为 GitHub 和博客里到处是这类内容。但它的知识边界非常清晰有截止日期。训练完成那一刻之后发生的事模型一概不知除非你去给它补上下文。没有私有信息。你公司内部的 CRM 数据、产品规格表、项目复盘文档、售后工单这些从未出现在公开互联网上的内容模型无法凭空知道。不擅长精确查证。问它某个具体数字、具体编号、某个配置项在不同版本间的差异模型更倾向于给你一个听起来合理的结果而这些结果经常是错的。这三条限制恰好对应了 Agent 在真实业务场景中遇到的大部分问题。你可以靠微调把一部分私有知识灌进模型参数里但微调成本高、更新周期长、还容易引入灾难性遗忘对于经常变化的业务数据来说并不划算。2.2 RAG 的核心思路把记忆从参数搬到外部RAG 的思路其实简单到一句话别让模型背知识而是让它在回答问题时查知识。我们平时查资料也是这个模式——你不需要把整本手册背下来但知道去哪一页找答案。RAG 就是给 Agent 装了一个查手册的动作用户问题进来之后系统先从知识库里检索出最相关的一批文档片段把它们拼到 Prompt 里模型再基于这些片段生成回答。这样模型不需要记住具体内容只需要读完检索结果后做理解和组织。知识的存储、更新、淘汰都发生在外部的知识库里跟模型参数完全解耦。这种设计带来的实际好处是知识实时可更新。文档一改向量库一更新Agent 立刻就能用上新知识不需要重新训练。回答可溯源。模型说某句话时你可以知道它是根据哪一篇文档说的这对企业场景里的可信度要求很关键。减少幻觉。虽然不能完全消除后面会讲为什么但至少模型在关键事实上有了依据而不是全靠猜。2.3 RAG 与微调到底怎么选这个问题我在不少群里被问过。我的判断标准很简单如果你的知识是能力型的——比如让模型学会某种特定格式的输出、某种工具的调用习惯——那微调更合适如果你的知识是信息型的——比如某个新产品的参数、公司制度、实时价格——那 RAG 更合适。信息型知识的特点是变化快、可以枚举、以文档形式存在这些正是 RAG 擅长处理的。能力型知识藏在模型的行为模式里不是靠检索能解决的。两者其实不冲突很多成熟的 Agent 系统是先用微调调教模型的行为再用 RAG 喂给模型素材。但起步阶段我建议优先做 RAG因为它迭代快、见效直接、门槛也低得多。3. 一条 RAG 管道的完整链路索引、检索、生成把 RAG 拆成三个阶段来看每个阶段都有自己的输入输出和质量要求。很多教程喜欢用一张架构图表示我这里用文字走一遍完整流程并标出每个环节最容易出问题的位置。3.1 索引阶段让文档变成可检索的向量索引阶段的目标是把一堆原始文档PDF、Word、Markdown、数据库里的文本字段转化成检索系统能快速命中的形式。这一步通常包含四个小步骤解析、清洗、切分、向量化。解析是把不同格式的文档变成纯文本。PDF 要考虑是否扫描件、是否有多栏排版Word 要处理表格HTML 要剥离标签。这步看起来基础但实际项目中很多知识库效果差根因就是解析环节丢了太多信息——比如 PDF 里表格的单元格顺序被打乱检索出来的内容读起来完全不通顺。清洗是把无关内容去掉页眉页脚、版权声明、导航菜单、重复的模板段落。这些噪音如果不处理会被一起向量化检索时经常返回一堆没用的碎片。切分chunking是索引阶段最关键、也最容易被低估的一步。切分决定了检索的基本单元是多大、边界在哪里。切得太小单个片段信息量不足模型拿不到完整上下文切得太大一个片段里塞了多个主题检索命中率会被拉低。后面我会专门展开讲切分的取舍。向量化是把切好的文本片段用 embedding 模型转成向量。这一步要注意的是嵌入模型的选择直接影响检索效果的上限。通用领域的 BGE、OpenAI 的 text-embedding-3、或者针对中文优化的模型效果差异很明显。选错模型往往不是差一点而是完全不能用。索引阶段做完得到的是一批向量和对应的原始文本通常会存入向量数据库比如 Milvus、Qdrant、pgvector同时配套一个元数据存储记录每个片段来自哪份文档、属于哪个章节、生成时间是什么。这些元数据后面在做过滤和排序时会用上。3.2 检索阶段从候选集到精准命中检索阶段接收的是用户 query输出的是最相关的一批文本片段。最基础的实现是把 query 也转成向量在向量库里做相似度搜索通常用余弦相似度或内积取 Top-K 个结果。但实战里我会更推荐混合检索的做法——向量检索 关键词检索同时进行再合并结果。为什么因为向量检索擅长捕捉语义相关性但它在精确匹配上很弱。你问合同编号 C2024-001 有没有录入系统这个编号在语义上没有什么相似的向量而关键词检索能直接精确匹配。反过来关键词检索做不了帮我找一下员工离职流程相关的说明这种语义查询。两者合并互补性很强。检索出来之后通常还要加一个重排序环节。倒排出来的 Top-K 是粗选质量比较糙重排序会用更强的模型比如 cross-encoder对候选片段逐条打分把真正有用的排到最前面。这个步骤对最终回答质量影响非常大但很多入门教程不会提到它。检索召回率低、排错序是整个 RAG 项目看起来检索了但答案还是很差的最常见原因。3.3 生成阶段把检索结果变成可信回答生成阶段的核心工作是把检索到的片段和用户的原始问题组装成一个清晰的 Prompt。组装时有两个点要特别注意。第一是可读性。检索结果内部是带顺序的需要按相关度排列后再拼接用清晰的标识分隔开比如【资料1】【资料2】。同时加上明确的指令告诉模型仅基于以上资料回答如果资料中没有相关信息直接说明不知道不要编造。这看起来像废话但对大模型的行为约束非常有效。第二是token 预算。检索回来的片段如果太多超过上下文窗口模型会忽略后面的内容或者回答质量明显下降。所以 Top-K 不是越大越好要根据模型的上下文长度和回答需求做取舍必要时可以对片段做摘要压缩、只保留关键段落。让模型基于资料组织回答还有一个潜藏的好处当回答出现争议时你可以顺着资料编号追溯是哪一段提供了依据准确判断问题出在检索没召回还是模型理解错了而不是一头雾水。3.4 三个阶段的常见失败模式我用一张表把三个阶段各自典型的失败模式列一下方便排查时快速定位阶段典型症状可能根因索引检索出来一堆无关内容解析丢数据、切分不合理、embedding 模型不匹配索引相似问题召回不一致切分边界不稳定、文档变更后未重新索引检索明确关键词查不到只用向量检索没有关键词兜底检索Top-K 里混入明显不相关项缺少重排序或元数据过滤条件没生效生成回答与资料矛盾Prompt 约束不足、模型没有遵循指令生成内容空洞、泛泛而谈检索到的片段本身信息密度低、切分过碎4. 检索质量的决定性细节切分、嵌入模型与重排序4.1 切分策略不是越小越好很多人刚开始做 RAG 时觉得切分就是按固定字数切一下比如 500 个字符一个 chunk。这个做法能跑通 Demo但生产环境里几乎一定会出问题。为什么因为固定字数切分会无意识地把一句话从中间截断、把一个完整概念拆到两个 chunk 里。比如一份产品说明里写该产品支持 TLS 1.2 和 TLS 1.3 两种加密协议如果切分边界落在TLS 1.2和TLS 1.3之间检索的时候无论 query 涉及哪种协议模型拿到的都是半句话。我实践下来比较有效的做法是按语义边界切分优先按标题、段落、列表项这些自然的文档结构切如果文档没有清晰结构再退一步按句号、分号等边界做滑动窗口。滑动窗口的好处是可以设置重叠overlap让相邻 chunk 共享一小段文本避免信息在边界处丢失。切分时还要考虑业务实体的完整性——如果知识库里的内容大量涉及产品编号、合同条款、代码片段这类强关联实体切分单元应该尽量保留它们的完整上下文。衡量切分好坏我有一个很简单的方法把切出来的 chunk 随机抽 100 个人眼扫一遍看能不能在不看原文的情况下读懂每段在讲什么。读不懂的比例超过一两成说明切分策略需要调。4.2 嵌入模型选型别盲选也别只看排行榜嵌入模型决定了一个 chunk 被理解成什么样。同一个 query在不同 embedding 模型下检索出来的结果可能天差地别。选型时我通常关注四个维度语言适配性。如果知识库以中文为主优先选在中文语料上训练或调优过的模型。通用英文模型处理中文的效果不一定差但细节上的语义偏差会在检索环节放大。向量维度与存储成本。维度越高表达能力越强但存储和计算成本也越高。对百万量级以下的知识库来说768 或 1024 维基本够用不必硬上 3000 维的大模型。输入长度上限。不同模型能接受的最大 token 数不同要跟你的切分大小匹配。如果 chunk 经常超过模型输入上限会被截断等于信息白切了。是否支持领域定制。有些场景下通用 embedding 效果不好需要用领域数据做后续训练。选型时提前问一句这个模型能不能在自有数据上继续训练能就留了一条优化后路。团队里如果没人专门研究过 embedding我建议先拿一批真实问题做检索命中率评测再对比两三个候选模型。不要只看排行榜分数因为排行榜的数据分布跟你的知识库通常不一样。4.3 重排序为什么是效果上升的杠杆重排序是很多 RAG 项目被忽视但收益最高的环节。向量检索的 Top-K 结果里真正有用的可能只有两三条其余都是语义沾边、内容无关。直接喂给模型轻则浪费 token重则让模型被不相关信息带偏。重排序的做法是在粗排结果上再跑一个更强的模型通常采用交叉编码器结构——把 query 和候选文档拼在一起输入模型输出一个相关性分数。这跟向量检索的双塔结构不同交叉编码器能看到 query 和文档之间的完整交互判断更精细代价是速度慢所以只能对 Top-K 里的几十条结果做精排。我一般会这么搭配向量库先粗筛出 2050 条候选重排序后取前 58 条给模型。这个组合兼顾了召回率和精排质量。加上重排序之后比较明显的变化是答案像是从正确的文档里摘出来的了而不是读了好几段废话之后猜了一个答案。5. 落地 RAG 时最容易踩的坑与排查链路这一节全是实战里我踩过或帮别人排查过的坑。每个坑我都会给出现象、原因和排查路径方便你自己对照。5.1 坑一query 与文档的粒度错配这是 RAG 项目中最隐蔽、最容易让人一头雾水的坑。现象是你问一个很具体的问题检索出来的资料全部是泛泛的背景介绍根本没有直接答案。原因是用户的 query 粒度是点状而文档切出来的 chunk 是面状。比如知识库里存的是《员工手册》全文切分后每段覆盖一个大主题。用户问年假可以累积到第二年吗而相关句子藏在休假制度那一章的一大段文字里向量检索时这段文字跟 query 的语义重合度并不高排到了很靠后的位置被 Top-K 截掉了。排查链路先把你自己的 query 拿去检索把召回的前 10 条一条条看过去确认是不是有相关性高的内容被排在后面如果有说明向量检索的排序不准需要调切分粒度或加重排序如果连相关内容都没召回那可能是切分把关键句子弄丢了或 embedding 对领域术语理解不够。5.2 坑二假阳性检索结果混入上下文假阳性是指某条结果本身跟 query 部分相关但关键信息是错的或者属于另一个产品、另一个版本的资料。比如你问V2 版本的配置项 X 有什么用检索召回了 V1 版本的同样配置项说明模型若无其事地拿旧版资料回答了你。这类问题光靠向量检索很难根除必须在检索前后做好元数据过滤。这也是我建议大家维护元数据字段的原因文档版本、适用产品线、更新时间、作者权限……在检索前先把这些元数据当作过滤条件传入可以大幅减少跨版本、跨业务的串扰。如果排查时发现这类问题频繁出现先看元数据过滤条件设置了没有再看 Top-K 里有没有混入明显不满足条件的结果最后才是调整 embedding 和重排序。5.3 坑三上下文太长导致模型选择性失明有人为了尽量多给资料Top-K 设到 20每个 chunk 又是 800 字一份 prompt 光资料就一万多字。结果模型回答出来的内容越来越空甚至开始重复提问里的词句。原因是模型的注意力在超长上下文里会衰退中间段的资料经常被忽略。我自己的经验是给模型的最终上下文里资料不超过模型输入窗口的三分之一到二分之一留出足够的空间给指令和组织回答。如果资料真的很多可以先做一个粗筛加精排把范围压到 5 条左右如果精排后仍然信息过载可以做一步段落摘要用一个小模型先把长 chunk 压缩成要点再交给主模型作答。这个坑排查起来最简单把完整 prompt 打印出来数一下资料占了多少 token超过了就降 Top-K看回答质量是不是反而上去了。5.4 一条可复用的排查链路如果你被一个说不清原因的效果问题卡住我建议按下面的顺序排查而不是乱试先看原始文档解析找一个明确有答案的问题去原文里定位答案所在的位置。再看切分确认答案所在的那段文本是被完整切进了某个 chunk还是被截断了。单测检索把 query 单独跑一次检索看召回的前 20 条里有没有包含答案的 chunk。检查重排序如果答案在粗排的 Top-20 里但没进精排的 Top-5问题出在重排序如果根本没进 Top-20问题出在检索或切分。最后看 Prompt排除了上面的所有问题之后再把最终喂给模型的 prompt 完整读一遍看指令是否清晰、资料顺序是否合理。这套链路能覆盖绝大多数效果问题的定位。我见过太多人一上来就调 embedding 模型、换向量数据库忙活半天发现是 PDF 解析把表格内容弄丢了——先用链路排查别做无效优化。6. 从 RAG 到 Agentic RAG管道正在变成一种能力RAG 做了一段时间之后你会发现它有一个天然局限它是一问一答的静态检索。用户问什么系统就检索什么然后把结果直接交出去。但 Agent 的任务往往不是一次查询能完成的。比如用户说帮我分析一下我们上个季度的客户流失原因再给出三条建议这个问题需要拆分步骤先检索流失数据相关文档再检索产品更新记录还要结合行业文章——不同步骤需要不同来源的知识单纯一次 Top-K 检索根本解决不了。这就是 Agentic RAG 的出发点。在这个模式下检索不再是一次被动查询而是一个可以由 Agent 调用的工具。Agent 根据任务进度自主决定现在需要查什么、用什么关键词查、查完之后下一步该做什么。它可以跑多轮检索把几次检索结果汇总后再回答。这个模式真正把 RAG 从给模型喂资料的管道升级成了Agent 认知能力的一部分。从落地路径上看我不建议一上来就冲 Agentic RAG。先把基础 RAG 的质量做到稳定——切分合理、检索精准、重排序到位——然后再给 Agent 接入工具调用的能力。因为 Agentic RAG 的问题复杂度更高如果基础 RAG 本身就飘Agent 的多步检索会被错误累积放大排查起来也更痛苦。就我个人的实践感受来说RAG 最容易被低估的不是技术而是数据质量意识。把文档梳理清楚、把知识结构想明白效果比换任何模型、任何数据库都来得快。带着这个思路去做 Agent 的知识获取管道你会发现很多问题其实在进入检索之前就已经注定结果了。