Comprendre le fonctionnement du filtrage dans la recherche vectorielle vous aidera à équilibrer les compromis entre performance et rappel, et à découvrir certaines des optimisations utilisées pour rendre la recherche vectorielle plus performante lorsque le filtrage est utilisé.

Pourquoi le filtrage ?

La recherche vectorielle a révolutionné la manière dont nous trouvons des informations pertinentes dans de grands ensembles de données, en nous permettant de découvrir des éléments sémantiquement similaires à une requête.

Toutefois, il ne suffit pas de trouver des articles similaires. Nous devons souvent réduire les résultats de la recherche en fonction de critères ou d'attributs spécifiques.

Imaginez que vous recherchiez un produit dans un magasin de commerce électronique. Une recherche purement vectorielle peut vous montrer des articles visuellement similaires, mais vous pouvez aussi vouloir filtrer par fourchette de prix, marque, disponibilité ou évaluations des clients. Sans filtrage, vous seriez confronté à un vaste éventail de produits similaires, ce qui rendrait difficile de trouver exactement ce que vous cherchez.

Le filtrage permet un contrôle précis des résultats de la recherche, garantissant que les éléments récupérés ne sont pas seulement alignés sur le plan sémantique, mais qu'ils répondent également à toutes les exigences nécessaires. L'expérience de recherche est ainsi beaucoup plus précise, efficace et conviviale.

C'est là qu'Elasticsearch et Apache Lucene excellent - l'utilisation d'un filtrage efficace sur différents types de données est l'une des principales différences avec les autres bases de données vectorielles.

Filtrage pour la recherche vectorielle exacte

Il existe deux manières principales d'effectuer des recherches de vecteurs exacts :

• Utilisation d'un type d'index flat pour votre champ dense_vector. Ainsi, les recherches sur knn utilisent la recherche exacte au lieu de la recherche approximative.

• Utilisation d'une requête script_score qui utilise des fonctions vectorielles pour calculer le score. Ceci peut être utilisé avec n'importe quel type d'index.

Lors de l'exécution d'une recherche vectorielle exacte, tous les vecteurs sont comparés à la requête. Dans ce cas, le filtrage améliore les performances, car seuls les vecteurs qui passent le filtre doivent être comparés.

Cela n'a pas d'incidence sur la qualité du résultat, car tous les vecteurs sont pris en compte de toute façon. Nous filtrons simplement à l'avance les résultats qui ne sont pas intéressants, afin de réduire le nombre d'opérations.

C'est très important, car il peut être plus performant d'exécuter une recherche exacte plutôt qu'une recherche approximative lorsque les filtres appliqués donnent un petit nombre de documents.

La règle de base est d'utiliser la recherche exacte lorsque moins de 10 000 documents passent le filtre. Les index BBQ sont beaucoup plus rapides pour les comparaisons, il est donc logique d'utiliser la recherche exacte lorsque les index basés sont inférieurs à 100k. Consultez cet article de blog pour plus de détails.

Si vos filtres sont toujours très restrictifs, vous pouvez envisager une indexation axée sur la recherche exacte plutôt que sur la recherche approximative en utilisant un type d'index flat plutôt qu'un index basé sur HNSW. Pour plus de détails, voir les propriétés de index_options.

Filtrage pour la recherche vectorielle approximative

Lors de l'exécution d'une recherche vectorielle approximative, nous échangeons la précision des résultats contre la performance. Les structures de données de recherche vectorielle telles que HNSW recherchent efficacement les voisins les plus proches sur des millions de vecteurs. Ils se concentrent sur la récupération des vecteurs les plus similaires en effectuant le moins possible de comparaisons de vecteurs, qui sont coûteuses à calculer.

Cela signifie que les autres attributs de filtrage ne font pas partie des données vectorielles. Les différents types de données ont leurs propres structures d'indexation qui sont efficaces pour les trouver et les filtrer, comme les dictionnaires de termes, les listes d'écritures et les valeurs doc.

Étant donné que ces structures de données sont distinctes du mécanisme de recherche vectorielle, comment appliquer le filtrage à la recherche vectorielle ? Il existe deux options : appliquer les filtres après la recherche vectorielle (post-filtrage) ou avant la recherche vectorielle (préfiltrage).

Chacune de ces options présente des avantages et des inconvénients. Voyons cela de plus près !

Post-filtrage

Le post-filtrage applique des filtres après que la recherche vectorielle a été effectuée. Cela signifie que les filtres sont appliqués après que les k résultats vectoriels les plus similaires ont été trouvés.

Il est évident que nous pouvons potentiellement obtenir moins de k résultats après avoir appliqué les filtres aux résultats. Nous pourrions bien sûr obtenir plus de résultats à partir de la recherche vectorielle (valeur k plus élevée), mais nous ne serons pas sûrs d'obtenir k ou plus après avoir appliqué les filtres.

L'avantage du post-filtrage est qu'il ne modifie pas le comportement de la recherche vectorielle lors de l'exécution - la recherche vectorielle n'est pas consciente du filtrage. En revanche, il modifie le nombre final de résultats obtenus.

Voici un exemple de post-filtrage à l'aide de la requête knn. Vérifier que la clause de filtrage est distincte de la requête knn :

Le post-filtrage est également disponible pour la recherche knn en utilisant le post-filtre:

Gardez à l'esprit que vous devez utiliser une section de post-filtrage explicite avec la recherche knn. Si vous n'utilisez pas de post-filtre, la recherche knn combinera les résultats des plus proches voisins avec d'autres requêtes ou filtres au lieu d'effectuer un post-filtre.

Préfiltrage

L'application de filtres avant la recherche vectorielle permet d'abord d'extraire les documents qui satisfont aux filtres, puis de transmettre ces informations à la recherche vectorielle.

Lucene utilise les BitSets pour stocker efficacement les documents qui satisfont aux conditions du filtre. La recherche vectorielle parcourt ensuite le graphe HNSW en tenant compte des documents qui satisfont à la condition. Avant d'ajouter un candidat aux résultats, il vérifie qu'il est contenu dans le BitSet des documents valides.

Cependant, le candidat doit être exploré et comparé à la requête, même s'il ne s'agit pas d'un document valide. L'efficacité de HNSW repose sur la connexion entre les vecteurs du graphe : si nous cessons d'explorer un candidat, cela signifie que nous risquons d'ignorer également ses voisins.

Imaginez que vous conduisiez pour vous rendre à une station-service. Si vous écartez les routes qui ne comportent pas de station-service, il est peu probable que vous arriviez à destination. Les autres routes ne sont peut-être pas celles dont vous avez besoin, mais elles vous relient à votre destination. Idem pour les vecteurs sur un graphique HNSW !

Il s'ensuit que l'application d'un préfiltrage est moins performante que la non-application de filtres. Nous devons effectuer le travail sur tous les vecteurs que nous visitons dans notre recherche, et nous devons rejeter ceux qui ne correspondent pas au filtre. Nous travaillons davantage et prenons plus de temps pour obtenir nos meilleurs résultats.

Voici un exemple de préfiltrage dans le DSL de requête Elasticsearch. Vérifiez que la clause de filtrage fait désormais partie de la section knn :

Le préfiltrage est disponible à la fois pour la recherche knn et la requête knn:

Optimisation du préfiltrage

Il existe quelques optimisations que nous pouvons appliquer pour garantir la performance du préfiltrage.

Nous pouvons passer à la recherche exacte si le filtre est très restrictif. Lorsqu'il y a peu de vecteurs à comparer, il est plus rapide d'effectuer une recherche exacte sur les quelques documents qui satisfont le filtre.

Il s'agit d'une optimisation appliquée automatiquement dans Lucene et Elasticsearch.

Une autre méthode d'optimisation consiste à ignorer les vecteurs qui ne satisfont pas au filtre. Au lieu de cela, cette méthode vérifie les voisins des vecteurs filtrés qui passent le filtre. Cette approche réduit effectivement le nombre de comparaisons puisque les vecteurs filtrés ne sont pas pris en compte, et continue d'explorer les vecteurs connectés au chemin actuel.

Cet algorithme est ACORN-1, et le processus est décrit en détail dans ce billet de blog.

Filtrage à l'aide de la sécurité au niveau du document

Document Level Security (DLS) est une fonctionnalité d'Elasticsearch qui spécifie les documents que les rôles d'utilisateurs peuvent récupérer.

La DLS est réalisée à l'aide de requêtes. Une requête peut être associée aux index pour un rôle, ce qui limite effectivement les documents qu'un utilisateur appartenant à ce rôle peut extraire des index.

L'interrogation sur le rôle est utilisée comme filtre pour extraire les documents qui y correspondent et qui sont mis en cache sous la forme d'un ensemble de bits. Ce BitSet est ensuite utilisé pour envelopper le lecteur Lucene sous-jacent, de sorte que seuls les documents renvoyés par la requête sont considérés comme vivants, c'est-à-direqu'ils existent dans l'index et n'ont pas été supprimés.

