Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Creare una policy di ragionamento automatico

Quando si crea una policy di ragionamento automatico, il documento di origine viene tradotto in una serie di regole logiche formali e uno schema di variabili e tipi. Questa pagina ti guida nella preparazione del documento, nella creazione della politica e nella revisione dei risultati.

Amazon Bedrock crittografa la policy di ragionamento automatico con Servizio AWS di gestione delle chiavi (AWS KMS). Per impostazione predefinita, Amazon Bedrock usa una chiave di proprietà del servizio. Facoltativamente, è possibile specificare una chiave KMS gestita dal cliente per un ulteriore controllo sulla crittografia dei dati delle policy.

Per testare e utilizzare la tua politica di ragionamento automatico, assicurati di disporre delle autorizzazioni appropriate.

Prepara il documento sorgente

Prima di aprire la console o chiamare l'API, prepara il documento che Automated Reasoning utilizzerà per estrarre regole e variabili. La qualità della tua politica dipende direttamente dalla qualità di questo input.

Struttura e chiarezza del documento

I controlli di ragionamento automatico funzionano meglio con documenti che contengono regole chiare e inequivocabili. Ogni regola deve indicare una condizione e un risultato. Evita un linguaggio vago, criteri soggettivi o regole che dipendono da un contesto esterno non presente nel documento.

Esempio: regole chiare o vaghe

Limiti di dimensione e suddivisione di documenti di grandi dimensioni

I documenti di origine hanno una dimensione massima di 5 MB e 50.000 caratteri. Anche le immagini e le tabelle nei documenti vengono conteggiate ai fini del limite di caratteri.

Se il documento supera questi limiti o se copre più domini non correlati, suddividilo in sezioni mirate. Ad esempio, suddividi un manuale per i dipendenti in documenti separati per le politiche sulle ferie, l'idoneità alle indennità e il rimborso delle spese. Crea la tua polizza con la prima sezione, quindi utilizza la creazione iterativa delle politiche (descritta più avanti in questa pagina) per unire sezioni aggiuntive nella stessa politica.

Pre-process documenti complessi

I documenti che contengono molte clausole di esclusione di responsabilità legali o contenuti non correlati alle regole che si desidera applicare produrranno politiche rumorose con variabili e regole non necessarie. Prima di caricarli, considera:

(Facoltativo) Usa un LLM per riscrivere i documenti come regole logiche

Per i documenti che contengono prosa narrativa, linguaggio legale o formattazione complessa, prendi in considerazione l'utilizzo di un modello di frontiera con capacità di ragionamento avanzate per riscrivere il contenuto sotto forma di regole chiare e logiche prima di caricarlo nei controlli di ragionamento automatico. Questa fase di preelaborazione, una tantum, converte il testo in un formato da cui i controlli di Automated Reasoning possono estrarre con maggiore precisione, ottenendo politiche di qualità superiore con meno variabili inutilizzate e semplici asserzioni.

Esistono due approcci alla preelaborazione LLM, a seconda della complessità del documento e del livello di controllo desiderato sull'estrazione.

Approccio 1: estrazione delle regole in testo normale

Chiedi al LLM di riscrivere il documento come un elenco numerato di regole if-then. Questo approccio è semplice e funziona bene per documenti brevi e mirati in cui le regole sono relativamente chiare nella fonte.

Esempio di richiesta:

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]

Approccio 2: estrazione strutturata delle regole

Per documenti complessi o lunghi, chiedi al LLM di estrarre le regole come JSON strutturato con metadati per ogni regola. Questo approccio produce un output più ricco che ti aiuta a verificare da quali parti del documento proviene ciascuna regola, quanto è sicura l'estrazione e quali regole sono dedotte anziché dichiarate direttamente. Chiede inoltre al LLM di generare regole di sanità mentale (vincoli di confine basati sul buon senso come «l'età non deve essere negativa») che si traducano direttamente nelle regole di confine utilizzate dalle politiche di ragionamento automatico. Per ulteriori informazioni sulle regole di confine, vedere. Convalidare gli intervalli per i valori numerici

Esempio di richiesta:

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]

Dopo aver eseguito l'estrazione strutturata, rivedi l'output JSON. Presta particolare attenzione a:

Converte le regole JSON riviste in istruzioni if-then in testo semplice da utilizzare come documento sorgente durante la creazione della politica di ragionamento automatico.

