Percolateur Elasticsearch pour la gouvernance de la recherche e-commerce : traduire les requêtes ambiguës en stratégies de récupération contrôlée

Cet article propose une analyse technique approfondie de l'implémentation Elasticsearch de l'architecture du plan de contrôle décrite dans la partie 3, montrant comment l'élaborer à l'aide du percolateur Elasticsearch. Il décrit les modèles utilisés pour mettre en œuvre un moteur de politique déterministe et gouverné en production.

De l'architecture à la mise en œuvre

L'architecture du plan de contrôle a été décrite dans la partie 3 : la correspondance inverse en tant que primitive de recherche, les documents de politique qui séparent la correspondance de l'action et les transformations en cascade qui composent plusieurs politiques en un seul plan d'exécution. Le présent article présente de manière pratique la fonctionnalité d'Elasticsearch qui sous-tend la recherche de politiques, à savoir la requête percolateur.

Le percolateur est parfaitement adapté à la gouvernance, car il inverse le sens de la recherche exactement comme l'exige un plan de contrôle. Cet article présente la mise œuvre étape par étape, en commençant par une explication claire du fonctionnement du percolateur et de son importance, puis en abordant la conception des index, le stockage des politiques, l'évaluation au moment de la requête et la composition de plusieurs politiques.

Fonctionnement de la recherche normale

Un système e-commerce peut être appelé à traiter des centaines de milliers, voire des millions de documents produit contenant des champs tels que title categoryet price. Lorsqu'un utilisateur recherche les documents correspondants, Elasticsearch doit comparer la chaîne de recherche de l'utilisateur à un ou plusieurs champs stockés dans ces documents produit. L'analyseur par défaut d'Elasticsearch, l'analyseur standard, met le texte en minuscules et le divise en tokens. Une recherche sur "oranges" correspond à "Oranges" en raison de la casse minuscule. Avec un analyseur sensible à la version linguistique qui comprend la racinisation, elle correspond également à "orange", car les deux formes se réduisent à la même racine. Par exemple, la requête de correspondance suivante renvoie les documents qui contiennent "orange" ou "oranges" dans leur champ “title”.

Ainsi, pour la requête ci-dessus, Elasticsearch renvoie les documents produit dont le champ title correspond à "oranges", qui peuvent inclure des résultats tels que "Configure à l'orange", "Jus d'orange", "Oranges juteuses", "Marmelade d'orange", etc. À noter qu'Elasticsearch est couramment utilisé pour comparer une chaîne de recherche à des documents et pour renvoyer les documents qui correspondent à la chaîne de recherche.

Le problème de gouvernance : trouver des politiques pertinentes avant de rechercher des produits

Comme indiqué dans les parties 1 à 3, un système de recherche gouverné n'envoie pas la chaîne de recherche de l'utilisateur directement au catalogue de produits. Il vérifie d'abord si des politiques s'appliquent à cette chaîne de recherche.

Un détaillant décide que lorsqu'un visiteur recherche exactement le mot "oranges", les résultats doivent être limités à la catégorie "Oranges", en excluant le jus d'orange, la confiture d'orange et le soda à l'orange. Cette décision opérationnelle est enregistrée sous forme de politique. Lorsqu'un utilisateur tape "oranges", le plan de contrôle doit trouver cette politique, en lire les instructions et modifier la recherche dans le catalogue de produits en conséquence. Pour ce faire, le plan de contrôle doit déterminer quelles politiques enregistrées sont pertinentes pour cette chaîne de recherche.

Dans un déploiement d'entreprise, on peut trouver des centaines, voire des milliers de politiques de ce type. Les vérifier une par une à l'aide d'une logique conditionnelle (if/else) est l'antimodèle de la couche applicative comme décrit dans la partie 2. Il faut un moyen de stocker toutes ces politiques dans un index et de trouver instantanément celles qui correspondent à une chaîne de recherche donnée. C'est là qu'intervient le percolateur.

Inverser le sens : le percolateur

Nous avons déjà mentionné que, dans le cadre d'une recherche classique, Elasticsearch sert généralement à comparer une chaîne de recherche à des documents et à renvoyer les documents qui contiennent cette chaîne.

Le percolateur inverse ce processus. Avec un percolateur, vous disposez d'un index où chaque document stocke un modèle de requête, puis une chaîne de recherche entrante est comparée à ces requêtes stockées afin de déterminer quel modèle de requête stocké a été déclenché.

Quant à la gouvernance, les "modèles de requêtes enregistrés" sont des politiques. Chacune d'entre elles contient un modèle décrivant le type de chaîne de recherche auquel elle doit correspondre. Par exemple, la chaîne de recherche correspond-elle exactement à "oranges", ou contient-elle "huile d'olive" ? La chaîne entrante est le texte de recherche de l'utilisateur reçu lors de la requête et qui doit être comparé à tous les modèles de politiques enregistrés. Ce sujet est abordé dans une vidéo PRISM connexe à 04:09.

Étape par étape : comment une recherche sur "oranges" trouve la politique correspondante

La politique

Un détaillant a créé une politique qui s'applique lorsqu'un utilisateur lance une recherche sur le mot "oranges ", sans aucun autre terme. Une fois la correspondance établie, le reste du document contient les règles que le plan de contrôle utilisera pour construire la requête Produit ; dans cet exemple, l'une des règles consiste à limiter (filtrer) les résultats à la catégorie Fruits.

Le champ percolator contient le modèle qui définit quand cette politique doit s'activer. Dans ce cas, cela correspond à l'expression "START oranges END". Les champs rule_type et rule_args définissent l'action que la politique doit effectuer en cas de déclenchement. Les jetons START et END sont des repères de délimitation, que nous expliquerons prochainement.

Vous pouvez voir comment une politique est rédigée dans l'interface utilisateur PRISM Studio à 2:52 de la vidéo PRISM associée.

L'utilisateur lance une recherche

Un acheteur tape "oranges" dans la barre de recherche.

Le plan de contrôle vérifie les politiques correspondantes avec précision

Avant de rechercher dans le catalogue de produits, le plan de contrôle intercepte la chaîne de recherche de l'utilisateur, l'encapsule dans des repères de délimitation et l'envoie au percolateur :

La chaîne "START oranges END" est comparée à tous les modèles de politique enregistrés. En interne, Elasticsearch applique ces modèles à cette chaîne et renvoie ceux qui correspondent. C'est le principe du percolateur. La chaîne de recherche de l'utilisateur a été comparée à tous les modèles de politique enregistrés, et ceux qui correspondaient ont été renvoyés. Pas de condition "il/else". Pas d'évaluation séquentielle. L'index gère la correspondance.

Le plan de contrôle applique la politique

Le plan de contrôle analyse les actions des politiques correspondantes. La politique ci-dessus indique au plan de contrôle de limiter les résultats à la catégorie Fruits. Le plan de contrôle construit la requête Elasticsearch finale sur le catalogue de produits comme suit :

L'utilisateur a cherché "oranges". Le catalogue de produits reçoit une requête pour "oranges" limitée à la catégorie Fruits. En raison de cette contrainte, le jus d'orange, la marmelade d'orange et le soda à l'orange sont exclus.

Pourquoi "marmelade d'orange" ne déclenche PAS la politique sur les oranges

Supposons qu'un autre utilisateur lance une recherche sur "marmelade à l'orange". Le plan de contrôle encadre la chaîne et filtre : "START orange marmalade END". Le modèle de politique pour les oranges est match_phrase: "START oranges END". La politique pour les oranges ne correspondant pas, elle n'est pas appliquée et les résultats ne sont pas limités à la catégorie Fruits.

