Ce dernier article pose la question suivante : qu'est-ce qui change lorsque l'entrée provient d'un agent IA ?

La réponse est que l'architecture ne change pas, mais les enjeux, oui. Toutes les propriétés du plan de contrôle gouverné qui sont importantes pour les requêtes rédigées par des humains sont encore plus importantes lorsque le décideur en amont est un grand modèle de langage (LLM). Le déterminisme, l'auditabilité, la résolution des conflits et l'application des contraintes deviennent des garde-fous critiques plutôt que des commodités opérationnelles, car le système qui produit l'entrée est par nature probabiliste.

Le problème de la recherche agentique

L'approche la plus courante de la recherche pilotée par l'IA est simple : donner au LLM le schéma de la base de données, fournir des règles métier dans le prompt et laisser l'agent générer la requête directement.

Pour un chatbot e-commerce, cela signifie injecter le mapping d'index Elasticsearch, les types de champs, les taxonomies de catégories, la logique de tarification et les contraintes métier dans la fenêtre de contexte de l'agent, puis demander au LLM de traduire le langage naturel en DSL de requêtes Elasticsearch valide. Le LLM devient ainsi l'auteur de la requête.

Cette approche fonctionne lors des démonstrations. Elle échoue en production pour quatre raisons.

Gonflement du contexte

Le mapping d'un système e-commerce d'entreprise est un document complexe. Les définitions de champs, les objets imbriqués, les configurations multichamps et les paramètres d'analyse peuvent représenter des milliers d'éléments avant même l'ajout de la logique métier. Outre ce mapping, l'agent a besoin des taxonomies de catégories (qui, dans le contexte de l'e-commerce d'entreprise, peuvent contenir des dizaines de milliers de valeurs), des règles de tarification, des hiérarchies de marques, des critères d'éligibilité et de la logique de campagne.

Le résultat est une fenêtre de contexte dominée par les métadonnées structurelles plutôt que par l'intention réelle de l'utilisateur. Cela augmente la latence, augmente le coût des tokens et dégrade la capacité du LLM à suivre les instructions à mesure que le contexte s'agrandit. Il s'agit d'un phénomène bien documenté, parfois appelé pourriture contextuelle : à mesure que le prompt s'allonge, l'attention portée par le modèle à une instruction particulière diminue.

Hallucination probabiliste

Les LLM génèrent des requêtes à partir de schémas présents dans leurs données d'entraînement et du contexte fourni. Lorsqu'on leur demande de produire du DSL de requêtes Elasticsearch, le modèle peut halluciner des noms de champs inexistants, construire des clauses de requête syntaxiquement invalides, appliquer incorrectement des types de filtres à des types de champs inappropriés, ou produire des requêtes syntaxiquement valides mais sémantiquement incorrectes, renvoyant des résultats qui ne correspondent pas à l'intention de l'utilisateur.

Le benchmark BIRD de conversion texte vers SQL de Google Cloud illustre les limites de cette approche. Le résultat de pointe de Google, basé sur un modèle unique, a atteint une précision de 70 à 80 %, c'est-à-dire que près d'une requête générée sur quatre était incorrecte. Ce résultat concerne le SQL, bien plus standardisé que le DSL de requêtes Elasticsearch. Le taux d'erreur des requêtes Elasticsearch générées par LLM dans un environnement de production réel, avec des mappings complexes et une sémantique spécifique au métier, serait probablement plus élevé.

Pour un système e-commerce critique en termes de revenus, un taux d'erreur de requête sur quatre n'est pas un problème de réglage à résoudre de façon itérative. C'est une limite architecturale de l'approche.

La faille de sécurité

Lorsque le LLM a accès au schéma de la base de données et agit en tant qu'auteur de la requête, le système est vulnérable à l'injection indirecte de prompts. Un utilisateur qui interagit avec un chatbot e-commerce peut créer des entrées conçues pour inciter l'agent à générer des requêtes involontaires.

Ce n'est pas un risque théorique. L'injection de prompts est l'une des surfaces d'attaque les plus activement étudiées dans les systèmes LLM déployés. Le problème fondamental est que lorsque l'agent rédige la requête, il n'y a pas de limite structurelle entre l'intention de l'utilisateur et l'exécution de la requête. Le LLM interprète simultanément la demande de l'utilisateur et construit l'opération de base de données. Toute manipulation du premier élément affecte directement le second.

Échec du scaling à haute cardinalité

Certains champs e-commerce présentent une cardinalité extrême. Un catalogue de produits peut comporter 17 000 valeurs de catégorie, des milliers de noms de marques et des centaines de combinaisons d'attributs. Les workflows agentiques standard nécessitent l'injection de ces valeurs dans le contexte afin que le LLM puisse sélectionner la valeur correcte lors de la construction d'une requête.