Étant donné que les documents sont extraits du lecteur pour effectuer la requête knn, seuls les documents disponibles pour l'utilisateur seront pris en compte. S'il existe un préfiltre, les documents DLS y seront ajoutés.

Cela signifie que le filtrage DLS fonctionne comme un préfiltre pour la recherche vectorielle approximative, avec les mêmes implications en termes de performances et d'optimisations.

Le DLS avec recherche exacte présente les mêmes avantages que l'application de n'importe quel filtre - moins il y a de documents extraits du DLS, plus la recherche exacte est performante. Tenez également compte du nombre de documents renvoyés par le DLS - si les rôles du DLS sont très restrictifs, vous pouvez envisager d'utiliser la recherche exacte au lieu de la recherche approximative.

Analyse comparative

Chez Elasticsearch, nous voulons nous assurer que le filtrage de la recherche vectorielle est efficace. Nous disposons d'un benchmark spécifique pour le filtrage vectoriel qui effectue des recherches vectorielles approximatives avec différents filtrages afin de s'assurer que la recherche vectorielle continue à récupérer des résultats pertinents aussi rapidement que possible.

Vérifiez les améliorations apportées lors de l'introduction d'ACORN-1. Pour les tests où seuls 2% des vecteurs passent le filtre, le temps de latence des requêtes est réduit à 55% de la durée initiale :

Conclusion

Le filtrage fait partie intégrante de la recherche. S'assurer que le filtrage est performant dans la recherche vectorielle, et comprendre les compromis et les optimisations, c'est ce qui fait l'efficacité et la précision d'une recherche.

Le filtrage a un impact sur les performances de la recherche vectorielle :

• La recherche exacte est plus rapide lorsque l'on utilise le filtrage. Vous pouvez envisager d'utiliser la recherche exacte au lieu de la recherche approximative si votre filtrage est suffisamment restrictif. Il s'agit d'une optimisation automatique dans Elasticsearch.

• La recherche approximative est plus lente lorsque l'on utilise le préfiltrage. Le préfiltrage nous permet d'obtenir les k premiers résultats correspondant au filtre, au prix d'une recherche plus lente.

• Le post-filtrage ne permet pas nécessairement de retrouver les k premiers résultats, car ils peuvent être filtrés par le filtre lorsqu'il est appliqué.

Bon filtrage !

Vous vous demandez peut-être pourquoi utiliser des graphiques multiples ? Il s'agit d'un effet secondaire d'un choix architectural de Lucene : les segments immuables. Comme pour la plupart des choix architecturaux, il y a des avantages et des inconvénients. Par exemple, nous avons récemment obtenu la certification Serverless Elasticsearch. Dans ce contexte, nous avons tiré des avantages très importants des segments immuables, notamment une réplication efficace de l'index et la possibilité de découpler le calcul de l'index et de la requête et de les faire évoluer indépendamment. Pour la quantification vectorielle, les fusions de segments nous donnent la possibilité de mettre à jour les paramètres pour les adapter aux caractéristiques des données. Dans le même ordre d'idées, nous pensons que la possibilité de mesurer les caractéristiques des données et de revoir les choix d'indexation présente d'autres avantages.

Dans ce billet, nous discuterons du travail que nous avons effectué pour réduire de manière significative la charge de travail liée à la construction de plusieurs graphes HNSW et, en particulier, pour réduire le coût de la fusion des graphes.

Arrière-plan

Afin de maintenir un nombre raisonnable de segments, Lucene vérifie périodiquement s'il doit fusionner des segments. Cela revient à vérifier si le nombre de segments actuel dépasse un nombre de segments cible, qui est déterminé par la taille du segment de base et la politique de fusion. Si le nombre est dépassé, Lucene fusionne les groupes de segments alors que la contrainte n'est pas respectée. Ce processus a été décrit en détail dans d'autres documents.

Lucene choisit de fusionner des segments de taille similaire car cela permet d'obtenir une croissance logarithmique de l'amplification de l'écriture. Dans le cas d'un index vectoriel, l'amplification de l'écriture est le nombre de fois qu'un vecteur sera inséré dans un graphique. Lucene essaiera de fusionner les segments par groupes d'environ 10. Par conséquent, les vecteurs sont insérés dans un graphe environ {10}\left (\frac{n}{n_0}\right )fois, où le nombre de vecteurs de l'index et est le nombre de vecteurs du segment de base attendu. En raison de la croissance logarithmique, l'amplification de l'écriture est à un chiffre, même pour les indices les plus importants. Cependant, le temps total passé à fusionner les graphes est linéairement proportionnel à l'amplification de l'écriture.

Lors de la fusion des graphes HNSW, nous procédons déjà à une petite optimisation : nous conservons le graphe du plus grand segment et y insérons les vecteurs des autres segments. C'est la raison pour laquelle le facteur 9/10 est mentionné ci-dessus. Nous montrons ci-dessous comment nous pouvons faire beaucoup mieux en utilisant les informations de tous les graphiques que nous fusionnons.

Fusion du graphique HNSW

Auparavant, nous retenions le plus grand graphe et insérions des vecteurs provenant des autres en ignorant les graphes qui les contiennent. L'idée clé que nous utilisons ci-dessous est que chaque graphe HNSW que nous écartons contient des informations de proximité importantes sur les vecteurs qu'il contient. Nous aimerions utiliser cette information pour accélérer l'insertion d'au moins une partie des vecteurs.

Nous nous concentrons sur le problème de l'insertion d'un petit graphe dans un graphe plus grand , puisqu'il s'agit d'une opération atomique que nous pouvons utiliser pour construire n'importe quelle politique de fusion.

La stratégie consiste à trouver un sous-ensemble de sommets de l' à insérer dans le grand graphe. Nous utilisons ensuite la connectivité de ces sommets dans le petit graphe pour accélérer l'insertion des sommets restants Dans ce qui suit, nous utilisons et pour désigner les voisins d'un sommet dans le petit et le grand graphe, respectivement. Schématiquement, le processus est le suivant.

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

