刚把Agent系列写到第四篇，上一篇把Agent的记忆机制和上下文窗口讲透了，这一篇得换个角度，聊聊Agent的知识从哪来。如果你试过把一个业务Agent丢进一个完全陌生的领域，比如让它回答公司内部的产品规格、售后工单、行业规范，它会表现得像刚入职的实习生——聊天很流畅，一问具体规则就露馅。这个问题本质上是知识割裂：大模型懂的是一般世界知识，而你的业务知识它完全没见过。AI Agent要在一个真实场景里干活，必须有一条能把外部知识送进模型推理链路的管道，这个管道就是RAG（Retrieval-Augmented Generation，检索增强生成）。这篇就把它彻底拆开，从原理到实操，从单次检索到Agentic RAG，把我做知识获取管道踩过的坑和验证过的方案一次讲清楚。

RAG这词这两年已经被说烂了，但很多人的理解停在“给模型加个知识库”这个层面，实际上知识获取管道是一条完整的水管：从文档源头抽水，经过清洗和切割，变成向量放进池子，用户提问时再按需抽回几段文本，最后交给生成模型拧出水龙头。这篇文章适合正在搭AI Agent、准备做RAG知识库，或者想理解“为什么RAG有时好使有时拉胯”的开发者，三千字打底，暂时收不住——因为细节确实多。

1. 先从“知识从哪来”说起：Agent的三种知识来源

1.1 参数记忆、上下文记忆和外部知识

拆解Agent的知识获取之前，先明确一个框架。模型能用的知识其实分三种：参数记忆、上下文记忆、外部知识。

参数记忆是模型在预训练阶段压进权重里的世界知识，比如“法国的首都是巴黎”这类，这部分知识训练完就冻结了，除非重新训练否则不会更新。上下文记忆是对话窗口里临时给模型的信息，用户上传的文档、历史聊天记录都算，它只在本次会话有效，窗口一满就被挤出去。外部知识指模型没学过、没见过的业务数据，存在数据库、文件服务器、知识库里，需要一条管道把它们动态送进上下文，再配合参数记忆一起工作。

RAG解决的是外部知识接入问题。为什么不能直接把外部知识塞进参数记忆？因为模型训练一次动辄几百万美金，更新知识的时延根本跟不上业务节奏，今天改个产品规格，难道要重新训练一遍？显然不现实。RAG的思路是化整为零：平时把知识切块存好，用户提问时只把相关的几块取回来放进上下文，既绕开了训练成本，也让知识可以按天甚至按小时更新。

1.2 为什么“没有管道”的Agent会一本正经地胡说

不带RAG的Agent常见翻车现场是这样的：你问“咱们公司企业版的并发超限阈值是多少？”模型可能一本正经地给出一个听起来极其专业但纯属编造的数字。原因很简单，它训练时根本没见过你公司的企业版文档，为了维持回答的连贯性，模型会基于概率“补全”答案。这类情况在LLM领域叫幻觉。

我之前做过一个内部工单分类Agent，初期只把历史工单文本塞进系统提示词，结果模型把几十个工单的关键信息混在一起，分类结果惨不忍睹，因为它根本没有办法从超长上下文里精准定位某一类工单的特征。后来改成RAG管道，先把历史工单按问题类型切成块，再针对用户描述检索最相似的若干条工单记录作为参考，准确率直接拉起来。这个对比很直观：不是模型的推理能力不够，而是你压根没有把对的信息递给它。知识获取管道的存在价值，就是确保模型在正确的时间拿到正确的知识片段。

1.3 知识割裂的代价：检索、记忆、推理必须闭环

说回“知识割裂”这个词。很多Agent系统看起来功能齐全——有对话、有记忆、有工具调用，但每个模块是孤立的。对话模块不会主动触发知识查询，记忆模块存的内容和业务知识库毫无关联，工具调用后拿到的结果又不会回填到上下文。四个字：各干各的。

真实场景需要的是闭环。用户提出一个问题，Agent先做意图识别，当它发现这个问题依赖外部知识时，立即触发知识检索；检索结果不仅要交给生成模型回答，还要把关键信息写入短期记忆，后续追问时能基于同样的知识源继续对话。这条闭环链跑通了，Agent才谈得上“懂业务”。RAG就是把这个闭环中的“喂知识”环节标准化，提供一套从文档到向量再到召回的统一操作方式。接下来的章节，我就沿着这条管道的各段展开。

