Le benchmark Qdrant FineWeb 10B face au problème des petites données dans la recherche par IA

Qdrant a publié un jeu de données de recherche de 10 milliards de documents, mettant en lumière un conflit fondamental dans l’infrastructure IA : les systèmes de production sont gigantesques, alors que de nombreux tests reconnus restent relativement modestes. Le benchmark Qdrant FineWeb 10B offre aux chercheurs un corpus public comprenant des vecteurs denses et clairsemés, des requêtes filtrées et des résultats exacts de plus proches voisins. Son échelle rend les raccourcis habituels plus difficiles à masquer.

Cette publication ne proclame pas Qdrant comme la base de données vectorielle la plus rapide. Elle crée une infrastructure commune pour tester Qdrant, Milvus, Elasticsearch et d’autres systèmes de récupération dans des conditions exigeantes. Cette distinction est importante, car les graphiques de performance des fournisseurs reflètent souvent des jeux de données, du matériel, des objectifs de rappel, des filtres et des paramètres clients différents.

La confrontation centrale n’oppose donc pas Qdrant à un rival désigné. Elle oppose des mesures ouvertes et reproductibles à des affirmations de benchmark opportunes. Qdrant a rendu cette confrontation plus sérieuse, mais n’a pas répondu à toutes les questions concernant la qualité de la recherche en production.

Le benchmark Qdrant FineWeb 10B change le point de départ

Qdrant a fait passer le débat public sur les benchmarks de millions de vecteurs à plus de 10 milliards de documents Web réels.

Publié le 1er septembre 2026, Qdrant-FineWeb-10B s’appuie sur FineWeb, un corpus sélectionné issu de Common Crawl. La fiche du jeu de données publique recense 10,074,324,060 enregistrements.

Chaque enregistrement comprend la charge utile du document original et ses métadonnées. Il contient également un embedding dense et un embedding clairsemé produits avec le modèle gte-multilingual-base d’Alibaba. Un embedding dense représente un document sous la forme d’un vecteur numérique de longueur fixe, tandis qu’un embedding clairsemé enregistre des termes pondérés dans un vocabulaire bien plus vaste.

La représentation dense comporte 768 dimensions. Ses vecteurs sont normalisés pour la similarité cosinus, une mesure de proximité directionnelle entre vecteurs. La représentation clairsemée utilise des identifiants de tokens pondérés et un score par produit scalaire.

Ce corpus commun permet des comparaisons entre récupération dense, clairsemée, filtrée et hybride. La récupération hybride combine l’appariement sémantique avec des signaux fondés sur les termes, aidant les systèmes à traiter à la fois le sens général et les noms ou expressions exacts.

La publication fournit également 119,953 requêtes réparties en quatre groupes. Elles comprennent 100,000 requêtes denses, 10,000 requêtes clairsemées, 4,953 requêtes denses filtrées par texte et 5,000 requêtes denses filtrées de façon structurée. Les requêtes proviennent des jeux de données MS MARCO de Microsoft.

Pour chaque requête, Qdrant fournit les 1,000 résultats les plus proches exacts. Ces résultats exacts constituent la vérité terrain, c’est-à-dire la réponse de référence utilisée pour mesurer si un index approximatif plus rapide a manqué des voisins pertinents.

La production de cet ensemble de référence a exigé une recherche exhaustive dans l’ensemble du corpus. Qdrant indique que le travail a impliqué plus d’un quadrillion de calculs de distance sur une infrastructure basée sur des GPU. C’est important, car les systèmes de recherche approximative des plus proches voisins évitent délibérément de comparer chaque requête à chaque vecteur stocké.

L’approximation rend la recherche praticable, mais elle introduit des omissions. Sans vérité terrain exacte, les développeurs ne peuvent pas calculer le rappel de manière fiable. Le rappel mesure la proportion des vrais résultats les plus proches qu’un système approximatif récupère.

Le benchmark Qdrant FineWeb 10B modifie donc le matériel de test disponible, et pas seulement son volume. Les équipes peuvent examiner la vitesse d’ingestion, la construction d’index, l’utilisation mémoire, la latence, le débit, les filtres et le rappel par rapport au même ensemble de référence public.

