走进 AI Agent 第四篇知识获取管道——RAG 基础Agents 系列写到这里前面三篇我们聊了 Agent 的核心架构、工具调用与规划能力。今天这篇是第四篇主题聚焦在一个非常具体、也非常关键的模块上知识获取管道也就是 RAGRetrieval-Augmented Generation检索增强生成。如果你正在从零搭建一个 AI Agent大概率会被同一个问题卡住模型再强也没办法准确回答你私有知识库里的问题。RAG 就是用来解决这个问题的核心手段它把知识获取从模型参数里的固有记忆变成了一条可维护、可观测、可迭代的外部管道。这篇文章我会完整讲清楚 RAG 在 Agent 里到底承担什么角色、一条完整的知识获取管道长什么样、每个环节怎么落地、有哪些重要且坑爹的参数以及我实际踩过的坑。适合正在做 RAG 项目、准备给 Agent 接知识库、或者在选型阶段想搞明白要自己搭还是直接用服务的开发者参考。读完你至少能自己动手搭一条最小可用的 RAG 管道并且知道下一步往哪个方向优化。1. 内容整体设计与思路拆解1.1 为什么 Agent 需要一套外部知识管道先聊一个很基础的问题大模型本身已经知道很多东西了聊天、写代码、做总结都行为什么还需要外面再接一套知识库答案很简单模型参数里存的知识是训练截止时的通用知识而不是你业务现场的私有知识。你的产品文档、售后话术、内部流程、用户历史工单这些东西不在模型肚子里模型再强也编不出来。你硬让它答它就一本正经地胡说八道。另外还有知识更新的问题。哪怕模型今天上了新版本把最近的公开内容纳入训练你也不可能为了一个内部流程文档的改动就去重新训练或者微调一次模型。最理性的方案是把模型当成一个会说话的推理引擎知识不塞进它的参数里而是放在外部存储中每次问问题的时候先把相关的片段捞出来再连着问题一起交给模型组织答案。这就是 RAG 的核心思想检索的时候用外部管道生成的时候用大模型。在 Agent 体系里这个管道的地位更特殊。Agent 的规划能力告诉你应该怎么做工具调用能力告诉你能做哪些事但任何一个决策都需要事实依据。知识获取管道就是事实来源。没有它Agent 的每一步决策都是在凭感觉走。1.2 整条主线的四个环节RAG 基础管道其实就四个环节。我在这篇里会把它们拆开讲清楚因为后面做优化基本都是在这四个环节上做文章。第一个环节是数据接入与清洗。你在意的知识可能散落在 PDF、Word、Markdown、HTML、数据库里甚至在一个你内网 ERP 系统的某个接口里。第一步是把这些乱七八糟的格式统一抓出来转成纯文本去掉页眉页脚、表格错乱、无效字符再按一定粒度切成一个个片段。这个阶段很多人不重视但其实超过一半的 RAG 效果问题都出在这一步源头脏下游全废。第二个环节是向量化与索引。把切好的文本片段通过 Embedding 模型转成向量存进向量数据库。同时保留一个倒排索引或文本索引用于后续的关键词检索。真正的生产级 RAG 系统很少只依赖一种索引大多数是混合索引后面我会展开讲。第三个环节是查询与检索。用户问一个问题系统先把问题做查询改写Query Rewriting再做向量检索和关键词检索各自召回一批候选片段经过重排序Rerank精选 TopN组装成给模型看的上下文。这个环节直接决定模型能看到的证据链是否完整也是 RAG 效果波动最大的地方。第四个环节是生成。把用户问题、检索到的知识片段、以及一个明确的指令模板一起提交给大模型让模型基于给定的知识片段回答问题。这里的 prompt 设计、片段在上下文里的排序、token 控制都是有讲究的。很多团队在生成环节偷懒导致召回明明挺好最后回答却一塌糊涂。1.3 解决什么问题避开了什么方案我想花一小段说清楚为什么我用 RAG 来解决知识获取问题而不是用微调Fine-tuning或者长上下文硬塞。如果你做微调本质上是想改变模型本身。知识量一大微调的成本和迭代周期就失控了今天加一篇文档不可能明天就微调一版上线。长上下文硬塞也有它的致命伤当你的知识库文档总量超过几十万字符时根本塞不下而且塞进去的内容在注意力机制下会稀释模型很容易忽略中间部分。RAG 的优雅之处在于它把知识从模型参数中剥离出来了成为一个独立可更新的资源。加知识就是往库里加文档改知识就是删掉一段重传一遍。整个过程完全不碰模型改动成本低、速度快、可追踪。2. 核心细节解析与实操要点2.1 文档切分的粒度、策略与元数据第一个实操难点就是切分。切分粒度直接决定了检索的精度与召回。设想一下你把一个 100 页的 PDF 作为一个整体入库用户问一个问题整篇文档的向量都和问题不太像检索出的片段乱七八糟既没有针对性也没有证据感。反过来如果你把一句话切成一个片段检索是精准了但这句话通常缺乏足够的上下文模型拿到的信息太碎也无法组织出完整回答。实际经验中切分策略取决于你的文档类型。如果是产品说明书、规章制度这类段落结构完整的文本按标题结构做语义切分最合适就是利用 markdown 的标题层级或 PDF 的目录结构在合适的章节边界切一刀。如果是工单数据、FAQ 这类短文本就可以直接按条切。如果是连续没有结构的日志或年报就需要用固定 token 窗口切比如每 400~500 个 token 一段相邻两段保留 30~50 个 token 的重叠避免把语义完整的句子拦腰截断。切分的同时一定要顺手把元数据带上。元数据包括来源文件名、页码、章节号、时间戳、权限标签等。这些信息在后续检索排序、过滤、展示引用来源时都是刚需。很多团队入库的时候偷懒不存元数据后面被问到你的知识库有多少篇文章、每篇在哪个位置命中的时完全答不出来。元数据还会影响一些高级能力例如按部门隔离这是企业级 RAG 从 Demo 走向生产的必经之路。2.2 Embedding 的选型、维度与退化检测Embedding 选型是另一个决定 RAG 效果上限的关键环节。简单说Embedding 模型负责把一段文本变成一个向量数组向量之间的距离代表语义相似度。选错了模型后面无论怎么优化检索策略效果都会卡在一个不上不下的位置。我的建议是中文场景优先选择针对中文语料优化的开源模型这类模型在公开榜单上效果都还不错而且针对中文长文本、中文惯用语做了优化。英文混合场景就要关注模型是否支持跨语种。使用之前一定要搞清楚这个模型的向量维度是多少、最大输入 token 是多少、是否对短文本友好。维度越高存储和计算开销越大但不一定效果就更好具体要拿你自己的语料做评测。最关键的一点线上测试的任一环节都不要换 Embedding 模型。一旦换了所有已入库的向量全部失效必须重新灌库这个代价在数据量大了之后是灾难性的。我还会在库里边跑一个退化检测脚本每个星期抽样一些常见问题跑一遍检索看召回率有没有下降。知识库更新频繁的时候有些新入库的文档格式特殊Embedding 可能就退化了导致某些问题检索不到答案。这个脚本不复杂但能救你很多次。2.3 向量数据库与混合检索存储检索这一层市面上的选择很多。本地小规模场景直接用 FAISS 就够了纯 Python 库轻量、无服务、单机能力强。生产环境则要看你的数据量级、并发要求、是否要上线持久化服务。Milvus、Weaviate、Elasticsearch、OpenSearch 是几个主流选项。如果团队里已经有 ES 集群直接在 ES 上开启向量检索功能也是一种务实选择毕竟运维成本低。但只靠向量检索效果远远不够。向量检索擅长处理语义相似但用词不同的情况比如用户问怎么退款知识库里写的是退费流程向量能把它们关联上。但向量检索对精确匹配很不敏感产品型号ABC-100和ABC-200在向量空间里极其接近很容易混淆。关键词检索则相反它对精确词很敏感。所以生产级 RAG 一般采用混合检索向量召回与关键词召回并行再合并结果交给 Rerank 排序。这个策略没有什么高深理论却是我在实际项目里带回召率最有效的一招。3. 实操过程与核心环节实现3.1 一条最小 RAG 管道的搭建记录这里我给你一条可以直接跑通的最小管道实现我尽量不用特定框架给你拆成低耦合模块方便你理解每一段代码在做什么。第一步加载文档并做文本清洗。我会用一些常见的解析库把 PDF、Markdown、Word 转成纯文本。注意这一步里最容易踩的坑是 PDF 表格提取看似整齐的表格直接提取文本后会变成一行行没有意义的数字和汉字。如果你们的文档里表格很多我建议额外用 PDF 转 Markdown 的方案至少能保留表格结构信息。第二步文本切片。用大小固定的窗口切保持相邻段有重叠内容。这一步我在上面的章节里讲过属于粗加工。如果你想更精细可以引入基于标题的递归切分也就是优先匹配文档标题在标题边界切如果某一段太长再按字符数量切。这种策略对结构化文档很友好。第三步向量化并入库。对切好的每个片段做 Embedding把向量和原文、元数据一起存入向量数据库。本地 demo 阶段我强烈建议直接使用 FAISS没有服务依赖随时可以在 Jupyter Notebook 里看结果。如果你想用它做验证代码大概是这个结构import faiss import numpy as np # 假设 docs 是切好的文本片段列表embeddings 是对应的向量矩阵 dimension embeddings.shape[1] index faiss.IndexFlatIP(dimension) # 用内积作为相似度度量Embedding 模型如果是归一化的内积就等价于余弦相似度 index.add(embeddings) # 保存 faiss.write_index(index, knowledge_base.index) # 加载 index faiss.read_index(knowledge_base.index)第四步检索。给定一个用户问题转成向量在 FAISS 里做相似度搜索取 TopK。同时你也可以用同样的文本库建立一个 TF-IDF 或 BM25 索引做关键词检索。这一步我先给你一个最朴素版本只做了向量召回。D, I index.search(query_embedding.reshape(1, -1), k5) # D 是相似度分数I 是命中的片段序号 results [(docs[idx], float(score)) for idx, score in zip(I[0], D[0])]第五步组装上下文并调用模型生成。把命中的片段按相关度降序拼接起来前面加一段系统指令你是一个知识助手请只基于给定的资料进行回答如果资料中没有相关内容请直接说明无法回答。然后把问题附在后面。这里的关键点是控制总 token 长度不要让上下文无限膨胀。3.2 加上混合检索和 Rerank 的完整管道的优化方案上面的最小管道只能用于理解原理真实业务里会和能用的 RAG有明显差距。差距不在于流程不对而在于检索精度和上下文质量。我现在给的这套优化方案是我在实际项目里的标准配置。查询改写我放在检索前面。用户原始问题往往口语化、指代模糊比如那个功能怎么配置这里的那个功能模型不知道指的是什么。如果 Agent 的前置模块已经解析出了历史记录就可以把指代补全变成【日志分析】那个【日志采集】功能怎么配置再用这个改写后的 query 做向量检索。很多 RAG 项目不重视这一步导致检索的入口质量就是差的后面再怎么做重排序效果也有限。Rerank 这一步比很多人想象中重要得多。向量检索返回的 TopK 是候选集不是最终证据你要用更强的排序模型做精排。常见做法是用 Cross-Encoder 模型对问题-片段逐对打分。这是一条最实用的推荐第一轮用轻量的向量模型快速召回较大候选集比如 20~30 条第二轮用 Rerank 模型精排取前 5~10 条。虽然 Rerank 会给管道增加几十毫秒甚至几百毫秒的延迟但在知识问答场景里这个延迟通常值得因为证据链质量直接决定回答质量。另外在组装上下文时不要只是简单拼接。我建议你按顺序排列先放与问题最相关的片段再放次要的同时给每个片段前面加一行来源标注【来源产品手册_3.2节】。这一步有两个好处一是让模型知道每段知识的出处增强可解释性二是如果多个片段之间有冲突模型可以依据来源的优先级来做权衡。我给你一个可以对照调整的配置思路环节推荐做法说明文本切分按标题结构优先兼顾固定窗口保持段落语义完整性小段重叠 20~50 字符Embedding中文场景用开源中文向量模型注意最大 token 与维度部署前用本地语料测评索引向量索引 BM25 倒排索引两者互补覆盖语义匹配和精确匹配查询改写结合对话历史做指代消解可在 Agent 流程里加一步也可用轻量模型自动改写召回数量第一轮召回 20~30 条给重排序留足候选空间防止漏掉正确答案RerankCross-Encoder 对问题-片段精排精排后保留 5~8 条控制上下文长度Prompt强指令声明仅基于资料回答防止模型自由发挥并约定资料冲突时的处理策略输出约束按列表/JSON 输出附引用来源方便上层 Agent 解析结果3.3 Agentic RAG 的演进方向既然你是冲着 Agent 系列来的我建议你在理解基础 RAG 管道之后顺带了解一下Agentic RAG这个方向。它和基础 RAG 的区别在于基础 RAG 是一条直线问题进来检索一次生成答案。Agentic RAG 则是让主 Agent 自己决定我去检索几次、检索哪些库、是否需要换个 query 再查一次、查完之后我是否需要调用一个工具去验证结果。举个例子你问 Agent 某某版本的许可证什么时候到期 基础 RAG 流程是一次检索一堆文档很可能检索到多个版本的信息答案不精确。Agentic RAG 里Agent 发现这个 query 涉及版本号和日期两个实体于是它先把问题拆分先去向量库检索产品的版本说明文档再检索一份内部台账表两次结果合并后它决定调用一个日期计算工具核对剩余天数最后才生成答复。整个过程把 RAG 从一次检索 生成升级成多轮检索 工具调用 动态规划。这也是 2026 年各类 Agent 产品的核心卖点之一从能查进化到知道怎么查、查完还知道怎么用。不过我不建议一上来就做 Agentic RAG。先把基础管道跑稳、评估指标拉起来再逐步把 Agent 的规划能力加进去否则你只会得到一个又慢又难排查的乱动流程。3.4 把检索结果变成结构化证据链很多 RAG 项目忽略了一个小细节最终交给大模型的上下文不只是原始文本片段更应该是结构化证据链。这说起来很简单就是让模型在使用知识库时不只是看到文本而是看到每个片段对应的元数据、置信度和来源。实际落地时我是这么做的检索结果里除了文本内容还保留来源路径、页码和关键信息提取结果把这些一并拼进上下文字符串里。这样做的好处超出了预期一来是模型在生成时可以引用来源让用户知道结论出处二来在审计和调试时有据可查当回答出错时你能快速定位是检索错了还是生成错了。这一整套思路也是 Spring AI、LangChain4j 等框架里知识管理模块的设计雏形如果你现在就在用这些框架开发企业级 Agent可以顺着这个思路理解它的抽象层级。4. 常见问题与排查技巧实录4.1 检索不到正确知识的典型原因这是 RAG 上线后被抱怨最多的一项。用户问一个问题系统总是答不知道或者答出不相干的内容。我的排查顺序一般是这样第一先看原始文档切分是否有问题。如果一段文本被从中间切开向量化之后语义不完整自然检索不到。把召回结果的片段文本打印出来看一眼基本就能确认。第二检查 Embedding 模型是否合适。有些领域词表很特殊比如专业产品型号、化学名、医学术语通用 Embedding 模型对这些词不够敏感这时候需要检索关键词走 BM25或者换领域模型。第三检查检索阈值。很多向量数据库会设置一个相似度阈值低于阈值的片段直接过滤。这个阈值设太高检索结果会被全部滤掉设太低就全是垃圾。我遇到过最离奇的一个案例是知识库里明明有答案但把问题里的一个词稍微换个说法检索结果就完全不同。排查了半天发现是切分时把关键段落切进了两个相邻片段各自向量化后残余语义都不足以和问题对齐。后来我调整了切分重叠长度问题就消失了。这种问题往往只会在知识库规模上来之后才暴露。所以我的强烈建议是每次调整管道前建立一个典型问题-预期答案的回归集。不求上百条先建 20~30 条覆盖不同文档结构的例子一旦改动导致检索结果变差立刻就能发现。4.2 检索到了但生成回答错误有些情况是召回完全没问题片段里就是正确答案但大模型生成时给出了错误回答。这类问题通常出在提示词约束不够。你要明确告诉模型只能从提供的资料中作答资料中没有的内容不要自行编造。很多人写 prompt 的时候没有强调这一点模型会把参数里的固有知识和检索出来的资料混在一起一旦两者冲突模型经常会偏好自己更熟悉的答案哪怕那是错的。另一种情况是上下文中有相互矛盾的片段。比如知识库里既有旧版产品说明又有新版的更新公告对于同一个问题旧版回复不支持、新版回复已支持模型不知道该听谁的。这时候需要在上下文组装时加入元数据优先级比如更新时间越新的片段优先级越高或者用 Rerank 分数做加权尽量减少低质量片段进入最终上下文的概率。也可以做一个独立的知识对齐审查模型在生成阶段之后加一层校验让另一个模型把生成的回答与检索到的证据逐条核对标记出哪些内容没有证据支撑。这层校验会增加成本和延迟但在医疗、金融这类错误容忍度极低的场景中价值远超成本。4.3 响应延迟过高时的性能排查RAG 管道延迟的三大来源Embedding 延迟、检索延迟、生成延迟。Embedding 延迟在本地模型上会比较明显尤其并发请求多的时候需要用 GPU 或缓存机制优化。检索延迟常见于向量库和文档集合过大的场景可以给向量索引做分区或者把不经常访问的冷文档区隔开。生成延迟主要取决于上下文长度上下文越长模型输出越慢所以不要无脑地把 20 个片段全塞给模型。我给大家一个实际经验值如果是线上问答整个 RAG 管道把延迟控制在 2 秒以内比较理想。其中检索阶段 200~400 毫秒重排序 100~300 毫秒生成阶段 1~1.5 秒其余消耗在 API 路由上。如果你需要追到 500 毫秒以内通常就得缓存问题-答案对、给高频问题做精确匹配了。4.4 系统评测指标Hit Rate 和 MRR很多读者会问RAG 系统到底怎么量化效果好不能只靠感觉调参。我用得最多的两个指标是 Hit Rate命中率和 MRRMean Reciprocal Rank平均倒数排名。Hit Rate 的含义是对于一组测试问题正确答案是否出现在检索返回的前 K 个结果里。比如有 100 个问题返回前 5 个片段其中 80 个问题能在这 5 个片段里找到正确答案那么 Hit Rate5 就是 80%。这个指标强调的是答案有没有被召回。MRR 更严格一些它看重的是正确答案在排序中的位置。假设一个问题正确答案排在第 1 位这个问题的倒数排名就是 1/1另一个问题排在第 3 位倒数排名是 1/3平均一下就是整个集合的 MRR。这个指标非常直观地反映重排序的质量。我建议你在搭建管道初期就建立评测集从线上真实用户反馈里挑出高频问题每个问题标注标准答案和答案所在文档。然后每次改动切分策略、Embedding 模型、召回数量、Rerank 阈值时都跑一遍评测集比对 Hit Rate 和 MRR 的变化。这个方法听起来简单却是避免玄学调参的最有效手段。5. 实践心得与扩展思考5.1 一开始别急着上全套架构先用最小管道跑通写到这里我特别想说一个很多团队都在犯的通病一上来就搭了一套包含完整 Agent、多个向量库、复杂的切分策略、Rerank 模型的生产级系统结果花了一个月还在配置各种组件连一条能跑通的问题都没解决。我的建议是先在 Notebook 里用 50 篇真实文档和 10 个测试问题把最朴素的加载-切分-向量化-检索-生成跑通。哪怕效果一般也要先把缺口暴露出来。然后一个环节一个环节地做针对性优化。很多团队的失败不在方案不够先进而在没有建立最基本的可运行基线。5.2 知识管道的可维护性远比技术先进性重要知识管道的生命周期里内容更新是最普通的日常操作。你肯定不希望每次上线一篇新文档都要手动跑一遍切片脚本再手动做一次向量化。所以从一开始就要设计一个自动化的入库管道或者说一套知识持续集成流程。文档被添加入库、更新、删除都通过一套统一的接口触发同时自动维护索引的增量更新。这一点上我想到 2026 年很热的一个词RAG as a Service就是把知识接入、切片、索引、检索都封装成服务。很多团队确实需要这样的能力但我不认为你应该把所有期望寄托在一个黑盒上。你必须自己理解每个环节的原理才能够在黑盒出问题时知道去哪里排查。所以这篇基础向的文章反而是值得先吃透的东西。5.3 从知识管道到智能体的完整感知闭环最后我想把这个话题收拢到你正在做的 Agent 项目上。Agent 的知识获取管道不应该被理解为一次性的检索工具它应该是一个持续学习、持续融入 Agent 决策的闭环。拿一个实际场景举例你在 Agent 里集成了多个数据源每个源的知识结构不同。有的源是结构化表格有的源是长文档有的源是 FAQ。如果你把所有源都粗暴地切片、向量化、丢进同一个库效果不会好因为不同数据源适合的检索策略与上下文编排逻辑并不一样。更合理的做法是给每个数据源建立独立的子管道表格类用数据库查询 文本摘要长文档按章节切片 向量检索FAQ 用布尔匹配 向量相似度混合。然后在主 Agent 层做一个知识源路由先判断用户问题最可能命中哪个源再去对应的子管道检索。这就不仅是 RAG 了而是把知识管道接入到了 Agent 的感知层。到这一步你的 Agent 才真正长出了会根据场景选知识来源的能力。这也是我在系列前面几篇反复强调的不要在单一技术上做到极致而是要让技术的组合形成产品能力。RAG 基础是这条路上的第一步也是绕不开的一步。最后分享一个我自己的习惯每次给 Agent 调完检索或者知识库结构我都会顺手把当时遇到的问题、排查思路、最终方案记下来形成一份团队的RAG 排障手册。这件事看起来微不足道但当你上线半年、知识库文档翻了三倍之后再遇到一次离奇的检索问题你翻看手册两分钟就能定位。而这个系列的每一篇本质上就是这样一本手册的公开版本。希望这篇知识获取管道的拆解能帮你在搭自己 Agent 的路上少踩几个坑。