特徴量パイプラインの構築 は何をしますか？
使用すべき場面
- ウェアハウス/ストリームデータからMLモデル用の特徴量をエンジニアリングする場合。
- ラベルリークやトレイン/サーブスキューを防ぐ場合。
- 特徴量ストア、オンライン推論、または履歴バックフィルを設定する場合。
- 一般的なモデリング/集約（dbt/Sparkのスキルを使用）には使用しないこと。ただし、ML特徴量にフィードする場合は除く。
ワークフロー
- [ ] 各特徴量をエンティティキーとイベントタイムスタンプで定義する
- [ ] ポイントインタイム正しい結合（ラベル時刻時点）でトレーニングセットを構築する
- [ ] オフライン（トレーニング）とオンライン（推論）で1つの定義を共有する
- [ ] オンライン特徴量の鮮度/マテリアライゼーションを設定する
- [ ] トレーニング用に履歴特徴量を冪等にバックフィルする
- ポイントインタイムの正確性。 各ラベルのタイムスタンプ時点で特徴量を結合する — 予測時刻より前に分かっていたデータのみを使用する。これにより、最も有害な特徴量バグであるラベルリークを防ぐ。
- オフライン/オンラインのパリティ。 トレーニング（オフライン、バッチ）と推論（オンライン、低レイテンシ）で同じ方法で特徴量を計算する。ロジックが異なるとトレイン/サーブスキューが発生し、プロダクションで静かに劣化する。
- 鮮度。 オンライン特徴量は、モデルの許容する古さに合わせたスケジュールでマテリアライズする必要がある。
- 冪等なバックフィル。 履歴特徴量の再計算は繰り返し可能でなければならない（
designing-backfills-and-replaysを参照）。
パターン
ポイントインタイム（時点）結合 — 各ラベルイベントの厳密に前の最新特徴量値を選択する：
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;
単一の定義、2つのパス — 特徴量を一度定義し（例：Feast FeatureView）、トレーニング用にオフラインストアへ、推論用にオンラインストアへマテリアライズする。これにより、両方で同一のロジックが使用される。
鮮度とマテリアライゼーション — オンラインマテリアライゼーションをスケジュールする；特徴量の鮮度を他のデータセットSLAと同様に監視する（implementing-pipeline-observability を参照）。
よくある落とし穴
- ラベルリーク — ラベル時刻より後に計算された特徴量を結合すると、オフラインメトリクスが水増しされ、プロダクションで劣化する；常に時点結合を行う。
- トレイン/サーブスキュー — オフラインとオンラインの実装が分離するとドリフトする；1つの定義を共有する。
- 古いオンライン特徴量 — モデルが古い値で推論する；鮮度を設定し監視する。
- 再現不可能なバックフィル — 一貫性のないトレーニング履歴；特徴量の再計算を冪等にする。
- エンティティ/タイムスタンプキーの欠落 — 特徴量を時間をまたいで正しく結合できない；両方を必須にする。
- バージョン管理されていない特徴量 — 静かな再定義がモデルの比較可能性を損なう；特徴量定義をバージョン管理する。