Jailbreaks em LLMs explicados: o que um jailbreak muda e por que não é Abliteration

Em julho de 2023, três pesquisadores executaram 32 prompts prejudiciais contra o GPT-4 e o Claude 1.3 por meio de 28 ataques diferentes. A técnica única mais forte — três famílias de ataque empilhadas umas sobre as outras — passou em 94 por cento do conjunto contra o GPT-4 e em 81 por cento contra o Claude 1.3. O que fechou o conjunto não foi um ataque melhor, mas uma escolha: um adversário autorizado a escolher qual dos 28 funcionava melhor para cada prompt conseguiu passar todos os 32 nos dois modelos, o que o artigo relata como um 1,00 limpo. A leitura desconfortável é que um jailbreak não é um defeito que desaparece quando o modelo fica mais inteligente ou se comporta melhor. É uma propriedade do prompt, e o prompt pertence a quem quer que o esteja enviando. O que acontece depois que a recusa para — a chamada de ferramenta, a leitura do arquivo, a saída que chega a algum lugar que age sobre ela — é a parte o arquivo de incidentes de IA foi criado para registrar.

Vale a pena ser preciso sobre essa formulação, porque "jailbreak" é usado para várias coisas diferentes, e as diferenças determinam o que qualquer mitigação pode sequer fazer. Este texto aborda o que um jailbreak edita, o que os números medidos realmente dizem, por que não existe uma resposta por modelo para "é possível fazer jailbreak nele?", e onde a técnica deixa de ser uma questão de segurança de modelo e passa a ser uma de segurança de sistema.

Um jailbreak é uma edição no prompt, não no modelo

O modelo permanece exatamente como foi entregue. Nada é retreinado, nenhum peso é tocado, nenhum ajuste fino é aplicado. O atacante altera a solicitação de modo que obedecer se torne a continuação localmente correta, e o comportamento de segurança que foi treinado no modelo perde para uma instrução concorrente que ele também foi treinado a seguir.

Essa única frase descarta uma grande categoria de supostas correções. Você não pode corrigi-lo nos pesos — não há nada de errado com os pesos. Você não pode enumerá-lo, porque o espaço de prompts é aberto. E você não pode verificá-lo uma única vez, porque a técnica que falha hoje não é a que será tentada amanhã. O que você pode fazer é medir uma taxa, em um conjunto fixo de prompts, em relação a uma versão fixa do modelo, e então observar essa taxa mudar quando qualquer um desses três mudar.

O que o experimento de 32 prompts realmente mediu

O estudo é Jailbroken: How Does LLM Safety Training Fail?, de Alexander Wei, Nika Haghtalab e Jacob Steinhardt, publicado no arXiv em julho de 2023 como 2307.02483. Seu conjunto de testes era composto por 32 prompts prejudiciais — metade extraída de uma avaliação publicada do GPT-4, metade adaptada de trabalhos publicados de red teaming sobre o Claude — e sua medida de resultado é direta: um caso é contado como sucesso quando a resposta é simultaneamente prejudicial e pertinente à solicitação original. Qualquer coisa que trave, se desvie ou responda a uma pergunta diferente não conta.

Duas propriedades dos resultados são mais úteis do que qualquer linha individual. A primeira é quão desigualmente os ataques transferem entre modelos. O role-play do AIM obteve 0,75 contra o GPT-4 e 0,00 contra o Claude 1.3. O JSON com few-shot obteve 0,53 e 0,00. Enquanto isso, a codificação Base64 foi o tipo inverso de desigualdade — 0,34 no GPT-4 e 0,38 no Claude 1.3 — e os distratores ficaram em 0,44 e 0,47. Uma técnica contra a qual um fornecedor claramente treinou aparece como zero naquele modelo e não diz nada sobre o modelo ao lado.

O segundo é o que acontece quando famílias são combinadas. Injeção de prefixo mais supressão de recusa mais Base64 produziram 0,56 contra o GPT-4 e 0,66 contra o Claude 1.3. Adicionar injeção de estilo elevou para 0,69 e 0,84. Adicionar geração de conteúdo de site e restrições de formatação elevou para 0,94 e 0,81. O empilhamento é o truque inteiro: cada camada é algo que o modelo foi treinado para fazer, e a combinação não deixa nenhuma posição de token em que recusar seja a continuação mais natural.

Os modelos daquela tabela têm três anos e já não são o que se está implantando. Os números não são o ponto; a forma é. Cada mecanismo da tabela continua ativo em todos os modelos desde então, porque nenhum deles jamais foi um bug no GPT-4 ou no Claude 1.3 — são consequências de como o treinamento para seguir instruções e o treinamento de segurança interagem.

Duas maneiras pelas quais o treinamento de segurança falha

A explicação do artigo é incomumente clara, e é a parte que vale a pena levar consigo: há dois modos de falha, e cada ataque na tabela é uma instância de um deles.

