Passage à l'échelle des bases de données vectorielles : Pinecone vs Milvus

Les bases de données vectorielles constituent le moteur de toute application d'IA d'envergure. Lorsque vous concevez un système de recherche sémantique, un moteur de recommandation ou un pipeline RAG (Retrieval-Augmented Generation) avancé, votre base de données vectorielle est le composant le plus susceptible de ralentir l'ensemble de votre système. La réalité de la mise à l'échelle des bases de données vectorielles est complexe. Vous commencez avec quelques centaines de milliers d'embeddings, et tout semble extrêmement rapide. Vous atteignez les dix millions, et soudainement votre latence explose, la consommation de mémoire s'envole et votre facture cloud s'apparente à un numéro de téléphone.

Dans cet article, nous allons détailler précisément ce qui se produit lorsque vous passez à l'échelle avec des bases de données vectorielles - en nous concentrant spécifiquement sur Pinecone et Milvus. Nous analyserons l'architecture, les détails d'implémentation, les dures réalités des baisses de performance et la manière de concevoir un système capable de gérer des milliards de vecteurs sans s'effondrer.

Le problème : Pourquoi la recherche vectorielle à grande échelle est complexe

Le problème fondamental des bases de données vectorielles réside dans le fait que la recherche de similitude dans des espaces de grande dimension est gourmande en calculs et extrêmement consommatrice de mémoire. Les bases de données relationnelles classiques utilisent des index B-tree ou de hachage pour trouver des correspondances exactes en un temps $O(\log n)$ ou $O(1)$. Les bases de données vectorielles ne recherchent pas des correspondances exactes ; elles effectuent une recherche des plus proches voisins approximatifs (ANN - Approximate Nearest Neighbor). Elles doivent calculer la distance (cosinus, produit scalaire ou L2) entre votre vecteur de requête et des millions d'autres vecteurs.

La barrière de la mémoire (Memory Wall)

