Elasticsearch BBQ vs. OpenSearch FAISS : Comparaison des performances de la recherche vectorielle

De la recherche vectorielle aux puissantes API REST, Elasticsearch offre aux développeurs la boîte à outils de recherche la plus complète. Explorez nos notebooks d’exemples sur GitHub pour tester de nouveaux cas d’usage. Vous pouvez également démarrer votre essai gratuit ou exécuter Elasticsearch en local dès aujourd’hui.

Recherche vectorielle avec quantification binaire : Elasticsearch avec BBQ est 5 fois plus rapide qu'OpenSearch avec FAISS. Elastic a reçu des demandes de notre communauté pour clarifier les différences de performance entre Elasticsearch et OpenSearch, en particulier dans le domaine de la recherche sémantique/recherche vectorielle. Nous avons donc réalisé ces tests de performance pour fournir des comparaisons claires et basées sur des données.

Démonstration de quantification binaire

Le stockage de vecteurs à haute dimension dans leur forme originale peut nécessiter beaucoup de mémoire. Les techniques de quantification compriment ces vecteurs dans une représentation compacte, ce qui réduit considérablement l'empreinte mémoire. La recherche s'effectue alors dans l'espace compressé, ce qui réduit la complexité des calculs et accélère les recherches, en particulier dans les grands ensembles de données.

Elastic s'engage à faire de Lucene un moteur vectoriel très performant. Nous avons introduit une meilleure quantification binaire (BBQ) dans Elasticsearch 8.16, en plus de Lucene, et l'avons fait évoluer dans les versions 8.18 et 9.0. BBQ repose sur une nouvelle approche de la quantification scalaire qui réduit les dimensions float32 en bits, ce qui permet une réduction de la mémoire de ~95% tout en conservant une qualité de classement élevée.

