3. 特征工程与特征漂移：特征分类与漂移成因
在授信决策引擎中，特征并非一成不变。理解特征的稳定性、掌握漂移的常见原因，是构建可靠监控体系的前提。本章将系统梳理特征分类标准与漂移根因，为后续的 LightGBM 重要性分析奠定基础。
3.1 特征分类：稳定型 vs. 不稳定型
根据特征随时间变化的波动程度，可将特征分为两大类。分类的核心依据是特征分布（均值、方差、分位数）在时间窗口内的变异系数（CV）或 PSI（群体稳定性指标）。
| 特征类型 | 定义 | 典型例子 | PSI 参考阈值 |
|---|---|---|---|
| 稳定型特征 | 分布随时间变化极小，统计属性长期保持一致性 | 年龄、性别、学历、户籍地（宏观层面） | PSI < 0.1 |
| 不稳定型特征 | 分布随时间出现显著偏移，统计属性波动明显 | 近 3 个月收入、消费金额、多头借贷次数、设备型号 | PSI ≥ 0.1 |
实践要点： 稳定型特征通常作为模型的基础骨架，而不稳定型特征需要更频繁的监控与重训练。在 LightGBM 中，不稳定型特征若重要性过高，会显著增加模型整体漂移风险。
3.2 特征漂移的三大常见原因
特征漂移并非随机发生，其背后通常有明确的业务或技术驱动因素。归纳起来，主要分为以下三类：
- 客群变化：授信策略调整、市场推广渠道变更、宏观经济周期波动，导致申请客群的结构性改变。例如，疫情期间消费贷客群收入分布整体下移。
- 政策调整：监管法规、内部风控规则、产品定价策略的变动，直接改变特征的计算口径或业务含义。例如，新征信管理办法要求调整“逾期天数”的计算起点。
- 数据源变更：上游数据接口升级、第三方数据供应商切换、埋点采集方式变化，导致特征原始值或缺失模式发生偏移。例如，某征信机构更新评分模型版本，导致“信用分”特征整体偏移。
诊断建议： 当监控系统检测到特征漂移时，应首先排查最近 1-2 周内是否有上述三类事件发生。建立“漂移-事件”关联日志，可大幅缩短根因定位时间。
3.3 特征漂移成因关系图
下图展示了三大漂移成因与特征稳定性之间的逻辑关系，以及它们对授信决策引擎的最终影响路径。
3.4 特征稳定性评估矩阵
在实际工程中，我们通常结合 PSI（群体稳定性指标） 和 特征重要性 两个维度，对特征进行分级管理。以下矩阵可作为监控优先级划分的参考：
| 特征重要性 \ 稳定性 | 稳定（PSI < 0.1） | 轻度漂移（0.1 ≤ PSI < 0.25） | 严重漂移（PSI ≥ 0.25） |
|---|---|---|---|
| 高重要性（LightGBM 增益排名前 20%） | 绿色：正常监控，低频重训 | 黄色：加强监控，评估是否需要特征替代 | 红色：紧急告警，立即排查根因，考虑模型回滚 |
| 中等重要性（排名 20%-60%） | 绿色：常规监控 | 黄色：适度关注，纳入定期重训范围 | 橙色：触发告警，评估特征剔除或变换 |
| 低重要性（排名后 40%） | 绿色：低频监控 | 绿色：可忽略，但需记录日志 | 黄色：低优先级告警，可随重训自动修复 |
关键提醒： 高重要性 + 严重漂移的特征是授信决策引擎的“定时炸弹”。在 LightGBM 模型中，这类特征会直接扭曲决策边界，导致通过率或坏账率出现剧烈波动。必须建立自动化告警与人工复核的双重机制。
3.5 漂移根因排查清单
当检测到特征漂移时，建议按以下清单进行系统性排查：
- 客群维度：近期是否有新渠道上线？是否调整了准入规则？宏观经济是否有重大事件（如降息、失业率波动）？
- 政策维度：内部风控策略是否更新？监管是否有新发文？产品利率或期限是否调整？
- 数据维度：上游数据接口是否升级？第三方数据供应商是否变更？数据采集 SDK 版本是否更新？
- 计算维度：特征工程代码是否被修改？缺失值填充逻辑是否变化？时间窗口计算是否出现 bug？
工程实践： 建议在特征存储层增加
feature_version 和 source_tag 字段，每次特征计算时记录版本号与数据来源。这样在漂移发生时，可以快速通过 SQL 回溯特征版本变更历史，大幅缩小排查范围。