Decitre est un réseau de librairies Rhône-Alpes qui a su se diversifier en s’orientant vers le e-commerce depuis 1997. Leur mission est de « permettre à chaque lecteur de trouver ses livres et à chaque livre de trouver ses lecteurs ». Grâce à la suite Elasticsearch, Decitre a réussi et continu à améliorer la pertinence de son moteur de recherche pour ses utilisateurs.

Introduction & Contexte

Nous verrons ici la démarche utilisée lors de l'amélioration de la pertinence de recherche d'un des outils de Decitre, suite à sa migration vers Elasticsearch effectuée avec l'aide de l'entreprise Zenika.

Decitre est un ensemble de librairies en Rhône-Alpes ainsi qu'un site de vente en ligne. Une part de ses activités est aussi la maintenance d'une base de données de livres. Cette base est entre autres fournie à d'autres librairies au travers d'une application en SaaS nommée ORB (pour Outil de Recherche Bibliographique). Elle repose en grande partie sur de la recherche dans cette base de livres.

Au début, nous n'avions aucune information sur les recherches effectuées. Nous avons donc loggué les recherches (en conservant l'utilisateur, la date, la recherche, le nombre de résultats et la durée de recherche).

Le fait de conserver les recherches effectuées par les utilisateurs nous était important, pour permettre de connaître le type de recherches effectuées, d'avoir des statistiques sur le nombre de résultats renvoyés, et de connaître dans quels cas les recherches ne renvoient pas de résultats.

Visualiser les recherches avec Kibana

Nous avons crée un script qui lit l'ensemble des recherches stockées dans nos logs pour les indexer dans Elasticsearch et enfin les exploiter dans Kibana.

Kibana nous permet donc maintenant d'avoir, entre-autres, un top des recherches sans résultat. En interne, nous consultons ce top une fois par semaine, et prenons des mesures pour chaque cas. Ces cas sont très variés : ajouter un livre manquant en base, ajouter de nouveaux synonymes, avoir de nouvelles pistes pour améliorer la configuration des “analyzers”, etc.

Faire des hypothèses et les valider en amont

Désormais nous avons des informations sur les recherches que font les utilisateurs ainsi que sur l’ensemble des données auxquelles ils accèdent. Nous pouvons donc émettre des hypothèses, telles que :

Quel est l'impact de l'ajout de synonymes ?
Le nombre de zéro résultat va-t-il diminuer si l'on rajoute un filtre (“token filter”) dans notre “analyzer"?
Les résultats sont-ils plus pertinents si l'on supprime certains champs sur lesquels portent la recherche ?

Ces hypothèses seront à définir en fonction du résultat des études précédentes.

Travail sur le nombre de résultats

Afin de valider les différentes hypothèses modifiant le nombre de résultats, nous utilisons notre environnement de pré-production. Après avoir extrait la liste des recherches simples effectuées sur un mois (ici plusieurs centaines de milliers de recherches), nous les rejouons sur l'environnement de pré-production qui a été mis dans l'état de la production.

Le script rejouant ces recherches va nous générer un fichier CSV contenant la recherche et le nombre de résultats renvoyés. Après cela, nous effectuons un déploiement sur la pré-production pour la mettre dans l'état dans lequel nous voulons faire le test (par exemple, pour tester l'impact de la suppression du résumé des champs sur lesquels portent la recherche). Alors, nous relançons le script pour rejouer toutes les requêtes extraites.

Nous nous retrouvons alors avec deux fichiers CSV, que nous allons fusionner pour donner un seul fichier contenant la recherche, le nombre de résultats avant et après. Viens ensuite une étape fastidieuse, mais intéressante qui consiste à prendre un échantillon de recherches dont le nombre de résultats change, et à les étudier une-à-une.

Étude des recherches unes-à-unes

Ici l'étude va dépendre du cas testé, par exemple après avoir supprimé un champ sur lequel porte la recherche, nous étudions les recherches qui passent à 0 résultats. Nous exécutons chaque recherche en production et étudions les résultats pour vérifier si ceux-ci sont pertinents. Après en avoir étudié une centaine, nous pouvons donc valider si ces recherches passant à 0 résultats n'ont pour la plupart pas de résultat pertinent.

Pour les recherches qui ont des résultats pertinents avant modification mais n'en ont plus après, nous indiquons pour chaque cas une piste pour permettre de retrouver ces résultats: ajout de synonymes, indexation de nouveaux champs conditionnellement, modification “analyzer”, etc.

