Évaluations de vérité sur le terrain
La vérité fondamentale est la bonne réponse connue ou le comportement attendu pour une entrée donnée, la « référence absolue » à laquelle vous comparez les résultats réels. Pour l'évaluation des agents, Ground Truth transforme l'évaluation subjective de la qualité en mesure objective, permettant ainsi la détection de régression, les ensembles de données de référence et l'exactitude spécifique à un domaine que les évaluateurs génériques ne peuvent pas fournir seuls.
Avec les évaluations Ground Truth, vous fournissez des entrées de référence en même temps que la durée de vos sessions lorsque vous appelez l'API Evaluate. Le service utilise ces entrées de référence pour évaluer le comportement réel de votre agent par rapport au comportement attendu. Les évaluateurs qui n'utilisent pas un champ de vérité spécifique l'ignorent et signalent les champs qui n'ont pas été utilisés dans la réponse.
Rubriques
Évaluateurs intégrés pris en charge et champs de vérité sur le terrain
Le tableau suivant indique quels évaluateurs intégrés prennent en charge Ground Truth et quels champs ils utilisent.
| Évaluateur | Niveau | Champ de vérité sur le terrain | Description |
|---|---|---|---|
|
|
Suivi |
|
Mesure la précision avec laquelle la réponse de l'agent correspond à la réponse attendue. Utilise la LLM-as-a-Judge notation. |
|
|
Session |
|
Valide si le comportement de l'agent répond aux assertions en langage naturel tout au long de la session. Utilise la LLM-as-a-Judge notation. |
|
|
Session |
|
Vérifie que la séquence d'appel d'outils réelle correspond exactement à la séquence attendue : mêmes outils, même ordre, aucun ajout. Notation programmatique (aucun appel de LLM). |
|
|
Session |
|
Vérifie que tous les outils attendus apparaissent dans l'ordre dans la séquence réelle, mais autorise des outils supplémentaires entre eux. Notation programmatique. |
|
|
Session |
|
Vérifie que tous les outils attendus sont présents dans la séquence réelle, quel que soit l'ordre. Des outils supplémentaires sont autorisés. Notation programmatique. |
Note
Les évaluateurs personnalisés prennent également en charge les champs de vérité sur le terrain par le biais d'espaces réservés dans leurs instructions d'évaluation. Pour plus de détails, consultez Ground Truth dans les évaluateurs personnalisés.
Le tableau suivant décrit les champs de vérité de base.
| Champ | Type | Scope | Description |
|---|---|---|---|
|
|
String |
Suivi |
La réponse attendue de l'agent pour un tour spécifique. Délimité à une trace utilisée |
|
|
Liste de chaînes |
Session |
Déclarations en langage naturel qui devraient être vraies concernant le comportement de l'agent au cours de la session. |
|
|
Liste des noms d'outils |
Session |
La séquence attendue d'appels d'outils pour la session. |
-
Les champs Ground Truth sont facultatifs. Si vous les omettez, les évaluateurs retombent dans leur mode sans vérité de base (par exemple, ils fonctionnent
Builtin.Correctnesstoujours sansexpectedResponseles utiliser, ils évaluent uniquement en fonction du contexte). -
Vous pouvez fournir tous les champs de vérité de base en une seule demande. Le service sélectionne les champs pertinents pour chaque évaluateur et indique
ignoredReferenceInputFieldsdans la réponse tous les champs qui n'ont pas été utilisés. -
Vous n'avez pas besoin de fournir toutes
expectedResponseles traces. Les traces sans vérité fondamentale sont évaluées à l'aide de la variante sans vérité fondamentale de l'évaluateur.
Conditions préalables
-
Python 3.10 et versions
-
Un agent déployé sur AgentCore Runtime avec l'observabilité activée, ou un agent créé avec un framework compatible configuré avec AgentCore Observability. Frameworks pris en charge :
-
Agents à mèches
-
LangGraph avec
opentelemetry-instrumentation-langchainouopeninference-instrumentation-langchain
-
-
Recherche de transactions activée dans CloudWatch — voir Activer la recherche de transactions
-
AWS informations d'identification configurées avec des autorisations pour
bedrock-agentcorebedrock-agentcore-control, etlogs(CloudWatch)
Pour obtenir des instructions sur les durées de session de téléchargement, voir Commencer avec l'évaluation à la demande.
À propos des exemples
Les exemples présentés sur cette page utilisent l'agent d'exemple des didacticiels d'AgentCore évaluationcalculatoretweather) et est déployé sur AgentCore Runtime avec l'observabilité activée.
Les exemples supposent une session à deux tours :
-
Tour 1 : « Qu'est-ce que 15 + 27 ans ? » — l'agent utilise l'
calculatoroutil et répond avec le résultat. -
Tour 2 : « Quel temps fait-il ? » — l'agent utilise l'
weatheroutil et réagit en fonction de la météo actuelle.
Avant d'exécuter des évaluations, appelez votre agent et attendez 2 à 5 minutes pour CloudWatch ingérer les données de télémétrie.
Les constantes suivantes sont utilisées dans les exemples de cette page. Remplacez-les par vos propres valeurs :
REGION = "<region-code>" AGENT_ID = "my-agent-id" SESSION_ID = "my-session-id" TRACE_ID_1 = "<trace-id-1>" # Turn 1: "What is 15 + 27?" TRACE_ID_2 = "<trace-id-2>" # Turn 2: "What's the weather?"
Exactitude avec réponse attendue
Builtin.Correctnessest un évaluateur au niveau de la trace qui mesure avec quelle précision la réponse de l'agent correspond à une réponse attendue. Lorsque vous le fournissezexpectedResponse, l'évaluateur compare la réponse réelle de l'agent à votre réalité de base en utilisant la LLM-as-a-Judge notation.
Exemple
GoalSuccessRate avec des assertions
Builtin.GoalSuccessRateest un évaluateur au niveau de la session qui valide si le comportement de l'agent répond à un ensemble d'assertions en langage naturel. Les assertions peuvent vérifier l'utilisation des outils, le contenu des réponses, l'ordre des actions ou tout autre comportement observable tout au long de la conversation.
Note
Les exemples ci-dessous utilisent des assertions qui valident l'utilisation des outils, mais les assertions sont rédigées en langage naturel sous forme libre. Vous pouvez les utiliser pour affirmer n'importe quel aspect du comportement des agents, comme le ton de réponse, l'exactitude des faits, le respect des normes de sécurité ou la logique métier.
Exemple
Trajectoire correspondant à la trajectoire attendue
Les évaluateurs de trajectoire comparent la séquence d'appels d'outils réelle de l'agent à une séquence attendue de noms d'outils. Trois variantes sont disponibles, chacune avec une rigueur d'adaptation différente. Tous les trois sont des évaluateurs au niveau de la session et utilisent la notation programmatique (aucun appel LLM, l'utilisation des jetons est donc nulle).
| Évaluateur | Règle de correspondance | Exemple |
|---|---|---|
|
|
La valeur réelle doit correspondre exactement aux attentes : mêmes outils, même commande, aucun supplément |
Prévu : |
|
|
Les outils attendus doivent apparaître dans l'ordre, mais des outils supplémentaires sont autorisés entre eux |
Prévu : |
|
|
Tous les outils attendus doivent être présents, la commande n'a pas d'importance, les extras sont autorisés |
Prévu : |
Exemple
Combiner tous les champs de vérité sur le terrain en une seule demande
Vous pouvez passer en revue tous les champs de vérité sur le terrain en un seul appel d'évaluation. Le service achemine chaque champ vers l'évaluateur approprié et ignore les champs qu'un évaluateur donné n'utilise pas. Cela signifie que vous pouvez créer vos entrées de référence une seule fois et les réutiliser entre différents évaluateurs sans modifier la charge utile.
Exemple
Comprendre les champs de saisie de référence ignorés
Lorsque vous fournissez des champs de vérité de base qu'un évaluateur n'utilise pas, la réponse inclut un ignoredReferenceInputFields tableau répertoriant les champs non utilisés. Il s'agit d'une information et non d'une erreur. L'évaluation se termine toujours avec succès.
Par exemple, si vous appelez Builtin.Helpfulness avec expectedResponse provided, l'évaluateur ignore la vérité fondamentale (Helpfulness ne l'utilise pas) et renvoie :
{ "evaluatorId": "Builtin.Helpfulness", "value": 0.83, "label": "Very Helpful", "explanation": "...", "ignoredReferenceInputFields": ["expectedResponse"] }
Ce comportement est intentionnel : il vous permet de créer un ensemble unique d'entrées de référence et de les utiliser sur plusieurs évaluateurs sans ajuster la charge utile de chacun d'entre eux.
La vérité de base dans les évaluateurs personnalisés
Les évaluateurs personnalisés peuvent utiliser des champs de vérité de base via des espaces réservés dans leurs instructions d'évaluation. Lorsque vous créez un évaluateur personnalisé, vous pouvez référencer les espaces réservés suivants :
-
Session-level évaluateurs personnalisés :
{context},,{available_tools},{actual_tool_trajectory},{expected_tool_trajectory}{assertions} -
Trace-level évaluateurs personnalisés :
{context},,{assistant_turn}{expected_response}
Par exemple, un évaluateur personnalisé au niveau de la trace qui vérifie la similarité des réponses peut utiliser :
Compare the agent's response with the expected response. Agent response: {assistant_turn} Expected response: {expected_response} Rate how closely the agent's response matches the expected response on a scale of 0 to 1.
Lorsque cet évaluateur est appelé avec expectedResponse les entrées de référence, le service remplace l'espace réservé par la valeur réelle du terrain avant la notation.
Pour plus de détails sur la création d'évaluateurs personnalisés, consultez la section Évaluateurs personnalisés.
Note
Les évaluateurs personnalisés qui utilisent des balises de vérité de base ({assertions},{expected_response},{expected_tool_trajectory}) ne peuvent pas être utilisés dans les configurations d'évaluation en ligne, car les évaluations en ligne surveillent le trafic de production en direct lorsque les valeurs de vérité de base ne sont pas disponibles.