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é

tâche

latence.moyenne

débit.moyen

avg_recall

Elasticsearch-9.0-BBQ

10-100-100

11.70

513.58

0.89

Elasticsearch-9.0-BBQ

10-1000-100

27.33

250.55

0.95

Elasticsearch-9.0-BBQ

10-1500-1500

35.93

197.26

0.95

Elasticsearch-9.0-BBQ

10-200-200

13.33

456.16

0.92

Elasticsearch-9.0-BBQ

10-2000-2000

44.27

161.40

0.95

Elasticsearch-9.0-BBQ

10-40-40

10.97

539.94

0.84

Elasticsearch-9.0-BBQ

10-50-50

11.00

535.73

0.85

Elasticsearch-9.0-BBQ

10-500-500

19.52

341.45

0.93

Elasticsearch-9.0-BBQ

10-750-750

22.94

295.19

0.94

OpenSearch-2.19-faiss

10-100-100

35.59

200.61

0.94

OpenSearch-2.19-faiss

10-1000-1000

156.81

58.30

0.96

OpenSearch-2.19-faiss

10-1500-1500

181.79

42.97

0.96

OpenSearch-2.19-faiss

10-200-200

47.91

155.16

0.95

OpenSearch-2.19-faiss

10-2000-2000

232.14

31.84

0.96

OpenSearch-2.19-faiss

10-40-40

27.55

249.25

0.92

OpenSearch-2.19-faiss

10-50-50

28.78

245.14

0.92

OpenSearch-2.19-faiss

10-500-500

79.44

97.06

0.96

OpenSearch-2.19-faiss

10-750-750

104.19

75.49

0.96

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 moyennequ'OpenSearch FAISS.

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

Tâche

Latence Moyenne

Débit moyen

Rappel moyen

Elasticsearch-9.0-BBQ

50-1000-1000

25.71

246.44

0.95

Elasticsearch-9.0-BBQ

50-1200-1200

28.81

227.85

0.95

Elasticsearch-9.0-BBQ

50-150-150

13.43

362.90

0.90

Elasticsearch-9.0-BBQ

50-1500-1500

33.38

202.37

0.95

Elasticsearch-9.0-BBQ

50-200-200

12.99

406.30

0.91

Elasticsearch-9.0-BBQ

50-2000-2000

42.63

163.68

0.95

Elasticsearch-9.0-BBQ

50-250-250

14.41

373.21

0.92

Elasticsearch-9.0-BBQ

50-500-500

17.15

341.04

0.93

Elasticsearch-9.0-BBQ

50-750-750

31.25

248.60

0.94

OpenSearch-2.19-faiss

50-1000-1000

125.35

62.53

0.96

OpenSearch-2.19-faiss

50-1200-1200

143.87

54.75

0.96

OpenSearch-2.19-faiss

50-150-150

43.64

130.01

0.89

OpenSearch-2.19-faiss

50-1500-1500

169.45

46.35

0.96

OpenSearch-2.19-faiss

50-200-200

48.05

156.07

0.91

OpenSearch-2.19-faiss

50-2000-2000

216.73

36.38

0.96

OpenSearch-2.19-faiss

50-250-250

53.52

142.44

0.93

OpenSearch-2.19-faiss

50-500-500

78.98

97.82

0.95

OpenSearch-2.19-faiss

50-750-750

103.20

75.86

0.96

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

tâche

latence.moyenne

débit.moyen

avg_recall

Elasticsearch-9.0-BBQ

100-1000-1000

27.82

243.22

0.95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224.04

0.95

Elasticsearch-9.0-BBQ

100-1500-1500

35.98

193.99

0.95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403.86

0.88

Elasticsearch-9.0-BBQ

100-2000-2000

45.36

159.88

0.95

Elasticsearch-9.0-BBQ

100-250-250

14.77

433.06

0.90

Elasticsearch-9.0-BBQ

100-300-300

14.61

375.54

0.91

Elasticsearch-9.0-BBQ

100-500-500

18.88

340.37

0.93

Elasticsearch-9.0-BBQ

100-750-750

23.59

285.79

0.94

OpenSearch-2.19-faiss

100-1000-1000

142.90

58.48

0.95

