第四章：模型开发文档审查——文档完整性、方法论合理性、变量选择逻辑的审查要点

模型开发文档，说白了就是模型的「出生证明」。我见过太多团队，模型做得漂亮，但文档一塌糊涂。监管来检查，一问三不知。嗯，今天我们就聊聊，怎么把这份「出生证明」写得让监管挑不出毛病。

4.1 文档完整性审查——缺了什么，一眼看穿

我个人习惯，拿到一份模型开发文档，先不急着看内容。先翻目录，看结构。缺了哪些章节，心里先有个数。

一份完整的模型开发文档，至少应该包含以下模块：

审查维度	必备内容	常见缺失项
项目背景	建模目的、业务场景、适用范围	很多人只写「开发一个评分卡」，但没说清楚用在哪个产品、哪个客群
数据说明	数据来源、时间窗口、样本量、变量清单	缺失数据字典，或者变量定义模糊
方法论	算法选择、参数设置、训练/验证/测试集划分	只说用了逻辑回归，但没说为什么用，也没说正则化参数怎么调的
变量处理	缺失值处理、异常值处理、WOE编码、分箱逻辑	分箱边界拍脑袋，没有业务解释
模型表现	区分度、校准度、稳定性指标	只放KS和AUC，没有PSI和校准曲线
模型局限性	已知缺陷、使用限制、监控计划	几乎没人写这一节，但监管最爱问

4.2 方法论合理性审查——为什么选这个，不选那个

方法论这块，我见过最离谱的，是有人用深度学习做信用评分卡，问为什么，答曰「因为深度学习很火」。你想想看，监管看到这个会怎么想？

方法论合理性的审查要点，我总结为三个「对」：

• 算法对场景：信用评分卡，逻辑回归、XGBoost是主流。如果你非要用SVM，请给出充分理由。我在项目中遇到过，有人用随机森林做可解释性要求极高的模型，结果被监管打回来重做。
• 参数对数据：样本不平衡怎么办？过采样还是欠采样？正则化参数怎么选的？这些不能靠「感觉」，要有交叉验证的结果支撑。
• 验证对结论：训练集、验证集、测试集，三者的表现差距不能太大。如果训练集KS 0.6，测试集KS 0.3，那说明过拟合了。文档里必须解释为什么，以及怎么处理的。

4.3 变量选择逻辑审查——每个变量都得有「身份证」

变量选择，是模型开发中最容易「藏雷」的地方。我见过有人用「客户星座」做变量，还煞有介事地做了WOE编码。嗯，这种变量，业务上解释得通吗？

变量选择的审查，我重点关注三点：

1. 业务逻辑：每个变量必须有业务含义。比如「近3个月逾期次数」，这个变量很直观。但「客户手机号尾数」，这个变量有什么业务逻辑？我曾经在审查中直接问开发人员：「你给我解释一下，为什么尾号是8的客户违约率更低？」对方答不上来。
2. 统计显著性：IV值、p值、VIF，这些统计指标必须达标。但要注意，统计显著不等于业务合理。反过来，业务合理但统计不显著的变量，可以考虑保留，但文档里要说明理由。
3. 时间稳定性：变量的分布在不同时间窗口是否一致？我见过一个模型，用了「近7天登录次数」这个变量，结果模型上线后，因为产品改版，登录次数暴增，模型直接崩了。变量稳定性分析（PSI）必须做，而且要在文档里体现。

4.4 知识体系框架图

下面这张图，是我自己整理的一套审查框架。每次做文档审查，我都会对照着看一遍，确保没有遗漏。

4.5 实战中的「灵魂拷问」清单

最后，分享一份我自己的审查清单。每次做文档审查，我都会逐条过一遍：

• ✅ 文档有没有说清楚「为什么做这个模型」？—— 不是为了做模型而做模型
• ✅ 数据的时间窗口是否合理？—— 训练集和验证集有没有时间穿越？
• ✅ 缺失值处理逻辑是否一致？—— 训练集和线上打分时，处理方式必须一样
• ✅ 变量分箱是否有业务解释？—— 不能只看统计，不看业务
• ✅ 模型表现指标是否全面？—— KS、AUC、PSI、校准曲线，一个都不能少
• ✅ 有没有写模型局限性？—— 没有局限性的模型，监管反而觉得你有问题

嗯，今天就聊到这里。文档审查这件事，说白了就是「把话说清楚，把事做明白」。你按照上面的框架去审查，基本不会出大问题。

---

公众号:蓝海资料掘金营，微信deep3321