🤖 machine learning

Risk Under Pressure: Compute-Aware Evaluation of Adversarial Robustness in Language Models

Este artigo propõe um framework de avaliação consciente de computação que mede o risco adversarial usando FLOPs cumulativos em vez de orçamentos de consultas fixos, revelando que o treinamento de alinhamento e o escalonamento de modelos têm efeitos não monotônicos e dependentes de categoria no esforço computacional necessário para realizar o jailbreak de grandes modelos de linguagem.

Autores originais: Malikeh Ehghaghi, Boglárka Ecsedi, Marsha Chechik, Colin Raffel

Publicado 2026-06-11

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Malikeh Ehghaghi, Boglárka Ecsedi, Marsha Chechik, Colin Raffel

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

A Grande Ideia: Não é Só Sobre Se Você Consegue Invadir, Mas Quanto Isso Custa

Imagine que você é dono de um cofre de alta segurança. Uma empresa de segurança vem testá-lo. Eles relatam: "Invadimos o cofre 100% das vezes."

No mundo dos Grandes Modelos de Linguagem (LLMs), isso geralmente é o fim da história. Pesquisadores dizem: "O modelo é inseguro porque um atacante teve sucesso."

Mas este artigo argumenta que isso é como dizer que um banco é inseguro apenas porque um ladrão eventualmente entrou, sem perguntar o quanto ele teve que trabalhar.

Cenário A: O ladrão abre a fechadura em 5 segundos com um clipe de papel.
Cenário B: O ladrão passa 10 dias, usa um cortador a laser e contrata uma equipe de engenheiros para perfurar o concreto.

Ambos os cenários resultam em um cofre "invadido". Mas o Cenário B é muito menos provável de acontecer no mundo real porque é caro demais e difícil demais.

Este artigo introduz uma nova forma de medir a segurança chamada "Risco sob Pressão" (Risk Under Pressure). Em vez de apenas contar quantas vezes uma IA falhou, ele mede quanto poder de computação (esforço) um atacante teve que gastar para fazer a IA dizer algo ruim.

As Novas Ferramentas: Medindo o "Suor Computacional"

Os autores criaram uma estrutura que trata o poder de processamento computacional como um orçamento. Eles medem o "suor" que um atacante tem que exercer usando FLOPs (operações de ponto flutuante), que é basicamente uma contagem de quantas operações matemáticas o computador teve que realizar.

Eles usam duas ferramentas principais para visualizar isso:

A "Curva de Risco-Computação" (A Colina): Imagine uma colina. A base é "fácil de quebrar" e o topo é "difícil de quebrar".
- Alguns modelos são como uma colina pequena; você pode subir até o topo (quebrar a segurança) com alguns passos.
- Outros modelos são como o Monte Everest; você tem que gastar uma quantidade massiva de energia apenas para chegar na metade do caminho.
A "Etiqueta de Preço" (C@τ): Isso responde: "Quanto poder de computação é necessário para quebrar este modelo 50% das vezes?"
- Se a etiqueta de preço for baixa, o modelo é vulnerável.
- Se a etiqueta de preço for enorme, o modelo é robusto, mesmo que ele possa teoricamente ser quebrado.

O Que Eles Descobriram: Os Resultados Surpreendentes

Os pesquisadores testaram muitos modelos de IA e métodos de ataque diferentes. Aqui está o que eles descobriram, traduzido para termos cotidianos:

1. O Treinamento Nem Sempre Torna as Coisas Mais Seguras (A Armadilha do "Sobre-treinamento")

Você pode pensar que, quanto mais você treina uma IA para ser segura, mais segura ela fica. O artigo descobriu que isso nem sempre é verdade.

A Analogia: Imagine ensinar uma criança a dizer "não" para estranhos.
- Estágio 1 (Base): A criança diz "sim" para tudo.
- Estágio 2 (SFT): Você ensina a criança a ser educada. Ela se torna muito boa em dizer "não".
- Estágio 3 (DPO/RL): Você tenta refiná-la ainda mais com recompensas. Surpreendentemente, às vezes elas ficam piores em dizer "não" para perguntas complexas.
A Descoberta: Às vezes, a versão "intermediária" do modelo era, na verdade, a mais difícil de quebrar. As versões finais, mais "alinhadas", às vezes tornavam-se mais fáceis de enganar ou, pelo menos, não ficavam muito mais difíceis de quebrar.

2. Modelos Maiores Nem Sempre São Mais Seguros (O Problema do "Alvo Grande")

Tornar um modelo maior (mais parâmetros) é como construir um castelo maior.

A Descoberta: Se o atacante usa um método "inteligente" (como um ataque de gradiente que calcula o caminho perfeito), um castelo maior é muito mais difícil de quebrar. É como tentar escalar uma torre de 100 andares versus uma casa de 1 andar.
A Ressalva: Se o atacante usa um método "burro" (como apenas tentar templates aleatórios ou copiar e colar prompts ruins), o tamanho do castelo não importa. Eles ainda podem invadir tão facilmente quanto antes.
Conclusão: Modelos maiores param os hackers "inteligentes", mas não param os hackers "preguiçosos".

3. O Truque do "Substituto" (Roubando as Chaves)

Atacantes muitas vezes não têm acesso ao modelo de código fechado e secreto que desejam hackear.

A Analogia: Imagine que você quer invadir um banco específico, mas não consegue chegar perto dele. Então, você vai a um banco semelhante na rua ao lado, aprende a abrir a fechadura dele e encontra uma chave mestra que funciona em ambos os bancos.
A Descoberta: Os pesquisadores mostraram que atacantes podem treinar suas ferramentas de "abrir fechaduras" em um modelo de IA pequeno e gratuito (open source). Uma vez que descobrem o truque, podem usar esse mesmo truque em um modelo de IA grande, caro e fechado. Isso economiza uma quantidade massiva de dinheiro e esforço para o atacante.

4. A Segurança é Desigual (O Efeito "Queijo Suíço")

Mesmo um modelo que parece geralmente seguro possui buracos.

A Descoberta: Pode ser necessário muito esforço para fazer uma IA falar sobre "bullying", mas pode ser necessário muito pouco esforço para fazê-la falar sobre "crimes cibernéticos" ou "drogas ilegais".
A Analogia: Imagine uma fortaleza com uma parede de pedra grossa no lado norte (difícil de quebrar), mas uma porta de madeira frágil no lado sul (fácil de quebrar). Se você medir apenas a espessura média da parede, pensará que a fortaleza é segura. Mas um atacante inteligente simplesmente passará pela porta de madeira.

Por Que Isso Importa

O artigo argumenta que precisamos parar de apenas perguntar "A IA quebrou?" e começar a perguntar "Quanto custou para quebrá-la?".

Se uma IA exige um supercomputador rodando por uma semana para ser enganada, ela é efetivamente segura para a maioria das pessoas. Se leva 5 segundos, é um desastre. Ao medir o "custo" do ataque, obtemos uma imagem muito mais clara da segurança no mundo real.

Em resumo: O artigo diz que precisamos parar de olhar para o placar da "Taxa de Sucesso" e começar a olhar para o placar do "Esforço Necessário" para entender verdadeiramente o quão seguros são nossos modelos de IA.

Resumo Técnico: Risco sob Pressão: Avaliação de Robustez Adversária Consciente de Computação em Modelos de Linguagem

Declaração do Problema

As avaliações atuais de robustez adversária para Grandes Modelos de Linguagem (LLMs) dependem predominantemente da Taxa de Sucesso de Ataque (ASR) medida sob orçamentos de consultas fixos. Esta abordagem trata implicitamente todas as etapas de ataque como tendo o mesmo custo, ignorando o fato de que diferentes estratégias de ataque (por exemplo, otimização baseada em gradiente vs. prompting baseado em templates) incorrem em despesas computacionais que podem variar em ordens de magnitude. Consequentemente, um modelo que requer 100 consultas de um ataque de template barato para falhar é pontuado identicamente a um modelo que falha imediatamente, obscurecendo o verdadeiro "fator de trabalho" ou esforço adversário necessário para violar o sistema. Esta limitação dificulta a determinação se o custo computacional de um ataque justifica seu retorno para um adversário e torna difícil comparar modelos sob gastos iguais de atacante.

Metodologia

Os autores propõem um framework de avaliação consciente de computação que substitui a contagem de consultas por pressão computacional, medida em operações de ponto flutuante cumulativas (FLOPs), como um proxy para o esforço adversário.

Framework Central

Refinamento Iterativo Orçado: Os ataques são modelados como processos iterativos onde uma política de ataque $\pi$ propõe prompts, um modelo alvo $M$ gera respostas e um juiz de segurança $E$ avalia os resultados. Este loop continua até que um sucesso seja encontrado ou um orçamento de consulta $\lambda$ seja esgotado.
Contabilidade de FLOPs: O framework calcula os FLOPs cumulativos para cada etapa, incluindo:
- Passagens de ida (forward passes) através do modelo alvo (geração e avaliação).
- Passagens de volta (backward passes) para ataques baseados em gradiente (white-box).
- Passagens de ida através de modelos atacantes auxiliares (refinamento black-box).
- Passagens de ida através do juiz de segurança.
- Os custos são derivados de aproximações padrão de transformadores para FLOPs ( $C_{fwd} \approx 2NL$ ), garantindo comparabilidade independente de hardware.
Curvas de Risco-Computação: Em vez de um único ponto de ASR, o framework gera curvas que mapeiam os FLOPs cumulativos (eixo x) para o risco empírico (eixo y).
Métricas de Resumo:
- C@ $\tau$ (Computação para $\tau$ -risco): Os FLOPs cumulativos médios necessários para um ataque atingir pela primeira vez um limite de risco específico (ex: 50%). Valores mais altos indicam maior robustez.
- Eficiência Média (AE): O risco esperado normalizado por FLOP ( $CAURC / \bar{C}_{max}$ ). Valores mais baixos indicam que um modelo é mais difícil de explorar por unidade de computação.