Telle est la finalité des repères de délimitation START et END. Sans eux, une politique qui met en correspondance le mot "oranges" pourrait s'appliquer par erreur à une requête comme "marmelade d'oranges". En encadrant la chaîne de recherche de l'utilisateur avec START et END et en incluant ces repères dans le modèle de la politique, nous nous assurons que la politique ne s'active que lorsque "oranges" est la chaîne de recherche complète, sans autres termes. Cela correspond aux attentes des acheteurs et du détaillant.

Deuxième politique : "huile d'olive" sur le champ lexical racine

Toutes les politiques ne nécessitent pas une correspondance exacte des chaînes de caractères. La politique "huile d'olive" correspondant à un champ racinisé, elle se déclenche indépendamment des variations mineures de la forme des mots :

Le modèle de cette politique correspond à query.stemmed au lieu de query. Lorsque la chaîne de recherche de l'utilisateur arrive, elle est stockée dans un champ query (le texte exact) et dans un champ query.stemmed (analysé par un analyseur de racinisation qui réduit les mots à leur racine, "olives" et "olive" ayant la même racine, de même que "huiles" et "huile"). Le modèle de la politique est vérifié par rapport à la version racinisée de la chaîne, et s'applique donc quelles que soient les variations mineures de forme des mots.

Les repères de délimitation START et END fonctionnent également sur le champ racinisé, garantissant que cette politique ne s'active que lorsque "huile d'olive" est la chaîne de recherche complète, et non lorsqu'elle apparaît dans une partie d'un élément plus long.

La suite de cet article aborde les détails de mise en œuvre qui préparent cette solution à la mise en production : le mapping d'index prenant en charge les deux modes de correspondance, la manière dont les mises en évidence déterminent la suppression des expressions et le suivi des expressions utilisées, ainsi que la façon dont plusieurs politiques contradictoires s'intègrent dans un plan d'exécution unique.

Mapping de l'index des politiques

L'index des politiques nécessite un champ de percolation pour stocker les modèles de requêtes enregistrés et un champ texte reflétant la structure de la chaîne de recherche entrante sur laquelle le percolateur effectuera la comparaison. Le schéma ci-dessous est simplifié par souci de clarté. Un déploiement en production est plus complexe et utilise des analyseurs personnalisés pour gérer les repères de délimitation, la correspondance de modèles variables (par exemple, identifier que "moins de 4 $" contient une valeur monétaire) et d'autres types d'analyses.

L'index est nommé policies, car chaque document représente une politique gouvernée complète telle que définie dans la partie 2. Cela inclut les critères de correspondance, l'action, la priorité et les métadonnées. Les champs rule_type et rule_args contiennent la composante "action" de la politique, c'est-à-dire les instructions que le plan de contrôle utilisera pour composer la requête à exécuter sur le catalogue de produits.

Le champ query correspond à la chaîne de caractères utilisée par le percolateur pour la recherche. Il existe deux variantes : une version exacte et une version racinisée. Lorsque la chaîne de recherche de l'utilisateur est reçue, elle est placée dans ce champ de l'index temporaire en mémoire. Les politiques correspondant à query voient la chaîne exacte ; les politiques qui correspondent à query.stemmed voient la version racinisée.

Percolation par mise en évidence, filtrage et tri

Les exemples simples ci-dessus illustrent des requêtes de percolation minimales. En pratique, le plan de contrôle ajoute la mise en évidence, filtre les politiques désactivées et trie les éléments par ordre de priorité :

La configuration de mise en évidence utilise "query" comme clé de champ avec "query.stemmed" dans matched_fields. Cela indique à l'outil surligneur unifié d'Elasticsearch de renvoyer les mises en évidence sur le champ parent query, mais aussi de prendre en compte les correspondances du sous-champ query.stemmed pour déterminer les jetons à surligner. C'est ce qui permet à une politique de correspondance sur le champ racinisé de produire des séquences de mise en évidence précises sur le texte original, ce dont le plan de contrôle a besoin pour la suppression et le suivi des expressions consommées.