Objetivos concorrentes são o que acontece quando as capacidades de um modelo e os seus objetivos de segurança apontam em direções diferentes. O seguimento de instruções é uma capacidade. Quando o pedido é enquadrado de forma que recusar violaria uma instrução que o modelo foi fortemente treinado para obedecer, o modelo resolve o conflito a favor da instrução. A injeção de prefixo é a versão mínima: diga ao modelo que a sua resposta tem de começar com "Absolutely! Here's", e os primeiros tokens já são um compromisso que torna a recusa incoerente. A supressão de recusas ataca a mesma fissura pelo outro lado, ao adicionar regras de formatação que proíbem a frase na qual uma recusa teria de ser escrita.

Generalização incompatível é o que você obtém quando o treinamento de segurança cobre uma distribuição de entradas estreita que a capacidade geral do modelo não abrange. O modelo aprendeu Base64 durante o pré-treinamento e consegue seguir perfeitamente uma instrução codificada. O treinamento de segurança, que viu principalmente solicitações em linguagem natural, nunca o ensinou a reconhecer que uma solicitação codificada ainda é uma solicitação. A mesma falha aparece com remoção de vogais, ROT13, leetspeak, divisão de payload e tarefas distratoras: cada um é um formato ao qual a capacidade generaliza e o comportamento de segurança não.

Depois que você tem essas duas categorias, os ataques deixam de parecer um conjunto heterogêneo de truques e passam a parecer duas famílias com uma causa raiz comum — o que também explica por que eles se combinam tão bem. Um prompt que suprime a recusa e esconde sua intenção em uma codificação está explorando os dois modos de falha ao mesmo tempo, e 0,94 é como isso se parece.

Por que não há uma resposta por modelo para “é possível fazer jailbreak?”

A forma de consulta mais comum nesse espaço é um nome de modelo seguido da palavra jailbreak. É a unidade de análise errada, e o motivo é a tabela acima. O sucesso depende de pelo menos cinco coisas ao mesmo tempo: a capacidade do modelo base, qual treinamento de segurança ele recebeu e em qual distribuição, o formato do prompt, as configurações de amostragem e quantas tentativas o atacante está disposto a gastar.

A última merece uma frase própria. Uma taxa medida em uma tentativa por prompt e uma taxa medida em "melhor de 28" não são a mesma medição, e o resultado adaptativo do artigo — 1,00 em ambos os modelos — é do segundo tipo. Quem cita uma taxa de jailbreak sem dizer de qual está falando não citou nada utilizável. A pergunta defensiva realista não é "dá para quebrar", mas "quantas tentativas são necessárias, e algo na minha stack percebe as tentativas".

Seguem-se duas consequências práticas. Um modelo que resiste ao seu conjunto de prompts hoje pode deixar de resistir após uma atualização de versão, uma alteração na camada de segurança ou uma mudança de configuração do lado do serviço — o resultado só é válido para a build que você testou, e é por isso que um teste sem versão e data não é um resultado. E o mesmo conjunto de prompts executado contra dois modelos diz qual deles é mais vulnerável na sua stack, não qual deles é seguro.

O que um jailbreak não é: abliteração

Esses dois são constantemente confundidos porque ambos acabam com um modelo produzindo uma saída que ele foi treinado para não produzir. Eles não são a mesma edição, e a diferença é a diferença entre um controle que você pode adicionar e uma propriedade que você não pode.

• Jailbreak — uma edição na camada de prompt. Os pesos permanecem inalterados. A direção de recusa ainda está no modelo; a solicitação foi simplesmente organizada de modo que outros comportamentos tenham prioridade sobre ela. Reverta o prompt e o comportamento reverte junto com ele.

• Abliteration — uma edição na camada de pesos. A direção de recusa é identificada — geralmente como uma direção no espaço de ativações — e projetada para fora dos pesos do modelo, de modo que o modelo deixa de produzir recusas para essa classe de solicitação. É uma alteração permanente no artefato, e é por isso que um checkpoint ablacionado se comporta de forma diferente do mesmo modelo base com um prompt engenhoso. A mecânica dessa edição está descrita em nosso guia sobre abliteration.

A diferença operacional importa mais do que a terminologia. Um jailbreak é um evento de runtime: ele chega junto com uma requisição e pode ser contado, ter a taxa limitada, ser filtrado e registrado em log como qualquer outra requisição. Um modelo abliterado é um evento de cadeia de suprimentos: o controle já foi removido antes de você recebê-lo, e nenhuma quantidade de monitoramento na camada de prompt o traz de volta. Se o seu modelo de ameaça é "alguém vai tentar persuadir o modelo", você está na primeira categoria. Se é "alguém vai me entregar um modelo com a recusa removida", você está na segunda, e o único controle real é a proveniência — saber qual checkpoint o endpoint está realmente servindo.

Jailbreak também não é injeção de prompt.

