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.

Création de votre politique de raisonnement automatisé

Lorsque vous créez une politique de raisonnement automatisé, votre document source est traduit en un ensemble de règles logiques formelles et en un schéma de variables et de types. Cette page vous explique comment préparer votre document, créer la politique et examiner les résultats.

Amazon Bedrock chiffre votre politique de raisonnement automatisé à l’aide de KMS (AWS Key Management Service). Par défaut, Amazon Bedrock utilise une clé détenue par le service. Vous pouvez éventuellement spécifier une clé KMS gérée par le client pour un contrôle supplémentaire sur le chiffrement des données de votre stratégie.

Pour tester et utiliser votre politique de raisonnement automatisé, assurez-vous de disposer des autorisations appropriées.

Préparez votre document source

Avant d'ouvrir la console ou d'appeler l'API, préparez le document qu'Automated Reasoning utilisera pour extraire les règles et les variables. La qualité de votre politique dépend directement de la qualité de ces informations.

Structure et clarté du document

Les contrôles de raisonnement automatisés fonctionnent mieux avec des documents contenant des règles claires et sans ambiguïté. Chaque règle doit énoncer une condition et un résultat. Évitez les termes vagues, les critères subjectifs ou les règles qui dépendent d'un contexte externe absent du document.

Exemple : règles claires ou vagues

Limites de taille et division de documents volumineux

La taille des documents source est limitée à 5 Mo et 50 000 caractères. Les images et les tableaux contenus dans les documents sont également pris en compte dans le calcul de la limite de caractères.

Si votre document dépasse ces limites, ou s'il couvre plusieurs domaines indépendants, divisez-le en sections ciblées. Par exemple, divisez un manuel de l'employé en documents distincts pour les politiques relatives aux congés, l'éligibilité aux avantages sociaux et le remboursement des dépenses. Créez votre politique avec la première section, puis utilisez la création de politiques itérative (décrite plus loin sur cette page) pour fusionner des sections supplémentaires dans la même politique.

Pré-traiter des documents complexes

Les documents contenant de nombreuses clauses générales, des avertissements juridiques ou du contenu sans rapport avec les règles que vous souhaitez appliquer produiront des politiques bruyantes contenant des variables et des règles inutiles. Avant de procéder au téléchargement, considérez les points suivants :

(Facultatif) Utilisez un LLM pour réécrire les documents sous forme de règles logiques

Pour les documents contenant de la prose narrative, du langage juridique ou une mise en forme complexe, envisagez d'utiliser un modèle novateur doté de capacités de raisonnement avancées pour réécrire le contenu sous forme de règles claires et logiques avant de le télécharger vers des contrôles de raisonnement automatisés. Cette étape de prétraitement unique convertit le texte dans un format que les contrôles de raisonnement automatisés peuvent extraire avec plus de précision, ce qui permet d'obtenir des politiques de meilleure qualité avec moins de variables inutilisées et de simples assertions.

Il existe deux approches pour le prétraitement LLM, en fonction de la complexité de votre document et du degré de contrôle que vous souhaitez obtenir sur l'extraction.

Approche 1 : extraction de règles en texte brut

Demandez au LLM de réécrire le document sous la forme d'une liste numérotée de règles « sif-then ». Cette approche est simple et fonctionne bien pour les documents courts et ciblés dont les règles sont relativement claires dans la source.

Exemple d'invite :

You are a logical reasoning expert. Your task is to analyze the provided
source text and rewrite it as a set of clear, logical rules using if-then
statements.

Instructions:
1. Extract the key relationships, conditions, and outcomes from the source text.
2. Convert these into logical implications using "if-then" format.
3. Use clear, precise language that captures the original meaning.
4. Number each rule for easy reference.
5. Ensure rules are mutually consistent and non-contradictory.

Format:
- Rule [N]: If [condition], then [consequence].
- Use "and" to combine multiple conditions.
- Use "or" for alternative conditions.
- Include negations when relevant: If not [condition], then [consequence].

