ストーリー
田
田中VPoE
モデルの管理ができるようになった。次は「特徴量ストア」だ。同じ特徴量を複数のチームが別々に計算している現状を知っているか?
あなた
確かに、顧客の購買頻度の計算方法がチームごとに微妙に違っていて、モデルの結果も異なっていました
あ
田
田中VPoE
それが「特徴量の断片化」問題だ。特徴量ストアは、特徴量の一元管理と再利用を実現する。学習時と推論時で同じ特徴量を使えることが最大のメリットだ
あなた
Training-Serving Skewの問題も解消できるんですね
あ
特徴量ストアとは
従来の課題
| 課題 | 具体例 |
|---|
| 重複計算 | 同じ「顧客の平均購入額」を5チームが個別に計算 |
| 定義のずれ | チームAは30日平均、チームBは90日平均 |
| Training-Serving Skew | 学習時と推論時で特徴量の計算ロジックが異なる |
| ディスカバリ困難 | どんな特徴量が既に存在するか分からない |
特徴量ストアの構成
データソース → 特徴量パイプライン → 特徴量ストア → 学習/推論
│
┌──────┴──────┐
オフラインストア オンラインストア
(バッチ学習用) (リアルタイム推論用)
主要な特徴量ストア
| ツール | 特徴 | ユースケース |
|---|
| Feast | OSS、シンプル | 中小規模、学習コスト低 |
| Tecton | マネージド、高機能 | 大規模、リアルタイム重視 |
| Hopsworks | OSS、フル機能 | エンタープライズ |
| SageMaker Feature Store | AWS統合 | AWSエコシステム |
| Vertex AI Feature Store | GCP統合 | 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、クラウドマネージドなど選択肢がある
チェックリスト
次のステップへ
次は特徴量エンジニアリングのベストプラクティスを学び、再利用性の高い特徴量を設計する方法を習得します。
推定読了時間: 30分