🤖 machine learning

Unlearning at Scale: State-Exact Trace-Preserving Deletion in Billion-Parameter Language Models

Este artigo demonstra que modelos de linguagem de bilhões de parâmetros podem alcançar uma exclusão com exatidão de estado e preservação de traço ao reproduzir o treinamento a partir de um armazenamento de tokens excluindo exemplos específicos, desde que a execução original tenha sido instrumentada para registrar a procedência e um checkpoint incontaminado seja retido, embora este método não garanta eficiência computacional para solicitações de exclusão dispersas.

Autores originais: Abdullah X

Publicado 2026-08-14

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Abdullah X

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

Imagine que você está assando um bolo enorme, de várias camadas, para uma festa gigantesca. No mundo da inteligência artificial, este bolo é um "modelo de linguagem", um programa de computador treinado para escrever, conversar e resolver problemas ao "comer" terabytes de texto. Normalmente, uma vez que o bolo foi assado, você não consegue facilmente retirar um único ingrediente — digamos, um tipo específico de fava de baunilha — sem estragar o bolo inteiro. Se você tentar raspá-lo, as camadas podem desmoronar ou o sabor pode mudar de formas imprevisíveis. Este é o problema do "desaprendizado de máquina" (machine unlearning): como fazer uma IA "esquecer" dados específicos nos quais ela foi treinada, especialmente quando leis (como o GDPR) dizem que as pessoas têm o direito de ter seus dados apagados?

Cientistas têm tentado resolver isso ou re-treinando o bolo inteiro do zero sem aquele ingrediente (o que é lento e caro) ou tentando remover cirurgicamente o sabor (o que muitas vezes deixa vestígios químicos estranhos). Mas há um detalhe: computadores não aprendem apenas com o que comem; eles aprendem com a ordem em que comem, a temperatura do forno e o tempo exato de quando mexem a massa. Se você mudar a ordem dos ingredientes, mesmo que remova o ingrediente ruim, o bolo final pode ter um gosto diferente de um bolo que foi assado perfeitamente sem aquele ingrediente desde o início. Este artigo mergulha na cozinha técnica e bagunçada da IA para fazer uma pergunta muito específica: podemos provar que um bolo assado após a remoção de um ingrediente é exatamente igual, bit a bit, a um bolo que foi assado com o plano de ignorar esse ingrediente desde o começo?

A Receita de Bolo de "Viagem no Tempo"

Este artigo, intitulado "Unlearning at Scale", é como uma equipe de padeiros super precisos que decidiram testar uma receita muito rigorosa para remover ingredientes. Eles não estão apenas tentando fazer o bolo parecer que esqueceu a baunilha; eles querem provar que o bolo é matematicamente idêntico a um bolo que nunca deveria ter tido baunilha em primeiro lugar.

Para fazer isso, eles construíram um sistema especial de "viagem no tempo". Imagine que você está assando um bolo, mas antes de começar, você escreve um cartão de receita super detalhado e imutável. Este cartão não lista apenas os ingredientes; ele registra o segundo exato em que você quebra cada ovo, a temperatura precisa do forno a cada minuto e a ordem específica em que você adiciona a farinha. Isso é o que o artigo chama de execução "preservadora de traço" (trace-preserving).

Agora, imagine que um cliente liga e diz: "Quero remover as favas de baunilha do meu pedido". Em uma cozinha normal, você poderia simplesmente pular a baunilha e continuar misturando. Mas na cozinha deste artigo, os padeiros têm um truque. Eles mantêm o cartão de receita exatamente o mesmo. Quando a receita diz "adicione baunilha no passo 5", os padeiros ainda vão ao passo 5, mas em vez de adicionar baunilha real, eles adicionam um ingrediente "fictício" que não tem gosto nem peso. Eles fazem isso sem alterar a ordem das outras etapas, a temperatura do forno ou a velocidade de mistura.

O Grande Teste: Bolos de Bilhões de Parâmetros

Os pesquisadores testaram essa ideia em três diferentes "bolos" (modelos de IA) de vários tamanhos:

Um bolo pequeno chamado Pythia 160M (160 milhões de parâmetros).
Um bolo gigante chamado Pythia 2.8B (2,8 bilhões de parâmetros).
Um tipo diferente de bolo chamado Llama 3.2 1B (1 bilhão de parâmetros).

