Agent Evaluationによる品質、コスト、レイテンシの評価方法

プレビュー

この記事では、Agent Evaluation が Agent Evaluation で AI アプリケーションの品質、コスト、レイテンシを評価する方法を説明し、品質の向上とコストとレイテンシの最適化を導くための知見を提供します。内容は次のとおりです。

LLMの審査員による品質の評価方法。
コストと待機時間の評価方法。
MLflowランのレベルでメトリクスを集計する方法。品質、コスト、レイテンシについて。

各組み込み LLM ジャッジのリファレンス情報については、「 Mosaic AI エージェント評価 LLM ジャッジリファレンス」を参照してください。

LLM審査員による品質評価方法

エージェント評価は、LLMジャッジを使用して2つのステップで品質を評価します。

LLMの審査員は、各行の特定の品質側面(正確性や根拠など)を評価します。詳細については、「ステップ 1: LLM 審査員が各行の品質を評価する」を参照してください。
エージェント評価は、個々のジャッジの評価を全体的な合格/不合格スコアと不合格の根本原因に組み合わせます。詳細については、「ステップ 2: LLM ジャッジ評価を組み合わせて品質問題の根本原因を特定する」を参照してください。

LLMジャッジの信頼性と安全性に関する情報については、ジャッジLLM動力源となるモデルに関する情報を参照してください。

ステップ1:LLM審査員がそれぞれの行の品質を評価

Agent Evaluation は、すべての入力行について、一連の LLM ジャッジを使用して、エージェントの出力に関する品質のさまざまな側面を評価します。各審査員は、以下の例に示すように、はいまたはいいえのスコアと、そのスコアの根拠を書面で作成します。

使用される LLM ジャッジの詳細については、「使用可能な LLM ジャッジ」を参照してください。

ステップ 2: LLM審査員の評価を組み合わせて、品質問題の根本原因を特定する

LLMジャッジを実行した後、Agent Evaluationはその出力を分析して全体的な品質を評価し、ジャッジの集合的な評価で合格/不合格の品質スコアを決定します。全体的な品質が失敗した場合、Agent Evaluation は、失敗の原因となった特定の LLM ジャッジを特定し、推奨される修正を提供します。

データは MLflow UI に表示され、 mlflow.evaluate(...) 呼び出しによって返される DataFrame の MLflow 実行からも使用できます。 DataFrame へのアクセス方法の詳細については、評価出力のレビューを参照してください。

次のスクリーンショットは、UI の概要分析の例です。

各行の結果は、詳細ビュー UI で確認できます。

利用可能なLLM審査員

以下の表は、品質のさまざまな側面を評価するためにエージェント評価で使用される一連のLLMジャッジをまとめたものです。詳細については、 Response judges および Retrieval judgesを参照してください。

LLM ジャッジを強化するモデルの詳細については、「 LLM ジャッジを強化するモデルに関する情報」を参照してください。各組み込み LLM ジャッジのリファレンス情報については、「 Mosaic AI エージェント評価 LLM ジャッジリファレンス」を参照してください。

審査員の氏名	ステップ	審査員が評価する品質面	必須入力	グラウンドトゥルースが必要ですか?
`relevance_to_query`	レスポンス	応答アドレスはユーザーの要求に関連していますか (関連していますか) ?	`response`, `request`	いいえ
`groundedness`	レスポンス	生成された応答は、取得したコンテキストに基づいていますか(幻覚ではありません)?	`response`, `trace[retrieved_context]`	いいえ
`safety`	レスポンス	回答に有害または有毒なコンテンツが含まれていますか?	`response`	いいえ
`correctness`	レスポンス	生成された応答は (グラウンドトゥルースと比較して) 正確ですか?	`response`, `expected_response`	あり
`chunk_relevance`	検索	レトリーバーは、ユーザーのリクエストに応答するのに役立つ(関連性のある)チャンクを見つけましたか? 注: このジャッジは、取得された各チャンクに個別に適用され、各チャンクのスコアと根拠が生成されます。これらのスコアは、関連するチャンクの割合を表す各行の `chunk_relevance/precision` スコアに集計されます。	`retrieved_context`, `request`	いいえ
`document_recall`	検索	レトリーバーは既知の関連文書をいくつ見つけましたか?	`retrieved_context`, `expected_retrieved_context[].doc_uri`	あり
`context_sufficiency`	検索	レトリーバーは、期待される応答を生成するのに十分な情報を含むドキュメントを見つけましたか?	`retrieved_context`, `expected_response`	あり

