# 规则引擎系统介绍

> 风控规则引擎（决策引擎）的方案说明：它和决策流、变量平台、模型平台怎么分工，规则怎么表达与执行，如何做灰度、回测、解释与治理，以及自研与开源的取舍。本文只讲方案与设计，不含实现代码。

## 一、它是什么，解决什么问题

### 1.1 定义与边界

规则引擎是**把「业务判断」从代码里抽出来、变成可配置、可热更新、可审计的资产**的一套系统。在风控里，它通常和三个概念一起出现，边界要分清：

| 概念 | 回答的问题 | 典型形态 |
| --- | --- | --- |
| 规则引擎（Rule Engine） | 单条/一组判断怎么算 | 表达式求值、决策表、规则集 |
| 决策引擎（Decision Engine） | 一次决策按什么顺序走 | 决策流：变量 → 规则 → 模型 → 分支 → 结果 |
| 规则管理（Rule Management） | 谁改的、能不能上、出问题怎么退 | 版本、审批、灰度、回滚、审计 |
| 工作流（Workflow） | 人工环节怎么流转 | 工单、审批、复核 |

风控里说的「规则引擎」，多数时候指的是前两者合体：**一套可编排、可热更新、带命中轨迹的决策执行系统**。

### 1.2 没有规则引擎时的痛点

| 痛点 | 表现 | 后果 |
| --- | --- | --- |
| 规则写死在代码里 | 改一个阈值要发版 | 响应从「小时」变「周」 |
| 策略与研发强耦合 | 策略同学只能提需求 | 迭代慢、责任不清 |
| 逻辑散落各处 | 准入在 A 服务、反欺诈在 B 服务 | 无法整体回测，冲突无人知 |
| 不可解释 | 只返回「拒绝」 | 客诉与监管无法答复 |
| 变更不可追溯 | 谁改的、改前是什么没人知道 | 出事故无法定位、无法回滚 |
| 无法灰度 | 只能一刀切上线 | 一次错误规则误杀大批客户 |

### 1.3 核心能力目标

- **快**：策略改动当天生效，无需发版。
- **准**：规则语义明确、无歧义、可回测验证。
- **可解释**：每次决策能回答「命中了哪条规则、依据哪些变量、当时取值多少」。
- **可管**：版本、审批、灰度、回滚、审计全链路留痕。
- **可控**：单次决策耗时有预算，异常能降级，不会拖垮主流程。

## 二、能力全景

| 层次 | 关键能力 | 主要产出 |
| --- | --- | --- |
| 接入层 | HTTP/gRPC/SDK、消息消费、批量接口、离线回放 | 统一的决策入口 |
| 编排层 | 决策流、分支、并行、子流程、节点编排 | 决策流定义 |
| 表达层 | 表达式、决策表、决策树、脚本、DMN | 规则资产 |
| 执行层 | 编译、缓存、求值、短路、超时、降级 | 决策结果 + 命中轨迹 |
| 取数层 | 变量/特征服务、名单、三方、模型评分 | 决策所需数据 |
| 治理层 | 版本、审批、灰度、回滚、权限、审计 | 变更记录 |
| 观测层 | 命中率、拒绝率、耗时、异常、规则贡献 | 监控大盘 |

### 2.1 规则的五种表达形态

| 形态 | 说明 | 适合谁 | 优点 | 局限 |
| --- | --- | --- | --- | --- |
| 表达式 | `score < 600 && multiLoan >= 3` 这类布尔表达式 | 策略、研发 | 直观、轻量、性能好 | 复杂逻辑难维护 |
| 决策表 | 行=条件组合，列=结论（Excel/DMN 表格） | 策略、业务 | 一眼看全、易评审 | 组合爆炸时难读 |
| 决策树 | 分层条件 + 叶子结论 | 策略 | 结构清晰、可解释 | 深树难维护 |
| 脚本 | Groovy/JS 沙箱脚本 | 研发 | 表达力最强 | 难治理、有安全风险 |
| DSL（JSON/YAML） | 结构化描述规则与流程 | 平台 | 可校验、可版本化、跨语言 | 需要设计与工具链 |

实践中最常见的是**表达式 + 决策表为主，脚本兜底，DSL 做载体**。

### 2.2 决策流编排

