評価セット
プレビュー
この機能はパブリックプレビュー段階です。
エージェントアプリケーションの品質を測定するには、高品質で正確な応答がどのようなものかを定義できる必要があります。 これを行うには、評価セットを指定します。 この記事では、評価セットに必要なスキーマ、評価セットに存在するデータに基づいて計算されるメトリック、および評価セットを作成するためのベスト プラクティスについて説明します。
Databricks では、人間がラベル付けした評価セットを作成することを推奨しています。 これは、代表的な質問とグラウンドトゥルースの回答のセットです。 アプリケーションに取得ステップが含まれている場合は、応答の根拠となるサポート ドキュメントをオプションで提供することもできます。
適切な評価セットには、次の特性があります。
代表的セット:アプリケーションが本番運用で遭遇するリクエストの範囲を正確に反映する必要があります。
困難: アプリケーションの機能の全範囲を効果的にテストするには、困難で多様なケースを含める必要があります。
継続的更新セット:アプリケーションの使用方法と変化する運用トラフィックのパターンを反映するために、定期的に更新する必要があります。
評価セットを使用して評価を実行する方法については、「評価を実行して結果を表示する方法」を参照してください。
評価セットスキーマ
次の表は、mlflow.evaluate()
呼び出しで提供されるDataFrameに必要なスキーマを示しています。
列 |
データ型 |
説明 |
入力引数として渡されたアプリケーション |
提供された以前の生成出力 |
---|---|---|---|---|
request_id |
文字列 |
リクエストの一意の識別子。 |
オプション |
オプション |
リクエスト |
文字列 |
評価するアプリケーションへの入力、ユーザーの質問またはクエリ。 たとえば、「RAG とは」などです。 |
*必須 |
*必須 |
expected_retrieved_context |
配列 |
リクエストに対して期待される取得コンテキストを含むオブジェクトの配列 (アプリケーションに取得ステップが含まれている場合)。 配列スキーマ |
オプション |
オプション |
expected_response |
文字列 |
入力要求に対するグラウンドトゥルース (正解) の回答。 |
オプション |
オプション |
response |
文字列 |
評価対象のアプリケーションによって生成された応答。 |
エージェント評価によって生成 |
オプション。指定されていない場合は、トレースから派生します。 |
retrieved_context |
配列 |
評価対象のアプリケーションでリトリーバーによって生成された取得結果。 アプリケーション内に複数の取得ステップがある場合、これは最後のステップ(トレース内で時系列順)からの取得結果です。 配列スキーマ |
エージェント評価によって生成 |
オプション。提供されていない場合は、提供されたトレースから派生します。 |
trace |
対応するリクエストに対するアプリケーションの実行の MLflow トレース。 |
エージェント評価によって生成 |
オプション。 |
アプリケーションがmodel
入力引数を通じて渡されたときに使用できるメトリック
計算されるメトリクスは、評価セットで提供されるデータによって決まります。 次の表は、アプリケーションを入力引数として受け取る評価の依存関係を示しています。 列は評価セットに含まれるデータを示し、 X
そのデータが提供される場合にメトリックがサポートされていることを示します。
これらのメトリクスの測定内容の詳細については、 「エージェント メトリクスとLLM審査員を使用してアプリのパフォーマンスを評価する」を参照してください。
計算されたメトリクス |
|
|
|
---|---|---|---|
|
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
|
✓ |
✓ |
|
|
✓ |
request
のみを含むサンプル評価セット
eval_set = [
{
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
}
]
request
とexpected_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.",
}
]
request
、expected_response
、expected_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
そのデータが提供される場合にメトリックがサポートされていることを示します。
計算されたメトリクス |
|
|
|
|
---|---|---|---|---|
|
✓ |
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
✓ |
顧客定義のLLMジャッジ |
✓ |
✓ |
✓ |
✓ |
|
✓ |
✓ |
✓ |
|
|
✓ |
✓ |
✓ |
|
|
✓ |
✓ |
||
|
✓ |
request
とresponse
のみを含むサンプル評価セット
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.",
}
]
request
、response
、retrieved_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",
},
],
}
]
request
、response
、retrieved_context
、expected_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",
},
],
}
]
request
、response
、retrieved_context
、expected_response
、expected_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アプリケーションに送信されるリクエストの形式と同じであることを確認してください。
人間のラベル付け者は、質問の解釈が異なるなど、本質的にノイズが多く一貫性がありません。これはプロセスの重要な部分です。ヒューマンラベリングを使用すると、考えていなかった質問の解釈が明らかになり、申請時に観察した行動についての知見が得られる場合があります。