Comment un RAG retrouve la bonne info : cosinus, Euclidienne, dot, Jaccard expliqués sans math

Imaginez un catalogue industriel de 50 000 références

Vous cherchez une vis spécifique. Pas son code exact — vous l’avez oublié. Vous savez juste qu’elle ressemble à une autre que vous avez utilisée l’an dernier sur une presse à injecter, qu’elle est en inox, qu’elle fait à peu près 8 mm de diamètre, et qu’elle visse dans un alu plutôt mou.

Comment retrouver la bonne ligne dans un catalogue de 50 000 références ?

La réponse intuitive — celle qu’utilise un magasinier expérimenté — c’est de chercher des références proches : même matière, même filetage, même usage. Le mot clé c’est proches. Pas identiques. Proches.

Un système RAG (Retrieval-Augmented Generation) fait exactement ça, mais sur du texte. Vous lui donnez une question, il vous ramène les passages proches dans son catalogue documentaire, puis un LLM rédige la réponse à partir de ces passages. La qualité du résultat dépend entièrement de la qualité de la recherche de proximité — et donc de la métrique de similarité choisie.

Cet article décortique les quatre métriques qu’on rencontre dans 95 % des stacks RAG : la similarité cosinus, la distance euclidienne, le produit scalaire, et l’indice de Jaccard. On va voir ce que chacune mesure, quand l’utiliser, et surtout — quand elle peut vous trahir.

Aucune formule intimidante. Quatre vidéos courtes pour visualiser. Un tableau récapitulatif à la fin. C’est tout.

Embeddings : l’empreinte sémantique d’un texte

Avant de mesurer une distance, il faut savoir entre quoi.

Un embedding, c’est une liste de nombres qui représente le sens d’un texte. Pas le texte lui-même — son sens. Quand vous donnez la phrase “livraison retardée à cause d’un défaut sur la presse” à un modèle d’embedding (Sentence-BERT, OpenAI text-embedding, BGE, etc.), il vous renvoie typiquement 384, 768 ou 1536 nombres.

Ces nombres ne veulent rien dire pris un par un. Mais collectivement, ils définissent une position dans un espace géométrique — qu’on appelle l’espace latent. Deux textes qui parlent de la même chose auront des embeddings proches dans cet espace. Deux textes qui parlent de choses différentes auront des embeddings éloignés.

C’est tout le pari du RAG moderne : transformer du texte en géométrie, puis raisonner sur la géométrie.

Et c’est là qu’arrive notre vraie question : comment mesurer “proche” dans un espace à 768 dimensions ?

Quatre réponses dominent.

La métrique #1 du RAG : la similarité cosinus

La similarité cosinus mesure l’angle entre deux vecteurs, pas leur longueur. Si deux vecteurs pointent dans la même direction, leur similarité cosinus vaut 1. S’ils sont perpendiculaires (orthogonaux), elle vaut 0. S’ils pointent à l’opposé, elle vaut -1.

Pourquoi c’est devenu le standard de fait du RAG ? Parce qu’en NLP, la direction d’un vecteur d’embedding capture le sujet du texte, alors que sa norme (sa longueur) capture surtout des artefacts comme la longueur du document ou la fréquence brute des mots. Si un fournisseur vous envoie un mail de trois lignes sur un défaut palette, et qu’un autre vous envoie un rapport de quinze pages sur le même défaut, vous voulez que les deux soient retrouvés ensemble. La cosinus le fait. Une métrique sensible à la longueur ne le ferait pas.

Domaines d’application typiques : RAG documentaire, recherche sémantique, déduplication de tickets, clustering de feedback client. Si vous démarrez un projet RAG et que vous ne savez pas quoi choisir, partez sur la cosinus. Vous ajusterez ensuite si besoin.

Petit piège tout de même : la cosinus suppose que les embeddings ont été correctement entraînés pour que la direction porte l’information. Ce n’est pas garanti pour tous les modèles, mais c’est vrai pour la quasi-totalité des modèles modernes (Sentence-BERT, BGE, OpenAI text-embedding-3, etc.).

La distance euclidienne : intuitive mais traîtresse

La distance euclidienne, c’est la distance à vol d’oiseau entre deux points. On l’apprend au collège : on relie deux points par une ligne droite, et on mesure la longueur de cette ligne.

Sur le papier, c’est la métrique la plus naturelle. Elle correspond à notre intuition de l’espace physique. Sur un GPS, c’est ce qu’on calcule.

Mais en RAG, elle pose un problème. Comme elle dépend de la longueur des vecteurs (de leur magnitude), elle peut classer comme “loin” deux documents qui parlent exactement du même sujet, simplement parce que l’un est plus long que l’autre. Vous pouvez avoir deux vecteurs parfaitement alignés (donc cosinus = 1) mais avec une distance euclidienne énorme parce que l’un est trois fois plus long que l’autre.

Quand elle est pertinente quand même : quand les vecteurs sont déjà normalisés (ramenés à une longueur de 1). Dans ce cas, la distance euclidienne et la similarité cosinus deviennent équivalentes mathématiquement — minimiser l’une revient à maximiser l’autre. Beaucoup de bases vectorielles (FAISS, Qdrant) exploitent cette propriété pour optimiser les calculs.

Domaines d’application : recherche d’images, clustering géométrique, k-means classique. En RAG textuel sans normalisation préalable, à éviter.

Le produit scalaire : le cousin rapide du cosinus

Le produit scalaire (en anglais dot product), c’est ce qu’on obtient en multipliant deux vecteurs composante par composante, puis en additionnant tout. Géométriquement, il représente la longueur de l’ombre projetée d’un vecteur sur l’autre.

