Élaboration d'un plan de contrôle pour gérer la recherche dans le commerce électronique

Les parties 1 et 2 de cette série ont démontré pourquoi la recherche e-commerce nécessite une couche de gouvernance, une couche de décision entre la requête utilisateur et le moteur de recherche. Cette couche classe l'intention, applique les contraintes et oriente la requête vers la stratégie de recherche appropriée (par exemple, BM25, sémantique ou hybride). Cet article explique comment construire cette couche à l'aide d'une architecture simple : les politiques d'interprétation des requêtes sont stockées sous forme de documents et récupérées lors de l'exécution de la requête grâce à une correspondance inverse rapide. Comme les nouvelles politiques de recherche (par exemple, "mettre en avant la marque X" ou "afficher uniquement la catégorie Y") ne nécessitent aucune modification du code, la couche de routage reste stable malgré l'évolution des politiques et garantit la sécurité des moteurs de recherche dans les environnements critiques. Si vous souhaitez voir le résultat final de cette architecture avant de poursuivre votre lecture, regardez cette vidéo : Fixing Search Relevance in Seconds: Introducing PRISM.

Pourquoi l'interprétation des requêtes est souvent un défi

Le stockage des politiques sous forme de code (blocs if/else dans la couche applicative) génère des dizaines de milliers de lignes de logique fragile, dépourvue de tout système d'indexation permettant une récupération efficace des règles au moment de la requête. L'itération est lente (un changement de comportement de requête unique peut nécessiter un cycle de déploiement de six semaines), la responsabilité n'est pas clairement établie (pourquoi les résultats ont-ils changé ?) et les utilisateurs métier ne peuvent pas modifier le comportement de recherche sans l'intervention de l'ingénierie. Ceci est illustré à gauche dans l'image suivante :

Le stockage des politiques sous forme de données dans un index Elasticsearch est illustré à droite de l'image ci-dessus. Cette approche résout tous les problèmes liés à une logique de résolution des requêtes codée en dur. Cependant, pour que cela fonctionne, il faut pouvoir déterminer rapidement quelles politiques correspondent à la requête de l'utilisateur et comment les conflits doivent être résolus. C'est là qu'intervient le plan de contrôle géré.

Le modèle du plan de contrôle

Un plan de contrôle géré s'intercale entre la requête brute de l'utilisateur et la récupération dans Elasticsearch. Il reçoit le texte de l'utilisateur en entrée, et sa sortie est un plan d'exécution qui inclut des filtres, des pondérations et des décisions de routage pour la récupération.

Un pipeline du plan de contrôle se compose de ces éléments :

1. Requête utilisateur : l'utilisateur saisit une chaîne de caractères indiquant ce qu'il recherche, par exemple "oranges" ou "cadeau pour grand-père".
2. Recherche de politique : mise en correspondance de la requête utilisateur avec l'index des politiques.
3. Renvoi des politiques correspondantes : Les politiques correspondant à la requête utilisateur sont renvoyées à partir de l'index des politiques.
4. Application de la politique : le plan de contrôle analyse ces politiques renvoyées et compose les politiques correspondantes en un plan d'exécution cohérent unique comprenant des filtres, des boosts, des remplacements et des garde-fous, et qui applique la méthode de récupération appropriée (par exemple, lexicale, sémantique ou hybride).
5. Exécution : la requête Elasticsearch modifiée sensible aux intentions est transmise à l'application pour être exécutée sur un index de catalogue de produits.
6. Explication (optionnel) : en plus de créer une requête qui fournit des résultats alignés sur l'activité et l'intention, le plan de contrôle fournit une charge utile d'explicabilité optionnelle pour montrer quelles politiques ont été déclenchées et comment elles ont été combinées.

Pour déterminer les politiques à appliquer à la chaîne de recherche d'un utilisateur, il faut utiliser une primitive de correspondance inverse rapide, que nous résolvons à l'aide de la requête percolateur. Après avoir récupéré les politiques pertinentes, la combinaison de plusieurs politiques correspondantes en un plan d'exécution unifié nécessite un framework de jugement : priorités, stratégies de conflit, suivi des expressions utilisées et transformations en cascade qui appliquent les politiques en séquence plutôt qu'indépendamment. De plus, il convient de sélectionner la technologie de récupération la plus appropriée (par exemple, BM25 pour "oranges" ou recherche sémantique pour "cadeau pour grand-père").

Recherche de politique : vérification de la requête avant la recherche de produits

Lorsqu'un client saisit une requête, un système de recherche doté d'une couche de contrôle contrôlée ne l'envoie pas directement au catalogue de produits. La requête est d'abord vérifiée au regard d'un ensemble de règles prédéfinies, puis modifiée pour correspondre à son intention et aux priorités de l'entreprise.

Structure de la politique

Chaque politique est un simple document qui définit deux choses :

• Critères de correspondance : Le texte de la requête qui doit déclencher l'application de cette politique. Ce peut être une expression exacte, un seul mot, un schéma ou une combinaison des deux.
• Action : quoi faire lorsque la politique est déclenchée. Cela peut consister à appliquer un filtre de catégorie, exclure des produits, extraire une contrainte de prix ou modifier la stratégie de récupération.

Le système identifie toutes les politiques correspondantes, les organise en un plan d'exécution, puis lance la recherche de produits. Ensemble, les politiques agissent comme un vendeur compétent qui comprend vos besoins et vous guide vers le bon rayon.

Le modèle de politique

Les premiers articles de cette série ont présenté des exemples d'application des politiques : la restriction de la recherche d'"oranges" à la catégorie des fruits et légumes, la prise en compte de l'exclusion de l'option "sans cacahuètes" et l'orientation de la recherche "cadeau pour grand-père" vers une recherche sémantique. Le principe architectural fondamental est que, dans chaque cas, la requête est vérifiée par rapport aux politiques enregistrées avant le début de la recherche de produits. Ces politiques déterminent les contraintes à appliquer, le texte à modifier et la stratégie de recherche à utiliser. La requête sur le catalogue de produits intervient après l'application des politiques et la création d'une nouvelle requête réécrite.

Pourquoi c'est rapide

Un système de commerce électronique d'entreprise peut comporter des millions de produits, mais seulement quelques centaines ou milliers de politiques. La recherche de politiques s'effectue dans un index restreint et ciblé, et non dans le catalogue complet des produits, ce qui la rend rapide. De plus, comme les politiques sont stockées dans leur propre index, un responsable merchandising qui ajoute une nouvelle politique n'a pas besoin de modifier le code de l'application, et un ingénieur qui optimise la recherche de produits n'a pas besoin de modifier l'index des politiques. Ces deux aspects évoluent indépendamment.

Les exemples ci-dessus décrivent ce qui se passe sur le plan conceptuel. Sous le capot, la recherche de politique est mise en œuvre à l'aide du type de requête percolator d'Elasticsearch, spécialement conçu pour ce type de schéma : faire correspondre un texte entrant à un ensemble de requêtes stockées. La quatrième partie de cette série propose une exploration pratique et approfondie de l'implémentation du percolateur, notamment les mappings d'index, les marqueurs de délimitations et le suivi des expressions par mise en évidence. Le mécanisme de recherche étant traité en détail dans la quatrième partie, examinons maintenant le contenu d'un document de politique et la manière dont le plan de contrôle rassemble plusieurs politiques en un seul plan d'exécution.

Exemples de politiques

Maintenant que nous avons vu le rôle conceptuel des politiques, examinons leur contenu concret. Les deux politiques ci-dessous ont été conçues pour être intentionnellement conflictuelles, ce qui illustrera le système de résolution des conflits décrit dans les sections suivantes.

Chocolat pas cher

La politique ci-dessous détecte si un utilisateur a effectué une recherche contenant l'expression "chocolat pas cher". Le cas échéant, les résultats sont limités aux catégories "Chocolats" et "Chocolats au lait". Cette règle applique également un filtre de prix de 2 $. Notez par ailleurs que cette règle a une priorité de 210 ; nous y reviendrons lors de notre discussion plus approfondie sur la résolution des conflits.

