# Recherche sémantique et embeddings : une autre façon d’indexer un site WordPress > La recherche native de WordPress compare des mots. La recherche par embeddings compare des sens. Voici comment fonctionne cette approche et comment l'intégrer sans tout reconstruire. - Auteur : Clément Hadrot - Publié le : 2023-11-14 - Mis à jour le : 2023-11-14 - Catégorie : IA & MCP - URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/recherche-semantique-embeddings-wordpress/ ## L’essentiel - La recherche WordPress native repose sur une correspondance de mots-clés en SQL - Les embeddings représentent le sens d'un texte sous forme de vecteur numérique - Une base vectorielle externe est presque toujours nécessaire en complément La recherche intégrée à WordPress, basée sur la fonction `WP_Query` et une correspondance de type `LIKE` en SQL, trouve ses limites dès qu'un visiteur formule sa requête différemment du vocabulaire utilisé dans les articles. Chercher « comment accélérer mon site » ne renverra rien si l'article concerné parle uniquement de « performance » et d'« optimisation », alors que le sens recherché est exactement le même. C'est précisément le problème que la recherche sémantique, basée sur les embeddings, vient résoudre. Cet article explique le principe de fonctionnement de cette approche et la façon de l'intégrer à un site WordPress sans repartir de zéro sur le moteur de recherche existant. ## Ce qu'est un embedding Un embedding est une représentation numérique d'un texte sous la forme d'un vecteur, c'est-à-dire une liste de plusieurs centaines ou milliers de nombres décimaux. Cette représentation est produite par un modèle spécialisé, distinct des modèles de génération de texte, entraîné pour placer les textes de sens proche à des positions proches dans cet espace numérique. Concrètement, « accélérer un site » et « optimiser les performances » produiront deux vecteurs mathématiquement proches, même si aucun mot n'est commun aux deux expressions. La recherche sémantique consiste alors à transformer la requête de l'utilisateur en vecteur, puis à chercher dans la base de contenu les vecteurs les plus proches selon une mesure de distance (le plus souvent la similarité cosinus), plutôt que de comparer des chaînes de caractères. ## Pourquoi WordPress seul ne suffit pas MySQL, le moteur de base de données historique de WordPress, n'est pas conçu pour ce type de recherche par proximité vectorielle à grande échelle. Chercher les vecteurs les plus proches parmi plusieurs milliers d'articles nécessite un index spécialisé, que les extensions MySQL classiques ne fournissent pas nativement sur les versions utilisées majoritairement par les hébergements mutualisés en 2023. En pratique, la plupart des intégrations combinent WordPress avec un service externe dédié : une base de données vectorielle indépendante, interrogée via une API REST depuis l'extension WordPress. > L'essentiel à retenir : La recherche WordPress native repose sur une correspondance de mots-clés en SQL ; Les embeddings représentent le sens d'un texte sous forme de vecteur numérique ; Une base vectorielle externe est presque toujours nécessaire en complément Ce service externe stocke les vecteurs générés pour chaque article, avec l'identifiant du contenu correspondant en métadonnée, et répond à une requête de recherche en renvoyant la liste des identifiants les plus pertinents. WordPress se charge ensuite d'aller chercher les articles correspondants via `WP_Query` avec un tableau d'identifiants (`post__in`), en respectant l'ordre de pertinence renvoyé par le service vectoriel. ## Construire l'index initial La mise en place démarre par la génération des embeddings pour l'ensemble du contenu existant. Ce traitement s'effectue idéalement via WP-CLI, dans une commande personnalisée qui parcourt les articles et appelle l'API d'embeddings pour chacun : ``` wp mon-extension indexer-embeddings --post_type=post --batch-size=20 ``` Ce script parcourt les articles par lots, envoie le contenu de chacun à l'API d'embeddings, puis transmet le vecteur obtenu à la base vectorielle avec l'identifiant WordPress associé. Traiter par lots limite le risque de dépassement de délai d'exécution PHP sur un catalogue de plusieurs centaines d'articles, un piège fréquent si l'indexation est lancée en une seule requête via l'interface d'administration. ## Maintenir l'index à jour Une fois l'index initial construit, il faut le maintenir synchronisé avec les publications et modifications ultérieures. Le hook `save_post` est le point d'entrée naturel pour déclencher une réindexation, mais il ne doit surtout pas appeler l'API d'embeddings de façon synchrone à chaque enregistrement, sous peine de ralentir l'expérience d'édition. La bonne pratique consiste à planifier la réindexation via `wp_schedule_single_event()`, pour un traitement en arrière-plan quelques secondes après la sauvegarde. - Déclencher la réindexation sur `save_post`, uniquement pour les statuts publiés - Différer le traitement réel via une tâche planifiée asynchrone - Supprimer l'entrée correspondante côté base vectorielle sur le hook `before_delete_post` > Une recherche sémantique mal maintenue devient vite pire qu'une recherche classique : elle renvoie du contenu qui n'existe plus. ## En résumé La recherche par embeddings apporte une amélioration nette pour les visiteurs qui ne formulent pas leur requête avec le vocabulaire exact du site, un cas fréquent sur les blogs à forte volumétrie de contenu. Sa mise en œuvre sur WordPress passe presque toujours par un service vectoriel externe, interrogé en complément du moteur de recherche natif, avec une attention particulière portée à la synchronisation entre le contenu WordPress et son index vectoriel dans la durée.