Agent知识获取管道：从RAG到Agentic RAG的工程演进指南

1. 为什么Agent非要配一条知识获取管道

聊到AI Agent，大多数人的第一反应是“能自己干活”。确实，Agent的核心能力在于规划、拆解任务、调用工具，但有一个问题始终绕不过去：它脑子里的知识是“死的”。

我一直强调一个观点：大模型本身是一个推理引擎，不是一个知识库。它训练完毕的那一刻，世界就被定格了。你问它2025年之后发生的事，它不知道；你问它你们公司内部的产品手册、售后FAQ、竞品分析报告，它更是完全没概念。传统做法是微调，把知识灌进权重里。但微调成本高、周期长、更新一次要重新训练，而且你根本控制不了它记没记住、记住的是不是错的。还有一层更麻烦的：即使它记住了，你也拿不出证据——它的回答无法溯源，出错了你只能干瞪眼。

所以就有了RAG（Retrieval-Augmented Generation，检索增强生成）。

RAG的思路极其朴素：既然模型不知道，那就别让它猜，给它一份参考资料，让它对着资料回答。这就像我们开卷考试，题目再怎么偏，只要你带着教材、翻得够快，也能写出个七八分。Agent需要RAG，本质上就是因为知识获取管道是它落地到真实业务的必经之路。不管你是做一个客服机器人、一个企业内部的知识问答助手，还是一个能自动读文档写报告的工作流，没有RAG，Agent就是空中楼阁。

这篇是“走进AI Agent”系列的第四篇，前面我们聊过Agent的架构、规划能力、工具调用。这一篇聚焦知识获取管道，把RAG从原理到落地、从传统RAG到Agentic RAG的演进路径完整过一遍。适合三种人看：一是准备在自己项目里接入知识库的开发者，二是想搞清楚RAG为什么经常“答非所问”的产品经理，三是研究Agent怎么跟外部知识交互的算法工程师。

2. 一条RAG管道的完整工作流程

RAG这名字听着高级，拆开看其实就是一个“查资料—组装—回答”的流水线。我习惯把整条链路切成三个阶段：索引、检索、生成。每个阶段都有各自的坑，我们一个一个说。

2.1 索引阶段：文档入库那点事

索引阶段的任务是把原始文档变成计算机能快速查找的结构化格式。很多人以为这一步就是把文档丢进数据库，其实没这么简单，这里面有几个关键决策点。

第一个决策是文档解析。你手里的资料可能是PDF、Word、Markdown、网页，甚至扫描件。PDF是最恶心的格式，尤其是那种图文混排、多栏排版的，直接用库解析往往得到一堆乱序文本。我踩过最深的坑是：解析PDF的时候把页眉页脚、表格线、页码全带进去了，结果检索时命中了一堆带“第X页共Y页”的垃圾片段。后来学聪明了，先用OCR或者结构化解析工具把PDF转成可靠的文本流，再按标题层级做分块。这里可以补充说明，如果文档本身是HTML，优先抓取正文结构，去掉样式脚本；如果是扫描件，先过一轮OCR识别，识别完还要做纠错，否则错别字会直接影响后续向量检索的效果。

第二个决策是分块策略。教科书上告诉你“把文档切成固定长度的chunk”，但固定长度是最蠢的做法，它会把一句话拦腰截断，也会把两个无关主题强行绑在一起。我常用的是递归字符分块：先按段落标题切，段落太长再按句号切，句子还太长就按固定的字符窗口切。这样能最大程度保住语义完整性。分块大小怎么定？太小了，比如128个字符，检索到的上下文信息量不足，生成阶段模型的回答会显得东拼西凑；太大了，比如2048个字符，检索精度就会下降，因为一个块里掺杂了太多无关内容。我没有一个公用的推荐值，因为跟文本类型强相关。技术文档、法律条文这种结构清晰的，512到1024个token比较合适；聊天记录、口语化文本这种信息密度低的，可以把块调大一点。你只能自己调，用一批真实查询做测试，看哪个粒度下命中率最高。