Scrivi istruzioni efficaci

Quando crei una policy, puoi fornire istruzioni opzionali che guidino il modo in cui Automated Reasoning elabora il documento di origine. Sebbene facoltative, buone istruzioni migliorano significativamente la qualità delle regole e delle variabili estratte.

Le istruzioni efficaci dovrebbero riguardare tre aspetti:

Istruzioni di esempio:

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.

Crea una policy nella console

Crea una policy utilizzando l'API

Una policy di ragionamento automatico è una risorsa del tuo AWS account identificata da un Amazon Resource Name (ARN). La creazione di una policy tramite l'API è un processo in due fasi: prima crea la risorsa della policy, quindi avvia un flusso di lavoro di compilazione per estrarre le regole dal tuo documento.

Fase 1: Creare la risorsa relativa alla politica

Usa l'CreateAutomatedReasoningPolicyAPI per creare la risorsa politica.

Esempio:

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

Risposta di esempio:

{
  "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"
}

Passaggio 2: avvia un flusso di lavoro di compilazione per estrarre le regole

Usa l'StartAutomatedReasoningPolicyBuildWorkflowAPI con la policy ARN del passaggio 1 per estrarre regole e variabili dal tuo documento di origine.

Esempio:

# 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?'\"
        }
      ]
    }
  }"

Risposta di esempio:

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

Controlla lo stato della build con: ListAutomatedReasoningPolicyBuildWorkflows

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

Rivedi la politica estratta

Al termine di una compilazione, rivedi la definizione della policy estratta prima di iniziare il test. L'individuazione dei problemi in questa fase consente di risparmiare tempo rispetto alla loro individuazione tramite test falliti in un secondo momento.

Nella console, apri la tua policy e vai alla pagina Definizioni. Tramite l'API, usa GetAutomatedReasoningPolicyBuildWorkflowResultAssets with --asset-type POLICY_DEFINITION per recuperare la definizione estratta e --asset-type QUALITY_REPORT per recuperare il rapporto sulla qualità. Puoi visualizzare un elenco completo delle risorse prodotte durante il flusso di lavoro, ad esempio il rapporto di fedeltà, utilizzando il parametro. --asset-type ASSET_MANIFEST

Verifica i problemi seguenti:

Consulta il rapporto sulla fedeltà

Quando crei una politica da un documento di origine, viene generato automaticamente un rapporto di fedeltà insieme alla politica estratta. Il rapporto di fedeltà misura l'accuratezza con cui la politica rappresenta il contenuto di origine e fornisce una base dettagliata che collega ogni regola e variabile a dichiarazioni specifiche del documento. Per ulteriori informazioni sui concetti di Fidelity Report, vedere. Rapporto Fidelity

Rivedi il rapporto di fedeltà nella console

Nella console, apri la polizza e scegli la scheda Documento di origine (accanto a Definizioni). La vista Contenuto sorgente mostra ogni dichiarazione atomica estratta dal documento come riga numerata in una tabella. Ogni riga mostra:

Utilizza i filtri a discesa Regole e variabili per concentrarti sulle istruzioni che fondano una regola o una variabile specifica. Usa la barra di ricerca per trovare contenuti specifici all'interno delle dichiarazioni estratte.

Se modificate la policy dopo l'estrazione iniziale, ad esempio modificando regole o aggiungendo variabili, scegliete il pulsante Rigenera per aggiornare il rapporto di fedeltà in modo che rifletta la definizione corrente della policy.

Rivedi il rapporto di fedeltà utilizzando l'API

Usa GetAutomatedReasoningPolicyBuildWorkflowResultAssets with --asset-type FIDELITY_REPORT per recuperare il rapporto di fedeltà. Per rigenerare il report dopo aver apportato modifiche alle politiche, utilizza StartAutomatedReasoningPolicyBuildWorkflow il tipo di flusso di lavoro di compilazione GENERATE_FIDELITY_REPORT e fornisci i documenti di origine sul campo. generateFidelityReportContent Il flusso di lavoro rianalizza i documenti rispetto all'attuale definizione delle politiche e produce un nuovo rapporto di fedeltà. È inoltre possibile recuperare i documenti di origine originali da un precedente flusso di lavoro di compilazione utilizzando --asset-type SOURCE_DOCUMENT il --asset-id parametro (ottenere l'ID della risorsa dal manifesto dell'asset).

