📚 课程目录第4章融合决策流核心概念

4. 融合决策流核心概念

在真实的风控、营销、授信、反欺诈等业务中，单一手段往往难以同时满足可解释、可迭代、可审计、可规模化的要求。规则系统擅长表达明确的业务底线与强约束，模型擅长从高维数据中捕捉统计规律与非线性关系。融合决策流的核心，不是把两者简单叠加，而是让它们在同一个执行框架中各司其职、按序协作、结果可追溯。

一、核心原理：规则与模型的互补性

规则与模型的差异，决定了它们必须互补而非互斥。规则是“人写出来的判断”，模型是“数据学出来的判断”。前者稳定、透明、易审计，但维护成本高、覆盖有限；后者泛化能力强、能处理复杂交互，但存在黑箱性、漂移风险和阈值调优成本。

维度	规则	模型	融合后的目标
可解释性	高，条件与动作清晰	中低，依赖特征贡献	关键拒绝可解释，边缘案例可量化
迭代方式	人工配置、审批发布	样本训练、离线评估	规则兜底，模型持续调优
覆盖能力	有限，依赖专家经验	强，可覆盖高维组合	规则守底线，模型扩覆盖
风险类型	滞后、冲突、爆炸	漂移、过拟合、不可解释	互相校验，降低系统性风险

互补性的本质是：规则提供确定性与边界，模型提供概率与排序。例如，规则可以直接拒绝“命中黑名单”的申请，而模型可以对剩余申请给出违约概率，再结合分数阈值做分层决策。

二、融合层次：从串联到深度协同

融合不是单一层次，而是从浅到深可分为四层。理解层次，才能在设计决策流时选择合适结构。

结果层融合：规则输出通过/拒绝，模型输出分数，最终由投票、加权或优先级合并。实现简单，但中间过程不可见。
特征层融合：规则命中结果作为模型输入特征，例如“是否命中设备异常规则”作为离散特征。模型能学习规则与标签的交互。
决策层融合：规则与模型各自输出决策，再由仲裁节点按业务策略合并。适合需要保留独立审计链的场景。
执行层融合：规则和模型作为决策流中的节点，按边和条件动态编排，支持分支、并行、回退与人工审核。这是工程上最常用的形态。

选择融合层次时，先问三个问题：是否需要独立审计？是否允许模型使用规则结果？是否需要在运行中动态调整路径？答案决定层次，而不是技术偏好。

三、决策流、节点、边与执行语义

融合决策流可以理解为一个有向图：节点是执行单元，边是流转路径，执行语义决定何时走哪条边、如何合并结果。常见节点类型包括：规则节点、模型节点、分流节点、合并节点、人工审核节点和动作节点。

{
  "flowId": "loan_decision_v3",
  "nodes": [
    {"id": "start", "type": "start"},
    {"id": "rule_blacklist", "type": "rule", "ruleSet": "blacklist_v2"},
    {"id": "model_score", "type": "model", "model": "risk_score_v5"},
    {"id": "merge", "type": "merge", "strategy": "priority"},
    {"id": "action_reject", "type": "action", "result": "REJECT"},
    {"id": "action_review", "type": "action", "result": "REVIEW"},
    {"id": "action_pass", "type": "action", "result": "PASS"}
  ],
  "edges": [
    {"from": "start", "to": "rule_blacklist"},
    {"from": "rule_blacklist", "to": "action_reject", "condition": "hit == true"},
    {"from": "rule_blacklist", "to": "model_score", "condition": "hit == false"},
    {"from": "model_score", "to": "merge"},
    {"from": "merge", "to": "action_review", "condition": "score >= 0.6 && score < 0.8"},
    {"from": "merge", "to": "action_pass", "condition": "score < 0.6"},
    {"from": "merge", "to": "action_reject", "condition": "score >= 0.8"}
  ]
}

执行语义需要明确三件事：顺序（串行还是并行）、条件（边上的表达式何时为真）、合并（多路结果如何汇总）。例如，优先级合并表示高优先级节点的结论覆盖低优先级；加权合并表示按权重计算综合分；投票合并表示多数一致才通过。

四、案例与场景：贷前审批融合决策流

以贷前审批为例，一个典型的融合决策流如下：先执行黑名单与反欺诈规则，命中则直接拒绝；未命中进入模型评分节点，输出违约概率；随后进入合并节点，按分数区间分流：低于0.6通过，0.6至0.8转人工复核，高于0.8拒绝。整个过程规则负责硬约束，模型负责风险排序，人工负责灰区兜底。

输入：用户申请信息 + 设备信息 + 历史行为
执行：
1. 规则节点 blacklist_v2 -> hit=true 则 REJECT
2. 模型节点 risk_score_v5 -> score
3. 合并节点 priority -> 按 score 分流
输出：
score < 0.6  -> PASS
0.6 <= score < 0.8 -> REVIEW
score >= 0.8 -> REJECT

这个案例的关键在于：规则和模型不是互相替代，而是规则先做确定性过滤，模型再做概率性排序。如果反过来，先跑模型再跑规则，黑名单用户可能因为模型分数低而被误放，造成底线失守。

五、误区与复盘

常见误区一：把规则命中结果直接作为模型标签。规则命中不等于真实坏样本，直接当标签会引入偏差。误区二：边条件写得过于复杂，导致执行路径不可预测。误区三：合并策略不明确，多个节点输出冲突时无法仲裁。误区四：忽略执行语义中的短路与并行，导致性能与一致性受损。

复盘时建议检查四点：规则是否只做底线、模型是否只做排序、边条件是否可读可测、合并策略是否可审计。一个健康的融合决策流，应该让每个节点的职责单一，让每条边的条件明确，让最终决策可以回溯到具体规则或模型分数。

掌握这些核心概念后，后续设计决策流时就不会陷入“规则和模型谁更重要”的争论，而是把注意力放在如何编排、如何合并、如何验证上。这才是融合决策流真正的工程价值。