Introdução: por que o jailbreak é um problema
Os modelos de linguagem modernos tentam recusar solicitações prejudiciais ou perigosas, mas nenhuma proteção é perfeita. Ataques de jailbreak criam prompts que contornam essas restrições: pedem para imaginar um cenário hipotético, mudar de papel, reescrever a tarefa de uma forma "segura" e assim por diante. Pesquisadores e defensores querem entender o quão perigosas essas ataques realmente são.
A maioria das ataques funciona em modo de caixa-preta: o invasor não tem acesso aos pesos do modelo, não tem como analisar seus mecanismos internos. Existe apenas uma API, para a qual é possível enviar solicitações e receber respostas. Portanto, todos os esforços do atacante se resumem à seleção de texto. Para avaliar o quão boa é uma ataque, é preciso entender não apenas se a proteção foi contornada, mas também a que custo.
Normalmente, usa-se uma métrica simples — a proporção de tentativas bem-sucedidas (ASR). Mas ela não mostra quantas solicitações foram necessárias. E é justamente o número de chamadas ao modelo que muitas vezes se torna a principal limitação na prática: quanto mais solicitações, maior a chance de ser notado, mais cara a ataque em termos de tempo e dinheiro.
ASR como métrica enganosa
Vamos imaginar duas formas de ataque. A primeira testa centenas de variações de prompts até que uma funcione. A segunda usa um modelo pré-validado e obtém o resultado em três tentativas. Se ambas têm a mesma porcentagem de sucesso, ao olhar para o ASR elas parecerão equivalentes. Mas em condições reais, a segunda é claramente mais perigosa: é mais rápida, mais barata e deixa menos rastros.
É por isso que comparar apenas pelo ASR lembra uma competição de atiradores em que um atira a três metros e o outro a trinta, mas a vitória é dada pelo número de acertos. Sem levar em conta as condições, o resultado não faz sentido. Para jailbreaks, essa condição deve ser o orçamento de chamadas ao modelo.
Fair-ASR: contando as chamadas
Em um trabalho recente no arXiv, pesquisadores propuseram o protocolo Fair-ASR. Sua essência é comparar ataques com o mesmo número máximo de chamadas-alvo. Uma chamada-alvo é uma solicitação diretamente ao modelo atacado: enviou o prompt, recebeu a resposta. Essa limitação é fácil de controlar, é igual para qualquer método e não requer conhecimento interno do modelo.
Por que isso é importante? Algumas métricas tentam levar em conta a complexidade computacional, por exemplo, via FLOPS. Mas para modelos fechados e proprietários, essas estimativas são imprecisas. Já o número de chamadas é um indicador direto e compreensível. Se uma ataque obtém sucesso em 10 solicitações e outra precisa de 1000, com um orçamento de 10 a segunda simplesmente não acontece.
Além disso, os pesquisadores sugerem monitorar separadamente as chamadas do atacante — solicitações a ferramentas auxiliares, como outro modelo de linguagem que gera prompts. Isso permite ver o quadro completo: primeiro, quantas solicitações foram usadas no modelo-alvo; segundo, quantos recursos adicionais foram necessários.
O que mudou com a comparação justa
Os autores reavaliaram 11 ataques conhecidas usando Fair-ASR e descobriram que sua classificação muda muito dependendo do orçamento alocado. Uma ataque que parece poderosa com cem chamadas pode se mostrar fraca com cinco, e vice-versa. Isso significa que as conclusões antigas sobre eficácia eram, no mínimo, incompletas.
O inesperado foi que métodos simples não desapareceram. Perturbações aleatórias de prompts e modelos escritos manualmente continuam muito competitivos quando o acesso ao modelo-alvo é limitado. Eles não exigem grandes recursos computacionais e funcionam quase imediatamente.
Já as ataques gerenciadas por LLM, onde o modelo auxiliar cria as variações de contorno por conta própria, mostraram-se piores. Elas gastam muitas chamadas tanto no modelo-alvo quanto na própria geração. Nenhuma das ataques testadas desse tipo se mostrou eficaz imediatamente em ambos os indicadores. Ou o resultado é alcançado com um grande orçamento, ou a ataque é cara demais em chamadas auxiliares.
ReCode: uma ataque eficaz inspirada na pesquisa
Essa lacuna entre a eficácia desejada e os custos reais levou os pesquisadores a criar sua própria metodologia — a ataque composicional ReCode. Ela usa reescrita dessensibilizante: a solicitação prejudicial original é reformulada para parecer neutra e não provocar reações de defesa. Em seguida, entram em ação dois primitivos simples e baratos que se mostraram bem na reavaliação do Fair-ASR.
Os resultados são impressionantes. Com um orçamento de apenas 20 chamadas-alvo, a ReCode alcança 85% de sucesso no GPT-5, e em média cada solicitação gasta apenas 7.19 chamadas a ferramentas auxiliares. Para comparação, muitas outras ataques com esse orçamento limitado são praticamente inúteis. E aquelas que podem se gabar de indicadores comparáveis geralmente exigem muito mais recursos auxiliares.
Conclusões
A pesquisa dá um sinal claro: avaliar ataques apenas pela proporção de tentativas bem-sucedidas não é mais possível. É necessário um ponto de referência único, e o número de chamadas ao modelo-alvo é a medida mais transparente e universal disponível. O Fair-ASR propõe exatamente essa abordagem, e ela pode se tornar o padrão para comparações futuras.
Para aqueles que protegem modelos, a conclusão prática importante é: não se deve focar apenas em ataques complexas com inteligência artificial no papel de invasor. Métodos simples e baratos — perturbações aleatórias, modelos — continuam sendo uma ameaça real com recursos limitados. É a resistência a eles que deve ser testada em primeiro lugar. Ataques complexas gerenciadas por LLM podem ser impressionantes em relatórios de laboratório, mas em condições reais são caras demais e não tão perigosas quanto parecem.
