特徴量ストアとは

機械学習において、特徴量とは、モデルが予測を生成するためのインプットとして使用される未加工データから導出された変数または属性です。これらは、購入頻度や地理的位置など、データ内の行動、コンテキスト、状態の測定可能な側面を表します。

例えば、不正アクセス検知、モデルは未加工データではなく、キュレートされたシグナルに依存します。特徴量には、過去1週間の取引数や最近の購入場所などが含まれる場合があります。これらは、不正行為を示す可能性のあるパターンを捉えるように設計された表現です。

特徴量はしばしばML特徴量と呼ばれ、複数のデータ・ソースから生成され、データサイエンスと機械学習の両方のワークフローをサポートするデータセットに整理されます。これらの特徴量はモデルのトレーニング、メトリクスの評価、モデルの本番システムへのデプロイに使用されます。

機械学習モデルは、データの数値表現に基づいて動作します。各データ点は特徴値の集合として表現され、多くの場合ベクトル形式で表され、各次元は特定の属性に対応しています。会計情報のように本質的に数値的な構造化データ型もあれば、テキスト、画像、音声のように非構造化データ型もあり、モデルで使用する前に構造化された数値形式に変換する必要があります。

非構造化データを変換する一つの方法は特徴工学であり、未加工データを集約、フィルタリング、エンコーディングなどの技術を用いて構造化された機械可読のインプットに変換します。特徴工学には特徴量抽出（未加工データから意味のある表現を導き出すアルゴリズム）や特徴量選択（最も関連性の高い変数を特定する）も含まれます。

機械学習ワークフローはモデルの学習と推論にまたがるため、特徴量は過去のデータと生産中の新しいデータの両方から計算されます。整合性を維持するには、データ・パイプライン、特徴量パイプライン、データ・エンジニアリング・システム間の調整が必要であり、これは特徴量ストアが解決するために設計された課題です。

実際には、特徴量ストアは機械学習ライフサイクルの各段階をサポートします。

• 特徴量エンジニアリングと開発：新しい特徴量を定義するための構造化された環境を提供し、チームが特徴量を共有したり、特徴量を再利用したり、重複した実装を回避したりできるようにします。

• モデル・トレーニング：過去の特徴量データとトレーニング・データを提供し、モデルが信頼できるデータセットでトレーニングされるようにします。

• 推論とサービング：オンライン特徴量ストアシステムを通じてリアルタイムに特徴量の値を提供し、低遅延予測を実現します。

• モニタリングと反復：メトリクスを追跡し、スキュー（データの不均一な分布）を検知し、ワークフロー内の特徴量の品質を監視します。

今日の人工知能（AI）システムの多くを支える機械学習モデルの性能は、そのインプット変数の質に直接依存します。入るものが、何が出てくるかを決定します。

特徴量の値は、モデルがトレーニング・データ内のパターンを解釈し、それらのパターンを新しいデータに適用する方法を決定します。この連携は、特徴量データを大規模に管理すると同時に、学習と推論に一貫性を持たせるという2つのことを行うことで、モデルの性能を向上させます。

特徴量データの管理は、機械学習システムが拡張するにつれて、ますます複雑になります。特徴量は、多くの場合、分散環境で作業するデータ・エンジニアリング・チームやMLチームによって、複数のワークフローを通じて生成され、循環します。

一元化されたシステムがなければ、重複した機特徴量や一貫性のない特徴量定義が発生します。チームは同じ特徴量をわずかに異なるロジックで計算し、データセットやパイプライン内で不整合を引き起こす可能性があります。これらの矛盾により、特徴量の再利用が困難になり、モデル開発にリスクが生じます。

モデルのトレーニングでは、特徴量は履歴データから計算され、トレーニング用データセットにまとめられます。一度デプロイされた同じ特徴量定義は、新しいデータに適用され、推論のために再計算されなければなりません。これは、多くの場合、リアルタイムまたはほぼリアルタイムの環境でのことです。

特徴量の計算方法がわずかに異なるだけでも、トレーニングと本番環境のインプットの間に不一致（しばしばトレーニング・サービング・スキューと呼ばれる）が生じ、性能の低下につながる可能性があります。

