Planejando o red teaming para grandes modelos de linguagem (LLMs) e suas aplicações

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

O que é red teaming?

O termo red teaming historicamente descreve ataques adversários sistemáticos para testar vulnerabilidades de segurança. Com a ascensão dos LLMs, o termo se estendeu além da cibersegurança tradicional e evoluiu no uso comum para descrever muitos tipos de sondagem, teste e ataque de sistemas de IA. Com os LLM, tanto a utilização benigna como a adversarial podem produzir resultados potencialmente nocivos, que podem assumir muitas formas, incluindo conteúdos nocivos como o discurso de ódio, o incitamento ou a glorificação da violência ou conteúdos sexuais.

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

Red teaming é uma prática recomendada no desenvolvimento responsável de sistemas e recursos usando LLMs. Embora não substitua o trabalho sistemático de medição e mitigação, os red teamers ajudam a descobrir e identificar danos e, por sua vez, permitem estratégias de medição para validar a eficácia das mitigações.

Embora a Microsoft tenha conduzido exercícios de red teaming e implementado sistemas de segurança (incluindo filtros de conteúdo e outras estratégias de mitigação) para seus modelos de Serviço OpenAI do Azure (consulte esta Visão geral das práticas de IA responsáveis), o contexto de cada aplicativo LLM será exclusivo e você também deve conduzir o red teaming para:

• Teste o modelo base LLM e determine se há lacunas nos sistemas de segurança existentes, dado o contexto da sua aplicação.

• Identificar e mitigar deficiências nos filtros padrão ou estratégias de mitigação existentes.

• Fornecer feedback sobre falhas, a fim de fazer melhorias.

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

Aqui está como você pode começar e planejar seu processo de LLMs red teaming. O planejamento antecipado é fundamental para um exercício produtivo de red teaming.

Antes do teste

Plano: Quem fará o teste

Monte um grupo diversificado de equipes vermelhas

Determine a composição ideal dos red teamers em termos de experiência, demografia e conhecimento das pessoas em todas as disciplinas (por exemplo, especialistas em IA, ciências sociais, segurança) para o domínio do seu produto. Por exemplo, se você estiver projetando um chatbot para ajudar os profissionais de saúde, os especialistas médicos podem ajudar a identificar riscos nesse domínio.

Recrute equipas vermelhas com mentalidades benignas e adversárias

Ter red teamers com uma mentalidade adversarial e experiência em testes de segurança é essencial para entender os riscos de segurança, mas red teamers que são usuários comuns do seu sistema de aplicativos e não estiveram envolvidos em seu desenvolvimento podem trazer perspetivas valiosas sobre os danos que os usuários comuns podem encontrar.

Atribua red teamers a danos e/ou características do produto

• Atribua equipes vermelhas da RAI com experiência específica para investigar tipos específicos de danos (por exemplo, especialistas no assunto de segurança podem investigar jailbreaks, extração de meta prompt e conteúdo relacionado a ataques cibernéticos).

• Para várias rodadas de testes, decida se deseja trocar as atribuições de equipe vermelha em cada rodada para obter perspetivas diversas sobre cada dano e manter a criatividade. Se mudar de tarefas, dê tempo para que os funcionários da equipe vermelha se atualizem sobre as instruções para seus danos recém-atribuídos.

• Em estágios posteriores, quando o aplicativo e sua interface do usuário são desenvolvidos, convém atribuir teamers vermelhos a partes específicas do aplicativo (ou seja, recursos) para garantir a cobertura de todo o aplicativo.

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

Pode ser útil fornecer aos red teamers:

• Instruções claras que podem incluir:
  • Uma introdução descrevendo o propósito e o objetivo da rodada dada de red teaming; o produto e as funcionalidades que serão testadas e como aceder aos mesmos; que tipos de questões testar; áreas de foco dos red teamers, se os testes forem mais direcionados; quanto tempo e esforço cada equipa vermelha deve gastar nos testes; como registar os resultados; e quem contactar com perguntas.
