Dor De Contração De Treinamento

O que realmente acontece quando o treinamento entra no problema

Quando você começa a fine-tunar um modelo, especialmente em hardware consumer ou até mesmo em clusters pequenos, logo percebe que existem certos patamares de dor que todo mundo que já rodou treinamento sério conhece muito bem. Eu não vou chamar isso de "dor de contração de treinamento" num sentido poético. É um termo que surgiu nas comunidades técnicas brasileiras para descrever especificamente aquela fase em que o modelo aparenta estar aprendendo, mas na prática os losses oscilam, a validação não melhora e tudo parece travado num loop estéril. A questão é que esse fenômeno não é um bug. Ele tem causas concretas. O primeiro sintoma geralmente é um loss de treino que cai rápido nas primeiras centenas de steps e depois entra num platô irregular. Às primeira vista parece que o modelo parou de aprender. O que está acontecendo na realidade é mais sutil.

Entendendo a dor de contração de treinamento na prática

O que a comunidade passou a chamar de dor de contração de treinamento acontece quando há uma dissonância entre o que o modelo está assimilando no batch atual e o que ele precisa consolidar em escala. Você tem exemplos variados no dataset, mas o modelo não consegue formar padrões estáveis porque a taxa de aprendizado, o tamanho do batch ou a quantidade de dados efetivos estão fora de sincronia. O resultado é aquele padrão de loss em dente de serra que não desce de jeito nenhum. Eu já enfrentei isso diretamente num projeto de fine-tuning de LLM para português com cerca de 7B de parâmetros. Estávamos usando LoRA em cima de um base treinado majoritariamente em inglês. Os primeiros 500 steps foram promissores, o loss caiu de 2,3 para 1,1. Aí travou. Oscilava entre 1,08 e 1,14 por quase mil steps sem nenhuma direção clara. A validação em um holdout de 5% não melhorava. Perda de tempo e GPU queimando. O problema real era o learning rate. Estávamos usando um schedule linear com warmup de 10% e rate fixo de 2e-4, que é um valor padrão que aparece em praticamente todo tutorial da internet. Ajustei para cosine decay com warmup de 3% e rate máximo de 5e-5, e em cerca de 800 steps adicionais o loss estabilizou em 0,87 com validação subindo consistentemente. A diferença não foi mágica. Foi simplesmente que o modelo precisava de um caminho mais suave para converge em dados cuja distribuição era bem diferente do corpus original.

Outro detalhe que quase ninguém menciona: o grau de heterogeneidade do dataset influencia diretamente a intensidade dessa dor. Se o seu dataset de treino tem alta variabilidade de estilo, registro e domínio, o modelo pode entrar num estado de "contração" onde ele tenta memisar padrões conflitantes simultaneamente. Isso é especialmente crítico quando se trabalha com datasets mistos, como treinar um modelo de código que também recebe exemplos de linguagem natural. O modelo fica num limbo e o loss reflete isso.

Métodos que funcionam, sem misticismo

A abordagem prática mais comum envolve ajustar três variáveis em conjunto: learning rate schedule, batch size efetivo e a proporção de dados de validação usados durante o treino. O erro mais frequente é alterar apenas uma delas e esperar que o problema se resolva. Na maioria das vezes, isso só piora a situação. O schedule de learning rate é onde a maioria dos problemas se origina. Warmup curto demais faz o modelo dar passos grandes demais no início e cair num mínimo local ruim. Warmup longo demais retarda a convergência de forma desnecessária e pode simular uma falsa estabilidade. Para datasets medianos, algo entre 2% e 5% do total de steps como warmup costuma funcionar. O cosine decay posterior ao warmup é geralmente superior ao linear porque oferece uma desaceleração mais gradual nos steps finais, o que ajuda o modelo a refinar os pesos em vez de apenas continuar avançando cegamente. O batch size também merece atenção. Batch pequeno demais gera ruído alto nas estimativas de gradiente e pode gerar flutuações que parecem convergência mas não são. Batch grande demais tende a levar a mínimos mais estreitos e generalização pior. Um batch size efetivo entre 16 e 64 é um ponto razoável para começar, ajustando conforme a memória disponível. Se estiver usando gradient accumulation, o batch efetivo é o batch por GPU vezes o número de GPUs vezes o número de acúmulos.

