Concepts — MLflow 2.6.0 documentationの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
MLflowは4つのコンポーネントから構成されます: Tracking、Projects、ModelsとModel Registryです。TrackingやProjectsを使用することなしに、MLflowのモデルフォーマットでモデルをエクスポートするなど、それぞれのコンポーネントを個別に使用することができますが、これらは協調するように設計されています。
MLflowのコアの哲学は、あなたのワークフローに対して可能な限り制約を課さないということです: すべての機械学習ライブラリで動作するように設計されており、お使いのコードに関するほとんどのことは慣習に従って決定されており、既存のコードベースに取り込むためには最低限の変更で済むようになっています。同時に、MLflowではすべてのコードベースが自身のフォーマットで記述されることを狙いにしており、複数のデータサイエンティストで再現可能で再利用可能にしています。本書では、典型的な機械学習(ML)のワークフローと、どこにMLflowが適用されるのかを説明します。
機械学習ワークフロー
機械学習では、何かしらのターゲットのメトリックを最大化するモデルを構築するためには、さまざまなデータセットやデータ準備のステップ、アルゴリズムを必要とします。モデルを構築すると、そのモデルをプロダクションシステムにデプロイし、パフォーマンスを監視し、新たなデータに対して継続的に再トレーニングし、代替モデルと比較する必要があります。
このため、機械学習で生産的になるためには、いくつかの理由で課題が存在します:
- 実験の追跡が困難です。 お使いのラップトップでいくつかのファイルを操作していたり、インタラクティブなノートブックを使用していたりする際、どのようにして、特定の結果をもたらしたのがどのデータ、どのコード、どのパラメーターであることを説明しますか？
- コードの再現が困難です。 最新の注意を払ってコードのバージョンやパラメーターを追跡したとしても、同じ結果をサイド取得するには環境全体(ライブラリの依存関係など)をキャプチャする必要があります。他のデータサイエンティストがあなたのコードを使いたいと考えた際や、別のプラットフォーム(クラウドなど)で大規模に同じコードを実行したいと考えたには特に問題となります。
- モデルをパッケージングし、デプロイする標準化された方法がありません。 すべてのデータサイエンスチームは、使用するそれぞれのMLライブラリに対して自身のアプローチを持っており、生成されたモデル、コード、パラメータ間のリンクは多くの場合失われます。
- モデル(バージョンやステージ遷移)を管理する中央ストアが存在しません。 データサイエンスチームは多くのモデルを作成します。コラボレーションしたり、モデルライフサイクルを管理する中央的な場所がない場合には、データサイエンスチームはモデルのステージをどのように管理するのかに関しての課題に直面します: 開発からステージング、最終的にはアーカイブやプロダクションをそれぞれのバージョンや注釈、履歴とともに管理しなくてはなりません。
さらに、個々のMLライブラリがこれらの問題のいくつかに対するソリューションを提供していたとしても、ベストな結果を得るためには複数のMLライブラリをトライしなくてはならないことがほとんどです。MLflowによって、あなたがどのライブラリを使っているのかを他のデータサイエンティストが知る必要なしに「ブラックボックス」として再現できるように、モデルとすべてのライブラリをトレーニング、再利用、デプロイ、パッケージングできるようになります。
MLflowのコンポーネント
MLflowはMLワークフローの管理を支援する4つのコンポーネントを提供します:
MLflow Trackingは、機械学習のコードを実行する際にパラメーター、コードのバージョン、メトリクス、アーティファクトを記録し、あとで結果を可視化するAPIとUIです。結果をローカルファイルやサーバーに記録するためにいかなる環境(スタンドアローンのスクリプトやノートブック)でMLflow Trackingを活用し、複数の実行(ラン)を比較することができます。また、異なるユーザーの結果を比較得するために活用することもできます。
MLflow Projectsは、再利用可能なデータサイエンスコードをパッケージングするための標準フォーマットです。それぞれのプロジェクトは、コードを格納する単なるディレクトリやGitのリポジトリであり、依存関係やコードの実行方法を指定するための説明ファイルや単なる習慣を活用します。例えば、プロジェクトにはPythonのConda環境を指定するためのconda.yamlファイルを含めることができます。ProjectでMLflow Tracking APIを使用する際には、MLflowは自動でプロジェクトバージョン(Gitコミットなど)とすべてのパラメーターを記録します。GitHubやご自身のGitリポジトリから既存のMLflow Projcetsを簡単に実行することができ、マルチステップのワークフローでチェーンすることができます。
MLflow Modelsは、複数のフレーバーで機械学習モデルをパッケージングする慣習とそれらをデプロイする助けとなるさまざまなツールを提供します。それぞれのモデルは任意のファイルと、モデルを使用できるいくつかの「フレーバー」を一覧する説明ファイルを格納するディレクトリとして保存されます。例えば、TensorFlowモデルはTensorFlow DAGや入力データを適用するPython関数としてロードすることができます。MLflowはさまざまなプラットフォームで一般的なさまざまなモデルタイプをデプロイするためのツールを提供します: 例えば、「Python関数」フレーバーをサポートするすべてのモデルは、DockerベースのRESTサーバーやAzure MLやAWS SageMakerのようなクラウドプラットフォーム、バッチやストリーミング推論のためにApache Sparkのユーザー定義関数としてデプロイすることができます。Tracking APIを用いてMLflow Modelsを出力した際には、MLflowは自動でどのプロジェクトとランから得られたのかを記憶します。
MLflow Registryは、MLflowモデルの完全なライフサイクルをコラボレーションを通じて管理するための中央のモデルストア、一連のAPIやUIを提供します。モデルのリネージ(どのMLflowエクスペリメントとランがモデルを生成したのか)、モデルのバージョン管理、ステージ遷移(ステージングからプロダクション、アーカイブなど)、注釈を管理します。
参照アーティファクト
MLflow APIでアーティファクトの場所を指定した際、Tracking、Models、Projects APIを呼び出したのかに応じて構文が変化します。Tracking APIにおいては、(ランID, 相対パス)のタプルを用いてアーティファクトの場所を指定します。Models、Projects APIでは、以下の方法でアーティファクトの場所を指定します:
/Users/me/path/to/local/modelrelative/path/to/local/model-
<scheme>/<scheme-dependent-path>。例:s3://my_bucket/path/to/modelhdfs://<host>:<port>/<path>runs:/<mlflow_run_id>/run-relative/path/to/modelmodels:/<model_name>/<model_version>models:/<model_name>/<stage>-
mlflow-artifacts:/path/to/model。トラッキングサーバーを--serve-artifactsのプロキシーモードで実行している場合。
例:
Tracking API
mlflow.log_artifacts("<mlflow_run_id>", "/path/to/artifact")
Models API
mlflow.pytorch.log_model(
"runs:/<mlflow_run_id>/run-relative/path/to/model", registered_model_name="mymodel"
)
mlflow.pytorch.load_model("models:/mymodel/1")
スケーラビリティとビッグデータ
機械学習において良い結果を得る鍵となるのがデータです。このため、MLflowは大規模なデータセットや大規模な出力ファイル(モデルなど)、大量のエクスペリメントにスケールするように設計されています。特に、MLflowでは4つの次元でのスケールをサポートしています:
- 個々のMLflowランは、Apache Sparkを用いるなどした分散クラスターで実行することができます。お好きな分散処理インフラストラクチャでランを起動し、比較するためにトラッキングサーバーに結果をレポートすることができます。MLflowにはDatabricksでランを起動するためのビルトインAPIが含まれています。
- MLflowは、ハイパーパラメータチューニングなど異なるパラメータを用いて並列に複数のランを起動することができます。複数のランをスタートするためにシンプルにProjects APIを活用することができ、それらをトラッキングするためにTracking APIを使うことができます。
- MLflow ProjectsはAWS S3やDBFSのような分散ストレージと読み書きを行うことができます。MLflowはローカルファイルでのみ実行可能なプロジェクトのためにそれらのファイルをローカルに自動でダウンロードしたり、サポートしている場合には分散ストレージのURIをプロジェクトに提供します。これは、100TBのファイルの特徴量生成のように、大規模データセットを構築するプロジェクトを記述できることを意味します。
- MLflow Model Registryは、完全なモデルライフサイクルをコラボレーションを通じて管理するための中央ハブを第企業に提供します。企業内の多くのデータサイエンスチームは数百のモデルを開発し、それぞれのモデルにはエクスペリメント、ラン、バージョン、アーティファクト、ステージ遷移が伴います。中央のレジストリは、大企業における複数チームにおけるモデルの発見や目的の明確化の助けとなります。
ユースケースの例
あなたが一人で作業しているデータサイエンティストなのか、大企業に属しているのかに応じて、MLflowを活用する方法は複数存在します:
個々のデータサイエンティストは自分のマシンでローカルにエクスペリメントを追跡するためにMLflow Trackingを活用し、今後の再利用のためにprojectsでコードを整理し、MLflowのデプロイメントツールを用いてプロダクションエンジニアがデプロイすることができるモデルを出力します。MLflow Trackingはデフォルトではローカルのファイルシステムでファイルを読み書きするので、サーバーをデプロイする必要はありません。
データサイエンスチームは、同じ問題に取り組む複数のユーザーで結果を記録、比較するためにMLflowトラッキングサーバーをデプロイすることができます。パラメータやメトリクスに対する命名規則をセットアップすることで、同じ問題に取り組むためにさまざまなアルゴリズムを試すことができ、新たなデータに対して同じアルゴリズムを実行し、後でモデルを比較することができます。さらに、誰でも別のモデルをダウンロードして実行することができます。
大企業では、MLflowを用いてプロジェクト、モデル、結果を共有することができます。MLflow Projectsを用いて全てのチームが別のチームのコードを実行できるので、他のチームが活用できる有用なトレーニングステップやデータ準備ステップをパッケージすることができ、同じタスクに取り組んでいるさまざまなチームの結果を比較することができます。さらに、エンジニアリングチームは容易にワークフローをR&Dからステージング、プロダクションに移行することができます。
プロダクションエンジニアは、同じ方法でさまざまなMLライブラリのモデルをデプロイし、お使いの管理システムにファイルとしてモデルを格納し、モデルがどのランからもたらされたのかを追跡することができます。
研究者はオープンソース開発者は、MLflow ProjectフォーマットでGitHubにコードを公開することができ、誰でもmlflow run github.com/...コマンドを用いてそれらのコードを容易に実行できるようにします。
MLライブラリの開発者は、MLflowのビルトインツールを用いたデプロイメントを自動でサポートするように、MLflowモデルフォーマットでモデルを出力することができます。さらに、デプロイメントツールの開発者(サービングプラットフォームを構築しているクラウドベンダーなど)は、自動でさまざまなモデルをサポートすることができます。