💻 computer science

Willing but Unable: Separating Refusal from Capability in Code LLMs via Abliteration

Este artigo demonstra que a "ablateração", uma técnica de edição de pesos de baixo posto que projeta ortogonalmente as direções de recusa, pode desacoplar efetivamente a recusa de LLMs de código alinhados para segurança em gerar código vulnerável de suas capacidades reais de geração, permitindo assim a produção escalável de código vulnerável rotulado para pesquisa de detecção de vulnerabilidades sem comprometer a validade sintática.

Autores originais: Cristina Carleo, Pietro Liguori, Naghmeh Ivaki, Domenico Cotroneo

Publicado 2026-06-05

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Cristina Carleo, Pietro Liguori, Naghmeh Ivaki, Domenico Cotroneo

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

O Grande Problema: O Robô "Superprotetor"

Imagine que você está tentando ensinar um robô a identificar falhas de segurança em códigos de computador. Para fazer isso, você precisa de uma enorme biblioteca de exemplos mostrando tanto códigos "seguros" quanto códigos "quebrados" (vulneráveis).

No entanto, há um detalhe. Os robôs (modelos de IA) que temos hoje são treinados para serem muito seguros. Se você perguntar a eles: "Ei, você pode me mostrar como quebrar um banco de dados?", eles imediatamente dizem: "Não! Eu não posso fazer isso. Isso é perigoso."

Isso é um problema para os pesquisadores. Eles precisam que o robô cometa o erro para que possam estudá-lo e construir defesas melhores. Mas o robô se recusa a desempenhar o papel do "vilão", mesmo que o pesquisador queira apenas estudar o erro em um ambiente de laboratório controlado.

O Experimento: Desligando o Botão de "Parar"

Os pesquisadores deste artigo queriam ver se conseguiam desligar esse botão de "Parar" sem quebrar o cérebro do robô. Eles usaram uma técnica chamada Abliteration.

Pense no cérebro da IA como uma biblioteca gigante de pensamentos. Quando o robô vê um pedido para criar uma falha de segurança, um "sinal de recusa" específico (como uma luz de alarme vermelha) pisca em sua mente, e ele interrompe a conversa.

Abliteration é como um cirurgião removendo cuidadosamente apenas aquela luz de alarme vermelha da fiação do robô. Eles não treinaram o robô novamente nem o ensinaram coisas novas; eles apenas editaram cirurgicamente os pesos (as conexões) para impedir que o sinal de recusa fosse disparado.

As Três Descobertas Principais

Os pesquisadores testaram isso em três tamanhos diferentes de modelos de IA (Pequeno, Médio e Grande) usando código Python e um tipo específico de falha de segurança chamado Injeção de SQL (que é como enganar um banco de dados para revelar segredos).

1. A "Recusa" Depende do Tamanho e do Contexto

Antes de realizarem a cirurgia, eles notaram algo interessante:

O Modelo Gigante (14B): Ele recusava 100% das vezes. Não importava o que você pedisse, ele dizia "Não".
O Modelo Médio (7B): Ele era seletivo. Recusava a maior parte das vezes em códigos longos e complexos, mas às vezes dizia "Sim" em trechos de código curtos e simples.
O Modelo Pequeno (3B): Ele mal recusava. Estava disposto a tentar quase qualquer coisa.

A Analogia: Imagine três guardas de segurança. O guarda grande é tão rigoroso que barra todo mundo. O guarda médio barra pessoas com bolsas grandes, mas deixa passar pessoas com pequenos envelopes. O guarda pequeno é muito relaxado e deixa quase todo mundo passar.

2. A Cirurgia Funcionou (A Parte do "Disposto")

Depois que realizaram a cirurgia de "Abliteration":

A Recusa Desapareceu: Os modelos Gigante e Médio pararam de dizer "Não". Agora eles estavam dispostos a tentar criar a falha de segurança.
O Cérebro Continuava Saudável: Crucialmente, a cirurgia não quebrou o robô. O código que eles produziam ainda era gramaticalmente correto e fazia sentido. Eles não haviam lobotomizado a IA; apenas removeram o reflexo de "eu não vou fazer isso".

A Analogia: É como tirar uma placa de "Proibido Entrar" de uma porta. A porta sempre esteve aberta e o corredor lá dentro estava ótimo; a placa apenas dizia que as pessoas não podiam passar. Uma vez que a placa foi removida, as pessoas puderam passar, e o corredor continuou perfeitamente intacto.

3. Disposição $\neq$ Capacidade (A Parte do "Incapaz")

Esta é a descoberta mais importante. Só porque o robô agora estava disposto a cometer o erro, não significava que ele era capaz de fazê-lo bem.

O Modelo Gigante (14B): Uma vez que o sinal de "Não" foi removido, ele era ótimo em criar a falha de segurança. Ele teve sucesso cerca de 90% das vezes.
O Modelo Médio (7B): Também era muito bom, tendo sucesso cerca de 90% das vezes.
O Modelo Pequeno (3B): Embora estivesse disposto e não recusasse, ele era ruim na tarefa real. Ele teve sucesso apenas cerca de 25–48% das vezes.

