Por que filtros de segurança em IA bloqueiam perguntas legítimas — e como consertar isso

A maioria dos sistemas de segurança para modelos de linguagem trata perigo como uma propriedade do assunto. Um pedido é considerado arriscado porque menciona armas, fraude ou automutilação, e modelos de guarda como o LlamaGuard-3 (um modelo especializado que classifica se um texto pode causar dano) codificam exatamente essa lógica. O problema é que isso cria um efeito colateral conhecido: modelos que recusam perguntas inofensivas só porque contêm uma palavra que parece perigosa.

Segundo pesquisadores da Multiverse Computing, em artigo publicado no blog da Hugging Face (uma plataforma onde desenvolvedores compartilham e baixam modelos de IA já treinados), implantações reais quase nunca funcionam dessa forma. O mesmo modelo pode virar assistente geral, produto educacional, sistema corporativo ou serviço público, e cada cenário precisa de limites diferentes dentro do mesmo tema. Um tutor de educação cívica e um assistente do setor público podem usar o mesmo modelo, mas precisam de comportamentos opostos em política: ambos devem responder perguntas factuais sobre eleições, mas só um deles precisa recusar pedidos para escrever propaganda manipuladora. Um filtro baseado em assuntos gerais não consegue expressar essa divisão.

O novo estudo formaliza o problema como um universo temático — todos os pedidos sobre política, nos experimentos — que contém um subconjunto nocivo que a implantação precisa recusar. A política ideal não é recusar toda a política, mas recusar o subconjunto nocivo enquanto continua respondendo ao complemento inofensivo. O comportamento ideal seria um corte nítido: recusar dentro do subconjunto, responder em todo o resto do tema. Mas um modelo treinado nunca aprende esse corte perfeito, e o treinamento convencional pode acabar expandindo a recusa para território legítimo próximo da fronteira.

A abordagem padrão para construir dados de treinamento aqui é a autogeração: pegar o modelo-alvo, direcioná-lo para recusar cada pedido nocivo e manter os traços que um modelo de guarda verifica como recusas genuínas. Quando os pesquisadores aplicaram essa receita e mediram cada componente, encontraram três problemas. Primeiro, uma lacuna de cobertura: uma única tentativa de geração nem sempre produz uma recusa aceita, e esses pedidos são silenciosamente descartados do conjunto de treinamento — no experimento, 19,88% dos pedidos foram perdidos. Segundo, reações negativas: ajuste de segurança tende a produzir recusas falsas em pedidos inofensivos que parecem superficialmente perigosos. Terceiro, divisões comuns entre nocivo e inofensivo não medem a forma da fronteira de jeito nenhum.

No modelo Qwen3-8B (um modelo de linguagem chinês de código aberto), o treinamento com dados de recusa política elevou a taxa de recusa política de 9,47% para 84,75%. Parece uma vitória limpa, mas não é. No mesmo ponto de treinamento, a taxa de recusa excessiva no XSTest (um benchmark que mede recusas falsas) subiu de 2% para 74%. A configuração com a menor taxa de respostas nocivas também foi a que recusou quase três quartos de pedidos claramente seguros. O achado central do estudo é que a composição dos dados de treinamento decide onde um modelo se posiciona no espaço entre segurança e recusa excessiva, então os dois eixos precisam ser medidos juntos. Adicionar pares de pedidos na fronteira — um que deve ser recusado, outro que deve ser respondido, ambos sobre o mesmo assunto — reduziu a recusa excessiva no lado legítimo de 32,94% para 4,16%, enquanto a recusa no lado nocivo caiu apenas de 91,88% para 87,72%. A conclusão prática, segundo os autores, é que ajuste de segurança não deve ser avaliado apenas pela taxa de recusa de conteúdo nocivo, porque um modelo que recusa mais não é automaticamente mais seguro.