Olá a todos! Meu nome é Sasha, sou CTO e cofundador do LoyaltyLab. Há dois anos, meus amigos e eu, como todos os estudantes pobres, fomos à noite comprar cerveja na loja mais próxima de nossa casa. Ficamos muito chateados porque o varejista, sabendo que viríamos buscar cerveja, não ofereceu desconto em salgadinhos ou biscoitos, embora isso fosse tão lógico! Não entendíamos por que essa situação estava acontecendo e decidimos abrir nossa própria empresa. Bem, como bônus, ganhe descontos todas as sextas-feiras nas mesmas fichas.

E tudo chegou ao ponto em que estou apresentando material sobre a parte técnica do produto em NVIDIA GTC. Estamos felizes em compartilhar nosso trabalho com a comunidade, por isso estou publicando meu relatório na forma de um artigo.

Introdução

Como todo mundo no início da jornada, começamos com uma visão geral de como os sistemas de recomendação são feitos. E a arquitetura mais popular acabou sendo do seguinte tipo:

Consiste em duas partes:

Amostragem de candidatos para recomendações usando um modelo simples e rápido, geralmente colaborativo.
Ranking de candidatos com modelo de conteúdo mais complexo e lento, levando em consideração todas as características possíveis nos dados.

Doravante usarei os seguintes termos:

candidato/candidato a recomendações — um par usuário-produto que poderia ser potencialmente incluído nas recomendações em produção.
extração de candidatos/extrator/método de extração de candidatos — um processo ou método para extrair “candidatos a recomendações” dos dados disponíveis.

A primeira etapa geralmente envolve o uso de diferentes variações de filtragem colaborativa. O mais popular - ALS. É surpreendente que a maioria dos artigos sobre sistemas de recomendação apenas revele várias melhorias nos modelos colaborativos na primeira fase, mas ninguém fala muito sobre outros métodos de amostragem. Para nós, a abordagem de usar apenas modelos colaborativos e diversas otimizações com eles não funcionou com a qualidade que esperávamos, por isso nos aprofundamos em pesquisas especificamente nesta parte. E no final do artigo vou mostrar o quanto conseguimos melhorar a ELA, que era a nossa linha de base.

Antes de prosseguir com a descrição da nossa abordagem, é importante observar que nas recomendações em tempo real, quando é importante levarmos em conta os dados que ocorreram há 30 minutos, não há realmente muitas abordagens que possam funcionar no tempo necessário. Mas, no nosso caso, temos que coletar recomendações não mais do que uma vez por dia e, na maioria dos casos, uma vez por semana, o que nos dá a oportunidade de usar modelos complexos e melhorar várias vezes a qualidade.

Vamos tomar como base quais métricas apenas o ALS mostra na tarefa de extrair candidatos. As principais métricas que monitoramos são:

Precisão - a proporção de candidatos corretamente selecionados entre os amostrados.
Recall é a proporção de candidatos que aconteceram entre aqueles que realmente estavam no intervalo alvo.
Pontuação F1 - Medida F calculada nos dois pontos anteriores.

Também veremos as métricas do modelo final após o treinamento do aumento de gradiente com recursos de conteúdo adicionais. Existem também três métricas principais aqui:

Precision@5 - a porcentagem média de produtos entre os 5 primeiros em termos de probabilidade para cada comprador.
taxa de resposta@5 - conversão de clientes de uma visita à loja na compra de pelo menos uma oferta pessoal (5 produtos em uma oferta).
média de roc-auc por usuário - média roc-auc para cada comprador.

É importante notar que todas essas métricas são medidas em validação cruzada de série temporal, ou seja, o treinamento ocorre nas primeiras k semanas e k+1 semanas são consideradas dados de teste. Assim, os altos e baixos sazonais tiveram um impacto mínimo na interpretação da qualidade dos modelos. Mais adiante em todos os gráficos, o eixo das abscissas indicará o número da semana na validação cruzada e o eixo das ordenadas indicará o valor da métrica especificada. Todos os gráficos são baseados em dados de transações de um cliente para que as comparações entre si sejam corretas.

Antes de começarmos a descrever nossa abordagem, primeiro olhamos para a linha de base, que é um modelo treinado em ALS.
Métricas de recuperação de candidatos:

Métricas finais:

Trato todas as implementações de algoritmos como algum tipo de hipótese de negócios. Assim, de forma muito aproximada, qualquer modelo colaborativo pode ser considerado como uma hipótese de que “as pessoas tendem a comprar o que pessoas semelhantes a elas compram”. Como já disse, não nos limitamos a tal semântica, e aqui estão algumas hipóteses que funcionam bem em dados no varejo offline:

Que eu já comprei antes.
Semelhante ao que comprei antes.
Período de uma compra passada há muito tempo.
Popular por categoria/marca.
Compras alternativas de produtos diferentes semana após semana (cadeias de Markov).
Produtos semelhantes aos compradores, de acordo com características construídas por diferentes modelos (Word2Vec, DSSM, etc.).

O que você comprou antes?

A heurística mais óbvia que funciona muito bem no varejo de alimentos. Aqui pegamos todos os produtos que o titular do cartão de fidelidade comprou nos últimos K dias (geralmente de 1 a 3 semanas) ou K dias há um ano. Aplicando apenas este método, obtemos as seguintes métricas:

Aqui é bastante óbvio que quanto mais demoramos o período, mais recordação temos e menos precisão temos e vice-versa. Em média, as “últimas 2 semanas” proporcionam melhores resultados para os clientes.

Semelhante ao que comprei antes

Não é surpresa que para o varejo alimentar “o que comprei antes” funcione bem, mas extrair candidatos apenas do que o usuário já comprou não é muito legal, pois dificilmente surpreenderá o comprador com algum produto novo. Portanto, propomos melhorar ligeiramente esta heurística usando os mesmos modelos colaborativos. A partir dos vetores que recebemos durante o treinamento em ALS, podemos obter produtos semelhantes aos que o usuário já adquiriu. Esta ideia é muito semelhante aos “vídeos semelhantes” nos serviços de visualização de conteúdos de vídeo, mas como não sabemos o que o utilizador está a comer/comprar num determinado momento, só podemos procurar vídeos semelhantes ao que ele já comprou, especialmente já que já sabemos como funciona bem. Aplicando este método nas transações do usuário nas últimas 2 semanas, obtemos as seguintes métricas:

é k — o número de produtos similares recuperados para cada produto adquirido pelo comprador nos últimos 14 dias.
Essa abordagem funcionou especialmente bem para nosso cliente, para quem era fundamental não recomendar nada que já estivesse no histórico de compras do usuário.

Período de compra atrasada

Como já descobrimos, devido à elevada frequência de compra de bens, a primeira abordagem funciona bem para as nossas necessidades específicas. Mas e quanto a produtos como sabão em pó/xampu/etc. Ou seja, com produtos que dificilmente serão necessários a cada uma ou duas semanas e que os métodos anteriores não conseguem extrair. Isso leva à seguinte ideia - propõe-se calcular o período de compra de cada produto em média para clientes que compraram mais o produto k uma vez. E então extraia o que o comprador provavelmente já esgotou. Os prazos calculados para mercadorias podem ser verificados visualmente quanto à adequação:

E então veremos se o final do período do produto está dentro do intervalo de tempo em que as recomendações estarão em produção e veremos o que acontece. A abordagem pode ser ilustrada assim:

Aqui temos 2 casos principais que podem ser considerados:

É necessário provar produtos de clientes que compraram o produto menos de K vezes?
É necessário amostrar um produto se o final do seu período for anterior ao início do intervalo alvo.

O gráfico a seguir mostra quais resultados esse método alcança com diferentes hiperparâmetros:

ft — Leve apenas clientes que compraram o produto pelo menos K (aqui K = 5) vezes
tm — Aceite apenas candidatos que se enquadrem no intervalo alvo

Não é de surpreender que ele seja capaz (0, 0) o maior recordar e o menor precisão, já que nesta condição é recuperado o maior número de candidatos. No entanto, os melhores resultados são alcançados quando não amostramos produtos para clientes que compraram um determinado produto menos de k tempos e extrato, inclusive mercadorias, cujo final do período cai antes do intervalo de meta.

Popular por categoria

Outra ideia bastante óbvia é experimentar produtos populares de diferentes categorias ou marcas. Aqui calculamos para cada comprador top-k categorias/marcas “favoritas” e extraia “popular” desta categoria/marca. No nosso caso, determinaremos “favorito” e “popular” pelo número de compras do produto. Uma vantagem adicional desta abordagem é a sua aplicabilidade no caso de partida a frio. Ou seja, para clientes que realizaram poucas compras, ou que não vão à loja há muito tempo, ou que acabaram de emitir um cartão fidelidade. Para eles, é mais fácil e melhor estocar itens que são populares entre os clientes e têm um histórico. As métricas resultantes são:

Aqui, o número após a palavra “categoria” significa o nível de aninhamento da categoria.

No geral, também não é surpreendente que categorias mais restritas obtenham melhores resultados, pois extraem produtos “favoritos” mais precisos dos compradores.

Compras alternativas de produtos diferentes de semana para semana

