Implémentation de l'IA dans le commerce de détail avec Apache Cassandra et Apache Pulsar

Le parcours vers la mise en œuvre de solutions d'intelligence artificielle et d'apprentissage automatique nécessite de résoudre de nombreux défis courants qui surgissent régulièrement dans les systèmes numériques : mettre à jour les systèmes hérités, éliminer les processus par lots et utiliser des technologies innovantes fondées sur l'IA/ML pour améliorer l'expérience client dans des manières qui ressemblaient à de la science-fiction il y a quelques années à peine.

Pour illustrer cette évolution, suivons un entrepreneur hypothétique qui a été embauché pour aider à mettre en œuvre des solutions d'IA/ML chez un détaillant à grande surface. Ceci est le premier d'une série d'articles qui détaillent les aspects importants du voyage vers l'IA/ML.

Le problème : un processus par lots fragile

C'est le premier jour chez BigBoxCo dans l'équipe « Infrastructure ». Après avoir suivi les activités obligatoires des ressources humaines, j'ai reçu mon badge d'entrepreneur et je me suis dirigé vers mon nouvel espace de travail.

Après avoir rencontré l'équipe, on m'a dit que nous avions une réunion avec l'équipe « Recommandations » ce matin.

Mon accès au système ne fonctionne pas encore tout à fait, alors j'espère que le service informatique réglera cela pendant que nous serons en réunion.

Dans la salle de réunion, nous sommes quelques-uns : mon manager et deux autres ingénieurs de ma nouvelle équipe, et un ingénieur de l'équipe Recommandations. Nous commençons par quelques présentations, puis nous passons à discuter d'un problème de la semaine précédente.

De toute évidence, il y a eu une sorte d'échec de lot du jour au lendemain la semaine dernière, et ils en ressentent encore les effets.

Il semble que les recommandations de produits actuelles soient basées sur les données collectées à partir des commandes des clients. A chaque commande, il y a une nouvelle association entre les produits commandés, qui est enregistrée.

Lorsque les clients consultent les pages de produits, ils peuvent obtenir des recommandations basées sur le nombre d'autres clients qui ont acheté le produit actuel aux côtés de différents produits.

Les recommandations de produits sont servies aux utilisateurs sur bigboxco.com via une couche de microservice dans le cloud. La couche de microservice utilise un déploiement de centre de données local (cloud) d' Apache Cassandra pour diffuser les résultats.

La façon dont les résultats sont collectés et servis, cependant, est une tout autre histoire. Essentiellement, les résultats des associations entre produits (achetés ensemble) sont compilés lors d'une tâche MapReduce. C'est le traitement par lots qui a échoué la semaine dernière.

Bien que ce processus par lots n'ait jamais été rapide, il est devenu plus lent et plus fragile au fil du temps. En fait, parfois, le processus prend deux ou même trois jours pour s'exécuter.

Améliorer l'expérience

Après la réunion, je vérifie mon ordinateur et il semble que je puisse enfin me connecter. Pendant que je regarde autour de moi, notre ingénieur principal (PE) passe et se présente.

Je lui raconte la rencontre avec l'équipe Recommandations, et il me raconte un peu plus l'historique du service Recommandations.

Il semble que ce processus par lots soit en place depuis environ 10 ans. L'ingénieur qui l'a conçu est passé à autre chose, peu de personnes dans l'organisation le comprennent vraiment et personne ne veut y toucher.

L'autre problème, je commence à l'expliquer, est que l'ensemble de données à l'origine de chaque recommandation date presque toujours de quelques jours.

Bien que cela ne soit pas un gros problème dans le grand schéma des choses, si les données de recommandation pouvaient être mises à jour, cela profiterait aux promotions à court terme que le marketing organise.

Il hoche la tête en signe d'accord et dit qu'il est définitivement ouvert aux suggestions sur la façon d'améliorer le système.

C'est peut-être un problème de graphe ?

Au début, cela me semble être un problème de graphique. Nous avons des clients qui se connectent au site et achètent des produits. Avant cela, lorsqu'ils regardent un produit ou l'ajoutent au panier, nous pouvons afficher des recommandations sous la forme "Les clients qui ont acheté X ont également acheté Y".

Le site a cela aujourd'hui, en ce sens que le service de recommandations fait exactement cela : il renvoie les quatre principaux produits supplémentaires qui sont fréquemment achetés ensemble.

Mais nous aurions besoin d'un moyen de « classer » les produits, car la mise en correspondance d'un produit avec tous les autres achetés en même temps par l'un de nos 200 millions de clients va devenir importante et rapide.

Nous pouvons donc les classer en fonction du nombre de fois qu'ils apparaissent dans une commande. Un graphique de ce système pourrait ressembler à ce qui est illustré ci-dessous dans la figure 1.

