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

2. 金融特征工程基础

在金融机器学习项目中，模型效果的上限往往由特征决定，而特征能否被稳定、可追溯、低延迟地供给，则由特征存储决定。理解“特征—特征工程—特征存储”三者的关系，是构建金融级特征平台的第一块基石。本节将从核心概念出发，结合金融场景的特殊约束，给出可落地的认知框架。

一、核心概念：特征、特征工程与特征存储

特征（Feature）是模型输入的可量化信号，是对原始数据的一次或多次变换结果。例如，原始交易流水是数据，而“用户近7天平均单笔消费金额”才是特征。特征具有三个关键属性：实体（Entity）、时间戳（Timestamp）和值（Value）。在金融场景中，实体通常是客户、账户、商户、产品、设备等；时间戳决定了特征在某一时刻的有效性；值则是数值、类别、向量或嵌入。

特征工程（Feature Engineering）是将原始数据转化为模型可用特征的完整过程，包括数据清洗、聚合、窗口计算、编码、归一化、交叉组合等。它不仅是技术操作，更是业务知识的编码过程。例如，风控中的“近30天夜间交易占比”背后是对欺诈行为模式的理解。

特征存储（Feature Store）是特征工程与模型训练、推理之间的中间层，负责特征的注册、存储、版本管理、在线/离线一致性供给。它解决的核心问题是：训练与推理特征不一致（Training-Serving Skew）、特征重复开发、特征血缘缺失和时间点正确性（Point-in-Time Correctness）。

一句话总结：特征是原料，特征工程是加工工艺，特征存储是仓库与物流系统。三者缺一不可，而金融场景对“物流”的时效性、一致性和可审计性要求远高于一般行业。

二、金融场景的特殊性：为什么通用特征工程不够用

金融业务对特征工程提出了远超互联网推荐场景的约束，主要体现在以下五个方面：

强时间依赖与防穿越：金融特征必须严格遵循“当时可知”原则。计算2024年3月1日的违约风险特征时，只能使用该时点之前产生的数据，否则会造成标签泄漏，模型离线AUC虚高、上线后失效。
在线推理低延迟：支付反欺诈、实时授信等场景要求特征在几十毫秒内返回，特征存储必须支持高并发点查，而非批量扫描。
离线在线一致性：同一特征在训练时用Spark计算、推理时用Flink或Redis计算，若逻辑不一致，模型表现会断崖式下跌。
强监管与可审计：金融模型需满足监管审查，特征的定义、来源、变换逻辑、版本变更必须可追溯、可复现。
高基数与稀疏性：商户ID、设备指纹、银行卡号等实体基数极大，特征维度高且稀疏，对存储和计算提出更高要求。

下表对比了通用推荐场景与金融场景在特征工程关键维度上的差异：

维度	通用推荐场景	金融场景
时间正确性要求	中等，允许近似	极高，必须严格Point-in-Time
在线延迟要求	百毫秒级可接受	十毫秒级，部分场景要求毫秒级
一致性要求	尽力而为	强一致，训练推理必须对齐
可审计性	一般	强监管，全链路血缘
实体基数	用户、物品，中等	客户、账户、商户、设备，极高
特征更新频率	天级/小时级	实时/秒级/天级混合

三、方法流程：从原始数据到可服务特征

金融特征工程的标准流程可归纳为六个阶段，每个阶段都需要特征存储的参与：

需求定义：明确模型目标、实体、标签口径和特征候选集，形成特征需求文档。
数据探查与清洗：处理缺失、异常、重复，统一时间口径和实体主键。
特征变换：窗口聚合、比率、趋势、交叉、编码等，输出特征定义。
特征注册：将特征元数据（名称、实体、类型、时间窗口、Owner、版本）写入特征存储。
离线回填与训练集生成：按Point-in-Time逻辑生成训练样本，保证标签与特征时间对齐。
在线服务与监控：将特征同步至在线存储，提供低延迟查询，并监控特征漂移与缺失率。

以下是一个特征注册的元数据配置示例，展示了金融特征存储中常见的字段定义：

feature:
  name: user_night_txn_ratio_30d
  entity: customer_id
  dtype: float32
  description: "近30天夜间交易笔数占比"
  owner: risk_team
  source: dwd_transaction_detail
  transformation: |
    SELECT customer_id,
           SUM(CASE WHEN hour(txn_time) BETWEEN 0 AND 5 THEN 1 ELSE 0 END)
           / COUNT(1) AS night_ratio
    FROM dwd_transaction_detail
    WHERE txn_time >= date_sub(current_date, 30)
    GROUP BY customer_id
  online_ttl: 7d
  offline_ttl: 365d
  version: v1.2
  tags: [risk, fraud, realtime]

在金融特征存储中，建议为每个特征强制标注时间窗口、实体主键和Owner。缺少任一字段，后续的Point-in-Time回填和线上排障都会变得极其困难。

四、案例与场景：实时反欺诈中的特征流转

以支付反欺诈为例，一笔交易请求到达时，系统需要在50毫秒内完成特征组装并给出风险评分。此时特征存储需要同时提供三类特征：

实时特征：来自Flink的“近5分钟同设备交易次数”，写入在线存储，延迟秒级。
近线特征：来自Spark Streaming的“近24小时用户交易金额均值”，小时级更新。
离线特征：来自数仓的“用户历史最大单笔金额”，天级更新，但需同步至在线存储。

特征存储在此过程中的核心价值是：统一特征定义、保证离线回填与在线查询使用同一套变换逻辑、并提供特征血缘以便事后审计。若缺少特征存储，团队往往会在训练脚本和线上服务中重复实现特征逻辑，导致“离线AUC 0.92，线上AUC 0.71”的典型事故。

五、常见误区与复盘

误区一：把特征存储当成“特征数据库”。特征存储的核心不是存储，而是一致性供给与时间正确性。只存不治，等于没有。

误区二：离线特征直接同步到线上即可。离线特征往往基于全量历史计算，若不做时间截断，线上推理会用到未来信息，造成严重泄漏。

误区三：特征定义散落在代码中。没有统一注册和版本管理，特征变更后无法回溯，模型复现成本极高。

误区四：忽视特征监控。金融场景中数据分布漂移频繁，缺少缺失率、均值、PSI等监控，模型失效往往在事后才发现。

复盘建议：在项目初期就建立特征注册规范，强制要求每个特征具备实体、时间窗口、Owner、版本和血缘信息；在训练集生成环节引入Point-in-Time校验；在上线前进行离线在线一致性比对，确保同一实体同一时间点的特征值完全一致。只有把特征当作一等公民管理，金融机器学习项目才能从“一次性实验”走向“可持续生产”。