📚 课程目录第3章规则模型定义

3. 规则模型定义：规则的基本组成与元数据设计

规则模型是风控规则引擎在线推理的核心数据抽象。一个可执行、可维护、可追溯的规则，必须包含三个基本组成部分：条件（Condition）、动作（Action）和优先级（Priority）。在此基础上，规则元数据设计和版本管理机制决定了规则引擎在复杂业务场景下的可治理性。

3.1 规则的基本组成

每条规则在引擎内部被建模为一个结构化对象，包含以下三个核心要素：

组成要素	定义	示例
条件（Condition）	一组逻辑表达式，用于评估输入事实是否满足触发规则的要求。支持原子条件（字段比较）和复合条件（AND/OR/NOT 组合）。	`orderAmount > 5000 AND userLevel == "NEW"`
动作（Action）	条件满足时引擎执行的具体操作，包括决策输出（如拒绝、人工审核）、变量赋值、事件发送、风险标签追加等。	`decision = "REJECT"; riskTag += "HIGH_AMOUNT_NEW_USER"`
优先级（Priority）	规则在规则集中的执行顺序。数值越小优先级越高，引擎按优先级升序执行规则。同优先级规则按规则 ID 排序。	`priority = 100`（高于 `priority = 200`）

实战建议：优先级设计应预留足够的数值间隔（如 10、50、100），避免后续插入新规则时因无空位而需要全局重排。推荐使用 100 的倍数作为基础步长。

3.2 规则元数据设计

规则元数据是描述规则自身属性的结构化信息，用于规则的管理、检索、审计和监控。一个完整的规则元数据模型至少包含以下维度：

标识元数据：规则 ID（全局唯一）、规则名称、规则编码（业务可读）。
归属元数据：所属规则集 ID、业务域（如支付、登录、信贷）、场景标签。
生命周期元数据：创建时间、创建人、最后修改时间、生效时间、失效时间、规则状态（草稿/生效/失效/归档）。
治理元数据：版本号、变更描述、审批人、上线时间、回滚标记。
性能元数据：平均执行耗时（ms）、命中率、最近命中时间、异常次数。

  元数据设计原则：元数据应独立于规则的条件和动作逻辑存储，支持运行时只加载条件/动作部分以提升推理性能，元数据仅在管理端查询时全量加载。

以下是一个简化的规则元数据 JSON 结构示例：

{
  "ruleId": "RUL_20250321_001",
  "ruleName": "新用户大额交易拦截",
  "ruleCode": "NEW_USER_HIGH_AMOUNT",
  "ruleSetId": "RS_PAYMENT_001",
  "businessDomain": "payment",
  "status": "ACTIVE",
  "version": 3,
  "priority": 100,
  "effectiveTime": "2025-03-21T00:00:00Z",
  "expireTime": null,
  "createdBy": "zhangsan",
  "createdAt": "2025-03-20T10:30:00Z",
  "updatedAt": "2025-03-21T08:15:00Z",
  "description": "拦截注册7天内且单笔金额超过5000元的交易",
  "avgExecMs": 1.2,
  "hitCount": 1523
}

3.3 规则版本管理

规则版本管理是保障在线推理系统稳定性和可回溯性的关键机制。每次规则逻辑的变更都应产生一个新的版本，而非直接覆盖原有规则。版本管理需要解决以下核心问题：

版本号递增：每次规则内容（条件或动作）变更时，版本号自动 +1。元数据变更（如描述、标签）不触发版本号变更。
版本快照：每个版本保存完整的规则定义快照，包括条件表达式、动作列表、优先级和元数据。支持按版本号回溯任意历史版本。
版本状态流转：规则版本经历“编辑 → 测试 → 审核 → 上线 → 回滚”等状态，每个状态变更记录操作人和时间。
灰度发布：支持指定规则版本在特定流量比例或特定用户分桶中生效，实现平滑上线。

常见陷阱：不要将规则版本号与规则集版本号混用。规则集版本管理的是规则组合关系，规则版本管理的是单条规则内部逻辑。两者应独立维护。

下图展示了规则版本管理的完整生命周期：

3.4 规则模型与版本管理的存储设计

在在线推理系统中，规则模型和版本数据通常采用双表存储策略：

存储表	存储内容	访问模式	索引策略
规则主表	规则当前生效版本的全部定义（条件、动作、优先级、元数据）	高频读取，用于在线推理时加载	按 ruleId + status 建立唯一索引
规则版本历史表	每个版本的完整快照，包含版本号、变更内容、操作人、时间戳	低频写入，仅管理端查询时读取	按 ruleId + version 建立联合索引

性能优化：在线推理时只从规则主表加载当前生效版本的条件和动作部分，元数据中的治理字段（如变更描述、审批人）仅在管理端展示时从版本历史表按需加载，避免不必要的序列化开销。

下图展示了规则模型、元数据与版本管理之间的整体关系：

3.5 规则模型定义的最佳实践

条件与动作分离：条件只负责逻辑判断，不产生副作用；动作只负责执行决策，不包含判断逻辑。两者通过规则引擎的评估-执行两阶段解耦。
优先级预留：使用 100 的倍数作为优先级步长，预留中间数值用于后续规则插入，避免全局重排。
版本号语义化：版本号从 1 开始递增，不跳号。回滚操作不产生新版本号，而是将目标历史版本的内容复制到主表并标记当前版本号。
元数据独立存储：在线推理时只加载条件、动作和优先级，元数据仅在管理端查询时加载，减少序列化开销和内存占用。
审计链路完整：每个版本的状态变更都记录操作人、时间戳和变更原因，形成不可篡改的审计日志。