OpenSearch-2.19-faiss

100-1200-1200

153.03

51.04

0.95

OpenSearch-2.19-faiss

100-1500-1500

181.79

43.20

0.96

OpenSearch-2.19-faiss

100-200-200

50.94

131.62

0.83

OpenSearch-2.19-faiss

100-2000-2000

232.53

33.67

0.96

OpenSearch-2.19-faiss

100-250-250

57.08

131.23

0.87

OpenSearch-2.19-faiss

100-300-300

62.76

120.10

0.89

OpenSearch-2.19-faiss

100-500-500

84.36

91.54

0.93

OpenSearch-2.19-faiss

100-750-750

111.33

69.95

0.94

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.

La recherche vectorielle est en train de révolutionner la manière dont nous effectuons les recherches par similarité, en particulier dans des domaines comme l’IA et le Machine Learning. Face à l’adoption de plus en plus répandue des modèles d’intégration de vecteurs, la capacité de rechercher efficacement à travers des millions de vecteurs de haute dimension devient cruciale.

Elastic et OpenSearch ont choisi des approches très distinctes pour l’exécution des bases de données vectorielles. Pour que ses produits soient le meilleur choix pour les applications de recherche vectorielle, Elastic a investi massivement dans l’optimisation d’Apache Lucene avec Elasticsearch. En revanche, OpenSearch a élargi son champ d’action en intégrant d’autres implémentations de recherche vectorielle et en explorant au-delà de la portée de Lucene. En nous concentrant de manière stratégique sur Lucene, nous pouvons proposer un soutien très intégré dans notre version d’Elasticsearch. Il en résulte un ensemble de fonctionnalités amélioré, où chaque composant complète et amplifie les capacités de l’autre.

Ce blog offre une comparaison détaillée entre Elasticsearch 8.14 et OpenSearch 2.14, en se basant sur différentes configurations et différents moteurs vectoriels. Dans cette analyse des performances, Elasticsearch s'est avéré être la plateforme supérieure pour les opérations de recherche vectorielle, et les fonctionnalités à venir creuseront encore davantage l'écart. Comparé à OpenSearch, il a excellé dans tous les domaines de référence — offrant des performances 2 à 12 fois plus rapides en moyenne. Cela s’est produit dans des scénarios utilisant des quantités et des dimensions de vecteurs variables, notamment so_vector (2 millions de vecteurs, 768D), openai_vector (2,5 millions de vecteurs, 1536D) et dense_vector (10 millions de vecteurs, 96D), tous disponibles dans ce référentiel aux côtés des scripts Terraform pour provisionner toute l’infrastructure requise sur Google Cloud et les manifestes Kubernetes pour exécuter les tests.

Les résultats de ce blog s’ajoutent à ceux d'une étude validée par une tierce partie et publiée précédemment. L’étude avait révélé qu’Elasticsearch est plus rapide de 40%–140% qu’OpenSearch en ce qui concerne les opérations d’analyse de recherche les plus courantes : requêtes textuelles, tri, plages, histogramme de dates et filtrage par termes. Maintenant, nous pouvons ajouter un autre facteur de différenciation : la recherche vectorielle. Maintenant, nous pouvons ajouter un autre facteur de différenciation : la recherche vectorielle.

Jusqu’à 12 fois plus rapide d’emblée

Nos tests d'évaluation ciblés sur les quatre ensembles de données vectorielles impliquaient à la fois des recherches KNN approximatives et KNN exactes, en tenant compte de différentes tailles, dimensions et configurations, totalisant 40.189.820 demandes de rechercher non mises en cache. Les résultats : Elasticsearch est jusqu'à 12 fois plus rapide qu'OpenSearch pour la recherche vectorielle et nécessite donc moins de ressources de calcul.

Figure 1 : Tâches groupées pour ANN et KNN exact dans différentes combinaisons dans Elasticsearch et OpenSearch.

Les groupes tels que knn-10-100 signifient une rechercher KNN avec et . Dans la recherche vectorielle HNSW, détermine le nombre de voisins les plus proches à récupérer pour un vecteur de requête. Il définit le nombre de vecteurs similaires qui seront renvoyés en résultat. définit le nombre de vecteurs candidats à récupérer à chaque segment. Un plus grand nombre de candidats peut renforcer la précision, au prix de ressources de calcul plus importantes.