L'algorithme d'indexation le plus couramment utilisé dans les bases de données vectorielles est HNSW (Hierarchical Navigable Small World). HNSW est extrêmement rapide, mais il nécessite que l'intégralité de l'index réside en mémoire RAM pour offrir des performances optimales. Si vous disposez de 100 millions de vecteurs, chacun ayant 1536 dimensions (comme le modèle text-embedding-ada-002 d'OpenAI), et que vous utilisez des nombres à virgule flottante sur 32 bits, les données brutes représentent à elles seules environ 600 Go. Ajoutez à cela la surcharge du graphe HNSW, et vous dépassez 1 To de RAM nécessaire.

Dès que votre index dépasse la mémoire disponible, le système commence à utiliser le disque (swap), et votre latence initialement inférieure à la milliseconde passe à plusieurs centaines de millisecondes ou plus. C'est la barrière de la mémoire. Vous ne pouvez pas simplement ajouter indéfiniment de la RAM ; à un certain stade, les contraintes matérielles imposent de distribuer la charge.

Le goulot d'étranglement du calcul

Même si vous parvenez à tout conserver en mémoire, calculer les distances entre des vecteurs à 1536 dimensions reste très lourd pour les processeurs. Les instructions SIMD (Single Instruction, Multiple Data) aident à accélérer les calculs, mais à mesure que le volume de vos requêtes augmente, vous saturerez vos cœurs CPU. Les calculs mathématiques requis pour évaluer des produits scalaires ou des distances L2 sur des millions de vecteurs à grande dimension, au rythme de milliers de requêtes par seconde, exigent une puissance de calcul considérable.

Analyse des algorithmes d'indexation vectorielle et de leurs limites

Pour comprendre pourquoi la mise à l'échelle des bases de données vectorielles est si délicate, nous devons analyser les algorithmes d'indexation sous-jacents. On ne peut optimiser ce que l'on ne comprend pas.

Les index plats (Flat Indexes)

L'approche la plus simple est l'index plat. Elle consiste à prendre le vecteur de requête et à calculer sa distance avec chacun des vecteurs de la base de données. Cela garantit une précision de recherche de 100 % (recall), mais l'exécution évolue de façon linéaire $O(n)$. Avec un million de vecteurs, c'est lent. À un milliard, c'est inutilisable. Les index plats ne conviennent qu'aux très petits ensembles de données ou lorsque la précision absolue est obligatoire.

Index de fichiers inversés (IVF - Inverted File Index)

L'IVF découpe l'espace vectoriel en cellules de Voronoi. Lors de l'ingestion, chaque vecteur est associé au centroïde le plus proche. Lors d'une requête, le système identifie les centroïdes les plus proches du vecteur de requête et limite sa recherche à ces cellules spécifiques. Cela restreint considérablement l'espace de recherche. Cependant, l'IVF nécessite toujours d'importantes ressources mémoire et de calcul pour gérer les centroïdes et affecter les vecteurs de manière précise.

Graphes HNSW (Hierarchical Navigable Small World)

HNSW construit un graphe multicouche. La couche inférieure contient l'ensemble des vecteurs, et les couches supérieures contiennent progressivement moins de vecteurs, agissant comme des « voies rapides » pour la recherche. Lors d'une requête, l'algorithme entre par la couche supérieure, se déplace vers le nœud le plus proche, puis descend d'une couche, répétant ce processus jusqu'à identifier les plus proches voisins dans la couche inférieure. HNSW offre une latence et une précision exceptionnelles, mais sa consommation de mémoire est colossale. Les liaisons du graphe exigent un espace de stockage important, doublant souvent l'empreinte mémoire des vecteurs bruts.

Confrontation d'architectures : Pinecone vs Milvus

Pour aborder la question de la mise à l'échelle, deux voies principales s'offrent à vous : une solution SaaS entièrement managée comme Pinecone, ou un système distribué open source à héberger soi-même (ou managé) comme Milvus.

Pinecone : L'approche Serverless

Pinecone fait abstraction de l'infrastructure. Vous n'avez pas à provisionner de nœuds, à configurer des partitions (shards) ou à gérer la mémoire. Vous définissez un index, envoyez vos vecteurs et lancez vos requêtes.

L'architecture historique de Pinecone reposait sur des instances basées sur des pods, mais leur nouvelle architecture serverless change la donne. Dans celle-ci, Pinecone dissocie le calcul du stockage. Le stockage réside dans un service de stockage d'objets (comme AWS S3), et des nœuds de calcul sans état chargent des parties de l'index en mémoire à la demande en s'appuyant sur une couche de cache sophistiquée.

Les avantages de Pinecone :

• Aucune surcharge opérationnelle. Votre équipe d'ingénierie se concentre sur la logique de l'application, pas sur l'infrastructure.
• Évolutivité serverless réelle. Vous payez à l'usage et le système s'adapte de manière transparente.
• Excellente expérience de développement. Les SDK sont bien conçus et l'API est intuitive.

Les inconvénients de Pinecone :

• Coûteux à très grande échelle. Lorsque votre volume de vecteurs atteint des centaines de millions, le coût du SaaS devient significatif.
• Fonctionnement interne opaque. En cas de ralentissement, vous ne pouvez pas facilement analyser la structure de l'index sous-jacent ou affiner les paramètres matériels. Vous dépendez entièrement de leur environnement managé.

Milvus : Le moteur distribué

Milvus est une base de données vectorielle open source conçue spécifiquement pour la mise à l'échelle massive. Son architecture est hautement distribuée et basée sur des microservices, s'apparentant à une plateforme moderne cloud-native plutôt qu'à une base de données monolithique classique.

Milvus structure son architecture en quatre couches distinctes :

1. Couche d'accès (Access Layer) : Un proxy sans état qui gère les requêtes des clients, l'authentification et le routage.
2. Service coordinateur (Coordinator Service) : Le cerveau du système, qui gère la topologie du cluster, les métadonnées et attribue les tâches aux nœuds de travail.
3. Nœuds de travail (Worker Nodes) : Les moteurs du système. Les nœuds de requête (Query nodes) gèrent les recherches ANN, les nœuds de données (Data nodes) gèrent l'ingestion et les nœuds d'indexation (Index nodes) construisent les index HNSW ou IVF en arrière-plan.
4. Stockage (Storage) : Repose sur MinIO ou S3 pour le stockage d'objets et sur etcd pour les métadonnées, garantissant une grande durabilité.

Les avantages de Milvus :

• Évolutivité infinie si vous disposez des compétences en ingénierie requises. Vous pouvez mettre à l'échelle les nœuds de requête indépendamment des nœuds d'ingestion.
• Open source, ce qui vous laisse le contrôle total de l'infrastructure et des coûts. Vous pouvez le déployer sur des serveurs physiques (bare metal) ou des clusters Kubernetes personnalisés pour optimiser l'utilisation du matériel.
• Contrôle fin. Il prend en charge des algorithmes d'indexation avancés (IVF_FLAT, IVF_SQ8, IVF_PQ) vous permettant d'équilibrer précisément la précision de recherche (recall) et l'efficacité mémoire.

Les inconvénients de Milvus :

• Grande complexité opérationnelle. Exploiter Milvus en production exige de gérer Kubernetes, etcd, Apache Pulsar ou Kafka, et MinIO. Cela nécessite une équipe DevOps ou d'ingénierie de plateforme dédiée.

Implémentation : Comment nous avons réussi le passage à l'échelle

Lorsque nous avons dû faire passer le système RAG d'un client de 5 millions à 500 millions de vecteurs, nous avons atteint les limites des implémentations de base. Voici précisément comment nous y sommes parvenus et le code que nous avons déployé.

Étape 1 : La quantification est obligatoire

Si vous utilisez des vecteurs à virgule flottante de 32 bits à grande échelle, vous gaspillez votre budget. La première étape de la mise à l'échelle consiste à implémenter la quantification.

La quantification réduit la précision de vos vecteurs. La quantification scalaire (SQ - Scalar Quantization) convertit les nombres à virgule flottante 32 bits en entiers 8 bits, réduisant l'utilisation de la mémoire par 4. La quantification de produit (PQ - Product Quantization) compresse encore davantage les vecteurs en les découpant en sous-vecteurs et en les regroupant (clustering), ce qui permet de réduire l'empreinte mémoire jusqu'à 10 fois ou plus.

Dans Milvus, passer à un index IVF_SQ8 a transformé nos performances.

from pymilvus import Collection, CollectionSchema, FieldSchema, DataType

# Définir le schéma
fields = [
    FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
    FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1536)
]
schema = CollectionSchema(fields=fields, description="Scaled RAG collection")
collection = Collection(name="enterprise_rag", schema=schema)

# Configuration de l'index Milvus
index_params = {
    "metric_type": "COSINE",
    "index_type": "IVF_SQ8",
    "params": {"nlist": 4096}
}

# Créer l'index
collection.create_index(
    field_name="embedding", 
    index_params=index_params
)

Avec IVF_SQ8, nous avons réduit notre empreinte mémoire de 75 %. La précision de recherche a légèrement diminué (de 99 % à 96 %), mais dans un pipeline RAG où le LLM réalise la synthèse finale, cette baisse est tout à fait acceptable. Le LLM peut s'accommoder d'un léger bruit dans le contexte récupéré, ce qui justifie largement les économies financières réalisées.

Étape 2 : Partitionnement intelligent et filtrage des métadonnées

Il est rare de devoir effectuer une recherche sur l'intégralité de l'espace vectoriel. La plupart des requêtes comportent des filtres logiques (par exemple, « rechercher uniquement les documents de 2023 » ou « rechercher uniquement les données de l'utilisateur X »).

Pinecone et Milvus prennent tous deux en charge le filtrage par métadonnées. Cependant, filtrer après la recherche vectorielle est à proscrire (post-filtrage). Vous risquez de trouver les 100 plus proches voisins, puis d'en éliminer 99 sur la base d'un horodatage, retournant des résultats incomplets ou non pertinents.

Vous devez utiliser le pré-filtrage ou le filtrage à étape unique. Milvus s'appuie sur un mécanisme de masques binaires (bitsets) pour appliquer les filtres avant de calculer les distances. Pinecone gère cela nativement avec ses index de métadonnées.

Pour aller plus loin dans la mise à l'échelle, partitionnez vos données. Dans Milvus, nous avons mis en place un partitionnement strict par identifiant de locataire (tenant ID) pour assurer l'isolation des clients et préserver les performances :

# Création d'une partition
collection.create_partition("tenant_1042")

# Insertion dans une partition spécifique avec Milvus
collection.insert(
    data=entities,
    partition_name="tenant_1042"
)

# Requête sur une partition spécifique
results = collection.search(
    data=[query_vector],
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 128}},
    limit=10,
    partition_names=["tenant_1042"]
)

