Bases de données vectorielles : le moteur discret de l'IA moderne

Derrière chaque assistant conversationnel qui « comprend » une question, chaque moteur de recherche qui trouve le bon document même quand aucun mot-clé ne correspond, chaque système de recommandation qui devine ce qui vous plaira, se cache une pièce d'infrastructure discrète mais décisive : la base de données vectorielle. On en parle rarement dans les gros titres, éclipsée par les modèles de langage aux noms tapageurs. Pourtant, sans elle, la plupart des applications d'intelligence artificielle qui manipulent du sens seraient tout simplement impraticables à grande échelle. C'est le moteur qui tourne sous le capot — invisible, mais indispensable.

Cet article propose un panorama accessible et concret de ces bases de données pas comme les autres. Nous partirons de la brique élémentaire — l'embedding, cette manière de transformer du sens en chiffres — pour comprendre ensuite pourquoi une base classique ne suffit plus, comment fonctionne la recherche par similarité, quels algorithmes rendent la chose rapide à l'échelle du milliard de vecteurs, et enfin comment choisir une solution parmi le paysage foisonnant des outils disponibles. L'objectif n'est pas de vendre une technologie, mais de vous donner les clés pour comprendre ce qui se joue et décider en connaissance de cause.

Un mot de méthode. Ce domaine avance vite et se prête volontiers aux formules marketing. Nous nous en tiendrons aux mécanismes vérifiables et aux ordres de grandeur documentés, en signalant honnêtement les limites et les compromis. Car une base vectorielle, comme tout outil, brille sur certains usages et se révèle superflue sur d'autres. Savoir quand elle est pertinente vaut mieux que de l'adopter par réflexe.

L'embedding : transformer le sens en coordonnées

Tout commence par une idée à la fois simple et profonde : et si l'on pouvait représenter le sens d'un mot, d'une phrase ou d'une image par une liste de nombres ? C'est exactement ce que fait un embedding. Un modèle spécialisé, entraîné sur d'immenses corpus, apprend à convertir une donnée — un fragment de texte, une photo, un extrait sonore — en un vecteur, c'est-à-dire une suite de plusieurs centaines, voire plusieurs milliers de nombres.

Comme le résume IBM dans sa documentation technique, un embedding vectoriel est « une liste de nombres qui désigne un emplacement dans un espace multidimensionnel ». Chaque dimension de ce vecteur encode une caractéristique apprise de la donnée. Ces caractéristiques ne sont pas définies à la main : elles émergent de l'entraînement du modèle, qui découvre seul quelles dimensions sont utiles pour représenter le sens.

La géométrie du sens

La propriété qui rend les embeddings si utiles tient en une phrase : dans cet espace, la proximité géométrique reflète la proximité sémantique. Deux textes qui parlent de la même chose se retrouvent proches l'un de l'autre ; deux textes sans rapport se retrouvent éloignés. « Chat » et « félin » seront voisins ; « chat » et « comptabilité » seront distants. C'est là que réside toute la magie — et elle n'a rien de mystérieux : elle découle directement de la manière dont le modèle a été entraîné à placer les concepts liés côte à côte.

Cette organisation ouvre des possibilités que la recherche par mots-clés ne permettait pas. Prenons un exemple parlant. Un moteur classique cherchant l'expression exacte « comment réduire ma facture d'électricité » passera à côté d'un document intitulé « astuces pour diminuer sa consommation d'énergie », faute de mots communs. Un moteur fondé sur les embeddings, lui, comprendra que les deux formulations désignent la même intention, parce que leurs vecteurs seront voisins dans l'espace. On parle alors de recherche sémantique : on cherche le sens, pas les mots.

Un embedding ne stocke pas des mots, il stocke une position dans un espace de sens. Deux idées proches occupent des points voisins — et c'est cette géométrie qui rend la recherche sémantique possible.

Figure 1. Deux formulations du même besoin (orange) atterrissent côte à côte, sans partager un seul mot. Le « chat » (bleu) reste très éloigné : la géométrie encode le sens, pas les chaînes de caractères.

Une brique universelle

Le principe ne se limite pas au texte. Les mêmes techniques permettent de produire des embeddings d'images, de sons, de vidéos, de code source, voire de combinaisons de plusieurs modalités. Un embedding d'image et un embedding de texte peuvent d'ailleurs être placés dans le même espace, ce qui autorise à retrouver une photo à partir d'une description écrite. Cette généralité fait de l'embedding une brique fondamentale, réutilisable dans une multitude d'applications : recherche, recommandation, détection de doublons, classification, regroupement automatique de documents similaires.

Il faut toutefois garder en tête une limite honnête : la qualité de l'embedding dépend entièrement du modèle qui le produit. Un bon modèle d'embedding place les concepts avec finesse ; un modèle médiocre brouille les distances et dégrade toute la chaîne en aval. Le choix du modèle d'embedding est donc au moins aussi important que celui de la base de données qui stockera les vecteurs. C'est un point souvent négligé, alors qu'il conditionne la pertinence des résultats plus que n'importe quel réglage technique.

Pourquoi une base de données classique ne suffit plus

Une fois que l'on sait produire des embeddings, une question pratique se pose : où les ranger et comment les interroger ? On pourrait être tenté de les stocker dans une base de données traditionnelle, relationnelle par exemple. Après tout, un vecteur n'est qu'une liste de nombres, et les bases classiques savent stocker des nombres. Le problème n'est pas le stockage — c'est la recherche.

Les bases de données classiques sont optimisées pour un type de question précis : trouver les enregistrements dont une valeur correspond exactement à un critère, ou tombe dans un intervalle. « Donne-moi tous les clients dont l'âge est supérieur à 40 ans » est une requête que ces bases exécutent avec une efficacité redoutable, grâce à des index arborescents éprouvés depuis des décennies. Mais la question posée à une base vectorielle est d'une tout autre nature : « donne-moi les dix vecteurs les plus proches de celui-ci, dans un espace à mille dimensions ». Ce n'est plus une question d'égalité ou d'intervalle, mais de similarité géométrique.

Le problème du plus proche voisin

Ce problème porte un nom : la recherche du plus proche voisin (nearest neighbor). Trouver, parmi des millions de points, celui qui est le plus proche d'un point de requête. La méthode naïve consiste à calculer la distance entre le vecteur de requête et chacun des vecteurs stockés, puis à retenir les plus petits. C'est ce qu'on appelle une recherche exhaustive, ou « force brute ».

Sur quelques milliers de vecteurs, cette approche fonctionne très bien. Le souci apparaît à l'échelle. Comparer un vecteur de requête à cent millions de vecteurs de mille dimensions chacun représente cent milliards de multiplications pour une seule recherche. Répétez cela pour chaque requête d'un service qui en traite des milliers par seconde, et la facture de calcul devient intenable. La recherche exhaustive ne passe pas à l'échelle — c'est un fait mathématique, pas un défaut d'implémentation.

C'est précisément le vide que comblent les bases de données vectorielles. Comme le formule IBM, une base vectorielle « stocke et récupère les données sous forme de représentations numériques appelées embeddings, permettant une recherche fondée sur la similarité sémantique plutôt que sur la correspondance exacte de mots-clés ». Leur raison d'être n'est pas de stocker les vecteurs — n'importe quelle base peut le faire — mais de les chercher vite, à très grande échelle, en acceptant un compromis intelligent que nous allons détailler.

Mesurer la similarité : les distances qui comptent

Avant de parler d'algorithmes rapides, il faut clarifier une notion centrale : que signifie « proche » quand on parle de vecteurs ? Il n'existe pas une seule façon de mesurer la proximité, mais plusieurs, et le choix a des conséquences concrètes. Trois métriques dominent l'usage.

Les trois métriques usuelles

• La distance euclidienne mesure la distance en ligne droite entre deux points, exactement comme on mesurerait la distance entre deux villes sur une carte. Plus la distance est petite, plus les vecteurs sont proches. Elle tient compte à la fois de la direction et de la magnitude des vecteurs.
• La similarité cosinus s'intéresse uniquement à l'angle formé par deux vecteurs, en ignorant leur longueur. Deux vecteurs qui pointent dans la même direction sont jugés similaires, quelle que soit leur amplitude. C'est de loin la métrique la plus répandue pour les embeddings de texte, car le sens est porté par la direction, pas par la magnitude.
• Le produit scalaire (ou produit intérieur) combine direction et magnitude. Sur des vecteurs normalisés — c'est-à-dire ramenés à une longueur unitaire — il devient équivalent à la similarité cosinus, ce qui explique qu'on les confonde souvent.

