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

Comment fonctionnent les embeddings : de la phrase au vecteur numérique

Un embedding est un vecteur numérique dense une longue liste de nombres qui capture le sens sémantique d’un mot, d’une phrase ou d’un document. Ces vecteurs comptent généralement entre 768 et 3072 dimensions, selon le modèle utilisé. Par exemple, le modèle OpenAI text-embedding-3-small produit des vecteurs de 1536 dimensions, tandis que les modèles de la famille BGE se situent dans une plage de 512 à 1024 dimensions.

Contrairement à une simple correspondance de mots, ces vecteurs représentent le sens, pas les mots eux-mêmes. Deux phrases aux mots différents mais au sens proche comme « mer » et « océan » produisent des vecteurs très similaires sur le plan mathématique.

• Vecteurs denses 768 à 3072 dimensions, une valeur par concept appris
• Sens sémantique la signification prime sur la forme lexicale
• Modèles Transformers l’architecture de référence, née du papier « Attention is all you need »
• Token CLS la méthode principale pour extraire l’embedding d’une phrase
• Proximité vectorielle deux concepts proches = deux vecteurs proches dans l’espace

Génération des embeddings : le rôle des Transformers

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. 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.

Dimensions courantes selon les modèles et usages

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. 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.

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.

Recherche sémantique : définition et différence avec la recherche par mots-clés

La recherche sémantique ne se contente pas de matcher des mots : elle analyse le sens et l’intention derrière la requête. Là où une recherche lexicale (BM25, TF-IDF) échoue face à la synonymie « réduction des effectifs » ne répond pas à la requête « licenciements » , les embeddings comprennent la proximité conceptuelle. Un même vecteur de 768 dimensions peut rapprocher « mer », « océan » et « Saint-Tropez ».

La recherche par mots-clés souffre de deux faiblesses structurelles : la synonymie et la polysémie. Une requête comme « apple charger » donnera des résultats sur les fruits, pas sur les accessoires. La recherche sémantique, elle, encode le contexte pour lever ces ambiguïtés. Le pipeline est simple : on crée les embeddings, on les stocke, puis on compare leur similarité vectorielle pour retourner les passages les plus pertinents. comme le montre la comparaison typescript,

Concrètement, une requête « cancel my plan » trouve immédiatement un article « terminate subscription » grâce à la similarité sémantique. La recherche classique, elle, rate systématiquement ce type de correspondance. C’est cette capacité à dépasser la surface des mots qui rend la recherche sémantique indispensable pour la donnée non structurée, où le sens prime sur la forme.

Recherche hybride : combiner la recherche sémantique et la recherche lexicale

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.

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

Le RAG (Retrieval-Augmented Generation) est l’infrastructure qui donne aux grands modèles de langage une mémoire consultable. Au lieu de laisser le LLM inventer une réponse à partir de son seul entraînement, on lui fournit des preuves textuelles pertinentes, extraites d’une base de connaissances, qu’il doit résumer et expliquer. C’est cette ancrage documentaire qui transforme une génération approximative en réponse vérifiable.

Le pipeline RAG, étape par étape

Le fonctionnement du RAG suit un flux précis, où chaque étape conditionne la qualité du résultat final. Voici les cinq maillons de la chaîne :

• Découpage : le document source est fragmenté en chunks de 512 tokens maximum, la limite de contexte typique des modèles d’embedding.
• Vectorisation : chaque chunk est transformé en un vecteur de 768 à 1024 dimensions selon le modèle choisi (BGE, E5, OpenAI).
• Indexation : les vecteurs sont stockés dans une base vectorielle avec leurs métadonnées (source, date, titre).
• Récupération : la requête utilisateur est vectorisée, puis comparée aux chunks ; on récupère les K=5 passages les plus proches par similarité cosinus.
• Génération : ces 5 chunks sont injectés dans le prompt du LLM comme contexte, avec la question de l’utilisateur.

Le choix de la dimension des vecteurs influence directement le coût et la précision. Pour un usage général en RAG, une plage de 384 à 768 dimensions offre le meilleur équilibre entre qualité et performance. Les domaines complexes (juridique, médical) justifient des vecteurs de 1024 à 1536 dimensions, tandis que les applications à très fort volume et sensibles aux coûts se contenteront de 256 à 384 dimensions.

Pourquoi le RAG réduit les hallucinations des LLM

Un LLM seul « invente » lorsqu’il ne sait pas : il produit une réponse plausible mais fausse. Le RAG remplace ce mécanisme d’invention par un mécanisme de résumé et d’extraction. Le modèle ne génère plus à partir de rien, il synthétise les preuves qu’on lui donne. Cette différence fondamentale explique pourquoi le RAG améliore la précision de récupération de 20 à 40 % lorsque les embeddings sont bien choisis.

Concrètement, le pipeline force le LLM à s’appuyer sur des sources identifiables. Si l’information demandée ne figure pas dans les chunks récupérés, le modèle est invité à répondre qu’il ne sait pas, plutôt que de combler les lacunes. Ce garde-fou est d’autant plus efficace que le découpage en chunks est bon : des passages trop larges introduisent du bruit, des passages trop courts perdent le sens. Un chunking mal conçu reste la cause n°1 de résultats hors-sujet même avec le meilleur modèle d’embedding du marché.

Notons que la latence d’embedding varie selon l’infrastructure : comptez 50 à 200 ms par requête via l’API OpenAI, contre 10 à 50 ms avec Sentence Transformers en local, et seulement 2 à 10 ms par lot avec une accélération GPU. Pour un système RAG en production, cette différence se ressent directement dans l’expérience utilisateur.

Bases de données vectorielles et chunking : l’infrastructure d’une recherche sémantique performante

Bases de données vectorielles : stockage et indexation des embeddings

Une base vectorielle stocke pour chaque document son ID, le vecteur d’embedding et ses métadonnées (titre, URL, tags, langue, date de création). Ces métadonnées permettent de filtrer avant la recherche par exemple ne récupérer que les documents des 90 derniers jours et de gérer les permissions applicatives.

La taille des vecteurs impacte directement le stockage : un modèle à 768 dimensions consomme deux fois plus de mémoire qu’un modèle à 384 dimensions. Pour un usage général en RAG, la plage 384 à 768 dimensions offre le meilleur compromis ; les domaines complexes (juridique, médical) tirent parti de 1024 à 1536 dimensions, tandis que les applications à fort volume privilégient 256 à 384 dimensions.

À grande échelle, l’indexation ANN (approximate nearest neighbor) remplace la recherche exacte : elle sacrifie un peu de précision pour passer de plusieurs secondes à quelques millisecondes sur des millions de vecteurs. Les mises à jour se font par insert, update et delete le contenu modifié doit être ré-embedding.

Le chunking : le découpage qui fait la différence

• Impact majeur : le chunking influence souvent plus la qualité que le choix du modèle
• Taille fixe : simple à implémenter mais coupe les phrases en plein milieu
• Découpage par structure : respecte paragraphes, sections et titres du document
• Taille idéale : un chunk doit contenir une pensée complète
• Chevauchement : préserve le contexte aux frontières des chunks
• Mauvais chunking : cause n°1 de résultats hors-sujet

Un chunk trop petit perd le sens global ; trop grand, il introduit du bruit dans la similarité. La limite de 512 tokens des modèles d’embedding impose de toute façon un découpage : les chunks doivent tenir dans cette fenêtre. Un chevauchement de quelques dizaines de tokens entre chunks voisins préserve la continuité du propos et évite les coupures malheureuses. Le syndrome du « bon document, mauvais passage » où le système retrouve le bon article mais le mauvais paragraphe est presque toujours un problème de chunking, pas de modèle.

Cas d’usage concrets : quand la recherche sémantique transforme les applications métier

La recherche sémantique n’est pas une prouesse technique isolée : elle résout des problèmes métier très concrets, là où la recherche par mots-clés atteint ses limites. Voici comment elle transforme les opérations quotidiennes des équipes support, e-commerce et connaissance interne.

