LESSON 30分

ストーリー

田中VPoE
モデルの管理ができるようになった。次は「特徴量ストア」だ。同じ特徴量を複数のチームが別々に計算している現状を知っているか?
あなた
確かに、顧客の購買頻度の計算方法がチームごとに微妙に違っていて、モデルの結果も異なっていました
田中VPoE
それが「特徴量の断片化」問題だ。特徴量ストアは、特徴量の一元管理と再利用を実現する。学習時と推論時で同じ特徴量を使えることが最大のメリットだ
あなた
Training-Serving Skewの問題も解消できるんですね

特徴量ストアとは

従来の課題

課題具体例
重複計算同じ「顧客の平均購入額」を5チームが個別に計算
定義のずれチームAは30日平均、チームBは90日平均
Training-Serving Skew学習時と推論時で特徴量の計算ロジックが異なる
ディスカバリ困難どんな特徴量が既に存在するか分からない

特徴量ストアの構成

データソース → 特徴量パイプライン → 特徴量ストア → 学習/推論

                               ┌──────┴──────┐
                          オフラインストア  オンラインストア
                          (バッチ学習用)    (リアルタイム推論用)

主要な特徴量ストア

ツール特徴ユースケース
FeastOSS、シンプル中小規模、学習コスト低
Tectonマネージド、高機能大規模、リアルタイム重視
HopsworksOSS、フル機能エンタープライズ
SageMaker Feature StoreAWS統合AWSエコシステム
Vertex AI Feature StoreGCP統合GCPエコシステム

特徴量の種類

種類更新頻度
バッチ特徴量時間〜日単位月間購入回数、平均注文額
ストリーミング特徴量秒〜分単位直近10分の閲覧数
リクエスト時特徴量リアルタイム現在のデバイス、位置情報

Feastの基本概念

from feast import FeatureStore, Entity, FeatureView, Field
from feast.types import Float64, Int64

# エンティティ定義
customer = Entity(
    name="customer_id",
    join_keys=["customer_id"],
)

# 特徴量ビュー定義
customer_features = FeatureView(
    name="customer_features",
    entities=[customer],
    schema=[
        Field(name="total_purchases", dtype=Int64),
        Field(name="avg_order_value", dtype=Float64),
        Field(name="days_since_last_order", dtype=Int64),
    ],
    source=customer_data_source,
)

特徴量ストア導入のメリット

メリット効果
再利用性特徴量の重複開発を80%削減
一貫性Training-Serving Skewを排除
ディスカバリ既存特徴量を検索・再利用可能
ガバナンス誰がいつ何を使ったかを追跡

まとめ

  • 特徴量ストアは特徴量の一元管理と再利用を実現する基盤
  • オフラインストア(学習用)とオンラインストア(推論用)の2層構造
  • Training-Serving Skewの解消が最大のメリット
  • Feast、Tecton、クラウドマネージドなど選択肢がある

チェックリスト

  • 特徴量ストアの必要性を説明できる
  • オフライン/オンラインストアの違いを理解した
  • 主要なツールの特徴を把握した
  • Feastの基本概念を理解した

次のステップへ

次は特徴量エンジニアリングのベストプラクティスを学び、再利用性の高い特徴量を設計する方法を習得します。

推定読了時間: 30分