Chapitre 4 — Choisir la bonne base vectorielle

Quatrième billet de la tournée chapitre par chapitre de LLM Primer III : Améliorer l'IA d'entreprise avec RAG. La partie d'un système RAG qui grandit le plus vite, coûte le plus à grande échelle et enferme le plus l'équipe — choisie sur des critères techniques et décidée sur des critères opérationnels.

Pourquoi ce chapitre existe

La base vectorielle est la couche de stockage du système de recherche, et le choix est une décision multi-axes — performance, résidence des données, forme opérationnelle de l'équipe, coût total de possession sur la durée de vie du système. Un mauvais choix enferme pour des années, parce que déplacer un milliard d'embeddings entre systèmes est un projet qu'aucune équipe ne prend à la légère. Les comparaisons techniques sont utiles, mais le choix est habituellement décidé sur les trois axes que les comparaisons techniques élident : où les données ont le droit de vivre, ce que l'équipe peut exploiter, et ce que le système coûte sur sa durée de vie.

4.1 Architectures : dédiées contre extensions

La première décision, souvent non nommée, est entre adopter un nouveau système dédié aux charges vectorielles et étendre un système que l'équipe exploite déjà. Une base dédiée — Pinecone, Qdrant, Milvus, Weaviate, Vespa — est conçue depuis l'index vers l'extérieur. Planificateur de requêtes, disposition du stockage, modèle de réplication et API sont tous pensés pour des requêtes de plus proches voisins approximatives sur des vecteurs en haute dimension. Plafonds de performance plus élevés, surtout sur les requêtes hybrides filtre + vecteur ; un système de plus à exploiter.

Une approche par extension — pgvector, Elasticsearch dense_vector, MongoDB Atlas Vector Search, Redis avec RediSearch — ajoute la recherche vectorielle à une base que l'équipe fait déjà tourner. Pas de nouvelle authentification, pas de nouvelle procédure de sauvegarde, pas de nouvelle rotation d'astreinte, pas de nouvelle cadence de patch. Le plafond de performance est fixé par l'architecture de l'hôte et est généralement bien au-dessus de ce que les applications sous les dizaines de millions de vecteurs demandent. La décision n'est rarement une pure question de performance. C'est plus souvent une question de savoir où l'équipe est disposée à dépenser son budget opérationnel — une équipe qui fait tourner une seule base Postgres ne veut pas en exploiter une seconde ; une équipe qui fait tourner dix services de données ne bronche pas devant un onzième.

4.2 Leaders managés : Pinecone et Vertex

Pinecone est la base vectorielle managée canonique. Simplicité opérationnelle, latence prévisible, SDK mature, et une formule serverless qui découple stockage et calcul et facture sur l'usage réel plutôt que sur la capacité provisionnée. Le bon défaut pour les nouveaux déploiements à moins que la charge ne bénéficie spécifiquement d'une capacité réservée. Le prix est l'enfermement architectural que tout système managé propriétaire porte — les embeddings sont portables en principe, mais le coût d'export-et-réindexation est réel. Vertex AI Vector Search est l'offre de Google, bâtie sur la bibliothèque ScaNN qui alimente la propre recherche de similarité à grande échelle de Google. Plafond d'échelle plus élevé, intégration serrée avec le reste de GCP — modèles d'embedding, IAM, Cloud Monitoring — et l'engagement stratégique correspondant envers un cloud unique. Azure AI Search occupe la même position pour les équipes engagées chez Microsoft. Le choix parmi les trois options natives de plateforme suit généralement l'engagement cloud existant, ce qui est raisonnable tant que l'équipe a vérifié l'échelle et la résidence.

4.3 Open source : Qdrant, Milvus, Weaviate

La catégorie open source s'adresse aux équipes qui veulent contrôler leur propre infrastructure — pour des raisons de coût, de résidence ou stratégiques — et ont la capacité opérationnelle de faire tourner des systèmes distribués. Qdrant est le plus petit et le plus focalisé : écrit en Rust, déployable en un seul binaire, conçu pour une recherche vectorielle à faible latence avec un filtrage et une quantization solides. Accessible au point d'être opérationnel en quelques minutes ; le bon choix pour la plus petite empreinte opérationnelle possible. Milvus est le plus grand et le plus orienté entreprise — architecture cloud-native séparant calcul, stockage et métadonnées, avec le plafond d'échelle le plus élevé de la catégorie (corpus à l'échelle du milliard, index accélérés par GPU, stockage en couches). Complexité opérationnelle significative, atténuée par Zilliz Cloud. Weaviate se place entre les deux — plus riche en fonctionnalités que Qdrant, moins complexe que Milvus, avec des modules intégrés pour l'embedding, le reranking et le multi-tenant. Une plateforme de recherche plutôt qu'un simple index de recherche. Les trois sont sous licence Apache dans leur cœur avec des offres managées payantes, et leurs benchmarks sont à un petit facteur constant les uns des autres. La décision est l'adéquation, pas la performance brute.

