Vector database (base de données vectorielle)

Les bases de données vectorielles se distinguent fondamentalement des bases de données relationnelles et des index de recherche classiques. Alors que les bases SQL renvoient des correspondances exactes et que la recherche plein texte repose sur la correspondance de mots-clés, les bases de données vectorielles travaillent avec la proximité sémantique. Elles ne comparent pas des chaînes de caractères, mais des représentations mathématiques du sens. Un client qui cherche « mobilier de bureau durable » trouve ainsi aussi des produits décrits comme « équipement de poste de travail écologique ». C'est cette capacité qui fait des bases de données vectorielles l'infrastructure de la Retrieval-Augmented Generation et des moteurs de recommandation modernes. Le compromis : tu échanges la précision déterministe contre la flexibilité sémantique.

Dans le marketing B2B, leur valeur se manifeste dans trois scénarios. Premièrement : les catalogues produits aux spécifications techniques que les clients veulent interroger en langage naturel. Un fabricant de machines trouve « clés dynamométriques pour applications à haute température », même si le catalogue indique « outils de serrage résistants à la chaleur ». Deuxièmement : les bibliothèques de contenus avec livres blancs, études de cas et enregistrements de webinaires, que l'on peut parcourir par thème plutôt que par titre. Troisièmement : les chatbots du service client qui accèdent à la documentation produit, aux bases de FAQ et aux tickets de support, sans qu'il faille entraîner manuellement chaque formulation. La base de données vectorielle fournit au grand modèle de langage les documents pertinents, et le LLM formule la réponse.

Les limites sont réelles et coûteuses. Les bases de données vectorielles ne passent pas à l'échelle de façon linéaire. Au-delà de plusieurs millions de vecteurs, les besoins en mémoire et les temps de réponse augmentent nettement. Les vecteurs de grande dimension (1536 dimensions pour les embeddings d'OpenAI) consomment des gigaoctets de RAM. Pinecone, Weaviate ou Qdrant coûtent vite des montants à quatre chiffres par mois pour des charges de travail en production. À cela s'ajoute que la qualité de la recherche dépend du modèle d'embedding. Si tu changes de modèle, tu dois recalculer tous les vecteurs. Autre erreur : utiliser les bases de données vectorielles comme solution universelle. Pour les requêtes structurées, les transactions ou les séries temporelles, PostgreSQL ou ClickHouse restent le meilleur choix. Les bases de données vectorielles résolvent un problème précis, pas tous les problèmes de données.

Lors du choix, ce qui compte, c'est la capacité d'intégration dans ta stack IA d'entreprise existante. Les services managés comme Pinecone ou Zilliz Cloud réduisent la charge d'exploitation, mais coûtent plus cher et te lient à un fournisseur. Les solutions auto-hébergées comme Qdrant ou Milvus te donnent le contrôle, mais exigent des capacités DevOps. Vérifie la prise en charge de la recherche hybride, qui combine recherche vectorielle et filtres classiques. Un catalogue produits doit rester filtrable par prix ou disponibilité pendant que la recherche sémantique s'exécute. Teste la latence sous charge. Des temps de réponse supérieurs à 200 millisecondes ruinent l'expérience utilisateur. Et prévois le versionnage dès le départ : tes embeddings vont changer, ta base de données doit pouvoir suivre.