Après avoir testé différentes techniques de quantification et tiré parti des optimisations spécifiques à chaque moteur, nous avons obtenu des résultats détaillés pour chaque piste, tâche et moteur vectoriel, que vous trouverez ci-dessous.

KNN exact et KNN approximatif

Pour des ensembles de données et des cas d’utilisation variés, l’approche appropriée pour la recherche vectorielle variera. Dans ce blog, toutes les tâches indiquées comme knn-* comme knn-10-100 utilisent Approximate KNN et script-score-* font référence à Exact KNN, mais quelle est la différence entre elles et pourquoi sont-elles importantes ?

Grâce à sa plus grande évolutivité, la méthode de l’algorithme des plus proches voisins approximatifs (ANN) est la solution préférée lorsque vous traitez des ensembles de données plus substantiels. La méthode des plus proches voisins exacts (KNN) est idéale pour les jeux de données plus modestes qui nécessitent parfois un processus de filtrage.

La méthode du KNN exact emploie une approche par la force brute, qui consiste à calculer la distance entre un vecteur et chaque autre vecteur du jeu de données. Elle classe ensuite ces distances pour trouver les voisins les plus proches. Même si cette méthode assure une correspondance exacte, elle fait face à des problèmes d’évolutivité pour les jeux de données volumineux et à haute dimension. Toutefois, il y a de nombreuses situations dans lesquelles le recours au KNN exact est requis :

• Réévaluation: dans les cas qui impliquent des recherches lexicales ou sémantiques suivies d’une réévaluation basée sur les vecteurs, le KNN exact est indispensable. Dans un moteur de recherche de produits, par exemple, on peut d’abord filtrer les résultats de recherche initiaux à l’aide de requêtes textuelles (mots-clés, catégories), puis utiliser les vecteurs associés aux éléments filtrés pour une évaluation de similarité plus précise.

• Personnalisation: dans le cas d'un grand nombre d'utilisateurs, dont chacun est représenté par un nombre relativement peu élevé (environ 1 million) de vecteurs distincts, le classement de l'index en fonction des métadonnées de l'utilisateur (p. ex., user_id) et le score par force brute avec des vecteurs deviennent efficaces. Cette approche permet de fournir des recommandations personnalisées ou un contenu personnalisé, en fonction de comparaisons de vecteurs précises qui sont spécifiquement conçues pour les préférences de chaque utilisateur.

Le KNN exact permet d’assurer un classement final et des recommandations précis et adaptés aux préférences de l’utilisateur, car ils sont fondés sur la similarité vectorielle.

D’un autre côté, le KNN approximatif (ANN) utilise des méthodes qui rendent la recherche de données plus rapide et plus efficace que le KNN exact, en particulier dans les jeux de données volumineux et à haute dimension. Contrairement à une approche par force brute qui mesure la distance exacte entre une requête et tous les points (ce qui pose des défis de calcul et de mise à l’échelle), l’ANN recourt à des techniques spécifiques afin de restructurer efficacement les index et les dimensions des vecteurs interrogeables dans l’ensemble de données. Même si cela peut entraîner une légère inexactitude, cela accélère considérablement le processus de recherche, ce qui en fait une solution de rechange efficace pour les ensembles de données volumineux.

Dans ce blog, toutes les tâches indiquées comme knn-* comme knn-10-100 utilisent KNN approximatif et script-score-* font référence à KNN exact.

Méthodologie de test

Même si l'API des opérations de recherche BM25 est similaire pour Elasticsearch et OpenSearch (puisque ce dernier est une copie du premier), cela ne s’applique pas à la recherche vectorielle, laquelle a été introduite après la copie. OpenSearch a adopté une approche différente d’Elasticsearch en ce qui concerne les algorithmes, en introduisant deux autres moteurs - nmslib et faiss luceneplus , chacun avec ses configurations et limitations spécifiques (par exemple, nmslib dans OpenSearch n’autorise pas les filtres, une fonctionnalité essentielle pour de nombreux cas d’utilisation).

