2. 基础概念
在模型评分与业务规则融合决策的实战中，术语混淆是导致方案设计偏差的首要原因。很多团队在需求评审时各说各话：算法工程师谈“分数”，风控专家谈“规则”，架构师谈“引擎”，最终交付的系统却把三者揉成一团，既无法解释，也无法迭代。本节把最核心的六个术语逐一拆开，明确它们的边界、输入输出与协作关系，为后续章节的融合设计打下共同语言。
一、核心原理：从“判断”到“决策”的分层
任何一次自动化决策，本质上都在回答一个问题：“对当前这个对象，应该采取什么动作？”这个问题的答案由两类知识共同支撑：一类是从历史数据中归纳出的概率性判断，另一类是业务专家沉淀的确定性约束。模型评分负责前者，业务规则负责后者，决策引擎负责把两者编排成可执行的决策流。
理解这组概念的关键，是区分三个层次：信号层（模型评分、评分卡输出分数）、逻辑层（业务规则、规则集表达条件与动作）、编排层（决策引擎、策略路由控制执行顺序与分支）。信号层回答“有多大概率”，逻辑层回答“满足什么条件就做什么”，编排层回答“先算哪个、后判哪个、冲突时听谁的”。三层职责不清，系统就会退化成“一堆 if-else 里塞了个模型”。
一句话记忆：评分卡是模型评分的一种可解释实现形式；规则集是业务规则的组织容器；策略路由是决策引擎中决定“走哪条路”的调度逻辑。
二、方法流程：六个术语的输入输出与协作
下面按一次典型决策的执行顺序，说明各术语在流程中的位置。
- 模型评分：输入特征向量，输出一个连续分数或概率值。例如信用评分模型输出 300～850 的分数，反欺诈模型输出 0～1 的风险概率。它是“原材料”，本身不直接产生动作。
- 评分卡：模型评分的一种工程化实现，通常由若干评分项加权求和得到总分。评分卡强调可解释、可审计，每个评分项对应明确的业务含义和分值区间。
- 业务规则：形如“如果 年龄 < 18 则 拒绝”的原子判断。它由条件（condition）和动作（action）组成，是业务约束的最小表达单元。
- 规则集：把同一主题或同一决策阶段的多条业务规则组织在一起，并定义命中策略（如“任一命中即触发”或“全部命中才触发”）。规则集是规则的管理单元。
- 策略路由：根据前置结果决定后续走哪条分支。例如“若模型评分 > 700 则走快速通过路由；若 500～700 则走人工复核路由；若 < 500 则走拒绝路由”。
- 决策引擎：承载以上所有元素的运行时容器，负责加载规则集、调用模型评分、执行策略路由，并输出最终决策结果与解释信息。
这六个术语的协作关系可以用一个简化的执行链表示：
输入请求
→ 决策引擎加载策略
→ 调用模型评分（或评分卡）得到分数
→ 策略路由根据分数选择规则集
→ 规则集逐条匹配业务规则
→ 汇总命中结果，输出决策动作 + 原因码
三、案例/场景：信贷审批中的术语落地
假设一个消费信贷审批场景，申请人的模型评分为 620，我们来看各术语如何具体出现。
| 术语 | 在本场景中的具体形态 | 输入 | 输出 |
|---|---|---|---|
| 模型评分 | 信用风险模型输出 620 分 | 征信、收入、负债等特征 | 连续分数 620 |
| 评分卡 | 年龄、收入、历史逾期三项加权得分 | 三项原始字段 | 总分及各项分值 |
| 业务规则 | “近 6 个月逾期次数 ≥ 3 则拒绝” | 逾期次数 | 命中/未命中 |
| 规则集 | “高风险拒绝规则集”含 8 条规则 | 多条规则条件 | 是否触发拒绝 |
| 策略路由 | 620 分落入 500～700 区间，路由至人工复核 | 模型评分 | 路由目标 |
| 决策引擎 | 执行上述全部步骤并返回结果 | 申请请求 | 决策 + 原因码 |
在这个案例中，模型评分给出了“620 分”这个信号，策略路由据此选择“人工复核”分支，规则集在人工复核前先执行硬性拒绝规则。如果某条业务规则命中，则直接拒绝，不再进入人工复核。这就是典型的“规则优先、模型辅助”的融合模式。
四、误区/复盘：最容易混淆的三组概念
误区一：把模型评分等同于决策结果。模型评分只是概率或分数，不是动作。把分数直接当决策用，会导致阈值拍脑袋、无法解释拒绝原因。正确做法是让评分进入策略路由，由规则集决定动作。
误区二：把规则集等同于决策引擎。规则集只是规则的集合，没有执行能力；决策引擎才负责调度、计算和输出。把规则集当引擎用，会导致规则之间无法共享上下文、无法调用模型。
误区三：把评分卡等同于模型评分。评分卡是模型评分的一种实现方式，但模型评分还包括机器学习模型、深度学习模型等。评分卡强调可解释性，机器学习模型可能精度更高但解释成本更大。二者是包含关系，不是等同关系。
复盘这些误区的根源，在于没有区分“信号”与“动作”。模型评分和评分卡输出的是信号，业务规则和规则集输出的是动作，策略路由和决策引擎负责把信号转化为动作。只要在团队内统一这个分层认知，后续的融合设计、规则优先级、冲突消解就有了共同的讨论基础。
建议在项目启动时，用一张“术语对照表”让业务方、算法方和工程方各自填写对同一术语的理解，现场对齐差异。这比事后争论“为什么规则没生效”要高效得多。
五、术语速查清单
- 模型评分：模型输出的连续分数或概率，是决策的输入信号。
- 评分卡：可解释的评分模型实现，由评分项加权求和。
- 业务规则：条件 + 动作的原子判断单元。
- 规则集：多条业务规则的组织容器，定义命中策略。
- 策略路由：根据前置结果选择后续分支的调度逻辑。
- 决策引擎：加载规则、调用模型、执行路由并输出决策的运行时容器。
掌握这六个术语的边界与协作关系，是后续学习“模型评分与业务规则如何融合”“冲突如何消解”“决策如何可解释”的前提。在下一部分内容中，我们将进入融合模式的具体设计，但在此之前，请确保团队对上述术语的理解已经对齐。