Interpretabilidade mecanicista, um guia prático

§ 01 · A premissa

Engenharia reversa, não caixa-preta

Um transformer treinado é um programa escrito na linguagem de multiplicações matriciais. A interpretabilidade mecanicista trata esse programa como legível: o objetivo é recuperar o algoritmo que a rede implementa, não apenas descrever as saídas.

A unidade de análise é o circuito — um pequeno subgrafo de attention heads, neurônios MLP e direções do fluxo residual que juntos executam uma computação identificável, como detectar um objeto indireto ou copiar um token anterior.

§ 02 · O problema da polissemanticidade

Por que neurônios individuais raramente significam uma coisa só

Neurônios em modelos de linguagem disparam para conceitos não relacionados — um mesmo neurônio MLP pode ativar em código Python, poesia francesa e tickers da bolsa. Isso é superposição: o modelo empacota mais features do que tem dimensões, atribuindo a cada feature uma direção, não um neurônio.

Ler o modelo neurônio a neurônio, portanto, falha. A base correta não é a canônica; precisa ser descoberta.

§ 03 · Sparse autoencoders (SAEs)

Como desempacotar superposição na prática

Um sparse autoencoder é uma pequena rede sobrecompleta treinada para reconstruir as ativações de uma camada a partir de uma camada oculta muito mais larga, com penalidade L1. A camada oculta aprende um dicionário de features que, empiricamente, são quase monossemânticas: uma dimensão para "parêntese não balanceado", outra para "Ponte Golden Gate", outra para "usuário está pedindo conselho médico".

Uma receita viável: (1) colete ativações de um fluxo residual intermediário em ~10⁸ tokens; (2) treine um SAE com ~16–64× a largura da camada e um coeficiente L1 ajustado para 30–80 features ativas por token; (3) rotule os exemplos que mais ativam cada feature com um LLM pequeno; (4) valide ablando a feature e medindo a mudança nos logits downstream.

• §Perda de reconstrução + esparsidade L1 é o objetivo base; SAEs gated e top-k melhoram o trade-off fidelidade/esparsidade.
• §Feature splitting: alargar o dicionário tende a dividir features grossas em finas. Escolha a largura pela tarefa, não por uma regra universal.
• §Features mortas são comuns — monitore a fração de features que nunca disparam e faça pruning ou reinicialização.

§ 04 · Análise de circuitos

De features a algoritmos

Uma vez que se nomeia features, é possível traçar como se compõem. A análise de circuitos identifica quais attention heads e MLPs movem quais features pelo fluxo residual para produzir um comportamento específico. O exemplo canônico é o circuito de identificação de objeto indireto (IOI) no GPT-2 small — uma cadeia de name-movers, S-inhibition e duplicate-token heads que responde "Mary and John went to the store, John gave a drink to ___".

O fluxo é: escolha uma tarefa estreita, defina uma métrica (por exemplo, diferença de logit entre o token correto e um distrator) e enumere os componentes que afetam materialmente a métrica. Tudo que você não consegue abladar sem quebrar o comportamento faz parte do circuito.

§ 05 · Activation patching

O teste causal que separa correlação de mecanismo

Activation patching executa o modelo duas vezes em duas entradas — um prompt limpo e um corrompido — e copia a ativação de uma posição da execução limpa para a corrompida. Se a saída volta em direção à resposta limpa, aquela posição carrega causalmente a informação; se nada muda, não carrega, independentemente do que um probe indicou.

Path patching é a variante mais precisa: em vez de patchear todo efeito downstream, você patcheia apenas o caminho através de uma aresta específica do grafo, isolando qual conexão head-a-head ou head-a-MLP está de fato sendo usada.

• §Denoising: injete ativações limpas numa execução corrompida. Diz o que é suficiente.
• §Noising (ablação): substitua ativações limpas por corrompidas ou pela média. Diz o que é necessário.
• §Attribution patching: aproximação de primeira ordem (Taylor) que evita O(N) forward passes e escala para modelos inteiros.

§ 06 · Probes e seus limites

Úteis, mas apenas correlacionais

Um probe linear é um classificador treinado sobre ativações congeladas para prever uma propriedade — sentimento, veracidade, a posição de uma peça no tabuleiro. Alta acurácia do probe mostra que a informação é linearmente legível naquela camada.

Não mostra que o modelo usa essa informação. Um probe na camada 8 pode ler "a resposta é B" perfeitamente enquanto a computação real do modelo ignora essa direção e deriva a resposta em outro lugar. Confirme com activation patching antes de tirar conclusões mecanicistas.

§ 07 · Um how-to mínimo

Lendo um comportamento ponta a ponta

O que segue é um pipeline compactado para ir de "o modelo faz X" a "aqui está o circuito que implementa X":

• §1. Defina X como uma métrica sobre logits (não uma sensação). Monte um dataset pareado de prompts limpos e corrompidos que diferem só em X.
• §2. Rode activation patching por camadas e posições para localizar onde o efeito vive.
• §3. Aprofunde com path patching para identificar as heads e MLPs específicas no caminho causal.
• §4. Decodifique esses componentes com um SAE para nomear as features que lêem e escrevem.
• §5. Valide escrevendo o algoritmo em prosa, prevendo novos inputs que ele deve e não deve tratar, e testando.

§ 08 · Por que alinhamento se importa

Interpretabilidade como instrumento de segurança

Se conseguirmos identificar uma feature para "o usuário está tentando um jailbreak", "estou sendo avaliado" ou "eu ganharia recursos mentindo aqui", ganhamos uma superfície de monitoramento que avaliações comportamentais não oferecem — que dispara antes do token danoso ser emitido.

As questões abertas são duras: features encontradas hoje não estão garantidas em modelos maiores amanhã; dicionários de SAE deslizam sob fine-tuning; e um modelo ciente de que está sendo interpretado pode, em princípio, contornar o probe. Interpretabilidade mecanicista é uma ferramenta necessária para o alinhamento, não um problema resolvido.