特徴量ストアは、特徴量定義を一元化し、特徴量変換を標準化することで、これらの課題に対処します。特徴量は一度定義され、共有システムに保管され、アプリケーション・プログラミング・インターフェース（API）またはソフトウェア開発キット（SDK）インターフェースを通じてアクセスされます。多くの場合、特徴量レジストリーを通じて管理されるこの調整により、チームは複数のパイプライン、モデル、ユースケースにわたって特徴量を再利用できるようになります。

特徴量ストア・アーキテクチャーは、次のような機械学習のいくつかの主要な段階間でデータを結び付けます。

• 取り込みとトランスフォーメーション
• ストレージ層
• 特徴量サービング
• 特徴量レジストリーとメタデータ
• オーケストレーションとライフサイクル管理

データは複数のデータ・ソースから収集され、取り込みパイプラインを通じて処理されます。これらのパイプラインは、データと特徴量のトランスフォーメーションを適用して、未加工データを特徴量の値に変換します。

特徴計算は、過去に収集したデータのバッチ処理、リアルタイム更新のためのストリーミングパイプライン、推論時のオンデマンド特徴量計算など、さまざまな方法で行うことができます。これらの変換は、自動化されたワークフローの中で、Python、構造化クエリー言語（SQL）、その他のシステムを使用して実装されることが多いです。

特徴量ストアは、オフライン・ストアとオンライン・ストアの二重ストレージ・モデルを使用します。オフライン・ストア、またはオフライン特徴量ストアは、歴史的な特徴量データを維持し、トレーニング・データおよびトレーニング・データセットへのアクセスを提供することでモデル・トレーニングをサポートします。通常、データウェアハウスやデータレイクの上に構築されます。

オンライン・ストア、つまりオンライン特徴量ストアは、現在の特徴量の値を維持し、モデル推論中の低遅延ルックアップをサポートします。このようにオフライン・ストアとオンライン・ストアを分離することで、さまざまなワークロードにわたる拡張性と性能の両方が可能になります。

特徴量サービングとは、機械学習モデルに特徴量の値を提供するプロセスです。APIまたはSDKレイヤーを使用すると、アプリケーションは環境間の特徴量を取得できるため、特徴量定義の整合性が維持されます。また、トレーニング・サービングの歪みを最小限に抑え、予測を行う際にモデルが最新の特徴量の値を確実に受け取るようにするのにも役立ちます。

特徴量レジストリーは、特徴量定義の集中型記録システムとして機能します。メタデータ、リネージュ、バージョン情報を保管し、特徴量がどのように構築され、どこで使われているかを可視化します。このトレーサビリティーによって、再利用可能な特徴量の発見、ガバナンスとアクセス制御の実施、ワークフロー内の依存関係の追跡が容易になります。

特徴量ストアは、特徴量ライフサイクル全体にわたってパイプラインとワークフローをオーケストレーションします。一般的なタスクには、特徴量計算の自動化、ヒストリカル特徴量データのバックフィル・オペレーション管理、定義変更時の特徴量の再計算、重複している特徴量や古い特徴量の特定などがあります。したがって、オーケストレーションによって、特徴量パイプラインの信頼性とスケーラビリティーがデータ・プラットフォーム全体で維持されます。

実装はさまざまですが、ほとんどの特徴量ストアはコア・アーキテクチャーを超えて一貫した機能セットを提供し、スケーラブルで信頼性の高い機械学習ワークフローを実現します。

これらの機能を組み合わせることで、機械学習ワークフローにおける特徴量データの管理方法が定義されます。それらはまた、特徴量ストアがより広範なデータ・アーキテクチャー内でどのように適合するかを反映します。

従来のデータ・システム（ウェアハウスやその他のデータストアなど）は、組織全体でデータを処理し、移動するように設計されています。ただし、このデータは本質的に機械学習に適しているわけではありません。

特徴量ストアは、特徴量データを機械学習モデルの再利用可能なインプットに整理し、開発および実稼働段階での特徴量定義、計算、提供方法を標準化することでこの基盤の上に構築されます。

特徴量ストアは、機械学習システムの開発と維持の方法を改善する一連の実用的な利点を提供します。

• モデル開発効率の向上：再利用可能な特徴量定義により、新しいプロジェクトごとに特徴量を再構築する必要が減り、チームはデータの準備ではなくモデルの設計に集中できるようになります。

• 機械学習モデル間の一貫性：標準化された特徴量パイプラインにより、トレーニングと推論中に特徴量が同じ方法で計算されることが保証され、トレーニング・サービング・スキューのリスクが軽減されます。

