Pesquisa em Power-learning Ranking de Experiências do Airbnb - Agatetepê
Como construímos e iteramos em um aprendizado de máquina na plataforma Search Ranking para um novo mercado de dois lados e como o ajudamos a crescer.
Mihajlo Grbovic em Airbnb Engineering & Data Science Seguir 5 de fev · 20 min ler
Por: Mihajlo Grbovic, Eric Wu, Pai Liu, Chun Como Tan, Liang Wu, Yu Bo, Alex Tian
As Experiências do Airbnb são atividades artesanais projetadas e conduzidas por anfitriões especializados que oferecem um sabor único da cena e cultura locais. Cada experiência é avaliada pela qualidade por uma equipe de editores antes de chegar à plataforma.
Lançamos Experiências do Airbnb em novembro de 2016 com 500 Experiências em 12 cidades do mundo todo. Durante 2017, aumentamos o negócio para 5.000 Experiências em 60 cidades. Em 2018, o rápido crescimento continuou, e conseguimos levar a Experiences para mais de 1.000 destinos, incluindo lugares únicos como a Ilha de Páscoa, a Tasmânia e a Islândia. Terminamos o ano forte com mais de 20.000 experiências ativas.
À medida que o número de Experiências cresceu, Search & Discoverability e Personalização se tornaram fatores muito importantes para o crescimento e sucesso do mercado.
Neste post, descrevemos os estágios do nosso desenvolvimento do Ranking de Experiência usando o aprendizado de máquina em diferentes fases de crescimento do mercado, de pequeno a médio e grande porte.
As três primeiras etapas do nosso modelo de Aprendizado de Máquina de Ranking de Pesquisa
A principal vantagem é que o Search Rank baseado em aprendizado de máquina funciona em todos os estágios, já que escolhemos o modelo e a infraestrutura com o nível correto de complexidade para a quantidade de dados disponíveis e o tamanho do inventário que precisa ser classificado. Modelos muito complexos não funcionarão bem quando treinados com pequenas quantidades de dados, e linhas de base simples são abaixo do ideal quando grandes quantidades de dados de treinamento estão disponíveis.
Estágio 1: construir uma linha de base forte
Quando as Experiências do Airbnb foram lançadas, a quantidade de experiências que precisavam ser classificadas na pesquisa era pequena e começamos a coletar dados sobre as interações do usuário com experiências (impressões, cliques e reservas). Naquele momento, a melhor escolha era apenas aleatoriamente reclassificar Experiências diariamente, até que um pequeno conjunto de dados fosse coletado para o desenvolvimento do modelo de Estágio 1 ML.
Coletando dados de treinamento: para treinar nosso primeiro modelo de aprendizado de máquina para experiências de classificação, coletamos registros de pesquisa (ou seja, cliques) de usuários que acabaram fazendo reservas.
Coleta de dados de treinamento: cliques em sessões de pesquisa de usuários que acabaram fazendo reservas
Rotular dados de treinamento: ao rotular os dados de treinamento, estávamos interessados principalmente em dois rótulos: experiências que foram agendadas (que tratamos como rótulos positivos) e experiências que foram clicadas, mas não agendadas (que tratamos como rótulos negativos). Dessa maneira, coletamos um conjunto de dados de treinamento de 50.000 exemplos .
Construindo sinais com base nos quais iremos classificar : No Estágio 1 do nosso modelo de ML, decidimos classificar apenas com base nos Recursos de Experiência. No total, construímos 25 recursos, alguns dos quais foram:
Duração da experiência (por exemplo, 1h, 2h, 3h, etc.)
Preço e Preço por hora
Categoria (por exemplo, aula de culinária, música, surf, etc.)
Comentários (classificação, número de avaliações)
Número de reservas (últimos 7 dias, últimos 30 dias)
Ocupação de instâncias passadas e futuras (por exemplo, 60%)
Número máximo de lugares (por exemplo, no máximo 5 pessoas podem participar)
Treinando o modelo de classificação: dados de treinamento, rótulos e recursos, usamos o modelo GBDT (Gradient Boosted Decision Tree ). Neste ponto, tratamos o problema como classificação binária com a função de perda de perda de log .
Ao usar o GBDT, não é preciso se preocupar muito com o dimensionamento dos valores do recurso ou com os valores ausentes (eles podem ser deixados como estão). No entanto, um fator importante a ser levado em conta é que, ao contrário de um modelo linear, usar contagens brutas como recursos em um modelo baseado em árvore para tomar decisões transversais de árvores pode ser problemático quando essas contagens tendem a mudar rapidamente em um mercado em rápido crescimento. . Nesse caso, é melhor usar taxas de frações. Por exemplo, em vez de usar as contagens de reservas nos últimos 7 dias (por exemplo, 10 reservas), é melhor usar frações de reservas, por exemplo, em relação ao número de visitantes (por exemplo, 12 reservas por mil espectadores).
Testando o modelo de classificação: Para realizar o ajuste de hiper-parâmetro off-line e comparação com a classificação aleatória na produção, usamos dados de hold-out que não foram usados no treinamento. Nossa escolha de métricas foi AUC e NDCG , que são métricas padrão de classificação. Especificamente, reclassificamos as Experiências com base nas pontuações do modelo (probabilidades de reserva) e testamos onde a Experiência reservada seria classificada entre todas as Experiências em que o usuário clicou (quanto maior, melhor).
Além disso, para ter uma ideia do que um modelo treinado aprendeu, plotamos gráficos de dependência parcial para vários recursos de Experiência mais importantes. Esses gráficos mostraram o que aconteceria com as pontuações específicas da Experiência se consertarmos valores de todos, exceto um único recurso (aquele que estamos examinando). Como pode ser observado nos gráficos abaixo, o modelo aprendeu a utilizar os recursos da seguinte maneira:
Experiências com mais reservas por 1k de espectadores terão classificação mais alta
Experiências com classificação de avaliação média mais alta terão classificação mais alta
Experiências com preços mais baixos terão classificação mais alta
Como os testes off-line costumam ter muitas suposições, por exemplo, em nosso caso, limitamos-nos a reclassificar o que os usuários clicaram e não o inventário inteiro. Realizamos um experimento on-line, ou seja, teste A / B como nossa próxima etapa. Comparamos o modelo de Fase 1 ML com a classificação aleatória baseada em regras em termos de número de reservas. Os resultados foram muito encorajadores, já que conseguimos melhorar as reservas em + 13% com o modelo de classificação ML do Estágio 1.
Detalhes da implementação: Nesta fase, o nosso modelo ML limitou-se a usar apenas o Experience Features e , como resultado, o ranking de Experiências foi o mesmo para todos os usuários. Além disso, todos os parâmetros de consulta (número de convidados, datas, local, etc.) serviram apenas como filtros para recuperação (por exemplo, buscar Paris Experiences disponível na próxima semana para 2 convidados) e a classificação de Experiências não foi alterada com base nessas entradas.
Dada essa configuração simples, todo o pipeline de classificação, incluindo treinamento e pontuação, foi implementado offline e executado diariamente no Airflow . A saída foi apenas uma ordenação completa de todas as Experiências, ou seja, uma lista ordenada, que foi carregada em máquinas de produção e usada toda vez que uma pesquisa foi conduzida para classificar um subconjunto de Experiências que satisfizessem os critérios de pesquisa.
Etapa 2: personalize
O próximo passo no desenvolvimento do Ranking de Pesquisa foi adicionar o recurso Personalização ao nosso modelo de classificação ML.
Desde o início, sabíamos que o Personalização iria desempenhar um grande papel no ranking de Experiências, devido à diversidade do inventário e do interesse do hóspede.
Ao contrário do nosso negócio de Casa, onde duas Salas Privadas na mesma cidade a um preço semelhante são muito semelhantes, duas Experiências escolhidas aleatoriamente são muito diferentes, por exemplo, uma aula de culinária versus uma aula de surf . Ao mesmo tempo, os convidados podem ter diferentes interesses e ideias sobre o que desejam fazer em sua viagem, e nosso objetivo é capturar esse interesse rapidamente e fornecer o conteúdo certo nos resultados de pesquisa.
Introduzimos dois tipos diferentes de personalização, principalmente por meio de engenharia de recursos, dados coletados sobre os usuários.
1. Personalizar com base nas Casas Airbnb reservadas
Uma grande parte das reservas de Experiência vem de hóspedes que já reservaram uma Página Inicial do Airbnb. Portanto, temos um pouco de informação que podemos usar para construir recursos para personalização:
Localização da casa reservada
Preço da viagem (abaixo / acima do mercado)
Tipo de viagem: Família, Negócios
Primeira viagem ou retorno ao local
Viagem doméstica / internacional
Para dar exemplos de recursos que podem ser construídos para orientar a classificação, demonstramos dois importantes:
Distância entre a casa reservada e a experiência. Conhecendo a localização da Home Reservada (latitude e longitude), bem como a localização da reunião Experience, podemos calcular a sua distância em milhas. Os dados mostram que os usuários gostam de conveniência, ou seja, uma grande fração das Experiências do Airbnb reservadas está perto da Página inicial do Airbnb.
Experiência disponível durante a reserva de viagens. Com as datas de check-in e check-out da Casa, temos uma ideia de quais datas o hóspede deseja reservar Experiências e pode marcar Experiências como disponíveis ou não durante essas datas.
Esses dois recursos (além de outros) foram usados no treinamento do novo modelo de classificação ML. Abaixo mostramos seus gráficos de dependência parcial.
As parcelas confirmaram que o comportamento das características corresponde ao que esperávamos intuitivamente que o modelo aprendesse, ou seja, as Experiências que estão mais próximas da Home Reservada terão classificação mais alta (terão pontuações mais altas) e as Experiências disponíveis para as datas Reservadas serão mais altas (o que é muito conveniente) porque mesmo em buscas sem datas podemos alavancar datas de viagem).
2. Personalizar com base nos cliques do usuário
Dado o histórico de pesquisa de curto prazo do usuário, podemos inferir informações úteis que podem nos ajudar a personalizar futuras pesquisas:
Inferir o interesse do usuário em determinadas categorias: por exemplo, se o usuário estiver clicando principalmente em Experiências de música , podemos inferir que o interesse do usuário está na Música.
Inferir a disponibilidade da hora do dia do usuário : por exemplo, se o usuário estiver clicando principalmente em Experiências noturnas , podemos inferir que o usuário está disponível a essa hora do dia
No momento em que são publicados na plataforma, cada Experiência é manualmente marcada com uma categoria (por exemplo, caminhadas, esqui, cavalgadas, etc.). Esses dados estruturados nos permitem diferenciar os tipos de experiências. Isso também nos dá a capacidade de criar perfis de interesse do usuário em cada categoria, agregando seus cliques em diferentes categorias.
Para isso, calculamos dois recursos derivados de cliques de usuários e categorias de experiências clicadas:
Intensidade da categoria: soma ponderada de cliques do usuário em experiências que têm essa categoria específica.
onde a soma é nos últimos 15 dias (d_0 até d_now) e A é o número de ações (nesse caso, cliques) em determinada categoria no dia d.
Recência da categoria: número de dias que passaram desde que o usuário clicou pela última vez em uma experiência nessa categoria.
Observe que o usuário pode ter clicado em muitas categorias diferentes com diferentes intensidades e recências, mas quando o recurso é calculado para uma Experiência específica que precisa ser classificada, usamos a intensidade e a atualidade dessa categoria de Experiência.
Para ilustrar o que nosso modelo aprendeu para esses dois recursos, mostramos os gráficos de dependência parcial abaixo. Como pode ser observado no lado esquerdo, as Experiências em categorias para as quais o usuário teve alta intensidade terão classificação mais alta. Ao mesmo tempo, ter o recurso de recência (à direita) permite que o modelo esqueça a história à medida que o tempo passa e as Experiências nas categorias em que o usuário clicou por último há muito tempo serão classificadas como inferiores.
Construímos os mesmos tipos de recursos (intensidade e recência) para várias ações diferentes do usuário, incluindo a lista de desejos e a reserva de uma determinada categoria.
Personalização da Hora do Dia: Diferentes Experiências são realizadas em diferentes momentos do dia (por exemplo, de manhã cedo, à noite, etc.). Assim como rastreamos cliques em diferentes categorias, também podemos acompanhar os cliques em diferentes horários do dia e calcular a hora do dia entre as porcentagens de hora do dia do usuário e a hora do dia da experiência, conforme descrito abaixo.
Como pode ser observado, o modelo aprendeu a usar esse recurso de uma maneira que classifica Experiências realizadas na hora do dia que o usuário prefere mais.
Treinamento do modelo de classificação: para treinar o modelo com recursos do Personalização , primeiro geramos dados de treinamento que contêm esses recursos, reconstruindo o passado com base nos registros de pesquisa. Naquela época, já tínhamos um inventário maior (4000 experiências) e conseguíamos coletar mais dados de treinamento (exemplos com 250 KB) com quase 50 recursos de classificação.
Ao criar recursos de personalização, é muito importante não " vazar o rótulo", ou seja, expor algumas informações que aconteceram após o evento usado para criar o rótulo. Por isso, usamos apenas os cliques de usuários que ocorreram antes das reservas. Além disso, para reduzir ainda mais o vazamento, ao criar dados de treinamento calculamos a personalização apresenta apenas se o usuário interagiu com mais do que uma experiência e categoria (para evitar casos em que o usuário clicou apenas uma Experiência / categoria, por exemplo, Surf, e acabou de reserva essa categoria).
Outro aspecto importante a pensar era que o nosso tráfego de pesquisa contém pesquisas por tanto sessão e usuários registrados-out. Considerando isso, achamos mais apropriado treinar dois modelos , um com recursos de personalização para usuários logados e um sem recursos de personalização que servirão para o tráfego de logout . A principal razão foi que o modelo conectado treinado com recursos de personalização depende demais da presença desses recursos e, como tal, não é apropriado para uso em tráfego desconectado .
Teste do modelo de classificação: realizamos um teste A / B para comparar a nova configuração com 2 modelos com recursos do Personalização ao modelo da Etapa 1. Os resultados mostraram que a Personalização é importante, pois conseguimos melhorar as reservas em + 7,9% em comparação com o modelo. Modelo de estágio 1
Detalhes da implementação: Para implementar a veiculação do modelo da Fase 2 na produção, escolhemos uma solução simples que requeria menos tempo para ser implementada. Criamos uma tabela de consulta com chave do ID do usuário que continha uma classificação personalizada de todas as experiências para esse usuário e usamos a chave 0 para classificar os usuários desconectados.
Isso exigia a computação off-line diária de todos esses rankings no Airflow , computando os recursos mais recentes e marcando os dois modelos para produzir rankings. Devido ao alto custo envolvido com classificações personalizadas pré-computação para todos os usuários ( O ( NM ), onde N é o número de usuários e M é o número de Experiências), limitamos N a apenas 1 milhão de usuários mais ativos.
Os recursos de personalização neste momento foram computados apenas diariamente, o que significa que temos latência de até um dia (também um fator que pode ser muito melhorado com mais investimento em infraestrutura).
A implementação do estágio 2 foi uma solução temporária usada para validar os ganhos de personalização antes de investirmos mais recursos na criação de uma infraestrutura de pontuação on – line no estágio 3, que era necessária, já que N e M devem crescer muito mais.
Etapa 3: Mude para a pontuação online
Depois de demonstrar ganhos significativos em reservas ao repetir o modelo de classificação ML e depois que os dados de inventário e treinamento aumentaram até onde é possível treinar um modelo mais complexo, estávamos prontos para investir mais recursos de engenharia na construção de uma infraestrutura de pontuação on – line ganhos.
A mudança para o Online Scoring também desbloqueia todo um novo conjunto de recursos que podem ser usados: Recursos de consulta (destacados na imagem abaixo).
Isso significa que poderíamos usar o local inserido, o número de convidados e as datas para projetar mais recursos.
Por exemplo, podemos usar o local inserido, como cidade, bairro ou local de interesse, para calcular a Distância entre Experiência e Local Entrado . Esse recurso nos ajuda a classificar essas Experiências mais perto do local inserido mais alto.
Além disso, podemos usar o número de convidados inserido (individuais, casal, grupo grande) para calcular como se relaciona com o número de convidados em uma reserva média de Experiência que precisa ser classificada. Esse recurso nos ajuda a classificar melhor as Experiências de ajuste.
Na configuração on-line, também podemos aproveitar a configuração de idioma do navegador do usuário para personalizar a linguagem rapidamente. Algumas Experiências são oferecidas e traduzidas em vários idiomas. Se a tradução do idioma de configuração do navegador estiver disponível, essa será exibida. Com a classificação no mundo on-line, podemos dar um passo além e classificar as Experiências de correspondência de idiomas mais alto, criando um recurso que determina se a experiência é oferecida no idioma do navegador . Na imagem abaixo, mostramos um exemplo de ranqueamento do modelo Stage 3 ML Experiências oferecidas em russo mais alto quando o idioma do navegador é russo.
Finalmente, na configuração on-line, também conhecemos o país do qual o usuário está pesquisando. Podemos usar as informações do país para personalizar o ranking "Experiência" com base nas categorias preferidas pelos usuários desses países. Por exemplo, dados históricos nos dizem que, quando visitam Paris, os viajantes japoneses preferem aulas e workshops (por exemplo, perfumaria) , viajantes dos EUA preferem experiências de comida e bebida , enquanto viajantes franceses preferem História e Voluntariado . Usamos essas informações para projetar vários recursos de personalização no nível Origem – Destino.
Treinando o modelo de classificação: para treinar o modelo com os recursos de consulta , primeiro os adicionamos aos dados históricos de treinamento. O inventário naquele momento era de 16.000 Experiências e nós tínhamos mais de 2 milhões de exemplos rotulados para serem usados em treinamento com um total de 90 recursos de classificação. Como mencionado anteriormente, nós treinamos dois modelos GBDT:
Modelo para usuários logados , que Usa Recursos de Experiência , Recursos de Consulta e Recursos do Usuário (Personalização)
Modelo para tráfego desconectado , que usa os recursos de experiência e consulta, treinados com dados (cliques e reservas) de usuários conectados, mas sem considerar os recursos de personalização
A vantagem de ter uma infraestrutura de pontuação online é que podemos usar o modelo logado para muito mais usos do que antes, porque não há necessidade de pré-computar classificações personalizadas como fizemos no Estágio 2. Usamos o modelo logado sempre que sinais de personalização estavam disponíveis para um ID de usuário específico, senão voltamos a usar o modelo desconectado .
Teste do modelo de classificação: realizamos um teste A / B para comparar os modelos de estágio 3 aos modelos de estágio 2. Mais uma vez, conseguimos aumentar as reservas, desta vez em + 5,1% .
Detalhes da implementação: Para implementar a pontuação on-line de milhares de listagens em tempo real, criamos nossa própria ML infra no contexto de nosso serviço de pesquisa. Existem basicamente três partes da infraestrutura, 1) obtendo entrada de modelo de vários locais em tempo real, 2) implantação de modelo para produção e 3) modelo de pontuação.
O modelo requer três tipos de sinais para realizar a pontuação: Recursos de experiência , Recursos de consulta e Recursos do usuário . Diferentes sinais foram armazenados de maneira diferente, dependendo de seu tamanho, frequência de atualização, etc. Especificamente, devido ao seu grande tamanho (centenas de milhões de chaves de usuário), os Recursos do Usuário foram armazenados em um armazenamento de valor-chave on-line e caixas de servidores de pesquisa podem procurá-las quando um usuário faz a pesquisa. Os Recursos de Experiência, por outro lado, não são tão grandes (dezenas de milhares de Experiências) e, como tal, podem ser armazenados na memória das caixas do servidor de pesquisa e lidos diretamente a partir daí. Finalmente, os recursos de consulta não são armazenados e são lidos à medida que chegam do front end.
A experiência e os recursos do usuário são atualizados diariamente conforme o término do trabalho de geração do recurso de fluxo de ar. Estamos trabalhando na transição de alguns dos recursos para o mundo on-line, usando um armazenamento de valor-chave com recursos de leitura e gravação que nos permitiria atualizar os recursos instantaneamente à medida que mais dados chegam (por exemplo, novas revisões de experiência, novo usuário cliques, etc.).
No processo de implementação do modelo, transformamos o arquivo de modelo GBDT, que originalmente veio de nosso pipeline de treinamento no formato JSON, para uma estrutura Java GBDT interna e o carregamos no aplicativo de serviço de pesquisa quando ele é iniciado.
Durante o estágio de pontuação, primeiro obtemos todos os recursos ( User, Experience e Query Features ) de suas respectivas localizações e os concatenamos em um vetor usado como entrada para o modelo. Em seguida, dependendo se os recursos do usuário estão vazios ou não, decidimos qual modelo usar, ou seja, modelo desconectado ou conectado , respectivamente. Por fim, retornamos as pontuações do modelo para todas as Experiências e as classificamos na página em ordem decrescente das pontuações.
Estágio 4: lidar com regras de negócios
Até este ponto, o objetivo do nosso modelo de ranking era aumentar as reservas. No entanto, um mercado como o Airbnb Experiences pode ter vários outros objetivos secundários, como os chamamos de Business Rules, que podemos ajudar a alcançar através do aprendizado de máquina .
Uma regra de negócio tão importante é promover Qualidade . Desde o início, acreditamos que, se os hóspedes tiverem uma experiência realmente boa, eles voltarão e reservarão Experiências novamente em um futuro próximo. Por esse motivo, começamos a coletar feedback dos usuários em termos de 1) avaliações por estrelas, variando de 1 a 5, e 2) feedback adicional de respostas múltiplas estruturadas para saber se a Experiência era única, melhor que o esperado, envolvente etc.
À medida que mais e mais dados se tornaram disponíveis para suportar nossa hipótese de remarcação, a tendência ficou mais clara. Como pode ser observado à esquerda na figura abaixo, os hóspedes que tiveram uma ótima experiência (uma classificação de 5 estrelas) têm 1.5x mais probabilidade de remarcar outra Experiência nos próximos 90 dias em comparação com os hóspedes que tiveram menos bom tempo (deixe 4 estrelas ou inferior).
Isso nos motivou a experimentar nossa função objetivo, onde mudamos nossa classificação binária (+1 = reservado, -1 = clique e não reservado) para introduzir pesos nos dados de treinamento para diferentes níveis de qualidade (por exemplo, maior para reservas de alta qualidade, menor para reservas de muito baixa qualidade). Os níveis de qualidade foram definidos pela nossa equipe de qualidade por meio da análise de dados. Por exemplo:
qualidade muito alta A experiência é uma com> 50 avaliações,> 4.95 avaliações e> 55% dos hóspedes dizendo que a Experiência foi única e melhor que o esperado.
Experiência de muito baixa qualidade é um com > 10 avaliações, <4.7 avaliação da avaliação.
Ao testar o modelo treinado de tal forma, os resultados dos testes A / B (à direita na figura acima) mostraram que podemos alavancar o ranking de aprendizado de máquina para conseguir mais de reservas de alta qualidade e menos de reservas de baixa qualidade , mantendo as reservas globais neutras.
De maneira semelhante, enfrentamos com sucesso vários outros objetivos secundários:
Descobrir e promover potenciais novos hits antecipadamente usando sinais de início a frio e promovê-los no ranking (isso levou a um ganho de reserva de + 14% para novos hits e reservas globais neutras)
Reforçar a diversidade nos 8 melhores resultados, de tal forma que podemos mostrar o conjunto diversificado de categorias, o que é especialmente importante para o tráfego de baixa intenção (isto levou a + 2,3% do ganho total de reserva ).
Otimize a pesquisa sem localização para cliques Para usuários com baixa intenção que acessam nosso site, mas não pesquisam com um local especificado, acreditamos que um objetivo diferente deve ser usado. Nossa primeira tentativa foi escolher o Top 18 de todas as localidades com base em nossas pontuações de modelo de classificação e, em seguida, reposicionar com base na taxa de cliques (isso gerou + 2,2% de ganho total de reserva em comparação ao cenário em que não reclassificamos baseado no CTR).
Monitorando e explicando classificações
Para qualquer mercado de dois lados, é muito importante ser capaz de explicar por que certos itens se classificam da maneira que fazem.
No nosso caso, é valioso porque podemos:
Dê aos anfitriões um feedback concreto sobre os fatores que levam à melhoria do ranking e quais fatores levam ao declínio.
Acompanhe as tendências gerais que o algoritmo de classificação está aplicando para ter certeza de que é o comportamento que queremos ter em nosso mercado.
Para desenvolver esse recurso, usamos o Apache Superset e o Airflow para criar dois painéis:
Painel que rastreia rankings de Experiências específicas em seu mercado ao longo do tempo, bem como valores de recurso utilizados pelo modelo ML.
Painel que mostra as tendências gerais de classificação para diferentes grupos de experiências (por exemplo, como as Experiências de 5 estrelas se classificam no mercado).
Para dar uma ideia do motivo pelo qual esses tipos de painéis podem ser úteis, damos vários exemplos nas figuras a seguir.
Na figura abaixo, mostramos um exemplo de uma Experiência cuja classificação (painel esquerdo) melhorou da posição 30 para a posição 1 (topo do ranking). Para explicar por que, podemos examinar as plotagens que rastreiam várias estatísticas dessa Experiência (painel da direita), que são usadas diretamente como recursos no modelo ML ou usadas para derivar recursos.
Exemplo explicando porque o ranking de uma experiência particular melhorou ao longo do tempo
Pode-se observar claramente que a classificação melhorou porque o número de avaliações aumentou de 0 para 60, mantendo-se uma classificação de revisão de 5.0 e> 60% dos usuários disseram que a Experiência foi melhor do que o esperado. Além disso, o anfitrião baixou o preço, o que também pode ter levado à melhoria do ranking.
Na figura seguinte, mostramos um exemplo de uma Experiência cuja classificação se degradou da posição 4 para a posição 94. Mais uma vez, os sinais que o modelo de classificação usa como entrada podem contar a história.
Exemplo explicando porque o ranqueamento de uma experiência particular se degradou ao longo do tempo
A experiência começou a receber críticas negativas (classificação média reduzida de 4,87 para 4,82), o anfitrião aumentou o preço em US $ 20 e os números gerais de reserva diminuíram. Além disso, nesse mercado, a hora do dia em que a Experiência é realizada (de manhã cedo) tornou-se cada vez menos popular (efeito de sazonalidade ligeiro). Todos esses fatores combinados levam ao declínio do ranking.
O painel foi particularmente útil para nossos gerentes de mercado que estão em contato frequente com os anfitriões.
Além disso, para poder acompanhar o tipo de comportamento de classificação que estamos aplicando, foi útil analisarmos a classificação de determinados grupos de experiências em seus mercados. Na figura abaixo, mostramos um instantâneo do nosso painel, onde podemos acompanhar a classificação média (menor é melhor) de diferentes dimensões.
Por exemplo, o gráfico à esquerda mostra que Experiências com> 50 avaliações são muito melhores do que experiências com 10–30 revisões. Olhando para as outras duas parcelas, podemos ver que, em média, Experiências com classificação de avaliação de> 4,9 são as melhores (muito melhores do que aquelas com classificação média mais baixa) e Experiências para as quais> 55% dizem que sua experiência foi muito melhor do que Experiências não exclusivas.
Esse tipo de painel é útil para tomar decisões de negócios e modificações no algoritmo de classificação para impor comportamentos melhores. Por exemplo, com base na figura que mostra as tendências de classificação dos diferentes grupos de faixa de preço (mostrados abaixo), percebemos que o preço muito baixo Experiências têm uma vantagem muito grande no ranking. Decidimos tentar reduzir essa vantagem removendo o preço como um dos sinais usados pelo modelo de classificação.
O resultado da remoção do preço e reciclagem do modelo foi que a diferença no ranking diminuiu (após 01 de julho), sem prejudicar as reservas globais. Isso demonstra a utilidade do relatório e como a classificação pode ser manipulada usando o aprendizado de máquina para obter o comportamento de classificação desejado.
Trabalho contínuo e futuro
Em nosso trabalho contínuo e futuro, estamos interagindo
Construção de dados de treinamento (registrando os valores do recurso no momento da pontuação, em vez de reconstruí-los com base no melhor palpite para esse dia)
Função de perda (por exemplo, usando a perda pareada, em que comparamos a Experiência com Experiência com a classificação que foi classificada como superior, mas não reservada, uma configuração que é muito mais apropriada para classificação)
Rótulos de treinamento (por exemplo, usando utilitários em vez de rótulos binários, ou seja, atribuindo valores diferentes a diferentes ações do usuário, como: 0 para impressão, 0,1 para clique, 0,2 para clique com data e hora selecionadas, 1,0 para reserva, 1,2 para reserva de alta qualidade )
Adicionar mais sinais em tempo real (por exemplo, ser capaz de personalizar com base nas atividades imediatas do usuário, ou seja, cliques ocorridos há 10 minutos em vez de 1 dia atrás)
Explicitamente perguntando aos usuários sobre os tipos de atividades que desejam fazer em sua viagem (para que possamos personalizar com base no interesse declarado, além dos inferidos)
Enfrentando o viés de posição que está presente nos dados que usamos no treinamento
Otimização para objetivos secundários adicionais , como ajudar hosts que hospedam com menos frequência que outros (por exemplo, 1 a 2 por mês) e anfitriões que saem de férias e voltam
Testando diferentes modelos além do GBDT
Encontrar mais tipos de oferta que funcionam bem em determinados mercados , aproveitando as previsões do modelo de classificação.
Estrutura de exploração / exploração
Teste a abordagem humana no ciclo (por exemplo, escolhas da equipe)
Vamos atualizar os leitores sobre o que funcionou e o que não funcionou à medida que continuamos a empurrar os limites do Ranking de Experiência para o crescimento de nosso mercado.
Resumo do Impacto nos Negócios até agora
Deixamos você com o resumo do impacto da reserva que nossa equipe fez até agora com os experimentos que foram discutidos na postagem do blog.
A ideia principal é: " Não espere até ter big data, você pode fazer um pouco com pequenos dados para ajudar a crescer e melhorar seus negócios. "