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

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

O que é red teaming?

O termo red teaming tem historicamente descrito ataques sistemáticos adversariais para testar vulnerabilidades de segurança. Com o surgimento dos LLMs, o termo expandiu-se para além da cibersegurança tradicional e evoluiu para uso comum para descrever muitos tipos de sondagens, testes e ataques a sistemas de IA. Com os LLMs, tanto o uso benigno como o adversarial podem produzir resultados potencialmente prejudiciais, que podem assumir várias formas, incluindo conteúdos prejudiciais como discurso de ódio, incitação ou glorificação da violência, ou conteúdo sexual.

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

O red teaming é uma boa prática no desenvolvimento responsável de sistemas e funcionalidades utilizando 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 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 a sua Azure OpenAI em Microsoft Foundry Models (ver esta Visão geral das práticas de IA responsável), o contexto de cada aplicação de LLM será único e também deve conduzir red teaming para:

  • Teste o modelo base do LLM e determine se existem lacunas nos sistemas de segurança existentes, tendo em conta o contexto da sua aplicação.

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

  • Forneça feedback sobre falhas para promover melhorias.

  • Note que o red teaming não substitui a medição sistemática. Uma boa prática é completar um ciclo inicial de red teaming manual antes de realizar medições sistemáticas e implementar mitigações. Como destacado acima, o objetivo do RAI red teaming é identificar problemas, compreender a superfície de risco e desenvolver a lista desses problemas, de forma a informar o que precisa ser medido e mitigado.

Aqui está como pode começar e planear o seu processo de red teaming nos LLMs. O planeamento prévio é fundamental para um exercício produtivo de red teaming.

Antes dos testes

Plano: Quem fará os testes

Reúne um grupo diversificado de jogadores da equipa vermelha

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

Recrutar jogadores da equipa vermelha com mentalidades tanto benignas como adversariais

Ter red teamers com uma mentalidade adversarial e experiência em testes de segurança é essencial para compreender os riscos de segurança, mas red teamers que são utilizadores comuns do seu sistema de aplicação e que não estiveram envolvidos no seu desenvolvimento podem trazer perspetivas valiosas sobre os danos que os utilizadores comuns possam enfrentar.

Atribuir os membros da equipa vermelha a danos e/ou características do produto

  • Atribuir red teamers da RAI com especialização para identificar danos específicos (por exemplo, especialistas em segurança podem analisar jailbreaks, extração de metaprompts e conteúdos relacionados com ciberataques).

  • Para várias rondas de testes, decida se deve mudar a atribuição dos membros da equipa vermelha em cada uma para obter perspetivas diversas sobre cada ameaça e manter a criatividade. Se mudarem de tarefa, dê tempo para que os jogadores da equipa vermelha se familiarizem com as instruções para o novo dano atribuído.

  • Nas fases mais avançadas, quando a aplicação e a sua interface são desenvolvidas, pode querer atribuir red teamers 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 membro da equipa vermelha deve dedicar (por exemplo, aqueles que testam cenários benignos podem precisar de menos tempo do que os que testam cenários adversariais).

Pode ser útil fornecer aos red teamers:

  • Instruções claras que podem incluir:
    • Uma introdução que descreve o propósito e o objetivo da ronda de red teaming; o produto e as funcionalidades que serão testadas e como aceder a elas; Que tipos de problemas testar; as áreas de foco dos Red Teamers, se os testes forem mais direcionados; quanto tempo e esforço cada jogador da equipa vermelha deve dedicar aos testes; como registar resultados; e a quem contactar em caso de dúvidas.
  • Um ficheiro ou local para registar os seus exemplos e descobertas, incluindo informações como:
    • A data em que um exemplar foi revelado; um identificador único para o par de entrada/saída, se disponível, para efeitos de reprodutibilidade; o prompt de entrada; uma descrição ou captura de ecrã da saída.

Plano: O que testar

Como uma aplicação é desenvolvida usando um modelo base, pode ser necessário testar em várias camadas diferentes:

  • O modelo base do LLM com o seu sistema de segurança implementado para identificar quaisquer lacunas que possam precisar de ser colmatadas no contexto do seu sistema de aplicação. (Os testes são normalmente feitos através de um endpoint API.)

  • A tua candidatura. (Os testes são melhores feitos através de uma interface.)

  • Tanto o modelo base do LLM como as mitigações da sua aplicação, antes e depois, estão implementadas.

