Voltar

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

  1. 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

Avalie este artigo:
Categoria
CEVIU Dados
Publicado
09 de novembro de 2026
Editoria
CEVIU Dados

Quer receber mais sobre CEVIU Dados?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser