組織が機械学習をより広範囲に活用し始めると、データとそれを使用する機械学習モデルだけでなく、生データをモデルが使用できる概念に整理する機能も管理する必要があります。
参照: 人工知能倫理ポリシー (TechRepublic Premium)
LinkedInは今年初め、社内で数百もの機械学習ベースのサービス（ペタバイト規模のデータを扱うサービスなど）に利用している機能ストア「Feathr」をオープンソース化しました。例えば、興味のある求人情報や読者が読みたくなるようなブログ記事の表示などです。これはAzure Feature Storeサービスの基盤となる技術であり、より幅広い開発チームにとってより便利なものとなるよう、Linux Foundation AI & Data Foundationの一部となりました。
LinkedInでFeathrに取り組んでいるシニアスタッフエンジニアのDavid Stein氏は、TechRepublicに対し、「フィーチャーストアとFeathrは、企業が考慮する必要があるすべての事項を網羅することで、MLOpsの実行方法と機械学習モデルの効率的、効果的、かつコンプライアンスに準拠した導入方法の重要な要素です」と語った。
機械学習が特徴を見つける方法
機械学習の用語では、特徴とは機械学習モデルに入力される特定のデータであり、データベースの列やコード内の変数のようなものと考えてください。
「ある人が車を買うかどうかを予測しようとしていて、モデルへの入力として人物と車があり、その予測が購入する可能性か買いたくないかというものであるならば、モデルが使用するように設計される特徴には、その人の収入レベルや好きな色など、その人について知っていることや車について知っていることが含まれるかもしれません」とスタイン氏は述べた。「10億行にも及ぶ巨大なデータセットがある場合、出発点として列のセットを選び、それらの特徴をどのように使用して予測を行うかを中心にモデルを設計することになります。」
製品 ID や日付など、一部の機能はデータ内に存在しますが、その他の機能は処理する必要があるため、データベース内の必要な列を単に指定するよりも複雑です。
「今後必要となる他のすべての有用な機能は、さまざまな他のデータ資産から計算され、結合され、集約される必要があるかもしれません」とスタイン氏は説明した。
機械学習モデルが取引を扱う場合、過去3ヶ月間のレストランでの取引の平均値がそのような特徴量になります。レコメンデーションシステムを構築する場合、データはユーザー、商品、購入履歴のテーブルであり、その特徴量は、過去1週間または1ヶ月間にどのような商品が購入されたか、その商品が平日か週末か、購入時の天候はどうだったかなど、レコメンデーション作成に使用できるものになります。
複雑な機械学習システムには数百、数千もの特徴量が含まれており、データをそれらの特徴量に変換するパイプラインの構築には膨大な作業量がかかります。複数のデータソースに接続し、「時点」の正確性などを維持しながら特徴量をラベル付きデータと組み合わせ、それらの特徴量を低レイテンシのストレージに保存し、モデルを用いて予測を行う際にも特徴量が同じように処理されるようにする必要があります。
「LinkedInには、データベースやETLデータストアといった膨大なデータ資産に加え、求人情報、広告、フィードアイテム、LinkedInユーザー、企業、スキル、職種など、多種多様な情報に加え、LinkedInの経済グラフも存在します」とスタイン氏は述べた。「特定の予測問題に関連する可能性のある、膨大な数の様々なエンティティが存在します。」
それらすべてのデータセットを見つけて接続するだけでも、そこに含まれるさまざまな機能の選択と計算を始める前に、大変な作業になります。
「機械学習モデルを構築するエンジニアは、膨大なシグナルの元となる様々なデータ資産の詳細を見つけるために、多大な労力を費やす必要があります」とスタイン氏は述べた。また、データへのアクセス方法を標準化するのにも時間をかける必要がある。異なるデータソースでは、同じ情報がユーザーID、プロフィールID、UIDなどとラベル付けされる可能性があるからだ。
2人が同じデータを用いて異なるモデルを学習させると、異なるプロジェクトで同じ特徴量を作成してしまう可能性があります。これは労力の無駄であり、特徴量の定義がわずかに異なるだけで、混乱を招くような異なる結果が返される可能性があります。さらに、各チームはプロジェクトごとに複雑な特徴量エンジニアリングパイプラインを構築する必要があります。
Feathr: 機能のためのプラットフォーム
フィーチャーストアは、フィーチャーをまとめて登録できるレジストリです。これにより、すべての作業を一度で行うことができます。すべてのプロジェクトで同じパイプラインを使用でき、他の開発者が既に作成したフィーチャーが必要な場合は、それを再利用できます。これがFeathrの機能です（図A）。
図A
Stein 氏は、これらをパッケージ マネージャーのように考えることを提案しています。
「フィーチャーストアは、機械学習アプリケーションや機械学習モデルに必要なデータをよりシンプルかつ容易にインポートできるようにするものです」と彼は述べた。「これは、特に長期間にわたって実行される大規模プロジェクトや、類似のデータセットを使用するプロジェクトが多数ある企業では、非常に複雑な設定になることがよくあります。私たちは、機械学習エンジニアが特徴量を入力としてインポートし、モデルコードを簡単に記述できるようにしたいと考えています。」
適切なデータセットを見つけてデータを特徴量に集約するコードを書く代わりに、「機械学習エンジニアは、『ユーザーの経験年数と会社に関する情報が欲しい』と言えば、それを入力テーブルの列として表示してくれるようになるはずです」とスタイン氏はさらに説明した。こうすることで、エンジニアは特徴量のインフラストラクチャではなく、モデルの開発に時間を費やすことができる。
これは、あらゆる機械学習プロジェクトにおける開発者の作業量を大幅に削減することを意味します。あるケースでは、Feathrのおかげで数千行のコードがわずか10行に短縮されました。また別のケースでは、フィーチャーストアに組み込みの演算子があるため、数週間かかるはずだった作業が数時間で完了しました。
開発パイプラインにおける手動プロセスが少なければ少ないほど、脆弱性は低くなります。なぜなら、複雑な作業を毎回完璧に手作業でこなす必要がないからです。こうした組み込み機能があれば、より多くの人がこれらの高度な技術を活用できるようになります。
「Feathrは、生のイベントデータに対してスライディングウィンドウのアクティビティシグナルを定義する機能を提供します」とスタイン氏は述べた。「以前は、それを適切に実行できるプラットフォームがなければ、これを行うのは全く困難でした。より基本的なツールを使って正しく実行するのは非常に困難で、多くのチームはそのようなシグナルの使用を試みる気さえありませんでした。」
Feathr は、機能を低レイテンシのキャッシュに保存して、本番環境ですぐに使用できるようにする作業も行います。
「アプリケーションが推論を実行しようとする際、いくつかの特徴量の値を要求し、それをモデルに通して予測を行います」とスタイン氏は付け加えた。「クエリに非常に迅速に答えられるように、特徴量ストアの仕組みには迅速に応答することが求められます。」
機械学習モデルをトレーニングしているときはそれほど低いレイテンシは必要ないので、Spark などの他の場所からデータを取得できますが、Feathr を使用すると、そのために別のコードを記述する必要はありません。
「モデルコードを書く機械学習エンジニアの観点からすると、それらは同じに見えるようにしたいのです」とスタイン氏は語った。
機械学習では、精度と再現性が重要です。モデルがどのように結果を生成するのか、そしてどのようなデータを使用しているのかを把握することも重要です。特徴ストアを利用することで、これらの監査が容易になります（Azure Feature Store には、データの取得元と使用場所を示す使いやすいユーザーインターフェイスが備わっています）。また、様々なデータ識別子ではなく、簡略化された名前が表示されるため、理解も容易になります（図 B）。
図B
データアクセスはフィーチャーストアを通じて一元管理されていますが、Feathrはロールベースアクセス制御（RBAC）を使用して、データセットへのアクセス権限を持つユーザーのみがモデルにデータセットを利用できるようにしています。オープンソースのFeathrはAzure Purviewを使用しているため、一度アクセス制御を設定すれば、あらゆる場所で一貫して安全に適用できます。
効果的なエンタープライズ機械学習
Feathr は LinkedIn が社内で使用しているテクノロジーと構成に合わせて構築されているため、オープンソース化によってより汎用化され、LinkedIn とは異なるテクノロジーを使用している企業にも役立つようになります。
「業界では、このような問題を抱える人が増えています」とスタイン氏は指摘する。「機能パイプラインを構築する各組織は、こうしたエンジニアリング上の課題をどう解決し、正しく使用されているかをどのように確認するかを個別に検討する必要があります。こうした課題は、一度構築すればプラットフォームソリューションとして問題なく構築できるのです。」
最初のステップは、Microsoftと協力して、FeathrをAzureでスムーズに動作させることでした。これには、LinkedInよりも業界全体でより一般的な、より多くのデータソースのサポートが含まれます（図C）。
図C
AzureでFeathrをご利用の場合、Azure Blob Storage、Azure Data Lake Storage、Azure SQLデータベース、データウェアハウスからデータを取得できます。特徴量を定義したら、Azure DatabricksまたはAzure Synapse Analyticsで実行されるSparkを使用して生成できます。
特徴量は、低レイテンシでの提供のためにAzure Redis Cacheに保存され、チーム間で共有するためにAzure Purviewに登録されます。機械学習モデルで特徴量を使用する場合は、Azure Machine Learning内から呼び出すことができます。モデルをAzure Kubernetes Serviceクラスターにデプロイすると、Redis Cacheから特徴量を取得できます。
プロジェクトを LF AI & Data Foundation に導入することが次のステップであり、これにより Feathr は Azure エコシステムを超えることになります。
「この連携と提携により、Feathrに携わる人々のネットワークが強化されます」とスタイン氏は述べた。「関連プロジェクトとの連携に必要なリソースや機会にアクセスできるようになります。」
フィーチャーストアはかなり新しいアイデアなので、コラボレーションと貢献が重要です。
「業界は、こうしたツールがどうあるべきか、何をすべきかについての詳細をよりしっかりと理解する方向に成長しており、私たちは学んだことを基にそれに貢献しようと努めています」と彼は付け加えた。
プロジェクトをオープンソース化する際によくあることですが、この作業により、LinkedIn 自体にとっても Feathr はより優れたものになりました。
「LinkedInのエンジニアリングには、一般的に有用で業界にとって興味深いと思われるものをオープンソース化する文化があります」とスタイン氏は語った。
新規ユーザーは、ツールを開発した人々にとって、ますます多様化する問題の解決にどのように活用できるかを目の当たりにすることで、ツールの有用性をより深く理解する機会となります。また、新規ユーザーがプロジェクトを手に取り、問題解決にどのように活用できるか、そして他のツールとの比較を理解できるよう、ドキュメントを充実させる上での原動力にもなると彼は指摘しました。
「バランスの取れた製品には、多くの要素が不可欠です」とスタイン氏は述べた。「オープンソース化してソリューションを公開することは、製品をより良いものにするための絶好の機会です。Feathrをオープンソースコミュニティ、そして今回Linux Foundationに統合したことは、より幅広い機械学習やユースケースに対応できる、より優れたツールへと進化させ続けるプロセスの一環です。これは、LinkedInにとっても、コミュニティにとっても、より良い製品へと進化していくための道筋なのです。」
