Desaprendizado de Máquina (Machine Unlearning)

O que é Desaprendizado de Máquina?

desaprendizado de máquina (machine unlearning) é o conjunto de técnicas usadas para remover a influência de dados específicos de treinamento de um modelo de aprendizado de máquina (machine learning) treinado (muitas vezes já implantado). O motivador mais comum é a conformidade com direitos de exclusão de dados (por exemplo, o “direito ao apagamento” (right to erasure) do GDPR ou a LGPD do Brasil), mas o desaprendizado também é relevante para segurança (remover registros envenenados), segurança operacional (remover conteúdo nocivo) e governança (aplicar políticas de retenção (retention policies)).

Informalmente, se um modelo foi treinado no conjunto de dados (D) e, mais tarde, precisamos excluir um subconjunto (D_f) (o “conjunto de esquecimento” (forget set)), o desaprendizado busca produzir um novo modelo que se comporte como se tivesse sido treinado em (D \setminus D_f) — sem necessariamente pagar o custo total de treinar do zero.

Na prática, o desaprendizado abrange um espectro:

Desaprendizado exato (exact unlearning): O modelo atualizado é (quase) idêntico a um modelo retreinado do zero em (D \setminus D_f).
Desaprendizado aproximado (approximate unlearning): O modelo é “próximo o suficiente” sob métricas escolhidas, com influência residual limitada.
Desaprendizado funcional (functional unlearning): O modelo pode não corresponder ao retreinamento, mas não reproduz nem explora o conteúdo/registro específico de forma significativa (comum em cenários de modelos de linguagem de grande porte quando a exatidão é inviável).

O desaprendizado de máquina faz parte dos controles operacionais de IA Responsável (Responsible AI), junto com Governança de IA, Auditorias e Documentação, Avaliações de Risco e processos de transparência como Relato de Incidentes e Transparência.

Por que o desaprendizado importa (motivos legais, de segurança e de produto)

Regimes de proteção de dados podem exigir que organizações excluam dados pessoais mediante solicitação e deixem de processá-los. Para sistemas de ML, surgem perguntas:

Se o registro de um usuário foi usado para treinar um modelo, excluí-lo do armazenamento é suficiente?
Ou os parâmetros do modelo (e quaisquer artefatos downstream) também precisam ser atualizados para remover essa influência?

A interpretação mais rígida de “apagamento” para ML sugere que o modelo não deve continuar refletindo a informação apagada de um modo que afete resultados de forma significativa para esse usuário ou para outros. Na prática, equipes frequentemente adotam uma abordagem baseada em risco (risk-based approach) alinhada a estruturas de governança (ver Estrutura de Gestão de Riscos em IA do NIST) e aos detalhes da lei e às expectativas do regulador (ver LGPD (Brasil) para Sistemas de IA).

Segurança e integridade: removendo dados envenenados ou tóxicos

Se um exemplo de treinamento é identificado como malicioso (envenenamento de dados (data poisoning)) ou violador de política, o desaprendizado pode fazer parte da resposta a incidentes (incident response):

Remover pontos envenenados que induzem backdoors (ver Envenenamento de Dados).
Remover conteúdo protegido por direitos autorais ou não permitido.
Remover exemplos de treinamento que causam saídas inseguras.

Políticas de retenção e higiene do ciclo de vida do modelo

Mesmo sem solicitação de um usuário, organizações podem precisar aplicar:

minimização de dados (data minimization)
limites de retenção baseados em tempo
obrigações contratuais de exclusão (fornecedores, parceiros)
descontinuação de conjuntos de dados (por exemplo, dados coletados sob uma política antiga de consentimento)

O desaprendizado se torna a ponte operacional entre a governança de dados e o comportamento do modelo.

O que significa “remover influência”, exatamente?

O alvo ideal: equivalência ao retreinamento

A definição conceitual mais limpa é:

Após desaprender (D_f), o modelo resultante deve ser indistinguível de um modelo treinado do zero em (D \setminus D_f), usando o mesmo procedimento de treinamento.

Isso é forte — e, para aprendizado profundo (deep learning), muitas vezes caro ou impraticável.

Definições práticas: métricas e residuais aceitáveis

Equipes normalmente definem o que querem dizer por remoção usando critérios mensuráveis:

Distância de parâmetros (parameter distance): Os pesos estão próximos de uma linha de base retreinada (baseline) (se disponível)?
Distância de saída (output distance): As previsões/logits diferem da linha de base retreinada dentro de uma tolerância?
Testes comportamentais (behavioral tests): O modelo ainda reproduz texto excluído ou memoriza um registro específico?
Resistência a ataques de privacidade (privacy attack resistance): A remoção reduz o sucesso de Ataques de Inferência de Associação ou Ataques de Inversão de Modelo?
Regressão em nível de tarefa (task-level regression): A qualidade geral permanece aceitável?

Esses critérios devem ser documentados nos artefatos de conformidade do modelo (ver Cartões de Modelo e Cartões de Sistema).

A granularidade importa: o que estamos esquecendo?

Os alvos de desaprendizado variam muito:

Um único registro (uma linha de um usuário)
Todos os registros de um usuário (múltiplas linhas, sessões, dispositivos)
Um documento (por exemplo, uma página web em um corpus)
Uma classe de dados (por exemplo, um atributo sensível)
A contribuição de uma execução de treinamento (por exemplo, remover os dados de um cliente em Aprendizado Federado)

Seu pipeline deve suportar linhagem de dados (data lineage) para identificar o que foi usado e por onde fluiu (bruto → limpo → transformado em atributos (featurized) → amostrado → treinado → destilado).

Abordagem de referência: retreinamento (ainda o padrão-ouro)

Retreinamento completo do zero

retreinamento (retraining) do modelo em (D \setminus D_f) é o mais simples conceitualmente e, em geral, o mais forte em termos de auditabilidade (auditability):

Prós: Narrativa clara, mais próximo de “como se nunca tivesse sido treinado com isso”.
Contras: Caro; pode levar dias para modelos profundos grandes; pode interromper cronogramas de implantação; pode exigir recomputar atributos.

Isso permanece como padrão para muitos cenários de alto impacto, onde o volume de exclusões é baixo e o treinamento do modelo é administrável.

Retreinamento a partir de um ponto de verificação pré-exclusão

Se você mantém pontos de verificação (checkpoints) (instantâneos dos pesos) durante o treinamento, às vezes é possível evitar o retreinamento completo:

Identifique o ponto de verificação mais cedo antes de o conjunto de esquecimento ter sido introduzido (ou antes de sua influência principal se acumular).
Retome o treinamento a partir dele com os dados filtrados.

Isso funciona melhor quando a ordem de treinamento e a ingestão de dados são bem controladas. Exige registro cuidadoso para provar que o conjunto de esquecimento não foi usado antes do ponto de verificação.

Exemplo: pipeline “filtrar e retreinar” (aprendizado supervisionado clássico)

# Pseudocode: dataset filtering + retraining
forget_user_id = "u_123"

D = load_training_table()
D_filtered = D[D.user_id != forget_user_id]

model = Model()
model.train(D_filtered)

save_model(model, version_tag="no_u_123")
log_unlearning_event(user_id=forget_user_id, model_version="no_u_123")

Na prática, você também precisará excluir ou reconstruir:

atributos em cache,
arquivos de treinamento fragmentados (sharded),
índices de amostragem,
conjuntos de avaliação (se contiverem os dados excluídos),
modelos derivados (modelos aluno destilados, ensembles).

Estratégias comuns de desaprendizado além do retreinamento

1) Filtragem de dados para sistemas não paramétricos e modulares

Alguns sistemas são naturalmente “desaprendíveis” porque armazenam diretamente os dados de treinamento:

