3. 特征工程基础：特征的定义、特征与原始数据的区别、特征工程在KYC中的重要性
在KYC（Know Your Customer）风控场景中，模型的表现上限往往不取决于算法本身，而取决于输入数据的质量与表达方式。特征工程正是将原始业务数据转化为模型可理解、可学习、可区分的数学表达的过程。本章将系统讲解特征的定义、特征与原始数据的本质区别，以及特征工程在KYC场景中的核心价值。
3.1 特征的定义
特征（Feature） 是从原始数据中提取或构造的、能够反映业务对象某一维度属性的数值化或离散化表示。特征是机器学习模型进行预测和分类的最小信息单元。
在KYC场景中，特征通常具有以下属性：
- 可量化性：能够被表示为数值、类别或布尔值，例如“年龄=35”、“证件类型=身份证”。
- 区分性：在不同用户群体（正常用户 vs 欺诈用户）之间呈现统计差异。
- 稳定性：在时间维度上分布相对稳定，不会因短期波动导致模型失效。
- 可解释性：业务人员能够理解该特征所代表的业务含义。
💡 核心认知：特征是原始数据的“翻译器”。同样的原始数据，经过不同的特征构造方式，可以产生截然不同的模型效果。特征的质量直接决定了风控模型的区分能力和泛化能力。
3.2 特征与原始数据的区别
原始数据是业务系统直接产生的、未经加工的底层记录；特征是经过清洗、转换、聚合、组合后形成的模型输入。两者之间存在本质差异，理解这一区别是做好特征工程的前提。
| 对比维度 | 原始数据 | 特征 |
|---|---|---|
| 数据形态 | 非结构化或半结构化（文本、JSON、日志） | 结构化数值或类别（浮点数、整数、one-hot向量） |
| 信息密度 | 低，包含大量噪声和冗余 | 高，聚焦于与目标变量相关的信息 |
| 缺失处理 | 直接保留空值或异常值 | 经过填充、标记或建模处理 |
| 时间维度 | 单点记录，无聚合 | 可包含窗口聚合（近7天、近30天） |
| 业务语义 | 字段名直接对应数据库列 | 经过业务逻辑编码（如“设备指纹风险分”） |
| 模型可读性 | 模型无法直接处理文本或JSON | 模型可直接作为输入张量 |
举例说明：
- 原始数据：用户提交的身份证照片（图像文件） + 姓名文本 + 活体检测视频流。
- 特征：身份证OCR置信度（0.92）、姓名与身份证号一致性校验结果（1/0）、活体检测通过标志（1/0）、人脸与身份证照片相似度（0.85）。
原始数据是“原材料”，特征是“精加工产品”。模型不直接吃原材料，只吃特征。
3.3 特征工程在KYC中的重要性
特征工程（Feature Engineering）是指利用领域知识和数学方法，从原始数据中提取、构造、选择、变换特征的过程。在KYC风控场景中，特征工程的重要性体现在以下四个层面：
- 提升模型区分能力：好的特征能放大正常用户与风险用户之间的差异。例如，将“注册时间”转化为“注册时间距当前的小时数”，能更直接地反映“新注册即申请”的异常行为模式。
- 降低模型复杂度：高质量特征可以用更简单的模型（如逻辑回归）达到复杂模型（如深度网络）的效果，降低过拟合风险和部署成本。
- 增强业务可解释性：KYC场景受强监管约束，模型决策需要可追溯。特征工程阶段构造的“设备关联团伙数”、“IP地址风险等级”等特征，天然具备业务解释能力。
- 应对数据稀疏与冷启动：KYC场景中，新用户往往只有少量基础信息。通过特征工程构造“外部征信分缺失标志”、“多头借贷查询次数”等特征，可缓解冷启动问题。
📊 行业数据：据FICO和多家头部金融机构的实践经验，在风控模型开发中，特征工程环节通常占据项目总时间的60%~80%，而模型选择和调参仅占20%~40%。特征工程是风控模型真正的“护城河”。
3.4 KYC特征工程核心流程
下图展示了KYC场景下特征工程的标准流程，从原始数据接入到最终特征存储，每个环节都直接影响特征质量。
3.5 KYC场景特征分层体系
在KYC风控实践中，特征通常按照数据来源和业务层级进行分层管理。分层体系有助于特征的组织、复用和监控。下表展示了KYC场景中常见的四层特征体系：
| 特征层级 | 数据来源 | 典型特征示例 | 更新频率 |
|---|---|---|---|
| L1 基础身份特征 | 用户提交的证件信息、人脸、活体 | 年龄、性别、证件类型、OCR置信度、人脸相似度 | 实时/一次性 |
| L2 行为环境特征 | 设备指纹、IP、GPS、操作行为日志 | 设备ID、IP归属地、GPS与证件地址距离、操作时长 | 实时 |
| L3 关联网络特征 | 设备图谱、IP图谱、联系人图谱 | 设备关联用户数、IP关联设备数、团伙风险评分 | 准实时（T+1） |
| L4 外部征信特征 | 第三方征信机构、黑名单库、多头借贷平台 | 征信分、多头借贷次数、逾期记录、法院执行信息 | 准实时/离线 |
⚠️ 常见误区：很多团队在KYC模型开发初期，只关注L1基础身份特征，忽略了L2和L3层特征。实际上，在身份冒用和团伙欺诈场景中，L2行为环境特征和L3关联网络特征的区分能力往往远高于L1特征。特征分层不是理论框架，而是实战中必须遵循的优先级策略。
3.6 特征工程实战要点
在KYC场景中开展特征工程时，需要重点关注以下实战要点：
- 缺失值处理策略：KYC场景中，部分用户可能缺少人脸信息或外部征信数据。不能简单删除，而应构造“缺失标志位”特征，让模型学习缺失模式本身是否与风险相关。
- 时间窗口特征：对于行为日志类数据，构造“近1小时/近24小时/近7天”的聚合特征（如登录次数、操作失败次数），能有效捕捉短期异常行为。
- 交叉特征：将两个或多个基础特征进行组合，例如“年龄 × 申请金额”、“设备风险等级 × IP归属地风险等级”，往往能产生非线性区分能力。
- 特征稳定性监控：特征上线后需持续监控PSI（群体稳定性指标），当特征分布发生显著偏移时，需及时回溯特征构造逻辑或重新训练模型。
# KYC特征构造示例：时间窗口聚合特征（Python伪代码）
def build_time_window_features(user_logs, window_hours=[1, 24, 168]):
features = {}
for window in window_hours:
cutoff = datetime.now() - timedelta(hours=window)
window_logs = user_logs[user_logs['timestamp'] >= cutoff]
features[f'login_count_{window}h'] = len(window_logs[window_logs['action'] == 'login'])
features[f'fail_count_{window}h'] = len(window_logs[window_logs['result'] == 'fail'])
features[f'device_change_count_{window}h'] = window_logs['device_id'].nunique()
# 缺失值处理：若窗口内无日志，填充0并添加缺失标志
if len(window_logs) == 0:
features[f'no_log_flag_{window}h'] = 1
else:
features[f'no_log_flag_{window}h'] = 0
return features