Correspondances phrase-vers-filtre : recherche sémantique pour les filtres de produits

Cet article explique comment nous générons et enrichissons les correspondances phrase-vers-filtre qui alimentent notre système d'extraction de filtres. Ces correspondances connectent des phrases en langage naturel issues de requêtes de recherche à des filtres de produits structurés.

Le problème : extraire des filtres à partir du langage naturel

Lorsque les utilisateurs recherchent « mini pc with 16gb ram », nous devons extraire :

Facteur de forme : Mini PC
Mémoire principale : 16

Mais les utilisateurs expriment la même intention de nombreuses façons :

« 16gb ram mini pc »
« mini computer 16 gb memory »
« small pc 16gb »
« compact desktop with 16 gigs »

Nous avons besoin d'un système qui mappe toutes ces variantes de phrases aux bonnes valeurs de filtres.

Processus en deux étapes

Nous générons les correspondances de phrases en deux étapes :

Étape 3a : générer les phrases de base à partir des caractéristiques produits à l'aide de permutations et de règles spécifiques aux caractéristiques
Étape 4 : enrichir avec la similarité sémantique à l'aide de plongements

Cette approche hybride combine la précision basée sur des règles avec la flexibilité sémantique.

Étape 3a : génération des phrases de base

Métadonnées des caractéristiques

Chaque caractéristique produit possède des métadonnées dans la séquence de caractéristiques :

Titre : nom de la catégorie (par exemple « Processing » pour les caractéristiques de processeur)
Unité : unité de mesure (par exemple « GB » pour la mémoire, « GHz » pour la fréquence)

Ces métadonnées guident la génération de phrases.

Génération par permutations

Pour chaque valeur de caractéristique, nous générons toutes les permutations de :

Titre : « processor »
Clé de caractéristique : « series »
Valeur : « i5 »
Unité : (aucune pour « series »)

Cela produit :

« processor series i5 »
« series processor i5 »
« i5 processor series »
« i5 series processor »
« processor i5 »
« series i5 »
« i5 »

Toutes les permutations garantissent que nous correspondons aux requêtes quel que soit l'ordre des mots.

Combinaisons valeur + unité

Pour les caractéristiques avec unités (mémoire, stockage, fréquence), nous générons à la fois les variantes avec espace et sans espace :

« 16 gb » (avec espace)
« 16gb » (sans espace)

Ces variantes se combinent avec d'autres composants :

« 16gb ram »
« ram 16gb »
« processor 16gb »

Règles de suffixe pour les ports

Pour les caractéristiques de connectivité (USB, HDMI, DisplayPort), nous ajoutons des suffixes de port :

« usb port »
« usb ports »
« 2 usb ports »
« hdmi port »

Cela correspond à des requêtes comme « mini pc with 2 hdmi ports ».

Règles spécifiques aux caractéristiques

Chaque type de caractéristique possède une génération de phrases personnalisée :

Série de processeur (i3, i5, série N) :

Les désignations de processeurs Core génèrent des variantes : nom du fabricant, marque du cœur, formes combinées
Les processeurs de la série N (N100, etc.) créent des schémas de combinaison similaires
Chacun génère plusieurs permutations avec « processor »

Mémoire principale :

Les valeurs numériques génèrent des variantes GB avec et sans espace (« 16gb », « 16 gb »)
Ajout automatique des qualificatifs « ram » et « memory » (« 16gb memory », « 16 gb ram »)

Stockage SSD :

Les valeurs numériques génèrent des variantes GB (« 512gb », « 512 gb »)
Génère automatiquement des variantes TB pour les valeurs ≥ 1024 (par exemple, 1024GB → 1TB)
Ajout automatique des qualificatifs « ssd » et « storage » (« 512gb ssd », « 512 gb storage »)

Facteur de forme :

Mini PC → plusieurs variantes, y compris la forme sans espace
Tout-en-un → « all in one », « aio », formes abrégées
Client léger → variantes avec/sans espace
PC industriel → formes abrégées et complètes

Génération :

Les valeurs de génération numériques deviennent : « 12th gen », « 12th generation », « gen 12 »

Cœurs :

2 → « dual core »
4 → « quad core »
6 → « hexa core »
8 → « octa core »
Tous génèrent des variantes « [n] core processor »

Ethernet :

« 1000 » → [« gigabit ethernet », « gbe », « 1gbps »]
« 2500 » → [« 2.5gbe », « 2.5 gigabit », « 2.5gbps »]

Système d'exploitation :

« Windows 11 » → [« windows », « windows 11 », « win 11 »]
« Ubuntu » → [« linux », « ubuntu »]
« FreeDOS » → [« freedos », « no os », « without os »]

Liste blanche pour les valeurs autonomes

Seules certaines caractéristiques autorisent la correspondance de valeurs autonomes pour éviter les faux positifs :

