什么是 Decision RAG：从解释的 AI 到判定的 AI

缘起：止步于解释的 RAG

本文是专题连载“判定的 AI：Decision RAG 的虚与实”的第 1 篇。作为基础篇，先梳理这个术语从何而来、主张什么。

RAG（检索增强生成）是先找到与问题相关的文档，再把其内容输入模型，让模型生成有依据的回答的方法。RAG 综述论文（paper）总结说，RAG 的出现是为了用外部数据库中的知识弥补 LLM 的弱点，如幻觉、过时的知识以及难以追溯的推理过程。然而，企业业务中有相当一部分并不止于“这项规定写了什么”。还需要决定是否批准采购申请、把工单分派给哪个团队、是否转交给人工处理（升级）。

“Decision RAG”这个名称出自 Martin Connell 的 LinkedIn 专栏文章（w1）。文章说，大多数 RAG 只被设计成“提供信息（inform）”，而没有被设计成“做出决定”。即使是高级的实现，最终也止步于解释，无法给出明确的决定、一致地应用规则、输出结构化结果、在规定的控制范围内运行，以及产生可重复的结果。不过，这篇文章是没有支撑论文或实际案例的观点文章。本连载把 Decision RAG 视为“一位从业者的提议”，不把它当作已成定论的业界术语。

同样的问题意识在别处也能看到。软件开发公司 Leanware 的文章（w2）指出，RAG 大体上能给出有依据的回答，但在支持工单路由、贷款审批、合规是/否判定上会卡住。原因是：同一问题每次运行可能得到不同结果，无法保证遵守业务规则，决策记录（日志）没有结构化，也没有执行工作流的路径。该文把同样的结构称为“检索增强决策引擎”。名称尚未统一，这本身就说明这个概念仍在成形之中。

判定型在 RAG 演进脉络中的位置

判定型新提出了什么要求，把它与先前的 RAG 分支并列比较就能看清。RAG 综述论文（paper）把 RAG 分为朴素（Naive）RAG、高级（Advanced）RAG 和模块化（Modular）RAG，并从检索、生成、增强三个维度梳理相关技术。智能体 RAG 综述（paper）认为，现有 RAG 受限于固定的工作流程，无法进行多步推理，并梳理了通过反思、规划、工具使用、多智能体协作等模式动态调整检索策略的智能体 RAG。

从输入、输出、推理方式和解释责任四个方面比较这四个分支，情况如下。朴素 RAG 接收一个问题，找到相关文档片段，写出供人阅读的回答。推理在模型内部隐式进行，展示出处是加分项而非义务。高级 RAG 的输入和输出形态相同，借助重排器（重排序模型）或混合检索提升所找依据的质量。智能体 RAG 接收一个目标，反复进行多次检索和工具调用；过程越长，追溯其为何这样做就越困难。智能体 RAG 综述（paper）也把评估、协调和治理列为待解决的问题。

专栏文章（w1）所说的判定型，把一个事件（申请、工单、交易）连同其附带文档、结构化记录和政策一起作为输入。输出是包含判定结果和依据的结构化记录。推理遵循“依照这些条件进行评估”的明确标准，解释是必需而非可选。该文把这一脉络概括为“检索返回文档，RAG 返回答案，Decision RAG 返回结果”。

这一脉络中有一点需要注意。朴素、高级、模块化和智能体 RAG 是综述论文整理出的分类，而判定型是一篇专栏文章附加上去的位置，不应把它们视为同等分量的分类。

五个要素及对应的研究与工具

专栏文章（w1）用五个要素来说明判定型。将其简要概括，并为每个要素附上实际对应的研究和工具，如下所示。

第一，结合多个来源的上下文。这意味着不仅是文档片段，还要把结构化记录、政策和运营数据相互对照。Leanware 的文章（w2）把这一步描述为检索层：非结构化知识来自向量数据库，结构化记录来自 SQL 数据库，实时状态来自 API，政策来自文档库。Palantir 的 AIP Logic 文档（w5）也举例说明，基于 LLM 的函数以本体对象为输入，并与客户邮件进行交叉核对。

第二，明确判定标准。不是问“这些信息意味着什么”，而是指示“依照这些条件确定相应结果”。RAD（paper）与此最为接近。该研究指出，现有 RAG 缺少定量权重和可追溯的推理路径。因此，它从行业文档中自动提取关键标准，构建带权重的层次化决策模型，并依据该模型撰写结构化报告。层次分析法（AHP）原本是一种多准则决策方法，需要专家手工构建标准，难以扩大规模；该研究把这项工作交给了 LLM 和多个智能体。

