Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résoudre les problèmes et affiner votre politique de raisonnement automatique

Lorsqu'un test de stratégie de raisonnement automatisé échoue (le résultat réel ne correspond pas au résultat attendu), le problème réside soit dans la traduction (le langage naturel a été mappé sur les mauvaises variables ou valeurs), soit dans les règles (la logique de la politique ne correspond pas à votre domaine). Cette page propose une approche systématique pour diagnostiquer et résoudre les deux types de problèmes.

Avant de commencer le dépannage, assurez-vous de bien comprendre le processus de validation en deux étapes (traduire, puis valider) décrit dansTraduction : du langage naturel à la logique formelle. Cette distinction est la clé d'un débogage efficace.

Flux de travail de débogage

Lorsqu'un test échoue, utilisez le résultat réel pour identifier le type de problème et passez à la section correspondante.

Résoudre les problèmes de traduction

Des problèmes de traduction surviennent lorsque les contrôles de raisonnement automatisés ne peuvent pas associer de manière fiable le langage naturel aux variables de votre politique. Le symptôme le plus visible est le TRANSLATION_AMBIGUOUS résultat, mais les problèmes de traduction peuvent également entraîner des erreurs ou des SATISFIABLE résultats lorsque des variables ou des valeurs incorrectes VALID sont attribuées. INVALID

Diagnostiquer les résultats de TRANSLATION_AMBIGUI

Une TRANSLATION_AMBIGUOUS constatation inclut deux champs clés qui vous aident à comprendre le désaccord :

Examinez ces champs pour identifier la source spécifique d'ambiguïté, puis appliquez le correctif approprié dans la liste suivante.

Définitions de variables qui se chevauchent

Lorsque plusieurs variables peuvent raisonnablement représenter le même concept, les modèles de traduction ne sont pas d'accord sur celle à utiliser.

Symptôme : Les options TRANSLATION_AMBIGUOUS résultats montrent le même concept attribué à différentes variables. Par exemple, une option attribue « 2 ans de service » tenureMonths = 24 tandis que l'autre l'attribue à. monthsOfService = 24

Correctif : Fusionnez les variables qui se chevauchent en une seule variable avec une description complète. Mettez à jour toutes les règles qui font référence à la variable supprimée pour utiliser la variable restante.

Exemple :

Descriptions de variables incomplètes

Les descriptions des variables qui manquent de détails sur la façon dont les utilisateurs se réfèrent aux concepts dans le langage courant compliquent la mise en correspondance des données saisies avec la bonne variable.

Symptôme : ils options affichent la bonne variable mais avec des valeurs différentes, ou la traduction attribue une valeur qui ne correspond pas à ce que l'utilisateur a dit. Par exemple, « 2 ans » est traduit par au tenureMonths = 2 lieu detenureMonths = 24.

Correctif : mettez à jour la description de la variable pour inclure les règles de conversion des unités, les synonymes et les formulations alternatives. Voir Rédiger des descriptions complètes des variables pour obtenir des conseils détaillés.

Exemple :

Formatage des valeurs incohérent

Une ambiguïté de traduction peut survenir lorsque le système ne sait pas comment formater des valeurs telles que des nombres, des dates ou des pourcentages.

Symptôme : ils options affichent la même variable mais avec des formats de valeur différents. Par exemple, une option traduit « 5 % » interestRate = 5 en. L'autre le traduit eninterestRate = 0.05.

Correctif : mettez à jour la description de la variable pour spécifier le format attendu et inclure les règles de conversion. Consultez Spécifier les unités et les formats dans les descriptions des variables.

Texte de saisie ambigu

Parfois, l'entrée elle-même est véritablement ambiguë : elle contient des pronoms vagues, des références peu claires ou des déclarations qui peuvent être interprétées de plusieurs manières.

Symptôme : Ils options présentent des interprétations fondamentalement différentes d'un même texte. Par exemple, « Peuvent-ils prendre congé ? » peut faire référence à n'importe quel type d'employé.

Correctif : s'il s'agit d'un test, réécrivez l'entrée pour qu'elle soit plus précise. Au moment de l'exécution, votre application doit demander des éclaircissements à l'utilisateur lorsqu'elle reçoit un TRANSLATION_AMBIGUOUS résultat. Pour les modèles d'intégration, voirIntégrez des contrôles de raisonnement automatisés dans votre application.

Ajuster le seuil de confiance

Si vous voyez des TRANSLATION_AMBIGUOUS résultats pour des entrées à la limite de l'ambiguïté, vous pouvez ajuster le seuil de confiance. L'abaissement du seuil permet aux traductions comportant moins de modèles d'accord de passer à la validation, ce qui réduit les TRANSLATION_AMBIGUOUS résultats mais augmente le risque de traductions incorrectes.