Eles realizaram um experimento massivo. Primeiro, assaram um bolo "perfeito" onde seguiram a receita, mas adicionaram um fictício de "peso zero" para o ingrediente proibido. Este é o "Oráculo" — o padrão ouro de como o bolo deveria ser. Depois, assaram um segundo bolo usando seu método de "redação": eles fisicamente removeram o ingrediente proibido da despensa (o depósito de dados), mas seguiram exatamente a mesma receita, substituindo o item faltante pelo fictício sempre que a receita o chamava.

O Resultado: Uma Combinação Perfeita

O resultado foi chocante em sua precisão. Quando compararam os dois bolos, descobriram que o bolo "redigido" era bit a bit idêntico ao bolo "Oráculo".

Para o modelo Pythia 2.8B, eles verificaram 2.775.208.960 números individuais (o estado do modelo) e encontraram zero diferenças.
Para o modelo Llama 3.2 1B, eles verificaram 1.498.482.688 números e encontraram zero diferenças.
Até o "estado do otimizador" (que é como a memória de como o padeiro ajustou a receita conforme avançava) era exatamente o mesmo.

Isso prova que, se você tiver o "cartão de receita" certo (o plano de execução) e começar de um checkpoint limpo (um instantâneo do bolo antes que o ingrediente ruim fosse adicionado), você pode remover dados e obter um resultado que é matematicamente indistinguível de um bolo que nunca deveria ter tido aqueles dados.

O Problema: Não é uma Varinha Mágica

No entanto, o artigo é muito cuidadoso ao não chamar isso de uma "varinha mágica" para deletar dados rapidamente. O autor aponta uma limitação importante: o Tempo.

Se o ingrediente proibido foi adicionado no início do processo de cozimento, ou se os ingredientes estavam espalhados aleatoriamente pela receita, os padeiros precisam voltar e assar quase todo o bolo novamente desde o início para obter o mesmo resultado exato.

Em seus testes, se pedissem para remover 5% aleatórios dos dados, eles tiveram que reproduzir quase 100% das etapas de treinamento.
O artigo afirma explicitamente que isso não estabelece uma "exclusão barata". Não é um conserto rápido; é uma reconstrução lenta e precisa.

O Que Isso NÃO Significa

O autor é muito rigoroso sobre o que seus resultados não provam:

Não é uma garantia comportamental: Só porque os números são idênticos, não significa automaticamente que a IA irá "se comportar" de forma diferente de uma maneira que satisfaça um pedido legal de exclusão. O artigo realizou alguns testes padrão para ver como a IA se comportava, mas eles os tratam apenas como notas "descritivas", não como prova de que o método funciona para exclusão legal no mundo real.
Não é um conserto universal: Isso só funciona se você planejou com antecedência. Você não pode pegar um modelo de IA antigo que não foi construído com este "cartão de receita" especial e magicamente fazê-lo funcionar desta forma depois.
Não é um escudo de privacidade: O artigo admite que, embora os números tenham sido removidos do depósito de reprodução específico, isso não prova que os dados foram apagados de cada backup, cache ou disco rígido no universo.

A Conclusão

Em termos simples, este artigo é uma prova de conceito para um tipo de "esquecimento" muito específico e muito rigoroso. Ele mostra que, se você construir seu processo de treinamento de IA com um plano rígido e imutável e uma maneira de registrar cada etapa, você pode remover dados cirurgicamente e obter um resultado matematicamente perfeito. É como provar que você pode trocar uma fava de baunilha real por uma falsa em uma receita complexa e terminar com um bolo que é indistinguível de um que nunca teve baunilha.

Mas o artigo também nos avisa: este é um processo pesado e lento. Requer planejamento prévio e, se os dados que você deseja remover estiverem espalhados por toda parte, você poderia muito bem simplesmente assar o bolo inteiro novamente. É uma ferramenta poderosa para cientistas que precisam provar exatamente o que aconteceu em um programa de computador, mas ainda não é um botão rápido para deletar dados no mundo real.

Resumo Técnico: Unlearning at Scale: State-Exact Trace-Preserving Deletion in Billion-Parameter Language Models

1. Formulação do Problema

