影響力のあるMLモデル — どれほど難しいことだろうか？

ビジネスのユースケースを解決するモデルを構築することは、誰にとっても素晴らしいアイデアに聞こえます。MLを活用して特定のウェブサイトでパーソナライゼーションによってエンゲージメントを5%向上させることができれば、収益が何パーセントか増加するのは直感的に理解できるでしょう。

しかし、このプロジェクトを危険にさらす可能性のある2つの要因がしばしば見過ごされがちです。

1. 実際にパーソナライゼーションを5%向上させられるモデルを構築するのに十分なデータがあるか
2. そのモデルを構築・デプロイし、継続的にその効果を発揮させるために必要な投資。

さて、この2つのことをテストするのは簡単ではないでしょうか？モデル構築のアイデアから、最終的にモデルを本番環境に導入し、ビジネスへの影響を評価するまでに何が必要か、深く掘り下げてみましょう。例えば、フードデリバリーアプリが、顧客がアプリで注文した際に予想配達時間を表示したいケースを考えてみましょう。配達時間は事前に分からないため、都市、レストラン、時間帯、顧客からレストランまでの距離などの特定の要因に基づいて予測できるMLモデルを構築する必要があります。

フードデリバリーアプリでユーザーに推定配達時間を表示する

このモデルをリリースするまでのワークフローには、以下のチームが関わります。

プロジェクト構想

プロダクトマネージャーは、配達時間を推定するプロジェクトを考案します。配達時間が十分に正確であれば、ユーザーにより良い体験を提供できると期待されます。配達時間に関する顧客からの問い合わせが減り、全体的な顧客満足度も向上するはずです。その後、ビジネスチームはデータサイエンスチームにこのモデルの作成を依頼します。

データ収集

データサイエンティストは、過去のすべての注文とその配達時間の履歴データの収集を開始します。

• 場合によっては、 以前のデータが適切に記録されていない可能性があります - まずデータを記録し収集する（プロダクトチーム、データエンジニアリングチーム）。
• 幸運なケースでは、 このデータは容易に入手できる可能性があります
• 多くの場合、 これにはETLパイプラインの記述が必要になります データを適切な形式にするためです。データエンジニアリングチームが、必要な形式でデータを取り込むためのパイプラインを作成します。

データ分析

次にデータサイエンティストは データがすべて正しいか分析します — ヌル値や不正な値がなく、必要なデータがすべて揃っているかを確認します。多くの場合、データサイエンティストはデータセットにいくつかのバグを発見したり、一時的なバグが原因で数日分の不良データがあることに気づいたりします。良いモデルを構築するためには、不正なデータを取り除く必要があります。これにより、プロダクトチームやデータエンジニアリングチームとの間で何度かやり取りが発生する可能性があります。

特徴量エンジニアリング

データが適切であることが確認できたら、場合によってはデータサイエンティストは、特徴量を計算し、保存するためのパイプラインを構築したいと考えるでしょう。これにより、学習時と推論時の乖離（training-serving skew）を防ぎ、推論時に特徴量を取得しやすくなります。

ただし、これはオプションのステップであり、データ量や同じデータセットで構築されるモデルの数が少ない場合はスキップされます。チームが特徴量エンジニアリングを行うと決定した場合、AirflowやPrefectのようなパイプラインオーケストレーションシステムと、特徴量を取得するためのデータベース/キャッシュ（例：Feast）が必要になります。特徴量ストアの構築自体が大規模な取り組みであり、かなりの労力を要します。

モデル学習

データがすべて準備できたら、データサイエンティストは最適なものを特定するために、さまざまなアルゴリズム、特徴量、モデルを試します。後で参照したり、他のチームメンバーと共有したりできるように、すべてのメトリクス、パラメータ、モデルを記録したいと考えるでしょう。 ここで実験トラッキングとモデルメタデータストアが重要になります。

モデルサービング

