第 3 章 数据基础：数据源、变量类型与数据质量
做信用评分模型，有一句老话我特别信：模型是饭菜，数据是食材。食材不新鲜，再厉害的厨师也白搭。这一章，我就把数据基础掰开了讲，包括数据从哪来、有哪些类型、怎么才算高质量。你想想，如果连客户有没有逾期都搞不清，模型怎么可能稳？
3.1 数据源的三驾马车
信用评分用的数据，来源不外乎三个方向：征信、内部、第三方。我个人习惯先摸清楚每个来源的质量和稳定性，再去谈变量加工。
3.1.1 征信数据
这是最正统的信用数据，来自央行征信中心、百行征信、朴道征信这类机构。包含信用卡还款、贷款记录、查询次数、担保信息等。特点是权威但更新有延迟，一般月更新。
避坑：我遇到过某个项目直接拉央行征信的原始字段当变量，结果发现部分客户征信报告上“当前逾期”字段为空，实际上是因为客户从未办过信用卡，系统默认没数据。我们后来加了一层空值处理，才没把好客户误判成坏客户。
3.1.2 内部数据
自家系统里沉淀的。比如交易流水、App行为、客服投诉、还款渠道偏好。优势是实时、高频、可控。缺点是有偏——数据只覆盖存量客户，对于新客或者流失客，内部数据就抓瞎了。
我个人建议：做内部数据变量时，先做存量客户覆盖度分析，如果某个行为字段缺失率超过 80%，就别硬凑了。
3.1.3 第三方数据
包括运营商（通话时长、流量）、电商（消费等级）、社保公积金（收入稳定性）、黑名单（涉诉、欺诈）等。好处是能填补征信盲区，坏处是数据质量参差不齐，有些供应商接口动不动超时。
我曾经踩过一个大坑：引入某家电商消费数据，说好日更新，结果上线后连续三天接口返回空值。排查半天是对方服务器挂了，我们模型却照常跑了三天，正样本全部标记异常。从那以后，我对第三方数据都做了中断保护：接口失败时用前一次快照填充，并标记为“未知”。
| 数据源 | 核心字段举例 | 优点 | 常见坑 |
|---|---|---|---|
| 征信 | 贷款余额、逾期次数、查询频次 | 权威、合规 | 更新慢、空值含义模糊 |
| 内部 | 月均交易金额、登录频率、客诉次数 | 实时、可控 | 存量偏差、缺失率高 |
| 第三方 | 运营商在网时长、电商月消费额、社保基数 | 补充征信盲区 | 稳定性差、接口不可靠 |
3.2 变量类型：别把西瓜和芝麻混在一起喂模型
数据拿到手后，先分类型。不同变量类型，处理方式、入模方式完全不同。嗯，我这里说的不是“变量”本身，而是值的刻度尺。
- 数值型（连续/离散）：比如“授信额度”“近6个月逾期次数”。可以直接用，但注意分布极值和量纲差异。
- 分类型（名义/有序）：比如“学历（高中/本科/硕士）”“婚姻状态”。必须做编码，我习惯用坏账率编码或者WOE编码，而不是随便 0/1。
- 二元型：比如“是否多头借贷”“是否命中黑名单”。这种最简单，直接 0/1 就行。
- 文本型：比如“客户留言提取的关键词”。需要先分词，再做成 TF-IDF 或词频向量。老实说，传统评分卡很少直接用文本，但机器学习模型可以。
3.3 数据质量要求：少了会漏，多了会乱
数据质量是模型的生命线。我搞项目时，花在数据清洗上的时间通常占整个建模周期的 60% 以上。下面这四条，是我评估一家数据供应商或一个内部数据表时的核心标准。
- 完整性：缺失率不能过高。一般缺失率超过 50% 的变量直接丢弃；30%~50% 的变量可以考虑做缺失值指示，或者用同组均值填补。
- 准确性：字段值是否真实。比如“年龄”字段突然出现“-1”或“999”，明显是录入异常。我一般用业务规则做四层校验，比如年龄必须在 0~120 之间。
- 一致性：同一个客户在不同表里，字段值应该一致。以前遇到一个麻烦：客户在 A 系统显示“大专”，在 B 系统显示“本科”，这种不一致直接影响模型稳定性。
- 时效性：数据是否足够新。征信数据如果延迟 3 个月，那时点信息就基本没用了。我个人习惯给每个变量打一个“数据采集时间戳”，建模时只取最近 90 天的记录。