View a markdown version of this page

Conceitos: mensagens, tipos de blocos de conteúdo e verificações - Amazon Bedrock

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Conceitos: mensagens, tipos de blocos de conteúdo e verificações

Os conceitos a seguir descrevem a estrutura das solicitações à InvokeGuardrailChecks API.

Mensagens

Uma mensagem é a unidade básica do conteúdo que você envia para avaliação. Cada mensagem tem dois campos: uma função que identifica quem produziu o conteúdo e uma matriz de conteúdo que contém o texto real como um ou mais blocos de conteúdo digitados.

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

Isso reflete a estrutura role-plus-content-blocks usada em outros lugares no Amazon Bedrock, de forma que a conversa que você já criou para um modelo possa ser transmitida com pouca ou nenhuma remodelação. InvokeGuardrailChecks O messages campo de uma solicitação é uma matriz, então você pode enviar uma única mensagem ou uma sequência que represente uma troca de vários turnos (por exemplo, uma instrução do sistema seguida por um turno do usuário). As mensagens são avaliadas na ordem em que você as fornece, e suas posições são importantes: alguns resultados se referem a uma mensagem por sua base zero messageIndex e a um bloco dentro dessa mensagem por sua contentIndex (veja os resultados de informações confidenciais).

A função rotula a origem do conteúdo. As seguintes funções são suportadas:

  • system— Instruções que configuram o comportamento do modelo.

  • user— Entrada do usuário final.

  • assistant— Saída produzida pelo modelo.

Tipos de blocos de conteúdo

O content campo é uma matriz de blocos digitados em vez de uma string simples. Um bloco digitado é um objeto pequeno cuja chave nomeia seu tipo. Esse design permite que o formato da mensagem transmita outros tipos de conteúdo (como imagens ou documentos) no futuro sem alterar o formato geral da mensagem. Atualmente, o único tipo de bloco suportado étext, cujo valor é uma string simples:

{ "text": "Hello world" }

Uma mensagem pode conter no máximo dez blocos de conteúdo. Um bloco de conteúdo pode conter no máximo um text bloco. Como text é o único tipo compatível atualmente, isso significa efetivamente um bloco de texto por bloco de conteúdo. Para avaliar várias partes distintas de texto em uma função, envie-as como blocos de conteúdo separados na content matriz. Para avaliar várias partes distintas de texto em várias funções, envie-as como mensagens separadas na messages matriz.

Cheques

O termo cheques é intercambiável com o termo salvaguardas oferecido pelo Amazon Bedrock Guardrails. O checks objeto é um objeto de configuração com um campo opcional por tipo de verificação, e você inclui somente as verificações que deseja executar. Você não define um enable/disable sinalizador separado: uma verificação é executada se e somente se seu campo estiver presente, e as verificações omitidas não produzem nenhum resultado nem uso. Você deve definir pelo menos um campo de verificação.

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

Como a configuração é embutida por solicitação, você pode variar sua postura de segurança de chamada para chamada sem gerenciar um recurso de proteção armazenado. Etapas diferentes em um loop de agente podem solicitar combinações diferentes de verificações na mesma mensagem ou em mensagens diferentes.

Cada verificação tem seu próprio formato de configuração. O nome do campo seleciona a verificação; o objeto dentro dela lista o que essa verificação procura:

  • contentFilter— Faz uma categories lista (ÓDIO, INSULTOS, SEXO, VIOLÊNCIA, MÁ CONDUTA).

  • promptAttack— Obtém uma categories lista (JAILBREAK, PROMPT_INJECTION, PROMPT_LEAKAGE).

  • sensitiveInformation— Obtém uma entities lista (31 entidades de PII suportadas).

A solicitação e a resposta são simétricas — As teclas que você define em checks são as mesmas que retornam em results e. usage Se você solicitar contentFilter esensitiveInformation, somente esses dois aparecerão na resposta; promptAttack está ausente porque nunca foi executado. Isso facilita o mapeamento de uma descoberta até o cheque que a produziu.

Detect-only em todas as verificações — nenhuma verificação bloqueia, mascara ou reescreve o conteúdo. Cada um retorna pontuações (uma severityScore para filtro de conteúdo e ataque imediato, confidenceScore mais uma compensação de localização para informações confidenciais), e você decide como seu aplicativo age com base em requisitos específicos.