一次决策通常不是一条规则，而是一张流程图。节点类型大致如下：

| 节点 | 作用 | 注意点 |
| --- | --- | --- |
| 变量节点 | 批量取特征/名单/三方数据 | 并行取数、超时兜底 |
| 规则集 | 一组规则按策略求值（全部执行/命中即停/加权打分） | 短路策略要明确 |
| 决策表 | 多维条件映射到结论 | 命中多条时的优先级 |
| 评分卡 | 线性加权打分、分段映射 | 分箱与分值的版本管理 |
| 模型节点 | 调用模型服务（PMML/ONNX/在线 API） | 超时、降级、冠军挑战者 |
| 分支节点 | 按结果分流（通过/拒绝/转人工/加强核验） | 分支要可回放 |
| 并行节点 | 多条链路同时跑再汇总 | 结果合并规则要定义 |
| 子流程 | 复用公共决策片段 | 避免循环调用 |
| 人工/异步节点 | 转人工复核、异步补充材料 | 与主链路解耦 |

### 2.3 与变量平台的关系

规则引擎**不负责算变量**，只负责「拿变量做判断」。变量由特征变量平台算好，规则里引用变量名即可。两者边界：

- 变量平台：口径、窗口、回溯、在线离线一致；
- 规则引擎：组合、阈值、优先级、决策流、命中轨迹。

把聚合计算写进规则表达式（如 `count(orders, 30d) > 5`）看似方便，实际会让规则无法复用、无法回溯、性能不可控——这是最常见的架构错误之一。

### 2.4 模型与评分的接入

- **评分卡**：本质是加权求和 + 分段映射，可以作为规则引擎的内置节点，也可以放在变量平台算。
- **机器学习模型**：以服务形式调用（PMML/ONNX/自研 API），返回分数与阈值判断。
- **冠军挑战者**：同一流量同时跑主模型与候选模型，只记录不决策，对比效果后切换。
- **模型兜底**：模型超时或异常时，规则给出保守结论（拒绝/转人工），而不是直接放行。

### 2.5 执行结果与轨迹

一次决策至少应返回：**决策结论**（通过/拒绝/转人工/调额）、**决策码**（可枚举的原因码）、**命中规则列表**（含版本）、**变量快照**（当时取值）、**耗时分解**（取数/规则/模型各多少毫秒）。没有轨迹，就没有复盘、没有客诉答复、没有模型迭代依据。

## 三、技术实现路线

### 3.1 表达式解释型

用成熟的表达式引擎求值，规则以字符串或结构化表达式存储。

| 引擎 | 语言/生态 | 特点 | 风险 |
| --- | --- | --- | --- |
| AviatorScript | Java | 轻量、编译成字节码、性能好 | 生态小、复杂逻辑表达弱 |
| QLExpress | Java（阿里） | 语法友好、支持宏与函数 | 版本兼容与沙箱配置 |
| MVEL / SpEL | Java | 与 Spring 集成好 | 性能一般、沙箱需加固 |
| CEL | 多语言（Google） | 类型安全、无副作用、可静态校验 | 生态偏新、函数库有限 |
| 自研 AST | 任意 | 完全可控、可静态分析 | 建设成本高 |

优点：接入快、单条规则性能好、容易做热更新。缺点：**规则之间的组合关系要靠上层编排**，复杂的多条件优先级容易失控。

### 3.2 生产式规则引擎（RETE 类）

代表是 Drools。核心思想是把规则编译成网络，增量匹配事实（fact），适合「几百条规则、事实频繁变化」的场景。

- 优点：规则多时匹配效率高、支持推理链（一条规则结论触发另一条）、生态成熟。
- 缺点：**重**，学习曲线陡（DRL 语法、KIE 体系）；内存占用高；热更新与多版本管理复杂；排查问题时「为什么这条规则命中了」不直观。
- 适合：规则数量大、需要推理、团队有 Java 平台能力的机构。

### 3.3 脚本引擎（沙箱）

Groovy / JavaScript（GraalJS）等，给研发最大自由度。

- 优点：复杂逻辑、循环、外部函数调用都能写。
- 缺点：**不可静态分析**（冲突检测、覆盖率分析做不了）、有安全风险、性能不稳定、策略同学改不动。
- 使用原则：只作为「平台算子覆盖不了」的兜底，且必须沙箱（禁 IO、禁反射、限时限额）。

