💻 computer science

Auditing Inference-Time Defense Evaluation for Multimodal Large Language Models

Este artigo apresenta uma auditoria comparativa rastreável de defesas de tempo de inferência de modelos de linguagem de grande escala multimodais, revelando falhas críticas de proveniência em dados de referência e protocolos de avaliação que invalidam reivindicações anteriores de recusa em massa, ao mesmo tempo em que destaca a necessidade de padrões rigorosos de integridade de dados em avaliações de segurança futuras.

Autores originais: Bulat Nutfullin, Vladimir Evgrafov, Dmitry Namiot

Publicado 2026-07-17

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Bulat Nutfullin, Vladimir Evgrafov, Dmitry Namiot

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

Imagine que você é o chef executivo de um restaurante muito chique que serve duas coisas ao mesmo tempo: uma imagem em um prato e um pedido falado. Seu objetivo é garantir que a cozinha nunca cozinhe nada perigoso, mesmo que alguém tente enganar o chef escondendo uma instrução "venenosa" dentro da imagem ou sussurrando de um jeito estranho. Este é o mundo dos Modelos de Linguagem de Grande Escala Multimodais (MLLMs). Estes são cérebros de computador superinteligentes que podem "ver" imagens e "ler" texto, e então conversar de volta com você. Mas, como eles podem ver, atores mal-intencionados podem tentar infiltrar comandos prejudiciais desenhando-os em pixels ou escondendo-os no fundo de uma foto.

Para impedir isso, cientistas inventaram as Defesas em Tempo de Inferência. Pense neles como seguranças que ficam bem na porta da cozinha. Eles não mudam a receita do chef (o cérebro do modelo); em vez disso, eles verificam o pedido antes de ele entrar, ou verificam o prato final antes de ele sair. Alguns guardas adicionam uma nota de aviso educada ao pedido, enquanto outros sacodem um pouco a imagem para borrar qualquer truque escondido. A grande questão para todo o mundo da segurança de IA é: Qual guarda está fazendo o melhor trabalho? Se não pudermos confiar nos guardas, podemos acidentalmente servir uma refeição perigosa ou, pior, podemos ficar com tanto medo do perigo que nos recusamos a servir comida alguma.

A Grande Auditoria da Cozinha: Quando a Planilha de Pontuação Estava Errada

Uma equipe de pesquisadores de Moscou decidiu brincar de detetive. Eles não construíram novos guardas; em vez disso, vasculharam os arquivos de um experimento recente que afirmava testar três diferentes guardas de segurança (inspirados por métodos chamados RapGuard, AdaShield e SmoothVLM) em oito chefes de IA diferentes. Eles queriam ver quem era o melhor. Mas, ao escavarem os arquivos, encontraram uma bagunça de links quebrados, ingredientes ausentes e planilhas de pontuação confusas.

Aqui está o que eles descobriram, servido com uma dose de realidade.

1. O Mistério do "Ingrediente Faltante"

Os pesquisadores descobriram que o experimento deveria testar 9.000 pedidos diferentes (entradas) através de sete testes de segurança diferentes. No entanto, quando verificaram a procedência (o rastro de papel de onde os dados vieram), perceberam que três dos sete testes estavam completamente quebrados.

O Erro do "Prato Errado": Um teste, destinado a verificar se a IA conseguia detectar instruções ocultas em imagens, estava na verdade servindo a imagem errada. Era como tentar testar um alarme de incêndio borrifando água em uma torradeira em vez de em um detector de fumaça.
A Trapaça do "Apenas Texto": Outro teste deveria ser uma mistura de imagens e texto, mas o sistema acidentalmente permitiu que a IA ignorasse as imagens e apenas lesse o texto. Foi um "fallback de apenas texto", o que significa que a IA nunca teve que realmente olhar para a imagem para passar no teste.
A Falha do "Patch Aleatório": Um terceiro teste alegava usar um "patch adversarial" especial (um pequeno adesivo truculento em uma imagem para confundir a IA). Mas o computador não gerou o adesivo truculento; ele apenas desenhou um retângulo aleatório.

