Resumo Técnico: Fair ASR: Reavaliando Jailbreaks de Caixa Preta sob Orçamentos de Chamadas de Alvo Compartilhados

1. Declaração do Problema

As avaliações atuais de ataques de jailbreak em Grandes Modelos de Linguagem (LLMs) dependem primariamente da Taxa de Sucesso de Ataque (ASR), mas frequentemente falham em considerar o orçamento de ataque necessário para alcançar esse sucesso. Estudos existentes frequentemente relatam valores de ASR terminais obtidos sob restrições de recursos desiguais, levando a comparações injustas onde a eficácia de um método é confundida com a quantidade de acesso ao alvo que ele utiliza.

Embora avaliações recentes "conscientes de computação" tentem normalizar os orçamentos agregando recursos em um escalar unificado (ex: FLOPs), essa abordagem possui limitações significativas para cenários de caixa preta:

1. Invisibilidade: Os FLOPs de inferência para modelos de código fechado são geralmente indisponíveis e devem ser estimados.
2. Não Intercambiabilidade: Os FLOPs colapsam distintas restrições de recursos (ex: limites de taxa de API vs. custo computacional) em uma única métrica, obscurecendo realidades operacionais onde o acesso ao modelo alvo é o principal gargalo devido a limites de taxa e detecção de abuso.

Consequentemente, há uma falta de uma base comparável e observável para avaliar ataques de jailbreak de caixa preta heterogêneos.

2. Metodologia: Protocolo Fair-ASR

Para abordar essas questões, os autores introduzem o Fair-ASR, um protocolo de avaliação que padroniza as comparações sob orçamentos de chamadas de alvo compartilhados ($B$).

Princípios Fundares

• Orçamento Primário ($B$): O protocolo utiliza o número de chamadas de alvo (consultas ao modelo vítima) como o orçamento primário. Isso foi escolhido porque:
  • É universal para todos os ataques de caixa preta (todo ataque deve consultar o alvo).
  • Reflete restrições operacionais (limites de taxa, suspensões de conta).
  • É diretamente observável, ao contrário dos FLOPs para APIs fechadas.
• Métrica Secundária: As chamadas de atacante (consultas a um LLM atacante ou juiz auxiliar) são rastreadas separadamente para analisar as trocas de eficiência (trade-offs), em vez de serem colapsadas no orçamento primário.
• Métricas de Avaliação:
  • ASR@B: A fração de solicitações prejudiciais atacadas com sucesso dentro de no máximo $B$ chamadas de alvo.
  • Curva de ASR-Orçamento: A trajetória da ASR conforme $B$ aumenta, revelando taxas de crescimento e pontos de saturação.
  • Chamadas de Alvo Médias (ATC): A média de chamadas de alvo consumidas por ataque bem-sído.
  • Pontuação de Prejudicialidade (HS): Uma métrica de qualidade (usando a rubrica StrongREJECT) que avalia a severidade e a convincente natureza da resposta prejudicial.

Escopo Experimental

Os autores reavaliaram 11 ataques representativos em três categorias:

1. Templates manuais: CodeAttack, DeepInception, CipherChat.
2. Amostragem repetida estocástica: Best-of-N (BoN).
3. Ataques automatizados impulsionados por LLM: PAIR, TAP, ReNeLLM, AutoDAN, GPTFuzzer, AutoDAN-Turbo, Rainbow Teaming.

Os experimentos foram conduzidos em diversos modelos alvo (Llama-3.1, gpt-oss, GPT-4o, GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6) usando conjuntos de dados padrão (HarmBench, JailbreakBench).

3. Principais Descobertas da Reavaliação

A aplicação do Fair-ASR revelou três percepções críticas:

1. Rankings Dependentes de Orçamento: Os rankings de ataques são altamente sensíveis ao orçamento de chamadas de alvo. Métodos que parecem superiores sob grandes orçamentos podem ser superados por métodos mais simples sob orçamentos apertados. Por exemplo, no Llama-3.1-8B, o TAP lidera o BoN em $B=5$, mas o BoN ultrapassa o TAP em $B=100$.
2. Competitividade de Primitivos Simples: Primitivos de ataque simples permanecem altamente competitivos sob acesso igual ao alvo.
   • Perturbação Estocástica: O BoN continua a melhorar com chamadas de alvo adicionais, alcançando alta ASR sem qualquer chamada de modelo atacante.
   • Templates Manuais: Templates estruturados (ex: CodeAttack) alcançam altas taxas de sucesso com pouquíssimas chamadas de alvo (ex: 62% de ASR em $B=1$), muitas vezes superando métodos complexos impulsionados por LLM em regimes de baixo orçamento.
3. Trocas de Eficiência (Efficiency Trade-offs): Nenhum método avaliado impulsionado por LLM é uniformemente eficiente tanto em chamadas de alvo quanto em chamadas de atacante.
   • ReNeLLM alcança alta eficiência de chamadas de alvo (baixo ATC), mas incorre em altos custos de chamadas de atacante devido à reescrita iterativa e portões de nocividade baseados apenas em prompts.
   • Outros métodos (ex: PAIR, TAP) podem usar menos chamadas de atacante, mas requerem significativamente mais chamadas de alvo para atingir limiares de sucesso semelhantes.

4. Solução Proposta: ReCode

Motivado pelo identificado "hiato de eficiência bidimensional", os autores propõem o ReCode, um ataque composicional projetado para maximizar a ASR enquanto minimiza tanto as chamadas de alvo quanto as de atacante.

Arquitetura de Design

O ReCode combina três componentes em um pipeline de passagem única:

1. Reescrita de Dessensibilização Livre de Portão (Gate-free): Ao contrário do ReNeLLM, que usa um portão de nocividade baseado apenas em prompt para filtrar reescritas (provocando tentativas custosas), o ReCode realiza uma reescrita de passagem única usando estratégias de dessensibilização (ex: reescrita literária, substituição objetiva) sem um loop de juiz auxiliar.
2. Perturbação Estocástica Livre de Atacante: O prompt reescrito passa por perturbações de nível de caractere (ex: inversão de caixa, inserção de ASCII) de forma semelhante ao BoN, exigindo zero chamadas adicionais de atacante.
3. Nesting de Estilo de Código Estruturado: O prompt perturbado é incorporado em um template estruturado de estilo de código (ex: definições de classe Python), disfarçando ainda mais a intenção sem exigir o refinamento do modelo atacante.

Resultados

Avaliado sob um orçamento de $B=20$ chamadas de alvo:

• Desempenho: O ReCode alcançou uma ASR média de 81,0% em cinco modelos alvo (incluindo variantes gpt-oss) e 70,3% nos três modelos de fronteira de código fechado (GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6).
• Eficiência: Exigiu uma média de apenas 7,00 chamadas de atacante por solicitação (AAC), significativamente menor que o ReNeLLM (18,69) e o TAP (49,56).
• Ganhos Específicos: No GPT-5, o ReCode melhorou a ASR de 31% (ReNeLLM) para 85%, reduzindo as chamadas de atacante de 26,02 para 7,19.
• Prejudicialidade: O ReCode também alcançou a maior Pontuação de Prejudicialidade (HS) média de 0,662, indicando que maiores taxas de sucesso correlacionam-se com respostas prejudiciais de maior qualidade.

5. Significância e Alegações

O artigo afirma que o Fair-ASR fornece uma base observável necessária para comparar jailbreaks de caixa preta, corrigindo conclusões enganosas derivadas de comparações de orçamentos desiguais. Demonstra que a complexidade algorítmica não garante eficiência e que primitivos simples e de baixo custo são frequentemente subutilizados.

A introdução do ReCode serve como uma prova de conceito de que fechar o hiato de eficiência é possível ao combinar a reescrita de dessensibilização com técnicas de ofuscação livres de atacante. Os autores concluem que as avaliações futuras devem ir além da ASR terminal para considerar a eficiência de recursos conjunta (chamadas de alvo e de atacante) para avaliar com precisão o cenário de segurança dos LLMs.

Limitações Notadas:

• O protocolo foca atualmente em ataques de turno único e ainda não cobre configurações de múltiplos turnos.
• As chamadas de alvo não capturam o uso de tokens, preços de API ou o custo manual de desenvolvimento de templates.
• O estudo reconhece que, embora o ReCode seja eficiente, comportamentos específicos de modelos (ex: a sensibilidade do Claude ao nesting de código) podem variar, exigindo investigação adicional.