Qu'est-ce qu'un Embedding et la Recherche Vectorielle

Cherchez “chiot” dans un système qui ne compare que des mots-clés et un document sur l’éducation des chiens ne ressortira pas, même si n’importe qui lisant les deux les jugerait étroitement liés. La recherche par mots-clés compare des chaînes de caractères. Elle ne sait pas que “chiot” et “chien” veulent dire presque la même chose. Les embeddings règlent exactement ce problème. Ils transforment un texte en une liste de nombres, un vecteur, placé de sorte que des textes de sens proche se retrouvent près d’autres textes de sens proche, quels que soient les mots employés.

Comment un modèle d’embedding transforme le texte en nombres

Un modèle d’embedding est un réseau de neurones entraîné à placer du texte en un point d’un espace à haute dimension : 384, 768 ou 1536 dimensions sont des tailles courantes, selon le modèle. Il ne consulte pas un dictionnaire. À partir d’énormes quantités de texte, il a appris quels mots et expressions apparaissent dans des contextes similaires, et il encode cela dans la position vers laquelle pointe le vecteur.

La distance dans cet espace suit la proximité de sens. “Roi” et “reine” se retrouvent proches. “Roi” et “golden retriever” se retrouvent loin. Personne n’a dit au modèle de comparer ces mots ; c’est l’entraînement qui a produit cette géométrie, mot par mot.

Vous pouvez observer la même forme avec des nombres choisis à la main, avant même qu’un vrai modèle entre en jeu. Donnez à chaque mot un vecteur de 3 nombres (un vrai modèle en utilise des centaines) :

1
2
3

king  = [0.90, 0.10, 0.85]
queen = [0.88, 0.12, 0.10]
dog   = [0.05, 0.95, 0.40]

king et queen s’accordent étroitement sur les deux premiers nombres. Pas dog. Pour transformer cet “accord étroit” en un score unique, il faut une métrique de similarité.

Cosine similarity, dot product et Euclidean distance comparés

Trois métriques reviennent constamment dans le travail avec les embeddings, chacune répondant à une question légèrement différente :

La cosine similarity est celle que vous utiliserez presque toujours. Beaucoup de modèles de text embedding normalisent leur sortie à une longueur de 1, donc seule la direction varie, et sur des vecteurs normalisés, cosine et dot product donnent le même classement. Le score va de -1 (opposé) à 1 (identique), 0 signifiant aucun lien. Voici le calcul sur les vecteurs choisis à la main :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import numpy as np

def cosine_similarity(a, b):
    a, b = np.array(a, dtype=float), np.array(b, dtype=float)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

king  = [0.90, 0.10, 0.85]
queen = [0.88, 0.12, 0.10]
dog   = [0.05, 0.95, 0.40]

print(cosine_similarity(king, queen))  # 0.801
print(cosine_similarity(king, dog))    # 0.375

0,801 contre 0,375. king se retrouve bien plus proche de queen que de dog. Un vrai modèle produit le même type d’écart, réparti sur des centaines de dimensions apprises à partir de données plutôt que trois choisies à la main.

Comment générer des embeddings en Python

sentence-transformers est la bibliothèque open source de référence pour cela. Elle fonctionne en local, sans clé API :

1

pip install sentence-transformers

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
sentences = [
    "The weather is lovely today.",
    "It's so sunny outside!",
    "He drove to the stadium.",
]
embeddings = model.encode(sentences)          # shape: (3, 384)
print(model.similarity(embeddings, embeddings))

all-MiniLM-L6-v2 transforme chaque phrase en un vecteur de 384 nombres, et model.similarity calcule la cosine similarity pour chaque paire. Les deux phrases sur le beau temps ne partagent presque aucun mot, et pourtant elles obtiennent un score élevé entre elles et faible face à celle sur le stade. Même schéma que l’exemple jouet, sauf que les nombres viennent maintenant d’un modèle qui a appris la langue.

Les API hébergées renvoient la même chose. Les endpoints text-embedding-3-small d’OpenAI et embed de Cohere donnent tous deux une liste de nombres décimaux par texte. Si vous faites déjà tourner des modèles en local, Ollama sert aussi des embeddings : ollama pull nomic-embed-text, puis appelez son endpoint /api/embed (la configuration est traitée dans Comment exécuter un LLM en local avec Ollama). La bibliothèque change. Le vecteur, et ce que vous en faites, non.

Comment la recherche de similarité vectorielle trouve la correspondance la plus proche

Calculer l’embedding d’un seul texte est la partie facile. Le vrai travail est presque toujours ailleurs : étant donné un vecteur de requête, trouver les correspondances les plus proches parmi des milliers ou des millions de vecteurs stockés. C’est la recherche de similarité vectorielle, et sa version directe est la force brute : noter la requête contre chaque vecteur stocké et garder les meilleurs résultats.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

import numpy as np, time

rng = np.random.default_rng(0)

for n in [10_000, 100_000, 1_000_000]:
    vectors = rng.normal(size=(n, 384)).astype(np.float32)
    query = rng.normal(size=384).astype(np.float32)

    start = time.perf_counter()
    scores = vectors @ query / (np.linalg.norm(vectors, axis=1) * np.linalg.norm(query))
    top5 = np.argsort(scores)[-5:]
    elapsed = time.perf_counter() - start
    print(f"n={n:>9,}  {elapsed*1000:.2f} ms")

Sur une machine ordinaire, cela affiche quelque chose proche de :

1
2
3

n=   10,000  0.70 ms
n=  100,000  7.82 ms
n=1,000,000  63.64 ms

Le temps croît linéairement avec le nombre de vecteurs, O(n) selon les termes de la notation Big O, mais NumPy rend chaque étape si peu coûteuse qu’un million de vecteurs prend largement moins de 100 ms. Cela cesse de suffire avec un trafic concurrent important, des dizaines de millions de vecteurs, ou les deux. Il faut alors un index approximate nearest neighbor (ANN), qui fait pour les vecteurs ce qu’un B-tree fait pour une clause WHERE dans une base de données (voir Comment Fonctionnent les Index de Base de Données). Deux types reviennent partout :

• HNSW (Hierarchical Navigable Small World) construit un graphe multicouche reliant chaque vecteur à ses voisins, si bien qu’une recherche parcourt le graphe vers la réponse au lieu de toucher chaque vecteur. Il offre le meilleur recall par milliseconde parmi les options courantes, au prix d’une mémoire plus importante et de constructions d’index plus lentes.
• IVFFlat regroupe les vecteurs en clusters autour de centroïdes, puis ne cherche que dans les clusters les plus proches de la requête. Il se construit plus vite et consomme moins de mémoire que HNSW, mais nécessite des données représentatives déjà chargées avant sa création. Construit sur une table vide, il produit de mauvais clusters et un mauvais recall.

Dans Postgres avec l’extension pgvector, chacun se résume à une instruction :

1
2
3
4
5

-- HNSW : peut être construit à tout moment, même sur une table vide
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);

-- IVFFlat : chargez d'abord des données représentatives, puis construisez
CREATE INDEX ON items USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);

Les deux échangent de l’exactitude contre de la vitesse. Ils peuvent manquer le vecteur réellement le plus proche, ce qui ne pose pas de problème pour la recherche et les recommandations, mais en pose pour tout cas qui exige la réponse exacte à chaque fois.

Erreurs courantes dans la recherche par embeddings

• Interroger avec un modèle et stocker avec un autre. Les vecteurs de deux modèles différents vivent dans des espaces incompatibles. Si vous changez de modèle, recalculez l’embedding de chaque document stocké avec le nouveau. Un mélange d’anciens et de nouveaux vecteurs renvoie des correspondances inutiles sans la moindre erreur.
• Classer par dot product sur des vecteurs jamais normalisés. Le dot product inclut la longueur, donc un vecteur long peut dépasser dans le classement un vecteur plus court et plus pertinent. Normalisez à l’écriture, ou utilisez l’opérateur cosine, qui ignore la longueur.
• Confondre proximité et exactitude. Un score cosine élevé signifie “apparaît dans des contextes similaires”, pas “est la bonne réponse”. Une requête sur les effets secondaires d’un médicament peut renvoyer un extrait sur le dosage de ce même médicament : lié, et faux. C’est la principale cause d’échec dans les pipelines RAG. La similarité réduit les candidats. Elle ne les vérifie pas.
• Ajouter un index ANN avant que la force brute ne soit vraiment trop lente. Le benchmark ci-dessus traite un million de vecteurs en moins de 100 ms. HNSW ou IVFFlat ajoutent du temps de construction, des paramètres à régler et des résultats approximatifs. Cela vaut le coup au-delà de dizaines de millions de vecteurs ou sous forte charge concurrente, pas par défaut.
• Oublier de recalculer l’embedding quand la source change. Un embedding est un instantané du texte au moment où vous l’avez calculé. Modifiez le document sans le recalculer et la recherche continuera de renvoyer l’ancienne version en toute confiance.

Avez-vous besoin d’une base de données vectorielle ?

Pas pour commencer. Calculez l’embedding de quelques centaines de vos documents réels avec sentence-transformers, gardez les vecteurs dans un tableau NumPy et cherchez-les avec la boucle à force brute ci-dessus. Pas de base de données, pas d’index. Passez à pgvector ou à une base de données vectorielle gérée une fois que la force brute devient mesurablement trop lente pour votre volume de données et de requêtes. N’ajoutez un index ANN par-dessus que lorsque le scan de table est le goulot d’étranglement que vous avez réellement mesuré.

Articles associés

• Qu’est-ce que le RAG : Retrieval-Augmented Generation
• La Notation Big O Expliquée avec des Exemples de Code