Pinterest reverte queda de quase 6% no ranking do Homefeed ao treinar embeddings em múltiplas epochs
Aprofundamento CEVIU
Aprofundamento
O problema central é de overfitting em grandes ID embeddings. Segundo o time de engenharia do Pinterest, essas tabelas são pré-treinadas para aprender representações de Pins e depois ajustadas dentro do modelo de ranking do Homefeed. Por terem capacidade enorme e receberem atualizações esparsas e de cauda longa, elas tendem a memorizar IDs de exemplos repetidos em vez de generalizar. Por isso o fine-tuning ficava limitado a uma epoch. Ao estender de uma para duas epochs, a métrica offline de save caiu quase 6%.
Para localizar a causa, o time isolou componentes. Congelar a tabela fez a regressão sumir e, em três epochs, rendeu +1,25% sobre o modelo de uma epoch. Isolar caminhos de gradiente (contrastivo, transformer, feature cross) evitou o overfitting, mas não bateu a tabela totalmente congelada. A receita final: manter a tabela congelada na primeira epoch e liberá-la na segunda, com janela de dados menor. O resultado superou tanto o modelo de uma epoch quanto o multi-epoch totalmente congelado. Com janela de 20 dias, houve lift de 1,16%. Congelar até a última epoch deu +0,49% numa janela de 10 dias, enquanto treinar a tabela já na primeira epoch gerou regressão de 0,80%. Na eficiência, o lookup distribuído de embeddings chegava a mais de 15% do tempo de treino. Um pipeline semissíncrono sobrepõe a comunicação do próximo batch à computação do atual, com atraso limitado a uma atualização de embedding, e sem degradação de qualidade observada. O time optou por implementação própria porque os utilitários de pipelining do TorchRec não integraram bem com seus trainers. Vale separar o artigo (assinado por engenheiros do Pinterest) da técnica descrita, que é um método interno de treino, sem repositório público localizado. Leia o artigo original para os detalhes.
Por que isso importa
Para quem opera modelos de recomendação com tabelas de ID grandes, a lição é tratar o momento da atualização dos embeddings como hiperparâmetro. O trabalho mostra uma tendência quase linear entre atrasar a atualização e melhorar o resultado. Também há limite: os ganhos saturaram perto de três epochs, e os números valem para o Homefeed, não são garantia para outros contextos.
Linha do tempo
Pinterest detalha como reverteu a queda de quase 6% no ranking do Homefeed com embeddings congelados na primeira epoch e pipeline semissíncrono.
Perguntas frequentes
Por que treinar embeddings por várias epochs causa overfitting?
As tabelas de ID têm capacidade enorme e recebem atualizações esparsas. Com exemplos repetidos, o modelo memoriza IDs em vez de aprender representações gerais. No Homefeed, isso derrubou a métrica offline de save em quase 6% ao passar de uma para duas epochs.
Qual foi a solução do Pinterest?
Desacoplar a otimização dos embeddings do restante do modelo. A tabela fica congelada na primeira epoch e é adaptada depois, na segunda. Isso superou o modelo de uma epoch e também o multi-epoch com tabela totalmente congelada.
Como o pipeline semissíncrono reduz o tempo ocioso de GPU?
Ele sobrepõe a comunicação de embeddings do próximo batch à computação do batch atual, usando CUDA streams e eventos. O batch B usa embeddings atualizados até o B menos 2, um atraso limitado de uma atualização. O time não observou perda de qualidade.
Isolar gradientes não bastava?
Evitou o overfitting, mas não superou a tabela totalmente congelada. Permitir só o gradiente contrastivo funcionou, porém com resultado pior. Já contrastivo mais feature cross teve overfitting catastrófico.
Fontes
- medium.comfonte original
- Categoria
- CEVIU Dados
- Publicado
- 09 de novembro de 2026
- Editoria
- CEVIU Dados
