Antes do Q, K e V: Reconstruindo o Transformer a partir de princípios fundamentais

Por que a arquitetura Transformer não é arbitrária

Muita gente aprende sobre Transformers com a metáfora clássica: “cada token faz uma pergunta (query) e recebe respostas (keys) que são ponderadas (values)”. Funciona como analogia, mas não explica por que Q, K e V são necessários. A arquitetura poderia ser diferente? Ou esses conceitos abstratos são inevitáveis?

Um artigo profundo publicado no Towards Data Science reconstrói o Transformer a partir de princípios fundamentais — e mostra que o formato geral da arquitetura é, sim, difícil de evitar. Sem depender de analogias, o autor demonstra que as queries surgem de um problema de simetria, enquanto values e attention heads aparecem quando substituímos uma matriz de pesos dinâmica e impraticável por um conjunto pequeno de transformações reutilizáveis.

A pergunta central: “Do we really need keys, queries, values, and dot product attention?” — Nós realmente precisamos de chaves, consultas, valores e atenção por produto escalar?

O problema da memória fixa das RNNs

Antes dos Transformers, as redes neurais recorrentes (RNNs) eram o padrão para processamento sequencial. Mesmo com variantes avançadas como as LSTMs, que resolvem o problema do gradiente que desaparece, todas as RNNs compartilham uma limitação fundamental: elas “comprimem” entradas passadas em uma memória de tamanho fixo.

Imagine codificar a frase “eu tenho cinco dólares” na memória de uma RNN. Se depois você adicionar “mas perdi dois”, a memória precisa ser sobrescrita — e a informação original sobre os “cinco dólares” se degrada. É como tentar guardar um romance inteiro em um post-it.

Essa limitação levou à pergunta que deu origem aos Transformers: e se cada token pudesse acessar diretamente todos os tokens anteriores, sem passar por um gargalo de memória fixa?

Atenção: o acesso direto entre tokens

A grande sacada do mecanismo de atenção é permitir que cada token “olhe” para todos os outros tokens da sequência. Mas isso cria um problema imediato: os tokens são representados como vetores, e comparar vetores diretamente não captura relações semânticas.

É aqui que entram as projeções lineares — matrizes que transformam o vetor do token em diferentes “espaços” de representação. A pergunta que o artigo explora é: por que exatamente essas projeções específicas?

De onde vêm as Queries e Keys

O autor mostra que queries e keys surgem de um requisito de simetria. Quando dois tokens interagem — digamos, o token A prestando atenção no token B — a força dessa interação precisa fazer sentido independentemente da direção. Se A é relevante para B, essa relação deve ser capturada de forma consistente.

Isso exige que calculemos similaridades usando duas projeções separadas: uma para o token que “pergunta” (query) e outra para o token que “responde” (key). O produto escalar entre Q e K satisfaz essa simetria, mas as matrizes individuais permitem que o modelo aprenda o que perguntar e como responder para cada token.

Sem essa separação Q/K, o modelo estaria preso a uma similaridade fixa entre as representações originais dos tokens — o que funcionaria mal para capturar os diferentes papéis que uma mesma palavra pode ter em contextos diferentes.

Values: a peça que faltava

Se queries e keys resolvem quanto de atenção cada par de tokens merece, os values resolvem o que transmitir. O artigo mostra que os values surgem naturalmente quando tentamos substituir uma matriz de pesos dinâmica e enorme (uma matriz diferente para cada par de tokens, o que seria inviável) por uma combinação eficiente de transformações fixas.

As múltiplas cabeças de atenção (multi-head attention) seguem a mesma lógica: em vez de uma única matriz de transformação enorme, dividimos o trabalho entre várias cabeças menores, cada uma especializada em um tipo diferente de relação entre tokens. É uma forma de compressão inteligente: poucas transformações reutilizáveis cobrem a mesma função que exigiria uma matriz gigantesca e impossível de treinar.

Conexão surpreendente com o MLP

O artigo termina com uma observação fascinante: o bloco feedforward (MLP) do Transformer — normalmente tratado como uma caixa-preta que processa cada token independentemente — pode ser interpretado como um armazenamento chave-valor próprio.

Os neurônios da camada oculta do MLP atuam como “keys” que detectam padrões específicos nos tokens, enquanto os pesos da camada de saída funcionam como “values” que adicionam informações ao token. É como se o Transformer tivesse dois mecanismos de atenção operando em paralelo: um explícito (multi-head attention, entre tokens) e um implícito (MLP, dentro de cada token).

Por que isso importa em 2026

Compreender que a arquitetura Transformer não é um acidente histórico, mas sim a convergência de pressões de design fundamentais, é crucial por dois motivos:

Primeiro, ajuda a identificar quais partes da arquitetura são essenciais e quais são acidentais. Isso orienta quais otimizações fazem sentido — compressão de KV cache, arquiteturas de atenção linear e alternativas eficientes como Mamba e RWKV todas mexem em aspectos diferentes dessa estrutura fundamental.

Segundo, e talvez mais importante: se os Transformers eventualmente forem substituídos (como as RNNs foram), entender por que eles funcionam nos ajuda a projetar a próxima arquitetura mais rapidamente. A história se repete: as RNNs não sumiram porque eram inúteis, mas porque entendemos suas limitações e construímos algo melhor.