Recherche sémantique : le guide complet des embeddings et du RAG

Comment fonctionnent les embeddings : vecteurs, dimensions et similarité

Génération des embeddings : du texte au vecteur numérique

Un modèle d’embedding comme text-embedding-3 d’OpenAI, Cohere, BGE ou E5 transforme un texte en une liste de nombres à virgule flottante. Cette liste, appelée vecteur, capture le sens profond de la phrase, et non ses mots exacts. Les dimensions typiques de ces vecteurs varient entre 768 et 3072 dimensions, selon la puissance du modèle utilisé, une approche qui permet aussi la classification à peu d’exemples. L’objectif est de placer des textes sémantiquement proches dans des zones voisines de l’espace vectoriel. Par exemple, « comment réparer un vélo » et « réparation de bicyclette » produiront des vecteurs quasi identiques, même sans aucun mot en commun. C’est cette proximité vectorielle qui permet à la recherche sémantique de comprendre l’intention derrière une requête, quels que soient les termes employés.

Mesures de similarité : cosinus, euclidienne et produit scalaire

Cette approche vectorielle s'applique aussi aux tests automatisés, où la recherche sémantique peut valider des parcours utilisateur complexes, comme ceux couverts par les tests end-to-end avec Playwright.

Le coût d’embedding varie selon le modèle choisi : $0.02/1M tokens pour le modèle OpenAI text-embedding-3-small, contre $0.13/1M tokens pour le text-embedding-3-large. Chaque requête prend entre 50 et 200 ms via l’API OpenAI, tandis que les Sentence Transformers en local traitent un lot en 10 à 50 ms, et jusqu’à 2 à 10 ms avec une accélération GPU.

Le choix des dimensions dépend du cas d’usage. Une plage de 384 à 768 dimensions offre un bon équilibre pour un usage général RAG, notamment pour la génération augmentée, comme pour les embeddings pour RAG, à l’image de l’implémentation rag. Les domaines complexes juridique, médical, technique tirent profit de 1024 à 1536 dimensions. Pour les applications à fort volume et sensibles aux coûts, 256 à 384 dimensions suffisent souvent. Les dimensions courantes sont 384, 768, 1024 et 1536, avec un exemple type : un vecteur de 768 dimensions pour un article de centre d’aide.

Les embeddings ne sont pas annotés manuellement : ils sont générés par des modèles d’apprentissage. L’algorithme Word2Vec a ouvert la voie dès 2013, mais il est aujourd’hui dépassé. L’architecture Transformers, introduite en 2017 avec le papier « Attention is all you need », est devenue la référence absolue, tout comme le comparatif Rust Go guide le choix des langages systèmes. Ces modèles analysent des millions de phrases pour apprendre quels mots apparaissent dans des contextes similaires, et encodent ces relations dans des vecteurs numériques.

Une fois vos textes convertis en vecteurs, il faut calculer leur proximité. La méthode la plus répandue est la similarité cosinus, qui mesure l’angle entre deux vecteurs. Un score de 0 à 1 indique la force de la similarité : 1 pour des phrases identiques sémantiquement, 0 pour des textes sans rapport. Cette métrique est privilégiée car elle est insensible à la taille des vecteurs.

D’autres approches existent, comme la distance euclidienne, qui calcule la distance géométrique directe entre deux points, ou le produit scalaire, souvent utilisé avec des modèles optimisés pour ce calcul. Le choix de la métrique influence directement les résultats de recherche, la similarité cosinus restant la plus robuste pour la plupart des cas d’usage en traitement du langage naturel.

Recherche sémantique vs vectorielle vs hybride : différences et complémentarités

Limites de la recherche lexicale : synonymie, polysémie et mots-clés

La recherche lexicale, celle qui repose sur des algorithmes comme BM25 ou TF-IDF, compare des chaînes de caractères, à l’image du choix entre JavaScript et TypeScript pour le typage. Elle est performante pour les termes techniques, les noms propres ou les identifiants précis, mais bute sur deux obstacles structurels : la synonymie et la polysémie.

La synonymie, d’abord. Si un utilisateur cherche « comment réduire les coûts d’exploitation » et que le document parle de « diminuer les dépenses opérationnelles », aucun mot ne correspond : le résultat est nul, alors que le sens est identique. La polysémie, ensuite. Le mot « banque » peut désigner une institution financière, un établissement de données ou la rive d’un fleuve. Une recherche par mots-clés renverra un mélange de résultats sans lien avec l’intention réelle de l’utilisateur.

La recherche vectorielle (sémantique) contourne ce problème en projetant les textes dans un espace vectoriel de 768 à 3072 dimensions. Deux phrases de sens proche, même sans mots communs, s’y retrouvent à proximité. Le score de similarité, évalué sur une échelle de 0 à 1, reflète alors la proximité conceptuelle plutôt que l’identité textuelle.

Complémentarité : quand utiliser chaque approche et pourquoi l’hybride gagne

Chaque approche a ses forces. La recherche lexicale excelle pour retrouver un code produit, un numéro de série ou un nom de version logicielle des données où le mot exact prime. La recherche sémantique brille face aux questions formulées différemment du contenu indexé, comme « quelle est la politique de remboursement ? » face à une page titrée « conditions d’annulation ».

L’approche hybride combine les deux : elle exécute simultanément une recherche vectorielle et une recherche par mots-clés, puis fusionne les résultats en pondérant leurs scores respectifs. C’est elle qui offre la meilleure couverture. Sur un corpus technique, elle garantit que la requête « bug mémoire API Python » retrouve à la fois les articles traitant du « memory leak » (proximité sémantique) et ceux contenant précisément les mots-clés API et Python (correspondance lexicale). Cette complémentarité explique pourquoi la plupart des moteurs de recherche modernes, des assistants documentaires aux plateformes e-commerce, adoptent cette architecture combinée.

RAG : ancrer les réponses des LLM avec les embeddings

Cette architecture combinée repose sur des mécanismes de sécurité robustes, à l’image de la double authentification expliquée pour protéger les accès aux systèmes.

La recherche hybride exécute en parallèle une requête sur un index vectoriel et une recherche par mots-clés (BM25), puis fusionne les résultats avec des scores normalisés. Cette approche excelle là où la sémantique seule échoue : noms de produits, numéros de commande, codes d’erreur ou identifiants précis. Les mots-clés garantissent une correspondance exacte, tandis que les embeddings comprennent l’intention et les synonymes.

Prenons une requête comme « cancel my plan » : la recherche lexicale ne trouve rien dans une base contenant « terminate subscription ». Inversement, une recherche vectorielle pure se perd sur « apple charger » face à des articles sur les pommes. En combinant les deux, vous compensez les limites réciproques : la précision lexicale renforce la compréhension sémantique, et inversement.

C’est le meilleur choix par défaut pour des données contenant des chaînes à faire correspondre impérativement. La fusion des scores avec pondérations (par exemple 0,5/0,5) équilibre les deux signaux. Pour un système RAG, cette stratégie augmente la précision de récupération de 20 à 40 % par rapport à une approche unique, selon les jeux de données et la qualité des embeddings choisis.

Le RAG (Retrieval-Augmented Generation) repose sur une idée simple : donner aux grands modèles de langage un accès à vos documents pour éviter qu’ils ne répondent à l’aveugle. Les embeddings servent de pont entre votre base de connaissances et le modèle. Voici le pipeline complet qui rend cette arch, itecture possible, étape par étape.,

• Découpage des documents : fractionner les textes en segments cohérents (chunks) pour faciliter la récupération ciblée et réduire le bruit.
• Indexation en embeddings vectoriels : transformer chaque chunk en vecteur numérique grâce à un modèle de type text-embedding-3 ou BGE, puis les stocker dans une base vectorielle.
• Récupération des chunks pertinents : lors d’une requête, calculer la similarité cosinus entre le vecteur de la question et ceux des chunks. Les vecteurs proches, avec un score situé entre 0 et 1, sont sélectionnés.
• Injection dans le contexte LLM : insérer les segments récupérés dans le prompt du modèle pour lui fournir le contexte nécessaire.
• Génération de réponse ancrée : le modèle formule une réponse factuelle et étayée, directement fondée sur les documents indexés.

L’intérêt de ce mécanisme est double. D’une part, il réduit les hallucinations en forçant le modèle à s’appuyer sur des sources vérifiables. D’autre part, il permet de répondre à des questions très spécifiques, portant sur des informations internes, des données chiffrées ou des détails techniques que le modèle n’a pas mémorisés.

Enfin, le RAG optimise les coûts : au lieu de réentraîner un LLM sur de nouveaux documents, il suffit de mettre à jour les embeddings dans la base vectorielle. La combinaison du stockage vectoriel et du contexte injecté crée un système de recherche puissant, capable de manipuler des corpus volumineux tout en fournissant des réponses précises.

Bases de données vectorielles : stockage, infrastructure et choix

Les vecteurs d’embedding ont une dimension considérable, allant de 768 à 3072 dimensions. Les stocker dans une base relationnelle classique provoque vite des problèmes de performance. Une base vectorielle est conçue pour ce type de données : elle indexe les vecteurs et permet des recherches de similarité rapides, sans recalculer les embeddings à chaque requête.

Le choix de l’infrastructure dépend de votre volume de données. Pour un projet simple, une bibliothèque comme FAISS suffit. Pour une application d’entreprise, privilégiez une base dédiée (Pinecone, Weaviate, Qdrant) qui gère le cycle de vie des vecteurs : stockage, indexation et récupération. L’objectif reste le même : éviter de re-générer des embeddings coûteux à chaque recherche.

Chunking : le découpage des textes pour une meilleure récupération

Le chunking, ou découpage des documents en segments, est une étape décisive qui influence fortement la qualité de la recherche. Un découpage par taille fixe, toutes les N tokens par exemple, est simple à mettre en œuvre mais risque de couper une phrase en plein milieu, appauvrissant ainsi le sens du vecteur généré.

À l’inverse, un découpage par structure, qui respecte les paragraphes, les sections et les titres, produit des chunks plus cohérents. Cette approche permet de créer des embeddings plus précis, car chaque segment représente une idée complète, ce qui améliore directement la pertinence des résultats de la recherche sémantique et l’efficacité d’un pipeline RAG.

Applications concrètes et modèles d’embeddings : cas d’usage et critères de choix

Cas d’usage en entreprise : texte, images, audio et code source

Le principe des embeddings est universel : transformer n’importe quel contenu en vecteur numérique, puis comparer ces vecteurs pour trouver ce qui est sémantiquement proche. Cette approche fonctionne aussi bien pour du texte que pour des images, de l’audio ou du code source.

• Indexation de documents internes pour RAG : transformer des centaines de manuels, contrats ou guides en vecteurs pour permettre à un LLM d’y piocher les passages pertinents avant de répondre.
• Recherche d’images par description textuelle : avec un modèle comme CLIP (OpenAI), une requête en langage naturel retrouve des visuels sans que ceux-ci aient été tagués manuellement.
• Recherche multimodale avec CLIP : le même modèle encode textes et images dans un espace partagé, rendant possible une recherche croisée entre les deux formats.
• Comparaison de contenus par vecteurs : détecter des documents quasi dupliqués, regrouper des tickets de support par sujet ou rapprocher des offres d’emploi et des CV.

Dans les faits, la recherche sémantique s’applique aussi à l’audio et au code source. Une phrase prononcée, un enregistrement de réunion ou une fonction Python peuvent être encodés en vecteurs, puis comparés pour retrouver un extrait précis ou du code similaire.

Critères de choix d’un modèle d’embeddings

Le choix d’un modèle d’embedding dépend de plusieurs facteurs mesurables. Les vecteurs produits occupent typiquement 768 à 3072 dimensions selon l’architecture : plus la dimension est élevée, plus la capacité de représentation est fine, mais plus le stockage et le calcul sont coûteux.

Sentence Transformers, basés sur les modèles BERT, constituent un socle courant. La bibliothèque sbert.net donne accès à des modèles pré-entraînés sur Hugging Face, entraînés par paires de phrases annotées (supervisé) ou via la méthode TSDAE (non supervisé). Pour évaluer la pertinence, on mesure la similarité entre phrases sur une échelle de 0 à 1 un score proche de 1 indique une forte proximité sémantique.

Pour les projets en français, privilégiez un modèle multilingue ou spécialement entraîné sur la langue. Le coût d’inférence, la latence et le volume de dimensions doivent être mis en regard de la taille de votre corpus et de vos besoins en précision.

{
« @context »: « https://schema.org »,
« @type »: « Article »,
« headline »: « Recherche sémantique : le guide complet des embeddings et du RAG »,
« description »: « Les embeddings transforment le texte en vecteurs numériques pour capturer le sens. »,
« datePublished »: « 2026-08-17 »,
« author »: {
« @type »: « Organization »,
« name »: « alex-test.xyz »
},
« publisher »: {
« @type »: « Organization »,
« name »: « alex-test.xyz »,
« url »: « https://alex-test.xyz »
}
}