モデルが構築されたら、モデルはマイクロサービスとして、またはバッチ推論ジョブとしてホストされる必要があります。配送時間予測のケースでは、これはリアルタイムのオンラインサービスである必要があるため、オートスケーリングサービスとしてデプロイするのが理にかなっているでしょう。この場合、MLエンジニアがモデルを受け取り、FlaskまたはFastAPIサービスでラップし、Dockerイメージを構築します。その後、MLエンジニアはDevOpsチームの協力を得て、それをインフラストラクチャ上にマイクロサービスとしてデプロイします。

プロダクト統合

モデルAPIがホストされたら、プロダクトチームまたはバックエンドチームは、予測された配送時間を活用し、アプリに表示するために、コード内でAPIを呼び出す必要があります。これには、データサイエンティスト、プロダクトチーム、MLエンジニアリングチーム間の連携が必要です。この間、プロダクトマネージャーは予測をテストしたいと考えるかもしれません。いくつかのサンプル入力でモデルを迅速にテストできれば素晴らしいでしょう。そのためには、迅速なモデルデモの構築が必要になる場合があります。

モデル監視

モデルがデプロイされ、プロダクトで使用されるようになると、デプロイされたモデルに関するメトリクスが必要になります。

1. システム監視: これにはCPU、メモリ、APIレイテンシー、エラー、モデルのクラッシュなどのメトリクスが含まれ、通常はPrometheus/GrafanaやDatadog/New Relicのような有償ソリューションを使用して行われます。これはエンジニアリング、プロダクト、データサイエンスチームによって使用されます。

 2. モデルモニタリング： これには、入力される本番データに対するモデル予測に関連するメトリクスが含まれます。これはデータサイエンティストが主に興味を持つデータであり、モデル精度、特徴量ドリフト、予測ドリフトなどのメトリクスを含みます。これにより、データサイエンティストは、モデルがトレーニング時と同様に動作しているか、外部入力データの分布が変化していないか、システム内の他の場所にバグがないかなどを判断するのに役立ちます。

モデルに関する包括的なモニタリングを実現するには、データサイエンス、エンジニアリング、DevOpsチームからの多大な労力が必要となります。

完全な自動化

すべてのモニタリングが整備されたら、データサイエンティストは理想的には完全な再学習ループを自動化したいと考えるでしょう。これには、KubeflowやAirflowのようなパイプラインオーケストレーションフレームワークが必要となります。

ビジネスインパクトの評価：

次に、このモデルが実際のユーザー満足度指標に与える影響も評価する必要があります。この場合のいくつかの代替指標としては、配送時間に関する顧客からの問い合わせ数や、注文に対する顧客の全体的な満足度スコアなどが挙げられます。ビジネスメトリクスはモデルメトリクスと結合される必要があり、データエンジニアリングチームはおそらくこのデータを取得し、ビジネスリーダーが確認できるように社内ダッシュボードツールに表示するためのETLパイプラインを作成するでしょう。

大まかにまとめると、これには5つのステークホルダーが関与します：

1. プロダクトマネージャー / ビジネスチーム
2. データエンジニアリングチーム
3. データサイエンスチーム
4. MLエンジニアリングチーム
5. バックエンドエンジニアリングチーム
6. DevOpsチーム

この全体的なプロセスは、どの企業でも簡単に2〜3ヶ月以上かかり、最初の数モデルでは6ヶ月にも及ぶことがあります。これは、複数のステークホルダーと複数のスキルセットが関与しているため、MLを効果的にするにはこれほど多くの時間と初期の先行投資が必要となるからです。

このプロセスに関わるスケーラビリティと信頼性の側面についてはまだ触れていません。将来の記事で、以下の側面の一部を取り上げたいと考えています。

1. インフラストラクチャのプロビジョニング
2. CI/CDプロセス
3. A/Bテストを含むモデル実験
4. インフラストラクチャのスケーラビリティ
5. デプロイ方法の選択

ここでの解決策は、自動化できる部分を自動化し、データサイエンティストやMLエンジニアが関連するすべてのツールを習得することなく、ほとんどのステップを実行できる自律性を提供することです。この分野では多くの取り組みが行われており、数年後には、影響力のあるMLモデルの構築が、今日のランディングページ作成と同じくらい簡単になることを願っています。