Accueil › Glossaire › Semantic Search

Semantic Search (Recherche Sémantique)

Le semantic search est une technique de recherche d’information qui exploite l’intelligence artificielle pour comprendre le sens et l’intention derrière une requête, au lieu de se limiter à la correspondance exacte de mots-clés.

Quand vous cherchez « comment protéger mon jardin du gel », un moteur de recherche classique va chercher des pages contenant exactement ces mots. Un moteur de recherche sémantique comprend que vous voulez des conseils de jardinage hivernal et peut vous renvoyer un article intitulé « Préparer ses plantations pour l’hiver » sans qu’aucun mot de votre requête n’y figure. C’est toute la différence entre chercher des mots et chercher du sens.

Comment fonctionne le semantic search

Le semantic search repose sur un principe fondamental : transformer du texte en vecteurs numériques (des embeddings) qui capturent le sens des mots, puis comparer ces vecteurs pour trouver les contenus les plus proches sémantiquement d’une requête. Voici les étapes concrètes du processus.

Étape 1 : Indexation du corpus

Avant toute recherche, chaque document de votre base (articles, fiches produit, FAQ, etc.) est converti en un vecteur numérique par un modèle d’embedding. Ce vecteur est typiquement une liste de 384 à 3072 nombres à virgule flottante, selon le modèle utilisé. Par exemple, le modèle all-MiniLM-L6-v2 de Sentence Transformers produit des vecteurs de 384 dimensions, tandis que text-embedding-3-large d’OpenAI peut aller jusqu’à 3072 dimensions. Ces vecteurs sont stockés dans une base de données vectorielle comme Pinecone, Weaviate ou Qdrant.

Étape 2 : Transformation de la requête

Quand un utilisateur tape sa requête, elle est convertie en vecteur avec le même modèle d’embedding. C’est un point critique : vous devez toujours utiliser le même modèle pour indexer vos documents et pour encoder vos requêtes. Comparer des embeddings issus de modèles différents produit des résultats incohérents.

Étape 3 : Recherche par similarité

Le système compare le vecteur de la requête avec tous les vecteurs du corpus en utilisant une métrique de distance, généralement la similarité cosinus (cosine similarity) ou le produit scalaire (dot product). Les documents dont les vecteurs sont les plus proches de celui de la requête sont considérés comme les plus pertinents. Pour éviter de parcourir des millions de vecteurs un par un, les bases vectorielles utilisent des algorithmes d’approximation comme HNSW (Hierarchical Navigable Small World) qui permettent une recherche en quelques millisecondes, même sur des corpus de plusieurs millions de documents.

Étape 4 : Reranking (optionnel)

Dans les pipelines les plus avancés, les résultats initiaux passent par une étape de reranking. Un modèle plus puissant (souvent un cross-encoder) évalue chaque paire requête-document pour affiner le classement. Cette étape est plus lente mais nettement plus précise. C’est le pattern standard dans les systèmes de RAG (Retrieval-Augmented Generation) en production.

Semantic search vs. keyword search

La différence fondamentale tient en une phrase : le keyword search cherche des mots, le semantic search cherche du sens. Voici un tableau comparatif pour clarifier les forces et limites de chaque approche.

Les technologies clés du semantic search

Modèles d’embedding

Le modèle d’embedding est le composant central. Il transforme du texte en vecteurs numériques qui capturent les relations sémantiques. Les principaux modèles utilisés en production :

Le choix du modèle dépend de votre cas d’usage. Plus le nombre de dimensions est élevé, meilleure est la capture sémantique, mais plus le stockage et le calcul sont coûteux. Pour un prototype ou une FAQ interne, all-MiniLM-L6-v2 (gratuit, open source) fait très bien le travail. Pour un moteur de recherche e-commerce en production avec des millions de produits, un modèle comme text-embedding-3-large ou Cohere Embed v3 sera plus adapté.

Bases de données vectorielles

Les embeddings doivent être stockés et interrogés efficacement. C’est le rôle des bases de données vectorielles, qui implémentent des algorithmes de recherche de plus proches voisins (ANN, Approximate Nearest Neighbor) pour retrouver les vecteurs les plus similaires en quelques millisecondes.

Les trois leaders du marché en 2026 :

D’autres options existent : Milvus (via Zilliz Cloud) pour les très gros volumes (milliards de vecteurs), Chroma pour le prototypage rapide, ou pgvector si vous souhaitez rester dans l’écosystème PostgreSQL. Elasticsearch et OpenSearch proposent aussi des capacités vectorielles intégrées, ce qui permet de combiner recherche textuelle classique et recherche sémantique dans un seul système.

Algorithmes de recherche ANN

