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

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

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

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 architecture possible, étape par étape. , comme pour sécuriser ses comptes,

Pour approfondir les applications pratiques des embeddings et du RAG, notamment dans les assistants conversationnels, vous pouvez consulter notre guide sur discord ia, qui explore comment ces technologies améliorent l’expérience utilisateur.

Pour implémenter efficacement ce pipeline, le choix du langage de programmation est crucial. Que vous optiez pour TypeScript ou JavaScript, les bibliothèques d’embeddings et de RAG sont disponibles dans les deux écosystèmes, facilitant l’intégration dans vos projets web.

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