Por que os erros de shape de tensores passam despercebidos

Você já passou por isso. O loop de treinamento roda, a loss cai, as métricas parecem boas. Depois de três semanas em produção, alguém percebe que as saídas do modelo estão erradas de um jeito que ninguém consegue explicar.

O problema? Um eixo que, na sua cabeça, significava uma coisa, mas que o código tratou de forma completamente diferente.

Não é erro de compilação. Não é crash em tempo de execução. É algo pior: um erro silencioso de corretude que afeta todas as predições do modelo.

O problema da notação

A verdade incômoda é essa: o que você não consegue nomear, você não consegue verificar.

A maioria dos frameworks de tensor ignora o significado dos eixos. Um shape como (32, 768, 12, 64) pode representar:

• (batch, sequence, heads, dim_per_head) em um contexto
• (batch, features, height, width) em outro
• (batch, tokens, layers, channels) em outro ainda

O compilador não se importa. O shape é apenas uma tupla de números. Desde que as dimensões multipliquem corretamente, a operação é válida. O framework executa tudo e, com isso, o significado semântico fica gravado nos pesos.

Esse é o bug invisível. Não está errado do ponto de vista matemático, só está errado quanto à intenção.

O que uma notação melhor poderia fazer

Imagine se as operações com tensores carregassem seu significado junto com o sistema de tipos. Não apenas shapes — dimensões rotuladas.

Em vez de ficar debugando qual eixo é qual, você declararia isso logo de início:

tensor: [batch=32, sequence=128, heads=12, dim_per_head=64]

Aí o compilador poderia verificar se:

• O broadcast só acontece em dimensões que realmente podem ser broadcastadas
• As operações de redução colapsam apenas os eixos que você queria
• As heads de atenção permanecem separadas das dimensões de features
• O LayerNorm normaliza exatamente os eixos corretos

O compilador viraria seu copiloto. Ele detectaria o swap de eixos antes de você treinar por três semanas.

O custo real dos bugs silenciosos

Considerando o que esses bugs de dimensão realmente representam:

Em pesquisa: Horas de testes para entender porque os números não replicam. É um hyperparameter? Um seed diferente? Ou será que a ordenação dos eixos é wrong? Agora multiplique isso pelas experimentos falhos.

Em produção: Um modelo deployado que é sutilmente miscalibrado. A precision pode ser 94% em vez de 96%. O bug é pequeno para se escond<|eos|>