Série : « i3 », « i5 », « N100 » (mais pas les lettres simples)
Modèle de processeur : « N100 », « 1335U »
Système d'exploitation : « Windows », « Linux », « Ubuntu »
Génération : « 12th », « 13th », « 14th »
Marque du processeur : « Intel », « ARM »

Par exemple, « 2 » ne doit pas correspondre à « 2 cores » lorsque la requête est « 2 hdmi ports ». Le contrôle de longueur empêche les lettres simples ou les valeurs ambiguës très courtes d'être mises en correspondance de manière autonome. Les caractéristiques avec des composants d'unité explicites, comme Ethernet ou les ports, ne génèrent des combinaisons autonomes que lorsqu'elles sont qualifiées par leur unité.

Prévention des collisions

Les valeurs de mémoire et de stockage se chevauchent (les deux ont 64, 128, 256, etc.). L'étape 4 applique des règles de plage de valeurs pour lever l'ambiguïté :

≤ 64 Go : mémoire principale (RAM)
≥ 128 Go : stockage SSD
Plage de 65 à 127 Go : ignorée (ambiguë)

Les phrases avec des qualificatifs explicites (« ram »/« memory » ou « ssd »/« storage ») outrepassent cette règle et peuvent correspondre à n'importe quelle valeur.

De plus, les termes généraux vagues qui correspondent à trop de filtres sans rapport sont exclus lors de la résolution des collisions par post-traitement : des termes comme « connectivity », « audio », « display », « processor » et « physical » créent trop d'ambiguïté entre plusieurs facettes.

Étape 4 : expansion sémantique

Extraction de n-grammes