次のスクリーンショットは、これらのジャッジが UI でどのように表示されるかの例を示しています。

根本原因の特定方法

すべての審査員が合格した場合、品質は passと見なされます。いずれかのジャッジが不合格となった場合、以下の順序リストに基づいて、最初に不合格となったジャッジが根本原因と判断されます。この順序付けが使用されるのは、裁判官の評価が因果関係で相関していることが多いためです。たとえば、レトリーバーが入力リクエストに対して適切なチャンクまたはドキュメントを取得していないと context_sufficiency が評価した場合、ジェネレータは適切なレスポンスの合成に失敗するため、 correctness も失敗する可能性があります。

グラウンドトゥルースが入力として提供される場合、次の順序が使用されます。

context_sufficiency
groundedness
correctness
safety
顧客定義の LLM 裁判官

グラウンドトゥルースが入力として提供されていない場合は、次の順序が使用されます。

chunk_relevance - 関連するチャンクは少なくとも 1 つありますか?
groundedness
relevant_to_query
safety
顧客定義の LLM 裁判官

Databricks が LLM のジャッジ精度を維持および改善する方法

Databricks は、LLM 審査員の質を向上させることに専念しています。品質は、 LLM 審査員が人間の評価者とどの程度一致しているかを測定することで評価されます。これは、以下のメトリクスを使用して行われます。

コーエンのカッパ(評価者間の一致の尺度)を増加させました。
精度の向上 (予測されたラベルのうち、人間の評価者のラベルと一致するものの割合)。
F1スコアが増加しました。
誤検知率の低下。
偽陰性率の低下。

これらのメトリクスを測定するために、 Databricks は、顧客データセットを代表する学術的および独自のデータセットからの多様で挑戦的な例を使用して、最先端の LLM ジャッジアプローチに対する審査員のベンチマークと改善を行い、継続的な改善と高い精度を確保しています。

Databricks がジャッジの品質を測定し、継続的に改善する方法の詳細については、「 Databricks がエージェント評価の組み込み LLM ジャッジの大幅な改善を発表」を参照してください。

`databricks-agents` SDKを使用して審査員を試す

このdatabricks-agents SDK には、ユーザー入力に対してジャッジを直接呼び出す APIs が含まれています。これらの APIs を使用して、審査員がどのように機能するかを確認するための迅速かつ簡単なエクスペリメントを行うことができます。

次のコードを実行して、 databricks-agents パッケージをインストールし、Pythonカーネルを再起動します。

%pip install databricks-agents -U
dbutils.library.restartPython()

その後、ノートブックで次のコードを実行し、必要に応じて編集して、自分の入力でさまざまなジャッジを試すことができます。

from databricks.agents.eval import judges

SAMPLE_REQUEST = "What is MLflow?"
SAMPLE_RESPONSE = "MLflow is an open-source platform"
SAMPLE_RETRIEVED_CONTEXT = [
        {
            "content": "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."
        }
    ]
SAMPLE_EXPECTED_RESPONSE = "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."

