Toutes les deux ou trois semaines, quelqu’un me demande quelle base vectorielle il devrait utiliser, et il veut un seul nom. Je n’en donne jamais un seul, car la reponse honnete depend de ce que vous exploitez deja, du nombre de vecteurs et de la charge operationnelle que vous etes pret a assumer. J’ai mis en production des systemes sur plusieurs d’entre elles, et voici comment je decide vraiment. Si les termes embeddings et plus proches voisins approximatifs vous sont nouveaux, commencez d’abord par mon explication sur les bases vectorielles et la recherche par similarite.
Commencez par la reponse ennuyeuse : pgvector
Si vous exploitez deja Postgres, essayez pgvector avant tout le reste. C’est une extension qui ajoute un type de colonne vecteur et les types d’index dont vous avez besoin, et elle vous laisse garder vos embeddings dans la meme base que le reste de vos donnees. Ce dernier point compte plus qu’on ne l’avoue. Filtrer une recherche vectorielle par identifiant d’utilisateur, par locataire ou par plage de dates est trivial quand les vecteurs vivent a cote de ces colonnes, car c’est juste une clause WHERE que le planificateur comprend deja.
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id bigserial PRIMARY KEY,
espace_id bigint NOT NULL,
corps text NOT NULL,
embedding vector(768)
);
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops);
SELECT id, corps
FROM documents
WHERE espace_id = 42
ORDER BY embedding <=> '[0.12, -0.03, ...]'
LIMIT 5;
Cet operateur de distance calcule la distance cosinus, et l’index HNSW la garde rapide. Pour la plupart des produits allant jusqu’a quelques millions de vecteurs, c’est tout ce qu’il vous faut, et vous evitez d’exploiter un second systeme. J’ai laisse avec plaisir des applications sur pgvector bien au-dela du point ou l’on supposait qu’elles l’auraient depasse.
Quand vous depassez Postgres
pgvector a des limites. Les constructions d’index deviennent lourdes quand le nombre de vecteurs grimpe vers les dizaines de millions, la pression memoire entre en concurrence avec votre charge transactionnelle, et vous n’avez pas les reglages specialises qu’offre un moteur dedie. Quand cela commence a faire mal, il est temps de regarder une base concue pour ca. Les candidats vers lesquels je me tourne sont Qdrant, Weaviate, Milvus et Pinecone.
Qdrant
Qdrant est ma recommandation par defaut pour un moteur dedie quand une equipe veut s’auto-heberger. Il est ecrit en Rust, les performances sont excellentes, et sa recherche filtree est vraiment bonne plutot que rajoutee a la va-vite. Le filtrage sur la charge utile s’integre a l’index vectoriel, donc vous ne payez pas la penalite decrite plus haut ou un filtre demolit le rappel. L’API est propre, la documentation honnete, et l’exploiter dans Docker ou Kubernetes est simple. Pour la plupart des equipes qui quittent pgvector, c’est la que je les oriente.
Weaviate
Weaviate assume d’etre plus qu’un simple stockage de vecteurs. Il a des modules integres pour generer des embeddings, faire de la recherche hybride d’office, et meme orchestrer des etapes generatives. Si vous voulez que la base prenne en charge une plus grande partie du pipeline et que vous aimez une API a saveur GraphQL, c’est un bon choix. Je trouve ces fonctions supplementaires utiles quand une equipe est petite et veut moins de pieces mobiles, et moins utiles quand une equipe a deja son propre code d’embedding et de recuperation et veut juste un stockage rapide.
Milvus
Milvus, c’est la grosse machinerie. Il est concu pour la tres grande echelle, avec une architecture distribuee qui separe stockage et calcul, et il prend en charge un large eventail de types d’index. Si vous gerez des centaines de millions ou des milliards de vecteurs, Milvus est concu exactement pour ca, et il monte en charge horizontalement comme les autres n’y arrivent pas aussi proprement. Le cout est la complexite operationnelle. C’est plus a exploiter, plus a comprendre, et excessif pour une charge qui tient confortablement sur un seul noeud. Sortez-le quand l’echelle l’exige vraiment, pas avant.
Pinecone
Pinecone est l’option geree et serverless. Vous n’exploitez rien, vous appelez une API, et elle gere la montee en charge et l’exploitation. Pour les equipes qui ne veulent pas posseder d’infrastructure, cela vaut de l’argent, et l’experience developpeur est fluide. Les compromis sont les habituels d’un service gere : le cout a l’echelle, moins de controle, et une dependance a un fournisseur pour une partie centrale de votre systeme. J’y recours quand une equipe avance vite et que le travail d’infrastructure n’est pas la ou elle veut depenser son attention limitee.
Comment je choisis vraiment
- Deja sur Postgres, sous quelques millions de vecteurs : pgvector. N’ajoutez pas un systeme dont vous n’avez pas besoin.
- Auto-hebergement, envie d’un moteur dedie rapide avec un filtrage solide : Qdrant.
- Envie que la base gere les embeddings et la recherche hybride : Weaviate.
- Des centaines de millions de vecteurs et une equipe pour l’exploiter : Milvus.
- Aucune envie d’exploiter de l’infrastructure : Pinecone.
Les facteurs qui comptent plus que le logo
Le nom de marque sur la base est la decision la moins interessante. Ce qui determine vraiment si vous serez content six mois plus tard est une liste plus courte. La performance de la recherche filtree, car les vraies requetes combinent presque toujours similarite et contraintes de metadonnees. La douleur du reindexage quand vous changez de modele d’embedding, ce qui arrivera. L’evolution du cout avec le nombre de vecteurs et le volume de requetes. Et la charge operationnelle a laquelle vous souscrivez par rapport a l’equipe dont vous disposez.
J’ai vu bien plus de projets souffrir d’un index mal regle ou d’une mauvaise strategie de decoupage que d’un mauvais choix de fournisseur. La base est un composant. Le systeme autour, surtout la qualite de la recuperation, est la ou se jouent vraiment les gains et les pertes, ce qui est le sujet de construire des systemes RAG avec des bases vectorielles.
Mon choix par defaut honnete
Commencez par pgvector. Prouvez que le produit fonctionne. Mesurez vos vrais schemas de requete et votre vrai nombre de vecteurs. Ne passez a un moteur dedie que lorsque vous avez la preuve que Postgres est le goulot d’etranglement, et a ce moment-la vous en saurez assez sur votre charge pour choisir le bon avec confiance. Prendre le systeme distribue sophistique des le premier jour est une facon classique de passer des semaines sur l’exploitation pour un probleme que vous n’avez pas encore.