RAG的难题，已经从“查到资料”转向“组织可用上下文”

过去一年，RAG成为企业落地大模型时最常见的技术路径之一。

原因并不复杂。企业通常不愿意为每一类内部知识重新训练模型，却希望模型能够理解制度文档、产品资料、业务规则、数据指标和操作流程。于是，文档解析、切分、向量化、召回、重排，构成了许多团队对RAG的第一印象。

但当系统从演示走进生产，问题很快会发生变化。

用户不再只问“这份制度写了什么”，而会提出更接近业务任务的问题：

为什么华东区域本月毛利率下降？请列出主要原因，并创建跟进任务。

这不是一道单纯的文档问答题。系统可能需要同时完成几件事：

• 确认“毛利率”的指标定义与计算口径；
• 查询经营数据库，比较区域、产品、客户和时间维度的数据；
• 检索价格政策、促销规则、异常记录与历史复盘材料；
• 判断哪些信息能够构成解释，哪些只是相关线索；
• 在权限范围内生成结论，并决定是否可以创建后续任务；
• 记录数据来源、操作过程与不确定性。

这正是企业RAG面临的核心变化：

RAG的重点不再只是召回相关文本，而是围绕具体任务，获取、筛选、组织并注入可信的上下文。

需要同时明确边界。RAG并不等于Agent、工具调用、工作流或权限治理。它解决的是外部信息如何进入模型当前的工作上下文；Agent负责在不确定任务中规划与选择，工作流负责确定性步骤和风险控制，工具负责访问外部系统，治理机制负责权限、审计和人工介入。

它们共同构成企业智能应用，但不应被混为一个概念。

一、用户要完成任务，而不只是获得一段文本

传统RAG最适合的场景，是边界稳定的知识查询。

例如：

• 某项制度的适用范围是什么；
• 某个产品功能如何配置；
• 某类故障的标准处理步骤是什么；
• 某个技术术语在内部文档中的定义是什么。

在这些问题中，找到正确文档片段，再生成忠实于原文的解释，通常已经能够满足需求。

但企业中的大量问题并非如此。

仍以“华东区域毛利率下降”为例，系统若只检索到一篇促销政策文件，最多只能回答“近期存在促销活动”。它无法判断促销是否确实影响了毛利率，更无法确认影响来自价格、成本、产品结构、客户结构，还是数据口径变化。

因为一个可用于业务判断的答案，往往不仅依赖文本，还依赖以下信息：

| 信息类型 | 在经营分析中的作用 |

|---|---|

| 文档资料 | 价格政策、促销规则、经营说明、历史复盘 |

| 结构化数据 | 订单、成本、收入、客户、产品、区域数据 |

| 业务元数据 | 指标定义、字段含义、表之间的关联关系 |

| 时间与版本信息 | 政策生效时间、产品版本、数据更新时间 |

| 权限与约束 | 哪些数据可见、哪些动作可执行、哪些结论需复核 |

因此，知识库不是答案库。

它更准确的角色，是模型完成任务时可调用的外部证据集合。问题不在于“是否找到一些相关内容”，而在于这些内容是否足以支持当前判断，是否包含正确的口径、时间范围、权限边界和业务约束。

对于进入生产流程的系统，RAG需要回答的第一个问题不再是“相关吗”，而是：

这些上下文，是否足以支撑模型完成当前任务？

二、RAG的核心变化：从文本召回转向上下文组织

企业信息通常不是以单一文档形态存在的。

制度规则可能藏在PDF、网页和流程说明中；指标定义可能位于数据字典、语义层或报表说明中；业务事实存在于数据库；复杂关系分散在工单、日志、产品版本和组织信息里。

如果把所有问题都交给向量检索，系统会遇到明显边界。

向量检索擅长处理语义相近的问题，例如“如何申请某类费用”和“报销该类费用需要哪些材料”。但它未必擅长处理精确编号、产品型号、字段名称、时间过滤条件和数值聚合。

例如，用户问：

