决策引擎与规则配置：一条审批流怎么搭，才不会每次调模型都出事

决策引擎与规则配置：一条审批流怎么搭，才不会每次调模型都出事

上一篇我们搭完了评分卡。但评分卡产出的只是一个分数——它自己不会放款，也不会拒贷。真正把分数、规则、外部数据和额度策略串起来、输出”通过/拒绝/转人工”那个动作的，是决策引擎。

在海外现金贷这个场景里，决策引擎的地位被严重低估。很多团队的模型做得不错，业务却总是出问题：改一个 cut-off 要发版、模型换一版就全线回归、监管来查却拿不出半年前的拒贷理由。根因通常不在模型，而在引擎的架构。

一、第一个决定：把”决策逻辑”拆成三层

最常见的错误，是把决策逻辑做成一个大函数——读特征、跑模型、判规则、出结果，全在一个服务里。这个结构在业务量小的时候没问题，一旦开始迭代就会付出代价。

正确做法是拆成三层，层与层之间用明确的接口通信：

模型层。 只负责统计或机器学习打分，输出一个或多个分数加特征归因。它不持有任何业务规则。这一层可以用 Python 写，因为迭代速度重要、生态也在这里。

策略层（Policy）。 确定性的硬规则：监管利率上限、敞口限制、命中即拒条件、强制拒绝项。这一层是可以用穷举测试验证的代码。

路由层（Strategy）。 决定”这个产品、这个地区、这个客群该用哪个模型、哪个 cut-off”。champion/challenger 的分配逻辑就住在这里。

拆开的好处非常实际：因为打分与策略隔离，你可以重训模型而不碰任何一条规则；因为 cut-off 住在路由层，你改一个阈值不需要重新部署代码。把三层揉在一起的团队，每次模型更新都像拆炸弹——因为打分逻辑的变化和策略逻辑的变化会打包成同一个有风险的 diff 一起上线。

二、数据调用要分优先级，不要一把梭并行

自动化审批在申请人视角里是一个瞬间，在系统内部其实是一串外部调用，每个调用都有自己的延迟、成本和失败模式。征信局接口在月末会降级，银行流水聚合器会返回不完整的交易历史——这些都不改变你的信贷政策，但会改变规则运行时看到的那份材料。

实操上把外部调用分成三层：

第一层是资格层。 身份、欺诈信号，以及你自己的命中即拒规则（地域、主体类型、经营年限）。这一层最便宜、也最致命——大量申请会死在这里。

第二层是能力层。 征信数据、银行流水、收入核验。这一层最贵。

第三层是定价层。 用于精细化定价，常常是可选的。

顺序的原则是：先跑便宜且决定性的检查，再花钱买那份不会改变结论的报告。 一个能靠自有数据直接拒掉的申请，没有任何理由先去付费拉征信。

并行仍然值得用，但要用在同一层内部，而不是跨层全并行。把第一层和第二层一起发出去，等于花钱给那些本会被命中即拒规则拦掉的申请做征信。上线前先测一个数：有多大比例的申请死在第一层。 这个数决定了并行策略是否划算。

三、数据源失败不等于拒绝

这是最容易被忽略、也最容易出事的一环。

征信接口超时、聚合器返回空，都不是信贷决策，而是一个独立的状态。你的规则必须明确说清这五种情况里走哪一种：

1. 在限定次数内重试；
2. 切备用数据源；
3. 在明确的容忍范围内，用缩减后的数据集做判断；
4. 挂起，按计划重新执行；
5. 连同缺失项一起转人工复核。

这个区分有法律重量。按通行的不利行动（adverse action）规则，债权人通常需在收到完整申请后 30 天内告知申请人结果——批准、反报价或拒绝，而未完成的申请则应发出”材料不完整通知”并写明还缺什么。一个因为聚合器返回空而”悄悄拒掉”的文件，会产出一份你根本说不出具体理由的不利行动通知。 转人工的文件必须有明确的责任人和时限。

四、可解释性在信贷里是一个存储需求

“可解释 AI”听起来像研究课题。在放贷业务里它其实是一张数据库表的设计问题。

对每一个自动化决策，必须持久化这几样：

