Ranqueamento de busca do Airbnb (GBDT → DL, Experiences)

01 · CONTEXTO

Um marketplace de dois lados e uma lista curta

O Airbnb é um marketplace de dois lados: anfitriões oferecem seus espaços, chamados de anúncios, para serem reservados por hóspedes do mundo todo. A tarefa do ranqueamento de busca é responder ao hóspede com uma lista ordenada de um punhado de anúncios, escolhidos entre os milhares disponíveis no inventário.

O modelo em foco faz parte de um ecossistema de modelos que contribuem para decidir quais anúncios mostrar. Dentro desse ecossistema, é ele que ordena os anúncios disponíveis segundo a probabilidade de o hóspede reservar.

A primeira versão do ranqueamento foi uma função de pontuação escrita à mão. Trocá-la por um modelo de árvores de decisão com gradient boosting (GBDT) trouxe um dos maiores saltos de reservas da história da empresa. Com o tempo, porém, os ganhos em reservas online saturaram, com longos períodos de experimentos neutros, e isso tornou o momento maduro para tentar mudanças amplas no sistema.

O treino parte dos logs: o modelo novo aprende uma função de pontuação que coloque, o mais alto possível, as impressões dos anúncios que acabaram reservados. Depois ele é testado online em um framework de testes A/B, para ver se alcança um aumento estatisticamente significativo de conversões em relação ao modelo atual.

02 · EVOLUÇÃO DO MODELO

De uma rede simples a uma DNN

A transição para deep learning foi o auge de uma série de refinamentos iterativos. A equipe começou com arquiteturas customizadas e intrincadas e se viu sobrecarregada pela complexidade; os autores adaptam então o conselho de Karpathy para algo como não ser herói, no começo.

O primeiro modelo a chegar ao ar foi uma rede simples, de uma única camada oculta, que ficou neutra em reservas frente ao GBDT. Ela usava as mesmas features do GBDT, e o valor do exercício foi validar que o pipeline de redes neurais estava pronto para produção e apto a servir tráfego real.

O primeiro avanço veio de combinar a rede com a ideia do Lambdarank, para otimizar diretamente o NDCG. A formulação passou a ser de preferência par a par: com os anúncios vistos por quem reservou, montam-se pares de anúncio reservado e anúncio não reservado. Cada perda de par é ponderada pela diferença de NDCG que resultaria de trocar as posições dos dois anúncios, o que prioriza levar o anúncio reservado ao topo da lista, e não ao fim.

Em outra variante, a previsão final da FM entrou como feature da rede e, do GBDT, o índice da folha ativada em cada árvore entrou como feature categórica. Os modelos alternativos tinham desempenho comparável ao da rede em teste, mas os anúncios que eles priorizavam eram bem diferentes.

03 · FEATURES E SINAIS

Features que a rede consegue aproveitar

As features que alimentam a DNN são, em sua maioria, propriedades simples dos anúncios, como preço, comodidades e histórico de reservas, passadas diretamente com engenharia mínima. As exceções são saídas de outros modelos: o preço dos anúncios que usam o recurso Smart Pricing, vindo de um modelo especializado, e a similaridade do anúncio com o que o usuário já viu, calculada com embeddings de co-visualização.

1. Propriedades simples do anúncio entram na DNN quase sem transformação.

2. O preço dos anúncios com Smart Pricing é fornecido por um modelo especializado.

3. A similaridade com o que o usuário já viu vem de embeddings de co-visualização.

4. A DNN usa esses sinais para ordenar os anúncios segundo a probabilidade de reserva.

Alimentar a rede com as features do GBDT, sem tratamento, deu muito errado: a perda saturava no meio do treino e passos adicionais não tinham efeito. Para árvores de decisão, os valores numéricos exatos pouco importam desde que a ordem relativa faça sentido; as redes neurais, ao contrário, são bastante sensíveis a eles.

A suavidade da distribuição das features se mostrou uma ferramenta inestimável para achar bugs, porque os erros costumam destoar da distribuição típica, e um exemplo foram bugs de moeda nos preços registrados para certas geografias.

Para a localização, em vez de latitude e longitude brutas, usa-se o deslocamento em relação ao centro do mapa mostrado ao usuário, o que permite ao modelo aprender propriedades globais baseadas em distância, e não de geografias específicas.

Já a preferência por bairros, no GBDT, vinha de um pipeline muito engenheirado. Na rede bastou criar uma feature categórica que combina a cidade da consulta com a célula S2 do anúncio, mapeada a um inteiro por uma função de hash. O embedding dessa feature é aprendido por retropropagação e codifica a preferência de localização pelo bairro.

04 · O QUE NÃO FUNCIONOU

Tentativas que esbarraram no marketplace

As tentativas malsucedidas superam as bem-sucedidas. Duas delas ilustram como uma técnica eficaz e popular fora pode funcionar pior quando trazida para casa.

A primeira foi usar o id de cada anúncio como índice de um embedding, aprendendo uma representação por anúncio, técnica que teve sucesso em outras aplicações. Nas variações testadas, porém, o id do anúncio levou principalmente a overfitting.

A causa está no marketplace. Anúncios sofrem restrições do mundo físico: mesmo o mais popular só pode ser reservado um número limitado de vezes por ano. Essa limitação gera dados muito esparsos por anúncio, e o overfitting é consequência direta dela.

A segunda tentativa foi aprendizado multitarefa: o modelo previa ao mesmo tempo a probabilidade de reserva e de visualização longa, e o embedding do id era compartilhado entre as tarefas. Online, as visualizações longas subiram bastante, mas as reservas ficaram neutras. Inspeções manuais apontaram possíveis razões, como anúncios caros de alto padrão ou com descrições longas e difíceis de ler.

Também o dropout não ajudou: todas as variações de dropout testadas degradaram levemente as métricas offline.

05 · SISTEMA E TREINO

Treinar e servir a DNN

Uma busca do hóspede chega a um servidor que faz recuperação e pontuação, e que também produz logs. Um pipeline processa esses logs para criar os dados de treino, o treino é feito em TensorFlow e os modelos são então enviados ao servidor.

1. A busca do hóspede chega ao servidor, que faz recuperação e pontuação.

2. Para atender ao requisito estrito de latência da busca, a pontuação da rede usa uma biblioteca própria em Java.

3. O servidor também produz logs.

4. Um pipeline processa os logs para criar os dados de treino.

5. O treino do modelo é feito em TensorFlow com esses dados.

6. Os modelos treinados são enviados ao servidor de recuperação e pontuação.

Quando começaram a levar modelos TensorFlow à produção, a equipe não encontrou solução eficiente para pontuá-los numa stack Java. A conversão de dados de ida e volta entre linguagens introduzia uma latência que era um bloqueio, e por isso criaram uma biblioteca própria de pontuação de redes neurais em Java.

O pipeline de dados também escondia um gargalo. A maior parte do tempo de treino ia em parsear CSV e copiar dados; refazer o pipeline com Protobufs e a API Dataset acelerou o treino, elevou a utilização da GPU e permitiu escalar os dados de treino de semanas para meses.

Outro gargalo veio das features quase estáticas. Muitas eram propriedades de anúncios que raramente mudavam, e lê-las em cada exemplo de treino criava um gargalo de entrada.

1. Ler as propriedades quase estáticas do anúncio em cada exemplo de treino criava um gargalo de entrada.

2. Para eliminar esse tráfego de disco, o exemplo passou a carregar apenas o id do anúncio como feature categórica.

3. As features quase estáticas foram empacotadas num embedding não treinável indexado pelo id do anúncio.

4. Residente na memória da GPU, o embedding evita carregar do disco, via CPU, vários kilobytes de dados por exemplo.

5. Nas features que mudaram durante o período de treino, trocou-se um pequeno nível de ruído por velocidade de treino.

06 · INTERPRETABILIDADE E LIÇÕES

Entender a rede e o que muda no roteiro

A estimativa de importância de features e a interpretabilidade deram um passo atrás com a mudança para redes. A força das redes está em achar interações não lineares entre as features, o que também dificulta estudar uma feature isoladamente.

O TopBot ranqueia, para cada consulta de teste, os anúncios com o modelo e compara a distribuição dos valores das features entre os anúncios do topo e os do fim. Em um exemplo, a distribuição de avaliações era muito parecida entre topo e fim, o que indicava que aquela versão do modelo não usava avaliações como esperado.

Na retrospectiva, a mudança de roteiro é nítida: antes o foco era engenharia de features, e depois da migração tentar fazer manualmente uma matemática melhor sobre as features perdeu o brilho. Isso liberou a equipe para problemas de nível mais alto, como melhorar o objetivo de otimização.