classificadores de k-vizinhos mais próximos (k-NN / nearest neighbor classifiers)
métodos de kernel (kernel methods) com vetores de suporte armazenados (support vectors) (depende da implementação)
Geração Aumentada por Recuperação (Retrieval-Augmented Generation, RAG) com um banco de dados vetorial (vector database)

Para esses, “desaprender” pode ser tão simples quanto excluir registros do armazenamento e fazer reindexação (reindexing):

Remover a incorporação (embedding) do documento do BD vetorial.
Garantir que não esteja presente em caches ou réplicas.
Reconstruir o índice, se necessário.

Isso costuma ser a forma mais prática de atender solicitações de exclusão em produtos de modelos de linguagem de grande porte: manter o modelo de base fixo e garantir que a camada de recuperação não apresente mais o conteúdo excluído.

2) SISA e retreinamento baseado em fragmentos (treinamento particionado)

Uma abordagem conhecida é treinar em fragmentos (shards) e fatias (slices) (frequentemente chamada de SISA: Fragmentado, Isolado, Fatiado e Agregado (Sharded, Isolated, Sliced, and Aggregated)):

Particionar os dados de treinamento em fragmentos independentes.
Treinar submodelos separados por fragmento (ou por fatia ao longo do tempo).
Combiná-los em um ensemble de modelos (ensemble) ou preditor agregado.

Para esquecer um registro, retreine apenas o(s) fragmento(s) que o continham.

Prós: Grande economia quando as exclusões são pequenas em relação aos dados.
Contras: Exige planejamento e mudanças na arquitetura de treinamento; pode prejudicar a acurácia em comparação a um único modelo monolítico; complexidade de servir ensembles.

Essa abordagem se alinha bem a objetivos de governança porque cria uma trilha de auditoria clara de dados → fragmento → componente do modelo.

3) Desaprendizado exato/eficiente para modelos convexos (quando disponível)

Para alguns modelos (por exemplo, regressão linear, regressão logística, regressão ridge), o objetivo de treinamento é convexo (convex), e atualizações às vezes podem ser computadas de forma eficiente:

Usar estatísticas suficientes (sufficient statistics) (como (X^\top X), (X^\top y)) para “subtrair” contribuições.
Usar métodos de otimização incremental (incremental optimization methods) para convergir rapidamente após a exclusão.

Isso pode oferecer garantias fortes e é uma boa opção para ambientes regulados ou sensíveis a custo — se a classe de modelo for adequada à tarefa.

4) Funções de influência e aproximações de segunda ordem (desaprendizado aproximado)

funções de influência (influence functions) estimam como os parâmetros do modelo mudariam se um ponto de treinamento fosse removido, usando gradientes e Hessianas inversas (aproximadas) (inverse Hessians).

Ideia de alto nível:

Computar gradientes da perda para o conjunto de esquecimento.
Estimar a mudança de parâmetros que “desfaria” sua contribuição.
Aplicar uma atualização corretiva sem retreinamento completo.

Prós:

Potencialmente muito mais barato do que retreinar.
Pode suportar exclusão por registro.

Contras:

Requer aproximações que podem ser instáveis para redes profundas.
Muitas vezes é sensível a hiperparâmetros (hyperparameters) e ao condicionamento (conditioning).
Difícil de auditar como “equivalente ao retreinamento” em modelos não convexos.

5) Ajuste fino para “esquecer” (ascensão de gradiente / treinamento negativo) em redes profundas e modelos de linguagem de grande porte

Uma família pragmática de métodos tenta reduzir a probabilidade de o modelo produzir o conteúdo esquecido executando atualizações direcionadas:

Treinar nos exemplos a esquecer com um objetivo negativo (negative objective) (por exemplo, ascensão de gradiente (gradient ascent) na verossimilhança deles).
Opcionalmente adicionar um conjunto de retenção (retain set) para preservar a capacidade geral (regularizar em direção ao comportamento original em dados fora do conjunto de esquecimento).

