Embedding et recherche vectorielle

Un embedding (plongement, en français) est la représentation d'un texte, d'une image ou de tout autre contenu sous la forme d'un vecteur, une liste de nombres qui encode son sens. Deux contenus proches par le sens ont des vecteurs proches, ce qui permet de les comparer par calcul plutôt que par les mots qu'ils partagent. C'est le fondement de la recherche vectorielle, du RAG et de nombreux usages SEO : regroupement de mots-clés, maillage interne, détection de contenus redondants.

Définition détaillée de l'embedding

Un ordinateur ne manipule que des nombres. Pour qu'un programme compare deux textes, il faut d'abord les convertir en une forme numérique. La méthode historique, l'encodage « one-hot », attribue à chaque mot du vocabulaire une position dans un très long vecteur, avec un 1 à sa position et des 0 partout ailleurs. La documentation du cours d'apprentissage automatique de Google en montre les limites : pour un vocabulaire de 5 000 mots, chaque vecteur compte 5 000 cases, presque toutes vides, et rien dans cette représentation n'indique que « crêpe » et « pancake » ont un rapport.

L'embedding résout ce problème en représentant chaque élément dans un espace de dimension bien plus faible, où la position est apprise à partir des données. Un modèle d'embedding lit d'énormes volumes de texte et apprend à placer les mots (puis les phrases, les paragraphes, les documents) de telle sorte que des contenus utilisés dans des contextes similaires se retrouvent proches. Le résultat est un vecteur dense : une liste de quelques centaines ou milliers de nombres décimaux, dont aucun n'a de signification isolée, mais dont l'ensemble situe le contenu dans un « espace sémantique ».

Le principe a été popularisé par word2vec, décrit en janvier 2013 par Tomas Mikolov et ses collègues de Google : des vecteurs de mots appris sur 1,6 milliard de mots en moins d'une journée, dans lesquels les relations de sens deviennent des opérations arithmétiques (le vecteur de « roi » moins celui de « homme » plus celui de « femme » tombe près de celui de « reine »). Les modèles actuels, construits sur l'architecture Transformer, produisent des embeddings contextuels : le même mot reçoit un vecteur différent selon la phrase où il apparaît, ce qui distingue la « banque » où l'on dépose de l'argent de la « banque » de données.

Comment mesurer la proximité de deux vecteurs

Une fois deux contenus convertis en vecteurs, leur proximité se calcule. La mesure la plus employée est la similarité cosinus, connue en recherche d'information sous le nom de cosinus de Salton : le cosinus de l'angle formé par les deux vecteurs, qui vaut 1 quand ils pointent dans la même direction (même sens), 0 quand ils sont orthogonaux (sans rapport) et -1 quand ils sont opposés. La documentation de l'API Gemini illustre ainsi la comparaison de « What is the meaning of life? » et « What is the purpose of existence? », dont la similarité est élevée, avec « How do I bake a cake? », dont elle est faible.

D'autres mesures existent : le produit scalaire et la distance euclidienne. Google précise dans la documentation de son API d'embeddings de texte que ses vecteurs sont normalisés, de sorte que ces trois mesures donnent le même classement. La différence avec le TF-IDF est de nature : le TF-IDF compte des mots et ne rapproche deux textes que s'ils partagent du vocabulaire, alors que l'embedding rapproche « délai de remboursement » et « combien de temps pour être remboursé », qui n'ont pas un mot en commun.

Les modèles d'embedding et leurs paramètres

Les grands fournisseurs proposent des modèles d'embedding accessibles par API, distincts de leurs modèles de génération. Chez Google, gemini-embedding-001 produit par défaut des vecteurs de 3 072 dimensions ; la documentation de l'API Gemini indique que le modèle est entraîné avec la technique Matryoshka Representation Learning, qui permet de tronquer le vecteur à 1 536 ou 768 dimensions en perdant peu de qualité, pour économiser du stockage et du calcul. Le modèle plus récent gemini-embedding-2 est multimodal : texte, images, vidéo, audio et documents sont projetés dans un même espace, ce qui autorise une recherche d'images à partir d'une phrase. Chez OpenAI, la documentation de l'API décrit text-embedding-3-small et liste les usages courants : recherche, regroupement, recommandation, détection d'anomalies, classification.

