Orientações de segurança

Parte do que torna os modelos de linguagem grandes (LLMs) tão úteis é que eles são ferramentas criativas que podem abordar muitas tarefas de linguagem diferentes. Infelizmente, isso também significa que modelos de linguagem grandes podem gerar resultados inesperados, como textos ofensivos, insensíveis ou factualmente incorretos. Além disso, devido à incrível versatilidade desses modelos, é difícil prever exatamente quais tipos de resultados indesejados eles podem produzir. Embora a API Genmini tenha sido projetada com os princípios de IA do Google em mente, a responsabilidade é dos desenvolvedores aplicar esses modelos com responsabilidade. Para ajudar os desenvolvedores na criação de aplicativos seguros e responsáveis, a API Gemini inclui alguns filtros de conteúdo integrados, bem como configurações de segurança ajustáveis em quatro dimensões de dano. Consulte o guia de configurações de segurança para saber mais.

Este documento tem como objetivo apresentar alguns riscos de segurança que podem surgir ao usar LLMs e recomendar recomendações emergentes de design de segurança e desenvolvimento. As leis e regulamentações também podem impor restrições, mas essas considerações estão fora do escopo deste guia.

As etapas a seguir são recomendadas ao criar aplicativos com LLMs:

• os riscos de segurança do seu aplicativo
• Considerar ajustes para reduzir riscos de segurança
• Realizar testes de segurança adequados ao seu caso de uso
• Pedir feedback dos usuários e monitorar o uso

As fases de ajuste e teste precisam ser iterativas até que você atinja o desempenho adequado para seu aplicativo.

Entender os riscos de segurança do seu aplicativo

Neste contexto, segurança está sendo definida como a capacidade de um LLM de evitar causar danos aos usuários, por exemplo, gerando linguagem ou conteúdo tóxico que promova estereótipos. Os modelos disponíveis por meio da API Gemini foram projetados com os princípios de IA do Google em mente, e o uso deles está sujeito à Política de uso proibido da IA generativa. A API fornece filtros de segurança integrados para ajudar a resolver alguns problemas comuns do modelo de linguagem, como linguagem tóxica e discurso de ódio, além do esforço para incluir e evitar estereótipos. No entanto, cada aplicativo pode apresentar um conjunto diferente de riscos para os usuários. Portanto, como proprietário do aplicativo, você é responsável por conhecer os usuários e os possíveis danos que seu aplicativo pode causar, além de garantir que seu aplicativo use os LLMs com segurança e responsabilidade.

Como parte dessa avaliação, considere a probabilidade de ocorrência de um dano e determine a gravidade e as etapas de mitigação. Por exemplo, um app que gera artigos baseados em eventos factuais precisaria ter mais cuidado para evitar a desinformação em comparação a um app que gera histórias fictícias para entretenimento. Uma boa maneira de começar a explorar possíveis riscos de segurança é pesquisar seus usuários finais e outras pessoas que possam ser afetadas pelos resultados do seu aplicativo. Isso pode assumir muitas formas, incluindo pesquisa de estudos de ponta no domínio do app, observação de como as pessoas estão usando apps semelhantes, realização de estudo com usuários, pesquisa ou realização de entrevistas informais com usuários em potencial.

Faça ajustes para evitar riscos de segurança.

Agora que você entende os riscos, pode decidir como minimizá-los. Determinar quais riscos priorizar e o quanto você precisa fazer para tentar evitá-los é uma decisão crítica, semelhante à triagem de bugs em um projeto de software. Depois de determinar as prioridades, comece a pensar sobre os tipos de mitigações que seriam mais apropriadas. Muitas vezes, mudanças simples podem fazer a diferença e reduzir riscos.

Por exemplo, ao projetar um aplicativo, considere:

• Ajuste a saída do modelo para refletir melhor o que é aceitável no contexto do aplicativo. O ajuste pode tornar a saída do modelo mais previsível e consistente e, portanto, pode ajudar a reduzir certos riscos.
• Fornecer um método de entrada que cria saídas mais seguras. A entrada exata que você fornece a um LLM pode fazer diferença na qualidade da saída. Testar comandos de entrada para descobrir o que funciona de forma mais segura no seu caso de uso vale o esforço, porque você pode fornecer uma UX que facilita isso. Por exemplo, você pode restringir os usuários para escolherem apenas em uma lista suspensa de comandos de entrada ou oferecer sugestões de pop-up com frases descritivas que foram encontradas de forma segura no contexto do seu aplicativo.

• Bloquear entradas não seguras e filtrar saídas antes que sejam exibidas ao usuário. Em situações simples, as listas de bloqueio podem ser usadas para identificar e bloquear palavras ou frases não seguras em comandos ou respostas, além de exigir que revisores humanos mudem ou bloqueiem manualmente esse conteúdo.

• Uso de classificadores treinados para rotular cada comando com possíveis danos ou indicadores maliciosos. Diferentes estratégias podem ser empregadas para lidar com a solicitação com base no tipo de dano detectado. Por exemplo, se a entrada for explicitamente adversária ou abusiva por natureza, ela poderá ser bloqueada e gerar uma resposta prescrita.

  Dica avançada

  • Se os sinais determinarem que a saída é prejudicial, o aplicativo poderá empregar as seguintes opções:
    • Envie uma mensagem de erro ou uma saída roteirizada.
    • Tente executar o comando novamente, caso uma saída segura alternativa seja gerada, já que o mesmo comando às vezes gera saídas diferentes.