Isso é comum em pesquisas de desaprendizado em modelos de linguagem de grande porte porque o retreinamento completo muitas vezes é inviável.

Trade-offs:

Pode reduzir memorização direta (“não produza este texto”).
Não necessariamente remove influência estatística sutil.
Pode introduzir efeitos colaterais (mudanças inesperadas de comportamento, redução de qualidade ou novos modos de falha).

6) Desaprendizado “localizado” eficiente em parâmetros (adaptadores, adaptação de baixa classificação, cabeças)

Se seu sistema usa ajuste fino eficiente em parâmetros (parameter-efficient fine-tuning) (adaptadores (adapters)/adaptação de baixa classificação (Low-Rank Adaptation, LoRA)) sobre um modelo base congelado (frozen base model), às vezes é possível desaprender por:

Remover ou retreinar apenas os pesos do adaptador que foram ajustados no conjunto de esquecimento.
Manter o modelo base inalterado.

Isso fornece uma fronteira de governança clara: “os dados pessoais só influenciaram o adaptador”, que pode ser excluído e reconstruído.

Desaprendizado em sistemas implantados de modelos de linguagem de grande porte: o que é realista hoje?

Para modelos de linguagem de grande porte grandes e de uso geral, o desaprendizado exato no nível do modelo de base (foundation model) geralmente não é realista, a menos que você controle todo o pipeline de treinamento e consiga arcar com retreinamentos parciais.

Em produção, o desaprendizado normalmente se concentra em onde os dados residem:

Camada de RAG/ferramentas: Excluir o documento do índice de recuperação (retrieval index), caches e backups.
Camada de ajuste fino: Se você ajustou finamente com dados de usuários, excluir e retreinar o ajuste fino (ou adaptador) sem esses dados.
Registro e telemetria (logging / telemetry): Remover rastros de treinamento (logs de prompts (prompt logs) usados para treinamento), conjuntos de dados derivados e artefatos de avaliação.
Camadas de segurança e política: Garantir que o sistema não reproduzirá conteúdo excluído mesmo quando provocado.

Uma lição operacional-chave: se você quer garantias práticas de exclusão, projete para separabilidade (por exemplo, manter conteúdo do usuário em armazenamentos recuperáveis em vez de “incorporá-lo permanentemente” nos pesos do modelo de base).

Verificação: como saber se o desaprendizado funcionou?

verificação (verification) é uma das partes mais difíceis. Em geral, você não consegue provar que um modelo profundo tem zero influência residual de um registro. Em vez disso, você desenha um plano de verificação defensável.

Técnicas comuns de verificação

Comparação com linha de base de retreinamento (se viável): Treinar um modelo “ouro” em (D \setminus D_f) e comparar saídas ou distribuições.
Testes de canário direcionados (targeted canary tests): Se o conjunto de esquecimento é uma string/documento específico, testar se o modelo ainda consegue reproduzi-lo sob vários prompts.
Teste de inferência de associação: Executar inferência de associação antes/depois; um desaprendizado bem-sucedido deve reduzir a vantagem do atacante (ver Ataques de Inferência de Associação).
Testes de extração/regurgitação para modelos de linguagem de grande porte (extraction/regurgitation tests): Sondar com paráfrases e prefixos parciais; medir correspondência exata ou similaridade semântica (semantic similarity).
Suíte de regressão downstream (downstream regression suite): Garantir que o comportamento fora do conjunto de esquecimento permaneça dentro de limites aceitáveis.

Requisitos de auditabilidade

Para governança e conformidade, você normalmente precisa de:

Um registro da solicitação (o que excluir, por quê, quando)
Linhagem do conjunto de dados e onde o registro apareceu
O método usado (retreinamento, retreinamento de fragmento, atualização aproximada)
Versões do modelo e hashes
Evidências de verificação e aprovação formal (sign-off)

Isso se alinha diretamente às práticas de Auditorias e Documentação e deve alimentar Cartões de Sistema.

Aviso prático: não determinismo complica “equivalência”

O treinamento em aprendizado profundo frequentemente é não determinístico (nondeterminism) devido a:

kernels de GPU
precisão mista (mixed precision)
ordem de dados distribuída
sementes aleatórias

Assim, mesmo o retreinamento completo pode não produzir pesos idênticos. Sua política deve definir equivalência aceitável em termos de saídas e risco, não de identidade bit a bit (bitwise identity).

Como o desaprendizado se relaciona a ataques de privacidade e privacidade diferencial

Ataques de privacidade revelam memorização e influência

O desaprendizado está intimamente ligado à privacidade porque muitos ataques de privacidade exploram a influência dos dados de treinamento:

Inferência de associação: “Este registro estava no conjunto de treinamento?”
Inversão de modelo: “Consigo reconstruir atributos sensíveis?”
Extração de dados de treinamento: “Consigo recuperar sequências memorizadas de um modelo de linguagem de grande porte?”

Se seu modelo é vulnerável a isso, solicitações de exclusão se tornam mais urgentes e mais complexas: mesmo um pequeno grau de memorização pode criar exposição significativa.

Privacidade diferencial pode reduzir a necessidade de desaprendizado (mas não a elimina)

Treinar com Privacidade Diferencial (por exemplo, DP-SGD) limita a influência de qualquer registro individual, o que pode:

reduzir memorização,
reduzir risco de inferência de associação,
tornar solicitações de exclusão mais fáceis de tratar em uma estrutura baseada em risco.

No entanto:

Privacidade diferencial é uma garantia no momento de treinamento e pode degradar a utilidade do modelo.
Privacidade diferencial não satisfaz automaticamente um requisito estrito de “como se nunca tivesse sido treinado”.
Você ainda pode precisar excluir dados de logs, caches e armazenamentos de RAG.

Em alguns programas de governança, privacidade diferencial é posicionada como um controle preventivo (preventive control), enquanto o desaprendizado é um controle corretivo (corrective control).

Considerações operacionais e armadilhas

1) Linhagem de dados e “cópias ocultas”

Uma solicitação de exclusão frequentemente falha na prática porque o registro existe em muitos lugares:

tabelas brutas de ingestão
conjuntos de dados limpos
repositórios de atributos (feature stores)
fragmentos de treinamento em armazenamento de objetos
dataloaders em cache
artefatos de rastreamento de experimentos
conjuntos de dados de avaliação
logs de prompts usados para ajuste fino
índices vetoriais e suas réplicas
backups e cópias de recuperação de desastres

Um programa robusto trata o desaprendizado como um problema de sistema, e não apenas como uma atualização de modelo.

2) Modelos derivados e dependências downstream

Se você treinou:

um modelo destilado,
um modelo de incorporações usado por outros produtos,
um componente de ensemble,
um reordenador (reranker),
um classificador de segurança, talvez seja necessário desaprender ao longo do grafo de dependências (dependency graph).

Por isso, fluxos de trabalho de exclusão devem ser integrados à Governança de IA geral.

3) Objetivos de nível de serviço (SLOs) e custo

O desaprendizado pode exigir:

capacidade de retreinamento sob demanda,
implantações em etapas (staged rollouts),
testes em sombra (shadow testing),
planos de reversão (rollback).

Organizações frequentemente definem categorias (tiers):

Nível 1 (alto risco): retreinar ou retreinar fragmentos com verificação forte
Nível 2 (risco médio): desaprendizado aproximado + suíte de verificação
Nível 3 (baixo risco): excluir de armazenamentos e logs; sem atualização de modelo

4) Modelos multitenant e influência “misturada”

