MLOps 向け機械学習設計パターン

著者 | Pier Paolo Ippolito、データ サイエンティスト

翻訳者 | 陸新王

校正 | 梁哲、孫淑娟

導入

デザイン パターンは、一般的な汎用的な問題に対するベスト プラクティスと再利用可能なソリューションのセットです。データ サイエンスやソフトウェア開発、アーキテクチャ設計などの分野では、繰り返し発生する問題が多数存在します。そのため、最も一般的な問題を分類し、それらを簡単に特定して解決するためのさまざまな形式の青写真を提供することで、より多くの人々に大きなメリットをもたらすことができます。

ソフトウェア開発においてデザインパターンを使用するというアイデアは、Erich Gammaらが「デザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素」[1]で初めて提案しました。さらに、サラ・ロビンソンらによる論文「機械学習デザインパターン」[2]によれば、デザインパターンは機械学習プロセスにも適用できるとのことだ。

この記事では、MLOps を構成するさまざまな設計パターンについて説明します。 MLOps (機械学習 -> 運用) は、実験的な機械学習モデルを現実世界で意思決定を行える生産的なサービスに変換するように設計された一連のプロセスです。 MLOps は基本的に DevOps と同じ原則に基づいていますが、データの検証と継続的なトレーニング/評価にさらに重点が置かれています (図 1)。

図 1: DevOps と MLOps (著者提供の画像)

MLOps の主な利点は次のとおりです。

• 市場投入までの時間の短縮（より迅速な導入）
• モデルの堅牢性が強化されました (データドリフトの特定、モデルの再トレーニングなどが容易になります)
• 異なるMLモデルのトレーニング/比較における柔軟性の向上

一方、DevOps では、継続的インテグレーション (CI) と継続的デリバリー (CD) というソフトウェア開発の 2 つの重要な概念を重視しています。継続的インテグレーションは、チームがプロジェクトで共同作業を行う方法として中央リポジトリを使用し、さまざまなチーム メンバーによって追加された新しいコードの追加、テスト、検証を可能な限り自動化することに重点を置いています。この方法では、アプリケーションのさまざまな部分が相互に正しく通信できるかどうかをいつでもテストし、あらゆる種類のエラーをすばやく特定できます。継続的デリバリーは、ソフトウェアのデプロイメントをスムーズに更新し、あらゆる形態のダウンタイムを最小限に抑えることに重点を置いています。

MLOps デザインパターン

ワークフローパイプライン

機械学習 (ML) プロジェクトは、さまざまなステップから構築されます (図 2)。

図 2: ML プロジェクトの主なステップ (著者提供の画像)

新しいモデルのプロトタイプを作成する場合、プロセス全体を記述するために単一のスクリプト (モノリシック) を使用するのが一般的ですが、プロジェクトが複雑になり、参加するチーム メンバーが増えると、プロジェクトの各ステップを個別のスクリプト (マイクロサービス) に分割する必要が生じます。したがって、このアプローチを採用すると、いくつかの利点が得られる可能性があります。

• さまざまなステップのオーケストレーションの変更を実験するのが簡単になります
• 定義によりプロジェクトを拡張可能にします（新しいステップを簡単に追加および削除できます）
• 各チームメンバーはプロセスの異なるステップに集中できる
• それぞれのステップで分散モデルの出力が得られる

ワークフロー パイプライン設計パターンは、ML パイプラインを作成するための計画の青写真を定義することを目的としています。 ML パイプラインは有向非巡回グラフ (DAG) で表すことができ、各ステップはコンテナーで表されます (図 3)。

図3: 有向非巡回グラフ (DAG) の例 (著者提供の画像)

この構造に従うことで、再利用可能で管理可能な ML プロセスを作成できます。ワークフロー パイプラインを使用する利点は次のとおりです。

• プロセスのステップを追加および削除することで、さまざまな前処理手法、機械学習モデル、ハイパーパラメータをテストするための複雑な実験を作成できます。
• それぞれの異なるステップの出力を個別に保存します。最後のステップで変更が適用された場合、パイプラインの先頭でステップを再実行することを回避します (これにより、時間と計算能力を節約できます)
• エラーが発生した場合、どの手順を更新する必要があるかを簡単に判断できます。
• CI/CD を使用して本番環境にデプロイされると、パイプラインはさまざまな要因 (時間間隔、外部トリガー、ML メトリックの変更など) に基づいて再実行されるようにスケジュールできます。

機能プラットフォーム

機能プラットフォームは、機械学習プロセス用に設計されたデータ管理レイヤーです (図 4)。この設計パターンの主な目的は、機械学習機能を整理して使用する方法を簡素化することです。これは、企業が ML パイプラインを構築するためにこれまでに作成したすべての機能を保存する、何らかの形式の中央リポジトリを作成することによって実現されます。こうすることで、データ サイエンティストがさまざまな ML プロジェクトに同じ機能のサブセットを提供する必要がある場合、生データを処理済みの機能に複数回変換する必要がなくなり、時間のかかる作業が省けます。最も一般的な 2 つのオープン ソース機能プラットフォーム ソリューションは、Feast と Hopsworks です。

図 4: 機能プラットフォーム設計パターン (著者提供の画像)