Un paramètre souvent négligé est le type de tâche. L'API Gemini accepte pour gemini-embedding-001 un task_type (similarité sémantique, classification, regroupement, document à retrouver, requête de recherche...) qui ajuste la représentation à l'usage : une requête et un document ne se vectorisent pas de la même façon. Trois règles pratiques en découlent : ne jamais comparer des vecteurs issus de modèles différents, vectoriser la requête et les documents avec le même modèle et le même réglage, et refaire tous les vecteurs quand on change de modèle.

La recherche vectorielle

La recherche vectorielle consiste à stocker les vecteurs d'un corpus, puis, pour une requête donnée, à retrouver les vecteurs les plus proches. Sur quelques milliers de documents, une comparaison exhaustive suffit. Au-delà, on recourt à des index de recherche approchée des plus proches voisins (ANN, Approximate Nearest Neighbor), qui sacrifient un peu d'exactitude pour répondre en millisecondes sur des millions d'entrées. Google indique que son service Vector Search repose sur ScaNN, une technologie de Google Research qui alimente aussi la recherche Google, YouTube et Google Play.

Le stockage se fait dans une base vectorielle dédiée (Pinecone, Weaviate, Qdrant, Milvus) ou dans une extension d'une base existante : pgvector ajoute à PostgreSQL un type de colonne vecteur, des index et les distances cosinus, euclidienne et produit scalaire ; Elasticsearch et OpenSearch proposent l'équivalent. Un moteur sérieux ne se contente pas des vecteurs : il combine la recherche sémantique et une recherche lexicale classique (BM25, héritier du TF-IDF, sur un index inversé), puis fusionne les deux listes, par exemple par Reciprocal Rank Fusion. C'est la recherche hybride, qui rattrape les faiblesses de chaque méthode : le vecteur ignore les références exactes (un numéro de pièce, un nom propre rare), le lexical ignore les synonymes.

C'est cette chaîne qui est à l'oeuvre dans un système RAG : les documents sont découpés en passages, vectorisés et indexés ; la question de l'utilisateur est vectorisée à son tour ; les passages les plus proches sont transmis au modèle de langage, qui rédige à partir d'eux. Les moteurs génératifs (AI Overviews, mode IA, ChatGPT avec recherche, Perplexity) appliquent le même principe à l'échelle du web.

Les usages SEO des embeddings

Les embeddings sont devenus un outil de travail courant en référencement, parce qu'ils rendent calculable ce qui relevait auparavant du jugement.

• Regroupement de mots-clés : vectoriser une liste de requêtes, puis appliquer un algorithme de clustering, regroupe celles qui portent la même intention, sans dépendre de la présence des mêmes mots. Le regroupement par vecteurs se complète utilement d'un regroupement par SERP (deux requêtes qui font remonter les mêmes pages), qui reflète la lecture de Google plutôt que celle du modèle.
• Maillage interne : calculer la similarité entre toutes les pages d'un site fait apparaître, pour chaque page, ses voisines les plus proches par le sens, ce qui fournit des candidats de liens internes qu'un éditeur n'aurait pas repérés dans un catalogue de plusieurs milliers d'URL.
• Cannibalisation et doublons : deux pages dont les vecteurs sont presque identiques traitent le même sujet ; c'est un signal de cannibalisation à examiner, avant fusion ou différenciation.
• Adéquation page-requête : la similarité entre le vecteur d'une requête cible et celui d'une page, ou de chacun de ses paragraphes, indique quels passages répondent à la question et lesquels s'en éloignent. La mesure est indicative : le modèle d'embedding d'un fournisseur n'est pas celui que Google utilise.
• Recherche interne et RAG : un moteur de recherche interne fondé sur le sens, ou un assistant qui répond à partir de la documentation d'un site, s'appuient sur la même mécanique.

Ces traitements sont accessibles sans infrastructure lourde : un appel d'API par texte, un tableur ou un script pour les similarités, une bibliothèque de clustering. Le coût se mesure en fractions de centime par millier de tokens vectorisés.

Les limites et les erreurs fréquentes

