Planejando o red teaming para LLMs (grande modelo de linguagem) e seus aplicativos

Este guia oferece algumas estratégias potenciais para planejar como configurar e gerenciar o red teaming para riscos de IA responsável (RAI) em todo o ciclo de vida do produto do modelo de linguagem grande (LLM).

O que é o red teaming?

O termo agrupamento vermelho historicamente descreveu ataques sistemáticos de adversários para testar vulnerabilidades de segurança. Com o aumento das LLMs, o termo se estendeu além da segurança cibernética tradicional e evoluiu em uso comum para descrever muitos tipos de investigação, teste e ataque de sistemas de IA. Com as LLMs, o uso benigno e contraditório pode produzir saídas potencialmente prejudiciais, que podem tomar muitas formas, incluindo conteúdo prejudicial, como discurso de ódio, incitação ou glorificação da violência ou conteúdo sexual.

Por que o red teaming do RAI é uma prática importante?

O red teaming é uma melhor prática no desenvolvimento responsável de sistemas e recursos que usam LLMs. Embora não seja uma substituição para o trabalho sistemático de medição e mitigação, os agrupadores vermelhos ajudam a descobrir e identificar danos e, por sua vez, habilitam estratégias de medição para validar a eficácia das mitigações.

Embora a Microsoft tenha realizado exercícios de red teaming e implementado sistemas de segurança (incluindo filtros de conteúdo e outras estratégias de mitigação) para seu Azure OpenAI nos Modelos do Microsoft Foundry (consulte esta Visão geral de práticas de IA responsáveis), o contexto de cada aplicação de LLM será único e você também deve realizar exercícios de red teaming para:

  • Teste o modelo base llm e determine se há lacunas nos sistemas de segurança existentes, dado o contexto do seu aplicativo.

  • Identifique e reduza as deficiências nas estratégias de mitigação ou filtros padrão existentes.

  • Forneça comentários sobre falhas para fazer melhorias.

  • Observe que o red teaming não é uma substituição para a medida sistemática. Uma melhor prática é concluir uma rodada inicial de red teaming manual antes de realizar medidas sistemáticas e implementar mitigações. Conforme destacado acima, o objetivo do red teaming do RAI é identificar os danos, entender a superfície de risco e desenvolver a lista de danos que podem informar o que precisa ser medido e mitigado.

Veja como você pode começar e planejar seu processo de LLMs de red teaming. O planejamento avançado é fundamental para um exercício de agrupamento vermelho produtivo.

Antes do teste

Plano: Quem fará o teste

Montar um grupo diversificado de integrantes da equipe vermelha

Determine a composição ideal dos membros do time vermelho em termos de experiência, demografia e expertise das pessoas entre disciplinas (por exemplo, especialistas em IA, ciências sociais, segurança) para o domínio do seu produto. Por exemplo, se você estiver criando um chatbot para ajudar os profissionais de saúde, especialistas médicos poderão ajudar a identificar riscos nesse domínio.

Recrute membros para a equipe vermelha com mentalidades tanto benignas quanto adversárias

Ter integrantes da equipe vermelha com uma mentalidade adversária e experiência em testes de segurança é essencial para entender os riscos de segurança, mas os integrantes da equipe vermelha que são usuários comuns do seu sistema de aplicação e não estão envolvidos em seu desenvolvimento podem trazer perspectivas valiosas sobre os riscos que os usuários comuns podem encontrar.

Atribua membros da equipe vermelha a danos e/ou recursos do produto

  • Atribua red teamers do RAI com conhecimento específico para investigar tipos específicos de danos (por exemplo, especialistas em assuntos de segurança podem investigar jailbreaks, extração de meta prompt e conteúdo relacionado a ataques cibernéticos).

  • Para várias rodadas de teste, decida se deve mudar as atribuições do red teamer em cada rodada para obter perspectivas diversas sobre cada dano e manter a criatividade. Se alternar as atribuições, dê tempo para os red teamers se atualizarem sobre as instruções para seus danos recém-atribuídos.

  • Em estágios posteriores, quando o aplicativo e sua interface do usuário forem desenvolvidos, pode ser desejável atribuir especialistas da equipe vermelha a partes específicas ou funcionalidades do aplicativo para garantir a cobertura de todo o aplicativo.

  • Considere quanto tempo e esforço cada membro da equipe vermelha deve dedicar (por exemplo, aqueles que testam cenários benignos podem precisar de menos tempo do que aqueles que testam cenários adversariais).

Pode ser útil fornecer aos red teamers:

  • Instruções claras que podem incluir:
    • Uma introdução que descreve a finalidade e o objetivo da determinada rodada de agrupamento vermelho; o produto e os recursos que serão testados e como acessá-los; para quais tipos de problemas testar; áreas de foco dos agrupadores vermelhos, se o teste for mais direcionado; quanto tempo e esforço cada teamer vermelho deve gastar em testes; como registrar resultados; e com quem entrar em contato com perguntas.
  • Um arquivo ou local para gravar seus exemplos e descobertas, incluindo informações como:
    • A data em que um exemplo foi exibido; um identificador exclusivo para o par de entrada/saída, se disponível, para fins de reprodução; o prompt de entrada; uma descrição ou captura de tela da saída.

