Command R 08-2024 e os modos de segurança: que controlo oferecem e o que deve testar

O que safety_mode controla — e o que não controla

O Command R 08-2024 é uma versão do modelo da Cohere identificada pelo nome de modelo command-r-08-2024. Ao chamar os endpoints de chat da Cohere, o parâmetro safety_mode permite escolher entre modos que alteram as instruções de segurança incorporadas no pedido. Por outras palavras, é uma configuração que orienta o modelo durante a interação, não uma certificação independente do modelo nem uma garantia de que uma aplicação é segura.

Esta distinção é importante na prática. Um resultado aceitável num teste com um pedido simples descreve apenas essa combinação de modelo, endpoint, parâmetros e instruções. Por si só, não permite concluir que a aplicação irá resistir a entradas adversariais, tratar corretamente documentos não fiáveis ou bloquear todas as respostas prejudiciais. Estas propriedades exigem testes do sistema completo e controlos de produto adequados ao risco.

A documentação disponível do fornecedor não deve ser interpretada como prova de que um modo elimina todo o conteúdo problemático. O cartão do modelo fornece contexto sobre avaliações e limitações de segurança, mas não demonstra a eficácia de cada modo para command-r-08-2024. Por isso, é preferível descrever os modos como uma opção de configuração que deve ser avaliada, e não como uma defesa completa.

STRICT, CONTEXTUAL e NONE: diferenças e nomes por endpoint

Na referência do Chat V1, os valores documentados são STRICT, CONTEXTUAL e NONE; aí, safety_mode está assinalado como beta. A referência atual do Chat V2 enumera STRICT, CONTEXTUAL e OFF. Assim, NONE e OFF são nomes que aparecem em referências diferentes, não valores que se devam considerar intercambiáveis na mesma chamada: antes de configurar uma integração, é necessário confirmar a especificação do endpoint utilizado.

Historicamente, a Cohere apresentou os modos como diferentes níveis de orientação de segurança. STRICT dá prioridade a uma aplicação mais rigorosa dessas instruções; CONTEXTUAL aplica-as tendo em conta o contexto do pedido; e NONE representa a opção sem o conjunto de instruções acrescentado por esse modo. Esta descrição não significa que NONE transforme o modelo num sistema sem qualquer proteção: o anúncio do fornecedor indica que certas proteções não podem ser desativadas.

O objetivo de CONTEXTUAL é evitar que a segurança se reduza a uma resposta mecânica a palavras isoladas. No entanto, o facto de o nome sugerir uma interpretação contextual não prova que o modelo consiga sempre distinguir um pedido legítimo de um pedido prejudicial. Uma equipa deve verificar essa capacidade com exemplos do seu domínio, incluindo casos que suscitem dúvidas razoáveis.

A indicação de que o V1 está em beta é relevante para a gestão de alterações: recomenda rever a documentação e repetir os testes antes de atualizar a integração. A referência do V2 apresenta o seu próprio conjunto de valores, mas as fontes fornecidas não esclarecem suficientemente se o estado beta do V1 se mantém, nem se os detalhes de disponibilidade são idênticos em todos os canais de implementação. Não se deve transferir automaticamente o estado de um endpoint para o outro.

A limitação com tools e documents altera o que um teste demonstra

A referência do Chat V1 documenta que safety_mode não pode ser combinado com tools, tool_results e documents. A referência do Chat V2 também indica uma limitação de combinação com tools e documents. Para uma equipa que utiliza geração aumentada por recuperação (RAG) ou chamadas a ferramentas, isto representa um limite operacional: um teste isolado do modo não deve ser apresentado como prova direta do comportamento do fluxo completo.

A incompatibilidade documentada também não permite concluir que as ferramentas ou os documentos sejam inseguros, nem que o modelo não os possa utilizar em qualquer configuração. Indica que os parâmetros enumerados não podem ser combinados na chamada tal como está descrita nessas referências. A integração deve respeitar o formato aceite pelo endpoint e validar os componentes e a interação entre eles separadamente.

Uma avaliação útil separa pelo menos duas perguntas. Primeiro: como responde o modelo com safety_mode numa chamada compatível e controlada? Segundo: o que acontece na aplicação real quando são recuperados documentos, enviados resultados de ferramentas ou incorporadas instruções próprias? A resposta à primeira pergunta não substitui a resposta à segunda. Além disso, um texto recuperado pode conter instruções, informação incorreta ou material prejudicial; a aplicação deve tratá-lo como conteúdo a avaliar, e não como uma política de segurança.

As fontes fornecidas descrevem as restrições de parâmetros nas referências do Chat V1 e do Chat V2. Não especificam todas as combinações disponíveis em cada canal de implementação, nem permitem afirmar que todos os serviços compatíveis com a Cohere ofereçam capacidades idênticas. Confirme a especificação aplicável ao ambiente concreto antes de conceber o teste.

Um protocolo de avaliação reproduzível