• Confondre similarité et pertinence : deux textes très proches par le sens ne répondent pas forcément à la même question, et une page peut être pertinente sans ressembler à la requête. La similarité est un signal, pas une décision.
• Vectoriser des pages entières : un vecteur unique pour un document de 3 000 mots moyenne des sujets différents et devient flou. Le découpage en passages (le « chunking ») conditionne la qualité de tout ce qui suit.
• Extrapoler à Google : Google utilise des représentations vectorielles dans ses systèmes depuis des années, mais personne, en dehors de Google, n'a accès à ses modèles. Un score de similarité calculé avec un modèle public décrit le contenu, pas le classement.
• Négliger la langue : les modèles multilingues placent les langues dans un espace commun, mais la qualité varie selon la langue et le domaine. Un test sur un échantillon connu, avant de traiter tout un site, évite les surprises.
• Oublier la mise à jour : un index vectoriel reflète le corpus au moment de sa construction. Pages modifiées ou supprimées imposent de revectoriser.

FAQ

Quelle différence entre un embedding et un mot-clé ?

Un mot-clé est une chaîne de caractères ; un moteur qui s'en sert cherche des pages contenant les mêmes mots. Un embedding est un vecteur qui encode le sens : deux textes sans aucun mot commun peuvent avoir des vecteurs proches s'ils parlent de la même chose. Les deux approches sont complémentaires, et les moteurs modernes les combinent (recherche hybride).

Qu'est-ce que la similarité cosinus ?

C'est le cosinus de l'angle entre deux vecteurs : 1 quand ils ont la même direction, 0 quand ils n'ont aucun rapport, -1 quand ils s'opposent. C'est la mesure la plus courante pour comparer des embeddings, et l'héritière du cosinus de Salton utilisé depuis les années 1970 en recherche d'information. Sur des vecteurs normalisés, le produit scalaire donne le même classement.

Combien de dimensions a un embedding ?

Cela dépend du modèle : gemini-embedding-001 produit 3 072 dimensions par défaut et peut être tronqué à 1 536 ou 768 ; d'autres modèles en produisent quelques centaines. Plus de dimensions n'est pas toujours mieux : le stockage et le temps de calcul augmentent, pour un gain de qualité qui plafonne vite selon l'usage.

Google utilise-t-il des embeddings pour classer les pages ?

Google emploie des représentations vectorielles dans plusieurs de ses systèmes, dont la compréhension des requêtes depuis BERT et la recherche vectorielle qui alimente ses produits (ScaNN). Ses modèles ne sont pas publics : un embedding calculé avec une API tierce ne reproduit pas l'évaluation de Google, il en donne une approximation utile pour organiser un site.

Faut-il une base vectorielle pour utiliser des embeddings en SEO ?

Non pour la plupart des usages SEO : quelques milliers de mots-clés ou de pages se comparent en mémoire, dans un script ou un carnet Python. Une base vectorielle (pgvector, Qdrant, Pinecone...) devient utile quand il faut interroger en continu un corpus de plusieurs centaines de milliers de passages, comme dans un moteur de recherche interne ou un RAG.

En résumé

• Embedding : la représentation d'un contenu sous forme de vecteur de nombres qui encode son sens ; des contenus proches par le sens ont des vecteurs proches.
• Mesure : la similarité cosinus (cosinus de Salton), le produit scalaire ou la distance euclidienne ; sur des vecteurs normalisés, elles donnent le même classement.
• Modèles : word2vec (2013) pour les mots, puis les modèles Transformer contextuels ; aujourd'hui gemini-embedding-001 et gemini-embedding-2 (Google), text-embedding-3 (OpenAI), accessibles par API.
• Recherche vectorielle : index de plus proches voisins (ANN, ScaNN), bases vectorielles ou extensions comme pgvector, combinés au lexical dans une recherche hybride ; c'est la brique de récupération du RAG.
• Usages SEO : regroupement de mots-clés par intention, candidats de maillage interne, détection de cannibalisation, adéquation page-requête, recherche interne.
• Limites : similarité n'est pas pertinence, les modèles publics ne sont pas ceux de Google, le découpage des documents conditionne la qualité.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !