Stratégie de test : scénarios et tests QnA Génération automatique de scénarios de test dans la console Générez automatiquement des scénarios de test à l'aide de l'API Créez un test QnA manuellement dans la console Créez un test QnA à l'aide de l'API Exécuter des tests Comprendre les résultats des tests

Test d’une politique de raisonnement automatisé

Les tests confirment que les règles de votre politique sont correctes et que les contrôles de raisonnement automatisés peuvent traduire avec précision le langage naturel en logique formelle. Vous testez une politique en envoyant des instructions en langage naturel pour validation, puis en inspectant les commentaires pour vous assurer que la traduction utilise les bonnes variables et que les règles produisent les résultats escomptés.

Il existe deux approches de test complémentaires : les scénarios générés et les tests question-and-answer (QnA). Chacun cible une partie différente du pipeline de validation. Le flux de travail recommandé consiste à commencer par des scénarios pour valider l'exactitude des règles, puis à ajouter des tests QnA pour valider l'exactitude de la traduction.

Stratégie de test : scénarios et tests QnA

Les contrôles de raisonnement automatisés valident le contenu en deux étapes : d'abord, les modèles de base traduisent le langage naturel en logique formelle ; ensuite, les techniques mathématiques vérifient la logique par rapport à vos règles de politique. Chaque approche de test cible une étape différente de ce pipeline.

Scénarios générés (vérifier l'exactitude des règles)

Les scénarios générés testent directement la sémantique encodée dans vos règles de politique. Ils éliminent l'incertitude liée à la traduction en langage naturel de l'équation, en déterminant si les règles elles-mêmes sont correctes.

Les scénarios sont générés à partir de vos règles de politique et représentent des situations qui sont logiquement possibles compte tenu de ces règles. Ils sont triés pour faire apparaître le plus grand nombre de likely-to-be-wrong scénarios en premier. Pour chaque scénario, vous passez en revue les affectations de variables et vous décidez :

Bravo — Le scénario est réaliste et devrait effectivement être possible. Enregistrez-le en tant que SATISFIABLE test.
Pouce vers le bas — Quelque chose ne va pas. Le scénario ne devrait pas être possible compte tenu de votre connaissance du domaine. Fournissez des commentaires en langage naturel expliquant pourquoi, et les contrôles de raisonnement automatisés tenteront de déduire les modifications de règles nécessaires.

Exemple : selon votre politique, les employés à temps plein ayant plus de 12 mois d'ancienneté sont éligibles au congé parental. Un scénario généré peut s'afficherisFullTime = true, tenureMonths = 3, eligibleForParentalLeave = true. Si ce scénario n'est pas possible (parce que 3 mois, c'est moins de 12), vous devriez l'approuver et expliquer que les employés ont besoin d'au moins 12 mois d'ancienneté. Cela indique une règle manquante ou incorrecte.

Utilisez des scénarios comme première étape de test. Ils vous aident à détecter les problèmes liés aux règles avant de passer du temps à écrire des tests QnA.

Tests QnA (test de précision de traduction)

Les tests QnA valident l'ensemble du pipeline end-to-end : traduction en langage naturel et validation des règles en même temps. Ils imitent les interactions réelles des utilisateurs et détectent les problèmes de traduction que les scénarios ne peuvent détecter.

Chaque test QnA comprend :

Une entrée (facultatif) : question qu'un utilisateur peut poser à votre application.
Un résultat : la réponse que votre modèle de base est susceptible de générer.
Un résultat attendu — Le résultat de validation que vous attendez (par exemple, VALID ouINVALID).

Exemple : Pour la même politique de congé parental, un test QnA peut être : input = « Je travaille ici depuis 2 ans à plein temps. Puis-je prendre un congé parental ? » , output = « Oui, vous êtes éligible au congé parental. «, résultat attendu =VALID. Cela permet de vérifier si les contrôles de raisonnement automatisés se traduisent correctement par « 2 ans » tenureMonths = 24 et « temps plein » parisFullTime = true.

Astuce

Créez des tests qui couvrent à la fois les scénarios valides et non valides. Par exemple, si votre politique stipule que « les employés ont besoin d'un an de service pour le congé parental », créez des tests pour les réponses qui énoncent correctement cette règle et des tests pour les réponses qui énoncent incorrectement une exigence différente.

Flux de travail de test recommandé

Générez et examinez des scénarios. Commencez ici pour vérifier que vos règles sont correctes. Corrigez tous les problèmes liés aux règles avant de continuer.
Rédigez des tests QnA pour les principaux cas d'utilisation. Concentrez-vous sur les questions que vos utilisateurs sont les plus susceptibles de poser et sur les réponses que votre LLM est le plus susceptible de générer. Incluez les cas extrêmes et les conditions limites.
Exécutez tous les tests. Vérifiez que les scénarios et les tests QnA sont réussis.
Itérer. Si les tests échouent, déterminez si le problème est lié aux règles (corrigez la politique) ou à la traduction (améliorez les descriptions des variables). Pour de plus amples informations, veuillez consulter Résoudre les problèmes et affiner votre politique de raisonnement automatique.

Génération automatique de scénarios de test dans la console

Accédez à la politique de raisonnement automatisé que vous souhaitez tester (par exemple, MyHrPolicy).
Choisissez Afficher les tests, puis sélectionnez Générer.
Dans la boîte de dialogue Générer des scénarios, passez en revue le scénario généré et les règles associées. Chaque scénario présente un ensemble d'assignations de variables qui sont logiquement possibles compte tenu de vos règles de politique. Évaluez si le scénario est réaliste dans votre domaine :
- Si le scénario peut se produire dans votre domaine (il est satisfaisant), sélectionnez l'icône du pouce levé. Cela enregistre le scénario en tant que test qui attend un SATISFIABLE résultat.
- Si le scénario n'est pas possible, sélectionnez l'icône représentant le pouce vers le bas. Fournissez une annotation expliquant pourquoi, par exemple, « Les employés ont besoin d'au moins 12 mois d'ancienneté pour bénéficier d'un congé parental, mais ce scénario indique 3 mois d'éligibilité ». Les contrôles de raisonnement automatisés utilisent vos commentaires pour déduire les modifications des règles qui empêcheraient ce scénario.
- Si vous souhaitez un autre scénario, choisissez Régénérer le scénario.
Astuce
Pour inspecter la version logique officielle du scénario, activez Afficher SMT-LIB. Cela est utile pour comprendre exactement quelles règles et quelles affectations de variables sont impliquées.
Sélectionnez Enregistrer et fermer pour enregistrer le test, ou Enregistrer et ajouter un autre test pour continuer à examiner les scénarios.
Si vous avez fourni des annotations (commentaires du pouce vers le bas) à des scénarios, choisissez Appliquer les annotations. Les vérifications de raisonnement automatisées lanceront un flux de travail de création pour appliquer les modifications à votre politique en fonction de vos commentaires.
Sur l'écran Réviser les modifications de politique, passez en revue les modifications proposées aux règles, aux variables et aux types de variables de votre politique. Sélectionnez ensuite Accepter les modifications.

Générez automatiquement des scénarios de test à l'aide de l'API

Utilisez l'GetAutomatedReasoningPolicyNextScenarioAPI pour récupérer les scénarios de test générés en fonction des règles de votre politique.

policyArn (obligatoire): L'ARN de la politique de raisonnement automatisé.
buildWorkflowId (obligatoire): Identifiant du flux de travail de génération pour les scénarios générés. Récupérez le dernier flux de production à l'aide de l'ListAutomatedReasoningPolicyBuildWorkflowsAPI.

Exemple :


aws bedrock get-automated-reasoning-policy-next-scenario \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

La réponse inclut un scénario généré avec des affectations de variables et les règles de politique associées. Passez en revue le scénario et utilisez l'CreateAutomatedReasoningPolicyTestCaseAPI pour l'enregistrer en tant que test, ou utilisez l'annotation APIs pour fournir des commentaires si le scénario révèle un problème de règle.

Créez un test QnA manuellement dans la console

Accédez à la politique de raisonnement automatisé que vous souhaitez tester (par exemple, MyHrPolicy).
Choisissez Afficher les tests, puis sélectionnez Ajouter.
Dans la boîte de dialogue Ajouter des tests, procédez comme suit :
1. Dans le champ Saisie (facultatif), saisissez la question qu'un utilisateur est susceptible de poser. Pour Output, entrez la réponse que votre modèle de base pourrait fournir. Ensemble, ils forment une paire QnA qui teste la manière dont votre politique valide les interactions réelles avec les utilisateurs.
2. Choisissez le résultat que vous attendez du test (par exemple Valide ou Invalide).
3. (Facultatif) Sélectionnez un seuil de confiance, qui est le niveau de confiance minimum pour la validation logique. Les contrôles de raisonnement automatisés utilisent plusieurs LLMs outils pour traduire le langage naturel en résultats. Il ne renvoie que les résultats étayés par un pourcentage significatif des traductions du LLM. Le seuil de confiance définit le pourcentage minimum de support nécessaire pour qu’une traduction devienne un résultat valide. Les résultats inférieurs au seuil sont présentés sous forme TRANSLATION_AMBIGUOUS de.
Sélectionnez Enregistrer pour créer le test.

Créez un test QnA à l'aide de l'API

Utilisez l'CreateAutomatedReasoningPolicyTestCaseAPI pour créer un test par programmation.