Le filtre enabled: true garantit que les politiques désactivées sont ignorées. Le paramètre de priorité sort garantit que les politiques prioritaires sont renvoyées en premier, afin que le plan de contrôle puisse les traiter dans le bon ordre pour les transformations en cascade. Le champ highlight est l'ajout le plus important ; il indique précisément quels mots de la chaîne de recherche de l'utilisateur ont déclenché chaque correspondance.

La réponse à une recherche "huile d'olive" peut ressembler à ce qui suit :

Pourquoi les points forts sont importants

Notez la mise en évidence dans la réponse : "<em>START olive oil END</em>". Elasticsearch nous indique précisément quels mots de la requête utilisateur ont déclenché la correspondance avec la politique. Ce n'est pas un simple détail. Les métadonnées mises en évidence influencent deux comportements essentiels en aval :

Suppression d'expressions. Certaines politiques nécessitent la suppression du texte correspondant dans la chaîne de recherche avant la construction de la requête du catalogue de produits. Par exemple, une politique qui recherche l'expression "pas cher" la supprime et la remplace par un filtre de prix. La mise en évidence indique précisément la section de la chaîne de recherche concernée par la politique, de sorte que le système sait ce qu'il faut supprimer.

Suivi des expressions consommées. Comme décrit dans la partie 3, lorsque plusieurs politiques correspondent à la même chaîne de recherche, une politique de priorité supérieure peut supprimer des mots auxquels une politique de priorité inférieure correspond également. En comparant la mise en évidence de chaque politique par rapport à la chaîne de recherche actuelle (en évolution), le système peut détecter qu'une expression a été consommée et ignorer la politique de priorité inférieure. Cela empêche le double traitement et assure un comportement déterministe.

Pour en savoir plus sur le fonctionnement de la mise en évidence, consultez cet article.

De la percolation au plan d'exécution

Le percolateur renvoie un ensemble de politiques correspondantes. Mais comme décrit dans la partie 3, la recherche n'est que la moitié du processus. L'autre moitié consiste à composer ces correspondances en un plan d'exécution cohérent. Voici à quoi cela ressemble pour une requête concrète.

Exemple concret : "Chocolat pas cher" pendant une campagne de Noël

Supposons que le système ait deux politiques actives : la politique "Chocolat bon marché" (priorité 210) et la politique "Chocolats de Noël" (priorité 300), toutes deux décrites en détail dans la partie 3.

Étape 1 : Filtrer. L'utilisateur lance une recherche sur "chocolat pas cher". Le plan de contrôle encapsule la chaîne de recherche sous la forme "START cheap chocolate END" et l'envoie au percolateur. Deux politiques correspondent : le modèle de politique "Chocolat pas cher" correspond à l'expression "chocolat pas cher", et le modèle de politique "Chocolats de Noël" correspond à "chocolat" via le champ racinisé.

Étape 2 : Trier par priorité. Le percolateur renvoie les deux politiques, triées par priorité dans l'ordre décroissant. La politique "Chocolats de Noël" (300) est traitée en premier, suivie de la politique "Chocolats pas chers" (210).

Étape 3 : Appliquer la transformation en cascade. C'est le modèle initial state → [Policy A] → state' → [Policy B] → state'' → execution plan présenté dans la partie 3.

La politique relative aux "Chocolats de Noël" (priorité 300) s'applique en premier :

• Ajoute un filtre de catégorie strict : "Aliments et boissons de Noël", "Friandises de Noël".
• Ajoute un filtre de prix : moins de 7 $.
• Ajoute un boost de catégorie "Calendriers de l'avent" (3x).

La politique relative au "Chocolat pas cher" (priorité 210) s'applique ensuite à l'état modifié :