找出近30天华东地区毛利率低于预算5个百分点的产品线。

这不是普通文档问答。系统需要理解“近30天”“华东地区”“毛利率”“预算”“低于5个百分点”等明确约束，并在正确的数据模型与指标口径下完成筛选和计算。

因此，生产级RAG的关键能力，不是选择一种“最强检索方式”，而是根据任务类型组织不同来源的信息。

| 问题类型 | 更适合的上下文获取方式 | 主要风险 |

|---|---|---|

| 制度解释、产品说明 | 语义检索、重排、原文引用 | 片段缺少前后文，版本过期 |

| 编号、型号、专有名词查询 | 关键词检索、全文检索、字段过滤 | 别名、拼写差异、精确匹配遗漏 |

| 指标分析、统计筛选 | 元数据检索、语义层、结构化查询 | 口径错误、关联错误、权限越界 |

| 跨资料关联分析 | 实体索引、关联路径、迭代检索 | 关联链条不完整，证据不足 |

| 流程处理与业务操作 | 上下文检索结合业务工具 | 参数错误、错误动作进入流程 |

这里的重点不是将所有能力塞入RAG，而是让RAG为不同任务提供合适的上下文。

一套成熟的系统通常会先判断问题属于解释、精确查询、数据分析还是业务操作，再决定需要检索文档、查询元数据、访问数据库，还是进入受控流程。这个过程可以称为上下文与任务编排，它比“召回若干文本块”更接近生产场景的真实难点。

三、检索策略必须匹配问题类型

单一向量检索并没有失效，它仍然是处理大量非结构化文本的重要手段。问题在于，企业任务往往同时包含语义理解、精确约束和结构化计算。

以经营分析助手为例，用户提出“为什么华东区域毛利率下降”，系统至少应先区分三个层面：

1. 事实层
   ：毛利率是否真的下降，下降发生在哪个时间段、哪些产品和客户中。
2. 定义层
   ：毛利率采用什么计算口径，预算数据来自哪里，是否存在数据更新延迟。
3. 解释层
   ：是否存在价格变化、促销活动、成本波动、产品结构变化或异常事件。

不同层面需要不同的信息获取机制：

• 事实层依赖结构化数据查询；
• 定义层依赖指标元数据和业务规则；
• 解释层可能需要检索政策文档、复盘报告、工单和沟通记录。

如果缺少事实层，模型容易把相关材料误写成原因；如果缺少定义层，系统可能基于错误口径得出“准确”的结论；如果缺少解释层，查询结果又会变成一串难以行动的数字。

因此，RAG的目标不应只是提高召回率，而应提高必要证据覆盖率。

所谓必要证据，不是所有相关材料，而是完成某项任务不可缺少的信息。例如，在问数任务中，必要证据可能包括指标定义、时间过滤规则、可用表结构、权限范围和查询结果；在客服任务中，可能包括当前产品版本、适用条款、客户状态和已发生的服务记录。

这也意味着，团队不能只问“检索结果相关不相关”，还应追问：

• 关键证据是否被召回？
• 模型是否知道当前证据仍然不足？
• 系统是否能在数据、文档和规则之间建立正确对应关系？
• 无法确认时，系统能否拒绝给出确定性结论？

四、关系结构何时值得引入

GraphRAG常被视为传统向量检索的升级方案，但更准确的理解是：它是一种用于表达显式关系的上下文组织方式。

传统文档切分后，系统得到的是许多独立片段。它们可以分别被召回，却未必能清晰表达实体之间的依赖关系、事件之间的关联路径，或跨文档信息如何串联。

例如，在研发故障分析中，一个问题可能涉及：

• 某个产品版本；
• 一次配置变更；
• 若干受影响服务；
• 对应错误日志；
• 历史工单和修复记录；
• 相关责任团队。

单次向量召回可能只找到错误日志或历史工单中的其中一类材料。若系统需要回答“这次故障是否与某次变更有关”，就需要沿着“版本 - 变更 - 服务 - 异常 - 工单”的关联路径组织证据。

