評価セット

プレビュー

この機能はパブリックプレビュー段階です。

エージェントアプリケーションの品質を測定するには、高品質で正確な応答がどのようなものかを定義できる必要があります。 これを行うには、評価セットを指定します。 この記事では、評価セットに必要なスキーマ、評価セットに存在するデータに基づいて計算されるメトリック、および評価セットを作成するためのベスト プラクティスについて説明します。

Databricks では、人間がラベル付けした評価セットを作成することを推奨しています。 これは、代表的な質問とグラウンドトゥルースの回答のセットです。 アプリケーションに取得ステップが含まれている場合は、応答の根拠となるサポート ドキュメントをオプションで提供することもできます。

適切な評価セットには、次の特性があります。

  • 代表的セット:アプリケーションが本番運用で遭遇するリクエストの範囲を正確に反映する必要があります。

  • 困難: アプリケーションの機能の全範囲を効果的にテストするには、困難で多様なケースを含める必要があります。

  • 継続的更新セット:アプリケーションの使用方法と変化する運用トラフィックのパターンを反映するために、定期的に更新する必要があります。

評価セットを使用して評価を実行する方法については、「評価を実行して結果を表示する方法」を参照してください。

評価セットスキーマ

次の表は、mlflow.evaluate()呼び出しで提供されるDataFrameに必要なスキーマを示しています。

データ型

説明

入力引数として渡されたアプリケーション

提供された以前の生成出力

request_id

文字列

リクエストの一意の識別子。

オプション

オプション

リクエスト

文字列

評価するアプリケーションへの入力、ユーザーの質問またはクエリ。 たとえば、「RAG とは」などです。

*必須

*必須

expected_retrieved_context

配列

リクエストに対して期待される取得コンテキストを含むオブジェクトの配列 (アプリケーションに取得ステップが含まれている場合)。 配列スキーマ

オプション

オプション

expected_response

文字列

入力要求に対するグラウンドトゥルース (正解) の回答。

オプション

オプション

response

文字列

評価対象のアプリケーションによって生成された応答。

エージェント評価によって生成

オプション。指定されていない場合は、トレースから派生します。responseまたはtraceのいずれかが必要です。

retrieved_context

配列

評価対象のアプリケーションでリトリーバーによって生成された取得結果。 アプリケーション内に複数の取得ステップがある場合、これは最後のステップ(トレース内で時系列順)からの取得結果です。 配列スキーマ

エージェント評価によって生成

オプション。提供されていない場合は、提供されたトレースから派生します。

trace

MLフロートレースのJSON文字列

対応するリクエストに対するアプリケーションの実行の MLflow トレース。

エージェント評価によって生成

オプション。responseまたはtraceのいずれかが必要です。

評価セット内の配列のスキーマ

配列expected_retrieved_contextretrieved_contextのスキーマは以下の表の通りです:

データ型

説明

入力引数として渡されたアプリケーション

提供された以前の生成出力

コンテンツ

文字列

取得したコンテキストの内容。HTML、プレーンテキスト、Markdownなどの任意の形式の文字列。

オプション

オプション

doc_uri

文字列

チャンクの元となった親ドキュメントの一意の識別子(URI)。

*必須

*必須

アプリケーションがmodel入力引数を通じて渡されたときに使用できるメトリック

計算されるメトリクスは、評価セットで提供されるデータによって決まります。 次の表は、アプリケーションを入力引数として受け取る評価の依存関係を示しています。 列は評価セットに含まれるデータを示し、 Xそのデータが提供される場合にメトリックがサポートされていることを示します。

これらのメトリクスの測定内容の詳細については、 「エージェント メトリクスとLLM審査員を使用してアプリのパフォーマンスを評価する」を参照してください。

計算されたメトリクス

request

request そして expected_response

requestexpected_response 、および expected_retrieved_context

response/llm_judged/relevance_to_query/rating

response/llm_judged/safety/rating

response/llm_judged/groundedness/rating

retrieval/llm_judged/chunk_relevance_precision

agent/total_token_count

agent/input_token_count

agent/output_token_count

response/llm_judged/correctness/rating

retrieval/ground_truth/document_recall

requestのみを含むサンプル評価セット

eval_set = [
    {
        "request": "What is the difference between reduceByKey and groupByKey in Spark?",
    }
]

requestexpected_responseを使用したサンプル評価セット

eval_set  = [
    {
        "request_id": "request-id",
        "request": "What is the difference between reduceByKey and groupByKey in Spark?",
        "expected_response": "There's no significant difference.",
    }
]

requestexpected_responseexpected_retrieved_contentのサンプル評価セット

eval_set  = [
    {
        "request_id": "request-id",
        "request": "What is the difference between reduceByKey and groupByKey in Spark?",
        "expected_retrieved_context": [
            {
                "doc_uri": "doc_uri_1",
            },
            {
                "doc_uri": "doc_uri_2",
            },
        ],
        "expected_response": "There's no significant difference.",
    }
]

アプリケーション出力が提供されている場合に利用可能なメトリクス

計算されるメトリクスは、評価セットで提供されるデータによって決まります。 この表は、評価セットとアプリケーション出力を Dataframe に提供する評価の依存関係を示しています。 列は評価セットに含まれるデータを示し、 Xそのデータが提供される場合にメトリックがサポートされていることを示します。

