3,323 測定値

MLOps に関する最も詳細なガイド: パート 1

に Lera Demiyanuk18m2023/10/06

長すぎる; 読むには

この記事では、MLOps の概念について詳しく説明します。また、3つの方法で行います。まず理論的には、最も賢明な MLOps スキームを使用します。次に、概念的には、アプローチに埋め込まれた成果物を通して行います。そして最後に、情報システムとしての MLOps を理解することによって。

featured image - MLOps に関する最も詳細なガイド: パート 1

こんにちは、ハッカーヌーン！この記事では、MLOps の概念について詳しく説明します。また、3つの方法で行います。まず理論的には、最も賢明な MLOps スキームを使用します。次に、概念的には、アプローチに埋め込まれたアーティファクトを通じて行います。そして最後に、情報システムとしての MLOps を理解することによって。

それでは、始めましょう。

MLOpsとは何ですか?

この疑問は、多くの ML システム開発チームの心を長い間占めてきました。この記事では、このようなシステムとは、ビジネスロジック全体の一部を実行するトレーニング済みモデルを 1 つ以上のコンポーネントに含む情報システムを理解します。

システムの他のコンポーネントと同様に、ビジネスロジックのこの部分は、変化するビジネスと顧客の期待に応えるために更新する必要があります。 MLOps のすべては、この定期的なアップデートにあります。

MLOpsの定義と説明

MLOps については、まだ単一の合意された定義がありません。多くの著者がそれを説明しようと試みてきましたが、同時に明確で体系的な説明を見つけるのは困難でした。

そのように考えられるものがあります。

MLOps は、ML システム開発 (dev) と ML システム展開 (ops) を統合して、本番環境での高性能モデルの継続的配信を標準化および合理化することを目的としたエンジニアリング分野です。

MLOps 定義の重要な部分を強調してみましょう。

工学分野
ML システムの開発および展開プロセスを統合することを目的としています。
新しいバージョンの継続的な配信を標準化および最適化します。
高性能モデル

つまり、MLOps は ML モデル用の DevOps の一種です。

MLOps の出現の歴史

このようなエンジニアリング分野は大規模な IT 企業で生まれたと信じられがちです。したがって、有意義なアプローチとしての MLOps は Google で生まれたという理論を信頼できます。Google では、D. Sculley が ML モデルを拡張機能に出力するという日常的なタスクから神経と時間を節約しようとしていました。 D. スカリーは現在「MLOps のゴッドファーザー」として広く知られており、同名のポッドキャストはオンラインで簡単に見つけることができます。

D. スカリーは、チームの技術的負債の観点からモデルを使った作業を検討し始めました。はい、モデルの新しいバージョンをすぐにリリースすることは可能ですが、結果として得られるシステムをサポートするコストは会社の予算に大きな影響を与えます。

彼の研究は論文「機械学習システムの隠れた技術的負債」は、2015 年に NeurIPS カンファレンスで公開されました。この記事の公開日は、MLOps の存在の出発点と考えることができます。

MLOps 成熟度レベル: 最もよく知られたモデル

ほとんどの IT プロセスと同様、MLOps にも成熟度レベルがあります。これらは、企業が現在どこにいるのか、そして次のレベルにどのように移行できるのか (そのような目標がある場合) を理解するのに役立ちます。また、一般に受け入れられている成熟度の決定方法を使用すると、競合他社の中での自分の位置を決定できます。

GigaOm MLOps 成熟度モデル

最も詳細に説明されており、ほとんどが理解できるモデルは、分析会社GigaOmによるものです。これは、すべてのモデルの中で Capability Maturity Model Integration (CMMI) に最も近いものです。これは組織プロセスを改善するための一連の方法論であり、0から4までの5つのレベルで構成されています。

GigaOm のモデルは、戦略、アーキテクチャ、モデリング、プロセス、ガバナンスの 5 つのカテゴリを通じて各成熟度レベルを明らかにします。

ML システム構築の初期段階でこのモデルに基づいて、重要な側面について事前に検討し、失敗の可能性を減らすことができます。ある成熟度レベルからより高い成熟度レベルに移行すると、チームは以前には存在していなかったかもしれない新しい課題に直面します。

Google MLOps 成熟度モデル

Google にもMLOps 成熟度レベルモデルがあることは注目に値します。それは最初に登場したものの一つでした。簡潔で、次の 3 つのレベルで構成されています。

レベル 0: 手動プロセス
レベル 1: ML パイプラインの自動化
レベル 2: CI/CD パイプラインの自動化

このモデルはフクロウの塗装の説明書に似ているという考えから逃れることはできません。まず、すべてを手作業で行い、ML パイプラインを組み立て、MLOps を完成させます。とは言え、よく説明されています。

Azure MLOps 成熟度モデル

現在、ML を使用している多くの大企業が成熟度モデルをまとめています。アズール同様のアプローチを使用してレベルを区別する、が含まれています。ただし、Google のものよりも多くのものがあります。

レベル 0: MLOps なし
レベル 1: DevOps はあるが MLOps はなし
レベル 2: 自動トレーニング
レベル 3: 自動モデル展開
レベル 4: 完全な MLOps 自動操作

強調表示されたすべてのモデルは、ほぼ 1 つのことに収束します。ゼロレベルでは、ML の実践はまったく行われていません。最後のレベルでは、MLOps プロセスの自動化が行われます。段階的なプロセスの自動化に関連する何かが常に中間にあります。 Azure では、トレーニングプロセスとその後のモデルのデプロイメントが自動化されています。

MLOps の概念フレームワーク

MLOps の概念に関連するすべてのプロセスをどのように説明しますか?驚くべきことに、記事の著者である3人のドイツ人が「機械学習オペレーション (MLOps): 概要、定義、アーキテクチャ" - それらを 1 つの図にカプセル化することさえできました。彼らは実際の調査を実施し、MLOps の概念を詳細に説明しました。

多くの要素が相互に影響し合うため、恐ろしいかもしれません。ただし、上記の成熟度レベルの特徴の多くがそこに見られます。少なくとも自動化されたパイプライン、CI/CD、モニタリング、モデルレジストリ、ワークフローオーケストレーション、およびサービス提供コンポーネント。

この図について説明し、それぞれについて詳しく説明します。

MLOps コアプロセス

このスキームの主要な部分は水平ブロックであり、その中に MLOps の手続き的側面が記述されています (文字 A、B、C、および D が割り当てられています)。それぞれは、企業の ML サービスの円滑な運用を保証するフレームワーク内で特定のタスクを解決するように設計されています。スキームを理解しやすくするために、順不同で始めることをお勧めします。

実験

企業に ML サービスがある場合、従業員は Jupyter で作業します。多くの企業では、これがすべての ML 開発プロセスの中心となるツールです。ここから、MLOps プラクティスの実装が必要なタスクのほとんどが始まります。

例を考えてみましょう。 A社は、機械学習を利用して一部のプロセスを自動化する必要があります（対応する部門と専門家がいると仮定します）。タスクを解決する方法が事前にわかっている可能性はほとんどありません。したがって、実行者は問題ステートメントを研究し、それを実現する可能な方法をテストする必要があります。

これを行うために、ML エンジニア/ML 開発者は、さまざまなタスク実装用のコードを作成し、ターゲットメトリックによって取得された結果を評価します。これらすべてはほとんどの場合、Jupyter Lab で行われます。このような形式では、多くの重要な情報を手動で取得し、実装間で比較する必要があります。

このような活動は実験と呼ばれます。これは、関連する問題を解決するためにさらに使用できる、実用的な ML モデルを取得することを意味します。

図に示すブロック C は、ML 実験を実行するプロセスを説明します。

タスクの範囲内で利用可能なデータの分析

ML 開発における多くの意思決定は、社内で利用可能なデータの分析に基づいて行われます。低品質のデータや存在しないデータに対して、目標品質メトリクスを使用してモデルをトレーニングすることはできません。

