Accueil › Glossaire › Vector Database

Vector Database : le moteur de recherche semantique de l’IA

Pourquoi une base de donnees vectorielle ?

Les bases de donnees classiques (PostgreSQL, MySQL, MongoDB) sont conques pour rechercher des correspondances exactes : « trouve tous les utilisateurs dont le nom est Martin ». Mais quand vous travaillez avec des embeddings, vous ne cherchez pas une correspondance exacte. Vous cherchez les vecteurs les plus proches d’un vecteur de requete dans un espace a 1 536 dimensions.

C’est la recherche de plus proches voisins (Approximate Nearest Neighbor, ANN). Une base de donnees classique devrait comparer la requete avec chaque vecteur stocke, un par un. Avec un million de vecteurs a 1 536 dimensions, cette comparaison brute prendrait des secondes. Une vector database optimisee le fait en quelques millisecondes grace a des index specialises.

Les vector databases sont le composant central de tout pipeline RAG. Sans elles, la recherche semantique a grande echelle serait impraticable.

Comment fonctionne une vector database ?

L’indexation

Quand vous inserez un vecteur, la base de donnees ne le stocke pas simplement dans une liste. Elle l’organise dans une structure d’index qui permet des recherches rapides. Les deux algorithmes d’indexation dominants sont :

HNSW (Hierarchical Navigable Small World). C’est l’algorithme le plus utilise en 2026. Il construit un graphe multicouche ou chaque vecteur est connecte a ses voisins les plus proches. La recherche navigue de couche en couche, en se rapprochant progressivement du resultat. HNSW offre un excellent compromis vitesse/precision et fonctionne bien meme a tres grande echelle.

IVF (Inverted File Index). L’espace vectoriel est divise en clusters. Lors d’une recherche, seuls les clusters les plus proches de la requete sont explores, au lieu de l’ensemble des vecteurs. Plus rapide que HNSW pour les insertions massives, mais moins precis.

La recherche

Une requete de recherche envoie un vecteur (l’embedding de votre question) et demande les K voisins les plus proches. La base retourne les K vecteurs les plus similaires, generalement avec leur score de similarite (cosinus, produit scalaire ou distance euclidienne) et les metadonnees associees.

Comparatif des principales vector databases

Pinecone

Pinecone est le choix « zero friction ». Entierement manage, il ne necessite aucune configuration d’infrastructure. Vous envoyez vos vecteurs via l’API, Pinecone gere l’indexation, la replication et la mise a l’echelle. Son offre gratuite (100 000 vecteurs) suffit pour les projets pilotes. Les plans payants demarrent a 70 $/mois. Inconvenient : pas d’auto-hebergement possible, donc pas adapte si vous avez des contraintes de souverainete des donnees.

Qdrant

Qdrant est ecrit en Rust, ce qui lui confere des performances exceptionnelles avec une empreinte memoire reduite. Il supporte le filtrage avance sur les metadonnees, la recherche hybride (dense + sparse), et les embeddings multi-vecteurs. Son API est elegante et bien documentee. Disponible en open source pour l’auto-hebergement ou en mode cloud manage via Qdrant Cloud.

Weaviate

Weaviate se distingue par sa recherche hybride native (vectorielle + BM25) et ses modules d’integration avec les modeles d’embedding. Il supporte nativement la generation augmentee : vous pouvez lancer une requete RAG directement depuis Weaviate, qui se charge de la recherche et de l’appel au LLM.

ChromaDB

ChromaDB est la solution la plus simple pour demarrer. Pas de serveur a installer : ChromaDB tourne en memoire dans votre script Python. Ideal pour le prototypage et les projets de petite taille (moins de 100 000 documents). Pour la production a grande echelle, les alternatives cloud sont plus adaptees.

pgvector

Si votre application utilise deja PostgreSQL, pgvector ajoute la recherche vectorielle sans introduire de nouvelle base de donnees. C’est la solution la plus pragmatique pour les equipes qui veulent eviter la complexite d’une infrastructure supplementaire. Les performances sont inferieures aux solutions specialisees, mais suffisantes pour des volumes inferieurs a 1 million de vecteurs.

Implementation pratique

# Exemple avec Qdrant (Python)
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
from openai import OpenAI

openai = OpenAI()
qdrant = QdrantClient(":memory:")  # En memoire pour le test

# Creer une collection
qdrant.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE)
)

# Indexer des documents
documents = [
    "L'IA generative transforme le marketing digital",
    "Les bases vectorielles sont essentielles pour le RAG",
    "Python est le langage le plus utilise en data science"
]

for i, doc in enumerate(documents):
    embedding = openai.embeddings.create(
        model="text-embedding-3-small", input=doc
    ).data[0].embedding
    
    qdrant.upsert(
        collection_name="documents",
        points=[PointStruct(id=i, vector=embedding, payload={"text": doc})]
    )

# Rechercher
query = "Comment utiliser l'IA en marketing ?"
query_vec = openai.embeddings.create(
    model="text-embedding-3-small", input=query
).data[0].embedding

results = qdrant.search(
    collection_name="documents",
    query_vector=query_vec,
    limit=3
)
for r in results:
    print(f"Score: {r.score:.3f} | {r.payload['text']}")

Bonnes pratiques

Ajoutez des metadonnees a vos vecteurs. Stockez le texte original, la source, la date, la categorie et tout attribut utile en tant que metadonnees. Cela permet de filtrer les resultats de recherche (par date, par source, par type de document) en plus de la similarite semantique.

Utilisez le filtrage pre-recherche. Plutot que de rechercher parmi tous les vecteurs puis filtrer, appliquez les filtres de metadonnees avant la recherche vectorielle. C’est beaucoup plus performant.

Planifiez la mise a jour. Les documents changent. Definissez une strategie de mise a jour : re-indexation complete periodique, ou mise a jour incrementale avec upsert. Supprimez les vecteurs obsoletes pour maintenir la qualite.

Surveillez les performances. Mesurez la latence de recherche (p50, p99), le recall (proportion de resultats pertinents retrouves), et l’utilisation memoire. Les vector databases gardent generalement l’index en RAM pour des performances optimales.

FAQ