1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MLflow 2.18.0のリリースノートと破壊的変更点に対する所感

Posted at

MLflow 2.18.0のrelease candidateが公開されました。

合せてリリースノートが出ていますが、将来に対する(個人的に)重要な変更点も記載されていたので、内容を確認して所感を述べてみます。

MLflow 2.18.0リリースノート

リリースノートの一部を和訳して掲載。

ほぼ機械翻訳ですので、正確には原文を確認ください。

2.18.0 (2024-11-12)

2.18.0リリースには、多くの重要な機能、強化、およびバグ修正が含まれています。

Pythonバージョンの更新

Python 3.8はサポート終了となりました。公式サポートが終了したため、MLflowはPython 3.9を最低サポートバージョンとします。

注: MLflowのChatModelインターフェースを使用してカスタムGenAIアプリケーションを作成している場合は、以下の将来の破壊的変更セクションを必ずお読みください。

実験的機能の破壊的変更

  • ChatModelインターフェースの変更 - MLflowおよびMLflowのGenAI機能と深く統合されているサービス内での統一化の一環として、カスタムGenAIアプリケーションの開発と使用のための一貫した標準インターフェースを作成するための段階的アプローチを進めています。最初の段階(次のいくつかのMLflowリリースで予定)では、いくつかのインターフェースを非推奨とし、変更される予定です。これらの変更は次のとおりです:

    • ChatModelインターフェースの名前変更
      • ChatRequestChatCompletionRequestに名前が変更され、将来予定されているリクエストインターフェースタイプの曖昧さを解消します。ChatRequestは将来の作業にはあまりにも一般的です。
      • ChatResponseChatCompletionResponseに名前が変更され、入力インターフェースと同じ理由です。
      • predict_streamはカスタムGenAIアプリケーションのための実際のストリーミング機能を提供するように更新されます。現在、predict_streamの戻り値の型はpredictの呼び出しからの同期出力を含むジェネレータです。将来のリリースでは、Chunksのジェネレータを返すように変更されます。predict_stream APIの既存の呼び出し構造は変更されませんが、返されるデータペイロードは大幅に変更され、非同期ストリーミング値が返される真のストリーミングリターンが可能になります。更新された戻り値の型は、既存のLangChainの実装に似たChatCompletionChunksのジェネレータになります。
      • ChatRequestChatResponseの可変コンポーネントは、現在メタデータフィールドとして設定されていますが、より具体的なcustom_inputsおよびcustom_outputsに名前が変更されます。これらのフィールド名は将来のGenAIインターフェースと一貫性を持たせます。
    • Rag Signaturesの非推奨
      • 異なるシステムへのインターフェースの複雑さを軽減するために、mlflow.models.rag_signatures内で定義されたデータクラスを将来のリリースで非推奨とし、これらをChatCompletionRequestChatCompletionResponse、およびChatCompletionChunks内の統一された署名定義およびデータ構造と統合します。

主要な新機能

  • Fluent APIスレッド/プロセスセーフティ - MLflowのトラッキングおよびモデルレジストリのためのFluent APIがオーバーホールされ、スレッドおよびマルチプロセスセーフティのサポートが追加されました。これにより、マルチプロセッシングおよびスレッド化されたアプリケーション内で実験、ラン、およびログの管理にClient APIを使用する必要がなくなります。

  • LLM-as-a-judgeエンドポイントの広範なサポート - このリリース以前は、LLMを使用してメトリックスコアを生成するMLflowの評価機能は、OpenAIのパブリックAPI、Databricksエンドポイント、またはAzureOpenAIエンドポイントのいずれかを使用する制限されたプロバイダーリストに制限されていました。

この制限は修正され、次のサポートが追加されました:

  • OpenAI互換エンドポイント - OpenAIのプロキシを実行している場合や、OpenAI仕様標準に準拠したセルフホスト型LLMを作成している場合、プロキシURLを定義し、評価リクエストと共に送信する追加ヘッダーを指定して、MLflow評価を使用して任意のLLMをジャッジとしてインターフェースすることができます。

  • 追加プロバイダー - Anthropic、Bedrock、Mistral、およびTogetherAIをOpenAIに加えてジャッジとして使用可能なLLMインターフェースとしてサポートします。これらの追加プロバイダーインターフェースに対してカスタムプロキシURLおよびヘッダーがサポートされます。

  • 強化されたトレースUI - マークダウンを使用したスパンコンテンツのレンダリングの強化から標準化されたスパンコンポーネント構造まで、MLflowのトレースUIは、GenAIトレースの内容を監査および調査する際の使いやすさと生活の質の向上をもたらすために大幅なオーバーホールが行われました。

  • DSPyフレーバー - MLflowは、DSPyモデルのログ、ロード、およびトレースをサポートし、MLflow内での高度なGenAI作成のサポートを拡大しました。

  • 環境変数依存関係の検出 - モデルをデプロイする際の便利なリマインダーとして、MLflowはモデルログ環境内で設定された検出された環境変数を記録し、これらの値をデプロイ時に設定するようにリマインダーを提供します。これに加えて、事前デプロイメント検証ユーティリティmlflow.models.predictに更新が加えられ、サブプロセスサービングシミュレーションに必要な環境変数が含まれるようになり、デプロイ前にモデルのデプロイ互換性を検証できるようになります。

2.18.0自体のリリースとしてはLLM-as-a-Judgeのジャッジモデルの拡大やDSPyフレーバーの追加が個人的関心事項ですね。

ただ、それよりもMLflowのChatModelにおける破壊的変更のアナウンスが個人的に一番大きいです。

これまでChatModelに関する記事をいくつか書きましたが、このあたりの挙動に大きく影響が起きますね。

ただ、predict_streamの修正は個人的に大きなポイントで、LLMの利用においては正直少し中途半端に感じていました。
記載があるように出力クラスがChatResponseクラスの形式でチャンクを出力するフォーマットにならず、このあたりが不便に感じていました。
これが是正されそうで非常にありがたい印象。

合せて以下のissueが解消されるんじゃないかなと期待しています。

以上、MLflow 2.18.0のリリースノートを見ての感想文でした。

2.17.xぐらいからChatModelのテコ入れが始まってるようで、個人的にワクワクしたのでポエムとして書いてみました。
MLflowのさらなるアップデートが楽しみです。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?