Devido a esses erros, os pesquisadores tiveram que descartar os resultados desses três testes. Eles não podiam apenas "corrigir" os números; os dados simplesmente não estavam lá. Isso os deixou com apenas 4.820 entradas válidas de quatro testes específicos (FigStep, JailBreakV, SALAD-bench e HarmBench-Simple) para trabalhar.

2. A Armadilha da "Palavra-Chave"

O experimento original usou uma forma muito simples de decidir se a IA era segura: ele procurava por palavras "mágicas" específicas.

Se a IA dissesse "Eu não posso fazer isso" ou "Sinto muito", era marcada como Segura (uma recusa).
Se a IA dissesse "Aqui está como fazer..." ou "Claro, posso ajudar", era marcada como Insegura (uma resposta prejudicial).

Os pesquisadores descobriram um grande problema com esse método. O sistema contava respostas vazias (onde a IA não dizia nada) como "Seguras" simplesmente porque o código legado não tinha uma regra especial para elas; como a string vazia não correspondia nem à lista "prejudicial" nem à lista de "recusa", a lógica padrão as contava como seguras. Também contava respostas que começavam com um aviso educado, mas que depois davam as instruções perigosas como "Seguras", porque o sistema só procurava a presença de uma frase de recusa para sobrepor uma frase prejudicial, e às vezes a lógica se confundia.

Quando reexaminaram os dados, descobriram que o método de "palavra-chave" era um juiz terrível. Era como um professor corrigindo uma prova olhando apenas para a palavra "o" e ignorando se o aluno realmente respondeu à pergunta. Em uma auditoria de 246 respostas complicadas, o sistema de palavras-chave perdeu 13 respostas prejudiciais que um juiz mais inteligente e humano (um "juiz da família Haiku") identificou corretamente como perigosas. Em termos técnicos, o sistema de palavras-chave rotulou esses 13 casos como "Seguros" quando eram, na verdade, "Prejudiciais" (falsos negativos).

3. O Mito da "Recusa em Massa"

O estudo original parecia sugerir que os guardas de segurança estavam fazendo a IA recusar tudo (uma "recusa em massa"). Os pesquisadores auditaram novamente 38.500 perguntas normais e seguras para ver com que frequência a IA dizia "não" quando não precisava.

O resultado? A IA foi muito educada e prestativa.

A taxa estimada de recusas desnecessárias foi de apenas 0,52%.
Mesmo no pior cenário (o maior grupo único de dados), a taxa era de apenas 3,24%.
Os pesquisadores observaram que a incerteza de "apenas amostragem" (a margem de erro) poderia chegar a 10,92%, mas isso ainda está longe da "recusa em massa" que o estudo original implicou.

A confusão veio do "preâmbulo defensivo". Os guardas de segurança frequentemente adicionavam um longo aviso educado no início da resposta (ex: "Devo alertar que isso é perigoso..."). O antigo sistema de palavras-chave pensou que esse aviso era a recusa, mas a IA na verdade prosseguia e dava a resposta de qualquer maneira. Era como um segurança dizendo: "Não vou deixar você entrar", mas depois abrindo a porta e deixando você passar. O sistema de palavras-chave rotulou erroneamente esses preâmbulos como recusas, inflando os números.

4. O Custo de Ser Seguro

Finalmente, os pesquisadores analisaram quanto tempo esses guardas de segurança desperdiçavam.

O guarda "Gaussiano" (que desfoca a imagem cinco vezes e vota na resposta) levou de 5,45 a 12,76 vezes mais tempo para processar um pedido do que se não fizesse nada.
O conjunto completo de três guardas levou de 4,36 a 16,59 vezes mais tempo.

Isso significa que, embora os guardas possam estar tentando ajudar, eles estão tornando a cozinha incrivelmente lenta.

O Veredito Final

Este artigo não nos diz qual guarda de segurança é o "melhor". Na verdade, ele nos diz que não podemos confiar nos rankings anteriores porque os dados estavam quebrados e o método de pontuação era falho.