Configuração Experimental

O framework foi aplicado em:

Modelos: Dez modelos abrangendo três famílias (Tulu3, Qwen2.5, Qwen3) e vários estágios de treinamento (Base, SFT, DPO, RLVR, SafeRL).
Ataques: Três estratégias distintas:
- JailBroken: Baseado em template (ofuscação aleatória).
- PAIR: Refinamento iterativo black-box usando um LLM atacante.
- GCG: Otimização de gradiente de coordenada baseada em gradiente white-box.
Benchmarks: HarmBench (200 comportamentos) e JailbreakBench (100 comportamentos).

Principais Resultados

A análise consciente de computação revelou padrões invisíveis às métricas padrão de ASR:

Efeitos Não Monotônicos de Alinhamento: O treinamento de alinhamento não aumenta linearmente a robustez. Na família Tulu3, o estágio de Ajuste Fino Supervisionado (SFT) frequentemente exibiu a maior robustez (ex: GCG e PAIR falharam em atingir 50% de risco dentro do orçamento). O alinhamento subsequente via Otimização de Preferência Direta (DPO) e Aprendizado por Reforço com Recompensas Verificáveis (RLVR) frequentemente reduziu a robustez, particularmente contra ataques baseados em templates, apesar de maior ASR em alguns casos.
Benefícios de Escalonamento Assimétricos: Aumentar o tamanho do modelo (ex: Qwen2.5 de 0.5B para 7B) aumentou significativamente o custo computacional para ataques baseados em gradiente (um aumento de 20 $\times$ em C@0.5), mas ofereceu proteção mínima contra ataques de template baratos (apenas 2.8 $\times$ de aumento). As métricas de ASR padrão mascararam essa disparidade, mostrando taxas de sucesso semelhantes entre as escalas.
Transferência de Ataque de Surrogato: Ataques baseados em gradiente (GCG) otimizados em um pequeno modelo surrogato de pesos abertos (Qwen2.5-0.5B) transferiram-se com sucesso para um alvo maior de pesos fechados (Qwen3-8B) a uma fração do custo original. Embora a transferência nem sempre tenha atingido regimes de alto risco, demonstrou que atacantes podem reduzir custos otimizando em surrogatos.
Heterogeneidade entre Categorias de Dano: Dentro de um único modelo, o custo computacional para violar a segurança variou em até $\approx 5\times$ entre diferentes categorias de dano (ex: assédio vs. cibercrime). O RL de segurança alinhada aumentou os custos agregados, mas deixou certas categorias (ex: cibercrime, atividades ilegais) desproporcionalmente acessíveis ou até mais eficientemente exploráveis (maior AE) do que o modelo base.
Trade-offs de Safety-RL: Embora o Safety-RL geralmente tenha elevado o custo adversário agregado, introduziu vulnerabilidades específicas. Por exemplo, sob GCG, o modelo SafeRL foi estritamente menos robusto que seu correspondente base, sugerindo uma incompatibilidade entre a distribuição de prompts de treinamento de RL e as sequências de tokens descobertas pela otimização de gradiente.

Significância e Alegações

O artigo argumenta que a robustez é uma função do custo computacional, não apenas da possibilidade. Ao adotar uma perspectiva de "fator de trabalho" centrada na segurança, os autores alegam:

Relevância Operacional: Uma vulnerabilidade só é operacionalmente relevante se for explorável dentro de um orçamento realista do adversário. Elevar o piso do custo computacional pode ser tão eficaz quanto reduzir as taxas de sucesso.
Limitações de Métricas Estáticas: Pontuações ASR padrão sob orçamentos de consultas fixos sistematicamente superestimam a robustez ao ignorar a eficiência variável de diferentes classes de ataque e os efeitos não lineares de escalonamento e alinhamento de modelos.
Comparação Unificada: O framework proposto permite comparações justas entre diversas estratégias de ataque (white-box vs. black-box) e configurações de modelos, normalizando-as contra um eixo de computação compartilhado.
Avaliação de Segurança Matizada: O ajuste de segurança não é uma melhoria monolítica; ele cria paisagens de proteção desiguais onde algumas categorias tornam-se significativamente mais difíceis de violar, enquanto outras permanecem vulneráveis ou tornam-se mais eficientes para ataque.

Os autores concluem que a avaliação adversária consciente de custo é necessária para mensurar com precisão o risco real da implantação de LLMs, pois modelos que parecem robustos sob métricas de contagem de consultas podem falhar catastroficamente quando avaliados sob pressão consciente de computação.