做 Agent 有一阵子之后我最大的感受是模型本身的能力差距远没有知识接入方式的差距来得致命。一个再聪明的模型如果只能靠训练时固化下来的参数知识回答业务问题那它在真实场景里就是一个礼貌的“幻觉制造机”。这也是我今天想把 RAGRetrieval-Augmented Generation检索增强生成单独拿出来聊的原因。作为“走进 AI Agent”系列的第四篇本文不再讲 Agent 的骨架和工具调用而是聚焦知识获取管道——也就是 RAG 基础。无论你是要做知识库问答、企业内部智能助手还是想把 Agent 接进垂直行业流程RAG 都是绕不开的第一步。这篇我尽量少讲抽象概念多讲落地逻辑、选型思路和排障经验适合正在或者准备从零搭建 Agent 的读者。1. 为什么 Agent 的“骨架”里必须塞进一条知识获取通道1.1 三个知识来源参数知识、上下文知识、外部知识从落地视角看一个 LLM 驱动的 Agent 能利用的知识大致有三类搞混它们的边界是很多项目跑偏的起点。第一类是参数知识也就是模型在预训练阶段学进权重里的东西。这类知识的优点是覆盖面广但问题也很明显它有截止日期。模型训练完的那一刻它的世界就定格了之后发生的事、你公司内部的新政策、某个产品的实时价格它一概不知道。第二类是上下文知识也就是通过提示词、对话历史和缓存信息临时塞给模型的内容。它的优势是灵活可以随时改但受上下文窗口限制不能无限塞而且塞进去的东西如果没有经过筛选反而会把模型带到沟里。第三类才是本文的主角——外部知识通过检索、工具调用等手段在推理时动态获取的知识。RAG 就是这类知识最典型、也最成熟的实现方式。参数知识负责“常识和语言能力”上下文知识负责“当次的对话状态”外部知识负责“事实和规则”三者的定位完全不同。如果你试图用上下文知识硬扛所有业务信息成本会迅速失控如果你什么都不做只依赖参数知识那 Agent 的下限就是一本过期的百科全书。1.2 RAG 解决的两个核心痛点知识截止与业务信息孤岛我在刚开始做 Agent 项目时犯过一个很典型的错误直接把公司内部的售后政策文档拼进 Prompt然后让模型回答。文档不长的时候效果还可以但一旦文档变多、问题变杂要么上下文塞不下要么模型开始胡乱组合不同文档里的内容输出一些看似合理但完全不存在的规定。RAG 解决的是两个层面上的问题。第一个是知识截止问题。模型训练完之后它不知道 2025 年之后发生了什么也不知道你们系统里刚刚更新的库存数据。RAG 可以在每次请求时去外部数据源里找回最新的信息让答案跟现实对齐。第二个是业务信息孤岛问题。大多数企业的核心知识根本不在公开语料里产品参数在 ERP 里售后政策在内部 Wiki 里技术方案在历史工单里。这些数据如果不去做索引和检索模型再聪明也无从谈起。有人会问那为什么不直接微调我的经验是微调和 RAG 不是替代关系。微调更适合改变模型的“行为风格”或者“输出格式”而 RAG 更擅长给模型“补充事实”。如果你今天有一批新知识明天可能又变后天还在更新那 RAG 明显更合适因为不用每次变化都重新训练。反过来如果你需要模型按照某个固定口吻、固定结构输出光靠 RAG 是不够的微调或精调提示词更直接。大多数项目的最优组合是用 RAG 解决知识新鲜度和覆盖面用 Prompt 设计解决行为约束必要的时候再考虑微调。1.3 知识获取管道和普通 API 调用相比特殊在哪里“管道”这个词值得拆开讲。RAG 不是一个简单的“查数据库再填进 Prompt”的动作它是一条多阶段的链路从原始文档的清洗、切分、向量化到索引存储再到查询时的召回、重排、合成。每个环节都会影响最终答案的质量而且环节之间是连锁反应。打个比方知识获取管道很像一个自来水系统文档加工是水源净化向量索引是蓄水池和管网查询召回是水龙头重排和合成是终端调温。你只换一个好水龙头但如果上游的水源是一池脏水出来的水照样不能喝。这条管道之所以要单独作为一个模块来设计就是因为 Agent 的能力上限往往不是模型决定的而是知识管道的通量和水质决定的。理解了这一点我们就可以往下拆管道本身了。2. RAG 三段式管道拆解入库、召回、合成不是三个模块是一套取舍2.1 入库阶段的隐藏工作量切分粒度与元数据设计很多人把 RAG 的第一步理解为“把文档丢给向量数据库”其实没那么简单。入库阶段有三个活儿最花时间文档清洗、切分、元数据标注。文档清洗经常被跳过但它恰恰决定了后续所有环节的质量下限。比如 PDF 转出来的文本经常带着多余换行、页眉页脚、乱码字符如果不做清理切分出来的文本块会非常脏检索时匹配到的内容也往往是“形似而神不似”。我通常的做法是先做统一格式转换再用正则或规则把页眉页脚、重复标题、无意义符号去掉必要时对表格类型的内容做结构还原而不是直接当成纯文本处理。切分是入库阶段里最影响效果的一步。切分粒度过大一个块里混了多个主题召回时容易带进无关内容切分粒度过小语义不完整模型拿到的是半句话根本没法理解。常用的做法是按固定字符数切分比如 512 或 1024 个字符配合一定的重叠率。但更建议在固定长度基础上结合“语义断点”也就是按段落、标题层级来做边界检测避免在句子中间硬切。元数据设计是很多人忽略的隐藏变量。简单说你要为每个文本块记录它来自哪篇文章、哪个章节、什么文档类型、更新时间等字段。这些元数据在后期可以做候选过滤比如“只检索 2025 年之后的政策文档”“只检索产品库里的规格参数”可以大幅减少无关召回。没有元数据的 RAG就像没有目录的档案库你只能靠全文搜索硬找。2.2 召回阶段的取舍向量相似度为什么还要配关键词检索召回阶段最常见的实现是向量检索但只靠向量检索远远不够。向量检索的思路是把文本映射到高维语义空间然后通过余弦相似度等指标找到语义相近的块。它擅长处理“意思相近但表述不同”的查询比如用户问“电脑老是卡怎么办”能匹配到“设备运行缓慢的排查方案”这类块。但向量检索有几个明显的弱点。第一对专有名词和编号类信息不敏感。比如产品型号“AC-3200B”如果向量索引里没有完全对应的 token相似度可能被拉得很低而一个简单的字符串匹配反而能精准命中。第二对数字、公式、代码片段等精确信息向量检索往往会给出“差不多但不对”的结果这在业务场景里非常致命。第三向量模型本身有语言和领域偏向在中文业务语料上通用向量模型的表现可能达不到预期。所以我会在召回阶段引入混合检索向量检索负责广度关键词检索比如 BM25 或 Elasticsearch 的全文检索负责精确匹配。两者各自召回一批候选再做融合排序。融合的办法有很多简单的是分数加权归一化进阶的是用 RRFReciprocal Rank Fusion这类排序融合算法。无论用哪种本质上都是对“语义相关性”和“字面匹配度”做一次取舍。你很难说哪条路绝对正确正确与否取决于你的业务知识长什么样。2.3 合成阶段的重排与上下文压缩召回结束之后合成阶段不是简单地“把候选块拼进 Prompt”就完了。候选块通常是十个八个但上下文窗口有限且不是每个候选都有价值。这时候一个容易被低估的组件就上场了重排器Reranker。重排器的思路是先用向量检索和关键词检索拉回一个较宽的候选集再用一个更精细的模型对候选做相关性打分。常见做法是用交叉编码器模型把查询和候选块拼在一起输入模型得到一个更精准的相关性分数。为什么需要这一步因为向量检索的分数通常是粗粒度的它可能把“提到同一个词但语义方向相反”的文本也打高分而重排器能更细地判断候选到底有没有回应查询的意图。我自己的经验是加上一个好的重排器之后答案质量的提升往往比换一个更强的 LLM 还明显。除此之外合成阶段还要做上下文压缩。也就是说不要把十个候选原封不动塞进去而是提取每个候选里和查询最相关的片段甚至做一些摘要。上下文压缩的好处是白减少噪声降低模型被无关信息带偏的概率也可以节省 token 成本。最后再把压缩后的上下文、用户问题和指令组装成最终的 Prompt。到这里基础 RAG 的链路才算真正跑通。3. 从零落地 RAG 基础管道切分参数、向量模型与混合检索的实操记录3.1 切分操作的三个翻车参数块大小、重叠率、跨章节切分我原来以为切分只需要设一个固定长度后来在真实数据上反复测才意识到里面全是坑。第一个坑是块大小。块大小直接影响召回的精度和上下文利用率。512 个字符的块比较适合主题相对独立的文档1024 个字符的块更适合内容密度高、上下文依赖强的技术文档。没有一个绝对值我一般会准备一组样本问题分别用不同块大小跑一遍召回命中率用数据说话。第二个坑是重叠率。重叠率是对“切分边界准确性”的补偿。如果完全不设重叠一个完整段落可能被拦腰切成两半查询时只能召回其中一半答案自然残缺。我的经验是重叠率放在 10% 到 20% 之间既不重复冗余又能保住语义边界。第三个坑最隐蔽跨章节切分。如果直接按固定长度切可能上一章的结尾和下一章的开头被拼在一起形成语义混乱的“缝合块”。更好的做法是先把文档按标题、段落结构切出父块再在父块内部做细粒度切分让每个块都携带章节上下文。3.2 嵌入模型选型的两个标准语言覆盖与维度开销选嵌入模型时很多人只看榜单分数忽略了两个实际指标。第一个是语言覆盖。英文语料上效果好的模型拿到中文业务文档上可能一塌糊涂。我会优先选择针对中文优化过的嵌入模型比如 BGE 系列或者其他在中文语料上有专门训练的模型。如果项目的语料是中英混杂还要特别留意模型在中英混合文本上的表现而不是只看单一语言的基准分数。第二个是向量维度带来的存储和检索开销。嵌入向量的维度越高理论上表达能力越强但存储成本和检索延迟也会上升。对一个几十万文档规模的项目来说维度翻倍可能意味着内存和磁盘开销的翻倍。我一般会结合工程条件选一个折中方案必要时用降维或者量化手段来压规模。选型上还有一个建议不要频繁切换嵌入模型因为切模型意味着整个索引库要重建。所以前期可以多花一点时间做基准测试确定之后尽量稳定使用后续的知识更新走增量入库就好了。3.3 重排器在中文业务场景下的作用被低估了我在最初搭建 RAG 时没有上重排器理由是“向量检索已经够用”。后来被几个案例教育了。典型的情况是用户问“你们对公转账的到账时间是多少”向量检索召回的候选里有两三块都提到了转账但一块讲的是对公转账到账时间另一块讲的是个人转账限额还有一块讲的是对公转账手续费。从向量相似度看它们的分数可能差得不大但真正能回答问题的只有第一块。重排器做的工作就是把这种“宽泛相关”和“精准命中”区分开来。在我用过的方案里轻量级交叉编码器重排器就能带来肉眼可见的效果提升。工程上重排器一定要放在“最终合成”之前操作步骤是先召回一个较大的候选集比如 20 到 50 条用重排器打分后取 Top 3 到 5 条再交给 LLM 生成答案。注意这里的候选集数量不能太小否则重排器没有足够的“筛选空间”但也不能太大否则重排本身的耗时会上来影响响应延迟。3.4 一个可以照搬的基础流程参考下面是我在项目里常用的 RAG 基础流程不绑定某个具体框架任何工具栈都可以照着落文档解析与清洗把 PDF、Word、Markdown、HTML 统一转成纯文本去掉页眉页脚、重复模板识别并尽量还原表格结构。结构化切分先按文档标题建立父块再按段落或固定长度切子块保留章节路径作为元数据。嵌入与入库调用嵌入模型生成向量连同文本块和元数据一起写入向量库同时建立关键词倒排索引。查询改写可选用户问题如果太口语化可以做轻量改写比如“最近出的那款手机怎么样”改写为更明确的检索语句提升召回精度。混合召回向量检索加关键词检索各返回一批候选做分数融合取 Top N。重排用交叉编码器对候选重新打分保留最相关的少量文本块。上下文拼装与生成整理上下文、用户问题、指令模板交给 LLM 生成最终答案。这套流程跑通之后你的 Agent 才算真正具备了一条稳定的知识获取管道。但只做到这一步还不足以应对复杂一点的业务需求所以接下来聊聊进阶变体。4. 进阶视野Agentic RAG、GraphRAG 与本体增强到底改了什么4.1 Agentic RAG 的本质变化从单次召回变成计划、验证、追问的循环基础 RAG 的流程是“用户提问 → 检索 → 生成”一次搞定。但实际业务里很多问题不是一个召回动作能解决的。比如“对比一下 A 产品和 B 产品上个季度的退换货率并给出改进建议”这种问题需要先定位“业绩数据来源”再分别获取 A、B 产品的退换货率然后可能还要再找退换货的细分类目最后才能综合分析。Agentic RAG 就是把“检索”这件事从单次动作升级为 Agent 循环。它把用户问题当成一个任务由 Agent 自行拆解成若干子问题按需调用不同的检索工具拿到结果后判断信息是否足够不够就继续检索或追问最后再合成答案。这个过程中“检索什么、什么时候检索、检索完要不要再检索”是由 Agent 动态决定的而不是预先写死的管道。这种模式非常适合问题复杂、依赖多轮信息拼装的场景。但代价也很明显延迟更高链路更长出错的可能性也更多。所以我通常的建议是能用基础 RAG 解决的问题不要一上来就上 Agentic RAG等你的基础管道质量足够稳定再逐步把复杂问题路由到 Agent 循环里去。4.2 GraphRAG 补的是文本块之间的“关系盲区”基础 RAG 的最小单元是文本块但很多知识藏在文本块之间的关系里。比如公司组织架构、产品组件结构、项目依赖关系这些知识分散在多个文档里单纯按文本块做向量召回很难把它们“串联”起来。GraphRAG 的做法是在入库阶段先通过 LLM 或规则抽取文档中的实体和关系构建一张知识图谱检索时不仅找语义相似的文本块还会沿着图谱的关系路径去扩展相关信息。比如用户问“这个功能改动会影响哪些模块”单纯向量检索只能返回文档里直接提到相关模块的段落而图谱检索可以把“A 模块引用了 B 模块、B 模块依赖 C 模块”这样的链条拉出来给出的答案会更完整。GraphRAG 的缺点也很明显图谱构建成本高、实体抽取质量不稳定、更新维护复杂。它适合知识之间的关系性很强的场景比如研发文档、产品架构说明书、复杂流程规范。如果只是做简单问答先不急着上图谱把混合检索做扎实更划算。4.3 本体增强从“语义相似”走向“概念对齐”本体Ontology增强是我最近在试的方向它解决的是“拼接式错误”的问题。业务领域里有很多同义词和上下位概念比如“设备”“机器”“硬件”在用户嘴里可能是一回事但在文档里它们的表述完全不同。如果只靠文本向量相似度模型可能把“设备故障”理解成“机器报错”去找答案结果找回一堆边缘内容。本体的思路是先把领域里的核心概念、概念间的层级关系和同义关系显式地定义出来然后在检索时用这些概念层去约束和扩展关键词。举个例子用户问“硬件兼容性”本体层可以自动扩展出“设备兼容性”“驱动支持”“接口标准”等关联概念再去检索就不会只盯着字面词。本体增强的落地成本不低因为它需要有人梳理领域知识而且本体本身也需要持续维护。但如果你做的 Agent 要深耕某个垂直行业本体层的收益会随着知识库规模的扩大越来越明显。可以说它是缓解“知识割裂”问题的一套长期解法。4.4 Skill 与 RAG 的结合方式检索结果作为工具参数最后谈谈热词里反复出现的“Skill 怎么和 RAG 结合”。在 Agent 的架构里Skill 一般指的是可执行的功能单元它包含触发条件、执行逻辑和输出格式。Skill 和 RAG 结合的正确方式不是把 RAG 做成一个独立的技能而是把 RAG 检索结果作为 Skill 执行时的输入参数。举个例子我有一个“政策问答技能”。当用户问到某个报销规则时Agent 路由到这个技能技能里先触发一次 RAG 检索拿到相关规则文档再结合用户的具体报销场景走一个规则校验逻辑最后输出是否合规、需要哪些材料。在这个过程中RAG 提供的是知识和依据Skill 提供的是业务规则和动作。两者分离又协作是 Agent 工程里一个很值得记住的模式。5. 质量瓶颈与一套可复用的排障链路5.1 五个典型症状及根因对照RAG 跑起来容易跑得稳很难。下面是我在多次排障中总结的常见症状和它们背后的根因你可以把这当一张快速诊断表用。症状可能的根因优先排查点答案完全跑题召回阶段没拉到相关内容检查 top-K 是否太小确认查询改写有没有把问题带偏答案相关但细节错误文本块被切碎语义不完整检查切分边界是否把完整段落切断增大块大小或重叠率答案频繁出现“不知道”索引库里根本没有对应内容查文档是否成功入库查元数据过滤是不是误伤了同一问题多次回答不一致召回候选不稳定检查混合检索融合逻辑检查是否有随机采样导致候选波动答案引用了不存在的规则多个文本块内容互相冲突检查知识库里是否混入了过期文档建议加来源和版本过滤这张表不一定覆盖所有情况但它能帮你快速定位问题到底出在“入库、召回、重排、生成”的哪一段而不是一上来就换模型。5.2 一条实用的评估链路从召回命中率到答案准确性很多项目失败不是因为没有代码而是因为没有评估。没有评估你就无法知道一个改动是变好了还是变坏了。我会建议从最简单的评估体系开始准备 20 到 50 条有代表性的业务问题为每个问题人工标注出正确答案对应的文本块编号然后可以做两类评估。第一类评估是召回命中率Hit Rate。把问题喂给检索管道检查 Top 5 或 Top 10 候选中是否包含标注的黄金文本块。如果 Hit Rate 偏低优先优化切分、嵌入模型和混合检索策略。第二类评估是答案质量评估。把问题、召回文本和模型生成答案放在一起人工或使用更强的模型当裁判按相关性、完整性、事实准确性三个维度打分。注意答案质量评估一定要考虑来源引用RAG 的答案必须能被回溯到具体的文本块否则就是无源之水。我通常的做法是把这两类评估固化成一个脚本每次修改任何组件之后都跑一遍记录对比结果。迭代几个版本后你会发现大多数“模型不行”的抱怨最后都指向了管道里的某一个具体环节。5.3 中文语料的特殊问题编码、分词与表格型知识中文场景里RAG 的几个特殊坑值得单独说。一是编码和乱码问题。从 PDF 转出来的中文经常会丢空格、出现全角半角混乱、断行错误。这些问题对向量检索影响尤其大因为模型对空格和换行的处理方式很敏感。我会在清洗阶段把全角符号统一转半角、把行内多余换行合并、修复常见乱码字符。二是分词与停用词。英文按空格分词中文没有天然分隔。虽然向量模型通常不依赖显式分词但关键词检索BM25对中文分词质量很敏感。建议选一个对中文支持好的分词器同时谨慎处理停用词——业务场景里的很多术语可能被误判成停用词那就毁灭性了。三是表格型知识。很多业务知识是以表格形式存在的比如报价表、参数对照表、库存状态表。如果直接把表格转成纯文本切分检索时经常只拿到零散的单元格模型根本拼不出完整上下文。我的经验是尽量在文档清洗阶段把表格转成结构化的 Markdown 或 HTML 表格在切分时以“整表”或“表头若干行”为单位保留元数据里标记表格类型检索结果里再接上表头信息。这一步做好表格问答的正确率会大幅上升。6. 写在最后RAG 是“知识获取管道”但不等于 Agent 的全部记忆6.1 RAG 与记忆机制的分工最后想说一个很容易被混淆的点RAG 不等于 Agent 的全部记忆。Agent 里通常还有一层“记忆机制”用来记录对话历史、用户偏好、短期状态等。RAG 管的则是长期的、事实性的、来自外部语料的知识。两者如何配合我的做法是路由层先判断用户问题是“事实型”还是“状态型”。事实型问题走 RAG 管道比如“公司年假政策是什么”状态型问题走记忆层比如“我刚才提到过的预算上限是多少”。两者也可以串联比如先查记忆确认用户身份再查 RAG 确认该身份适用的政策版本。把这两层的职责分清楚Agent 才不会在复杂对话里“东拼西凑”。6.2 我会把 RAG 管道升级成评估反馈回路如果现在让我给一个刚搭完基础 RAG 的人提建议除了把管道跑通之外我最想说的是给管道接上日志和评估反馈回路。每一次检索的候选、重排分数、最终引用的文本块、用户的后续反馈都值得记录下来。这些数据的价值非常大它们能告诉你哪些问题总是召回失败、哪些知识库文档长期没有被命中、哪些问题用户反复重问。我之前很长一段时间只关注“答案好不好看”很少去问“答案从哪里来”。后来把日志和评估体系补上之后才发现很多“效果不稳定”的抱怨其实是因为同一个问题在两次检索里命中了完全不同的文本块。只有当你把知识管道的每一段都纳入可观测范围Agent 的质量才能从“碰运气”变成“可迭代”。RAG 基础只是知识获取管道的起点。等你的基础管道稳定了后续的 Agentic RAG、GraphRAG、本体增强才有意义。这个系列后面我还会继续写知识管道进阶的方向包括评估体系完整落地、Agentic RAG 的多轮迭代案例以及怎么把知识管道的日志变成下一个版本训练的燃料。如果你也在做 Agent建议先别急着追新概念把你的切分、召回、重排、评估这四件事跑扎实再去谈进阶。
