Modelar sequências: o ponto de partida

01 · Conceito

Conceito

Um modelo está lendo um documento e chegou ao token 40.000. Para prever o token 40.001 ele pode precisar de algo que aconteceu no token 12, ou no token 39.999, ou de nada. A arquitetura não tem como saber de antemão qual dos casos é. Então ela precisa decidir, de uma vez por todas, o que tem permissão de levar adiante de tudo o que já leu.

É essa a pergunta em torno da qual gira a trilha inteira, e vale enunciá-la do jeito mais direto possível: quanto estado um modelo pode carregar entre tokens? Não “qual arquitetura é a melhor” — esse enquadramento esconde a troca. Todo projeto das trilhas 3 e 4, e o arranjo híbrido do espécime deste curso, é uma resposta diferente à pergunta do estado, e cada resposta compra uma coisa e paga com outra.

Duas respostas extremas delimitam o espaço.

A primeira diz que o estado é um vetor de tamanho fixo. Em cada posição o modelo calcula um estado novo a partir do estado velho e do token atual, e o velho é descartado:

Os mesmos parâmetros $\theta$ agem em toda posição, e é isso que permite a um único modelo lidar com qualquer comprimento. A memória é constante, o trabalho por token é constante, e o token 40.000 custa exatamente o que custou o token 1. A lição 3.2 desenvolve esse projeto.

A segunda diz para guardar um registro de key/value para cada posição. Na hora de prever, use scores de conteúdo aprendidos para misturar esses registros. Isso evita comprimir todo o passado num único estado recorrente e preserva um caminho direto para cada posição armazenada, mas os registros projetados e sua mistura ponderada não garantem recuperação exata. A memória cresce a cada token, e o trabalho de consultar o depósito cresce junto. A lição 3.5 apresenta o mecanismo, e a trilha 4 constrói o Transformer inteiro sobre ele.

Agora torne concreto o limite do estado fixo, porque não é uma preocupação vaga sobre “esquecer” — é aritmética. Considere uma tarefa de cópia: mostre ao modelo uma sequência aleatória de tokens, depois um delimitador, e exija que ele reproduza a sequência exatamente. Tome um vocabulário de 1.000 itens, de modo que cada token aleatório carregue $\log_2 1000\approx9.97$ bits de informação, e um estado de 256 números guardados em bf16, isto é, 512 bytes, ou 4.096 bits, como limite superior absoluto do que ele comporta. Uma sequência de 100 tokens a copiar carrega cerca de 997 bits. Isso cabe dentro de 4.096, então a tarefa é ao menos possível — se o treino encontra a solução é outra questão. Uma sequência de 1.000 tokens carrega cerca de 9.970 bits. Isso não cabe. Nenhuma arquitetura com esse tamanho de estado, nenhuma learning rate, nenhum dataset e nenhuma dose de paciência produzem um modelo que copie 1.000 tokens aleatórios por um canal de 512 bytes, porque a informação simplesmente não está lá para ser recuperada.

Aqui vem o desvio clássico. Um modelo falha numa tarefa que exige informação de muito atrás, e o reflexo é treinar mais tempo, alargar a rede ou culpar o otimizador. Às vezes é isso mesmo. Mas antes de gastar uma semana nisso, faça a conta: estime quantos bits a tarefa exige que atravessem o vão e compare com o que o estado carregado fisicamente comporta. Se a informação necessária excede o canal, pare de ajustar hiperparâmetros e mude a arquitetura. Se cabe com folga e o modelo ainda falha, aí você tem um problema genuíno de aprendizado — que os gradientes que somem da lição 3.2 vão explicar.

O outro extremo também tem um custo, e ele não é sutil em escala de produção. Armazenar cada posição significa memória que cresce sem limite. A lição 7.2 detalha a conta exata para o Qwen3.8-27B: no seu contexto nativo de 262.144 tokens, as keys e values armazenadas de uma única sequência chegam a 16 GiB. Contra isso, as camadas do mesmo modelo que carregam um estado recorrente fixo somam cerca de 144 MiB no total no caminho float32 de referência, e esse número não muda se a sequência tem cem tokens ou um quarto de milhão (Qwen3.8-27B Model Card, 2026). Dezesseis gibibytes contra cento e quarenta e quatro mebibytes, para a mesma sequência, dentro do mesmo modelo. Guarde esse contraste; é o argumento ao qual o resto do curso volta o tempo todo, e as lições 3.6, 4.15 e 4.16 explicam como um único modelo passou a conter as duas respostas ao mesmo tempo.

Alguns cuidados de arrumação fazem parte genuína do problema, e não da periferia dele. Que contexto é legítimo depende da tarefa: um modelo causal prevendo a posição $t+1$ não pode ver tokens futuros, e essa fronteira precisa ser imposta durante o treino mesmo que todos os alvos já estejam no arquivo. Um encoder bidirecional classificando uma frase completa pode ler os dois lados. Usar informação futura num benchmark offline invalida silenciosamente um sistema que deveria rodar ao vivo, e é um dos erros mais fáceis de cometer e mais difíceis de notar.

Sequências num batch têm comprimentos diferentes, então padding preenche um tensor retangular e uma máscara marca quais posições são reais. O padding não pode alterar nenhum estado, receber peso de attention nem contribuir para a loss. Um bug de mascaramento produz métricas excelentes seja vazando rótulos, seja fazendo média sobre posições de padding fáceis — e a métrica vai parecer maravilhosa o tempo todo.

O treino de modelos autorregressivos normalmente usa teacher forcing: no passo $t$ o modelo recebe o token anterior verdadeiro em vez da própria amostra. Isso torna os alvos construíveis em paralelo e estabiliza o aprendizado, mas a inferência condiciona nas escolhas anteriores do próprio modelo, então um erro cedo muda todo o contexto seguinte. O descasamento é real e as alternativas não são de graça.

Por fim, a avaliação precisa combinar com a estrutura. Acurácia por token pode esconder baixa validade da sequência inteira; calcular a média da loss de formas diferentes sobre posições com e sem padding muda o número; sequências geradas exigem escolhas de decoding e muitas vezes têm vários alvos aceitáveis. Reporte direcionalidade, limite de contexto, truncamento, mascaramento e como as métricas agregam. Um teste confiável de vazamento vale ser construído uma vez e mantido: monte dois exemplos idênticos até o tempo $t$ e diferentes depois, e confirme que a representação causal em $t$ é bit a bit idêntica em modo de avaliação. Se ela se move, informação futura chegou até lá por mascaramento, pré-processamento, normalização ou construção de alvos.