Qdrant a également publié deux jeux de données associés. PubMed-Multi-Vector regroupe des représentations denses, clairsemées et de type ColBERT sur un corpus médical. Coyo-Vector-Embeddings cible la récupération multimodale à l’aide de paires texte et légende d’image.

Ces ajouts reconnaissent que la recherche moderne ne se limite plus à un vecteur par document. Certains systèmes combinent plusieurs représentations, des conditions de métadonnées, du reranking et des images dans une même requête.

Avant cette publication, la page publique de comparaison de Qdrant utilisait des jeux de données allant d’environ un million à 10 millions de vecteurs. L’entreprise soutient désormais que ces échelles ne peuvent révéler tous les problèmes rencontrés par les systèmes de production distribués.

Cet argument bénéficie d’un appui historique. L’étude Billion-Scale ANN relevait que des travaux empiriques bien antérieurs se concentraient sur des jeux de données contenant environ un million de points. Ses auteurs ont créé un cadre d’évaluation plus large, car les systèmes de recherche, de recommandation et de classement fonctionnaient déjà à l’échelle du milliard.

Qdrant prolonge cette orientation avec des données issues du Web, des ensembles de résultats plus profonds, plusieurs modes de récupération et une infrastructure réutilisable. Ce changement rehausse les attentes envers quiconque formule des affirmations sur la recherche IA à grande échelle.

Pourquoi les petits benchmarks peuvent produire de grandes incompréhensions

Un benchmark peut rapporter des chiffres précis tout en répondant à la mauvaise question de production.

Le benchmarking de la recherche vectorielle est particulièrement sensible à la conception des tests. Le taux de requêtes signifie peu de chose sans le rappel effectivement atteint. La latence ne peut être interprétée sans connaître la profondeur des résultats, la sélectivité des filtres, la concurrence, la configuration de l’index et la mémoire disponible.

Un système affichant un rappel de 90 pour cent peut traiter davantage de requêtes qu’un autre atteignant 99 pour cent. Cela ne le rend pas automatiquement meilleur. Les résultats manquants peuvent contenir les éléments nécessaires pour répondre à une question client difficile.

La différence devient plus importante lorsque les applications récupèrent des centaines ou des milliers de candidats pour un reranker. Un reranker est un modèle de seconde étape qui réordonne un ensemble plus large de candidats à l’aide de signaux de pertinence plus détaillés. Il ne peut pas récupérer un document que l’étape initiale de récupération n’a jamais renvoyé.

Les petits jeux de données peuvent aussi tenir aisément en mémoire sur une seule machine. Avec 10 milliards d’enregistrements, les équipes doivent faire face au partitionnement, au routage, à la réplication, aux accès disque, au trafic réseau et aux charges de requêtes inégales. Ce sont des problèmes de système, non des problèmes algorithmiques isolés.

La construction de l’index constitue un autre point de pression. Un index séduisant après le chargement d’un million de vecteurs peut exiger un temps de construction ou un stockage temporaire impraticables à une échelle beaucoup plus importante. Les mises à jour et la reprise après incident peuvent encore modifier sa valeur opérationnelle.

Le filtrage introduit des complications similaires. De nombreuses recherches d’entreprise combinent la similarité sémantique avec des conditions telles que l’identité du locataire, la date, la langue, les droits d’accès ou la catégorie de produit. Un résultat rapide sans filtre ne montre pas comment le moteur se comporte lorsqu’un filtre élimine la plupart des candidats.

Qdrant-FineWeb-10B comprend à la fois des filtres textuels et structurés. Ses requêtes structurées peuvent appliquer des conditions numériques, de date et d’ensemble. Les chercheurs peuvent ainsi tester si un index maintient précision et latence à mesure que les sous-ensembles éligibles se resserrent.

Le jeu de données préserve également les métadonnées Web. Le texte Web réel contient des passages répétés, des distributions inhabituelles, des sujets de longue traîne et des quasi-doublons. Les vecteurs générés aléatoirement reproduisent rarement ces caractéristiques.