• Implementar proteções contra o uso indevido deliberado, como atribuir um ID exclusivo a cada usuário e impor um limite ao volume de consultas de usuários que podem ser enviadas em um determinado período. Outra proteção é se proteger contra possíveis injeções de solicitações. Assim como a injeção de SQL, a injeção de comandos é uma maneira de usuários mal-intencionados criarem um comando de entrada que manipula a saída do modelo. Isso pode ser feito, por exemplo, enviando um comando de entrada que instrui o modelo a ignorar exemplos anteriores. Consulte a Política de uso proibido da IA generativa para detalhes sobre o uso indevido deliberado.

• Ajustar a funcionalidade para algo que seja de risco inerentemente menor. Tarefas com escopo mais restrito (por exemplo, extração de palavras-chave de trechos de texto) ou que têm maior supervisão humana (por exemplo, geração de conteúdo de formato curto para revisão humana) geralmente apresentam um risco menor. Por exemplo, em vez de criar um aplicativo para escrever uma resposta por e-mail do zero, você pode limitá-lo a um contorno ou sugerir frases alternativas.

Realize testes de segurança de acordo com seu caso de uso.

Os testes são uma parte fundamental da criação de aplicativos robustos e seguros, mas a extensão, o escopo e as estratégias dos testes podem variar. Por exemplo, é provável que um gerador de haicai por diversão também apresente riscos menos graves do que um aplicativo projetado para uso de escritórios de advocacia para resumir documentos legais e ajudar a redigir contratos. No entanto, o gerador de haicais pode ser usado por uma variedade maior de usuários, o que significa que o potencial de tentativas adversárias ou até mesmo entradas prejudiciais não intencionais pode ser maior. O contexto da implementação também é importante. Por exemplo, um aplicativo com saídas que são analisadas por especialistas humanos antes de qualquer ação ser tomada pode ser considerado menos propenso a produzir saídas prejudiciais do que um aplicativo idêntico sem supervisão.

Não é incomum passar por várias iterações de alterações e testes antes de ter certeza de que está pronto para o lançamento, mesmo para aplicativos de risco relativamente baixo. Dois tipos de teste são particularmente úteis para aplicativos de IA:

• O comparativo de segurança envolve a criação de métricas de segurança que reflitam as maneiras como o aplicativo pode não ser seguro no contexto de como ele provavelmente será usado. Em seguida, é necessário testar o desempenho do aplicativo nas métricas usando conjuntos de dados de avaliação. É uma prática recomendada pensar nos níveis mínimos aceitáveis de métricas de segurança antes do teste para que 1) você possa avaliar os resultados do teste em relação a essas expectativas e 2) possa coletar o conjunto de dados de avaliação com base nos testes que avaliam as métricas mais importantes para você.

  Dicas avançadas

  • Cuidado para não depender demais de abordagens prontas para uso, porque é provável que você precise criar seus próprios conjuntos de dados de teste usando avaliadores humanos para se adaptar totalmente ao contexto do aplicativo.
  • Se você tiver mais de uma métrica, precisará decidir como será o equilíbrio se a mudança resultar em melhorias em uma métrica em detrimento de outra. Assim como em outras engenharia de desempenho, convém se concentrar no desempenho do pior caso em todo o conjunto de avaliação em vez de no desempenho médio.

• O teste adversário envolve tentar corromper o aplicativo de maneira proativa. O objetivo é identificar pontos fracos para que você possa tomar medidas para resolvê-los conforme apropriado. O teste adversário pode exigir tempo/esforço significativo de avaliadores com experiência no seu aplicativo. No entanto, quanto mais você fizer, maior será a chance de detectar problemas, especialmente aqueles que ocorrem raramente ou apenas depois de execuções repetidas do aplicativo.

  • O teste adversário é um método de avaliação sistemática de um modelo de ML com a intenção de aprender como ele se comporta quando recebe entradas maliciosas ou prejudiciais:
    • Uma entrada pode ser maliciosa quando é claramente projetada para produzir uma saída insegura ou prejudicial, como pedir a um modelo de geração de texto para gerar um discurso de ódio sobre uma determinada religião.
    • Uma entrada é inadvertidamente prejudicial quando ela pode ser inofensiva, mas produz saídas prejudiciais, por exemplo, pedir a um modelo de geração de texto para descrever uma pessoa de uma determinada etnia e receber uma saída racista.
  • O que distingue um teste adversário de uma avaliação padrão é a composição dos dados usados para testes. Para testes de adversários, selecione os dados de teste com maior probabilidade de gerar resultados problemáticos do modelo. Isso significa sondar o comportamento do modelo em busca de todos os tipos de dano possíveis, incluindo exemplos raros ou incomuns e casos extremos relevantes para as políticas de segurança. Também é preciso incluir diversidade nas diferentes dimensões de uma frase, como estrutura, significado e comprimento. Consulte as práticas de IA responsável do Google em imparcialidade para mais detalhes sobre o que considerar ao criar um conjunto de dados de teste.

    Dicas avançadas

    • Use testes automatizados em vez do método tradicional de recrutar pessoas em "equipes vermelhas" para tentar corromper seu aplicativo. Em testes automatizados, a "equipe vermelha" é outro modelo de linguagem que encontra textos de entrada que geram saídas prejudiciais do modelo que está sendo testado.

Monitorar problemas

Não importa o quanto você teste e mitigue, nunca é possível garantir perfeição. Portanto, planeje com antecedência como identificar e lidar com os problemas que surgirem. Abordagens comuns incluem configurar um canal monitorado para que os usuários compartilhem feedback (por exemplo, avaliações de marcações "Gostei" ou "Não gostei") e realizar um estudo com usuários para solicitar feedback de uma mistura diversificada de usuários de maneira proativa. Isso é especialmente valioso se os padrões de uso forem diferentes às expectativas.

Próximas etapas

• Consulte o guia de configurações de segurança para saber mais sobre as configurações de segurança ajustáveis disponíveis por meio da API Gemini.
• Consulte a introdução à criação de comandos para começar a escrever seus primeiros comandos.