Bases de données vectorielles : révolution de la recherche

Introduction

Les bases de données traditionnelles ont longtemps été le pilier des systèmes d'information, permettant de répondre à des requêtes précises telles que l'existence d'un enregistrement spécifique. Cependant, les bases de données vectorielles introduisent une nouvelle dimension en se concentrant sur la recherche de similarité. Ce changement est crucial dans un monde où une grande partie des données — qu'il s'agisse de documents, d'images, de comportements utilisateurs ou de fichiers audio — ne peut être efficacement recherchée par simple correspondance exacte. Les modèles d'embedding jouent ici un rôle clé, transformant les données brutes en vecteurs, où la proximité géométrique traduit une similarité sémantique.

Le défi majeur réside dans l'échelle. Comparer un vecteur de requête à chaque vecteur stocké implique des milliards d'opérations en virgule flottante, rendant la recherche en temps réel impraticable. Les bases de données vectorielles surmontent cet obstacle grâce à des algorithmes d'approximation des plus proches voisins, qui réduisent considérablement le nombre de calculs nécessaires tout en fournissant des résultats presque identiques à une recherche exhaustive, mais à un coût bien moindre.

Cet article se propose d'explorer ce fonctionnement en trois niveaux : le problème fondamental de la similarité et le rôle des vecteurs, la manière dont les systèmes de production stockent et interrogent les embeddings avec des techniques de filtrage et de recherche hybride, et enfin, les algorithmes d'indexation et les choix architecturaux qui permettent de gérer ces systèmes à grande échelle.

Niveau 1 : Comprendre le problème de similarité

Les bases de données traditionnelles sont conçues pour manipuler des données structurées, organisées en lignes et colonnes, et pour les récupérer à l'aide de recherches exactes ou de requêtes de plage. SQL excelle dans ce domaine. Cependant, une grande partie des données du monde réel, telles que les textes, les images, l'audio et les journaux de comportement des utilisateurs, échappe à cette structuration rigide. Pour ces types de données, la recherche par correspondance exacte est inadaptée.

La solution réside dans la représentation de ces données sous forme de vecteurs : des tableaux de longueur fixe composés de nombres en virgule flottante. Des modèles d'embedding, comme le text-embedding-3-small d'OpenAI pour les textes ou des modèles de vision pour les images, transforment le contenu brut en vecteurs qui capturent leur signification sémantique. Ainsi, des contenus similaires génèrent des vecteurs proches. Par exemple, les termes "chien" et "chiot" se retrouvent proches dans l'espace vectoriel, tout comme une photo et un dessin d'un chat.

Une base de données vectorielle stocke ces embeddings et permet des recherches basées sur la similarité, telles que "trouvez-moi les 10 vecteurs les plus proches de ce vecteur de requête". Ce processus est connu sous le nom de recherche des plus proches voisins.

Niveau 2 : Stockage et interrogation des vecteurs

Embeddings

Avant qu'une base de données vectorielle puisse fonctionner, le contenu doit être converti en vecteurs. Cette conversion est réalisée par des modèles d'embedding, qui sont des réseaux neuronaux mappant l'entrée dans un espace vectoriel dense, généralement avec 256 à 4096 dimensions selon le modèle utilisé. Les valeurs spécifiques dans le vecteur n'ont pas de signification directe ; ce qui importe, c'est la géométrie : des vecteurs proches indiquent un contenu similaire.

Pour obtenir un vecteur, on peut appeler une API d'embedding ou exécuter un modèle localement, puis stocker le tableau de flottants obtenu avec les métadonnées associées au document.

Métriques de distance

La similarité entre vecteurs est mesurée par leur distance géométrique. Trois métriques sont couramment utilisées :

• Similarité cosinus : elle mesure l'angle entre deux vecteurs, en ignorant leur magnitude. Cette métrique est souvent utilisée pour les embeddings textuels, où la direction est plus significative que la longueur.

• Distance euclidienne : elle mesure la distance en ligne droite dans l'espace vectoriel, utile lorsque la magnitude a une importance.

• Produit scalaire : rapide et efficace lorsque les vecteurs sont normalisés. De nombreux modèles d'embedding sont conçus pour l'utiliser.

Le choix de la métrique doit être aligné avec la manière dont le modèle d'embedding a été entraîné. Une mauvaise sélection peut dégrader la qualité des résultats.

Le problème des plus proches voisins

Trouver les plus proches voisins exacts est simple pour de petits ensembles de données : il suffit de calculer la distance entre la requête et chaque vecteur, de trier les résultats et de retourner les K meilleurs. Cette méthode, appelée recherche brute ou à plat, est 100 % précise mais évolue linéairement avec la taille de l'ensemble de données. Avec 10 millions de vecteurs de 1536 dimensions chacun, une recherche à plat devient trop lente pour des requêtes en temps réel.

La solution réside dans les algorithmes d'approximation des plus proches voisins (ANN), qui échangent une petite quantité de précision pour des gains significatifs en vitesse. Les bases de données vectorielles de production utilisent ces algorithmes ANN en arrière-plan. Les algorithmes spécifiques, leurs paramètres et leurs compromis seront examinés au niveau suivant.

Filtrage de métadonnées

La recherche vectorielle pure retourne les éléments les plus sémantiquement similaires à l'échelle mondiale. En pratique, on souhaite souvent des résultats plus spécifiques, comme "trouvez les documents les plus similaires appartenant à cet utilisateur et créés après cette date". C'est ce qu'on appelle la recherche hybride : elle combine la similarité vectorielle avec des filtres d'attributs.

