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 ](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrail-automated-reasoning-permissions.html) 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 **
| Trasparente (ottimo per l'estrazione) | Vago (scarso per l'estrazione) |
| --- | --- |
| «Full-time i dipendenti con almeno 12 mesi di servizio continuo hanno diritto al congedo parentale». | «I dipendenti idonei possono richiedere il congedo parentale previa approvazione del dirigente». |
| «Le richieste di rimborso devono essere presentate entro 30 giorni dall'acquisto. Gli articoli devono essere nella confezione originale.» | «I rimborsi vengono gestiti caso per caso». |
### 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:
+ Rimuovere intestazioni, piè di pagina, sommario e appendici che non contengono regole.
+ Estrarre solo le sezioni che contengono le regole pertinenti al tuo caso d'uso.
+ Semplificazione di tabelle complesse in semplici istruzioni di testo, ove possibile.
**Suggerimento**
Inizia con un sottoinsieme mirato delle tue regole. Crea e testa accuratamente la policy, quindi aggiungi gradualmente altri contenuti nelle iterazioni successive. Questo approccio consente di identificare e risolvere tempestivamente i problemi e ne semplifica la risoluzione.
### (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.
**Nota**
Controlla sempre l'output del LLM confrontandolo con il documento originale prima di utilizzarlo come testo sorgente.
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](automated-reasoning-policy-best-practices.md#bp-validate-ranges)
**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:
+ Regole con`confidence: low`: potrebbe essere necessaria una verifica manuale rispetto al documento di origine.
+ Regole con`ruleType: implicit`: sono state dedotte anziché dichiarate direttamente. Verifica che riflettano accuratamente l'intento della fonte.
+ L'`ambiguities`array: evidenziano le aree in cui il documento di origine non è chiaro e potrebbe essere necessario riscriverlo prima dell'estrazione.
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:
1. **Descrivi il caso d'uso. ** Spiega cosa fa la tua applicazione e quale tipo di contenuto verrà convalidato dalla policy. Ad esempio: «Questa policy convaliderà un chatbot delle risorse umane che risponde alle domande dei dipendenti sull'idoneità al congedo».
1. **Descrivi i tipi di domande che gli utenti faranno. ** Fornisci esempi di domande realistiche degli utenti. Ad esempio: «Gli utenti faranno domande come «Ho diritto al congedo parentale se lavoro qui da 9 mesi?» o «Quanti giorni di congedo per lutto posso usufruire?»
1. **Concentra l'estrazione. ** Se il documento tratta più argomenti, indica ai controlli di ragionamento automatico su quali parti concentrarsi e quali ignorare. Ad esempio: «Concentrati sulle sezioni da 3 a 5 che riguardano le politiche sulle ferie. Ignora la panoramica generale dell'azienda nella sezione 1 e l'organigramma nella sezione 2.»
**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
1. Nel riquadro di navigazione a sinistra, scegli **Ragionamento automatico**, quindi scegli **Crea policy**.
1. Inserisci un **Nome** per la policy.
1. (Facoltativo) Compila il campo **Descrizione** per la policy.
1. Per ** Source**, fornisci il documento che descrive le regole e le politiche del tuo dominio di conoscenza. Esegui questa operazione:
1. Per **Metodo di importazione**, esegui una di queste operazioni:
1. Seleziona **Carica documento**, quindi seleziona **Scegli file**. Carica un documento PDF con il contenuto di origine.
1. Seleziona **Inserisci testo**. Incolla o inserisci il contenuto di origine.
1. (Consigliato) Per ** istruzioni**, fornisci indicazioni su come elaborare il documento di origine. Scopri [Scrivi istruzioni efficaci](#write-effective-instructions) cosa includere.
1. (Facoltativo) Per **Tag**, scegli **Aggiungi nuovo tag** per aggiungere un tag alla policy.
1. (Facoltativo) Per **Crittografia**, scegli una chiave KMS per crittografare la policy. Puoi utilizzare la chiave predefinita di proprietà del servizio o selezionare una chiave gestita dal cliente.
1. Scegli **Crea policy**.
**Suggerimento**
Se l'applicazione prevede un set specifico di variabili, è possibile predefinire lo schema prima di importare il contenuto. Utilizza l'`CreateAutomatedReasoningPolicy`API o CloudFormation crea una policy con una `policyDefinition` che contenga le variabili e i tipi desiderati ma nessuna regola. Quindi utilizzalo [Elaborazione iterativa delle politiche](#iterative-policy-building) per importare il documento di origine. Automated Reasoning utilizzerà lo schema predefinito come punto di partenza e aggiungerà regole che fanno riferimento alle variabili.
## 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'`CreateAutomatedReasoningPolicy`API per creare la risorsa politica.
`name`(obbligatorio)
Il nome della policy . Deve essere univoco all'interno del tuo AWS account e della tua Regione.
`description` (facoltativo)
Una descrizione dello scopo della polizza.
`policyDefinition` (facoltativo)
Una definizione iniziale della politica con regole, variabili e tipi personalizzati. Usalo se hai già uno schema da cui partire.
`kmsKeyId` (facoltativo)
L'identificatore della chiave KMS per crittografare la policy. Se non specificato, Amazon Bedrock utilizza una chiave di proprietà del servizio.
`tags` (facoltativo)
Tag da associare alla policy.
`clientRequestToken` (facoltativo)
Un token di idempotenza per garantire che l'operazione venga completata non più di una volta.
**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'`StartAutomatedReasoningPolicyBuildWorkflow`API con la policy ARN del passaggio 1 per estrarre regole e variabili dal tuo documento di origine.
`policyArn`(richiesto)
L'ARN della risorsa politica creata nel passaggio 1.
`buildWorkflowType`(obbligatorio)
Impostato su `INGEST_CONTENT` per estrarre le regole da un documento. Puoi anche usarlo `INGEST_CONTENT` per unire il contenuto estratto da un documento in una politica esistente: includi la definizione della politica corrente `sourceContent` insieme al nuovo documento e le regole, le variabili e i tipi estratti vengono composti nella definizione esistente anziché sostituirla. Per informazioni, consulta [Elaborazione iterativa delle politiche](#iterative-policy-building).
`sourceContent`(obbligatorio)
Contiene il documento da elaborare e una definizione facoltativa della politica iniziale.
**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?'}}\"
}
]
}
}"
```
**Nota**
Nell'`policyDefinition`oggetto, il `version` campo è obbligatorio e deve essere impostato su`1.0`. Identifica la versione dello schema di definizione della politica ed è distinta dalla versione della risorsa politica (`DRAFT`o da una versione numerata).
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:
1. **Variabili non utilizzate. ** Nella console, cerca gli indicatori di avviso accanto alle variabili. Questi contrassegnano le variabili a cui non fa riferimento alcuna regola. Elimina le variabili inutilizzate: aggiungono rumore al processo di traduzione e possono causare `TRANSLATION_AMBIGUOUS` risultati. Nell'API, le variabili non utilizzate sono elencate nell'`QUALITY_REPORT`asset.
1. **Variabili duplicate o quasi duplicate. ** Scansiona l'elenco delle variabili per le variabili con significati sovrapposti, come e`tenureMonths`. `monthsOfService` Le variabili duplicate confondono il processo di traduzione perché i controlli di ragionamento automatico non possono determinare quale usare per un determinato concetto. Unisci o elimina i duplicati.
1. **Asserzioni semplici (regole non in formato if-then). ** Scorri le regole e cerca le regole che non siano in formato if-then, ad esempio. `(= eligibleForParentalLeave true)` Le semplici asserzioni creano assiomi, affermazioni sempre vere, che rendono logicamente impossibili determinate condizioni e portano a risultati inaspettati durante la convalida. `IMPOSSIBLE` Riscrivili come condizionali (ad esempio) o eliminali. `(=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave)` Le semplici asserzioni sono appropriate solo per condizioni al contorno come. `(>= accountBalance 0)`
1. **Regole contrastanti. ** Il rapporto sulla qualità segnala le regole che si contraddicono a vicenda. Regole in conflitto fanno sì che la politica venga restituita `IMPOSSIBLE` per tutte le richieste di convalida che coinvolgono regole in conflitto. Risolvi i conflitti unendo le regole o eliminandone una.
1. **Regole o variabili mancanti. ** Confronta la policy estratta con il tuo documento di origine. Se mancano regole o concetti importanti, puoi aggiungerli manualmente o ricreare la politica con istruzioni migliori.
**Suggerimento**
Il rapporto sulla qualità identifica anche set di regole disgiunti, ovvero gruppi di regole che non condividono alcuna variabile. I set di regole disgiunti non sono necessariamente un problema (la tua politica può riguardare argomenti indipendenti), ma possono indicare che nelle variabili mancano connessioni tra regole correlate.
## 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](automated-reasoning-checks-concepts.md#ar-concept-fidelity-report)
### 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:
+ Il numero dell'istruzione e il testo estratto.
+ Il ** documento di origine da cui proviene ** la dichiarazione.
+ Il numero di ** regole ** basate su tale dichiarazione.
+ Il numero di ** variabili ** basate su tale dichiarazione.
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:
+ **Punteggio di copertura basso. ** Un punteggio di copertura basso indica che parti significative del documento di origine non sono state incluse nella politica. Cerca le dichiarazioni con 0 regole e 0 variabili nella visualizzazione del contenuto di origine per identificare quali parti del documento sono state omesse e valuta la possibilità di utilizzare la creazione iterativa di policy per aggiungere il contenuto mancante. Per informazioni, consulta [Elaborazione iterativa delle politiche](#iterative-policy-building).
+ **Punteggio di precisione basso sulle singole regole. ** Ogni regola ha il proprio punteggio di precisione e la propria giustificazione. Le regole con punteggi di precisione bassi potrebbero non rappresentare fedelmente il materiale originale. Utilizza il ** filtro ** Regole per isolare le affermazioni di base di una regola specifica e confrontarle con la logica formale della regola per identificare interpretazioni errate.
+ **Regole o variabili non fondate. ** Le regole o le variabili prive di istruzioni di base possono essere state dedotte anziché estratte direttamente dal documento. Verifica che siano corrette o rimuovile se non riflettono il tuo intento.
**Suggerimento**
Il rapporto di fedeltà è particolarmente utile per la collaborazione con gli esperti di dominio che hanno creato il documento sorgente. Condividi con loro la ** visualizzazione del documento ** sorgente in modo che possano verificare che la policy rispecchi correttamente le loro intenzioni senza dover leggere direttamente le regole logiche formali.
## 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
1. Apri la tua politica di ragionamento automatico nella console.
1. Nella ** pagina ** Definizioni, scegli ** Importa**.
1. Seleziona l'opzione per unire il nuovo contenuto con la definizione della politica esistente.
1. Carica o incolla il contenuto sorgente aggiuntivo.
1. Rivedi la definizione aggiornata della policy e risolvi eventuali nuovi conflitti o duplicati.
### Aggiungi contenuti utilizzando l'API
Chiama `StartAutomatedReasoningPolicyBuildWorkflow` con`INGEST_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.}}\"
}
]
}
}"
```
**Importante**
L'API supporta un massimo di 2 flussi di lavoro di compilazione per policy, di cui solo uno può essere eseguito `IN_PROGRESS` in qualsiasi momento. Se devi iniziare una nuova build e disponi già di 2 flussi di lavoro, eliminane prima uno vecchio utilizzando. `DeleteAutomatedReasoningPolicyBuildWorkflow`
### 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:
+ **Correzione dei test non riusciti. ** Quando un test restituisce risultati imprevisti, fornisci il documento di origine e il feedback che descrivono il comportamento previsto per perfezionare le regole delle policy.
+ **Rispondere al feedback sui concetti mancanti. ** Fornisci un feedback in linguaggio naturale sui concetti che non sono attualmente inclusi nella policy, insieme al documento di origine come contesto.
+ **Aggiornamento dopo le modifiche al documento di origine. ** Quando il documento di origine viene revisionato, fornisci il documento aggiornato e descrivi le modifiche specifiche da incorporare.
`policyDefinition`(obbligatorio)
La definizione completa della politica attuale da perfezionare.
`workflowContent.iterativeRefinementContent.documents`(obbligatorio)
Il documento di origine da utilizzare come contesto per il perfezionamento.
`workflowContent.iterativeRefinementContent.feedback` (facoltativo)
Istruzioni in linguaggio naturale che descrivono le modifiche o i miglioramenti specifici desiderati. Ad esempio, «Aggiungi regole per l'idoneità al congedo per lutto» o «Aggiorna la soglia di permanenza in carica da 12 mesi a 6 mesi in base alla nuova revisione delle politiche».
```
# 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.}}\"
}
}
}"
```
**Suggerimento**
`ITERATIVELY_REFINE_POLICY`Utilizzalo quando il documento di origine è stato aggiornato e desideri che la politica rifletta le modifiche o quando desideri guidare il perfezionamento con istruzioni specifiche. `INGEST_CONTENT`Usala invece quando desideri aggiungere contenuti completamente nuovi da un nuovo documento.
## 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:
+ **Chiave**: `aws:bedrock:automated-reasoning-policy`
+ **Valore: ** l'Amazon Resource Name (ARN) della tua policy di ragionamento automatico