### 3.4 DSL + 解释器（自研）

用 JSON/YAML 描述规则与流程，自研执行器。风控领域最主流的自研形态。

```json
{
  "ruleSet": "anti_fraud_v3",
  "rules": [
    {
      "id": "AF001",
      "when": { "all": [
        { "var": "device.share_cnt_7d", "op": ">=", "value": 5 },
        { "var": "apply.cnt_1h", "op": ">=", "value": 3 }
      ] },
      "then": { "decision": "REJECT", "code": "AF001_DEVICE_FARM", "weight": 40 }
    }
  ],
  "strategy": "all_match"
}
```

- 优点：可校验（结构/类型/引用完整性）、可静态分析（冲突、死规则、覆盖率）、跨语言、可版本化、天然适合低代码编辑器。
- 缺点：前期要设计语法与执行器；表达力受限于设计（复杂算法仍需算子扩展）。
- 适合：策略同学自助配置、规则量大、需要强治理的场景。

### 3.5 决策表与 DMN

以表格表达「条件组合 → 结论」，是业务评审最友好的形式。DMN（Decision Model and Notation）是国际标准，定义了决策表、FEEL 表达式与决策依赖图，适合跨团队对齐与工具互通。

| 场景 | 示例 |
| --- | --- |
| 额度定价 | 收入区间 × 负债率区间 × 征信等级 → 额度系数 |
| 风险分级 | 逾期次数 × 逾期天数 → 风险等级 |
| 渠道策略 | 渠道 × 客群 × 产品 → 是否转人工 |

注意点：命中多行时的**优先级与冲突**必须显式定义（首次命中 / 全部命中取最严 / 加权求和），否则同一输入可能得出两个结论。

### 3.6 流式规则（CEP）

针对「一段时间内的事件模式」，如「5 分钟内 3 次失败登录后成功」「同一设备 1 小时内申请 10 次」。依赖 Flink CEP 或流式规则引擎，特点是有状态、按事件时间窗口。适合交易反欺诈与实时监控，但状态管理与补数复杂度高。

### 3.7 路线对比

| 路线 | 单次性能 | 规则规模 | 热更新 | 可解释/可治理 | 建设成本 | 适用 |
| --- | --- | --- | --- | --- | --- | --- |
| 表达式解释型 | 高 | 小—中 | 易 | 中 | 低 | 规则少、结构简单 |
| RETE（Drools） | 中（规则多时优） | 大 | 较难 | 中 | 中高 | 规则多、需推理 |
| 脚本沙箱 | 不稳定 | 任意 | 易 | 低 | 低 | 兜底、复杂逻辑 |
| 自研 DSL | 高 | 大 | 易 | 高 | 高 | 平台化、策略自助 |
| 决策表/DMN | 高 | 中 | 易 | 高 | 低—中 | 多维组合、业务评审 |
| 流式 CEP | 取决于窗口 | 中 | 中 | 中 | 高 | 事件模式、实时反欺诈 |

## 四、架构与运行时

### 4.1 分层架构

```text
接入层    HTTP / gRPC / SDK / 消息 / 批量
   ↓
编排层    决策流引擎（分支、并行、子流程）
   ↓
表达层    规则集 / 决策表 / 评分卡 / 模型 / 名单
   ↓
执行层    编译缓存 → 求值 → 短路 → 超时 → 降级
   ↓
取数层    变量平台 / 名单 / 三方 / 模型服务
   ↓
治理与观测  版本、审批、灰度、审计、指标
```

### 4.2 一次决策的执行链路

1. 接入层鉴权、限流、参数校验，生成 traceId；
2. 编排层加载当前生效版本的决策流（本地缓存 + 版本号）；
3. 变量节点并行取数（一次批量请求取回所需全部变量）；
4. 规则节点按顺序求值，命中即记录轨迹，按策略短路或全量执行；
5. 模型节点调用模型服务（带超时与降级）；
6. 汇总结论，生成决策码与命中列表，写决策日志（异步）；
7. 返回结果，整链路耗时控制在预算内。

### 4.3 性能设计