第三，以结构化输出给出结果。OpenAI（w3）和 Anthropic（w4）都在 API 文档中提供结构化输出功能。Claude 文档（w4）说明，该功能通过约束解码（constrained decoding）保证回答遵循指定的 JSON 模式。它有两种形式：规定回答格式的 JSON 输出，以及用模式校验工具输入的严格工具使用（strict tool use）。

第四和第五是内置的规则与控制，以及必需的解释。Policy-as-Skill（paper）同时处理这两点。该研究不把政策只作为提示词中的文字，而是将其封装为带版本的执行单元（技能）。一个技能定义的项目包括：名称、版本、检索范围、所需依据、判定模式、转交人工审核的条件、审计记录项、缺少依据时的行为、提示词模板和上下文契约。研究人员使用固定的 Gemma4 模型，在 600 个开发任务上比较了 13 种方法。加上审计功能的配置（PaS+Audit）取得了精确匹配准确率 53.8%、审核路由 F1 0.854、引用精确率 1.000、审计完整性 1.000 的成绩，在大多数治理与审核指标上优于 LLM+RAG。

如何运作：判定结果示例

按照 Leanware 文章（w2）整理的分层结构来理解判定型系统的流程会比较容易。检索层从多个来源收集上下文。推理层的 LLM 不做最终决定，而是生成分类标签、置信度分数、提取的字段、风险评估等信号。决策逻辑层对这些信号应用阈值、政策约束、监管规则和升级条件。这一层是相同输入产生相同输出的确定性层。最后，执行层修改记录或启动工作流，所有步骤都留下审计记录。

下面是本文自行编写的示例，展示对一条公司内部采购申请的判定结果，并非真实系统的输出。

{"case_id": "PR-2026-1107", "decision": "转交人工审核", "policy": {"name": "采购审批政策", "version": "v3"}, "criteria": [{"rule": "预算余额检查", "result": "满足"}, {"rule": "在审批限额以内", "result": "超出"}, {"rule": "是否为注册供应商", "result": "满足"}], "evidence": [{"source": "采购审批政策 v3，第 4.2 条", "quote": "超出限额的事项须经部门负责人批准"}, {"source": "ERP 预算记录"}], "next_step": "分派至部门负责人审批队列", "needs_human_review": true}

每个字段各有作用。decision 是下游系统据以分支的值。保留 policy 的版本，是为了日后能回溯“当时依据哪项规定做出判断”。Policy-as-Skill（paper）要求在审计记录中保留政策与模型版本以及依据 ID，也是出于同样的原因。criteria 逐条记录每项标准是否满足，一行一行地展示“为什么”。evidence 指向所引用原文的位置，next_step 和 needs_human_review 则是通往执行层和人工审核流程的连接点。

这个示例中的判定不是“批准”或“拒绝”，而是“转交人工审核”，这是有原因的。专栏文章（w1）也说，判定型并不是把人排除在外，而是自动处理低风险事项、辅助处理中等事项、把高风险或模糊的事项交给人。Policy-as-Skill（paper）同样预先规定了失败时的行为：依据不足时按“未知”或“审核”处理。

“虚”的第一个信号：新名称，老工作

拆解判定型的结构会发现，新东西比想象的少。把业务规则单独放在代码之外、让相同输入产生相同结果，这是规则引擎、业务规则管理系统（BRMS）和决策表（DMN，即 Decision Model and Notation 这类决策建模标准）长期以来在做的事。Leanware 的文章（w2）也写道，决策逻辑层用规则引擎、评分模型或简单的条件语句来实现。如此看来，判定型的新意与其说在于“判定”，不如说在于由 LLM 承担前端工作：从分散的文档中提取判定标准和依据并放入规则。RAD（paper）做的正是这一前端工作，即标准提取和权重分配。

第二个信号是结构化输出的代价。Claude 文档（w4）所说的保证，是回答遵守模式这一格式上的保证，而不是判定正确的保证。格式约束研究（paper）报告称，强制使用 JSON、XML 等格式时，LLM 的推理能力明显下降，而且格式约束越严格，推理任务的性能下降通常越大。越是必须拿到判定 JSON 的系统，越需要单独考虑“先自由推理，再装入格式”的顺序，原因就在这里。

