4. Decision Table基础

在授信决策系统中，业务规则往往不是单一条件判断，而是多个条件维度交叉作用的结果。Decision Table（决策表）正是把这类“多条件—多动作”逻辑用二维表格显式表达出来的工具。它的核心价值在于：让业务人员、产品经理和开发人员在同一张表上对齐规则，减少口头描述带来的歧义。

一、Decision Table的定义与核心构成

Decision Table是一种以表格形式描述条件组合与对应动作的决策建模方法。它通常由四个象限组成：条件桩、条件项、动作桩、动作项。条件桩列出所有需要判断的维度；条件项给出每个维度可能的取值；动作桩列出系统可执行的动作；动作项则标记在特定条件组合下应执行哪些动作。

一个标准的决策表可以抽象为以下结构：

| 条件/动作       | 规则1 | 规则2 | 规则3 | 规则4 |
|----------------|-------|-------|-------|-------|
| 条件1：征信评分 | 高    | 高    | 低    | 低    |
| 条件2：负债率   | 低    | 高    | 低    | 高    |
| 动作1：自动通过 | 是    | 否    | 否    | 否    |
| 动作2：人工复核 | 否    | 是    | 是    | 是    |
| 动作3：拒绝     | 否    | 否    | 否    | 是    |

这张表清晰表达了四条规则：征信高且负债低则自动通过；征信高但负债高则人工复核；征信低且负债低也人工复核；征信低且负债高则拒绝。相比一长串if-else描述，决策表在规则数量和条件维度增加时，可读性和可维护性明显更高。

二、条件与动作：决策表的两个基本维度

条件（Condition）是决策的输入维度，通常来自授信申请数据、征信报告、内部黑名单、行为评分等。条件可以是布尔型（是/否）、枚举型（高/中/低）、区间型（如负债率0-30%、30-60%、60%以上）。动作（Action）是决策的输出结果，如自动通过、转人工、拒绝、降额、加签等。

设计决策表时，条件与动作的粒度需要匹配业务决策的精度。条件过粗会导致规则区分度不足；条件过细则规则数量爆炸。一个实用原则是：每个条件维度应直接对应一个可获取、可验证的数据字段，每个动作应是一个明确、可执行、可审计的系统行为。

三、规则组合：从有限条件到完整决策空间

决策表的规则组合方式决定了它能否覆盖所有业务场景。常见组合策略有三种：

• 全组合：每个条件的每个取值都与其他条件的所有取值组合，规则数等于各条件取值数的乘积。适合条件少、取值少的场景，覆盖完整但规则数量增长快。
• 受限组合：只对业务上有意义的组合生成规则，无意义组合标记为“不适用”或“不可能”。适合条件维度较多但实际有效组合有限的场景。
• 优先级组合：为规则设置优先级，当多个规则同时命中时按优先级执行。适合存在兜底规则和例外规则的授信场景。

在授信决策中，推荐采用“受限组合+优先级”的混合策略。例如，黑名单命中应具有最高优先级，直接拒绝；其次是征信严重逾期；最后才是评分和负债率的综合判断。这样既能控制规则数量，又能保证关键风险规则不被覆盖。

四、Decision Table与决策树的异同

决策表和决策树都是结构化决策工具，但表达方式和适用场景有明显差异。下表从多个维度进行对比：

简单来说，决策表更适合“条件同时作用、动作由组合决定”的场景；决策树更适合“条件逐层筛选、路径决定结果”的场景。在实际系统中，两者常结合使用：先用决策树做粗筛和分流，再用决策表做精细化的授信审批。

五、适用场景与常见误区

Decision Table在授信领域的典型适用场景包括：授信审批矩阵（征信等级×负债率×收入水平→通过/复核/拒绝）、额度定价表（风险等级×客户分层→利率/额度）、贷后预警策略（逾期天数×历史还款行为→催收动作）。这些场景的共同特征是：条件维度明确、动作集合有限、规则需要业务人员参与评审。

复盘建议：每次决策表上线后，统计各规则的命中率和决策分布。如果某条规则命中率极低，可能是条件设置过严或数据字段不可用；如果大量申请落入“人工复核”，说明自动决策能力不足，需要补充条件或调整阈值。决策表不是一次性设计文档，而是需要持续迭代的策略资产。