# For chunk_relevance, the required inputs are `request`, `response` and `retrieved_context`.
judges.chunk_relevance(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For context_sufficiency, the required inputs are `request`, `expected_response` and `retrieved_context`.
judges.context_sufficiency(
  request=SAMPLE_REQUEST,
  expected_response=SAMPLE_EXPECTED_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For correctness, required inputs are `request`, `response` and `expected_response`.
judges.correctness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  expected_response=SAMPLE_EXPECTED_RESPONSE
)

# For relevance_to_query, the required inputs are `request` and `response`.
judges.relevance_to_query(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

# For groundedness, the required inputs are `request`, `response` and `retrieved_context`.
judges.groundedness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For safety, the required inputs are `request` and `response`.
judges.safety(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

コストとレイテンシの評価方法

エージェント評価は、トークン数と実行レイテンシを測定し、エージェントのパフォーマンスを理解するのに役立ちます。

トークンコスト

コストを評価するために、Agent Evaluation コンピュートは、トレース内のすべての LLM 生成呼び出しの合計トークン数をコンピュートします。これは、トークンの数が増えるほど与えられる総コストを概算したもので、一般的にはコストの増加につながります。トークン数は、 trace が利用可能な場合にのみ計算されます。 mlflow.evaluate()の呼び出しに model 引数が含まれている場合は、トレースが自動的に生成されます。評価データセットに trace 列を直接指定することもできます。

次のトークン数が各行で計算されます。

データフィールド	タイプ	説明
`total_token_count`	`integer`	エージェントのトレース内のすべての LLM スパンにわたるすべての入力トークンと出力トークンの合計。
`total_input_token_count`	`integer`	エージェントのトレース内のすべての LLM スパンにわたるすべての入力トークンの合計。
`total_output_token_count`	`integer`	エージェントのトレース内のすべての LLM スパンにわたるすべての出力トークンの合計。

実行レイテンシ

トレースのアプリケーション全体のレイテンシを秒単位でコンピュートします。レイテンシは、トレースが使用可能な場合にのみ計算されます。 mlflow.evaluate()の呼び出しに model 引数が含まれている場合は、トレースが自動的に生成されます。評価データセットに trace 列を直接指定することもできます。

次のレイテンシ測定値は、各行に対して計算されます。

名前	説明
`latency_seconds`	トレースに基づくエンドツーエンドの待機時間

MLflowランのレベルでメトリクスを集計する方法 (品質、コスト、レイテンシ)

行ごとの品質、コスト、およびレイテンシの評価をすべて計算した後、Agent Evaluation は、これらの評価を MLflow 実行に記録される実行ごとのメトリクスに集約し、すべての入力行にわたるエージェントの品質、コスト、およびレイテンシを要約します。

Agent Evaluation では、次のメトリクスが生成されます。

メトリクス名	タイプ	説明
`retrieval/llm_judged/chunk_relevance/precision/average`	`float, [0, 1]`	すべての質問の平均値は `chunk_relevance/precision` です。
`retrieval/llm_judged/context_sufficiency/rating/percentage`	`float, [0, 1]`	`context_sufficiency/rating`が`yes`と判断された質問の割合 .
`response/llm_judged/correctness/rating/percentage`	`float, [0, 1]`	`correctness/rating`が`yes`と判断された質問の割合 .
`response/llm_judged/relevance_to_query/rating/percentage`	`float, [0, 1]`	`relevance_to_query/rating`が`yes`と判断された質問の割合 .
`response/llm_judged/groundedness/rating/percentage`	`float, [0, 1]`	`groundedness/rating`が`yes`と判断された質問の割合 .
`response/llm_judged/safety/rating/average`	`float, [0, 1]`	`yes`と判断される質問の割合`safety/rating`。
`agent/total_token_count/average`	`int`	すべての質問の平均値は `total_token_count` です。
`agent/input_token_count/average`	`int`	すべての質問の平均値は `input_token_count` です。
`agent/output_token_count/average`	`int`	すべての質問の平均値は `output_token_count` です。
`agent/latency_seconds/average`	`float`	すべての質問の平均値は `latency_seconds` です。
`response/llm_judged/{custom_response_judge_name}/rating/percentage`	`float, [0, 1]`	`{custom_response_judge_name}/rating`が`yes`と判断された質問の割合 .
`retrieval/llm_judged/{custom_retrieval_judge_name}/precision/average`	`float, [0, 1]`	すべての質問の平均値は `{custom_retrieval_judge_name}/precision` です。

次のスクリーンショットは、メトリクスがUIにどのように表示されるかを示しています。

LLMジャッジを使用するモデルに関する情報

LLMジャッジは、Microsoftが運営するAzure OpenAIなどのサードパーティサービスを使用して生成AIアプリケーションを評価する場合があります。
Azure OpenAIの場合、Databricksは不正行為モニタリングをオプトアウトしているため、プロンプトや応答はAzure OpenAIに保存されません。
欧州連合（EU）のワークスペースの場合、LLMジャッジはEUでホストされているモデルを使用します。他のすべてのリージョンでは、米国でホストされているモデルを使用します。
パートナー向けの AI 支援機能を無効にすると、LLM の審査員がパートナー向けのモデルを呼び出すのを防ぐことができます。
LLMジャッジに送信されたデータは、モデルのトレーニングには使用されません。
LLMジャッジは、顧客のRAGアプリケーションの評価を支援することを目的としており、LLMジャッジの出力は、LLMのトレーニング、改善、微調整のために使用されるべきではありません。