Résoudre les problèmes liés aux règles

Des problèmes de règles se produisent lorsque la traduction est correcte mais que la logique de la politique ne correspond pas à votre domaine. Vous avez confirmé que les bonnes valeurs sont attribuées aux bonnes variables, mais le résultat de la validation est toujours erroné.

Devenir valide alors que vous vous attendiez à INVALID

La politique ne contient aucune règle interdisant la réclamation. La réponse contredit votre connaissance du domaine, mais la politique l'autorise.

Diagnostic : Regardez supportingRules le résultat. Ce sont les règles qui prouvent que la réclamation est valide. Vérifiez si ces règles sont correctes ou si une règle est manquante.

Causes courantes et solutions :

Devenir INVALIDE quand vous vous attendiez à VALID

La politique comporte une règle qui interdit à tort la réclamation.

Diagnostic : Regardez contradictingRules le résultat. Ce sont les règles qui réfutent la réclamation. Vérifiez si ces règles sont correctes.

Causes courantes et solutions :

Devenir SATISFIABLE quand vous vous y attendiez VALIDE

La réponse est correcte dans certaines conditions, mais pas dans toutes. La politique comporte des règles supplémentaires que la réponse ne prend pas en compte.

Diagnostic : comparez le résultat claimsTrueScenario et claimsFalseScenario le résultat. La différence entre eux montre les conditions que la réponse ne mentionne pas.

Causes courantes et solutions :

Corriger les résultats impossibles

Cela signifie IMPOSSIBLE que les contrôles de raisonnement automatisés ne peuvent pas évaluer les réclamations parce que les prémisses sont contradictoires ou que la politique elle-même contient des règles contradictoires. Il existe deux causes distinctes.

Contradictions dans la saisie

L'entrée du test contient des déclarations qui se contredisent. Par exemple, « je suis un employé à temps plein et aussi à temps partiel » isFullTime = true et isFullTime = false simultanément, ce qui est logiquement impossible.

Diagnostic : Inspectez les translation locaux dans la découverte. Recherchez les variables auxquelles des valeurs contradictoires sont attribuées.

Correctif : s'il s'agit d'un test, réécrivez l'entrée pour supprimer la contradiction. Au moment de l'exécution, votre application doit gérer IMPOSSIBLE les résultats en demandant à l'utilisateur de clarifier sa saisie.

Conflits dans la politique

La politique contient des règles qui se contredisent, ce qui empêche les contrôles de raisonnement automatisés de parvenir à une conclusion pour les entrées impliquant des règles contradictoires.

Diagnostic : Si l'entrée est valide (aucune prémisse contradictoire), le problème réside dans la politique. Vérifiez le contradictingRules champ dans le résultat pour identifier les règles en conflit. Consultez également le rapport de qualité (voirUtiliser le rapport de qualité) : il signale automatiquement les règles contradictoires.

Causes courantes et solutions :

Utilisez des annotations pour réparer votre police

Les annotations sont des corrections ciblées que vous appliquez à votre politique en cas d'échec des tests. Au lieu de modifier manuellement les règles et les variables, vous pouvez utiliser des annotations pour décrire le changement souhaité et laisser les contrôles de raisonnement automatique l'appliquer. Les annotations sont disponibles via la console et l'API.

Appliquer des annotations dans la console

Appliquer des annotations à l'aide de l'API

Utilisez l'StartAutomatedReasoningPolicyBuildWorkflowAPI avec REFINE_POLICY pour appliquer des annotations par programmation. Transmettez la définition complète de la politique actuelle avec les annotations.

Les types d'annotations incluent :

Exemple : ajout d'une variable et d'une règle manquantes à l'aide d'annotations

aws bedrock start-automated-reasoning-policy-build-workflow \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-type REFINE_POLICY \
  --source-content "{
    \"policyDefinition\": EXISTING_POLICY_DEFINITION_JSON,
    \"workflowContent\": {
      \"policyRepairAssets\": {
        \"annotations\": [
          {
            \"addVariable\": {
              \"name\": \"tenureMonths\",
              \"type\": \"int\",
              \"description\": \"The number of complete months the employee has been continuously employed. When users mention years of service, convert to months (for example, 2 years = 24 months).\"
            }
          },
          {
            \"addRuleFromNaturalLanguage\": {
              \"naturalLanguage\": \"If an employee is full-time and has more than 12 months of tenure, then they are eligible for parental leave.\"
            }
          }
        ]
      }
    }
  }"

Exemples d'annotations

Exemple 1 : Corriger une exigence de titularisation manquante

Problème : La politique approuve le congé parental pour tous les employés à temps plein, mais le document source exige une ancienneté de plus de 12 mois.

Exemple 2 : Corriger les variables qui se chevauchent à l'origine de TRANSLATION_AMBIGUA

