Orientações de segurança

Os modelos generativos de inteligência artificial são ferramentas poderosas, mas não estão sem suas limitações. A versatilidade e aplicabilidade deles às vezes podem gerar resultados inesperados, como saídas imprecisas, tendenciosas ou ofensivas. O pós-processamento e a avaliação manual rigorosa são essenciais para limitar o risco de danos resultantes desses resultados.

Os modelos fornecidos pela API Gemini podem ser usados para uma ampla variedade de aplicativos de IA generativa e de processamento de linguagem natural (PLN). O uso dessas funções só está disponível pela API Gemini ou pelo app da Web do Google AI Studio. O uso da API Gemini também está sujeito à Política de uso proibido da IA generativa e aos Termos de Serviço da API Gemini.

Parte do que torna os modelos de linguagem grandes (LLMs) tão úteis é que eles são ferramentas criativas que podem lidar com muitas tarefas de linguagem diferentes. Infelizmente, isso também significa que modelos de linguagem grandes podem gerar saídas inesperadas, incluindo texto ofensivo, insensível ou factualmente incorreto. Além disso, a incrível versatilidade desses modelos também é o que dificulta a previsão exata dos tipos de saída indesejável que eles podem produzir. Embora a API Gemini tenha sido projetada com os princípios de IA do Google em mente, a responsabilidade é que os desenvolvedores apliquem esses modelos com responsabilidade. Para ajudar os desenvolvedores a criar aplicativos seguros e responsáveis, a API Gemini tem algumas filtros de conteúdo integradas e 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.

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

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

• Noções básicas sobre os riscos de segurança do aplicativo
• Fazer ajustes para reduzir os riscos de segurança
• Realizar testes de segurança adequados ao caso de uso
• Pedir feedback dos usuários e monitorar o uso

As fases de ajuste e teste precisam ser iterativas até alcançar o desempenho adequado para o aplicativo.

Entenda os riscos de segurança do seu aplicativo

Nesse 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 na 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 de lutar pela inclusão 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 seus usuários e os possíveis danos que ele pode causar, além de garantir que ele use LLMs com segurança e responsabilidade.

Como parte dessa avaliação, você precisa considerar a probabilidade de ocorrência de um dano e determinar a gravidade e as etapas de mitigação. Por exemplo, um app que gera artigos com base em eventos factuais precisaria ter mais cuidado para evitar a desinformação, em comparação com 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 os usuários finais e outras pessoas que podem ser afetadas pelos resultados do aplicativo. Isso pode assumir várias formas, incluindo pesquisa de estudos de última geração no domínio do app, observação de como as pessoas estão usando apps semelhantes ou realização de um 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 mitigá-los. Determinar quais riscos priorizar e quanto 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 nos tipos de mitigação mais adequados. Muitas vezes, mudanças simples podem fazer a diferença e reduzir riscos.

Por exemplo, ao projetar um aplicativo, considere:

• Ajustar a saída do modelo para refletir melhor o que é aceitável no contexto do seu aplicativo. O ajuste pode tornar a saída do modelo mais previsível e consistente e, portanto, ajudar a mitigar certos riscos.
• Disponibilizar um método de entrada que disponibiliza saídas mais seguras. A entrada exata que você dá a um LLM pode fazer diferença na qualidade da saída. Vale a pena testar comandos de entrada para descobrir o que funciona com mais segurança no seu caso de uso, já que você pode fornecer uma UX que facilita isso. Por exemplo, é possível restringir os usuários a escolher apenas em uma lista suspensa de solicitações de entrada ou oferecer sugestões pop-up com frases descritivas que você encontrou funcionam com segurança no contexto do seu app.

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

• Usar 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 muito adversária ou abusiva por natureza, ela poderá ser bloqueada e, em vez disso, gerar uma resposta predefinida.

  Dica avançada

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

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

• Ajustar a funcionalidade a algo com risco inerentemente menor. Tarefas de escopo mais restrito (por exemplo, extração de palavras-chave de trechos de texto) ou que têm maior supervisão humana (por exemplo, gerar conteúdo curto que será revisado por um ser humano) geralmente apresentam um risco menor. Por exemplo, em vez de criar um aplicativo para escrever uma resposta de e-mail do zero, você pode limitar a expansão dele em 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 de teste variam. Por exemplo, um gerador de haicai apenas para diversão provavelmente representa riscos menos graves do que, digamos, um aplicativo projetado para uso por escritórios de advocacia para resumir documentos legais e ajudar a redigir contratos. No entanto, o gerador de haicai pode ser usado por uma variedade maior de usuários, o que significa que o potencial para 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 analisadas por especialistas humanos antes de qualquer ação ser tomada pode ser considerado menos propenso a produzir saídas prejudiciais do que o aplicativo idêntico sem essa supervisão.

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

• A comparação de segurança envolve a criação de métricas de segurança que refletem as formas como o aplicativo pode não ser seguro no contexto de como ele provavelmente será usado e, em seguida, testar o desempenho do aplicativo nas métricas usando conjuntos de dados de avaliação. É recomendável 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 com as abordagens prontas para uso, porque é provável que você precise criar seus próprios conjuntos de dados de teste usando avaliadores humanos para se adequar totalmente ao contexto do seu aplicativo.
  • Se você tiver mais de uma métrica, precisará decidir se haverá 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 do desempenho médio.

• O teste adversário envolve tentar proativamente interromper o aplicativo. O objetivo é identificar pontos fracos para que você possa tomar medidas para corrigi-los conforme necessário. Os testes adversários podem exigir tempo/esforço significativo de avaliadores com experiência no aplicativo. No entanto, quanto mais você fizer isso, maior será a chance de detectar problemas, especialmente aqueles que ocorrem raramente ou somente após execuções repetidas do aplicativo.

  • O teste adversário é um método para avaliar sistematicamente um modelo de ML com o objetivo de aprender como ele se comporta quando recebe entradas maliciosas ou inadvertidamente prejudiciais:
    • Uma entrada pode ser maliciosa quando é claramente projetada para produzir uma saída insegura ou nociva. Por exemplo, solicitar que um modelo de geração de texto gere um discurso de ódio sobre uma religião específica.
    • Uma entrada é inadvertidamente prejudicial quando a própria entrada pode ser inócua, mas produz uma saída prejudicial. 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 o teste. Para testes adversários, selecione os dados de teste com maior probabilidade de gerar uma saída problemática do modelo. Isso significa sondar o comportamento do modelo em relação a todos os tipos de dano possíveis, incluindo exemplos raros ou incomuns e casos extremos relevantes às políticas de segurança. Também precisa incluir diversidade nas diferentes dimensões de uma frase, como estrutura, significado e comprimento. Consulte as práticas de imparcialidade de IA do Google 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 danificar seu aplicativo. Nos testes automatizados, a "equipe vermelha" é outro modelo de linguagem que encontra texto de entrada que gera saídas prejudiciais do modelo que está sendo testado.

Monitorar problemas

Não importa o quanto você testa e atenua, nunca é possível garantir a perfeição. Por isso, planeje com antecedência como você vai detectar e lidar com os problemas que surgirem. As abordagens comuns incluem a criação de um canal monitorado para os usuários compartilharem feedback (por exemplo, classificação "Gostei/Não gostei") e a realização de um estudo de usuários para solicitar proativamente feedback de uma mistura diversificada de usuários. Isso é especialmente útil se os padrões de uso forem diferentes das expectativas.

Próximas etapas

• Consulte o guia de configurações de segurança para saber mais sobre as configurações ajustáveis disponíveis pela API Gemini.
• Consulte a introdução a comandos para começar a escrever suas primeiras solicitações.