O artigo aborda o desafio do machine unlearning (desaprendizado de máquina) em modelos de linguagem de grande escala (LLMs), reformulando o problema de uma tarefa de otimização comportamental para uma questão de sistemas de estado exato. Enquanto a literatura existente frequentemente define o desaprendizado como a produção de um comportamento de modelo indistinguível de um treinado sem dados específicos, essa abordagem sofre de ambiguidade em pipelines de treinamento determinísticos.

No treinamento moderno, o estado realizado depende não apenas do conjunto de dados, mas dos controles de execução: ordem das amostras, consumo de números pseudoaleatórios (RNG), limites de acumulação de gradiente, cronogramas de taxa de aprendizado e kernels numéricos específicos de hardware. Simplesmente remover dados e retreinar (reempacotamento denso) altera esses controles, resultando em um rastro de execução diferente e um estado final diferente. Consequentemente, "o modelo treinado sem $F$ " não identifica um estado de referência único, a menos que a execução ou a distribuição de referência sejam explicitamente especificadas.

O artigo define um contrafactual de deleção preservador de traço: um cenário onde os controles lógicos da execução de treinamento original (slots de micro-lote, sementes, limites de acumulação, passos do otimizador) permanecem fixos, mas a contribuição de perda dos identificadores solicitados é definida como zero. O objetivo é verificar se um sistema de replay pode reconstruir este estado contrafactual específico bit a bit, mesmo quando as linhas de dados físicos correspondentes aos identificadores deletados estão ausentes do armazenamento de replay.

2. Metodologia

2.1 Definição de Deleção Preservadora de Traço

O autor formaliza uma Deleção Preservadora de Traço ($TD$) onde:

O plano de execução $P$ permanece imutável.
Cada registro de micro-lote é retido, mas os identificadores no conjunto de esquecimento $F$ são mapeados para sequências dummy fixas com peso de amostra zero.
Identificadores retidos, sementes, taxas de aprendizado e índices lógicos de passo do otimizador permanecem inalterados.
Regra do segmento vazio: Nos limites de acumulação de gradiente, ocorre uma transição do otimizador apenas se houver pelo menos uma contribuição ponderada retida naquele segmento. Se um segmento contiver apenas slots de peso zero (deletados), o limite lógico é preservado, mas o passo do otimizador é pulado para evitar alterar os momentos do otimizador (ex: momentos do AdamW) com gradientes zero.

2.2 Design do Sistema

O sistema proposto baseia-se em instrumentação prospectiva e redação física:

Plano de Execução Imutável: A execução de treinamento original registra um plano JSONL contendo identificadores de amostra ordenados, sementes de RNG por micro-lote, taxas de aprendizado e flags de acumulação.
Log de Escrita Antecipada (WAL): Durante o treinamento, um WAL binário compacto de 32 bytes registra o estado da execução (tag de ID ordenado, semente, taxa de aprendizado, índice de passo, flags, CRC32) juntamente com um manifesto de ID ordenado.
Redação Física: Antes do replay, um novo armazenamento de tokens é materializado contendo apenas as linhas retidas. O plano imutável ainda referencia os identificadores deletados como marcadores de slot lógicos.
Mecanismo de Replay: Durante o replay, o sistema intercepta requisições para identificadores deletados. Em vez de buscar os dados ausentes, ele substitui a sequência dummy fixa por peso zero. Isso garante que o micro-lote numérico (tokens, rótulos, pesos) seja idêntico ao oráculo do traço, apesar da ausência física das linhas de dados.

2.3 Protocolo de Verificação

O sistema verifica a Exatidão do Traço comparando o estado terminal do replay redigido contra um Oráculo de Traço executado separadamente. O Oráculo executa a mesma lógica contrafactual (dummies de peso zero) a partir de um checkpoint elegível. A exatidão é definida como parâmetros do modelo ( $\theta$ ) e estados do otimizador ( $\Omega$ ) bit a bit idênticos nos tipos de dados registrados.

3. Principais Contribuições