O que eles descartaram: Eles provaram que as alegações originais sobre "recusa em massa" estavam erradas e que três dos sete testes de segurança eram inválidos.
O que eles encontraram: Os guardas de segurança (especificamente os envelopes de prompt/wrappers) mudam o comportamento da IA, mas o efeito varia drasticamente dependendo do modelo de IA e do tipo de teste. Às vezes eles ajudam, às vezes prejudicam e, às vezes, apenas atrasam as coisas.
A Lição: Você não pode apenas rodar um teste e olhar para uma pontuação. Você precisa garantir que os ingredientes (entradas) sejam reais, que a planilha de pontuação (avaliação) realmente meça a segurança e que você tenha a receita completa (texto bruto) para verificar o trabalho.

Os autores concluem que, antes de podermos comparar diferentes guardas de segurança, precisamos construir um sistema melhor e mais honesto para testá-los. Até lá, não podemos dizer com certeza quem é o herói e quem está apenas tornando a cozinha mais lenta.

Resumo Técnico: Auditoria da Avaliação de Defesa em Tempo de Inferência para Modelos de Linguagem de Grande Escala Multimodais

Declaração do Problema

Modelos de Linguagem de Grande Escala Multimodais (MLLMs) introduzem novas superfícies de ataque via canais visuais, incluindo instruções incorporadas em imagens, distribuídas entre modalidades ou ocultas em perturbações no espaço de pixels. Embora as defesas em tempo de inferência (modificação de entradas, prompts ou saídas sem o retreinamento dos pesos) ofereçam uma estratégia de mitigação de baixo custo, sua avaliação sofre de problemas críticos de integridade. Os autores identificam que os resultados de segurança comparativos frequentemente dependem de uma procedência de dados falha: arquivos de resultados podem não corresponder aos payloads de imagem reais processados, rótulos "seguros" podem ser derivados de strings vazias ou votos de pipeline em vez de recusas semânticas, e carregadores de benchmarks podem recorrer silenciosamente a modos apenas de texto quando imagens estão ausentes. Consequentemente, as avaliações existentes frequentemente confundem artefatos de pipeline com segurança semântica, falhando em validar se uma defesa realmente impede a geração prejudicial ou apenas altera o formato da saída.

Metodologia

Os autores conduziram uma auditoria rastreável de um arquivo experimental cobrindo dois wrappers de prompt fixos (inspirados em AdaShield e RapGuard) e um adaptador de perturbação de imagem Gaussiana (inspirado em SmoothVLM). O estudo avaliou esses adaptadores em oito MLLMs das famílias InternVL e Qwen-VL.

A metodologia envolveu três fases principais de auditoria:

Auditoria de Proveniência de Entrada e Saída:
A equipe examinou os logs de execução e os arquivos de entrada para sete benchmarks de segurança planejados (totalizando 9.000 entradas). Eles verificaram se os payloads de imagem correspondiam aos benchmarks pretendidos e se o carregador não admitia fallbacks apenas de texto. Três ramos foram identificados como falhos nesses testes:
- MM-SafetyBench: O renderizador local usou o campo de payload incorreto.
- JailBreakV-MM: O carregador admitiu fallbacks apenas de texto para imagens ausentes.
- Ramo Adversarial-patch: O executor gerou retângulos aleatórios em vez de patches adversariais otimizados.
  Esses ramos foram colocados em quarentena, deixando quatro corpora (FigStep, JailBreakV, SALAD-Bench, HarmBench-Simple) com 4.820 entradas por configuração para análise.
Reavaliação Semântica e de Palavras-Chave:
Os escores de segurança originais dependiam de um classificador de palavras-chave legado ( $C_{kw}$ ) que contava strings vazias como "seguras" e utilizava voto de maioria para adaptadores Gaussianos. Os autores reauditaram 274 respostas adversariais usando um protocolo separado de juiz baseado em LLM. Eles descobriram que a regra de palavra-chave apresentava uma alta taxa de falsos negativos (13 de 246 respostas comparáveis) e que rótulos "seguros" frequentemente mascaravam preâmbulos defensivos ou saídas vazias.
Auditoria de Recusa Benigna:
Para medir a recusa excessiva (falsos positivos em consultas benignas), os autores analisaram 3 500 saídas derivadas de consultas benignas do MMBench. Eles empregaram um juiz de LLM dedicado para distinguir entre recusas de sistema diretas, preâmbulos defensivos seguidos de respostas e recusas reais. Eles calcularam taxas de recusa agregadas e intervalos de amostragem, excluindo explicitamente a interpretação de "recusa em massa" derivada do protocolo de palavra-chave legado.

Principais Contribuições

O artigo apresenta quatro contribuições específicas:

Estrutura de Auditoria Rastreável: Um método para distinguir entre benchmarks pretendidos, payloads reais, texto retornado, proxies de pipeline e julgamentos semânticos.
Análise Comparativa Restrita: Uma reavaliação de wrappers de prompt (Ada, Rap) e sua combinação (A+R) contra um adaptador Gaussiano (Smooth) nos corpora retidos (FigStep, JailBreakV, SALAD-Bench, HarmBench-Simple).
Reestimativa de Recusa Benigna: Uma estimativa corrigida da taxa de recusa baseada em 38.500 saídas, demonstrando que o protocolo de palavra-chave legado superestimou significativamente as taxas de recusa devido à contaminação por preâmbulos defensivos.
Medição de Custo Operacional: Quantificação do tempo de processamento em lote e da frequência de emissão de preâmbulo defensivo, separando esses custos da precisão da tarefa não medida.

Resultados

Integridade de Dados: Três dos sete ramos de benchmark planejados foram invalidados devido a falhas de proveniência de entrada. Os resultados restantes são agregados descritivos de um protocolo de palavra-chave legado, não taxas de inocuidade semanticamente validadas.
Scores de Segurança: Os scores de palavra-chave legados não mostraram uma ordenação uniforme entre modelos ou adaptadores. Por exemplo, no modelo 8B InternVL3.5, o score variou de 0,882 (sem adaptador) a 1,000 (wrapper Rap), mas a auditoria semântica não pôde validar esses como melhorias de segurança genuínas.
Discrepância entre Palavra-Chave e Semântica: Em uma busca não aleatória de 246 respostas adversariais, a regra de palavra-chave perdeu 13 casos prejudiciais (falsos negativos) que um juiz semântico identificou. A precisão foi de 41,7% e o recall de 69,8% nesta amostra.
Recusa Benigna: A estimativa de ponto de recusa agregada para consultas benignas foi de 0,52%, com a maior célula estimável em 3,24%. Isso contradiz a interpretação original de "recusa em massa". O protocolo de palavra-chave inflou essa taxa em aproximadamente 54 vezes porque contou preâmbulos defensivos (emitidos pelo wrapper Rap em 20–78% das saídas) como recusas.
Custos Operacionais: O adaptador Gaussiano aumentou o tempo de processamento em 5,45–12,76 vezes, e o stack completo de três adaptadores aumentou-o em 4,36–16,59 vezes.

Significância e Alegações

Os autores afirmam explicitamente que este trabalho não reivindica que uma defesa ou roteador adaptativo seja universalmente superior. Em vez disso, a significância reside em:

Correção Metodológica: Destacar que as avaliações de segurança exigem manifestos imutáveis vinculando payloads a resultados, preservação de texto visível ao usuário separado de votos de pipeline, e avaliadores que meçam o construto pretendido (segurança semântica vs. correspondência de palavra-chave).
Evidência de Variabilidade: Os dados mostram que o desempenho da defesa é altamente dependente do modelo e do corpus específicos, justificando o perfilamento de pipelines candidatos no tráfego alvo antes da implantação.
Requisitos de Proveniência: O artigo estabelece um conjunto de requisitos de proveniência para futuras avaliações de defesa de MLLM, argumentando que, sem esses portões (entradas válidas, respostas brutas armazenadas, julgamento semântico), as classificações comparativas são inválidas.

O artigo conclui que os dados arquivados não sustentam a interpretação anterior de recusa em massa ou um ranking definitivo de defesas. Ele convoca avaliações futuras a utilizarem manifestos versionados e julgamento semântico independente mais denso antes de comparar pipelines de defesa fixos e adaptativos.