したがって、どのようなデータを取得し、それを使用して何ができるかを理解することが重要です。これを行うには、たとえば次のようにします。

Jupyter または Superset を使用して ADHoc スタディを実施する
標準 EDA (探索的データ分析)

データをより深く理解するには、セマンティック分析と構造分析を組み合わせる必要があります。

ただし、データの準備がプロジェクトチームの管理下にある場合はごくまれです。この場合、さらなる困難が確実に発生します。場合によっては、この段階で、データが作業に適していないため、プロジェクトをこれ以上開発しても意味がないと判明することがあります。

高品質のデータセットの形成

利用可能なデータに自信がある場合は、前処理ルールについて考える必要があります。適切なデータが大量に存在する場合でも、そのデータに欠落や歪んだ値などが含まれていないという保証はありません。「入力データの品質」という用語と、よく知られている「ガベージイン - ガベージアウト」という言葉について言及する必要があります。ここ。

どんなに優れたモデルを使用しても、低品質のデータでは悪い結果が得られます。実際には、高品質のデータセットの作成に多くのプロジェクトリソースが費やされます。

ML モデルのトレーニングと検証

前の段階の後、実験を行うときにトレーニング済みモデルのメトリクスを考慮するのが合理的です。検討中のブロックのフレームワーク内で、実験は ML モデルのトレーニングと検証をリンクすることで構成されます。

実験は、準備されたデータセット上で選択されたハイパーパラメータのセットを使用してモデルの目的のバージョンをトレーニングする古典的なスキームで構成されます。この目的のために、データセット自体がトレーニング、テスト、検証サンプルに分割されます。

最初の 2 つは、最適なハイパーパラメータのセットを選択するために使用されます。
3 つ目は、選択したハイパーパラメーターのセットでトレーニングされたモデルが、ハイパーパラメーターの選択とトレーニングのプロセスに参加しなかった未知のデータに対して適切に動作することの最終的な検証と確認です。

検証サンプルの詳細については、以下を参照してください。この記事。

コードとハイパーパラメータをリポジトリに保存する

モデル学習メトリクスが良好な場合、モデルコードと選択されたパラメーターは企業リポジトリに保存されます。

実験プロセスの基本的な目標はモデルエンジニアリングであり、これは最適なアルゴリズムの選択と最適なハイパーパラメータ調整の選択を意味します。

実験の難しさは、開発者が ML モデルの動作パラメータの多くの組み合わせを確認する必要があることです。そして、私たちは使用される数学的装置のさまざまな変形について話しているのではありません。

一般的には手間がかかります。そして、モデルパラメータの組み合わせの枠組み内で望ましいメトリクスが達成されない場合はどうすればよいでしょうか?

特徴量エンジニアリング

ML モデル操作の望ましいメトリックが達成できない場合は、新しい特徴を使用してデータセットオブジェクトの特徴記述を拡張してみることができます。これらにより、モデルのコンテキストが拡張されるため、必要なメトリクスが向上する可能性があります。

新機能には次のものが含まれる場合があります。

表形式データの場合: 既存のオブジェクト属性の任意の変換 - 例: X^2、SQRT(X)、Log(x)、X1*X2 など。
対象分野に基づいて: BMI、年間のローン支払い延滞数など。

特徴量エンジニアリングに関連する図の部分を見てみましょう。

ブロック B1 は、利用可能なソースデータを変換し、そこから特徴を取得するための一連の要件を形成することを目的としています。コンポーネント自体の計算は、ML 開発者が入力した「式」に従って、これらの高度に前処理され、クリーン化されたデータから実行されます。

フィーチャの操作は反復的であるということが重要です。 1 つの機能セットを適用すると、新しいアイデアが思い浮かび、別の機能セットで実現するなど、無限に続く可能性があります。これは、図ではフィードバックループとして明示的に示されています。

ブロック B2 は、データに新しい特徴を追加する即時プロセスを記述します。

データソースへの接続と取得は、非常に複雑な技術的な操作です。説明を簡単にするために、チームがアクセスできるソースがいくつかあり、これらのソースからデータをアンロードするツール (少なくとも Python スクリプト) があると仮定します。

