Como os LLMs calculam de verdade

Conhecer a arquitetura de um Transformer não é o mesmo que saber o que um modelo treinado faz. A arquitetura define o formato do cálculo; o treino preenche bilhões de parâmetros com estratégias que ninguém projetou e que precisam ser descobertas depois, por investigação.

A analogia usada pela própria Anthropic é biológica: o modelo é cultivado, não construído, e estudar seus mecanismos internos se parece mais com microscopia do que com leitura de código-fonte. A linha de pesquisa que faz isso é a interpretabilidade, e ela desenvolveu ferramentas para rastrear quais circuitos internos se ativam durante uma resposta específica.

Para o seu objetivo como usuário avançado, esse é o material mais valioso que existe. Ele substitui suposições sobre o comportamento do modelo por evidência sobre o mecanismo.

O caso mais didático documentado pela Anthropic é uma soma simples, 36 mais 59. Rastreando os circuitos internos, os pesquisadores encontraram não um algoritmo, mas dois caminhos rodando ao mesmo tempo.

Um caminho é aproximado: estima grosseiramente a magnitude do resultado, algo como perto de noventa e cinco. O outro é preciso e estreito: calcula com exatidão o último dígito da soma. Os dois se combinam no final para produzir a resposta correta.

Nada nessa estratégia se parece com o algoritmo escolar de somar coluna por coluna com transporte. O modelo inventou um método próprio, adequado à maquinaria de que dispõe, e ninguém o ensinou a fazer assim.

O achado seguinte é o mais importante para quem usa modelos profissionalmente. Perguntado sobre como chegou ao resultado, o modelo descreve o algoritmo escolar, com unidades, dezenas e transporte. Ou seja, descreve um método que ele demonstravelmente não usou.

A explicação não é mentira no sentido intencional. O modelo aprendeu, dos textos humanos, como se explica uma soma, e essa explicação é o que ele produz quando o pedido é explicar. O circuito que calcula e o circuito que explica são diferentes.

A consequência prática é direta e vale para muito além de aritmética: a explicação que um modelo dá do próprio raciocínio é uma saída gerada como qualquer outra, não um registro de execução. Ela pode ser fiel, e frequentemente é útil, mas não é auditoria. Trate raciocínio verbalizado como evidência fraca sobre o processo interno, e verifique conclusões pelo resultado, não pela narrativa.

Dois outros achados da mesma linha de pesquisa reorganizam a intuição comum. O primeiro: ao escrever versos com rima, o modelo ativa candidatos de palavra final antes de começar a linha, e depois constrói a frase para chegar até eles. Isso contraria a imagem do modelo como puro previsor míope de um token por vez; há planejamento em algum horizonte.

O segundo: os mesmos circuitos internos se ativam para um conceito independentemente do idioma em que a pergunta é feita. Há indício de um espaço conceitual compartilhado entre línguas, com a tradução para o idioma de saída acontecendo em uma etapa posterior. É por isso que conhecimento adquirido em um idioma transfere para outro.

Ambos os achados justificam a mesma postura: a previsão do próximo token é a interface de treino, não a descrição completa da computação interna.

Primeira razão, a tokenização. Números são fatiados em pedaços arbitrários e o modelo nunca vê quantidade, vê símbolos. Já detalhado no M5, e é a raiz mais concreta.

Segunda razão, a ausência de laço. Uma passagem pelo modelo tem profundidade fixa, um número fixo de camadas. Algoritmos exatos com muitos passos, como multiplicação longa, exigiriam iteração que a arquitetura não oferece dentro de uma única passagem. É por isso que escrever o raciocínio passo a passo ajuda de verdade: o texto gerado vira a memória de trabalho externa que a arquitetura não tem.

Terceira razão, a natureza dos caminhos encontrados. Estratégias aproximadas funcionam bem na faixa de números que apareceu com frequência no treino e degradam fora dela. Números grandes ou incomuns caem justamente nessa borda.

Quarta razão, a amostragem. Mesmo com o cálculo interno correto, temperatura acima de zero pode sortear um token de dígito diferente. Para tarefas exatas, temperatura baixa é decisão técnica, não estilística.

Regra operacional que decorre disso: para aritmética que importa, peça o passo a passo, use temperatura baixa e prefira que o modelo chame uma ferramenta de cálculo em vez de calcular internamente.

A prova final do projeto é narrar este caminho sem consultar nada. Ele tem onze etapas, e você já viu cada uma delas.

O texto entra e é fatiado pelo tokenizador em índices inteiros. Cada índice busca uma linha na matriz de embeddings, produzindo um vetor de dimensão d. A codificação posicional é somada para que a ordem exista. O vetor entra no primeiro bloco, onde é normalizado e projetado em consulta, chave e valor por três matrizes aprendidas. As pontuações de atenção saem do produto escalar entre consultas e chaves, escaladas pela raiz de d k e mascaradas para o futuro. O softmax converte cada linha de pontuações em pesos que somam um, e esses pesos produzem uma média ponderada dos valores. O resultado é somado de volta à entrada pela conexão residual. O MLP processa cada posição isoladamente, expandindo, aplicando não linearidade e comprimindo, com nova conexão residual. Esse bloco se repete dezenas de vezes. Ao final, o estado da última posição é multiplicado pela matriz de saída, produzindo um logit por token do vocabulário. O softmax com temperatura transforma logits em probabilidades, top-k ou top-p corta a cauda, e um token é sorteado. O token é anexado à sequência e tudo recomeça.

Quando você conseguir dizer isso em voz alta, com suas palavras, sabendo o que cada operação faz e por quê, o Projeto Axioma cumpriu o que prometeu.