機能プラットフォームの詳細については、（https://towardsdatascience.com/getting-started-with-feature-stores-121006ee81c9）をご覧ください。

変換

Transform 設計パターンは、入力、機能、変換を個別のエンティティとして保持することにより、機械学習モデルを本番環境で簡単に展開および保守できるようにすることを目的としています (図 5)。実際、生データは、機械学習モデルへの入力として使用できるようになる前に、さまざまな前処理手順を経る必要があることが多く、これらの変換の一部は、推論のためにデータを前処理するときに再利用できるように保存する必要があります。

図5: 入力と特徴の関係（著者提供画像）

たとえば、ML モデルをトレーニングする前に、外れ値に対処し、データをよりガウス分布に見せるために、正規化/標準化手法が数値データに適用されることがよくあります。これらの変換は、将来推論のために新しいデータが提供されたときに再利用できるように保存する必要があります。これらの変換を保持しないと、トレーニングとサービングの間でデータの偏りが生じ、推論用に提供された入力データの分布が ML モデルのトレーニングに使用された入力データとは異なることになります。

トレーニング モデルとサービング間のあらゆる種類のデータ スキューを回避するには、機能プラットフォーム設計パターンを使用するという解決策があります。

マルチモード入力

ML モデルをトレーニングする場合、画像、テキスト、数値などのさまざまな種類のデータを使用できますが、一部の種類のモデルでは特定の種類の入力データしか受け入れることができません。たとえば、Resnet-50 は入力データとして画像のみを受け入れることができますが、KNN (K Nearest Neighbor) などの他の ML モデルは入力として数値データのみを受け入れることができます。

ML 問題を解決するには、さまざまな形式の入力データを使用する必要があります。この場合、何らかの形式の変換を適用して、さまざまなタイプの入力データすべてに共通の表現を作成する必要があります (マルチモーダル入力設計パターン)。たとえば、テキスト、数値、カテゴリデータの組み合わせがある場合、ML モデルをトレーニングするために、感情分析、バッグオブワード、単語埋め込みなどの手法を使用してテキストデータを数値形式に変換し、ワンホットエンコーディングを使用してカテゴリデータを変換できます。この方法では、すべてのデータを同じ形式 (数値) で保存して、モデルのトレーニングに使用できるようになります。

カスケード

シナリオによっては、1 つの ML モデルだけでは問題を解決できない場合があります。この場合、最終目標を達成するには、一連の相互依存する ML モデルを作成する必要があります。たとえば、ユーザーに推奨するアイテムの内容を予測するとします (図 6)。この問題を解決するには、まずユーザーが 18 歳未満か 18 歳以上かを予測できるモデルを作成する必要があります。次に、モデルの応答に応じて、2 つの異なる ML 推奨エンジン (1 つは 18 歳以上のユーザーに製品を推奨し、もう 1 つは 18 歳未満のユーザーに製品を推奨する) のいずれかにルーティングされます。

図 6: カスケード設計パターン (著者提供の画像)

この ML モデルのカスケードを作成するには、それらが一緒にトレーニングされるようにする必要があります。実際、それらの相互依存性により、最初のモデルが変更された場合（他のモデルを更新しない場合）、後続のモデルが不安定になる可能性があります。このプロセスを自動化するには、ワークフロー パイプライン設計パターンを使用できます。

結論は

この記事では、MLOps をサポートする最も一般的な設計パターンのいくつかについて説明しました。機械学習のデザイン パターンについて詳しく知りたい場合は、AIDVFest20 での Valliappa Lakshmanan の講演と、書籍『Machine Learning Design Patterns』の公開 GitHub リポジトリをご覧ください。

参考文献

[1] 「デザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素」（Addison-Wesley、1995年）：www.uml.org.cn/c%2B%2B/pdf/DesignPatterns.pdf

[2] 「機械学習デザインパターン」（サラ・ロビンソン他、2020年）：

​​https://www.oreilly.com/library/view/machine-learning-design/9781098115777/​​

著者：

Pier Paolo Ippolito は、サウサンプトン大学を卒業したデータ サイエンティストです。彼は人工知能の修士号を取得しており、金融や医療などの分野における AI および機械学習アプリケーションの開発に強い関心を持っています。

連絡先:

著者の最新の記事やプロジェクトを知りたい場合は、以下に連絡してください。

• リンクトイン
• ​​​​個人ウェブサイト​​
• 中
• ​​GitHub​​
• カグル

翻訳者紹介

51CTO コミュニティ エディターの Lu Xinwang 氏は、1990 年代生まれでキャリア パスを変更したプログラマーです。私はフロントエンド ページに取り組んだり、ビジネス インターフェイスを書いたり、クローラーに取り組んだり、JS を勉強したりしてきましたが、幸運にも Golang に触れてマイクロサービス アーキテクチャへの変革に参加できました。現在は主にJavaを書いており、同社のカスタマイズ可能なローコードプラットフォームのデータエンジン層の設計と開発を担当しています。

原題: ​​MLOps 向け機械学習のデザインパターン​​​​、著者: Pier Paolo Ippolito

2022年1月13日にTowards Data Scienceに掲載されました