データのクリーニングと変換。この段階では、実験ブロック (C) の同様のステップ (データ準備) をほぼ実行します。最初の実験の時点で、ML モデルのトレーニングにどのようなデータがどのような形式で必要かはすでに理解されています。残っているのは、新しい機能を正しく生成してテストすることだけですが、この目的のためのデータ準備プロセスは可能な限り自動化する必要があります。

新しい特徴の計算。上で述べたように、これらのアクションは、データタプルのいくつかの要素を単純に変換することで構成されます。もう 1 つのオプションは、別の大規模な処理パイプラインを実行して、同じデータタプルに 1 つの機能を追加することです。いずれの場合も、連続して実行される一連のアクションがあります。

結果を追加します。前のアクションの結果がデータセットに追加されます。ほとんどの場合、データベースの負荷を軽減するために、フィーチャはバッチでデータセットに追加されます。ただし、ビジネスタスクの実行を高速化するために、オンザフライ (ストリーミング) を実行する必要がある場合があります。

取得した特徴をできるだけ効率的に使用することが重要です。保存して、社内の他の ML 開発者のタスクで再利用します。このスキームには、この目的のためのフィーチャーストアがあります。これは社内で利用でき、個別に管理され、組み込まれるすべての機能がバージョン管理される必要があります。フィーチャーストアには、オンライン (ストリーミングスクリプトの場合) とオフライン (バッチスクリプトの場合) の 2 つの部分があります。

自動化された ML ワークフロー

記事の冒頭で、ML システムとは、ビジネスロジック全体の一部を実行するトレーニング済みモデルを 1 つ以上のコンポーネントに含む情報システムを意味すると述べました。開発によって得られた ML モデルが優れているほど、その運用の効果は大きくなります。トレーニングされたモデルは、受信するリクエストのストリームを処理し、それに応じていくつかの予測を提供するため、分析または意思決定プロセスの一部を自動化します。

モデルを使用して予測を生成するプロセスは推論と呼ばれ、モデルのトレーニングはトレーニングと呼ばれます。 2 つの違いの明確な説明は Gartner から借用できます。ここでは猫で練習してみます。

本番環境の ML システムを効率的に運用するには、モデルの推論メトリクスに常に注意を払うことが重要です。低下が始まったら、すぐにモデルを再トレーニングするか、新しいモデルに置き換える必要があります。ほとんどの場合、入力データの変化 (データドリフト) が原因で発生します。たとえば、モデルが写真内のカップケーキを認識できるというビジネス上の問題があり、これが入力として与えられます。例のチワワ犬はバランスをとるためのものです。

元のデータセットのモデルはチワワ犬について何も知らないため、誤った予測をします。そのため、データセットを変更して新たな実験を行う必要があります。新しいモデルはできるだけ早く生産されるはずです。ユーザーがチワワ犬の画像をアップロードすることを禁じている人はいませんが、間違った結果が得られるでしょう。

次に、実際の例をさらに見てみましょう。マーケットプレイス向けのレコメンデーションシステムの開発を考えてみましょう。

ユーザーの購入履歴、類似ユーザーの購入、その他のパラメーターに基づいて、モデルまたはモデルのアンサンブルが推奨事項を含むブロックを生成します。これには、購入収益が定期的にカウントおよび追跡される製品が含まれます。

何かが起こり、顧客のニーズが変化します。したがって、彼らの推奨事項はもはや意味がありません。推奨商品の需要が減少します。これらすべてが収入の減少につながります。

次のマネージャーは叫び、明日までにすべてを復旧するよう要求しますが、それは何も起こりません。なぜ？新しい顧客の嗜好に関するデータが不足しているため、新しいモデルを作ることもできません。レコメンデーション生成の基本的なアルゴリズム (アイテムベースの協調フィルタリング) をいくつか取得して、運用環境に追加できます。このようにして、推奨事項は何とか機能しますが、これは一時的な回避策にすぎません。