第三个决策是向量化。分好块之后，要把每一块文本转成向量。这个环节的选型直接决定检索质量的上限。常见的Embedding模型像BGE、E5、text-embedding系列，各有各的擅长领域。这里有一条铁律：Embedding模型的领域匹配度比模型大小重要得多。你拿一个通用中文模型去处理法律文书，效果大概率不如一个专门在法律语料上训练过的小模型。所以建索引之前，先拿一小批语料跑几个候选模型，对比一下检索命中率再定。

索引构建完成后，还要存进向量数据库。向量库的选型我放在后面第4章专门讲，这里先不展开。

2.2 检索阶段：召回不是“搜到了”就行

检索阶段的目标是从知识库里找出与用户问题最相关的几个片段，作为生成答案的参考资料。

这里有个很多初学者容易误会的点：向量检索不等于语义检索的全部。向量检索擅长处理“意思相近但表达不同”的情况，比如用户问“退款流程是什么”，知识库里写的是“如何办理退货退款”，向量检索能把这两者关联起来。但向量检索也有明显的弱点，它对专有名词、精确ID、数字特别不敏感。你搜“A100GPU的显存带宽”，如果知识库里写的是“GA100架构下显存带宽为2TB/s”，向量检索不一定能准确命中，因为数字和型号的语义表达差异不大，向量距离上并不够接近。

所以真正靠谱的检索方案是混合检索：先用BM25做稀疏检索，再用向量模型做稠密检索，最后把两路结果合并，再做一次重排序（Rerank）。BM25是个老牌的词频统计方法，它在关键词匹配、精确术语上表现很好；向量检索负责语义泛化。两者互补，召回率能提升一大截。

这个过程我实测下来的感受是：一个“关键词精确命中”加“语义模糊召回”的组合，能让长尾查询的可回答率从60%拉到85%以上。代价是多跑一路检索，延迟会增加几十毫秒到一百多毫秒。在Agent场景里，这个延迟是可以接受的，因为Agent本身就不止一轮交互。

检索之后还有一个容易被忽略的环节：重排序。向量检索按相似度的排序，在这个阶段，我们拿用户查询和召回的片段重新计算相关性分数，把真正跟问题强相关的片段排到最前面。优秀的Rerank模型能明显提升生成质量。这一步有个很直观的例子：一个关于“怎么申请发票”的问题，初召回的时候，系统可能同时命中“发票申请流程”和“发票常见问题”，这两个片段在向量空间里跟问题都挺接近的。但Rerank一打分，“申请流程”的相关性就明显高出一截，因为它回答了“怎么操作”，而后者只是背景知识。没有Rerank，生成模型可能就被带偏，开始泛泛而谈发票的用途了。

2.3 生成阶段：把上下文拼装成提示词

检索到片段之后，下一步是把用户问题、检索到的片段、Agent的历史对话背景，一起拼装成提示词，发给大模型生成答案。

拼装这里有个细节：不是把所有检索到的片段都塞进去，而是要选择性截取。我看过一些失败案例，开发者把Top-5甚至Top-10的片段全填进上下文中，结果是问题淹没在无关信息里，模型反而找不到关键线索。一般来说，取Top-3到Top-5就够了，如果Rerank质量高，Top-3完全够用。

提示词的写法上，我有一个比较固定的模板，大致是：

你是一个基于内部知识库回答问题的助手。 请只依据以下资料片段回答问题。如果资料中没有对应信息，请明确回答“知识库中未找到相关信息”，不要编造。 资料片段： [片段1] [片段2] [片段3] 用户问题：{{query}} 历史对话：{{history}}

这里最关键的一句是“不要编造”。大模型的生成惯性太强了，如果你不给它这个约束，它会在知识库信息不足时自动“脑补”，一本正经地给你编一个错误答案。这个约束虽然不能100%消除幻觉，但能把幻觉比例压到一个可接受的范围。

生成阶段还有两种模式可以按场景切换：一种是抽取式生成，适合“请根据文档回答XXX”的任务，回答应该主要引用原文；另一种是综合性生成，适合“总结一下这份报告的核心观点”的任务，需要模型跨多个片段提炼信息。Agent场景下我建议把这两种模式做成两个不同的工具或提示词模板，让Agent根据任务类型动态选择，而不是用一个提示词硬扛所有场景。

