Contração De Treinamento Frequente

O que é contração de treinamento frequente

A técnica se chama assim porque você reduz periodicamente a quantidade de dados que passa pelo modelo durante o treino, mantendo os parâmetros que já aprenderam e descartando o que não traz valor. O nome em si é meio arbitrário — na prática, é sobre compactar o treinamento repetitivo. Muita gente confunde com pruning ou quantização, mas não é a mesma coisa. Pruning remove pesos. Aqui você está removendo amostras duplicadas, quase-idênticas ou ruído puro do conjunto de treinamento, e fazendo isso várias vezes ao longo do processo, não só no início. O objetivo real é evitar que o modelo gaste ciclos atualizando pesos para dados que já foram mais que suficientes. Você economiza tempo de GPU, reduz overfitting e ainda mantém a accuracy praticamente intocada na maior parte dos casos.

Por que a contração de treinamento frequente funciona

Ao contrário do que parece, rodar o modelo em dados redundantes não ajuda em nada. O gradiente simplesmente se repete. Após algumas épocas, a informação marginal de uma nova amostra idêntica à anterior é praticamente zero. Continuar treinando com esse volume original é jogar energia no vazio. O que acontece na prática é que o modelo converge rápido nos primeiros ciclos e depois passa a memorizar ruído em vez de aprender padrões novos. A contração freqüente corta esse supérfluo antes que ele cause dano. Já vi isso funcionando de verdade. Em um projeto de classificação de texto, tínhamos um dataset com cerca de 400 mil amostras, das quais aproximadamente 35% eram duplicatas ou muito similares. Rodamos o baseline completo primeiro, depois aplicamos a contração gradual a cada três épocas. O resultado: redução de 68% no tempo total de treino, sem queda perceptível na F1-score. A diferença era na ordem de 0.002, basicamente ruído de medição.

Como aplicar na prática

Vamos ao método direto, sem rodeios. Primeiro você precisa transformar cada amostra em um vetor representativo. Use um modelo pré-treinado leve, não precisa ser anything pesado. Um BERT small ou até um SentenceTransformer com dimensão 384 já resolve. Salve esses embeddings em disco. Fazer isso todo treino novo é desperdício. No meu caso, usei um modelo distilbert-base-multilingual-cased rodando em batch de 512. Levou cerca de 12 minutos para os 400 mil embeddings num RTX 3090. Depois disso, o arquivo ficou com 6.2 GB, tranquilo de carregar de novo.

Passo 2 — Identificar cluster de similaridade

Use uma métrica de similaridade coseno e agrupe amostras com score acima de 0.92. Esse threshold de 0.92 não é dogma — é onde eu parei de cortar dados úteis. Abaixo disso, você começa a remover variações legítimas. Acima, tá tudo no lixo. Para grandes datasets, brute force é inviável. Use approximate nearest neighbors com FAISS. Index IVF16384 + HNSW32 foi o que me deu boa performance com recall de 0.94 nas consultas. O tempo de query pra 400 mil vetores ficou em torno de 40 segundos.

Passo 3 — Contrair e re balancear

Aqui é onde a coisa fica interessante. Não basta jogar fora os duplicados. Você precisa decidir qual amostrarepresenta cada cluster. Minha heurística favorita: fique com a amostra mais próxima da mediana do embedding do cluster, não a mais central. Amostras centrais tendem a ser as mais genéricas e menos informativas. A mediana traz um ponto que representa bem a dispersão real. Depois de selecionar os representantes, recombo os pesos de batch durante o treino. Como você tem menos amostras agora, aumente o learning rate em 10 a 15% para compensar a redução de estocasticidade. Se não fizer isso, o modelo converge mais devagar do que would would ter convergido com os dados originais.

Passo 4 — Repetir ciclicamente

A periodicidade depende do seu dataset e do tamanho dele. No geral, a cada duas a cinco épocas. Teste com validação tracking. Se a curva de loss validar não melhorar entre duas contrações consecutivas, você tá cortando cedo demais. Se melhorar rápido entre as contrações, pode alongar o intervalo. O ciclo completo — embedding, clustering, seleção, rebalanceamento — leva em média 15 a 20 minutos no setup que descrevi. Comparado ao treino que economiza (que pode ser de horas), o payoff é claro.

Pegadinhas que ninguém conta

A primeira armadilha: a contração funciona mal em datasets extremamente desbalanceados. Se uma classe tem 10 mil amostras e outra tem 200, você vai eliminar grande parte das 200 e o modelo vai virar enviesado. Minha solução foi aplicar a contração separadamente por classe, com um mínimo absoluto de 50 amostras por cluster após o corte. Assim garantimos que nenhuma classe desaparecesse. A segunda: dados temporais ou sequenciais não se prestam bem a isso. Se a ordem importa, remover duplicados pode quebrar a consistência temporal. Nesses casos, restrinja a contração a janelas de tempo, não ao dataset inteiro. Terceira pegadinha mais sutil: alguns frameworks de treino mantêm cache interno de batches. Se você contrair o dataset mas o framework continuar servindo batches do cache antigo, sua contração é inútil. Verifique isso. No PyTorch puro não tem esse problema, mas em pipelines como DataLoaders com prefetch alto ou em sistemas como TensorFlow datasets, pode ser preciso resetar o iterator após cada contração.

Quando não usar

Se seu dataset já é pequeno — digamos, menos de 5.000 amostras — a contração não vale o overhead computacional. O ganho de tempo seria de minutos, não de horas. Nesse cenário, focaria mais em data augmentation dirigida do que em contração. Também não recomendo se você tá trabalhando com datasets sintéticos gerados por LLMs. Esses dados têm alta variância interna mesmo quando parecem similares. A similaridade coseno vai sugerir remoções que na prática estragam a diversidade do set.

Resumo técnico

O método básico é: embedar clusters por similaridade coseno com threshold ~0.92 selecionar representantes pela mediana do cluster rebalancear learning rate repetir a cada 2 a 5 épocas. O tempo total de setup inicial gira em torno de 15 minutos. O ganho real aparece quando o treino original duraria mais de uma hora por época. Não é bala de prata. Funciona bem em datasets textuais e de imagem com redundância clara. Não funciona bem em dados temporais, sequenciais, sintéticos ou muito pequenos. Escolha o contexto certo e o retorno é consistente. Se quiser testar, comece com um subset de 10% do dataset pra validar o pipeline antes de rodar no total. Evita gastar recurso à toa se o threshold estiver errado pra o seu caso específico.