Not-Just-Scaling Laws: Towards a Better Understanding of the Downstream Impact of Language Model Design Decisions

Este artigo apresenta uma meta-análise de 92 modelos de linguagem que demonstra que incorporar decisões de design, como a composição dos dados e escolhas arquiteturais, melhora significativamente a previsão do desempenho downstream em comparação com o uso exclusivo da escala do modelo.

O essencial

Imagine que você está tentando prever o quão inteligente será um carro antes mesmo de ele sair da fábrica.

Até recentemente, a indústria de Inteligência Artificial (IA) tinha uma regra simples: "Quanto maior o motor e quanto mais combustível você colocar, mais rápido o carro vai." No mundo das IAs, isso significava que, se você aumentasse o tamanho do modelo (número de parâmetros) e a quantidade de dados que ele lia (número de tokens), ele ficaria automaticamente melhor em tudo. Isso é o que chamamos de "Leis de Escala".

Mas os autores deste paper, um grupo de pesquisadores da Carnegie Mellon e outras instituições, descobriram que essa regra não é toda a história. Eles dizem: "Não é só o tamanho do motor que importa; o tipo de combustível e o design do carro fazem toda a diferença."

Aqui está uma explicação simples do que eles descobriram, usando analogias do dia a dia:

1. O Problema: O "Gigante" vs. O "Especialista"

Imagine dois estudantes:

• O Gigante: Um aluno que leu 1 milhão de livros, mas leu tudo de qualquer jeito, sem filtro.
• O Especialista: Um aluno que leu apenas 100 mil livros, mas foram livros de alta qualidade, bem organizados e com um currículo específico.

A "Lei de Escala" antiga diria que o Gigante sempre ganharia. Mas os pesquisadores descobriram que, às vezes, o Especialista ganha. Por quê? Porque a qualidade e a mistura do que ele estudou importam mais do que apenas a quantidade bruta.

2. A Solução: O "Mapa de Receitas"

Os pesquisadores criaram um banco de dados gigante com 92 modelos de IA diferentes (desde os pequenos até os gigantes). Eles não olharam apenas para o tamanho, mas anotaram tudo sobre a "receita" de cada um:

• Arquitetura: Como o cérebro foi montado (o tipo de "engrenagem" interna).
• Dados: O que ele comeu? (Quanto era código de computador? Quanto era livros? Quanto era internet?).
• Comportamento: O que ele escreve quando você pede para ele "falar livremente"?

Eles usaram isso para treinar um "adivinho" (um modelo de regressão) que tenta prever o quão bom um modelo será em testes de raciocínio, matemática ou programação.

3. As Descobertas Principais (O que mudou?)

A. A Mistura Perfeita de "Comida" (Dados)

A descoberta mais saborosa foi sobre código de computador.

• A Analogia: Imagine que a IA é um cozinheiro. Se você der apenas farinha (texto comum), ele faz pão. Se você der apenas açúcar (código), ele faz doces.
• O Resultado: Eles descobriram que a mistura ideal não é 100% de nada. Para um modelo ser bom tanto em conversar quanto em programar, a receita ideal tem cerca de 15% a 25% de código.
  • Pouco código? Ele não aprende a raciocinar logicamente.
  • Muito código (mais de 25%)? Ele começa a esquecer como conversar naturalmente e fica "robótico" em tarefas de linguagem.

B. A Internet pode ser "Lixo" (Dados Web)

• A Analogia: Imagine que você está tentando ensinar uma criança a ser honesta. Se você deixar ela ler apenas fóruns de internet aleatórios (onde há muita mentira e desinformação), ela vai aprender a mentir.
• O Resultado: Modelos treinados com muita "água suja" da internet (dados web) tendem a ser menos verdadeiros em testes de veracidade. Quanto mais "web" na dieta, pior a honestidade do modelo.

C. O Design do "Cérebro" (Arquitetura)

• A Analogia: Dois carros podem ter o mesmo motor, mas um tem uma suspensão esportiva e o outro tem pneus de caminhão. O desempenho muda dependendo do terreno.
• O Resultado: Detalhes técnicos, como o tipo de "normalização de camadas" (uma peça interna do cérebro da IA) ou como ele lembra de posições (positional embeddings), fazem diferença. Não é o fator principal, mas ajuda a refinar o desempenho.

4. Por que isso é importante?

Antes, os desenvolvedores pensavam: "Vamos apenas comprar mais computadores e ler mais dados, e a IA vai ficar mágica."

Este paper diz: "Espere! Se você mudar a receita, você pode ter uma IA menor, mais barata e mais inteligente do que um gigante mal treinado."

Eles provaram que, ao adicionar essas novas informações (tipo de dado, arquitetura) à previsão, conseguiram prever o desempenho dos modelos com 3% a 28% mais precisão do que apenas olhando para o tamanho.

Resumo em uma frase:

Não basta apenas fazer a IA maior; é preciso cuidar do que ela come e como seu cérebro é construído para que ela seja realmente inteligente.

O que isso significa para o futuro?
Os desenvolvedores podem agora usar esse "mapa de receitas" para criar modelos melhores sem precisar gastar bilhões de dólares apenas em poder de computação bruta. É como passar de "comer tudo o que vê pela frente" para "fazer uma dieta balanceada e personalizada".

Resumo técnico

Resumo Técnico: Leis de Escala Além da Escala

1. O Problema

O desempenho dos Modelos de Linguagem (LLMs) é frequentemente atribuído apenas ao aumento do tamanho do modelo (número de parâmetros) e à quantidade de dados de treinamento (número de tokens). As "Leis de Escala" tradicionais (como as de Kaplan et al., 2020) sugerem que o desempenho pode ser previsto com base nessas duas variáveis.