Les trois moteurs emploient l’algorithme HNSW, lequel est très performant pour la recherche approximative des plus proches voisins et particulièrement puissant en présence de données de grande dimension. Il est important de noter que faiss prend également en charge un deuxième algorithme, ivf, mais comme il nécessite une formation préalable sur l'ensemble de données, nous allons nous concentrer uniquement sur HNSW. Le concept principal de HNSW est d’organiser les données en couches de graphes connectés, où chaque couche reflète une granularité différente de l’ensemble de données. La recherche s’amorce à la couche supérieure, qui propose la vue la plus grossière. Elle progresse ensuite vers des couches de plus en plus fines jusqu’au niveau de base.

Les deux moteurs de recherche ont fait l’objet de tests dans un cadre contrôlé, sous des conditions strictement identiques, afin de garantir un terrain d'essai équitable. La méthode utilisée est comparable à la comparaison de performance publiée précédemment, avec des groupes de nœuds dédiés pour Elasticsearch, OpenSearch et Rally. Le script terraform est disponible (ainsi que toutes les sources) pour provisionner un cluster Kubernetes avec :

• 1 pool de nœuds pour Elasticsearch avec 3 machines e2-standard-32 (128 Go de RAM et 32 processeurs)

• 1 pool de nœuds pour OpenSearch avec 3 machines e2-standard-32 (128 Go de RAM et 32 processeurs)

• 1 pool de nœuds pour Rally avec 2 machines t2a-standard-16 (64 Go de RAM et 16 processeurs)

Chaque test (ou piste) a été exécuté à 10 reprises pour chaque configuration, qui incluait différents moteurs, différentes configurations et différents types de vecteurs. Chaque piste se compose de tâches qui sont répétées de 1000 à 10 000 fois, en fonction de la piste. En cas d'échec d’une tâche dans une piste (en raison, par exemple, d’une temporisation de réseau), toutes les tâches sont abandonnées. C’est pourquoi tous les résultats sont issus de pistes qui ont démarré et se sont terminées sans problème. L’ensemble des résultats de test sont validés sur le plan statistique, ce qui assure que les améliorations ne sont pas le résultat d’une coïncidence.

Résultats détaillés

Pourquoi comparer en utilisant le 99e percentile et non la latence moyenne ? Prenons un exemple hypothétique du prix moyen des logements dans un quartier donné. Le prix moyen peut laisser penser que la zone est onéreuse, mais en y regardant de plus près, il peut se révéler que la plupart des logements sont évalués à un prix beaucoup plus bas, et que seules quelques propriétés de luxe font augmenter la moyenne. Le prix moyen peut ne pas refléter avec précision la gamme complète des valeurs des maisons dans la région, comme l’illustre cet exemple. C’est comparable à l’étude des temps de réponse, où le chiffre moyen peut dissimuler des enjeux critiques.

Tâches

• KNN approximatif avec k :10 n :50

• KNN approximatif avec k : 10 n : 100

• KNN approximatif avec k : 100 n : 1 000

• KNN approximatif avec k :10, n :50 et filtres de mots-clés

• KNN approximatif avec k : 10, n : 100 et filtres de mots-clés

• KNN approximatif avec k :100, n :1000 et filtres de mots-clés

• KNN approximatif avec k:10 n:100 en conjonction avec l'indexation

• KNN exact (score du script)

Moteurs vectoriels

• lucene dans Elasticsearch et OpenSearch, tous deux en version 9.10

• faiss dans OpenSearch

• nmslib dans OpenSearch

Types de vecteurs

• hnsw dans Elasticsearch et OpenSearch

• int8_hnsw dans Elasticsearch (HNSW avec quantification automatique 8 bits–: lien)

• sq_fp16 hnsw dans OpenSearch (HNSW avec quantification automatique 16 bits : lien)

Recherche prête à l'emploi et recherche de segments simultanés

Lucene est une bibliothèque de moteur de recherche de texte hautement performante, rédigée en Java. Elle constitue la pierre angulaire de nombreuses plateformes de recherche, telles qu’Elasticsearch, OpenSearch et Solr. Le cœur du système de Lucene repose sur l’organisation des données en segments. Ces segments sont des index autonomes qui permettent d’exécuter les recherches plus efficacement. Donc, si vous effectuez une recherche sur un moteur basé sur Lucene, cette recherche sera exécutée dans ces segments, de manière séquentielle ou en parallèle.