• Support client : retrouver un ticket ancien ou une transcription de chat en cherchant par paraphrase (« je veux résilier » ↔ « cancel my plan »), même si les termes diffèrent totalement.
• E-commerce : la découverte produit par intention (« petit sac à dos pro pour ordinateur 13 pouces ») plutôt que par nom exact, captant les synonymes et le contexte d’usage.
• Recommandations : proposer des « articles similaires » sémantiquement proches, traversant les catégories pour surprendre et convertir.
• Recherche interne entreprise : interroger les politiques RH, notes de réunion et documentations en langage naturel, sans connaître la terminologie exacte employée dans les documents.

Un cas d’école fréquemment cité : la requête « cancel my plan » échoue face à un article intitulé « terminate subscription ». La recherche lexicale classique ne fait pas le lien ; la recherche sémantique, si. C’est exactement ce que vivent les équipes support confrontées à des volumes massifs de tickets : la synonymie et la paraphrase bloquent la résolution rapide.

Les gains de précision sont significatifs : l’intégration de meilleurs embeddings améliore la précision de récupération de 20 à 40 % dans les systèmes de question-réponse. Cette amélioration se traduit par moins de temps de recherche pour les employés et des taux de résolution plus élevés.

Au-delà du texte : images, audio et code source

Les embeddings ne se limitent pas aux mots. Des modèles comme CLIP projettent images et texte dans un même espace vectoriel : on peut chercher une photo par une description textuelle. Le même principe s’applique à l’audio et au code source, permettant une recherche transversale dans des silos de données hétérogènes.

Données structurées et non structurées unifiées

La magie opère quand on unifie des sources disparates : PDF, e-mails, transcriptions audio, vidéos, mais aussi bases de données structurées. Tous sont convertis en vecteurs et interrogés de la même manière. Cette unification accélère la prise de décision en réduisant drastiquement le temps de recherche dans des volumes d’informations autrement ingérables.

FAQ : vos questions sur la recherche sémantique et les embeddings

Quelle est la différence entre recherche sémantique et vectorielle ?

La recherche vectorielle est une technique technique, tandis que la recherche sémantique est un objectif. La recherche vectorielle transforme chaque texte en une liste de nombres, un vecteur, puis calcule la distance entre ces vecteurs pour trouver les plus proches. La recherche sémantique est le résultat de cette opération : elle comprend le sens, le contexte et les synonymes, là où une recherche par mots-clés échoue. En résumé, tout système de recherche sémantique moderne repose sur des embeddings et la recherche vectorielle, mais la dimension sémantique est la finalité, pas la méthode.

Combien coûte le déploiement d’embeddings pour une application ?

Les coûts varient fortement mais restent faibles pour démarrer. Vous distinguez deux postes : la génération des embeddings (le calcul) et leur stockage. Pour la génération, les API cloud facturent généralement entre 0,02 et 0,40 dollar pour 1 million de tokens, soit quelques centimes pour des bases documentaires de taille moyenne. Le stockage vectoriel est lui aussi économique : les bases open source comme FAISS ou Qdrant sont gratuites, et les solutions managées commencent autour de 20 dollars par mois. Un projet pilote (100 000 documents) coûte souvent moins de 50 dollars en investissement initial. L’essentiel du budget se trouve dans le développement et l’optimisation du pipeline, pas dans le matériel.

Quel modèle d’embedding choisir pour un système RAG ?

Votre choix dépend de la langue et du volume de vos données. Pour du contenu français, privilégiez des modèles multilingues comme les modèles de la famille E5 ou BGE, qui excellent sur les tâches de similarité. Les modèles propriétaires comme ceux d’OpenAI ou de Cohere offrent une grande simplicité d’intégration. Pour un contrôle total et zéro coût, les modèles open source du classement MTEB vous garantissent des performances contrôlées. Pensez à évaluer vos documents réels : la qualité de la recherche dépendra plus de votre découpage et de vos tests que du choix du modèle. Un bon compromis actuel reste un modèle open source de taille moyenne combiné à une base vectorielle auto-hébergée.