メインコンテンツまでスキップ

MLflow 3 の概要

この記事では、MLflow 3 の使用を開始する方法について説明します。MLflow 3 のインストール方法について説明し、開始するためのいくつかのデモ ノートブックが含まれています。また、MLflow 3 の新機能について詳しく説明するページへのリンクも含まれています。

MLflow 3 とはどのようなもので、既存の MLflow バージョンとどのように異なりますか?​

DatabricksにおけるMLflow 3は、Databricks レイクハウスの機械学習モデル、生成AIアプリケーション、エージェントに対する最先端のエクスペリメントの追跡、可観測性、パフォーマンス評価を提供します。MLflow 3 では、主要な追跡の概念を維持しながら、重要な新機能が導入されているため、2.x からの移行が迅速かつ簡単になります。Databricks で MLflow 3 を使用すると、次のことができます。

  • 開発ノートブックの対話型クエリから本番運用バッチ、またはリアルタイム サービング デプロイまで、すべての環境にわたるモデル、 AI アプリケーション、エージェントのパフォーマンスを一元的に追跡および分析します。

モデル追跡 UI。

  • Unity Catalog のモデル バージョン ページと、REST APIのすべてのワークスペースとエクスペリメントで、モデル メトリクスとパラメーターを表示してアクセスします。

複数の実行からのメトリクスを示す Unity Catalog のモデルバージョンページ。

  • リクエストとレスポンス( トレース )にアノテーションを付けて、すべてのジェネレーションAIアプリケーションとエージェントの包括的なエンドツーエンドの可観測性を実現し、人間の専門家と自動化された LLMジャッジの手法が豊富なフィードバックを提供できるようにします。このフィードバックを活用して、アプリケーションバージョンのパフォーマンスを評価および比較し、品質を向上させるためのデータセットを構築できます。

複数のトレースの詳細を示すモデル ページの [トレース] タブ。

  • 組み込みおよびカスタムのLLMジャッジを備えた新しいmlflow.genai.evaluate()APIを使用して、生成AIアプリケーションを大規模に評価し、開発および本番運用中に生成AIアプリケーションの品質を評価します。

複数の評価の詳細を表示するエクスペリメントページの評価タブ。

  • Unity Catalog を使用して評価とデプロイのワークフローを調整し、モデル、AI アプリケーション、またはエージェントの各バージョンの包括的なステータスログにアクセスします。

段階的なロールアウトとメトリクス収集を含む複雑なデプロイ ジョブ。

これらの機能により、すべての AI イニシアチブの評価、デプロイ、デバッグ、モニタリングが簡素化および効率化されます。

生成AIの可観測性と評価​

MLflow 3 では、トレース、オブザーバビリティ、AI を活用したツールを組み合わせた包括的な 生成AI 機能が導入され、生成AI の品質を確実に測定できるため、アプリケーションのライフサイクル全体を通じて品質を監視および改善できます。MLflow エクスペリメント UI を活用して、Databricksにデプロイされているか外部にデプロイされているかに関係なく、本番運用アプリケーションからのトレースのリアルタイム ダッシュボードとモニタリング、フィードバックによる本番運用トレースの注釈付け、将来のイテレーションのためのデータセットの構築に活用できるようになりました。

MLflow 3 は、新しい評価機能を使用して、LLM の裁判官と人間のフィードバックを MLflow トレースに直接提供するためのファーストクラスのサポートを提供します。新しい mlflow.genai.evaluate() API は、 Agent Evaluation を利用した LLM ジャッジを MLflow SDK に統合し、評価に対するよりシンプルで強力なアプローチを提供します。事前構築済みスコアラーとカスタムスコアラーの両方をサポートしているため、デプロイ前にGenAIアプリケーションの品質に自信を持つことができます。さらに、ジャッジ向けのエージェント評価Databricks API、データセット、ラベリングセッション(Review App) ネームスペースに一元化され、シームレスな体験が可能になりました。mlflow.genai詳細については、「 生成AIためのMLflow 3」を参照してください。

記録済みモデル​

MLflow 3 の新機能の多くは、 LoggedModelの新しい概念に由来しています。生成AI アプリケーションまたはエージェントを開発する場合、開発者は git コミットまたはパラメーターのセットをトレースとメトリクスにリンクできるオブジェクトとしてキャプチャする LoggedModels を作成できます。 ディープラーニングや従来の ML アプリケーションの場合、 LoggedModels はトレーニング実行によって生成されたモデルの概念を高め、さまざまなトレーニングおよび評価実行間でモデルのライフサイクルを追跡するための専用オブジェクトとして確立します。

LoggedModels 開発のフェーズ (トレーニングと評価) および環境 (開発、ステージング、本番運用) 間で、メトリクス、パラメーター、トレースをキャプチャします。 LoggedModelをモデルバージョンとしてUnity Catalogに昇格すると、元のLoggedModelのすべてのパフォーマンスデータがUCモデルバージョンページに表示されるようになり、すべてのワークスペースとエクスペリメントを可視化できます。詳細については、「MLflow 記録済みモデルを使用したモデルの追跡と比較」を参照してください。

デプロイ ジョブ​