Cosa cercare

Quando esaminate il rapporto di fedeltà dalle API, prestate attenzione a:

Elaborazione iterativa delle politiche

Per i domini complessi, crea la tua policy in modo incrementale anziché cercare di acquisire tutto in un unico caricamento di documenti. Inizia con un sottoinsieme mirato delle tue regole, crea e testa la policy, quindi aggiungi altri contenuti nelle iterazioni successive.

Aggiungi contenuti nella console

Aggiungi contenuti utilizzando l'API

Chiama StartAutomatedReasoningPolicyBuildWorkflow conINGEST_CONTENT, trasmettendo la definizione completa della politica attuale insieme al nuovo documento. È necessario includere l'intera definizione esistente (regole, variabili e tipi) in modo che il nuovo contenuto venga unito alla politica esistente anziché sostituirla.

# 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.\"
        }
      ]
    }
  }"

Importa una definizione di policy utilizzando l'API

Se disponi già di una definizione di policy in formato JSON, utilizza StartAutomatedReasoningPolicyBuildWorkflow with IMPORT_POLICY per importarla direttamente. In questo modo si salta la fase di estrazione del documento e si carica la definizione così com'è.

aws bedrock start-automated-reasoning-policy-build-workflow \
  --policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk \
  --build-workflow-type IMPORT_POLICY \
  --source-content "{
    \"policyDefinition\": {
      \"version\": \"1.0\",
      \"variables\": [
        {
          \"name\": \"isFullTime\",
          \"type\": \"BOOL\",
          \"description\": \"Whether the employee works full-time.\"
        }
      ],
      \"rules\": [
        {
          \"id\": \"A1B2C3D4E5F6\",
          \"expression\": \"(=> isFullTime eligibleForBenefits)\"
        }
      ],
      \"types\": []
    }
  }"

Perfeziona una policy in modo iterativo utilizzando l'API

Usa StartAutomatedReasoningPolicyBuildWorkflow with ITERATIVELY_REFINE_POLICY per perfezionare una policy esistente utilizzando un documento sorgente e un feedback opzionale in linguaggio naturale. A differenza di ciò INGEST_CONTENT che estrae nuove regole da un documento, questo flusso di lavoro utilizza il documento come contesto per migliorare la politica esistente. Casi di utilizzo comune comprendono:

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

aws bedrock start-automated-reasoning-policy-build-workflow \
  --policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk \
  --build-workflow-type ITERATIVELY_REFINE_POLICY \
  --source-content "{
    \"policyDefinition\": EXISTING_POLICY_DEFINITION_JSON,
    \"workflowContent\": {
      \"iterativeRefinementContent\": {
        \"documents\": [
          {
            \"document\": \"$PDF_BASE64\",
            \"documentContentType\": \"pdf\",
            \"documentName\": \"Updated HR Policy v2\",
            \"documentDescription\": \"Revised HR leave policy with updated eligibility criteria.\"
          }
        ],
        \"feedback\": \"Update the tenure requirement for parental leave from 12 months to 6 months, as specified in section 3 of the revised document.\"
      }
    }
  }"

Autorizzazioni KMS per le policy di ragionamento automatico

Se si specifica una chiave KMS gestita dal cliente per crittografare la policy di ragionamento automatico, è necessario configurare le autorizzazioni che consentano ad Amazon Bedrock di utilizzare la chiave per conto dell’utente.

Autorizzazioni per le policy della chiave

Aggiungi la seguente dichiarazione alla policy della chiave KMS per consentire ad Amazon Bedrock di utilizzarla chiave per le policy di ragionamento automatico:

{
  "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"
    }
  }
}

autorizzazioni IAM

Il principale IAM deve disporre delle seguenti autorizzazioni per utilizzare una chiave KMS gestita dal cliente con le policy di ragionamento automatico:

{
  "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"
        }
      }
    }
  ]
}

Contesto di crittografia

Amazon Bedrock utilizza il contesto di crittografia per fornire ulteriore sicurezza alle policy di ragionamento automatico. Il contesto di crittografia è un insieme di coppie chiave-valore utilizzate come dati autenticati aggiuntivi durante la crittografia e la decrittografia della policy.

Per le policy di ragionamento automatico, Amazon Bedrock usa il seguente contesto di crittografia: