判定规则由谁掌握：规则引擎、DMN、策略代码与 LLM 的分工

为什么“谁掌握判定规则”是个问题

本文是“做判定的 AI：Decision RAG 的虚与实”系列的第 2 篇。第 1 篇将 Decision RAG 概括为一种提议：以检索到的依据，结构化地输出“批准、拒绝、分配”之类的判定及其依据，并留下了“要把多少交给 LLM”的问题。本篇用实务方法论回答这个问题。

问题在于判定逻辑放在哪里。把判定交给 LLM 时，通常会把判定标准写进提示语句中。DMN 引导提示研究（paper）指出，判定逻辑这样埋在提示中，业务人员就难以修改或完善它，提示编写本身也要依赖反复试错，从而在透明性、复用和维护上产生问题。同一输入可能得到不同答案的概率性生成特性，对判定来说也是负担。审计人员问“为什么这一件被批准了”时，“模型就是这么判断的”算不上回答。

但只靠规则引擎也不够。规则引擎需要输入结构化的值（金额、日期、分数）才能运行，而现场的输入很多是账单、诊断书、电子邮件这样的非结构化文档。因此，把判定拆成两件事来看的视角很有用。不妨比作整理事实的书记员和翻阅规章手册的审查员。书记员从杂乱的文件中提取并整理出“索赔金额多少、投保几个月”，审查员把这些事实与规章手册对照后得出结论。本文的问题归根结底是：书记员和审查员的位置上分别该安排谁。

老办法：规则管理系统与 DMN 决策表

把判定逻辑从程序代码中分离出来单独管理，这一想法并不新鲜。业务规则管理系统（BRMS）长期以来做的就是这件事。例如，IBM Operational Decision Manager 产品页面（w5）介绍说，该产品用于发现、捕获、分析、自动化和治理（govern）基于规则的业务决策。页面还表示，它会以文档记录决策是如何做出的，以支持审计和合规，并能在法规变化时快速修改策略。

DMN（Decision Model and Notation）是描述这类判定逻辑的标准。OMG 官方页面（w1）将 DMN 介绍为精确规定业务决策和业务规则的建模语言与表示法，并说明它被设计为与流程标准 BPMN 配合使用。根据 OMG 规范页面（w2），DMN 由两种工具构成：展示决策之间依赖关系的图形表示法，以及详细到可以执行的表达语言。它还有 XML 表示，可以在组织之间交换决策模型。该页面列出了从 1.0（2015 年 9 月）到 1.6（2026 年 9 月）的正式版本以及 1.7 测试版。Camunda DMN 教程（w3）列出的核心要素包括：决策表（输入、条件、输出）、用于编写条件的表达式语言 FEEL（Friendly Enough Expression Language），以及决策无法用一张表完成时使用的决策需求图（DRD）。

我们亲手做一个。下面是一个判定保险金小额自动支付的虚构决策表。假设从上到下依次检查，应用第一条匹配的规则。

| # | 材料齐全 | 索赔金额（韩元） | 投保期限（月） | 近 1 年索赔次数 | 处理 | |---|---|---|---|---|---| | 1 | false | - | - | - | "要求补充" | | 2 | true | < 1000000 | >= 12 | <= 2 | "自动支付" | | 3 | true | < 1000000 | < 12 | - | "人工审查" | | 4 | - | - | - | - | "人工审查" |

读法很简单。一行就是一条规则，一行中的条件全部以 AND 连接。“-”表示“任何值都可以”（w3）。第 2 行读作“材料齐全、金额低于 100 万韩元、投保 12 个月以上、近 1 年索赔不超过 2 次，则自动支付”。避开了所有条件的案件由最后一行接收，转交给人处理。`< 1000000`、`>= 12` 这样的条件就是 FEEL 表达式。Camunda 教程（w3）说明，用 FEEL 可以编写字符串匹配、真假、数值大小比较与范围、日期先后等条件。DMN 引导提示研究（paper）举例的虚构贷款表（“年薪超过 50,000 且信用分数在 700 以上则批准”，最后一行用“-”接收其余情况）也是同样的形式。关键在于，引擎直接执行业务人员所读的这张表。Camunda 表示，这样做可以减少分析师与开发人员之间的误解，在运行中也能快速修改（w3）。

