Feed de vídeos curtos (TikTok)

01 · CONTEXTO E REQUISITOS

Um feed sem fim, montado para cada pessoa

O feed de vídeos curtos do TikTok se chama For You. Segundo o próprio TikTok, ele é alimentado por um sistema de recomendação que entrega a cada usuário o conteúdo com mais chance de interessá-lo, e não existe um único feed: cada pessoa recebe um feed próprio.

Ao praticar este caso, vale confirmar três requisitos com o entrevistador: o feed abre rápido, a rolagem não espera o vídeo seguinte e o sistema aprende com o comportamento do usuário. O caso reúne recomendação, entrega por CDN e uma esteira de dados em tempo real, e cada requisito puxa uma dessas partes.

O paper do Monolith, da ByteDance, cita o ranking de vídeos curtos e os anúncios online como negócios movidos por feedback do cliente sensível ao tempo, e afirma que um sistema de recomendação escalável e em tempo real é vital para eles.

02 · O QUE ALIMENTA O RANKING

Sinais, pesos e o que não conta diretamente

Entre os fatores que o TikTok lista para recomendar estão três grupos: interações do usuário (curtir ou compartilhar vídeos, seguir contas, comentar e criar conteúdo), informação do vídeo (legendas, sons e hashtags) e configurações de dispositivo e conta (idioma, país e tipo de dispositivo).

Os fatores são ponderados. Um indicador forte de interesse, como assistir a um vídeo longo do começo ao fim, pesa mais que um fraco, como espectador e criador estarem no mesmo país. Depois, os vídeos são ranqueados pela probabilidade de interesse e entregues ao feed de cada usuário.

Segundo o TikTok, nem o número de seguidores nem o desempenho anterior da conta são fatores diretos da recomendação.

03 · DESENHO DE ALTO NÍVEL

Da rolagem à lista de vídeos

O desenho abaixo é uma simplificação de estudo, não a arquitetura interna do TikTok. Ele separa dois caminhos: a lista de vídeos de cada usuário, montada pelo serviço de feed, e os arquivos de vídeo, entregues por uma CDN.

1. O app pede mais vídeos ao abrir ou rolar o feed, e o gateway encaminha o pedido ao serviço de feed.

2. O serviço de feed consulta o cache e, se houver uma lista ordenada para aquele usuário, devolve essa lista.

3. Sem lista pronta, o serviço de feed pede ao ranking, que lê os metadados dos vídeos candidatos, como legenda, som e hashtags, e os ordena pela probabilidade de interesse.

4. O app recebe a lista com os endereços dos vídeos; os bytes de vídeo não passam pelo serviço de feed e seguem por outro caminho.

5. A CDN responde com a cópia mais próxima do usuário e só vai ao armazenamento quando ainda não tem o arquivo.

04 · ENTREGAR O VÍDEO

Arquivos grandes, perto de quem assiste

Uma CDN é uma rede de servidores interligados. Segundo a AWS, quando o usuário está longe do servidor de origem, um arquivo grande como um vídeo demora a carregar; por isso o conteúdo é guardado em servidores da CDN geograficamente mais próximos dos usuários, e o objetivo principal é reduzir a latência.

O mecanismo de cache da CDN, para conteúdo estático, funciona assim: no primeiro pedido, a origem responde ao visitante e envia ao mesmo tempo uma cópia ao POP mais próximo; no pedido seguinte, do mesmo visitante ou de outro na mesma região, quem responde é o servidor de cache, não a origem. O POP guarda essa cópia como arquivo em cache. Com isso, a CDN pode reduzir a quantidade de dados que a origem precisa fornecer.

1. O primeiro espectador da região faz o primeiro pedido do arquivo, e o pedido chega à origem.

2. A origem responde ao espectador e, ao mesmo tempo, envia uma cópia ao POP mais próximo, que a guarda em cache.

3. Quando o segundo espectador da mesma região pede o mesmo arquivo, o POP responde sozinho, sem acionar a origem.

