Migliorare la precisione aggiungendo controlli del ragionamento automatico in Guardrail per Amazon Bedrock
I controlli del ragionamento automatico in Guardrail per Amazon Bedrock verificano matematicamente i contenuti in linguaggio naturale rispetto alle policy definite, garantendo la massima conformità con i guardrail. Tali controlli possono contribuire a bloccare sistematicamente i contenuti dannosi o non conformi prima di essere distribuiti agli utenti. A differenza degli approcci basati sulla corrispondenza dei modelli, il ragionamento automatico offre una maggiore precisione con un minor numero di falsi positivi, in particolare per requisiti di policy complesse. Per i clienti che danno priorità alla precisione, le regole delle policy possono essere personalizzate per migliorare l’efficacia del guardrail tramite istruzioni logiche chiare.
Una sfida fondamentale dei modelli linguistici di grandi dimensioni (LLM) è quella di garantire la precisione delle risposte. Senza convalida, i modelli LLM a volte possono produrre allucinazioni o informazioni imprecise che minano la fiducia.
I controlli del ragionamento automatico in Guardrail per Amazon Bedrock risolvono questo problema utilizzando tecniche matematiche per:
-
Rilevare le allucinazioni nella risposta del modello LLM
-
Evidenziare ipotesi non dichiarate
-
Fornire spiegazioni sul motivo per cui le affermazioni accurate sono corrette
Questa funzionalità è particolarmente utile quando è necessario dimostrare la fondatezza fattuale della risposta di un modello LLM nei casi seguenti:
-
Settori regolamentati come l’assistenza sanitaria e le risorse umane
-
Applicazioni con regole complesse (approvazioni di mutui, leggi urbanistiche)
-
Scenari di conformità che richiedono risposte IA verificabili
In Guardrail per Amazon Bedrock, i controlli del ragionamento automatico non proteggono dagli attacchi di iniezione di prompt, ma convalidano esattamente ciò che ricevono: se come input vengono forniti contenuti dannosi o manipolati, la convalida viene eseguita su quel contenuto così com’è, secondo il principio GIGO (Garbage In, Garbage Out). Per rilevare e bloccare gli attacchi di iniezione di prompt, utilizza Filtri dei contenuti in combinazione con i controlli del ragionamento automatico.
Il ragionamento automatico analizza e rileva solo il testo pertinente alla policy del ragionamento stesso. Ignora il resto del contenuto e non è in grado di dire agli sviluppatori se la risposta è fuori tema o meno. Se hai bisogno di rilevare risposte fuori tema, utilizza altri componenti di guardrail, ad esempio le policy per gli argomenti.
Nota
I controlli del ragionamento automatico in Guardrail per Amazon Bedrock sono generalmente disponibili nelle Regioni degli Stati Uniti (Virginia settentrionale, Oregon e Ohio) e dell’UE (Francoforte, Parigi, Irlanda).
Nota
In Guardrail per Amazon Bedrock, i controlli del ragionamento automatico integrano altre funzionalità presenti nella soluzione, ad esempio filtri del contenuto e policy per gli argomenti. Per ulteriori informazioni, consulta Componenti di guardrail.
CloudFormation attualmente non è supportato. Il supporto per CloudFormation sarà presto disponibile.
I controlli del ragionamento automatico in Guardrail per Amazon Bedrock attualmente supportano solo l’inglese (Stati Uniti).
I controlli del ragionamento automatico in Guardrail per Amazon Bedrock non supportano le API di streaming.
Considerazioni e limitazioni
Prima di implementare i controlli del ragionamento automatico, tieni presente queste importanti limitazioni:
-
Complessità dei documenti: i documenti di origine devono essere ben strutturati con regole chiare e inequivocabili. I documenti molto complessi con condizioni annidate o affermazioni contraddittorie potrebbero non essere estratti in modo chiaro nella logica formale.
-
Tempo di elaborazione: la convalida del ragionamento automatico aggiunge latenza alle risposte dell’applicazione. Pianifica tempi di elaborazione aggiuntivi, in particolare per policy complesse con molte regole.
-
Ambito della policy: ogni policy deve concentrarsi su un dominio specifico (ad esempio risorse umane, finanze, ufficio legale) anziché cercare di coprire in un’unica policy più aree non correlate.
-
Limiti alle variabili: le policy con un numero eccessivo di variabili o interazioni tra regole molto complesse possono raggiungere i limiti di elaborazione o restituire risultati di tipo TOO_COMPLEX.
-
Dipendenza dal linguaggio naturale: la precisione della convalida dipende in larga misura dalla capacità di tradurre il linguaggio naturale dei prompt degli utenti e delle risposte dei modelli nelle variabili logiche formali della policy.
Best practice
Segui queste best practice per ottimizzare l’efficacia delle policy di ragionamento automatico:
-
Inizia in modo semplice: inizia con una policy mirata che copra le regole di base, quindi aggiungi gradualmente complessità. Esegui test approfonditi a ogni fase.
-
Scrivi descrizioni complete delle variabili: includi il modo in cui gli utenti potrebbero fare riferimento naturalmente ai concetti, non solo definizioni tecniche del documento di origine.
-
Testa i casi limite: crea test mirati in modo specifico alle condizioni limite, alle eccezioni e agli scenari insoliti che gli utenti potrebbero incontrare.
-
Monitora le soglie di attendibilità: inizia con soglie di attendibilità più elevate (0,8-0,9) e regolale in base alla tolleranza per i falsi positivi rispetto ai falsi negativi.
-
Esegui una manutenzione regolare delle policy: rivedi e aggiorna le policy man mano che le regole aziendali cambiano o quando identifichi lacune tramite test e uso in produzione.
-
Documenta le tue annotazioni: tieni traccia delle modifiche alle policy e dei motivi che le hanno causate per riferimenti futuri e condivisione delle conoscenze del team.
Prezzi
In Guardrail per Amazon Bedrock i controlli del ragionamento automatico vengono addebitati in base al numero di richieste di convalida elaborate. Per informazioni sui prezzi correnti, consulta la pagina Prezzi di Amazon Bedrock
Vengono addebitati costi per ogni richiesta di convalida, indipendentemente dal risultato (ad esempio VALID, INVALID, TRANSLATION_AMBIGUOUS). Per ottimizzare i costi:
-
Usa soglie di attendibilità appropriate per bilanciare la precisione con i requisiti di elaborazione
-
Prendi in considerazione la possibilità di memorizzare nella cache i risultati di convalida per query identiche o simili, se appropriato per il tuo caso d’uso
-
Monitora i modelli di utilizzo e modifica le policy per ridurre le richieste di convalida non necessarie
Inferenza tra Regioni per le operazioni delle policy
Il ragionamento automatico utilizza l’inferenza tra Regioni per ottimizzare le prestazioni e la disponibilità delle operazioni di creazione e test delle policy. Operazioni API specifiche distribuiscono automaticamente l’elaborazione tra le Regioni AWS all’interno dei confini geografici per garantire una fornitura di servizi affidabile.
Le seguenti operazioni dell’API di ragionamento automatico utilizzano l’inferenza tra Regioni:
-
StartAutomatedReasoningPolicyBuildWorkflow: invocata durante la creazione e la compilazione delle policy dai documenti di origine -
StartAutomatedReasoningPolicyTestWorkflow: invocata durante le procedure di convalida e test delle policy
Queste operazioni invocano modelli linguistici di grandi dimensioni per estrarre regole logiche formali dai documenti di origine e tradurre i costrutti del linguaggio naturale in rappresentazioni logiche strutturate. Per garantire prestazioni e disponibilità ottimali, l’elaborazione delle richieste viene distribuita secondo il seguente routing geografico:
-
Regioni degli Stati Uniti: le richieste API provenienti da Stati Uniti orientali (Virginia settentrionale), Stati Uniti occidentali (Oregon) o Stati Uniti orientali (Ohio) possono essere elaborate in qualsiasi Regione degli Stati Uniti supportata.
-
Regioni dell’Unione Europea: le richieste API provenienti dall’UE (Francoforte), dall’UE (Parigi) o dall’UE (Irlanda) possono essere elaborate in qualsiasi Regione dell’UE supportata.
Importante
I dati dei clienti rimangono entro il confine geografico di origine (Stati Uniti o Unione Europea) e vengono elaborati in conformità agli impegni di residenza dei dati di AWS. L’inferenza tra Regioni indirizza le richieste esclusivamente all’interno della stessa Regione geografica per ottimizzare le prestazioni e la disponibilità del servizio.
L’inferenza tra Regioni opera in modo trasparente senza richiedere alcuna configurazione da parte del cliente. La funzionalità dell’API rimane coerente indipendentemente dalla Regione specifica che elabora la richiesta.
Per utilizzare i controlli del ragionamento automatico in Guardrail per Amazon Bedrock, segui questi passaggi:
-
Carica un documento di origine che contenga le regole da applicare
-
Rivedi la policy estratta con concetti e regole identificati automaticamente
-
Verifica e perfeziona la policy per assicurarti che funzioni correttamente
-
Implementa la policy per convalidare le risposte del modello di fondazione
Il flusso di lavoro può essere visualizzato come:
Source Document → Extracted Policy → Testing → Deployment → Runtime Validation (rules) (formal logic) (verify) (activate) (check responses)
Policy
Le policy di ragionamento automatico sono alla base della convalida della precisione e contengono regole e variabili logiche estratte automaticamente dal documento di origine. Tali policy fungono da rappresentazione matematica delle regole aziendali e consentono al sistema di verificare sistematicamente se le risposte del modello di fondazione sono conformi ai vincoli definiti. Per eseguire i controlli del ragionamento automatico nell’applicazione in uso, configura il guardrail in modo da utilizzare una policy che soddisfi i requisiti di dominio e di convalida specifici.
Regole
Le regole sono la logica che il ragionamento automatico estrae dal documento di origine. Tali regole potrebbero essere scritte come istruzioni if-then. Di seguito sono elencati alcuni esempi di formato delle regole:
if <premise>, then <claim>
<premise> is true
Nota
Importante: le regole che non sono nel formato if-then possono avere conseguenze indesiderate poiché stabiliscono assiomi. Ad esempio, se una regola si limita a indicare accountBalance > 5, diventa impossibile che il saldo di un conto sia pari o inferiore a 5, indipendentemente da ciò che dice il contenuto da convalidare. La regola ha reso logicamente impossibile l’esistenza di tale condizione. Ciò potrebbe comportare risultati di convalida imprevisti in cui il contenuto viene erroneamente contrassegnato come non conforme perché contraddice l’assioma stabilito dalla regola. Per evitare questa situazione, struttura le regole come istruzioni condizionali (formato if-then) che descrivono le relazioni anziché i vincoli assoluti.
Variabili
Nella policy di ragionamento automatico, le variabili rappresentano concetti a cui possono essere assegnati valori quando si traduce il linguaggio naturale in logica formale. Le regole delle policy definiscono i vincoli sui valori validi o non validi per tali variabili.
Alle variabili sono associati un nome, un tipo e una descrizione. Ad esempio, una policy sui benefit per i dipendenti potrebbe avere una variabile con il nome “età_dipendente”, il tipo “numero intero” e la descrizione “età del dipendente in anni”. A questa variabile potrebbe essere assegnato un valore come 25 basato sul linguaggio naturale in un prompt di un’applicazione.
Ad esempio, una variabile is_full_time in una policy delle risorse umane potrebbe avere una descrizione che indichi “dipendenti che lavorano più di 20 ore a settimana”, ovvero una citazione diretta dal documento di origine. Quando si utilizza un chatbot, è più probabile che gli utenti dicano “lavoro a tempo pieno” e non “lavoro più di 20 ore a settimana”.
La precisione della traduzione dal linguaggio naturale alla logica formale dipende in larga misura dalla qualità delle descrizioni delle variabili. Sebbene il processo di ragionamento sia valido una volta completata la traduzione, descrizioni chiare e complete delle variabili assicurano che i prompt dell’utente vengano interpretati correttamente. Senza descrizioni complete delle variabili, il ragionamento automatico potrebbe restituire NO_DATA perché non è in grado di tradurre il linguaggio naturale di input nella relativa rappresentazione logica formale.
È importante che una descrizione di variabile tenga conto di scenari come questo. Una descrizione completa della variabile potrebbe indicare: “i dipendenti che lavorano più di 20 ore a settimana sono a tempo pieno. Gli utenti useranno i termini a tempo pieno per impostare questo valore su true oppure part-time per impostarlo su false”.
Tipi di variabili predefiniti
Nella tabella seguente sono indicati i tipi predefiniti di variabili che possono essere presenti nella policy.
| Tipo | Descrizione |
|---|---|
|
bool |
Le variabili booleane possono essere vere o false. Ad esempio, in una policy per il congedo, si utilizzerebbe una variabile |
|
int |
Le variabili numeriche |
|
real |
Le variabili numeriche |
|
enum |
Le variabili enum possono memorizzare un singolo valore selezionato da un insieme di opzioni fisse. Ad esempio, in una policy di congedo, è possibile utilizzare una variabile enum per memorizzare il tipo di ferie: (1) Ferie retribuite; (2) Motivi personali; (3) Congedo. Oltre ai tipi di variabili predefiniti, è inoltre possibile creare tipi enum personalizzati e definiti dall’utente che forniscono un contesto aggiuntivo. Questi tipi personalizzati consentono di definire set di valori specifici pertinenti al dominio della policy. |
Argomenti