Les paramètres de mode de filtrage et de stratégie de gestion des conflits présentés ici (hard_filter, soft_boost, restrict, override) sont expliqués en détail dans la section ci-dessous relative à la résolution des conflits.

Lorsque la politique ci-dessus est activée, une recherche de "chocolat bon marché" respecte le filtre prix de 2 $ et limite les résultats aux catégories "Chocolats" et "Chocolats au lait". Voici des exemples de résultats :

Chocolat de Noël

La politique ci-dessous est un exemple de politique applicable à Noël. Elle limite les résultats aux catégories "Produits alimentaires et boissons de Noël" et "Confiseries de Noël", met en avant les produits appartenant également à la catégorie "Calendriers de l'Avent" et applique un filtre de prix inférieur à 7 $ pour privilégier les articles saisonniers abordables. Notez également que cette politique a une priorité de 300. Nous y reviendrons plus en détail lors de notre discussion sur la résolution des conflits.

Lorsque la politique ci-dessus est activée sans aucune politique contradictoire, une recherche de "chocolat" respecte le filtre de prix de 7 $ et limite les résultats aux catégories "Produits alimentaires et boissons de Noël" et "Confiseries de Noël", tout en mettant en avant les produits étiquetés "Calendriers de l'avent". Des exemples de résultats sont présentés ci-dessous :

Combiner des politiques concordantes

La recherche de politique décrite plus haut n'est qu'une partie du processus. L'autre partie concerne ce qui se passe lorsque plusieurs politiques correspondent à la même requête.

Dans tout déploiement d'une certaine envergure, une seule requête déclenche systématiquement plusieurs politiques à la fois. L'expression "chocolat bon marché" correspondra aux deux politiques que nous avons présentées plus haut. Chaque politique est correcte prise isolément. Le défi consiste à les combiner en un seul plan d'exécution cohérent, sans contradictions, sans double comptage et sans qu'une politique n'annule silencieusement l'action d'une autre.

Ce n'est pas un problème de recherche, mais un problème de jugement. Le système doit décider si :

• Ordre d'application : si une politique de négation supprime "sans cacahuètes" de la requête, la politique de prix voit-elle toujours le texte original ou le texte modifié ?
• Conflits de filtres : si deux politiques fixent des plafonds de prix différents, laquelle prévaut ? La politique perdante est-elle silencieusement supprimée ou se transforme-t-elle progressivement en soft boost ?
• Propriété des expressions : si deux polices portent sur le même mot et que la première l'a déjà consommé, la deuxième doit-elle continuer à l'utiliser ?

Une implémentation simple (appliquer toutes les politiques correspondantes indépendamment, puis fusionner les résultats) dysfonctionne dès que les politiques interagissent. L'architecture nécessite un modèle explicite de la composition des politiques. Ce modèle est présenté dans les deux sections suivantes : un framework de priorisation et de résolution des conflits, et un modèle de transformation en cascade qui rend l'interaction des politiques déterministe.

L'idée clé est que l'application d'une politique n'est pas un ensemble d'opérations indépendantes, mais une transformation en cascade. Chaque politique reçoit l'état de réécriture produit par toutes les politiques de priorité supérieure et le transforme à nouveau :

État initial → [Politique A] → état' → [Politique B] → état'' → ... → plan d'exécution

L'état contient le texte de la requête réécrit, les filtres accumulés, l'intention actuelle et toutes les extensions de synonymes. Une politique de haute priorité peut supprimer du texte de la requête, et chaque politique suivante traite la requête modifiée et non la requête initiale. Le contexte s'accumule. L'ordre est important.

Priorité et résolution des conflits : le déterminisme est important

Les stratégies de résolution de conflits spécifiques relèvent d'un choix de conception. Différentes organisations peuvent gérer les conflits différemment en fonction de leurs besoins opérationnels. L'approche suivante illustre le type de framework de jugement nécessaire à un plan de contrôle. L'important n'est pas tant ces stratégies spécifiques, mais le fait que le système dispose de stratégies explicites et déterministes, plutôt que de laisser les conflits se résoudre par des interactions imprévisibles.

Ordre de priorité

