Netflix: linhas personalizadas, RecSysOps e modelo fundacional

01 · CONTEXTO

Muitos modelos, um custo que cresce

O sistema de recomendação da Netflix não é um modelo só. A própria empresa descreve uma variedade de modelos de aprendizado de máquina especializados, cada um para uma necessidade distinta, como “Continue Watching” e “Today’s Top Picks for You”.

Com a expansão dos algoritmos de personalização para atender a novas necessidades de negócio, a manutenção do sistema ficou cara. Além disso, era difícil transferir inovações de um modelo para outro, porque a maioria é treinada de forma independente mesmo usando fontes de dados comuns.

1. Vários modelos partem das mesmas fontes de dados de interação.

2. Cada modelo especializado é treinado de forma independente, o que dificulta transferir inovações de um para outro.

3. Muitos desses modelos ficam limitados a uma janela temporal curta do histórico, por restrições de latência de serving ou de custo de treino.

A resposta descrita pela equipe é uma arquitetura em que o aprendizado das preferências dos membros fica centralizado e pode ser aproveitado por vários modelos.

02 · DADOS E TREINO

Interações viram tokens

A Netflix compara o volume de interações ao de tokens dos grandes modelos de linguagem: com mais de 300 milhões de usuários ao fim de 2024, são centenas de bilhões de interações. Para aproveitar esse volume, usa-se uma tokenização das interações, que identifica os eventos significativos e reduz a redundância.

A tokenização funde ações adjacentes em tokens de nível mais alto; a duração total assistida, por exemplo, pode precisar ser somada. Há uma troca: tokenização com perda demais joga fora sinal valioso, e uma sequência detalhada demais pode exceder limites de tempo de processamento e de memória.

Mesmo assim, o histórico de usuários ativos pode ter milhares de eventos, além do que transformers com atenção padrão comportam. Na inferência, a janela de contexto costuma ficar em centenas de eventos, não por limite do modelo, mas porque esses serviços exigem latência de milissegundos.

Para contornar isso no treino, a equipe usa atenção esparsa, que estende a janela a várias centenas de eventos mantendo a eficiência, e amostragem por janela deslizante, com janelas de interações que se sobrepõem. Na inferência com decodificação em vários passos, o KV caching reaproveita cálculos anteriores.

Para prever a próxima interação, combinam-se atributos do momento do pedido, como horário de login, dispositivo ou local, com atributos pós-ação do passo anterior, como o título interagido e a duração.

O objetivo padrão é a predição autorregressiva do próximo token, como no GPT, mas com ajustes. As interações não têm o mesmo peso: um trailer de 5 minutos não deve contar como um filme de 2 horas assistido por inteiro. Para capturar dependências de longo prazo, pode-se prever vários tokens à frente a cada passo, e campos como gênero podem servir de alvos auxiliares, com o ID do item como alvo principal.

03 · COLD START

Títulos novos sem histórico

Títulos novos entram no catálogo com frequência. O modelo precisa estimar a preferência dos membros por títulos recém-lançados antes que alguém tenha interagido com eles.

Duas capacidades atendem a isso. Primeiro, o treino incremental: retreinar com o histórico de todos os membros com frequência é impraticável, então novos modelos são aquecidos reaproveitando parâmetros do anterior e inicializando parâmetros novos para os títulos novos. Segundo, o modelo combina embeddings de ID aprendíveis com embeddings aprendíveis dos metadados.

A mistura usa um mecanismo de atenção baseado na “idade” da entidade, em vez de uma soma simples. Com alguma aleatoriedade no treino, o modelo é incentivado a aprender com os metadados e não só com o ID. Assim, títulos recém-lançados ou de pré-lançamento têm embeddings razoáveis mesmo sem dados de interação.

04 · COMO O MODELO É USADO

Predição, embeddings e fine-tuning

Os times consumidores têm três caminhos. O primeiro é usar o modelo como preditor direto, que tem várias cabeças de predição, por exemplo para preferências por gênero. O segundo é usar embeddings de membros e entidades, calculados em jobs em lote e guardados para uso offline e online. O terceiro é o fine-tuning com dados da aplicação, integrando o modelo completo ou subgrafos.

1. O treino consome o histórico de interações e também os metadados dos títulos.

2. O treino prevê a próxima interação e é aquecido a partir de parâmetros do modelo anterior.

3. O modelo fundacional passa a concentrar o aprendizado de preferências dos membros.

4. Jobs em lote calculam embeddings e os guardam para uso offline e online.

5. Modelos especializados usam os embeddings como atributos ou para gerar candidatos.

6. Eles também podem integrar o modelo ou subgrafos e fazer fine-tuning com menos dados e computação.

Embeddings trazem um risco para quem os consome: o espaço tem dimensões arbitrárias e não interpretáveis e é incompatível entre execuções de treino diferentes. Para estabilizá-lo, a equipe aplica uma transformação ortogonal de baixo posto, de modo que as dimensões mantenham o significado quando o modelo base é retreinado.

Segundo a Netflix, os experimentos confirmam que a lei de escala também vale para o modelo fundacional, com melhorias consistentes à medida que dados e tamanho do modelo aumentam.

05 · OPERAÇÃO

RecSysOps: manter o sistema saudável

Operar um sistema de recomendação em larga escala exige alta disponibilidade e vazão e envolve muitos serviços e equipes; código e modelos novos vão à produção com frequência. A Netflix descreve o RecSysOps, um conjunto de boas práticas para operar o sistema, que inclui o monitoramento de ponta a ponta e tem quatro componentes.

A detecção é o componente mais crítico, porque dispara os demais. Entre as lições estão não confiar só nas auditorias das equipes parceiras e auditar, da própria perspectiva, todas as entradas e saídas. Do lado do membro, um item escolhido que o modelo de ranking não pôs no topo é um problema em potencial; do lado dos itens, as equipes apontaram preocupação com cold start e viés de produção.

Na predição, o cold start importa porque cada item é lançado uma única vez. Por isso, com dados históricos, a equipe construiu um modelo que prevê problemas de cold start com uma semana ou mais de antecedência.

1. A equipe audita entradas e saídas do serviço da própria perspectiva, sem depender só das auditorias dos parceiros.

2. Quando o membro escolhe um item que o ranking não pôs no topo, o caso é um problema em potencial a analisar.

3. A predição estima antes do lançamento se um item terá problema de cold start.

4. Para reproduzir problemas, o serviço registra candidatos, contexto, atributos e id do modelo para uma fração do tráfego.

5. O diagnóstico reproduz o caso e checa se a causa está nas entradas ou no próprio modelo.

6. A resolução escolhe um hotfix de um menu preparado com antecedência.

06 · DIAGNÓSTICO E RESOLUÇÃO

Da causa ao conserto

No diagnóstico, o primeiro passo é reproduzir o problema de forma isolada, o que exige registrar candidatos, contexto, atributos e id do modelo de serving. Para reduzir o custo, o registro cobre só uma fração do tráfego.

Para validar as entradas, uma solução simples é comparar os valores dos atributos com os de um item ou membro comparável. Em um caso, isso expôs que o idioma de um item estava mal configurado no banco upstream. Se as entradas estão corretas, investiga-se o modelo e seus dados de treino.

Na resolução, o hotfix em um modelo de ML é difícil: os modelos são muito otimizados, demoram a treinar e qualquer alteração manual tende a piorar as recomendações. Por isso é melhor ter um menu de hotfixes preparado com antecedência, com aplicação simples. As verificações de detecção e predição devem rodar de forma automática e regular.