Example:
Source: "Students who complete all assignments and attend at least 80% of
classes will pass the course."
Rule 1: If a student completes all assignments and attends at least 80% of
classes, then they will pass the course.

Source Text:
[Paste your document here]

Approche 2 : extraction de règles structurées

Pour les documents complexes ou longs, demandez au LLM d'extraire les règles sous forme de JSON structuré avec des métadonnées pour chaque règle. Cette approche produit des résultats plus riches qui vous aident à vérifier les parties du document d'où provient chaque règle, le degré de fiabilité de l'extraction et les règles qui sont déduites plutôt que énoncées directement. Il demande également au LLM de générer des règles de bon sens — des contraintes limites de bon sens telles que « l'âge ne doit pas être négatif » — qui se traduisent directement dans les règles de limites utilisées par les politiques de raisonnement automatisé. Pour plus d'informations sur les règles de délimitation, voirValidation de plages pour les valeurs numériques.

Exemple d'invite :

You are a logical reasoning expert. Extract formal logical rules from the
provided text.

Output Format:
For each rule, provide:
- Rule ID: [unique identifier]
- Conditions: [ALL preconditions — preserve compound conditions with AND/OR/NOT]
- Consequence: [the outcome/action]
- Confidence: [high/medium/low based on text clarity]
- Source Reference: [quote or paraphrase from source]
- Rule Type: [explicit/implicit/sanity]

Critical Guidelines:
1. PRESERVE ALL CONDITIONS: Do not drop or simplify conditions.
2. PRESERVE LOGICAL OPERATORS: Maintain AND, OR, NOT relationships exactly.
3. PRESERVE QUANTIFIERS: Keep "all", "any", "at least", numeric thresholds.
4. PRESERVE EXCEPTIONS: Include "unless", "except when" clauses.
5. Make implicit conditions explicit only when clearly implied by context.
6. Use consistent terminology across rules.
7. Flag ambiguities such as unclear, incomplete, or contradictory statements.
8. Add sanity rules for common-sense constraints:
   - Numeric ranges (e.g., "age must be between 0 and 150")
   - Temporal constraints (e.g., "start date must be before end date")
   - Physical limits (e.g., "quantity cannot be negative")
   - Mutual exclusivity (e.g., "status cannot be both active and inactive")

Output Requirements:
- Produce final JSON only (no text or markdown).
- Use the following JSON keys:
  - "rules" for the rules array
  - "ambiguities" for the ambiguities array

Source Text:
[Paste your document here]

Après avoir exécuté l'extraction structurée, passez en revue la sortie JSON. Portez une attention particulière à :

Convertissez les règles JSON révisées en instructions if-then en texte brut à utiliser comme document source lors de la création de la politique de raisonnement automatisé.

Rédiger des instructions efficaces

Lorsque vous créez une politique, vous pouvez fournir des instructions facultatives qui indiquent comment Automated Reasoning traite votre document source. Bien que facultatives, de bonnes instructions améliorent considérablement la qualité des règles et des variables extraites.

Pour être efficaces, les instructions doivent couvrir trois points :

Exemple d'instruction :

This policy will validate HR questions about leave eligibility. The document
has sections on different leave types (parental, medical, bereavement, personal).
Users will ask questions like "Am I eligible for parental leave if I've worked
here for 9 months?" or "Can part-time employees take bereavement leave?"
Focus on the eligibility criteria for each leave type. Capture variables that
help determine whether an employee is eligible for a specific type of leave.

Création d'une politique dans la console

Création d'une politique à l'aide de l'API

Une politique de raisonnement automatisé est une ressource de votre compte AWS identifiée par un Amazon Resource Name (ARN). La création d'une politique via l'API est un processus en deux étapes : créez d'abord la ressource de politique, puis lancez un flux de travail de génération pour extraire les règles de votre document.

Étape 1 : Création de la ressource de politique

Utilisez l'CreateAutomatedReasoningPolicyAPI pour créer la ressource de politique.

Exemple :

aws bedrock create-automated-reasoning-policy \
  --name "MyHRPolicy" \
  --description "Validates HR chatbot responses about leave eligibility" \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/12345678-1234-1234-1234-123456789012

Exemple de réponse :

{
  "createdAt": "2025-07-21T14:43:52.692Z",
  "definitionHash": "f16ba1ceca36e1d21adce559481add6a...",
  "name": "MyHRPolicy",
  "policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk",
  "updatedAt": "2025-07-21T14:43:52.692Z",
  "version": "DRAFT"
}

Étape 2 : démarrer un flux de travail de génération pour extraire les règles

Utilisez l'StartAutomatedReasoningPolicyBuildWorkflowAPI avec l'ARN de politique indiqué à l'étape 1 pour extraire les règles et les variables de votre document source.

Exemple :

# Encode your PDF to base64
PDF_BASE64=$(base64 -i your-policy.pdf | tr -d '\n')

# Start the build workflow
aws bedrock start-automated-reasoning-policy-build-workflow \
  --policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk \
  --build-workflow-type INGEST_CONTENT \
  --source-content "{
    \"policyDefinition\": {
      \"version\": \"1.0\",
      \"types\": [],
      \"rules\": [],
      \"variables\": []
    },
    \"workflowContent\": {
      \"documents\": [
        {
          \"document\": \"$PDF_BASE64\",
          \"documentContentType\": \"pdf\",
          \"documentName\": \"HR Leave Policy\",
          \"documentDescription\": \"Validates HR chatbot responses about leave eligibility. Users ask questions like 'Am I eligible for parental leave?'\"
        }
      ]
    }
  }"

Exemple de réponse :

{
  "policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk",
  "buildWorkflowId": "d40fa7fc-351e-47d8-a338-53e4b3b1c690"
}

Vérifiez l'état de la construction avec ListAutomatedReasoningPolicyBuildWorkflows :

aws bedrock list-automated-reasoning-policy-build-workflows \
  --policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk

Passez en revue la politique extraite

Une fois la génération terminée, passez en revue la définition de politique extraite avant de commencer les tests. La détection des problèmes à ce stade permet de gagner du temps par rapport à leur découverte ultérieure suite à l'échec de tests.

Dans la console, ouvrez votre politique et accédez à la page Définitions. Via l'API, utilisez GetAutomatedReasoningPolicyBuildWorkflowResultAssets with --asset-type POLICY_DEFINITION pour récupérer la définition extraite et --asset-type QUALITY_REPORT pour récupérer le rapport de qualité. Vous pouvez consulter une liste complète des actifs produits au cours du flux de travail, tels que le rapport de fidélité, à l'aide du --asset-type ASSET_MANIFEST paramètre.

Vérifiez les problèmes suivants :

Consultez le rapport de fidélité

Lorsque vous créez une politique à partir d'un document source, un rapport de fidélité est automatiquement généré en même temps que la politique extraite. Le rapport de fidélité mesure la précision avec laquelle la politique représente votre contenu source et fournit des bases détaillées qui relient chaque règle et variable à des déclarations spécifiques du document. Pour plus d'informations sur les concepts des rapports de fidélité, consultezRapport de fidélité.

Consultez le rapport de fidélité dans la console

Dans la console, ouvrez votre politique et choisissez l'onglet Document source (à côté de Définitions). L'affichage du contenu source affiche chaque instruction atomique extraite de votre document sous forme de ligne numérotée dans un tableau. Chaque ligne indique :

Utilisez les filtres déroulants Règles et variables en haut du tableau pour vous concentrer sur les déclarations qui fondent une règle ou une variable spécifique. Utilisez la barre de recherche pour trouver un contenu spécifique dans les déclarations extraites.

Si vous modifiez la politique après l'extraction initiale, par exemple en modifiant les règles ou en ajoutant des variables, cliquez sur le bouton Régénérer pour mettre à jour le rapport de fidélité afin qu'il reflète votre définition de politique actuelle.

Consultez le rapport de fidélité à l'aide de l'API

Utilisez GetAutomatedReasoningPolicyBuildWorkflowResultAssets with --asset-type FIDELITY_REPORT pour récupérer le rapport de fidélité. Pour régénérer le rapport après avoir apporté des modifications aux politiques, utilisez-le StartAutomatedReasoningPolicyBuildWorkflow avec le type de flux de travail de génération GENERATE_FIDELITY_REPORT et fournissez les documents sources generateFidelityReportContent sur le terrain. Le flux de travail réanalyse les documents par rapport à la définition de politique actuelle et produit un nouveau rapport de fidélité. Vous pouvez également récupérer les documents source d'origine à partir d'un flux de travail de génération précédent à l'--asset-type SOURCE_DOCUMENTaide du --asset-id paramètre (obtenir l'ID de l'actif à partir du manifeste des actifs).

Ce qu’il faut rechercher

Lorsque vous consultez le rapport de fidélité du APIs, faites attention aux points suivants :

Élaboration itérative de politiques

Pour les domaines complexes, élaborez votre politique progressivement plutôt que d'essayer de tout capturer dans un seul document chargé. Commencez par un sous-ensemble ciblé de vos règles, créez et testez la politique, puis ajoutez du contenu lors des itérations suivantes.

Ajouter du contenu dans la console

Ajouter du contenu à l'aide de l'API

Appelez StartAutomatedReasoningPolicyBuildWorkflow avecINGEST_CONTENT, en transmettant la définition complète de la politique actuelle avec le nouveau document. Vous devez inclure la définition existante complète (règles, variables et types) afin que le nouveau contenu soit fusionné avec la politique existante plutôt que de le remplacer.

# First, retrieve the current policy definition
aws bedrock get-automated-reasoning-policy \
  --policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk

# Encode the new document
PDF_BASE64=$(base64 -i additional-rules.pdf | tr -d '\n')

# Start a build workflow with the existing definition + new document
aws bedrock start-automated-reasoning-policy-build-workflow \
  --policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk \
  --build-workflow-type INGEST_CONTENT \
  --source-content "{
    \"policyDefinition\": EXISTING_POLICY_DEFINITION_JSON,
    \"workflowContent\": {
      \"documents\": [
        {
          \"document\": \"$PDF_BASE64\",
          \"documentContentType\": \"pdf\",
          \"documentName\": \"Additional Benefits Rules\",
          \"documentDescription\": \"Additional rules covering medical and bereavement leave eligibility.\"
        }
      ]
    }
  }"

Autorisations KMS pour les politiques de raisonnement automatisé

Si vous spécifiez une clé KMS gérée par le client pour chiffrer votre politique de raisonnement automatisé, vous devez configurer des autorisations permettant à Amazon Bedrock d’utiliser la clé en votre nom.

Autorisations de stratégie de clé

Ajoutez la déclaration suivante à votre stratégie de clé KMS pour autoriser Amazon Bedrock à utiliser la clé pour les politiques de raisonnement automatisé :

{
  "Sid": "PermissionsForAutomatedReasoningPolicy",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:user/role"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:aws:bedrock:automated-reasoning-policy": [
        "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/policy-id",
        "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/policy-id:*"
      ],
      "kms:ViaService": "bedrock.us-east-1.amazonaws.com"
    }
  }
}

Autorisations IAM

Votre principal IAM doit disposer des autorisations suivantes pour utiliser une clé KMS gérée par le client avec des politiques de raisonnement automatisé :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowKMSForAutomatedReasoningPolicy",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:DescribeKey",
        "kms:GenerateDataKey"
      ],
      "Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:aws:bedrock:automated-reasoning-policy": [
            "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/policy-id",
            "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/policy-id:*"
          ],
          "kms:ViaService": "bedrock.us-east-1.amazonaws.com"
        }
      }
    }
  ]
}

Contexte de chiffrement

Amazon Bedrock utilise un contexte de chiffrement pour renforcer la sécurité de vos politiques de raisonnement automatisé. Le contexte de chiffrement est un ensemble de paires clé-valeur utilisées comme données authentifiées supplémentaires lors du chiffrement et du déchiffrement de votre politique.

Pour les politiques de raisonnement automatisé, Amazon Bedrock utilise le contexte de chiffrement suivant :