A Analogia: Imagine três artistas que foram solicitados a pintar um quadro de um vaso quebrado.

O Artista Gigante foi instruído: "Você não pode pintar isso!", mas depois de ser autorizado, ele pintou uma obra-prima.
O Artista Médio também foi autorizado e pintou um ótimo quadro.
O Artista Pequeno nunca ouviu um "Não" para começar, mas quando tentou pintar o vaso quebrado, simplesmente não conseguiu acertar os detalhes — ele queria fazer, mas carecia de habilidade.

A Conclusão: Duas Coisas Diferentes

O artigo prova que Recusa (disposição) e Capacidade (habilidade) são duas coisas distintas.

Recusa é uma configuração de segurança que pode ser desligada (via Abliteration).
Capacidade é uma medida de quão inteligente o modelo é. Desligar a configuração de segurança não torna um modelo "burro" em "inteligente".

Por que isso importa?

Para Pesquisadores: Se você quiser gerar dados para treinar ferramentas de segurança, não pode apenas usar um modelo pequeno e esperar que funcione. Mesmo que você desligue seus filtros de segurança, ele pode não ser inteligente o suficiente para criar os erros realistas de que você precisa. Você precisa de um modelo maior.
Para a Segurança: Mostra que os filtros de segurança são muito específicos. Você pode remover a "recusa" sem quebrar a capacidade do modelo de escrever um bom código. Isso significa que o alinhamento de segurança é uma camada específica sobre a inteligência do modelo, não a própria inteligência.

Uma Nota sobre Ética

Os autores são muito cuidadosos. Eles liberaram as ferramentas para medir isso e os dados, mas não liberaram os modelos "cirurgicamente modificados" que podem realmente criar essas falhas de segurança. Eles acreditam que, embora a ideia de como fazer isso seja conhecida, liberar os modelos "hackeados" reais seria perigoso demais. Eles querem ajudar pesquisadores a estudar a segurança, não dar uma nova arma a hackers.

Resumo Técnico: Disposto, mas Incapaz: Separando Recusa de Capacidade em Code LLMs via Ablateração

Declaração do Problema
O artigo aborda um gargalo crítico na detecção de vulnerabilidades baseada em aprendizado: a escassez de dados de treinamento rotulados com precisão. Os conjuntos de dados existentes sofrem de ruído de rótulo significativo (20–71%) e duplicação porque são minerados de commits marcados com CVE. Embora os Grandes Modelos de Linguagem (LLMs) ofereçam um caminho para a aumentação de dados, os métodos atuais tipicamente transformam sementes vulneráveis existentes, herdando assim o ruído do corpus de origem. Uma abordagem complementar envolve partir de um código seguro e instruir um LLM a injetar uma vulnerabilidade específica de Common Weakness Enumeration (CWE). No entanto, os LLMs de código modernos, alinhados para segurança e ajustados por instrução, recusam sistematicamente tais comandos devido ao Aprendizado por Reforço com Feedback Humano (RLHF) ou Otimização de Preferência Direta (DPO), mesmo quando o modelo possui a capacidade subjacente para realizar a transformação. Essa recusa cria uma barreira para a geração de conjuntos de dados de vulnerabilidade em larga escala e baseados em especificações.

Metodologia
Os autores propõem um estudo de viabilidade utilizando ablateração, uma técnica de edição de pesos de baixo posto (low-rank), para remover a barreira de recusa enquanto preservam a capacidade generativa. O estudo foca em CWE-89 (SQL Injection) em Python como um estudo de caso.

Seleção do Modelo: O estudo utiliza a família Qwen2.5-Coder-Instruct em três escalas de parâmetros: 3B, 7B e 14B. Estes modelos foram escolhidos por serem de pesos abertos, possuírem especialização em código e pela viabilidade de inferência baseada em CPU.
Procedimento de Ablateração: Baseado na hipótese de que a recusa é mediada por um subespaço linear específico no fluxo residual do modelo, os autores aplicam projeção ortogonal para remover essa "direção de recusa".
- Eles computam uma matriz de contraste entre as ativações de prompts prejudiciais (injeção de CWE) e inofensivos.
- A Decomposição de Valores Singulares (SVD) identifica os $k$ vetores singulares à direita superiores que representam a direção de recusa.
- Esses vetores são projetados para fora das matrizes de peso de saída ( $W_{out}$ ) de camadas específicas do transformer (tipicamente o terço superior da rede) sem retreinamento.
- Hiperparâmetros ( $k$ e passagens de refinamento) são ajustados por tamanho de modelo (ex: $k=2$ para 3B, $k=8$ para 7B/14B).
Pipeline Experimental:
- Entrada: 70 amostras Python seguras do PromSec (20 amostras, aplicações Flask de múltiplas rotas) e SafeCoder (50 amostras, trechos de rota única).
- Prompting: Uma instrução fixa solicita que o modelo reescreva o código seguro para introduzir o CWE-89 (ex: substituindo consultas parametrizadas por concatenação de strings).
- Validação: Um processo de três etapas avalia as saídas:
  1. Classificação de Recusa: Detecção de padrões de recusa baseada em regex.
  2. Validação Sintática: Verificação de análise AST e checagem de compilação.
  3. Detecção de Vulnerabilidade: Um conjunto de três analisadores estáticos (CodeQL, Semgrep, Bandit) sinaliza potenciais vulnerabilidades.
  4. Adjudicação Manual: Dois autores verificam manualmente as saídas positivas dos detectores contra a especificação do CWE-89 para resolver falsos positivos/negativos.
