guides

Comment fonctionne la recherche sémantique (2026)

Comment fonctionne la recherche sémantique : embeddings, vecteurs et recherche hybride expliqués simplement, et pourquoi les mots-clés ratent tes favoris.

SavedThat teamPublié le 11 mai 2026Mis à jour le 30 sept. 202616 min de lecture

Tape « combien ça coûte d'acquérir des clients » dans le moteur de recherche de tes favoris, et regarde : rien ne correspond. La vidéo que tu cherches est pourtant dans ta bibliothèque, puisque tu l'as enregistrée. L'intervenant a dit « CAC » seize fois. Toi, tu as tapé « coût d'acquisition client ». Les mots ne se recoupent pas. Aucun résultat.

Ce type d'échec porte un nom : le problème du décalage de vocabulaire. C'est pour cela que la recherche par mots-clés continue de perdre du terrain, et pour cela que la recherche sémantique est désormais la norme dans tous les outils sérieux qui cherchent dans du texte. Voici comment fonctionne vraiment la recherche sémantique en 2026, en termes simples, sans diplôme de maths requis, et pourquoi la plupart des applis grand public qui vantent leur « recherche IA » se trompent encore.

Le problème du décalage de vocabulaire en 60 secondes

Les anciens moteurs de recherche comparaient des chaînes de caractères littérales. Tu tapais coût d'acquisition client, et le système trouvait les documents qui contenaient exactement ces mots. Ceux qui disaient « CAC », « le coût pour attirer de nouveaux acheteurs » ou « ce qu'on paie par inscription » restaient invisibles.

La recherche en recherche d'information mesure ce phénomène depuis quarante ans. Le décalage de vocabulaire typique tourne autour de 70 à 80 % : la plupart du temps, les gens emploient des mots différents pour désigner la même chose. Si ta recherche se limite aux chaînes littérales, tu passes à côté de quatre documents pertinents sur cinq. Autrement dit, poliment : « la recherche par mots-clés ne marche pas depuis 1985 ».

Deux avancées ont réglé le problème. La première, ce sont les embeddings : une façon de représenter le sens sous forme de nombres, pour que deux phrases qui veulent dire la même chose se retrouvent « proches », même si elles n'ont aucun mot en commun. La seconde, ce sont les bases de données vectorielles : des systèmes de stockage et d'indexation capables de trouver rapidement les vecteurs les plus proches, même quand le corpus compte des millions de documents.

Réunies, elles rendent la « recherche sémantique » possible.

Ce qu'est un embedding, en clair

Prends une phrase. Fais-la passer dans un réseau de neurones. Le réseau renvoie une liste de nombres, en général 384, 768 ou 1 536. Cette liste, c'est l'embedding de la phrase.

L'astuce, c'est que le réseau est entraîné pour que des phrases de sens proche produisent des listes proches. Un exemple concret :

"Qu'est-ce que le coût d'acquisition client" → embedding A
"Combien on paie pour ramener un nouveau client" → embedding B
"Comment vont les mouettes aujourd'hui" → embedding C

Les embeddings A et B seront proches dans l'espace à 1 536 dimensions où ils se trouvent. C sera loin. La proximité se mesure par la similarité cosinus, c'est-à-dire le degré d'alignement des deux vecteurs dans cet espace à très grand nombre de dimensions. Une valeur proche de 1,0 signifie un sens presque identique ; proche de 0, aucun rapport.

Imagine chaque phrase comme un point dans une galaxie à 1 536 dimensions, où la direction traduit le sens. Les coordonnées elles-mêmes ne veulent rien dire : ce qui compte, c'est quelles phrases se retrouvent à côté de quelles autres.

Le modèle qui s'en charge

En 2026, plusieurs modèles se valent. text-embedding-3-small d'OpenAI produit nativement 1 536 dimensions et prend en charge la représentation Matryoshka (tu peux tronquer à 768 ou 256 dimensions pour économiser du stockage sans réentraîner). embed-v3 de Cohere tient la comparaison sur les contenus multilingues. Les alternatives open source comme bge-large et nomic-embed-text ne sont qu'à quelques points de précision et tournent sur un Mac.