Definição de Deleção Condicionada à Execução: O artigo formaliza o desaprendizado como um contrafactual preservador de traço, separando a definição do estado alvo do método de alcançá-lo (ex: reempacotamento denso).
Sistema de Replay Prospectivamente Instrumentado: Um sistema que registra a proveniência da execução (WAL + manifesto) e suporta replay a partir de armazenamentos fisicamente redigidos enquanto mantém o controle determinístico dos inputs.
Evidência de Bilhões de Parâmetros Bit-Exata: Demonstração empírica de exatidão de estado em três endpoints:
- Pythia 160M: Exato através de 162M de parâmetros e estado do otimizador para quatro geometrias de deleção (início, meio, fim, aleatória).
- Pythia 2.8B: Exato através de 2,77 bilhões de parâmetros para uma requisição de deleção aleatória de 5%.
- Llama 3.2 1B + TOFU: Exato através de 1,49 bilhão de parâmetros após omitir 400 de 4.000 exemplos.
Análise de Localidade de Replay: Uma análise estrutural mostrando que, embora requisições tardias localizadas permitam um replay de sufixo eficiente, requisições grandes e dispersas forçam quase um replay total, limitando a eficiência computacional desta abordagem para deleções dispersas.
Artefato de Pesquisa Auditável: Lançamento público contendo revisões de código-fonte, hashes de dados, planos de execução e hashes de estado, tratando métricas comportamentais padronizadas (OpenUnlearning) como diagnósticos descritivos, não como evidência causal.

4. Resultados

Exatidão de Estado: Em todos os cenários testados, o replay redigido produziu um estado de modelo e otimizador que era bit a bit idêntico ao oráculo de traço executado separadamente. Isso incluiu correspondências exatas nos momentos do otimizador (estados Adam), que são críticos para a continuidade do treinamento futuro.
Distinção Contrafactual: Experimentos no Pythia 160M confirmaram que o reempacotamento denso (retreinar em $D \setminus F$ com novo loteamento) e a filtragem física (remover linhas antes do forward pass) resultam em diferenças de estado não nulas em relação ao oráculo do traço. Isso valida que "treinar nos dados retidos" não é equivalente a uma "deleção preservadora de traço".
Escalabilidade: O método escalou com sucesso para 2,8 bilhões de parâmetros (Pythia 2.8B) e arquiteturas de diferentes famílias (Llama 3.2), provando que o invariante se mantém em escalas de bilhões de parâmetros sob ambientes de GPU única travados.
Análise de Custo: A proveniência de controle (WAL + manifesto) é pequena em relação aos checkpoints do modelo (0,019% – 0,20%). No entanto, o custo do replay é dependente da localidade. Para uma deleção aleatória de 5% em um modelo de 2.8B, o replay exigiu reiniciar do passo zero, levando quase o mesmo tempo que a execução original. O artigo observa que requisições dispersas forçam estruturalmente quase um replay total.

5. Significância e Alegações

O artigo faz uma contribuição modesta, porém precisa, ao campo do machine unlearning:

Escopo da Alegação: O autor afirma explicitamente que não alega "deleção barata" ou superioridade universal sobre métodos de desaprendizado aproximado (ex: Gradiente Ascendente, NPO). O método requer instrumentação prospectiva e pode incorrer em custos de replay total para requisições dispersas.
Estado vs. Comportamento: O artigo separa rigorosamente a exatidão de estado do esquecimento comportamental. Embora os estados liberados tenham sido avaliados usando o benchmark OpenUnlearning TOFU, o autor trata esses resultados apenas como diagnósticos descritivos. Ele evita explicitamente alegações causais de que a preservação do traço causa comportamentos de esquecimento específicos, citando a falta de controles correspondentes (ex: uma linha de base de apenas dados retidos e métricas pré-ajuste fino).
Auditável: A principal significância é o estabelecimento de uma definição algorítmica auditável de deleção. Ao fixar o contrato de execução e provar a igualdade bit a bit com um contrafactual declarado, o sistema fornece uma garantia verificável de que um traço de execução específico foi neutralizado, distinta de alegações sobre a ausência de dados ao nível de parâmetros.
Limitações: O autor reconhece que o método não garante a deleção de backups, caches ou outras camadas de armazenamento, nem satisfaz obrigações legais (ex: GDPR Artigo 17) por si só. É um primitivo de sistema para reconstruir um estado histórico específico, não uma solução de política de uso geral.

Em resumo, o artigo demonstra que a exatidão de estado em bilhões de parâmetros é alcançável para um contrafactual de deleção específico e preservador de traço, desde que o sistema de treinamento seja instrumentado prospectivamente e o ambiente de execução seja travado. Estabelece que o "desaprendizado" deve ser definido pelo programa contrafactual específico sendo executado, não apenas pelo conjunto de dados retidos.