1. 先从 Agent 架构里把知识管道单独拎出来看写 AI Agent 系列写到第四篇前面几篇分别聊了 Agent 的基础认知、规划能力和工具调用这一篇切入的角度非常关键——知识获取管道。简单说就是 Agent 到底从哪里拿到它回答问题、做决策所需要的事实。先给一个整体框架免得大家陷入细节出不来。一个完整 AI Agent 的架构通常包含几个核心模块感知模块接收多模态输入理解用户意图记忆模块短期上下文 长期知识存储规划模块任务拆解、步骤编排、路径选择行动模块调用工具、执行动作、获取外部反馈本篇聚焦的是记忆模块里的知识获取管道也就是 RAGRetrieval-Augmented Generation检索增强生成。你完全可以把它理解为 Agent 的长期记忆外挂——模型本身的参数知识是它的先天记忆RAG 解决的是后天补充资料并随时查阅的问题。我见过很多初学者一上来就堆 LangChain 代码把数据灌进向量库然后调一个检索链条就跑完全没想过为什么要这样设计。结果一问知识更新了怎么办检索不准怎么办多轮对话里怎么用历史信息全懵。这篇不从代码教起而是从为什么要这么设计管道里每一环在解决什么问题讲起最后才落到实操参数和避坑经验上。一句话概括RAG 不是向量数据库 Prompt 拼接的玩具它是 Agent 知识的质量控制和分发中枢。2. 为什么一篇讲 Agent 的文章要花大篇幅先讲 RAG很多人会有个疑问我已经有 LLM 了模型本身知道那么多知识为什么还要搞一套 RAG这个问题我每次分享都要解释一遍因为答案直接决定了整套系统的架构取舍。2.1 模型参数知识的天花板LLM 的知识存储在参数里本质上是海量语料的压缩统计结果。它有三个绕不开的问题知识新鲜度差训练数据截止日期就是它的知识保质期。问它最近发布的产品信息、最新的行业政策、刚出来的论文结论几乎必然出错或开始编。私有知识完全缺失企业内部文档、个人笔记、特定项目的技术方案、某个系统的接口文档这些东西根本不在公开语料里模型自然无从知晓。知识粒度不可控即便模型知道某个领域它的回答粒度是全局统计的。你问一个具体到某个版本、某个参数、某个团队内部的约定事项它只能给你一个相似但错误的内容。这不是模型的问题这是所有统计模型的边界。而 Agent 要落地到真实业务里恰恰天天要面对这三类模型不知道但系统必须知道的知识。2.2 Agent 场景里的 RAG 不是可选优化是地基我做过一个企业内部文档问答 Agent最开始没有接 RAG纯靠给模型写一大堆 system prompt 去约束它。结果很惨让它引用公司报销制度的具体条款它给你编了个像模像样但根本不存在的第 4.3 条让它根据项目周报汇总进度它把两个不同项目的相似描述合并到了一起。这就是典型的参数知识污染——模型分不清哪些是它见过的网上知识哪些是它此刻应该依赖的企业知识。加入 RAG 之后逻辑变成了这样用户提问Agent 先从企业知识库检索出最相关的 3~5 段资料把资料作为上下文注入 Prompt模型基于资料 问题生成答案答案末尾附上资料来源引用本质上模型从我凭记忆回答变成了我查阅资料后回答。后者的可靠性、可追溯性、可更新性完全不在一个数量级。2.3 RAG 给了 Agent 可验证的底气这是很多技术文章不点破的一点。Agent 一旦要自主行动、自主决策它就必然会遇到拿不准的情况。这时候如果靠模型记忆硬猜错误会被放大如果有一条管道可以去查资料、去对比、去引用Agent 的行为就变得可以被审计、被解释、被修正。说白了RAG 让 Agent 的不知道和瞎说有了区分度。这个区分度恰恰是 Agent 产品能否在企业里落地的最低门槛。3. 让整套 RAG 管道真正跑起来拆分、向量化、检索、生成理论铺垫完进入实操。我按一条最小可用管道的顺序拆解每步都会讲清为什么这么做和参数怎么定。3.1 文档加载与清洗脏数据进脏答案出管道的第一环是文档接入。这里的核心原则是你对文档做的预处理质量决定了整个 RAG 检索质量的上限。我常用的做法格式归一化PDF、Word、Markdown、HTML、TXT 全部转成纯文本或 Markdown。PDF 用 PyMuPDF 提取遇到扫描件还要先走 OCR这时候选 Tesseract 还是 PaddleOCR 取决于语言和清晰度中文文档我推荐 PaddleOCR准确率明显高一截。结构信息保留直接用 pdfplumber 之类按页提取会丢失标题层级、表格结构、代码块的上下文关系。更好的办法是转成 Markdown保留#标题层级后面切块和检索都能利用这些结构信号。噪声过滤页眉页脚、导航栏文案、重复的版权声明、乱码残留这些都要在清洗阶段干掉。否则入向量库以后检索到的片段里有一半是无关噪声再好的模型也回答不出准确的答案。注意清洗阶段最容易被忽视的是表格数据。表格一旦被摊平成纯文本表格的语义关系就丢了。后续检索如果依赖表格做题效果会很差。建议至少把标准表格按表头 : 单元格的键值对形式转换或者干脆用多模态模型直接从图片表格里抽取结构化数据再入文本。3.2 分块策略切多少、怎么切、要不要重叠文档进入管道后要切成固定大小的文本块。这里没有一个万能参数但有几个经验和试错方向。块大小的选择逻辑模型推理的上下文窗口有限检索回来的每段文本都会占用 Prompt 空间。块太小语义不完整检索到局部却看不懂全局块太大三个块就把上下文塞满了答案生成的自由度变小检索的精确命中率反而下降。我自己的经验值文档类型初始块大小重叠长度理由技术文档/操作手册512 token50~100步骤性内容较多512 足以容纳完整操作步骤长论文/研究报告768~1024 token128段落逻辑较强拆太小会破坏论证结构代码文件按函数/类切块0代码语义边界清晰按函数切最合理对话记录/问答对256~384 token32问答内容短促块太大检索命中率低切块方式字符数切块、token 数切块、语义边界切块三者的区别我实际感受是很大的。字符切简单粗暴中文环境下 500 字和 512 token 差距不大但英文文档 token 切更合理语义边界切按段落、按 Markdown 标题分节、按代码函数分块是最好的因为每一块都是一个相对完整的话检索到它之后模型能看懂全局。重叠窗口的必要性重叠是为了防一句话被拦腰切断的情况。比如一段文字在第 499 个 token 处讲到关键结论上一块只包含它的前半句下一块只包含后半句。不重叠的情况下检索结果就是两段残缺的话模型要费力拼接。重叠 50~100 token代价是向量库体积增加 10%~20%但检索准确率提升明显我在大多数项目里都保留重叠。3.3 向量化Embedding 模型的选择与比较切好块之后要把每块文本转成向量。Embedding 模型的选择直接决定语义相似的判断标准这个环节不夸张地说比后面的检索代码重要得多。怎么选一个够用的 Embedding 模型中文场景我现在的主力是BAAI/bge-m3它在中文语义匹配、检索任务上非常稳定支持 8192 的输入长度还能做多语言混合。早期项目用过shibing624/text2vec-base-chinese也能跑但长文本和多语言混合场景明显弱一截。英文场景OpenAI text-embedding-3-large或BAAI/bge-large-en-v1.5都可以BGE 系列的开源优势在于数据完全可控不用把企业内部文档发给外部接口。行业特殊术语多医疗、法律、金融通用 Embedding 经常对专业术语理解不到位这时候优先考虑领域微调或者改用专门的领域模型。实际对比的方法别听人推荐就拍板。拿你自己领域里的 50~100 个真实问答对分别用候选模型做检索看 top5 命中率这个指标叫 hit rate。我自己选型时给三个模型各跑了 200 条 query误差低于 3% 才会定下来不然宁可用稍慢但更准的模型。提示本地部署还是 API 调用这个决策不只看单次成本。RAG 检索通常是高频操作每个用户问题都要检索多次如果走 API成本会线性涨。企业场景、文档量大、调用频繁的建议本地部署一个 7B 级别的 Embedding 模型一张消费级显卡甚至纯 CPU 都能带动。3.4 索引与存储向量库 元数据过滤向量数据存储层市面上的方案不少FAISS、Milvus、Weaviate、Qdrant、Chroma。我现在的选型标准很简单练手和原型FAISS 就够了轻量、无需额外服务跑在内存里。小团队生产环境用 Qdrant 或 Milvus支持过滤、副本、持久化、多租户隔离。需要和生态整合PostgreSQL pgvector 也很好一个库把业务数据和向量都管了运维省心。元数据过滤是我强烈建议一开始就设计的。比如企业内部知识库文档可能按部门、文档类型、时间、权限级别打标签。检索时如果有元数据过滤条件就能先圈定范围再算相似度精度和性能都大幅提升。没有元数据过滤你检索全公司的文档某个团队的内部方案经常淹没在不相关的资料里。3.5 检索与重排序别只信 Top-K 相似度第一步检索通常用余弦相似度或内积取 Top-KK 我默认 20~50。但原始向量召回只是粗排必须接一个**重排序Re-rank**环节。为什么向量检索擅长找语义相关但不擅长判断精确匹配。比如你问报销标准是多少向量召回可能给你一堆报销流程报销类型的文章真正的数字标准却排到了十几名开外。粗排取太多噪声、取太少漏答案最稳妥的做法是向量检索先召回 Top50用一个交叉编码器Cross Encoder模型对query, 文档块逐对打分按精排分数取 Top3~5 进入 Prompt重排序模型我常用BAAI/bge-reranker-v2-m3它对中英文混合和长文档都支持得不错。加了 rerank 之后我几个项目的答案准确率从 60%~70% 提升到了 85% 以上这个环节投入产出比极高。3.6 生成把检索结果组织成模型可用的上下文最后一步把重排序后的文本块拼进 Prompt让生成模型回答。这个过程有三个经验引用标注每个检索块前面加编号生成时要求模型在答案中标注来源编号比如根据 [1][2] 所述……。这样答案可以追踪出错时能定位是知识库哪个文档造成的。限制生成边界Prompt 里要清晰说明如果检索资料不足以回答问题明确回答知识库中没有找到相关内容而不是强行编造。这能显著降低幻觉率。保留原始问题上下文多轮对话里别只把当前问题丢给检索管道要把整个会话的压缩摘要作为检索输入的一部分。不然它呢效果怎么样这种代词引用式问题会完全检索不到正确资料。4. 我在配置 RAG 时反复调整的几个工程细节讲完主流程这节把我的踩坑总结集中写一下。这些细节正常情况下文档里不会写但对生产环境的影响非常大。4.1 块大小和真实查询粒度的匹配一个很隐蔽的问题你切块的大小要和用户真实问题的粒度匹配。如果用户问的是Python 里怎样做字符串格式化而你文档切的是 1024 token 的大段落那么每一块里既有字符串格式化又有文件读写又有异常处理检索回来的相关其实是一坨大杂烩。相反如果文档是操作手册用户问部署步骤是什么你切 256 token 就会把完整流程切开检索回来只有第一步和第五步模型根本拼不出全流程。我的做法是先做一轮用户真实问题聚类分析高频问题涉及的文档片段大概多长再反过来定 chunk 大小。这不是一次定死的上线之后还要定期根据 bad case 分析反推调整。4.2 元数据过滤比想象的更有价值这个在 3.4 提过但我要再强调一遍。RAG 检索不准的最大来源之一就是知识库里东西太多什么都像相关。加一层时间过滤能让最近三个月的数据优先返回加一层部门过滤能让 A 组的方案不会干扰 B 组的检索。尤其常见的是产品说明书类知识库新旧版本混在一起不加版本过滤检索结果经常新旧参半答案自相矛盾。4.3 混合检索一定要打开的关键字能力纯向量检索有一个盲区专有名词、缩写、型号、人名、编号。这些东西的字面信息比语义信息更关键。比如技术文档里频繁出现的 LSTM-3000 这种型号名向量化之后语义相近的 3000L 设备文档也可能被召回但你真正想找的是完全匹配的型号。所以我默认管道里同时保留关键词检索BM25和向量检索再用 RRFReciprocal Rank Fusion把两路结果融合。实践下来带型号、工单号、订单号这类查询混合检索的准确率比纯向量检索高出 20% 以上。4.4 重排序该在什么时候接入不是所有场景都需要重排序。如果知识库只有几百个文档块向量搜索 Top5 直接进 Prompt 就够了再加一个 rerank 模型纯属增加复杂度和延迟。但一旦文档块数量超过几万或者检索结果相关性经常不稳定重排序就必须上。延迟预算也要考虑重排序模型需要把 query 和每个候选块配对做前向计算50 个候选大约增加 100~300ms对于实时对话场景是个可感知的成本。批量离线分析场景则无所谓直接用最强模型。4.5 检索结果的自查机制一个容易忽略的问题你怎么知道检索结果够好我现在的做法是给管道加一层自查逻辑——重排序后拿到 Top3 分数如果最高分低于某个阈值说明知识库里大概率没有相关内容。这时候 Agent 不该硬答而应该明确告诉用户知识库中未找到足够相关信息建议补充资料或换种问法或者启动备用管道Web 检索。这个阈值必须用离线评估集去标定取开和关之间分界最清晰的点。别拍脑袋定否则你会发现很多问题被静默吞掉了。5. 知识新鲜度、多轮记忆和检索智能化的三层演进基础 RAG 跑通之后进入 Agent 场景里你会碰到三个进阶问题知识更新、多轮对话、检索策略本身要不要动态化。一个个说。5.1 知识更新增量索引而不是全量重建知识库不可能静止。企业内部文档每周都在产生新的产品手册每发一个版本就要替换旧的。最笨的方法是隔段时间全量重建向量库简单但慢文档多的时候一次费几小时而且期间检索质量不可控。增量更新的做法是每个文档块记录来源文件的版本号和变更时间每次上传新文档解析后只对新块做向量化同时把旧版本的块标记为无效软删除。检索时通过元数据过滤排除已失效版本。这套方案配合一个简单的版本管理表完全不需要引入复杂的向量库运维组件。5.2 多轮检索记忆Agent 不能每次都失忆单轮 RAG 好做多轮对话才是 Agent 的主战场。用户第一轮问公司的差旅标准第二轮问那住宿标准呢Agent 要能带着第一轮的话题去检索。最简单的做法是把最近几轮对话压缩成一个当前话题摘要喂给检索管道。更进一步的做法是引入记忆分层短期记忆最近几轮对话原文、长期记忆用户偏好、历史关键决策让检索管道能同时参考这两层信息。我踩过的坑是把完整对话历史全文都喂给检索管道结果历史里的噪声文本污染了检索查询相关性反而下降。压缩摘要的效果远好于原文拼接。5.3 Agentic RAG从一次检索到按需检索最后聊一下 agentic rag。传统 RAG 是一问一检——用户提问系统检索模型回答。但复杂问题往往需要多步检索先检索目录了解知识库有哪些内容再逐步深入子话题或者先检索到一个初步结论再针对结论中的未知点发起第二轮检索。这种检索 - 判断 - 再检索的循环本质上就是 RAG 管道被 Agent 的规划能力驱动。我的经验是不要把 agentic rag 当作炫技。它适合知识库维度多、问题复杂度高的场景比如政策咨询、技术合规审查。简单的 FAQ 检索用固定管道就足够了引入 agentic rag 反而增加了延迟和 token 消耗。5.4 RAG 之外的知识获取方式RAG 是知识获取管道的核心但不是全部。系统提示词system prompt 里写死的团队规范、函数工具调用查数据库、查 API、代码解释器执行 Python 做计算都是 Agent 获取知识的途径。我在设计 Agent 时通常按三层组合先查结构化 API再检索非结构化文档最后才依赖模型参数记忆。顺序很重要结构化数据的准确性最高非结构化文档次之参数记忆最不可控尽量只用它做语言组织而不是提供事实。Agent 的知识获取管道建设本质上是解决模型不知道但任务需要知道的问题。把 RAG 的每一环——清洗、分块、向量化、检索、重排序、生成——都理解成一种对知识的精炼工序整个系统的设计思路就会清晰得多。下一篇可以接着聊 Agent 的记忆管理机制RAG 作为记忆模块的一部分如何和短期上下文、长期偏好记忆协同工作。