[翻訳] MLflow Tracingのコンセプト

[Tracing Concepts](https://mlflow.org/docs/latest/llms/tracing/overview.html)の翻訳です。

:::note warn
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
:::

このガイドでは、トレーシングとは何か、生成AI(GenAI)アプリケーションにどのように適用されるのか、トレーシングの主要コンポーネントが何であるのかを学びます。

![](https://mlflow.org/docs/latest/_images/tracing-top.gif)

このガイドの説明に対する適切な添付資料には、ここで議論されるコンセプトをMLflowがどのように構成するのかを説明している[Tracing Schema](https://mlflow.org/docs/latest/llms/tracing/tracing-schema.html)があります。

# トレーシングとは？

機械学習(ML)の文脈におけるトレーシングは、MLモデルの実行における詳細なトラッキングと、データフローと処理ステップの記録を指します。データ入力から予測の出力に至る、モデルオペレーションのそれぞれのステージにおける透明性と洞察を提供します。MLモデルのデバッグ、最適化、パフォーマンスの理解において、このような詳細なトラッキングが重要となります。

## 従来の機械学習

従来のMLでは、推論プロセスは比較的わかりやすいものです。リクエストが行われると、入力データはデータを処理し、予測結果を生成するモデルに投入されます。

以下の図では、入力データ、モデルサービングのインタフェース、モデル自身間の関係性を示しています。

![](https://mlflow.org/docs/latest/_images/tracing-traditional-ml.png)

このプロセスは完全に透明であり、入出力の両方が明確に定義され、エンドユーザーにとって理解可能なものです。例えば、SPAM検知モデルにおいては、入力はメールであり、出力はメールがSPAMかそうでないかを示す2値のラベルとなります。推論プロセス全体には透明性があり、どのようなデータが送信され、どのような推論結果が返却されるのかを容易に特定できるので、定量的なモデルパフォーマンスの文脈内で大きく逸脱したプロセスを完全にトレーシングすることができます。

しかし、サーバーに対するリクエストの処理の特性、モデル推論のレイテンシー、システムにアクセスするロギングAPIに対するさらなる洞察を提供するために、デプロイメント設定の一部としてトレーシングが含まれる場合があります。トレースロギングのこのような古典的な形態においては、レイテンシーやパフォーマンス観点で推論リクエストと関連づけられたメタデータは監視、記録され、これらのログは通常、モデルのオペレーションを理解するためにモデルの開発者やデータサイエンティストには活用されません。

## スパンのコンセプト

トレーシングの文脈において、スパンはシステムにおける単一のオペレーションを表現します。開始時間や終了時間、オペレーションに関するその他の文脈情報のようなメタデータをキャプチャします。このメタデータと共に、作業ユニット(生成AIモデルの呼び出し、ベクトルストアの検索、関数呼び出しなど)に提供される入力、オペレーションによる出力が記録されます。

以下の図では、スパン内での生成AIモデルの呼び出し、適切な情報の収集を説明しています。スパンには、開始時間や終了時間、リクエストの引数、呼び出しの入出力が含まれます。

![](https://mlflow.org/docs/latest/_images/span-anatomy.png)

## トレースのコンセプト

生成AIトレーシングの文脈におけるトレースは、プロセッサで非同期的に呼び出され記録される、有向非循回グラフ(DAG)のようなスパンのイベントのコレクションとなります。それぞれのスパンはシステムにおける単一のオペレーションを表現し、開始時間、終了時間、その他の文脈情報のようなメタデータを含みます。これらのスパンは、エンドツーエンドのプロセスに対する包括的なビューを提供するトレースを構成するために接続されます。

- **DAGライクの構造:** DAG構造によって、オペレーションのシーケンスに循環がないことを確実にし、実行フローの理解を容易にします。
- **スパン情報:** それぞれのスパンは、関数呼び出し、データベースのクエリー、APIリクエストのような個別の作業ユニットをキャプチャします。スパンにはオペレーションの文脈を与えるメタデータが含まれています。
- **階層型の関連性:** スパンはあなたのアプリケーションの鏡となり、さまざまなコンポーネントがどのように相互作用し、どのような依存関係にあるのかを確認することができます。

これらのスパンを収集、解析することで、実行パスを追跡し、ボトルネックを特定し、システムのさまざまなコンポーネント間の依存関係やインタラクションを理解することができます。生成AIアプリケーションの堅牢性を保証し、問題を診断し、パフォーマンスを最適化するには、このレベルの可視性が重要となります。

RAGアプリケーションで全体のトレースが何をキャプチャできるのかを説明するためには、以下の図をご覧ください。

![](https://mlflow.org/docs/latest/_images/trace-concept.png)

このアプリケーションに含まれるサブシステムは、システムの品質と適切性において重要なものとなります。最終ステージのLLMとやり取りを行う際にデータが流れるであろうパスに対する可視性を持たないと、それぞれのピースに対して非常に単調で面倒、高コストな手動での検証によってのみ品質が達成されるアプリケーションを生み出すことになります。

## 生成AI ChatCompletionsのユースケース

チャットコンプリーションのような生成AIアプリケーションにおいては、モデルと生成AIを活用したアプリケーションの開発にとってトレーシングが非常に重要なものとなります。これらのユースケースには、入力プロンプトに基づいて人間のようなテキストを制することなどが含まれます。エージェントや生成AIモデルを拡張するための情報検索を含む生成AIアプリケーションほど複雑ではありませんが、チャットインタフェースはトレーシングによるメリットを享受することができます。チャットセッションを通じた生成AIモデルとのやり取り単位でのインタフェースに対するトレーシングを有効化することで、文脈的な履歴、プロンプト、入力、設定パラメータ、出力全体に対する評価、生成AIモデルに送信されたリクエストペイロードの完全な文脈をカプセル化することができます。

例として、以下の図では、デプロイメントサーバーにホストされている、モデルへの接続に用いられるChatCompletionsのインタフェース、外部の生成AIサービスへのインタフェースが示されています。

![](https://mlflow.org/docs/latest/_images/chat-completions-architecture.png)

課金、パフォーマンス評価、適切性、ハルシネーションの評価、一般的なデバッグを含む、インタフェースプロセスを取り囲むその他のメタデータは様々な理由から有用なものと言えます。キーとなるメタデータには以下のようなものがあります:

- **トークン数:** 課金に影響を与える処理トークン数。
- **モデル名:** 推論に用いられた固有のモデル。
- **プロバイダータイプ:** モデルを提供するサービス、プラットフォーム。
- **クエリーパラメータ:** 生成プロセスに影響を与えるtemperatureやtop-k。
- **入力クエリー:** リクエストの入力(ユーザーの質問)。
- **クエリーレスポンス:** 生成を調整するためにクエリーパラメータを用いて、入力クエリーに対してシステムが生成したレスポンス。

このメタデータは、生成されるレスポンスの品質やパフォーマンスに様々な設定がどのような影響を与えるのかを理解する役に立ち、ファインチューニングや最適化の助けとなります。

## 高度なRAGアプリケーション

Retrieval-Augmented Generation (RAG)のようにより複雑なアプリケーションにおいては、効果的なデバッグと最適化においてトレーシングが重要となります。RAGにはドキュメントの収集、生成AIモデルとのやり取りを含む複数のステージが関与します。入力と出力しか見えないと、改善のための問題や機会のソースを特定することが困難となります。

例えば、生成AIシステムが満足できないレスポンスを生成する場合、問題は以下のような箇所にあるかも知れません:

- **ベクトルストアの最適化:** ドキュメント収集プロセスの効率性と精度。
- **エンべディングモデル:** エンコード、適切なドキュメントの検索に用いられるモデルの品質。
- **リファレンスマテリアル:** 検索されるドキュメントのコンテンツと品質。

トレーシングによって、RAGパイプラインにおけるそれぞれのステップを、品質のために調査、判断することができるようになります。すべてのステージに対する可視性を提供することで、トレーシングは収集プロセス、エンべディングモデル、リファレンスマテリアルのコンテンツのどこで調整が必要なのかを特定する助けとなります。

例えば、以下の図では、最終的な出力生成プロセスをガイドする追加の収集データを用いて繰り返し生成AIモデルが呼び出される、シンプルなRAGアプリケーションを構成する複雑なインタラクションを説明しています。

![](https://mlflow.org/docs/latest/_images/rag-architecture.png)

このように複雑なシステムでトレーシングが有効化されていないと、問題の根本原因やボトルネックの特定が困難となります。以下のステップは実際には「ブラックボックス」となってしまうことでしょう:

1. **入力クエリーのエンべディング**
1. **エンコードされたクエリーベクトルの戻り値**
1. **ベクトル検索の入力**
1. **ベクトルデータベースから収集されたドキュメントのチャンク**
1. **生成AIへの最終的な入力**

それぞれのリクエストに関連付けられる、入力、出力、メタデータをキャプチャするように設定された手段を備えたこれら5つの重要なステップなしでの、このようなシステムのレスポンスに関する問題の適切性の診断は、このようなアプリケーションのデバッグ、改善、改良を困難にします。反応性やコストに関するパフォーマンスチューニングを検討する際、これらのステップそれぞれにおけるレイテンシーに対する可視性を持たないと、それぞれのステップでの設定や手動での実装を必要とする全く異なる課題を引き起こすことになります。

# MLflowのトレーシングを使い始める

MLflowでのトレーシングの活用について学ぶのであれば、[MLflow Tracing Guide](https://mlflow.org/docs/latest/llms/tracing/index.html)をご覧ください