Vector Database

Une base de données vectorielle stocke des plongements, les vecteurs numériques produits par les modèles pour le texte, les images, l’audio ou la vidéo, avec un identifiant et des métadonnées pour chaque élément, puis répond en quelques millisecondes à la question « quels vecteurs stockés sont les plus proches de celui-ci ? » parmi des millions, voire des milliards d’éléments. Elle associe un index de recherche vectorielle aux fonctionnalités d’une base de données : insertions, mises à jour et suppressions, filtrage par métadonnées, persistance, contrôle d’accès et réplication entre machines. Les bases de données vectorielles assurent l’étape de récupération de la génération augmentée par récupération (RAG), de la recherche sémantique et des systèmes de recommandation.

Fonctionnement d’une base de données vectorielle#

Lors de l’écriture, un modèle de plongement, externe à la base de données ou intégré à celle-ci, convertit chaque élément en vecteur, que la base stocke avec un identifiant et une charge utile de métadonnées, par exemple le fichier source, la date, la caméra ou le client. Comparer une requête à chaque vecteur stocké est exact, mais lent à grande échelle ; la base construit donc un index de plus proches voisins approximatifs (ANN). HNSW relie chaque vecteur à ses voisins proches dans un graphe à plusieurs niveaux que la recherche parcourt de manière gloutonne ; les index à fichier inversé (IVF) regroupent les vecteurs avec le clustering k-means et ne parcourent que les groupes les plus proches de la requête ; et les méthodes de quantification vectorielle, comme la quantification produit, compressent chaque vecteur en quelques octets. Lors de la lecture, la requête est transformée en vecteur avec le même modèle, puis comparée à l’aide d’une mesure telle que la similarité cosinus, le produit scalaire ou la distance euclidienne ; la base renvoie les identifiants, scores et charges utiles des k premiers résultats, que de nombreux systèmes fusionnent avec les résultats par mots-clés dans une recherche hybride.

Cet exemple utilise Chroma, une base de données vectorielle open source qui s’exécute en mémoire dans un processus Python :

import chromadb

# Client en mémoire ; chromadb.PersistentClient(path="db") conserve les données sur le disque
client = chromadb.Client()
collection = client.create_collection("inspection_notes")

# Chroma transforme chaque document en vecteur à l’aide de son modèle de plongement par défaut et indexe les vecteurs
collection.add(
    ids=["n1", "n2", "n3"],
    documents=[
        "Hairline crack found near the weld on bracket B7",
        "Paint scratch on the left door panel",
        "Porosity in the weld seam of the frame rail",
    ],
    metadatas=[{"line": "A"}, {"line": "B"}, {"line": "B"}],
)

# Recherche des plus proches voisins limitée à une seule ligne de production
results = collection.query(query_texts=["welding defects"], n_results=1, where={"line": "B"})
print(results["ids"][0], results["documents"][0])

La requête renvoie la note n3 sur la porosité de soudure de la ligne B. Le filtre de métadonnées écarte la note sur la fissure de la ligne A, bien que son texte soit tout aussi proche de « défauts de soudage ».

Bases de données vectorielles et systèmes apparentés#

• Bibliothèques de recherche vectorielle comme FAISS : des index en processus, notamment HNSW, IVF et la quantification produit, sans serveur, stockage de métadonnées ni réplication. Plusieurs bases de données vectorielles s’appuient sur ces bibliothèques.
• Bases de données vectorielles spécialisées : Pinecone en tant que service géré, et Milvus, Qdrant, Weaviate et Chroma en tant que projets open source, conçus dès le départ autour des plongements.
• Extensions vectorielles comme pgvector : elles ajoutent à PostgreSQL des colonnes vectorielles avec des index HNSW et IVFFlat, afin que les plongements cohabitent avec les données relationnelles. Elasticsearch, OpenSearch, MongoDB Atlas et Redis proposent des champs vectoriels similaires à côté de leur recherche par mots-clés.
• Magasins de caractéristiques : ils fournissent les caractéristiques d’entrée des modèles, par clé d’entité, pour l’entraînement et l’inférence. Ils recherchent les enregistrements par identifiant, et non par similarité.
• Lacs de données : ils stockent des fichiers bruts, comme des images et des journaux, auxquels une base de données vectorielle fait référence par identifiant ou chemin d’accès.

Applications concrètes#

• Mémoire des agents d’IA : les pipelines RAG et les agents stockent des fragments de documents et des conversations passées afin qu’un grand modèle de langage puisse les retrouver à la demande.
• Recherche visuelle dans le commerce de détail : les fonctionnalités « Acheter des articles similaires » transforment en vecteurs les photos de chaque produit et renvoient les articles les plus proches de celui consulté par le client.
• Détection d’anomalies : un nouvel échantillon dont les voisins stockés les plus proches sont tous éloignés est signalé comme inhabituel, par exemple une transaction ou une mesure de capteur.

Les collections d’images ont besoin d’un modèle de vision pour produire les vecteurs. Ultralytics YOLO26 en fournit un avec model.embed(), qui exécute le modèle sur chaque image et renvoie un vecteur de caractéristiques agrégé depuis l’avant-dernière couche, prêt à être stocké avec le chemin de l’image et les métadonnées de capture pour détecter les quasi-doublons ou rechercher des images similaires, comme dans Rechercher des images similaires sur Ultralytics Platform.

Dimensionnement et réglage#

Les paramètres d’index établissent un compromis entre le rappel et la latence d’inférence : l’étendue de recherche de HNSW (ef_search) et le nombre de groupes sondés par IVF (nprobe) permettent tous deux de trouver davantage de vrais voisins, au prix de requêtes plus lentes. Les équipes les règlent donc en les comparant à une recherche exacte sur des requêtes d’échantillon. La mémoire détermine le coût du matériel. Un million de plongements float32 de 768 dimensions occupent 3,07 Go (1 000 000 x 768 x 4 octets) avant toute surcharge d’index ; la quantification scalaire int8 des vecteurs réduit cette taille à 768 Mo, et les plongements Matryoshka peuvent être tronqués à un plus petit nombre de dimensions pour réduire encore la taille.