| 手段 | 作用 |
| --- | --- |
| 规则预编译 | 表达式编译成字节码/AST 缓存，避免每次解析 |
| 版本常驻内存 | 生效版本整体加载，热更新原子切换 |
| 变量懒加载 | 仅取本次分支真正用到的变量（需静态分析支持） |
| 并行取数 | 变量、名单、模型并行发起，按最慢的等 |
| 短路求值 | 命中拒绝立即结束，不再算后续 |
| 超时预算 | 每个节点设预算，超时走降级分支 |
| 无状态执行 | 在线决策不做跨请求状态，便于水平扩容 |

### 4.4 高可用与降级

- **多副本无状态**：任意实例可处理任意请求；
- **本地缓存 + 版本校验**：治理中心不可用不影响在线决策；
- **降级策略分级**：变量取不到 → 使用默认值并打标；模型超时 → 规则保守结论；决策流异常 → 兜底流程（宁可拒绝或转人工，不可默认放行）；
- **演练**：定期做「治理中心宕机」「变量平台超时」的故障演练。

### 4.5 热更新与版本

规则变更不应重启服务。常见做法：治理中心发布新版本 → 推送版本号 → 实例拉取并原子替换内存中的规则快照 → 新请求用新版本，存量请求用旧版本跑完。每次决策日志记录**规则版本号**，保证事后可复现。

## 五、治理与运营（最容易被忽略）

### 5.1 规则生命周期

`草稿 → 单测通过 → 场景集回归 → 审核 → 灰度 → 全量 → 下线`，每一步留痕。审核不只是流程，要能看到**规则 diff、影响面（哪些产品/渠道在用）、回测结果**。

### 5.2 测试与回测

| 类型 | 做法 | 目的 |
| --- | --- | --- |
| 单规则单测 | 构造边界输入验证真假 | 防止表达式写错 |
| 场景集回归 | 维护一批「已知结论」的样本 | 防止改一条影响一片 |
| 历史回放 | 取历史决策请求重跑新版本 | 看通过率/拒绝率变化 |
| 影子双跑 | 新版本只计算不决策，记录差异 | 上线前最后一道闸 |
| 沙盘模拟 | 用假设分布跑规则 | 评估极端场景 |

### 5.3 灰度与回滚

- **分桶**：按客户号哈希 / 渠道 / 产品维度切流量；
- **影子模式**：新版本并行计算，只记录不生效；
- **逐步放量**：1% → 10% → 50% → 100%，每档观察拒绝率、误杀率、客诉；
- **一键回滚**：保留上一版本，秒级切回；
- **熔断**：异常率超阈值自动回退旧版本。

### 5.4 规则质量治理

| 问题 | 检测方式 |
| --- | --- |
| 规则冲突 | 静态分析条件重叠且结论相反 |
| 死规则 | 长期命中率为 0（被前置规则完全遮蔽或条件不可达） |
| 覆盖漏洞 | 某些输入组合无任何规则命中 |
| 复杂度失控 | 单规则条件数、规则集规模设上限 |
| 阈值漂移 | 命中的变量分布随时间变化，规则效果衰减 |
| 重复规则 | 语义相同但 ID 不同 |

### 5.5 可解释与审计

- **决策轨迹**：每个节点的输入、输出、耗时、命中与否；
- **变量快照**：决策时点的取值，含数据来源与版本；
- **原因码**：可枚举、可对外解释，避免「系统判定」这类模糊表述；
- **审计**：谁在什么时候改了哪条规则、审批人是谁、规则版本与生效区间。

### 5.6 权限与合规

- 编辑、审核、发布三权分立（至少编辑与发布分离）；
- 生产环境只允许通过发布流程变更，禁止直接改库；
- 敏感规则（拒绝、限额）单独审批；
- 满足监管对「自动化决策可解释、可申诉」的要求。

## 六、风控场景落地

