3. 规则模型与语法：规则的基本组成与常用语法
在低延迟风控规则引擎中，规则是决策的核心载体。一条规则的本质是“当某些条件成立时，执行特定动作”。本章将拆解规则的基本组成要素，并介绍三种最常用的规则语法模式：if-then、决策表和评分卡。理解这些基础模型，是构建高性能、可维护风控策略的前提。
3.1 规则的基本组成
任何一条风控规则，无论其复杂度如何，都包含三个核心要素：条件（Condition）、动作（Action）和优先级（Priority）。
| 要素 | 定义 | 低延迟设计要点 |
|---|---|---|
| 条件（Condition） | 对输入事实（如用户年龄、交易金额、IP 归属地）进行布尔逻辑判断的表达式。 | 使用短路求值、索引化条件字段，避免重复计算。 |
| 动作（Action） | 条件满足时执行的操作，如“拒绝交易”、“标记为高风险”、“输出风险分数”。 | 动作应幂等、轻量，避免在动作中发起阻塞式 I/O。 |
| 优先级（Priority） | 规则在规则集中的执行顺序，通常用整数表示（数值越小优先级越高）。 | 采用静态排序 + 冲突消解策略，避免运行时动态重排序。 |
低延迟实践： 在规则编译阶段，将优先级直接编码为规则在内存中的线性执行顺序，避免在推理时进行优先级比较或排序操作。
3.2 常用规则语法
3.2.1 if-then 规则
if-then 是最基础、最直观的规则形式，适用于单条件或简单多条件组合的场景。其结构清晰，易于理解和调试。
// 示例：高风险交易拦截规则
rule "HighRiskTransaction"
when
$tx : Transaction( amount > 10000 && countryCode == "X" )
$user : User( riskLevel == "HIGH" )
then
$tx.setDecision("REJECT");
$tx.setReason("高风险交易：金额超限且用户高风险");
update($tx);
end
性能关键点： 在低延迟引擎中，if-then 规则的条件部分应尽量使用 索引字段（如金额、用户等级），避免在条件中调用外部服务或执行复杂计算。条件中的逻辑运算符优先级应明确，减少括号嵌套深度。
3.2.2 决策表
决策表（Decision Table）是处理多条件、多组合场景的利器。它将多个 if-then 规则压缩为一张表格，通过行列交叉的方式定义不同条件组合下的动作。决策表在风控中常用于“规则矩阵”或“额度策略”场景。
| 用户等级 | 交易金额 | 设备可信度 | 决策动作 |
|---|---|---|---|
| LOW | < 1000 | HIGH | PASS |
| LOW | >= 1000 | HIGH | REVIEW |
| HIGH | < 5000 | LOW | REJECT |
| HIGH | >= 5000 | ANY | REJECT |
低延迟陷阱： 决策表在运行时通常被编译为 决策树 或 哈希映射。如果决策表行数过多（如超过 100 行），线性扫描会导致延迟飙升。建议将决策表拆分为多个小表，或使用索引化查找。
3.2.3 评分卡
评分卡（Scorecard）是一种特殊的规则模型，它将多个条件映射为分数，最终通过总分来决定动作。评分卡在信用评估、欺诈评分中广泛应用，其核心优势在于可解释性强。
// 评分卡示例：交易风险评分
scorecard "TransactionRiskScore"
// 基础分
baseScore: 50
// 特征分片
when amount > 10000 then addScore: 30
when amount > 5000 && amount <= 10000 then addScore: 15
when countryCode == "X" then addScore: 25
when deviceAgeInDays < 7 then addScore: 20
when userAge < 18 then addScore: 40
// 总分阈值动作
if totalScore >= 100 then decision: "REJECT"
if totalScore >= 60 && totalScore < 100 then decision: "REVIEW"
if totalScore < 60 then decision: "PASS"
end
低延迟优化： 评分卡中的分数累加操作应使用 整数运算 而非浮点数，避免精度损失和性能开销。同时，将评分卡编译为 线性扫描 + 提前终止 的指令序列，当总分已超过拒绝阈值时，可跳过后续评分项。
3.3 规则模型对比与选型
| 模型 | 适用场景 | 可维护性 | 低延迟性能 | 可解释性 |
|---|---|---|---|---|
| if-then | 简单策略、快速拦截 | 高（单条规则独立） | 高（直接编译为条件跳转） | 高 |
| 决策表 | 多条件组合、规则矩阵 | 中（表格化，易于审查） | 中（需编译为决策树） | 高 |
| 评分卡 | 信用评分、欺诈评分 | 中（分数调整需谨慎） | 高（线性累加，可向量化） | 极高（分数贡献清晰） |
3.4 规则语法设计原则
- 原子性： 每条规则只做一件事，避免在一条规则中混合多个不相关的条件与动作。
- 无状态性： 规则的条件和动作不应依赖引擎内部状态，确保规则可重复执行且结果一致。
- 可测试性： 每条规则应能独立测试，输入输出明确，便于单元测试和回归验证。
- 低延迟友好： 避免在规则条件中使用正则表达式、循环、递归或外部调用；优先使用整数比较、位运算和哈希查找。
实战建议： 在风控规则引擎中，建议将 高频拦截规则（如黑名单、金额超限）设计为 if-then 形式并放在规则集最前面；将 复杂评分规则 设计为评分卡；将 多维度组合策略 设计为决策表。三种模型可以混合使用，通过规则优先级控制执行顺序。