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à.
Migliora la precisione aggiungendo controlli di ragionamento automatizzato in Amazon Bedrock Guardrails
I controlli di ragionamento automatizzato in Amazon Bedrock Guardrails verificano matematicamente i contenuti in linguaggio naturale rispetto alle politiche definite, garantendo la massima conformità con i guardrail. Questi controlli possono aiutarti a bloccare sistematicamente i contenuti dannosi o non conformi prima che raggiungano gli utenti. A differenza degli approcci di pattern matching, Automated Reasoning offre una maggiore precisione con un minor numero di falsi positivi, in particolare per requisiti politici complessi. Per i clienti che danno priorità alla precisione, le regole delle policy possono essere personalizzate per migliorare l'efficacia del guardrail attraverso istruzioni logiche chiare.
Una sfida fondamentale dei modelli linguistici di grandi dimensioni (LLMs) è garantire l'accuratezza delle risposte. Senza convalida, a volte LLMs può produrre allucinazioni o informazioni imprecise che minano la fiducia.
I controlli di ragionamento automatizzati in Amazon Bedrock Guardrails risolvono questo problema utilizzando tecniche matematiche per:
-
Rileva le allucinazioni nelle risposte LLM
-
Evidenzia ipotesi non dichiarate
-
Fornisci spiegazioni sul motivo per cui le affermazioni accurate sono corrette
Questa funzionalità è particolarmente utile quando è necessario dimostrare la base fattuale della risposta di un LLM in:
-
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
I controlli di ragionamento automatizzati in Amazon Bedrock Guardrails non proteggono dagli attacchi di pronta iniezione. Questi controlli convalidano esattamente ciò che invii loro: se come input vengono forniti contenuti dannosi o manipolati, la convalida verrà eseguita su quel contenuto così com'è (immondizia in entrata, immondizia in uscita). Per rilevare e bloccare gli attacchi di iniezione rapida, utilizza i filtri di contenuto in combinazione con i controlli di ragionamento automatico.
Il ragionamento automatico analizza e rileva solo il testo pertinente alla politica di ragionamento automatico. Ignorerà il resto del contenuto e non potrà dire agli sviluppatori se la risposta è fuori tema o meno. Se hai bisogno di rilevare risposte fuori tema, utilizza altri componenti di guardrail come le politiche tematiche.
Nota
I controlli di ragionamento automatizzati in Amazon Bedrock Guardrails sono generalmente disponibili nelle regioni degli Stati Uniti (Virginia settentrionale, Oregon e Ohio) e dell'UE (Francoforte, Parigi, Irlanda).
Nota
I controlli di ragionamento automatizzati in Amazon Bedrock Guardrails integrano altre funzionalità di Amazon Bedrock Guardrails come filtri dei contenuti e policy tematiche. Per ulteriori informazioni, consulta i componenti di Guardrail.
CloudFormation al momento non è supportato. CloudFormation il supporto arriverà presto.
I controlli di ragionamento automatizzato in Amazon Bedrock Guardrails attualmente supportano solo l'inglese (Stati Uniti).
I controlli di ragionamento automatizzati in Amazon Bedrock Guardrails non supportano lo streaming. APIs
Considerazioni e limitazioni
Prima di implementare i controlli di 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 rientrare 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 politica: ogni politica dovrebbe concentrarsi su un dominio specifico (ad esempio, risorse umane, finanze, diritto) anziché cercare di coprire più aree non correlate in un'unica politica.
-
Limiti variabili: le politiche con un numero eccessivo di variabili o interazioni tra regole eccessivamente complesse possono raggiungere i limiti di elaborazione o restituire risultati TOO_COMPLEX.
-
Dipendenza dal linguaggio naturale: l'accuratezza della convalida dipende in larga misura dalla capacità di tradurre il linguaggio naturale nei prompt degli utenti e nelle risposte dei modelli nelle variabili logiche formali della policy.
Best practice
Segui queste best practice per massimizzare l'efficacia delle tue politiche di ragionamento automatizzato:
-
Inizia in modo semplice: inizia con una politica mirata che copra le regole di base, quindi aggiungi gradualmente complessità. Esegui test approfonditi in ogni fase.
-
Scrivi descrizioni complete delle variabili: includi il modo in cui gli utenti potrebbero naturalmente fare riferimento ai concetti, non solo alle definizioni tecniche del documento di origine.
-
Casi limite di test: create test mirati specificamente alle condizioni limite, alle eccezioni e agli scenari insoliti che gli utenti potrebbero incontrare.
-
Monitora le soglie di confidenza: inizia con soglie di confidenza più elevate (0,8-0,9) e aggiusta in base alla tua tolleranza per i falsi positivi rispetto ai falsi negativi.
-
Manutenzione regolare delle politiche: rivedi e aggiorna le politiche man mano che le regole aziendali cambiano o quando identifichi le lacune attraverso test e uso in produzione.
-
Documenta le tue annotazioni: tieni traccia delle modifiche alle politiche e dei motivi alla base di esse per riferimenti futuri e condivisione delle conoscenze del team.
Prezzi
I controlli di ragionamento automatizzato in Amazon Bedrock Guardrails vengono addebitati in base al numero di richieste di convalida elaborate. Per informazioni aggiornate sui prezzi, consulta la pagina dei 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:
-
Utilizza soglie di confidenza appropriate per bilanciare l'accuratezza 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 politiche per ridurre le richieste di convalida non necessarie
Inferenza interregionale per le operazioni politiche
Il ragionamento automatizzato utilizza l'inferenza interregionale per ottimizzare le prestazioni e la disponibilità delle operazioni di creazione e test delle politiche. 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- Richiamato durante la creazione e la compilazione delle politiche dai documenti di origine -
StartAutomatedReasoningPolicyTestWorkflow- Richiamato durante le procedure di convalida e test delle politiche
Queste operazioni richiamano 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 d'America o Unione Europea) e vengono elaborati in conformità agli impegni di residenza dei dati di AWS. L'inferenza interregionale indirizza le richieste esclusivamente all'interno della stessa regione geografica per ottimizzare le prestazioni e la disponibilità del servizio.
L'inferenza tra regioni funziona in modo trasparente senza richiedere la configurazione del cliente. La funzionalità dell'API rimane coerente indipendentemente dalla regione specifica che elabora la richiesta.
Per utilizzare i controlli di ragionamento automatico in Amazon Bedrock Guardrails, segui questi passaggi:
-
Carica un documento sorgente che contenga le regole che desideri applicare
-
Rivedi la politica estratta con concetti e regole identificati automaticamente
-
Verifica e perfeziona la politica per assicurarti che funzioni correttamente
-
Implementa la policy per convalidare le risposte del tuo modello di base
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 politiche di ragionamento automatico sono alla base della convalida dell'accuratezza e contengono regole e variabili logiche che vengono estratte automaticamente dal documento di origine. Queste policy fungono da rappresentazione matematica delle regole aziendali e consentono al sistema di verificare sistematicamente se le risposte del modello di base sono conformi ai vincoli definiti. Per eseguire i controlli di ragionamento automatico nella vostra applicazione, configurate il guardrail in modo da utilizzare una policy che soddisfi i requisiti di dominio e di convalida specifici.
Regolamento
Le regole sono la logica che Automated Reasoning estrae dal documento di origine. Queste potrebbero essere scritte come istruzioni if-then. Ecco alcuni esempi del 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 stabilendo assiomi sul mondo. Ad esempio, se una regola si limita a indicareaccountBalance > 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 portare a risultati di convalida imprevisti in cui il contenuto viene erroneamente contrassegnato come non conforme perché contraddice l'assioma stabilito dalla regola. Per evitare ciò, struttura le regole come istruzioni condizionali (formato if-then) che descrivono le relazioni anziché i vincoli assoluti.
Variables
Le variabili rappresentano concetti nella politica di ragionamento automatico 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 queste variabili.
Le variabili hanno un nome, un tipo e una descrizione. Ad esempio, una politica sui benefit per i dipendenti potrebbe avere una variabile con il nome «employee_age», il tipo «numero intero» e la descrizione «L'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 is_full_time variabile in una politica delle risorse umane potrebbe avere una descrizione che indichi «Dipendenti che lavorano più di 20 ore a settimana», che è 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».
L'accuratezza 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 le istruzioni dell'utente vengano interpretate correttamente. Senza descrizioni complete delle variabili, Automated Reasoning potrebbe tornare NO_DATA perché non è in grado di tradurre il linguaggio naturale di input nella sua rappresentazione logica formale.
È importante che una descrizione 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 diranno a tempo pieno di impostare questo valore su true, oppure a tempo parziale di impostarlo su false».
Tipi di variabili predefiniti
La tabella seguente descrive i tipi predefiniti di variabili che la politica può avere.
| Tipo | Descrizione |
|---|---|
|
bool |
Le variabili booleane possono essere vere o false. Ad esempio, in una politica di congedo, si utilizzerebbe una |
|
int |
|
|
real |
|
|
enum |
Le variabili Enum possono memorizzare un singolo valore selezionato da un insieme di opzioni fisse. Ad esempio, in una politica di congedo, è possibile utilizzare una variabile enum per memorizzare il tipo di ferie: (1) Ferie retribuite; (2) Tempo personale; (3) Congedo È inoltre possibile creare tipi enum personalizzati e definiti dall'utente che forniscono un contesto aggiuntivo oltre ai tipi di variabili predefiniti. Questi tipi personalizzati consentono di definire set specifici di valori pertinenti al dominio della politica. |
Argomenti