En ciblant des partitions précises, vous réduisez considérablement l'espace de recherche, contournant ainsi la barrière de la mémoire pour les requêtes spécifiques à un locataire.

Étape 3 : Gestion de l'ingestion à haut débit

Passer à l'échelle ne concerne pas seulement la lecture, mais aussi l'écriture. Les pipelines d'ingestion s'engorgent rapidement. Si vous sollicitez une base de données vectorielle avec des insertions individuelles répétées, vous surchargerez le journal des transactions et ralentirez la création de l'index.

Le traitement par lots (batching) est indispensable. Nous avons développé un pipeline de données qui regroupe les vecteurs en lots optimisés avant de les envoyer à la base de données.

# Pipeline d'ingestion par lots avec Pinecone
import itertools
from pinecone import Pinecone

pc = Pinecone(api_key="your-api-key")
pinecone_index = pc.Index("enterprise-rag")

def chunker(iterable, batch_size):
    """Génère des lots successifs de taille n."""
    it = iter(iterable)
    chunk = tuple(itertools.islice(it, batch_size))
    while chunk:
        yield chunk
        chunk = tuple(itertools.islice(it, batch_size))

# Insertion par lots de 1 000 vecteurs
# massive_vector_list est une liste de dictionnaires : {'id': 'vec1', 'values': [...], 'metadata': {...}}
for batch in chunker(massive_vector_list, 1000):
    pinecone_index.upsert(vectors=batch)

Pour Milvus, nous avons découplé l'ingestion à l'aide d'Apache Kafka, en publiant les données brutes dans un sujet (topic) et en utilisant un microservice consommateur dédié pour structurer et insérer les lots.

Stratégies de mise à l'échelle avancées

Au-delà de 100 millions de vecteurs, les optimisations de base ne suffisent plus. Des stratégies avancées sont nécessaires.

Séparation du calcul et du stockage

Si vous gérez votre propre infrastructure, séparez les ressources destinées à l'indexation de celles allouées aux requêtes. L'indexation est un traitement d'arrière-plan très gourmand en ressources CPU. Si une reconstruction d'index démarre pendant un pic de requêtes, votre latence va fortement augmenter. Dans Milvus, vous évitez cela en adaptant les nœuds d'indexation indépendamment des nœuds de requête.

Répliques de lecture (Read Replicas)

À l'instar des bases de données relationnelles, les bases de données vectorielles tirent profit des répliques de lecture. Une fois votre index construit, vous pouvez le dupliquer sur plusieurs nœuds pour répartir le trafic de consultation. C'est essentiel pour les environnements à forte concurrence.

Recherche hybride