4.4 Embarqué et Postgres : Chroma et pgvector

La plupart des déploiements RAG réels servent quelques dizaines de requêtes par seconde sur quelques centaines de milliers de vecteurs, pas des millions par seconde sur des milliards. Pour ces charges, le bon outil tourne dans le processus de l'application ou à côté de lui. Chroma est l'option embarquée — in-process par défaut, persiste sur disque local, le cas le plus simple ne demande aucune configuration. Le bon choix pour les prototypes, les outils qui sont livrés avec leurs données, et les déploiements de production qui tiennent sur une machine. pgvector ajoute un type vecteur, des opérateurs de distance et l'indexation HNSW/IVFFlat à Postgres. Pour des corpus jusqu'à environ dix millions de vecteurs sur un hôte bien dimensionné, pgvector est un choix de production crédible et l'option la plus simple opérationnellement pour les équipes qui font déjà tourner Postgres. La recherche vectorielle devient une requête SQL contre une table que l'ORM existant comprend ; les jointures avec les métadonnées structurées sont de première classe. La vertu cachée de ces options est qu'elles abaissent le coût de changer d'avis — la migration vers un système distribué, si elle a lieu, est bornée.

4.5 Résidence, exploitation, et coût — les axes qui décident vraiment

Les trois axes opérationnels méritent d'être nommés parce qu'ils sont là où les décisions de production sont réellement décidées. La résidence des données restreint la liste des candidats avant toute comparaison technique ait du sens. Protection des données de l'UE, réglementation des services financiers, engagements de cloud souverain — ces contraintes ne sont pas négociables, et la question à poser en premier à tout fournisseur est de savoir quelles régions il supporte et quels sont ses engagements contractuels de traitement des données. Un piège particulier : les embeddings sont des données dérivées, mais ils restent des données personnelles sous la plupart des cadres réglementaires parce qu'ils peuvent être inversés ou utilisés pour retrouver l'original par recherche de similarité. Un contrat qui couvre les documents bruts mais reste vague sur les embeddings est incomplet.

La forme opérationnelle est la capacité propre de l'équipe. Une équipe de trois ingénieurs qui fait tourner un seul service applicatif devrait choisir l'option qui ajoute la plus petite surface opérationnelle — pgvector, un Pinecone managé ou Qdrant Cloud, Chroma embarqué. Une équipe de trente peut absorber la complexité d'un système open source distribué pour les avantages de coût et de capacité. L'erreur est de choisir un système qui ne correspond pas à la capacité réelle de l'équipe à l'exploiter. Le coût total sur la durée de vie du système inclut le provisioning, le monitoring, les sauvegardes, les exercices de restauration, la planification de capacité, le travail de mise à jour, et le coût proportionnel du temps d'astreinte. Le cadrage honnête demande le coût dans trois scénarios — charge actuelle, 10x, 100x — parce que la pente de la courbe compte autant que le point de départ.

Ce que prépare le Chapitre 4

La base vectorielle détermine ce que la couche de stockage peut contenir, à quelle vitesse on peut l'interroger, quels patrons de filtres et de métadonnées elle supporte. Aucune de ces propriétés ne décide à elle seule de la qualité de la recherche — elles décident de ce qu'il est possible de construire au-dessus. Ce qui se construit au-dessus, c'est la chaîne de recherche, où les gains se composent : recherche hybride combinant vecteurs denses et BM25, fusion par rang réciproque entre retrieveurs hétérogènes, reranking par cross-encoder, et la couche de compréhension de requête qui fait le pont entre la manière dont les utilisateurs demandent et celle dont les documents répondent.

Prochaine étape — Chapitre 5 : Architecturer la chaîne de recherche. Comment la recherche vectorielle dense et la recherche par mots-clés se combinent par fusion de rangs réciproques, l'étape de reranking par cross-encoder qui ferme l'essentiel de l'écart de qualité restant, et la couche de compréhension de requête qui fait le reste.