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

Este guia oferece algumas estratégias potenciais para planear a configuração e gestão do red teaming para riscos de IA responsável (RAI) ao longo do ciclo de vida dos produtos baseados em grandes modelos de linguagem (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 funcionalidades usando LLMs. Embora não substituam 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 é realizar uma primeira ronda de testes de red teaming manual antes de proceder a medições sistemáticas e implementar medidas de mitigação. 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

Forme um grupo diversificado de red teamers

Determine a composição ideal de uma equipa de red team 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 a área 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 elementos de equipas vermelhas com mentalidade tanto benigna quanto adversária

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 rondas de testes, decida se deseja trocar as atribuições da equipa vermelha em cada ronda para obter perspetivas diversas para cada risco e manter a criatividade. Ao trocar de tarefas, dê tempo para que os membros da equipa vermelha se atualizem sobre as instruções para as suas novas atribuições.

• Em estágios posteriores, quando a aplicação e a sua interface do utilizador são desenvolvidas, poderá querer atribuir equipas de teste especializadas a partes específicas da aplicação (ou seja, funcionalidades) para garantir a cobertura de toda a aplicação.

• 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 dada rodada de red teaming; o produto e as funcionalidades que serão testadas e como aceder aos mesmos; que tipos de problemas ou questões testar; áreas de enfoque 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 endpoint da API.)

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

• Tanto o modelo base LLM quanto a sua aplicação, antes e depois de as mitigações estarem implementadas.

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 num ponto de extremidade diferente do de produção, considere testar novamente no ponto de extremidade de produção ou na interface de utilizador 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.

Realizar atividades de red teaming guiadas e iterar: Continuar a examinar os riscos na lista; identificar novos riscos 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 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 está a recolher para evitar sobrecarregar os membros da equipa vermelha, sem faltar 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

Planeie estar em prontidão enquanto as atividades de red teaming estiverem em andamento

• Esteja preparado para ajudar os membros da equipa vermelha com instruções e situações 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 os membros das 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.