Treinamento unificado elevou o resultado no HumanEval+ para 24,96% pass@1

Hoje, treinar um modelo de linguagem se parece com operar uma fábrica com várias linhas de produção separadas. Primeiro, o modelo lê um corpus enorme de textos; depois, aprende com dados mais especializados; em seguida, é treinado para seguir instruções; e só então recebe feedback por meio de RL. Em cada transição, mudam os dados, o código, a infraestrutura e a equipe. Ao mesmo tempo, surge um problema conhecido: ao melhorar uma habilidade, o modelo pode esquecer parcialmente outra.

Os autores do trabalho Training Foundation Models with a Single Algorithm testaram se essa corrida de revezamento poderia ser transformada em um único processo contínuo. A resposta deles é que as diferentes etapas podem ser representadas como treinamento sobre distribuições-alvo de dados, com os exemplos misturados em um fluxo comum e uma única função de perda de máxima verossimilhança ponderada por tokens sendo otimizada. Até as atualizações de política em RL são reduzidas aqui ao ajuste das probabilidades das respostas, levando em conta a recompensa recebida.

Como isso funciona em um exemplo simples

Imagine um modelo pequeno que primeiro aprende linguagem comum, depois quebra-cabeças lógicos e, por fim, programação. Um pipeline clássico executa três sessões de treinamento consecutivas. No Unified Training, o servidor de treinamento pode receber exemplos dos três tipos simultaneamente, mas em proporções diferentes: muitos dados de linguagem geral, menos quebra-cabeças e uma pequena parcela de tarefas com recompensa por código correto.

O peso de cada fluxo determina aquilo a que o modelo dedica mais atenção naquele momento. Os dados anteriores não desaparecem completamente, por isso o modelo perde com menos frequência capacidades que já adquiriu. É menos parecido com um formando que fecha o livro após a prova e mais com um profissional que continua revisando aos poucos os fundamentos durante a prática.

Nas tarefas lógicas, o resultado dependeu fortemente da composição da mistura: aproximadamente de 4% a 39% pass@1 em tarefas de tamanho conhecido. As variantes por etapas registraram de 12,24% a 24,54%. Em novas tarefas com 12 personagens, a abordagem unificada entregou aproximadamente 1–13%, enquanto a variante por etapas selecionada obteve 5,58%. A dispersão é mais importante aqui do que o máximo atraente: o próprio algoritmo não elimina a necessidade de ajustar as proporções dos dados.

Em um experimento com um modelo de 0,76 bilhão de parâmetros, o RL em matemática e, depois, em código produziu 23,67–24,96% pass@1 no HumanEval+ quando a proporção de dados misturados variou de 0,5% a 5%. O treinamento sequencial convencional obteve 22,94%. A diferença é pequena, mas mostra que preservar parte do fluxo de dados anterior pode ajudar na etapa seguinte de adaptação.

Onde as evidencias terminam

A principal limitação do trabalho é a escala. Todos os experimentos foram realizados em modelos com menos de um bilhão de parâmetros. Além disso, no modelo de 0,76B, a unificação foi usada apenas durante a etapa final de RL, não em todo o percurso entre o pre-treinamento e um assistente pronto. Portanto, ainda é cedo para afirmar que pipelines separados deixaram de ser necessários.

Também não foi encontrado um cronograma universal de mistura. Uma proporção resolve melhor os quebra-cabeças conhecidos, outra funciona melhor em tarefas novas e uma terceira favorece o código. Em um produto real, também seria preciso considerar o custo computacional, a qualidade da filtragem dos dados, as latências do sistema assíncrono e objetivos de segurança conflitantes.

O que as equipes devem fazer

Desenvolvedores de modelos próprios devem tratar o Unified Training como uma hipótese de engenharia verificável. Não é necessário reescrever imediatamente todo o stack. É possível começar com um experimento restrito: durante a etapa de SFT ou RL, manter uma pequena parcela dos dados da etapa anterior e comparar a qualidade das novas habilidades e o grau de esquecimento em um conjunto fixo de testes.

Para as equipes de produto, outra ideia pode ser mais útil: as fronteiras entre pre-treinamento, ajuste fino e RL podem ser uma conveniência organizacional, e não uma propriedade fundamental do aprendizado. Se o resultado for reproduzido em modelos maiores, um único fluxo assíncrono simplificará a transferência de dados entre as etapas e permitirá alterar prioridades mais rapidamente. Por enquanto, o valor do trabalho não está na promessa de “um algoritmo para tudo”, mas no código, no modelo e no esquema experimental concreto que pode ser testado em um conjunto próprio de tarefas.