Ce réalisme est important pour la génération augmentée par récupération, ou RAG. Un système RAG récupère des documents avant qu’un modèle de langage ne construise une réponse. Les échecs peuvent provenir d’une récupération insuffisante, d’un mauvais découpage, d’autorisations incorrectes, de contenus obsolètes ou d’erreurs de génération.

Un benchmark de base de données n’isole qu’une partie de cette chaîne. Il peut néanmoins révéler si la couche de récupération fournit les bons candidats dans des conditions contrôlées. Les équipes qui construisent une base de connaissances interrogeable ont besoin à la fois de mesures d’infrastructure et d’évaluations fondées sur leurs documents réels.

La publication de Qdrant pousse les fournisseurs de bases de données vectorielles à publier davantage de contexte avec leurs affirmations de performance. Les acheteurs devraient exiger un rappel comparable, un matériel clairement défini, des configurations complètes, la latence de queue, le temps d’indexation et la consommation de ressources.

La latence de queue mesure les requêtes les plus lentes vers la fin de la distribution de latence. Le 99e percentile, couramment appelé p99, indique le seuil sous lequel 99 pour cent des requêtes se terminent. Il importe souvent davantage qu’une moyenne lorsque les utilisateurs attendent des réponses cohérentes.

Le benchmark interpelle également les équipes d’ingénierie internes. De nombreuses organisations évaluent les bases de données à partir d’un petit échantillon, car générer des embeddings et des réponses exactes à pleine échelle coûte cher. Ces tests peuvent manquer des changements non linéaires causés par le sharding ou la pression mémoire.

Les données publiques à grande échelle abaissent une partie de cette barrière. Elles ne rendent pas une expérience sur 10 milliards de vecteurs peu coûteuse, mais elles éliminent la nécessité de créer indépendamment l’ensemble du corpus et le jeu de référence.

Vultr indique avoir fourni les ressources de calcul et le stockage objet utilisés pour la génération des embeddings. Selon son récit d’infrastructure, Qdrant a traité environ 500,000 fichiers et produit près de 25 téraoctets de données d’embeddings en approximativement cinq jours.

Ces chiffres décrivent la création du jeu de données, et non le coût ou la vitesse d’exécution de chaque base de données face à celui-ci. Cette distinction évite que la publication ne devienne une nouvelle affirmation de performance non étayée.

Supernova transforme le jeu de données en test de reproductibilité

La publication la plus importante pourrait être Supernova, car un jeu de données statique ne peut pas standardiser la manière dont les bases de données sont chargées, interrogées et mesurées.

Qdrant a publié Supernova comme un framework open source couvrant quatre étapes du benchmarking de recherche vectorielle. Il génère des embeddings, calcule la vérité terrain exacte, charge les bases de données ciblées et exécute des charges de travail de recherche.

Le framework sépare ces tâches en modules spécialisés. nova-embed gère la génération d’embeddings entre différents modèles et systèmes de stockage. Il répartit le travail entre des workers indépendants sans s’appuyer sur une base de données centrale de coordination.

nova-bf effectue le calcul de vérité terrain par force brute. La force brute compare les requêtes à chaque vecteur éligible, produisant un ensemble de référence exact plutôt qu’une approximation. Qdrant indique que le module diffuse les partitions depuis un stockage distant afin d’éviter de placer l’intégralité du corpus dans la mémoire GPU.

L’outil peut traiter des représentations denses, clairsemées et multivecteurs. Il peut également évaluer les filtres sur des CPU avant de transférer les données admissibles vers les GPU. Cette conception vise à réduire les transferts inutiles lorsque les filtres éliminent de larges portions du corpus.

nova-load pilote l’ingestion parallèle dans une base de données. Cette phase mesure la vitesse à laquelle un système peut accepter le jeu de données et révèle des contraintes opérationnelles que les benchmarks de requêtes purs ignorent.

nova-storm génère un trafic de recherche concurrent. Selon les détails de publication de Qdrant, il enregistre le débit de requêtes, plusieurs percentiles de latence, les temps de construction et le rappel par rapport aux résultats exacts.