Cela crée un compromis impossible : soit injecter toutes les valeurs possibles (consommant un contexte énorme et dégradant les performances), injecter un sous-ensemble (et accepter que l'agent ne puisse pas référencer des valeurs en dehors de ce sous-ensemble), ou revenir à une recherche non gouvernée. Ceci est directement lié au problème central abordé dans la partie 1 : si le LLM recherche "oranges" et qu'Elasticsearch renvoie des sodas à l'orange, l'expérience du chat se dégrade de la même manière que l'expérience de la recherche. L'absence de gouvernance signifie que le système ne peut pas appliquer la résolution prévue par l'acheteur.

La récupération dynamique de valeurs pertinentes en fonction de la requête est une alternative connue, mais elle introduit une étape supplémentaire non déterministe où la récupération elle-même peut passer à côté de valeurs pertinentes. De plus, cela ajoute de la latence et de la complexité à chaque requête.

L'alternative architecturale : dissocier l'intention de l'exécution

Le plan de contrôle gouverné décrit dans les parties 1 à 7 offre une approche fondamentalement différente. Au lieu que le LLM soit l'auteur de la requête finale, son rôle est réduit à une seule tâche bien délimitée : extraire une chaîne d'intention de recherche à partir de l'entrée en langage naturel de l'utilisateur.

L'utilisateur indique : "Je cherche des chaussures marron bon marché." Le rôle de l'agent n'est pas de générer une requête Elasticsearch, mais d'extraire et de transmettre l'intention de recherche (dans ce cas, quelque chose comme "chaussures marron bon marché") au plan de contrôle. Le plan de contrôle suit alors sa procédure habituelle : il filtre la chaîne d'intention par rapport aux politiques stockées, compose les politiques correspondantes par le biais de transformations en cascade, résout les conflits de manière déterministe et produit une requête Elasticsearch gouvernée.

Le LLM ne voit jamais le mapping des index. Il ne connaît jamais les types de champs, les taxonomies de catégories ou les seuils de tarification. Il ne crée jamais de clause de requête. Il agit du côté du langage naturel d'une frontière architecturale que nous appelons isolation des métadonnées (metadata air gap), une séparation stricte entre la composante probabiliste (le LLM) et la couche de données structurées (schéma, politiques et construction de requêtes).

Ce que l'espace isolé des métadonnées fournit

• Insensibilité au schéma. Le LLM n'a pas accès au schéma de la base de données et ne peut donc pas générer de requêtes invalides, halluciner les noms de champs ni être manipulé pour révéler des informations structurelles. Le schéma existe uniquement du côté déterministe de la séparation physique.

• Contexte minimal. Au lieu de milliers de tokens de données de mapping, de règles métier et de taxonomies de catégories, le prompt du LLM ne contient qu'une persona et des instructions d'extraction d'intent. Cela réduit considérablement le coût des tokens, la latence et la dégradation du contexte.

• Exécution déterministe. Chaque requête qui parvient à Elasticsearch est créée par le plan de contrôle à l'aide de modèles de règles validées par des humains, et non générés de manière probabiliste par un LLM. La validité syntaxique est garantie. La correction sémantique est garantie par le même framework de politiques que celui décrit dans les parties 1 à 6.

• Sécurité par architecture. L'injection de prompt devient structurellement inefficace. Même si un utilisateur manipule l'agent pour produire une chaîne d'intention inhabituelle, cette chaîne est filtrée par rapport aux politiques stockées. Si aucune politique ne correspond, aucune requête n'est générée. L'utilisateur ne peut pas demander à l'agent de construire une requête, car l'agent ne construit pas de requêtes. Le plan de contrôle le fait, et le plan de contrôle est déterministe.

Comment les pièces s'assemblent

La procédure suivante explique comment le plan de contrôle gouverné traite une requête transmise par un agent.

Étape 1 : L'utilisateur parle à l'agent

Un client interagissant avec un chatbot e-commerce déclare : "Je cherche du chocolat pas cher, sans arachide."

Étape 2 : L'agent extrait l'intention

Le rôle du LLM est d'extraire les intentions, et non de générer des requêtes. À partir d'un simple prompt lui demandant d'identifier l'intention de la recherche du produit, l'agent produit une chaîne de caractères : "chocolat bon marché sans arachide".

Il s'agit d'une tâche de classement simple. Le LLM n'a pas besoin du mapping d'index, de la taxonomie par catégories ou des règles de tarification pour la réaliser. Il doit comprendre le langage naturel, et c'est exactement ce que font les LLM.

Étape 3 : Le plan de contrôle gère la requête

La chaîne d'intention "chocolat bon marché sans arachide" est transmise au plan de contrôle, qui la compare à l'index des politiques. Trois politiques correspondent :

• La politique "bon marché" (extrait "bon marché", applique un filtre de prix basé sur la catégorie de produit).

• La politique "chocolat" (limite les résultats aux catégories de chocolat).

• La politique de négation "sans" (extrait la cible d'exclusion et applique un filtre must_not)

Le plan de contrôle applique ces politiques par le biais de la même transformation en cascade décrite dans la partie 3 et 4 : ordre de priorité, résolution des conflits par champ, suivi des expressions consommées. Si une politique "campagne de Noël" est également active, elle se combine avec les politiques de produits exactement comme décrit dans la partie 3 ; l'implication de l'agent ne change absolument rien au modèle de gouvernance.

Étape 4 : La requête gouvernée s'exécute

Le plan de contrôle produit une requête Elasticsearch entièrement gouvernée : une recherche sur "chocolat", limitée aux catégories appropriées, avec un prix plafond dérivé de la politique "bon marché", un filtre d'exclusion pour les produits contenant de l'arachide et toutes les améliorations de campagne actives appliquées. Si la politique "chocolat" comprend également des pondérations d'optimisation économique (Partie 7), celles-ci sont également appliquées. La valeur du boosting de marge est fixée à 3x, car "chocolat" est une requête de navigation où le détaillant bénéficie de la promotion de produits à marge plus élevée. Si l'acheteur a un historique d'achat(Partie 6), les signaux de personnalisation sont superposés. Cette requête est syntaxiquement valide par construction et sémantiquement correcte par conception de la politique.

Étape 5 : Les résultats sont renvoyés par l'intermédiaire de l'agent

Les résultats des produits sont renvoyés à l'agent, qui les présente à l'utilisateur sous forme de conversation. Le rôle de l'agent dans le chemin de retour est la présentation : mettre en forme les résultats, répondre aux questions de suivi, fournir des détails sur les produits. La récupération elle-même était gouvernée, déterministe et explicable.

Ce que l'agent sait faire (et ce qu'il ne sait pas faire)

Cette architecture tire parti des points forts du LLM et protège le système de ses points faibles.

Les LLM excellent dans la compréhension de l'intention en langage naturel. "Je cherche du chocolat pas cher, sans arachide" est une tâche de compréhension du langage naturel qui consiste à analyser l'intention, identifier les références aux produits et reconnaître la négation. Les LLM gèrent cela efficacement, car il s'agit d'un problème de classification, et non de génération. Le résultat est une courte chaîne de caractères exprimant l'intention, et non une requête structurée complexe.

Les LLM peinent à produire des résultats structurés et précis sous des contraintes complexes. Générer du DSL de requêtes Elasticsearch valide exige des noms de champs exacts, une imbrication correcte des clauses, des types de filtres appropriés pour chaque champ et une application cohérente des règles métier à travers des milliers de cas particuliers. Ce sont précisément les propriétés qu'un système déterministe garantit sans difficulté, contrairement à un système probabiliste.

Le plan de contrôle gouverné place chaque composant à sa place : le LLM côté langage naturel, le moteur de politique déterministe côté construction de requêtes, et une frontière architecturale entre eux.

La gouvernance limite le rayon d'action

C'est la même idée que dans la partie 3, étendue au contexte agentique. Dans la partie 3, nous avons observé que la gouvernance rend la recherche sémantique plus sûre en réduisant le nombre de candidats avant le début de la recherche. Une recherche sémantique sur plus de 500 produits dans une catégorie gouvernée est fondamentalement différente d'une recherche sémantique sur plus de 500 000 références.

Le même principe s'applique aux requêtes effectuées par l'intermédiaire d'un agent. Sans gouvernance, un agent qui interprète mal l'expression "chocolat bon marché" pourrait générer une requête qui parcourt l'ensemble du catalogue sans contrainte de prix, sans filtre de catégorie, sans exclusions. Avec la gouvernance, même si l'agent produit une chaîne d'intention imparfaite, le plan de contrôle limite la requête aux politiques qui correspondent. Le pire scénario est la réduction du nombre de politiques déclenchées, et non l'exécution d'une requête illimitée sur le catalogue de produits.

La gouvernance réduit le rayon d'action des erreurs probabilistes. Cela reste vrai, que le composant probabiliste soit un modèle de récupération sémantique ou un agent LLM.

Politiques suggérées par LLM : élargissement de la couverture

La partie 2 a introduit l'idée qu'un LLM peut suggérer de nouvelles politiques qui entrent dans le même pipeline Auteur → Test → Promotion que les politiques rédigées par des humains. Dans le contexte agentique, cela devient une puissante boucle de feedback.

Un LLM peut analyser les logs de requêtes, identifier les modèles où le plan de contrôle n'a pas de politique correspondante (requêtes qui aboutissent à une récupération sans modification) et suggérer de nouvelles politiques pour combler ces lacunes. Un responsable merchandising examine chaque suggestion, la teste et la déploie si elle produit le comportement attendu. Le modèle de gouvernance garantit qu'aucune politique suggérée par le LLM n'est mise en production sans validation humaine.

Au fil du temps, cela crée un cercle vertueux : la couverture des politiques du plan de contrôle s'étend, la proportion de requêtes nécessitant une récupération non modifiée diminue et le système devient progressivement plus régulé, chaque politique étant auditable, versionnée et réversible individuellement.

Le schéma le plus large : garde-fous déterministes pour les systèmes probabilistes

L'architecture décrite dans cette série, un plan de contrôle déterministe qui se situe entre une source d'entrée probabiliste et un système de recherche de données, n'est pas spécifique à la recherche e-commerce. Le même schéma s'applique partout où un agent IA doit interagir avec des données structurées.

Un agent interrogeant une base de données SQL fait face aux mêmes défis : gonflement du contexte dû à l'injection de schéma, noms de colonnes hallucinés, risques d'injection de prompt et sélection de valeurs à haute cardinalité. Un agent interagissant avec un système de billetterie comme Jira, un système de gestion de la relation client (CRM) comme Salesforce ou un dépôt de code comme GitHub est confronté à des problèmes analogues. Dans tous les cas, la question architecturale centrale est la même : le LLM doit-il rédiger la requête, ou doit-il extraire l'intention et la transmettre à une couche déterministe qui rédige la requête ?

Le plan de contrôle gouverné fournit une réponse répétable à cette question. Les politiques sont des données. L'extraction de l'intention est le travail du LLM. La construction de requêtes est le travail du plan de contrôle. L'espace entre les métadonnées permet de les séparer. Et le framework de gouvernance (ordre des priorités, résolution des conflits, transformations en cascade, auditabilité) garantit que la couche déterministe est gérable opérationnellement à mesure que le nombre de politiques augmente.

Conclusion

Les modèles de gouvernance de la recherche e-commerce décrits dans cette série (politiques en tant que données, workflow Auteur → Test → Promotion, transformations en cascade, résolution des conflits par champ, correspondance inversée basée sur un percolateur et repli multiniveau) ont été conçus pour un monde où un responsable merchandising rédige des politiques et un client saisit des requêtes. Mais cette architecture offre bien plus de possibilités que son cas d'utilisation initial.

Lorsque la source d'entrée est un agent IA plutôt qu'un consommateur humain, le plan de contrôle gouverné devient la couche de sécurité critique entre un système probabiliste et un système de stockage de données de production. Il fournit les garanties déterministes (validité syntaxique, exactitude sémantique, auditabilité et sécurité) requises par les systèmes d'entreprise que les LLM ne peuvent assurer seuls.

Le plan de contrôle déterministe ne remplace pas l'agent IA. Il permet simplement de déployer l'agent IA en toute sécurité.

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

L'architecture de plan de contrôle gouverné décrite dans cette série, depuis le paradigme des politiques en tant que données jusqu'à la recherche par percolateur, en passant par la personnalisation, l'optimisation économique et l'isolation des agents, a été conçue et réalisée par Elastic Services Engineering. Chaque modèle présenté dans cette série provient d'un système opérationnel construit et validé à l'aide de catalogues de produits à l'échelle de l'entreprise.

Si votre équipe développe des expériences de recherche optimisées par l'IA et a besoin de garde-fous déterministes pour les requêtes gérées par des agents, ou si vous souhaitez implémenter une architecture de recherche gouvernée et modifiable par l'entreprise sur Elasticsearch, les services professionnels d'Elastic peuvent accélérer votre mise en œuvre. 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.

Cet article présente deux mécanismes de personnalisation qui étendent le plan de contrôle gouverné sans en modifier l’architecture. Les deux mécanismes s’ajoutent de manière cumulative à la couche de gouvernance présentée dans les parties 1 à 5 : les politiques continuent de s’appliquer, les contraintes restent respectées, les conflits sont toujours résolus, et les signaux de personnalisation sont intégrés à la même requête gouvernée, garantissant ainsi que les résultats renvoyés par Elasticsearch sont déjà personnalisés.

Le premier mécanisme met en avant les produits déjà achetés par le client concerné. Le second active des politiques spécifiques à certaines cohortes selon le profil du client. Ensemble, ils montrent que la personnalisation n’est pas un système distinct ajouté à la recherche ni un traitement appliqué après récupération des résultats ; elle constitue une extension naturelle du plan de contrôle piloté par des politiques.

Pour une analyse approfondie des techniques mathématiques de personnalisation utilisées dans cet article, consultez les articles Personnaliser la recherche dans Elasticsearch avec un post-traitement ML et Classement basé sur les cohortes dans Elasticsearch.

Pour voir une démonstration en direct montrant comment l’historique d’achat peut être utilisé pour booster les résultats de recherche des clients fidèles, regardez la vidéo Personnalisation explicable : booster la recherche grâce à l’historique d’achat.

Amélioration de l'historique des achats individuels

La forme la plus simple de personnalisation est aussi l’une des plus efficaces : lorsqu’un client a déjà acheté un produit, mettez-le en avant lorsqu’il effectue une recherche associée. Un client qui achète régulièrement une marque précise de cookies aux pépites de chocolat devrait voir ces produits apparaître plus haut dans les résultats lorsqu’il recherche « cookies », non pas parce qu’un modèle a prédit une préférence, mais parce qu’il existe des preuves comportementales directes.

Fonctionnement

Lorsqu’une requête de recherche inclut un identifiant utilisateur, comme c’est le cas pour un utilisateur disposant d’une session ouverte, le plan de contrôle exécute deux requêtes Elasticsearch en parallèle à l’aide d’un pool de threads :

1. La requête percolator exécutée sur l’index des politiques (la même recherche de gouvernance décrite dans les parties 3 et 4).

2. Une requête sur l'historique des achats dans un index user_purchases, filtrée sur l'utilisateur spécifique par term(user_id), puis faisant correspondre la chaîne de recherche actuelle avec les titres des produits de cet utilisateur.

Ces requêtes s’exécutent simultanément (aucune n’attend l’autre), de sorte que la recherche de personnalisation n’ajoute aucune latence significative au pipeline de gouvernance.

La requête sur l’historique d’achat utilise l’analyse de texte d’Elasticsearch (racinisation, tokenisation) pour faire correspondre la chaîne de recherche actuelle aux titres de produits enregistrés. Cela signifie qu’une recherche sur « cookies » correspondra à un achat passé de « brownie cookies » grâce à l’analyse de texte standard, sans nécessiter de correspondance exacte de chaîne.

Calcul des pondérations de boost

Tous les achats passés ne méritent pas le même niveau de boost. La pondération prend en compte deux facteurs intuitifs : la fréquence d’achat du produit par le client et la date récente de cet achat. Un produit acheté 15 fois la semaine dernière constitue un signal bien plus fort qu’un produit acheté une seule fois il y a six mois. La pondération utilise une échelle logarithmique pour la fréquence (afin qu’un seul produit acheté en grande quantité ne domine pas tous les autres) et une décroissance exponentielle pour la récence (afin que les achats plus anciens perdent naturellement en importance au fil du temps).

Pour les détails mathématiques de la formule de boost, consultez l’article Personnaliser la recherche dans Elasticsearch sans post-traitement ML.

Transformation en requête

Les boosts liés à l’historique d’achat sont intégrés à la requête comme couche de scoring la plus externe, englobant les filtres et boosts des politiques de gouvernance décrits dans les parties 3 et 4, ainsi que tous les boosts liés aux signaux métier, tels que la marge et la popularité (que nous explorerons dans la partie 7). Cela signifie qu’un produit supprimé par une politique de gouvernance ne réapparaîtra pas à cause d’un boost lié à l’historique d’achat. La gouvernance contrôle l’ensemble de résultats ; la personnalisation ajuste l’ordre des résultats au sein de celui-ci. Les produits sans historique d’achat ne sont pas pénalisés. Leur classement gouverné est préservé, même si les produits disposant d’un historique d’achat pertinent apparaîtront avant eux, toutes choses étant égales par ailleurs.

Pourquoi interroger Elasticsearch à chaque recherche ?

L’historique d’achat est interrogé dans Elasticsearch à chaque recherche plutôt que mis en cache dans la couche applicative. Il s’agit d’un choix de conception délibéré. Comme la requête compare la chaîne de recherche actuelle aux titres des produits à l’aide du pipeline d’analyse de texte d’Elasticsearch, le système bénéficie des mêmes mécanismes de racinisation, de tokenisation et de gestion linguistique que ceux utilisés par la recherche produit elle-même. Une recherche en mémoire mise en cache nécessiterait de réimplémenter cette analyse ou d’accepter une correspondance moins précise.

Pour comprendre pourquoi cet ordre est important, prenons l’exemple d’un client qui a déjà acheté du jus d’orange et recherche maintenant « oranges ». La requête sur l’historique d’achat associe « jus d’orange » au terme de recherche « oranges » grâce à l’analyse de texte et calcule un boost pour ce produit. Mais la couche de gouvernance a déjà limité « oranges » à la catégorie des produits frais, excluant ainsi totalement le jus d’orange. Le boost lié à l’historique d’achat pour le jus d’orange est bien présent dans la requête, mais il n’a aucun effet, car aucun document correspondant n’existe dans l’ensemble de résultats gouverné sur lequel il pourrait s’appliquer. Le client voit des oranges fraîches classées selon leur pertinence et les critères de personnalisation. Les garde-fous de gouvernance restent en place.

Le coût en performances reste minimal : l’index de l’historique d’achat est de petite taille (l’historique d’un utilisateur contient généralement quelques dizaines à quelques centaines de documents, et non des millions), et la requête s’exécute en parallèle de la recherche percolator ; elle n’allonge donc pas le chemin critique.

Exemple de requête pour « eau de source » sans historique utilisateur

Si un utilisateur non connecté, ou un utilisateur n’ayant jamais acheté d’« eau de source », effectue une recherche, il pourra voir des résultats similaires à ceux-ci :

Exemple d’historique d’achat utilisateur

À l’inverse, une utilisatrice nommée Carol dispose d’un historique d’achat contenant les produits suivants :

Exemple de recherche pour « eau de source » avec l’historique d’achat ci-dessus

Si Carol recherche « eau de source », elle verra des résultats personnalisés qui reflètent ses achats passés. D’après l’historique d’achat ci-dessus, elle a acheté « Carbonated Spring Water » (la bouteille verte) environ 40 fois, le plus récemment il y a deux jours. Si elle recherche « eau de source », ce produit bénéficie alors d’un boost, puisque nous savons qu’elle l’apprécie. Notez que dans les résultats non personnalisés, l’eau de source Rubicon apparaissait en première position.

Activation des politiques basées sur les cohortes

L’historique d’achat individuel fonctionne bien pour les clients fidèles dont les habitudes sont déjà établies. Mais de nombreux clients sont nouveaux, anonymes ou naviguent en dehors de leurs habitudes habituelles. Pour ces clients, l’appartenance à une cohorte offre une autre forme de personnalisation, fondée sur le profil du client plutôt que sur ses actions passées.

Un client vegan recherchant « chocolat » devrait voir les chocolats vegans apparaître plus haut dans les résultats. Un client respectant les règles halal et recherchant « snacks » devrait voir les options certifiées halal mises en avant. Un client soucieux de sa santé recherchant « yaourt » devrait voir les options probiotiques bénéficier d’un boost.

Les cohortes comme politiques, et non comme étiquettes produit

Les produits possèdent déjà leurs attributs habituels, y compris des champs tels que dietary_restrictions: ["vegan"] ou dietary_restrictions: ["halal"]. La question est de savoir où réside la logique qui relie la cohorte d'un acheteur à ces attributs de produit.

L’approche naïve serait de coder cette mapping en dur dans la couche application ou dans le modèle de recherche : si l’utilisateur est vegan, ajoutez un bonus à dietary_restrictions: "vegan". Mais c’est le même spaghetti de couche application décrit dans la Partie 1, et cela crée la même friction opérationnelle : ajouter une nouvelle cohorte ou modifier la signification d’une cohorte nécessite un changement de code.

Le plan de contrôle gouverné conserve la logique de cohorte dans le moteur de politiques. Une politique de cohorte fait le lien entre deux éléments : l'appartenance d'un client à une cohorte (par exemple, « végétalien ») et un attribut de produit (par exemple, dietary_restrictions: “vegan”). La politique définit le lien : lorsqu’un client de la cohorte végane recherche, privilégiez les produits où dietary_restrictions inclut « végan ».

Comme la logique des cohortes réside dans le moteur des politiques plutôt que dans le code de l'application, cela signifie :

• L’ajout d’une nouvelle cohorte peut se faire en créant une nouvelle politique ; aucune réindexation des produits n’est nécessaire.

• Les politiques de cohorte utilisent l’intégralité du moteur de règles : elles peuvent ajouter des filtres, appliquer des boosts souples, étendre les synonymes, modifier la stratégie de récupération ou effectuer toute autre action prise en charge par une politique.

• Le comportement des cohortes est géré via la même interface utilisateur d'administration que toutes les autres politiques : un marchand peut créer, tester et promouvoir des politiques de cohorte via le workflow Auteur → Test → Promouvoir décrit dans la deuxième partie.

Exemple de politique de cohorte vegan

Un responsable merchandising crée une politique de cohorte présentant les caractéristiques suivantes :

• Cohortes : ["vegan"].

• Critères de correspondance : correspond à n'importe quelle requête (ou à une catégorie de produit spécifique).

Action : Accélération douce sur dietary_restrictions: "vegan" avec un poids d'accélération de 2.

Comment fonctionne l'activation des cohortes

Chaque document de politique comporte un champ cohorts. Les politiques universelles qui s'appliquent à tous les acheteurs, quelle que soit leur cohorte, peuvent laisser ce champ vide, et une valeur de "_all" leur sera attribuée en interne par le plan de contrôle. Les politiques spécifiques à chaque cohorte stockent les noms de leurs cohortes cibles, comme ["vegan", "kosher", “sweet_tooth”].

Lorsqu’une requête de recherche inclut un profil utilisateur, le plan de contrôle construit un filtre terms simple pour la requête du percolateur :

Ce filtre unique inclut toutes les politiques universelles ainsi que les politiques spécifiques à chaque cohorte de l’utilisateur. La sentinelle _all en fait un filtre d'inclusion propre : Aucune requête must_not ou exists n'est nécessaire pour traiter le cas où une politique n'a pas de restriction de cohorte.

Le percolator évalue ensuite les correspondances de politiques comme d’habitude. La seule différence est que l’ensemble des politiques candidates a été restreint à celles pertinentes pour les cohortes de ce client. Tous les traitements en aval (transformations en cascade, résolution des conflits champ par champ, suivi des expressions consommées) fonctionnent exactement comme dans le flux non personnalisé décrit dans les parties 3 et 4.

Résultats d’un utilisateur non vegan (standard) lors d’une recherche sur « chocolat »

Lorsqu’un utilisateur non vegan recherche du chocolat, aucun boost lié à une cohorte vegan n’est appliqué à ses résultats. Ils verront souvent des chocolats non vegans parmi les premiers résultats, comme ci-dessous :

Résultats de la politique de cohorte vegan lors d’une recherche sur « chocolat »

Lorsqu'un client végétalien recherche « chocolat », cette politique est incluse dans l'ensemble des candidats au percolateur. Il correspond, et le plan de contrôle applique un boost doux aux chocolats certifiés végétaliens. Le boost est multiplicatif : les chocolats végétaliens sont mieux classés, mais les chocolats non végétaliens ne sont pas totalement exclus, car le filtre ci-dessus est défini comme un soft boost, comme nous l'avons décrit en détail dans la troisième partie de cette série.

Cependant, si le client recherche explicitement « Hershey milk chocolate », le boost vegan s’applique toujours, mais peut être compensé par la pertinence textuelle plus forte des produits Hershey au chocolat au lait.

Un client n’appartenant pas à la cohorte vegan et effectuant la même recherche ne voit jamais la politique « cohorte vegan » ; elle ne fait pas partie de son ensemble de politiques candidates. La couche de gouvernance reste identique ; seul l’ensemble des politiques actives diffère.

Cohortes avec historique d’achat

Un client vegan disposant d’un historique d’achat important bénéficie à la fois de l’activation des politiques spécifiques à la cohorte vegan et des boosts liés à son historique d’achat. Pour les nouveaux clients ou les utilisateurs anonymes, l’appartenance implicite à une cohorte suffit à offrir une personnalisation pertinente sans nécessiter de données comportementales (par exemple, un utilisateur anonyme n’a peut-être recherché que des produits vegans, et nous le classons donc comme membre de la cohorte vegan). Un client qui indique respecter les règles halal lors de la création de son compte reçoit immédiatement des résultats adaptés au halal dès sa première recherche.

Composition des couches de personnalisation

L'ordre d'imbrication des couches function_score est important. De l'intérieur vers l'extérieur :

1. Requête de base : la correspondance par mots-clés ou sémantique avec les requêtes nommées (fulltext_match, title_phrase_match).

2. Couche de politique de gouvernance : Filtres durs sous forme de clauses bool.filter, coups de pouce doux sous forme de fonctions function_score (parties 3 et 4).

3. Stimulation des signaux d'affaires : L'augmentation des marges et de la popularité (que nous étudierons dans la partie 7).

4. L'historique des achats stimule : La couche externe function_score.

Cet ordre garantit que la gouvernance contrôle l’ensemble de résultats (ce qui apparaît), que les signaux métier ajustent le classement au sein de cet ensemble (ce qui apparaît en premier du point de vue du distributeur) et que l’historique d’achat affine encore davantage le classement selon le comportement individuel (ce qui apparaît en premier du point de vue du client). Chaque couche s’ajoute à la précédente de manière multiplicative, de sorte que les effets se cumulent plutôt qu’ils n’entrent en conflit.

Ce que cela signifie sur le plan opérationnel

La personnalisation via le plan de contrôle gouverné préserve toutes les propriétés opérationnelles décrites dans les parties 1 et 2 :

• Modifications sans déploiement. Les politiques de cohorte sont créées, testées et promues via l'interface utilisateur. L'ajout d'une nouvelle cohorte alimentaire ou l'ajustement d'un poids d'appoint ne nécessite aucune modification du code et aucune intervention technique.

• Auditabilité. Chaque politique de cohorte est un document distinct et versionné. Lorsqu’un responsable merchandising demande : « Pourquoi les produits vegans sont-ils mieux classés pour cet utilisateur ? », la réponse réside dans une politique précise dotée d’une priorité spécifique, visible dans le panneau de débogage aux côtés de toutes les autres politiques déclenchées pour cette requête.

• Résolution de conflits. Les politiques de cohorte participent au même mécanisme de résolution des conflits champ par champ décrit dans la partie 3. Si le boost de catégorie d’une politique de cohorte entre en conflit avec la surcharge de catégorie d’une politique de campagne, le conflit est résolu de manière déterministe à l’aide du même cadre de priorités et de stratégies, sans traitement spécifique supplémentaire.

• Mesurabilité. Comme les politiques de cohorte sont distinctes et activables individuellement, leur impact sur les taux de conversion, de clic et d’ajout au panier peut être mesuré indépendamment, comme pour toute autre politique du système.

À suivre dans cette série

Le prochain article explore une autre dimension du plan de contrôle gouverné : la manière dont les boosts liés à la marge et à la popularité peuvent être ajustés requête par requête via des politiques, transformant ainsi l’optimisation économique en décision de gouvernance plutôt qu’en configuration statique.

Voir la partie 7 : Optimisation économique gouvernée par les requêtes : boosts de marge et de popularité par requête

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

Les mécanismes de personnalisation décrits dans cet article (boost basé sur l’historique d’achat individuel et activation de politiques adaptées aux cohortes) ont été conçus et développés par Elastic Services Engineering dans le cadre de notre accélérateur reproductible de recherche e-commerce. Les deux mécanismes s’intègrent à l’architecture de plan de contrôle gouverné décrite tout au long de cette série. 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.

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.

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 :

Type de champ

Stratégies disponibles

Par défaut

Champs de négation (__not, __match__not)

remplacer, fusionner

override

Champs numériques (__max, __min, __gt, __lt)

restrict, override, soft_boost

restrict

Tous les autres champs (mot-clé, texte)

soft_boost, override, merge

soft_boost

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.

La recherche lexicale (mise en correspondance de textes), la recherche sémantique (mise en correspondance de concepts) et la recherche hybride (combinaison de signaux lexicaux et sémantiques) ne résolvent pas ces problèmes à elles seules. La recherche lexicale peut renvoyer n’importe quel résultat contenant le mot « oranges », tandis qu’une recherche purement sémantique sur une requête à forte intention comme « oranges » peut s’élargir à des articles connexes, tels que des citrons ou des pamplemousses. La récupération hybride mélange ces signaux lexicaux et sémantiques, mais elle ne permet toujours pas de déterminer si cette requête doit être traitée comme navigationnelle, quelles contraintes doivent être imposées ou quelles politiques commerciales doivent s’appliquer. Le problème n’est pas lié à l’outil de récupération en soi, mais plutôt au manque d’un palier de gouvernance qui identifierait le type de requête et les restrictions à imposer en amont du processus de recherche.

Cet article se penche sur la gouvernance des moteurs de recherche e-commerce, les enjeux qu’elle représente et comment une couche de contrôle assure un « retrieval » fiable et pertinent.

Que signifie la gouvernance dans la recherche sur les sites e-commerce ?

Dans ce contexte, la gouvernance signifie l’introduction d’une couche de décision entre la requête de l’utilisateur et le moteur de recherche. Cette couche remplit les fonctions suivantes :

• Classifie l’intention de la requête : s’agit-il de navigation (« oranges ») ou de découverte (« cadeau pour grand-père ») ?

• Applique des contraintes commerciales : quelles limites de catégorie, règles d'éligibilité, contraintes de disponibilité ou politiques de merchandising s'appliquent ?

• Oriente vers la stratégie appropriée : faut-il utiliser la récupération lexicale, la récupération sémantique ou une approche hybride ?

Une couche de gouvernance détermine l’approche de récupération à utiliser pour chaque requête, les contraintes à respecter et les politiques commerciales à appliquer avant que la recherche ne commence. Il est important de ne pas confondre la gouvernance avec la récupération hybride : la recherche hybride est une stratégie de récupération qui combine des signaux lexicaux et sémantiques, tandis que la gouvernance est la couche de décision en amont qui détermine s’il convient d’utiliser une approche lexicale, sémantique ou hybride.

Le statu quo : l’implémentation « spaghetti » de la couche application

Aujourd’hui, la solution retenue par de nombreux distributeurs consiste à injecter de la logique métier directement au niveau de l’application. Cette approche mène souvent à un code spaghetti : des milliers de lignes mêlant structures conditionnelles rigides, expressions régulières et modèles de recherche alambiqués.

Cette approche peut fournir les résultats de recherche souhaités, comme indiqué ci-dessus, mais elle crée des frictions opérationnelles importantes :

• Contraintes liées à l’ingénierie : sans tickets de développement et sans cycles de déploiement prolongés (souvent de plusieurs semaines), les responsables métier ne disposent d’aucun levier pour faire évoluer le comportement de recherche.

• Fragmentation : la logique de recherche se retrouve éparpillée entre le code applicatif et les modèles de recherche, ce qui la rend difficile à expliquer ou à auditer, et rend toute évolution risquée.

Même lorsque les équipes reconnaissent la nécessité du routage, le débat se concentre souvent sur la mauvaise question : quelle méthode de récupération choisir.

Le faux choix : lexical ou sémantique ou hybride

Les équipes de recherche présentent souvent le défi comme un choix de stratégie de récupération : lexicale/BM25 versus sémantique/vecteurs versus hybride. Cette approche est compréhensible (les méthodes de récupération sont importantes), mais elle passe à côté du mode d'échec le plus courant dans les déploiements réels, à savoir qu'utiliser une seule approche de récupération pour toutes les requêtes donnera des résultats sous-optimaux.

La recherche commerciale est un mélange d'intentions fondamentalement différentes :

• Recherche de navigation déterministe, intention marquée (ex. : « oranges », « lait », « chocolat sans arachides », « huile d’olive à petit prix »).

• Découverte exploratoire (« blouson pour la randonnée en montagne », « cadeau pour un enfant de 12 ans qui aime la robotique »).

• Contraintes opérationnelles (disponibilité, taille, prix, couleur).

• Merchandising et campagnes (Boost, Bury, campagnes saisonnières).

Lorsque le système achemine tout cela via la même stratégie de récupération, les résultats sont souvent systématiquement erronés de manière prévisible, car le modèle opérationnel manque de gouvernance. Lorsque les équipes ne reconnaissent pas cela comme une lacune de gouvernance, elles réagissent avec le seul levier dont elles disposent : davantage de réglages.

Pourquoi le réglage de la pertinence peut devenir cyclique

Sans couche de routage, la « pertinence » se transforme souvent en un carnet de commandes interminable :

• Pourquoi cette requête affiche-t-elle les accessoires au-dessus du produit principal ?

• Pourquoi cette requête phare affiche-t-elle tout à coup des produits apparentés plutôt que des correspondances exactes ?

• Pourquoi les résultats ont-ils changé après l’ajout de synonymes, l’ajustement des analyseurs ou l’activation du mode hybride ?

• Pourquoi l'équipe métier a-t-elle besoin d'une version d'ingénierie pour corriger une seule requête ?

En réponse, les équipes intensifient les ajustements : ajout de synonymes, hausse des pondérations, nouveaux essais de réordonnancement et prolifération de cas particuliers dans le code de l’application. Cela peut donner des résultats temporaires, toutefois la solution reste instable : sans un étage décisionnel clair pour identifier la nature de la requête et appliquer les restrictions nécessaires en amont, le système demeure imprévisible.

Structure des intentions e-commerce : entre requêtes fréquentes et requêtes spécifiques de la longue traîne

Nous employons ici les appellations « head » et « tail » pour illustrer de manière concrète les types de requêtes de navigation et de découverte les plus fréquents sur les sites de vente en ligne. Dans le monde réel, de nombreuses requêtes présentent des caractéristiques propres à ces deux catégories :

Requêtes principales (intention déterministe)

Ce sont des requêtes de navigation ciblées pour lesquelles l’utilisateur a une idée précise de son besoin :

• Intention à un seul élément (« oranges », « lait », « pain »).

• Des marques exactes ou des familles de produits (« iPhone 15 Pro », « Diet Coke »).

• Des références (SKU), des numéros de modèles ou des tailles (« ABC123 », « Air Max 270 »).

Pour ces requêtes, la récupération lexicale peut gérer la correspondance des jetons (faire correspondre les mots), mais l’entreprise s’attend également à ce que les contraintes soient respectées, que les classements soient prévisibles et que les résultats soient contrôlables. Un gestionnaire de catalogue doit garantir que les résultats d’une requête respectent le cloisonnement des catégories, les règles de disponibilité et les priorités stratégiques de l’entreprise.

Une gouvernance est nécessaire pour mettre en œuvre la résolution envisagée. Par exemple, « oranges » doit correspondre à la catégorie des produits agricoles, et non au jus d'orange, à la marmelade d'orange ou au soda à l'orange.

Requêtes extrêmes (découverte exploratoire)

Il s’agit de requêtes descriptives, riches en intentions, dans lesquelles les clients explorent :

• « Cadeau pour un grand-père gourmand »

• « Blouson pour la randonnée en montagne »

• « Chaussures pour rester debout toute la journée »

La récupération lexicale est souvent difficile à mettre en œuvre. La récupération sémantique excelle car elle peut l’intention de la requête au produit, même lorsque les termes ne correspondent pas littéralement. Mais la récupération sémantique seule est rarement suffisante non plus. Les requêtes réelles nécessitent souvent l'application de contraintes, quelle que soit la méthode de recherche utilisée.

Le respect des contraintes est indépendant de la méthode de recherche utilisée

L'application de contraintes à la récupération sémantique ne signifie pas recherche hybride. Ces notions sont orthogonales. Les contraintes (filtres, boosts) au sein d’Elasticsearch sont applicables à n’importe quel mode de récupération : lexical, sémantique ou hybride. Toute la difficulté réside dans le choix de l’interprétation de la requête, des contraintes à respecter et de la méthode de récupération des données la plus appropriée.

Voici quelques exemples de requêtes combinant la récupération avec des contraintes strictes :

• Oranges : recherche lexicale sur le terme « oranges » associée à un filtre de catégorie (ex. : « Fruits »), excluant ainsi la confiture d’orange, le jus d’orange ou les boissons gazeuses à l’orange.

• Fruits riches en vitamine C à moins de 4 $ : recherche sémantique pour cibler l’aspect nutritionnel, complétée par des restrictions pour ne conserver que la catégorie des fruits et les articles dont le prix ne dépasse pas 4 $.

• Chaussures confortables pour le travail : recherche sémantique pour l'intention contextuelle plus une contrainte de catégorie limitant les résultats aux chaussures.

Ces requêtes ne peuvent pas être traitées par une seule approche :

• La récupération lexicale pure s’avère ici limitée, car des locutions comme « riche en vitamine C » ou « confortable » ne correspondent pas toujours à des attributs propres et structurés. Il peut être nécessaire de les inférer en analysant les descriptions, les évaluations d’utilisateurs ou les caractéristiques des articles.

• Une recherche sémantique pure peut également montrer ses limites ; sans l’application de contraintes, une requête du type « fruits riches en vitamine C » risque de proposer des compléments alimentaires, des boissons fruitées ou des légumes, dépassant alors le cadre de la catégorie et des prix initialement prévus.

Une couche de gouvernance détermine si une requête nécessite une récupération lexicale, une compréhension sémantique, l’application de contraintes, ou une combinaison de ces éléments. Faute d’une telle structure, les équipes e-commerce pourraient être confrontées aux situations suivantes :

• Sur-filtrage : appliquer une recherche lexicale à des requêtes sémantiques (comme « cadeau pour grand-père »), ce qui limite indûment les résultats.

• Sous-contrainte : utiliser des requêtes sémantiques pour des requêtes de tête à forte intention (par exemple, « oranges »).

En matière de gouvernance, la difficulté réside dans la création d’un système pouvant appliquer le traitement le plus approprié selon la classe de requête rencontrée.

Ce qui se passe en l’absence de gouvernance

Le mode de défaillance le plus courant est simple : les équipes prennent la requête brute de l’utilisateur et la transmettent directement à une stratégie de récupération unique (lexicale, sémantique ou hybride), sans couche de gouvernance intermédiaire.

La récupération lexicale ne parvient pas à la résolution prévue

Lorsqu'un utilisateur recherche « oranges », une stratégie de recherche lexicale peut renvoyer tout élément contenant ce jeton : jus d'orange, marmelade d'orange ou soda à l'orange. Le système a correctement associé le terme, mais sans gouvernance, il peut ne pas résoudre le contexte d'achat prévu (le fruit).

La récupération sémantique va au-delà des contraintes prévues

Lorsqu’un utilisateur recherche des « oranges », un système sémantique peut récupérer des articles conceptuellement liés à travers des concepts de produits proches. Le système peut comprendre correctement le domaine plus large (fruits ou produits), mais sans une gouvernance explicite, il peut encore s'élargir au-delà de la contrainte voulue par l'utilisateur (notamment les oranges).

L'écart, c'est la gouvernance

Ce qu’il faut, c’est une couche de décision en amont qui détermine l’intention de la requête et impose les bonnes contraintes avant même que la récupération ne commence. Cette approche corrige les types d’erreurs suivants :

• Éléments similaires ou connexes apparaissant aux côtés de ce que l'utilisateur voulait réellement.

• Des frontières de catégories floues (« boissons » par rapport à « produits frais »).

• Incapacité à mettre en œuvre des augmentations saisonnières ou des campagnes.

• Des résultats imprévisibles et inexplicables.

Compréhension de l'intention et routage : le plan de contrôle nécessaire

Un système de recherche gouverné introduit un plan de contrôle léger devant la recherche (avant d’exécuter une requête dans Elasticsearch). Ce mécanisme de contrôle sera examiné plus en profondeur dans les troisième et quatrième volets de cette série ; ici, nous nous concentrons sur ses capacités plutôt que sur ses modalités techniques :

Un plan de contrôle peut détecter l'intention, appliquer des politiques commerciales et assurer la stratégie de récupération appropriée comme suit :

1. Détectez les signaux d'intention

• Cette requête relève-t-elle de la navigation ou de la découverte ?

• La requête correspond-elle à un produit phare identifié (lait, pain, bananes) ?

• Y a-t-il une correspondance identifiée avec un produit, une marque ou une catégorie spécifique (par exemple, « oranges » devrait être redirigé vers les produits frais) ?

• La requête est-elle un modèle de type SKU ?

• Cette recherche correspond-elle à une campagne en cours ou à une règle saisonnière (par exemple, mettre en avant les produits liés à la dinde lors des fêtes de fin d’année) ?

• Cette recherche contient-elle des restrictions implicites (catégorie, caractéristiques, éléments à exclure, prix/format/coloris) ?

2. Appliquer les politiques de gouvernance et commerciales

• Appliquez d'abord les contraintes déterministes (catégorie/attribut/négation/disponibilité).

• Appliquer les politiques de merchandising actives (promotion/enterrement/épinglage/remplacement).

• Résoudre les conflits à l’aide de règles de priorité (par exemple, les dérogations liées aux campagnes par rapport aux politiques globales).

3. Orientation vers la stratégie de récupération appropriée

• Lexicale (rapide, déterministe) pour les requêtes principales de navigation/à forte intention.

• Extraction sémantique pour les requêtes True Discovery.

• Une approche hybride où le cumul des signaux lexicaux et sémantiques crée de la valeur, tout en respectant des règles métier explicites.

Dans les faits, la sortie du plan de contrôle n’est pas une simple commande du type « utiliser la recherche hybride » ou « utiliser la recherche sémantique ». Il s’agit d’un plan de recherche régulé, incluant une analyse de l’intention de l’utilisateur, les politiques et contraintes applicables, ainsi que la stratégie d’extraction à lancer. Pour illustrer ce propos, prenons quelques exemples simples :

Requête d'acheteur

Interprétation dirigée

Exemple de plan de récupération

« chocolat sans arachides »

Requête orientée produit avec une contrainte d’exclusion stricte

Recherche lexicale sur le chocolat, avec un filtre d’exclusion pour les produits contenant des arachides

« huile d’olive bon marché »

Requête produit/catégorie avec contrainte de prix

Récupération lexicale pour l'huile d'olive avec un filtre de prix plafonné au seuil du détaillant pour les produits bon marché

« fruit riche en vitamine C en moins de 4 $ »

Requête de découverte nécessitant une compréhension sémantique et des contraintes strictes

Recherche sémantique pour l'intention nutritionnelle, limitée à la catégorie des fruits et filtrée aux produits d'un prix inférieur à 4 $

Un plan de contrôle sélectionne la politique et la stratégie de récupération appropriées pour chaque requête de manière cohérente, prévisible et à grande échelle. Cette approche fiabilise les méthodes de recherche complexes en environnement de production, dans la mesure où les restrictions liées à l’intention priment et où les choix de routage sont clairement définis plutôt que suggérés.

Comment cela se rapporte à d'autres approches

Certaines équipes s’appuient sur des modèles de plongements sémantiques plus performants pour affiner la compréhension des produits, ce qui permet d’accroître sensiblement la pertinence de la recherche sémantique. Certaines équipes privilégient des méthodes de reclassement comme le Learning To Rank (LTR), qui permettent d’ajuster l’ordre des résultats selon l’interaction des utilisateurs ou des indicateurs métier une fois le « retrieval » effectué. Les deux sont précieux et souvent complémentaires. De meilleurs plongements améliorent la correspondance de similarité. Le reclassement améliore l'ordre parmi les candidats récupérés.

La gouvernance traite un aspect différent de la problématique : elle intervient en amont du processus de récupération des données. Ce plan définit la stratégie de recherche (lexicale, sémantique ou hybride), impose les contraintes déterministes adéquates et identifie les requêtes nécessitant l’application conjointe de plusieurs politiques d’entreprise.

Ce que permet un plan de contrôle gouverné

Une fois qu'une couche de gouvernance est mise en place, le modèle opérationnel change fondamentalement. Les requêtes critiques pour les revenus deviennent prévisibles. Les équipes métier peuvent mettre à jour les comportements de recherche sans attendre les cycles de publication de l'ingénierie. Les techniques de récupération de données sophistiquées, comme les modèles sémantiques ou hybrides, peuvent être déployées de manière incrémentale, sécurisées par un aiguillage et des barrières de sécurité, au lieu d’être activées de façon binaire à l’échelle du système.

Le prochain article de cette série examine à quoi ressemble ce modèle opérationnel dans la pratique et explique pourquoi il peut être tout aussi important que la technologie de recherche qui le sous-tend.

Si la correction d’une requête à fort impact financier nécessite l’ouverture d’un ticket Jira et un déploiement technique, le blocage ne se situe pas au niveau du moteur de recherche, mais bien au niveau du modèle d’exploitation. Le commerce en ligne actuel doit pouvoir transformer une intention métier en un comportement de recherche encadré et vérifiable, avec rapidité et sécurité, tout en tirant parti des méthodes de récupération de données sophistiquées quand elles génèrent une valeur ajoutée concrète.

À suivre dans cette série

Les approches abordées dans cette série interviennent en amont de la recherche : il s'agit de traduire l'intention métier en une stratégie de requête adaptée avant même que la génération de la requête ne commence. Dans le prochain article, nous passerons du problème technique au problème opérationnel : que se passe-t-il lorsque les équipes métier peuvent modifier le comportement de recherche sans intervention technique, et pourquoi la gouvernance garantit la sécurité de cette démarche.

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

Les freins techniques, la fragilité de la couche logique applicative et l’instabilité des résultats de recherche sont autant de défis que les services Elastic vous aident à relever dans le cadre de prestations pour le commerce en ligne de grande envergure. L’architecture de plan de contrôle gouverné décrite dans cette série a été conçue par l’ingénierie des services Elastic.

Que vous perdiez un temps précieux en développement pour ajuster vos stratégies de mise en avant ou que l’optimisation de votre moteur de recherche stagne, nous sommes là pour analyser votre infrastructure et mettre en place une solution de recherche structurée, directement éditable par vos experts métier. Contactez Elastic 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.