Ce dernier point n'est pas anecdotique. La documentation de Pinecone comme celle de Milvus insistent sur une règle d'or : la métrique de similarité utilisée pour interroger la base doit correspondre à celle avec laquelle le modèle d'embedding a été entraîné. La plupart des modèles de phrases modernes — de la famille Sentence-BERT aux modèles E5 ou GTE — sont pensés pour la similarité cosinus. Utiliser une distance euclidienne sur des vecteurs conçus pour le cosinus dégrade silencieusement la qualité des résultats, sans jamais lever d'erreur. C'est le genre de piège discret qui coûte cher : rien ne casse, mais tout se dégrade.

La règle la plus simple pour choisir sa métrique : reprendre celle avec laquelle le modèle d'embedding a été entraîné. Le reste n'est qu'optimisation de second ordre.

Retenons donc une chose : le choix de la métrique n'est pas un réglage arbitraire, mais une contrainte imposée par le modèle d'embedding en amont. Une base vectorielle bien configurée respecte cette cohérence de bout en bout, du modèle qui produit les vecteurs jusqu'à la requête qui les compare.

La recherche approximative : le compromis fondateur

Nous voici au cœur du sujet, et à l'idée qui change tout. Puisque la recherche exhaustive du plus proche voisin est trop coûteuse à grande échelle, l'industrie a fait un pari lucide : renoncer à la certitude de trouver le voisin exact, en échange d'une accélération colossale. C'est le principe de la recherche du plus proche voisin approximatif, ou ANN (Approximate Nearest Neighbor).

L'intuition est la suivante. Dans la quasi-totalité des applications réelles — recherche documentaire, recommandation, RAG — il importe peu de trouver le tout premier voisin exact plutôt que le deuxième ou le troisième. Ce qui compte, c'est de remonter des résultats pertinents, très vite. Accepter une petite marge d'imprécision permet d'accélérer la recherche de plusieurs ordres de grandeur. On échange quelques dixièmes de pourcent de « rappel » — la proportion de vrais voisins effectivement retrouvés — contre un gain de vitesse qui se compte en dizaines ou centaines de fois. Pour l'immense majorité des usages, l'affaire est excellente.

Ce compromis se règle. Toutes les bases vectorielles sérieuses exposent des paramètres qui permettent de déplacer le curseur entre vitesse et précision. On peut privilégier un rappel quasi parfait au prix d'une recherche un peu plus lente, ou au contraire favoriser la vélocité en tolérant un rappel légèrement inférieur. Ce réglage fin est l'un des leviers essentiels du déploiement d'une base vectorielle : il n'existe pas de réglage universel, seulement le réglage adapté à votre exigence de qualité et à votre budget de latence.

HNSW : le graphe qui a fait référence

Parmi les algorithmes de recherche approximative, l'un s'est imposé comme la référence de fait dans la plupart des bases vectorielles modernes : HNSW, pour Hierarchical Navigable Small World — « petit monde navigable hiérarchique ». Il mérite qu'on s'y attarde, car comprendre son fonctionnement éclaire beaucoup des choix techniques que l'on rencontre ensuite.

L'origine : un article de 2016

HNSW a été introduit par Yury Malkov et Dmitry Yashunin dans un article déposé sur arXiv en mars 2016, sous le titre « Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs ». Le travail a ensuite été publié dans la prestigieuse revue IEEE Transactions on Pattern Analysis and Machine Intelligence en avril 2020 (volume 42, numéro 4, pages 824 à 836). C'est un exemple typique d'une contribution de recherche fondamentale qui, quelques années après sa publication, se retrouve au cœur d'une industrie entière.

Le principe des couches

L'idée de HNSW s'inspire de la théorie des « petits mondes », cette observation célèbre selon laquelle, dans un réseau social, on peut relier deux personnes quelconques par une courte chaîne de connaissances. HNSW construit un graphe où chaque vecteur est un nœud, relié à ses voisins proches par des arêtes. Chercher le plus proche voisin revient alors à naviguer de proche en proche dans ce graphe, en se rapprochant à chaque pas de la cible.

