建立特徵管線
使用時機
- 從倉儲/串流資料為 ML 模型工程化特徵。
- 防止標籤洩漏與訓練/服務偏差。
- 設定特徵儲存、線上服務或歷史回填。
- 除非是為了提供 ML 特徵，否則不要用於一般的建模/聚合（請使用 dbt/Spark 技能）。
工作流程
- [ ] 為每個特徵定義實體鍵與事件時間戳記
- [ ] 使用時間點正確的聯結（以標籤時間為準）建構訓練集
- [ ] 為離線（訓練）與線上（服務）共用**同一份**定義
- [ ] 設定線上特徵的新鮮度/具現化
- [ ] 以等幂方式回填歷史特徵以供訓練
- 時間點正確性。 以每個標籤的時間戳記為準聯結特徵——僅使用在預測時間點之前已知的資料。這可以防止標籤洩漏，這是最具破壞性的特徵錯誤。
- 離線/線上一致性。 以相同方式為訓練（離線、批次）與服務（線上、低延遲）計算特徵。邏輯不一致會導致訓練/服務偏差與無聲的生產環境效能衰退。
- 新鮮度。 線上特徵必須依排程具現化，以符合模型對過時資料的容忍度。
- 等幂回填。 重新計算歷史特徵必須可重複複製（請參閱
designing-backfills-and-replays）。
模式
時間點（as-of）聯結——選取每個標籤事件之前的最新特徵值：
SELECT l.entity_id, l.label_ts, f.value AS feature
FROM labels l
LEFT JOIN features f
ON f.entity_id = l.entity_id
AND f.event_ts <= l.label_ts -- 僅過去的資料；無洩漏
QUALIFY ROW_NUMBER() OVER (
PARTITION BY l.entity_id, l.label_ts ORDER BY f.event_ts DESC) = 1;
單一定義，雙重路徑——一次定義特徵（例如 Feast FeatureView）；具現化到離線儲存供訓練使用，並具現化到線上儲存供服務使用，如此兩者皆使用相同的邏輯。
新鮮度 + 具現化——排程線上具現化作業；像監控任何資料集服務水準協議一樣監控特徵新鮮度（implementing-pipeline-observability）。
常見陷阱
- 標籤洩漏——聯結在標籤時間之後計算的特徵會虛增離線指標，並在生產環境中崩潰；務必使用 as-of 聯結。
- 訓練/服務偏差——分開的離線與線上實作會產生偏差；共用一份定義。
- 過時的線上特徵——模型使用舊值進行服務；設定並監控新鮮度。
- 不可重複複製的回填——不一致的訓練歷史；讓特徵重新計算具有等幂性。
- 缺少實體/時間戳記鍵——特徵無法跨時間正確聯結；兩者都需要。
- 無版本控制的特徵——無聲的重新定義會破壞模型可比性；對特徵定義進行版本控制。