Une marketplace ajoute « canapé » et « banquette » dans un groupe de synonymes bidirectionnel pour réduire les recherches sans résultat. Les canapés apparaissent alors sur des requêtes de banquettes automobiles, tandis que les accessoires pour banquette remontent dans le mobilier. Le rappel progresse, mais la pertinence et les facettes deviennent incohérentes.
Le problème s’aggrave lorsque chaque équipe ajoute ses propres listes dans le moteur, le code ou un fichier importé. Une règle destinée à une catégorie s’applique partout, les suppressions ne sont pas propagées et personne ne peut expliquer pourquoi une référence exacte a été élargie. Le vocabulaire devient une couche invisible du ranking.
Le vrai enjeu des synonymes sur une marketplace opérateur est d’étendre une requête seulement lorsque l’intention et le contexte le justifient. Contre-intuitivement, une règle unidirectionnelle et très locale résout souvent davantage de besoins qu’un grand dictionnaire symétrique.
Vous allez comprendre comment collecter les formulations, distinguer équivalence, alias, abréviation et correction, puis fermer portée, tests et rollback. Chaque règle possède exemples positifs et négatifs ; les métriques mesurent résultats utiles, reformulations, commandes et effets de bord.
Borner la promesse des synonymes
Nommer le défaut de recherche
Un synonyme répond à un écart de vocabulaire entre requête et catalogue. Il ne répare pas une mauvaise taxonomie, un attribut absent, une offre indisponible ou une erreur de ranking. Le diagnostic classe la cause avant de proposer une règle.
L’équipe part de requêtes réelles avec peu de bons résultats, puis identifie ce qui aurait dû être retrouvé. Une baisse de zéro résultat ne suffit pas si les nouveaux candidats sont faux. La sortie attendue est une amélioration annotée.
Définir le coût d’un faux positif
Une extension trop large peut masquer une référence exacte, polluer une facette ou créer une incompatibilité. Le coût dépend de la catégorie : une approximation décorative et une pièce technique ne portent pas le même risque.
Le contrat fixe pertinence minimale, positions protégées et segments sensibles. Une référence, une norme ou un modèle exact garde priorité. L’opérateur accepte parfois moins de rappel pour éviter une commande impossible.
Observer le vocabulaire réel
Rapprocher requêtes et catalogue
Logs de recherche, reformulations, clics, tickets et échanges vendeurs révèlent les mots employés. Le catalogue apporte noms normalisés, attributs, marques et compatibilités. Les sources sont datées et segmentées par langue, pays et catégorie.
Les requêtes sensibles sont agrégées et protégées. Bots, tests internes et campagnes sont exclus. Une formulation fréquente n’est pas automatiquement correcte ; elle devient un candidat à analyser avec les résultats attendus.
Construire une file d’opportunités
Chaque candidat contient requête source, volume, résultats actuels, reformulation, catégorie et valeur estimée. Les cas sans résultat mais à forte intention passent avant les variantes déjà bien servies. Un owner accepte ou rejette avec motif.
Les experts métier ajoutent exemples et contre-exemples. Le support signale les mots ambigus ; commercial apporte les usages vendeurs. Le registre ne reçoit aucune règle sans preuve de besoin et périmètre testable.
La file calcule une priorité à partir des recherches exposées, de la valeur des intentions, de l’absence de bons candidats et du coût d’erreur. Elle conserve aussi les opportunités rejetées pour éviter leur retour mensuel sans information nouvelle. Chaque proposition possède owner, date de décision, source des données et prochaine condition de réexamen.
Distinguer les types de règles
Séparer équivalence et expansion
Deux termes vraiment interchangeables dans le contexte peuvent former une équivalence. Une expansion unidirectionnelle ajoute un terme plus précis ou normalisé sans modifier le sens inverse. Le choix détermine candidats et scoring.
« Téléphone portable » et « mobile » peuvent être proches dans une catégorie, mais une règle globale toucherait accessoires et forfaits. Le registre exige phrase d’intention et exemples avant de choisir la direction.
Traiter alias, abréviation et faute
Un alias de marque, une abréviation métier, une translittération et une faute fréquente ont des sources différentes. Ils peuvent utiliser correction, normalisation ou mapping d’entité plutôt qu’un synonyme lexical.
La requête originale reste visible dans la trace. L’interface peut signaler une correction et permettre de revenir en arrière. Une forme rare ou ambiguë n’est pas normalisée silencieusement sans seuil de confiance.
La classification est exclusive au moment de la compilation : une même relation ne passe pas successivement par correction puis synonymie sans que ce chemin soit testé. Les transformations conservent ordre, poids et motif. Un diagnostic affiche la chaîne complète afin que l’équipe repère une dérive créée par l’interaction de deux mécanismes pourtant corrects isolément.
Limiter langue et catégorie
Attacher la règle à une intention
Langue, marché, catégorie, type de surface et éventuel attribut définissent la portée. Une règle française de bricolage ne s’applique pas à une catégorie automobile portant le même mot. Le contexte est résolu avant expansion.
Le moteur reçoit requête, locale et catégories candidates ; il retourne les règles éligibles avec version. Une portée vide n’est jamais interprétée comme globale par défaut. Les exceptions sont explicites.
Gérer les catégories multiples
Une requête peut viser plusieurs univers. Le système conserve d’abord les candidats exacts, puis applique des expansions propres à chaque branche. Le reranking évite qu’une catégorie élargie écrase la catégorie la plus probable.
Les facettes sont calculées sur les candidats réellement retenus. Une règle ne fabrique pas une facette incompatible. Le diagnostic montre contribution de chaque portée au résultat final.
Une table de portée relie catégorie stable, descendants autorisés et exclusions. Lorsqu’une taxonomie fusionne ou déplace une branche, un job simule l’effet sur les règles avant publication. Les portées devenues vides sont suspendues ; celles dont le volume explose attendent une nouvelle approbation au lieu d’hériter aveuglément de la hiérarchie.
Traiter marques, unités et références
Reconnaître les entités avant expansion
Marques, gammes, modèles, normes et références possèdent une identité catalogue. Les alias se rattachent à cette entité plutôt qu’à un mot libre. Une marque devenue nom commun exige une règle contextualisée.
La reconnaissance protège les recherches exactes. Si un identifiant correspond, alors le moteur privilégie l’entité et ses compatibilités. Les expansions lexicales viennent seulement après ce candidat.
Normaliser unités et formes
Millimètres, pouces, puissances, volumes et pluriels demandent normalisation structurée. Convertir une unité n’est pas déclarer deux chaînes synonymes ; le résultat doit respecter valeur, tolérance et attribut.
Les règles gèrent séparateurs, accents et casse sans perdre l’original. Une référence où la casse ou le tiret porte du sens conserve son traitement. Les tests couvrent collisions entre modèles proches.
Le parseur produit tokens, entités, valeurs normalisées et unités avec leur confiance. Le moteur ne convertit une mesure que si la catégorie possède l’attribut correspondant et une tolérance autorisée. Les valeurs sources restent dans la trace ; toute erreur de conversion peut être retirée par version sans reconstruire les documents d’origine.
Refuser les fausses équivalences
Documenter les contre-exemples
Chaque proposition possède requêtes où elle ne doit pas s’appliquer. Les homonymes, catégories voisines, négations et accessoires forment des contre-exemples fréquents. Une règle sans négatif reste incomplète.
Le jeu d’évaluation protège ces cas à chaque version. Une nouvelle expansion qui améliore dix requêtes mais casse une référence critique est rejetée. Les exceptions ne s’ajoutent pas indéfiniment pour sauver une règle trop large.
Éviter les relations commerciales déguisées
Substitut, complément, compatible, meilleur marché et sponsorisé ne sont pas des synonymes. Ils appartiennent à recommandation, compatibilité ou merchandising avec leur propre transparence. Les mélanger falsifie l’intention.
Une marque ne peut pas acheter une équivalence avec un terme générique. Les règles commerciales ont emplacement, plafond et libellé. Le registre lexical reste gouverné par la pertinence.
Versionner le registre
Fermer le schéma de règle
Identifiant, type, termes, direction, langue, portée, priorité, dates, owner et preuve composent la règle. Les exemples positifs et négatifs sont obligatoires. Un statut distingue brouillon, test, actif, suspendu et retiré.
Les chevauchements sont détectés avant publication. Deux règles en chaîne peuvent étendre au-delà de l’intention. Le compilateur limite profondeur et signale les cycles.
Organiser revue et expiration
Search propose, métier valide le sens et data vérifie l’évaluation. Les règles sensibles exigent un second approbateur. Une expiration force la revue des termes saisonniers, marques ou campagnes.
La modification crée une version et un diff. Le rollback restaure l’artefact précédent de façon atomique. Les décisions gardent auteur, motif et ticket sans permettre une édition directe en production.
Le pipeline de publication valide schéma, cycles, volume estimé et suite de tests, puis signe un artefact immuable. Recherche charge cet artefact par identifiant et confirme son checksum. Un canary reçoit la nouvelle version ; le monitoring compare taux d’application et latence avant de déplacer le reste du trafic. L’ancien artefact reste chaud pendant la fenêtre de rollback.
Appliquer au bon étage
Choisir indexation ou requête
L’expansion à la requête est réversible et contextualisable ; l’expansion à l’index peut simplifier certains usages mais élargit durablement les documents. Le choix dépend du type de règle, du volume et du besoin d’explication.
Les deux voies n’appliquent pas la même règle par accident. Un artefact compilé indique cible et version. Le déploiement en shadow compare candidats avant de modifier le trafic.
Conserver poids et provenance
Le terme original garde souvent un poids supérieur à l’expansion. Exact, alias validé et rapprochement large portent des boosts différents. Le ranking reçoit la provenance pour expliquer le score.
L’entrée, les expansions et les candidats sont journalisés par échantillon avec rétention limitée. Un endpoint de diagnostic reproduit la décision depuis requête, contexte et version, sans modifier le registre.
Le service retourne terme source, expansions, poids, portée et règles refusées. Les consommateurs appliquent un contrat stable et ne réinterprètent pas la direction. Une indisponibilité utilise la dernière version saine ; si elle expire au-delà du seuil, alors la recherche revient aux termes originaux et signale la dégradation plutôt que d’ouvrir toutes les relations.
Évaluer hors ligne
Construire des jugements pertinents
Le jeu réunit requêtes, résultats attendus, acceptables et faux. Les annotateurs disposent du contexte de catégorie et des attributs. Les désaccords révèlent souvent une règle métier ou une taxonomie à clarifier.
Références exactes, longue traîne, fautes et homonymes sont surreprésentés selon le risque. Une règle n’est pas jugée seulement sur les requêtes qui ont motivé sa création. Les données nouvelles restent séparées de l’entraînement éventuel.
Les jugements conservent auteur, consigne, date et niveau d’accord. Un arbitre traite les divergences sans effacer les annotations initiales. La suite sépare un noyau régressif stable d’un échantillon récent, afin qu’une amélioration sur les requêtes nouvelles ne masque pas la perte d’un besoin historique important.
Le corpus inclut également des requêtes qui ne doivent produire aucune expansion. Ces témoins mesurent la tendance du moteur à intervenir partout. Ils couvrent noms propres, références, négations et formulations déjà satisfaites ; leur dégradation bloque la version même si les opportunités ciblées progressent.
Comparer rappel et précision
Rang, précision, rappel, zéro résultat et faux candidats sont calculés par segment. Les seuils varient selon la verticalité. La suite bloque les régressions critiques même si la moyenne progresse.
Par exemple, si une expansion réduit de 12 % les zéros de résultat mais double les accessoires incorrects dans le top cinq, alors elle reste en brouillon. Une portée plus étroite ou une règle unidirectionnelle est retestée.
Expérimenter en production
Définir cohorte et garde-fous
L’expérience nomme règles, requêtes éligibles, durée, métrique et seuils d’arrêt. L’assignation reste stable. Les logs conservent version du registre et de l’index pour ne pas mélanger plusieurs changements.
Clic utile, ajout, commande servie, reformulation, retour et abandon complètent le zéro résultat. Les références exactes et catégories sensibles forment des garde-fous. Les métriques tardives attendent leur maturité.
Interpréter par intention
Une moyenne positive peut cacher une dégradation sur mobile, une langue ou les nouveaux produits. Les analyses segmentent type de règle et requête. Une hausse du clic ne vaut pas pertinence si le retour augmente.
Si le seuil de faux candidats est franchi, alors le kill switch désactive l’artefact concerné sans retirer tout le moteur. Les événements restent disponibles pour diagnostic et la cohorte revient à la référence.
Monitorer et corriger
Surveiller règles et données
Le monitoring suit taux d’expansion, règles sans usage, collisions, latence, zéro résultat et reformulations. Un changement catalogue peut rendre une règle inutile ou dangereuse. Les alertes portent owner et portée.
Un seuil protège les expansions anormalement fréquentes. Si une version s’applique à dix fois plus de requêtes que prévu, alors elle repasse en shadow. Le registre sain reste disponible pour rollback.
Traiter les incidents de pertinence
Le runbook collecte requête, contexte, candidats, règles, score et version. Il distingue synonymes, index, catalogue et ranking. La correction cible la couche responsable au lieu d’ajouter une nouvelle exception au hasard.
Scénario : une règle globale fait remonter des pièces incompatibles. L’équipe la suspend, identifie commandes exposées et ajoute un test régressif. La reprise exige portée corrigée, évaluation verte et canary sous seuil.
Adapter la méthode et éviter les erreurs
Pour qui cette gouvernance des synonymes convient
Elle convient aux marketplaces avec plusieurs catégories, langues ou vocabulaires métiers. Un petit catalogue peut commencer avec aliases de références et quelques expansions locales, mais garde registre, exemples et versions.
Search porte le pipeline ; catalogue les entités ; métier le sens ; data l’évaluation ; commercial les demandes ; run le rollback. Chaque owner accepte une sortie et un seuil.
Erreurs fréquentes avec les synonymes de recherche
Créer un dictionnaire global, rendre toutes les relations bidirectionnelles, confondre compatible et synonyme, ignorer les références exactes et mesurer seulement les zéros sont les erreurs majeures. Elles gagnent du rappel au prix de faux résultats.
Une autre erreur consiste à empiler des exceptions dans le moteur. Le registre doit pouvoir expliquer la règle et sa portée ; sinon la taxonomie, les entités ou le ranking demandent une correction différente.
Plan d’action pour gouverner les synonymes
Semaines 1 à 4 : sources et registre
La première semaine sélectionne deux catégories et cent requêtes à faible satisfaction. L’équipe classe vocabulaire, données manquantes, taxonomie et ranking. La deuxième crée types, portées, exemples et contre-exemples dans le registre.
Les semaines trois et quatre construisent reconnaissance d’entités, compilation et diagnostic. Search branche un artefact en shadow ; métier valide le sens ; data annote requêtes exactes, longue traîne et homonymes. Les règles commerciales restent hors couche lexicale.
Semaines 5 à 8 : canary et run
La cinquième semaine ouvre une cohorte avec métriques et garde-fous. L’instrumentation conserve provenance, version et candidats ; le monitoring suit application anormale et collisions. La sixième teste rollback et changement catalogue.
Les semaines sept et huit attendent commandes et retours, puis arbitrent par intention. Le go exige précision protégée, reformulation réduite et références exactes intactes. Toute langue non annotée reste hors expansion automatique.
Le comité examine les règles sans usage et les opportunités rejetées afin d’éviter un registre gonflé. Il conserve seuils, limites, owners et date d’expiration. Une nouvelle source de règles doit alimenter le même workflow plutôt que publier directement.
La recette finale confie vingt requêtes dégradées à une équipe indépendante. Elle doit expliquer le candidat, suspendre une règle, observer le retour à la référence et réactiver une version corrigée depuis les outils prévus. Les traces, dashboards et runbooks doivent suffire ; toute correction directe dans le moteur bloque le passage à l’échelle.
- À faire d’abord : classer les causes sur cent requêtes réelles.
- À tester ensuite : homonymes, références exactes, unités et catégories multiples.
- À différer : les langues sans jugements suffisamment fiables.
- À refuser : toute relation globale sans contre-exemple et rollback.
Guides complémentaires pour l’opérateur
Structurer catalogue et contrôle
Le catalogue PIM marketplace fournit entités, attributs et taxonomie nécessaires aux portées.
Les écrans du back-office opérateur structurent registre, approbations et incidents.
Borner la première cohorte
Le MVP marketplace avant ouverture aide à limiter les règles indispensables.
La méthode pour ouvrir une première catégorie permet de constituer un jeu de requêtes réel.
Conclusion : étendre avec des preuves
Les synonymes marketplace améliorent la recherche lorsqu’ils répondent à un écart de vocabulaire prouvé, pas à tout défaut de catalogue.
Types, portées, entités, contre-exemples et versions empêchent une expansion locale de devenir une règle globale incontrôlée.
Tests, expériences et monitoring protègent précision et références exactes. Le rollback rend chaque décision réversible et explicable.
Pour concevoir ce registre lexical et son exploitation, Dawap peut vous accompagner dans votre marketplace opérateur.