• チーム間の強力なコラボレーション：特徴量データを一元管理することで、データサイエンティスト、データ・エンジニアリング、MLチームが特徴量を共有し、共通の記録システム（SOR）で作業できるようになります。

• ガバナンスとトレーサビリティー：特徴量ストアは構造化されたSORを特徴量定義に導入し、モデル間で特徴量の定義や使用方法を理解しやすくしつつ、一貫した標準を強制します。

• リアルタイム機械学習のサポート：特徴量ストアはオンライン特徴量ストアシステムを通じて特徴量の値への低遅延アクセスを提供し、ハイパーパーソナライゼーションやレコメンデーション・エンジンなどのユースケースをサポートします。

• スケーラブルで反復可能なワークフロー：自動化された特徴量パイプラインとオーケストレーションは、機械学習オペレーション（MLOps）をサポートします。これにより、組織はチームやユースケースの間で機械学習システムを拡張できるようになります。

特徴量ストアは、最適化されたストレージ層やRedisのようなキー値システムを用いて高スループットの特徴量サービングも可能にし、これらは最新のデータ・プラットフォームで管理されたインメモリー・サービスとして一般的に展開されています。このアプローチは、モデルが最新の特徴量の値を効率的に取得するのに役立ちます。

特徴量ストアの選択は、組織のデータ・アーキテクチャー、インフラストラクチャー、機械学習の成熟度によって異なります。一般的な考慮事項には以下が含まれます。

• 既存のデータ・プラットフォームとの統合
• オープンソースおよび管理型オプション
• アーキテクチャーの要件とワークロード
• ガバナンスと信頼

特徴量ストアは、既存のデータ・パイプライン、データウェアハウス、データレイク、より広範なデータ・プラットフォームシステムと連携する必要があります。しかし、特徴量パイプラインを確立されたワークフローに統合するには、多くの場合、データ変換の リファクタリング やチーム間の調整が必要になります。

そのため、組織は通常、特徴量ストアがSnowflake、Databricks、 SageMaker Feature StoreなどのAWSサービスといった既存のツールとどのように統合できるかを評価することから始めます。多くの場合、特徴量ストアは、データ・エンジニアリングとモデル展開をつなぐ、より広範なMLOpsシステムの一部として統合されています。¹

特徴量ストアの実装は多岐にわたり、組織は性能、拡張性、運用の複雑さのバランスを継続的に取っています。² オープンソース特徴量ストア・フレームワークであるFeastなどでは、企業は独自の特徴量パイプラインやインフラストラクチャーを構築および管理できますが、Tectonなどのプラットフォームでは、フルマネージドの本番環境対応ソリューションが提供されます。

しかし、UberのMichelangeloのように、より広範なシステムの一部として特徴量ストアの機能を含む、独自のエンドツーエンドの機械学習プラットフォームを構築することを選択する組織もあります。最終的に、特徴量ストアを構築するか採用するかの意思決定は、社内の専門知識と長期的な拡張性の要件によって決まります。

アーキテクチャー要件が中心的な役割を果たします。ユースケースによっては、リアルタイムまたは低遅延の特徴量サービングが必要ですが、バッチ処理またはオンデマンド特徴量計算に依存するユースケースもあります。データ量が増えるにつれて、高スループット要件もインフラストラクチャーに大きな要求が課せられます。

オフラインとオンラインの特徴量の値間の一貫性を維持すると、ヒストリカルデータ処理とリアルタイム推論の両方のサポートが複雑になります。調査では、特徴量ストアの設計がこうしたワークロード要件によって進められることが多いことや、レイテンシー、スケーラビリティー、ポイントインタイムの正確性などの問題が指摘されています。³

ガバナンスも同様に重要です。特徴量ストアは共有特徴量データ上で運用されるため、組織は特徴量がどのように定義、テスト、使用されているかを明確に可視化する必要があります。

特徴量データがチーム間で共有されるため、組織はデータ漏洩を防ぎ、特徴量が一貫して計算されるようにするための制御を下す必要があります。正式なガバナンス・フレームワークは、特徴量パイプライン全体の一貫性、リネージュ、コンプライアンスをサポートし、⁴ 機械学習システムの信頼性を維持するのに役立ちます。