{
« @context »: « https://schema.org »,
« @type »: « FAQPage »,
« mainEntity »: [
{
« @type »: « Question »,
« name »: « Comment fonctionnent les embeddings : vecteurs, dimensions et similariténnGénération des embeddings : du texte au vecteur numériquennUn modèle d’embedding comme text-embedding-3 d’OpenAI, Cohere, BGE ou E5 transforme un texte en une liste de nombres à virgule flottante. Cette liste, appelée vecteur, capture le sens profond de la phrase, et non ses mots exacts. Les dimensions typiques de ces vecteurs varient entre 768 et 3072 dimensions, selon la puissance du modèle utilisé.nnL’objectif est de placer des textes sémantiquement proches dans des zones voisines de l’espace vectoriel. Par exemple, « comment réparer un vélo » et « réparation de bicyclette » produiront des vecteurs quasi identiques, même sans aucun mot en commun. C’est cette proximité vectorielle qui permet à la recherche sémantique de comprendre l’intention derrière une requête, quels que soient les termes employés.nnMesures de similarité : cosinus, euclidienne et produit scalairennUne fois vos textes convertis en vecteurs, il faut calculer leur proximité. La méthode la plus répandue est la similarité cosinus, qui mesure l’angle entre deux vecteurs. Un score de 0 à 1 indique la force de la similarité : 1 pour des phrases identiques sémantiquement, 0 pour des textes sans rapport. Cette métrique est privilégiée car elle est insensible à la taille des vecteurs.nnD’autres approches existent, comme la distance euclidienne, qui calcule la distance géométrique directe entre deux points, ou le produit scalaire, souvent utilisé avec des modèles optimisés pour ce calcul. Le choix de la métrique influence directement les résultats de recherche, la similarité cosinus restant la plus robuste pour la plupart des cas d’usage en traitement du langage naturel.nnRecherche sémantique vs vectorielle vs hybride : différences et complémentaritésnnnnnLimites de la recherche lexicale : synonymie, polysémie et mots-clésnnLa recherche lexicale, celle qui repose sur des algorithmes comme BM25 ou TF-IDF, compare des chaînes de caractères. Elle est performante pour les termes techniques, les noms propres ou les identifiants précis, mais bute sur deux obstacles structurels : la synonymie et la polysémie.nnLa synonymie, d’abord. Si un utilisateur cherche « comment réduire les coûts d’exploitation » et que le document parle de « diminuer les dépenses opérationnelles », aucun mot ne correspond : le résultat est nul, alors que le sens est identique. La polysémie, ensuite. Le mot « banque » peut désigner une institution financière, un établissement de données ou la rive d’un fleuve. Une recherche par mots-clés renverra un mélange de résultats sans lien avec l’intention réelle de l’utilisateur.nnLa recherche vectorielle (sémantique) contourne ce problème en projetant les textes dans un espace vectoriel de 768 à 3072 dimensions. Deux phrases de sens proche, même sans mots communs, s’y retrouvent à proximité. Le score de similarité, évalué sur une échelle de 0 à 1, reflète alors la proximité conceptuelle plutôt que l’identité textuelle.nnComplémentarité : quand utiliser chaque approche et pourquoi l’hybride gagnennChaque approche a ses forces. La recherche lexicale excelle pour retrouver un code produit, un numéro de série ou un nom de version logicielle, des données où le mot exact prime. La recherche sémantique brille face aux questions formulées différemment du contenu indexé, comme « quelle est la politique de remboursement ? » face à une page titrée « conditions d’annulation ».nnL’approche hybride combine les deux : elle exécute simultanément une recherche vectorielle et une recherche par mots-clés, puis fusionne les résultats en pondérant leurs scores respectifs. C’est elle qui offre la meilleure couverture. Sur un corpus technique, elle garantit que la requête « bug mémoire API Python » retrouve à la fois les articles traitant du « memory leak » (proximité sémantique) et ceux contenant précisément les mots-clés API et Python (correspondance lexicale). Cette complémentarité explique pourquoi la plupart des moteurs de recherche modernes, des assistants documentaires aux plateformes e-commerce, adoptent cette architecture combinée.nnRAG : ancrer les réponses des LLM avec les embeddings »,
« acceptedAnswer »: {
« @type »: « Answer »,
« text »: « Le RAG (Retrieval-Augmented Generation) repose sur une idée simple : donner aux grands modèles de langage un accès à vos documents pour éviter qu’ils ne répondent à l’aveugle. Les embeddings servent de pont entre votre base de connaissances et le modèle. Voici le pipeline complet qui rend cette arch »
}
}
]
}