Un contrôleur distinct, nova-dist, utilise SkyPilot pour le provisionnement de clusters et l’ordonnancement des tâches. Qdrant indique que les mêmes configurations basées sur YAML peuvent cibler les principales plateformes cloud, Kubernetes et les clusters de calcul haute performance basés sur Slurm.

Cette conception vise l’adversaire principal de la publication : les affirmations opaques de benchmark. Un graphique publié offre une valeur limitée si des tiers ne peuvent pas examiner la charge de travail ou reproduire l’expérience. Les données publiques et les outils pilotés par configuration exposent davantage d’hypothèses.

Cette approche permet également aux fournisseurs concurrents de remettre en question les choix de Qdrant. Les ingénieurs de Milvus ou d’Elasticsearch peuvent proposer de meilleures configurations pour leurs systèmes. Les chercheurs peuvent modifier le matériel, la concurrence, les mélanges de requêtes et les objectifs de rappel sans reconstruire la vérité terrain.

Cette ouverture n’élimine pas les biais de réglage. Qdrant connaît naturellement mieux sa propre base de données que celles de ses concurrents. Sa documentation de benchmark reconnaît explicitement que l’entreprise peut configurer Qdrant plus efficacement et pourrait négliger des optimisations importantes ailleurs.

La reproductibilité apporte une réponse à ce conflit, plutôt qu’une preuve de neutralité. Lorsque le code, les données et les paramètres sont visibles, d’autres mainteneurs peuvent repérer les configurations insuffisantes et soumettre des modifications.

Une évaluation indépendante reste nécessaire. Une analyse de septembre de TechTarget a cité plusieurs spécialistes externes des données qui considéraient l’ensemble de données comme une contribution crédible. L’analyste William McKnight a déclaré que sa combinaison de distributions réalistes de textes web et de résultats exacts semblait bien adaptée aux tests denses, clairsemés et filtrés.

Un autre analyste, Kevin Petrie de BARC, a averti que les organisations avaient toujours besoin de benchmarks fondés sur leurs propres charges de travail. Cette réserve définit la valeur réelle de la publication. Un benchmark partagé facilite la comparaison, tandis qu’un test spécifique à une charge de travail appuie une décision d’achat.

Supernova peut aider à relier ces usages, car les équipes peuvent appliquer le cadre à un autre corpus. Elles peuvent conserver le pipeline de mesure tout en remplaçant les documents privés, les requêtes, les filtres et les modèles d’embedding.

Le benchmark vectoriel de Qdrant doit donc avant tout être compris comme une infrastructure de test. Il crée un point de départ public et un processus reproductible. Il ne désigne pas un vainqueur universel.

Ce que l’échelle de 10 milliards ne prouve toujours pas

L’échelle corrige une faiblesse du benchmarking de recherche vectorielle, mais elle ne peut représenter toutes les sources de défaillance d’un produit de recherche par IA.

Premièrement, FineWeb est un vaste corpus de textes web. Un corpus d’entreprise peut contenir du code, des contrats, des dossiers médicaux, des tickets de support, des catalogues de produits, des transcriptions de réunions ou de courts messages internes. Ces documents présentent des longueurs, vocabulaires, schémas de duplication et règles d’accès différents.

Deuxièmement, le benchmark utilise un seul modèle d’embedding pour son jeu de données central. Les modèles d’embedding transforment le texte en vecteurs, et leur comportement façonne le voisinage exploré. Changer de modèle peut modifier les dimensions vectorielles, la parcimonie, le regroupement et la difficulté de récupération.

Le benchmark Qdrant FineWeb 10B utilise gte-multilingual-base pour les représentations denses comme clairsemées. Cela garantit une cohérence, mais les performances avec ce modèle ne garantissent pas le même classement avec un autre modèle.

Troisièmement, les voisins les plus proches exacts ne sont pas automatiquement les documents les plus utiles. La vérité terrain détermine si un système approximatif a reproduit les correspondances les plus proches du modèle d’embedding. Elle ne détermine pas si ces correspondances répondent au besoin d’information d’un utilisateur.