Chercher le vecteur le plus proche parmi des millions d’entrées par force brute serait trop lent. Les algorithmes ANN (Approximate Nearest Neighbor) résolvent ce problème en échangeant une légère perte de précision contre un gain massif de vitesse. Le plus répandu est HNSW (Hierarchical Navigable Small World), un algorithme basé sur des graphes multi-couches qui permet une recherche en complexité logarithmique. Concrètement, que votre corpus contienne 100 000 ou 100 millions de documents, le temps de recherche reste de l’ordre de quelques millisecondes.

Autres algorithmes notables : IVF (Inverted File Index) pour les très gros volumes avec quantification, et FAISS (Facebook AI Similarity Search), une bibliothèque de Meta très utilisée en recherche pour benchmarker et prototyper.

Cas d’usage concrets

RAG (Retrieval-Augmented Generation)

Le cas d’usage le plus important du semantic search aujourd’hui est le RAG. Le principe : quand un utilisateur pose une question à un LLM, le système effectue d’abord une recherche sémantique dans une base de documents pour retrouver les passages les plus pertinents, puis injecte ces passages dans le prompt du LLM. Le modèle génère alors sa réponse en s’appuyant sur ces informations factuelles plutôt que sur sa seule mémoire d’entraînement. Résultat : moins d’hallucinations, des réponses plus fiables et à jour.

C’est exactement ce que font Perplexity, ChatGPT avec sa fonctionnalité de recherche web, et tous les chatbots d’entreprise qui répondent à des questions sur des documents internes.

Moteurs de recherche web

Google utilise le semantic search massivement depuis l’introduction de BERT en 2019, puis avec MUM et les modèles plus récents. Aujourd’hui, les AI Overviews de Google et les résultats de Perplexity reposent entièrement sur une compréhension sémantique des requêtes. L’ère du bourrage de mots-clés est définitivement révolue.

E-commerce et recommandation

Le semantic search transforme la recherche produit. Un utilisateur qui tape « robe légère pour mariage en été » obtient des résultats pertinents même si aucune fiche produit ne contient exactement ces mots. Les embeddings captent le concept et renvoient des robes de cocktail estivales, des tenues de cérémonie aérées, etc. Des plateformes comme Meilisearch et Algolia intègrent désormais la recherche sémantique en natif.

Recherche interne en entreprise

Slack, Notion, Confluence : les outils de productivité adoptent le semantic search pour permettre de retrouver des informations par le sens plutôt que par des mots-clés exacts. Quand vous cherchez « processus d’onboarding des nouveaux clients » dans votre base documentaire, le système retrouve aussi les documents intitulés « Guide d’intégration partenaire » ou « Procédure d’accueil client ».

Support client et chatbots

Les chatbots de support utilisent le semantic search pour matcher les questions des utilisateurs avec les articles de la base de connaissances, même quand la formulation diffère. « Mon colis n’est pas arrivé » matche avec un article FAQ intitulé « Suivi de livraison et retards ».

Implémenter le semantic search : guide pratique

Pipeline minimal en Python

Voici la structure d’un pipeline de semantic search minimal avec Sentence Transformers et FAISS :

from sentence_transformers import SentenceTransformer
import numpy as np
import faiss

# 1. Charger le modèle d'embedding
model = SentenceTransformer('all-MiniLM-L6-v2')

# 2. Encoder le corpus
documents = [
    "Guide pour protéger vos plantes du gel hivernal",
    "Les meilleures variétés de tomates pour l'été",
    "Comment installer un système d'arrosage automatique",
]
doc_embeddings = model.encode(documents)

# 3. Créer l'index FAISS
dimension = doc_embeddings.shape[1]  # 384 pour MiniLM
index = faiss.IndexFlatIP(dimension)  # Inner Product (cosine si normalisé)
faiss.normalize_L2(doc_embeddings)
index.add(doc_embeddings)

# 4. Rechercher
query = "protéger mon jardin du froid"
query_embedding = model.encode([query])
faiss.normalize_L2(query_embedding)

distances, indices = index.search(query_embedding, k=3)
for i, idx in enumerate(indices[0]):
    print(f"{i+1}. {documents[idx]} (score: {distances[0][i]:.3f})")

Ce code produit un résultat pertinent : le document sur la protection contre le gel apparaît en premier, bien que la requête ne contienne ni « gel » ni « plantes ».

Bonnes pratiques d’implémentation

Chunking : Ne pas indexer des documents entiers. Découpez-les en morceaux (chunks) de 200 à 500 tokens pour une granularité optimale. Des chunks trop longs diluent le signal sémantique. Des chunks trop courts perdent le contexte. Testez plusieurs tailles sur votre corpus spécifique.

Même modèle partout : Utilisez strictement le même modèle d’embedding pour l’indexation et la recherche. Un vecteur produit par OpenAI n’a aucun sens comparé à un vecteur produit par Cohere.

