★ FEATURED ARTICLE 1. 为什么Agent非要配一条知识获取管道聊到AI Agent大多数人的第一反应是“能自己干活”。确实Agent的核心能力在于规划、拆解任务、调用工具但有一个问题始终绕不过去它脑子里的知识是“死的”。我一直强调一个观点大模型本身是一个推理引擎不是一个知识库。它训练完毕的那一刻世界就被定格了。你问它2025年之后发生的事它不知道你问它你们公司内部的产品手册、售后FAQ、竞品分析报告它更是完全没概念。传统做法是微调把知识灌进权重里。但微调成本高、周期长、更新一次要重新训练而且你根本控制不了它记没记住、记住的是不是错的。还有一层更麻烦的即使它记住了你也拿不出证据——它的回答无法溯源出错了你只能干瞪眼。所以就有了RAGRetrieval-Augmented Generation检索增强生成。RAG的思路极其朴素既然模型不知道那就别让它猜给它一份参考资料让它对着资料回答。这就像我们开卷考试题目再怎么偏只要你带着教材、翻得够快也能写出个七八分。Agent需要RAG本质上就是因为知识获取管道是它落地到真实业务的必经之路。不管你是做一个客服机器人、一个企业内部的知识问答助手还是一个能自动读文档写报告的工作流没有RAGAgent就是空中楼阁。这篇是“走进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模型与开发框架先聊向量库选型。我把自己实测过的几种列个表向量库适用场景优缺点实测FAISS单机原型、纯Python项目上手最快但不方便做元数据过滤和持久化管理更像研究工具Chroma轻量级嵌入应用API很简单适合本地知识库但性能上限低数据量过百万后明显吃力Milvus生产级、大规模、分布式性能强支持混合检索和Filter但运维成本高需要单独的集群Qdrant生产级、中文生态友好Rust写的单机性能好支持丰富的Payload过滤我目前的主力Elasticsearch已有ES体系、偏文本搜索自带BM25和向量检索适合“文本搜索为主语义检索为辅”的场景如果项目刚开始数据量在几十万条以内单机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-K10再根据Rerank结果取Top-3给生成模型这样既保证召回率又不过度污染提示词。相似度阈值容易被忽略导致错误的片段进入候选集。建议用实际数据跑一些负样本算一下正样本和负样本的相似度分布然后取一个分界值。如果正样本最低相似度是0.53负样本最高是0.47那阈值设0.5就比较稳妥。注意不同Embedding模型产出的向量相似度分布不一样这个阈值不要直接拿网上的经验值套一定要自己算。质量验证环节我不推荐只看几个Demo案例就上线。我习惯在项目里维护一组评测问题集至少几十条覆盖简单问答、复杂推理、模糊指代、跨文档关联、知识库外问题等类型。每次调整参数或更换模型时统一跑一遍这个评测集计算三个指标Hit Rate命中率正确片段是否被检索出来MRR平均倒数排名正确片段排在第几位越靠前越好Answer Accuracy回答准确率最终生成答案是否正确这个评测集要定期更新因为用户的问题会越来越刁钻你会发现你永远需要更多的测试集来防止模型退化。4.3 本地知识库与业务系统集成的实用建议企业内部Agent数据往往散落在多个系统里Wiki、Confluence、企业微信文档、数据库、工单系统。如果全部导入一个知识库你会发现数据口径不一致、重复文档满天飞、还有大量过期内容。我的建议是分两层处理静态文档统一入向量库动态数据保留原系统只接API。静态文档更新频率低适合切块、向量化、入库。动态数据不行比如订单信息、库存状态、人员归属每几分钟就变一次如果同步到向量库频繁重建索引的代价非常高。这部分信息应该让Agent通过工具调用去查原系统而不是走RAG检索。知识库的更新机制我以前吃过亏。当时直接把新文档写进向量库不管旧的结果同一产品有两份手册版本还不一样检索出来的内容自相矛盾。后来改成“版本化目录”的结构每次导入新文档时把同主题的旧文档标记为过期并做一次“知识清理”把过期文档从索引里摘除或降权。这个过程可以半自动文档导入时带上元数据比如版本号、生效日期、状态检索时按元数据过滤只返回statusactive的片段。这个小改动让我后来的知识库质量稳定了许多。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系统上线后就是一个“活系统”它跟你写的代码一样需要在迭代和维护中持续演进所以把整个链路当成一个真正的软件工程来做而不是一次性建完就撒手不管。这是我能给的最真诚的建议。
阅读完成 · 觉得有帮助？