3. 从固定管道到Agentic RAG：知识获取开始“长脑子”

传统的RAG流程是一条固定管道：查询进来，检索，拼接提示词，生成。它的缺点是：如果用户的第一个查询本身写得模糊，检索出来的结果就会很烂，生成答案自然也不行。比如用户问“那个东西怎么涨价了？”，系统不知道“那个东西”到底是什么，检索出来的片段五花八门，答案当然让人一头雾水。

传统的RAG还有一个深层问题，就是它对“要不要检索”这件事没有任何判断力。简单说，用户只是问了一句“今天天气怎么样”，或者“你好”，系统也会傻乎乎地去知识库里捞一遍。不仅在检索质量上，这种不做判断的路子看起来就是低效的，而且在大规模知识库的场景里，必然拖慢响应速度，还会把完全无关的内容拼进答案里，让生成结果的质量进一步劣化。所以，单纯在提示词里加一个“不要编造”的约束，根本治不了这个根子上的毛病。

Agentic RAG就是要解决这些问题的。它的核心思想是：把知识获取变成一个由Agent编排的自主决策过程。

3.1 Query重写：把模糊问题变清晰

第一步是让Agent判断原始问题是否清晰，如果不够清晰，就先重写。

还是上面“那个东西怎么涨价了？”的例子。Agent会先看对话历史，发现用户其实是在前面聊某款显卡的价格，于是把查询重写成“RTX 4090显卡价格近期上涨的原因分析”。这一步靠大模型的语义理解能力就能完成，代价只是多一轮模型调用，效果却是质的飞跃。

重写的方式不止一种。如果Agent已经有用户画像或业务上下文，它还可以往查询里补充过滤条件，比如“近30天内关于XX产品的用户投诉总结”，加上时间限制后检索范围一下子精准很多。这就是重写比较直观的收益，它实际上是在帮检索阶段压缩候选集。

3.2 判断要不要检索：不是所有查询都值得去翻资料

Agentic RAG比传统RAG更聪明的另一点，是它学会了拒绝检索。

Agent会先评估当前查询是否能靠自身知识回答。如果能，就不检索，直接回答；如果不能或者不确定，才去检索。这一步评估其实可以用一个很简单的手段实现：让大模型自己输出一个结构化判断，比如：

{ "retrieval_required": true, "reason": "用户询问的是2025年产品价格变动，超出模型知识截止日期，需要检索最新资料" }

如果判断为不需要检索，直接走正常对话流程，响应速度快，还省了向量库的调用成本。如果判断为需要检索，才走检索链路。有些场景下，这种“先判断再检索”的机制能把平均单次请求的延迟降低20%到40%，因为它跳过了很多无效检索。

3.3 多步检索与工具协作：知识管道也可以是多跳的

Agentic RAG还能处理一个传统RAG搞不定的场景：多跳问题。

用户问“我们公司去年第四季度营收最高的产品线是什么，它对应的技术负责人是谁？”这个问题要分两步：先在财务报表里查“各产品线营收”，定位到营收最高的产品线，然后再去组织架构文档里查“该产品线的技术负责人”。这是一个跨文档、跨表的多步检索，传统RAG做不了，因为一条查询只能检索一次。Agentic RAG不一样：Agent先拿第一个子问题去检索，拿到结果后，再基于这个结果构造第二个子查询，继续检索，直到信息足够完整，最后统一生成答案。

另外，Agentic RAG还能调用外部工具来补充知识。比如查实时股票行情、查天气、查数据库里的订单记录，这些动态数据的获取不是检索静态文档能解决的，需要走API。把RAG和工具调用结合起来，知识管道的边界就一下子打开了。这也是我一直在思考的一个方向，Agent的知识获取不应该只有“文档检索”这一条路，它还应该包括数据库查询、API调用、甚至代码执行，然后把所有这些结果统一汇聚成生成上下文。这才是更完整的知识获取管道，而RAG只是其中最基础的底座。

4. 工程落地：从零搭一条可用的知识管道

讲了这么多原理和演进，接下来进入实操环节。我以一个典型的“企业内部知识问答Agent”为例，把整个搭建流程走一遍。

