3. 催收模型特征工程：特征来源、处理流水线与存储方案
特征工程是催收模型从开发走向生产部署的核心桥梁。原始数据必须经过系统化的特征提取、清洗、变换与存储，才能被模型高效利用。本章聚焦催收场景下特征的三大支柱：特征来源（内部与外部数据）、特征处理流水线（批处理与实时管道）以及特征存储方案（特征仓库与在线存储）。
3.1 特征来源：内部数据与外部数据
催收模型的特征数据可划分为两大来源：内部业务系统沉淀的数据与外部第三方机构提供的数据。两者的结合能显著提升模型对借款人还款意愿与还款能力的预测精度。
| 数据类别 | 典型数据源 | 关键特征示例 | 更新频率 |
|---|---|---|---|
| 内部数据 | 核心账务系统、贷后管理系统、客服系统 | 逾期天数、历史还款记录、承诺还款次数、接通率 | 实时/每日 |
| 外部数据 | 央行征信、百行征信、运营商、社保公积金 | 征信查询次数、多头借贷数、社保缴纳状态、通话活跃度 | 每周/每月 |
| 衍生数据 | 内部+外部交叉计算 | 收入负债比、近期行为评分、失联指数 | 按需/每日 |
实践建议：内部数据是特征工程的基础，应优先保证其完整性与一致性。外部数据用于补充信息盲区，但需关注数据合规性、成本与更新延迟。建议将外部数据作为“增强特征”而非“核心特征”引入模型。
3.2 特征处理流水线
特征处理流水线将原始数据转化为模型可用的数值特征。在催收场景中，流水线需要同时支持批量离线处理（用于模型训练与批量评分）和实时在线处理（用于实时决策）。
3.2.1 批处理流水线
批处理流水线通常基于 Spark 或 Pandas 构建，每日或每小时运行一次，处理全量或增量数据。典型步骤包括：
- 数据接入：从 Hive、HBase 或数据湖中读取原始表。
- 缺失值处理：对连续变量使用中位数填充，对分类变量使用众数或“未知”标记。
- 异常值截断：基于业务规则或分位数（如 99.9%）对极端值进行截断。
- 特征变换：对长尾分布特征做对数变换或 Box-Cox 变换。
- 特征编码：对类别特征使用目标编码（Target Encoding）或 WoE 编码。
- 特征聚合：按用户 ID 聚合近期行为统计量（如近 7 天通话次数均值）。
- 特征存储：将处理后的特征写入特征仓库。
# 批处理流水线伪代码示例（PySpark）
from pyspark.sql import functions as F
def batch_feature_pipeline(spark, date_str):
# 1. 读取原始数据
df = spark.read.table("ods.collection_behavior") \
.filter(F.col("dt") == date_str)
# 2. 缺失值处理
median_value = df.approxQuantile("call_duration", [0.5], 0.01)[0]
df = df.fillna({"call_duration": median_value, "contact_result": "UNKNOWN"})
# 3. 异常值截断
upper_bound = df.approxQuantile("call_duration", [0.999], 0.01)[0]
df = df.withColumn("call_duration",
F.when(F.col("call_duration") > upper_bound, upper_bound)
.otherwise(F.col("call_duration")))
# 4. 特征变换
df = df.withColumn("log_call_duration", F.log(F.col("call_duration") + 1))
# 5. 特征聚合
agg_features = df.groupBy("user_id").agg(
F.avg("log_call_duration").alias("avg_log_call_duration_7d"),
F.count("contact_result").alias("total_contacts_7d")
)
# 6. 写入特征仓库
agg_features.write.mode("overwrite").saveAsTable("feature_store.user_daily_features")
3.2.2 实时处理流水线
实时流水线用于处理催收策略中的实时事件，如用户点击还款链接、接听催收电话等。通常基于 Flink 或 Kafka Streams 构建，延迟控制在秒级。
实时特征处理关键点：
- 使用滑动窗口计算近期行为统计（如过去 5 分钟通话次数）。
- 特征计算需幂等，支持事件重放与状态恢复。
- 输出特征直接写入在线特征存储（如 Redis），供模型服务实时读取。
3.3 特征存储方案
特征存储是 MLOps 中连接特征工程与模型服务的核心组件。在催收场景中，特征存储需要同时满足离线分析与在线服务两种截然不同的访问模式。
3.3.1 离线特征仓库
离线特征仓库用于存储历史特征数据，主要服务于模型训练、回测与批量评分。常用技术选型包括：
- Hive / HDFS：适合大规模历史数据存储，支持 SQL 分析，延迟较高。
- ClickHouse：列式存储，适合高吞吐的批量特征查询与聚合分析。
- Delta Lake / Iceberg：提供 ACID 事务与时间旅行能力，保证特征数据一致性。
3.3.2 在线特征存储
在线特征存储用于存放最新特征值，供模型服务在毫秒级内读取。催收场景下，在线特征通常以用户 ID 为 Key，特征向量为 Value 进行存储。
| 技术组件 | 数据结构 | 读写延迟 | 典型场景 |
|---|---|---|---|
| Redis | Hash / String | < 5ms | 实时评分、策略规则查询 |
| DynamoDB | Key-Value | < 10ms | 高并发在线推理 |
| Feast + Redis | 特征视图 | < 10ms | 特征工程与模型服务统一管理 |
避坑指南：在线特征存储必须设置 TTL（过期时间），避免历史特征长期占用内存。同时，需建立离线与在线特征的一致性校验机制，防止因数据延迟导致训练与推理时的特征分布偏移。
3.3.3 特征存储最佳实践
在催收模型上线实践中，推荐采用双存储 + 统一特征视图的架构：
- 定义特征视图：使用 Feast 或自研特征注册中心，统一管理特征名称、类型、来源与版本。
- 离线写入：批处理流水线每日将特征写入 Hive/ClickHouse，并同步更新特征视图的元数据。
- 在线同步：实时流水线将最新特征写入 Redis，同时记录特征更新时间戳。
- 一致性校验：每日运行校验任务，对比离线与在线特征在关键分位数上的差异，差异超过阈值时触发告警。