Le raffinement décisif — le « H » de hiérarchique — consiste à empiler plusieurs couches de ce graphe. La couche supérieure ne contient qu'une poignée de nœuds, reliés par de longues arêtes qui couvrent de grandes distances. Les couches inférieures sont de plus en plus denses, avec des arêtes de plus en plus courtes. La recherche commence tout en haut, saute rapidement vers la bonne région de l'espace grâce aux longues arêtes, puis descend couche par couche pour affiner, jusqu'à la couche du bas où se joue la précision fine.

On peut filer une image : c'est le principe d'un atlas routier. Pour aller d'une ville à une autre, on commence par la carte nationale — les autoroutes, peu nombreuses mais couvrant de grandes distances — puis on passe à la carte régionale, enfin au plan de quartier pour trouver la rue exacte. HNSW fait exactement cela dans un espace à mille dimensions. Chaque niveau de zoom élimine une vaste portion de l'espace, ce qui explique la performance.

Figure 2. HNSW empile plusieurs couches d'un même graphe. La recherche entre par le haut (longues arêtes), saute vite vers la bonne région, puis descend de couche en couche jusqu'au voisin le plus proche, au niveau le plus fin.

Pourquoi c'est rapide

Ce parcours hiérarchique confère à HNSW une complexité de recherche remarquablement basse : elle croît de façon logarithmique avec le nombre de vecteurs. Autrement dit, multiplier par mille la taille de la base n'augmente que très modestement le temps de recherche. C'est cette propriété qui rend possible la recherche en quelques millisecondes sur des collections de plusieurs millions, voire milliards de vecteurs, sans parcourir chaque élément un à un.

HNSW n'est pas exempt de contreparties, et il serait malhonnête de les taire. La construction du graphe est coûteuse en temps et en mémoire : l'index occupe davantage de place que d'autres approches, et l'insertion de nouveaux vecteurs demande du travail. Deux paramètres principaux gouvernent le compromis. Le premier contrôle le nombre de connexions par nœud : plus il est élevé, meilleur est le rappel, mais plus l'index est gros et lent à construire. Le second règle l'effort de construction : une valeur plus haute améliore la qualité de l'index au prix du temps de fabrication. Bien régler ces deux boutons, c'est trouver le point d'équilibre entre qualité de recherche, empreinte mémoire et vitesse d'indexation.

Les autres familles d'algorithmes

HNSW n'est pas seul. Deux autres grandes familles méritent d'être connues, car on les rencontre fréquemment :

• IVF (Inverted File) partitionne l'espace en régions, un peu comme on découperait une carte en quartiers. Lors d'une recherche, on n'explore que les quelques régions les plus proches de la requête, en ignorant le reste. C'est rapide et économe en mémoire, au prix d'une phase préalable d'entraînement pour définir les régions.
• PQ (Product Quantization) compresse les vecteurs en les découpant en sous-parties, chacune remplacée par un code court. La mémoire nécessaire chute drastiquement, ce qui permet de tenir des milliards de vecteurs sur un matériel raisonnable, moyennant une petite perte de précision. On combine souvent IVF et PQ pour cumuler leurs avantages.

Le choix entre ces familles dépend du profil de l'application : volume de données, contrainte mémoire, fréquence des mises à jour, exigence de rappel. HNSW excelle quand la qualité de recherche prime et que la mémoire n'est pas le premier facteur limitant ; les approches à base de quantification s'imposent quand il faut tenir des volumes gigantesques sur un budget matériel contraint. Là encore, il n'y a pas de gagnant absolu, seulement des outils adaptés à des contextes.

Anatomie d'une requête, de bout en bout

Pour ancrer tout cela dans le concret, suivons le trajet complet d'une donnée, de son ingestion jusqu'à la réponse. C'est le meilleur moyen de voir comment les briques s'emboîtent.

La première phase est l'indexation. On part d'une collection de documents — des articles, des fiches produits, des pages d'aide. Chaque document est découpé en fragments de taille raisonnable, souvent quelques centaines de mots, car un embedding représente d'autant mieux un texte que celui-ci est cohérent et pas trop long. Chaque fragment passe ensuite dans le modèle d'embedding, qui le transforme en vecteur. Ces vecteurs sont stockés dans la base, accompagnés de métadonnées — l'identifiant du document d'origine, sa date, sa catégorie — et l'index de recherche (HNSW, par exemple) est construit au fur et à mesure.