Les politiques sont triées par priorité (de la plus élevée à la plus basse). Lorsqu'une même requête est traitée par plusieurs politiques, elles sont appliquées par ordre de priorité. Si deux politiques tentent de définir le même champ de filtre, la stratégie déclarée par la politique ayant la priorité la plus élevée pour ce champ prévaut. En cas de déclenchement de plusieurs politiques de même priorité, la politique ayant l'identifiant le plus élevé est prioritaire (comme si elle disposait d'une priorité supérieure) ; ce choix garantit un comportement déterministe en cas de conflit.

Résolution par champ, pas par politique

Un principe de conception essentiel : la résolution des conflits s'effectue par champ (par exemple, marque, catégorie ou description), et non par politique. Lorsque deux politiques produisent des filtres qui se chevauchent sur certains champs, seuls ces champs sont concernés par la stratégie de résolution des conflits, et cette stratégie est définie par la politique prioritaire correspondante. Les champs non conflictuels des deux politiques restent inchangés.

Ceci est important, car une approche par politique obligerait le système à accepter ou à rejeter une politique entière dès qu'un seul de ses champs est en conflit.

La résolution par champ préserve la quantité maximale d'informations utiles sur les contraintes.

Trois paramètres par champ de filtre

Chaque champ de filtre dans une politique possède trois paramètres indépendants :

Mode de filtrage : comment le filtre est appliqué lorsqu'il n'y a pas de conflit.

• hard_filter (par défaut) : appliqué comme une clause Elasticsearch bool.filter. Ceci permet d'exclure complètement les produits non pertinents. Par exemple, limiter une recherche sur "oranges" à la catégorie "fruits et légumes" élimine les résultats tels que le jus d'orange et marmelade d'orange. Les documents non pertinents sont totalement exclus des résultats.
• soft_boost: appliqué comme un poids Elasticsearch function_score avec un boost_weight configurable. Les documents correspondants reçoivent un boost de classement, mais les documents non correspondants ne sont pas exclus. C'est utile pour promouvoir une marque, par exemple, sans exclure d'autres marques.

Stratégie de conflit

Ce qui se passe lorsqu'une politique de moindre priorité définit le même champ :

• override: la valeur de cette politique prioritaire l'emporte ; la valeur de priorité inférieure est complètement supprimée. Valable pour tous les types de champs.
• restrict: Prenez la valeur numérique la plus restrictive (par exemple, le plafond inférieur pour le prix__max, the higher floor for price__min). Valable uniquement pour les champs de plage numériques.
• merge: combine les deux valeurs en une union. Valable uniquement pour les champs non numériques.
• soft_boost: convertir le filtre conflictuel en un poids function_score avec un boost_weight configurable au lieu d'un filtre strict. Pour plus de détails sur le boosting de function_score, consultez Influencer le classement BM25 avec l'optimisation multiplicative dans Elasticsearch. Ceci n'est valable que pour les champs de non-négation.

Valeur : la valeur réelle du filtre (par exemple, une liste de catégories, un seuil de prix).

Stratégies par type de champ : les stratégies ne sont pas toutes adaptées à tous les types de champs. Par exemple, une exclusion étant par nature binaire, elle ne peut pas recevoir un soft boost. Le tableau suivant montre quelles stratégies sont disponibles pour chaque type de champ :

Le paramètre soft_boost ne peut pas être appliqué aux champs de négation, car les exclusions sont binaires. Convertir "ne jamais afficher les conserves" en "préférer légèrement les produits non en conserve" modifie fondamentalement la sémantique ; un produit de la catégorie "conserves" apparaîtrait toujours, mais légèrement moins bien classé, ce qui annule l'intérêt de l'exclusion.

Un exemple concret : chercher du "chocolat pas cher" lors d'une campagne de Noël

Supposons qu'un commerçant ait créé les deux politiques relatives au chocolat que nous avons présentées précédemment : une politique de priorité inférieure pour le chocolat bon marché et une autre de priorité supérieure qui sera activée pendant la période de Noël. Si ces deux politiques sont activées, leur combinaison dépend du mode de filtrage et de la stratégie de gestion des conflits de la politique prioritaire. Dans ce cas, elles seront combinées comme suit :

Ceci met en évidence deux conflits, l'un concernant les catégories et l'autre le prix. Notons que la requête qui sera exécutée après cette transformation présente les caractéristiques suivantes :

• Seuls les produits des catégories "Aliments et boissons de Noël" et "Friandises de Noël" seront affichés.
• Dans ces catégories, si les produits sont également étiquetés comme appartenant à la catégorie "Calendriers de l'avent", leur prix sera multiplié par 3.
• Un filtre de prix de 2 $ est appliqué, provenant de la politique de priorité inférieure (car la politique de priorité supérieure a spécifié de "limiter" en cas de conflit).
• Les termes "pas cher" sont supprimés, seuls les produits correspondant au mot "chocolat" sont conservés.

Avec ces deux politiques activées, « cheap chocolate » renvoie des résultats similaires à l’image ci-dessous :

Assouplissement des contraintes

Le détaillant ne souhaite peut-être pas exclure les produits des catégories "Chocolats" et "Chocolats au lait" pendant la période de Noël. Les paramètres de la politique de Noël ont peut-être été trop restrictifs et ont supprimé par inadvertance des catégories couvertes par la politique concernant les "chocolats bon marché". Cet exemple illustre pourquoi il peut être plus judicieux de combiner les politiques de moindre priorité avec les politiques de priorité supérieure qui entrent en conflit. Par exemple, nous pourrions modifier la promotion des chocolats de Noël de sorte qu'au lieu d'appliquer une priorité absolue en cas de conflit, nous appliquions un soft boost. La modification apportée à cette politique serait la suivante :

Après cette modification, l'exécution du pipeline de transformation de la réécriture de requête pour "chocolat pas cher" se présente comme suit :

Lorsque l'option soft boost en cas de conflit est activée, les filtres conflictuels sont convertis en soft boosts au lieu d'être supprimés. La requête qui sera exécutée sur le catalogue de produits après cette transformation présente les caractéristiques suivantes :

• Comme "En cas de conflit" est spécifié comme "Soft boost" sur la politique de priorité élevée, les conflits seront convertis en boosts comme suit :
  • Un boost de 1x sera appliqué aux produits des catégories "Aliments et boissons de Noël" et "Friandises de Noël".
  • Un boost de 3x sera appliqué aux produits des catégories "Chocolats" et "Chocolats au lait"..
• Comme dans l'exemple précédent, si les produits sont également marqués comme appartenant à la catégorie "Calendriers de l'avent", un boost de 3x leur sera appliqué.
• Comme dans l’exemple précédent, un filtre de prix de 2 $ est appliqué.
• Les termes "pas cher" sont supprimés, seuls les produits correspondant au mot "chocolat" sont conservés.

Avec un filtrage assoupli, les résultats sont les suivants :

Remplacement du prix défini dans une politique de priorité élevée

Ou peut-être que le détaillant souhaite proposer des chocolats légèrement plus chers pendant les fêtes de fin d'année en augmentant le prix maximal à 7 $. Afin d'éviter que le prix maximal défini par la politique relative aux chocolats de Noël ne soit contourné si un utilisateur recherche "chocolats pas chers", nous pouvons configurer le mode de gestion des conflits de prix sur "remplacer" plutôt que sur "limiter", comme suit :

Grâce à ce remplacement, la requête pour "chocolat pas cher" ignore le prix maximal défini dans la politique "chocolat pas cher" et n'applique que le prix spécifié dans la politique "Chocolats de Noël", comme suit :

Ceci est similaire à l'exemple précédent, à la différence que le prix maximal est fixé à 7 $, valeur issue de la politique prioritaire, car celle-ci spécifie "Remplacer" en cas de conflit. Le filtre de prix de Noël étant prioritaire, les résultats sont les suivants :

Ces trois variantes (priorité, soft boost et remplacer le prix) illustrent une propriété essentielle du système : un responsable commercial peut modifier l'interaction entre deux politiques en ajustant un seul paramètre au sein d'une même politique, sans déployer de code. La stratégie de gestion des conflits est le levier qui contrôle le comportement opérationnel.

Suivi des expressions utilisées

Il existe une forme de conflit plus subtile : deux politiques qui correspondent sur la même expression. Si une politique prioritaire supprime "sans cacahuètes" de la requête, une politique moins prioritaire qui correspondait également à "sans" n'a plus rien à traiter. Le système détecte si l'expression correspondante n'est plus présente dans la requête reformulée et ignore la politique moins prioritaire.

Les politiques d'intention sont exemptées du suivi des expressions utilisées : elles définissent la stratégie de récupération en fonction de la correspondance de la requête d'origine, indépendamment du texte supprimé par les politiques prioritaires.

L'ordonnancement prioritaire, la résolution des conflits au niveau des champs et le suivi des expressions utilisées confèrent ensemble au plan de contrôle un modèle de composition déterministe. Grâce à cette base, le système est en mesure de prendre des décisions de routage qui seraient risquées sans elle.

La gouvernance régule la stratégie de récupération

Il est important de noter que le choix de la méthode de recherche appropriée (textuelle, sémantique ou hybride) intervient après la phase de gouvernance. Si vos politiques ont déjà imposé la "catégorie de produit", la recherche sémantique devient alors beaucoup moins risquée, car l'ensemble des candidats est restreint. Une recherche sémantique portant sur 500 articles de produit est très différente d'une recherche sémantique portant sur 500 000 références. La gouvernance permet de limiter le champ d'application de la recherche avant même son lancement.

Par exemple, sans gouvernance, une requête sémantique pour "Fruits riches en vitamine C à moins de 4 $" pourrait renvoyer, en plus des fruits, des flacons de vitamines, des carottes et des poivrons verts. Le plan de contrôle garantit que ces résultats indésirables ne sont même pas pris en compte dans l'expansion sémantique.

Avec cette contrainte en place, le plan de contrôle applique une logique de routage pragmatique :

• Lexical pour les requêtes de navigation et les requêtes d'en-tête où la précision déterministe est importante.
• Sémantique pour les requêtes d'exploration descriptive où la correspondance conceptuelle est utile.
• Hybride de manière sélective, lorsque des contraintes ont déjà été appliquées et que l'entreprise accepte un seuil de rappel plus large.

De l'architecture à la mise en œuvre

Le plan de contrôle gouverné traduit les intentions métier en plans d'exécution déterministes et composables, sans intégrer cette logique dans le code applicatif. Les politiques sont des données : elles sont mises en correspondance lors de la requête, résolues par des stratégies de gestion des conflits explicites par champ et appliquées sous forme de transformations en cascade produisant des résultats explicables. Elastic Services Engineering a conçu et déployé cette architecture pour des équipes e-commerce d'entreprise, en utilisant des modèles et des accélérateurs reproductibles qui raccourcissent le passage du concept à la production. Une démonstration de notre implémentation d'un plan de contrôle est disponible sur YouTube : Fixing Search Relevance in Seconds: Introducing PRISM.

À suivre dans cette série

Le prochain article se penchera sur la mise en œuvre pratique : comment le percolateur Elasticsearch gère la recherche de politiques, notamment les mappings d'index, les marqueurs de délimitations, le suivi des expressions par mise en évidence et des exemples concrets de requêtes.

Mettre en pratique la recherche e-commerce réglementée

L'architecture du plan de contrôle décrite dans cet article (résolution des conflits par champ, transformations de politiques en cascade et routage de récupération soumis à des contraintes de gouvernance) a été conçue et réalisée par Elastic Services Engineering. Chaque modèle, capture d'écran et pipeline de transformation présenté dans cette série provient d'un système opérationnel développé par Elastic Services Engineering et validé par rapport aux catalogues de produits à l'échelle de l'entreprise.

Si vous souhaitez implémenter un plan de contrôle gouverné et piloté par des politiques sur Elasticsearch, Elastic Services peut vous aider à y parvenir plus rapidement.

Rejoignez la discussion

Avez-vous des questions sur la gouvernance de la recherche, les stratégies de récupération ou l'architecture de recherche e-commerce ? Participez à la discussion élargie de la communauté Elastic.