AI Agent 知识获取管道：从 RAG 基础到 Agentic RAG

在开始写之前我想先说明一下我读到的这个标题走进 AI Agent 第四篇知识获取管道——RAG 基础。这是当前 AI 圈子里最热的实操方向之一。如果说 Agent 是一台智能机器那 RAG 就是它的供水系统。没有水机器再聪明也转不起来有了管道大模型才能真正接触到私域知识、实时数据回答出有依据的内容。这篇就围绕知识获取管道这条主线把 RAG 的全流程拆开讲透适合正在从零搭建 Agent、想搞清楚 RAG 到底在解决什么问题、以及如何在 2026 年的产品环境里把知识库落地的开发者参考。1. 知识获取管道为什么 Agent 必须先解决吃饱饭的问题1.1 Agent 的三层知识结构先想一个最核心的问题AI Agent 的知识从哪里来当你让 Agent 回答公司 2025 年第四季度的销售数据是多少它凭什么能给出准确的答案这里面的知识其实分三层第一层是大模型自身的参数知识。也就是模型在海量语料上预训练时学会的那些通用能力——语法、逻辑、常识、数学推理。这一层知识在模型训练完成的那一刻就冻结了它不会主动更新也不会知道你的公司内部发生了什么。很多企业上来就让大模型回复业务问题发现它一本正经地胡说八道毛病就出在这——你拿着一个只能靠记忆回答问题的引擎去处理它根本没记忆过的事情。第二层是上下文窗口内的临时知识。也就是你在 Prompt 里塞给它的那些参考资料。这一层非常灵活你能把最新报告、数据库查询结果直接喂进去让模型基于这些内容作答。但缺点也很明显上下文窗口是有限的你不可能每次都把几十万字的文档全塞进去而且塞得越多模型顾此失彼的概率就越高注意力被稀释回答质量反而下降。第三层才是 RAG 真正干的事——外部知识库。把文档切碎、向量化、存起来等用户提问的时候系统实时从库里召回最相关的内容拼装成上下文再交给大模型生成答案。这层的核心价值是既无限又新鲜知识库可以无限扩充知识可以随时更新而且每次回答都带着证据链回来模型不用猜照着材料说就行。RAG 等于把模型的知识边界和系统的知识供给解耦了。模型还是那个模型但你可以给它装上源源不断的活水。1.2 知识获取管道在 Agent 里的定位把 Agent 拆开看它的工作流通常是这样的用户输入 → Agent 规划任务 → 调用工具/检索知识 → 整合信息 → 生成回复 → 执行动作。在这个链路里知识获取管道承担的是信息输入的职责。没有它Agent 就是一个只有大脑没有眼睛和耳朵的空壳有了它Agent 才能感知到具体的、鲜活的、私域的信息环境。我常给团队打的一个比方是大模型是一个刚毕业的高材生聪明但没经验。你直接问他咱们公司的报销流程是什么他只能瞎编但你递给他一本员工手册让他查完再回答他就能给你一个八九不离十的准确答案。RAG 就是那本员工手册而且是会自动更新、自动检索、自动标注页码的手册。从实际工程角度看RAG 在 Agent 里还有一层规划层面的意义。一个复杂的 Agent 任务往往需要多轮工具调用而每轮调用之后拿到的结果本质上都是知识获取的一部分。你查数据库、调 API、读文件全部可以理解为知识管道的延伸。所以 RAG 不是 Agent 的一个可选配件而是整个 Agent 系统的地基工程。1.3 国内 2026 年 RAG 落地环境为什么要现在动手看热搜词里那一串——rag知识库、rag实战、搭建本地rag、基于 langchain 的 rag流程、agentic rag——就知道这个领域已经从概念验证走到了规模化落地的阶段。2026 年国内做 AI Agent 的产品盘点里几乎所有拿得出手的智能体都内置了知识库能力区别只是做得好不好、快不快、准不准。这个时间点动手做 RAG最大的红利是工具链已经成熟到不用重复造轮子的程度。本地有 net rag 甚至 ontology rag 这种带本体建模的选择云端有 rag as service 的托管方案Java 生态里 spring ai rag 已经能跟 spring cloud 无缝集成LangChain4j 让 JVM 系开发者也能轻松上车。换句话说现在的问题不是能不能做而是怎么做得更好。但反过来也要提醒一句工具成熟不等于效果达标。我做过的 RAG 项目里真正拉开差距的往往不是选了哪个框架而是对管道的理解深度——你知道文档切多碎吗你知道 embedding 模型选哪个吗你知道怎么评估召回命中率吗这些细节才是决定知识库好用还是废掉的分水岭。下面我就一步步拆。2. RAG 全流程解剖从文档到答案的五段管道2.1 管道总览先看整体再看局部RAG 的完整流程可以压缩成一句话知识入库 → 知识切分 → 向量化 → 检索召回 → 生成增强。这句话听起来简单但每个环节都有大量工程细节任何一个环节出问题最终答案的质量都会断崖式下跌。我习惯把 RAG 画成一条流水线入库阶段把 PDF、Word、Markdown、HTML、数据库记录等异构数据统一采集进来做清洗和格式归一化。这步做不好后面全是脏数据。切分阶段把长文档按语义、标题、固定长度切成块每块是一个可检索的知识单元。向量化阶段用 embedding 模型把文本块变成稠密向量说白了就是把一句话变成一串有数学意义的数字让计算机能计算语义相似度。索引与存储阶段把向量和原文一起存进向量数据库建立倒排索引和向量索引支撑快速召回。检索与重排阶段用户提问时把问题也向量化到库里找出 Top-K 最相似的文本块必要时再用重排模型精排一次。生成阶段把召回结果拼进 Prompt要求模型只基于这些材料回答并附上来源引用。这六个环节对应到用户感受上就是你问它一句它翻了一遍整个知识库然后把最相关的内容带上答案一起给你。而翻得准不准、带得好不好直接决定了这个 Agent 是真懂还是装懂。2.2 入库与清洗脏进脏出干净进才干净出很多人第一次做 RAG 时脑子里全是向量数据库、embedding 这些高级词汇结果第一步就在数据清洗上栽了跟头。我见过的典型场景是直接从公司内网拉了一堆 PDF 扔进去里面有扫描件、有表格、有页眉页脚、有重复段落结果检索出来的内容乱七八糟模型引用了一堆带第 3 页共 20 页的废文本。数据清洗的核心就三件事去噪、去重、归一化。去噪指的是把那些对语义理解没有帮助的噪声信息干掉——导航栏文字、页眉页脚、二维码描述、乱码字符都算。扫描版 PDF 要做 OCR这一步可以用 PaddleOCR 这类开源工具。表格类内容要考虑转成 Markdown 或者结构化数据而不是直接当作纯文本切否则表格语义会在切分时被切碎。去重更关键。很多企业内部文档有多个版本比如报销制度_V3_最终版.pdf和报销制度_最终版.pdf其实内容高度重合。如果你不去重索引里全是重复块检索时会反复召回同一个主题的不同说法模型容易把旧版本和新版本混在一起回答甚至自相矛盾。我一般用 MinHash 去做近似去重阈值调到 0.85 左右既能去掉重复又不误杀相似但不同的段落。归一化则是把格式统一。日期写成2025-01-15还是2025 年 1 月 15 日其实无所谓但要统一单位是元还是人民币要统一同样的专有名词大小写要统一。这一步不复杂却直接影响后面切分和检索的一致性。2.3 文本切分块的大小决定检索的天花板切分是整个管道里最容易被低估、又最影响效果的一步。它的难点在于度的把握块切得太小每块承载的信息不完整检索召回的片段支离破碎模型拼不出完整的答案块切得太大向量化后语义被稀释相似度计算不精准而且喂给大模型的上下文容易被无关信息灌满。我实际项目里的经验值给大家参考通用文档按 300~500 个 Token 切一块重叠 50~80 个 Token。这样既能保证每块有足够的语义完整性又能让跨块的上下文衔接不断裂。技术手册/操作指南这类文档行文结构清晰优先按标题层级切分。先用 Markdown 解析把标题树拉出来遇到二级标题就开新块块内再按段落续接。这样切出来的块天然跟用户的我要查某个功能怎么用这种需求对齐。表格数据单独处理不要跟大段文字混在一起切。建议每个表格作为一个独立块并且把表头信息重复拼接在每一行前面方便检索时命中行级内容。代码示例按函数或代码块切分保留注释。代码的语义边界在函数级别注释里往往藏着这段代码干什么的关键信息。切分策略没有银弹我的做法是多策略并行评估调优。先把几种切分策略都跑一遍用小样本的数据集标出哪些问题是系统该答对的然后对比不同切分策略下的召回命中率hit rate让数据说话而不是拍脑袋。2.4 向量化与索引先选对着色盘再谈画画切分完之后每一块文本就要变成向量了。这里的选择主要在两个层次embedding 模型和向量数据库。embedding 模型决定了语义相似度的度量基准。市面上有 openai 的 text-embedding-3 系列也有国产的 bge-large-zh、bge-m3、m3e还有最近很多企业用的通义 text-embedding-v3、Jina Embeddings 等。做中文知识库我建议优先考虑中文表现更好的国产模型。bge-m3 支持 100 种语言对中英混合场景格外友好通义的 text-embedding-v3 在中文长文本上的效果很稳。选模型的时候别只看榜单分数拿自己领域的真实数据测一遍才靠谱很多通用榜单一骑绝尘的模型到了你的业务场景里反而表现平平。向量库的选型也有讲究。milvus 适合大规模高并发场景单机版 qdrant 上手极快chroma 适合原型验证es 的向量检索能力也不弱。如果公司里已经有 elasticsearch 或者 opensearch用它顶上最省运维成本如果从零开始我建议先用眨眼就能跑起来的 chroma 或 falkordb 做 PoC等量级上来了再换专用向量库。记住不要在验证阶段就开始做架构军备竞赛。索引方面有个小细节一定要建混合索引。什么意思呢就是除了向量索引还要建全文索引。向量检索擅长找到语义相近的内容关键词检索擅长找到字面匹配的内容——这两者往往互补。用户问报销流程时向量检索能找到讲费用报销制度的段落因为语义相近但用户问ABC-1023 型号参数这种典型代码串时向量检索反而容易失手关键词检索却一打一个准。我现在的做法是两路并行召回融合排序后再取 Top-K效果比单用向量检索稳定得多。3. 检索策略与评估命中率是知识库的生命线3.1 从 Top-K 到重排序怎么让最相关的内容排最前面检索阶段的目标很纯粹找出跟用户提问最相关的 Top-K 个知识块。但最相关这个词在工程里往往很模糊。我举一个特别真实的场景用户问如何申请加班补贴知识库里有十条内容三条讲定义和适用范围、五条讲线上申请步骤、两条讲常见问题。向量检索召回的 Top-5 可能有三条都在讲适用范围因为这段文字跟申请这个动作的向量距离相近但它并不是用户想看的操作路径。这时候就需要重排序rerank来救场。rerank 模型跟 embedding 模型的区别在于embedding 是把文本映射到向量空间再比距离rerank 是把问题和候选文档直接拼在一起做深度语义交互后者更精细但计算成本高。所以现在的主流做法是双阶段召回第一阶段用向量检索关键词检索快速把范围缩小到 Top-50第二阶段用 rerank 模型精排成 Top-5 输出给大模型。bge-reranker-v2-m3 是我用下来性价比最高的 rerank 模型效果稳定资源开销可控。如果团队里没有 GPU 推理条件Cohere Rerank 这类 API 服务也可以用只是要评估延迟和成本。重排序这步在知识库规模小的时候可以省但一旦知识块数量超过一万它就是标配——直接决定你的 Agent 是次次都答到点上还是偶尔蒙对一次。3.2 命中率评估先定标尺再谈优化做 RAG 最忌讳的就是凭感觉。什么叫检索效果好不好如果没有量化指标你跟同事争论一天也争不出结果。我团队里默认的评估指标是三个第一个是 Hit Rate命中率。定义是对每个测试问题检查真实答案所在的原文块是否出现在召回结果里。如果在就算命中。比如你有 100 个测试问题其中 82 个问题的答案块被召回那 hit rate 就是 82%。这是知识库最核心的生命线指标。Hit rate 不高生成环节再努力也白搭。第二个是 MRR平均倒数排名。它衡量的是正确答案排得有多靠前。假设正确答案在召回列表的位置是 3那对这个问题的分数就是 1/3。把所有问题的分数平均得到 MRR。这个指标适合衡量重排效果——重排之后正确答案的位置是不是往前挪了。第三个是生成准确率Answer Accuracy/Correctness。让评测模型对 Agent 的最终回答打分看它是否正确、完整、并且忠实于召回文档。这一步可以借助 gpt-4o 或 qwen-max 做自动评估但要设计好评分 Prompt防止模型放水。有了这三把尺子优化方向就变得特别清晰。Hit rate 低 → 回头调切分策略、换 embedding 模型、加大召回数量Hit rate 可以但 MRR 低 → 上 rerank前两个都好但生成准确率差 → 改 Prompt 模板、调整上下文组织方式。数据驱动而不是感觉驱动。3.3 常见检索坑位为什么知识库有答案却找不到项目里踩过最多人踩的坑我给大家排个雷第一个坑是切分与问题粒度不匹配。用户的问题往往是某个完整功能怎么用而文档被切成 300 Token 的碎片后每块只讲了一个小步骤模型看到的是残缺的手册自然答不对。这种问题要从切分策略上解决——按文档结构切而不是机械地按固定长度切。第二个坑是语义相似但答案相反。比如知识库里有支持和不支持两个矛盾段落向量距离都很近召回都把两段带上了。模型面对互相矛盾的材料要么胡乱调和要么挑一边回答结果你怎么测都测不准。解法是入库前做冲突检测同一主题下矛盾的段落要打标或者人工确认检索时如果两段落相似度过高要去重降权。第三个坑是向量检索对窄召回词失效。很多专业名词、型号编码、冷门缩写向量空间里找不到相近的邻居。我刚才说的混合索引就是从这来的——关键词检索兜住字面匹配向量检索兜住语义扩展双保险才能减少漏召回。第四个坑是评测集不小心作弊。评测问题本身来自知识库原文改写跟训练语料重合度过高导致指标虚高、上线后立刻露出原形。评测集一定要留出类似用户在真实场景里会说的话而不是简单地把文档里的句子抽出来当问题。4. 从 RAG 到 Agentic RAG知识管道的进阶玩法4.1 传统 RAG 的局限一问一答但不会思考到这一步你已经能用基础 RAG 搭出一个文档问答助手了用户提问、系统检索、模型回答流程固定、效率稳定。但如果你把它搬进真正的 Agent 场景很快会发现几个问题的存在。第一个局限是多跳问题。用户问去年销售额最高的产品里哪个在华东区的退货率最低这需要先查出销售额排名再针对排名靠前的产品查退货率再对比得到结论。传统 RAG 一次检索只做一步回答这种问题全靠大模型瞎编。你需要让 Agent 自己规划先检索什么、拿到结果后再检索什么。第二个局限是不知道什么时候该查。在开放对话里用户可能先闲聊两句再抛出一个需要查知识库的问题。传统 RAG 会把每个问题都拿去检索导致闲聊话题也去库里找检索结果毫无用处还占上下文。Agent 需要判断现在是否需要调用知识管道。第三个局限是工具与知识的割裂。用户问帮我预约明天下午的会议室顺便告诉我上季度项目总结的重点——这既要调日历 API 又要查知识库。如果 RAG 和工具调用是两套体系Agent 就没法在一个任务里同时编排它们。这几个局限指向同一个方向RAG 不能只是一个被调用的函数它要变成 Agent 可自主决策的一部分——这就是 agentic rag。4.2 Agentic RAG 的三种核心能力我一直觉得 agentic rag 不是一种具体技术而是一组设计模式。落地时主要拆成三种能力第一种是按需检索。Agent 拥有一个决策节点判断当前对话是否需要检索知识库。判断的依据可以是问题是否包含事实性信息、是否涉及私域术语、用户是否明确要求查资料。这个决策可以用一个小模型来做也可以让 Agent 通过工具选择的机制自己决定。做到位之后闲聊不会误触发检索上下文也不会被无意义的检索结果污染。第二种是多步检索编排。Agent 可以拆解复杂问题生成检索计划先查什么、再查什么、中间是否要调用外部工具。实现方式可以是在 Agent 的工具列表里暴露多个检索入口按知识域分库检索也可以让 Agent 反复调同一个检索工具、每轮携带上一轮的推理结果再检索新内容。这一步是 Agent 化 RAG 的关键本质上是从一次检索定生死变成边推理边检索。第三种是查询改写与意图扩展。用户在对话里经常说它那个表格刚才提到的问题——代词多到检索系统想哭。Agent 的优势在于它看得到上下文可以先把用户的话改写成独立、明确的检索查询再送进知识库。比如用户说我跟你说过的那个报销问题的第二步怎么操作Agent 回溯对话历史改写成差旅报销申请流程第二步上传发票再下手检索命中率会大幅提升。4.3 技能Skill与 RAG 的结合思路热搜词里有人在问skill 怎么和 rag 结合起来这个问题太真实了。我的理解是skill 是 Agent 的行为能力RAG 是 Agent 的知识来源两者结合的关键是让知识触发技能、让技能产出新知识。举一个落地的例子企业内部有一个合同审查 Agent。它的技能清单里有条款一致性比对风险条款识别法规合规检查。这些技能的核心逻辑是规则和 Prompt 流程但执行每条技能时都需要查阅大量背景知识——历史合同模板、相关法条、公司风控红线。于是整个工作流就是Agent 接收合同 → 调用 RAG 检索公司历史合同库和法规库 → 加载文档内容作为技能执行的输入 → 执行合同审查技能 → 输出风险报告。RAG 相当于给技能装上了弹药库没有这个弹药库技能就是一个空壳的流程。反向的结合同样成立一次完整的技能执行会产生新的结果比如审查报告、数据结论这些结果也可以写回知识库供未来的检索使用。这就是 RAG 的自我进化——用过的知识沉淀下来越用越聪明。4.4 从零到一我推荐的 RAG 落地路线图如果你现在正要动手做一个 RAG 项目我建议按这个路线走能少走很多弯路第一个阶段先别碰代码。拿一个成熟的 RAG 产品把整个交互流程玩明白。现在国内外的 rag 托管服务、开源项目都有在线 demo你先给它们喂自己的文档看它们的切分效果、检索效果、引用方式。这一步是建立手感——你知道好的 RAG 应该长什么样才有资格谈自己搭。第二个阶段用一个轻量框架 48 小时跑通闭环。fastgpt、dify 这类工具或者 langchain 的 quickstart 教程都可以让流程先转起来。不要追求完美目标是看得到错误。跑通之后把代码停在本地开始动手改细节。第三个阶段建立评测集。从你的真实业务文档里挑 50~100 个问题逐个人工核对答案来源。这步不要省它是后续所有优化的基准线。没有评测集后面你换 embedding、调切分、加 rerank全都无法判断好坏。第四个阶段逐项优化。先切分、再 embedding、再检索策略、再重排、最后调 Prompt。每改一步跑一遍评测看 hit rate 和 MRR 的变化。经验数据是切分策略改写后 hit rate 往往提升 5~10 个百分点换成领域匹配的 embedding 又提升 5 个点加起来 rerank 再贡献 5 个点左右。这个阶段的产出才是有含金量的调通。第五个阶段接入 Agent 体系。把 RAG 管道封装成一个工具接口暴露给 Agent 调用再加上查询改写的逻辑让 Agent 带上下文地使用检索。到这一步你已经从RAG 基础走向了agentic rag。5. 避坑手记那些文档不会告诉你的实操经验5.1 关于 Prompt 模板生成环节才是最终背锅侠检索做得再好如果生成 Prompt 写得敷衍答案照样不行。我在多个项目里迭代出来一套相对稳的生成模板核心就三点角色设定、材料使用规则、答案格式约束。角色设定很简单你是企业内部知识助手请严格根据以下材料回答用户问题。材料使用规则是关键如果材料与问题无关请直接回答知识库中未找到相关信息如果材料存在冲突请指出冲突并说明多个说法不要编造材料外的内容。这一条能用指令把幻觉的可能性压到最低。答案格式约束可以让模型输出引用来源编号比如[1] 报销制度 V3 第 2.3 节。这样做的好处不止是让用户信服更重要的是方便你事后排查问题——用户说答得不对时你直接看引用了哪些块就能快速定位是检索错了还是生成错了。5.2 关于成本和延迟先算账再开工RAG 不是免费的主要成本在三个地方embedding 调用、rerank 调用、生成调用的 Token 消耗。我见过不少团队技术方案做得很漂亮一算账发现每天的成本根本扛不住。控制成本的几个土办法一是把知识库改成按需 embedding文档入库时算一次而不是每次检索都全库重算二是缓存系统消息和常用知识块的向量避免重复计算三是在 Prompt 里严格限制召回块数量Top-3 能解决的事不要 Top-10四是低频访问的知识库走冷热分层热数据放高配向量库冷数据放便宜存储甚至磁盘索引。延迟方面有个很实用的技巧把检索和生成做成流式并行。用户提问后先并行地跑向量检索和关键词检索等两者都回来后汇总重排再流式生成答案。第一 token 的延迟可以从传统的 3~5 秒压到 1~2 秒体感提升非常明显。5.3 关于安全与权限知识库也有涉密等级企业内部知识库最容易被忽视的就是权限隔离。很多团队的 RAG 管道是全公司共用一个向量库结果就是普通员工一搜索把 HR 的薪酬文档、核心项目组的保密方案全都召回了。这个问题上线前必须解决。做法上可以给知识块打权限标签标签颗粒度可以细到部门、角色、项目检索时根据当前用户的身份过滤不可见块。更进一步的方案是多库隔离——权限不同的知识域放到不同的索引里Agent 根据用户上下文动态选择可检索的库。技术上都不复杂但一定要纳入一期方案不要等到出事故再补。5.4 关于持续更新知识库是活物不是一次性工程RAG 上线只是开始它更像一个需要持续运营的知识产品。文档会更新、业务会变化、用户会问出知识库里没有的新问题——这些都需要有一套更新机制来兜底。日常运营里我建议至少做三件事一是定期的增量索引任务新文档入库后自动切分、向量化、去重二是未命中日志分析把系统召回不到答案的问题定期捞出来人工判断是切分问题、检索问题还是真缺知识分类处理三是知识库质量回顾每个月挑一次优先级最高的知识域做一次人工评测防止检索效果随着文档膨胀而劣化。这个活很累但它才是 RAG 项目真正的护城河。工具链谁都能搭持续把知识库喂好、调好、迭代好才是别人抄不走的竞争力。6. 终点也是起点知识管道的下一站写到这里RAG 的整个知识获取管道就算完整拆完了——从数据清洗、文本切分、向量化、索引、检索、重排到生成增强再到 agentic rag 的进阶玩法每一步都有它存在的理由也都有它在实操中的坑位。你拿这篇文章对照自己手头的项目应该能立刻定位到问题出在管道的哪一段。我个人在实际操作中的体会是基础 RAG 的门槛没有想象中高但要真正让它成为 Agent 可信赖的知识底座靠的是对数据细节的死磕和对评测指标的坚持。别急着上高大上的框架先把手里的文档洗干净、切好块把 hit rate 测明白你离一个真正有用的知识库就不远了。最后再分享一个小技巧刚开始做的时候尽量把知识库的规模控制在小而精——先做公司里使用频率最高的那 50 份文档做到检索准确率 90% 以上再去铺量。很多项目失败都不是因为技术不行而是因为知识库越做越胖、越胖越糊到最后什么内容都搜不准。小而精精而准这条路才是 RAG 落地最稳的方向。