policyArn (obligatoire): L'ARN de la politique de raisonnement automatisé.
queryContent (facultatif): La requête ou l'invite d'entrée qui a généré le contenu, telle que la question de l'utilisateur. Cela fournit un contexte pour la validation.
guardContent (obligatoire): Le contenu de sortie à valider : la réponse du modèle de base dont l'exactitude sera vérifiée.
expectedAggregatedFindingsResult (facultatif): Le résultat de validation attendu (par exemple, VALID ouINVALID). Le résultat réel est déterminé en triant les résultats par ordre de gravité et en sélectionnant le pire résultat. L'ordre de gravité du pire au meilleur est :TRANSLATION_AMBIGUOUS,IMPOSSIBLE,INVALID,SATISFIABLE,VALID.
confidenceThreshold (facultatif): Le niveau de confiance minimal pour la validation logique.

Exemple :


aws bedrock create-automated-reasoning-policy-test-case \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --query-content "Can I take a leave of absence if I'm a part-time employee?" \
  --guard-content "No, only full-time employees are eligible for leave of absence." \
  --expected-aggregated-findings-result "VALID" \
  --confidence-threshold 0.8

Exemple de réponse :


{
  "testCaseId": "test-12345abcde",
  "policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk"
}

Exécuter des tests

Exécution des tests dans la console

Accédez à la politique de raisonnement automatisé que vous souhaitez valider (par exemple, MyHrPolicy).
Choisissez Afficher les tests.
Effectuez l’une des actions suivantes :
- Pour exécuter tous les tests, choisissez Valider tous les tests.
- Pour exécuter un seul test, sélectionnez le bouton Action situé à côté du test et choisissez Valider.

Exécution de tests à l’aide de l’API

Utilisez l'StartAutomatedReasoningPolicyTestWorkflowAPI pour exécuter des tests et l'GetAutomatedReasoningPolicyTestResultAPI pour récupérer les résultats.

policyArn (obligatoire): L'ARN de la politique de raisonnement automatisé.
buildWorkflowId (obligatoire): Identifiant du flux de travail de génération sur lequel exécuter les tests. Récupérez le dernier flux de production à l'aide de l'ListAutomatedReasoningPolicyBuildWorkflowsAPI.
testCaseIds (facultatif): Liste des identifiants de test à exécuter. Si ce n'est pas le cas, tous les tests de la politique sont exécutés.

Exemple :


# Run tests
aws bedrock start-automated-reasoning-policy-test-workflow \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

# Get results for a specific test
aws bedrock get-automated-reasoning-policy-test-result \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690 \
  --test-case-id test-12345abcde

La réponse inclut des résultats de test détaillés avec les résultats de validation et l'état d'exécution. Pour répertorier tous les résultats des tests d'un flux de travail de génération, utilisez l'ListAutomatedReasoningPolicyTestResultsAPI.

Comprendre les résultats des tests

À la fin d'un test, vous recevez un ensemble de résultats. Chaque résultat représente une affirmation factuelle extraite de vos données de test, ainsi que le résultat de la validation, les assignations de variables utilisées et les règles de politique qui sous-tendent la conclusion. Pour une description détaillée de la structure de recherche et de tous les types de résultats de validation, voirConstatations et résultats de validation.

Anatomie d'un résultat de test

Chaque résultat de test inclut :

Résultat attendu : résultat que vous avez défini lors de la création du test.
Résultat réel : résultat agrégé de l'exécution du test. Ceci est déterminé en triant les résultats par ordre de gravité et en sélectionnant le pire résultat. L'ordre de gravité du pire au meilleur est :TRANSLATION_AMBIGUOUS,IMPOSSIBLE,INVALID,SATISFIABLE,VALID. Par exemple, un test comportant deux VALID résultats et un IMPOSSIBLE résultat a un résultat agrégé deIMPOSSIBLE.
Résultat de l'exécution : indique si le test a réussi (les résultats attendus et réels correspondent) ou s'il a échoué.
Conclusions — Les résultats de validation individuels. Chaque résultat contient les prémisses et les affirmations traduites, un score de confiance, des attributions de variables et les règles de politique qui sous-tendent la conclusion.

Interprétation pratique des résultats

Le tableau suivant récapitule ce que chaque résultat de validation signifie dans la pratique et les mesures à prendre lorsque vous le constatez lors d'un test. Pour la référence complète, y compris les champs de recherche et les descriptions détaillées, voirRéférence des résultats de validation.

