2. 特征血缘基础

在机器学习工程中，我们经常能回答“这张表来自哪个库”，却很难回答“这个特征是由哪些原始字段、经过哪些变换、在哪个时间窗口内计算出来的”。当模型效果突然下降、线上特征分布漂移、或需要排查训练数据泄漏时，缺失的正是特征血缘。本节从定义出发，厘清它与数据血缘的边界，并给出可落地的应用场景。

一、核心定义：什么是特征血缘

特征血缘（Feature Lineage）是对一个特征从“原始数据”到“模型输入”全链路的可追溯描述。它记录的不只是数据表之间的依赖，而是特征级别的来源、变换逻辑、计算参数、版本与消费关系。一个完整的特征血缘节点通常包含以下要素：

• 特征标识：特征名、特征视图（Feature View）、实体主键与时间戳字段。
• 上游来源：原始表、消息流、外部 API、其他派生特征。
• 变换逻辑：SQL、Python UDF、窗口聚合、编码或归一化算子。
• 计算参数：时间窗口、滑动步长、分桶边界、缺失值填充策略。
• 版本与时间：特征定义版本、生效时间、回填批次。
• 下游消费：被哪些训练集、模型、线上服务或监控任务引用。

可以用一个简化结构表达特征血缘的最小单元：

feature: user_7d_avg_order_amount
entity: user_id
timestamp: event_time
source:
  - table: ods_order_detail
    fields: [user_id, pay_amount, pay_time]
transform:
  type: window_aggregation
  window: 7d
  agg: avg
  filter: pay_status = 'SUCCESS'
version: v3
consumers:
  - training_set: rank_model_train_202406
  - online_service: rank_service_v2

这段描述让任何一位工程师都能回答：该特征从哪来、怎么算、算的是哪段时间、被谁用了。这正是特征血缘的核心价值——把“特征”从黑盒变量变成可审计的工程资产。

二、特征血缘与数据血缘的区别

数据血缘关注“表与表、字段与字段”的流转，典型问题是“这张报表的数据来自哪些库表”。特征血缘则进一步下沉到语义层与模型消费层，关注“这个特征在业务上代表什么、在时间上是否合法、是否被模型正确使用”。二者不是替代关系，而是层次递进关系。

三、方法流程：如何构建一条可用的特征血缘

构建特征血缘不是一次性文档工作，而是嵌入特征生命周期的持续过程。推荐按以下五步推进：

1. 特征注册：在特征注册中心声明特征名、实体、时间戳、数据类型与负责人。
2. 变换捕获：从 SQL 解析、UDF 注解或特征定义 DSL 中抽取算子与参数。
3. 依赖解析：将上游表字段与特征算子绑定，形成字段级到特征级的映射。
4. 消费登记：训练任务、推理服务、监控任务在读取特征时上报消费关系。
5. 版本与审计：每次特征定义变更生成新版本，保留生效时间与回填记录。

下面是一个特征定义 DSL 的片段，它同时承担“计算逻辑”和“血缘声明”两种职责：

feature_view: user_order_features
entities: [user_id]
source: ods_order_detail
features:
  - name: user_7d_avg_order_amount
    dtype: float
    transform: avg(pay_amount) over 7d
    filter: pay_status = 'SUCCESS'
    timestamp: pay_time
    owner: growth-algo

当该 DSL 被注册中心解析后，系统即可自动生成“字段 → 算子 → 特征 → 消费方”的有向图。下图展示了特征血缘的核心结构：左侧是原始字段，中间是变换算子与时间窗口，右侧是特征及其消费端，箭头方向表示依赖与数据流向。

四、应用场景：特征血缘真正解决的问题

特征血缘不是“画一张好看的图”，而是直接服务于以下高频工程场景：

• 训练数据防泄漏：通过时间戳与窗口血缘，判断特征在样本时间点是否“未来可知”，识别标签穿越与窗口穿越。
• 特征影响分析：当上游表字段变更或任务延迟时，快速定位受影响的特征、模型与线上服务。
• 特征复用与去重：发现语义相同但命名不同的特征，减少重复计算与存储成本。
• 线上问题排查：模型效果下降时，沿血缘回溯特征计算链路，定位是数据延迟、算子变更还是版本错配。
• 合规与审计：回答“该特征是否使用了用户敏感字段”“是否满足数据使用授权”。

五、常见误区与复盘

在实际落地中，团队常陷入以下误区：

1. 把数据血缘当特征血缘用：只追踪到表级，无法回答特征窗口与算子参数，防泄漏时仍然失效。
2. 血缘只在文档里：离线文档很快过期，必须让血缘从特征定义中自动生成。
3. 忽略版本与时间：特征定义变更后没有版本记录，导致历史训练集无法复现。
4. 消费端不上报：只记录特征生产，不记录谁在用，影响分析时无法闭环。
5. 追求大而全：一开始就试图覆盖所有特征，不如先覆盖高风险、高复用、强时间依赖的核心特征。