Problème : deux variables (tenureMonthsetmonthsOfService) représentent le même concept, ce qui entraîne des traductions incohérentes.

Annotations :

Exemple 3 : Corriger une simple assertion entraînant des résultats IMPOSSIBLES

Problème : La règle (= eligibleForParentalLeave true) est une simple assertion qui empêche toute saisie de prétendre que l'utilisateur n'est pas éligible.

Annotations :

Utiliser le rapport de qualité

Le rapport de qualité est généré après chaque flux de production et identifie les problèmes structurels de votre politique susceptibles d'entraîner des échecs de test. Dans la console, les problèmes liés aux rapports de qualité apparaissent sous forme d'avertissements sur la page Définitions. Via l'API, utilisez GetAutomatedReasoningPolicyBuildWorkflowResultAssets avec--asset-type QUALITY_REPORT.

Le rapport de qualité met en évidence les problèmes suivants :

Règles contradictoires

Deux règles ou plus aboutissent à des conclusions contradictoires pour le même ensemble de conditions. En cas de conflit de règles, votre politique est renvoyée IMPOSSIBLE pour toutes les demandes de validation impliquant des règles contradictoires.

Exemple : la règle A dit (=> isFullTime eligibleForLeave) et la règle B dit(=> (<= tenureMonths 6) (not eligibleForLeave)). Pour un employé à temps plein titulaire de 3 mois, la règle A indique qu'il est éligible et que la règle B indique qu'il n'est pas éligible, ce qui est contradictoire.

Correctif : Fusionnez les règles en une seule règle avec des conditions explicites :(=> (and isFullTime (> tenureMonths 6)) eligibleForLeave). Ou supprimez l'une des règles contradictoires si elle a été mal extraite.

Variables non utilisées

Variables qui ne sont référencées par aucune règle. Les variables non utilisées compliquent le processus de traduction et peuvent entraîner des TRANSLATION_AMBIGUOUS résultats lorsqu'elles entrent en concurrence avec des variables actives similaires pour le même concept.

Correctif : supprimez les variables inutilisées, sauf si vous prévoyez d'ajouter des règles qui y font référence lors d'une future itération.

Valeurs de type non utilisées

Valeurs d'un type personnalisé (enum) qui ne sont référencées par aucune règle. Par exemple, si votre LeaveType énumération contient les valeurs PARENTAL, MEDICAL, BEREAVEMENT et PERSONAL, mais qu'aucune règle ne fait référence à PERSONAL, elle est signalée comme non utilisée.

Correctif : ajoutez des règles qui font référence à la valeur inutilisée ou supprimez-la de l'énumération. Les valeurs non utilisées peuvent entraîner des problèmes de traduction si l'entrée mentionne le concept mais qu'aucune règle ne le gère.

Ensembles de règles disjoints

Groupes de règles qui ne partagent aucune variable. Les ensembles de règles disjoints ne constituent pas nécessairement un problème : votre police peut couvrir intentionnellement des sujets indépendants (par exemple, l'éligibilité aux congés et le remboursement des dépenses). Cependant, ils peuvent indiquer que les variables ne sont pas connectées entre les règles associées.

Quand agir : si les ensembles de règles disjoints doivent être liés (par exemple, ils traitent tous deux des avantages sociaux mais utilisent des noms de variables différents pour le même concept), fusionnez les variables qui se chevauchent pour les relier. Si les ensembles de règles sont réellement indépendants, aucune action n'est nécessaire.

Utiliser la CLI Kiro pour affiner les politiques

Kiro CLI fournit une interface de chat interactive pour diagnostiquer et résoudre les problèmes de politique. Il peut charger la définition de votre politique et votre rapport de qualité, expliquer pourquoi les tests échouent, suggérer des modifications et appliquer des annotations, le tout par le biais d'une conversation en langage naturel.

La CLI Kiro est particulièrement utile pour :

Exemple de flux de travail :

You: The test with ID test-12345 is not returning the expected result.
     Can you load the test definition and findings, look at the policy
     definition, and explain why this test is failing?

Kiro: [analyzes the test and policy] The test expects VALID but gets
      INVALID because rule R3 requires 24 months of tenure, while the
      test input specifies 18 months. The source document says 12 months.
      Rule R3 appears to have been misextracted.

You: Can you suggest changes to fix this?

Kiro: I suggest updating rule R3 to change the tenure threshold from 24
      to 12 months. Here's the updated rule: ...

You: Looks good. Can you use the annotation APIs to submit these changes?

Kiro: [applies annotations via the API]

Pour obtenir des instructions complètes sur la configuration et l'utilisation de la CLI Kiro avec des politiques de raisonnement automatisé, voirUtiliser la CLI Kiro avec une politique de raisonnement automatisé.