OpenSearch a introduit la recherche de segments simultanés en tant qu’indicateur facultatif et ne l’utilise pas par défaut, vous devez l’activer à l’aide d’un paramètre d’index spécial index.search.concurrent_segment_search.enabled comme détaillé ici, avec certaines limitations.

En revanche, Elasticsearch effectue des recherches sur les segments en parallèle par défaut. C’est pourquoi les comparaisons que nous effectuons dans cet article de blog tiendront compte, outre des différents moteurs et types de vecteurs, des différentes configurations également :

• Elasticsearch ootb : Elasticsearch prêt à l'emploi, avec recherche de segments simultanés ;

• OpenSearch ootb : sans activation de la recherche par segments simultanés ;

• OpenSearch css : avec la recherche par segments simultanés activée

À présent, examinons en détail les résultats pour chaque ensemble de données vectorielles qui a été testé :

2,5 millions de vecteurs, 1536 dimensions (openai_vector)

En commençant par la piste la plus simple, mais aussi la plus grande en termes de dimensions, openai_vector - qui utilise l'ensemble de données NQ enrichi avec des intégrations générées à l'aide du modèle text-embedding-ada-002 d'OpenAI. Il s'agit du plus simple, du fait qu’il ne teste que le KNN approximatif et qu'il ne comporte que 5 tâches. Les tests sont effectués en mode autonome (sans indexation) de même qu’en conjonction avec l’indexation, et avec un seul client ou 8 clients simultanés.

Tâches

• standalone-search-knn-10-100-multiple-clients : recherche sur 2,5 millions de vecteurs avec 8 clients simultanément, k : 10 et n :100

• standalone-search-knn-100-1000-multiple-clients : recherche sur 2,5 millions de vecteurs avec 8 clients simultanément, k : 100 et n : 1000

• standalone-search-knn-10-100-single-client: recherche sur 2,5 millions de vecteurs avec un seul client, k : 10 et n : 100

• standalone-search-knn-100-1000-single-client: recherche sur 2,5 millions de vecteurs avec un seul client, k : 100 et n : 1000

• parallel-documents-indexing-search-knn-10-100: indexation sur 2,5 millions de vecteurs tout en recherchant 100 000 documents supplémentaires, k : 10 et n : 100

Les performances moyennes de p99 sont décrites ci-dessous :

Nous avons constaté ici qu’Elasticsearch est 3 à 8 fois plus rapide qu’OpenSearch lors d’une recherche vectorielle effectuée en parallèle de l'indexation (c’est-à-dire. lecture+écriture) avec :10 et :100 et 2 à 3 fois plus rapide sans indexation pour les mêmes k et n. Pour :100 et :1000 (standalone-rechercher-knn-100-1000-single-client et standalone-rechercher-knn-100-1000-multiple-clients Elasticsearch est 2 à 7 fois plus rapide qu'OpenSearch, en moyenne.

Les résultats détaillés montrent les cas exacts et les moteurs vectoriels comparés :

Rappel

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0,969485

0,995138

Elasticsearch-8.14.0@lucene-int8_hnsw

0,781445

0,784817

OpenSearch-2.14.0@lucene-hnsw

0,96519

0,995422

OpenSearch-2.14.0@faiss

0,984154

0,98049

OpenSearch-2.14.0@faiss-sq_fp16

0,980012

0,97721

OpenSearch-2.14.0@nmslib

0,982532

0,99832

10 millions de vecteurs, 96 dimensions (dense_vector)

dense_vector avec 10 millions de vecteurs et 96 dimensions. Il est basé sur le jeu de données d'images Yandex DEEP1B. Le jeu de données est créé à partir des 10 premiers millions de vecteurs du fichier « données d’échantillon » appelé learn.350M.fbin. Les opérations de recherche font appel à des vecteurs qui proviennent du fichier de « requêtes de données » query.public.10K.fbin.

Après une fusion forcée, qui est habituellement effectuée sur des index en lecture seule, Elasticsearch et OpenSearch sont très performants sur cet ensemble de données. Cette opération est similaire à une défragmentation, ce qui permet d’avoir une seule « table » pour la recherche.

