Product Search Vision API ou la recommandation visuelle pour les nuls!

Les moteurs de recherche sont de plus en plus présents dans nos vies. Que ce soit pour trouver un produit à acheter ou sélectionner la série à binge watcher, ils sont devenus le pivot de notre vie numérique. Dans ce contexte, de plus en plus d’acteurs se lancent dans la recommandation visuelle. Amazon le propose déjà depuis bien longtemps, mais d’autres acteurs suivent la tendance comme ManoMano ou Castorama.

Cependant, ces solutions sont compliquées à mettre en place et demandent une équipe d’experts dédiés pour arriver à des résultats probants. Comment convaincre les décideurs d’adopter cette tendance qui rend un vrai service ? Comment lancer une Proof Of Concept en quelques jours, en maitrisant les coûts de réalisation et d’infrastructure ?

C’est avec ces questions en tête que j’ai voulu tester Product Search Vision API by Google Cloud. La promesse de Google est la suivante :

Vision API Product Search allows retailers to create products, each containing reference images that visually describe the product from a set of viewpoints. Retailers can then add these products to product sets. […] When users query the product set with their own images, Vision API Product Search applies machine learning to compare the product in the user’s query image with the images in the retailer’s product set, and then returns a ranked list of visually and semantically similar results.

Lançons notre expérimentation pour valider tout ça! Pour cela, nous allons avoir besoin de récupérer un catalogue produit, de nettoyer les données pour les mettre au format attendu par l’API et enfin, nous pourrons appeler le service de Google pour construire notre ProductSet.

Un peu de vocabulaire…

Avant d’aller plus loin, il est important de prendre le temps de comprendre les différents termes représentant les ressources manipulées, spéficiques à cette API de Google.

Ainsi, un product set est une resource logique contenant un groupe de products et des images (reference images).

Chaque product est représenté par quelques valeurs définies, comme l’identifiant du produit ou sa catégorie, les informations relatives à l’image (identifiant et uri) mais aussi les labels, permettant de spécifier des attributs relatif au produit.

Construction du catalogue

Pour un PoC en dehors de toute organisation, il me faut trouver un catalogue utilisable, me permettant de tester l’API avec un jeu de données valable. Pour cela, je me suis tourné vers Kaggle. En effet, cette plateforme orientée Data Science met à disposition des compétitions et des datasets pour apprendre ou se perfectionner en Machine Learning.

Après une recherche rapide, j’ai fait le choix d’utiliser le dataset Fashion Product Image qui compte un peu plus de 44000 images de produits divers. Kaggle permet de télécharger les datasets gratuitement, il ne me reste plus qu’à uploader les fichiers sur Google Cloud Storage.

Attention: Ce dataset compressé pèse environ 23 Gb, il faut prévoir un peu de temps pour le téléchargement.

Du catalogue au productSet

Pour pouvoir appeler l’API de Google, il est nécessaire de transformer nos informations en product set. On peut voir un product set comme une coquille vide dans laquelle on va ajouter des produits. Il existe deux façons de créer ce product set :

• Soit on crée une coquille vide que l’on remplira a posteriori en ajoutant des produits (via des appels API)
• Soit on utilise le bulk import pour pouvoir créer le product set et ses produits en une fois

Dans notre cas, je préfère utiliser le bulk import pour ne faire qu’un appel API lorsque j’aurai nettoyé mes données.

Alors, comment allons-nous transformer nos données brutes provenant de Kaggle en product sets ? La documentation nous précise qu’il faut fournir un fichier CSV à l’API import et que ce fichier doit respecter la norme suivante :

Le champsimage-uri devant convenir l’url Cloud Storage des images, j’ai commencé par uploader l’ensemble des images de produit sur un bucket. Ensuite, il faut s’occuper de la transformation du catalogue. Celle-ci est assez simple, c’est surtout du changement de format. Par facilité, j’ai utilisé Apache Beam (sur Dataflow) même si la volumétrie ne nécessite pas de parallélisation. Voici ce que fait la pipeline:

1. Lecture des données à partir du fichier styles.csv
2. Transformation de chaque ligne au format bulk import
3. Passage en mode CSV
4. Ecriture du résultat dans Cloud Storage

Le configuration de notre environnement est terminée !

Un peu de Data Science ?

Maintenant que nous avons notre product set sur Cloud Storage, il est temps de passer au coeur du sujet! Construire un modèle, l’entrainer, le valider et le mettre en production… Enfin, c’est que l’on aurait dû faire sans l’API de Google.

Pour faire simple, nous allons uniquement appeler l’API avec le path du(des) fichier(s) GCS. Le traitement étant délégué à l’API, une simple Cloud Function nous permet de faire cet appel. Une fois l’import effectué, il faudra attendre un peu avant de pouvoir appeler l’API. En effet, une étape d’indexation est nécessaire, celle-ci se déroule environ toutes les 30 minutes.

Prédiction et résultat

Nous voilà à l’étape finale : valider que l’API réponde comme nous l’espérons, avec des produits en relation avec une image personnelle.

Pour valider le bon fonctionnement de cette API, j’ai pris différentes références de produits (robes, t-shirts, basket, etc.) sur des sites e-commerce. Il est assez simple d’obtenir une prédiction. Un appel API et le tour est joué. La réponse de l’API contient :

• Une liste de produits correspondant à notre image, avec, pour chaque résultat, un score de confiance,
• Une liste de produits se basant sur des cadres de délimitations. Ainsi, sur une scène, l’API est capable d’identifier plusieurs produits et de faire les recommendations sur cet ensemble.

Les résultats sont plutôt convainquant! En effet, bien que mon jeu de donnée ne soit pas si représentatif d’un réel catalogue produit, l’API me retourne des produits similaires lorsque je lui propose une image sans bruit (photo de face, fond neutre, etc.). Par moment, les résultats sont assez hasardeux : j’ai tenté la recommendation pour un porte-feuille, l’API m’a retourné tout type de produit, sauf des porte-feuilles!

Alors, pourquoi un tel décalage ? Premièrement, parce que mon catalogue ne contient pas énormément de références. Celui-ci compte environ 44,000 lignes regroupant différents types d’articles (vêtements, bijoux, maroquinerie), chaque échantillon n’est donc pas assez représenté. Ensuite, je n’utilise pas les labels pour affiner ma recherche. De ce fait, lorsque l’on cherche un porte-feuille, on le compare avec des pantalons ou des montres… Enfin, l’utilisation des bounding boxes pour localiser les zones importantes sur les images devraient aider l’algorithme à identifier au mieux ce que je recherche.

Conclusion

La Product Search Vision API semble fonctionner, si on prend le temps d’analyser le jeu de données. Alors oui, ce n’est pas parfait, les résultats obtenus étant par moment hasardeux. Mais nous n’utilisons qu’une API! Après 30 minutes de développement, on est capable d’avoir une Proof of Concept, sans effort particulier. De mon point de vue, cette API est à considérer dans ce cadre d’usage. Commencez avec cette solution, évaluez l’engouement de vos utilisateurs et ajustez ensuite.

Je tiens à préciser que j’ai pu tester cette API chez Décathlon, avec un catalogue de plus de 160,000 produits. Les résultats sont bien meilleurs que ceux que j’expose ici. Alors, n’hésitez pas à tester cette solution chez vous, avec votre catalogue et vos images. Qui sait, les résultats vont peut-être vous bluffer et vous pourrez remettre en question ce que vous venez de lire ;)