Les implémentations varient. Le pré-filtrage applique d'abord le filtre d'attribut, puis exécute l'ANN sur le sous-ensemble restant. Le post-filtrage exécute d'abord l'ANN, puis applique le filtre. Le pré-filtrage est plus précis mais plus coûteux pour les requêtes sélectives. La plupart des bases de données de production utilisent une variante de pré-filtrage avec un index intelligent pour maintenir la rapidité.

Recherche hybride : dense + sparse

La recherche vectorielle dense pure peut manquer de précision au niveau des mots-clés. Une requête pour "date de sortie de GPT-5" pourrait dériver sémantiquement vers des sujets d'IA générale plutôt que vers le document spécifique contenant l'expression exacte. La recherche hybride combine l'ANN dense avec la récupération sparse (BM25 ou TF-IDF) pour obtenir à la fois une compréhension sémantique et une précision au niveau des mots-clés.

L'approche standard consiste à exécuter la recherche dense et sparse en parallèle, puis à combiner les scores en utilisant la fusion de rang réciproque (RRF) — un algorithme de fusion basé sur le rang qui ne nécessite pas de normalisation des scores. La plupart des systèmes de production prennent désormais en charge la recherche hybride nativement.

Niveau 3 : Indexation pour l'échelle

Algorithmes d'approximation des plus proches voisins

Les trois algorithmes d'approximation des plus proches voisins les plus importants occupent chacun un point différent sur la surface de compromis entre vitesse, utilisation de la mémoire et rappel.

• Hierarchical Navigable Small World (HNSW) : cet algorithme construit un graphe multi-couche où chaque vecteur est un nœud, avec des arêtes reliant des voisins similaires. Les couches supérieures sont rares et permettent une traversée rapide à longue distance, tandis que les couches inférieures sont plus denses pour une recherche locale précise. Lors d'une requête, l'algorithme navigue à travers ce graphe vers les voisins les plus proches. HNSW est rapide, gourmand en mémoire et offre un excellent rappel, ce qui en fait le choix par défaut dans de nombreux systèmes modernes.

• Inverted File Index (IVF) : il regroupe les vecteurs en clusters en utilisant k-means, construit un index inversé qui mappe chaque cluster à ses membres, puis ne recherche que les clusters les plus proches lors de la requête. IVF utilise moins de mémoire que HNSW mais est souvent un peu plus lent et nécessite une étape d'entraînement pour construire les clusters.

• Product Quantization (PQ) : cet algorithme compresse les vecteurs en les divisant en subvecteurs et en quantifiant chacun d'eux à un codebook. Cela peut réduire l'utilisation de la mémoire de 4 à 32 fois, permettant de gérer des ensembles de données à l'échelle des milliards. Il est souvent utilisé en combinaison avec IVF sous la forme IVF-PQ dans des systèmes comme Faiss.

Configuration de l'index

HNSW a deux paramètres principaux : ef_construction et M :

• ef_construction : ce paramètre contrôle combien de voisins sont considérés lors de la construction de l'index. Des valeurs plus élevées améliorent généralement le rappel mais prennent plus de temps à construire.

• M : il détermine le nombre de liens bidirectionnels par nœud. Un M plus élevé améliore généralement le rappel mais augmente l'utilisation de la mémoire.

Ces paramètres doivent être ajustés en fonction du rappel souhaité, de la latence et du budget mémoire disponible.

Lors de la requête, ef_search contrôle combien de candidats sont explorés. L'augmentation de ce paramètre améliore le rappel au détriment de la latence. C'est un paramètre d'exécution que l'on peut ajuster sans reconstruire l'index.

Pour IVF, nlist définit le nombre de clusters, et nprobe détermine combien de clusters rechercher lors de la requête. Plus de clusters peuvent améliorer la précision mais nécessitent également plus de mémoire. Un nprobe plus élevé améliore le rappel mais augmente la latence.

Rappel vs. Latence

L'ANN vit sur une surface de compromis. On peut toujours obtenir un meilleur rappel en recherchant plus d'index, mais cela a un coût en latence et en calcul. Il est essentiel d'évaluer l'ensemble de données spécifique et les modèles de requête. Un rappel@10 de 0.95 pourrait être excellent pour une application de recherche ; un système de recommandation pourrait avoir besoin de 0.99.

Échelle et sharding

Un seul index HNSW peut tenir en mémoire sur une machine jusqu'à environ 50 à 100 millions de vecteurs, selon la dimensionnalité et la RAM disponible. Au-delà, il est nécessaire de sharder : partitionner l'espace vectoriel entre les nœuds et répartir les requêtes entre les shards, puis fusionner les résultats. Cela introduit un surcoût de coordination et nécessite une sélection soigneuse de la clé de shard pour éviter les points chauds.

Backends de stockage

Les vecteurs sont souvent stockés en RAM pour une recherche ANN rapide. Les métadonnées sont généralement stockées séparément, souvent dans un magasin clé-valeur ou colonne. Certains systèmes prennent en charge des fichiers mappés en mémoire pour indexer des ensembles de données plus grands que la RAM, débordant sur disque lorsque nécessaire. Cela échange une certaine latence pour l'échelle.

Les index ANN sur disque comme DiskANN (développé par Microsoft) sont conçus pour fonctionner à partir de SSD avec une RAM minimale. Ils atteignent un bon rappel et un bon débit pour des ensembles de données très volumineux où la mémoire est la contrainte principale.

Options de bases de données vectorielles

Les outils de recherche vectorielle se classent généralement en trois catégories.

Tout d'abord, vous pouvez choisir parmi des bases de données vectorielles spécialement conçues telles que :

• Pinecone : une solution entièrement gérée, sans serveur.