Comment fonctionne la recherche sémantique en 2026 — embeddings, vecteurs et recherche hybride expliqués simplement. Pourquoi la recherche par mot-clé manque tes favoris, et ce qui répare ça.
Tape « combien ça coûte d'acquérir des clients » dans une recherche de favoris enregistrés et regarde rien matcher. La vidéo que tu cherches est là dans ta bibliothèque — tu l'as enregistrée. L'intervenant a dit « CAC » seize fois. Ta recherche a dit « coût d'acquisition client ». Les mots ne se recoupent pas. Le match échoue.
Ce mode d'échec a un nom : le problème du décalage de vocabulaire. C'est pourquoi la recherche par mot-clé continue de perdre, et c'est pourquoi la recherche sémantique est maintenant le default dans chaque outil sérieux qui cherche du contenu en forme de texte. En dessous : comment fonctionne vraiment la recherche sémantique en 2026 — en français clair, pas besoin de diplôme en maths — et pourquoi la plupart des apps grand public qui livrent de la « recherche IA » se trompent encore.
Les vieux systèmes de recherche matchaient des chaînes littérales. Tu tapais coût d'acquisition client, le système trouvait les documents contenant ces mots exacts. Les documents qui disaient « CAC » ou « le coût pour ramener de nouveaux acheteurs » ou « ce qu'on paie par inscription » restaient invisibles.
Dans la recherche en information retrieval, c'est mesuré depuis quarante ans. Le décalage de vocabulaire typique est autour de 70-80% : les gens utilisent des mots différents pour le même concept la plupart du temps. Si ta recherche ne matche que des chaînes littérales, tu manques quatre documents pertinents sur cinq. C'est une façon polie de dire « la recherche par mot-clé est cassée depuis 1985 ».
Deux choses ont réglé ça. La première, c'est les embeddings : une manière de représenter le sens comme des nombres, pour que deux phrases qui veulent dire la même chose finissent « proches » même si elles ne partagent aucun mot. La seconde, c'est les bases de données vectorielles : du stockage et des index qui peuvent trouver les vecteurs les plus proches vite, même quand le corpus compte des millions de documents.
Ensemble, c'est ce qui fait que la « recherche sémantique » existe.
Prends une phrase. Passe-la dans un réseau de neurones. Le réseau retourne une liste de nombres — typiquement 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 similaire produisent des listes similaires. L'exemple littéral :
"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 CLes embeddings A et B seront proches dans l'espace à 1 536 dimensions où ils vivent. C sera loin. La proximité se mesure par similarité cosinus — à quel point les deux vecteurs sont alignés dans cet espace à haute dimension. Des nombres proches de 1,0 signifient un sens presque identique ; proches de 0, sans rapport.
Tu peux te le représenter comme tracer chaque phrase comme un point dans une galaxie à 1 536 dimensions où la direction encode le sens. Les coordonnées réelles ne veulent rien dire toutes seules — ce qui compte, c'est quelles autres phrases atterrissent près de quoi.
Plusieurs modèles sont compétitifs en 2026. text-embedding-3-small d'OpenAI livre 1 536 dimensions nativement et supporte le Matryoshka representation (tu peux tronquer à 768 ou 256 dimensions pour économiser le stockage sans réentraîner). embed-v3 de Cohere est compétitif sur le contenu multilingue. Les alternatives open-source comme bge-large et nomic-embed-text sont à quelques points de précision et tournent sur un Mac.
Pour des charges multilingues — comme des vidéos enregistrées dans 30 langues avec des requêtes dans n'importe laquelle — text-embedding-3-small est actuellement le meilleur équilibre précision/coût/dimensions. Chez SavedThat on utilise la troncation Matryoshka à 768 dimensions : moitié du stockage, ~99% de la qualité de recherche. (Plus d'infos sur Matryoshka representation.)
Plein d'apps grand public en 2026 annoncent de la « recherche IA ». La plupart veulent dire une des trois choses suivantes :
Seule la première résout vraiment le décalage de vocabulaire sur tes données. Les deux autres sont productisées mais pas utiles pour retrouver ce que toi tu as enregistré.
Diagnostic rapide : si tu peux chercher le concept sans trouver le document, mais que tu le trouves en cherchant un de ses mots spécifiques, l'outil fait du #2 ou du #3 emballé en « recherche IA ». Si tu peux trouver le document par paraphrase, c'est du #1.
Les embeddings tout seuls n'aident pas s'il faut comparer chaque requête à des millions de vecteurs un par un. La recherche complète d'un index de 50 000 documents prend des centaines de millisecondes en naïf — beaucoup trop lent pour de l'interactif.
Le fix, c'est l'indexation par approximate nearest neighbour (ANN). Des structures de données spécialisées — HNSW (Hierarchical Navigable Small World), IVF, ScaNN — stockent les vecteurs pour que les matches les plus proches soient trouvés en moins de 10 millisecondes même sur des bibliothèques avec des dizaines de millions de vecteurs.
L'état de l'art actuel (mai 2026) pour de la recherche sémantique en production :
pgvector ; les bases de données vectorielles standalone comme Qdrant, Pinecone et Weaviate utilisent toutes HNSW ou des variantes proches. SavedThat tourne en HNSW sur pgvector parce que garder les vecteurs à côté des métadonnées relationnelles est opérationnellement plus simple que de maintenir deux bases de données.halfvec(768) dans pgvector est maintenant le default pour tout déploiement attentif aux coûts.À l'échelle de SavedThat (actuellement ~120 vidéos enregistrées × ~50 chunks chacune = 6 000 vecteurs), l'index tient en RAM et les lookups sont sub-milliseconde.
Maintenant la chute que la plupart des tutos passent sous silence : la recherche sémantique perd contre la recherche par mot-clé sur les phrases exactes.
Si tu cherches "text-embedding-3-small" (un nom de produit exact), la recherche par mot-clé renvoie le document mentionnant cette chaîne exacte au rang 1. La recherche sémantique peut classer plus haut un document qui parle d'« embeddings 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 est absente.
C'est réel. Les benchmarks publics montrent systématiquement que la sémantique pure sous-performe le mot-clé pour les requêtes à haute spécificité : noms de produit, signatures de fonction, citations exactes, dates, noms de marque. La chose que la sémantique devait régler (le décalage de vocabulaire) n'existe pas pour ces requêtes parce que l'utilisateur a tapé la chaîne littérale qu'il voulait.
Le fix, c'est de lancer les deux et fusionner les résultats.
La recherche hybride est la technique qui est devenue silencieusement le default dans les systèmes de recherche en production sérieux depuis 2024 :
1 / (rank + 60), sommé entre les deux méthodes. Les documents qui apparaissent bien dans les deux reçoivent un boost significatif ; les documents qui n'apparaissent que dans un contribuent quand même.La constante 60 est un chiffre magique benchmarké à mort et qui marche sur la plupart des corpus. Tu peux la tuner ; tu n'as généralement pas besoin.
Le résultat : les requêtes reformulées trouvent quand même les matches conceptuels (via le côté sémantique), et les requêtes phrase exacte classent quand même le match littéral en #1 (via le côté mot-clé). L'angle mort de chaque méthode est couvert par l'autre.
C'est ce que SavedThat livre comme recherche par défaut. Le RPC search_chunks dans notre Postgres lance les deux requêtes en parallèle, calcule les scores RRF, et renvoie les hits classés en ~80ms pour notre taille de corpus actuelle. (Microsoft sur la recherche hybride)
Pour des cas à fort enjeu — e-discovery légale, littérature médicale, recherche enterprise sur des millions de documents — le RRF hybride est généralement l'avant-dernière couche. La dernière, c'est le re-ranking avec un modèle cross-encoder.
Un cross-encoder est un modèle plus petit et plus lent qui prend la requête complète et le document candidat complet et calcule un score de pertinence serré en y faisant attention conjointement. Tu ne peux pas le lancer sur un million de documents (trop lent) ; tu le lances sur les top 50-200 résultats du retrieval hybride pour les re-ordonner précisément.
Cohere livre rerank-v3 pour ça. Alternatives open-source : bge-reranker-large, jina-reranker-v2. Pour des charges grand public comme SavedThat, le gain marginal ne justifie pas les 100ms de latence. Pour la recherche e-discovery légale enterprise, le re-ranking par cross-encoder est maintenant standard.
On l'ajoutera quand notre corpus ou notre cas d'usage l'exigera. Pas avant.
Le pipeline complet, approximativement :
| Étape | Coût |
|---|---|
| Embedding de 1 000 chunks (~50 vidéos) | ~0,02 $ en crédits OpenAI |
| Stockage de 1M de chunks dans pgvector | ~25 $/mois sur une petite instance Postgres |
| Build d'index HNSW pour 1M de chunks | ~30 secondes, une seule fois par changement majeur de données |
| Une requête de recherche (embed + lookup HNSW + FTS + RRF) | ~0,0001 $ + 80ms |
Au pricing de SavedThat, un abonnement Pro (6,99 $/mois) couvre des milliers de recherches et plusieurs centaines de nouveaux enregistrements. L'économie est bonne à l'échelle grand public ; ce qui ne marche pas, c'est d'essayer de financer ça avec un plan gratuit-à-vie-illimité parce que la facture OpenAI croît linéairement avec le contenu pendant que les revenus plafonnent à zéro.
Trois raisons :
halfvec et MRL, les maths sont du double.Les outils qui livrent de la recherche sémantique depuis le jour 1 — Mem, Reflect, le tier premium de Glasp, SavedThat — sont majoritairement des builds post-2022 parce que c'est là que le coût des embeddings est passé sous le seuil où l'échelle grand public peut être priceée durablement.
Quand tu évalues un outil de chercher-dans-X en 2026, demande :
text-embedding-3-small marche sur 100+ langues ; les modèles plus vieux ou plus petits, non.Pour enregistrer des vidéos et les retrouver plus tard : SavedThat livre les quatre (vue d'ensemble de l'architecture ici). Glasp livre mot-clé uniquement (offre gratuite) et sémantique (payant). Mem livre la sémantique sans l'hybride. La « recherche IA » de Notion est du #2 — LLM sur mot-clé.
C'est la carte du terrain en mai 2026.
Fonctionnellement aucune — en pratique les termes sont utilisés de manière interchangeable. Strictement, un embedding est la *représentation* qu'un modèle produit, et un vecteur n'est qu'une liste de nombres. Tout embedding est un vecteur ; tout vecteur n'est pas un embedding (une colonne d'intensités de pixels est un vecteur mais pas un embedding). La plupart des papers et docs d'ingénierie utilisent « vecteur » comme terme de stockage et « embedding » comme terme conceptuel.
Ça dépend du modèle d'embedding. text-embedding-3-small d'OpenAI a été entraîné sur 100+ langues et produit des vecteurs à peu près alignés entre elles — une requête en russe et un document en anglais sur le même concept atterrissent dans des régions similaires de l'espace vectoriel. Les modèles open-source plus petits se dégradent souvent significativement sur le non-anglais. Si le multilingue est un requis, vérifie que la model card mentionne explicitement l'alignement cross-lingue.
Lancer deux recherches et concaténer les résultats donne juste deux fois plus de résultats. La recherche hybride les fusionne par score (RRF ou fusion pondérée) pour que le classement final reflète l'accord entre les deux méthodes. Un document au rang 1 en mot-clé et au rang 1 en sémantique finit au rang 1 global ; un document au rang 1 en mot-clé mais au rang 50 en sémantique tombe au milieu. Sans fusion, tu ne sais pas à quels résultats faire confiance.
Les embeddings encodent le sens sémantique, pas les chaînes littérales. Une requête comme 'text-embedding-3-small' a son sens dans 'membre de la famille des embeddings OpenAI' plus que dans la séquence littérale de tokens. Le vecteur de la requête est similaire aux vecteurs de documents qui parlent des embeddings OpenAI en général, qui peuvent classer plus haut que le document spécifique mentionnant le nom exact du produit. La recherche par mot-clé a zéro ambiguïté sur les chaînes exactes — elles apparaissent ou non. L'hybride couvre les deux modes.
Liés mais pas identiques. La recherche sémantique est l'étape de retrieval — trouver des documents proches d'une requête dans l'espace vectoriel. Le RAG (Retrieval-Augmented Generation) est un système qui utilise la recherche sémantique pour récupérer des documents, puis les passe à un LLM génératif qui écrit une réponse en utilisant les documents comme contexte. Le RAG inclut la recherche sémantique comme un composant ; tu peux avoir de la recherche sémantique sans RAG (quand tu veux juste trouver les documents, pas générer de texte par-dessus).
Pour l'inférence — chercher contre un index déjà construit — non. CPU suffit pour du retrieval à l'échelle grand public. Pour construire l'index — faire tourner le modèle d'embedding sur ton contenu — un GPU est rapide mais pas requis. L'API d'OpenAI fait les embeddings dans leur datacenter, te renvoyant le vecteur à stocker ; la seule chose de ton côté, c'est la base de données vectorielle et l'embedding de la requête (un court appel API par requête). Le coût, c'est des centimes pour mille recherches.
Search inside saved videos by what was actually said — across YouTube, Instagram, and TikTok. How transcript search works in 2026, and four tools that do it.
The 7 best video transcript search tools in 2026, ranked by what they actually do well. SavedThat, Glasp, Otter, Fireflies, Reduct, Trint, plus DIY Whisper.
The best AI video bookmark manager in 2026 depends on what you save. Honest comparison of SavedThat, Mymind, Raindrop, and Glasp — pricing, search, platforms.