第三个信号是规则的效果并不均衡。在 Policy-as-Skill（paper）中，开启确定性控制后整体准确率升至 61.2%，但研究人员指出，其效果在很大程度上取决于任务类型。因此他们得出结论：规则干预不应处处施加，而应有选择地施加。该研究还警告，仅仅输出大量元数据就可能让综合分数看起来更好。“附有解释”和“判定正确”是两回事。

还有一点容易混淆。本站的“决策模型（Decision model）”一文讨论的是为每个选项打出概率并直接选择的一类模型。本文的判定型 RAG 指的是把检索、规则和结构化输出组合在一起的系统设计，两者是不同的概念。

最新动向

近期研究中，“把判定逻辑移到 LLM 之外”这一方向正在取得具体成果。基于放射学指南的决策图研究 GDGraph（paper）将整理指南的阶段与评估单个病例的阶段分开。首先由 LLM 把散落在正文、表格和交叉引用中的临床指南转换为可执行的决策图。评估病例时，快速模型只回答局部问题，真假逻辑则由确定性的图遍历处理。在涵盖肾囊肿、附件肿块、甲状腺结节指南的 347 个病例中，准确率从 57.3% 提高到 90.8%，高于检索增强的 GPT-4o（80.1%）和使用 CoT 的图引导 GPT-4o（82.7%）。研究人员表示，延迟和成本也低得多。不过，这是医疗指南这一特定领域的结果，不应直接解读为实际诊疗中的表现。

另一个方向是把人的判定本身积累为依据。iRAG（paper）是一个知识库起初为空、将人做出的决定存为先例并用于检索的系统。它起初只是静默观察，随后进入援引依据对人的判断提出异议的阶段，最后过渡到可以暂缓判断的自动处理。研究人员报告称，降低旧先例权重的机制在知识发生变化时能提升性能，但在知识稳定时会增加错误。也就是说，这是一种取舍，而不是普遍优势。研究人员还表示，尚未与真实用户一起评估可用性。

两项研究指向同一幅图景：LLM 用于阅读文档、提取标准以及做局部判断，而判定的骨架放在图、规则、先例这类可追溯的结构中。一项梳理金融 AI 演变的研究（paper）总结道，更先进的模型或自主智能体并非在所有任务上都更好，应根据任务的性质选择方式。这一建议同样适用于判定型 RAG。

何时使用，何时避免

适合判定型设计的，是判定标准以文档形式存在、结果落在少数选项（批准、拒绝、审核、分派）之中、并且事后需要说明是谁以及为什么这样决定的业务。合规分类、公司内部审批、工单路由都是例子。相反，如果标准本身尚未达成共识，或者只要给出供人阅读和判断的说明就足够，那么现有 RAG 也能胜任。额外加上判定层只会增加需要管理的东西。

常见错误有四种。第一，把政策文字粘贴进系统提示词，就以为有了管控。Policy-as-Skill（paper）指出，仅靠自然语言提示词，无法确定使用哪个政策版本、没有依据时怎么办、何时转交给人。第二，把符合 schema 的输出误当成正确的判定（paper）。第三，权限管控只作用于输入，却以为输出也受到保护。Palantir 文档（w5）明确说明，行列访问控制会过滤模型读取的数据，但不适用于模型的输出或模型生成的编辑。第四，不验证判定的置信度分数就直接用于阈值。Leanware 的文章（w2）建议持续监测置信度校准、批准率变化以及被人推翻的判定。

最重要的原则是人承担最终责任。判定型的目标是一致性和可追溯性，而不是把判断的责任交给系统。转交人工审核的条件以及没有依据时的行为，必须从一开始就纳入设计。

延伸学习，以及第 2 篇预告

起点是 Martin Connell 的专栏（w1）。它能让你快速把握论点的骨架，但阅读时要记住这是一篇观点文章。接着看 Leanware 文章（w2）中的分层结构和与 RAG 的对比表，可以建立设计上的感觉。如果想准确了解发展脉络，可依次阅读 RAG 综述（paper）和智能体 RAG 综述（paper）。

若想通过研究确认判定型的各个要素，标准提取与权重可读 RAD（paper），管控、审计与人工审核接着读 Policy-as-Skill（paper）。尤其是 Policy-as-Skill 中有关于确定性管控在不同任务上作用不同的分析，与下一篇的问题直接相连。在引入结构化输出之前，务必一并阅读格式约束研究（paper）。最近的趋势则由 GDGraph（paper）和 iRAG（paper）很好地体现。

第 2 篇将正面讨论本文留下的问题：判定规则交给 LLM，还是交给规则引擎？以及这条边界应该划在哪里？