Uma avaliação comparativa deve definir antecipadamente o resultado considerado correto para cada caso. Se a equipa alterar os critérios depois de ver as respostas, pode acabar por favorecer o modo que confirma as expectativas prévias. Mantenha um conjunto de casos com etiquetas e justificação e execute cada caso com a mesma versão do modelo, endpoint e parâmetros, exceto a variável que pretende comparar.

Inclua pedidos permitidos, mas sensíveis: por exemplo, uma explicação preventiva sobre segurança, uma consulta educativa sobre um tema de risco ou um pedido de apoio que exija um tom cuidadoso. Acrescente pedidos claramente prejudiciais segundo a política do produto e casos ambíguos em que o modelo deva pedir contexto, limitar a resposta ou recusar uma parte do pedido. Estes são exemplos para construir um conjunto de avaliação; as fontes não publicam uma bateria específica para medir os modos do Command R 08-2024.

Teste variações linguísticas e de formulação: paráfrases, erros ortográficos, expressões indiretas e alterações de idioma relevantes para o público. Não basta traduzir literalmente um único caso, porque a equivalência da intenção pode perder-se ao mudar de língua. Se o produto recebe conteúdo em vários idiomas, avalie cada um com pessoas competentes ou com critérios revistos por especialistas.

Repita os casos várias vezes. As respostas podem variar entre execuções, e uma única amostra não permite medir a consistência. Guarde as entradas exatas, o resultado esperado, a resposta completa, a decisão de avaliação e o contexto da chamada. Quando o modelo, a API ou as instruções da aplicação mudarem, volte a executar o conjunto e compare as versões.

Métricas que ajudam a interpretar os resultados

Conte as recusas corretas: casos que deviam ser recusados e receberam uma negativa ou uma resposta segura, de acordo com os critérios definidos. Conte também as recusas indevidas: pedidos permitidos que foram bloqueados ou se tornaram inutilizáveis. Uma taxa de recusa elevada não demonstra, por si só, maior segurança se for obtida recusando muitas tarefas legítimas.

Registe também as respostas inseguras: casos que deviam ser recusados ou limitados e em que o sistema forneceu conteúdo não permitido. Analise separadamente o cumprimento das instruções do produto, a consistência entre execuções e as diferenças entre modos. Se uma resposta estiver parcialmente correta, utilize categorias intermédias definidas antecipadamente em vez de a forçar a ser classificada como “aprovada” ou “recusada”.

Separe os resultados por tipo de pedido, idioma, modo e configuração. Uma média agregada pode ocultar diferenças de desempenho entre consultas sensíveis e permitidas e pedidos ambíguos. Nos fluxos com documentos ou ferramentas, registe também que conteúdo foi recuperado, que ferramenta foi chamada e que informação voltou ao modelo, respeitando sempre as regras de privacidade e retenção da organização.

As métricas são elementos de prova para uma decisão, não um certificado universal. Uma amostra pequena, um conjunto demasiado previsível ou uma política de classificação pouco precisa podem criar uma falsa impressão de fiabilidade. Indique a dimensão e a composição do conjunto, o número de repetições e as divergências entre avaliadores. Quando os resultados forem ambíguos ou tiverem consequências importantes para as pessoas, inclua uma revisão humana especializada.

Registe o ambiente e mantenha controlos externos

Para que os resultados possam ser interpretados, registe o identificador exato do modelo — incluindo command-r-08-2024 quando aplicável —, o endpoint, o valor de safety_mode e a data. Acrescente os restantes parâmetros de geração, as instruções do sistema e da aplicação, o idioma da entrada e se foram incluídos documentos, ferramentas ou resultados de ferramentas. A data e a versão da integração ajudam a detetar quando duas execuções aparentemente comparáveis não utilizaram o mesmo ambiente.

A documentação do fornecedor não responde a todas as perguntas de implementação colocadas neste guia. Em particular, não há aqui provas suficientes para confirmar se o estado beta do V1 se aplica ou não ao V2, se a limitação de combinação tem o mesmo âmbito em todos os canais ou se um protocolo pode ser reproduzido sem alterações em todos os ambientes compatíveis. Verifique esses pontos na referência atualizada do seu endpoint e na configuração real antes de interpretar os resultados.

Mantenha os seus próprios controlos, mesmo que um teste favoreça determinado modo. Estes podem incluir a definição de utilizações permitidas, controlos de acesso às ferramentas, validação de dados, limites às ações, monitorização, procedimentos de resposta a incidentes e revisão humana em decisões de elevado impacto. A escolha dos controlos depende do produto e do risco: não é possível deduzir uma configuração suficiente apenas a partir do nome do modo.

Como critério prático, escolha o modo que cumpra a política da sua aplicação com um equilíbrio aceitável entre respostas inseguras e recusas indevidas, sempre com base em testes representativos. Se o resultado depender da utilização de documentos ou ferramentas, avalie o fluxo de produção separadamente e confirme os parâmetros aceites. Repita a avaliação quando o modelo, o endpoint, as instruções ou a arquitetura mudarem. Assim, a decisão sobre o Command R 08-2024 fica associada a provas do sistema que é realmente utilizado, em vez de depender da designação de um modo.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.