Implementando AI no varejo com Apache Cassandra e Apache Pulsar

A jornada para implementar soluções de inteligência artificial e aprendizado de máquina requer a resolução de muitos desafios comuns que surgem rotineiramente em sistemas digitais: atualização de sistemas legados, eliminação de processos em lote e uso de tecnologias inovadoras baseadas em IA/ML para melhorar a experiência do cliente em maneiras que pareciam ficção científica apenas alguns anos atrás.

Para ilustrar essa evolução, vamos acompanhar um empreiteiro hipotético que foi contratado para ajudar a implementar soluções de IA/ML em um grande varejista. Este é o primeiro de uma série de artigos que detalharão aspectos importantes da jornada para AI/ML.

O problema: um processo em lote frágil

É o primeiro dia na BigBoxCo na equipe “Infrastructure”. Depois de trabalhar nas atividades obrigatórias de recursos humanos, recebi meu crachá de contratado e fui para meu novo local de trabalho.

Depois de conhecer a equipe, fui informado de que teríamos uma reunião com a equipe de “Recomendações” esta manhã.

O acesso ao meu sistema ainda não está funcionando, então espero que a TI resolva isso enquanto estivermos na reunião.

Na sala de reunião, somos apenas alguns de nós: meu gerente e outros dois engenheiros da minha nova equipe e um engenheiro da equipe de Recomendações. Começamos com algumas apresentações e depois passamos a discutir um assunto da semana anterior.

Evidentemente, houve algum tipo de falha de lote durante a noite na semana passada, e eles ainda estão sentindo os efeitos disso.

Parece que as recomendações atuais de produtos são orientadas por dados coletados de pedidos de clientes. A cada pedido, há uma nova associação entre os produtos pedidos, que é registrada.

Quando os clientes visualizam as páginas do produto, eles podem obter recomendações com base em quantos outros clientes compraram o produto atual junto com produtos diferentes.

As recomendações de produtos são fornecidas aos usuários em bigboxco.com por meio de uma camada de microsserviço na nuvem. A camada de microsserviço usa uma implantação de centro de dados local (nuvem) do Apache Cassandra para fornecer os resultados.

Como os resultados são coletados e veiculados, no entanto, é uma história completamente diferente. Essencialmente, os resultados das associações entre produtos (comprados juntos) são compilados durante um trabalho MapReduce. Este é o processo em lote que falhou na semana passada.

Embora esse processo em lote nunca tenha sido rápido, ele se tornou mais lento e quebradiço com o tempo. Na verdade, às vezes o processo leva dois ou até três dias para ser executado.

Melhorando a experiência

Após a reunião, verifico meu computador e parece que finalmente posso fazer login. Enquanto olho em volta, nosso engenheiro principal (PE) vem e se apresenta.

Conto a ele sobre a reunião com a equipe de Recomendações e ele me conta um pouco mais da história por trás do serviço de Recomendações.

Parece que esse processo em lote está em vigor há cerca de 10 anos. O engenheiro que o projetou mudou-se, poucas pessoas na organização realmente o entendem e ninguém quer tocá-lo.

O outro problema, começo a explicar, é que o conjunto de dados que orienta cada recomendação quase sempre tem alguns dias.

Embora isso possa não ser grande coisa no grande esquema das coisas, se os dados de recomendação pudessem ser mais atualizados, isso beneficiaria as promoções de curto prazo executadas pelo marketing.

Ele concorda com a cabeça e diz que está definitivamente aberto a sugestões sobre como melhorar o sistema.

Talvez seja um problema de gráfico?

No início, isso me parece um problema gráfico. Temos clientes que acessam o site e compram produtos. Antes disso, quando olham para um produto ou adicionam ao carrinho, podemos mostrar recomendações na forma de “Clientes que compraram X também compraram Y”.

O site tem isso hoje, pois o serviço de recomendações faz exatamente isso: ele retorna os quatro principais produtos adicionais que são frequentemente comprados juntos.

Mas teríamos que ter uma maneira de “classificar” os produtos porque o mapeamento de um produto para todos os outros comprados ao mesmo tempo por qualquer um de nossos 200 milhões de clientes aumentará rapidamente.

Assim, podemos classificá-los pelo número de vezes que aparecem em um pedido. Um gráfico desse sistema pode se parecer com o mostrado abaixo na Figura 1.

Depois de modelar isso e executá-lo em nosso banco de dados gráfico com volumes reais de dados, percebi rapidamente que isso não funcionaria.

A travessia de um produto para clientes próximos a seus produtos e o cálculo dos produtos que mais aparecem leva algo em torno de 10 segundos.

Essencialmente, nós "pontuamos" no problema do lote de dois dias, para que cada pesquisa coloque a latência de travessia exatamente onde não a queremos: na frente do cliente.

Mas talvez esse modelo de gráfico não esteja muito longe do que precisamos fazer aqui? Na verdade, a abordagem descrita acima é uma técnica de aprendizado de máquina (ML) conhecida como “filtragem colaborativa”.

Essencialmente, a filtragem colaborativa é uma abordagem que examina a semelhança de certos objetos de dados com base na atividade com outros usuários e nos permite fazer previsões com base nesses dados.

No nosso caso, coletaremos implicitamente os dados do carrinho/pedido de nossa base de clientes e os usaremos para fazer melhores recomendações de produtos para aumentar as vendas online.

Implementação

Em primeiro lugar, vamos olhar para a coleta de dados. Adicionar uma chamada de serviço extra à função de “fazer pedido” de compras não é um grande negócio. Na verdade, ele já existe; apenas os dados são armazenados em um banco de dados e processados posteriormente. Não se engane: ainda queremos incluir o processamento em lote.

Mas também queremos processar os dados do carrinho em tempo real, para que possamos alimentá-los de volta no conjunto de dados on-line e usá-los imediatamente depois.

Começaremos colocando uma solução de transmissão de eventos como Apache Pulsar . Dessa forma, todas as novas atividades do carrinho são colocadas em um tópico pulsar , onde é consumido e enviado para o banco de dados de lote subjacente , bem como para ajudar a treinar nosso modelo de ML em tempo real.

Quanto ao último, nosso consumidor Pulsar gravará em uma tabela Cassandra (mostrada na Figura 2) projetada simplesmente para armazenar entradas para cada produto no pedido. O produto então tem uma linha para todos os outros produtos desse e de outros pedidos:

 CREATE TABLE order_products_mapping ( id text, added_product_id text, cart_id uuid, qty int, PRIMARY KEY (id, added_product_id, cart_id) ) WITH CLUSTERING ORDER BY (added_product_id ASC, cart_id ASC); 

Podemos então consultar esta tabela para um determinado produto (“DSH915” neste exemplo), assim:

 SELECT added_product_id, SUM(qty) FROm order_products_mapping WHERE id='DSH915' GROUP BY added_product_id; added_product_id | system.sum(qty) ------------------+----------------- APC30 | 7 ECJ112 | 1 LN355 | 2 LS534 | 4 RCE857 | 3 RSH2112 | 5 TSD925 | 1 (7 rows)

Podemos então pegar os quatro principais resultados e colocá-los na tabela de recomendações de produtos, prontos para o serviço de recomendação consultar por ` product_id `:

 SELECT * FROM product_recommendations WHERE product_id='DSH915'; product_id | tier | recommended_id | score ------------+------+----------------+------- DSH915 | 1 | APC30 | 7 DSH915 | 2 | RSH2112 | 5 DSH915 | 3 | LS534 | 4 DSH915 | 4 | RCE857 | 3 (4 rows)

Desta forma, os novos dados de recomendação são constantemente atualizados. Além disso, todos os ativos de infraestrutura descritos acima estão localizados no data center local.

Portanto, o processo de extrair relacionamentos de produtos de um pedido, enviá-los por meio de um tópico do Pulsar e processá-los em recomendações armazenadas no Cassandra ocorre em menos de um segundo.

Com esse modelo de dados simples, o Cassandra é capaz de atender às recomendações solicitadas em milissegundos de um dígito.

Conclusões e Próximos Passos

Queremos ter certeza de examinar como nossos dados estão sendo gravados em nossas tabelas Cassandra a longo prazo. Dessa forma, podemos nos antecipar a possíveis problemas relacionados a coisas como crescimento de linha não vinculado e atualizações no local.

Alguns filtros heurísticos adicionais podem ser necessários para adicionar também, como uma lista de “não recomendados”.

Isso ocorre porque existem alguns produtos que nossos clientes comprarão uma vez ou com pouca frequência, e recomendá-los apenas ocupará espaço em relação a outros produtos que eles provavelmente comprarão por impulso.

Por exemplo, recomendar a compra de algo de nossa divisão de eletrodomésticos, como uma máquina de lavar, provavelmente não resultará em uma “compra por impulso”.

Outra melhoria futura seria implementar uma plataforma AI/ML em tempo real como Kaskada para lidar tanto com o streaming de relacionamento do produto quanto para fornecer os dados de recomendação diretamente ao serviço.

Felizmente, criamos uma maneira de aumentar o lento processo em lote existente usando o Pulsar para alimentar os eventos de adição de carrinho a serem processados em tempo real. Assim que tivermos uma ideia de como esse sistema funciona a longo prazo, devemos considerar o encerramento do processo de lote herdado.

O PE reconheceu que avançamos bem com a nova solução e, melhor ainda, que também começamos a lançar as bases para eliminar algumas dívidas técnicas. No final, todos se sentem bem com isso.

Em um próximo artigo, veremos como melhorar as promoções de produtos com a pesquisa vetorial .

Saiba como o DataStax habilita a IA em tempo real

Por Aaron Ploetz, DataStax

Também publicado aqui