Tâches

Chaque tâche fait l'objet d’un préchauffage de 100 requêtes, et la mesure est ensuite effectuée sur les 1000 requêtes suivantes

• knn-search-10-100: recherche sur 10 millions de vecteurs, k : 10 et n : 100

• knn-search-100-1000: recherche sur 10 millions de vecteurs, k : 100 et n : 1000

• knn-search-10-100-force-merge: recherche sur 10 millions de vecteurs après une fusion forcée, k : 10 et n : 100

• knn-search-100-1000-force-merge: recherche sur 10 millions de vecteurs après une fusion forcée, k : 100 et n :1000

• knn-search-100-1000-concurrent-with-indexing: indexation sur 10 millions de vecteurs tout en mettant à jour 5 % de l'ensemble de données, k : 100 et n : 1000

• script-score-query: recherche KNN exacte de 2000 vecteurs spécifiques.

Elasticsearch et OpenSearch ont tous deux obtenu de bons résultats pour le KNN approximatif. Lorsque l’index est fusionné (c’est-à-dire qu’il n’a qu’un seul segment) dans knn-rechercher-100-1000-force-merge et knn-rechercher-10-100-force-merge, OpenSearch fonctionne mieux que les autres lors de l’utilisation de nmslib et faiss, même s’ils sont tous autour de 15 ms et tous très proches.

Lorsque l'index a plusieurs segments (ce qui est typique lorsqu'un index reçoit des mises à jour), Elasticsearch maintient la latence autour de ~7ms et ~16ms dans les tests knn-search-10-100 et knn-search-100-1000, tandis que tous les autres moteurs OpenSearch sont plus lents.

Lorsque l'index est interrogé et mis à jour simultanément (knn-search-100-1000-concurrent-with-indexing), Elasticsearch maintient une latence inférieure à 15 ms (13,8 ms). Il est presque 4 fois plus rapide qu’OpenSearch par défaut (49,3 ms) et reste plus rapide lorsque la recherche concurrente de segments est activée (17,9 ms), bien que la différence ne soit pas significative.

En ce qui concerne le KNN exact, l’écart est bien plus important : Elasticsearch est 6 fois plus rapide qu’OpenSearch (~260 ms contre ~1600 ms).

Rappel

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0,969843

0,996577

Elasticsearch-8.14.0@lucene-int8_hnsw

0,775458

0,840254

OpenSearch-2.14.0@lucene-hnsw

0,971333

0,996747

OpenSearch-2.14.0@faiss

0,9704

0,914755

OpenSearch-2.14.0@faiss-sq_fp16

0,968025

0,913862

OpenSearch-2.14.0@nmslib

0,9674

0,910303

2 millions de vecteurs, 768 dimensions (so_vector)

Cette piste, so_vector, est dérivée d’une extraction des publications de StackOverflow téléchargée le 21 avril 2022. Seuls les documents de questions y figurent, les documents de réponses ayant tous été supprimés. Chaque titre de question a été encodé dans un vecteur en utilisant le modèle de transformateur de phrase multi-qa-mpnet-base-cos-v1. Cet ensemble de données contient les 2 premiers millions de questions.

Contrairement à la piste précédente, chaque document ici contient d'autres champs en plus des vecteurs pour prendre en charge le test de fonctionnalités comme le KNN approximatif avec filtrage et la recherche hybride. nmslib pour OpenSearch est notamment absent dans ce test car il ne prend pas en charge les filtres.

Tâches

Chaque tâche fait l'objet d’un préchauffage de 100 requêtes, et la mesure est ensuite effectuée sur les 100 requêtes suivantes. Veuillez noter que les tâches ont été groupées dans un souci de simplicité, le test contenant 16 types de recherche, 2 valeurs k et 3 valeurs n différentes.

• KNN-10-50: recherche sur 2 millions de vecteurs sans filtres, k :10 et n :50

• knn-10-50-filtered: recherche sur 2 millions de vecteurs avec des filtres, k :10 et n :50

• knn-10-50-after-force-merge: recherche sur 2 millions de vecteurs avec filtres et après une fusion forcée, k :10 et n :50