2. RAG的底层逻辑：先“找”再“写”，本质是给模型开卷考试

2.1 把开卷考试的思路翻译成系统设计

RAG为什么有效？一个特别贴切的类比是开卷考试。直接让LLM回答业务问题，等于闭卷考试，它只能靠记忆里那点模糊的印象答题，答不上来就编。RAG等于允许它带资料进场，遇到不会的题目可以翻书，翻到的内容放在旁边照着写。这个“翻书”动作就是检索，“照着写”动作就是生成。

但开卷考试和开卷考试之间差距很大。考场上给你一本四百页的产品手册，你要是从头翻到尾，考试时间根本不够。RAG系统的检索环节必须做到精准，考试时直接翻到第138页那段，而不是整本书塞给模型。这就是向量检索、rerank、知识路由这些技术的意义所在。整个RAG系统的核心评价标准也只有一条：送进模型上下文的那几块文本，是否真的覆盖了用户问题的答案范围。

2.2 三个关键阶段：索引、检索、生成

标准RAG管道可以拆成三大阶段，我习惯叫它“三件套”。

索引阶段处理的是入库问题。原始文档格式各异——PDF、Word、Markdown、网页、数据库记录，先把它们解析成纯文本，再切成大小合适的块，接着用嵌入模型把每块文本转成一个向量，最后把这些向量连同原文一起存进向量数据库。这一步的目标是准备好“可被查找”的知识。

检索阶段处理的是查询问题。用户问题同样走一次嵌入向量化，然后在向量数据库里做相似度搜索，召回最相近的N个文本块，必要时再用重排序模型从粗召回结果里精挑一轮。这一步的目标是找到“最相关的知识片段”。

生成阶段处理的是表达问题。把检索到的文本块拼进提示词，交给大模型结合用户问题生成最终答案。这一步的关键是让模型明确“只能依据检索材料回答”，这样才能遏制幻觉。

2.3 从朴素RAG到Agentic RAG：管道越来越像“会思考”

最早的RAG实现很简单，用户问题到知识检索到答案生成，一条直线跑下来。这种朴素的RAG应付“某个规范是什么”这类单跳问题绰绰有余，但遇到复杂问题就露怯。比如用户问“最近三个月华南区客户对登录模块的投诉主要集中在哪些环节？”这个问题至少需要两步：先定位投诉知识库里的华南区相关记录，再按时间窗口和主题过滤。朴素RAG只会做一次向量检索，结果往往是垃圾进、垃圾出。

后来大家开始给RAG加智能化组件：路由决定这个问题该走向量检索还是走SQL查询，多跳检索把一个大问题拆成多个子问题依次查，甚至让Agent自主决定查几次、用哪些工具。这类方案就是现在热门的Agentic RAG。我会在第四节专门展开这个进阶方向，因为这是Agent和知识管道结合最有价值的部分。

3. 知识获取管道的实操拆解：从文档到向量库的完整链路

3.1 文档加载与清洗：这一步偷懒，后面全部还债

知识管道的入口是文档加载。很多人在这里犯的第一个错误，是拿一个通用解析库直接处理所有格式。实测下来各格式差别非常大：PDF还要分三种情况——文本型PDF直接提取就行，扫描型PDF必须走OCR，表格型PDF得用专门的表格解析工具，比如camelot或pdfplumber的表格模式。

文档清洗是另一个容易被忽略的环节。我处理过一批企业知识文档，全文带页眉页脚、目录、版本修订记录，如果直接把原始文本切块入库，检索时会召回一堆“第1页共20页”之类的垃圾片段。我的清洗习惯是这样的：先抽掉目录页和重复页眉页脚；再过滤掉纯图片页面；然后针对Markdown或HTML文本，要特别小心代码块和表格标记，不能把它们混进正文切块。清洗标准只有一个：切出来的每一块文本，都应该是一个语义完整的、可独立理解的信息单元。

3.2 切块策略：大小、重叠与语义边界