Hybrid search en production : Ne vous fiez jamais au semantic search seul. Les termes très spécifiques (numéros de référence, codes produit, noms propres) sont mal capturés par les embeddings. Combinez toujours avec une recherche par mots-clés (BM25) via le hybrid search.

Reranking : Pour les applications critiques, ajoutez un cross-encoder en post-traitement. Récupérez les top 20-50 résultats de votre recherche vectorielle, puis re-classez-les avec un modèle plus précis. Le gain de pertinence est souvent significatif pour un coût computationnel modéré.

Évaluation : Mesurez la qualité avec des métriques standard : precision@k (proportion de résultats pertinents dans les k premiers), recall@k (proportion des documents pertinents retrouvés), et NDCG (Normalized Discounted Cumulative Gain). Ne vous fiez jamais à votre intuition seule.

Semantic search et SEO

Le semantic search a profondément transformé le référencement. Google ne se contente plus de compter les occurrences d’un mot-clé. Le moteur analyse la pertinence sémantique globale d’une page : le sujet est-il couvert en profondeur ? Les entités mentionnées sont-elles cohérentes ? L’intention de l’utilisateur est-elle satisfaite ?

Pour les créateurs de contenu, cela signifie que le bourrage de mots-clés est contre-productif. Un article qui couvre naturellement un sujet avec ses termes connexes, ses variantes et ses concepts associés sera mieux classé qu’un texte qui répète 50 fois le même mot-clé. Le schéma de données structurées (Schema.org), les graphes de connaissances et les entités sont devenus des leviers SEO majeurs. L’objectif est de rapprocher l’embedding de votre contenu de celui des requêtes de vos utilisateurs cibles dans l’espace vectoriel de Google.

Les answer engines comme Perplexity et les AI Overviews de Google poussent cette logique encore plus loin : ils ne classent pas des pages, ils extraient et synthétisent l’information pertinente. La qualité sémantique du contenu est donc plus importante que jamais.

Limites et défis du semantic search

Correspondances exactes ratées. C’est le talon d’Achille. Un embedding ne capture pas bien un numéro de série, un code juridique ou un terme très spécifique à un domaine. La requête « article L.225-37 du Code de commerce » risque de renvoyer des résultats sur le droit des sociétés en général plutôt que cet article précis. C’est pourquoi le hybrid search est indispensable en production.

Coût computationnel. Générer des embeddings pour des millions de documents nécessite du GPU. Stocker des vecteurs de 1024 dimensions pour 10 millions de documents représente environ 40 Go de mémoire. Les coûts d’infrastructure sont significativement plus élevés qu’un index inversé classique.

Opacité. Il est difficile d’expliquer pourquoi le système a renvoyé un résultat plutôt qu’un autre. Avec BM25, vous pouvez tracer exactement quels mots ont matché et avec quel score. Avec le semantic search, le raisonnement est enfoui dans les 1024 dimensions d’un vecteur.

Qualité dépendante du modèle. Les performances varient fortement selon le modèle d’embedding choisi et le domaine. Un modèle entraîné sur du texte généraliste fonctionnera moins bien sur des corpus médicaux ou juridiques spécialisés. Le fine-tuning du modèle d’embedding sur votre domaine améliore significativement les résultats mais demande des données étiquetées.

Latence de mise à jour. Quand un nouveau document est ajouté, il faut générer son embedding et l’insérer dans l’index. Sur les systèmes à très haut volume, cette latence peut être un enjeu. Les bases vectorielles modernes supportent l’insertion en temps réel, mais la réindexation complète reste coûteuse.

Verdict

Le semantic search n’est plus une technologie expérimentale. C’est le standard de facto pour toute application qui nécessite de retrouver de l’information par le sens : RAG, chatbots, moteurs de recherche internes, e-commerce. Si vous construisez un système d’information retrieval en 2026, ne pas utiliser de semantic search est un choix à contrejustifier.

Cela dit, le semantic search seul ne suffit jamais. Les meilleures implémentations combinent recherche vectorielle et recherche par mots-clés (hybrid search), ajoutent une étape de reranking avec un cross-encoder, et affinent le modèle d’embedding sur leur domaine. L’outil simple qui « marche tout seul » n’existe pas encore : la qualité du pipeline de recherche dépend de vos données, de votre chunking, et de votre évaluation continue.

Pour démarrer rapidement : un modèle Sentence Transformers open source + Qdrant en self-hosted (gratuit) ou Pinecone (free tier). Pour la production à l’échelle : Weaviate ou Elasticsearch avec hybrid search natif, un modèle d’embedding premium (OpenAI ou Cohere), et un cross-encoder pour le reranking.