RAG 生产级落地的六道分水岭：从文本拆解到 Agentic RAG

每次技术社区一聊 RAG总能看到“检索增强生成已经烂大街了”这种论调。说这话的人多半刚用 LangChain 或者 LlamaIndex 跑通了一条“加载 PDF - 文本切块 - 向量化 - 向量检索 - 丢给大模型生成”的流水线然后得出一个结论RAG 不过如此。我不这么看。烂大街的从来不是 RAG 本身而是那条被各类 rag 框架封装得越来越廉价的流水线。你随便搜一下“ollama 简易本地 rag 知识库”零基础复制教程一抓一大把跟着做确实能跑出一个像模像样的问答机器人但问题恰恰出在“像模像样”上——它能处理精心挑选的三五篇文档却应付不了真实场景里的几千份混合格式资料它能回答“这份合同里违约金是多少”却回答不了“这两个季度条款变化背后的业务逻辑”。真正把 RAG 做成生产级系统的团队和拿着 Demo 到处演示的团队差距不在是否会用框架而在六个容易被忽略的分水岭。这六处才是 RAG 从玩具走向生产力的关键。1. 先拆掉“流水线 RAG”的底裤它到底解决了什么又掩盖了什么聊六处分水岭之前得先把“流水线 RAG”的定义说清楚否则后面所有的批判都是空对空。一条标准的流水线 RAG 长这样文档加载Loader→ 文本拆解Splitter→ 向量化Embedding→ 向量入库Vector Store→ 检索召回Retriever→ 结果重排Reranker可选项多数人直接跳过→ 注入 Prompt → 大模型生成。这套东西有四个特征固定顺序、环节解耦、每步都有现成组件、端到端只需几十行代码。它当然有价值。2019 年 RAG 概念刚提出时最大的痛点是没有这条流水线——你得自己处理文档解析、自己维护索引、自己设计检索逻辑。如今 LangChain、LlamaIndex、LangChain4j easy rag 这类项目把环节全部封装成了“积木”搭积木这件事本身确实不值钱了。但它掩盖了三件要命的事。第一它把“检索”简化成了“点一下接口”可检索才是 RAG 的真正大脑。你写的那个vector_store.similarity_search(query, k4)背后是无数个被轻描淡写跳过的细节——用哪个嵌入模型、按什么相似度度量、文本块切多大、需不需要混合检索、召回结果怎么去噪。第二它把“文本拆解”简化成了“按字符数切”可切分方式直接决定了大模型最终读到的内容是否完整。整段语义被拦腰截断是所有 Demo 型 RAG 的通病。第三它默认“把文档扔进去就能检索”可现实中文档是 PDF、表格、扫描件、图片的混合体还有大量隐含的业务结构。流水线处理不了结构它只处理文本。所以接下来要聊的六处全部是流水线没有覆盖、但生产环境绕不开的地方。2. 分水岭一拆解不再是“按字数切”而是决定记忆颗粒度文本拆解是最不起眼、但翻车率最高的环节。因为它看起来太简单了——RecursiveCharacterTextSplitter(chunk_size512, chunk_overlap50)一行代码完事。2.1 为什么“固定字数切”必然翻车一个 512 字符或 token的窗口对中文文档来说大概是几百字的段落。问题在于语义的单位从来不是字数而是“一个完整的意思”。举个我实际遇到的例子一份产品说明书写着“本产品不适用于以下场景1. 高温环境2. 高湿度环境3. 强酸碱环境”如果两三句话刚好被切成两块第一块的结尾停在“1. 高温环境”第二块从“2. 高湿度环境”开始那么大模型在回答“这个产品适合在什么环境下用”时只会从切出来的碎片里看到半截内容结论自然荒谬。更隐蔽的问题是“切小了检索准、切大了上下文碎”的两难。块越小向量与 query 的匹配粒度越细检索精度越高但大模型看到的上下文就越碎片化生成时缺乏连贯背景块越大上下文越完整但一块里往往包含两三个主题向量表达的语义被稀释检索时就容易召回“看起来相关、实际答非所问”的内容。2.2 能打的拆解策略标题感知、父子块与滑动窗口不同场景我会用不同的拆解策略但都遵循一条原则让块边界贴合语义边界。标题感知拆解先按 Markdown 标题或文档的层级结构切分确保每个块属于同一个章节或小节。很多 PDF 转出来的文本带有标题样式先基于标题划分再对过长的二级标题内容做二次切分能显著降低“跨主题”的块出现概率。父子块结构小块负责检索提高精度大块负责生成提供上下文。具体做法是把文档拆成 256 token 的“子块”和 1024 或 2048 token 的“父块”向量索引只存子块召回时根据子块所属的父块把父块内容一并塞给大模型。这对“检索到细节 生成时看全貌”的需求非常管用。滑动窗口重叠块与块之间保留一定重叠比如 10%-15%避免恰好把一句完整的话切开。这是最低成本的兜底方案但要注意重叠比例太高会导致冗余索引增加存储和检索开销。2.3 拆解之后别忘了埋元数据文本块本身只是纯文本但如果能在拆解时顺手记录来源文件名、章节路径、页码、文档类型、更新时间后续的价值会大得多——过滤只搜某年的合同、引用溯源生成答案时标注出处页码、排序加权最新文档优先都依赖元数据。这是流水线教程里几乎不讲、但生产系统一定会做的细节。3. 分水岭二召回质量靠的不是一个向量库而是一条混合检索链路多数人做 RAG召回阶段就是一个向量相似度搜索把 query 转成向量算余弦相似度取 Top-K。这个做法在“语义相近的模糊查询”上表现不错但在真实业务里会碰到一个尴尬的问题向量检索天生不擅长精确匹配。3.1 向量召回的死穴精确 ID、型号、人名与反直觉搭配我做过一个内部设备知识库用户问“TS-200 的额定电压是多少”向量检索召回了一堆关于 TS-100、TS-300 以及“额定电压”相关的内容却把真正包含“TS-200”的文档排到了很后面。原因在于嵌入模型在计算相似度时更关注整体的语义主题而不是个别字符的精确匹配——对于“TS-200”这种字母数字混合的精确标识向量表示里几乎没有区分度。类似的场景还有问“去年和今年的退货率分别是多少”时query 里的“去年”“今年”都是模糊指代向量检索无法精确算出时间边界问“哪份合同里出现了‘不可抗力’条款”关键词精确检索反而比向量更快更准。3.2 混合检索BM25 做精确召回向量做语义召回再用 RRF 合并解决思路不是二选一而是“混合检索”——多条检索通道并行再合并结果。BM25 关键词检索对 query 做分词按词频和逆文档频率打分擅长精确词、产品型号、人名、编号的召回。向量语义检索擅长同义改写、抽象问题、跨语言查询。合并策略常用 RRFReciprocal Rank Fusion对每个文档在每条通道里的排名取倒数求和排名越靠前贡献越大最终按融合分数排序。这种方法不需要调权重对不同通道的打分尺度不敏感工程上最省心。在 LangChain 生态里这通常体现为EnsembleRetriever同时挂 BM25Retriever 和 VectorStoreRetriever如果要更精细也可以用 Elasticsearch 这类搜索引擎把向量检索和 BM25 在同一个索引里原生支持。3.3 重排别让召回结果直接进 Prompt召回 Top-20 或 Top-50 之后直接全塞给大模型既不经济还可能让模型被无关内容干扰。正确做法是在召回和生成之间加一道重排Rerank用一个交叉编码器模型Cross-Encoder把 query 和每条候选文本拼接后整体计算相关性分数打散重排只取前 3-5 条进生成。交叉编码器的精度远高于双塔式向量检索因为它在同一模型里同时看到了 query 和文档全文对“看似相关实则无关”的负样本更敏感。代价是计算量高所以工业界的标准打法就是向量检索粗召回几十条再交给重排序模型精排几条。一步到位追求“检索即答案质量”的人大多会在真实数据上吃一次亏才明白这层漏斗的价值。4. 分水岭三图片、表格、扫描件怎么变成可检索的上下文很多同学第一次接触 RAG 知识库时都会冒出一个问题知识库能存储图片吗或者说能不能让 RAG 直接检索图片这是对“存储”和“检索”的误解叠加。向量库存的从来不是原始文件而是“文本的向量”或者“多模态内容的向量”。所以这个问题要分三层回答。4.1 第一层图片本身进不了知识库但图片的“文本替身”可以对一张产品故障图最实用的做法是先让多模态大模型比如 GPT-4o、Qwen-VL、本地部署的 LLaVA生成一段图片描述包含图片里出现的型号、界面文字、故障状态再把这段描述作为文本块存入知识库。用户问“KM-300 报错 E5 怎么办”检索到的是这张图片的描述文本生成答案时模型可以引用图片内容。本质上就是用多模态模型把图片“翻译”成了可检索的文字。4.2 第二层表格和扫描件先做结构还原PDF 里的表格是 RAG 最大的敌人。按文本流解析出来的表格往往行序错乱、单元格内容断裂把它切成文本块后大模型根本看不出“哪一列对应哪一行”。处理思路是表格结构还原要么用专门工具把表格转成 Markdown保留表头和行列对应关系要么在拆解时把“表格”当作特殊块类型单独用结构化方式抽取再在生成阶段用表格内容配合提问。扫描件则要先做 OCR比较老的扫描版合同、内部规章不做 OCR 的 RAG 等于让大模型“看天书”。市面上本地可跑的方案有 PaddleOCR、Tesseract识别后要注意把 OCR 结果按版面顺序拼回文档流否则识别文字是有了段落顺序却乱了。4.3 第三层图文混排的终局方案是多模态向量化如果业务场景里图片信息密度高且不能靠描述文本覆盖就需要用真正的多模态嵌入模型——把图片和文本映射到同一个向量空间检索时用户输入文字 query直接通过向量相似度匹配图片。这是“知识库能存图片”的正解但工程成本高需要多模态向量模型、需要 GPU 推理资源、索引和召回链路也要改造。对大多数团队而言先用“图片转描述文本”的方案过渡是性价比更高的选择。判断标准很简单图片是辅助说明还是承载核心信息5. 分水岭四从平面向量索引走向知识组织ontology 与图谱不只是“炫技”大多数 RAG 系统的知识组织方式是“一袋文本块”——所有文档被切碎扔进向量库彼此之间没有关系。这在 wiki 类、FAQ 类场景够用因为每个知识条目本来就是相对独立的。但一旦涉及企业内部文档、专家经验、多份合同之间的交叉引用平面检索就会出现两个硬伤一是实体歧义“苹果”到底指水果还是公司二是多跳问题“A 项目的负责人所有过的项目”。5.1 wiki 类场景为什么不需要图谱先说说为什么有些场景确实不需要上图谱。维基百科式的静态知识库条目之间有明确的超链接结构每个条目自带标题、分类、摘要语义边界清晰。直接按段落拆、按标题检索效果已经很稳定。这种场景强行引入图谱是典型的过度设计——花了大量人力抽取实体和关系换来的一两个点的准确率提升根本不值。5.2 ontology 和 GraphRAG 解决的是“关系密集”的问题真正需要上 ontology 或知识图谱的场景有几个共同特征实体频繁跨文档出现、问题需要沿着关系链推理、不同来源对同一实体的表述不一致。GraphRAG 的思路是先抽取文档中的实体人、组织、产品、术语和关系“负责”“隶属于”“导致”构建一张图再对图做社区检测和摘要生成最后在问答时结合图结构和原始文本块。ontology 则更进一步给实体和关系定义了一套共享的语义模型比如“员工-就职于-部门”“合同-包含-条款”让知识组织从“相似度匹配”升级为“关系约束下的推理”。我参与过的一个售后知识库维修手册和故障记录里反复出现某个设备型号的多种写法“TS-200”“TS200”“穿石200”纯向量检索会把它们当不同实体。引入 ontology 后先做实体归一化再建立“设备型号-故障现象-解决方案”的关联关系回答“TS200 报错怎么处理”时检索会先找到归一化后的实体节点再沿着关系找出关联文本准确率从 61% 提到了 83%。5.3 想清楚你是要“找得快”还是“推得深”我的个人判断是如果你的核心痛点是大规模知识库里“找不着、找不准”优先优化拆解和混合检索别急着上图谱如果你的核心痛点是“需要跨文档推理、实体关系密集、多种表述混淆”ontology 和 GraphRAG 才是该投入的方向。这两者的 ROI 差别巨大。6. 分水岭五给 RAG 装上“度量衡”不然你永远不知道它在退化不会有人反对“RAG 需要评测”但现实是绝大多数项目把评测做成了“看几个样例感觉不错”。这是最危险的状态——大模型的回答是生成式的随机性和漂移都很显著今天感觉不错明天换了底模版本可能全面崩坏而你毫无察觉。6.1 分三层设计评测体系我对 RAG 系统的评测分三层每层关注不同的问题检索层只看召回质量不管生成。常用指标包括 RecallK正确答案是否在召回结果里、MRR正确答案排得多靠前。这层的问题用“正确答案文本在知识库中的位置”来构造评测集。生成层基于召回内容看大模型是否忠实于上下文Faithfulness 忠实性、是否覆盖用户问题Answer Relevance 答案相关性、是否符合预期格式格式合规率。端到端层直接在用户真实 Query 上打分让大模型当裁判LLM-as-a-Judge对比参考答案和系统回答的相关性、完整性、有用性同时兼顾推理成本、端到端延迟。三层混在一起评测是最常见的错误——回答差了你分不清是检索没召回还是模型没用好召回内容。6.2 评测集不用贪多但要覆盖“最难的那批问题”刚开始做评测时我的建议是从真实用户日志里挑 100-200 条代表性 query每条标注对应的标准答案文本块可以是人工翻出来的也可以参考已有系统然后按难度分层简单直接检索、需要跨文档整合、需要精确数值匹配、答案在图片或表格里。每次调整拆解策略、换 embedding 模型、改检索链路都拿这 200 条做回归看各层指标的涨跌。这一百多条“够用但不够全”的种子评测集往往比几千条自动生成的评测更管用因为每一题你都清楚它卡在哪个环节。6.3 没有评测体系的 RAG 优化都是靠感觉调参我见过太多团队卡在一个怪圈里换个 chunk 参数拿三五个问题试一下“好像还行”就上线过了两周用户反馈变差又换回来。没有量化指标这种“靠感觉调参”永远无法收敛。有了评测体系之后方向就清晰多了检索层召回率不达标优先动 chunk 大小、混合检索权重、重排模型生成层忠实性不达标优先动 Prompt 结构、上下文截断策略端到端不达标再考虑是否要从单轮 RAG 升级成多轮编排。顺序不能乱否则你只是在陪大模型掷骰子。7. 分水岭六从单跳问答到 Agentic RAG编排是最后一层分水岭前面五处解决的都是“一次检索、一次生成”的静态流程。但大量真实问题并不是单跳就能回答的。7.1 单轮 RAG 的边界复杂问题一上来就撞墙“对比今年和去年的退货率分析差异原因并给出建议”——这种问题如果直接丢给单轮 RAG流程会这样向量检索召回一堆退货相关的碎片模型拼凑一段口吻像模像样的回答里面可能既有 2023 年的数据又有 2025 年的政策你根本分不清它引用的是哪一年的上下文。原因在于这类问题需要先拆解成子问题今年的退货率是多少、去年的退货率是多少、各自的原因有哪些再按子问题依次检索、汇总推理。单轮 RAG 没有“拆解”这个心智。7.2 Agentic RAG把检索从“一次调用”变成“可规划的行动”RAG 与智能体结合业界叫 Agentic RAG。核心区别在于Agent 拥有工具检索、查数据库、调用 API、能记忆中间结果、可做多轮规划并在每轮行动后观察结果、调整下一步。具体到知识库问答常见的几种模式Query 路由先判断用户问题属于哪个子知识库再路由到对应的检索链路。比如“合同相关问法律库设备相关问运维库”避免所有问题都打到一个混合索引里。Query 改写把“退货率差异原因”改写成“2024 年退货率”“2025 年退货率”“退货原因数据分析报告”等多个可检索的子查询分别召回再合并。多跳检索回答“A 项目的负责人负责过哪些项目”先检索出 A 项目的负责人是谁再用这个名字做第二轮检索。工具闭环检索不到答案时Agent 调用其他工具查结构化数据库、调外部 API、请求人工补充而不是硬编一段“未找到相关信息”。7.3 什么时候值得上 Agentic RAGAgentic RAG 不是银弹它引入的是决策链路和额外推理成本。核心判断标准是你的问题类型里有多大比例需要拆解、多跳或路由如果 80% 是单跳事实问题“这个产品支持哪些协议”老老实实把前五处分水岭做扎实性价比更高如果用户问题本身就带复合意图、需要推理链、需要跨库汇总Agentic RAG 才能打出明显优势。我自己的经验是先维护一个“问题复杂度”的分类统计直接检索能答的算一类需要拆解的算一类需要检索外部工具的算一类以此决定要不要引入 Agent。没有这个统计就上 Agent你只会得到一辆造价昂贵但大部分时间在跑空路的高级汽车。回头看流水线 RAG 之所以让人觉得烂大街是因为它把所有环节都“平均化”了——拆解平均化、检索平均化、知识组织平均化、评测平均化。而真正把一套 RAG 做出生产价值的团队恰恰是在这些平均化的地方较真拆解时考虑语义边界检索时不只靠向量知识库里的图片表格能真正被利用再用评测体系守住质量底线最后按需引入智能体编排。这六处才是 RAG 对抗“烂大街”论调的底气也是你下一步值得花时间的地方。