文档是连续的，知识块必须分开存。切块是RAG链路里最艺术的一步，它直接影响检索质量。块太小，比如一句话一块，语义不完整，召回后模型看到的上下文太碎；块太大，比如一整个章节一块，向量被“信息噪音”稀释，相似度检索变得不敏感。实操中要按文档类型取平衡点，我的参考经验是技术手册类用256到512个token的块大小，问答对类用128到256，法规条款类可以到512以上。

还有一个容易踩的坑叫“切块位置”。按固定字符长度硬切，会把一个完整概念从中间切成两截，管道的检索效果立刻崩盘。更好的做法是采用递归切分器，优先按段落边界切，段落太长再按句子边界切，尽量保住语义完整性。另外，相邻块之间要保留一定的重叠，比如20到50个token，这样跨块的信息不会因为切分边界而丢失。切块参数不是玄学，它直接决定后续的hit rate（召回命中率），强烈建议上线前用一组测试问题跑几轮不同参数的对比实验。

3.3 嵌入模型选型：中文场景别看名气看效果

把文本变成向量是知识管道的关键技术步骤。这里的门槛在于嵌入模型的选择。英文场景长期用得比较多的是OpenAI的text-embedding-3系列，但中文业务场景里我建议优先考虑国产开源嵌入模型，比如BGE-M3、GTE-Qwen、ACGE等。原因是中文的语义表达和英文差异很大，通用英文嵌入模型对中文长尾词、行业术语的表示效果通常会差一点。

几个选型建议可以抄作业：预算有限且对召回精度要求不高，直接上BGE-M3，1024维，中文效果好，支持1024长度的文本；如果追求更高精度且显存充足，可以用GTE-Qwen2-7B-instruct这类大参数模型，检索质量能再上一个台阶。嵌入维度和向量数据库的索引类型是绑定的，先定模型再选库，不然维度变了就得重建索引。另外，系统性建议把嵌入模型单独部署成一个服务，因为生产环境里文档入库和查询检索都会高频调用它，和主应用的推理链路解耦会好维护很多。

3.4 向量库选型：从pgvector到Milvus的取舍

向量数据库是知识块的存储层，选型直接决定检索性能和运维成本。我的建议是先明确场景再选库，不要一上来就上重型分布式方案。

如果项目规模小，知识块数量在十万级以下，优先考虑pgvector。它火在“复用现有PostgreSQL”，不需要额外运维一套系统，还能用标准SQL做向量字段和业务字段的混合过滤，比如“只检索2024年且类型为工单的知识块”，这类过滤用pgvector写起来非常自然。如果数据量到百万级、并发查询高、向量维度高，考虑Milvus或Qdrant这类专业向量数据库。Milvus的强项是分布式扩展和混合检索能力，Qdrant轻量许多，部署快，云环境的托管部CS也很成熟。

还有一个容易被忽视的问题是元数据过滤。向量搜索是“找语义上相似的”，但同一个词在不同业务域里含义可能完全不同。比如“账号被封”在风控域和客服域的处理方法是两回事，如果没有业务标签作为过滤条件，召回结果会跨域串味。我每次建向量集合都会留出一组metadata字段，把来源、业务域、时间、文档类型等结构化信息一并写进去，检索时强制带上过滤条件。这种做法能显著降低垃圾召回。

3.5 检索召回与重排序：只靠向量搜索远远不够

知识管道走到检索这一步，有一点必须说清楚：向量相似度不等于问题答案的相关性。向量相似度衡量的是语义空间里向量方向接近，但这和“这段文字是否直接回答了我的问题”并不等价。所以生产级别的RAG，通常建议做成两段式召回：第一段用向量检索粗召回Top 50，第二段用重排序模型精确打分取Top 5到10。重排序模型通常会综合考量query和文档的交互特征，相关性判断比向量距离准得多。

粗召回数量设置也要讲究。Top K值太低，正确答案可能压根不在候选集里；Top K值太高，后面重排序模型的处理时间和成本都会涨。我的常用配置是向量召回Top 50，重排序取Top 5。重排序模型可以选BGE-Reranker-v2-M3这样的开源模型，也有商用的Cohere Rerank可供选择。这块建议前期就接入，不做rerank的RAG基本是半成品，很容易在线上被差评打回来。

4. Agentic RAG：让知识管道跟着问题“绕路”

4.1 从平面检索到多跳推理：Agent怎么拆问题

