信用风险管理:模型、度量、工具及应用

做风控的同学常卡在同一处：模型跑得出分，却说不清这个分该怎么用、阈值定在哪、出问题先查谁。这篇不讲打分卡原理，只把「模型—度量—工具—应用」这条链子串起来，给一份从建到管的自查顺序：先定度量口径，再挑模型与数据，最后把工具接到监控与回退上。

做风控的同学常卡在同一处：模型跑得出分，却说不清这个分该怎么用、阈值定在哪、出问题先查谁。建模本身能写好几本书，但真正让一件事卡住的往往不是算法，而是「模型—度量—工具—应用」这条链子没串起来：度量口径没定就急着调参，工具没接监控就敢上生产，最后分数天天出，业务不敢用。

这篇不讲打分卡原理，只给一份从建到管的自查顺序：先定度量口径，再挑模型与数据，然后按四段结构找工具，最后把监控与回退接上。每节都附判断标准，以及什么情况下这套做法不适用。数字类的东西一律不写死，需要对照时到站内页面看当时的口径。

先定度量口径，再谈模型

第一步不是选模型，是把风险拆开说。至少分三层：违约概率、违约损失率、违约暴露。三层各自靠什么数据估，要分别写清楚——一层靠行为流水，一层靠抵质押与清收历史，一层靠额度使用与授信结构。用一个分数包打天下，后面阈值一定定不准，因为没人知道这个分对应的是哪一层风险。

还要区分排序能力与校准能力。排序看能不能把人按风险排开，校准看分数能不能直接当概率用。这决定阈值怎么定：排序好但校准差的模型，适合做分层和规则触发；要拿分数直接算预期损失，就必须把校准做上去，否则对不上账。

• 样本口径先对齐：观察期、表现期、好坏定义各写一行，贴在建模文档首页，不然后面对不上账
• 先定决策口径：是要卡通过率，还是要卡某个损失上限，两种目标选出的阈值不一样
• 把人工复核的触发条件也当成度量的一部分写进去，别等上线才发现没人兜
• 定期回看口径是否还成立，业务模式变了，好坏定义往往先失效

模型与数据怎么配

模型族的选择应该由可用数据决定，而不是反过来。只有内部行为数据，就走行为评分口径；有征信与多头数据，可以走组合口径。为了用上新算法硬凑特征，是上线后翻车最常见的原因之一——特征本身不稳定，再好的模型也扛不住。

特征清单要标来源与更新频率。过期几天的字段和实时字段不能混在同一批训练里，否则线下效果好，线上分数天天跳。上线前务必留出时间外样本验证，同一时间段内随机切分的验证结果普遍偏乐观，说服不了风控和审计。

时间外样本

用比训练期更晚的时段做验证，更接近真实上线效果

特征来源标注

每个字段写清取自哪个系统、多久更新一次、缺失时怎么填

冷启动

新客无行为数据时的兜底策略，通常靠规则或外部数据

术语口径不统一是团队内耗的大头。分箱、WOE、KS 这些词，不同人理解差别很大，建议先到 /ai-dict/category/basics 把定义对齐，再开建模评审，能省下大量来回解释的时间。

工具链怎么接

工具按四段来找：取数、算分、决策、留痕。四段缺一段都不要上生产。取数决定特征能不能按时到位，算分决定延迟，决策决定阈值与规则的组合方式，留痕决定出事后能不能复盘。很多团队只盯着中间两段，前后一断，模型再好也落不了地。

1. 取数段确认每个特征的最晚到达时间，标注关键路径字段；验证方式是模拟一次真实请求，看缺哪些字段
2. 算分段把模型封装成可版本化的服务，输入输出结构固定；到 /tools/speed-test 量一条延迟基线，贷前链路对时间敏感，只测准确率不够
3. 决策段规则与模型分开配置，规则允许人工改，模型走版本发布流程；验证方式是跑一遍规则与模型冲突时的优先级
4. 留痕段记录每次决策用到的模型版本、特征快照与规则命中项；验证方式是随机抽几笔，看能否完整还原当时决策

监控至少盯三样：分数分布漂移、特征缺失率、拒绝率与通过率的联动变化。分布漂移说明客群或数据变了，缺失率上升往往是上游接口出问题，拒绝率突然上升要先怀疑规则而不是模型。三者一起看，比单看某个指标更容易定位。

不同产品线对工具链的要求不一样。小额高频、笔数多的产品线，值得把四段全部自动化；笔数很少的产品线，重自动化的投入产出不划算，保留人工环节反而更稳。

上线后的监控与回退

上线不是终点。定期做回溯验证：把已经放款的客户按新模型重算一遍，和实际表现比对。这一步能暴露很多线下验证看不到的问题，尤其是客群在放款后发生变化的情况。比对的频率按业务节奏定，别照搬别人的周期。

• 给每个模型配一条回退路径：降级到上一版本，或直接降到规则兜底
• 写清谁有权触发回退，以及触发后多久生效，别等到出事才开会定
• 变更记录留底：谁改的、何时生效、影响哪条产品线，审计时这是第一手材料
• 把分布漂移、缺失率、拒绝率三个信号做成同一个看板，避免各看各的
• 每季度做一次回退演练，确认降级路径真的能走通

回退不是失败，是设计的一部分。真正危险的是没有回退选项，只能硬扛着看分数往下掉。把回退当成常规动作，团队心理负担会小很多，出问题时也敢早动手。

落地自查清单

把前面几节收敛成一张清单，逐条打勾。七项分别是：度量口径、样本定义、特征来源、模型版本、决策阈值、监控指标、回退方案。任何一项写不出具体内容，就说明这块还没想清楚，别急着上线。

推进节奏上，新老模型并行跑一段时间再切，先切小流量产品线。并行期重点看两套决策的差异案例，差异大的样本逐笔看，往往能发现特征或规则上的问题。差异平稳后再扩大流量，别一步到位。

还有一件容易漏的事：把「什么情况下人工介入」写进流程，别让系统自己兜。系统擅长一致性和速度，不擅长处理没见过的情况。人工兜底的条件、权限和时效写清楚，出问题时才有人接得住。

涉及个人信息的处理与留存边界，对照 /safety 的合规条目过一遍。数据能用多久、谁能看、怎么脱敏，这些不是风控一个部门的事，但风控往往是第一道经手方，提前对齐能少很多返工。