• KNN-10-100: recherche sur 2 millions de vecteurs sans filtres, k :10 et n :100

• knn-10-100-filtered: recherche sur 2 millions de vecteurs avec des filtres, k :10 et n :100

• knn-10-100-after-force-merge: recherche sur 2 millions de vecteurs avec filtres et après une fusion forcée, k :10 et n :100

• KNN-100-1000: Recherche sur 2 millions de vecteurs sans filtres, k :100 et n :1000

• knn-100-1000-filtered: recherche sur 2 millions de vecteurs avec des filtres, k :100 et n :1000

• knn-100-1000-after-force-merge: recherche sur 2 millions de vecteurs avec filtres et après une fusion forcée, k :100 et n :1000

• exact-knn: recherche KNN exacte avec et sans filtres.

Au cours de ce test, Elasticsearch est toujours plus rapide qu’OpenSearch par défaut, sauf dans deux cas où la différence n’est pas très grande (knn-10-100 et knn-100-1000). Les tâches impliquant knn-10-50, knn-10-100 et knn-100-1000 en combinaison avec des filtres montrent une différence allant jusqu'à 7x (112 ms contre 803 ms).

Les performances des deux solutions semblent s'équilibrer après une « fusion forcée », ce qui est compréhensible, comme en témoignent knn-10-50-after-force-merge, knn-10-100-after-force-merge et knn-100-1000-after-force-merge. Pour ces tâches, faiss est plus rapide.

La performance pour le KNN exact est à nouveau très différente : Elasticsearch est cette fois 13 fois plus rapide qu’OpenSearch (~385 ms contre ~5262 ms).

Rappel

knn-recall-10-100

knn-recall-100-1000

knn-recall-10-50

Elasticsearch-8.14.0@lucene-hnsw

1

1

1

Elasticsearch-8.14.0@lucene-int8_hnsw

1

0,986667

1

OpenSearch-2.14.0@lucene-hnsw

1

1

1

OpenSearch-2.14.0@faiss

1

1

1

OpenSearch-2.14.0@faiss-sq_fp16

1

1

1

OpenSearch-2.14.0@nmslib

0,9674

0,910303

0,976394

Elasticsearch et Lucene, les vainqueurs incontestables

Chez Elastic, nous innovons sans cesse avec Apache Lucene et Elasticsearch pour pouvoir proposer la meilleure base de données vectorielles pour les cas d'utilisation de recherche et de récupération, y compris la RAG (Génération augmentée de récupération). Nos avancées récentes ont considérablement amélioré les performances, rendant la recherche vectorielle plus rapide et plus économe en espace qu'auparavant, en s'appuyant sur les améliorations de Lucene 9.10. Ce blog présente une étude qui montre que lorsque l’on compare les versions les plus récentes, Elasticsearch est jusqu’à 12 fois plus rapide qu’OpenSearch.

Il convient de noter que les deux produits utilisent la même version de Lucene (Notes de publication d'Elasticsearch 8.14 et Notes de publication d'OpenSearch 2.14).

Le rythme d'innovation d'Elastic nous permettra d'aller encore plus loin, non seulement pour nos clients sur site et Elastic Cloud, mais aussi pour ceux qui utilisent notre plateforme sans état. Des fonctionnalités comme la prise en charge de la quantification scalaire vers int4 seront proposées avec des tests rigoureux, afin que les clients puissent utiliser ces techniques sans une perte significative d'exactitude, de la même manière que nos tests pour l’int8.

La capacité d’une recherche vectorielle à être efficace est un critère non négociable pour les moteurs de recherche modernes, du fait de la prolifération des applications d’IA et de Machine Learning. Elasticsearch est la solution qui s’impose pour les organisations qui ont besoin d’un moteur de recherche puissant capable de gérer la demande en données vectorielles de grand volume et de haute complexité.

L’intégration d’Elasticsearch pour les besoins de recherche vectorielle, que ce soit pour étendre une plateforme établie ou lancer de nouveaux projets, représente une approche stratégique qui générera des bénéfices tangibles et à long terme. Fort de son avantage de performance avéré, Elasticsearch est bien placé pour sous-tendre la prochaine vague d’innovations dans la recherche.