| 场景 | 典型决策流 | 规则示例 |
| --- | --- | --- |
| 贷前准入 | 变量 → 黑名单 → 反欺诈规则 → 评分卡 → 模型 → 额度 | 命中黑名单直接拒绝；多头 ≥ 5 且近 1 小时申请 ≥ 3 转人工 |
| 反欺诈 | 设备/关系/行为变量 → 规则集 → 加强核验 | 同设备关联 ≥ 5 个申请 → 拒绝并打团伙标 |
| 额度定价 | 评分 → 决策表 → 额度系数 | 收入段 × 负债率 × 征信等级 → 系数 |
| 贷中预警 | 定时批量 → 规则集 → 预警工单 | 额度使用率 > 90% 且还款延迟 2 次 → 降额预警 |
| 贷后催收 | 逾期天数 → 分案决策表 | 逾期 1—7 天 → 短信；> 30 天 → 委外 |
| 名单管理 | 名单命中 → 分支 | 灰名单 → 加强核验；白名单 → 跳过部分规则 |

一条完整链路的示意：

```text
请求 → 校验 → [变量节点: 身份/设备/多头/征信]
     → [反欺诈规则集: AF001..AF012]  命中失败 → 拒绝(AF00x)
     → [评分卡: 600 分] → [模型: PD 0.12]
     → [决策表: 额度系数] → 通过/转人工
```

## 七、规则与模型怎么分工

| 维度 | 规则 | 模型 |
| --- | --- | --- |
| 可解释性 | 强，逐条可讲 | 弱，需 SHAP 等辅助 |
| 冷启动 | 立刻可用 | 需要样本与训练 |
| 迭代速度 | 小时级 | 周—月级 |
| 覆盖能力 | 处理已知模式 | 处理未知模式 |
| 稳定性 | 确定性强 | 受分布漂移影响 |
| 监管友好度 | 高 | 中（需模型风险管理） |

常见的组合姿势：**规则做硬约束与兜底（黑名单、欺诈、监管红线）→ 模型做排序与精细化定价 → 规则做后置复核与人工分流**。两者不是替代关系，规则永远需要一层「政策与合规的确定性表达」。

## 八、常见坑与反模式

| # | 反模式 | 后果 | 规避 |
| --- | --- | --- | --- |
| 1 | 把聚合计算写进规则表达式 | 无法复用与回溯、性能不可控 | 变量交给特征平台 |
| 2 | 规则无版本、直接改生产 | 事故无法回滚 | 版本 + 审批 + 灰度 |
| 3 | 只返回结论不返回原因 | 客诉与复盘无从下手 | 决策码 + 命中轨迹 |
| 4 | 规则集无限膨胀 | 冲突、死规则、维护崩溃 | 定期治理、合并同类、设上限 |
| 5 | 决策流无超时预算 | 一个慢节点拖垮整链路 | 节点级超时 + 降级 |
| 6 | 降级时默认放行 | 风险敞口瞬间放大 | 降级走保守分支 |
| 7 | 灰度只按比例不按客群 | 高风险客群先中招 | 按客群/渠道分层灰度 |
| 8 | 用脚本写核心规则 | 不可分析、不可治理 | 脚本仅兜底 |
| 9 | 决策表命中冲突未定义 | 同输入不同结论 | 显式优先级 |
| 10 | 规则与模型口径不一 | 规则拒绝、模型通过，互相打脸 | 统一变量口径与阈值来源 |
| 11 | 没有回放能力 | 无法验证改动影响 | 历史请求可重放 |
| 12 | 业务与研发共用一个账号 | 责任不清 | 三权分立 + 审计 |

## 九、选型与落地路线

### 9.1 选型

| 情况 | 建议 |
| --- | --- |
| 规则 < 50 条、只有一个场景 | 表达式引擎 + 简单编排，别自研平台 |
| 规则多、策略同学要自助 | 自研 DSL + 可视化编辑器 + 治理 |
| Java 生态深、需要推理 | Drools，但要做好版本管理与性能压测 |
| 多维组合判断多 | 决策表 / DMN，业务评审最省事 |
| 事件模式（短时高频） | Flink CEP，独立于在线决策流 |
| 强监管、需逐条解释 | 表达式/决策表为主，模型辅助 |

### 9.2 三阶段路线

| 阶段 | 目标 | 重点动作 | 风险 |
| --- | --- | --- | --- |
| 起步 | 规则与代码解耦 | 统一决策入口、表达式化、基础日志与原因码 | 只做「配置化」，没有治理 |
| 成长 | 策略自助、可灰度 | 决策流编排、版本与审批、影子双跑、监控 | 流程变重，策略同学不愿用 |
| 成熟 | 平台化、可运营 | 规则质量分析、冲突检测、贡献度、冠军挑战者、成本与容量 | 过度设计，平台比业务跑得快 |