Uma abordagem interessante que não vi em artigos sobre sistemas de recomendação é um método estatístico de cadeias de Markov bastante simples e ao mesmo tempo funcional. Aqui levamos 2 semanas diferentes, depois para cada cliente construímos pares de produtos [comprado na semana i]-[comprado na semana j], onde j > i, e a partir daqui calculamos para cada produto a probabilidade de mudar para outro produto na próxima semana. Ou seja, para cada par de bens produção-produtoj Contamos o número deles nos pares encontrados e dividimos pelo número de pares, onde produção foi na primeira semana. Para extrair candidatos, pegamos o último recibo do comprador e extraímos top-k os próximos produtos mais prováveis da matriz de transição que recebemos. O processo de construção de uma matriz de transição é assim:

A partir de exemplos reais na matriz de probabilidade de transição, vemos os seguintes fenômenos interessantes:

Aqui você pode notar dependências interessantes que se revelam no comportamento do consumidor: por exemplo, amantes de frutas cítricas ou de uma marca de leite da qual provavelmente mudarão para outra. Também não é surpreendente que produtos com alta frequência de compras repetidas, como a manteiga, também acabem aqui.

As métricas no método com cadeias de Markov são as seguintes:

k — o número de produtos recuperados para cada produto adquirido na última transação do comprador.
Como podemos ver, o melhor resultado é mostrado pela configuração com k=4. O aumento na semana 4 pode ser explicado pelo comportamento sazonal próximo aos feriados.

Produtos semelhantes aos compradores, de acordo com características construídas por diferentes modelos

Agora chegamos à parte mais difícil e interessante - a busca pelos vizinhos mais próximos com base em vetores de clientes e produtos construídos de acordo com diversos modelos. Em nosso trabalho usamos 3 desses modelos:

ALS
Word2Vec (Item2Vec para tais tarefas)
DSSM

Já tratamos da ELA, você pode ler sobre como ela aprende aqui. No caso do Word2Vec, utilizamos a conhecida implementação do modelo de gensim. Por analogia com os textos, definimos a oferta como um recibo de compra. Assim, ao construir um vetor de produto, o modelo aprende a prever para o produto no recebimento o seu “contexto” (os demais produtos no recibo). Nos dados de comércio eletrônico, é melhor usar a sessão do comprador em vez de um recibo; os caras da Ozônio. E o DSSM é mais interessante de analisar. Inicialmente foi escrito pelo pessoal da Microsoft como modelo de busca Você pode ler o artigo de pesquisa original aqui. A arquitetura do modelo é assim:

é Q — consulta, consulta de pesquisa do usuário, D[eu] — documento, página da internet. A entrada para o modelo são os atributos da solicitação e das páginas, respectivamente. Após cada camada de entrada há uma série de camadas totalmente conectadas (perceptron multicamadas). A seguir, o modelo aprende a minimizar o cosseno entre os vetores obtidos nas últimas camadas do modelo.
As tarefas de recomendação usam exatamente a mesma arquitetura, só que em vez de uma solicitação existe um usuário e em vez de páginas existem produtos. E no nosso caso, essa arquitetura se transforma no seguinte:

Agora, para verificar os resultados, resta abordar o último ponto - se no caso de ALS e DSSM definimos explicitamente vetores de usuário, então no caso de Word2Vec temos apenas vetores de produto. Aqui, para construir o vetor do usuário, definimos 3 abordagens principais:

Basta adicionar os vetores e, para a distância do cosseno, verificamos que simplesmente calculamos a média dos produtos no histórico de compras.
Somatória vetorial com alguma ponderação de tempo.
Pesagem de mercadorias com coeficiente TF-IDF.

No caso da ponderação linear do vetor comprador, partimos da hipótese de que o produto que o usuário comprou ontem tem maior influência no seu comportamento do que o produto que comprou há seis meses. Portanto, consideramos a semana anterior do comprador com probabilidades de 1 e o que aconteceu a seguir com probabilidades de ½, ⅓, etc.:

Para os coeficientes TF-IDF, fazemos exatamente o mesmo que no TF-IDF para os textos, só que consideramos o comprador como um documento e o cheque como uma oferta, respectivamente, a palavra é um produto. Dessa forma, o vetor do usuário mudará mais para bens raros, enquanto bens frequentes e familiares para o comprador não mudarão muito. A abordagem pode ser ilustrada assim:

Agora vamos dar uma olhada nas métricas. Esta é a aparência dos resultados do ALS:

Métricas para Item2Vec com diferentes variações de construção do vetor comprador:

Neste caso, é usado exatamente o mesmo modelo da nossa linha de base. A única diferença é qual k usaremos. Para usar apenas modelos colaborativos, é necessário levar cerca de 50 a 70 produtos mais próximos de cada cliente.

E métricas de acordo com DSSM:

Como combinar todos os métodos?

Legal, você diz, mas o que fazer com um conjunto tão grande de ferramentas de extração de candidatos? Como escolher a configuração ideal para seus dados? Aqui temos vários problemas:

É necessário limitar de alguma forma o espaço de busca por hiperparâmetros em cada método. É claro que é discreto em todos os lugares, mas o número de pontos possíveis é muito grande.
Usando uma pequena amostra limitada de métodos específicos com hiperparâmetros específicos, como você pode selecionar a melhor configuração para sua métrica?

Ainda não encontramos uma resposta definitivamente correta para a primeira pergunta, então partimos do seguinte: para cada método, é escrito um limitador de espaço de busca de hiperparâmetros, dependendo de algumas estatísticas sobre os dados que temos. Assim, conhecendo o período médio entre as compras das pessoas, podemos adivinhar em que período utilizar o método “o que já foi comprado” e “período de compra há muito tempo”.

E depois de passarmos por um certo número adequado de variações de diferentes métodos, notamos o seguinte: cada implementação extrai um certo número de candidatos e tem um certo valor da métrica chave para nós (recall). Queremos obter um total de um certo número de candidatos, dependendo do nosso poder computacional permitido, com a métrica mais alta possível. Aqui o problema se transforma lindamente no problema da mochila.

Aqui, o número de candidatos é o peso do lingote e o método de recall é o seu valor. Porém, existem mais 2 pontos que devem ser levados em consideração na implementação do algoritmo:

Os métodos podem ter sobreposição nos candidatos que recuperam.
Em alguns casos, será correto usar um método duas vezes com parâmetros diferentes, e a saída candidata do primeiro não será um subconjunto do segundo.

Por exemplo, se tomarmos a implementação do método “o que já comprei” com diferentes intervalos de recuperação, então seus conjuntos de candidatos serão aninhados uns nos outros. Ao mesmo tempo, diferentes parâmetros em “compras periódicas” na saída não proporcionam interseção completa. Portanto, dividimos as abordagens de amostragem com diferentes parâmetros em blocos de forma que de cada bloco queiramos usar no máximo uma abordagem de extração com hiperparâmetros específicos. Para fazer isso, você precisa ser um pouco esperto na implementação do problema da mochila, mas a assintótica e o resultado não mudarão.

Esta combinação inteligente permite-nos obter as seguintes métricas em comparação com modelos simplesmente colaborativos:

Nas métricas finais vemos a seguinte imagem:

No entanto, aqui você pode notar que há um ponto descoberto para recomendações que são úteis para os negócios. Agora acabamos de aprender como fazer um ótimo trabalho ao prever o que o usuário comprará, por exemplo, na próxima semana. Mas simplesmente dar desconto em algo que ele já vai comprar não é muito legal. Mas é legal maximizar a expectativa, por exemplo, das seguintes métricas:

Margem/volume de negócios baseada em recomendações pessoais.
Verificação média do cliente.
Frequência das visitas.

Assim, multiplicamos as probabilidades obtidas por diferentes coeficientes e os reclassificamos para que os produtos que afetam as métricas acima cheguem ao topo. Não existe uma solução pronta para qual abordagem seja melhor usar. Até experimentamos esses coeficientes diretamente na produção. Mas aqui estão técnicas interessantes que geralmente nos dão os melhores resultados:

Multiplique pelo preço/margem do produto.
Multiplique pela receita média em que o produto aparece. Então surgirão mercadorias, com as quais geralmente levam outra coisa.
Multiplique pela frequência média de visitas dos compradores deste produto, partindo da hipótese de que este produto provoca as pessoas a voltarem a comprá-lo com mais frequência.

Após realizar experimentos com coeficientes, obtivemos as seguintes métricas em produção:

é conversão geral de produtos — a parcela de produtos adquiridos entre todos os produtos nas recomendações que geramos.

Um leitor atento notará uma diferença significativa entre as métricas offline e online. Esse comportamento é explicado pelo fato de que nem todos os filtros dinâmicos de produtos que podem ser recomendados podem ser levados em consideração no treinamento do modelo. Para nós, é uma história normal quando metade dos candidatos recuperados podem ser filtrados; esta especificidade é típica do nosso setor.

Em termos de receita, obtém-se a seguinte história, fica claro que após o lançamento das recomendações, a receita do grupo de teste está crescendo fortemente, agora o aumento médio da receita com nossas recomendações é de 3-4%:

Concluindo, quero dizer que, se você precisar de recomendações que não sejam em tempo real, poderá encontrar um aumento muito grande na qualidade em experimentos com extração de candidatos a recomendações. Muito tempo para sua geração permite combinar muitos bons métodos, que no total darão ótimos resultados para o negócio.

Terei prazer em conversar nos comentários com quem achar o material interessante. Você pode me fazer perguntas pessoalmente em telegrama. Também compartilho meus pensamentos sobre IA/startups em meu canal de telegrama - Bem-vindo :)

Fonte: habr.com

Como melhoramos drasticamente a qualidade das recomendações no varejo off-line