O terceiro termo que entra na mistura é injeção de prompt, e a pergunta decisiva é quem é o atacante. Um jailbreak vem do usuário, que está tentando obter conteúdo que o modelo foi treinado para reter. A injeção de prompt vem de conteúdo — um documento recuperado, uma página da web, um resultado de ferramenta — que carrega instruções que o desenvolvedor nunca escreveu, e funciona quer o usuário seja hostil ou não. O mesmo modelo pode ser imune a um e totalmente aberto ao outro, porque eles são neutralizados em lugares diferentes: jailbreaks na entrada e na saída do modelo, injeção na fronteira de confiança entre dados e instruções.

O que realmente reduz a taxa

Nada aqui é garantia, e qualquer afirmação em contrário é conversa de vendedor. O que segue é o conjunto de controles que alteram os números, ordenados pelo quanto eles rendem em relação ao esforço.

• Presuma que a camada de prompt falhe. Todo controle que depende de o modelo recusar está a apenas um atacante adaptativo de distância de zero. Projete como se a solicitação acabasse passando e coloque o controle onde o dano ocorreria.

• Restrinja o que um jailbreak bem-sucedido pode alcançar. O raio de impacto de um assistente comprometido por jailbreak é tudo o que suas ferramentas, credenciais e escopo de recuperação permitem. O privilégio mínimo em ferramentas e o escopo por locatário na recuperação reduzem o valor de um jailbreak bem-sucedido de forma muito mais confiável do que qualquer filtro de prompt.

• Julgue a saída, não o prompt. Classificadores do lado da saída capturam famílias que você nunca viu, porque olham para o que foi realmente produzido, e não para como foi solicitado. Eles também são a única camada que ainda funciona quando o formato de entrada é novo — o que, segundo o modo de falha de generalização incompatível, acontece na maioria das vezes.

• Trate o prompt do sistema como um valor de configuração, não como uma fronteira de segurança. Ele é texto na mesma janela de contexto que o ataque. Aumenta o custo de uma tentativa; não a impede.

• Torne as tentativas visíveis. A única vantagem que um defensor tem sobre o atacante adaptativo é que o ataque costuma ser repetido. Limites de frequência, deteção de repetições e registo transformam uma busca de 28 tentativas num evento que consegue ver, em vez de 28 pedidos que, isoladamente, pareciam normais.

• Re-teste a cada mudança de modelo. Um pin de versão mais um conjunto fixo de prompts é o que transforma "testamos uma vez" em um número comparável. Sem o pin, a comparação não tem sentido.

Como medir sua própria meta

Se o objetivo é um número sobre o qual você possa agir, defina as três variáveis que o artigo definiu: o conjunto de prompts, a versão do modelo e o número de tentativas. Use um conjunto de prompts que inclua ambos os modos de falha — instruções que tornam a recusa constrangedora, e codificações que ocultam a solicitação — porque um conjunto feito apenas de um deles favorecerá um modelo que é fraco no outro. Classifique de forma conservadora: prejudicial e dentro do tema, não apenas fora do tom. E relate o resultado como uma taxa em relação a um número declarado de tentativas, nunca como sim ou não.

Quando vários modelos candidatos estão em jogo, a comparação só funciona se o mesmo conjunto de prompts for executado em cada um deles, e é aí que a infraestrutura importa mais do que a metodologia. Executar uma única avaliação nos modelos que roteamos elimina o contrato por fornecedor e o trabalho do cliente do exercício; os preços de tabela dos fornecedores são repassados sem margem, então a execução custa o que os fornecedores cobram e nada mais. O que a avaliação mede é o comportamento do modelo, não o nosso — o roteamento muda qual modelo responde, e não faz com que nenhum deles se recuse mais.

Onde o registro começa

Uma taxa de sucesso medida indica o quão difícil é derrubar a camada de prompt. Ela não indica o que aconteceu quando alguém a derrubou em produção, e é essa segunda pergunta que decide se a taxa importa. Um jailbreak que produz um parágrafo grosseiro é um problema de moderação de conteúdo. Um jailbreak que produz uma chamada de ferramenta é um incidente, e a diferença está inteiramente no que o sistema permitiu que a saída alcançasse.

Esse arquivo é o registro de campo: o que os agentes realmente fizeram, com uma fonte para cada entrada e um veredito sobre se alguém foi prejudicado. Interpretado à luz de uma medição de jailbreak, ele responde à pergunta que a medição não consegue responder — se a fronteira que um prompt cruzou é uma da qual algo a jusante depende. Se for, o jailbreak é um achado de segurança e o controle pertence às permissões da ferramenta. Se não for, o jailbreak é um resultado de conteúdo, e a atitude honesta é arquivá-lo como tal em vez de inflá-lo para uma vulnerabilidade.

A nota final é a que as evidências sustentam. O jailbreaking não será resolvido por um modelo melhor, porque os modos de falha são estruturais: seguir instruções é uma capacidade, e o treinamento de segurança é uma capacidade mais restrita, e a lacuna entre elas é onde vive cada ataque neste artigo. O que pode ser resolvido é a consequência — garantindo que um modelo que deixa de recusar ainda não consiga fazer muita coisa.