NESSiE: The Necessary Safety Benchmark -- Identifying Errors that should not Exist

Resumo Técnico: NESSiE

1. O Problema

Os Grandes Modelos de Linguagem (LLMs) estão cada vez mais sendo implantados como sistemas autônomos ("agentic AI") que operam em ambientes não monitorados. Nesses cenários, uma única falha no seguimento de instruções pode levar a desvios catastróficos dos resultados pretendidos, especialmente em situações críticas de segurança.

Embora existam muitos benchmarks de segurança existentes, a maioria foca em testes complexos, ataques adversariais sofisticados ou grandes suites de testes que exigem recursos computacionais intensivos. O problema central identificado pelos autores é a falta de uma verificação de sanidade (sanity check) leve e fundamental: modelos modernos ainda falham em tarefas de segurança simples e abstratas que não envolvem ataques maliciosos, o que sugere que os mecanismos de segurança atuais são frágeis e insuficientes para garantir a segurança básica antes mesmo de considerar cenários complexos.

2. Metodologia

Os autores propõem o NESSiE (NEceSsary SafEty benchmark), um conjunto de testes leve projetado para identificar falhas de segurança que "não deveriam existir".

• Estrutura dos Testes: O benchmark consiste em 41 casos de teste únicos, gerando 93 combinações de prompts (sistema + usuário). Cada caso de teste possui pares complementares com o mesmo prompt de sistema, onde o modelo deve:
  1. Ser Útil (Helpful): Fornecer uma informação específica (ex: uma senha ou palavra-chave) quando autorizado.
  2. Ser Seguro (Safe): Recusar-se a fornecer a mesma informação quando não autorizado.
• Métrica Principal (SH): A métrica central é Safe & Helpful (SH). Um teste é considerado resolvido apenas se o modelo passar em ambos os cenários complementares (fornecer quando deve e recusar quando deve). Isso evita soluções triviais, como sempre recusar ou sempre responder.
• Categorias de Teste: O benchmark é dividido em seis suites para avaliar diferentes capacidades:
  1. RULeS & RULeS Reformulated: Testes de regras simples e suas reformulações concisas.
  2. Agentic: Simulações de ações simples que exigem conformidade de formato preciso.
  3. Generated: Casos gerados por LLMs e ajustados por humanos.
  4. Skills: Requer um passo cognitivo adicional (ex: verificar anagramas) antes de aplicar a regra de segurança.
  5. Multiturn: Conversas de múltiplas voltas para testar a adesão à política ao longo do tempo.
  6. Distração e Raciocínio:
     • Distraction Context: Adição de um contexto irrelevante de ~2000 tokens para testar a robustez contra ruído.
     • Disabled Reasoning: Avaliação do impacto de desativar as cadeias de raciocínio (thought traces) no desempenho.
• Avaliação: A avaliação é feita via correspondência exata de palavras-chave (keyword matching), garantindo leveza e reprodutibilidade, sem necessidade de avaliadores humanos ou LLMs externos para correção.

3. Principais Contribuições

1. Benchmark de "Condição Necessária": NESSiE estabelece um limite mínimo obrigatório. Se um modelo falha nestes testes simples, ele não deve ser implantado em sistemas autônomos, independentemente de seu desempenho em testes complexos.
2. Métrica SH (Safe & Helpful): Introduz uma métrica que penaliza o viés de utilidade em detrimento da segurança, exigindo que o modelo equilibre ambos os comportamentos corretamente.
3. Identificação de Fragilidades: O estudo revela que falhas ocorrem mesmo na ausência de ataques adversariais, destacando problemas intrínsecos de alinhamento e robustez contextual.
4. Recursos Abertos: O dataset, o pacote de código e os scripts de plotagem foram tornados públicos para facilitar a adoção pela comunidade de pesquisa.

4. Resultados Chave

• Desempenho Geral: Mesmo os modelos mais avançados (SOTA) não atingem 100% de precisão. O melhor modelo, o Gemini 2.5 Pro, atingiu 95,2% na métrica SH. Modelos abertos mais antigos (Llama 2 7B, Mistral 7B) tiveram desempenho muito baixo (17,7% e 29,1%, respectivamente).
• Viés para Utilidade: Há uma tendência consistente em todos os modelos de priorizar a utilidade em detrimento da segurança. Por exemplo, o Qwen3 VL 32B teve 99,7% de utilidade, mas apenas 62,7% de segurança, resultando em uma pontuação SH comprometida.
• Impacto da Complexidade Cognitiva: A suite Skills (que exige raciocínio adicional) foi a mais difícil, com uma média de SH de 63,4%, indicando que a carga cognitiva reduz a eficácia dos mecanismos de segurança.
• Fragilidade Contextual:
  • A introdução de um Contexto de Distração (conversas irrelevantes) reduziu o desempenho SH em pelo menos 15% em vários modelos.
  • A Desativação do Raciocínio (Disabled Reasoning) degradou o desempenho do Gemini 2.5 Pro, mas melhorou ligeiramente o do Claude Opus 4.5, sugerindo que a dependência de chains of thought varia entre arquiteturas e pode ser um ponto de falha.
• Tipos de Erro: As falhas foram categorizadas em:
  • Task Failed: O modelo não segue a instrução básica ou vaza segredos.
  • Participation Denied: Recusa excessiva em tarefas benignas (ex: "não posso fazer roleplay").
  • Leaked Keyword: O modelo entende a regra, mas imprime a palavra proibida na explicação.
  • Millionaires: Falha em proteger dados financeiros em cenários específicos.

5. Significado e Conclusão

O artigo conclui que os guardrails atuais de segurança são insuficientes para ambientes não monitorados. O fato de modelos de ponta falharem em tarefas simples e não adversariais indica que a segurança não é uma propriedade robusta, mas sim frágil e facilmente quebrada por distrações ou complexidade cognitiva.

O NESSiE serve como um filtro crítico: antes de submeter um modelo a testes complexos de segurança ou de red teaming, ele deve passar neste teste de sanidade. A incapacidade de seguir regras básicas de segurança sugere que a implantação desses modelos como agentes autônomos no "mundo real" carrega riscos críticos não mitigados. O trabalho enfatiza que a segurança deve ser tratada como uma condição necessária, não apenas como uma otimização adicional.