图结构、实体关系索引或其他关系化组织方式，在这类场景中可能更有价值。

但这不意味着所有RAG应用都需要引入GraphRAG。

图结构带来的并不只有检索能力，也包括额外成本：

• 实体识别和关系抽取可能产生错误关系；
• 关系结构需要持续更新，维护成本通常高于普通文档索引；
• 图中的关联不等于因果关系；
• 图检索结果仍需回到原始文档、数据库记录或日志中验证；
• 对简单、稳定、低风险的问答任务，图结构可能增加复杂度却没有明显收益。

因此，是否引入关系结构，应当基于一个工程判断：

当前任务是否需要跨资料、多实体、多步骤地解释关联关系，而普通文本检索和结构化查询是否已经无法稳定满足需求？

如果答案是否定的，简单的混合检索和明确过滤通常更经济。只有当显式关系能够带来可验证的准确率、解释性或任务效率提升时，图结构才值得承担构建和维护成本。

中文企业文档尤其需要注意这一点。层级标题、表格、术语别名、混合格式文档和扫描件，都会直接影响解析、实体识别与检索质量。任何关系结构都建立在数据质量之上，错误解析的材料被组织得再复杂，也无法自动成为可靠证据。

五、RAG、Agent与工作流，应该如何分工

当系统需要查询数据、调用业务工具、创建任务或执行审批时，RAG通常会与Agent和工作流同时出现。

这里最容易发生的误区，是把它们视为可互相替代的概念。

更合理的分工可以概括为：

| 能力 | 主要职责 |

|---|---|

| RAG | 获取、筛选、组织任务所需的外部上下文 |

| Agent | 在不确定任务中分解问题、选择工具和调整行动 |

| 工作流 | 固化确定性步骤、关键规则、审批节点和异常分支 |

| 工具与接口 | 访问数据库、业务系统、文档系统和执行服务 |

| 验证与治理机制 | 权限控制、参数校验、审计记录、人工确认和结果拦截 |

Agent不等于工作流。

固定的“检索 - 查询 - 生成报告 - 提交审批”更接近工作流：步骤由开发者预先定义，适合高频、稳定、风险可控的业务过程。

Agent的价值主要体现在任务路径并不完全确定时。例如，面对“分析毛利率下降原因”这一问题，系统可能需要先判断下降集中在哪些产品线，再决定是否继续查询促销记录、成本变化或客户结构。模型可以参与这种任务分解与工具选择。

但生产系统不应将关键业务动作完全交给模型自由决定。

对于涉及资金、审批、客户权益、生产变更或敏感数据的操作，确定性工作流、规则校验和人工确认仍然不可替代。模型可以提供分析、建议和材料准备，但不应绕过已有控制机制。

本文所说的“受约束运行环境”，是指承载模型运行的一组机制，包括工具描述、权限边界、上下文压缩、状态保存、错误处理、结果校验和审计记录。

没有这类机制，Agent容易退化为一次不可控的长提示词调用；但如果系统只有固定流程而没有模型的理解与判断能力，又难以处理复杂、开放和例外较多的任务。

对企业而言，更现实的形态往往不是“Agent替代工作流”，而是：

• 工作流定义边界与关键节点；
• Agent处理有限范围内的判断、检索与工具选择；
• RAG持续提供可追踪的业务上下文；
• 高风险结果通过规则与人工复核后进入业务链路。

六、业务型RAG必须用任务指标验收

“回答是否流畅”可以用于展示，但不足以证明系统具备生产价值。

对于业务型RAG，更重要的问题是：它是否减少了完成任务的时间、返工和风险。

以不同场景为例，评价重点应有所不同：

| 场景 | 业务结果指标 | 关键风险指标 |

|---|---|---|

| 客服支持 | 平均处理时长、一次解决率、转人工率 | 引用错误率、错误承诺率 |

| 经营分析 | 查询成功率、口径一致率、人工修正率 | 越权访问率、错误归因率 |

