La recherche à grande échelle est un défi. Aussi puissante que soit la recherche vectorielle, il peut être difficile de savoir comment évaluer correctement les facteurs clés tels que la précision, le coût et le débit pour des charges de travail plus importantes. Nous avons récemment publié le MongoDB Benchmark for Atlas Vector Search, qui présente des stratégies cruciales d'optimisation des performances pour la recherche vectorielle, fournissant un guide complet pour obtenir des résultats optimaux avec des jeux de données à grande échelle. L'objectif principal de notre guide est de réduire considérablement les difficultés lors de votre premier test vectoriel à grande échelle (> 10 millions de vecteurs) lors de l'évaluation des performances pour Atlas Vector Search.
Avec ce nouveau guide, nous souhaitons donner plus de contexte sur la façon d’utiliser le benchmark, d’explorer l’ensemble de données (y compris les facteurs pris en compte), ainsi que de résumer et de contextualiser les résultats. Regardons de plus près !
Remarque sur les données de benchmark
Toute bonne présentation inclut la diapositive de « safe harbor » requise, et l’art et la science du benchmarking ne font pas exception. Se lancer dans une charge de travail vectorielle à grande échelle peut présenter des obstacles importants découlant d’un manque d’informations précises et de la friction inhérente aux benchmarks initiaux. De plus, le paysage de la recherche vectorielle et des modèles d’embedding évolue rapidement, et les informations peuvent devenir obsolètes rapidement, entraînant les utilisateurs sur des voies inefficaces ou incorrectes. Sans un guide clair et à jour, les utilisateurs peuvent avoir du mal à prédire le comportement du système, à optimiser les configurations et à allouer les ressources en toute confiance.
Il est également utile de noter que de nombreux facteurs (quantification, dimensionnalité, filtrage, configuration des nœuds de recherche, concurrence, sharding, etc.) interagissent de manière complexe. Comprendre ces interactions et leur impact spécifique sur une charge de travail donnée nécessite des informations précises et approfondies. Sans cela, les utilisateurs pourraient optimiser un aspect pour, par inadvertance, en dégrader un autre.
Ce vide informationnel — associé aux frais généraux de configuration considérables, au réglage complexe des paramètres et au coût de l'expérimentation lié à l'exécution du premier benchmark — crée un obstacle substantiel à la validation et à la mise à l'échelle d'une solution. Néanmoins, nous estimons que ces benchmarks renforcent la confiance de nos clients dans leurs POC et leur fournissent un point de départ (contrairement au fait de n'avoir aucune boussole pour commencer).
En gardant ces facteurs à l’esprit, passons à un aperçu de l’ensemble de données.
Un aperçu du jeu de données
Le cœur de cette analyse de performance porte sur des tests effectués sur des sous-ensembles du jeu de données Amazon Reviews 2023, qui contient 48 millions de descriptions d’articles réparties dans 33 catégories de produits. Le jeu de données a été choisi en raison de la possibilité qu'il offre de créer un scénario d'e-commerce réaliste et à grande échelle, ainsi que d'offrir des données riches, y compris des avis d'utilisateurs (notes, texte, votes d'utilité), des métadonnées d'articles (prix, images) et des noms et descriptions détaillés d'articles, qui sont idéaux pour effectuer des recherches. Pour les tests de dimensions variables, des sous-ensembles de 5,5 millions d’articles ont été utilisés, intégrés à voyage-3-large pour produire des vecteurs de 2048 dimensions. Des vues ont ensuite été créées pour les découper en vecteurs de 1024, 512 et 256 dimensions afin de tester différentes dimensions. Pour le test de grande envergure et à haute dimension, un sous-ensemble de 15,3 millions d’articles, également intégré à des vecteurs de 2048 dimensions provenant de voyage-3-large, a été utilisé.
L’un des principaux enseignements du rapport est qu’à la dimensionnalité la plus élevée (15,3 millions de vecteurs utilisant des embeddings voyage-3-large à 2 048 dimensions), Atlas Vector Search, configuré avec une quantification scalaire ou binaire, conserve une précision de 90 à 95 % avec une latence de requête inférieure à 50 ms. Il est à noter que la quantification binaire peut entraîner une latence plus élevée lorsque le nombre de candidats demandés se compte par centaines, en raison du coût supplémentaire lié au rescoring avec des vecteurs de haute fidélité, mais elle peut rester préférable pour de nombreuses charges de travail à grande échelle en raison de sa rentabilité.

Méthodologie : analyse comparative avec le jeu de données d’avis Amazon
Maintenant que nous avons un peu parlé des données elles-mêmes et des informations incluses, décrivons certains des facteurs clés qui ont un impact sur les performances d'Atlas Vector Search, et la manière dont nous avons configuré notre benchmark pour les tester. Il est également important de reconnaître pourquoi ces variables sont critiques : tous les clients n'optimiseront pas leur recherche pour la même chose. Dans cette optique, nous tenterons également d'identifier les interactions et les compromis entre eux.
Bien que cette liste ne soit pas exhaustive (consultez le rapport complet pour plus de détails), examinons certains des facteurs de performance clés :
Rappel : le rappel (une mesure de la précision de la recherche) est considérablement impacté par la quantification et la dimensionnalité des vecteurs. Le rapport souligne que si la quantification scalaire commence généralement avec un meilleur rappel, la quantification binaire peut atteindre des niveaux de précision similaires en augmentant le nombre de numCandidates, bien que cela entraîne souvent une latence plus élevée en raison d’une étape supplémentaire de rescoring. En outre, les vecteurs de dimension supérieure (1024d et 2048d) maintiennent systématiquement un meilleur rappel, en particulier avec des jeux de données plus volumineux et la quantification, par rapport aux dimensions inférieures (256d et 512d), qui peinent à dépasser 70 à 80 % de rappel.
Dimensionnement et coûts : Le tableau du benchmark détaille les ressources requises (RAM, stockage) et les coûts associés pour différents niveaux de nœuds de recherche basés sur trois cas de test différents impliquant des tailles de jeu de données, des dimensions vectorielles et des méthodes de quantification (scalaire ou binaire) variables. Le guide fournit un exemple d’ensemble de données d’exemple indiquant que les besoins en ressources augmentent linéairement, tout en notant comment la quantification réduit considérablement les besoins en RAM.
Concurrence d'accès et débit : Le débit est évalué avec plusieurs requêtes émises simultanément. En général, la quantification scalaire permet d’atteindre davantage de requêtes par seconde (QPS) pour différentes valeurs limites, car il y a moins de travail par requête et aucune rescoring. Des goulots d’étranglement en termes de simultanéité sont souvent observés, ce qui indique qu'une latence plus élevée peut se produire. Il est recommandé d’augmenter le nombre de nœuds de recherche ou d’augmenter le nombre de vCPU disponibles pour résoudre ces goulots d’étranglement et obtenir une valeur QPS plus élevée.

Optimisation des performances de la recherche vectorielle
Ce rapport de référence examine en détail les performances de MongoDB Atlas Vector Search sur diverses configurations et de grands ensembles de données, plus précisément l’ensemble de données Amazon Reviews 2023. Il explore l'impact de facteurs tels que la quantification (scalaire et binaire), la dimensionnalité vectorielle, le filtrage, les configurations de nœuds de recherche, la compression binData, la concurrence et le sharding sur le rappel, la latence et le débit.
Bien qu’il n’y ait jamais de « solution miracle », car la définition de la « réussite » d’une recherche diffère d’une personne à l’autre, nous voulions mettre en évidence certains leviers à prendre en compte et les méthodes pour tirer le meilleur parti de votre propre déploiement. Notre objectif est d’apporter des éléments essentiels sur la manière d’évaluer et d’améliorer vos propres performances de recherche vectorielle, et de vous aider à bien peser et contextualiser les principaux facteurs. Prêt(e) à optimiser votre expérience de recherche vectorielle ?
Découvrez le guide de notre documentation.
Exécutez-le vous-même avec notre dépôt GitHub.