計算されたメトリクス

request そして response

requestresponse 、および retrieved_context

requestresponseretrieved_context、および expected_response

requestresponseretrieved_contextexpected_response、および expected_retrieved_context

response/llm_judged/relevance_to_query/rating

response/llm_judged/safety/rating

agent/request_token_count

agent/response_token_count

顧客定義のLLMジャッジ

retrieval/llm_judged/chunk_relevance/precision

response/llm_judged/groundedness/rating

response/llm_judged/correctness/rating

retrieval/ground_truth/document_recall

requestresponseのみを含むサンプル評価セット

eval_set = [
    {
        "request": "What is the difference between reduceByKey and groupByKey in Spark?",
        "response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
    }
]

requestresponseretrieved_contextのサンプル評価セット

eval_set = [
    {
        "request_id": "request-id", # optional, but useful for tracking
        "request": "What is the difference between reduceByKey and groupByKey in Spark?",
        "response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
        "retrieved_context": [
            {
                # In `retrieved_context`, `content` is optional, but delivers additional functionality if provided (the Databricks Context Relevance LLM judge runs to check the relevance of the provided content to the request).
                "content": "reduceByKey reduces the amount of data shuffled by merging values before shuffling.",
                "doc_uri": "doc_uri_2_1",
            },
            {
                "content": "groupByKey may lead to inefficient data shuffling due to sending all values across the network.",
                "doc_uri": "doc_uri_6_extra",
            },
        ],
    }
]

requestresponseretrieved_contextexpected_responseのサンプル評価セット

eval_set  = [
    {
        "request_id": "request-id",
        "request": "What is the difference between reduceByKey and groupByKey in Spark?",
        "expected_response": "There's no significant difference.",
        "response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
        "retrieved_context": [
            {
                # In `retrieved_context`, `content` is optional, but delivers additional functionality if provided (the Databricks Context Relevance LLM judge runs to check the relevance of the provided content to the request).
                "content": "reduceByKey reduces the amount of data shuffled by merging values before shuffling.",
                "doc_uri": "doc_uri_2_1",
            },
            {
                "content": "groupByKey may lead to inefficient data shuffling due to sending all values across the network.",
                "doc_uri": "doc_uri_6_extra",
            },
        ],
    }
]

requestresponseretrieved_contextexpected_responseexpected_retrieved_contextのサンプル評価セット

level_4_data  = [
    {
        "request_id": "request-id",
        "request": "What is the difference between reduceByKey and groupByKey in Spark?",
        "expected_retrieved_context": [
            {
                "doc_uri": "doc_uri_2_1",
            },
            {
                "doc_uri": "doc_uri_2_2",
            },
        ],
        "expected_response": "There's no significant difference.",
        "response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
        "retrieved_context": [
            {
                # In `retrieved_context`, `content` is optional, but delivers additional functionality if provided (the Databricks Context Relevance LLM judge runs to check the relevance of the provided content to the request).
                "content": "reduceByKey reduces the amount of data shuffled by merging values before shuffling.",
                "doc_uri": "doc_uri_2_1",
            },
            {
                "content": "groupByKey may lead to inefficient data shuffling due to sending all values across the network.",
                "doc_uri": "doc_uri_6_extra",
            },
        ],
    }
]

評価セットを開発するためのベストプラクティス

  • 評価セット内の各サンプルまたはサンプルのグループを単体テストとして検討します。つまり、各サンプルは、明示的に期待される結果を持つ特定のシナリオに対応している必要があります。たとえば、より長い文脈、マルチホップの推論、間接的な証拠から答えを推測する能力をテストすることを検討してください。

  • 悪意のあるユーザーによる敵対的なシナリオのテストを検討してください。

  • 評価セットに含める質問の数に関する具体的なガイドラインはありません。通常、高品質のデータからの明確な信号は、弱いデータからのノイズの多い信号よりもパフォーマンスが優れています。

  • 人間にとっても答えるのが非常に難しい例を含めることを検討してください。

  • 汎用のアプリケーションを構築しているのか、特定のドメインをターゲットにしているのかに関わらず、アプリにはさまざまな質問が投げかけられます。評価セットには、それを反映させる必要があります。たとえば、人事に関する特定の質問に回答するアプリケーションを作成する場合でも、アプリケーションが困惑したり、有害な反応を示したりしないように、他のドメイン(業務など)をテストすることを検討する必要があります。

  • 高品質で一貫性のある人間が生成したラベルは、アプリケーションに提供するグラウンドトゥルース値が目的の動作を正確に反映するようにするための最良の方法です。 高品質なヒューマンラベルを確保するためのいくつかのステップは次のとおりです。

    • 同じ質問に対する複数のラベル付け担当者からの回答(ラベル)を集約します。

    • ラベル付けの指示が明確であり、ラベル付け担当者が一貫していることを確認します。

    • 人間によるラベル付けプロセスの条件が、RAGアプリケーションに送信されるリクエストの形式と同じであることを確認してください。

  • 人間のラベル付け者は、質問の解釈が異なるなど、本質的にノイズが多く一貫性がありません。これはプロセスの重要な部分です。ヒューマンラベリングを使用すると、考えていなかった質問の解釈が明らかになり、申請時に観察した行動についての知見が得られる場合があります。