Pour des usages multilingues, comme les vidéos enregistrées par les utilisateurs de SavedThat (24 langues au 30 septembre 2026, avec des requêtes dans n'importe laquelle), text-embedding-3-small offre aujourd'hui le meilleur équilibre entre précision, coût et nombre de dimensions. Chez SavedThat, nous tronquons à 768 dimensions grâce à Matryoshka : moitié moins de stockage pour environ 99 % de la qualité de recherche. (En savoir plus sur la représentation Matryoshka.)

Pourquoi « utiliser l'IA » ne veut pas dire faire de la recherche sémantique

En 2026, beaucoup d'applis grand public annoncent une « recherche IA ». La plupart désignent par là l'une de ces trois choses :

Une vraie recherche sémantique : embeddings et recherche vectorielle, comme décrit plus haut.
Un LLM posé sur une recherche par mots-clés : le système lance une recherche par mots-clés, récupère des résultats, puis demande à un LLM de les reformuler ou de les résumer. La recherche elle-même reste limitée aux mots-clés ; le LLM ne fait que maquiller les échecs.
Des questions-réponses avec un LLM seul : tu poses une question, le LLM répond à partir de ses connaissances générales, et ton contenu enregistré n'est jamais consulté.

Seule la première résout vraiment le décalage de vocabulaire sur tes données. Les deux autres font de beaux arguments commerciaux, mais ne t'aident pas à retrouver ce que toi, tu as enregistré.

Test rapide : si chercher le concept ne trouve pas le document, alors que chercher l'un de ses mots précis le trouve, l'outil fait du n° 2 ou du n° 3 déguisé en « recherche IA ». Si tu retrouves le document avec une reformulation, c'est du n° 1.

Bases de données vectorielles : stocker les embeddings et les retrouver vite

Les embeddings seuls ne servent à rien s'il faut comparer chaque requête à des millions de vecteurs, un par un. Parcourir entièrement un index de 50 000 documents prend, avec une approche naïve, plusieurs centaines de millisecondes : bien trop lent pour un usage interactif.

La solution, c'est l'indexation par plus proches voisins approximatifs (ANN, approximate nearest neighbour). Des structures de données spécialisées, comme HNSW (Hierarchical Navigable Small World), IVF ou ScaNN, organisent les vecteurs pour trouver les plus proches en moins de 10 millisecondes, même dans des bibliothèques de plusieurs dizaines de millions de vecteurs.

L'état de l'art actuel (mai 2026) pour la recherche sémantique en production :

L'indexation HNSW est la plus répandue. Postgres la propose via l'extension pgvector ; les bases vectorielles autonomes comme Qdrant, Pinecone et Weaviate utilisent toutes HNSW ou des variantes proches. SavedThat utilise HNSW sur pgvector, car garder les vecteurs à côté des métadonnées relationnelles est plus simple à exploiter que d'entretenir deux bases de données.
Le stockage en demi-précision. Avec des flottants de 16 bits par dimension au lieu de 32, les vecteurs occupent deux fois moins d'espace disque. La perte de qualité est négligeable pour la recherche. Le type halfvec(768) de pgvector est désormais le choix par défaut de tout déploiement soucieux de ses coûts.
La troncature MRL (Matryoshka). Des embeddings entraînés une fois pour toutes à 1 536 dimensions sont tronqués au stockage à 768 ou 256 dimensions selon l'usage. On interroge d'abord un index rapide à 256 dimensions, puis on reclasse les 100 premiers résultats avec la version à 768 ou 1 536 dimensions.

À l'échelle de SavedThat (environ 230 000 segments de transcription dans l'ensemble de l'index au 30 septembre 2026), l'index tient en mémoire vive.

Le piège : seule, la recherche sémantique se trompe sur les expressions exactes

Voici maintenant ce que la plupart des tutoriels passent sous silence : sur les expressions exactes, la recherche sémantique fait moins bien que la recherche par mots-clés.

Si tu cherches "text-embedding-3-small" (un nom de produit exact), la recherche par mots-clés place en tête le document qui contient cette chaîne précise. La recherche sémantique, elle, peut classer plus haut un document qui parle des « embeddings d'OpenAI en général », parce qu'il est sémantiquement plus proche du sens moyen de la requête, même si la chaîne littérale n'y figure pas.

Le phénomène est bien réel. Les bancs d'essai publics montrent systématiquement que la recherche purement sémantique fait moins bien que les mots-clés sur les requêtes très précises : noms de produits, signatures de fonctions, citations exactes, dates, noms de marques. Le problème que la sémantique devait résoudre (le décalage de vocabulaire) ne se pose pas pour ces requêtes, puisque l'utilisateur a tapé exactement la chaîne qu'il voulait.

La solution : lancer les deux et fusionner les résultats.

La recherche hybride avec Reciprocal Rank Fusion

Depuis 2024, la recherche hybride s'est imposée sans bruit comme la norme dans les systèmes de recherche sérieux en production :

Lancer une recherche sémantique (similarité vectorielle) et récupérer les K premiers résultats, classés par similarité cosinus.
Lancer une recherche plein texte (mots-clés, tsvector, BM25, peu importe) et récupérer les K premiers résultats, classés par score de pertinence.
Fusionner les deux listes par fusion des rangs réciproques (Reciprocal Rank Fusion, RRF) : le score RRF de chaque document vaut 1 / (rank + 60), additionné sur les deux méthodes. Les documents bien classés dans les deux listes reçoivent un net coup de pouce ; ceux qui n'apparaissent que dans une seule comptent quand même.
Trier par score RRF combiné.

La constante 60 est un nombre magique éprouvé par d'innombrables tests, qui fonctionne sur la plupart des corpus. Tu peux l'ajuster ; en général, ce n'est pas nécessaire.

Résultat : les requêtes reformulées trouvent quand même les correspondances de sens (grâce au volet sémantique), et les requêtes sur une expression exacte placent quand même la correspondance littérale en tête (grâce au volet mots-clés). L'angle mort de chaque méthode est couvert par l'autre.

C'est la recherche que SavedThat propose par défaut. La fonction RPC search_chunks de notre base Postgres lance les deux requêtes en parallèle, calcule les scores RRF et renvoie les résultats classés. De bout en bout, calcul de l'embedding de la requête compris, une recherche prenait en médiane environ 1,3 seconde en septembre 2026. (Microsoft sur la recherche hybride)

Pour aller encore plus loin : le reclassement

Pour les usages à fort enjeu (découverte de pièces dans un contentieux, littérature médicale, recherche en entreprise sur des millions de documents), la fusion RRF hybride n'est en général que l'avant-dernière couche. La dernière, c'est le reclassement par un modèle cross-encoder.

Un cross-encoder est un modèle plus petit et plus lent qui prend en entrée la requête entière et le document candidat entier, et calcule un score de pertinence précis en examinant les deux ensemble. Impossible de le faire tourner sur un million de documents (trop lent) : on l'applique aux 50 à 200 premiers résultats de la recherche hybride pour les remettre précisément dans l'ordre.

Cohere propose rerank-v3 pour cela. Côté open source : bge-reranker-large, jina-reranker-v2. Pour un usage grand public comme SavedThat, le gain marginal ne justifie pas les 100 ms de latence supplémentaires. Pour la recherche documentaire juridique en entreprise, le reclassement par cross-encoder est désormais la norme.

Nous l'ajouterons quand notre corpus ou nos usages l'exigeront. Pas avant.

Ce que ça coûte

La chaîne complète, en ordre de grandeur :

Étape	Coût
Embeddings de 1 000 segments (environ 50 vidéos)	environ 0,02 $ en crédits OpenAI
Stockage de 1 million de segments dans pgvector	environ 25 $/mois sur une petite instance Postgres
Construction de l'index HNSW pour 1 million de segments	environ 30 secondes, une seule fois par changement majeur des données
Une requête de recherche (embedding + recherche HNSW + plein texte + RRF)	environ 0,0001 $, à peu près 1,3 s au total

Aux tarifs de SavedThat, un abonnement Pro (9,99 $/mois) couvre des milliers de recherches et jusqu'à 300 nouveaux enregistrements par mois. Le modèle économique tient à l'échelle grand public ; ce qui ne tient pas, c'est de vouloir le financer avec une offre gratuite, illimitée et à vie, car la facture OpenAI augmente proportionnellement au contenu pendant que les revenus restent bloqués à zéro.

Pourquoi la plupart des outils de « second cerveau » ne le proposent pas

Pour trois raisons :

La complexité technique. La recherche hybride avec RRF oblige à faire tourner deux systèmes de recherche et à fusionner leurs résultats. La plupart des équipes n'en mettent en place qu'un. Et c'est en général la recherche par mots-clés, parce qu'elle est plus ancienne et que ses outils sont éprouvés.
Le coût de stockage. Des embeddings à 1 536 dimensions × 4 octets par dimension, cela fait environ 6 Ko par segment. Une bibliothèque de 100 000 segments représente 600 Mo de stockage vectoriel, en plus du texte d'origine. Sans halfvec ni MRL, il faut compter le double.
L'inertie. La plupart des outils de prise de notes existants sont sortis avant que les embeddings de phrases deviennent bon marché et banals. Ajouter après coup la recherche sémantique à Evernote ou à Pocket aurait exigé un chantier de base vectorielle que l'entreprise n'a jamais jugé prioritaire.

Les outils qui proposent la recherche sémantique depuis leur lancement (Mem, Reflect, l'offre premium de Glasp, SavedThat) sont pour la plupart nés après 2022, parce que c'est à ce moment que le coût des embeddings est passé sous le seuil permettant de les proposer durablement au grand public, à un prix tenable.

Ce que ça change concrètement

Quand tu évalues un outil censé chercher dans tel ou tel contenu en 2026, pose ces questions :

Calcule-t-il des embeddings ? Si son schéma d'architecture ne comporte pas de base vectorielle, la réponse est non.
Fait-il de la recherche hybride ? La recherche purement sémantique est moins bonne que l'hybride pour beaucoup de requêtes réelles. Les outils qui proposent une « recherche vectorielle » sans recherche plein texte ne font que la moitié du travail.
Gère-t-il plusieurs langues ? Cela dépend du modèle d'embedding, pas de l'infrastructure de recherche. text-embedding-3-small fonctionne dans plus de 100 langues ; les modèles plus anciens ou plus petits, non.
Explique-t-il seulement comment il fonctionne ? Les outils qui détaillent leur méthode de recherche la maîtrisent en général. Ceux qui affichent « recherche propulsée par l'IA ✨ » sans plus de précisions font le plus souvent du n° 2 ou du n° 3 décrits plus haut (LLM sur mots-clés, ou questions-réponses seules).

Pour enregistrer des vidéos et les retrouver plus tard : SavedThat coche les quatre cases (présentation de l'architecture ici). Glasp propose uniquement les mots-clés (offre gratuite) ou la sémantique (offre payante). Mem propose la sémantique sans l'hybride. La « recherche IA » de Notion relève du n° 2 : un LLM sur des mots-clés.

Voilà l'état des lieux en mai 2026.

Questions fréquentes (2026)

Quelle est la différence entre un embedding et un vecteur ?

Dans les faits, aucune : les deux termes s'emploient indifféremment. Au sens strict, un embedding est la *représentation* produite par un modèle, et un vecteur n'est qu'une liste de nombres. Tout embedding est un vecteur, mais tout vecteur n'est pas un embedding (une colonne d'intensités de pixels est un vecteur, pas un embedding). La plupart des articles de recherche et des documentations techniques emploient « vecteur » pour parler du stockage et « embedding » pour parler du concept.

La recherche sémantique fonctionne-t-elle dans n'importe quelle langue ?

Cela dépend du modèle d'embedding. text-embedding-3-small d'OpenAI a été entraîné sur plus de 100 langues et produit des vecteurs à peu près alignés d'une langue à l'autre : une requête en russe et un document en anglais sur le même sujet atterrissent dans des régions voisines de l'espace vectoriel. Les modèles open source plus petits perdent souvent beaucoup en qualité hors de l'anglais. Si tu as besoin du multilingue, vérifie que la fiche du modèle mentionne explicitement l'alignement entre les langues.

En quoi la recherche hybride diffère-t-elle du fait de lancer deux recherches et d'afficher les deux ?

Lancer deux recherches et mettre les résultats bout à bout donne simplement deux fois plus de résultats. La recherche hybride les fusionne par score (RRF ou fusion pondérée), de sorte que le classement final reflète l'accord entre les deux méthodes. Un document premier en mots-clés et premier en sémantique finit premier au classement général ; un document premier en mots-clés mais cinquantième en sémantique se retrouve au milieu. Sans fusion, tu ne sais pas à quels résultats te fier.

Pourquoi la recherche purement sémantique fait-elle moins bien que les mots-clés sur les expressions exactes ?

Les embeddings encodent le sens, pas les chaînes de caractères littérales. Une requête comme « text-embedding-3-small » a pour sens « un membre de la famille des embeddings d'OpenAI » bien plus que la suite exacte de tokens. Son vecteur ressemble donc à ceux des documents qui parlent des embeddings d'OpenAI en général, qui peuvent se classer devant le document qui cite précisément le nom du produit. La recherche par mots-clés, elle, ne laisse aucune ambiguïté sur les chaînes exactes : elles figurent dans le texte ou non. L'hybride couvre les deux cas.

Le RAG, est-ce la même chose que la recherche sémantique ?

Les deux sont liés, mais pas identiques. La recherche sémantique est l'étape de recherche proprement dite : trouver les documents proches d'une requête dans l'espace vectoriel. Le RAG (Retrieval-Augmented Generation, génération augmentée par la recherche) est un système qui utilise la recherche sémantique pour récupérer des documents, puis les transmet à un LLM génératif qui rédige une réponse en s'appuyant sur ces documents. Le RAG inclut la recherche sémantique comme l'un de ses composants ; on peut faire de la recherche sémantique sans RAG (quand on veut seulement trouver les documents, sans générer de texte à partir d'eux).

Faut-il un GPU pour faire de la recherche sémantique ?

Pour l'interrogation, c'est-à-dire chercher dans un index déjà construit, non : un CPU suffit à l'échelle grand public. Pour construire l'index, c'est-à-dire faire tourner le modèle d'embedding sur ton contenu, un GPU va plus vite mais n'est pas indispensable. L'API d'OpenAI calcule les embeddings dans ses centres de données et te renvoie le vecteur à stocker ; de ton côté, il ne reste que la base vectorielle et l'embedding de la requête (un court appel d'API par requête). Le coût se compte en centimes pour mille recherches.