Sa relation avec la cosinus est limpide : la similarité cosinus, c’est exactement le produit scalaire divisé par le produit des normes. Donc si vos vecteurs sont déjà normalisés (norme = 1), le produit scalaire est la similarité cosinus, à zéro division près.

Pourquoi on le choisit malgré tout : c’est l’opération la plus rapide à calculer en mémoire. Une multiplication, une addition, c’est tout. Pas de racine carrée comme l’Euclidienne, pas de division comme la cosinus normalisée. Sur des bases de millions de vecteurs, ce gain compte. Beaucoup de modèles d’embedding modernes (notamment ceux d’OpenAI) renvoient déjà des vecteurs normalisés — il devient alors équivalent et plus rapide d’utiliser le produit scalaire que la cosinus explicite.

Domaines d’application : production RAG haute performance, ranking de candidats dans un retriever bi-encoder, scoring de pertinence dans les systèmes de recommandation. C’est la métrique par défaut de FAISS quand on travaille avec des embeddings normalisés.

Petit avertissement : si vos vecteurs ne sont pas normalisés, le produit scalaire favorisera les vecteurs longs sans que ce soit ce que vous voulez. Vérifiez toujours la convention de votre modèle d’embedding avant de choisir cette métrique.

L’indice de Jaccard : pour les ensembles, pas les vecteurs denses

Les trois premières métriques travaillent sur des vecteurs denses — des listes longues de nombres réels. L’indice de Jaccard, lui, travaille sur des ensembles — des collections de tokens, de tags, de mots-clés.

Sa définition est élémentaire : c’est le rapport entre la taille de l’intersection des deux ensembles et la taille de leur union.

Si deux documents partagent tous leurs tags, Jaccard = 1. S’ils n’en partagent aucun, Jaccard = 0. C’est aussi simple que ça.

Pourquoi c’est utile en RAG : tous les RAG modernes ne sont pas purement vectoriels. Beaucoup combinent une recherche sémantique (cosinus sur embeddings) avec une recherche lexicale (BM25, TF-IDF) ou une recherche par filtres (tags, métadonnées). Jaccard intervient typiquement dans la couche de filtrage : retrouver les documents dont les tags croisent la requête, calculer un score de chevauchement de mots-clés rares, ou déduplicater des résultats quasi-identiques.

Domaines d’application : déduplication, filtrage par tags métier, scoring lexical complémentaire au sémantique, recommandation par mots-clés. À l’inverse, n’essayez pas de l’appliquer directement à des embeddings denses — il n’a pas de sens géométrique pour ça.

Tableau récapitulatif : quand choisir quoi

Métrique	Mesure quoi	Force	Faiblesse	Cas RAG typique
Cosinus	Angle entre vecteurs	Insensible à la longueur, robuste	Suppose embeddings sémantiques propres	Recherche documentaire générale, FAQ, support
Euclidienne	Distance à vol d’oiseau	Intuitive, géométrique vraie	Sensible à la magnitude	Vecteurs normalisés uniquement, images
Produit scalaire	Projection orthogonale	Très rapide à calculer	Trompeuse si vecteurs non normalisés	Production haute perf, FAISS optimisé
Jaccard	Chevauchement d’ensembles	Simple, interprétable	Ne marche pas sur vecteurs denses	Filtrage par tags, déduplication, hybride

Règle pratique pour démarrer un projet RAG :

1. Embeddings normalisés (OpenAI, BGE moderne) → produit scalaire, c’est rapide et équivalent à la cosinus.
2. Embeddings non normalisés (certains modèles custom) → cosinus explicite.
3. Recherche par tags ou filtres → Jaccard en complément.
4. Distance euclidienne uniquement si vous savez précisément pourquoi.

Comment ça se traduit dans les outils que vous utilisez

Quand vous configurez une base vectorielle, le choix de la métrique apparaît systématiquement à la création de la collection. Quelques exemples concrets :

• Qdrant : paramètre distance lors du create_collection. Choix entre Cosine, Euclid, Dot. Le défaut sur la plupart des modèles modernes : Cosine.
• FAISS : index IndexFlatIP (inner product = produit scalaire) ou IndexFlatL2 (Euclidienne). Pour la cosinus, on normalise les vecteurs en amont puis on utilise IndexFlatIP.
• pgvector (PostgreSQL) : opérateurs <#> (négatif du produit scalaire), <=> (cosinus), <-> (Euclidienne). Le choix se fait dans la requête SQL ORDER BY embedding <=> query_vector.
• Pinecone, Weaviate, Chroma : tous proposent les mêmes trois choix de base, avec cosinus en défaut.

Le choix de la métrique est une propriété de la collection, pas de la requête. Changer de métrique implique généralement de réindexer. C’est une décision de design à prendre tôt — d’où l’intérêt de la comprendre.

Pour aller plus loin

Si vous travaillez sur de la donnée structurée et que les concepts d’agrégation et de signal vous parlent, lisez aussi :

• Agrégation de données industrielles : du signal brut au tableau de bord
• Architecture réseau industriel selon Purdue : où placer vos couches IA
• Construire des agents IA avec la méthode RIGO

Côté ressources externes pour creuser :

• Documentation Qdrant sur les distances — concis et orienté pratique
• Sentence-BERT (Reimers & Gurevych, 2019) — le papier fondateur des embeddings sémantiques modernes
• Stanford CS224N — Word Vectors — cours de référence pour comprendre la géométrie des embeddings
• Lucas Beyer — Embeddings Visualized — articles techniques avec visualisations de qualité

Si vous êtes en train de construire un système RAG pour vos données industrielles (documentation technique, base qualité, historique non-conformités, comptes-rendus de réunion) et que vous voulez éviter les pièges de configuration qui font perdre des semaines, prenez 30 minutes avec moi : bcub3.com/contact. Cadrage gratuit, discussion technique, pas de baratin commercial.