Cette distinction sépare le rappel ANN de la pertinence de récupération. Le rappel ANN demande si l’index a trouvé les vecteurs qu’un calcul exact aurait trouvés. La pertinence demande si ces documents aident réellement à répondre à la requête.

Un système peut atteindre un rappel ANN presque parfait tout en utilisant un modèle d’embedding qui comprend mal un domaine spécialisé. Il peut également renvoyer des documents techniquement similaires, mais obsolètes, non autorisés ou redondants.

Les propres conseils de Qdrant sur la pertinence recommandent un ensemble annoté associant des requêtes aux documents attendus. Cette couche d’évaluation reste essentielle pour les équipes qui déploient du RAG ou de la recherche sémantique.

Quatrièmement, la fiche du jeu de données signale un problème de reproductibilité numérique. La vérité terrain publiée utilisait une arithmétique GPU bfloat16, tandis que les scripts de régénération produisent des embeddings float32. De petites différences numériques peuvent réordonner des résultats ex æquo ou affecter les éléments proches de la limite des 1 000 premiers.

Qdrant a signalé cette divergence et indiqué travailler à un correctif. Le problème n’annule pas la valeur du jeu de données, mais il montre pourquoi les artefacts publics nécessitent une inspection indépendante.

Cinquièmement, l’accès constitue un obstacle concret. La page Hugging Face indique une taille totale de fichiers de plusieurs dizaines de téraoctets. De nombreuses équipes peuvent télécharger rapidement un jeu de données plus petit, mais rares sont celles qui peuvent facilement préparer, indexer et tester cette publication.

Les entreprises les plus à même d’exécuter le benchmark complet seront les fournisseurs de bases de données, les fournisseurs cloud, les grandes entreprises et les institutions de recherche. Les petites équipes pourraient dépendre de résultats publiés ou de sous-ensembles échantillonnés, recréant une partie du problème de confiance.

Un classement partagé et hébergé pourrait améliorer l’accès, mais il introduirait des questions de gouvernance. Quelqu’un doit définir les profils matériels, approuver les configurations, vérifier les soumissions, mettre à jour les versions des bases de données et empêcher la publication sélective des résultats.

Sixièmement, cette publication ne mesure pas la qualité complète d’une application. La recherche IA en production inclut souvent l’analyse des documents, le découpage en segments, la réécriture des requêtes, la fusion hybride, le reranking, la mise en cache, l’autorisation et la génération de réponses. Une défaillance à n’importe quelle étape peut dominer l’expérience utilisateur.

Ces limites ne plaident pas en faveur de benchmarks plus petits. Elles s’opposent à l’idée de traiter un seul grand benchmark comme un cadre d’achat complet.

Les acheteurs devraient combiner trois niveaux de preuves. Un test public peut révéler le comportement général à grande échelle. Un test sur une charge de travail privée peut reproduire les distributions et filtres locaux. Une évaluation de bout en bout peut mesurer si les utilisateurs reçoivent des réponses correctes et attribuables.

Cette norme est exigeante, mais la recherche IA soutient de plus en plus des décisions pour lesquelles manquer un seul document peut avoir de l’importance. Un benchmark devrait rendre ces compromis visibles plutôt que de les réduire à un unique score de débit.

Trois signaux montreront si le pari de Qdrant fonctionne

La publication ne réussira que si des équipes indépendantes l’utilisent pour produire des preuves comparables, identifier des problèmes et améliorer le processus de test.

Le premier signal sera la disponibilité de résultats tiers reproductibles. Les chercheurs et fournisseurs de bases de données doivent publier des exécutions complètes utilisant Qdrant-FineWeb-10B ou un sous-ensemble auditable. Ces rapports devraient inclure le matériel, les versions logicielles, les paramètres d’index, le temps d’ingestion, la mémoire, le rappel et la latence p99.

Un rappel comparable sera particulièrement important. Comparer le débit à différents niveaux de précision peut donner l’impression qu’un système plus rapide est meilleur sans révéler ce qu’il a omis. Les résultats devraient présenter les performances pour plusieurs objectifs de rappel.

Si des équipes indépendantes reproduisent les résultats sur Qdrant, Milvus, Elasticsearch, pgvector et d’autres systèmes, cette publication renforcera l’argument en faveur de mesures ouvertes. Si les configurations restent incomplètes ou trop coûteuses, son influence se limitera.

Le deuxième signal sera l’activité de correction autour des données et des outils. La différence numérique signalée dans la fiche du jeu de données offre un test immédiat. Un correctif rapide, des artefacts versionnés, des sommes de contrôle et des changements documentés renforceraient la confiance.

Les chercheurs devraient aussi examiner la composition des requêtes, les doublons, la couverture linguistique, les distributions de filtres et la difficulté des tâches de recherche des plus proches voisins. Un nombre élevé de lignes ne garantit pas une évaluation équilibrée.

L’historique des contributions de Supernova importe ici. Des rapports de bugs externes, des pull requests, des intégrations de backends et des configurations alternatives montreraient qu’il fonctionne comme une infrastructure communautaire. Une activité extérieure limitée le rapprocherait davantage d’une démonstration maintenue par un fournisseur.

Le troisième signal sera de savoir si les acheteurs modifient ce qu’ils demandent aux fournisseurs. Le résultat le plus durable ne serait pas une position unique dans un classement. Ce serait une norme d’approvisionnement plus solide pour la recherche IA.

Les équipes d’entreprise devraient demander aux fournisseurs de communiquer le rappel exact parallèlement à la latence. Elles devraient exiger des mesures d’ingestion et de construction d’index, et pas seulement la vitesse de requête en régime établi. Elles devraient également tester les filtres sélectifs et la récupération après défaillance.

Les résultats de benchmarks publics peuvent réduire une liste restreinte, mais les organisations ont toujours besoin de preuves locales. Un détaillant effectuant des recherches dans des catalogues de produits, par exemple, peut accorder de l’importance aux filtres d’inventaire et à une grande profondeur de récupération. Une équipe juridique peut privilégier l’isolation des locataires, les citations et la terminologie exacte.

Le benchmark Qdrant FineWeb 10B offre aux deux groupes un meilleur point de référence. Il montre ce qui devient mesurable lorsque quelqu’un assume le coût considérable de créer des réponses exactes à l’échelle d’Internet.

Qdrant en tire aussi des avantages stratégiques. L’entreprise peut influencer les mesures que les acheteurs jugent importantes, tout en plaçant son langage privilégié du rappel, de l’ouverture et de la reproductibilité au centre de la discussion.

Cela n’invalide pas le travail. Les normes commencent souvent lorsqu’un participant intéressé investit des ressources que d’autres n’investiraient pas. La garantie réside dans une gouvernance transparente et une réplication externe crédible.

Les concurrents disposent désormais d’un choix utile. Ils peuvent exécuter la charge de travail et publier leurs résultats, remettre en question ses hypothèses avec des preuves, ou contribuer à des jeux de données et tests alternatifs. Le silence rendra les affirmations opaques sur les performances plus difficiles à défendre.

Pour les développeurs, l’action immédiate n’est pas de télécharger des dizaines de téraoctets sans plan. Commencez par identifier la question qui nécessite une réponse : rappel algorithmique, montée en charge de la base de données, pertinence de récupération ou qualité de l’application de bout en bout.

Choisissez ensuite le plus petit test qui conserve la difficulté pertinente. Utilisez la vérité terrain publique lorsqu’elle convient, mais conservez les requêtes et documents privés dans l’évaluation finale. Enregistrez chaque configuration nécessaire pour reproduire le résultat.

Le benchmarking de recherche IA ne sera pas corrigé par l’échelle seule. Pourtant, l’échelle élimine une excuse devenue de plus en plus commode. Le benchmark Qdrant FineWeb 10B offre désormais au secteur un moyen public de tester des affirmations qui dépendaient auparavant de données et d’infrastructures privées.

Les prochains mois devraient révéler si la communauté le considère comme un laboratoire partagé ou comme un autre artefact de fournisseur. Les développeurs et les acheteurs devraient suivre les réplications, les corrections et les soumissions concurrentes, puis exiger la même transparence de chaque fournisseur de recherche IA qu’ils évaluent.