Capítulo 26 — Segurança de IA e aprendizado de máquina: métodos II | Graduação Segurança de IA e aprendizado de máquina

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 26 publicada. Mapa, exemplo, EX076.

flowchart TD
  N0["26.1 Red-teaming de aplicações com LLM"]
  N1["26.2 Suítes de testes"]
  N2["26.3 Ataques adaptativos"]
  N3["26.4 Cobertura e relato"]
  N4["26.5 Automação"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX076"]

Desenho lógico

flowchart LR
  N0["26.1 Red-teaming de aplicações com LLM"]
  N1["26.2 Suítes de testes"]
  N2["26.3 Ataques adaptativos"]
  N3["26.4 Cobertura e relato"]
  N4["26.5 Automação"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX076"]

[26.1 Red-teaming de aplicações com LLM]
    |
    v
[26.2 Suítes de testes]
    |
    v
[26.3 Ataques adaptativos]
    |
    v
[26.4 Cobertura e relato]
    |
    v
[26.5 Automação]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX076]

Objetivos de aprendizagem

Você vai (1) planejar com segurança avaliações adversariais de aplicações com LLM (red-teaming); (2) construir suítes de testes para injeção, divulgação e agência excessiva; (3) usar ataques adaptativos contra suas próprias defesas; e (4) relatar resultados com intervalos e cobertura.

26.1 Red-teaming de aplicações com LLM

Red-teaming é teste adversarial estruturado: uma equipe tenta atingir objetivos de atacante definidos dentro de um escopo autorizado. O NIST AI 600-1 lista o red-teaming entre as ações sugeridas para riscos de IA generativa. Defina objetivos (por exemplo, fazer o chatbot revelar a consulta de outro paciente; fazê-lo marcar sem consentimento), regras de engajamento e forma de relato. Para o Ask Lumen, as regras de engajamento nomearam a cópia de homologação como único alvo, limitaram os testes a duas semanas, exigiram pacientes sintéticos e indicaram o líder de segurança da LCH como contato caso algo inesperado acontecesse. O formato do relatório foi acordado de antemão, para que os achados não pudessem ser suavizados depois.

26.2 Suítes de testes

Transforme objetivos em suítes: muitos casos de teste variando redação, idioma, posição do texto injetado (início, meio, fim de um documento), codificação e estratégias de vários turnos. Mantenha uma parte reservada que os desenvolvedores nunca veem. Use payloads inofensivos e dados sintéticos. A posição importa porque um modelo pode tratar uma instrução no fim de um folheto longo de forma diferente de outra na primeira linha. A suíte de Rina colocou cada payload nas três posições e numa tabela, e incluiu alguns casos de vários turnos em que a segunda mensagem do paciente fazia referência ao documento. A parte reservada foi escrita por um colega e guardada separadamente.

26.3 Ataques adaptativos

Depois que uma defesa é acrescentada, ataque a defesa: se os documentos são envolvidos em delimitadores, tente texto que imite os delimitadores; se um classificador sinaliza "ignore previous", tente paráfrases. Carlini et al. (arXiv:1902.06705) enfatizam a avaliação adaptativa; ela vale igualmente para defesas de LLMs. Quando o Ask Lumen passou a envolver os documentos de parceiros em tags rotuladas, a rodada seguinte de Rina incluiu texto que fechava a tag antes da hora e abria um falso bloco de "sistema". Algumas tentativas mudaram a resposta do modelo, mas nenhuma produziu uma marcação, porque a verificação de política não dependia das tags.

26.4 Cobertura e relato

Relate as taxas de sucesso por categoria com intervalos, o número total de tentativas e as categorias não testadas. Mapas de cobertura para as entradas do OWASP LLM ajudam os leitores a ver as lacunas. O relatório de Rina sobre 100 casos de informação falsa deu 9 sucessos, com um intervalo de Wilson de cerca de 4.8% a 16.2%, e declarou com clareza que ataques em português e ataques escondidos em imagens não haviam sido testados. A tabela de cobertura mostrava LLM01, LLM02, LLM06 e LLM10 cobertos, e LLM03 deixado para a revisão da cadeia de suprimentos, com um responsável nomeado e uma data para o teste.

26.5 Automação

Scripts podem gerar variantes a partir de modelos, executá-las e avaliar os resultados pelos logs das ferramentas, e não pelo texto do modelo. Valide qualquer avaliador automático contra rótulos humanos numa amostra. Para a marcação para outro paciente, o avaliador de Rina lia o log da sandbox de agendamento e contava as marcações cujo paciente diferia do paciente da sessão. Isso é exato. Para informação falsa, a avaliação exigia julgamento, então ela conferiu o avaliador automático com seus próprios rótulos em 60 transcrições e encontrou duas discordâncias, o que a levou a tornar a regra dele mais rígida.

26.6 Exemplo resolvido (caso sintético da LCH)

O exercício autorizado de red team de Rina na homologação do Ask Lumen usou 600 casos em seis categorias. Resultados: marcação para outro paciente 0/100; divulgação de dados de outros pacientes 2/100 (ambas por meio do resumo de uma nota da equipe esquecida no índice); informação falsa sobre clínicas a partir de documentos injetados 9/100; esgotamento de custos bloqueado pelas cotas. As duas divulgações levaram à remoção das notas da equipe do índice; a taxa de informação falsa levou a uma verificação de embasamento contra os dados estruturados das clínicas. As divulgações pelas notas da equipe vieram do conteúdo, e não das regras do modelo: remover as notas corrigiu a causa.

26.7 Erros e limites

Três erros são comuns: testar apenas listas estáticas e públicas de jailbreaks; avaliar pelas próprias palavras do modelo; e "Red-teaming" sem escopo em produção. Listas públicas de jailbreaks são o que o fornecedor do Ask Lumen provavelmente já viu, então passar nelas mostra pouco. Um avaliador que lê a resposta do modelo, como "Marquei isso para você", deixa escapar marcações feitas em silêncio e conta bravatas que não fizeram nada; os logs das ferramentas mostram o que de fato aconteceu. Testar a produção sem escopo põe em risco consultas de pacientes reais, e é por isso que Rina testou apenas a homologação, com aprovação por escrito.

Exercícios

EX076 — Objetivos. Escreva três objetivos de red team para o DocSort. Rubrica: 3 = três objetivos específicos e mensuráveis; 2 = dois; 1 = vagos; 0 = nenhum.
EX077 — Adaptativo. Proponha um teste adaptativo para uma defesa baseada em delimitadores (descrito com segurança). Rubrica: 3 = imitar/fechar os delimitadores para que o conteúdo pareça instrução; 2 = genérico; 1 = vago; 0 = detalhe nocivo.
EX078 — Avaliação. Por que avaliar pelos logs das ferramentas, e não pelas respostas? Rubrica: 3 = ações podem acontecer apesar de um texto de recusa; os logs mostram os efeitos reais; 2 = parcial; 1 = vago; 0 = errado.

Síntese

Os métodos II constroem testes adversariais disciplinados: red-teaming com escopo, suítes reservadas, ataques adaptativos e avaliação pelos logs, relatados com intervalos e cobertura.

Continue estudando — capítulo 26 de 40

← Capítulo 25 (rascunho) · Índice de capítulos do curso · Capítulo 27 (rascunho) →