落地顺序建议：**先做「可解释 + 可回滚」，再做「可自助」**。没有回滚能力的热更新，比发版更危险。

## 十、趋势

- **规则与模型统一编排**：决策流里规则、评分卡、模型、名单是同级节点，由同一套版本与灰度管理。
- **策略即代码（Policy as Code）**：DSL 进 Git，走 CI、代码评审、自动化回归，规则变更与研发变更同一套工程实践。
- **实时化**：流式规则与在线决策融合，从「申请时判断」走向「事件发生时判断」。
- **智能化辅助**：用历史决策数据自动挖掘候选规则、检测冲突与冗余，LLM 辅助把自然语言策略转成 DSL（仍需人工审核）。
- **可解释与合规内建**：决策轨迹、原因码、模型解释成为默认能力，而非事后补。

## 十一、竞品与选型参考

| 产品 / 厂商 | 类型 | 优点 | 局限 |
| --- | --- | --- | --- |
| Drools | 开源规则引擎 | RETE 增量匹配、规则多时效率高、Java 生态成熟 | 体系重、DRL 学习曲线陡，热更新与多版本管理复杂 |
| Camunda（DMN / BPMN） | 开源 + 商业 | 标准规范、可视化好、流程编排能力强 | 偏业务流程，高频在线决策性能与规则治理需扩展 |
| IBM Operational Decision Manager | 商业 | 企业级规则治理成熟、稳定性好、审计完善 | 昂贵、实施依赖厂商、迭代偏重 |
| FICO Blaze Advisor | 商业 | 决策规则能力强、与评分卡结合紧密 | 闭源、成本高、国内生态与人才少 |
| 国内决策引擎（同盾、邦盛等） | 商业 | 风控场景贴合、内置变量/名单/模型节点、上线快 | 黑盒、绑定厂商、深度定制受限 |
| 自研 DSL + 编排 | 自研 | 完全可控、可静态分析、与变量平台天然打通 | 建设与维护成本高，需要长期投入 |

> 选型顺序建议：先看治理（版本/审批/灰度/回滚）与可解释，再看表达力，最后才比性能。

> **资料来源与时效**：厂商官网与公开产品文档、开源项目文档/仓库、公开技术文章与行业报告，以及行业常见实践；信息整理截至 **2026-10**，未逐一与厂商核实。产品能力、定价与版本会随迭代变化，选型前请核对官方最新资料并做 POC 验证；本节不构成选型推荐，也不含厂商商务信息。

## 十二、与其他风险系统的关系

| 系统 | 关系 | 交互内容 |
| --- | --- | --- |
| 特征变量平台 | 上游 | 决策流通过变量服务取数 |
| 名单服务 | 上游 | 实时名单命中作为硬拦截或转人工 |
| 模型平台 | 上游 | 模型节点调用评分/PD 服务 |
| 授信额度与定价 | 下游 | 输出准入结论、限额、风险等级 |
| 人工审核 | 下游 | 灰区与命中规则转人工 |
| 决策留痕 | 下游 | 命中轨迹、规则版本、耗时明细 |
| 策略分析 | 双向 | 规则命中与贡献度评估，驱动策略调优 |

## 十三、术语表

| 术语 | 含义 |
| --- | --- |
| 规则集 | 一组按策略求值的规则 |
| 决策流 | 由节点组成的决策编排图 |
| RETE | 生产式规则引擎的增量匹配算法 |
| DMN | 决策模型与标记法，含决策表与 FEEL 表达式 |
| 短路 | 命中即停止后续判断 |
| 影子模式 | 新版本只计算不生效，用于比对 |
| 冠军挑战者 | 主模型与候选模型并行比较 |
| 原因码 | 可枚举的决策原因标识 |
| 决策轨迹 | 每个节点的输入输出与命中记录 |
| CEP | 复杂事件处理，识别事件序列模式 |

---

> 规则引擎的价值不在于「能配规则」，而在于「改错了能立刻退回去、退回去还能说清楚为什么」。选型时先问治理与回滚，再问性能与生态。