La seconde phase est la requête. Un utilisateur pose une question. Cette question est convertie en vecteur par le même modèle d'embedding que celui utilisé à l'indexation — c'est une condition impérative, faute de quoi les vecteurs ne seraient pas comparables. La base recherche alors les vecteurs les plus proches de ce vecteur de requête, grâce à l'index approximatif, et remonte les fragments correspondants, classés par similarité décroissante. En quelques millisecondes, on obtient les passages les plus pertinents, même si aucun mot exact de la question n'y figure.

Le filtrage par métadonnées

Un besoin très courant en pratique mérite d'être souligné : combiner la recherche sémantique avec des filtres classiques. « Trouve-moi les documents sémantiquement proches de cette question, mais uniquement ceux publiés après 2024 et rédigés en français. » Ce croisement entre similarité vectorielle et conditions sur les métadonnées est un point technique délicat, longtemps mal géré par certains systèmes.

L'illustration la plus parlante vient de l'écosystème PostgreSQL. La version 0.8.0 de l'extension pgvector, publiée en octobre 2024, a précisément introduit les scans d'index itératifs pour résoudre un problème récurrent : lorsqu'on appliquait un filtre après la recherche vectorielle, on obtenait souvent moins de résultats que demandé, car le filtre éliminait une partie des voisins retournés par l'index. Le scan itératif permet à l'index de continuer à chercher jusqu'à satisfaire la condition, sans sacrifier la qualité. C'est un bon exemple de la maturation continue de ces outils : les problèmes concrets rencontrés en production nourrissent des améliorations ciblées, version après version.

Le paysage des solutions en 2025

Passons du concept aux outils. Le marché des bases vectorielles s'est étoffé rapidement, au point qu'un débutant peut s'y perdre. On peut néanmoins le structurer en quelques grandes familles, ce qui simplifie considérablement le choix.

Les bases vectorielles dédiées

Ce sont des systèmes conçus dès le départ pour la recherche vectorielle, et rien d'autre. Ils offrent en général les meilleures performances brutes et les fonctionnalités les plus avancées. Parmi les noms les plus établis :

• Pinecone : solution entièrement gérée dans le cloud, réputée pour sa simplicité de mise en œuvre. On n'administre aucune infrastructure ; en contrepartie, le coût peut grimper avec le volume.
• Milvus : projet open source pensé pour l'échelle du milliard de vecteurs, avec de multiples types d'index et un support multimodal. Puissant, mais plus exigeant à exploiter.
• Qdrant : écrit en Rust, apprécié pour sa faible latence et son offre open source généreuse.
• Weaviate : réputé pour sa recherche hybride, qui combine similarité vectorielle et correspondance de mots-clés, et pour ses modules d'embedding intégrés.
• Chroma : particulièrement adapté au développement local et au prototypage, léger à mettre en place.

Les extensions de bases existantes

L'autre grande voie consiste à ajouter la capacité vectorielle à une base de données que l'on possède déjà. C'est l'approche de pgvector, l'extension open source qui apporte le stockage et la recherche de vecteurs à PostgreSQL. Elle propose deux types d'index — HNSW pour la meilleure performance de recherche, et IVFFlat pour une construction plus rapide et une empreinte mémoire moindre — et supporte les métriques euclidienne, cosinus et produit scalaire.

L'intérêt de cette approche est considérable pour de nombreuses organisations. Plutôt que d'ajouter un nouveau système à administrer, sauvegarder et sécuriser, on tire parti d'une base éprouvée que les équipes maîtrisent déjà. On peut, dans la même requête SQL, croiser une recherche vectorielle avec des jointures relationnelles, des filtres transactionnels et toute la richesse de PostgreSQL. Pour beaucoup de projets — jusqu'à des dizaines de millions de vecteurs selon le matériel — cette solution est amplement suffisante et évite une complexité inutile. C'est souvent le choix le plus sage pour démarrer.

La question à se poser n'est pas « quelle est la meilleure base vectorielle ? » mais « quelle est la solution la plus simple qui répond à mon besoin réel ? » — et pour bien des projets, une extension sur une base existante suffit largement.