Nous calculons l'ensemble à l'aide d'une procédure que nous décrivons ci-dessous (ligne 1). Ensuite, nous insérons chaque sommet de dans le grand graphe à l'aide de la procédure d'insertion HNSW standard (ligne 2). Pour chaque sommet que nous n'avons pas inséré, nous trouvons ses voisins que nous avons insérés et leurs voisins dans le grand graphe (lignes 4 et 5). Nous utilisons une procédure FAST-SEARCH-LAYER avec cet ensemble (ligne 6) pour trouver les candidats pour le site SELECT-NEIGHBORS-HEURISTIC de l'article HNSW (ligne 7). En fait, nous remplaçons SEARCH-LAYER pour trouver l'ensemble de candidats dans la méthode INSERT (Algorithme 1 de l'article), qui est par ailleurs inchangée. Enfin, nous ajoutons le sommet que nous venons d'insérer dans (ligne 8).

Il est clair que pour que cela fonctionne, chaque sommet dans doit avoir au moins un voisin dans En fait, nous exigeons que pour chaque sommet dans que pour quelque M, la connectivité maximale de la couche. Nous observons que dans les graphes HNSW réels, les degrés des sommets sont assez variés. La figure ci-dessous montre une fonction de densité cumulative typique du degré de sommet pour la couche inférieure d'un graphique Lucene HNSW.

Nous avons étudié la possibilité d'utiliser une valeur fixe pour et de la faire dépendre du degré du sommet. Ce deuxième choix conduit à des accélérations plus importantes avec un impact minimal sur la qualité du graphe, nous avons donc opté pour ce qui suit

Notez que | est égal au degré du sommet dans le petit graphe par définition. Le fait d'avoir une limite inférieure de deux signifie que nous insérerons tous les sommets dont le degré est inférieur à deux.

Un simple argument de comptage suggère que si nous choisissons avec soin, il nous suffit d'insérer directement dans Plus précisément, nous colorons une arête du graphe si nous insérons exactement l'un de ses sommets d'extrémité dans Nous savons alors que pour que chaque sommet de ait au moins voisins dans , nous devons colorer au moins \sum_ arêtes. En outre, nous nous attendons à ce que

Ici, \mathbb [N_s(U)|\right] est le degré moyen des sommets dans le petit graphe. Pour chaque sommet , nous colorons au plus arêtes. Par conséquent, le nombre total d'arêtes que nous prévoyons de colorer est au maximum de _U\left [|N_s(U)|\right]. Nous espérons qu'en choisissant avec soin, nous colorerons un nombre d'arêtes proche de ce nombre et donc, pour couvrir tous les sommets, doit satisfaire à

Ceci implique que {1}{4}|V_s|=\frac{1}{5}|V_s|.

Si SEARCH-LAYER domine le temps d'exécution, cela signifie que nous pourrions accélérer le temps de fusion jusqu'à Compte tenu de la croissance logarithmique de l'amplification de l'écriture, cela signifie que même pour de très grands indices, nous ne ferions que doubler le temps de construction par rapport à la construction d'un seul graphique.

Le risque de cette stratégie est de nuire à la qualité du graphique. Nous avons d'abord essayé avec une version sans option FAST-SEARCH-LAYER. Nous avons constaté que cela dégradait la qualité des graphes dans la mesure où le rappel en fonction de la latence était affecté, en particulier lors de la fusion en un seul segment. Nous avons ensuite exploré diverses alternatives en effectuant une recherche limitée dans le graphique. Finalement, le choix le plus efficace a été le plus simple. Utilisez SEARCH-LAYER mais avec une faible ef_construction. Ce paramétrage nous a permis d'obtenir des graphes d'excellente qualité tout en réduisant le temps de fusion d'un peu plus de 30% en moyenne.

Calcul de l'ensemble de jonction

La recherche d'un bon ensemble de jointures peut être formulée comme un problème de couverture de graphe HNSW. Une heuristique gourmande est une heuristique simple et efficace pour approximer les couvertures optimales des graphes. L'approche que nous adoptons consiste à sélectionner les sommets un par un pour les ajouter à dans l'ordre décroissant des gains. Le gain est défini comme suit :

Ici, représente le nombre de voisins d'un vecteur dans et est la fonction indicatrice. Le gain comprend la variation du nombre de sommets que nous avons ajoutés à , c'est-à-dire \max , puisque nous nous rapprochons de notre objectif en ajoutant un sommet moins couvert. Le calcul du gain est illustré dans la figure ci-dessous pour le sommet central orange.

Nous conservons l'état suivant pour chaque sommet

1. S'il est périmé,

2. Son gain ,

3. Le nombre de sommets adjacents dans est noté

4. Un nombre aléatoire dans l'intervalle [0,1] qui est utilisé pour départager les ex-aequo.

Le pseudo-code pour le calcul de l'ensemble de jonction est le suivant.

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

Nous commençons par initialiser l'état dans les lignes 1 à 5.

À chaque itération de la boucle principale, nous extrayons d'abord le sommet de gain maximal (ligne 8), en brisant les égalités de manière aléatoire. Avant de procéder à toute modification, nous devons vérifier si le gain du sommet est périmé. En particulier, chaque fois que nous ajoutons un sommet à , nous affectons le gain d'autres sommets :

1. Puisque tous ses voisins ont un voisin supplémentaire en , leurs gains peuvent changer (ligne 14)

2. Si l'un de ses voisins est maintenant entièrement couvert, tous les gains de ses voisins peuvent changer (lignes 14-16).

Nous recalculons les gains paresseusement, c'est-à-dire que nous ne recalculons le gain d'un sommet que si nous voulons l'insérer dans (lignes 18-20). Puisque les gains ne font que diminuer, nous ne pouvons jamais manquer un sommet que nous devrions insérer.

Notez que nous avons simplement besoin de suivre le gain total de sommets que nous avons ajoutés à pour déterminer quand sortir. En outre, pendant que {exit}au moins un sommet aura un gain non nul, de sorte que nous progressons toujours.

Résultats

Nous avons mené des expériences sur quatre ensembles de données qui, ensemble, couvrent les trois mesures de distance prises en charge (Euclidean, cosinus et produit intérieur) :

1. quora-E5-small : 522931 documents, 384 dimensions et utilise la similarité cosinus,

2. cohere-wikipedia-v2 : 1M documents, 768 dimensions et utilise la similarité cosinus,

3. gist : 1M documents, 960 dimensions et utilise la distance euclidienne, et

4. cohere-wikipedia-v3 : 1M documents, 1024 dimensions et utilise le produit intérieur maximum.

Pour chaque ensemble de données, nous évaluons deux niveaux de quantification :

1. int8 - qui utilise un entier de 1 octet par dimension et

2. BBQ - qui utilise un seul bit par dimension.

Enfin, pour chaque expérience, nous avons évalué la qualité de la recherche à deux profondeurs d'extraction et nous l'avons examinée après la construction de l'index, puis après la fusion forcée en un seul segment.

En résumé, nous obtenons des accélérations substantielles et constantes dans l'indexation et la fusion tout en maintenant la qualité du graphe et donc les performances de recherche dans tous les cas.

Expérience 1 : quantification int8

Les gains de vitesse moyens entre la ligne de base et le candidat, les changements proposés, sont les suivants :

Accélération du temps d'indexation : 1,fois

Accélération de la fusion forcée : 1,fois

Cela correspond à la répartition suivante des durées d'exécution

Par souci d'exhaustivité, les horaires exacts sont les suivants

Index

Fusionner

Ensemble de données

ligne de base

candidat

Développer

candidat

quora-E5-petit

112.41s

81.55s

113.81s

70.87s

wiki-cohere-v2

158.1s

122.95s

425.20s

239.28s

liste

141.82s

119.26s

536.07s

279.05s

wiki-cohere-v3

211.86s

168.22s

654.97s

414.12s

Nous présentons ci-dessous les graphiques de rappel et de latence qui comparent le candidat (lignes pointillées) à la ligne de base à deux profondeurs de recherche : rappel@10 et rappel@100 pour les index avec plusieurs segments (le résultat final de notre stratégie de fusion par défaut après l'indexation de tous les vecteurs) et après la fusion forcée à un seul segment. Une courbe plus haute et plus à gauche est meilleure, ce qui signifie une meilleure mémorisation avec une latence plus faible.

Comme vous pouvez le constater, pour les indices de segments multiples, le candidat est meilleur pour l'ensemble de données Cohere v3 et légèrement moins bon, mais presque comparable, pour tous les autres ensembles de données. Après la fusion en un seul segment, les courbes de rappel sont presque identiques dans tous les cas.

Expérience 2 : Quantification BBQ

Les gains de vitesse moyens entre la ligne de base et le candidat sont les suivants :

Accélération du temps d'indexation : 1,fois

Accélération de la fusion forcée : 1,fois

Cela correspond à la répartition suivante des durées d'exécution

Par souci d'exhaustivité, les horaires exacts sont les suivants

Index

Fusionner

Ensemble de données

ligne de base

candidat

Développer

candidat

quora-E5-petit

70.71s

58.25s

59.38s

40.15s

wiki-cohere-v2

203.08s

142.27s

107.27s

85.68s

liste

110.35s

105.52s

323.66s

202.2s

wiki-cohere-v3

313.43s

190.63s

165.98s

159.95s

Pour les indices de segments multiples, le candidat est meilleur pour presque tous les ensembles de données, à l'exception de cohere v2 où la ligne de base est légèrement meilleure. Pour les indices de segment unique, les courbes de rappel sont presque identiques dans tous les cas.

Conclusion

L'algorithme présenté dans ce blog sera disponible dans la prochaine version de Lucene 10.2, ainsi que dans la version d'Elasticsearch qui est basée sur cette dernière. Les utilisateurs pourront profiter de l'amélioration des performances de fusion et de la réduction du temps de construction de l'index dans ces nouvelles versions. Ce changement fait partie de nos efforts continus pour rendre Lucene et Elasticsearch rapides et efficaces pour la recherche vectorielle et hybride.

Le débogage des bogues de concurrence n'est pas une sinécure, mais nous allons nous y atteler. C'est là qu'intervient Fray, un cadre de test de concurrence déterministe du laboratoire PASTA de l'Université de Californie du Sud, qui transforme les défaillances en défaillances reproductibles de manière fiable. Grâce à la conception astucieuse du shadow lock de Fray et au contrôle précis des threads, nous avons traqué un bug Lucene délicat et l'avons finalement éliminé. Ce billet explore la façon dont les héros et les outils open-source rendent le débogage de la concurrence moins pénible et le monde du logiciel bien meilleur.

Les bogues de simultanéité : le fléau des ingénieurs en informatique

Les bogues liés à la concomitance sont les pires. Non seulement ils sont difficiles à réparer, mais le plus difficile est de les faire tomber en panne de manière fiable. Prenons l'exemple de l'échec de ce test, TestIDVersionPostingsFormat#testGlobalVersions. Il génère plusieurs fils d'écriture et de mise à jour de documents, ce qui remet en cause le modèle de concurrence optimiste de Lucene. Ce test a mis en évidence une condition de course dans le contrôle optimiste de la concurrence. En d'autres termes, une opération de document peut faussement prétendre être la dernière d'une séquence d'opérations 😱. Cela signifie que, dans certaines conditions, une opération de mise à jour ou de suppression peut réussir alors qu'elle aurait dû échouer compte tenu des contraintes de concurrence optimistes.

Toutes nos excuses à ceux qui détestent les traces de pile Java. Remarque : supprimer ne signifie pas nécessairement "effacer". Il peut également indiquer une "mise à jour" du document, car les segments de Lucene sont en lecture seule.

Apache Lucene gère chaque thread qui écrit des documents par l'intermédiaire de la classe DocumentsWriter. Cette classe crée ou réutilise des fils de discussion pour l'écriture de documents et chaque action d'écriture contrôle ses informations dans la classe DocumentsWriterPerThread (DWPT). En outre, le rédacteur garde la trace des documents supprimés dans le site DocumentsWriterDeleteQueue (DWDQ). Ces structures conservent en mémoire toutes les actions de mutation des documents et se vident périodiquement, libérant ainsi les ressources en mémoire et transférant les structures sur le disque.

Afin d'éviter le blocage des threads et d'assurer un débit élevé dans les systèmes concurrents, Apache Lucene tente de ne se synchroniser que dans les sections très critiques. Bien que cela puisse être une bonne chose dans la pratique, comme dans tous les systèmes concurrents, il y a des dragons.

Un faux espoir

Mon enquête initiale m'a permis d'identifier quelques sections critiques qui n'étaient pas correctement synchronisées. Toutes les interactions avec un site DocumentsWriterDeleteQueue donné sont contrôlées par le site DocumentsWriter qui l'entoure. Ainsi, même si les méthodes individuelles ne sont pas synchronisées de manière appropriée sur le site DocumentsWriterDeleteQueue, leur accès au monde l'est (ou devrait l'être). (Ne nous attardons pas sur la confusion entre propriété et accès - il s'agit d'un projet de longue date rédigé par de nombreux contributeurs. Laissez-lui un peu de répit.)

Cependant, j'ai trouvé un endroit qui n'était pas synchronisé lors d'un rinçage.

Ces actions ne sont pas synchronisées en une seule opération atomique. Cela signifie qu'entre la création de newQueue et l'appel de getMaxSeqNo, un autre code a pu être exécuté, incrémentant le numéro de séquence dans la classe documentsWriter. J'ai trouvé l'insecte !

Mais, comme pour la plupart des bogues complexes, il n'a pas été facile de trouver la cause première. C'est alors qu'un héros est intervenu.

Un héros dans la mêlée

Voici notre héros : Ao Li et ses collègues du laboratoire PASTA. Je le laisserai expliquer comment ils ont sauvé la situation avec Fray.

Fray est un cadre de test de concurrence déterministe développé par des chercheurs du PASTA Lab de l'Université Carnegie Mellon. La motivation derrière la création de Fray provient d'un écart notable entre le monde universitaire et l'industrie : alors que les tests déterministes de concurrence ont été largement étudiés dans la recherche universitaire depuis plus de 20 ans, les praticiens continuent de s'appuyer sur les tests de stress - une méthode largement reconnue comme peu fiable et peu fiable - pour tester leurs programmes simultanés. C'est pourquoi nous avons voulu concevoir et mettre en œuvre un cadre de test de concurrence déterministe dont l'objectif principal est la généralité et l'applicabilité pratique.

L'idée maîtresse

Fray s'appuie sur un principe simple mais puissant : l'exécution séquentielle. Le modèle de concurrence de Java offre une propriétéessentielle: si un programme est exempt de course aux données, toutes les exécutions sembleront cohérentes d'un point de vue séquentiel. Cela signifie que le comportement du programme peut être représenté comme une séquence d'instructions.

Fray exécute le programme cible de manière séquentielle : à chaque étape, il met en pause tous les threads sauf un, ce qui permet à Fray de contrôler précisément l'ordonnancement des threads. Les fils sont sélectionnés au hasard pour simuler la concurrence, mais les choix sont enregistrés en vue d'une relecture déterministe ultérieure. Pour optimiser l'exécution, Fray n'effectue des changements de contexte que lorsqu'un thread est sur le point d'exécuter une instruction de synchronisation telle que le verrouillage ou l'accès atomique/volatile. Une propriété intéressante de la liberté de la course aux données est que ce changement de contexte limité est suffisant pour explorer tous les comportements observables dus à l'entrelacement des threads(notre article contient une esquisse de preuve).

Le défi : contrôler l'ordonnancement des threads

Bien que l'idée de base semble simple, la mise en œuvre de Fray a présenté des défis importants. Pour contrôler l'ordonnancement des threads, Fray doit gérer l'exécution de chaque thread d'application. À première vue, cela peut sembler simple : remplacer les primitives de concurrence par des implémentations personnalisées. Cependant, le contrôle de la concurrence dans la JVM est complexe et implique un mélange d'instructions de bytecode, de bibliothèques de haut niveau et de méthodes natives.

Il s'est avéré qu'il s'agissait d'un trou de lapin :

• Par exemple, chaque instruction MONITORENTER doit avoir un correspondant MONITOREXIT dans la même méthode. Si Fray remplace MONITORENTER par un appel de méthode à un stub/mock, il doit également remplacer MONITOREXIT.

• Dans le code qui utilise object.wait/notify, si MONITORENTER est remplacé, le object.wait correspondant doit également être remplacé. Cette chaîne de remplacement s'étend jusqu'à object.notify et au-delà.

• La JVM invoque certaines méthodes liées à la concurrence (par exemple, object.notify lorsqu'un thread se termine) dans le code natif. Le remplacement de ces opérations nécessiterait de modifier la JVM elle-même.

• Les fonctions de la JVM, telles que les chargeurs de classes et les threads de collecte de déchets (GC), utilisent également des primitives de concurrence. La modification de ces primitives peut créer des incohérences avec ces fonctions de la JVM.

• Le remplacement des primitives de concurrence dans le JDK entraîne souvent des plantages de la JVM pendant sa phase d'initialisation.

Ces défis ont clairement montré qu'un remplacement complet des primitives de concurrence n'était pas réalisable.

Notre solution : la conception d'une serrure à l'abri des regards

Pour relever ces défis, Fray utilise un nouveau mécanisme de verrouillage fictif pour orchestrer l'exécution des threads sans remplacer les primitives de concurrence. Les Shadow locks agissent comme des intermédiaires qui guident l'exécution des threads. Par exemple, avant d'acquérir un verrou, un thread d'application doit interagir avec le verrou fantôme correspondant. Le verrou fantôme détermine si le thread peut acquérir le verrou. Si le thread ne peut pas continuer, le verrou fantôme le bloque et permet à d'autres threads de s'exécuter, ce qui évite les blocages et permet une concurrence contrôlée. Cette conception permet à Fray de contrôler l'entrelacement des threads de manière transparente tout en préservant l'exactitude de la sémantique de la concurrence. Chaque primitive de concurrence est soigneusement modélisée dans le cadre du verrouillage fictif afin d'en garantir la solidité et l'exhaustivité. Plus de détails techniques peuvent être trouvés dans notre document.

En outre, cette conception est conçue pour être à l'épreuve du temps. En n'exigeant que l'instrumentation des verrous fantômes autour des primitives de concurrence, il garantit la compatibilité avec les versions plus récentes de la JVM. Cela est possible parce que les interfaces des primitives de concurrence dans la JVM sont relativement stables et sont restées inchangées depuis des années.

Test Fray

Après la construction de Fray, l'étape suivante a été l'évaluation. Heureusement, de nombreuses applications, comme Apache Lucene, intègrent déjà des tests de concurrence. Ces tests de concurrence sont des tests JUnit classiques qui génèrent plusieurs threads, effectuent un certain travail, attendent (généralement) que ces threads se terminent, puis affirment une certaine propriété. La plupart du temps, ces tests réussissent parce qu'ils n'exercent qu'un seul entrelacement. Pire encore, certains tests n'échouent qu'occasionnellement dans l'environnement CI/CD, comme décrit précédemment, ce qui rend ces échecs extrêmement difficiles à déboguer. Lorsque nous avons exécuté les mêmes tests avec Fray, nous avons découvert de nombreux bogues. Notamment, Fray a redécouvert des bogues précédemment signalés qui n'avaient pas été corrigés en raison de l'absence d'une reproduction fiable, y compris l'objet de ce blog : TestIDVersionPostingsFormat.testGlobalVersions. Heureusement, avec Fray, nous pouvons les rejouer de manière déterministe et fournir aux développeurs des informations détaillées, ce qui leur permet de reproduire et de résoudre le problème de manière fiable.

Prochaines étapes pour Fray

Nous sommes ravis d'entendre les développeurs d'Elastic dire que Fray a été utile pour déboguer les bogues de concurrence. Nous continuerons à travailler sur Fray afin de le rendre accessible à un plus grand nombre de développeurs.

Nos objectifs à court terme sont d'améliorer la capacité de Fray à rejouer le programme de manière déterministe, même en présence d'autres opérations non déterministes telles qu'un générateur de valeurs aléatoires ou l'utilisation de object.hashcode. Nous visons également à améliorer la facilité d'utilisation de Fray, en permettant aux développeurs d'analyser et de déboguer les tests de concurrence existants sans aucune intervention manuelle. Plus important encore, si vous rencontrez des difficultés pour déboguer ou tester les problèmes de concurrence dans votre programme, nous aimerions avoir de vos nouvelles. N'hésitez pas à créer un problème dans le dépôt Github de Fray.

Il est temps de corriger le bogue de la concurrence

Grâce à Ao Li et au laboratoire PASTA, nous disposons désormais d'une instance de ce test qui échoue de manière fiable ! Nous pouvons enfin réparer cette chose. Le principal problème réside dans la manière dont DocumentsWriterPerThreadPool permet la réutilisation des fils et des ressources.

Ici, nous pouvons voir la création de chaque thread, qui fait référence à la file d'attente de suppression initiale de la génération 0.

Ensuite, l'avance dans la file d'attente se produira au moment de l'effacement, en voyant correctement les 7 actions précédentes dans la file d'attente.

Mais avant que tous les fils ne puissent finir de se vider, deux d'entre eux sont réutilisés pour un document supplémentaire :

Ces derniers incrémenteront alors le site seqNo au-delà du maximum supposé, qui a été calculé lors de la chasse d'eau comme étant 7. Notez le site supplémentaire numDocsInRAM pour les segments _3 et _0

Lucene tient donc compte de manière incorrecte de la séquence d'actions des documents au cours d'une vidange et déclenche l'échec de ce test.

Comme toutes les bonnes corrections de bogues, la correction proprement dite se résume à une dizaine de lignes de code. Mais il a fallu plusieurs jours à deux ingénieurs pour trouver la solution :

Tous les héros ne portent pas de capes

Oui, c'est un cliché, mais c'est vrai.

Le débogage de programmes simultanés est extrêmement important. Ces bogues de concurrence délicats prennent un temps fou à déboguer et à résoudre. Bien que les nouveaux langages comme Rust intègrent des mécanismes permettant d'éviter de telles conditions de course, la majorité des logiciels dans le monde sont déjà écrits, et écrits dans un autre langage que Rust. Java, même après toutes ces années, reste l'un des langages les plus utilisés. L'amélioration du débogage sur les langages basés sur la JVM permet d'améliorer le monde du génie logiciel. Et étant donné que certains pensent que le code sera écrit par de grands modèles de langage, peut-être que notre travail d'ingénieur consistera finalement à déboguer du mauvais code LLM au lieu de notre propre mauvais code. Mais quel que soit l'avenir du génie logiciel, le débogage simultané des programmes restera essentiel pour la maintenance et la création de logiciels.

Merci à Ao Li et à ses collègues du laboratoire PASTA de l'avoir rendu encore meilleur.

Lucene & la communauté

La force d'un projet dépend de la communauté qui le soutient. Malgré plus de 20 ans de développement, le projet Lucene reste dynamique et prospère grâce à ses contributeurs passionnés et actifs.

En 2024, le projet Lucene a fait l'objet de plus de 2 000 modifications de la part de 98 contributeurs uniques, et de près de 800 demandes de modification. Le nombre de contributeurs continue de croître, avec de nouveaux committers et membres du PMC qui rejoignent le projet et contribuent à son succès.

Lucene 10

2024 a vu la première version majeure depuis près de 3 ans - Lucene 10, avec plus de 2 000 commits de 185 contributeurs uniques. Si le modèle de développement suivi par Lucene permet d'apporter de nombreuses améliorations et fonctionnalités dans des versions mineures, une version majeure offre la possibilité d'apporter des fonctionnalités plus importantes et des modernisations. Par exemple, Lucene 10 nécessite au minimum Java 21. L'augmentation de la version minimale de Java permet à Lucene de continuer à bénéficier des améliorations apportées par la version moderne de Java.

L'objectif principal de Lucene 10 est de mieux utiliser le matériel sur lequel il fonctionne. Jetons un coup d'œil rapide sur les principaux faits marquants :

• Plus de parallélisme dans les recherches - alors que l'exécution des recherches est déjà parallélisée entre les segments, nous allons maintenant plus loin, en parallélisant à l'intérieur des segments. Cela permet de dissocier la représentation sur disque des performances d'exécution, ce qui permet même à des segments uniques de bénéficier du nombre de cœurs des systèmes modernes.

• Meilleur parallélisme des E/S - le modèle d'E/S synchrone simple utilisé par Lucene a été amélioré grâce à une étape de préfixation. Cela permet d'informer le système d'exploitation qu'une région d'un fichier d'index sera nécessaire dans un avenir très proche, sans pour autant bloquer le thread appelant.

• Meilleure efficacité de l'unité centrale et du stockage grâce à l'indexation épar se - Lucene 10 introduit la prise en charge de l'indexation éparse, parfois appelée indexation par clé primaire ou indexation par zone dans d'autres magasins de données.

Pour plus d'informations sur Lucene 10, consultez l'article dédié à Lucene 10.

Recherche et innovation dans le domaine de Lucene

En 2024, Lucene a connu un essor de la recherche et de l'innovation, en particulier dans les domaines de l'intégration de l'apprentissage automatique, de la recherche vectorielle et de l'optimisation pour les ensembles de données à grande échelle, avec des références à 10 articles et publications de recherche distincts. Voici quelques-uns des principaux domaines de recherche et développements :

• Recherche vectorielle et prise en charge de l'intégration - Lucene offre une solution puissante et évolutive pour la recherche vectorielle, permettant la recherche sémantique à grande échelle. En tirant parti de la solide infrastructure d'indexation et de recherche de Lucene, les utilisateurs peuvent combiner le meilleur de la recherche textuelle traditionnelle avec les capacités avancées de la recherche vectorielle moderne, ce qui fait de Lucene une solution complète pour un large éventail de tâches de recherche et d'extraction d'informations.

• Modèles de recherche hybrides - La recherche s'est également penchée sur les techniques de recherche hybrides, Lucene combinant la recherche traditionnelle par mot-clé et la recherche moderne par vecteur. En fusionnant des index basés sur des termes avec des représentations vectorielles denses, Lucene peut fournir des résultats de recherche plus précis et plus pertinents sur le plan contextuel, comblant ainsi le fossé entre la précision des moteurs de recherche traditionnels et la flexibilité de la recherche sémantique.

Les efforts de recherche en cours en 2024 démontrent la capacité d'adaptation de Lucene à l'évolution des besoins des technologies de recherche modernes, en particulier dans le contexte de l'IA, de la recherche sémantique et des applications de big data. Le projet continue de se développer en tant que plateforme puissante, flexible et efficace pour les cas d'utilisation de la recherche traditionnelle et de pointe.

2024 versions de Lucene

Bien qu'il ne s'agisse pas d'un reflet exact, le simple volume des publications met en évidence le dévouement et l'énergie constants de la communauté. Ces mises à jour comprennent des améliorations majeures des performances et de l'efficacité de la recherche vectorielle, la prise en charge de madvise, des optimisations pour le décodage des listes d'écritures, des améliorations supplémentaires de la vitesse grâce à SIMD, et bien d'autres choses encore.

Voici la liste complète des sorties :

• 10.1.0 (2024-12-20)

• 9.12.1 (2024-12-13)

• 10.0.0 (2024-10-14)

• 9.12.0 (2024-09-28)

• 8.11.4 (2024-09-24)

• 9.11.1 (2024-06-27)

• 9.11.0 (2024-06-06)

• 9.10.0 (2024-02-20)

• 8.11.3 (2024-02-08)

• 9.9.2 (2024-01-29)

Vous pouvez trouver plus d'informations et les notes de version sur la page Lucene Core. En outre, il existe des versions équivalentes de PyLucene.

Conclusion

Alors que Lucene arrive à maturité, il continue de prospérer grâce à sa communauté dévouée et dynamique. Comme nous l'avons vu, 2024 a été une année incroyablement productive, et nous nous tournons maintenant vers les développements passionnants que 2025 apportera.

Ce blog est différent des autres. Il ne s'agit pas d'une explication d'une nouvelle fonctionnalité ou d'un tutoriel. Il s'agit d'une simple ligne de code qui a pris trois jours à écrire. Nous allons corriger une corruption potentielle de l'index Apache Lucene. J'espère que vous en tirerez quelques enseignements :

• Tous les tests défectueux sont reproductibles, avec suffisamment de temps et les bons outils.

• Pour que les systèmes soient robustes, il faut qu'il y ait plusieurs niveaux de tests. Cependant, les niveaux de tests plus élevés deviennent de plus en plus difficiles à déboguer et à reproduire.

• Le sommeil est un excellent débogueur

Comment les tests d'Elasticsearch

Chez Elastic, nous avons une pléthore de tests qui s'exécutent sur la base de code Elasticsearch. Certains sont des tests fonctionnels simples et ciblés, d'autres sont des tests d'intégration "happy path" sur un seul nœud, et d'autres encore tentent de casser le cluster pour s'assurer que tout se comporte correctement dans un scénario de défaillance. Lorsqu'un test échoue continuellement, un ingénieur ou un outil d'automatisation crée un problème sur github et le signale à une équipe particulière pour qu'elle l'étudie. Ce bogue particulier a été découvert lors d'un test du dernier type. Ces tests sont délicats et ne peuvent parfois être répétés qu'après de nombreux essais.

Qu'est-ce que ce test teste réellement ?

Ce test particulier est intéressant. Il créera un mappage particulier et l'appliquera à un groupe primaire. Ensuite, lors de la création d'une réplique. La principale différence est que lorsque la réplique tente d'analyser le document, le test injecte une exception, provoquant ainsi l'échec de la récupération d'une manière surprenante (mais attendue).

Tout fonctionnait comme prévu, à un détail près. Lors du nettoyage du test, nous avons validé la cohérence, et c'est là que ce test a rencontré un problème.

Ce test n'a pas donné les résultats escomptés. Lors du contrôle de cohérence, nous vérifions que tous les fichiers de segments Lucene répliqués et primaires sont cohérents. C'est-à-dire non corrompu et entièrement répliqué. Avoir des données partielles ou corrompues est bien pire que d'avoir une défaillance totale. Voici l'effrayante et abrégée trace de pile de l'échec.

D'une manière ou d'une autre, lors de l'échec de la réplication forcée, le shard répliqué a fini par être corrompu ! Permettez-moi d'expliquer la partie essentielle de l'erreur en termes simples.

Lucene est une architecture basée sur les segments, ce qui signifie que chaque segment connaît et gère ses propres fichiers en lecture seule. Ce segment particulier était validé par ses SegmentCoreReaders pour s'assurer que tout était en ordre. Chaque lecteur central contient des métadonnées qui indiquent quels types de champs et de fichiers existent pour un segment donné. Cependant, lors de la validation du Lucene90PointsFormat, certains fichiers attendus manquaient. Avec les segments du fichier _0.cfs, nous attendons un fichier en format point appelé kdi. cfs représente le système de fichiers composés "" dans lequel Lucene combinera parfois tous les types de champs et tous les petits fichiers en un seul fichier plus grand pour une réplication et une utilisation des ressources plus efficaces. En fait, les trois extensions de fichiers de points : kdd, kdi, et kdm manquaient. Comment pouvons-nous arriver au point où un segment Lucene s'attend à trouver un fichier de points mais où il n'y en a pas ! Cela ressemble à un bug de corruption effrayant !

La première étape de la correction d'un bogue est de le reproduire.

La reproduction de l'échec de ce bogue particulier a été extrêmement douloureuse. Bien que nous tirions parti des tests de valeurs aléatoires dans Elasticsearch, nous veillons à fournir à chaque défaillance une graine aléatoire (espérons-le) reproductible afin de garantir que toutes les défaillances peuvent être étudiées. Cela fonctionne très bien pour toutes les défaillances, sauf celles qui sont dues à une condition de course.

Peu importe le nombre de fois que j'ai essayé, la graine en question n'a jamais répété l'échec localement. Mais il existe des moyens d'exercer les tests et de tendre vers un échec plus reproductible.

Notre suite de tests particulière permet d'exécuter un test donné plus d'une fois dans la même commande via le paramètre -Dtests.iters. Mais ce n'était pas suffisant, je devais m'assurer que les fils d'exécution changeaient et augmentaient ainsi la probabilité que cette condition de course se produise. Un autre problème était que le test prenait tellement de temps à s'exécuter que le programme d'exécution du test se mettait en veilleuse. Finalement, j'ai utilisé le cauchemar bash suivant pour exécuter le test de manière répétée :

Le stress fait son apparition. Cela vous permet de lancer rapidement un processus qui mangera les cœurs de l'unité centrale pour le déjeuner. L'envoi aléatoire de spam stress-ng tout en exécutant de nombreuses itérations du test défaillant m'a finalement permis de reproduire l'échec. Un pas de plus. Pour stresser le système, il suffit d'ouvrir une autre fenêtre de terminal et d'exécuter :

Révéler le bogue

Maintenant que l'échec du test révélant le bogue est en grande partie reproductible, il est temps d'essayer d'en trouver la cause. Ce qui rend ce test particulier étrange, c'est que Lucene le lance parce qu'il attend des valeurs de point, mais qu'aucune n'est ajoutée directement par le test. Uniquement les valeurs textuelles. Cela m'a poussé à examiner les changements récents apportés à nos champs de contrôle optimiste de la concurrence: _seq_no et _primary_term. Ces deux éléments sont indexés en tant que points et existent dans chaque document Elasticsearch.

En effet, un commit a modifié notre mappeur _seq_no! OUI ! Cela doit être la cause ! Mais mon excitation a été de courte durée. Cela ne fait que modifier l'ordre dans lequel les champs sont ajoutés au document. Avant cette modification, les champs _seq_no étaient ajoutés en dernier au document. Ensuite, ils ont été ajoutés en premier. Il est impossible que l'ordre d'ajout des champs dans un document Lucene soit à l'origine de cet échec...

Oui, la modification de l'ordre d'ajout des champs est à l'origine de l'échec. Ceci était surprenant et s'avère être un bogue dans Lucene lui-même ! Le fait de modifier l'ordre dans lequel les champs sont analysés ne devrait pas modifier le comportement de l'analyse d'un document.

Le bogue dans Lucene

En effet, le bogue dans Lucene se concentre sur les conditions suivantes :

• Indexation d'un champ de valeurs de points (par ex. _seq_no)

• Essai d'indexation d'un champ de texte lancé lors de l'analyse

• Dans cet état étrange, nous ouvrons un lecteur en temps quasi réel de l'auteur qui fait l'expérience de l'exception d'analyse de l'index du texte.

Mais j'ai eu beau essayer, je n'ai pas réussi à le reproduire entièrement. J'ai directement ajouté des points de pause pour le débogage dans la base de code Lucene. J'ai tenté d'ouvrir des lecteurs de manière aléatoire pendant le parcours d'exception. J'ai même imprimé des mégaoctets et des mégaoctets de journaux en essayant de trouver le chemin exact où cette défaillance s'est produite. Je n'ai pas pu le faire. J'ai passé une journée entière à me battre et à perdre.

Puis j'ai dormi.

Le lendemain, j'ai relu la trace de pile originale et j'ai découvert la ligne suivante :

Dans toutes mes tentatives de recréation, je n'ai jamais défini spécifiquement la politique de fusion de la rétention. La politique SoftDeletesRetentionMergePolicy est utilisée par Elasticsearch pour répliquer avec précision les suppressions dans les répliques et garantir que tous nos contrôles de concurrence sont en charge du moment où les documents sont effectivement supprimés. Dans le cas contraire, Lucene a le contrôle total et les supprimera à chaque fusion.

Une fois que j'ai ajouté cette politique et que j'ai répliqué les étapes les plus élémentaires mentionnées ci-dessus, la panne s'est immédiatement répliquée.

Je n'ai jamais été aussi heureux d'ouvrir un bogue dans Lucene.

Alors qu'il se présentait comme une condition de course dans Elasticsearch, il était simple d'écrire un test échouant de manière répétée dans Lucene une fois que toutes les conditions étaient remplies.

En fin de compte, comme tous les bons bogues, il a été corrigé avec une seule ligne de code. Plusieurs jours de travail pour une seule ligne de code.

Mais cela en valait la peine.

Pas la fin

J'espère que vous avez apprécié cette aventure avec moi ! Écrire des logiciels, en particulier des logiciels aussi répandus et complexes qu'Elasticsearch et Apache Lucene, est gratifiant. Cependant, il est parfois exceptionnellement frustrant. J'aime et je déteste à la fois les logiciels. La correction des bogues n'est jamais terminée !

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.

Bien que HNSW soit un moyen puissant et flexible de stocker et de rechercher des vecteurs, il nécessite une quantité importante de mémoire pour fonctionner rapidement. Par exemple, l'interrogation de 1MM float32 vectors de 768 dimensions nécessite environ de ram. Dès que vous commencez à rechercher un nombre important de vecteurs, cela devient coûteux. La quantification des octets est un moyen d'utiliser environ moins de mémoire. Lucene et, par conséquent, Elasticsearch prennent en charge l'indexation des vecteurs d' depuis un certain temps, mais la construction de ces vecteurs relève de la responsabilité de l'utilisateur. Cela est sur le point de changer, car nous avons introduit la quantification scalaire dans Lucene.

Quantification scalaire 101

Toutes les techniques de quantification sont considérées comme des transformations avec perte des données brutes. Cela signifie que certaines informations sont perdues pour des raisons d'espace. Pour une explication approfondie de la quantification scalaire, voir : Quantification scalaire 101. À un niveau élevé, la quantification scalaire est une technique de compression avec perte. Un simple calcul permet de réaliser des économies d'espace significatives avec très peu d'impact sur le rappel.

Explorer l'architecture

Les personnes habituées à travailler avec Elasticsearch sont peut-être déjà familiarisées avec ces concepts, mais voici un aperçu rapide de la distribution des documents pour la recherche.

Chaque index Elasticsearch est composé de plusieurs tiroirs (shards). Bien que chaque nuage ne puisse être affecté qu'à un seul nœud, plusieurs nuages par index permettent un parallélisme de calcul entre les nœuds.

Chaque tesson est composé d'un seul index Lucene. Un index Lucene se compose de plusieurs segments en lecture seule. Pendant l'indexation, les documents sont mis en mémoire tampon et périodiquement vidés dans un segment en lecture seule. Lorsque certaines conditions sont remplies, ces segments peuvent être fusionnés en arrière-plan en un segment plus large. Tout cela est configurable et comporte son lot de complexités. Mais lorsque nous parlons de segments et de fusion, nous parlons de segments Lucene en lecture seule et de la fusion périodique automatique de ces segments. Voici une analyse plus approfondie de la fusion des segments et des décisions en matière de conception.

Quantification par segment dans Lucene

Chaque segment dans Lucene stocke les éléments suivants : les vecteurs individuels, les indices du graphe HNSW, les vecteurs quantifiés et les quantiles calculés. Par souci de concision, nous nous concentrerons sur la manière dont Lucene stocke les vecteurs quantifiés et bruts. Pour chaque segment, nous conservons la trace des bruts dans le fichier vec, des vecteurs quantifiés et d'un seul multiplicateur correctif dans le ainsi que les métadonnées relatives à la quantification fichier vemq.

Figure 1 : Présentation simplifiée d'un fichier de stockage de vecteurs bruts. Occupe la de l'espace disque puisque les valeurs sont de 4 octets. Étant donné que nous quantifions, ces données ne seront pas chargées lors de la recherche HNSW. Ils ne sont utilisés que sur demande expresse (par ex. secondaire par force brute via le rescore), ou pour la re-quantification lors de la fusion de segments.

Figure 2 : Présentation simplifiée du fichier fichier. Occupe un espace de et sera chargé en mémoire lors de la recherche. Les octets sont destinés à prendre en compte le multiplicateur de correction, utilisé pour ajuster la notation afin d'améliorer la précision et la mémorisation.

Figure 3 : Présentation simplifiée du fichier de métadonnées. C'est ici que nous gardons trace de la quantification et de la configuration du vecteur, ainsi que des quantiles calculés pour ce segment.

Ainsi, pour chaque segment, nous stockons non seulement les vecteurs quantifiés, mais aussi les quantiles utilisés pour créer ces vecteurs quantifiés et les vecteurs bruts originaux. Mais pourquoi conserver les vecteurs bruts ?

Une quantification qui évolue avec vous

Étant donné que Lucene se concentre périodiquement sur les segments en lecture seule, chaque segment n'a qu'une vue partielle de l'ensemble des données. Cela signifie que les quantiles calculés ne s'appliquent directement qu'à cet échantillon de l'ensemble de vos données. Ce n'est pas très grave si votre échantillon représente correctement l'ensemble de votre corpus. Mais Lucene vous permet de trier votre index de différentes manières. Ainsi, vous pourriez indexer des données triées d'une manière qui ajoute un biais pour les calculs de quantile par segment. De plus, vous pouvez effacer les données quand vous le souhaitez ! Votre échantillon peut être minuscule, ne serait-ce qu'un seul vecteur. Un autre avantage est que vous avez le contrôle sur le moment où les fusions ont lieu. Bien qu'Elasticsearch ait configuré des valeurs par défaut et une fusion périodique, vous pouvez demander une fusion quand vous le souhaitez via l'API _force_merge. Alors, comment permettre cette flexibilité tout en assurant une bonne quantification et un bon rappel ?

La quantification vectorielle de Lucene s'adaptera automatiquement au fil du temps. Lucene étant conçu avec une architecture de segments en lecture seule, nous avons la garantie que les données de chaque segment n'ont pas changé et des démarcations claires dans le code pour savoir quand les choses peuvent être mises à jour. Cela signifie que lors de la fusion des segments, nous pouvons ajuster les quantiles si nécessaire et éventuellement ré-équantifier les vecteurs.

Figure 4 : Trois exemples de segments avec différents quantiles.

Mais la requantification n'est-elle pas coûteuse ? Il y a un certain surcoût, mais Lucene gère les quantiles intelligemment et ne les quantifie complètement que lorsque c'est nécessaire. Prenons l'exemple des segments de la figure 4. Donnons aux segments et documents chacun et au segment seulement documents. Lucene prend une moyenne pondérée des quantiles et si le quantile fusionné qui en résulte est suffisamment proche des quantiles originaux du segment, nous n'avons pas besoin de quantifier à nouveau ce segment et nous utiliserons les quantiles nouvellement fusionnés.

Figure 5 : Exemple de quantiles fusionnés lorsque les segments et ont documents et que le segment n'en a que .

Dans la situation représentée à la figure 5, nous pouvons voir que les quantiles fusionnés qui en résultent sont très similaires aux quantiles originaux en et Ils ne justifient donc pas la quantification des vecteurs. Le segment semble s'écarter trop de la réalité. Par conséquent, les vecteurs de seront quantifiés à nouveau avec les valeurs de quantile nouvellement fusionnées.

Il existe en effet des cas extrêmes où les quantiles fusionnés diffèrent considérablement des quantiles initiaux. Dans ce cas, nous prendrons un échantillon de chaque segment et recalculerons entièrement les quantiles.

Performance de quantification & numbers

Est-il rapide et offre-t-il toujours un bon rappel ? Les chiffres suivants ont été recueillis lors de l'exécution de l'expérience sur une instance GCP c3-standard-8. Pour garantir une comparaison équitable avec , nous avons utilisé une instance suffisamment grande pour contenir des vecteurs bruts en mémoire. Nous avons indexé vecteurs Cohere Wiki en utilisant le produit intérieur maximal.

Figure 6 : Rappel@10 pour les vecteurs quantifiés par rapport aux vecteurs bruts. La performance de recherche des vecteurs quantifiés est nettement plus rapide que celle des vecteurs bruts, et le rappel est rapidement récupérable en rassemblant seulement 5 vecteurs supplémentaires ; visible par .

La figure 6 illustre l'histoire. Bien qu'il y ait une différence de rappel, comme on peut s'y attendre, elle n'est pas significative. Et la différence de rappel disparaît en rassemblant seulement 5 vecteurs supplémentaires. Tout cela avec des fusions de segments rapides et 1/4 de la mémoire des vecteurs .

Conclusion

Lucene apporte une solution unique à un problème difficile. La quantification ne nécessite aucune étape de "formation" ou d'"optimisation". Dans Lucene, cela fonctionnera simplement. Il n'y a pas d'inquiétude à avoir quant à la nécessité de "ré-entraîner" votre index vectoriel si vos données changent. Lucene détectera les changements significatifs et s'en chargera automatiquement pendant toute la durée de vie de vos données. Nous attendons avec impatience le moment où nous intégrerons cette fonctionnalité dans Elasticsearch !

Arrière-plan

Lors du développement d'Elasticsearch, nous rencontrons parfois un problème important pour lequel il n'existe pas d'approche simple ou établie. Il est naturel de se demander s'il existe un document universitaire traitant de cette question. D'autres fois, le travail universitaire est une source d'inspiration. Nous tombons sur un article proposant un nouvel algorithme ou une nouvelle structure de données et nous nous disons "ce serait tellement utile !". Voici quelques exemples de la façon dont Elasticsearch et Apache Lucene intègrent des travaux universitaires :

• HyperLogLog++ pour les agrégations de cardinalité

• Algorithme C3 pour la sélection adaptative des répliques

• Graphes hiérarchiques navigables du petit monde (HNSW) pour la recherche du vecteur le plus proche dans Lucene

• Statistique MIC pour améliorer la classification par apprentissage automatique

• Block-max WAND pour une recherche plus rapide des meilleurs résultats dans Lucene

• ... et bien d' autres encore

Les articles universitaires constituent une ressource inestimable pour les ingénieurs qui développent des systèmes à forte intensité de données. Mais leur mise en œuvre peut être intimidante et sujette à des erreurs - les descriptions d'algorithmes sont souvent complexes et des détails pratiques importants sont omis. Les tests constituent un véritable défi : par exemple, comment tester de manière approfondie un algorithme d'apprentissage automatique dont le résultat dépend étroitement de l'ensemble de données ?

Évaluez le document comme vous le feriez pour une dépendance logicielle.

L'ajout d'une nouvelle dépendance logicielle nécessite une évaluation minutieuse : si l'autre paquet est incorrect, lent ou peu sûr, notre projet pourrait l'être aussi. Avant d'intégrer une dépendance, les développeurs veillent à en évaluer la qualité.

Il en va de même pour les travaux universitaires que vous envisagez de mettre en œuvre. On peut penser que parce qu'un algorithme a été publié dans un article, il doit être correct et performant. Mais même s'il a été soumis à un processus d'examen, un document universitaire peut présenter des problèmes. Peut-être que la preuve d'exactitude repose sur des hypothèses qui ne sont pas réalistes. Il se peut aussi que la section "expériences" montre des performances nettement supérieures à celles de la ligne de base, mais que cela ne soit valable que pour un ensemble de données spécifique. Même si le document est de grande qualité, son approche peut ne pas convenir à votre projet.

Lorsque l'on se demande si l'on doit accepter une "dépendance" à l'égard d'un document universitaire, il est utile de se poser les mêmes questions que celles que l'on se poserait à l'égard d'un logiciel :

• La bibliothèque est-elle largement utilisée et "testée au combat" ? → D'autres paquets ont-ils mis en œuvre ce document, et cela a-t-il bien fonctionné pour eux ?

• Existe-t-il des critères de performance ? Ces données vous semblent-elles exactes et équitables ? → L'article comporte-t-il des expériences réalistes ? Sont-ils bien conçus ?

• L'amélioration des performances est-elle suffisamment importante pour justifier la complexité ? → Le document est-il comparable à une approche de référence solide ? Dans quelle mesure la performance est-elle supérieure à celle de la base de référence ?

• L'approche s'intégrera-t-elle bien à notre système ? → Les hypothèses et les compromis de l'algorithme sont-ils adaptés à notre cas d'utilisation ?

D'une manière ou d'une autre, lorsqu'un logiciel publie une comparaison de ses performances avec celles de ses concurrents, c'est toujours le logiciel qui est le plus rapide ! Si une tierce partie a conçu les critères de référence, ils peuvent être plus équilibrés. Le même phénomène s'applique aux travaux universitaires. Si un algorithme donne de bons résultats non seulement dans l'article original, mais apparaît également dans d'autres articles comme une référence solide, il est très probable qu'il soit solide.

Soyez créatifs avec les tests

Les algorithmes tirés d'articles universitaires ont souvent un comportement plus sophistiqué que les types d'algorithmes que nous rencontrons couramment. Il s'agit peut-être d'un algorithme d'approximation qui troque la précision contre une plus grande rapidité. Il peut aussi s'agir d'une méthode d'apprentissage automatique qui prend en compte un vaste ensemble de données et produit des résultats (parfois inattendus). Comment pouvons-nous écrire des tests pour ces algorithmes si nous ne pouvons pas caractériser leur comportement de manière simple ?

Focus sur les invariants

Lors de la conception des tests unitaires, il est courant de penser en termes d'exemples : si nous donnons à l'algorithme cet exemple d'entrée, il devrait produire cette sortie. Malheureusement, pour la plupart des algorithmes mathématiques, les tests basés sur des exemples ne couvrent pas suffisamment leur comportement.

Considérons l'algorithme C3, qu'Elasticsearch utilise pour déterminer quel nœud doit traiter une requête de recherche. Il classe chaque nœud à l'aide d'une formule nuancée qui incorpore le service précédent et les temps de réponse du nœud, ainsi que la taille de sa file d'attente. Tester quelques exemples ne permet pas vraiment de vérifier que nous avons compris la formule correctement. Il est utile de prendre du recul et de réfléchir au test des invariants : si le temps de service augmente, le rang du nœud diminue-t-il ? Si la taille de la file d'attente est de 0, le rang est-il déterminé par le temps de réponse, comme le prétend le document ?

Se concentrer sur les invariants peut s'avérer utile dans un certain nombre de cas courants :

• La méthode est-elle censée ne pas tenir compte de l'ordre ? Si c'est le cas, le fait de passer les données d'entrée dans un ordre différent devrait produire le même résultat.

• Certaines étapes de l'algorithme produisent-elles des probabilités de classe ? Si c'est le cas, la somme de ces probabilités doit être égale à 1.

• La fonction est-elle symétrique par rapport à l'origine ? Si c'est le cas, l'inversion du signe de l'entrée devrait simplement inverser le signe de la sortie.

Lorsque nous avons mis en œuvre C3 pour la première fois, nous avons eu un problème dans la formule où nous avons accidentellement utilisé l'inverse du temps de réponse à la place du temps de réponse. Cela signifie que les nœuds les plus lents peuvent être mieux classés ! Lors de la correction du problème, nous avons veillé à ajouter des vérifications invariantes afin d'éviter de nouvelles erreurs.

Comparer avec une implémentation de référence

Parallèlement à l'article, les auteurs ont publié une mise en œuvre de l'algorithme. (Cela est particulièrement probable si l'article contient des expériences, car de nombreuses revues exigent que les auteurs publient le code permettant de reproduire les résultats). Vous pouvez tester votre approche par rapport à cette implémentation de référence pour vous assurer que vous n'avez pas oublié des détails importants de l'algorithme.

Lors du développement de l'implémentation HNSW de Lucene pour la recherche du plus proche voisin, nous avons testé une bibliothèque de référence créée par les auteurs de l'article. Nous avons testé Lucene et la bibliothèque sur le même ensemble de données, en comparant la précision de leurs résultats et le nombre de calculs qu'ils ont effectués. Lorsque ces nombres correspondent étroitement, nous savons que Lucene met fidèlement en œuvre l'algorithme.

Lors de l'intégration d'un algorithme dans un système, il est souvent nécessaire de procéder à des modifications ou à des extensions, comme l'adaptation à plusieurs cœurs ou l'ajout d'heuristiques pour améliorer les performances. Il est préférable de commencer par mettre en œuvre une version "vanilla", de la tester par rapport à la référence, puis d'y apporter des modifications incrémentielles. Vous pouvez ainsi être sûr d'avoir capturé tous les éléments clés avant de procéder à des personnalisations.

Duel contre un algorithme existant

La dernière section propose une autre idée d'invariant de test : comparer le résultat de l'algorithme à celui d'un algorithme plus simple et mieux compris. Prenons l'exemple de l'algorithme WAND block-max de Lucene, qui accélère la recherche de documents en ignorant ceux qui ne peuvent pas figurer dans les premiers résultats. Il est difficile de décrire exactement le comportement de l'outil WAND block-max dans tous les cas, mais nous savons que son application ne devrait pas modifier les premiers résultats ! Nos tests peuvent donc générer plusieurs requêtes de recherche aléatoires, puis les exécuter avec et sans l'optimisation WAND et vérifier que les résultats correspondent toujours.

Un aspect important de ces tests est qu'ils génèrent des entrées aléatoires sur lesquelles la comparaison est effectuée. Cela peut permettre de mettre en œuvre des cas auxquels vous n'auriez pas pensé et de mettre en évidence des problèmes inattendus. Par exemple, le test de comparaison aléatoire de Lucene pour la notation BM25F a permis de détecter des bogues dans des cas subtils. L'idée d'alimenter un algorithme avec des entrées aléatoires est étroitement liée au concept de fuzzing, une technique de test courante dans le domaine de la sécurité informatique.

Elasticsearch et Lucene utilisent fréquemment cette approche de test. Si vous voyez un test qui mentionne un duel "" entre deux algorithmes (TestDuelingAnalyzers, testDuelTermsQuery...), vous savez que cette stratégie est en action.

Utiliser la terminologie du document

Lorsqu'un autre développeur travaillera avec votre code, il devra consulter le document pour en suivre les détails. Le commentaire sur l'implémentation HyperLogLog++ d'Elasticsearch le dit bien : "Essayer de comprendre ce que fait cette classe sans avoir lu le document est considéré comme aventureux." Ce commentaire de méthode constitue également un bon exemple. Elle comprend un lien vers l'article universitaire et met en évidence les modifications apportées à l'algorithme tel qu'il a été décrit à l'origine.

Étant donné que les développeurs fonderont leur compréhension du code sur le document, il est utile d'utiliser exactement la même terminologie. La notation mathématique étant laconique, il peut en résulter des noms qui ne seraient pas habituellement considérés comme "de bon style", mais qui sont très clairs dans le contexte de l'article. Les formules tirées d'articles universitaires sont l'une des rares occasions où vous rencontrerez des noms de variables cryptiques dans Elasticsearch, comme rS et muBarSInverse.

La façon recommandée par l'auteur pour lire un article : avec un grand café.

Vous pouvez envoyer un courriel à l'auteur

Lorsque vous travaillez sur un document difficile, vous pouvez passer des heures à réfléchir à une formule, sans savoir si vous avez mal compris ou s'il s'agit simplement d'une erreur de frappe. S'il s'agissait d'un projet open source, vous pourriez poser une question sur GitHub ou StackOverflow. Mais à qui s'adresser pour obtenir un travail universitaire ? Les auteurs semblent occupés et pourraient être ennuyés par vos courriels.

Au contraire, de nombreux universitaires aiment entendre que leurs idées sont mises en pratique et sont heureux de répondre à des questions par courrier électronique. Si vous travaillez sur un produit qu'ils connaissent bien, il se peut même qu'ils listent l'application sur leur site web !

Les universitaires ont également de plus en plus tendance à discuter de leurs articles en public, en utilisant les mêmes outils que ceux utilisés pour le développement de logiciels. Si un article est accompagné d'un logiciel, vous pouvez trouver des réponses aux questions les plus courantes sur Github. Les communautés Stack Exchange telles que "Theoretical Computer Science" et "Cross Validated" contiennent également des discussions détaillées sur les articles les plus populaires. Certaines conférences ont commencé à publier en ligne tous les comptes rendus d'articles. Ces revues contiennent des discussions avec les auteurs qui peuvent apporter des informations utiles sur l'approche.

A suivre

Cet article se concentre sur les bases du choix d'un document académique et sur la manière de le choisir.

L'algorithme doit être mis en œuvre correctement, mais il ne couvre pas tous les aspects du déploiement réel de l'algorithme. Par exemple, si l'algorithme n'est qu'un élément d'un système complexe, comment s'assurer que les modifications apportées à cet élément conduisent à des améliorations de bout en bout ? Et que se passe-t-il si l'intégration de l'algorithme nécessite des modifications ou des extensions substantielles que l'article original ne couvre pas ? Il s'agit là de sujets importants sur lesquels nous espérons revenir dans de prochains articles.