| 研发支持 | 故障定位时间、重复排查次数、问题解决率 | 误报率、错误变更建议率 |

| 审批辅助 | 材料准备时间、规则命中准确率、人工复核比例 | 漏审率、错误动作拦截率 |

| 知识问答 | 有效解决率、问题闭环率 | 幻觉率、拒答错误率 |

为了定位问题，评估还应拆分到系统链路的不同环节：

| 能力 | 建议观察指标 |

|---|---|

| 文档解析 | 标题、表格、页眉页脚、扫描件的解析准确率 |

| 检索 | Recall@K、必要证据覆盖率、引用命中率 |

| 生成 | 忠实度、事实错误率、拒答准确率 |

| 结构化查询 | SQL执行成功率、结果集正确率、指标口径一致率 |

| 工具调用 | 参数准确率、越权调用率、失败恢复率 |

| 业务交付 | 任务完成率、人工接管率、平均处理时长 |

| 治理与审计 | 审计完整率、敏感信息泄露率、错误动作拦截率 |

这里有一个常被忽视的问题：引用不等于正确。

系统展示了若干来源，只能证明它找到了材料，不能证明这些材料确实支持最终结论。尤其在问数、审批和业务操作中，验证不能停留在“附上引用”，还需要检查指标口径、过滤条件、参数范围、权限边界和执行结果。

例如，NL2SQL的验证至少不能只看SQL是否能运行。更关键的是：

• 查询使用的字段是否符合指标定义；
• 时间范围与用户问题是否一致；
• 关联关系是否引入重复计数；
• 结果是否与已知报表或抽样数据相符；
• 用户是否有权限查看该结果。

对高风险场景而言，系统还应具备明确的拒答与升级机制。当证据不足、数据冲突或权限不明时，最可靠的行为不是生成一个看似完整的答案，而是说明无法确认的原因，并转入人工复核或确定性流程。

七、生产级RAG的真正门槛，是上下文质量与系统边界

许多团队开始RAG项目时，首先比较向量数据库、Embedding模型、切分策略和重排模型。这些选择仍然重要，但它们很难单独解释最终生产效果。

决定系统是否可用的，往往是更靠前也更靠后的问题：

• 企业文档和数据是否被正确解析、更新和分级；
• 指标、字段、实体和业务规则是否有可靠定义；
• 系统能否根据任务类型获取必要而非冗余的上下文；
• 模型是否被限制在明确权限与工具边界内；
• 输出是否经过数据、规则或人工验证；
• 出现错误时，团队能否追踪问题来自解析、检索、规划、工具调用还是生成环节。

这意味着，企业RAG不是一个孤立组件，也不应被无限扩张为所有AI能力的总称。

更准确地说，它正在从“文档检索增强模块”，演变为企业智能应用中的上下文组织层：将分散的文档、数据、关系、时间信息和业务约束，转化为模型在当前任务中能够使用、能够追踪、能够验证的证据。

至于任务规划、工具调用、流程执行、权限治理和人工接管，则需要由Agent运行环境、工作流系统与企业应用共同承担。

结尾：RAG的价值，取决于它能否提供可用证据

企业RAG不会只剩下一种形态。

简单、稳定、低风险的制度问答和知识检索，依然是合理且有价值的应用；复杂的经营分析、研发支持和流程协同，则需要RAG与结构化数据、工具调用、Agent和工作流共同工作。

因此，RAG系统的竞争重点正在逐渐从“召回了多少内容”，转向更难也更实际的问题：

• 是否获得了完成任务所需的正确上下文；
• 是否区分了文本线索、数据事实与业务规则；
• 是否能在证据不足时保持克制；
• 是否能在权限边界内支持后续动作；
• 是否能让每一次判断和执行被追踪、验证和复盘。

对需要进入生产流程的RAG系统而言，成熟度不应只看回答是否自然。

更重要的是，它能否让模型基于可靠证据，在明确边界内，完成一项真正可交付的工作。