Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Conceptos: mensajes, tipos de bloques de contenido y comprobaciones
Los siguientes conceptos describen la estructura de las solicitudes a la InvokeGuardrailChecks API.
Mensajes
Un mensaje es la unidad básica de contenido que se envía para su evaluación. Cada mensaje tiene dos campos: una función que identifica quién produjo el contenido y una matriz de contenido que contiene el texto real en forma de uno o más bloques de contenido mecanografiados.
{ "role": "user", "content": [{ "text": "Hello world" }] }
Esto refleja la estructura de bloques de rol más contenido utilizada en otras partes de Amazon Bedrock, por lo que la conversación que ya se ha creado para un modelo se puede transmitir con poca o ninguna remodelación. InvokeGuardrailChecks El messages campo de una solicitud es una matriz, por lo que puede enviar un único mensaje o una secuencia que represente un intercambio de varios turnos (por ejemplo, una instrucción del sistema seguida de un turno para el usuario). Los mensajes se evalúan en el orden en que se proporcionan y su posición es importante: algunos resultados se refieren a un mensaje por su base cero messageIndex y a un bloque dentro de ese mensaje por su valor contentIndex (consulte los resultados de información confidencial).
El rol etiqueta el origen del contenido. Se admiten los siguientes roles:
-
system— Instrucciones que configuran el comportamiento del modelo. -
user— Entrada del usuario final. -
assistant— Salida producida por el modelo.
Tipos de bloques de contenido
El content campo es una matriz de bloques escritos en lugar de una cadena simple. Un bloque escrito es un objeto pequeño cuya clave indica su tipo. Este diseño permite que el formato del mensaje incluya otros tipos de contenido (como imágenes o documentos) en el futuro sin cambiar la forma general del mensaje. Actualmente, el único tipo de bloque admitido estext, cuyo valor es una cadena simple:
{ "text": "Hello world" }
Un mensaje puede contener como máximo diez bloques de contenido. Un bloque de contenido puede contener como máximo un text bloque. Como text es el único tipo compatible en la actualidad, esto significa, en efecto, un bloque de texto por bloque de contenido. Para evaluar varios fragmentos de texto distintos dentro de un rol, envíelos como bloques de contenido separados en la content matriz. Para evaluar varios fragmentos de texto distintos en varios roles, envíelos como mensajes separados en la messages matriz.
Comprueba
El término controles es intercambiable con el término salvaguardas que ofrece Amazon Bedrock Guardrails. El checks objeto es un objeto de configuración con un campo opcional por tipo de comprobación, y usted incluye solo las comprobaciones que desee ejecutar. No se establece un enable/disable indicador independiente: una comprobación se ejecuta si su campo está presente y solo si está presente, y las comprobaciones omitidas no producen ningún resultado ni uso. Debe establecer al menos un campo de verificación.
"checks": { "contentFilter": { ... }, "promptAttack": { ... }, "sensitiveInformation": { ... } }
Como la configuración está en línea para cada solicitud, puede variar su postura de seguridad de una llamada a otra sin tener que administrar un recurso de barandilla almacenado. Los distintos pasos de un bucle de agentes pueden solicitar distintas combinaciones de comprobaciones con el mismo mensaje o con mensajes diferentes.
Cada cheque tiene su propia forma de configuración. El nombre del campo selecciona la marca; el objeto que contiene muestra lo que busca la marca:
-
contentFilter— Toma unacategorieslista (odio, insultos, relaciones sexuales, violencia, mala conducta). -
promptAttack— Toma unacategorieslista (JAILBREAK, PROMPT_INJECTION, PROMPT_LEAKAGE). -
sensitiveInformation— Toma unaentitieslista (31 entidades PII compatibles).
La solicitud y la respuesta son simétricas: las claves que configuras checks son las mismas que aparecen en results y. usage Si solicitas contentFilter ysensitiveInformation, solo esas dos aparecen en la respuesta, promptAttack está ausente porque nunca se ejecutó. Esto facilita la asignación de un hallazgo al cheque que lo produjo.
Detect-only en todas las comprobaciones: no hay ninguna casilla que bloquee, oculte ni reescriba el contenido. Cada una de ellas arroja puntuaciones (una severityScore por el filtro de contenido y un ataque rápido, y confidenceScore otra por la ubicación para la información confidencial), y tú decides cómo actúa tu aplicación en función de ellas en función de tus requisitos específicos.