OpenSearch, quant à lui, utilise plusieurs moteurs vectoriels : nmslib (aujourd'hui obsolète), Lucene et FAISS. Dans un blog précédent, nous avons comparé Elasticsearch et OpenSearch pour la recherche vectorielle. Nous avons utilisé trois ensembles de données différents et testé différentes combinaisons de moteurs et de configurations sur les deux produits.

Ce blog se concentre sur les algorithmes de quantification binaire actuellement disponibles dans les deux produits. Nous avons testé Elasticsearch avec BBQ et OpenSearch avec la quantification binaire de FAISS en utilisant la piste Rallye openai_vector.

L'objectif principal était d'évaluer la performance des deux solutions avec le même niveau de rappel. Que signifie le terme "rappel"? Le rappel est un indicateur qui mesure le nombre de résultats pertinents retrouvés par un système de recherche.

Dans cette évaluation, recall@k est particulièrement important, k représentant le nombre de premiers résultats pris en compte. Le rappel@10, le rappel@50 et le rappel@100 mesurent donc le nombre de vrais résultats pertinents qui apparaissent respectivement dans les 10, 50 et 100 premiers éléments retrouvés. Le rappel est exprimé sur une échelle de 0 à 1 (ou de 0% à 100% précision). C'est important car nous parlons de KNN approximatif (ANN) et non de KNN exact, où le rappel est toujours de 1 (100%).

Pour chaque valeur de k, nous avons également spécifié n, qui est le nombre de candidats pris en compte avant d'appliquer le classement final. Cela signifie que pour Rappel@10, Rappel@50 et Rappel@100, le système récupère d'abord n candidats à l'aide de l'algorithme de quantification binaire, puis les classe pour déterminer si les k premiers résultats contiennent les éléments pertinents attendus.

En contrôlant n, nous pouvons analyser le compromis entre l'efficacité et la précision. Un n plus élevé augmente généralement le rappel, car plus de candidats sont disponibles pour le classement, mais il augmente également la latence et diminue le débit. Inversement, un n plus faible accélère la recherche mais peut réduire la mémorisation si trop peu de candidats pertinents sont inclus dans l'ensemble initial.

Dans cette comparaison, Elasticsearch a démontré une latence plus faible et un débit plus élevé qu'OpenSearch sur des configurations identiques.

Méthodologie

La configuration complète, ainsi que les scripts Terraform, les manifestes Kubernetes et la piste Rallye spécifique sont disponibles dans ce dépôt sous openai_vector_bq.

Comme pour les benchmarks précédents, nous avons utilisé un cluster Kubernetes composé de :

• 1 pool de nœuds pour Elasticsearch 9.0 avec 3 machines e2-standard-32 (128GB RAM et 32 CPUs)
• 1 pool de nœuds pour OpenSearch 2.19 avec 3 machines e2-standard-32 (128GB RAM et 32 CPUs)
• 1 pool de nœuds pour Rallye avec 2 machines e2-standard-4 (16GB RAM et 4 CPUs)

Nous avons mis en place un cluster Elasticsearch version 9.0 et un cluster OpenSearch version 2.19.

Elasticsearch et OpenSearch ont été testés avec la même configuration : nous avons utilisé openai_vector Rally track avec quelques modifications - qui utilise 2,5 millions de documents de l'ensemble de données NQ enrichis avec des embeddings générés à l'aide du modèle text-embedding-ada-002 d'OpenAI.

Les résultats portent sur la latence et le débit mesurés à différents niveaux de rappel (rappel@10, rappel@50 et rappel@100) en utilisant 8 clients simultanés pour effectuer des opérations de recherche. Nous avons utilisé un seul arbre et aucune réplique.

Nous avons exécuté les combinaisons suivantes de k-n-rescore, par exemple 10-2000-2000, ou k:10, n:2000 et rescore:2000 permet de retrouver les k (10) premiers candidats sur n candidats (2000) en appliquant un rescore sur 2000 résultats (ce qui équivaut à un "facteur de suréchantillon" de 1). Chaque recherche a été exécutée 10 000 fois avec 1000 recherches comme échauffement :

Rappel@10

• 10-40-40
• 10-50-50
• 10-100-100
• 10-200-200
• 10-500-500
• 10-750-750
• 10-1000-1000
• 10-1500-1500
• 10-2000-2000

Rappel@50

• 50-150-150
• 50-200-200
• 50-250-250
• 50-500-500
• 50-750-750
• 50-1000-1000
• 50-1200-1200
• 50-1500-1500
• 50-2000-2000

Rappel@100

• 100-200-200
• 100-250-250
• 100-300-300
• 100-500-500
• 100-750-750
• 100-1000-1000
• 100-1200-1200
• 100-1500-1500
• 100-2000-2000

Pour reproduire le benchmark, les manifestes Kubernetes pour rally-elasticsearch et rally-opensearch ont toutes les variables pertinentes externalisées dans un ConfigMap, disponible ici (ES) et ici (OS). Le paramètre search_ops peut être personnalisé pour tester n'importe quelle combinaison de k, n et rescore.

Configuration d'OpenSearch Rally

/k8s/rally-openai_vector-os-bq.yml

Configuration de l'index Opensearch

Les variables du ConfigMap sont ensuite utilisées pour la configuration de l'index, certains paramètres restant inchangés. La quantification sur 1 bit dans OpenSearch est configurée en réglant le niveau de compression sur "32x".

index-vectors-only-mapping-with-docid-mapping.json

Configuration d'Elasticsearch Rally

/k8s/rally-openai_vector-es-bq.yml

Configuration de l'index Elasticsearch

index-vectors-only-mapping-with-docid-mapping.json

Résultats

Il y a plusieurs façons d'interpréter les résultats. Pour la latence et le débit, nous avons tracé un graphique simplifié et un graphique détaillé à chaque niveau de rappel. Il est facile de voir les différences si l'on considère que "plus c'est élevé, mieux c'est" pour chaque indicateur. Cependant, le temps de latence est un facteur négatif (plus il est faible, mieux c'est), tandis que le débit est un facteur positif. Pour les graphiques simplifiés, nous avons utilisé (rappel / latence) * 10000 (appelé simplement "vitesse") et rappel * débit, de sorte que les deux mesures signifient qu'une plus grande vitesse et un plus grand débit sont meilleurs. Allons-y.

Rappel @ 10 - simplifié

À ce niveau de rappel, Elasticsearch BBQ est jusqu'à 5 fois plus rapide (3,9 fois plus rapide en moyenne) et a un débit 3,2 fois plus élevé en moyenne qu'OpenSearch FAISS.

Rappel @ 10 - Détaillé

Rappel à 50 ans - simplifié

À ce niveau de rappel, Elasticsearch BBQ est jusqu 'à 5 fois plus rapide (4,2 fois plus rapide en moyenne) et a un débit 3,9 fois plus élevé en moyenne qu'OpenSearch FAISS.

Résultats détaillés - Rappel à 50

Rappel à 100

À ce niveau de rappel, Elasticsearch BBQ est jusqu 'à 5 fois plus rapide (en moyenne 4,6 fois plus rapide) et a un débit 3,9 fois plus élevé en moyenne qu'OpenSearch FAISS.

Résultats détaillés - Rappel à 100

Améliorations apportées au barbecue

BBQ a beaucoup évolué depuis sa première version. Pour Elasticsearch 8.16, à des fins de comparaison, nous avons inclus un benchmark de la version 8.16 avec le benchmark actuel, et nous pouvons voir comment le rappel et la latence se sont améliorés depuis.

Dans Elasticsearch 8.18 et 9.0, nous avons réécrit l'algorithme de base pour quantifier les vecteurs. Ainsi, si BBQ 8.16 était bien, les versions les plus récentes sont encore meilleures. Pour en savoir plus, cliquez ici et ici. En bref, chaque vecteur est quantifié individuellement au moyen de quantiles scalaires optimisés. Ainsi, les utilisateurs bénéficient d'une plus grande précision dans la recherche vectorielle sans compromettre les performances, ce qui rend la recherche vectorielle d'Elasticsearch encore plus puissante.

Conclusion

Dans cette comparaison de performances entre Elasticsearch BBQ et OpenSearch FAISS, Elasticsearch surpasse de manière significative OpenSearch pour la recherche vectorielle, atteignant des vitesses de requête jusqu'à 5 fois plus rapides et un débit 3,9 fois plus élevé en moyenne pour différents niveaux de rappel.

Les principales conclusions sont les suivantes :

• Recall@10: Elasticsearch BBQ est jusqu'à 5 fois plus rapide (3,9 fois plus rapide en moyenne) et a un débit 3,2 fois plus élevé en moyenne par rapport à OpenSearch FAISS.
• Recall@50: Elasticsearch BBQ est jusqu'à 5 fois plus rapide (4,2 fois plus rapide en moyenne) et a un débit 3,9 fois plus élevé en moyenne par rapport à OpenSearch FAISS.
• Recall@100: Elasticsearch BBQ est jusqu'à 5 fois plus rapide (4,6 fois plus rapide en moyenne) et a un débit 3,9 fois plus élevé en moyenne par rapport à OpenSearch FAISS.

Ces résultats mettent en évidence les avantages d'Elasticsearch BBQ en termes d'efficacité et de performances, en particulier dans les scénarios de recherche vectorielle à haute dimension. La technique BBQ (Better Binary Quantization), introduite dans Elasticsearch 8.16, permet une réduction substantielle de la mémoire (~95%) tout en maintenant une qualité de classement élevée, ce qui en fait un choix supérieur pour les applications de recherche vectorielle à grande échelle.

Chez Elastic, nous innovons sans cesse pour améliorer Apache Lucene et Elasticsearch afin de fournir la meilleure base de données vectorielle pour les cas d'utilisation de recherche et d'extraction, y compris RAG (Retrieval Augmented Generation). Nos récentes avancées ont considérablement augmenté les performances, rendant la recherche vectorielle plus rapide et plus efficace en termes d'espace qu'auparavant, en s'appuyant sur les gains de Lucene 10. Ce blog est une autre illustration de cette innovation.