Qdrant libère des outils pour tester les déploiements RAG à très grande échelle

Mettre à l'épreuve les moteurs avec dix milliards de vecteurs denses et éparses

De surcroît, les jeux de vecteurs open source actuels ne sont pas suffisamment volumineux pour observer le comportement d’un système distribué à large échelle. La plupart des jeux de vecteurs disponibles publiquement ne contiennent pas plus de 10 millions de vecteurs et pèsent quelques gigaoctets de données. Qdrant-fineweb-10B rassemble 53 To de données (28,66 To) et de vecteurs (24,47 To).

De fait, comme Redis ou MongoDB, Qdrant s’appuie sur un mécanisme de sharding – de partitionnement horizontal – pour s’assurer de la montée à l’échelle de sa base de données et ses performances. Les collections sont divisées et réparties en petites partitions sur plusieurs serveurs ou nœud d’un serveur. Cela joue à la fois sur les performances pures et le chemin de stockage des vecteurs.

Or, les plus grands clients de l’éditeur exploitent déjà quelques centaines de millions jusqu’à plusieurs milliards de points de données.

« Vous pouvez établir de projections à partir de 10 millions de vecteurs en considérant que le comportement du système sera linéaire. Cela ne permet pas de le tester à pleine charge. Nous avons découvert que notre fonction de répartition de ces données entre les shards ne fonctionne en réalité pas comme prévu, que la répartition n’était pas proportionnelle », illustre André Zayarni. « Nous ne nous en serions pas rendu compte si nous nous étions contentés des projections ».

Si le volume de stockage est prévisible, l’écriture des vecteurs, leur répartition, l’indexation, le volume de requêtes, leur fréquence sont autant de paramètres qui jouent sur les performances d’un moteur de recherche sémantique ou d’un mécanisme RAG.

Qdrant-FineWeb-10B rassemble ainsi 1 vecteur dense de 768 dimensions et un vecteur épars par document. « Les vecteurs épars sont plus sophistiqués. Ils encodent le contexte associé à un mot, à une phrase ou à un paragraphe », décrit André Zayarni. « Jusqu’alors, les jeux de données de grande taille contenant des vecteurs épars n’existaient tout simplement pas. Même les petits “datasets” sont rares de nos jours ».

L’idée est de comparer le comportement des deux types de vecteurs avant de le déployer au sein d’un système de recherche sémantique ou RAG.

Par ailleurs, la plupart des benchmarks pour évaluer les systèmes vectoriels ne prennent pas en compte les filtres. Ceux-là permettent d’appliquer des contraintes supplémentaires : une plage de date, un langage, une catégorie, etc. Or, si une recherche vectorielle « brute » peut être performante, le moteur peut peiner lorsque ces filtres s’appliquent.

Enfin, selon Qdrant, pour comparer les résultats, il est nécessaire d’établir la vérité terrain. Les vecteurs doivent être associés aux documents sources, aux métadonnées et aux questions associés afin d’obtenir des mesures justes du rappel (recall). Cet indicateur définit la capacité du système de recherche à extraire les documents pertinents pour satisfaire la recherche. À noter que les filtres eux-mêmes génèrent des réponses spécifiques. Qdrant-FineWeb-10B réunit 100 000 requêtes issues de MS MARCO, ainsi que 10 000 requêtes éparses et 10 000 autres filtrées et les réponses associées.

Supernova, une suite d’outils pour propulser de grandes évaluations

Réunir et interroger 10 milliards de vecteurs n’est pas trivial. Le framework Supernova, écrit en Python et en Rust, a justement été mis en place pour assister à la création des vecteurs, calculer la vérité terrain, charger les embeddings dans une base de données vectorielle et exécuter ces comparaisons à l’échelle. Pour Qdrant-FineWeb-10B, la startup allemande s’est appuyée sur le modèle d’embedding gte-multilingual-base d’Alibaba.

Supernova dispose de plusieurs commandes. Nova-embed sert à générer les embeddings tout en conservant les données de données. Supernova prend en charge SentenceTransformers, vLLM, OpenAI et FastEmbed. Chaque worker invoqué est isolé. Par ailleurs, avec BGE-M3 – un modèle d’embedding capable de produire des vecteurs denses, épars et hybrides – Supernova parallélise les charges de travail pour éviter de relancer la commande trois fois.

Nova-bf vise à calculer le score de vérité terrain sur des GPU. Il utilise PyTorch et ne conserve qu’un résultat « top-k » à jour. « Il ne conserve jamais l’intégralité du corpus ni la matrice de scores complète en mémoire. Il dispose d’un parcours de calcul des scores distinct pour les données denses, éparses et multivectorielles (ColBERT), et traite les filtres comme faisant partie intégrante du pipeline plutôt que comme une étape postérieure à la recherche », précise Qdrant.

Un exercice qui n’a rien d’une sinécure. L’éditeur ne s’est pas arrêté aux 10 premiers résultats, mais en a pris en compte 1000, comme le ferait un acteur du e-commerce. Au total, en comptant les 120 000 requêtes évoquées plus haut, Qdrant a calculé un billiard de distances entre les vecteurs.

L’exécution des charges de travail est effectuée à l’aide de la commande nova-dist. Elle s’appuie sur le framework SkyPilot pour provisionner les machines, planifier les jobs et leur restauration sur AWS, Slurm, GCP, Azure et Kubernetes. La distribution des workloads est automatisée. Les commandes nova-load et storm servent à charger les vecteurs dans une base de données et commencer le chargement des requêtes.

Qdrant a par ailleurs optimisé Supernova pour que les filtres coûtent le moins cher possible et que les GPU utilisés soient continuellement alimentés en données lors de la phase de création des vecteurs.

Supernova a également servi à constituer les benchmarks PubMed-BGE-M3 et Coyo-VE. PubMed-BGE-M3 contient trois représentations (dense, épars, hybride) du même corpus de données scientifiques rassemblés par le National Institutes of Health américain. Coyo-VE, lui, rassemble des images et du texte (5,81 To) ainsi que les 15 millions de vecteurs denses associés (117 Go), généré par Qwen 3-VL-Embedding.

Le benchmark contenant 10 milliards de vecteurs a été testé sur le supercalculateur Aurora du laboratoire national américain d’Argonne, dans l’Illinois. Chaque nœud dispose de deux processeurs Intel Xeon MAX de 52 cœurs et de 1 To de mémoire vive, ce qui n’est pas à la portée du premier venu. Cependant, André Zayarni explique qu’il est tout à fait possible d’exploiter un sous-ensemble du benchmark pour tester un système de recherche sur « 100 millions, voire 1 milliard de vecteurs ». De plus, les entreprises et les concurrents de Qdrant peuvent tester leur base de données comme Elastic, Milvus/Ziliz, Weaviate ou encore Pinecone, ainsi que les SGBD compatibles avec les vecteurs, dont PostgreSQL.

« Nous sommes très fiers de proposer ces benchmarks et ces outils en open source. Nous croyons que cela va démocratiser les initiatives de recherche avancée et d’IA. Nos compétiteurs peuvent aussi s’en servir », vante André Zayarni.

Désormais, la majeure partie des grandes bases de données prennent en charge les vecteurs.

Toutefois, le CEO de Qdrant croit en la nécessité de base de données spécialisée. « Quand une entreprise souhaite déployer un système de recherche vectorielle, ma première question concerne le cas d’usage et le volume de données », explique-t-il.

« Si vous dépassez le million de points de données et que la recherche vectorielle est secondaire dans votre application, utilisez simplement ce dont vous disposez déjà dans votre pile technologique. Postgres suffit amplement. MongoDB aussi », poursuit-il. « Une solution spécialisée est importante et pertinente si les résultats de recherche ont un impact direct et concret sur votre chiffre d’affaires. Nous avons ainsi des exemples où nos clients sont passés d’autres solutions à la nôtre parce qu’ils pouvaient améliorer la recherche de quelques pour cent, ce qui leur rapportait déjà des dizaines, voire des centaines de millions de plus en chiffre d’affaires ».

Volume, rappel et latence sont alors trois métriques essentielles. « Les éditeurs de base de données multimodèle n’iront jamais aussi loin que ce que nous faisons ou ils introduiront les techniques avancées après coup », juge André Zayarni.

Edge et mémoire agentique sur la feuille de route

Qdrant monétise principalement ses services DBaaS pour le passage à l’échelle. Son logiciel de gestion de cluster est la principale brique propriétaire de sa pile technologique en cloud. Le reste est majoritairement open source.

Qdrant ne vise pas seulement les e-commerçants ou les spécialistes de la R&D. Elle entend renforcer ses fonctions Edge de sa solution. « Vous pouviez déjà exécuter Qdrant sur le cloud et on premise en mode self-hosted. Le mode Edge doit permettre des déploiements locaux, dans le cadre de projets d’IA physique. Qdrant pourrait jouer le rôle de backbone pour la mémoire des robots », envisage le dirigeant. Là, il s’agit d’assurer une synchronisation entre une instance distante du moteur de recherche vectorielle avec une autre dans le cloud ou on-premise.

L’autre développement qui nécessite l’intervention des communautés open source et des éditeurs concerne la mémoire agentique. Là, l’éditeur dit prendre en compte les retours des responsables des frameworks tels que LangGraph, Mem0 et Cognee. « Notre feuille de route est basée sur les retours de notre communauté, des partenaires et sur nos observations sur le marché », note André Zayarni. Qdrant cherche également à faciliter les déploiements en cloud pour les usagers.