2. 特征工程基础

在特征回填、回放与一致性治理的实战中，很多问题并不是出在计算引擎或调度系统，而是出在对“特征”本身的理解偏差。有人把特征当成一张宽表里的列，有人把特征当成实时接口返回的字段，也有人把特征当成模型训练时临时拼出来的数值。这些理解在各自场景下都不算错，但一旦进入跨离线、近线、在线的生产体系，就会暴露出定义不清、类型混乱、生命周期失控等问题。因此，在讨论回填与回放之前，必须先回到特征工程的基础：特征是什么、有哪些类型、它从产生到消亡经历哪些阶段。

一、特征定义：不是“字段”，而是可复用的业务语义单元

从工程视角看，特征可以定义为：在特定时间点、特定实体上，由确定的数据源和计算逻辑产出的、可供模型或规则消费的数值化或类别化信息。这个定义包含四个关键约束：实体、时间点、计算逻辑、消费形式。缺少任何一个，特征就会退化成普通字段。

例如，“用户最近7天支付金额”是一个特征，因为它明确了实体（用户）、时间窗口（最近7天）、计算逻辑（支付金额求和）和消费形式（数值）。而“用户表里的 amount 字段”不是特征，它只是原始数据，没有时间窗口和聚合语义。理解这一点，是后续做特征回填和一致性校验的前提。

二、特征类型：按数据形态与计算方式分类

特征类型决定了存储结构、回填策略和一致性校验方式。常见分类可以从两个维度展开：数据形态和计算方式。

按计算方式，又可分为原始特征（直接取自业务表）、统计特征（聚合、窗口计算）、组合特征（多特征交叉）、衍生特征（模型打分或规则输出）。不同类型在回放时的可重算性差异很大：原始特征通常可重放，统计特征依赖历史快照，组合与衍生特征则强依赖版本。

三、特征生命周期：从定义到退役的六个阶段

特征不是一次性产物，它有自己的生命周期。把生命周期管清楚，回填和回放才有依据。典型生命周期包括：

1. 定义与注册：明确实体、时间语义、计算逻辑、负责人，写入特征注册表。
2. 开发与验证：在离线环境实现计算逻辑，做数据质量与分布校验。
3. 上线与发布：生成版本号，发布到离线、近线、在线存储，配置SLA。
4. 消费与监控：被训练、推理、规则消费，监控覆盖率、延迟、漂移。
5. 变更与回填：逻辑或数据源变更时，触发回填与回放验证。
6. 退役与归档：停止消费，保留历史版本，清理存储与调度任务。

其中，变更与回填是最容易出问题的阶段。很多团队在修改特征逻辑后，只重算最新分区，不回溯历史，导致训练集和推理集特征口径不一致。回放则是验证这种不一致的手段：用历史时间点重放计算逻辑，对比新旧结果。

四、案例与场景：一次特征变更引发的回填事故

某电商团队将“用户近7天支付金额”从“按下单时间统计”改为“按支付时间统计”。开发同学只重算了最新一天的分区，训练集仍使用旧逻辑。结果离线AUC提升，但线上效果下降。复盘发现：训练集和推理集的特征口径不一致，且历史回填缺失。

正确的做法是：

• 在特征注册表中记录逻辑版本，变更时生成新版本号。
• 对历史分区执行回填，回填范围覆盖训练样本时间窗口。
• 用回放任务在若干历史时间点重放新旧逻辑，对比差异。
• 差异超过阈值时阻断发布，而不是直接上线。

# 回填任务示例（伪代码）
feature: user_pay_amt_7d
version: v2
logic: sum(pay_amount) where pay_time in [t-7d, t)
backfill_range: 2024-01-01 ~ 2024-06-30
replay_points: 2024-03-01, 2024-04-01, 2024-05-01
compare: v1 vs v2
threshold: max_diff_ratio < 0.01
action: block_release_if_exceeded

五、常见误区与复盘要点

在特征工程基础阶段，最常见的误区有：把字段当特征、忽略时间语义、类型混用、生命周期缺失、回填范围不足。复盘时可以问五个问题：

1. 这个特征的实体和时间窗口是否明确？
2. 它的类型是否决定了正确的存储与回填方式？
3. 它当前处于生命周期的哪个阶段？
4. 变更时是否触发了回填与回放？
5. 新旧版本的一致性校验是否通过？