La recherche vectorielle excelle pour les correspondances sémantiques, mais s'avère inefficace pour les mots-clés exacts (comme la recherche d'une référence produit spécifique). Implémenter une recherche hybride - qui associe la recherche vectorielle à une recherche textuelle classique (comme BM25) - vous permet de confier les recherches exactes à un moteur adapté (comme Elasticsearch) et de réserver la base de données vectorielle aux seules requêtes sémantiques. Pinecone gère nativement les vecteurs denses/creux, ce qui simplifie cette architecture.

Observabilité et supervision à grande échelle

Vous ne pouvez pas exploiter une base de données vectorielle à grande échelle sans outils de suivi.

Supervisez attentivement ces métriques :

1. Temps de construction de l'index : Si cette durée s'allonge, votre pipeline d'ingestion risque de prendre du retard.
2. Latence des requêtes (percentiles p95 et p99) : Les moyennes masquent les anomalies. Suivez le centile p99 pour détecter les ralentissements.
3. Utilisation mémoire par nœud : Indispensable pour anticiper la barrière de la mémoire. Configurez des alertes bien avant d'atteindre 90 % d'occupation.
4. Taux d'éviction : Si vous utilisez un système avec échange sur disque, mesurez la fréquence d'éviction des vecteurs de la RAM. Un taux élevé indique un besoin de mémoire supplémentaire ou d'une meilleure quantification.

Pièges à éviter

La mise à l'échelle des bases de données vectorielles met en évidence plusieurs réalités exigeantes.

1. Ignorer les démarrages à froid (Cold Starts) : Dans les architectures serverless comme celle de Pinecone, ou lorsque Milvus doit charger un segment du disque vers la mémoire, la première requête subit une latence plus élevée. Si votre application exige des temps de réponse bas et constants, vous devez mettre en place des requêtes de préchauffage (warm-up) factices pour maintenir les caches actifs.
2. Sur-indexation : Il n'est pas nécessaire d'indexer tous les champs. Les index vectoriels sont coûteux à concevoir. Si votre débit d'ingestion baisse, vérifiez si vous ne reconstruisez pas les graphes HNSW trop fréquemment ou si vous n'indexez pas des métadonnées rarement exploitées dans vos filtres de requêtes.
3. Rechercher à tout prix une précision de 100 % (Recall) : Les ingénieurs cherchent parfois à obtenir une précision de 100 % sur les recherches ANN. C'est un piège. Accepter de descendre à 95 % de précision peut multiplier les performances par 10 tout en restant imperceptible pour l'utilisateur final. Exploitez PQ ou SQ, et ajustez les paramètres ef_search ou nprobe de manière ferme.
4. Ne pas tester avec des données réelles : Des vecteurs synthétiques ne se comportent pas comme des embeddings réels. Réalisez toujours vos tests de performance avec les embeddings exacts produits par votre modèle en production.

Le choix final

Le choix entre Pinecone et Milvus revient à un arbitrage classique entre acheter une solution ou la construire soi-même.

Si votre équipe d'ingénierie est restreinte, vos délais courts et votre volume de vecteurs de l'ordre de quelques dizaines de millions, Pinecone s'impose. Le temps économisé sur la gestion de l'infrastructure compense largement le coût de l'abonnement SaaS. Vous pouvez déployer une configuration prête pour la production en quelques heures.

Si vous manipulez des centaines de millions ou des milliards de vecteurs et que vous disposez d'une équipe DevOps ou d'ingénierie de plateforme dédiée, Milvus est la voie recommandée. Son architecture microservices vous permet d'ajuster l'ingestion et les requêtes indépendamment, et les économies de coûts générées par la quantification et l'optimisation du matériel sur vos propres serveurs seront majeures.

Mettre à l'échelle des bases de données vectorielles est un défi d'ingénierie de haut niveau, mais en maîtrisant les contraintes de mémoire, en exploitant la quantification et en structurant judicieusement vos partitions, vous pourrez concevoir des systèmes capables de traiter des milliards de vecteurs en quelques millisecondes. Évitez les suppositions, mesurez vos performances et concevez pour la mise à l'échelle dès le premier jour.