策略即代码：OPA 与判定查询

如果说 DMN 起源于业务人员阅读的表格，那么“策略即代码（policy as code）”潮流则来自开发和基础设施一侧。OPA 官方文档（w4）将 OPA（Open Policy Agent）介绍为一个开源通用策略引擎，用于统一整个技术栈中的策略执行。策略用一种名为 Rego 的声明式语言编写。声明式不是写“按什么顺序计算”，而是写“什么条件必须为真”。文档列举了微服务、Kubernetes、CI/CD 流水线、API 网关等用途，并说明 OPA 是 CNCF 毕业项目。

设计的核心在于将判定（decision-making）与执行（enforcement）分离（w4）。服务需要判定时，以 JSON 等结构化数据为输入向 OPA 发起查询，OPA 将输入与策略和数据对照评估后返回判定。执行仍由服务负责。同样重要的是，判定结果不限于允许、拒绝这类是或否，也可以是任意结构化数据。文档中的示例策略是“可从互联网访问的服务器不得开放安全性较弱的 http 协议”“不得开放 telnet”。把这些条件用 Rego 写好，既可以在创建服务器时加以阻止，合规团队也可以定期找出违规服务器。

与 LLM 结合来看，OPA 式设计带来的启示就很清楚了。判定引擎只需遵守“输入结构化数据，输出结构化判定”这一约定，不关心输入由谁生成。只要 LLM 把从非结构化文档中提取的事实按规定的 JSON 形式传入，判定就可以交给由人审阅、加版本号管理的策略代码。与 DMN 相比，区别在于使用者。业务人员需要直接阅读和修改的判定适合用 DMN 决策表，访问权限、部署条件这类由工程师管理的判定则适合用 Rego 这样的策略代码。

三种分工模式比较

LLM 与确定性规则的组合方式大致可分为三类。第一，LLM 单独判定：把规则写进提示，判定也由 LLM 给出。第二，LLM 提取 + 规则引擎判定：LLM 只从非结构化文档中提取事实，按规定的 schema 传递，判定由决策表或策略代码完成。第三，规则引擎判定 + LLM 辅助：输入本来就是结构化的，判定由引擎给出，LLM 只帮忙撰写发给客户的说明文字，或审查规则转为“人工审查”的例外案件。

按标准逐项比较如下（下表的评价是本文的判断）。准确性：LLM 单独判定在多步骤规则应用中可能不稳定（参见下一节的研究）。提取型的判定本身准确，但提取一旦出错，判定也随之出错。规则判定型只要输入正确，判定就正确。一致性：能保证同一输入得到同一判定的，只有含规则引擎的两种模式。审计便利性：规则引擎可以记录“命中了第几条规则”，而 LLM 单独判定无法保证模型写出的解释与实际判定理由一致。规则变更成本：改一行提示看似容易，但很难确认其影响。规则引擎一侧修改流程较重，但可以按表测试变更效果。非结构化输入：规则判定型要求输入是结构化的才能使用。

因此，适合的业务各不相同。LLM 单独判定适合风险低、规则尚只以文字形式存在且经常变化的初步分类或草稿撰写。提取型适合输入非结构化但标准已成文的业务，例如保险索赔材料或贷款申请材料审查。规则判定型适合金额、分数等输入已在数据库中、审计要求严格的业务。实务中，常在同一业务内同时使用第二和第三种模式：LLM 提取事实，引擎判定，LLM 解释该判定。此时应让说明文字以引擎给出的判定和依据规则编号为输入来撰写，判定与解释才不会出现偏差。

研究走向何方

以下数值均来自各论文设定的实验条件（数据集、模型、任务），不应理解为在其他业务中也能取得同样效果。

DMN 引导提示（paper）用 DMN 对判定逻辑建模，并据此把提示结构拆细，让 LLM 沿着既定的决策路径执行。该方法被用于在研究生课程中为学生作业生成反馈，由讲师给生成的反馈打上正确/错误标签进行评估。在这一案例研究中，其结果优于仅用 CoT（Chain-of-Thought）提示写入相同内容的做法；在基于技术接受模型（TAM）的问卷中，学生表示反馈有用。判定仍由 LLM 完成，但规则的原始版本放在业务人员可以修改的 DMN 中，因此这是一种介于“仅用 LLM”和“规则引擎”之间的方式。

符号工作记忆研究（paper）考察了 LLM 为什么会漏掉规则。初步分析显示，LLM 擅长单次应用规则，但步骤越多性能越差；当规则给出的顺序与应用顺序不一致时，表现更差。研究者认为原因在于“规则接地”（rule grounding），即找出当前应把哪条规则应用到哪个事实上。因此，他们把事实和规则以自然语言和符号（Prolog）两种形式存入外部工作记忆，接地交给符号匹配，实际的规则应用交给 LLM。在 CLUTRR、ProofWriter、AR-LSAT、Boxes 四个数据集上，他们报告使用 GPT-4 和 GPT-3.5 取得了优于 CoT 类方法和基于符号的基线的结果。神经符号表示研究（paper）的方向略有不同：它把模型的 Hidden Representation 转换为神经符号向量，在该空间中解题后再合并回原来的状态。在一组数学推理任务上，它报告交叉熵损失比 CoT 提示和 LoRA 微调平均低 88.6%，答对的题目多 15.4 倍。不过，这项研究处理的是数值计算规则而非业务规则，与其直接移植到判定系统，不如把它看作指向同一方向的依据：“把精确遵循规则的部分交给符号一侧会更好”。

Policy-as-Skill（paper）最贴近实务。它是一个运行时，把依据核验、审核路由、版本管理和审计打包成“可执行、带版本的策略功能”。研究固定使用 Gemma4 后端，在 600 个开发任务上比较了 13 种方法。PaS+Audit 的精确匹配为 53.8%，审核 F1 为 0.854，引用精确率和审计完整性为 1.000，在大多数治理与审核指标上领先于 LLM+RAG。加入确定性控制后，整体准确率升至 61.2%，但效果因任务而差异很大。研究者据此得出结论：不要给所有判定都套上基于规则的干预，而应有选择地加入。精确匹配只是略高于一半，这一点也值得一并记住。

商用工具的思路与本体的位置

商用工具也遵循类似的分工。这里不是说哪款产品更好，而是看官方文档中写明的设计。IBM ODM 产品页面（w5）强调以下功能：编写和测试判定的界面、对照场景和关键绩效指标（KPI）进行测试与模拟、基于角色的权限管理，以及治理与变更管理。页面还介绍了一款遵循 DMN、基于开源的产品（IBM Decision Manager Open Edition）。页面还说明，与 watsonx Orchestrate 的对话功能集成后，用户可以通过对话调用判定引擎；这与第三种模式相似，即由 LLM 接收对话、由引擎做出判定。

Palantir AIP Logic 文档（w6）将其描述为以无代码方式构建、测试和部署基于 LLM 的函数的环境。Logic 函数以本体对象或文本为输入，可以返回对象或字符串，也可以直接编辑本体。文档举出的用途是把非结构化输入中的关键信息连接到本体。设置自动化后，本体编辑既可以直接生效，也可以转入等待人工审核。同一文档指出，行级和列级访问控制只过滤模型“读取”的数据。这一控制不作用于模型的输出或模型生成的本体编辑，因此文档建议对流向下游的数据同时使用标记或基于分类的访问控制加以保护。

