Jeux d’évaluation
Important
Cette fonctionnalité est disponible en préversion publique.
Pour mesurer la qualité d’une application agentique, vous devez être en mesure de définir un ensemble représentatif de demandes, ainsi que des critères qui caractérisent des réponses de haute qualité. Vous faites cela en fournissant un jeu d’évaluation. Cet article décrit les différentes options de votre jeu d’évaluation et certaines bonnes pratiques pour la création d’un jeu d’évaluation.
Databricks recommande de créer un jeu d’évaluation étiqueté par l’homme, qui se compose de questions représentatives et de réponses de base. Si votre application inclut une étape de récupération, vous pouvez éventuellement fournir les documents de prise en charge sur lesquels vous attendez que la réponse soit basée. Bien qu’un ensemble d’évaluation étiqueté par l’homme soit recommandé, l’évaluation de l’agent fonctionne de manière égale avec les jeux d’évaluation générés de manière synthétique.
Un bon jeu d’évaluation présente les caractéristiques suivantes :
- Représentatif : il doit refléter avec précision la plage de demandes que l’application rencontrera en production.
- Difficile : il doit inclure des cas difficiles et diversifiés pour tester efficacement toute la plage des capacités de l’application.
- Mise à jour continue : il doit être mise à jour régulièrement pour refléter l’utilisation de l’application et les modèles changements dans les modèles de trafic de production.
Pour connaître le schéma requis d’un jeu d’évaluation, consultez le schéma d’entrée d’évaluation de l’agent.
Exemples d’ensembles d’évaluations
Cette section inclut des exemples simples d’ensembles d’évaluation.
Échantillon de jeu d’évaluation avec uniquement request
eval_set = [
{
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
}
]
Échantillon de jeu d’évaluation avec request
et 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.",
}
]
Échantillon de jeu d’évaluation avec request
, expected_response
et 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.",
}
]
Échantillon de jeu d’évaluation avec uniquement request
et 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.",
}
]
Échantillon de jeu d’évaluation avec request
, response
et 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",
},
],
}
]
Échantillon de jeu d’évaluation avec request
, response
, retrieved_context
et 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",
},
],
}
]
Échantillon de jeu d’évaluation avec request
, response
, retrieved_context
, expected_response
et 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",
},
],
}
]
Meilleures pratiques pour développer un jeu d’évaluation
- Considérez chaque échantillon, ou groupe d’échantillons, dans le jeu d’évaluation comme un test unitaire. Autrement dit, chaque échantillon doit correspondre à un scénario spécifique avec un résultat attendu explicite. Par exemple, envisagez de tester des contextes plus longs, un raisonnement sur plusieurs tronçons et le capacité à déduire des réponses à partir de preuves indirectes.
- Envisagez de tester des scénarios contradictoires à partir d’utilisateurs malveillants.
- Il n’existe aucune directive spécifique sur le nombre de questions à inclure dans un jeu d’évaluation, mais des signaux clairs provenant de données de haute qualité donnent généralement de meilleurs résultats que des signaux bruyants provenant de données de faible qualité.
- Envisagez d’inclure des exemples qui sont très difficiles, même pour les humains à répondre.
- Que vous développiez une application à usage général ou que vous cibliez un domaine spécifique, votre application rencontrera probablement un large éventail de questions. Le jeu d’évaluation devrait en tenir compte. Par exemple, si vous créez une application pour répondre à des questions RH spécifiques, vous devriez tout de même envisager de tester d’autres domaines (par exemple, les opérations) afin de vous assurer que l’application ne hallucine pas ou ne fournisse pas de réponses nuisibles.
- Des étiquettes cohérentes et de haute qualité générées par des humains sont le meilleur moyen de garantir que les valeurs de référence que vous fournissez à l’application reflètent avec précision le comportement souhaité. Voici quelques étapes pour garantir des étiquettes humaines de haute qualité :
- Agrégez les réponses (étiquettes) de plusieurs étiqueteurs humains pour la même question.
- Assurez-vous que les instructions d’étiquetage sont claires et que les étiqueteurs humains sont cohérents.
- Veillez à que les conditions du processus d’étiquetage humain sont identiques au format des requêtes soumises à l’application RAG.
- Les étiqueteurs humains sont par nature bruyants et incohérents, par exemple en raison de différentes interprétations de la question. Il s’agit d’une partie importante du processus. L’utilisation de l’étiquetage humain peut révéler des interprétations de questions auxquelles vous n’aviez pas prises en compte et qui pourraient fournir un aperçu du comportement que vous observez dans votre application.