📚 课程目录第2章特征工程基础

特征工程基础：反洗钱中的特征分层方法

特征工程是反洗钱模型构建中最具技术含量、也最耗时的环节。原始交易数据不会直接告诉你“这笔交易是否可疑”，你需要通过特征工程将原始数据转化为能够揭示洗钱行为的量化指标。本章将系统讲解特征工程在反洗钱中的核心地位、特征与标签的映射关系，以及特征分层的设计思想。

一、特征工程在反洗钱中的重要性

在反洗钱建模流程中，特征工程处于数据清洗与模型训练之间的关键位置。没有高质量的特征，再先进的算法也无法产出可靠的预警结果。以下表格总结了特征工程在反洗钱各环节中的具体作用：

环节	原始数据问题	特征工程解决方式	对模型的影响
数据清洗	字段缺失、格式不统一	缺失值填充、时间戳标准化	保证特征可计算
特征提取	交易流水无统计信息	聚合生成金额均值、频次、标准差	刻画交易行为模式
特征变换	金额分布严重右偏	对数变换、分箱处理	提升模型对极端值的鲁棒性
特征选择	冗余特征导致过拟合	相关性分析、IV值筛选	降低噪声、提高泛化能力
特征分层	特征维度混乱	按交易、账户、客户、网络分层	结构化建模、可解释性增强

核心观点：反洗钱模型的上限由特征工程决定，算法只是逼近这个上限的工具。在金融合规领域，特征的可解释性往往比模型精度更重要——监管机构需要知道“为什么这笔交易被预警”。

二、特征与标签的关系

在反洗钱场景中，特征（Feature）是描述交易、账户或客户行为的可量化属性，标签（Label）是模型要预测的目标变量——通常为“是否可疑”。两者之间存在明确的逻辑链条：

特征驱动标签：可疑行为必然在特征上留下痕迹。例如，频繁的小额整数交易（特征）可能指向“化整为零”的洗钱手法（标签）。
标签定义特征边界：监管规则（如单笔超过5万元人民币的现金交易）直接决定了哪些特征需要重点构建。
时间错位关系：特征基于历史交易窗口（如过去30天），标签基于当前或未来的判定结果。建模时必须保证特征时间早于标签时间，避免未来信息泄露。

以下SVG图展示了特征与标签在反洗钱建模中的映射关系：

实战提示：在SQL中构造特征时，建议使用 WHERE 交易时间 < 标签时间 作为过滤条件，并在窗口函数中明确指定 ROWS BETWEEN 30 PRECEDING AND 1 PRECEDING，确保特征窗口严格闭合。

三、特征分层的核心思想

反洗钱特征分层是指按照数据粒度和业务含义，将特征组织成不同层级，每一层解决特定维度的建模需求。分层设计能够显著提升特征的可维护性、可复用性和模型的可解释性。

标准反洗钱特征分为以下四个层级：

层级	粒度	典型特征	建模用途
L1 交易层	单笔交易	交易金额、交易时间、交易类型、对手方ID	实时规则引擎、单笔异常检测
L2 账户层	账户维度	日均交易金额、交易频次、金额标准差、整数交易占比	账户画像、行为评分
L3 客户层	客户维度	关联账户数、总交易量、跨境交易占比、高风险对手方数量	客户风险评级、KYC增强
L4 网络层	关联图谱	交易网络密度、中心度、环路检测、资金汇聚系数	团伙识别、洗钱网络挖掘

以下SVG图展示了特征分层的金字塔结构，以及各层之间的数据流动关系：

四、特征分层的实战价值

在实际反洗钱项目中，特征分层带来的收益是立竿见影的：

降低特征冗余：同一特征只需在最低层级计算一次，上层通过聚合复用，避免重复计算。
提升模型可解释性：监管问询时，可以从L4网络层逐层向下追溯，定位到具体交易。
支持多模型并行：L1特征用于实时规则引擎，L2-L3特征用于离线评分模型，L4特征用于团伙挖掘，互不干扰。
便于特征迭代：新增特征只需在对应层级添加，不影响其他层级的计算逻辑。

常见误区：不要将所有特征堆砌在同一张宽表中。虽然宽表在训练时方便，但在生产环境中，宽表会导致存储膨胀、计算延迟、特征血缘混乱。建议按分层设计，每层独立建表，通过主键关联。

五、SQL实现特征分层的初步思路

在后续章节中，我们将详细讲解如何使用SQL实现每一层特征的计算。这里先给出一个简单的分层SQL结构示例，帮助建立直观认识：

-- L1 交易层：提取单笔交易特征
CREATE VIEW l1_transaction_features AS
SELECT
    transaction_id,
    account_id,
    amount,
    transaction_time,
    CASE WHEN amount % 1 = 0 THEN 1 ELSE 0 END AS is_integer_amount,
    CASE WHEN amount BETWEEN 49000 AND 51000 THEN 1 ELSE 0 END AS is_round_50k
FROM raw_transactions;

-- L2 账户层：按账户聚合L1特征
CREATE VIEW l2_account_features AS
SELECT
    account_id,
    COUNT(*) AS tx_count_30d,
    AVG(amount) AS avg_amount_30d,
    STDDEV(amount) AS std_amount_30d,
    SUM(CASE WHEN is_integer_amount = 1 THEN 1 ELSE 0 END) * 1.0 / COUNT(*) AS integer_ratio_30d
FROM l1_transaction_features
WHERE transaction_time >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY account_id;