4.1 选型：向量库、Embedding模型与开发框架

先聊向量库选型。我把自己实测过的几种列个表：

如果项目刚开始，数据量在几十万条以内，单机Qdrant或Chroma都够用。如果上了生产且有着严格的性能要求，直接上Milvus或云服务，别在单机方案上硬撑。

Embedding模型的选型，我最常用的判断方式是跑一个“检索命中率测试”。拿50个用户真实问题，对每个问题从知识库里找出标准答案对应的文档片段，然后用不同的Embedding模型检索Top-10，看命中率。BGE系列的中文效果在Equal场景下通常表现不错，E5对英文的支持更好。这里多说一句，很多团队喜欢用OpenAI的text-embedding-3，但企业内部知识库往往涉及敏感数据，不太方便把文档内容传到外部API，所以更稳妥的做法是部署一个本地开源Embedding模型，比如BGE、GTE或M3E。数据安全跟检索效果一样重要，这也是自建管道时要考虑的关键因素。

4.2 检索参数调优与质量验证

检索参数里最核心的是Top-K和相似度阈值。

Top-K决定了每次检索返回多少个候选片段。我用过一段时间的经验是：先设Top-K=10，再根据Rerank结果取Top-3给生成模型，这样既保证召回率，又不过度污染提示词。相似度阈值容易被忽略，导致错误的片段进入候选集。建议用实际数据跑一些负样本，算一下正样本和负样本的相似度分布，然后取一个分界值。如果正样本最低相似度是0.53，负样本最高是0.47，那阈值设0.5就比较稳妥。注意不同Embedding模型产出的向量相似度分布不一样，这个阈值不要直接拿网上的经验值套，一定要自己算。

质量验证环节，我不推荐只看几个Demo案例就上线。我习惯在项目里维护一组评测问题集，至少几十条，覆盖：简单问答、复杂推理、模糊指代、跨文档关联、知识库外问题等类型。每次调整参数或更换模型时，统一跑一遍这个评测集，计算三个指标：

• Hit Rate（命中率）：正确片段是否被检索出来
• MRR（平均倒数排名）：正确片段排在第几位，越靠前越好
• Answer Accuracy（回答准确率）：最终生成答案是否正确

这个评测集要定期更新，因为用户的问题会越来越刁钻，你会发现你永远需要更多的测试集来防止模型退化。

4.3 本地知识库与业务系统集成的实用建议

企业内部Agent，数据往往散落在多个系统里：Wiki、Confluence、企业微信文档、数据库、工单系统。如果全部导入一个知识库，你会发现数据口径不一致、重复文档满天飞、还有大量过期内容。

我的建议是分两层处理：静态文档统一入向量库，动态数据保留原系统，只接API。静态文档更新频率低，适合切块、向量化、入库。动态数据不行，比如订单信息、库存状态、人员归属，每几分钟就变一次，如果同步到向量库，频繁重建索引的代价非常高。这部分信息应该让Agent通过工具调用去查原系统，而不是走RAG检索。

知识库的更新机制我以前吃过亏。当时直接把新文档写进向量库，不管旧的，结果同一产品有两份手册，版本还不一样，检索出来的内容自相矛盾。后来改成“版本化目录”的结构：每次导入新文档时，把同主题的旧文档标记为过期，并做一次“知识清理”，把过期文档从索引里摘除或降权。这个过程可以半自动：文档导入时带上元数据，比如版本号、生效日期、状态，检索时按元数据过滤，只返回status=active的片段。这个小改动让我后来的知识库质量稳定了许多。

5. 常见问题与排查实录

RAG看起来简单，但每个环节都可能出bug。这一节梳理几个我实际踩过的坑和排查思路。

5.1 召回质量差：问题可能根本不在检索

我遇到过一个典型案例：用户问“发票抬头错了怎么修改”，Agent回答“抱歉，知识库中未找到相关信息”。但知识库里明明有相关内容。排查下来发现，知识库里对应文档写的是“发票信息变更流程”，文档标题和正文里都没有“抬头”这个词，于是语义检索没召回。

