1. 知识获取管道为什么RAG是Agent落地的第一道坎聊到AI Agent很多人第一反应是“给大模型接上工具”或者“让模型自己规划任务”。但真正从0到1把Agent从Demo推到可用状态的人心里都清楚一件事Agent的推理能力再强喂给它的知识不行输出照样拉胯。这也是“走进 AI Agent 第四篇”会专门聚焦在知识获取管道上、并且默认用RAG打底的原因——RAG解决的不是“模型会不会答”而是“模型凭什么答”。先给还在上车的读者一个定位RAG全称Retrieval-Augmented Generation检索增强生成。它的核心思路非常朴素大模型的知识截止日期固定、内部参数容量有限那我就把私有知识先存到外部知识库里等用户提问时先从知识库里把相关的片段捞出来再连同问题一起交给大模型让模型“带着参考资料作答”。听起来不复杂但真做起来从切分策略、向量化模型选择、检索排序到和Agent的规划循环怎么配合每一层都有坑。这篇面向的对象有两类。一类是你已经跑通过基本的Agent链路比如ReAct模式下模型能调工具但发现它一碰到领域细节就胡说八道另一类是你在RAG项目里单独试过文档问答返回结果还不错可一旦要让Agent自主决定“什么时候查、查什么、查完怎么用”就卡住了。这篇文章就是要把知识获取管道这一层彻底拆开先讲清楚RAG在Agent里到底承担什么角色再逐层看索引构建、检索质量、上下文组装这些环节的实操要点最后聊聊我从实际项目里踩过的坑和排查思路。先说个结论RAG不是Agent的可选组件而是Agent记忆系统的外置化实现。Agent本身有短期记忆对话上下文窗口但长期记忆、领域知识、实时信息这几块不落到RAG管道里Agent就只是个“会调用工具的聊天机器人”而不是“懂行的助理”。理解了这层你再看市面上那些“Agentic RAG”的讨论就不会觉得是新概念而是RAG在Agent规划能力加持下的自然演进。整个知识获取管道可以切成五层数据接入、文档解析、文本切分、向量化与索引、检索与重排。每一层独立看都不难但串联起来之后任何一层的劣化都会直接放大到最终回答质量上。接下来我按实际开发顺序一层层说。2. 索引构建文档从“能读”到“好查”的第一步2.1 数据接入与解析别小看这一关大部分RAG项目死得最早的环节不是模型不行是文档压根没被正确读出来。PDF里是扫描件、PPT里的文字是图片格式、Word表格跨页被拆断、网页正文混着导航和广告这些场景我基本每周都能遇到。先说我的经验结论先做文件类型白名单再做内容解析验证最后才谈切分和向量化。很多教程直接给你一段PyPDFLoader的代码你跑通了本地PDF就觉得万事大吉但真实知识库里往往是混合格式——产品手册是PDF、内部Wiki是HTML导出、技术方案是Markdown、Excel里还躺着SKU清单。如果解析阶段不按类型分流处理后面检索的质量根本无从谈起。以PDF为例我建议至少区分三种情况文本型PDF可以直接提取文字重点处理页眉页脚、目录、页码干扰。扫描型PDF必须接OCR管道中文场景推荐PaddleOCR或RapidOCR不要指望通用OCR一把梭。复杂版式PDF双栏排版、表格嵌套、图文混排建议用版面分析工具先把页面切成区块再提取。实际操作中我有一个很笨但很有效的验收办法解析完成后对每个文档抽样10%的内容打印出来看一眼。不是看文字对不对而是看段落顺序、标题层级、表格结构有没有被打乱。因为后面切分是依赖文本顺序的如果这里顺序乱了切出来的每一片都是“语义碎片”。2.2 文本切分策略字符数、段落还是语义块解析完之后就是切分。切分的目标很直白把一个长文档切成若干“语义完整、长度适中”的小块。太长检索召回时会把不相关的内容裹挟进来太短单块信息量不够模型无法理解上下文。最基础的按固定字符数切比如512个字符或1024个字符配上overlap重叠窗口实现成本最低。但它的硬伤是分界线很可能是句子中间甚至把一个完整概念拦腰切断。比如“该产品不支持USB供电”被切成“该产品不支持USB”和“供电”召回后语境就变味了。所以我更推荐“段落优先 递归切分”的组合策略先用段落标记换行符、Markdown标题、PDF章节标记把文档切成语义完整的大块。如果某一块超过设定的最大长度比如1500字符再按句子边界递归切小。相邻块之间保留适当overlap一般50-100字符防止跨块语义断裂。这块有几个经验参数可以给出来参数推荐范围说明最大块长度500~1500字符中文场景我常用800字符过长检索噪声大过短信息量不足Overlap50~150字符用于缓解边界语义截断具体要跟着块长度走切分维度段落优先先按结构切再按长度兜底不要一上来就按字数硬切对于有隐含层级结构的文档法律条款、技术规范、产品FAQ我个人会用“父子块”方案父块是完整的章节或条款子块是细粒度片段。检索时命中的是子块但传给模型的是父块全文上下文完整性会好很多。2.3 向量化模型选择与索引存储切分完成之后每一段文本要变成向量才能做相似度检索。这一步有个常见误区向量模型的选择比索引存储的选型更影响你的RAG上限。流水线后面检不检得准很大程度取决于文本段落转成向量之后相似语义的距离是否足够近。中文场景下我的建议是分几个梯队评估第一梯队通用效果好BGE系列如bge-large-zh-v1.5、M3E系列、Text2Vec-Chinese这几个社区验证多中等规模知识库够用。第二梯队多语言/跨语种GTE系列、Multilingual E5适合文档和查询语言不一致的场景。第三梯队蒸馏小模型如果部署环境资源有限BGE-small、MiniLM等轻量模型也可以跑但检索精度会明显下降适合Demo。挑向量模型不要只看榜单分数一定要拿你自己的领域文档做召回测试。我踩过的真实例子通用榜单上某个模型分数很高但放到我手里的机械行业技术文档里“扭矩”和“转速”的语义距离它算得不准检索结果就特别漂。索引存储方面中等规模知识库几万段以内用FAISS或者Milvus Lite就够不需要一上来就上分布式向量数据库。真正要关注的参数是索引类型Flat暴力检索精确但慢适合小规模验证。IVF系列聚类倒排索引速度和精度折中适合百万级以内。HNSW图索引召回率高、查询快是当前主流默认选择。实操里我用FAISS时IndexHNSWFlat配合M16、efConstruction200在几十万向量规模下检索延迟基本在几十毫秒量级完全够用。向量化字段记得做归一化否则后续算余弦相似度容易出偏差。3. 检索质量召回率、重排与查询改写3.1 检索召回别只盯着TopK很多人在RAG里对“检索”的理解就是“向量相似度TopK”。这块恰恰是Agent场景下最需要重新审视的地方——Agent的问题不是单一事实型问题而是复合型问题。比如“对比A产品和B产品在防水等级上的差异并给出B产品的适用场景”你如果把它当成一个整体去向量检索召回出来的很可能全是某个产品页面的某个段落压根没法支撑对比回答。我的做法是在Agent调用RAG接口之前先做一轮查询改写和意图拆分。有两个思路可以落地意图识别判断问题是否需要检索知识库。闲聊、通用常识、纯推理任务没必要走RAG管道直接让大模型回答即可。省一次检索延迟也减少噪声注入。子问题拆分把复合问题拆成若干个独立查询。比如上面的例子拆成“A产品防水等级”“B产品防水等级”“B产品适用场景”分别检索再合并结果。召回数量这块固定TopK比如Top4或Top6是最省事的但不够稳。我给的建议是“按相关性阈值动态截断”设定一个相似度下限比如0.35具体要按向量模型实测调低于这个值的段落不进入上下文在此基础上再限制最大条数比如Top8兜底防止相关片段太多把上下文窗口挤爆。还有一个容易被忽视的点只检索向量会漏掉精确匹配的信息。产品型号、编号、法规条文这类内容向量检索的表现往往不如关键词匹配。所以我在线上RAG用的是“混合检索”向量召回 BM25关键词召回再用RRFReciprocal Rank Fusion合并排名。实测下来混合检索在包含代码、型号、标准号的知识库中命中率比纯向量高出一截。3.2 重排用精排模型把TopK里的大鱼捞回来召回阶段追求的是“别漏”所以TopK里大概率混着不少不相关或弱相关的片段。如果这些片段直接塞给大模型轻则增加上下文噪声重则让模型被错误信息带偏。重排Rerank就是用来做第二次筛选的。重排的思路不复杂召回阶段用轻量向量模型粗筛出候选集比如Top30然后用一个更强的交叉编码器模型对“查询-候选段落”逐对打分重新排序取分数最高的Top3到Top5进入最终上下文。在Agent场景里重排解决一个非常实际的问题模型多轮对话后提问里往往带着指代和隐性上下文纯靠向量匹配已经失真了。重排模型能看到完整查询和完整候选段落相关性判断能力明显更强。中文场景常用的是BGE-reranker系列效果和速度都可用性价比很高。我一般把重排放在“混合检索合并结果之后”做一次就够不要做两遍耗时翻倍收益不显著。3.3 查询改写与多轮对话适配Agent调用RAG时往往不是在单轮问答里调一次而是在多轮任务里反复调。这时候有个很经典的坑用户说“那它的价格呢”向量检索如果直接拿这句话去搜根本搜不到任何东西。因为“它”指代的是上一轮提到的产品这句话本身没有足够的语义锚点。标准的解法是查询改写把多轮上下文里的指代词补全把简略表达还原成完整查询。实现方式有三种路径模板规则简单场景下把最近几轮用户和Agent的内容拼接让大模型生成“适合检索的独立查询”。实现简单成本可控适合早期验证。独立改写模型用一个参数较小的LLM做专门的查询改写链路更稳定避免主对话模型的上下文污染。Agent内联合改写把改写动作交给Agent自身在规划里完成改写结果作为工具调用的输入参数。这也是Agentic RAG里的常见形态。我的建议是在Agent架构里把“查询改写”当成RAG工具内部的一个固定步骤而不是依赖Agent模型偶发的自觉。固定步骤保证稳定性剩下让Agent去做任务拆解和结果综合。4. 上下文组装让“喂给模型的东西”真正可用4.1 检索结果怎么进Prompt不是拼上去就完事很多RAG项目死在了最后一步召回内容质量不错但拼进Prompt之后模型输出还是不行。为什么因为上下文组装这件事细节决定成败。先说结构。一段合格的RAG上下文应该至少包含三块信息检索来源文档名、页码/章节、内容片段、相关性提示比如让模型优先使用检索内容。纯扔一坨文本进去模型不知道哪些是重点、哪些是背景也不知道回答时要不要引用出处。我常用的Prompt结构大致是你将基于以下检索到的资料回答用户问题。 资料1来源产品手册v3.2第12章防水等级说明 ... 资料2来源FAQ库 ... 请结合资料给出答案如果资料中找不到答案请明确说明“知识库中没有相关信息”不要臆测。这样做的效果有两个一是模型“有据可依”不容易幻觉二是有来源标注之后Agent可以把来源一并返回给用户做溯源展示信任感完全不同。还有一个细节容易被忽略检索到的多个片段之间往往内容重复甚至互相矛盾。尤其是同一个主题分布在多个文档里的场景。矛盾信息直接塞给模型模型会蒙圈或者自行“和稀泥”。我的处理方式是在组装前加一个轻量去重和冲突归纳如果两段内容高度重复保留信息量更完整的如果存在矛盾把矛盾点显式标注出来让模型去判断哪个更权威。4.2 上下文长度预算RAG和Agent记忆怎么分配Agent场景下有个比单轮RAG问答更棘手的问题上下文窗口是有限的RAG检索结果要和对话历史、工具调用记录、Agent的思考过程抢空间。如果每次RAG返回Top8长片段几轮对话下来上下文窗口就爆了。这块我采用“分区预算”的思路对话历史区压缩后的多轮摘要或最近N轮对话负责保留任务主线。工具记录区已经执行过的工具、参数、关键结果摘要。RAG上下文区本次回答实际依赖的检索片段只放当前轮次需要的放完用完即弃。任务指令区系统Prompt、角色设定、输出格式要求这个区基本不变。落实到实现上我会限制RAG检索结果的总字符数比如上限2500字符TopK数量跟着这个预算走而不是固定Top5。宁可少给也要给精准宁可截断也不能让无关片段挤掉Agent的推理空间。另外Agent每轮调RAG时前一轮检索的片段不应该一直留在上下文里。处理完的段落要归档或裁剪只保留本轮相关的片段。这是Agentic RAG和普通知识库问答最明显的差别——普通问答是无状态的Agent是有状态的状态管理不做知识管道迟早拖垮Agent。4.3 知识库更新的同步问题最后说一个容易被忽略、但线上一定会遇到的坑知识库的更新滞后。Agent背后如果是一套定时任务去更新索引那么用户在多轮会话中可能已经引用了最新的情报但知识库检索出来的还是旧内容两边一冲突Agent就露馅了。我的建议是把知识更新也封装成Agent可调用的工具。例如search_knowledge_base(query)常规检索。upsert_document(doc_id, content)增量更新单篇文档。delete_document(doc_id)删除失效文档。这样Agent在执行任务过程中如果发现知识库缺失某项信息可以通过工具自行补全而不用等离线管道。增量更新时要注意向量索引的同步策略小规模增量可以直接重建或插入大规模量级则要考虑增量索引的合并周期。5. 从RAG到Agentic RAG让知识管道长出手脚5.1 Agent怎么决定“什么时候查、查什么”RAG标准管道是“用户提问 → 固定检索 → 组装上下文 → 生成回答”。Agentic RAG的本质变化是把中间步骤从固定流程变成Agent可决策的环节。这也是我这篇标题里“知识获取管道”想带出来的进阶视角——管道不只是被动被调用它可以被Agent编排。典型场景是Agent接到一个任务“帮我把这个产品线的常见问题整理成一份FAQ文档”。标准RAG只能被动回答碎片化提问但Agent可以把任务拆成多个检索动作每个动作查询不同的子主题再把多次检索结果归纳成结构化文档。中途发现某类问题的知识在库里不足Agent还会发起增量检索或者主动问用户要资料。这套循环就是Agentic RAG。落地时我给Agent设定的知识获取能力包括四个工具查询改写将多轮上下文转化为独立检索语句。知识检索混合检索 重排返回带来源标注的片段。知识库状态检查判断指定主题在库里是否存在、覆盖情况如何。知识写入/更新新知识落地或旧知识修正。有了这四个工具Agent就不是“只能查”而是“能感知知识边界能补全知识能利用知识做事”。这就是知识管道从被动组件变成主动能力的升级路径。5.2 Agent内部多跳检索的取舍多跳检索Multi-hop Retrieval是Agentic RAG里一个很吸引人的概念Agent先查到A文档从A文档里发现需要确认B信息再发起第二轮检索。听起来强大实操中却很容易翻车。我的经验是多跳检索不要无脑放开要设置严格的跳数上限和上下文预算。每一跳都会消耗时间和上下文窗口三跳以上如果还没有收敛到结果大概率是查询改写或召回策略出了问题继续跳只会让错误累积。实际项目里我更推荐“子问题并行检索 一次综合”的做法Agent在规划阶段把问题拆成多个独立子问题并行发起检索节省时间拿到结果后做信息整合。这种方式比“串行多跳”稳得多尤其在工具调用并发支持良好的框架里效果提升非常明显。另外如果你用的是LangChain或Spring AI这类框架注意工具调用的结果如何回填到Agent的上下文中。很多框架默认只把工具返回的最终文本塞回去而丢失了检索结果的结构化信息来源、分数、段落ID。这也是我强调重排后要保留来源标注的原因——Agent后续如果需要与用户对齐出处结构化信息必不可少。5.3 从RAG知识库到Agent记忆的统一视角聊到这里其实可以把RAG和Agent记忆放在同一个画面里看了。Agent的记忆系统如果画成一张图大致三块短期记忆当前对话的上下文窗口对应Agent的会话状态。长期记忆用户偏好、历史决策、任务结果这些是跨会话沉淀下来的。领域知识产品资料、技术文档、FAQ这些就是RAG管道管理的对象。三者不是孤立的。一个成熟的Agent应该在长期记忆里记录“用户上次问过哪些方向”在领域知识里检索“最新的产品规格”再结合短期对话上下文实时回答问题。我个人的实践是把RAG知识库当成可读写的外部记忆而不只是可读的知识源。用户确认过的事实、Agent自己生成的高质量答案都值得回写到知识库里。这个动作能让Agent越用越“懂行”。6. 实操复盘一个从0到1的Agent RAG练手难题6.1 练手项目怎么选才不会半途而废如果你还没有跑通过一个完整的AgentRAG项目我建议不要一上来就搭“企业级智能问答系统”。目标越大越容易卡在数据清洗和部署细节上。挑一个“边界清晰、语料可控”的场景比如“个人知识库问答助手”——把自己常用的技术文档、笔记、周报导进去做一个能回答“我上周结论是什么”“这个项目用了哪些技术栈”这类问题的Agent。为什么要选这类场景因为你自己就是语料的领域专家检索结果对不对你一眼就能判断。很多RAG项目效果“看起来还行”是因为提问者根本不了解底料被模型流畅的输出唬住了。用自己的数据你才能准确感受到召回质量和组装质量的真实水平。6.2 最小可用链路的落地清单我建议按下面这条链路落地每一步都验证过再进下一步准备10~20篇你自己的文档格式统一转成Markdown或纯文本。按“段落优先 递归切分”建立切分管线人工检查10%切分结果。选一个中文向量模型BGE或M3E用FAISS建索引。写一个最简检索接口向量召回Top10人工检查召回相关性。接入Rerank模型对比重排前后的Top5质量差异。写好Prompt组装逻辑让大模型基于检索结果回答问题。最后再接Agent框架LangChain、Spring AI、或其他你熟悉的工具全家桶把“查询改写-检索-组装-回答”封装成Agent的一个工具动作。这套链路看起来平淡但每一步都踩住了RAG的核心环节。我见过太多人跳过了第4步直接上Agent编排框架最后出了问题根本不知道是检索召回烂还是Prompt写法不对。6.3 评测与迭代没有评测RAG就是玄学RAG项目最容易陷入“感觉差不多”的状态同一个问题换一种问法结果截然不同但又说不出系统哪里该改。所以从第一天就要搭一套最小评测集。我的做法是准备20~30条覆盖不同场景的测试问题手工标注每个问题的相关文档片段和参考答案。每次改动换向量模型、调切分参数、加重排都跑一遍这组问题记录三个指标召回命中率RecallK相关文档片段是否出现在前K条结果里。答案忠实度模型回答是否严格基于检索片段有没有臆测。端到端可用率最终回答是否直接可用或只需少量修改。不用多准能对比“改动前 vs 改动后”就够了。有了这套评测基准RAG就不再是玄学而是可以持续调优的系统。我自己练手时曾经因为换了一个向量模型召回命中率从71%掉到58%如果没有评测集这种劣化根本感知不到。7. 踩坑笔记RAG在Agent场景下的高频问题与排查方法7.1 检索出来一堆“看似相关实则无关”的内容这是RAG新手最容易遇到的挫败。症状是检索结果的相似度分数都不低但内容跟问题根本对不上。原因通常出在向量模型和查询表达上。排查路径我建议按顺序来先拿原始查询直接跑检索检查召回结果——如果这里就是乱的问题出在索引或向量模型。检查查询本身是否太短或太口语化——尝试用改写后的完整查询再跑。检查切分粒度——如果段落太短单块信息量不足很容易“沾边但不解决”。最后考虑换向量模型或回退到混合检索。7.2 答案引用了知识库里不存在的内容模型一本正经编造知识库里的“依据”这是RAG最危险的问题。根源往往不是模型笨而是Prompt没有显式约束“只能基于检索内容回答”。我的处理方式是双保险Prompt里明确写上“当前对话具备知识库检索能力请严格依据检索片段回答不要补充外部知识”同时在答案生成后增加一个校验步骤检查回答中的关键实体是否在检索片段中出现过。如果有异常强制要求Agent重新检索或直说“信息不足”。7.3 上下文窗口被检索结果塞爆前面提过分区预算这里补充一个实操数字我常把RAG上下文限制在总窗口的30%以内。比如32K上下文的模型检索片段总预算控制在8K到10K字符剩下的空间留给对话历史、工具记录和推理链。记住一件事上下文越满模型越容易丢掉关键指令。宁可少塞检索片段也不要挤掉系统指令。7.4 Agent调RAG的次数失控有的Agent在任务中反复调RAG一度出现“一个问题查十几次”的情况。这通常是任务拆解粒度太细或者检索结果质量问题导致Agent觉得“没查到要的”。我的对策是设置单任务最大检索次数比如5次超过就强制Agent基于已有信息回答或向用户提问。检索结果返回时附带“内容覆盖情况摘要”让Agent快速判断是否命中而不是只看一条条片段自己猜。8. 写在最后的一点经验回顾整个知识获取管道我的最大体会是RAG链路里每个环节都是木桶上的一块板短板决定最终效果。索引构建粗糙检索再怎么优化也救不回来检索质量不行Prompt结构再精致模型也是拿垃圾当食材。与其迷信某个“最强向量模型”或“最强RAG框架”不如老老实实把每个环节的评测跑一遍找到自己的短板在哪里。另外一个从实操中沉淀下来的建议是不要一上来就追求“全自动Agent”。更稳的路径是先让Agent用“手动挡”——每一步检索都由用户在界面上逐步确认确认链路没问题了再把决策权交给Agent。这个过渡非常有用它能帮你看清RAG管道里哪些地方稳定可靠哪些地方还需要人兜底。知识获取管道是Agent的“眼睛”和“耳朵”它的质量决定了Agent能不能看清任务、听准需求。下一篇我会继续聊Agent的另一个重要组件——记忆管理到时候再和大家分享长期记忆、会话记忆怎么和RAG管道协同工作。