Résultat	Ce que cela signifie	Que faire
`VALID`	Les affirmations contenues dans la réponse sont mathématiquement prouvées correctes compte tenu des prémisses et des règles de votre politique. La découverte inclut `supportingRules` des preuves des affirmations et une `claimsTrueScenario` démonstration de leur véracité.	Si tel est le résultat attendu, le test est réussi. Vérifiez `untranslatedPremises` `untranslatedClaims` les parties de la saisie qui n'ont pas été validées : le `VALID` résultat ne couvre que les demandes traduites.
`INVALID`	Les réclamations contredisent les règles de votre police d'assurance. Le résultat consiste notamment à `contradictingRules` montrer quelles règles ont été violées.	Si tel est le résultat attendu, le test est réussi. En cas d'imprévu, vérifiez si les règles sont correctes ou si la traduction a attribué les mauvaises variables. Consultez le `contradictingRules` pour comprendre quelles règles sont à l'origine du résultat.
`SATISFIABLE`	Les réclamations sont conformes à votre police, mais ne tiennent pas compte de toutes les règles pertinentes. La réponse est correcte dans certaines conditions, mais pas dans toutes. Le résultat inclut à la fois a `claimsTrueScenario` et a `claimsFalseScenario` indiquant les conditions dans lesquelles les affirmations sont vraies et fausses.	Comparez les deux scénarios pour identifier les conditions manquantes. Cela signifie généralement que la réponse est incomplète. Elle n'est pas fausse, mais elle ne mentionne pas toutes les exigences. Déterminez si votre test doit être attendu `SATISFIABLE` ou si la réponse doit être plus complète.
`IMPOSSIBLE`	Les contrôles de raisonnement automatisés ne permettent pas d'évaluer les demandes parce que les prémisses sont contradictoires ou parce que la politique elle-même contient des règles contradictoires.	Vérifiez si l'entrée du test contient des déclarations contradictoires (par exemple, « Je suis à temps plein et également à temps partiel »). Si l'entrée est valide, la contradiction est probablement liée à votre politique. Vérifiez le rapport sur la qualité pour détecter les règles contradictoires. Consultez Résoudre les problèmes et affiner votre politique de raisonnement automatique.
`TRANSLATION_AMBIGUOUS`	La traduction du langage naturel vers la logique formelle était ambiguë. Le multiple LLMs utilisé pour la traduction n'était pas d'accord sur la manière d'interpréter l'entrée. Le résultat inclut des interprétations alternatives pour vous aider à comprendre le désaccord.	Il s'agit généralement d'un problème de description des variables. Passez en revue les interprétations alternatives pour comprendre où se situe le désaccord, puis améliorez les descriptions des variables pertinentes. Causes courantes : chevauchement de variables, descriptions vagues ou texte de saisie ambigu. Consultez Résoudre les problèmes et affiner votre politique de raisonnement automatique.
`TOO_COMPLEX`	L'entrée contient trop d'informations pour que les contrôles de raisonnement automatisés puissent les traiter dans les limites de latence.	Simplifiez la saisie des tests. Si le problème persiste, votre politique est peut-être trop complexe. Pensez à la scinder en plusieurs politiques ciblées ou à simplifier les règles qui impliquent une arithmétique non linéaire.
`NO_TRANSLATIONS`	L'entrée n'a pas pu être traduite en logique formelle. Cela signifie généralement que l'entrée n'est pas pertinente pour le domaine de votre politique, ou que la politique ne comporte pas de variables permettant de modéliser les concepts contenus dans l'entrée.	Si l'entrée doit être pertinente pour votre politique, ajoutez les variables manquantes et mettez à jour vos règles. Si l'entrée est réellement hors sujet, ce résultat est attendu : votre application doit traiter le contenu hors sujet séparément (par exemple, en utilisant des politiques thématiques).

Conseils de débogage en cas d'échec des tests

Lorsqu'un test échoue (le résultat réel ne correspond pas au résultat attendu), appliquez l'approche suivante pour diagnostiquer le problème :

Vérifiez d'abord la traduction. Examinez les prémisses et les allégations contenues dans les conclusions. Les bonnes variables sont-elles attribuées ? Les valeurs sont-elles correctes ? Si la traduction est incorrecte, le problème réside dans vos descriptions de variables, et non dans vos règles. Par exemple, si « 2 ans » a été traduit en au tenureMonths = 2 lieu detenureMonths = 24, la description de la variable doit spécifier la conversion d'unités.
Vérifiez les règles. Si la traduction semble correcte, le problème réside dans vos règles de politique. Examinez le supportingRules ou contradictingRules dans le résultat pour identifier les règles concernées. Comparez-les à votre document source.
Vérifiez s'il n'y a pas de contenu non traduit. Regardez untranslatedPremises etuntranslatedClaims. Si des parties importantes de l'entrée n'ont pas été traduites, vous devrez peut-être ajouter des variables pour capturer ces concepts.
Vérifiez le score de confiance. Un faible score de confiance indique que les modèles de traduction ne concordent pas. Cela suggère que les descriptions des variables sont ambiguës pour ce type d'entrée.

Pour obtenir des conseils de dépannage détaillés, consultezRésoudre les problèmes et affiner votre politique de raisonnement automatique.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Bonnes pratiques en matière de politiques

Résoudre les problèmes et affiner votre politique