MLflow 3 では、デプロイ ジョブの概念も導入されています。デプロイ ジョブは、 LakeFlow ジョブを使用して、評価、承認、デプロイなどの手順を含むモデルのライフサイクルを管理します。 これらのモデル ワークフローは Unity Catalog によって管理され、すべてのイベントは Unity Catalog のモデル バージョン ページで使用できるアクティビティ ログに保存されます。

MLflow 2.x からの移行​

MLflow 3 には多くの新機能がありますが、エクスペリメントと実行のコア概念と、パラメーター、タグ、メトリクスなどのメタデータはすべて同じままです。MLflow 2.x から 3.0 への移行は非常に簡単で、ほとんどの場合、コードの変更は最小限で済みます。このセクションでは、MLflow 2.x との主な違いと、シームレスな移行のために注意すべき点について説明します。

ロギングモデル​

2.x でモデルをログに記録する場合は、 artifact_path パラメーターが使用されます。

with mlflow.start_run():
    mlflow.pyfunc.log_model(
        artifact_path="model",
        python_model=python_model,
        ...
    )

MLflow 3 では、代わりに name を使用すると、後でモデルを名前で検索できます。artifact_path パラメーターは引き続きサポートされていますが、非推奨になりました。さらに、MLflow 3 ではモデルが最優先になったため、MLflow ではモデルのログ記録時に実行をアクティブにする必要がなくなりました。最初に実行を開始せずに、モデルを直接ログに記録できます。

mlflow.pyfunc.log_model(
    name="model",
    python_model=python_model,
    ...
)

アーティファクトのモデル化​

MLflow 2.x では、モデル アーティファクトは、実行のアーティファクト パスの下に実行アーティファクトとして格納されます。MLflow 3 では、モデル アーティファクトは、モデルのアーティファクト パスの下の別の場所に格納されるようになりました。

# MLflow 2.x
experiments/
  └── <experiment_id>/
    └── <run_id>/
      └── artifacts/
        └── ... # model artifacts are stored here
# MLflow 3
experiments/
  └── <experiment_id>/
    └── models/
      └── <model_id>/
        └── artifacts/
          └── ... # model artifacts are stored here

問題を回避するために、mlflow.<model-flavor>.log_model から返されるモデル URI を使用して mlflow.<model-flavor>.load_model でモデルを読み込むことをお勧めします。このモデル URI は models:/<model_id> 形式 (MLflow 2.x のように runs:/<run_id>/<artifact_path> ではなく) であり、モデル ID のみが使用可能な場合は手動で作成することもできます。

モデルレジストリ​

MLflow3 では、デフォルト レジストリ URI がdatabricks-uc になり、Unity CatalogのMLflowモデルレジストリが使用されます (詳細については、「Unity Catalogでのモデルのライフサイクルの管理 」を参照してください)。Unity Catalog に登録されているモデルの名前は、<catalog>.<schema>.<model>という形式です。mlflow.register_modelなど、登録済みのモデル名が必要なAPIsを呼び出す場合は、この完全な 3 レベルの名前が使用されます。

Unity Catalogが有効になっていて、デフォルト カタログが Unity Catalogにあるワークスペースの場合、名前として <model> を使用することもでき、デフォルト カタログとスキーマが推論されます (Mlflow 2.x から動作に変更はありません)。ワークスペースで Unity Catalog が有効になっているが、 そのデフォルト カタログ が Unity Catalogに構成されていない場合は、完全な 3 レベルの名前を指定する必要があります。

DatabricksはUnity CatalogのMLflowモデルレジストリを使用して、モデルのライフサイクルを管理することをお勧めします。

Workspace Model Registry (legacy) を引き続き使用する場合は、次のいずれかの方法を使用してレジストリ URI を databricksに設定します。

その他の重要な変更​

  • MLflow 3 クライアントは、MLflow 2.x クライアントでログに記録されたすべての実行、モデル、トレースを読み込むことができます。ただし、必ずしもその逆であるとは限らないため、MLflow 3 クライアントでログ記録されたモデルとトレースは、古い 2.x クライアント バージョンで読み込むことができない場合があります。
  • mlflow.evaluate API は非推奨になりました。LLM または 生成AI アプリケーションの場合は、代わりに mlflow.genai.evaluate API を使用します。従来のMLモデルやディープラーニングモデルの場合は、元のmlflow.evaluate APIとの完全な互換性が維持されるmlflow.models.evaluateを使用してください
  • run_uuid 属性が RunInfo オブジェクトから削除されました。コードでは代わりに run_id を使用してください。

MLflow 3 をインストールする​

MLflow 3 を使用するには、正しい (>= 3.0) バージョンを使用するようにパッケージを更新する必要があります。次のコード行は、ノートブックが実行されるたびに実行する必要があります。

Python
%pip install mlflow>=3.0 --upgrade
dbutils.library.restartPython()

ノートブックの例​

MLflow次のページでは、従来のML ラーニングとディープラーニングの 3 モデル追跡ワークフローについて説明します。各ページには、サンプルノートブックが含まれています。

次のステップ​

MLflow 3 の新機能の詳細については、次の記事を参照してください。

に最終更新