• Tente d'ajouter un filtre strict par catégorie : "Chocolats", "Chocolats au lait", mais la politique de Noël a déjà défini ce champ sur on_conflict: override, donc les catégories "Chocolat pas cher" sont exclues.
• Tente d'ajouter un filtre de prix : 2 $, la politique de Noël est définie sur on_conflict: restrict pour le prix, et 2 $ est plus restrictif que 7 $, donc 2 $ l'emporte.
• Supprime les termes "bon marché" de la chaîne de recherche.

Étape 4 : Créer la requête Elasticsearch. Le plan de contrôle assemble le plan d'exécution en une seule requête Elasticsearch sur le catalogue de produits :

La chaîne de recherche initiale était "chocolat pas cher". La requête qui aboutit au catalogue de produits est un plan de récupération contrôlé et adapté à l'intention : les termes "pas cher" sont intégrés et convertis en contrainte de prix, les résultats sont limités aux catégories saisonnières de Noël, les produits du calendrier de l'avent sont mieux référencés et le prix plafond reflète la valeur plus restrictive de la politique de priorité inférieure. Chaque transformation est déterministe, traçable et explicable.

Pour un aperçu rapide de la façon dont ces multiplicateurs interagissent avec le score BM25 de base, consultez la vidéo PRISM associée à 8:45 où ces boosts multiplicatifs sont abordés.

Pourquoi cette échelle

Le percolateur est efficace pour ce cas d'utilisation en raison de l'asymétrie : un système e-commerce d'entreprise peut comporter des millions de produits mais seulement des centaines ou des milliers de politiques de gouvernance. Le percolateur vérifie une chaîne de recherche entrante par rapport à cet ensemble de modèles de politique stockés, et non en analysant l'intégralité du catalogue de produits. Le coût est proportionnel au nombre de politiques, et Elasticsearch applique des optimisations internes (indexation des termes à partir de schémas de requête stockés, contournant la logique booléenne) afin d'assurer une correspondance rapide.

L'ajout d'une nouvelle politique revient à indexer un nouveau document. La désactivation d'une politique équivaut à une mise à jour de champ. Aucun changement de code, aucun déploiement, aucun redémarrage.

De la recherche à la récupération contrôlée

Le percolateur fournit la primitive de correspondance inverse rapide qui rend l'architecture du plan de contrôle évoquée dans la partie 3 pratique à grande échelle. Les politiques sont des données stockées et indexées, puis comparées efficacement aux chaînes de recherche entrantes. Le plan de contrôle compose les politiques de correspondance en un plan d'exécution gouverné grâce à la transformation en cascade et à la résolution des conflits par champ décrites dans la partie 3. Enfin, le moteur de recherche exécute ce plan d'exécution gouverné sur le catalogue de produits.

Résultat : un système qui permet à un détaillant de créer une nouvelle politique sans toucher au code de l'application, de la tester par rapport à des requêtes représentatives, de la promouvoir en production et de voir immédiatement ses effets. Le percolateur accélère la recherche de politique, le plan de contrôle rend la composition de politique déterministe, et le workflow gouverné sécurise l'ensemble du processus.

À suivre dans cette série

Le prochain article de cette série étend le plan de contrôle gouverné à de nouveaux territoires. Il introduit une architecture de recherche à plusieurs niveaux, expliquant comment orchestrer une récupération stricte, souple et sémantique tout en maintenant une pagination et des facettes stables.

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

Le plan de contrôle basé sur un percolateur décrit dans cet article, depuis les mappings d'index et les repères de délimitation jusqu'au suivi des expressions clés et à la composition de politiques en cascade, a été conçu par Elastic Services Engineering dans le cadre de nos accélérateurs de recherche e-commerce reproductibles. Chaque exemple de requête et chaque structure de politique présentés ici proviennent d'un système opérationnel validé à l'aide de catalogues de produits à l'échelle de l'entreprise.

Si vous souhaitez implémenter un plan de contrôle gouverné, basé sur des politiques sur Elasticsearch, les services Elastic peuvent vous y aider plus rapidement. Contactez Elastic Professional Services.

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.