Comment choisir sans se tromper

Devant cette abondance, quelques critères pragmatiques permettent de trancher :

• Le volume : quelques centaines de milliers de vecteurs ne posent aucun problème à n'importe quelle solution ; le milliard de vecteurs restreint le choix aux systèmes taillés pour l'échelle.
• Le mode d'exploitation : préfère-t-on une solution gérée sans administration, ou l'auto-hébergement pour maîtriser les coûts et les données ?
• L'écosystème existant : si l'on utilise déjà PostgreSQL, une extension évite d'introduire un nouveau composant.
• Les fonctionnalités : recherche hybride, filtrage avancé, multimodalité, multi-tenant — tous les systèmes ne se valent pas sur ces points.
• Le coût total : au-delà du prix affiché, il faut compter le temps d'exploitation, la mémoire nécessaire et la scalabilité future.

Un conseil traverse toutes les recommandations sérieuses : commencer simple. Il est souvent judicieux de démarrer avec une solution facile à opérer, quitte à migrer vers un système plus spécialisé lorsque le volume ou les contraintes de coût l'imposent réellement. Optimiser prématurément pour une échelle qu'on n'atteindra peut-être jamais est une source classique de complexité gaspillée.

Le rôle central dans les applications d'IA

Si les bases vectorielles ont connu un tel essor, c'est parce qu'elles se sont retrouvées au cœur de l'une des architectures les plus utiles de l'IA moderne : la génération augmentée par récupération, ou RAG. Le principe consiste à relier un modèle de langage à une base de connaissances externe, afin qu'il réponde à partir de documents à jour et vérifiables plutôt que de sa seule mémoire d'entraînement.

Le mécanisme s'appuie directement sur tout ce que nous avons décrit. Comme l'explique IBM, dans un flux RAG, « le texte est extrait des documents et découpé en fragments ; un modèle d'embedding transforme ces fragments en vecteurs conservés dans une base vectorielle ». Lors d'une question, la requête est convertie en vecteur, la base remonte les fragments les plus pertinents, et ces fragments sont fournis au modèle de langage comme contexte pour formuler sa réponse. La base vectorielle joue ici le rôle de la mémoire documentaire du système : elle sait retrouver, en quelques millisecondes, les quelques passages utiles parmi des millions.

Figure 3. Le flux RAG en deux temps. En bleu, l'indexation des documents sources ; en rouge, la requête utilisateur. La base vectorielle est l'unique pont entre les connaissances et le modèle de langage.

Ce rôle explique pourquoi la qualité d'un système RAG dépend si étroitement de sa base vectorielle et de son modèle d'embedding. Un modèle de langage brillant, alimenté par une récupération médiocre, produira des réponses médiocres : il ne peut raisonner que sur ce qu'on lui donne. À l'inverse, une récupération précise transforme un modèle même modeste en assistant fiable sur un domaine précis. C'est une leçon importante et parfois contre-intuitive : dans beaucoup d'applications, l'effort investi dans la qualité de la recherche vectorielle rapporte davantage que la course au modèle de langage le plus puissant.

Au-delà du RAG

La recherche vectorielle ne se limite pas au RAG. Elle irrigue quantité d'usages éprouvés :

• La recherche sémantique dans des moteurs internes, où l'on cherche par le sens et non par les mots exacts.
• Les systèmes de recommandation, qui suggèrent des articles ou des contenus proches de ceux appréciés par un utilisateur.
• La détection de doublons et de contenus similaires, en repérant les vecteurs très proches.
• La recherche d'images ou de sons par similarité, y compris à partir d'une requête d'une autre modalité.
• La classification et le regroupement automatiques, en exploitant la structure de l'espace vectoriel.

Cette polyvalence explique pourquoi la base vectorielle est devenue une brique d'infrastructure aussi répandue. Elle ne résout pas un problème unique, mais toute une catégorie de problèmes qui partagent une même nature : retrouver, dans un vaste ensemble, ce qui ressemble le plus à une référence donnée. Dès qu'un besoin prend cette forme, la recherche vectorielle est un candidat sérieux.

Les limites à garder en tête

Aucun outil n'est une solution universelle, et l'honnêteté commande d'en signaler les frontières. Une base vectorielle brille sur la recherche par similarité, mais elle n'est pas la réponse à tout, et il est utile de savoir quand elle n'est pas le bon choix.