Étude globale

Le travail précédent ne peut être effectué que sur un sous-ensemble des recherches. Afin d'avoir une vue d'ensemble des changements, nous utilisons graphviz. Un script permet de partir du fichier contenant la recherche, le nombre de résultats avant et après, et va donner un fichier “graphviz” que l'on peut convertir en image.

Figure 1. Vue d'ensemble des changements avec graphviz

Cette figure montre les mouvements du nombre de résultats obtenus lors d’une recherche - ici représentés par tranches - avant et après modification. Par exemple, si l’on considère le premier rectangle: avant modification 55 025 recherches n’avaient pas de résultat contre 53 268 après modification. Nous constatons donc une diminution du nombre de recherches sans résultat de 3% dans la tranche “0 résultat”. Nous observons également que 1 587 (2,88% arrondi à 3%) des recherches qui n’aboutissaient à aucun résultat avant modification donnent désormais “de 1 à 5 résultats” après modification. De la même manière, 119 et 29 recherches sont respectivement passées de “0 résultat” à “6 à 20 résultats” et “21 à 40 résultats” (voir les flèches illustrant le passage d’une tranche de résultats à l’autre).

Indicateurs en production

Avant de mettre les changements en production, il est nécessaire de définir des indicateurs pour savoir si les changements ont réellement un impact positif en production. C’est pourquoi nous surveillons d’une part l’historique des recherches effectuées [1] et d’autre part les consultations des fiches produit [2].

Figure 2. Tableau de bord Kibana montrant le temps de réponse des recherches et le nombre de recherche effectuées par période [1].

Ce tableau de bord Kibana affiche les percentiles de temps de réponse des recherches où 50% des recherches sont réalisées en moins de 60ms. Généré après chaque mise en production, ce graphique permet de mesurer l’impact des modifications sur les performances du moteur de recherche. En dessous, est affiché le nombre de recherches effectuées par période afin de vérifier que lors d’une augmentation (ex. à la rentrée ou Noël), les temps de réponse d’Elasticsearch restent identiques

D'autre part, nous nous intéressons aux clics vers les fiches produit. En effet, nous surveillons l'identifiant de la recherche ainsi que la position à laquelle se trouve le produit recherché dans la liste des résultats de recherche. Par exemple, lorsqu'un utilisateur clique sur l’un des premiers résultats (entre 1 et 5), alors la pertinence du moteur de recherche est considérée comme bonne. Par contre, s’il clique sur des résultats en dessous de la 30 ème position, alors la pertinence est considérée comme étant moins bonne.

Figure 3. Tableau de bord Kibana montrant la position des fiches produits visitées dans la liste de résultats et les consultations de fiches produits [2].

Le tableau de bord Kibana illustré en Figure 3, montre que 95% des clics se font sur les 20 premiers résultats de la liste - ce qui atteste d’une bonne pertinence des résultats affichés par le moteur de recherche dans la liste des résultats. En dessous, nous observons que seulement 10% des recherches donnent lieu à la consultation d’une fiche produit. En d’autres termes 90% des recherche d’aboutissent pas à la consultation d’une fiche produit.

Ces pourcentages peuvent être expliqués par de multiples raisons. Par exemple, l'utilisateur a obtenu toutes les informations qu’il recherchait à partir de la liste des résultats et n'a donc pas eu besoin de consulter une fiche produit ou encore l’utilisateur a fait une autre recherche parce que les résultats de la précédente n’étaient pas pertinents.

Conclusion

Cet article montre comment Decitre a amélioré la pertinence de son moteur de recherche :

En collectant des informations (sur les utilisateurs, les recherches, les données)
En faisant des hypothèses/tests que nous validons et en itérant sur ces tests
En ayant des indicateurs en production pour suivre l'impact des modifications sur la pertinence et la performance.

Pour plus d'informations cliquez ici.

Elasticsearch Platform

Suite Elastic

Elastic Cloud

Observability

Security

Search

Par secteur

Par solution

Témoignage client

Développeurs

Communication

Apprentissage

Aide

Actualités d'Elastic

<

2015

février

>

Utilisations d'Elasticsearch et leçons à tirer

Nous suivre

À propos de nous

Emplois

Presse

Partenaires

Confiance et sécurité

Relations investisseurs

EXCELLENCE AWARDS