• Um ficheiro ou local para registar os seus exemplos e constatações, incluindo informações como:
  • A data em que um exemplo foi surgido; um identificador único para o par entrada/saída, se disponível, para efeitos de reprodutibilidade; 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 base LLM com seu sistema de segurança em vigor para identificar quaisquer lacunas que possam precisar ser abordadas no contexto do seu sistema de aplicação. (O teste geralmente é feito por meio de um ponto de extremidade da API.)

• A sua candidatura. (O teste é melhor feito por meio de uma interface do usuário.)

• Tanto o modelo base LLM quanto seu aplicativo, 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 básico para entender a superfície de risco, identificar danos e orientar o desenvolvimento de mitigações de RAI para seu produto.

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

• Realize testes de aplicativos(s) na interface do usuário de produção tanto quanto possível, pois isso mais se assemelha ao uso no mundo real.

Ao relatar resultados, deixe claro quais pontos de avaliação foram usados para testes. Quando o teste foi feito em um ponto de extremidade diferente do produto, considere testar novamente no ponto de extremidade de produção ou na interface do usuário em rodadas futuras.

Plano: Como testar

Realize testes abertos para descobrir uma ampla gama de danos.

O benefício de os red teamers da RAI explorarem e documentarem qualquer conteúdo problemático (em vez de lhes pedir para encontrarem exemplos de danos específicos) permite-lhes explorar criativamente uma vasta gama de questões, descobrindo pontos cegos na sua compreensão da superfície de risco.

Crie uma lista de danos do teste aberto.

• Considere a criação de uma lista de danos, com definições e exemplos dos danos.
• Forneça esta lista como uma diretriz para os jogadores da equipe vermelha em rodadas posteriores de testes.

Conduzir o red teaming guiado e iterar: Continuar a sondar os danos na lista; identificar novos danos que surjam.

Use uma lista de danos, se disponível, e continue testando danos conhecidos e a eficácia de suas mitigações. No processo, você provavelmente identificará novos danos. Integrá-los na lista e estar aberto a alterar as prioridades de medição e mitigação para lidar com os danos recentemente identificados.

Planeje quais danos priorizar para testes iterativos. Vários fatores podem informar sua priorização, incluindo, mas não limitado a, a gravidade dos danos e o contexto em que eles são mais propensos a surgir.

Plano: Como registar 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 que eles usaram; a saída do sistema; um ID exclusivo, se disponível, para reproduzir o exemplo no futuro; e outras notas).

• Seja estratégico com os dados que você está coletando para evitar sobrecarregar os funcionários vermelhos, sem perder informações críticas.

Criar uma estrutura para a recolha de dados

Uma planilha compartilhada do Excel geralmente é o método mais simples para coletar dados de agrupamento vermelho. Um benefício desse arquivo compartilhado é que os red teamers podem revisar os exemplos uns dos outros para obter ideias criativas para seus próprios testes e evitar a duplicação de dados.

Durante os testes

Planeje estar em espera ativa enquanto o red teaming 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 oportunos para os funcionários da equipe vermelha.

Após cada ronda de testes

Dados do relatório

Partilhe um breve relatório a intervalos regulares com as principais partes interessadas que:

1. Lista os principais problemas identificados.

2. Fornece um link para os dados brutos.

3. Antecipa o plano de testes para as próximas rodadas.

4. Reconhece as equipas vermelhas.

5. Fornece qualquer outra informação relevante.

Diferenciar entre identificação e medição

No relatório, certifique-se de esclarecer que o papel do red teaming da RAI é expor e aumentar a compreensão da superfície de risco e não substitui 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 omnipresença desse dano.

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

As orientações contidas neste documento não se destinam a ser, nem devem ser interpretadas como prestando aconselhamento jurídico. A jurisdição em que você está operando pode ter vários requisitos regulamentares ou legais que se aplicam ao seu sistema de IA. Esteja ciente de que nem todas essas recomendações são apropriadas para todos os cenários e, inversamente, essas recomendações podem ser insuficientes para alguns cenários.