3. 决策引擎架构
在授信决策引擎的设计中，架构决定了系统的可维护性、可扩展性与决策一致性。很多团队在初期把“规则”和“评分卡”混在一起实现，导致后期策略迭代困难、责任边界模糊。本节从核心模块划分入手，梳理数据流走向，并重点厘清规则引擎与评分卡引擎在架构中的不同定位。
一、核心模块划分
一个可落地的授信决策引擎，通常由以下核心模块构成。每个模块承担明确职责，避免逻辑交叉。
- 接入网关：负责API鉴权、限流、请求参数校验与协议转换，是外部调用方进入决策引擎的唯一入口。
- 决策编排器：控制整个决策流程的执行顺序，决定先查什么数据、再跑什么规则、最后如何汇总结果。
- 数据适配层：对接征信、反欺诈、内部黑名单、三方数据源，统一数据格式并处理超时与降级。
- 规则引擎：执行布尔逻辑判断，输出“通过/拒绝/转人工”等离散结论。
- 评分卡引擎：执行评分模型计算，输出连续分数或概率值。
- 决策汇总器：综合规则结果与评分结果，按策略矩阵生成最终授信结论与额度建议。
- 决策日志与审计：记录每次决策的输入、中间结果、命中规则与最终输出，满足合规与回溯要求。
核心原则：规则引擎做“是非判断”，评分卡引擎做“程度量化”，决策汇总器做“综合裁决”。三者职责不可互相替代。
二、数据流走向
一次典型的授信决策请求，数据流按以下顺序推进：
- 外部系统通过API提交授信申请，网关完成鉴权与参数校验。
- 决策编排器根据产品类型与场景，加载对应的决策流配置。
- 数据适配层并行调用所需数据源，返回结构化特征数据。
- 规则引擎基于特征数据执行硬规则与软规则，输出规则命中结果。
- 评分卡引擎基于特征数据计算评分，输出分数与风险等级。
- 决策汇总器结合规则结果与评分结果，按策略矩阵输出最终决策。
- 决策日志模块持久化全链路数据，供审计与模型迭代使用。
下面是一个简化的决策流配置示例，展示了规则与评分卡的编排关系：
{
"flowId": "credit_decision_v3",
"steps": [
{"type": "data", "name": "loadFeatures", "sources": ["internal", "credit_bureau"]},
{"type": "rule", "name": "hardRejectRules", "onHit": "reject"},
{"type": "scorecard", "name": "riskScoreA", "output": "scoreA"},
{"type": "scorecard", "name": "riskScoreB", "output": "scoreB"},
{"type": "rule", "name": "softPolicyRules", "dependsOn": ["scoreA", "scoreB"]},
{"type": "decision", "name": "finalDecision", "strategy": "matrix_v2"}
]
}三、规则引擎与评分卡引擎的定位差异
这是架构设计中最容易混淆的部分。两者虽然都基于数据做判断，但在输入、输出、可解释性和迭代方式上存在本质差异。
| 维度 | 规则引擎 | 评分卡引擎 |
|---|---|---|
| 输出类型 | 离散结论（通过/拒绝/转人工） | 连续分数或概率值 |
| 典型逻辑 | IF-THEN 布尔判断 | 加权求和、WOE转换、Logistic回归 |
| 可解释性 | 强，可精确到命中哪条规则 | 中，可解释到特征贡献度 |
| 迭代频率 | 高，策略调整可日级上线 | 低，模型重训通常周级或月级 |
| 维护角色 | 策略运营、风控策略师 | 数据科学家、模型工程师 |
| 典型场景 | 黑名单拦截、年龄准入、反欺诈硬规则 | 信用风险排序、额度定价、通过率预估 |
规则引擎适合处理“一票否决”或“监管硬性要求”的场景；评分卡引擎适合处理“风险排序”和“精细化定价”的场景。两者配合使用，才能兼顾合规性与风险区分度。
四、案例与常见误区复盘
某消费金融平台在初期将评分卡逻辑直接写入规则引擎，用大量IF-THEN模拟加权求和。结果当模型需要调整权重时，策略人员必须逐条修改规则，不仅效率低，还容易引入人为错误。后来将评分卡独立为引擎模块，规则引擎只负责硬规则与策略路由，迭代效率提升明显。
常见误区包括：
- 用规则引擎替代评分卡：导致规则数量膨胀，维护成本急剧上升，且无法输出连续风险分数。
- 用评分卡替代规则引擎：导致硬性合规要求无法刚性执行，例如年龄不符、黑名单命中仍可能被评分“稀释”。
- 决策汇总逻辑缺失：规则和评分各自输出，但没有统一的策略矩阵做最终裁决，导致结论冲突。
- 忽略决策日志：上线后无法回溯某笔申请为何被拒，合规审计与模型迭代都受阻。
架构设计时务必明确：规则引擎与评分卡引擎是并列的执行单元，不是替代关系。决策编排器负责调度，决策汇总器负责裁决，三者缺一不可。
总结来看，授信决策引擎的架构质量，取决于是否清晰划分了规则引擎与评分卡引擎的边界，是否建立了统一的数据流与决策汇总机制。只有在架构层面把“判断”与“量化”分开，才能让策略迭代与模型迭代各自独立、互不干扰，最终支撑起稳定、可解释、可审计的授信决策服务。