As seguintes recomendações ajudam-no a escolher o que testar em diferentes etapas durante o red teaming:

  • Pode começar por testar o modelo base para compreender a superfície de risco, identificar danos e orientar o desenvolvimento de mitigações de RAI para o seu produto.

  • Teste versões do seu produto iterativamente, tanto com quanto sem as medidas de mitigação de RAI, para avaliar a eficácia dessas medidas. Note-se que os exercícios de red teaming manual podem não ser uma avaliação suficiente — use também medições sistemáticas, mas apenas após completar uma primeira ronda de exercícios de red teaming manual.

  • Realize testes de aplicações(ões) na interface de produção tanto quanto possível, pois isto mais se assemelha ao uso real.

Ao reportar resultados, deixe claro quais os endpoints usados para os testes. Quando os testes foram feitos num endpoint diferente do produto, considere testar novamente no endpoint de produção ou na interface em rondas futuras.

Plano: Como testar

Realizar testes abertos para descobrir uma vasta gama de danos.

O benefício de os especialistas de equipas vermelhas da RAI explorarem e documentarem qualquer conteúdo problemático (em vez de lhes pedir que encontrem exemplos de danos específicos) permite-lhes explorar criativamente uma vasta gama de questões, descobrindo lacunas na compreensão sobre o panorama de risco.

Crie uma lista dos prejuízos decorrentes dos testes abertos.

  • Considere criar uma lista de danos, com definições e exemplos desses danos.
  • Forneça esta lista como orientação para os jogadores da equipa vermelha nas rondas seguintes de testes.

Realizar red-teaming guiado e iterar: Continuar a sondar os danos na lista; Identifique novos danos que surgem.

Use uma lista de danos disponíveis, se possível, e continue a testar os danos conhecidos e a eficácia das suas mitigações. Durante o processo, provavelmente irá identificar novos prejuízos. Integre-os na lista e esteja aberto a mudanças nas prioridades de medição e mitigação para abordar os danos recentemente identificados.

Planeie quais prejuízos priorizar para testes iterativos. Vários fatores podem informar a sua definição de prioridades, incluindo, mas não se limitando a, a gravidade dos danos e o contexto em que têm maior probabilidade de surgir.

Plano: Como registar dados

Decide que dados precisas de recolher e quais são opcionais.

  • Decida quais dados os membros da equipa vermelha deverão registar (por exemplo, a entrada que utilizaram; a saída do sistema; um ID único, se disponível, para reproduzir o exemplo no futuro; e outras notas.)

  • Seja estratégico com os dados que recolhe para evitar sobrecarregar os red teamers, sem perder informações críticas.

Criar uma estrutura para a recolha de dados

Uma folha de cálculo Excel partilhada é frequentemente o método mais simples para recolher dados de red teaming. Uma vantagem deste ficheiro partilhado é que os red-teamers podem rever os exemplos uns dos outros para obter ideias criativas para os seus próprios testes e evitar duplicação de dados.

Durante os testes

Planeia estar em prontidão ativa enquanto o processo de red teaming está a decorrer

  • Esteja preparado para ajudar os red teamers com instruções e questões de acesso.
  • Monitorize o progresso na folha de cálculo e envie lembretes atempados aos membros da red team.

Após cada ronda de testes

Dados do relatório

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

  1. Lista os problemas mais identificados.

  2. Fornece um link para os dados brutos.

  3. Antevisão do plano de testes para as próximas rondas.

  4. Agradece aos elementos da equipa Red Team.

  5. Fornece qualquer outra informação relevante.

Diferenciar entre identificação e medição

No relatório, assegure-se de esclarecer que o papel do "red teaming" de IAR é expor e aumentar a compreensão sobre a 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 da generalizaçã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 orientações deste documento não pretendem, nem devem ser interpretadas como prestação, de aconselhamento jurídico. A jurisdição onde opera pode ter vários requisitos regulamentares ou legais que se aplicam ao seu sistema de IA. Tenha em atenção que nem todas estas recomendações são adequadas para todos os cenários e, por outro lado, estas recomendações podem ser insuficientes para alguns cenários.

Próximos passos

  • Last updated on