Après avoir modélisé cela et l'avoir exécuté sur notre base de données graphique avec de vrais volumes de données, j'ai rapidement réalisé que cela ne fonctionnerait pas.

La traversée d'un produit à des clients proches jusqu'à leurs produits et le calcul des produits qui apparaissent le plus prennent environ 10 secondes.

Essentiellement, nous avons « lancé » le problème du lot de deux jours, pour que chaque recherche place la latence de traversée précisément là où nous ne le voulons pas : devant le client.

Mais peut-être que ce modèle de graphe n'est pas trop éloigné de ce que nous devons faire ici ? En fait, l'approche décrite ci-dessus est une technique d'apprentissage automatique (ML) connue sous le nom de "filtrage collaboratif".

Essentiellement, le filtrage collaboratif est une approche qui examine la similarité de certains objets de données en fonction de l'activité avec d'autres utilisateurs, et il nous permet de faire des prédictions basées sur ces données.

Dans notre cas, nous collecterons implicitement les données de panier/commande de notre clientèle et nous les utiliserons pour faire de meilleures recommandations de produits afin d'augmenter les ventes en ligne.

Mise en œuvre

Tout d'abord, regardons la collecte de données. L'ajout d'un appel de service supplémentaire à la fonction d'achat "passer la commande" n'est pas trop important. En fait, il existe déjà ; c'est juste que les données sont stockées dans une base de données et traitées plus tard. Ne vous y trompez pas : nous voulons toujours inclure le traitement par lots.

Mais nous voudrons également traiter ces données de panier en temps réel, afin que nous puissions les réinjecter directement dans l'ensemble de données en ligne et les utiliser immédiatement après.

Nous commencerons par mettre en place une solution de diffusion d'événements telle que Pulsar Apache . De cette façon, toute nouvelle activité de panier est mise sur un Sujet Pulsar , où il est consommé et envoyé à la fois à la base de données batch sous-jacente et pour aider à former notre modèle ML en temps réel.

Quant à ce dernier, notre consommateur Pulsar écrira dans une table Cassandra (illustrée à la figure 2) conçue simplement pour contenir des entrées pour chaque produit de la commande. Le produit a alors une ligne pour tous les autres produits de cette commande et d'autres :

 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); 

Nous pouvons ensuite interroger cette table pour un produit particulier ("DSH915" dans cet exemple), comme ceci :

 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)

Nous pouvons ensuite prendre les quatre premiers résultats et les placer dans le tableau des recommandations de produits, prêt pour que le service de recommandation interroge par ` 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)

De cette façon, les nouvelles données de recommandation sont constamment mises à jour. En outre, tous les actifs d'infrastructure décrits ci-dessus sont situés dans le centre de données local.

Par conséquent, le processus consistant à extraire les relations de produit d'une commande, à les envoyer via un sujet Pulsar et à les transformer en recommandations stockées dans Cassandra se déroule en moins d'une seconde.

Avec ce modèle de données simple, Cassandra est capable de fournir les recommandations demandées en quelques millisecondes à un chiffre.

Conclusions et prochaines étapes

Nous voudrons être sûrs d'examiner comment nos données sont écrites dans nos tables Cassandra à long terme. De cette façon, nous pouvons anticiper les problèmes potentiels liés à des éléments tels que la croissance des lignes non liées et les mises à jour sur place.

Certains filtres heuristiques supplémentaires peuvent également être nécessaires, comme une liste « ne pas recommander ».

En effet, nos clients achèteront certains produits une fois ou rarement, et les recommander ne fera que prendre de la place par rapport à d'autres produits qu'ils sont beaucoup plus susceptibles d'acheter de manière impulsive.

Par exemple, recommander l'achat d'un article de notre division d'électroménagers, comme une machine à laver, ne donnera probablement pas lieu à un « achat impulsif ».

Une autre amélioration future consisterait à implémenter une plate-forme AI/ML en temps réel comme Kaskada pour gérer à la fois le streaming de la relation produit et pour fournir directement les données de recommandation au service.

Heureusement, nous avons trouvé un moyen d'augmenter le processus par lots lent existant en utilisant Pulsar pour alimenter les événements d'ajout de panier à traiter en temps réel. Une fois que nous aurons une idée de la façon dont ce système fonctionne à long terme, nous devrions envisager d'arrêter le processus par lots hérité.

Le PE a reconnu que nous avions bien avancé avec la nouvelle solution et, mieux encore, que nous avions également commencé à jeter les bases pour éliminer une partie de la dette technique. Au final, tout le monde s'en sent bien.

Dans un prochain article, nous verrons comment améliorer les promotions de produits avec la recherche vectorielle .

Découvrez comment DataStax permet l'IA en temps réel

Par Aaron Ploetz, DataStax

Également publié ici