特徴量エンジニアリング - L0 カリキュラム

ストーリー

田

田中VPoE

特徴量ストアの概要を理解したところで、次は「良い特徴量」を設計する方法論だ。特徴量エンジニアリングのベストプラクティスを学ぼう

あなた

モデルの精度は特徴量の質で決まるとよく聞きます

あ

田

田中VPoE

その通り。特に再利用を前提とした特徴量設計は、チーム全体の生産性を大きく向上させる。ネーミング規約から計算の冪等性まで、運用を見据えた設計が重要だ

特徴量設計の原則

命名規約

{entity}_{aggregation}_{metric}_{window}

例	意味
`customer_sum_purchase_amount_30d`	顧客の30日間購入金額合計
`product_avg_rating_90d`	商品の90日間平均評価
`customer_count_login_7d`	顧客の7日間ログイン回数

良い特徴量の条件

条件	説明
冪等性	同じ入力に対して常に同じ出力
タイムスタンプ付き	いつ時点の値かが明確
ドキュメント化	計算ロジック、データソース、オーナーが明記
テスト済み	単体テスト、データ品質チェックがある

特徴量変換パターン

時間ウィンドウ集約

# 複数ウィンドウの特徴量を一度に生成
windows = [7, 14, 30, 90]

for w in windows:
    df[f"purchase_count_{w}d"] = df.groupby("customer_id")["purchase_id"].transform(
        lambda x: x.rolling(f"{w}D").count()
    )
    df[f"purchase_amount_sum_{w}d"] = df.groupby("customer_id")["amount"].transform(
        lambda x: x.rolling(f"{w}D").sum()
    )

カテゴリカル特徴量

手法	用途	注意点
Label Encoding	順序あり	順序の意味を保持
One-Hot Encoding	カテゴリ少数	カーディナリティ爆発に注意
Target Encoding	カテゴリ多数	データリーケージに注意
Embedding	高カーディナリティ	深層学習向け

交互作用特徴量

# 特徴量の組み合わせ
df["price_per_quantity"] = df["total_price"] / df["quantity"]
df["recency_frequency_ratio"] = df["days_since_last"] / (df["purchase_count"] + 1)

特徴量パイプラインの設計

Raw Data → Validation → Transformation → Feature Store → Serving
    │           │              │               │            │
  データソース  品質チェック    変換ロジック    永続化      提供

バッチ vs ストリーミング

方式	更新頻度	処理エンジン	ユースケース
バッチ	時間〜日	Spark / dbt	月間集計、履歴統計
ストリーミング	秒〜分	Flink / Kafka	リアルタイムカウント
オンデマンド	リクエスト時	アプリ内計算	デバイス情報、位置

特徴量のテスト

# データ品質テストの例
def test_feature_not_null(df, feature_name):
    null_ratio = df[feature_name].isnull().mean()
    assert null_ratio < 0.01, f"{feature_name}: null率 {null_ratio:.2%}"

def test_feature_range(df, feature_name, min_val, max_val):
    assert df[feature_name].between(min_val, max_val).all(), \
        f"{feature_name}: 範囲外の値が存在"

def test_feature_distribution(df, feature_name, expected_mean, tolerance=0.1):
    actual_mean = df[feature_name].mean()
    assert abs(actual_mean - expected_mean) / expected_mean < tolerance

まとめ

命名規約を統一し、チーム全体で一貫した特徴量管理を実現する
冪等性、タイムスタンプ、ドキュメント化が良い特徴量の条件
バッチ/ストリーミング/オンデマンドの適切な使い分けが重要
特徴量のテストと品質チェックを自動化する

チェックリスト

特徴量の命名規約を理解した
主要な変換パターンを説明できる
バッチとストリーミングの使い分けが分かる
特徴量テストの重要性を理解した

次のステップへ

次はオンライン/オフラインストアの具体的な設計と、Feature Servingの実装パターンを学びます。

推定読了時間: 30分