Um modelo compartilhado treinado com dados de muitos usuários torna a exclusão por usuário mais difícil. Mitigações arquiteturais incluem:

isolar dados de usuário em armazenamentos de RAG,
usar adaptadores por locatário (tenant),
treinar modelos por locatário para implantações de alta sensibilidade.

5) “Desaprendizado” vs “recusa”

Para modelos de linguagem de grande porte, um atalho tentador é adicionar uma regra de segurança: “Recusar responder sobre X.” Isso não é a mesma coisa que desaprender:

A recusa controla saídas sob alguns prompts.
O modelo ainda pode conter e usar a informação internamente ou vazá-la via jailbreaks (jailbreaks). A recusa pode ser uma mitigação temporária, mas não deve ser apresentada como exclusão.

Um fluxo de trabalho prático de desaprendizado (roteiro)

1) Recebimento e triagem

Identificar o sujeito (ID de usuário, ID de documento, chaves de registro (record keys)).
Confirmar base legal e escopo (GDPR/LGPD; ver LGPD (Brasil) para Sistemas de IA).
Determinar quais sistemas usaram os dados: treinamento, ajuste fino, RAG, analytics.

2) Classificar o modelo e escolher uma estratégia

Perguntas para decidir o método:

O modelo é retreinável dentro da janela de tempo exigida?
Os dados são armazenados diretamente (RAG/k-NN) vs incorporados aos pesos (baked into weights)?
Temos treinamento fragmentado que permite retreinamento parcial?
O desaprendizado aproximado é aceitável para o nível de risco?

3) Executar a exclusão em todo o plano de dados

Excluir dos armazenamentos primários, repositórios de atributos e índices.
Purgar caches.
Tratar backups conforme a política (frequentemente “excluir na restauração” (delete on restore) + retenção limitada (bounded retention), documentado explicitamente).

4) Atualizar o modelo (se necessário)

Opções:

retreinar completamente,
retreinar fragmentos afetados,
retreinar adaptadores,
aplicar atualização aproximada de desaprendizado.

5) Verificar e documentar

Executar a suíte de verificação (testes comportamentais + orientados à privacidade).
Registrar evidências, versões de modelo e aprovação.
Atualizar Cartões de Modelo / Cartões de Sistema se relevante.
Se o desaprendizado foi acionado por um incidente (envenenamento, vazamento), seguir Relato de Incidentes e Transparência.

Limites e desafios em aberto

Não convexidade e escala (non-convexity and scale): Modelos profundos não têm atualizações exatas de desaprendizado simples; desaprendizado eficiente e comprovável continua sendo uma área ativa de pesquisa.
Definir “influência”: Mesmo que um modelo não consiga reproduzir um registro literalmente, ele ainda pode ser influenciado estatisticamente por ele.
A verificação é adversarial: Atacantes podem encontrar prompts que evocam conteúdo memorizado apesar de o modelo passar em testes padrão.
Problemas de cadeia de suprimentos: Se você depende de modelos de base de terceiros, pode não conseguir desaprender dos pesos base — empurrando você para separação arquitetural (RAG, adaptadores) e controles contratuais.

Principais aprendizados

O desaprendizado de máquina trata de fazer um modelo em produção se comportar como se registros específicos de treinamento nunca tivessem sido usados — motivado por leis de privacidade, incidentes de segurança e governança de retenção.
retreinamento (total ou parcial) é a abordagem mais defensável, mas pode ser custosa.
Sistemas práticos frequentemente combinam:
- exclusão de armazenamentos de dados (especialmente RAG/BDs vetoriais),
- treinamento modular (fragmentos, adaptadores),
- desaprendizado aproximado para modelos profundos,
- verificação forte e trilhas de auditoria.
O desaprendizado deve ser projetado como parte de um programa mais amplo de IA Responsável, com documentação clara e controles operacionais (ver Auditorias e Documentação, Avaliações de Risco e Estrutura de Gestão de Riscos em IA do NIST).