4. 数据收集与整合
好，我们进入第四章。数据，才是评分卡的灵魂。模型算法再花哨，喂进去的是垃圾，出来的肯定是垃圾——这是铁律。我做了这么多年风控，见过太多项目在数据整合阶段就埋下了大坑。
说白了，数据收集与整合，就是给模型找“粮食”。你要知道哪些粮食能吃，哪些有毒，怎么把不同的粮食混到一起做成一顿好饭。这一章，我们重点聊三个问题：内部数据怎么挖？外部征信怎么选？多个数据源怎么拼才不会出乱子？
核心观点： 数据质量决定模型上限，算法只是逼近这个上限。数据整合阶段多花一个月，模型上线后能省半年的维护时间。
4.1 内部数据：你坐在金矿上，别只顾着挖外面
很多人一上来就盯着外部征信数据，觉得越多越好。其实内部数据才是你的核心资产。为什么？
内部数据的三个层次：
- 申请数据：年龄、性别、职业、收入、学历、婚姻状况、居住地等——这些都是客户自己填的，也是最原始的画像。
- 行为数据：登录频次、浏览产品、页面停留时间、修改个人信息次数——这些反映了客户当下的真实意图和稳定性。
- 贷后表现数据：历史还款记录、逾期天数、提前还款次数、展期次数——这是最硬的标签，直接定义好客户和坏客户。
我的经验： 我建议你优先把“贷后表现数据”清洗干净。很多团队花大量精力搞外部特征，结果内部的历史逾期标签都是错的——这种模型注定失败。先把内部地基打牢，再谈外部锦上添花。
举个例子。我在一个消费金融项目里，发现内部客户“填写信息时长”这个变量跟逾期率显著负相关。填写越快的客户，逾期率反而低。你想想看，一个客户迅速填完所有信息，说明什么？说明他对自己情况非常熟悉，大概率是个“老玩家”。外部征信根本查不到这个信号。
4.2 外部征信数据：知道去哪里找，更要知道怎么看
外部数据是大头。但很多人在这个环节被“数据中介”割了韭菜。
外部征信数据的典型分类：
| 类型 | 典型数据源 | 主要特征变量 | 质量/覆盖率 |
|---|---|---|---|
| 央行征信 | 中国人民银行征信中心 | 还款记录、信用卡张数、贷款笔数、查询次数 | 覆盖率极高，但时效性稍差（更新周期T+1以上） |
| 百行/朴道征信 | 百行征信、朴道征信 | 多头借贷、借还款行为、设备指纹 | 新兴人群覆盖好，数据维度新 |
| 三方数据 | 同盾、极光、中诚信、百融等 | 多头指数、联系人关系网、黑名单、设备异常 | 通常实时，数据质量参差不齐，需严格测试 |
| 运营商数据 | 三大运营商 | 通话时长、通话频次、联系人稳定性、入网时长 | 对长尾客群有效，但授权获取门槛高 |
注意： 我曾经在一个项目中引入一家小型三方数据公司，对方的“多头借贷指标”声称有3000+特征。结果我们拿来一做验证，发现80%的特征跟内部已知变量高度共线，而且有10%的特征在验证样本中缺失率超过70%。这就是典型的“数据注水”。不要迷信特征数量，要亲自验证每个变量的IV值和稳定性。
关于征信数据，还有个常见误区——很多人觉得查询次数越多越好。其实，查询次数是把双刃剑。查询太多说明客户在多头借贷，风险高；查询太少可能是“白户”，风险难以判断。我个人习惯把“近3个月征信查询次数”做WOE变换，看看它的IV值。通常这个变量的IV值在0.2-0.5之间，属于中等区分力。
4.3 数据源整合策略：把散落的数据拼成完整画像
单个数据源再好，也只是拼图的一块。真正的难度在于如何把内外部数据整合成一张干净的“单客户单行”宽表。
整合的第一个问题：身份匹配
内部系统有客户ID，外部征信有身份证号+姓名。怎么配？
-- SQL示例：内外部数据身份匹配
SELECT
i.cust_id,
i.name,
i.id_no,
e.credit_score,
e.loan_cnt_last6m,
e.query_cnt_last3m
FROM internal_cust i
LEFT JOIN external_credit e
ON i.id_no = e.id_no
AND i.name = e.name
WHERE i.apply_date <= '2024-06-30' -- 固定观察点
嗯，这里要注意：单纯用身份证号和姓名匹配，遇到重名+身份证号录入错误的情况就会掉坑。我建议增加“手机号”作为辅助匹配键。对于匹配不上的记录，必须做人工抽检和模糊匹配。
整合的第二个问题：时间对齐
这是最容易出大错的地方。很多新人把客户申请日之后的外部数据拿来当特征——这是典型的“未来信息泄露”。
- 观察点： 客户提交申请的日期。
- 观察窗： 观察点之前的一段时间（比如近6个月）。外部征信数据、行为数据都只能取这个时间窗内的。
- 表现窗： 观察点之后的一段时间（比如6-12个月），用来定义“好”和“坏”。
避坑指南： 我曾经在做一个联合贷项目时，合作方的数据工程师把观察点后一个月的征信查询记录也纳入了模型特征。结果模型AB测试时KS高达0.6，上线后直接崩到0.2。原因就是模型“看到了未来”。你想想看，客户的未来表现怎么可能用作今天的预测？
整合的第三个问题：质量监控
数据整合完成不是终点。每次更新数据源时，都要做一轮质量监控。
- 缺失率检查： 每个特征的缺失率超过多少？内部数据通常控制在5%以内，外部数据可以放宽到20%。
- 一致性检查： 同一个数据源前后两期的分布有没有突变？比如“本月查询次数”的均值突然从2.3跳到5.1，大概率是数据源问题。
- 跨源交叉验证： 内部客户年龄 vs 外部征信推算的年龄是否一致？不一致的样本要标记出来。
我自己的习惯是，每次数据整合后，生成一份《数据质量报告》，包含每个特征的缺失率、均值、标准差、极端值占比。这是我做咨询服务的基操。
4.4 小结：数据整合的几个硬性指标
收个尾。数据整合不是一次性的，它贯穿整个模型生命周期。我建议你记住这几条：
- 内部数据优先，外部数据辅助
- 所有外部数据必须用客户授权的合规渠道获取
- 身份匹配至少通过2个独立键验证
- 时间对齐是红线——绝对不能用观察点之后的信息
- 每次更新数据源，必须重新跑一遍质量监控
嗯，这些看起来很基础。但我在业界看到的大多数模型翻车案例，根源都在前期的数据整合。基础打好了，后面的特征工程和模型训练才能顺利推进。