Nous extrayons des phrases fréquentes des requêtes de recherche réelles, allant de mots uniques (1-grammes comme « mini ») à des séquences plus longues (jusqu'à 6-grammes comme « mini pc with 16gb ram ssd »). Seules les phrases apparaissant au moins 3 fois sont conservées. Cette approche de filtrage réduit le bruit tout en préservant les habitudes de langage réelles des utilisateurs.

Génération de textes de recherche pour les filtres

Pour chaque valeur de filtre, nous générons des textes de recherche :

Mémoire principale : 16 :

« 16gb ram memory »
« 16 main memory »
« main memory 16 »

Stockage SSD : 512 :

« 512gb storage ssd »
« 512 ssd storage »
« ssd storage 512 »

Ces textes de recherche représentent le filtre dans l'espace des plongements.

Plongement et correspondance

Nous convertissons à la fois les phrases de requête et les textes de recherche des filtres en plongements, puis calculons la similarité cosinus entre eux. Les phrases dont les scores de similarité dépassent un seuil configuré sont ajoutées à la correspondance de ce filtre.

Phrases de départ manuelles

Nous injectons des phrases de départ manuelles à haute confiance avant l'expansion :

"Series:i5": [
    "i5",
    "core i5",
    "intel i5",
    "intel core i5",
    "i5 processor",
    "cpu i5",
]

Ces phrases de départ représentent les phrases de base dont nous savons qu'elles sont correctes pour chaque filtre. En les incluant avec des scores de similarité maximaux, elles guident l'algorithme d'expansion pour trouver des phrases apparentées ayant des significations similaires. Ces phrases de départ obtiennent toujours une similarité de 1,0 et guident l'expansion.

Plongement incrémental

Nous mettons en cache les plongements pour les phrases et les textes de recherche des filtres. Lorsque de nouvelles requêtes arrivent :

Charger les plongements existants
Plonger uniquement les nouvelles phrases
Les ajouter au cache

Cela évite de ré-plonger les données inchangées. Voir Stratégie de plongement pour plus de détails.

Résolution des collisions

Après la correspondance par similarité, nous résolvons les collisions entre les filtres Mémoire et Stockage :

Désambiguïsation basée sur les nombres :

Pour les phrases ambiguës contenant des nombres : si la phrase a une valeur ≤ 64, la conserver uniquement pour Mémoire ; si > 64, la conserver uniquement pour Stockage
Cela empêche « 16gb » de correspondre aux filtres de stockage SSD et « 512gb » de correspondre aux filtres de mémoire

Les qualificatifs explicites outrepassent les règles :

Les phrases avec les mots-clés « ram », « memory », « cpu », « processor » → Mémoire uniquement
Les phrases avec les mots-clés « ssd », « storage », « disk », « nvme », « drive » → Stockage uniquement
Exemple : « processor 8gb » correspond à Mémoire malgré son caractère numérique

Termes vagues :

Supprimer les phrases comme « connectivity », « audio », « display » qui correspondent à plusieurs filtres sans rapport

Format de sortie

Les correspondances finales sont triées par similarité (décroissante), puis par longueur (croissante) :

{
  "Main Memory:16": [
    {"phrase": "16gb ram", "similarity": 1.0},
# ... (details d'implémentation omis)

Intégration avec l'extraction de filtres

Ces correspondances alimentent l'algorithme d'extraction de filtres :

La requête arrive : « mini pc with 16gb ram »
Extraire les phrases : [« mini pc », « 16gb ram », « mini », « pc », « 16gb », « ram »]
Mettre en correspondance les phrases avec les filtres à l'aide des correspondances
Retourner les filtres : {"Form Factor": ["Mini PC"], "Main Memory": ["16"]}

Voir Algorithme d'extraction de filtres pour plus de détails.

Stockage et distribution

Les correspondances de phrases sont persistées sous forme de fichiers JSON et utilisées dans tout le système :

Fichier de correspondances de base : généré à l'étape 3a, contient les phrases basées sur des règles
Fichier de correspondances enrichies : généré à l'étape 4, contient les résultats de l'expansion sémantique

Les correspondances enrichies sont utilisées par :

Génération de pages de requête : extraction des filtres à partir du texte de requête
Service de recherche : API d'extraction de filtres en temps réel
Correspondance de produits : filtrage des produits par filtres extraits

Caractéristiques de performance

Génération de base (étape 3a) :

Le temps de traitement évolue avec le nombre de valeurs de filtres
Génère un grand nombre de variantes de phrases de base
L'utilisation de la mémoire reste modérée pendant la génération

Expansion sémantique (étape 4) :

Le temps de traitement évolue avec le volume de requêtes et la taille des plongements
La sortie contient significativement plus de phrases que la génération de base
Les besoins en mémoire augmentent en raison du stockage des plongements

L'expansion est limitée par le CPU en raison du calcul de similarité. L'utilisation de NumPy avec l'accélération BLAS accélère considérablement les opérations matricielles.

Intégration avec le pipeline SEO

La génération de correspondances de phrases correspond aux étapes 3a et 4 du pipeline SEO :

Étape 0 : Intégrer les données sources - Produits, pièces, articles
Étape 1 : Récupérer les requêtes - GSC, Google Ads, live, Algolia
Étape 2 : Combiner les requêtes - Fusionner toutes les sources
Étape 3a : Générer les correspondances de phrases de base ← Vous êtes ici
Étape 3b : Plonger les requêtes - Convertir en vecteurs
Étape 4 : Enrichir les correspondances de phrases ← Vous êtes ici
Étape 5 : Regrouper les requêtes - Regrouper en pages
Étape 6 : Correspondance de produits - Appariement requête-produit
Étape 7 : Construire les pages de requête - Générer le HTML
Étape 8 : Générer les recherches associées - Trouver les requêtes connexes
Étape 11 : Migrer vers Valkey - Charger dans le service de recherche

Voir Vue d'ensemble du pipeline SEO pour le flux complet.

Pourquoi deux étapes ?

La génération de base (étape 3a) fournit :

Précision : les phrases basées sur des règles correspondent exactement à ce que nous attendons
Couverture : les permutations garantissent que tous les ordres de mots sont couverts
Contrôle : les règles spécifiques aux caractéristiques intègrent la connaissance du domaine

L'expansion sémantique (étape 4) fournit :

Flexibilité : découvre des phrases auxquelles nous n'avions pas pensé
Langage réel des utilisateurs : apprend à partir de requêtes de recherche réelles
Synonymes : trouve des phrases équivalentes (« 16 gigs » pour « 16gb »)

Ensemble, elles équilibrent précision et rappel.

Références

Concepts techniques

Permutation - Wikipédia
Similarité cosinus - Wikipédia
N-gramme - Wikipédia
NumPy - Documentation officielle
BLAS - Wikipédia

Documentation des modèles

all-mpnet-base-v2 - Hugging Face
Sentence Transformers - Documentation officielle

Résumé

Nous générons des correspondances phrase-vers-filtre en deux étapes :

Étape 3a (génération de base) :

Générer toutes les permutations de titre, clé, valeur, unité
Appliquer des règles spécifiques aux caractéristiques (série de processeur, mémoire, stockage, facteur de forme)
Ajouter des suffixes de port pour les caractéristiques de connectivité
Liste blanche de valeurs autonomes pour des caractéristiques spécifiques
Produire l'ensemble de phrases de base à partir des règles

Étape 4 (expansion sémantique) :

Extraire des phrases n-grammes à partir de requêtes de recherche réelles
Plonger les phrases et les textes de recherche des filtres
Mettre en correspondance les phrases avec des scores de similarité supérieurs au seuil
Injecter des phrases de départ manuelles pour guider l'expansion
Résoudre les collisions mémoire/stockage
Produire un ensemble de phrases enrichies et désambiguïsées

Le résultat est une correspondance complète qui gère à la fois les phrases attendues (via les règles) et les variations inattendues (via la similarité sémantique). Ces correspondances alimentent l'extraction de filtres dans les pages de requêtes, la recherche et la correspondance de produits.

← Retour à l'index de documentation

Produits

Recherches et blogs populaires