Feature Store
フィーチャーストアとは何か、オフラインストアとオンラインストアがトレーニングとサービングのスキューをどのように防ぐのか、そしてスケーラブルなMLOpsにおいてなぜ特徴量管理が重要なのかを学びます。
フィーチャーストアは、機械学習モデルで使用されるデータ特徴量を管理、保存、検出、提供するための中央集約型システムです。チームがトレーニングと本番推論で同じ特徴量定義を適用できるよう支援し、重複した作業や不整合を削減します。例えば、複数のパイプラインで顧客の「過去30日間の購入回数」という値を再構築する代わりに、チームはその定義を1回作成し、その履歴を維持し、モデルが予測を行う際に最新の値を取得することができます。
フィーチャーストアの仕組み#
特徴量とは、アカウントの経過日数、平均トランザクション金額、検出されたオブジェクトの数、画像埋め込みなど、モデルに対する測定可能な入力です。生データは、特徴量エンジニアリングまたは自動化された特徴量抽出を通じて、有用なモデル入力となります。
一般的なフィーチャーストアは、いくつかのコンポーネントを調整します。
- 特徴量定義: スキーマは、各特徴量の名前、データ型、所有者、変換ロジック、エンティティキー、バージョンを記述します。Amazon SageMaker Feature Store conceptsで説明されているように、関連する特徴量は特徴量グループやビューに整理される場合があります。
- オフラインストア: 履歴値は、探索、トレーニング、検証、バッチ推論をサポートします。Feast offline store documentationでは、履歴となる時系列特徴量が基盤となるデータソースからどのように取得されるかが説明されています。
- オンラインストア: リアルタイム予測のために、最新の値が低レイテンシデータベースに保持されます。例えば、Feast online storeは通常、各エンティティキーの最新の値を保持します。
- マテリアライゼーション: スケジュールされた処理やストリーミング処理によって、計算された特徴量の値がオンラインストアに移動されます。
- レジストリとメタデータ: 検索可能な定義により、チームは特徴量の検出、ガバナンス、バージョニング、再利用を行うことができます。
エンティティは、特徴量が何について説明しているかを特定します。顧客ID、製品ID、マシンID、またはカメラIDである場合があります。イベントタイムスタンプは、書き込まれた日時ではなく、その値が有効だった日時を記録します。
フィーチャーストアが重要な理由#
主なメリットの1つは、トレーニングとサービングの間の一貫性です。モデルが1つの計算でトレーニングされたにもかかわらず、本番環境でわずかに異なる計算を受け取った場合、トレーニングとサービングのスキューによって予測品質が低下する可能性があります。中央集約された定義と共有される取得ロジックにより、これが起こりにくくなります。
時間認識型の取得も同様に重要です。トレーニングの行には、予測されたイベントが発生した時点ですでに存在していた情報のみを含める必要があります。Point-in-time joins in Feastは、それらの履歴値を再構築し、将来の情報からのデータ漏洩を防ぐのに役立ちます。同様に、Google Cloudのfeature-serving guidanceでは、時間に敏感な特徴量に対するタイムスタンプとポイントインタイムルックアップの重要性が強調されています。
また、フィーチャーストアは以下をサポートします。
- 再利用: 複数のモデルが、パイプラインを再構築することなく、信頼できる特徴量を利用できます。
- 鮮度: ストリーミング更新により、リアルタイム入力を最新の状態に保つことができます。
- ガバナンス: 所有権、リネージ、アクセス制御、バージョンにより、特徴量の監査が容易になります。
- モニタリング: チームは、欠損値、古いレコード、スキーマ変更、データドリフトを検出できます。
これらの機能により、フィーチャーストアは本番環境のMLOpsにおいて重要な要素となります。特に、多くのモデルやチームが共有データに依存している場合に重要です。
関連システムとの比較におけるフィーチャーストア#
フィーチャーストアは、単なる別のデータベースではありません。
- データレイクは大量の生データまたは処理済みデータを保持しますが、フィーチャーストアはモデル指向の定義、タイムスタンプ、取得ロジック、およびサービングインターフェースを追加します。
- ベクトルデータベースは、ベクトルに対する類似性検索を専門としています。フィーチャーストアは埋め込みを管理することもできますが、スカラー、カテゴリカル、集約、時系列の特徴量を保持することもできます。
- 特徴量エンジニアリングパイプラインは特徴量を計算し、フィーチャーストアは結果の値を管理および提供します。
- モデルレジストリがモデルのバージョンやアーティファクトを管理するのに対し、フィーチャーストアはモデルへの入力を管理します。
管理されたシステムでは、これらの責任のいくつかが統合されている場合があります。例えば、Azure Machine Learning managed feature storesは、特徴量の発見、バージョニング、マテリアライゼーション、履歴取得を提供します。
実社会での応用#
不正検出: 決済モデルでは、トランザクションの速度、平均購入金額、アカウントの経過日数、最近の支払い失敗回数を使用する場合があります。オフラインストアはトレーニング用の履歴値を再構築し、オンラインストアは新しいトランザクションが到着したときにミリ秒単位で現在の値を提供します。
コンピュータビジョン検査: 製造システムは、生産ラインとタイムスタンプをキーとして、ローリング欠陥カウント、機器の状態、シフトメタデータ、視覚的な埋め込みを保存できます。履歴特徴量は再トレーニングをサポートし、現在の値はデプロイされたモデルが新しい検出を解釈するのに役立ちます。チームはUltralytics Platformを使用して画像、アノテーション、トレーニング、デプロイ、モニタリングを管理し、別のフィーチャーストアが運用入力を提供することができます。
Ultralytics YOLO26は、後でエンティティID、タイムスタンプ、バージョンメタデータと共に登録できる画像特徴量を生成できます。
from ultralytics import YOLO
model = YOLO("yolo26n.pt")
images = [
"https://ultralytics.com/images/bus.jpg",
"https://ultralytics.com/images/zidane.jpg",
]
embeddings = model.embed(images)
first_image_features = embeddings[0]
print(len(embeddings))
print(first_image_features.shape)この例では、完全なフィーチャーストア管理ではなく、特徴量抽出を実行しています。本番ワークフローでは、Google Cloud ML quality guidelinesなどのプラクティスを使用して、ベクトルの検証、レコードおよびイベント時刻との関連付け、履歴バージョンの保存、および鮮度と品質のモニタリングを行います。