把RAG管道接入Agent之后，最直接的变化是检索不再是“一次完成”。一个成熟Agent面对复杂问题，应当先做任务规划，判断出需要哪些知识，再按顺序发起检索，并且可能用前一次检索的结果决定下一次检索的查询词。这个机制就是多跳检索。

用一个具体例子：用户问“这个季度华南区的客服投诉中，有多少比例和支付环节相关？”Agent的规划可能是：先检索“华南区本季度客服投诉报告”这个大块，从里面提取出航支付环节相关的事件关键词，再用这些关键词做第二轮向量检索命中细节片段，最后汇总两份结果生成结论。这种通过中间结果逐步缩小范围的检索方式，单靠朴素RAG的“一次query一发子弹”是做不到的。Agent的优势就在于它可以自己判断：这次检索到的材料够不够、要不要再查一次、数据有冲突时采信哪一份。

4.2 知识路由：让每条问题走对入口

Agentic RAG的另一个核心组件是知识路由。不是所有问题都适合向量检索。用户问“2024年销售额是多少”，正确答案可能藏在SQL数据库的财务表里；问“某某设备的维修步骤”，才适合去向量知识库翻手册。路由机制就是让Agent根据问题意图决定走哪条知识通道。

我在实际项目中常用的路由策略是基于LLM的意图分类：把可能的知识源枚举成标签，让Agent先分类再决定检索策略。特别要注意，不要让Agent把所有问题都默认丢给向量检索。对结构化数据查询，走SQL工具链路的准确率远高于文本检索，这也是为什么现在很多Agent开发框架强调“工具调用”和“RAG”的配合，其实就是知识路由在起作用。spring ai、langchain4j这类框架都已经比较成熟地支持这种路由编排，新项目直接复用就好。

4.3 Skill与RAG的结合：知识不是拿来背的，是拿来用的

还有一个热点方向值得展开：Skill与RAG如何结合。Skill可以理解为Agent预先编排好的“能力单元”，比如“识别工单风险等级”是一个Skill，“提取合同关键条款”是另一个Skill。RAG和Skill结合的关键思路，是把检索结果作为Skill的输入参数，而不是作为最终答案的半成品。

举个例子，一个“售后问题智能处理”Skill，它内部的执行逻辑可能是：先通过RAG检索相关产品手册段落，再通过第二步工具调用检查订单系统中的物流状态，最后结合两类信息生成处理意见。知识块在这里充当的是决策依据，而不是回答内容。对Skill的开发者来说，RAG检索到的信息不必直接呈现给用户，只需要成为链路中一个可靠的信息源。这个结合点做好了，Agent的行为表现会从“会找资料”升级为“会干活”。

5. 这些坑我替你踩过：知识获取管道的问题排查与调优

5.1 命中率低？先看数据切块，别急着换模型

大家碰到最多的问题就是检索命中率上不去。换了更强的Embedding模型、加了更大的向量数据库还是不行。根据我自己的排查经验，至少一半情况问题出在数据切块上，而不是模型上。查的时候按这个顺序来最有效。

先看文档清洗是否干净，如果知识块里混着大量无关字段，语义表示会被污染；再看切块是否破坏了语义完整性，常见症状是检索到一块文本后，模型给出的答案缺一半，因为另一半信息被切到邻块了；然后用一组标准问题做召回检查，人工看召回的结果是不是“沾边但不打中”。如果问题出在切块上，调整方案通常比换模型快得多。

召回结果不准的另一个高频原因是embedding模型和检索query的文本类型不一致。文档入库时本来用简体中文，用户查询时带着英文缩写，模型可能完全匹配不上。生活中常见的处理方式是做一个同义词扩展组件，把query里的英文缩写自动补充成中文全称，再去做向量检索，效果立竿见影。

5.2 上下文里的“脏数据”怎么查：打分法和字段溯源

用户说回答得不对，怀疑是RAG管线出了问题，但不知道具体是哪一段。这种场景我最常用来定位的方法，就是把检索到的原始知识块打印出来人工检查。集成日志里记录每次查询召回了哪几块文本、每块的分值是多少、来源文档是哪一个。如果回答错误，先看候选块的相关性，如果候选块本身就没覆盖答案，那问题在检索侧；如果候选块覆盖了答案，模型却答错了，那就是提示词约束或模型能力的问题。