理想的には、さまざまなモデルの再トレーニングまたは実験のプロセスが、マネージャーに指示されずにメトリクスに基づいて開始されるようにプロセスを設定する必要があります。そして、最終的には、運用中の現行のものが最良のものに置き換わることになります。図では、これは自動 ML ワークフローパイプライン (ブロック D) であり、何らかのオーケストレーションツールのトリガーによって開始されます。

これは、スキームの中で最も負荷の高いセクションです。ブロック D の操作には、いくつかの主要なサードパーティコンポーネントが関与しています。

ワークフローオーケストレーターコンポーネント。指定されたスケジュールまたはイベントでパイプラインを起動する役割を果たします。
モデルに必要な特徴に関するデータがそこから取得される特徴ストア
モデルレジストリと ML メタデータストア。起動されたパイプラインの作業後に取得されたモデルとそのメトリクスが配置されます。

ブロック自体の構造は、実験の段階と機能開発 (B2) ブロックを組み合わせたものです。これらが自動化する必要があるプロセスであることを考えると、驚くべきことではありません。主な違いは最後の 2 つのステージにあります。

エクスポートモデル
モデルレジストリにプッシュする

残りのステップは上で説明したステップと同じです。

これとは別に、オーケストレーターがモデルの再トレーニングパイプラインを実行するために必要なサービスアーティファクトについても触れたいと思います。これはリポジトリに保存され、選択されたサーバー上で実行されるコードです。ソフトウェア開発のすべてのルールに従ってバージョン管理とアップグレードが行われます。このコードはモデルの再トレーニングパイプラインを実装しており、結果はその正確さに依存します。

多くの場合、さまざまな ML ツールがコード内で実行され、その中でパイプラインのステップの実行が行われます。次に例を示します。

エアフローオーケストレーターはコードを実行してパイプラインのステージを実行します。
Feast はコマンドに応じてデータセット内のフィーチャに関するデータをアンロードします
次に、ClearML は新しいデータセットを作成し、独自のリポジトリから取得した必要なモデルパフォーマンスメトリクスのセットを使用して実験を実行します。
調査が完了すると、ClearML はモデルとそのパフォーマンスメトリックをストレージに保存します。

ここで注意すべき点は、実験を自動化することは一般に不可能であるということです。もちろん、AutoML の概念をプロセスに追加することも可能です。ただし、現時点では、実験のどの被験者に対しても同じ結果が得られると認められた解決策はありません。

一般に、AutoML は次のように動作します。

何らかの方法で、モデル操作パラメータの多くの組み合わせのセットを生成します
結果の組み合わせごとに実験を実行します。最適なモデルの選択に基づいて各実験のメトリクスを修正します
AutoML は、ジュニア/ミドルのデータサイエンティストが多かれ少なかれ標準的なタスクの中で行うであろうすべての操作を実行します。

自動化は少し処理されています。次に、モデルの新しいバージョンを運用環境に配信する準備をする必要があります。

モデルの提供と監視

予測を生成するには ML モデルが必要です。ただし、ML モデル自体はファイルであるため、それほど迅速に生成することはできません。このようなソリューションはインターネットでよく見つかります。チームは FastAPI を使用して、「述語に従う」ことができるようにモデルの周囲に Python ラッパーを作成します。

ML モデルファイルを受信した瞬間から、物事はいくつかの方法で展開されます。チームは次のことを行うことができます。

RESTfull サービスを構築するためのすべてのコードを作成する
すべてのラッピングを実装します
すべてを Docker イメージに構築します
そして、そのイメージからどこかにコンテナを構築します
何とかスケールアップしてください
メトリクスのコレクションを整理する
アラートを設定する
モデルの新しいバージョンをロールアウトするためのルールを設定する
他にもたくさんのこと

すべてのモデルに対してこれを実行し、将来的にコードベース全体を保守するのは多大な労力を要する作業です。これを簡単にするために、次の 3 つの新しいエンティティを導入した特別な提供ツールが登場しました。

推論インスタンス/サービス
推論サーバー
サービスエンジン

