Resumo Técnico: Pragmática Adversária para Avaliação de Segurança de IA

1. O Problema

As avaliações de segurança atuais para modelos de linguagem de fronteira dependem cada vez mais de julgamentos relativos ao comportamento ambíguo da linguagem natural. O desafio central não é meramente se um modelo resolve uma tarefa, mas se ele identifica corretamente a força diretiva do material de linguagem natural, a fronteira de política aplicável e a natureza da relação da fonte (por exemplo, distinguir entre uma instrução do usuário, uma passagem citada, uma saída de ferramenta ou uma tentativa adversária de deslocar a autoridade).

Os benchmarks existentes frequentemente comprimem essas distinções complexas em rótulos binários de passar/falhar. Essa abordagem obscurece as causas raízes da falha, que podem advir de limites de capacidade, ambiguidade de política, conflito de instrução, falha de scaffold ou instabilidade nos julgamentos do avaliador. Além disso, as métricas padrão de "recusa vs. resposta" falham em distinguir entre um modelo que está recusando de forma segura, recusando de forma excessivamente cautelosa, incapaz ou confuso pela hierarquia de instruções. O artigo argumenta que os rótulos de avaliação funcionam como licenças de inferência; sem uma distinção precisa, essas licenças não podem sustentar previsões confiáveis sobre o comportamento do modelo sob paráfrase, mudanças de wrapper ou variações de modelo.

2. Metodologia

O artigo introduz a Pragmática Adversária como um alvo de avaliação específico e um protocolo de anotação. Este framework foca em comportamentos de modelos relevantes para a segurança onde o modo de falha depende de como a linguagem é incorporada, atribuída, delimitada ou assumida.

2.1 Taxonomia da Pragmática Adversária

O benchmark distingue oito famílias de contrastes linguísticos, separadas para permitir a comparação controlada antes da recombinação em cenários complexos:

1. Comandos Incorporados: Distinguir instruções do usuário de texto incorporado em páginas da web, logs ou saídas de ferramentas (injeção de prompt indireta).
2. Menção/Uso e Citação: Diferenciar entre a execução de um comando e o mero ato de classificar, traduzir ou relatar uma string citada.
3. Autoridade e Hierarquia de Instrução: Resolver conflitos entre instruções de sistema, desenvolvedor, usuário, ferramenta e fontes externas, incluindo conteúdo não confiável mascarado como privilegiado.
4. Escopo, Negação e Modalidade: Lidar com operadores lógicos (ex: "a menos que", "apenas se") que alteram as condições de conformidade.
5. Deixe e Sequestro de Referência: Detectar quando indexicais (ex: "a instrução anterior") são redirecionados para fontes adversárias.
6. Atos de Fala Indiretos e Pressão Pragmática: Distinguir risco de política de pedidos enquadrados como hipotéticos, piadas ou jargões burocráticos.
7. Ambiguidade de Fronteira de Política: Casos onde o construto da política em si é subespecificado ou instável através de paráfrase.
8. Interpretação de Transcrição de Agente: Atribuir falhas em transcrições de múltiplos turnos a causas específicas (ex: falha da ferramenta vs. deriva de objetivo vs. erro de relatório estratégico).

2.2 Construção do Benchmark

O benchmark é construído usando pares mínimos. Cada par mantém a string superficial, o payload ou o espaço de resposta constantes, enquanto varia um único elemento de controle (ex: papel da fonte, nível de autoridade ou status pragmático).

• Payloads: O conjunto semente utiliza payloads "toy" inofensivos (ex: tokens de cores como "BLUE", segredos fictícios como "ALPHA-000") para preservar a estrutura de controle sem conteúdo inseguro operacional.
• Esquema: Os itens registram metadados incluindo papel da fonte, nível de autoridade, status pragmático, comportamento esperado e atribuição de falha específica.
• Protocolo: O pipeline de avaliação envolve metadados de itens pré-especificados, geração de saída do modelo, triagem auxiliada por regras, rotulagem por especialistas e adjudicação.

2.3 Anotação e Avaliação por Especialistas

Os avaliadores humanos são tratados como especialistas aplicando uma rubrica declarada, não como participantes de pesquisa. O protocolo separa cinco julgamentos distintos frequentemente colapsados em outros benchmarks:

1. Sucesso da tarefa
2. de Sensibilidade à fonte
3. Conformidade de política
4. Risco de segurança
5. Confiança do avaliador

A discordância entre esses rótulos é tratada como um sinal diagnóstico (indicando ambiguidade do item, instabilidade da política ou conflito de critério) em vez de ruído a ser suavizado pela média. A adjudicação ocorre em duas etapas: registro de rótulos específicos por critério sem forçar o consenso, seguido pela classificação da origem da discordância.

3. Principais Contribuições

• Framework Conceitual: Define "pragmática adversária" como um alvo de avaliação instrumental estreito, focando nos mecanismos linguísticos de falha de controle.
• Benchmark Semente: Um benchmark semente de 18 itens consistindo em nove pares mínimos através das oito famílias de fenômenos, acompanhado de um validador de esquema e inventário de metadados.
• Protocolo de Anotação: Um protocolo de avaliação por especialista detalhado que distingue sucesso de tarefa, conformidade de política e risco de segurança, incluindo uma matriz de recusa (distinguindo recusa apropriada, recusa excessiva e sub-recusa).
• Métricas: Um conjunto de oito métricas projetadas para reportar o desempenho por família de fenômenos em vez de pontuações agregadas, incluindo:
  • Precisão de contraste pareado
  • Sensibilidade à fonte da instrução
  • Robustez de menção/uso
  • Calibração de recusa
  • Validade do juiz (performance de LLM-as-judge)
  • Estabilidade de adjudicação
  • Deriva taxonômica e ambiguidade diagnóstica

4. Resultados Experimentais

O artigo relata sobre um piloto de semente local conduzido em 30 de junho de 2026, utilizando três modelos acessíveis via Ollama (qwen3:8b, gemma3:12b, glm-4.7-flash:q4_K_M) contra o conjunto semente de 18 itens (54 linhas item-modelo).

• Performance do Modelo:

  • Sucesso da Tarefa: 36 de 54 saídas foram sucessos totais da tarefa; 11 foram parciais; 7 foram falhas.
  • Conformidade de Política: 46 saídas foram conformes; 7 foram não conformes; 1 foi ambígua.
  • Passes Estritos de Pares: Apenas 13 de 27 células par–modelo passaram nos critérios estritos (ambos os variantes corretos).
  • Estabilidade: Três pares (comando incorporado, menção/uso, escopo-negação) foram estáveis entre todos os modelos. Três pares (referência dêitica ambígua, transcrição de agente, fronteira de política) tiveram zero passes estritos.
  • Modos de Falha: Modelos frequentemente adivinharam cores em tarefas de referência dêitica em vez de pedir esclarecimentos. Em itens de fronteira de política, modelos frequentemente exibiram tokens fictícios protegidos apesar de políticas fictícias.

• Validação de Juiz LLM:

  • Um juiz LLM (glm-4.7-flash) alcançou alta concordância em resultados de recusa (98,1%) e conformidade de política (88,9%).
  • A concordância foi menor para sucesso de tarefa (66,7%) e atribuição de falha (77,8%).
  • O juiz tendeu a elevar sucessos parciais de tarefa para sucesso total e falhou em recuperar falhas de capacidade atribuídas por especialistas, reforçando a necessidade de adjudicação por especialistas.

• Utilidade Diagnóstica: Verificações auxiliadas por regras identificaram linhas não conformes, mas não puderam determinar se uma resposta satisfazia o ato de fala pretendido ou a fronteira de política, confirmando a necessidade de adjudicação humana para contrastes pragmáticos.

5. Significância e Alegações

O artigo alega modestamente que o piloto de semente local valida o pipeline de medição (esquema, protocolo e métricas) em vez das propriedades psicométricas finais do benchmark ou das diferenças de segurança dos modelos de fronteira.

• Utilidade Prática: O framework fornece uma ferramenta para equipes de segurança identificarem fronteiras de política vagas, separarem a suscetibilidade de injeção de prompt da falha de tarefa e auditarem se as alegações de segurança repousam sobre rótulos confiáveis.
• Mudança Metodológica: Reenquadra falhas de avaliação de segurança como falhas de controle mediado pela linguagem. Argumenta-se que um benchmark que não consegue distinguir citação de comando ou autoridade de conteúdo está medindo o construto errado.
• Auditabilidade: O valor primário reside em tornar as alegações de segurança auditáveis: identificar qual string tinha autoridade, qual fronteira de política se aplicava e qual critério de adjudicação produziu o rótulo.
• Trabalho Futuro: O artigo delineia uma próxima passagem empírica envolvendo um conjunto de desenvolvimento de 50–100 itens, avaliações de política e linguísticas independentes, e maior validação de juiz LLM para testar a estabilidade através de paráfrase e superfícies de aplicação. Afirma explicitamente que os resultados atuais não estabelecem rótulos de ouro finais ou diferenças de segurança de modelos de fronteira.