2. 业务规则基础：定义、分类与表达方式
业务规则是特征工程的逻辑起点。在将业务知识转化为可计算的特征之前，必须对业务规则本身进行系统化的定义、分类和表达。本章将建立业务规则的基础框架，为后续的特征分层设计提供理论支撑。
2.1 业务规则的定义
业务规则（Business Rule）是对业务结构、行为或约束的精确陈述，它定义了业务如何运作、什么可以做、什么不可以做，以及在特定条件下应当如何决策。业务规则独立于技术实现，是业务知识的原子化表达。
核心定义：业务规则是指导业务行为、约束业务操作、推导业务结论的声明性陈述。它回答的是“业务应当如何”的问题，而非“系统如何实现”的问题。
一个完整的业务规则通常包含三个要素：
- 条件（Condition）：规则触发或适用的前提场景。
- 动作（Action）：条件满足时执行的操作或得出的结论。
- 优先级（Priority）：当多条规则同时适用时的冲突解决顺序。
| 要素 | 说明 | 示例 |
|---|---|---|
| 条件 | 规则生效的前置判断 | 用户年龄 < 18 岁 |
| 动作 | 条件满足时的业务结果 | 禁止购买含酒精商品 |
| 优先级 | 规则冲突时的裁决依据 | 风控规则优先级 > 促销规则 |
2.2 业务规则的分类
根据规则的作用方式和业务意图，业务规则可分为三大类：约束型、推导型和触发型。理解分类有助于在特征工程中确定规则的转化策略。
2.2.1 约束型规则
约束型规则定义业务操作的边界和限制条件，用于确保数据完整性、业务合规性和操作合法性。这类规则通常转化为特征工程中的过滤条件或校验特征。
- 数据约束：字段取值范围、格式要求、唯一性约束。
- 业务约束：交易限额、年龄限制、地域限制。
- 合规约束：监管要求、隐私保护规则。
特征工程视角：约束型规则通常直接映射为布尔型特征（是否满足约束）或数值型特征（与约束边界的距离）。
2.2.2 推导型规则
推导型规则基于已知事实或已有特征，通过逻辑推理或数学计算得出新的业务结论。这类规则是特征衍生和特征组合的核心来源。
- 计算推导：根据公式计算指标，如“年化利率 = 月利率 × 12”。
- 逻辑推导：根据条件组合得出结论，如“若用户等级为VIP且消费金额 > 5000，则判定为高价值用户”。
- 分类推导：将连续值映射为离散类别，如“信用评分 > 700 → 优质客户”。
2.2.3 触发型规则
触发型规则定义在特定事件或条件发生时需要自动执行的业务动作。这类规则通常转化为特征工程中的事件特征或时序特征。
- 事件触发：当某事件发生时执行动作，如“用户登录失败3次 → 锁定账号”。
- 时间触发：在特定时间点执行动作，如“每月1日 → 生成账单”。
- 状态触发：当业务状态变化时执行动作，如“订单状态变为‘已发货’ → 发送物流通知”。
| 分类 | 核心作用 | 特征转化方向 | 典型示例 |
|---|---|---|---|
| 约束型 | 定义边界与限制 | 布尔特征、校验特征 | 单笔交易限额 ≤ 10000 |
| 推导型 | 生成新结论 | 衍生特征、组合特征 | 风险等级 = f(年龄, 收入, 负债) |
| 触发型 | 驱动业务动作 | 事件特征、时序特征 | 逾期3天 → 发送催收通知 |
2.3 业务规则的表达方式
业务规则需要以清晰、无歧义的方式表达，以便业务人员、分析师和开发人员共同理解。常用的表达方式包括自然语言、决策表和决策树，三者各有适用场景。
2.3.1 自然语言表达
自然语言是最直观的表达方式，适用于规则数量较少、逻辑简单的场景。但自然语言存在歧义性，需要遵循结构化模板来降低理解偏差。
结构化模板：“如果 [条件1] 且/或 [条件2] ...，则 [动作/结论]。”
示例：
规则：如果 用户年龄 ≥ 18 且 用户身份认证通过，则 允许购买含酒精商品。
否则，拒绝购买并提示“年龄或身份不符合要求”。2.3.2 决策表表达
决策表以表格形式展示条件组合与对应动作，适合处理多条件、多结果的复杂规则集。决策表能够系统性地覆盖所有条件组合，避免遗漏。
决策表结构：
| 条件 / 规则编号 | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| C1：年龄 ≥ 18 | Y | Y | N | N |
| C2：身份认证通过 | Y | N | Y | N |
| A1：允许购买 | ✓ | ✗ | ✗ | ✗ |
| A2：提示年龄不符 | ✗ | ✗ | ✓ | ✓ |
| A3：提示身份未认证 | ✗ | ✓ | ✗ | ✓ |
使用建议：当条件数量 ≤ 5 个时，决策表最为高效；条件超过 6 个时，组合数呈指数增长，建议改用决策树或规则引擎。
2.3.3 决策树表达
决策树以树形结构展示规则的层次化判断过程，适合表达具有优先级顺序或嵌套条件的规则。决策树的每个分支代表一个条件判断，叶子节点代表最终结论。
2.4 三种表达方式的对比与选择
| 维度 | 自然语言 | 决策表 | 决策树 |
|---|---|---|---|
| 可读性 | 高（业务人员友好） | 中（需培训） | 高（直观） |
| 完整性 | 低（易遗漏） | 高（穷举组合） | 中（依赖分支设计） |
| 歧义性 | 高 | 低 | 低 |
| 适用条件数 | ≤ 3 个 | 3 ~ 5 个 | ≥ 4 个 |
| 维护成本 | 低（规则少时） | 中（组合变化需重算） | 中（分支调整影响大） |
| 特征工程适配 | 需人工解析 | 可直接映射为特征矩阵 | 可转化为规则特征 |
常见误区：不要试图用单一表达方式覆盖所有规则。实践中，建议先用自然语言与业务方确认规则意图，再用决策表或决策树进行结构化表达，最后转化为特征工程代码。三种方式应形成互补链条，而非互相替代。
2.5 从业务规则到特征工程的桥梁
业务规则的分类和表达方式直接决定了特征工程的设计策略：
- 约束型规则 → 校验特征：将规则边界转化为布尔型特征（是否违规）或距离型特征（与边界的差距）。
- 推导型规则 → 衍生特征：将规则中的计算逻辑和分类逻辑直接封装为新的特征列。
- 触发型规则 → 事件特征：将规则触发的事件频次、时间间隔、累计次数等转化为时序特征。