• 喂给模型的确切特征值；
• 模型版本标识；
• 原始分数；
• 触发的每一条策略规则；
• 最终的原因码。

这份记录才是不利行动通知能被辩护的基础，也是你能确定性地重放任意历史决策的前提。如果你无法把六个月前的某笔决策还原到当时那个模型版本，你手里就不是一个可审计的系统，而是一笔负债。 这条日志链路要在写正常流程之前先写。

对应到监管框架上，欧盟 AI 法案把”评估自然人信用状况”的模型列入 Annex III 第 5(b) 条的高风险清单，要求可解释、可人工干预、可被质询。美国方面，2026 年 4 月 17 日发布的 SR 26-2 取代了沿用十五年的 SR 11-7，成为银行模型风险管理的现行框架。这个框架把治理原则和风险为本的尺度写得很明确——虽然它把生成式与智能体 AI 排除在外，但传统评分卡和机器学习信用模型都在治理范围内；通过银行放款的金融科技合作方，往往会被延伸要求。

五、champion/challenger 要有真正的实验纪律

很多团队口头上说在做 challenger，实际做法是”challenger 跑着但没人看”。真正的 champion/challenger 需要四点：

一是流量分配可追溯。 哪个申请走了哪个模型，必须能被稳定地重放，而不是随机数决定完就丢了。

二是评估口径统一。 不能只比 AUC 这种预测指标，要放在固定历史样本上”重放”策略，比较通过率、损失、利差和转人工率——因为这些才是业务真正关心的结果。

三是时间窗足够长。 现金贷的账龄需要跨过至少一个完整的表现期（比如 M3+），短窗口的对比结论基本不可信。

四是结论要能推动上线。 challenger 赢了要能灰度切流，输了要能干净回滚。灰度与回滚是引擎的能力，不是运维的手工动作——如果切流需要改代码重新部署，团队实际上就不会去切。

六、几条容易被忽视的边界

决策与贷后要分开。 决策逻辑每月都在调，而还款计划、摊销这些贷后逻辑几乎不动，一旦动就必须绝对可靠。把二者塞进同一个服务，等于让稳定的、和钱直接相关的代码继承实验性代码的变更频率。放款系统（LOS）与贷后系统（LMS）分开建，是同一个道理。

大模型不要放在决策路径的终点。 大模型在信贷流程里确实有用——材料录入（把工资单、银行流水、发票转成结构化数据）比脆弱的模板解析器可靠得多；贷后环节可以做催收队列分诊并草拟沟通文案，附带建议动作交给人工确认。但硬性纪律是：只要大模型触及决策路径，它的输出只能作为确定性策略层的一个建议输入。绝不能让一个自由文本模型来下最终的信贷结论。 一个能抽取”月收入 4200″的模型是帮手；一个最后说”批准”的模型，就是一次不可审计、不可复现的决策。

别用你还没有的数据训模型。 最贵的架构错误，是在还没收集到还款数据的时候就去建机器学习。务实的路径是：先上一个规则引擎，从第一天就把 champion/challenger 的插槽接好，把所有环节都埋点，攒出干净、带标签的还款数据，等数据到位再引入模型。合规与数据质量要前置——这两样返工起来最痛苦。

七、上线前的自查清单

• 三层是否职责清晰，模型更新能否不碰策略；
• 外部调用的顺序是否按”便宜且决定性优先”排过；
• 数据源失败的五个分支是否都有明确规则和责任人；
• 是否能为任意一笔历史决策还原特征、模型版本、命中规则与原因码；
• champion/challenger 是否有固定样本、统一口径、足够长的表现期；
• 灰度与回滚是否不需要改代码；
• 决策服务与贷后服务是否物理分离；
• 大模型是否只出现在决策路径的建议侧。

小结

决策引擎的价值不在于”跑得多快”，而在于可变更、可复现、可辩护。评分卡决定”这个人风险多高”，决策引擎决定”我们拿这个风险怎么办”——而这个”怎么办”必须能被解释、能被回滚、能在一年之后被监管逐字复原。

下篇预告

下一篇（231）讲 Champion/Challenger：怎么用实验思维迭代风控策略，从流量切分、指标口径到上线决策，把”我觉得这个策略更好”变成”数据证明这个策略更好”。