View a markdown version of this page

Concetti: messaggi, tipi di blocchi di contenuto e controlli - Amazon Bedrock

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à.

Concetti: messaggi, tipi di blocchi di contenuto e controlli

I seguenti concetti descrivono la struttura delle richieste all'InvokeGuardrailChecksAPI.

Messaggi

Un messaggio è l'unità di contenuto di base che invii per la valutazione. Ogni messaggio ha due campi: un ruolo che identifica chi ha prodotto il contenuto e un array di contenuti che contiene il testo effettivo come uno o più blocchi di contenuto digitati.

{ "role": "user", "content": [{ "text": "Hello world" }] }

Ciò rispecchia la struttura role-plus-content-blocks utilizzata altrove in Amazon Bedrock, quindi la conversazione che hai già creato per un modello può essere trasmessa senza modifiche minime o nulle. InvokeGuardrailChecks Il messages campo di una richiesta è un array, quindi puoi inviare un singolo messaggio o una sequenza che rappresenta uno scambio a più turni (ad esempio, un'istruzione di sistema seguita da un turno dell'utente). I messaggi vengono valutati nell'ordine in cui vengono forniti e la loro posizione è importante: alcuni risultati rimandano a un messaggio in base a zero e a un blocco all'interno del messaggio in base messageIndex alla sua contentIndex (vedi i risultati relativi alle informazioni sensibili).

Il ruolo indica l'origine del contenuto. Sono supportati i seguenti ruoli:

  • system— Istruzioni che configurano il comportamento del modello.

  • user— Input da parte dell'utente finale.

  • assistant— Output prodotto dal modello.

Tipi di blocchi di contenuto

Il content campo è una matrice di blocchi digitati anziché una semplice stringa. Un blocco digitato è un piccolo oggetto la cui chiave indica il tipo. Questo design consente al formato del messaggio di trasportare altri tipi di contenuti (come immagini o documenti) in futuro senza modificare la forma generale del messaggio. Attualmente, l'unico tipo di blocco supportato ètext, il cui valore è una semplice stringa:

{ "text": "Hello world" }

Un messaggio può contenere al massimo dieci blocchi di contenuto. Un blocco di contenuto può contenere al massimo un text blocco. Poiché text è l'unico tipo supportato oggi, ciò significa effettivamente un blocco di testo per blocco di contenuto. Per valutare più parti di testo distinte all'interno di un ruolo, inviale come blocchi di contenuto separati nell'contentarray. Per valutare diverse parti di testo distinte in più ruoli, inviale come messaggi separati nell'messagesarray.

Controlli

Il termine check è intercambiabile con il termine Safeguards offerto da Amazon Bedrock Guardrails. L'checksoggetto è un oggetto di configurazione con un campo opzionale per tipo di controllo e includi solo i controlli che desideri eseguire. Non impostate un enable/disable flag separato: un controllo viene eseguito se e solo se il relativo campo è presente e i controlli omessi non producono alcun risultato né alcun utilizzo. È necessario impostare almeno un campo di controllo.

"checks": { "contentFilter": { ... }, "promptAttack": { ... }, "sensitiveInformation": { ... } }

Poiché la configurazione è in linea per richiesta, è possibile variare il livello di sicurezza da una chiamata all'altra senza gestire una risorsa guardrail memorizzata. Fasi diverse in un ciclo di agenti possono richiedere diverse combinazioni di controlli per lo stesso messaggio o per messaggi diversi.

Ogni controllo ha una propria forma di configurazione. Il nome del campo seleziona il controllo; l'oggetto al suo interno elenca ciò che il controllo cerca:

  • contentFilter— Richiede un categories elenco (ODIO, INSULTI, SESSUALI, VIOLENZA, CATTIVA CONDOTTA).

  • promptAttack— Richiede un categories elenco (JAILBREAK, PROMPT_INJECTION, PROMPT_LEAKAGE).

  • sensitiveInformation— Richiede un elenco (31 entità PII supportate). entities

La richiesta e la risposta sono simmetriche: le chiavi impostate in checks sono le stesse chiavi che ritornano in e. results usage Se richiedi contentFilter esensitiveInformation, nella risposta compaiono solo quelle due; promptAttack è assente perché non è mai stata eseguita. Ciò semplifica la mappatura di un risultato al controllo che lo ha prodotto.

Detect-only in ogni controllo: nessun controllo blocca, maschera o riscrive il contenuto. Ciascuno restituisce punteggi (uno severityScore per il filtro dei contenuti e l'attacco rapido, un confidenceScore altro per gli offset di posizione per le informazioni sensibili) e sei tu a decidere come agire l'applicazione in base a requisiti specifici.