Por que o re-treinamento repetido esbarra num teto: o estudo da LANN-4

Isto não é o anúncio de uma arquitetura pronta, mas um relato intermediário honesto sobre o que funcionou e o que não funcionou. O autor pede críticas concretas e específicas. Todas as regras e os conjuntos de tarefas foram fixados com antecedência, com hashes de verificação — não dá para ajustar o resultado depois — e os resultados foram recalculados de forma independente, com código escrito por alguém diferente de quem conduziu o experimento. É uma proteção contra autoengano.

A LANN-4 é uma rede neural que aprende ao longo de toda a sua existência, com um núcleo pequeno e fixo e memória mantida fora dele, em vez de crescer a cada atualização. É uma resposta à tendência dominante da indústria: o caminho padrão é tornar os modelos cada vez maiores. Mas o autor se interessa por outra coisa: quanta utilidade dá para extrair com um tamanho rigidamente limitado, de forma que cada nova tarefa parecida fique mais barata de resolver.

Princípios de trabalho: sete pilares do desenvolvimento

O desenvolvimento é guiado por sete princípios de trabalho — não uma descrição do funcionamento do sistema, mas referências orientadoras:

• O sistema lembra o passado entre tarefas, não começa do zero a cada vez.
• Cada tarefa recebe exatamente o esforço que ela vale, nem mais nem menos.
• Conhecimento e experiência ficam numa memória externa separada, não embutidos nos pesos do modelo.
• Ele aprende coisas novas sem esquecer as antigas.
• Resposta, dica e fato verificado são três coisas distintas; um honesto "não sei" vale mais que uma invenção convincente.
• Qualquer automelhoria é primeiro testada numa sandbox e por um juiz externo; o modelo não se corrige sozinho.
• Tudo relacionado a segurança e permissões é tratado de fora e não depende da obediência do modelo.

Metodologia: quatro rodadas, três modos

Foi usada uma única prova de 200 tarefas, idêntica em todas as etapas, e o sistema passou por quatro rodadas de re-treinamento. Três modos de operação foram comparados:

• Acúmulo — o modelo é re-treinado e cada rodada seguinte se soma à anterior.
• Do zero — cada rodada começa com um modelo limpo, sem acúmulo.
• Sem treinamento — simplesmente refaz a prova (controle de aleatoriedade).

O que principalmente se mediu: se a proporção de respostas corretas sobe de rodada para rodada.

Resultados: um salto e depois estagnação

A proporção de respostas corretas no modo de acúmulo: 53% → 59% → 54–57% → 54–57%. A primeira rodada trouxe um salto de cerca de cinco pontos percentuais. A segunda, terceira e quarta rodadas não acrescentaram nada. O modo "do zero" se comportou de forma idêntica — o ajuste acumulado não trouxe nenhuma vantagem. O modo de controle caiu ligeiramente, como era esperado do ruído estatístico. As tarefas antigas não passaram a ser resolvidas pior. O recálculo independente bateu exatamente com o primeiro — os números se sustentaram.

Uma rodada de re-treinamento com soluções verificadas realmente traz um ganho, e ele se mantém ao longo das quatro rodadas. Mas de onde vem esse ganho? Há duas explicações honestas, que levam o projeto em direções diferentes: ou o modelo absorveu o conteúdo das soluções corretas, ou simplesmente se adaptou ao formato do código.

A bifurcação e o teste placebo

Para separar as duas hipóteses, aplicou-se um teste placebo: compararam-se o re-treinamento com pares corretos de "tarefa + solução verificada" e o re-treinamento com pares deliberadamente trocados, em que a solução não corresponde à tarefa (verificou-se que os pares trocados de fato não resolviam as tarefas). Tudo o mais foi mantido igual: mesmo número de passos, mesmos exemplos, mesmas condições, mesma prova.

Há uma brecha nesse teste: ele separa o treinamento com código em geral do treinamento com conteúdo correto, mas só dentro de um mesmo tipo de tarefa. Ele não detecta o overfitting ao código daquele mesmo tipo de tarefa. Para fechar também essa brecha, é preciso um experimento separado com outros tipos de tarefas — mais um dia de GPU.

Três perguntas para a crítica

O autor pede críticas substanciais sobre três pontos:

• Um teste placebo com custos equivalentes é suficiente para chamar honestamente o ganho da primeira rodada de aprendizado de verdade? O que falta na lista de condições?
• Como fechar a brecha do overfitting a um único tipo de tarefa sem dobrar o trabalho de GPU?
• Outros já observaram o mesmo padrão — salto na primeira rodada, depois um teto — ao re-treinar repetidamente um modelo pequeno?

Um resultado negativo não é um fracasso. Ele delimita honestamente o terreno, mostrando até onde a capacidade de acumular aprendizado não leva. Esse resultado faz o projeto avançar.