Airbnb: aprendizado profundo em busca — +0,6% de reservas de uma nova arquitetura e +14% de reservas para novas listagens

• Applying Deep Learning to Airbnb Search (KDD 2019) — Airbnb / arXiv (Haldar et al.), 2018-10-22
• Improving Deep Learning for Airbnb Search (KDD 2020) — Airbnb / arXiv (Haldar et al.), 2020-02-13
• Listing Embeddings in Search Ranking (800 млн сессий, +21% CTR карусели) — Airbnb Engineering Blog (Mihajlo Grbovic), 2018-03-13

Contexto

A classificação de busca é o mecanismo ML central da Airbnb: ela decide quais de milhões de listagens um hóspede vê nos resultados da primeira página — e portanto quais hosts recebem reservas. O investimento em busca se converte em dinheiro diretamente, razão pela qual sua evolução é documentada pelo time com rara franqueza para a indústria: em dois artigos KDD marcantes — 'Applying Deep Learning to Airbnb Search' (preprint arXiv outubro 2018, KDD 2019) e 'Improving Deep Learning for Airbnb Search' (arXiv fevereiro 2020, KDD 2020), ambos de autoria de Malay Haldar e colegas.

Esses artigos são atípicos para o gênero: em vez de mostrar uma 'arquitetura inovadora', o time descreve um caminho de anos de iterações com porcentagens exatas de ganho de reservas de testes A/B online — e disseca os experimentos fracassados com igual detalhe. Os autores declaram claramente: 'deep learning foi aprendizado profundo para nós', e destilam sua metodologia no princípio de que os usuários guiam e o modelo segue — primeiro encontre o problema nos dados de comportamento real dos hóspedes, depois mude a arquitetura, não o contrário.

Pelo primeiro artigo, a Airbnb já tinha infraestrutura ML madura em torno da busca. Personalização em tempo real em embeddings de listagens estava em produção desde 2017: o time de Mihajlo Grbovic treinou representações vetoriais 32-dimensionais de casas em mais de 800 milhões de sessões de cliques de busca em 4,5 milhões de listagens ativas — o carrossel Similar Listings nesses embeddings ganhou 21% CTR. O ranking em si era acionado por um modelo de árvore de decisão com gradient boosting (GBDT) que tinha substituído uma função de pontuação manual — um lançamento que o time chama de uma das maiores melhorias de passo em reservas na história da empresa. Os problemas começaram após esse sucesso.

Problema

O primeiro modelo de gradient boosting entregou um ganho poderoso, mas os ganhos depois secaram: o time continuou aumentando o esforço enquanto testes A/B retornavam neutros repetidas vezes. Este é o platô clássico de um sistema ML maduro — quando a afinação de features e hiperparâmetros para de mover a métrica de negócio, levantando a questão de uma mudança de paradigma com resultado imprevisível.

O problema de busca da Airbnb também resiste a soluções prontas da literatura de ranking. Usuários quase nunca repetem uma query para o mesmo 'item': um hóspede que visitou Paris busca por Roma a seguir. A oferta é fortemente restrita: uma casa para um conjunto de datas pode ser reservada por apenas um hóspede, então resultados não podem simplesmente mostrar 'os mais populares'. O marketplace é bilateral — o ranking equilibra interesses de hóspedes e hosts, e sinais comportamentais (cliques, saves, solicitações de reserva) são ruidosos e enviesados.

Dois vieses sistêmicos mereciam ataques dedicados. Primeiro, cold start: novas listagens sem histórico de interação ficavam atrás por cerca de 6% NDCG comparadas às estabelecidas; a ironia é que as mesmas features de engajamento que dão ao modelo seu poder (removê-las custou 4,5% NDCG) enterravam recém-chegadas no fundo dos resultados — e sem novas listagens, o crescimento de oferta sufoca. Segundo, position bias: hóspedes reservam o que é mostrado mais acima com maior frequência, então dados de treinamento inflacionam a qualidade de listagens em posição alta, e um modelo treinado nesses logs auto-confirma erros antigos de ranking.

Solução

A mudança para redes neurais foi em iterações, cada uma validada por um teste A/B de reservas online. A primeira tentativa — uma rede simples com uma única camada oculta de 32 unidades ReLU — provou ser neutra em reservas contra GBDT. O avanço veio com uma NN Lambdarank: uma perda de ranking em pares reservado/não-reservado ponderada por deltas NDCG. Depois um ensemble onde índices de folha GBDT e predições de factorization machine alimentavam a rede como features. O final do primeiro artigo é uma rede profunda: 195 features (após expandir categóricas em embeddings), duas camadas ocultas de 127 e 83 ReLUs, treinada em 1,7 bilhões de pares impressão-resultado. O DNN entregou ganhos comparáveis ao empilhamento de todos os modelos anteriores — com um sistema muito mais simples.

Os fracassos recebem espaço igual nos artigos. Embeddings de ID de listagem — um truque padrão da indústria — levaram a overfitting: até a casa mais popular é reservada no máximo 365 vezes por ano, não suficiente sinal por ID. Aprendizado multi-tarefa (predizendo tanto reservas quanto long views) aumentou bruscamente visualizações — e não moveu reservas. Toda variante de dropout degradou métricas offline; conexões residuais, uma arquitetura Deep & Wide e redes de atenção 'falharam em mover a agulha'. Lições separadas dizem respeito a dados e engenharia: sem normalização de features, o treinamento saturou no meio da corrida, enquanto converter o pipeline de CSV para Protobuf acelerou treinamento 17x e levou utilização de GPU a ~90%.

O segundo artigo (KDD 2020) é o próximo turno. Uma arquitetura two-tower dividiu o modelo em uma 'query tower' e uma 'listing tower', cada uma comprimindo seu lado em um vetor 100-dimensional; a relevância é a distância entre vetores. Isso não é apenas qualidade (+0,7% NDCG online) mas performance: a complexidade de scoring cai de O(N·H·(Q+L)) para O(N·H_l·L + H_q·Q), cortando a latência 99º-percentil em 33%.

Para cold start, eles construíram um mecanismo de estimativa de engajamento para novas listagens: no lugar de histórico faltante, o modelo recebe um forecast de interação computado a partir de listagens vizinhas. Position bias foi vencido com position dropout: a posição de exibição é alimentada ao modelo como uma feature, mas é aleatoricamente zerada durante o treinamento (a taxa escolhida — 0,15) assim o modelo não aprende 'topo da página = bom'. Falhas são registradas novamente: monotonicidade rígida de preço reduziu reservas em 1,6%; a versão 'flexível' — bela offline — reduziu reservas em 0,67% em produção, e o teste foi revertido.

Resultado

Os resultados da segunda onda são fixados em testes A/B online. A arquitetura two-tower: +0,6% reservas e +0,75% receita com −33% latência de scoring p99; um efeito colateral curioso — o preço médio de casas reservadas caiu 2,3%, significando que o modelo ficou melhor em combinar preferências de preço dos hóspedes. O mecanismo cold start elevou reservas de novas listagens em 14% (e sua participação de impressão em primeira página por 14%), adicionando +0,38% ao total de reservas e tornando o lado de oferta mais saudável. Position dropout trouxe mais +0,7% reservas e um inesperado +1,8% receita; reservas de hotéis boutique — um segmento prejudicado pelo viés — subiram 1,1%.

A escala deve ser lida corretamente: frações de um percentual aqui não são 'resultados pequenos'. Em volumes da Airbnb, +0,6% reservas é um número absoluto enorme, e a soma de ganhos sequenciais (+0,6%, +0,38%, +0,7% apenas do segundo artigo) se compõe em efeito de dois dígitos cumulativo ao longo dos anos. O time em si chama a aplicação de redes neurais à busca uma das maiores histórias de sucesso ML da empresa. Os limites também são honestos: todos os números são testes A/B internos auto-reportados da empresa, mas o detalhe metodológico e os fracassos publicados dão a esses números mais peso que um press release típico.

Em nossa visão, o valor principal do par de artigos não é as arquiteturas específicas (redes two-tower e mitigação de position bias há muito se tornaram padrões de indústria) mas a cultura documentada: o único árbitro de cada mudança foi um teste online em dinheiro (reservas), com métricas offline servindo apenas como filtro de hipótese. O caso de 'soft monotonicity' de preço é revelador: uma ideia intuitivamente certa, bela offline, perdeu 0,67% de reservas em produção — sem disciplina de teste online teria permanecido no sistema.

Nossa segunda observação: a Airbnb efetivamente publicou um 'mapa de pegadinhas' para todos levando redes neurais para ranking de busca — do overfitting de ID à saturação sem normalização. Empresas retomando este caminho economizam meses não nos sucessos de outros mas nos fracassos de outros; nesse sentido, publicar honestamente fracassos é um caso raro de altruísmo em engenharia que funciona também como branding de empregador.

Lições aprendidas

1. Um platô após sucesso inicial é normal: quando GBDT parou de entregar, a resposta foi uma mudança de paradigma (redes neurais), não afinação sem fim de features.
2. Valide toda melhoria com a métrica de dinheiro online (reservas), não apenas NDCG offline: a 'soft monotonicity' de preço foi bela offline e falhou em produção em −0,67%.
3. Cold start merece seu próprio mecanismo: a estimativa de engajamento para novas listagens elevou suas reservas em 14% e tornou o marketplace mais saudável.
4. Viés de posição corrompe dados de treinamento: o truque simples de position-dropout (taxa 0,15) se converteu em +0,7% reservas e +1,8% receita.
5. Arquitetura pode se pagar em performance: a rede two-tower não apenas adicionou reservas mas cortou latência p99 em 33% reduzindo complexidade de scoring.
6. Truques padrão não se transferem cegamente: embeddings de ID de listagem sofrem overfitting (uma casa reserva no máximo 365 vezes por ano), e dropout degradou métricas offline.
7. Publique fracassos também: os artigos da Airbnb são valiosos precisamente porque documentam tentativas fracassadas (residual, Deep & Wide, atenção, multi-tarefa) que economizam meses de outros times.

Perguntas frequentes