No entanto, observa-se que modelos menores, treinados com dados curados ou com decisões arquitetônicas diferentes, podem superar modelos maiores treinados com mais tokens. As leis de escala baseadas apenas em parâmetros e tokens falham em explicar completamente o desempenho em tarefas downstream (como raciocínio, código ou verdade). O artigo questiona: quais outras decisões de design (arquitetura e composição de dados) impactam o desempenho e podem ser usadas para prever resultados com maior precisão?

2. Metodologia

Os autores desenvolveram uma abordagem sistemática para meta-analisar e prever o desempenho de LLMs indo além das leis de escala tradicionais.

• Construção de Banco de Dados:

  • Foram catalogados 92 modelos pré-treinados de código aberto (decoder-only, base), variando de 11M a 110B de parâmetros, lançados entre 2019 e 2024.
  • Foram excluídos modelos ajustados (fine-tuned), mistos (MoE) ou sem metadados públicos.
  • Recursos Coletados:
    • Arquitetura: Parâmetros, dimensões, tipos de normalização de camada (LayerNorm), embeddings posicionais, variantes de atenção (GQA, MQA), etc.
    • Composição de Dados: Percentuais de tokens de diferentes domínios (web, código, livros, acadêmico, referência) baseados na documentação oficial.
    • Recursos Derivados de Geração: Como muitos modelos não divulgam seus corpora completos, os autores geraram textos "livres" (sem contexto) dos modelos e usaram classificadores para inferir a composição dos dados de treinamento e extrair características linguísticas (ex: proporção de palavras interrogativas, profundidade de árvores de parse).

• Modelagem Preditiva:

  • Em vez de usar apenas leis de potência (scaling laws), os autores treinaram regressores baseados em árvores (XGBoost).
  • Entrada: Recursos de arquitetura e dados.
  • Saída: Pontuação em 12 benchmarks populares (ex: MMLU, GSM8K, HumanEval, TruthfulQA).
  • Comparação: O desempenho do regressor com todos os recursos foi comparado contra um baseline de apenas escala (parâmetros e tokens) e um baseline log-linear.

• Validação Experimental:

  • Para confirmar as descobertas observacionais, os autores realizaram experimentos de pré-treinamento confirmatórios com modelos de 460M parâmetros no conjunto de dados Dolma, variando sistematicamente as proporções de código e dados da web.

3. Principais Contribuições e Resultados

A. Melhoria na Previsão de Desempenho

• Incorporar recursos além da escala (arquitetura e composição de dados) aumentou a capacidade de prever o desempenho downstream em 3% a 28% (redução de erro relativo) em comparação com o uso de escala isolada.
• O regressor com todos os recursos superou consistentemente o modelo baseado apenas em escala em todos os benchmarks avaliados.
• Tarefas de raciocínio comum e geração de código mostraram os maiores ganhos de previsibilidade ao incluir novos recursos.

B. Insights sobre Composição de Dados

• Otimização de Código: A análise de importância de recursos (SHAP) revelou uma relação não linear entre a porcentagem de código no pré-treinamento e o desempenho.
  • Uma proporção de 15-25% de código parece ser o ponto ideal para equilibrar o desempenho em tarefas de código (HumanEval) e raciocínio em linguagem natural.
  • Proporções acima de 25% melhoram o código, mas degradam o desempenho em tarefas de raciocínio linguístico (NLI).
• Dados da Web e Veracidade: Houve uma associação negativa entre a proporção de dados da web e o desempenho em TruthfulQA. Modelos com maior exposição a dados da web tendem a ser menos precisos em questões de veracidade.

C. Impacto de Decisões Arquiteturais

• Embora a escala e a composição de dados sejam os fatores dominantes, decisões arquiteturais específicas (como o tipo de LayerNorm e Positional Embeddings) tiveram efeitos significativos em certos contextos, embora menores em magnitude global.

D. Validação Experimental

• Os experimentos confirmatórios com modelos de 460M validaram as previsões da meta-análise:
  • Confirmaram que ~8% de código é ótimo para NLI puro, mas 15-25% é melhor para um equilíbrio geral.
  • Confirmaram que o aumento de dados da web reduz a precisão em TruthfulQA (embora a métrica de perda tenha mostrado uma variação menor, a tendência de acurácia seguiu o esperado).

4. Significado e Implicações

• Fim do "Tamanho é Tudo": O trabalho demonstra que o tamanho do modelo e a quantidade de dados não são os únicos determinantes de qualidade. A curadoria de dados e as decisões de arquitetura são fatores críticos que podem ser otimizados independentemente da escala.
• Ferramenta para Desenvolvedores: O banco de dados e o framework de previsão fornecem recursos práticos para desenvolvedores de modelos tomarem decisões informadas sobre a mistura de dados (data mixing) antes de iniciar o treinamento, economizando custos computacionais.
• Método de Investigação: A abordagem de usar gerações do modelo como proxy para dados de treinamento permite analisar modelos que não divulgam seus corpora, democratizando a pesquisa sobre composição de dados.
• Limitações e Futuro: O estudo é observacional (não causal) e focado em modelos densos e em inglês. O trabalho sugere a necessidade de mais experimentos controlados e a expansão para arquiteturas alternativas (como MoE) e modelos multilíngues.

Conclusão

O artigo "Not-Just-Scaling Laws" estabelece que para entender e prever verdadeiramente as capacidades de um LLM, é necessário um modelo que considere a arquitetura, a composição detalhada dos dados e os padrões de geração, e não apenas o número de parâmetros e tokens. A otimização da mistura de dados (especialmente o equilíbrio entre código e linguagem natural) é uma alavanca poderosa para melhorar o desempenho downstream.