Planejando o red teaming para modelos de linguagem grande (LLMs) 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 surgimento dos 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 os 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 de 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 seus modelos de Serviço OpenAI do Azure (confira esta Visão geral das práticas de IA responsável), o contexto de cada aplicativo LLM será exclusivo e você também deverá conduzir o red teaming para:
Teste o modelo base do LLM e determine se há lacunas nos sistemas de segurança existentes, dado o contexto dos seus aplicativos.
Identifique e reduza as deficiências nos filtros padrão existentes ou nas estratégias de mitigação.
Envie 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 produtivo de agrupamento vermelho.
Antes do teste
Plano: Quem fará o teste
Monte um grupo diversificado de red teamers
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 criando um chatbot destinado a ajudar profissionais de saúde, especialistas médicos poderão ajudar a identificar riscos nesse domínio.
Recrutar red teamers com mentalidade benigna e adversária
Ter agrupadores vermelhos com mentalidade de adversário e experiência de teste de segurança é essencial para entender os riscos de segurança, mas agrupadores vermelhos que são usuários comuns do seu sistema de aplicativos e não estiveram envolvidos em seu desenvolvimento podem trazer perspectivas valiosas sobre os perigos que os usuários regulares podem encontrar.
Atribuir red teamers 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, convém atribuir red teamers a partes específicas do aplicativo (ou seja, recursos) para garantir a cobertura de todo o aplicativo.
Considere quanto tempo e esforço cada red teamer deve dedicar (por exemplo, esses testes para 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 que descreve a finalidade e o objetivo da determinada rodada de red teaming; o produto e os recursos que serão testados e como acessá-los; que tipos de problemas testar; áreas de foco dos red teamers, se o teste for mais direcionado; quanto tempo e esforço cada red teamer deve gastar em testes; como registrar resultados; e quem contatar em caso de dúvidas.
- 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 base de LLM com seu sistema de segurança em vigor para identificar quaisquer lacunas que possam precisar ser resolvidas no contexto do sistema de aplicativos. (O teste geralmente é feito por meio de um ponto de extremidade de API.)
Seu aplicativo. (O teste é melhor realizado 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 do RAI para seu produto.
Teste as versões do seu produto iterativamente com e sem mitigações do RAI em vigor para avaliar a eficácia das mitigações do 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 no mundo real.
Ao relatar os resultados, deixe claro quais pontos de extremidade foram usados para teste. 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 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 na sua compreensão 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 o red teaming guiado 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 na lista e esteja aberto a mudanças nas prioridades de medição e mitigação para abordar 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 com quais dados você está coletando para evitar sobrecarregar os red teamers, sem perder informações críticas.
Criar uma estrutura para coleta de dados
Uma planilha compartilhada do Excel geralmente é o método mais simples para coletar dados do red teaming. 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 o teste
Planejar estar em espera ativo 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 red teamers.
Após cada rodada de teste
Relatar dados
Compartilhe um relatório curto em um intervalo regular com os principais stakeholders que:
Lista os principais problemas identificados.
Fornece um link para os dados brutos.
Visualiza o plano de teste para as próximas rodadas.
Reconhece os red teamers.
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 a compreensão 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 e exemplos problemáticos, 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. Esteja ciente de que nem todas estas recomendações são apropriadas para todos os cenários e, por outro lado, essas recomendações podem ser insuficientes para alguns cenários.