这里与本体系列衔接起来。本体中的操作类型（action type）预先定义了“哪些对象、在什么条件下、可以如何更改”。把判定转为实际执行的关口正在这里。即使规则引擎或 LLM 做出了“自动支付”的判定，更改支付状态也必须经过带有权限和校验的操作类型。这种把判定与执行分开的结构，与 OPA 将判定与实施分离的理念相同。即使判定出错，也能在执行关口再拦一次；也可以由执行一侧根据风险程度决定是直接生效还是转入人工审核。

规则变更时：版本管理与回归测试

规则一定会变：法规修订，自动支付额度上调，又加上例外条款。此时应遵循的步骤用文字整理如下。第一，把判定规则从提示文本中取出，移到决策表或策略文件中。DMN 有 XML 交换格式（w2），可以把决策模型作为文件处理；Rego 策略本身也是代码文件。第二，给规则加上版本。这与 Policy-as-Skill（paper）把策略打包为“带版本的执行单元”是同一思路。第三，每个判定结果都同时记录应用的是哪个规则版本中的第几条规则。这样以后才能在相同条件下复现“当时那个判定”。

第四，建立回归测试集，即由输入和预期判定配对组成的一组代表性案例。以前面的保险决策表为例，要逐一放入每一行的边界情况（正好 12 个月、略低于和略高于 100 万韩元、第 3 次理赔）。修改规则后，要同时检查“应当改变的案例是否按预期改变”和“不应改变的案例是否保持不变”。IBM ODM 页面（w5）强调基于场景的测试与模拟，也是为了在部署前完成这种确认。

第五项是 LLM 时代新出现的工作。不能只测试规则，抽取提示和说明提示也要用同一测试集一起测试。规则引擎没变，但如果修改了抽取提示，使其开始以不同方式抽取“投保期限”，判定就会悄无声息地改变。反过来，也可能规则改了，说明提示却仍按旧标准撰写客户通知。因此，测试集中不仅要放结构化输入，还要放入原始文档，一次跑通“文档 → 抽取 → 判定 → 说明”全过程。AIP Logic 文档（w6）同时介绍了用于隔离开发函数的 Foundry Branching，以及按原因归类失败测试案例并提出提示修改建议的 AIP Evals 结果分析器，也是出于同样的考虑。

常见错误、延伸学习，以及第 3 篇

常见错误大致可归纳为五类。一是只把判定标准写在提示里，既没有版本也没有测试；二是反过来想用规则覆盖所有判定，结果在规则无法应对的业务上反而更差（回想 Policy-as-Skill（paper）报告确定性控制的效果因任务而异）；三是判定阶段察觉不到抽取阶段的错误。第四，LLM 撰写的说明与引擎实际应用的规则不一致。第五，只依赖读取权限控制，没有另外控制模型生成的输出和编辑的流向（w6）。抽取结果要用 schema 校验；当值为空或含糊时，一定要像决策表最后一行那样，设置转入人工审核的出口。

延伸学习建议按以下顺序进行。先通过 Camunda DMN 教程（w3）动手熟悉决策表、FEEL 和 hit policy，再跟着 OPA 官方文档（w4）中的服务器策略示例操作，体会“判定与实施的分离”。接着通过 DMN 引导提示（paper）了解把标准判定模型与 LLM 连接起来的最简单方法，并通过符号工作记忆研究（paper）理解 LLM 为什么会在多步规则应用中出现偏差。最后，阅读 Policy-as-Skill（paper）中把依据核验、审核路由和审计整合为一个运行时的设计，并一并看它的局限数值。

确定了规则放在哪里，剩下的问题是“这个判定可信吗”：抽取有多可靠，判定依据是否与实际文档相符，日后审计人员能否原样追溯判定过程。第 3 篇《判定可信吗：置信度、依据与审计》将讨论这三点。