Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Concepts : messages, types de blocs de contenu et contrôles

Les concepts suivants décrivent la structure des demandes adressées à l'InvokeGuardrailChecksAPI.

Messages

Un message est l'unité de base du contenu que vous soumettez pour évaluation. Chaque message comporte deux champs : un rôle qui identifie la personne qui a produit le contenu et un tableau de contenu qui contient le texte réel sous la forme d'un ou de plusieurs blocs de contenu dactylographiés.

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

Cela reflète la structure role-plus-blocs de contenu utilisée ailleurs dans Amazon Bedrock, de sorte que la conversation que vous avez déjà développée pour un modèle peut être transmise avec peu ou pas de refonte. InvokeGuardrailChecks Le messages champ d'une demande est un tableau. Vous pouvez donc envoyer un message unique ou une séquence représentant un échange à plusieurs tours (par exemple, une instruction système suivie du tour d'un utilisateur). Les messages sont évalués dans l'ordre dans lequel vous les avez fournis, et leur position est importante : certains résultats font référence à un message par sa base zéromessageIndex, et à un bloc de ce message par sa base contentIndex (voir les résultats relatifs aux informations sensibles).

Le rôle indique l'origine du contenu. Les rôles suivants sont pris en charge :

Types de blocs de contenu

Le content champ est un tableau de blocs typés plutôt qu'une simple chaîne. Un bloc dactylographié est un petit objet dont la clé indique le type. Cette conception permet au format du message de diffuser d'autres types de contenu (tels que des images ou des documents) à l'avenir sans modifier la forme globale du message. Actuellement, le seul type de bloc pris en charge esttext, dont la valeur est une chaîne nue :

{ "text": "Hello world" }

Un message peut contenir au maximum dix blocs de contenu. Un bloc de contenu peut contenir au maximum un text bloc. Comme il text s'agit du seul type pris en charge aujourd'hui, cela signifie en fait un bloc de texte par bloc de contenu. Pour évaluer plusieurs parties de texte distinctes au sein d'un même rôle, envoyez-les sous forme de blocs de contenu distincts dans le content tableau. Pour évaluer plusieurs parties de texte distinctes correspondant à plusieurs rôles, envoyez-les sous forme de messages distincts dans le messages tableau.

Chèques

Le terme « chèques » est interchangeable avec le terme « garanties » proposé par Amazon Bedrock Guardrails. L'checksobjet est un objet de configuration avec un champ facultatif par type de contrôle, et vous n'incluez que les contrôles que vous souhaitez exécuter. Vous ne définissez pas d' enable/disable indicateur distinct : une vérification est exécutée si et seulement si son champ est présent, et les vérifications omises ne produisent aucun résultat ni aucune utilisation. Vous devez définir au moins un champ à cocher.

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

Comme la configuration est intégrée à chaque demande, vous pouvez modifier votre posture de sécurité d'un appel à l'autre sans avoir à gérer une ressource de garde-corps stockée. Les différentes étapes d'une boucle d'agent peuvent demander différentes combinaisons de vérifications par rapport à des messages identiques ou différents.

Chaque vérification possède sa propre forme de configuration. Le nom du champ sélectionne le chèque ; l'objet qu'il contient indique ce que le contrôle recherche :

La demande et la réponse sont symétriques : les clés que vous définissez sous checks sont les mêmes que celles qui se trouvent sous results etusage. Si vous demandez contentFilter etsensitiveInformation, seuls ces deux éléments apparaissent dans la réponse ; promptAttack est absent car il n'a jamais été exécuté. Cela permet de relier facilement une constatation au chèque qui l'a produite.

Detect-only à chaque vérification : aucune vérification ne bloque, ne masque ou ne réécrit le contenu. Chacun d'entre eux renvoie des scores (un severityScore pour le filtre de contenu et l'attaque rapide, un confidenceScore pour les compensations de localisation pour les informations sensibles), et vous décidez de la manière dont votre application agit en fonction de ces résultats en fonction d'exigences spécifiques.