Memória
consultada

1 O que a memória somada não faz

A memória da apostila 11 é um vetor m por sequência, atualizado a cada bloco que sai da janela: m ← m + f([m ; s_bloco]). Ela persiste — a predição com a memória do texto certo ganha +0,019 sobre a memória de outro texto, mesmo uma janela inteira depois. Mas a mesma tabela mostrou o limite: "longa" (A+B) erra 0,181, pior que "recente" (só B, 0,173) e que "só antiga" (só A, 0,174). Um vetor de capacidade fixa não acumula: cada bloco novo sobrescreve parte do anterior. Quanto mais passado, menos de cada pedaço.

LeCun descreve outra peça. A palestra: "você pode ter de combinar a percepção com o conteúdo de uma memória para ter o estado completo do mundo". A entrevista: sistemas com "memória persistente, do tipo que nós temos". E o slide da arquitetura tem a memória como um módulo consultado pelo modelo de mundo, não como um somatório. A apostila 11 deixou isso escrito como pergunta em aberto: "a memória consultada, não só somada, exige atenção sobre um banco de estados abstratos, e é outra peça". Esta é a peça.

2 A peça: banco + atenção

Cada bloco de 8 tokens que sai da janela é abstraído pelo mesmo encoder de nível 2 (abstrair()) e guardado, não somado. O banco é o conjunto S = {s₁, …, s_n} desses estados. O modelo de mundo consulta o banco com uma chave projetada do estado atual, e lê o resultado por atenção:

q = W_q z_t / √d   r_t = softmax(q · S^T) S   Pred(z_t, a_t[, ζ][, m], r_t) → z_t+1

Três decisões, todas herdadas do que já foi medido. O encoder não recebe gradiente pelo banco (só W_q e o modelo de mundo aprendem a consultá-lo; a mesma regra da memória somada, pelo mesmo motivo: senão o encoder esconde o alvo no banco). O treino usa as janelas duplas da apostila 11: o banco de treino são os blocos do passado contíguo, e a atenção é exata sobre eles (no máximo 32 estados). E o banco-dropout de 0,5 já vem embutido — a lição da apostila 13: metade dos lotes com r = 0, para o preditor funcionar quando o banco está vazio, que é o caso de todo prompt curto.

A medida é a da apostila 11, transposta: ganho_banco = MSE(banco de outro texto) − MSE(banco certo), com a MSE do banco vazio ao lado. Zero quer dizer que a atenção não encontra nada útil no passado.

3 Por que um índice vetorial, e por que o turbovec

No treino o banco cabe numa multiplicação de matrizes. Na bancada, não: o banco cresce a cada bloco gerado ou lido, sessão após sessão, e a promessa da entrevista é que ele não seja apagado. Um milhão de blocos (oito milhões de tokens lidos) são 256 milhões de floats — um giga em fp32, e uma atenção exata sobre um milhão de estados a cada token. O que a atenção precisa de fato são os k maiores logits q · s_j; o resto do softmax é desprezível. E "os k maiores produtos internos com uma consulta" é exatamente o que um índice vetorial devolve.

O turbovec é um índice em Rust com ligação Python que implementa o TurboQuant (Google Research, 2025): cada vetor é normalizado, passa por uma rotação aleatória fixa (que torna cada coordenada aproximadamente Beta, com a mesma distribuição em todas as dimensões), é quantizado por coordenada com um codebook Lloyd-Max de 4 bits (16 níveis) e empacotado — 256 dimensões viram 128 bytes, oito vezes menos que fp32 — e um escalar por vetor corrige o viés do produto interno estimado. A busca roda em SIMD sobre os códigos, sem etapa de treino nem ajuste de parâmetros: o banco ingere online, um bloco de cada vez, que é o regime da bancada. A gravação é incremental (sync escreve só o que mudou desde a última vez), o que faz a persistência custar milissegundos por geração. O que ele não devolve são os vetores — só ids e pontuações —, então os estados em fp32 ficam num arquivo ao lado, e a atenção é feita sobre os k recuperados de verdade.

A alternativa mais simples seria manter tudo em RAM e fazer a busca exata; ela fica disponível como fallback (mesma API, sem o turbovec instalado) e é a referência para medir o que a quantização custa em recall — a pergunta que a seção 5 deixa aberta.

4 A rodada

Rodada wm1n2bco-sz1, na mesma verba das outras: hierarquia com média crua (a abstração honesta da apostila 11), SigReg-z, banco com dropout 0,5, sem a memória somada (para medir a peça sozinha). Três perguntas: o banco carrega passado (ganho > 0)? o passado inteiro vale mais que cada metade (o que o vetor não conseguia)? e o leme governa nesse mapa, com o banco vazio — que é a condição da apostila 12?

O banco resolve a diluição, que era o defeito da memória somada. Na apostila 11, "longa" (A+B) errava 0,181, pior que "recente" (só B, 0,173): quanto mais passado, menos de cada pedaço, porque um vetor de capacidade fixa sobrescreve a si mesmo. No banco consultado, "longa" erra 0,1736 — exatamente igual a "recente", e ligeiramente melhor que "só antiga" (0,1738). Guardar em vez de somar elimina a diluição por construção: o bloco antigo continua lá, intacto, e a atenção escolhe. É o que a arquitetura do slide previa e o somatório não entregava.

E o banco carrega pouco. O ganho sobre a memória de outro texto é +0,0036, contra os +0,014 da memória somada da apostila 11 e os +0,002 da somada com dropout. A causa é a mesma dos dois casos anteriores, e está na receita: o banco-dropout de 0,5 ensina o preditor a funcionar sem banco, e ele aprende a não depender dele. A diferença é que aqui o dropout era obrigatório — todo prompt curto começa com o banco vazio —, então o compromisso não é um erro de calibração e sim a forma do problema. A rodada com dropout menor é o teste que falta.

O leme não governa neste mapa (0,272 com cabeça e estado real contra 0,360 livre), e o custo ao gerador é o mais alto da família, +9,73%. Somando: a memória consultada entrega o que prometeu na persistência — não dilui — e não entrega no resto. Pela régua de ruído da apostila 13 §12.3, o +9,73% é indistinguível dos +9,55% do mesmo mapa sem banco: o banco é de graça e quase não carrega. Fica na bancada como peça de infraestrutura, com o índice quantizado em disco pronto para um banco grande, e a pergunta sobre o dropout em aberto.

5 Na bancada

• Todo modelo treinado com --world-bank ganha um banco em runs/<rodada>/banco/ (banco.tvim + estados em .npy), carregado quando o modelo é carregado e gravado ao fim de cada geração. Cada bloco que sai da janela — do prompt ou do que foi gerado — entra no banco.
• Parâmetros de compass: banco (true, false, ou "limpar"), banco_gravar (false = só consulta) e banco_k (top-k, padrão 8). A trajetória devolve banco_estados.
• O experimento (model/memory.py) imprime a tabela do banco ao lado da tabela da memória somada, quando o modelo tem as duas.