推論インスタンス (推論サービス) は、クエリを受信して応答予測を生成するために準備された特定の ML モデルです。このようなエンティティは、必要な ML モデルとそれを実行するための技術ツールを備えたコンテナを持つ Kubernetes クラスター内のサブを表すことができます。

推論サーバーは、推論インスタンス/サービスの作成者です。推論サーバーの実装は多数あります。それぞれが特定の ML フレームワークと連携して、そのフレームワークでトレーニングされたモデルを、入力クエリを処理して予測を生成するためにすぐに使用できるモデルに変換できます。

検索エンジンは主な管理機能を実行します。どの推論サーバーを使用するか、結果として得られる推論インスタンスのコピーをいくつ開始するか、およびスケールする方法が決定されます。

検討中のスキームでは、モデル提供コンポーネントの詳細は説明されていませんが、同様の側面が概説されています。

CI/CD コンポーネント。実稼働環境ですぐに実行できるモデルをデプロイします (Serving Engine のバージョンの 1 つとみなすことができます)。
モデルサービングは、利用可能なインフラストラクチャ内で、ストリーミングシナリオとバッチシナリオの両方の ML モデルの予測生成スキームを組織します (推論サーバーのバージョンの 1 つと考えることができます)。

Serving の完全なスタックの例については、Seldon のスタックを参照できます。

Seldon Core はサービスエンジンです
Seldon ML Server は推論サーバーであり、REST または gRPC 経由でモデルへのアクセスを準備します。
Seldon MLServer Custom Runtime は推論インスタンスであり、予測を生成するためにサンプルを実行する必要がある ML モデルのシェルインスタンスです。

Serving を実装するための標準化されたプロトコルもあり、このようなすべてのツールでのサポートは事実上必須です。これは V2 Inference Protocol と呼ばれ、KServe、Seldon、Nvidia Triton などの著名な市場プレーヤー数社によって開発されました。

サービス提供とデプロイメント

さまざまな記事で、単一のエンティティとして提供およびデプロイするためのツールへの参照が見つかる場合があります。ただし、両方の目的の違いを理解することが重要です。これは議論の余地のある問題ですが、この記事では次のように説明します。

サービス - API モデルの作成とそこから予測を取得する可能性。最終的には、内部にモデルを含む単一のサービスインスタンスが得られます。
デプロイ - 受信リクエストを処理するために必要な量のサービスインスタンスを配布します (Kubernetes デプロイではレプリカセットとして表すことができます)。

モデルのデプロイには多くの戦略を使用できますが、これらは ML 固有のものではありません。ちなみに、Seldon の有料版ではいくつかの戦略がサポートされているため、このスタックを選択するだけで、すべてがどのように機能するかを楽しむことができます。

モデルのパフォーマンス指標を追跡する必要があることに注意してください。そうしないと、問題を時間内に解決できなくなります。メトリクスをどのように正確に追跡するかが大きな問題です。 Arize AI はこれに基づいてビジネス全体を構築しましたが、誰も Grafana と VictoriaMetrics をキャンセルしませんでした。

プロジェクトの開始

上記のことをすべて考慮すると、ML コマンドは次のようになります。

データセットを生成します
ML モデル上で実験を実施します。
データセットを拡張し、モデルの品質を向上させるための新機能を開発します
将来の再利用に備えて最適なモデルをモデルレジストリに保存します
モデルの提供とデプロイをカスタマイズする
運用中のモデルの監視と、現在のモデルの自動再トレーニングまたは新しいモデルの作成をカスタマイズします。

それはコストがかかるように見えますが、正当化される場合のみです。したがって、図には合理的な目標設定を担当する別個の MLOps プロジェクト開始 (A) ブロックがあります。

ここでの考え方は、IT ディレクターの推論の例で説明できます。インスピレーションを受けたプロジェクトマネージャーが彼のところにやって来て、ML システムを構築するための新しいプラットフォームのインストールを依頼しました。両方が会社の利益を最優先に行動している場合、IT ディレクターは次のように質問を明確にします。