(ブログタイトル: 5 Minimum Requirements of an Operational Feature Store)

ここで"Operational"ってどう言う意味合いだろ??
- 直訳すると"運用可能な"だと思うけど、ブログの文脈的に"本番システム上に組み込んで実際に価値を発揮する"みたいなニュアンスと解釈してみてる...!
(一応、本記事はn週連続推薦システム系論文読んだシリーズ 41 週目、という位置付けで書いてます。まあMLを使った推薦システムにおいてFeature Storeは重要なコンポーネントなので...! )
- ちなみに40週目はこちら: 推薦システムの実務で人気なTwo-Towerモデルを「反実仮想機械学習」的に勾配ベースアプローチでオフライン学習させてみた!

refs

5 Minimum Requirements of an Operational Feature Store

条件1: Shareableであること

feature storeの基本的な前提は、それが組織全体で共有可能でなければならないこと。特徴量は、それを必要とする任意のチームがアクセスできる必要がある。
- これにより、開発工数が一定かかるような複雑な特徴量も再利用可能になる (埋め込みベクトルとか...!)
特徴量の共有に関するアイデアは、すでに普及してる。
- Twitterは「Sharing Adoption」というmetricを用意して監視してるみたい。
  - link元をたどって読んでいってみると...
    - 自社のFeature Storeの価値や効果を評価するための方法として、Twitterのエンジニアリングチームは、"Sharing Adaption"という指標を採用して監視してるっぽい。(なるほど...! Feature StoreのShareable度合いを測るためのmetricか...!!)
    - Sharing Adaption指標の定義: The number of teams who use another teams' features in production. (他のチームの特徴量を本番環境で使用しているチームの数)
データサイエンティストが検索して再利用できる特徴量達の単一のリポジトリを持つことは、DSの生産性にとって重要である。
- SQLやデータフレームのようなAPIを通じて、様々な特徴量を簡単に検索できることは、DSの成功に重要。

条件2: Transparent (透明性) が高いこと

feature storeが信頼されるためには、各特徴量のorigin(=元のデータソース?)と実装が調査可能である必要がある。
- そのためには、特徴量の生成プロセスが十分に文書化され(=まあコードが追えればいい気がする...!)、全ての人がそのプロセスを辿れるようにすべき。

条件3: Versioned (バージョン管理) されてること

feature storeの中心的なテーマの一つは、collaborativeな開発を促進すること。
- そのためには、前述のshareable & 高いtransparentさに加えて、versionedであることも重要
versionedであることは、以下の2つの形で提供される:
- 1. 特徴量生成 (特徴量がどのように計算されるか) のバージョン管理 (つまりfeature pipelineのプロダクションコードか...!)
- 1. 特徴量そのもの (特徴量が更新された日時) のバージョン管理 (つまり特徴量のevent_timeか...!)
  - 特徴量ユーザが、推論時に誤って古いデータを使ってしまうことを防ぐ。
  - 特徴量がいつ更新されたかを追跡するだけじゃなく、その変更の履歴を保持することが重要。
    - (うんうん、学習時のデータリークを防ぐpoint-in-time correct joinのために、過去のバージョンの特徴量も欲しいので...!)

条件4: Governed & Access Controlled (管理・アクセス制御されてること)

誰が特徴量ストアをクエリできるか、また歴史的に誰がクエリしてきたかに対する強力な管理・アクセス制御が重要。
- feature storeの管理者は、各特徴量へのアクセスを簡単に制限できるべきだし、組織内の誰が特定の特徴量をいつクエリしたかを確認できるべき。
同様に、特徴量のinsert/update/deleteも厳密に制御されるべき。
(この条件のモチベーションは、MLOps技術的負債論文で言及されてた「データ依存関係のスパゲティ化を防ごう」みたいな話かな...!)

条件5:

feature storeは通常、オフラインとオンラインの2つの異なるワークロードに分けられる:
- オフラインワークロード(offline workload):
  - 定期的なバッチでの特徴量作成時に、feature storeに書き込むプロセス
  - MLモデルのオフライン学習時に、feature storeから大規模に特徴量を取得するプロセス
  - MLモデルのバッチ推論時に、feature storeから大規模に特徴量を取得するプロセス
- オンラインワークロード(online workload):
  - streamlingな特徴量作成時に、feature storeに書き込むプロセス
  - MLモデルのリアルタイム推論時に、feature storeから特徴量を取得するプロセス
上記2つのワークロードは、しばしばそれぞれ専用のコンピューティングエンジンを持つ2つの別々のフィーチャーストアによって処理され、必要に応じて相互に通信する。(ex. DWHとRedisなど! )
- そしてこれが問題である!
  - データ不整合のリスク(学習時と推論時の特徴量がズレる...! data skew...!)
  - 同期用のETLパイプラインの必要性、運用コスト増。
  - アーキテクチャの複雑性を増加させる!
- 上記の理由から、劣悪なモデルや悪いビジネス結果につながり得る...!
  - (MLOps処方箋本におけるMLOpsの定義を参考に言い換えると、MLの成果をスケールできない要因となり得る、みたいな...!)
    - ちなみに...MLOps処方箋本のMLOpsの定義は「機械学習の成果をスケールさせるためのさまざまな取り組み」
理想のアーキテクチャ: 単一エンジンで両方の用途をカバーしていること!
- 単一のFeature Storeがバッチも、分析クエリも、低レイテンシーのlookupも対応しているべき。
  - (うんうん、裏側ではオンライン&オフラインに分かれてるとは思うけどけど、少なくとも特徴量を取得するユーザ側にはオンライン&オフラインの境界が情報隠蔽されてるべきかも...!)
- メリット:
  - オフライン・オンラインのdata skewを防止。
  - 運用がシンプル(同期用のETLパイプラインが不要)
  - Single source of Truth (真実の単一の起源?)が得られる。
よりシンプルなパラダイム(見方、考え方??): 特徴量計算の概念を、特徴量利用から分離すること。
- (これはあんまり説明がなくてよく意味がわかってないけど、要するにfeature storeとfeature pipelineは分離して考えようね、って話かな...!)
- 特徴量計算は、frequency(頻度)とComplexity(複雑さ)の2つの軸で考えると良いらしい。(feature pipelineを設定するときの観点かな...!)
  - Frequency(頻度): バッチ(定期実行) or リアルタイム(イベント駆動、ストリーミング)
  - Complexity(複雑さ): 算術程度の軽い計算 ~ 埋め込みなどの重めな計算
- 一方で特徴量利用時には、特徴量計算のFrequencyやComplexityによらず、ビジネスロジックやMLモデルのリアルタイム推論時には低レイテンシーで容易に取得できる必要がある...!
  - (まあビジネスロジックや推論が全てバッチで行われる場合は、この要件は不要のはず...!)