Validação durante o treino não é só uma questão de monitoramento passivo. Se você está rodando validação a cada 50 steps e o loss de validação já estagnou por 300 steps enquanto o loss de treino continua caindo, isso é um sinal claro de overfitting incipiente. Nesse ponto, parar o treino ou reduzir o learning rate imediatamente costuma ser mais produtivo do que continuar no piloto automático.

O que a maioria das pessoas erra

O erro mais comum é tratar a dor de contração de treinamento como um problema puramente hiperparamétrico. Muitas pessoas passam dias ajustando learning rate, weight decay, scheduler type, sem considerar que o problema pode estar no dataset. Um dataset mal balanceado, com duplicatas ou com examples mal rotulados, vai gerar exatamente esse comportamento de platô oscilante independente dos hiperparâmetros. Antes de gastar tempo tunerizando, verifique se o dataset tem integridade básica. Remova duplicatas exatas e near-duplicatas. Confira se as-labels estão corretas. Um dataset com 10 mil amostras bem curadas vale mais do que 100 mil amostras com problemas silenciosos. Isso é particularmente relevante quando se trabalha com dados gerados automaticamente ou coletados de fontes abertas, onde a qualidade pode variar drasticamente. Outro ponto negligenciado é o uso de mixed precision. FP16 pode causar instabilidade numérica em alguns modelos, especialmente os mais antigos ou com arquiteturas menos robustas. BF16 é uma alternativa mais estável quando disponível. Se você estiver usando FP16 e notar NaNs intermitentes ou gradients com valores extremamente altos, o downgrade para BF16 ou até FP32 pode resolver o problema sem custo significativo de performance em hardware moderno.

Quando a abordagem simplesmente não funciona

É importante ser honesto sobre as limitações. Fine-tuning com recursos limitados tem um teto claro. Se o seu dataset é pequeno demais, digamos menos de mil amostras representativas, não adianta tentar vencer o problema com ajustes de hiperparâmetros. O modelo simplesmente não tem informação suficiente para formar padrões generalizáveis. Nesse cenário, as opções são: usar um modelo menor, buscar mais dados ou recorrer a técnicas como few-shot prompting em vez de fine-tuning. Hardware também impõe restrições reais. Treinar um modelo de 7B com batch size grande o suficiente para ser estável pode exigir múltiplas GPUs de alto nível. Se você está limitado a uma única GPU consumer com 24GB, o batch size efetivo vai ser necessariamente pequeno, o que aumenta a variância das atualizações de gradiente. Técnicas como gradient checkpointing ajudam a economizar memória, mas não resolvem o problema de variância. Nesse caso, aceitar um treino um pouco mais ruidoso com mais epochs pode ser a melhor opção prática. Para quem está começando e não quer perder semanas experimentando combinações de hiperparâmetros, existem frameworks que automatizam parte desse processo. O Axolotl, por exemplo, oferece configs padrão razoáveis para vários cenários comuns. O LLaMA-Factory também tem uma aba de tuning com presets que cobrem a maioria dos casos práticos. O problema é que ninguém ensina a ler os logs adequadamente, e essas ferramentas não substituem o entendimento do que está acontecendo por baixo.

O que resta é observar os gráficos de treino com atenção. Loss de treino, loss de validação, gradient norm, learning rate atual. Cada um desses indicadores conta uma parte da história. Quando todos apontam na mesma direção, você sabe que o modelo está no caminho certo. Quando eles contradizem uns aos outros, é hora de parar e investigar antes de continuar gastando recurso.