No protocolo HTTP, um pedido Range pede ao servidor apenas partes de um recurso, e a documentação da MDN cita os players de mídia com acesso aleatório entre os clientes para os quais isso é útil. O servidor responde com o status 206 Partial Content.

05 · APRENDER EM TEMPO REAL

Fechar o laço entre a ação e a recomendação

O paper do Monolith observa que o mesmo usuário, interessado em um tema, pode mudar de interesse a cada minuto. Por isso, os modelos de serving precisam ser atualizados com o feedback novo o mais perto de tempo real possível.

No Monolith, o treino tem duas etapas. No treino em lote, o worker lê mini-lotes de exemplos do armazenamento. Depois do deploy do modelo, o treino continua em modo online: o worker consome dados em tempo real e atualiza o PS de treino, que sincroniza periodicamente seus parâmetros com o PS de serving. Um PS (servidor de parâmetros) guarda parâmetros e os atualiza com os gradientes que os workers calculam. Os parâmetros esparsos são as tabelas de embeddings; os densos são os pesos da rede neural.

1. O app registra as ações do usuário, como clique ou curtida, em uma fila de ações.

2. As features ficam em outra fila, e o joiner online as junta com os rótulos das ações para produzir exemplos de treino.

3. Os exemplos de treino são escritos em uma fila, e o worker de treino os consome diretamente e atualiza o PS de treino.

4. O PS de treino envia periodicamente ao PS de serving só os parâmetros esparsos que foram tocados, em intervalos da ordem de minutos.

5. O servidor de modelo passa a ranquear com os parâmetros atualizados, e o efeito chega ao usuário.

6. A mesma fila de exemplos também alimenta o treino em lote, por meio de um job que despeja os dados no HDFS.

O joiner enfrenta dois problemas práticos. Ações e features chegam sem garantia de ordem no tempo, então cada requisição tem uma chave única para casar uma com a outra. E as features que esperam muito por uma ação atrasada ficam em um armazenamento chave-valor em disco, consultado só depois do cache em memória.

A sincronização é incremental. O PS de serving não pode parar de servir durante a atualização, então o Monolith envia só os parâmetros esparsos tocados, em intervalos de nível de minuto. Os parâmetros densos mudam muito mais devagar que os embeddings esparsos e são atualizados com menos frequência.

A memória das tabelas de embeddings é outro gargalo. A tabela seria grande demais para a memória de uma única máquina, e hashing com colisões piora a qualidade do modelo à medida que a tabela cresce. O Monolith usa uma tabela hash baseada em Cuckoo hashing, que insere chaves novas sem colidir com as existentes, filtra os IDs antes de admiti-los e faz IDs inativos expirarem depois de um período predefinido.

Na tolerância a falhas, o Monolith tira snapshot de todos os PS de treino todo dia. Se um PS falha, perde-se um dia de atualizações, mas os autores relatam que a degradação de desempenho foi tolerável nos experimentos e resumem o resultado como a troca de confiabilidade do sistema por aprendizado em tempo real. No experimento com os dados do Criteo, mais frequência de sincronização melhorou a qualidade do modelo.

06 · PARTIDA A FRIO E LIMITES

Usuário novo, diversidade e o que o caso não cobre

Para um usuário novo, o TikTok convida a escolher categorias de interesse, como animais de estimação ou viagens, para ajustar as primeiras recomendações. Quem não escolhe começa com um feed geral de vídeos populares, e as primeiras curtidas, comentários e replays iniciam as recomendações seguintes.

Há também regras de diversidade e elegibilidade. O feed geralmente não mostra dois vídeos seguidos com o mesmo som ou do mesmo criador, e não recomenda conteúdo duplicado, já visto ou considerado spam. Vídeos recém-enviados ou em revisão, além de spam, podem ser inelegíveis para recomendação. O TikTok diz ainda que mostrar de vez em quando um vídeo sem relação com os interesses declarados é um componente intencional da sua abordagem.