Métricas de Avaliação: O estudo mede taxas de recusa, validade sintática, taxas de injeção de vulnerabilidade e similaridade de código (CrystalBLEU/CodeBLEU) contra contrapartes vulneráveis de verdade fundamental (ground-truth).

Principais Contribuições

Pipeline Reproduzível: Um fluxo de trabalho validado aplicando ablateração a LLMs de código ajustados por instrução, aliado a um conjunto de análise estática de múltiplas ferramentas e adjudicação manual.
Medição Empírica: Um estudo fatorial controlado (3 modelos $\times$ 2 condições $\times$ 2 conjuntos de dados $\times$ 3 execuções) fornecendo as primeiras medições empíricas de recusa e conformidade pós-ablateração em tarefas de injeção de CWE.
Separação Ortogonal de Vontade e Capacidade: O estudo demonstra que a recusa (vontade) e a capacidade de geração de código são eixos ortogonais. A ablateração remove com sucesso o reflexo de recusa sem criar novas capacidades; ela apenas desbloqueia capacidades que já estavam presentes, mas suprimidas.
Artefatos Abertos: Liberação do harness de avaliação (classificador de recusa, validadores, scripts de pontuação) e dados agregados, enquanto retém checkpoints abliterados específicos e amostras vulneráveis para mitigar riscos de uso indevido.

Resultados

A Recusa é Dependente de Tamanho e Contexto:
- O modelo 14B recusou 100% dos prompts em ambos os conjuntos de dados.
- O modelo 7B recusou 73% dos prompts do PromSec (múltiplas rotas), mas apenas 5% dos prompts do SafeCoder (rota única).
- O modelo 3B exibiu recusa negligenciável (0–7%).
A Ablateração Remove a Recusa:
- Pós-ablaterção, as taxas de recusa caíram para 0% (ou próximo de zero, ex: 1,7% para 3B no PromSec) em todos os tamanhos de modelo e conjuntos de dados.
- Preservação de Capacidade: A validade sintática permaneceu acima de 93% para todos os modelos abliterados. A intervenção não degradou a habilidade dos modelos de gerar código Python válido e coerente.
A Capacidade é Limitada pela Capacidade (Capacity-Bound):
- Uma vez removida a recusa, a taxa de injeção de vulnerabilidade escalou com os parâmetros do modelo:
  - 14B: ~88–97% de sucesso de injeção.
  - 7B: ~89–90% de sucesso de injeção.
  - 3B: ~25–48% de sucesso de injeção.
- A baixa taxa de sucesso do modelo 3B persistiu mesmo após a ablaterção, indicando que a limitação era uma falta de capacidade generativa (incapacidade de realizar a edição estrutural corretamente), e não um mecanismo de recusa.
Concordância de Detectores: Os analisadores estáticos mostraram níveis variados de concordância. O CodeQL foi altamente específico para certos ídolos (ex: flask_mysqldb), enquanto o Bandit teve maior recall em padrões sintáticos. A adjudicação manual foi essencial para resolver discrepâncias.

Significância e Alegações
O artigo alega fornecer um estudo de viabilidade preliminar demonstrando que:

A recusa pode ser desatrelada da capacidade: O alinhamento de segurança em LLMs de código atua como um "reflexo de recusa" que pode ser cirurgicamente removido via edições de pesos de baixo posto sem danificar o substrato generativo subjacente.
Viabilidade de Geração de Dados: O pipeline oferece um método para gerar dados de vulnerabilidade rotulados onde o ônus da rotulagem muda da detecção aberta (propensa a ruído) para a confirmação binária limitada. Os modelos 14B e 7B, uma vez abliterados, mostram alto potencial para gerar conjuntos de dados de vulnerabilidade de alta qualidade e baseados em especificações.
Implicações de Uso Dual: Os autores destacam uma preocupação de segurança: a capacidade de remover a recusa via simples edições de peso implica que modelos de pesos abertos alinhados para segurança podem ser facilmente convertidos em ferramentas para gerar código malicioso. Eles argumentam que a "superfície de ataque" exposta pela ablateração em entradas complexas já está presente por padrão em entradas mais simples (como visto com o 7B no SafeCoder).
Insight Metodológico: O estudo sugere que avaliar modelos alinhados para segurança unicamente em taxas de "recusa + falha" confunde dois fenômenos distintos. A aparente falha de um modelo em tarefas sensíveis pode ser inteiramente devida à recusa, que é removível, e não a uma falta de capacidade.

Os autores mantêm um tom modesto, observando que o estudo é limitado a um único CWE (89), uma única linguagem (Python) e uma única família de modelos. Eles declaram explicitamente que as descobertas não garantem a generalização para outros CWEs ou arquiteturas de modelos sem validação empírica adicional.