D'abord, elle ne remplace pas une base de données classique. Pour des requêtes exactes, des agrégations, des transactions, des relations complexes entre entités, les bases relationnelles restent supérieures. La recherche vectorielle est un complément, pas un substitut. Beaucoup d'architectures réussies combinent les deux : une base relationnelle pour les données structurées, une capacité vectorielle pour la recherche sémantique — parfois réunies dans un même système, comme le permet pgvector.

Ensuite, la qualité des résultats est plafonnée par celle des embeddings. Si le modèle d'embedding représente mal un domaine — un jargon technique très spécialisé, une langue peu couverte — la recherche vectorielle héritera de ces faiblesses. Choisir ou adapter un bon modèle d'embedding pour son domaine est souvent l'investissement le plus rentable, avant même de peaufiner la base elle-même.

Enfin, la recherche approximative introduit, par construction, une petite marge d'erreur. Dans l'immense majorité des cas, elle est imperceptible et sans conséquence. Mais pour des applications où le rappel doit être quasi parfait — certains contextes réglementaires ou critiques — il faut en avoir conscience et régler les paramètres en connaissance de cause, quitte à sacrifier un peu de vitesse. C'est un arbitrage à assumer explicitement, pas à ignorer.

Un moteur discret, mais structurant

Que retenir de ce panorama ? D'abord, que les bases de données vectorielles ne sont ni une mode ni une boîte noire. Elles répondent à un besoin précis et bien identifié : chercher, à très grande échelle et en quelques millisecondes, les données les plus proches par le sens d'une référence donnée. Ce besoin est né de la généralisation des embeddings, ces représentations numériques qui transforment le sens en géométrie.

Ensuite, que leur efficacité repose sur un compromis lucide. En renonçant à la certitude du plus proche voisin exact au profit d'une recherche approximative, et grâce à des algorithmes ingénieux comme HNSW, ces systèmes atteignent des performances qui seraient impensables par la force brute. Ce compromis est réglable, et le maîtriser fait partie du métier de qui déploie ces outils.

Enfin, que le bon réflexe n'est pas de choisir la solution la plus impressionnante sur le papier, mais la plus adaptée à son besoin réel. Pour beaucoup de projets, une extension sur une base existante suffit ; pour d'autres, un système dédié taillé pour l'échelle s'impose. Entre les deux, c'est le volume, les contraintes d'exploitation et l'écosystème en place qui doivent guider la décision, bien plus que la réputation d'un nom.

Les bases vectorielles resteront sans doute longtemps dans l'ombre des modèles de langage qui captent l'attention. C'est le sort des bonnes infrastructures : on ne les remarque que lorsqu'elles manquent. Mais pour quiconque construit des applications d'intelligence artificielle qui manipulent du sens — recherche, recommandation, assistants documentaires —, comprendre ce moteur discret, c'est comprendre l'un des rouages essentiels de l'IA d'aujourd'hui. Et c'est se donner les moyens de bâtir des systèmes qui trouvent, vraiment, ce que l'on cherche.

Sources

Cet article s'appuie sur des sources techniques publiques et vérifiables :

• IBM, « What Is a Vector Database? » — ibm.com/think/topics/vector-database (définition, embeddings, fonctionnement).
• IBM, « Vector Databases for RAG » — ibm.com/think/topics/rag-vector-database (rôle dans la génération augmentée par récupération).
• Y. Malkov, D. Yashunin, « Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs » — arXiv 1603.09320 (algorithme HNSW, publié dans IEEE TPAMI, vol. 42(4), avril 2020).
• pgvector, dépôt officiel — github.com/pgvector/pgvector (index HNSW et IVFFlat, métriques de distance).
• PostgreSQL, « pgvector 0.8.0 Released! » — postgresql.org (scans d'index itératifs, filtrage, octobre 2024).
• Pinecone, « Vector Similarity Explained » — pinecone.io/learn/vector-similarity (métriques de similarité, choix cohérent avec le modèle).
• Zilliz / Milvus, « Similarity Metrics for Vector Search » — zilliz.com/blog/similarity-metrics-for-vector-search (distances euclidienne, cosinus, produit scalaire).