实操中可以用一个“溯源SQL”把向量库的关联数据查清楚，也可以在接口层增加调试参数，让每次检索返回详细的候选块信息和metadata。这种能力要在一开始就设计进去，临时补很被动。

5.3 常见问题速查表

5.4 调优顺序：先稳基础，再上强度

最后说调优顺序。RAG管道的调优不存在一步到位，我建议按三个阶梯推进。第一阶梯是修数据和切块，把文档清洗做好、切块参数跑通，这一步是整个管道的下限，值得花一半的时间在这里。第二阶梯是做检索优化，加元数据过滤、调候选集大小、接重排序模型，把召回质量做稳。第三阶梯才轮到Agentic化，上知识路由、多跳检索、Skill编排，让管道真正具备规划能力。

如果一上来就急着上一堆Agent框架，数据侧却还是一团浆糊，最终效果一定很糟。RAG项目60%的工作量在数据和索引侧，20%在检索调优，最后20%才是生成和Agent逻辑，这个比例我做过多个项目，印象非常深。

6. 从“基础版RAG”到“生产级知识管道”的升级路径

6.1 离线索引与增量更新的平衡

基础版RAG做完，下一步要考虑生产落地。最核心的一个问题是知识更新的时效性。企业内部知识库不是静态的，产品文档会改版、工单记录天天增长、制度文件定期更新。如果每次更新都把全部数据重新embed一遍，索引构建时延和成本都受不了。

实际工程中常用的策略是分区更新加增量索引。我给一个知识库规划过这样的结构：按模块或时间周期将文档分组，更新时只要对涉及的组重新索引，并让向量库在后台做增量合并。查询侧保持线上索引热可用，更新操作在独立通道完成。这个机制能显著降低知识管道的运维压力。

6.2 评估体系：别用感觉调RAG

没有评估体系的RAG项目容易变成“感觉流”：同事试了说还行，就上线了。但生产场景必须有可量化的指标。我一直在用的基础评估指标有两个：hit rate表示“正确答案是否被召回到候选块中”，这一项衡量检索阶段的质量；答案正确率则要结合生成结果做LLM-as-judge或者人工抽样标注，衡量最终输出的质量。

建议建立一组与业务强相关的测试问题集，覆盖高频问题和知识边界问题，每次改索引、调参数之后都跑一遍回归测试。没有这组测试集，你做任何一次改动都无从判断是变好了还是变差了，这是我踩过最深刻的坑之一。

6.3 与Agent生态的衔接：Java、Python还是框架化

现在的Agent开发生态已经比较多元。Java技术栈的团队通常关注Spring AI，基于它做RAG和Agent集成比较顺滑，语义检索、提示词模板这些都有现成组件；Python生态更灵活，LangChain、LlamaIndex功能丰富，但也是“自由度过高容易走偏”的典型区域。生产型项目我更看重可控性，倾向于用框架的底层组件，但自己维护数据接入和检索流程。

另外，AgentScope 2.0提出的“RAG as a Service”思路值得关注一下。把知识管道封装成独立服务，对上层Agent提供统一的检索接口，Agent不需要关心底层是向量库还是SQL，只发起知识查询请求。这种设计有利于团队分工和系统演进，我个人比较推荐在规划Agent平台时优先考虑。

7. 一些想说的实操体会

做了几轮RAG项目之后，我最大的感受是RAG不是一个“锦上添花”的组件，而是Agent能不能落地的命门。很多人觉得只要接个向量库就算完成知识获取，结果上线没多久就发现召回质量上不去、知识更新不及时、复杂问题答得一塌糊涂。这些问题不是单点技术造成的，而是管道在整个生命周期里缺乏系统性的设计。

如果你想从这一篇开始动手，建议按这个路线走：拿一小批真实业务文档，做清洗和切块，跑通一条最小闭环；再准备二十条测试问题，记录命中率和答案质量；然后在闭环稳定的基础上，逐步加入rerank、元数据过滤、知识路由和多跳检索。不要一上来就求大而全。

这周我还在整理一个“文档自动清洗 + 切块 + 入库 + 评估”的完整示例项目，如果顺利，下一篇就把它放出来，到时候可以直接对着跑一遍。有关RAG和Agent结合的具体问题，欢迎交流。