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.

Le contenu de ce blog a été développé et vérifié à l'aide des versions Elastic 9.2.8 et 8.19.14, ainsi que des versions Filestream Integration 2.3.0 et 1.2.0.

Remarque importante : selon votre environnement, certaines étapes peuvent nécessiter des modifications spécifiques. De plus, sachez que les modèles dynamiques ont été supprimés du modèle de composants @package à compter de la version 2.3.3 de Filestream Integration.

Avant de commencer le processus de réindexation, il est important de prendre en compte l'allocation actuelle de stockage dans votre environnement. Les étapes décrites ci-dessous impliquent la création d'une copie de l'index sous-jacent existant, qui résidera temporairement dans le niveau hot.

Niveaux de données Elasticsearch

• Hot : le niveau hot est le point d'entrée d'Elasticsearch pour les données temporelles, stockant les données les plus récentes et les plus fréquemment recherchées. Les nœuds du niveau hot nécessitent des lectures et des écritures rapides, ce qui requiert davantage de ressources et un stockage plus rapide (SSD). Ce niveau est obligatoire et de nouveaux index de flux de données y sont automatiquement attribués.

• Warm : les données temporelles peuvent passer au niveau warm une fois qu'elles sont interrogées moins fréquemment que les données récemment indexées du niveau hot. Le niveau warm contient généralement les données des dernières semaines. Les mises à jour sont toujours autorisées, mais elles sont probablement peu fréquentes. Les nœuds du niveau warm n'ont généralement pas besoin d'être aussi rapides que ceux du niveau hot. Pour la résilience, les index du niveau hot doivent être configurés pour utiliser une ou plusieurs répliques.

• Cold : les données rarement consultées peuvent être déplacées du niveau warm vers le niveau cold. Celui-ci, tout en restant interrogeable, privilégie la réduction des coûts de stockage à la vitesse de recherche. Il est également possible d'y stocker des index classiques avec des répliques plutôt que des instantanés interrogeables, ce qui permet d'utiliser du matériel moins coûteux pour les données anciennes sans pour autant réduire l'espace disque requis par rapport au niveau warm.

• Frozen : les données rarement interrogées ou qui ne le sont plus passent du niveau cold au niveau frozen pour la durée restante de leur cycle de vie. Ce niveau utilise un référentiel de snapshots et des index partiellement assemblés pour stocker et charger les données, réduisant ainsi le stockage local et les coûts tout en permettant la recherche. Les recherches sur le niveau frozen sont généralement plus lentes que sur le niveau cold, car Elasticsearch peut avoir besoin de récupérer les données frozen depuis le référentiel de snapshots. Nous vous recommandons d'utiliser des nœuds dédiés au niveau frozen.

Prérequis : déterminer quels champs présentent des conflits

Pour déterminer les champs qui présentent des conflits de mapping, accédez à Stack Management -> Data Views -> logs-* (la data view logs-* est la hiérarchie la plus élevée des données présentes avec le préfixe logs-). Si des conflits sont présents, un encadré jaune s'affiche. Vous pouvez cliquer sur View conflicts ou, sous la zone Field type à côté de la zone Search, sélectionnez le conflit.

Cliquez sur le bouton jaune Conflict pour voir quels index sont associés à quels types de mapping.

Cette situation (où le champ est mappé à la fois en tant que keyword et en tant que long) se produit généralement parce que les données ont été ingérées avant qu'un type de mapping spécifique ait été défini dans le modèle de composants pour le flux de données concerné. Dans de tels cas, Elasticsearch tente de définir le mapping en fonction de ses modèles dynamiques.

Pour déterminer quel mapping est approprié pour le champ et si le champ est un champ ECS, une vérification avec la référence des champs ECS est nécessaire. Si le champ en question n'est pas un champ ECS, sa valeur doit être examinée pour déterminer le mapping approprié.

Si un champ, comme log.offset dans cet exemple, n'est pas documenté dans l'ECS, les étapes suivantes consistent à examiner la valeur du champ, à déterminer quel type de mapping conflictuel possède le plus d'index sous-jacents, et à examiner les modèles de composants des autres index.

En général, le type de mapping associé au plus grand nombre d'index est le bon, mais nous vous recommandons de vérifier la valeur du champ concerné pour le confirmer. Pour confirmer la validité d'un type de mapping (par exemple, long), vous devez également vérifier que la valeur du champ est appropriée pour ce type. Cette vérification peut être effectuée en utilisant Discover pour rechercher le champ en question. L'examen d'autres flux de données contenant le même champ peut également apporter une confirmation supplémentaire.

Pour examiner les valeurs présentes pour le champ qui présente le problème de mapping, revenez au bouton jaune Conflict indiqué précédemment, cliquez sur le bouton Conflict, sélectionnez l'un des index sous-jacents et collez-le dans une session Discover . Votre instruction Kibana Query Language (KQL) devrait ressembler à la capture d'écran suivante, pour inclure le délimiteur de champ _index:.

Préparation du nouveau modèle de composants personnalisé d'index sous-jacent

Pour résoudre le conflit de mapping dans le flux de données, examinez d'abord le modèle de composants @package pertinent. Vous trouverez ceci sous Stack Management -> Index Management -> Component Template. Cherchez le flux de données et sélectionnez le lien @package correspondant. Ce modèle contient des mappings prêts à l'emploi pour les champs et, bien que les incohérences de mapping soient rares, il est possible que le type le plus approprié ait été ignoré.

Vérifiez le modèle pour vous assurer qu'il contient l'imbrication et le mapping de champs nécessaires pour le champ en question. Par exemple, si le modèle liste log.offset comme keyword par erreur, la source du problème est ici.

Important : comme il n'est pas recommandé de modifier les modèles @package/managed, vous devez utiliser ou créer un modèle de composants @custom pour corriger le type de mapping (par exemple, pour log.offset) pour toutes les données futures.

• Nous ne recommandons pas de modifier les modèles @package/managed, car lorsque vous mettrez à jour l'intégration vers une version plus récente, toutes les modifications que vous apporterez au modèle @package seront remplacées. C'est pourquoi nous recommandons d'utiliser les modèles @custom.

• Si un flux de données rencontre des conflits de mapping, vous devez ajouter tous les champs manquants (imbrications ou mappings ECS et non-ECS) au modèle de composants @custom du flux de données. Créez ce modèle s'il n'existe pas encore et veillez à spécifier le type de mapping correct pour le champ.

• Si plusieurs conflits sont présents dans votre data view, appliquez simultanément tous les mappings manquants nécessaires au flux de données afin que la réindexation ne soit effectuée qu'une seule fois. L'ajout d'entrées pour le typage correct des données dans le modèle de composants @custom garantira que toute ingestion ultérieure de données suivra les mêmes règles de mapping.

Pour créer le modèle de composants @custom (ou vérifier qu'il est utilisé et renseigné), accédez ) Index Templates, saisissez le nom du flux de données en question et cliquez sur le modèle @custom approprié utilisé par le flux de données. Si le modèle n'est pas encore créé, une case jaune apparaît, vous permettant de le créer via l'interface utilisateur.

La capture d'écran ci-dessous montre la page suivante après que l'option Create component template a été sélectionnée. Laissez les paramètres par défaut tels quels sur la première page et cliquez sur Mappings ou Next jusqu'à atteindre la page Mappings.

Pour définir explicitement le mapping d'un nouveau champ entrant ou pour mettre à jour un champ présentant un conflit de mapping, lorsque le flux de données est réinitialisé en raison d'une configuration définie dans la politique de cycle de vie de l'index, une entrée est nécessaire pour le champ dans lequel le conflit existe.

La procédure suivante permet de définir le mapping du champ log.offset dans le modèle de composants @custom pour le flux de données filestream. Répétez les étapes pour ajouter des champs personnalisés ou mettre à jour les champs nécessaires du @package avec les mappings appropriés, si nécessaire, pour cet ensemble de données. Dans cet exemple, en définissant le décalage sur Long, le type de champ sera Numeric et le type numérique sera Long. Cliquez sur Add field, puis en dehors de la zone pour continuer.

Une fois tous les champs nécessaires ajoutés, cliquez pour vérifier, puis sélectionnez Create component template lorsque vous êtes prêt. log.offset sera défini sur long pour toutes les nouvelles données ingérées à partir de cette étape.

Création de la nouvelle structure de l'index sous-jacent

Le nouvel index sous-jacent doit comporter les mappings existants du modèle de composants du flux de données, ainsi que le modèle de composants ECS ecs@mappings. Le modèle de composants ecs@mappings est appliqué après le composant du flux de données en tant que catchall pour les mappings supplémentaires qui n'ont potentiellement pas été capturés dans les modèles de composants précédents.

Accédez à l'onglet navigateur pour les mappings @package du flux de données. (Stack Management -> Index Management -> Component Template -> logs-filestream.generic@package -> Manage -> Edit.) Une fois sur place, cliquez sur la section Review, puis sur Request, et enfin sur le bouton Copy à droite. Le contenu JSON du modèle de composants copié garantit la conservation des mappings de champs et des paramètres restants pendant la mise à jour du mapping de champ log.offset. Ce JSON constituera la structure sous-jacente de l'index nouvellement réindexé.

Important : si le JSON du modèle n'avait pas été copié et que l'opération de réindexation se soit poursuivie, le conflit log.offset aurait été résolu, mais de nouveaux conflits seraient survenus avec l'intégration, car l'intégrité des mappings actuels n'a pas été respectée, créant un double travail pour résoudre le problème initial.

Ouvrez un deuxième onglet de navigateur, accédez aux outils de développement et collez le contenu copié. Ensuite, pour nettoyer ce qui a été collé :

Modifications de la demande

1. Nom de l'index : remplacez _component_template/logs-filestream.generic@package par le nom de l'index sous-jacent que vous souhaitez réindexer, en ajoutant -1 à la fin. Par exemple, utilisez PUT <backing index to reindex>-1.

• Le -1 ajouté indique une réindexation et ne sera pas en conflit avec les paramètres de substitution ILM par défaut, qui sont basés sur la date de création de l'index.

2. Paramètres : supprimez la ligne "template" (ligne 3), ainsi que la toute dernière accolade fermante de l'ensemble de la charge utile JSON ; la ligne 3 doit commencer par "settings": {.

• Remplacez le contenu interne de la section des paramètres par "index.codec": "best_compression". Cette action appliquera la meilleure compression d'Elastic à l'index lors de sa création.

• Ajoutez "index.lifecycle.name": "logs", ainsi qu'une ligne pour "index.lifecycle.rollover_alias": "".

  1. L'entrée "index.lifecycle.name": "logs" appliquera la politique ILM des logs au nouvel index sous-jacent. Modifiez le nom de la politique ILM si vous n'utilisez pas de logs.

  2. Le "index.lifecycle.rollover_alias": "" est vide, car cet index sous-jacent ne sera par reconduit ; ce paramètre est néanmoins nécessaire pour éviter les erreurs de substitution ILM dans la phase ILM qui suit la phase hot.

3. Structure : la requête doit désormais inclure à la fois une section Settings et une section Mappings. Dans "mappings": {, vous devriez trouver "dynamic_templates" et une section "properties" contenant des champs codés en dur et leurs mappings.

4. Modification des modèles dynamiques : la section des modèles dynamiques actuels contient des entrées de champs qui peuvent être remplacés lorsque les modèles dynamiques ecs@mappings sont ajoutés ensuite, ce qui génère une redondance et des lignes supplémentaires qui ne sont pas nécessaires.

• Supprimez toutes les sections de "dynamic_templates" sauf la deuxième intitulée "_embedded_ecs-data_stream_to_constant": {.

• Répétez le même processus que celui décrit ci-dessus, en rassemblant les mappings dynamiques pour le modèle de composants @package, mais cette fois-ci les mappings dynamiques pour le modèle de composants ecs@mappings.

  • Il peut être plus simple de copier l'intégralité du contenu des mappings depuis l'interface utilisateur pour le modèle de composants ecs@mappings, de coller dans la section Dev Tools dynamic_templates fonctionnelle, et de supprimer les lignes dupliquées et inutiles là où c'est approprié. Incluez ces contenus de paramètres de modèle dynamique après l'entrée "_embedded_ecs-data_stream_to_constant": {. La section dynamic_templates doit être très proche des exemples de contenus ci-dessous dans Dev Tools.

• Si les dynamic_templates ne sont pas inclus/supprimés, d'autres champs (voir la capture d'écran ci-dessous) comporteront des mappings en double : text et keyword par rapport aux mappings appropriés, si la section dynamic_templates n'a pas été retirée. Ce qui reste devrait être la section "properties" sous "mappings". Cela créera également des problèmes dans la data view puisque les champs ont été mappés en double (s'ils n'ont pas déjà été mappés de cette façon) et provoquera des conflits de mapping supplémentaires.

5. Suppression des métadonnées : supprimez la dernière section étiquetée "_meta", ainsi que la section étiquetée "version", si elle est présente.

6. Formatage : indentez automatiquement les sections restantes et ajustez ou supprimez les accolades inutiles qui pourraient empêcher une exécution correcte.

7. Modification du mapping : accédez à la section "properties", recherchez "log", puis localisez "offset" imbriqué en dessous. Changez le type de keyword pour long, puis supprimez l'entrée de ligne (virgule incluse) étiquetée "ignore_above": 1024,. Si plus d'une entrée a été ajoutée au modèle de composants @custom créé précédemment, incluez-les ici.

La vue console de vos outils de développement devrait maintenant être semblable à l'exemple ci-dessous.

Une fois que votre console ressemble à l'exemple (avec tous les champs personnalisés supplémentaires inclus et les valeurs personnalisées spécifiques à votre environnement), exécutez la commande pour créer la structure du nouvel index sous-jacent, en prenant le temps de résoudre les erreurs éventuelles.

Démarrer le processus de réindexation

Une fois la structure du nouvel index sous-jacent correctement créée, l'étape suivante consiste à réindexer et à résoudre les conflits de mapping.

Important : si l'index sous-jacent qui présente le conflit de mapping est l'index le plus récent et l'index d'écriture actuel (par exemple, si le numéro final de l'index sous-jacent est -000001), le flux de données doit être remplacé. Le remplacement du flux de données est nécessaire, car l'index d'écriture actuel, dans lequel des documents sont ingérés, est un index sous-jacent actif et ne peut pas être modifié.

Maintenant que le mapping correct a été appliqué au dernier index d'écriture via le modèle de composants @custom créé précédemment, tous les nouveaux documents refléteront ce changement.

Ceci s'effectue en exécutant ce qui suit :

Par exemple :

La réindexation consiste à copier les données d'un index sous-jacent existant vers un nouvel index dans le cadre de la même convention de dénomination, généralement pour appliquer les modifications nécessaires. Ces modifications peuvent inclure des mises à jour d'un modèle de composants ou l'ajout d'un nouveau pipeline d'ingestion pour les données à traiter.

Ensuite, les données seront copiées depuis l'index sous-jacent dont les mapping sont incorrects vers un nouvel index sous-jacent. L'index sous-jacent initial a été remplacé, ce qui signifie qu'aucun nouveau document ne peut y être ajouté. Le nouvel index sous-jacent suivra la même convention de dénomination, ce qui préserve la visibilité et l'intégrité des données tout en appliquant la politique ILM adéquate, mais il contiendra le suffixe -1 pour indiquer qu'il a été réindexé.

Ajustez les noms d’index selon les besoins et collez le code suivant dans la console. En incluant wait_for_completion=false, vous pouvez suivre la progression de la copie des documents, ce qui permet d'estimer le temps de réindexation restant. Sans ce paramètre, vous ne pourrez pas suivre le statut à l'aide de la commande GET _tasks ci-dessous et ne pourrez vérifier le nombre de documents dans l'index de sauvegarde plus récent qu'à l'aide de la commande GET <backing index name>-1/_count.

Important : en cas de problèmes pendant le processus de réindexation, ne relancez pas la commande de réindexation, car cela redémarrera le processus et créera des enregistrements en double dans l'index se terminant par -1. Si un redémarrage est nécessaire, supprimez d'abord l'index avec -1 à la fin, puis exécutez la commande PUT précédente pour recréer le nouveau shell de l'index sous-jacent.

À l'exécution, la réponse inclura un identifiant de tâche. Vous pouvez surveiller la progression de la réindexation en utilisant cet ID avec la commande : GET _tasks/<task ID>.

La durée de la réindexation dépend du volume de données dans l'index initial. L'achèvement peut être suivi en recherchant "completed": true lors de l'exécution de la commande GET, ce qui devrait produire une sortie similaire.

GET _tasks/<task ID>

Le processus de réindexation étant maintenant terminé pour le nombre de documents, l'étape suivante consiste à vérifier que les mappings entre le nouvel index sous-jacent et le champ spécifique en question sont corrects.

Par exemple :

Vous pouvez vérifier que le mapping pour log.offset est conforme à celui indiqué ci-dessous. Pour confirmer que les autres champs n'ont qu'une seule entrée de mapping (et non text et keyword), comparez-les à un champ qui ne faisait pas partie de la section de modèle dynamique dans la commande PUT précédente.

Si l'index de support en cours de réindexation contient un grand nombre de documents, il est utile de vérifier l'état de ces documents copiés vers le nouvel index de support ; cela peut être fait à l'aide des deux commandes suivantes des outils de développement pour comparer les comptes.

GET .ds-logs-filestream.generic-default-2026.04.14-000001/_count

GET .ds-logs-filestream.generic-default-2026.04.14-000001-1/_count

Une fois que vous avez vérifié que les nombres correspondent et que les mappings corrects sont présents, mettez à jour le flux de données pour inclure le nouvel index sous-jacent afin d'éviter que la gestion des index comporte un index sous-jacent orphelin auquel la politique ILM ne s'appliquera jamais.

• Si l'opération aboutit, une confirmation de réussite est renvoyée.

Vérifiez que le nouvel index sous-jacent a été ajouté à l'aide de la commande suivante, en vous assurant que le paramètre ilm_policy est correct :

Vérifiez l'état ILM de l'index sous-jacent suivant avec cette commande :

• Vous constaterez que l'index est en mode hot, ce qui est normal car il a été créé très récemment (consultez la ligne 8 ou 10).

Exécutez la procédure suivante pour faire passer l'index de sauvegarde du niveau chaud au niveau approprié suivant la phase chaude de la stratégie ILM pour ce flux de données. Les valeurs spécifiques pour phase, action et name dans le current_step ci-dessous peuvent être consultées respectivement à partir des lignes 11, 13 et 15, dans la capture d’écran fournie ci-dessus.

La valeur next_step indique la phase ILM ou le niveau de données ultérieur auquel l'index passera.

Par exemple :

• Ce n'est pas nécessaire, mais par mesure de sécurité, vous pouvez exécuter à nouveau la commande _ilm/explain pour vous assurer que l'index sous-jacent est passé à la phase suivante et n'est plus en phase hot.

Lorsque les conditions suivantes sont remplies, vous pouvez supprimer en toute sécurité l'index sous-jacent initial qui présentait des conflits de mapping :

1. Un nouvel index sous-jacent a été correctement créé.

2. Les documents ont été déplacés vers le nouvel index et le nombre de documents correspond.

3. Les mappings ont été corrigés (ceux spécifiques au flux de données et ceux d'ECS).

4. Le flux de données intègre le nouvel index sous-jacent.

5. La politique ILM a été appliquée et a permis à l'index de sortir de sa phase chaude.

Important : sinon, avant de supprimer l'index initial, vous pouvez consulter la page Data Views. Sélectionnez logs-* et vérifiez que l'index sous-jacent réindexé (qui se termine par -1) apparaît maintenant dans la section long. L'index sous-jacent initial devrait toujours être présent sous keyword. Si l'index sous-jacent initial réindexé ne se trouve pas dans la section long, revenez en arrière pour vérifier les étapes précédentes et effectuer les corrections nécessaires.

Par exemple :

Après avoir résolu les conflits, retournez à la page Data Views et sélectionnez logs-*. Si le conflit était uniquement lié à log.offset, aucun conflit ne devrait plus être listé. Si d'autres conflits étaient présents, l'index sous-jacent initial ne devrait plus apparaître dans la liste des conflits, et le nouvel index sous-jacent devrait désormais figurer dans la section long.

Vous pouvez également vérifier dans Discover que le champ log.offset affiche désormais les icônes appropriées.

Poursuivez ce processus en répétant les étapes ci-dessus pour chaque index de sauvegarde présentant un conflit de mapping, jusqu'à ce que tous soient résolus avec succès.

Références :

• Référence de champ ECS

• Réindexer les documents

Conclusions

En suivant les étapes décrites dans cet article, vous résoudrez les conflits de mapping et vous assurerez que toutes les nouvelles données sont correctement mappées. Pour ce faire, vous lierez les modèles de composants nécessaires à votre source de données. Ce processus permet non seulement de corriger les problèmes immédiats, mais aussi d'établir une méthode sécurisée et reproductible pour gérer les modifications de schéma à mesure que vos données et vos besoins évoluent.

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.

Nous avons effectué une mise à niveau majeure de l'infrastructure pour tous les projets Elastic Cloud Serverless exécutés sur AWS, en migrant vers du matériel plus récent et plus performant. Cette modification a été déployée automatiquement sur tous les projets sans serveur. Vous bénéficiez maintenant d'un débit plus élevé et d'une latence plus faible pour les projets sans serveur Elasticsearch, Elastic Observability et Elastic Security sur AWS.

Principaux avantages en termes de performances pour les développeurs

La nouvelle infrastructure matérielle d'AWS sous-tend tout ce que vous faites avec Elastic Cloud Serverless, ce qui se traduit par des avantages tangibles au niveau de la vitesse et de la réactivité de vos applications.

Latence des requêtes réduite… débit accru

Le matériel amélioré augmente considérablement la vitesse des ressources de calcul ; vos requêtes de recherche sont ainsi traitées plus rapidement que jamais.

• Recherche et recherche vectorielle : que vous exécutiez des recherches full text traditionnelles ou que vous utilisiez la recherche vectorielle de pointe pour vos applications d'IA générative et de génération augmentée par récupération (RAG), vous constaterez une diminution notable de la latence. Une analyse comparative interne a révélé une diminution moyenne de 35 % de la latence de recherche.

• Indexation plus rapide : les taux d'ingestion de données sont optimisés, vous permettant d'indexer d'énormes volumes de données et des documents complexes avec un débit accru. Ceci est crucial pour les applications qui nécessitent une visibilité des données en temps quasi‑réel. L'évaluation comparative interne a montré une augmentation moyenne de 26 % du débit d'indexation.

Performances constantes sous charge

Elastic Cloud Serverless est conçu pour s'adapter automatiquement et dynamiquement en temps réel à la demande, minimisant ainsi la latence, quelle que soit votre charge de travail. Grâce à cette amélioration matérielle, le scaling est désormais plus performant et réactif.

• Gestion facile des pics de charge : qu'il s'agisse d'une augmentation soudaine du trafic utilisateur ou d'une ingestion massive de données par lots, la nouvelle infrastructure garantit un scaling vertical plus efficace sur vos ressources de recherche et d'indexation afin de maintenir une latence faible de façon constante.

• Découplage optimisé calcul‑stockage : l'architecture sans serveur sépare le calcul et le stockage, ce qui permet aux charges de travail de scaler indépendamment pour des performances et une rentabilité optimales. Le matériel plus rapide améliore la couche de calcul, maximisant l'efficacité de cette conception découplée.

Sous le capot : résultats des analyses comparatives internes

Pour quantifier l'impact de la mise à niveau de notre infrastructure AWS, l'équipe d'ingénierie d'Elastic a mené des tests de performance internes complets sur un large éventail de charges de travail sans serveur. Ces charges de travail ont fourni des preuves concrètes des améliorations de performances que vous pouvez attendre de vos applications, quel que soit votre cas d'utilisation.

L'approche d'analyse comparative

Nous avons concentré nos tests sur les indicateurs clés qui influencent directement l'expérience développeur et la réactivité des applications : le temps de réponse (c'est-à-dire la latence) et le débit lors des opérations de recherche et d'indexation.

• Test des charges de travail : les tests comprenaient des opérations de recherche à haute simultanéité typiques des applications destinées aux utilisateurs, des requêtes de recherche vectorielle complexes et l'ingestion/l'indexation de données à fort volume pour des cas d'utilisation d'observabilité et de sécurité. Plus précisément, notre méthodologie de test a utilisé des ensembles de données accessibles au public pour Rally, l'outil d'évaluation comparative d'Elastic.

  • wikipedia: Un ensemble de données issu d'un instantané du contenu textuel de Wikipédia, pour mesurer les performances de recherche textuelle à usage général.

  • MSMARCO-Passage-Ranking: Un ensemble de données issu de Microsoft Machine Reading Comprehension (MS MARCO), pour mesurer les performances de recherche sur des champs vectoriels épars.

  • OpenAI_Vector: Un ensemble de données issu du NQ de BEIR et enrichi d'embeddings générés par le modèle text-embedding-ada-002 d'OpenAI, pour évaluer les performances de recherche sur des champs vectoriels denses.

• Mesure : nous avons comparé les performances de l'ancienne et de la nouvelle infrastructure, en mesurant la latence au 99e percentile (P99) afin de capturer les performances les plus mauvaises et le nombre d'opérations par seconde, en tenant compte de la latence de queue. Chaque piste a été exécutée cinq fois pour chaque profil de matériel afin de garantir la cohérence des résultats.

• L'objectif : Notre objectif était de valider la capacité de l'infrastructure à fournir des performances plus rapides et plus prévisibles de manière constante, même pendant les périodes d'autoscaling rapide.

Résumé des données de performance

Les résultats confirment des gains d'efficacité et de rapidité significatifs. Ces gains se traduisent directement par des temps de réponse plus courts pour vos utilisateurs et par une réduction des coûts opérationnels grâce à la possibilité d'effectuer la même quantité de travail avec moins de ressources de calcul.

Les tableaux suivants décrivent en détail les améliorations quantitatives. Plus les valeurs sont élevées, meilleur est le débit ; plus les valeurs sont faibles, meilleure est la latence.

Résultats des recherches de référence :

Référence

Comparatif

Ancienne infrastructure

Nouvelle infrastructure

Différentiel

'wikipedia' (texte brut)

Débit des opérations de recherche (ops/s)

729

1107

+52 %

'wikipedia' (texte brut)

Latence des opérations de recherche (p99, ms)

56

35

-37 %

`MSMARCO-Passage-Ranking` (vecteurs épars)

Débit des opérations de recherche (ops/s)

22

31

+40 %

`MSMARCO-Passage-Ranking` (vecteurs épars)

Latence des opérations de recherche (p99, ms)

108

67

-38 %

'OpenAI_Vector' (vecteurs denses)

Débit des opérations de recherche (ops/s)

475

624

+31 %

'OpenAI_Vector' (vecteurs denses)

Latence des opérations de recherche (p99, ms)

35

22

-37 %

Résultats de référence de l'indexation :

Référence

Comparatif

Ancienne infrastructure

Nouvelle infrastructure

Différentiel

'wikipedia' (texte brut)

Débit des opérations de recherche (ops/s)

2 845

3 220

+13 %

'wikipedia' (texte brut)

Latence des opérations de recherche (p99, ms)

1769

1120

-37 %

`MSMARCO-Passage-Ranking` (vecteurs épars)

Débit des opérations de recherche (ops/s)

7087

8 900

+26 %

`MSMARCO-Passage-Ranking` (vecteurs épars)

Latence des opérations de recherche (p99, ms)

824

677

-18 %

'OpenAI_Vector' (vecteurs denses)

Débit des opérations de recherche (ops/s)

2972

3187

+7%

'OpenAI_Vector' (vecteurs denses)

Latence des opérations de recherche (p99, ms)

2946

2944

0 %

L'avantage supplémentaire : réduction des coûts

Bien que notre priorité soit de fournir des performances à faible latence, l'efficacité du nouveau matériel a également un impact direct et positif sur les coûts des projets Elasticsearch.

La tarification d'Elasticsearch Serverless est basée sur l'utilisation : vous ne payez que pour les ressources d'ingestion et de recherche que vous consommez. Grâce à un matériel plus récent et plus rapide, vos charges de travail s'exécuteront souvent avec moins de ressources, ce qui se traduit par une réduction des coûts pour la plupart des projets. Vous bénéficiez ainsi de performances optimales sans le surcoût : l'efficacité par excellence.

Qu'est-ce que cela signifie pour vous, le développeur ?

Cette mise à niveau de l'infrastructure est entièrement gérée par Elastic ; vous n'avez donc rien à faire, aucune migration ni modification de configuration. L'amélioration est immédiate et automatique pour tous vos projets sans serveur sur AWS.

Cette mise à niveau vous permet de :

• Créez des applications plus rapides : concentrez-vous sur la vélocité des fonctionnalités, en sachant que votre plateforme de recherche sous-jacente offre la vitesse exigée par vos utilisateurs.

• Innovez en confiance : déployez de nouvelles fonctionnalités de recherche, d'observabilité et de sécurité, y compris des capacités d'IA complexes telles que la recherche vectorielle et le classement par pertinence, sachant que la plateforme peut gérer la charge à des performances optimales.

• Simplifiez votre stack : utilisez un service entièrement géré qui prend en charge l'infrastructure, la planification de la capacité et le scaling, et concentrez‑vous sur votre code et vos données.

Dans la dernière partie de cette série, nous avons déployé le modèle E5 pré-entraîné d'Elastic (ainsi que d'autres modèles d'intégration de texte multilingue de Hugging Face) et nous nous sommes plongés dans la génération d'intégrations vectorielles denses à partir de vos données textuelles à l'aide d'Elasticsearch et de Kibana. Dans ce blog, nous examinerons les résultats de ces encastrements et mettrons en évidence les avantages significatifs de l'utilisation d'un modèle multilingue.

Maintenant que nous avons notre index coco_multilingual, la recherche nous donnera des documents en plusieurs langues, avec le champ "en" pour référence :

Effectuer une recherche en anglais

Essayons d'effectuer la recherche en anglais et voyons ce qu'il en est :

Ici, même si la requête semble faussement simple, nous recherchons les enchâssements numériques du mot "kitty" dans tous les documents, dans toutes les langues, sous le capot. Et comme nous effectuons une recherche vectorielle, nous pouvons rechercher sémantiquement tous les mots susceptibles d'être liés à "kitty" : "chat", "chaton", "félin", "gatto" (italien), "mèo" (vietnamien), 고양이 (coréen), 猫 (chinois), etc. Ainsi, même si ma requête est en anglais, nous pouvons rechercher du contenu dans toutes les autres langues. Par exemple, la recherche d'un chat lying on something donne des documents en italien, en néerlandais ou en vietnamien. Une question d'efficacité !

Recherche de contenu dans d'autres langues

De même, une recherche par mot-clé pour "chat" en coréen ("고양이") donnera également des résultats significatifs. Ce qui est spectaculaire ici, c'est que nous n'avons même pas de documents en coréen dans cet index !

Cela fonctionne parce que le modèle d'intégration représente le sens dans un espace sémantique partagé, ce qui permet de retrouver des images pertinentes même si la requête est formulée dans une langue différente de celle des légendes indexées.

Augmenter la pertinence des résultats de recherche grâce à la recherche hybride et au reranking

Nous sommes heureux que les résultats pertinents soient apparus comme prévu. Mais dans le monde réel, par exemple dans le commerce électronique ou dans les applications RAG qui doivent se limiter aux 5 à 10 premiers résultats les plus pertinents, nous pouvons utiliser un modèle de classement pour hiérarchiser les résultats les plus pertinents.

Par exemple, une requête demandant "quelle est la couleur du chat ?" en vietnamien donnera un grand nombre de résultats, mais les 1 ou 2 premiers ne seront pas forcément les plus pertinents.

Les résultats mentionnent tous le chat, ou une forme de couleur :

Améliorons donc cela ! Intégrons le modèle de rerank multilingue de Coherepour améliorer le raisonnement correspondant à notre question.

Maintenant, avec les premiers résultats, notre application peut répondre en toute confiance que la couleur du chaton est noire ou brune avec des rayures. Ce qui est encore plus intéressant ici, c'est que notre recherche vectorielle a détecté une omission dans la légende anglaise de l'ensemble de données original. Il est capable de trouver le chat à rayures brunes alors que la traduction anglaise de référence a omis ce détail. C'est la force de la recherche vectorielle.

Conclusion

Dans ce blog, nous avons présenté l'utilité d'un modèle d'intégration multilingue, et comment tirer parti d'Elasticsearch pour intégrer les modèles afin de générer des intégrations, et d'améliorer efficacement la pertinence et la précision avec une recherche hybride et un reranker. Vous pouvez créer votre propre cluster Cloud pour essayer la recherche sémantique multilingue en utilisant notre modèle E5 prêt à l'emploi sur la langue et l'ensemble de données de votre choix.

Dans un monde d'utilisateurs globaux, la recherche d'informations multilingues (CLIR) est cruciale. Au lieu de limiter les recherches à une seule langue, le CLIR vous permet de trouver des informations dans n'importe quelle langue, ce qui améliore l'expérience de l'utilisateur et rationalise les opérations. Imaginez un marché mondial où les clients du commerce électronique pourraient rechercher des articles dans leur langue et où les bons résultats apparaîtraient, sans qu'il soit nécessaire de localiser les données à l'avance. Ou encore, où les chercheurs universitaires peuvent rechercher des articles dans leur langue maternelle, avec nuance et complexité, même si la source est dans une autre langue.

Les modèles d'intégration de textes multilingues nous permettent justement de le faire. Les emboîtements sont un moyen de représenter le sens d'un texte sous forme de vecteurs numériques. Ces vecteurs sont conçus de manière à ce que les textes ayant des significations similaires soient situés à proximité les uns des autres dans un espace à haute dimension. Les modèles d'intégration de textes multilingues sont spécifiquement conçus pour représenter dans un espace vectoriel similaire les mots et les phrases ayant la même signification dans différentes langues.

Les modèles tels que le logiciel libre Multilingual E5 sont formés sur des quantités massives de données textuelles, souvent à l'aide de techniques telles que l'apprentissage contrastif. Dans cette approche, le modèle apprend à distinguer les paires de textes dont le sens est similaire (paires positives) de ceux dont le sens est différent (paires négatives). Le modèle est entraîné à ajuster les vecteurs qu'il produit de manière à maximiser la similarité entre les paires positives et à minimiser la similarité entre les paires négatives. Pour les modèles multilingues, ces données d'entraînement comprennent des paires de textes dans différentes langues qui sont des traductions l'une de l'autre, ce qui permet au modèle d'apprendre un espace de représentation commun pour plusieurs langues. Les enchâssements résultants peuvent ensuite être utilisés pour diverses tâches de NLP, y compris la recherche multilingue, où la similarité entre les enchâssements de texte est utilisée pour trouver des documents pertinents quelle que soit la langue de la requête.

Avantages de la recherche vectorielle multilingue

• Nuance: La recherche vectorielle excelle à capturer le sens sémantique, allant au-delà de la correspondance des mots clés. Ceci est crucial pour les tâches qui nécessitent de comprendre le contexte et les subtilités de la langue.

• Compréhension multilingue: Permet de rechercher efficacement des informations dans plusieurs langues, même lorsque la requête et les documents utilisent un vocabulaire différent.

• Pertinence: Fournit des résultats plus pertinents en se concentrant sur la similarité conceptuelle entre les requêtes et les documents.

"Prenons l'exemple d'un chercheur universitaire qui étudie l'impact des médias sociaux sur le discours politique" dans différents pays. Grâce à la recherche vectorielle, ils peuvent saisir des requêtes telles que "l'impatto dei social media sul discorso politico" (italien) ou "ảnh hưởng của mạng xã hội đối với diễn ngôn chính trị" (vietnamien) et trouver des articles pertinents en anglais, espagnol ou toute autre langue indexée. En effet, la recherche vectorielle identifie les articles qui traitent du concept de l'influence des médias sociaux sur la politique, et pas seulement ceux qui contiennent les mots clés exacts. Cela améliore considérablement l'étendue et la profondeur de leurs recherches.

Se lancer

Voici comment configurer CLIR en utilisant Elasticsearch - avec le modèle E5 qui est fourni dans la boîte. Nous utiliserons l'ensemble de données multilingues COCO, qui contient des légendes d'images dans plusieurs langues, pour nous aider à visualiser deux types de recherches :

1. Requêtes et termes de recherche dans d'autres langues sur un ensemble de données en anglais, et

2. Requêtes en plusieurs langues à partir d'un ensemble de données contenant des documents en plusieurs langues.

Ensuite, nous exploiterons la puissance de la recherche hybride et du reranking pour améliorer encore les résultats de la recherche.

Produits requis

• Python 3.6+

• Elasticsearch 8+

• Client Elasticsearch Python : pip install elasticsearch

Ensemble de données

L'ensemble de données COCO est un ensemble de données de sous-titrage à grande échelle. Chaque image de l'ensemble de données est légendée dans plusieurs langues différentes, avec plusieurs traductions disponibles par langue. À des fins de démonstration, nous indexerons chaque traduction comme un document individuel, avec la première traduction anglaise disponible à titre de référence.

Étape 1 : télécharger l'ensemble de données multilingues COCO

Pour simplifier le blog et faciliter le suivi, nous chargeons ici les 100 premières lignes du restval dans un fichier JSON local à l'aide d'un simple appel à l'API. Vous pouvez également utiliser la bibliothèque de données HuggingFace pour charger le jeu de données complet ou des sous-ensembles du jeu de données.

Si les données sont chargées avec succès dans un fichier JSON, vous devriez voir quelque chose de similaire à ce qui suit :

Data successfully downloaded and saved to multilingual_coco_sample.json

Étape 2 : (Démarrer Elasticsearch) et indexer les données dans Elasticsearch

a) Démarrez votre serveur Elasticsearch local.

b) Lancer le client Elasticsearch.

c) Données d'index

Une fois les données indexées, vous devriez voir quelque chose de similaire à ce qui suit :

Successfully bulk indexed 4840 documents

Indexing complete!

Étape 3 : Déployer le modèle formé E5

Dans Kibana, accédez à la page Stack Management > Trained Models, et cliquez sur Deploy pour le modèle .multilingual-e5-small_linux-x86_64. option. Ce modèle E5 est un petit ordinateur multilingue optimisé pour linux-x86_64, que l'on peut utiliser dès sa sortie de l'emballage. En cliquant sur "Déployer", vous accédez à un écran où vous pouvez ajuster les paramètres de déploiement ou les configurations des vCPUs. Par souci de simplicité, nous utiliserons les options par défaut, en sélectionnant les ressources adaptatives, ce qui permettra de dimensionner automatiquement notre déploiement en fonction de l'utilisation.

Si vous souhaitez utiliser d'autres modèles d'intégration de texte, vous pouvez le faire en option. Par exemple, pour utiliser le BGE-M3, vous pouvez utiliser le client Python Eland d'Elastic pour importer le modèle de HuggingFace.

Accédez ensuite à la page Modèles formés pour déployer le modèle importé avec les configurations souhaitées.

Étape 4 : Vectorisation ou création d'enchâssements pour les données d'origine avec le modèle déployé

Pour créer les enchâssements, nous devons d'abord créer un pipeline d'ingestion qui nous permettra de prendre le texte et de le faire passer par le modèle d'enchâssement de texte d'inférence. Vous pouvez le faire dans l'interface utilisateur de Kibana ou via l'API d'Elasticsearch.

Pour ce faire via l'interface Kibana, après avoir déployé le modèle entraîné, cliquez sur le bouton Test . Cela vous permettra de tester et de prévisualiser les éléments intégrés générés. Créez une nouvelle vue de données pour l'index coco , définissez Data view sur la vue de données coco nouvellement créée, et définissez Field sur description car c'est le champ pour lequel nous voulons générer des embeddings.

Cela fonctionne très bien ! Nous pouvons maintenant créer le pipeline d'ingestion et réindexer nos documents originaux, les faire passer par le pipeline et créer un nouvel index avec les embeddings. Pour ce faire, cliquez sur Créer un pipeline, ce qui vous guidera tout au long du processus de création du pipeline, avec des processeurs auto-remplis nécessaires pour vous aider à créer les embeddings.

L'assistant peut également remplir automatiquement les processeurs nécessaires pour gérer les défaillances lors de l'ingestion et du traitement des données.

Créons maintenant le pipeline d'ingestion. Je nomme le pipeline coco_e5. Une fois le pipeline créé avec succès, vous pouvez immédiatement l'utiliser pour générer les embeddings en réindexant les données indexées d'origine vers un nouvel index dans l'assistant. Cliquez sur Réindexer pour lancer le processus.

Pour des configurations plus complexes, nous pouvons utiliser l'API Elasticsearch.

Pour certains modèles, en raison de la manière dont ils ont été entraînés, il peut être nécessaire d'ajouter certains textes à l'entrée réelle avant de générer les enchâssements, faute de quoi les performances s'en trouveront dégradées.

Par exemple, avec le e5, le modèle s'attend à ce que le texte d'entrée suive "passage : {content of passage}". Utilisons les pipelines d'ingestion pour y parvenir : Nous allons créer un nouveau pipeline d'ingestion vectorize_descriptions. Dans ce pipeline, nous allons créer un nouveau champ temporaire temp_desc, ajouter "passage : " au texte description, faire passer temp_desc par le modèle pour générer des enchâssements de texte, puis supprimer le champ temp_desc.

En outre, nous pourrions vouloir spécifier le type de quantification que nous voulons utiliser pour le vecteur généré. Par défaut, Elasticsearch utilise int8_hnsw, mais ici je veux Better Binary Quantization (ou bqq_hnsw), qui réduit chaque dimension à une précision d'un seul bit. Cela permet de réduire l'empreinte mémoire de 96% (ou 32x) au prix d'une plus grande précision. J'opte pour ce type de quantification parce que je sais que j'utiliserai plus tard un reranker pour améliorer la perte de précision.

Pour ce faire, nous allons créer un nouvel index nommé coco_multi, et spécifier les mappings. La magie réside ici dans le champ vector_description, où nous spécifions que le type de l'index_optionsest bbq_hnsw.

Nous pouvons maintenant réindexer les documents originaux dans un nouvel index, avec notre pipeline d'ingestion qui va "vectoriser" ou créer des embeddings pour le champ des descriptions.

Et c'est tout ! Nous avons déployé avec succès un modèle multilingue avec Elasticsearch et Kibana et appris étape par étape comment créer les vector embeddings avec vos données avec Elastic, soit via l'interface utilisateur Kibana, soit avec l'API Elasticsearch. Dans la deuxième partie de cette série, nous explorerons les résultats et les nuances de l'utilisation d'un modèle multilingue. En attendant, vous pouvez créer votre propre cluster Cloud pour essayer la recherche sémantique multilingue en utilisant notre modèle E5 prêt à l'emploi sur la langue et l'ensemble de données de votre choix.

Traditionnellement, la gestion des robots d'indexation était un processus manuel et sujet aux erreurs. Il s'agissait de modifier les configurations directement dans l'interface utilisateur et de se débattre avec le clonage des configurations de crawl, le retour en arrière, la gestion des versions, etc. Traiter les configurations des robots comme du code résout ce problème en offrant les mêmes avantages que ceux que nous attendons du développement de logiciels : répétabilité, traçabilité et automatisation.

Ce flux de travail facilite l'intégration de l'Open Web Crawler dans votre pipeline CI/CD pour les retours en arrière, les sauvegardes et les migrations, tâches qui étaient beaucoup plus délicates avec les Elastic Crawlers précédents, tels que l'Elastic Web Crawler ou l'App Search Crawler.

Dans cet article, nous allons apprendre à.. :

• Gérer nos configurations de crawl en utilisant GitHub

• Disposer d'une installation locale pour tester les pipelines avant de les déployer

• Créer une configuration de production pour exécuter le robot d'exploration avec de nouveaux paramètres à chaque fois que nous apportons des modifications à notre branche principale.

Vous pouvez trouver le dépôt du projet ici. Pour l'instant, j'utilise Elasticsearch 9.1.3 et Open Web Crawler 0.4.2.

Produits requis

• Bureau Docker

• Instance Elasticsearch

• Machine virtuelle avec accès SSH (par exemple, AWS EC2) et Docker installé.

Étapes

1. Structure des dossiers

2. Configuration du robot

3. Fichier Docker-compose (environnement local)

4. Actions Github

5. Tests au niveau local

6. Déploiement vers prod

7. Modifications et redéploiement

Structure des dossiers

Pour ce projet, nous aurons la structure de fichier suivante :

Configuration du robot

Sous crawler-config.yml,, nous mettrons les éléments suivants :

Il s'agit d'une recherche à partir de https://web-scraping.dev/products, un site fictif pour les produits. Nous ne parcourrons que les trois premières pages du produit. Le paramètre max_crawl_depth empêchera le robot d'exploration de découvrir d'autres pages que celles définies comme seed_urls en n'ouvrant pas les liens qu'elles contiennent.

Elasticsearch host et api_key seront alimentés dynamiquement en fonction de l'environnement dans lequel nous exécutons le script.

Fichier Docker-compose (environnement local)

Pour le site local docker-compose.yml,, nous allons déployer le crawler et un seul cluster Elasticsearch + Kibana, de sorte que nous puissions facilement visualiser nos résultats de crawling avant de les déployer en production.

Notez que le crawler attend qu'Elasticsearch soit prêt à fonctionner.

Actions Github

Nous devons maintenant créer une action GitHub qui copiera les nouveaux paramètres et exécutera le crawler dans notre machine virtuelle à chaque poussée vers main. Ainsi, nous disposons toujours de la dernière configuration déployée, sans avoir à entrer manuellement dans la machine virtuelle pour mettre à jour les fichiers et exécuter le crawler. Nous allons utiliser AWS EC2 comme fournisseur de machines virtuelles.

La première étape consiste à ajouter l'hôte (VM_HOST), l'utilisateur de la machine (VM_USER), la clé RSA SSH (VM_KEY), l'hôte Elasticsearch (ES_HOST) et la clé API Elasticsearch (ES_API_KEY) aux secrets d'action GitHub :

De cette manière, l'action pourra accéder à notre serveur pour copier les nouveaux fichiers et exécuter le crawl.

Maintenant, créons notre fichier .github/workflows/deploy.yml:

Cette action exécutera les étapes suivantes à chaque fois que des modifications seront apportées au fichier de configuration du crawler :

1. Renseigner l'hôte Elasticsearch et la clé API dans la configuration yml

2. Copier le dossier config sur notre VM

3. Se connecter via SSH à notre VM

4. Exécuter le crawl avec la configuration que nous venons de copier depuis le repo

Tests au niveau local

Pour tester notre crawler localement, nous avons créé un script bash qui remplit l'hôte Elasticsearch avec l'hôte local de Docker et démarre un crawl. Vous pouvez lancer ./local.sh pour l'exécuter.

Regardons Kibana DevTools pour confirmer que le site web-crawler-index a été correctement renseigné :

Déploiement vers prod

Nous sommes maintenant prêts à pousser vers la branche principale, ce qui déploiera le crawler dans votre machine virtuelle et commencera à envoyer des logs à votre instance Serverless Elasticsearch.

Cela déclenchera l'action GitHub, qui exécutera le script de déploiement dans la machine virtuelle et commencera l'exploration.

Vous pouvez confirmer que l'action a été exécutée en allant sur le dépôt GitHub et en visitant l'onglet "Actions" :

Modifications et redéploiement

Vous avez peut-être remarqué que le site price de chaque produit fait partie du champ "body" du document. L'idéal serait de stocker le prix dans un champ distinct afin de pouvoir utiliser des filtres.

Ajoutons cette modification au fichier crawler.yml afin d'utiliser des règles d'extraction pour extraire le prix de la classe CSS product-price:

Nous constatons également que le prix comprend un signe de dollar ($), que nous devons supprimer si nous voulons exécuter des requêtes de plage. Nous pouvons utiliser un pipeline d'acquisition pour cela. Notez que nous y faisons référence dans notre nouveau fichier de configuration du crawler ci-dessus :

Nous pouvons exécuter cette commande dans notre cluster Elasticsearch de production. Pour celui de développement, comme il est éphémère, nous pouvons intégrer la création du pipeline dans le fichier docker-compose.yml en ajoutant le service suivant. Notez que nous avons également ajouté un depends_on au service crawler afin qu'il démarre après la création réussie du pipeline.

Exécutons maintenant `./local.sh` pour voir les changements localement :

C'est très bien ! Poussons maintenant la modification :

Pour confirmer que tout fonctionne, vous pouvez vérifier votre Kibana de production, qui devrait refléter les changements et afficher le prix comme un nouveau champ sans le signe du dollar.

Conclusion

Elastic Open Web Crawler vous permet de gérer votre crawler en tant que code, ce qui signifie que vous pouvez automatiser l'ensemble du pipeline - du développement au déploiement - et ajouter des environnements locaux éphémères et des tests sur les données explorées de manière programmatique, pour ne citer que quelques exemples.

Vous êtes invités à cloner le dépôt officiel et à commencer à indexer vos propres données à l'aide de ce flux de travail. Vous pouvez également lire cet article pour apprendre comment effectuer une recherche sémantique sur les index produits par le crawler.