Google Wide & Deep (Google Play)

01 · CONTEXTO

Memorizar ou generalizar

Este caso vem de um artigo do Google sobre a loja de apps do Google Play. Um sistema de recomendação é visto ali como um sistema de busca com ranking: a consulta reúne informações do usuário e do contexto, e a saída é uma lista ordenada de itens. A tarefa é achar os itens relevantes num banco e ordená-los por objetivos como cliques ou compras.

O desafio central é equilibrar duas capacidades. Memorização é aprender a coocorrência frequente de itens ou variáveis e explorar o histórico; ela tende a gerar recomendações mais pertinentes aos itens com que o usuário já agiu. Já a generalização tende a aumentar a diversidade do que é recomendado.

Cada lado tem um ponto fraco. Os produtos cruzados de variáveis esparsas memorizam bem, mas não generalizam para pares que não apareceram no treino. Os embeddings generalizam para pares nunca vistos, mas, quando as interações são esparsas, podem generalizar demais e recomendar itens menos relevantes; para essas regras de exceção, modelos lineares com produtos cruzados são mais econômicos em parâmetros.

02 · O MODELO

Wide, deep e treino conjunto

O componente wide é um modelo linear generalizado, e uma das transformações mais importantes é o produto cruzado, que captura interações entre variáveis binárias e acrescenta não linearidade ao modelo.

O componente deep é uma rede neural feed-forward. Cada variável categórica esparsa vira um vetor denso de baixa dimensão, o embedding, que começa aleatório e é treinado para minimizar a função de perda final.

Os dois componentes são combinados e treinados em conjunto, o que é diferente de um ensemble. No ensemble, os modelos são treinados separadamente e só combinam as previsões na inferência. No treino conjunto, todos os parâmetros são otimizados ao mesmo tempo, inclusive os pesos da soma das duas partes, e os gradientes seguem da saída para as duas partes simultaneamente.

Uma consequência é o tamanho do modelo: no treino conjunto a parte wide só precisa complementar as fraquezas da parte deep com poucas transformações cruzadas, em vez de ser um modelo wide completo.

03 · O SISTEMA

Recuperar candidatos e ranquear

O catálogo da loja é grande demais para pontuar tudo a cada consulta: com mais de um milhão de apps, isso é inviável dentro do requisito de latência, que costuma ser da ordem de 10 milissegundos. Por isso o primeiro passo é a recuperação, que devolve uma lista curta combinando modelos aprendidos e regras definidas por humanos, e só depois o ranking ordena essa lista. O artigo foca no modelo de ranking.

1. A consulta, com variáveis do usuário e do contexto, nasce quando a pessoa abre a loja e chega ao serviço de recomendação.

2. A recuperação reduz o catálogo a uma lista curta de candidatos, combinando modelos aprendidos e regras definidas por humanos.

3. Os servidores de modelo recebem os candidatos e as variáveis do usuário para pontuar cada app.

4. As pontuações vêm de uma passagem de inferência pelo modelo; os apps são ordenados da maior para a menor pontuação e exibidos nessa ordem.

5. Consultas, impressões e ações do usuário são gravadas em logs, que viram dados de treino.

04 · PRODUÇÃO

Treino contínuo e serving rápido

O pipeline tem etapas de geração de dados, treino e serving. Cada exemplo corresponde a uma impressão e o rótulo é a aquisição do app. Também se geram os vocabulários, tabelas que mapeiam cadeias de variáveis categóricas para IDs inteiros.

No experimento, a parte wide usa o produto cruzado entre apps instalados pelo usuário e apps exibidos. Os embeddings são concatenados com as variáveis densas num vetor de cerca de 1200 dimensões, que alimenta 3 camadas ReLU e a saída logística. O treino usou mais de 500 bilhões de exemplos.

Retreinar do zero a cada novo conjunto de dados é caro e atrasa o modelo atualizado, então um sistema de warm-start inicializa o novo modelo com os embeddings e os pesos lineares do anterior. Antes de ir para os servidores, o modelo passa por uma execução de teste e por uma comparação de qualidade contra o anterior.

1. Os logs viram exemplos rotulados e os vocabulários são gerados na etapa de geração de dados.

2. O treinador recebe os exemplos e é inicializado com os embeddings e os pesos lineares do modelo anterior, em vez de treinar do zero.

3. Antes de seguir, o modelo novo passa por uma execução de teste e tem a qualidade comparada à do anterior como checagem de sanidade.

4. Treinado e verificado, o modelo é carregado nos servidores de modelo.

No serving, cada requisição precisa ser atendida na ordem de 10 ms. Pontuar todos os candidatos num único lote com uma thread levava 31 ms; dividir em lotes menores e usar multithreading reduziu a latência no cliente para 14 ms, incluindo a sobrecarga de serving. No pico, os servidores pontuam mais de 10 milhões de apps por segundo.

05 · RESULTADOS

O que os experimentos mostraram

O experimento online foi um teste A/B de 3 semanas. O controle usava o modelo anterior, uma regressão logística só wide altamente otimizada, com muitos produtos cruzados. O Wide & Deep elevou a taxa de aquisição de apps na página principal em +3,9% sobre o controle, e teve +1% de ganho sobre o modelo só deep; os dois resultados foram estatisticamente significativos.

O AUC offline do Wide & Deep é só um pouco maior, e o impacto é mais significativo no tráfego online. Os autores sugerem como possível razão que, offline, impressões e rótulos são fixos, enquanto o sistema online pode gerar recomendações exploratórias que combinam generalização e memorização e aprender com as novas respostas dos usuários.

O sistema foi levado a produção no Google Play, loja de apps com mais de um bilhão de usuários ativos e mais de um milhão de apps.