Plano: O que testar

Como um aplicativo é desenvolvido usando um modelo base, talvez seja necessário testar em várias camadas diferentes:

  • O modelo básico da LLM com seu sistema de segurança implementado para identificar quaisquer lacunas que possam precisar ser resolvidas no contexto do seu sistema de aplicativos. (O teste geralmente é feito por meio de um endpoint de API.)

  • Seu aplicativo. (O teste é melhor feito por meio de uma interface do usuário.)

  • O modelo base de LLM e seus aplicativos antes e depois das mitigações estão em vigor.

As recomendações a seguir ajudam você a escolher o que testar em vários pontos durante o red teaming:

  • Você pode começar testando o modelo base para entender a superfície de risco, identificar danos e orientar o desenvolvimento de mitigações RAI para seu produto.

  • Teste as versões do seu produto iterativamente, com e sem mitigações RAI implementadas, para avaliar a eficácia das mitigações RAI. (Observe que o red teaming manual pode não ser uma avaliação suficiente — use medidas sistemáticas também, mas somente depois de concluir uma rodada inicial de red teaming manual.)

  • Realize testes de aplicativos na interface do usuário de produção o máximo possível porque isso se assemelha mais ao uso do mundo real.

Ao relatar os resultados, deixe claro quais critérios de avaliação foram usados para a testagem. Quando o teste foi feito em um endpoint não relacionado ao produto, considere testar novamente no endpoint de produção ou na interface do usuário em futuras rodadas.

Plano: Como testar

Realize testes abertos para descobrir uma ampla gama de danos.

O benefício dos red teamers do RAI explorarem e documentarem qualquer conteúdo problemático (em vez de pedir que encontrem exemplos de danos específicos) permite que eles explorem criativamente uma vasta gama de questões, descobrindo pontos cegos no seu reconhecimento da superfície de risco.

Crie uma lista de danos do teste aberto.

  • Considere criar uma lista de danos, com definições e exemplos dos danos.
  • Forneça essa lista como uma diretriz para os red teamers em rodadas posteriores de teste.

Conduza a equipe vermelha guiada e itere: continue investigando os danos na lista; identifique novos danos que aparecem.

Use uma lista de danos se disponível e continue testando os danos conhecidos e a eficácia de suas mitigações. No processo, você provavelmente identificará novos danos. Integre-os à lista e esteja aberto à mudança de prioridades de medição e mitigação para resolver os danos recentemente identificados.

Planeje quais danos priorizar para testes iterativos. Vários fatores podem informar sua priorização, incluindo, mas não se limitando a, a gravidade dos danos e o contexto no qual eles são mais propensos a aparecer.

Plano: Como registrar dados

Decida quais dados você precisa coletar e quais dados são opcionais.

  • Decida quais dados os red teamers precisarão registrar (por exemplo, a entrada usada; a saída do sistema; uma ID exclusiva, se disponível, para reproduzir o exemplo no futuro; e outras anotações.)

  • Seja estratégico na coleta de dados para evitar sobrecarregar os membros da equipe vermelha, garantindo que informações críticas não sejam perdidas.

Criar uma estrutura para coleta de dados

Uma planilha compartilhada do Excel geralmente é o método mais simples para coletar dados da equipe vermelha. Um benefício desse arquivo compartilhado é que os profissionais do red team podem avaliar os exemplos uns dos outros para adquirir ideias criativas para seus próprios testes e evitar a redundância de dados.

Durante o teste

Planeje estar em prontidão ativa enquanto o teste de intrusão estiver em andamento

  • Esteja preparado para ajudar os red teamers com instruções e problemas de acesso.
  • Monitore o progresso na planilha e envie lembretes no momento certo para a equipe vermelha.

Após cada rodada de teste

Dados do relatório

Compartilhe um relatório curto em um intervalo regular com os principais stakeholders que:

  1. Lista os principais problemas identificados.

  2. Fornece um link para os dados brutos.

  3. Visualiza o plano de teste para as próximas rodadas.

  4. Reconhece os red teamers.

  5. Fornece outras informações relevantes.

Diferenciar entre identificação e medição

No relatório, certifique-se de esclarecer que o papel do red teaming do RAI é expor e elevar o reconhecimento da superfície de risco e não é uma substituição para a medição sistemática e o trabalho rigoroso de mitigação. É importante que as pessoas não interpretem exemplos específicos como uma métrica para a difusão desse dano.

Além disso, se o relatório contiver conteúdo problemático e exemplos, considere incluir um aviso de conteúdo.

As diretrizes neste documento não se destinam a ser e não devem ser interpretadas como assessoria jurídica. A jurisdição na qual você está operando pode ter vários requisitos regulatórios ou legais que se aplicam ao seu sistema de IA. Lembre-se de que nem todas essas recomendações são apropriadas para todos os cenários e, por outro lado, essas recomendações podem ser insuficientes para alguns cenários.

Próximas etapas

  • Last updated on