LLM-Attacker compara ataques a split-LLM: gradientes elevaram o vazamento para 37,77%

Pesquisadores apresentaram o LLM-Attacker, um framework unificado de red team para avaliar a privacidade de modelos de linguagem split e distribuídos. O principal número vem de um experimento de controle com o GPT-2: bastou dar ao atacante os gradientes que o servidor devolve durante o treinamento para que a fatia de tokens recuperados subisse de 94,20% para 97,38%. A recuperação exata de documentos inteiros saltou de 13,71% para 37,77%, quase o triplo.

Por que os resultados de ataques a split-LLM não são comparáveis

No esquema split, o texto permanece no cliente, e o que vai para o servidor são representações intermediárias, ou seja, ativações de uma das camadas. A ideia é atraente: o servidor processa a parte pesada do modelo, e os dados originais do usuário não saem do dispositivo. Mas é possível reconstruir o texto a partir dessas representações, e já existem vários ataques desse tipo.

O problema é que os trabalhos são pouco comparáveis entre si. Um atacante vê certas mensagens, outro conhece os pesos do modelo, um terceiro não. Os datasets são diferentes, e as métricas de recuperação também. Quando um artigo afirma que "nossa defesa reduz o vazamento", não fica claro contra quem, em quais dados e por qual régua isso foi medido.

O que o framework registra e verifica

O LLM-Attacker transforma essas premissas ocultas em registros explícitos. O framework documenta o modelo de ameaça, as mensagens disponíveis ao atacante, os pesos conhecidos, o corpus e o método de contagem. Ataques compatíveis reaproveitam mensagens já registradas, e suas previsões são salvas e avaliadas de forma independente de quem executou o ataque.

Há uma regra rígida para defesas: só é possível declarar sucesso se houver uma linha de base pareada, sem a defesa. Sem esse ponto de referência, dizer que "melhorou" não significa nada. Além disso, o relatório final lista separadamente os ataques que não foram executados. Assim, a ausência de vazamento nos cenários testados deixa de ser confundida com ausência de vazamento em geral.

Os autores também separam dois tipos de afirmação: a verificação da correção da implementação e a eficácia medida do ataque. A primeira indica que o código faz o que se pretendia; a segunda mostra o quão perigoso é o ataque.

Experimento com o GPT-2: o que muda com o acesso a gradientes

O experimento de controle verificou como a avaliação reage a mudanças no acesso do atacante. Resultados:

• recuperação de tokens: 94,20% → 97,38% com a adição de gradientes;
• recuperação exata de documentos: 13,71% → 37,77%;
• o limiar de efeito de dois pontos percentuais foi fixado antes do início dos testes;
• o intervalo de confiança de 95% para o ganho em tokens fica inteiramente acima desse limiar.

Esse experimento é tratado separadamente do trabalho associado. Dentro do LLM-Attacker, ele serve como teste de sensibilidade: se os privilégios do atacante forem ampliados, a medição deve perceber, e percebeu. Vale notar que o aumento em tokens parece modesto (cerca de três pontos), enquanto em documentos inteiros é enorme. A métrica média esconde a cauda da distribuição, onde está o risco real de exposição.

Estudos adicionais dentro do framework avaliam como a escolha do corpus e as defesas baseadas em compressão afetam a recuperação. Um ataque publicado e adaptado é comparado com sua implementação de referência, e o código de medição é testado à parte.

Como montar a verificação na sua equipe

Para equipes que desenvolvem ou compram inferência split e treinamento distribuído, a conclusão é prática. Toda afirmação sobre privacidade deve nomear o atacante, o dataset e a regra de contagem, mostrar as execuções de controle e listar o que ficou sem verificação.

Na avaliação, convém rodar os ataques em pelo menos dois modos de acesso: apenas com as mensagens diretas e com gradientes, caso eles sejam devolvidos ao servidor. É preciso olhar não só a fatia de tokens, mas também a recuperação exata de documentos, porque foi essa métrica que mais cresceu. Qualquer defesa, seja compressão ou ruído, deve ser comparada com a versão sem ela nos mesmos dados. E, ao escolher um fornecedor, vale pedir um relatório justamente nesse formato: sem a lista de ataques não verificados, ele mostra só parte do quadro.