En clair
Une base de données classique retrouve ce qui correspond exactement : la facture numéro 2041, les clients dont le nom commence par D. Elle est démunie devant une question comme « trouvez-moi les documents qui parlent de retards de livraison », si les textes disent « colis jamais arrivé » ou « expédition en souffrance ». Une base vectorielle répond à ce besoin : elle cherche par ressemblance de sens.
Pour y parvenir, chaque texte est d’abord transformé en une liste de nombres, son vecteur, par un modèle spécialisé. Deux textes de sens voisin reçoivent des vecteurs voisins. Imaginez une bibliothèque où les livres ne sont pas rangés par ordre alphabétique mais par sujet, si finement que deux ouvrages proches par leur contenu se touchent sur l’étagère. Chercher revient à se rendre au bon endroit et à prendre les livres alentour.
Le principe vaut aussi pour des images, des sons ou des fiches produits. Il suffit de disposer d’un modèle capable de les traduire en vecteurs. La base ne juge pas le contenu : elle mesure des distances entre des listes de nombres. Si la traduction en vecteurs est de mauvaise qualité, le rangement l’est aussi, et la recherche ramène des résultats voisins mais hors sujet.
Un exemple
Un distributeur de pièces détachées reçoit des demandes rédigées de mille façons : « le joint qui fuit sous la cuve », « pièce caoutchouc pompe modèle 300 ». Son catalogue de 80 000 références est converti en vecteurs et rangé dans une base vectorielle. La demande du client est convertie à son tour, et la base renvoie les vingt références les plus proches par le sens.
Un filtre écarte ensuite les pièces indisponibles ou incompatibles avec le modèle de machine indiqué. Le vendeur obtient une courte liste pertinente, sans avoir à deviner le terme exact du catalogue.
Comment ça marche
Une base vectorielle stocke des embeddings, vecteurs denses de quelques centaines à quelques milliers de dimensions, accompagnés de métadonnées. La proximité se mesure par similarité cosinus, produit scalaire ou distance euclidienne. Comparer la requête à tous les vecteurs donne un résultat exact, mais ce calcul devient trop lent quand la collection grossit.
On recourt donc à la recherche approximative des plus proches voisins, qui accepte de manquer parfois un résultat en échange d’une vitesse bien supérieure. L’index le plus répandu, HNSW, proposé en 2016, organise les vecteurs en un graphe à plusieurs niveaux que l’on parcourt du plus grossier au plus fin, avec un coût qui croît de façon logarithmique avec la taille de la collection 1. D’autres index regroupent les vecteurs en paquets (IVF) ou les compressent pour économiser la mémoire. La bibliothèque Faiss rassemble ces méthodes et décrit les compromis entre vitesse, mémoire et précision 2.
L’offre se répartit en deux familles : des systèmes spécialisés, et des extensions de bases existantes, comme pgvector pour PostgreSQL, qui gère les index HNSW et IVFFlat 3. Les systèmes de production combinent souvent recherche vectorielle et recherche par mots-clés, puis appliquent des filtres sur les métadonnées : date, service, droits d’accès.
Ce que ça change pour une entreprise
La base vectorielle est la mémoire de recherche de la plupart des systèmes de RAG, des moteurs de recherche sémantique et des outils de recommandation. Elle permet de retrouver une information sans connaître les mots exacts du document, ce qui change l’usage d’une base documentaire, d’un catalogue ou d’un historique de tickets.
Elle a un coût et des contraintes. Il faut calculer les vecteurs, les stocker en mémoire, et tout recalculer si l’on change de modèle d’embedding, car les vecteurs de deux modèles ne sont pas comparables. La recherche par le sens est moins sûre sur les références exactes, les codes produits ou les noms propres, d’où l’intérêt de la combiner avec les mots-clés. Pour quelques milliers de documents, une extension de la base déjà en place suffit souvent : un système spécialisé se justifie surtout à grande échelle.
Idées reçues
- « Une base vectorielle comprend les documents. »
Elle ne comprend rien : elle compare des listes de nombres. Toute la finesse vient du modèle d’embedding qui a produit ces nombres.
- « Le résultat le plus proche est le bon. »
Proche ne veut pas dire pertinent. Un passage peut ressembler à la question sans y répondre, et la recherche approximative peut manquer le meilleur résultat.
- « Il faut forcément un produit spécialisé. »
Beaucoup de bases de données généralistes proposent aujourd’hui la recherche vectorielle. Le choix dépend surtout du volume et des besoins de filtrage.