这个是典型的Embedding模型不够强导致的问题。常见拉伸检查方向：

• 先看查询和文档的相似度分数，如果分数的确偏低，说明检索本身没召回；
• 换更强或更匹配领域的Embedding模型再试；
• 如果换了模型效果提升不大，考虑加一个关键词同义词扩展机制，比如维护一份业务同义词表，“抬头”映射到“发票信息”“开票信息”“购买方信息”；
• 还有一个方案是增加Rerank模型的权重，有些场景下初召回没有命中，但你可以调整BM25和向量检索的权重，让精确匹配的词更占优势。

最怕的一种情况是：用户问题本身有歧义，比如问“怎么申请”，没说申请什么。这类问题就算RAG再强也召回不到正确内容。这个时候要靠Agent的追问能力，让Agent反问用户“您想申请什么？”而不是硬答。

5.2 幻觉检测与兜底策略

RAG再怎么努力，也不可能完全消除幻觉，所以我们至少要能“检测幻觉”——识别出模型的回答是不是凭空捏造的。

我有两个土办法：

第一个办法很笨但很有效：强制模型引用片段编号做证据。生成提示词里加一句“回答时请在关键结论后标注来源片段编号，如[源自片段1]”。如果模型引用编号，说明回答有依据；如果模型长篇大论且没有任何编号，那就很可疑了。你还可以额外做一个校验：把输出里每个编号和真实返回给它的片段做比对，一旦发现编号不存在，直接丢弃这轮回答，重新走一次检索。

第二个办法是进行自洽性校验。把生成结果拆成几个关键断言，然后让模型去检索到的片段里逐一验证这些断言是否成立。如果出现“回答中的关键结论在检索片段里找不到对应依据”，就判定为幻觉。这个办法会多花几次模型调用，但在客服、法务、医疗等错误代价高的场景里，这笔成本是值得的。

5.3 知识库更新的及时性问题

还有个很常见的问题是“知识库刚更新了，为什么Agent还说不知道”。

排查方向通常是三个：

• 缓存失效机制没触发，Agent拿的还是旧会话里的上下文；
• 新文档没有经过切分和向量化就被直接丢进了原始文件目录；
• 检索时过滤条件把新文档误杀了，比如元数据里的status字段没有正确设置为active。

我踩得最深的一次坑是：文档确实是入库了，但我的切分逻辑里有一个“去重”步骤——根据文档标题判断是否重复，新文档标题跟旧文档一模一样，于是新版本被当成重复数据跳过了。当时还以为是向量刷新问题，查了很久，最后一层层打印日志才定位到。这种问题必须有完善的日志链路：入库日志、切分日志、向量化日志、检索日志，任何一个环节断了都会排查到怀疑人生。我的建议是，在系统里加一个“数据血缘”的跟踪：一个文档从上传到切分到向量化到检索，每一步都有记录。Agent回答完问题后，还能往回溯源到具体是哪个文档的哪个片段支撑了这个回答。这一点对调试、审计、以及建立用户信任都很有价值。

6. 几个我长期坚持的经验

最后分享几个在实战中总结出来的习惯。

关于Agentic RAG，我的体会是：不要为了“智能”而把所有查询都交给Agent去编排。稳住一个判断框架：简单问题走固定管道，复杂问题才上Agentic RAG。这个判断逻辑可以结合模型的置信度打分或历史命中率来做。我见过有些团队把所有的查询都丢给多轮Agent，结果延迟涨了三倍，准确率还下降了，因为Agent引入了新的不确定性。好的架构是“固定管道兜底，Agentic编排加强”，让简单的查询更快，复杂的查询更准。

另外一个不起眼但是很重要的经验：知识资产要跟代码一起做版本管理。我自己的项目里，知识库的原始文档、切分结果、Embedding模型的版本号、向量库的索引快照，都会打上tag存下来。这样万一改什么配置之后效果变差了，可以随时回滚到之前表现好的那个“知识快照”。RAG系统上线后就是一个“活系统”，它跟你写的代码一样，需要在迭代和维护中持续演进，所以把整个链路当成一个真正的软件工程来做，而不是一次性建完就撒手不管。这是我能给的最真诚的建议。