S’appuyant sur les exemples de la première partie, ce blog explore comment utiliser différentes techniques et la puissante boîte à outils de recherche vectorielle d’Elasticsearch afin de préparer les vecteurs d’interaction tardive pour des charges de production à grande échelle.

Les exemples complets de code sont disponibles sur GitHub.

Défis des modèles d’interaction tardive

ColPali crée plus de 1000 vecteurs par page pour les documents dans notre index.

Travailler avec des vecteurs d'interaction tardive présente alors deux défis :

1. Espace disque : l’enregistrement de tous ces vecteurs sur disque entraînera une consommation de stockage considérable, ce qui s’avérera coûteux à grande échelle..

2. Calcul : Lors du classement de nos documents avec la comparaison maxSimDotProduct() , nous devons comparer tous ces vecteurs pour chacun de nos documents avec les N vecteurs de notre requête.

Examinons quelques techniques pour remédier à ces problèmes.

Techniques pour optimiser les modèles d'interactions tardives

Vecteurs de bits

Afin de réduire l'espace disque, nous pouvons compresser les images en vecteurs binaires. Nous pouvons utiliser une simple fonction Python pour transformer nos multi-vecteurs en vecteurs de bits :

Le concept de noyau de la fonction est simple : les valeurs supérieures à 0 deviennent 1, et les valeurs inférieures à 0. Cela aboutit à un tableau de 0 et de 1, que nous transformons ensuite en une chaîne hexadécimale représentant notre vecteur de bits.

Pour le mapping de notre index, nous avons défini le paramètre element_type sur bit:

Après avoir écrit tous nos nouveaux vecteurs de bits dans notre index, nous pouvons classer nos vecteurs de bits en utilisant le code suivant :

En échange d'un peu de précision, cela nous permet d'utiliser la distance de hamming (maxSimInvHamming(...)), qui est capable de tirer parti d'optimisations telles que les masques de bits, SIMD, etc. Pour en savoir plus sur les vecteurs binaires et la distance de hamming, consultez notre blog.

Sinon, nous ne pouvons pas convertir notre vecteur de requête en vecteurs de bits et rechercher à l'aide du vecteur d'interaction tardive en pleine fidélité :

Cela comparera nos vecteurs en utilisant une fonction de similarité asymétrique.

Considérons une distance de Hamming standard entre deux vecteurs de bits.. Supposons que nous ayons un vecteur de document D :

Et un vecteur de requête Q :

La quantification binaire simple transformera les vecteurs D en 10101101 et Q en 11111011. Pour trouver la distance de Hamming, il faut des calculs directs en bits — c’est extrêmement rapide. Dans ce cas, la distance de hamming est 01010110, qui a un nombre de bits de 4. La notation devient donc l'inverse de cette distance de hamming. Rappelez-vous : plus les vecteurs sont similaires, plus la distance de Hamming est petite. L'inverser permet aux vecteurs les plus similaires d'être mieux notés. Plus précisément ici, le score serait 1/4 = 0.25.

Cependant, remarquez comment nous perdons l'ampleur de chaque dimension. Un 1 est un 1. Ainsi, pour Q, la différence entre 0.01 et 0.79 disparaît. Puisque nous quantifions simplement selon >0, nous pouvons faire une petite astuce où le vecteur Q n'est pas quantifié. Cela ne permet pas des calculs bit à bit extrêmement rapides, mais cela maintient le coût de stockage bas car D est toujours quantifié.

En résumé, cette méthode conserve les informations fournies dans Q, ce qui permet d’améliorer la qualité de l’estimation de la distance tout en limitant la consommation de stockage.

L'utilisation de vecteurs de bits nous permet d'économiser de manière significative de l'espace disque et de la charge de calcul au moment de la requête. Mais nous pouvons faire davantage.

Vecteurs moyens

Pour scaler notre recherche sur des centaines de milliers de documents, même les avantages de performance que nous apportent les vecteurs de bits ne seront pas suffisants. Afin de scaler à ces types de charges de travail, nous voudrons exploiter la structure d'index HNSW d'Elasticsearch pour la recherche vectorielle.

ColPali génère environ un millier de vecteurs par document, ce qui est trop pour les ajouter à notre graphe HNSW. Nous devons donc réduire le nombre de vecteurs. Pour cela, nous pouvons créer une représentation unique de la signification du document en prenant la moyenne de tous les vecteurs de documents produits par ColPali lors de l’intégration de notre image.

Pour l’instant, cela n’est pas possible au sein d’Elastic. Nous devrons donc prétraiter les vecteurs avant de les ingérer dans Elasticsearch.

Nous pouvons le faire avec Logstash ou des pipelines d'ingestion, mais ici nous utiliserons une simple fonction Python :

Nous normalisons également le vecteur afin de pouvoir utiliser la similarité par produit scalaire.

Après avoir transformé tous nos vecteurs ColPali en vecteurs moyens, nous pouvons les indexer dans notre champ dense_vector :

Il faut considérer que cela accroîtra l’utilisation globale du disque, car nous sauvegardons des données supplémentaires parallèlement à nos vecteurs d'interaction tardive. En outre, nous utiliserons de la RAM supplémentaire pour contenir le graphe HNSW, ce qui nous permettra de scaler la recherche à des milliards de vecteurs. Pour réduire l’utilisation de la RAM, nous pouvons utiliser notre fonctionnalité BBQ populaire. À notre tour, nous obtenons des résultats de recherche rapides sur d'énormes ensembles de données qui ne seraient autrement pas possibles.

À présent, nous recherchons simplement à l'aide de la requête knn pour trouver nos documents les plus pertinents.

Le meilleur résultat précédent a malheureusement été relégué au troisième rang.

Pour résoudre ce problème, nous pouvons effectuer une récupération en plusieurs étapes. Dans notre première étape, nous utilisons la requête knn pour rechercher les meilleurs candidats pour notre requête parmi des millions de documents. Dans la deuxième étape, nous ne classons que les k premiers (ici : 10) avec la plus grande fidélité des vecteurs d'interaction tardive de ColPali. 

Ici, nous utilisons l'outil rescore retriever introduit en 8.18 pour reclasser nos résultats. Après un nouveau calcul des scores, nous constatons que notre meilleur match se retrouve à nouveau en première position.

Remarque : Dans une application de production, nous pouvons utiliser un k bien supérieur à 10 car la fonction Max Sim est toujours relativement performante.

Regroupement de jetons

Le pooling de tokens réduit la longueur de séquence des plongements multi-vectoriels en regroupant les informations redondantes, comme les zones de fond blanc. Cette technique réduit le nombre de plongements tout en préservant la majeure partie du signal de la page.

Le pooling de jetons fonctionne en regroupant des embeddings de jetons similaires au sein d'un document en clusters à l'aide d'un algorithme de clustering. Ensuite, la moyenne des vecteurs dans chaque groupe est calculée pour créer une représentation unique et agrégée. Ce vecteur agrégé remplace les tokens originaux dans le groupe, réduisant ainsi le nombre total de vecteurs sans perte significative du signal du document.

Le document ColPali propose une valeur initiale de facteur de pool de 3 pour la plupart des ensembles de données, ce qui assure la maintenance de 97,8 % des performances originales tout en réduisant le nombre total de vecteurs de 66,7 %. 

Mais attention : l’ensemble de données « Shift », qui contient des documents très denses et riches en texte avec peu d’espace blanc, voit ses performances se dégrader rapidement à mesure que les facteurs de regroupement augmentent.

Pour créer les vecteurs regroupés, nous pouvons utiliser la bibliothèque colpali_engine :

Nous avons maintenant un vecteur dont les dimensions ont été réduites d’environ 66,7 %. Nous l'indexons comme d'habitude et nous pouvons rechercher dessus avec notre fonction maxSimDotProduct().

Nous pouvons obtenir de bons résultats de recherche au détriment d’une légère précision dans les résultats.

Conseil : avec un pool_factor plus élevé (100-200), vous pouvez également obtenir un juste milieu entre la solution vectorielle moyenne et celle dont nous avons discuté ici. Avec environ 5 à 10 vecteurs par document, il devient possible de les indexer dans un champ imbriqué pour tirer parti de l'index HNSW.

Encodeur Coss vs. encodeur à interaction tardive vs. bi-encodeur

Compte tenu de ces éléments, quelle est la place des modèles d'interaction tardive (comme ColPali ou ColBERT) vis-à-vis des autres méthodes de récupération de données par IA ?

Bien que la fonction de simulation maximale soit moins chère que les encodeurs croisés, elle nécessite néanmoins beaucoup plus de comparaisons et de calculs que la recherche vectorielle avec des bi-encodeurs, où nous comparons simplement deux vecteurs pour chaque paire requête-document.

Pour cette raison, nous recommandons d'utiliser les modèles d'interaction tardive uniquement pour le reclassement des k premiers résultats de recherche. Nous le reflétons également dans le nom du type de champ : rank_vectors.

Mais qu'en est-il de l'encodeur croisé ? Les modèles d'interaction tardive sont-ils meilleurs parce qu'ils sont moins chers à exécuter au moment de la requête ? Comme c'est souvent le cas, la réponse est : cela dépend. Les encodeurs croisés produisent généralement des résultats de meilleure qualité, mais ils nécessitent beaucoup de calcul car les paires de documents de requête doivent effectuer un passage complet à travers le modèle transformateur. Ils bénéficient également du fait qu'ils ne nécessitent aucune indexation de vecteurs et peuvent fonctionner de manière apatride. Résultats obtenus :

• Moins d'espace disque utilisé

• Un système plus simple

• Qualité supérieure des résultats de recherche

• Latence plus élevée, et donc impossible à repositionner aussi profondément

D'autre part, les modèles d'interaction tardive peuvent décharger une partie de ce calcul sur l'index, ce qui rend la requête moins coûteuse. Le prix à payer est la nécessité d’indexer les vecteurs, ce qui complexifie nos pipelines d’ingestion et nécessite davantage d’espace disque pour sauvegarder ces données.

Dans le cas particulier de ColPali, l'analyse des informations contenues dans les images est très coûteuse car elles contiennent beaucoup de données. Dans ce cas, le compromis penche en faveur de l'utilisation d'un modèle d'interaction tardive tel que ColPali, car évaluer ces informations au moment de la requête serait trop gourmand en ressources/lent.

Pour un modèle d’interaction tardif comme ColBERT, qui fonctionne sur des données textuelles comme la plupart des encodeurs croisés (par exemple, elastic-rerank-v1), la décision pourrait plutôt pencher vers l’utilisation du codeur croisé pour bénéficier des économies et de la simplicité du disque.

Nous vous encourageons à peser le pour et le contre en fonction de votre cas d'utilisation et à expérimenter les différents outils qu'Elasticsearch met à votre disposition pour créer les meilleures applications de recherche.

Conclusion

Dans ce blog, nous avons exploré diverses techniques pour optimiser les modèles d'interaction tardive comme ColPali pour la recherche vectorielle à grande échelle dans Elasticsearch. Bien que les modèles d'interaction tardive offrent un bon équilibre entre l'efficacité de la récupération et la qualité du classement, ils présentent également des défis liés au stockage et au calcul.

Pour relever ces défis, nous avons examiné :

• Des vecteurs de bits pour réduire de manière significative l'espace disque tout en tirant parti de calculs de similarité efficaces, tels que la distance de Hamming ou la similarité maximale asymétrique.

• Des vecteurs moyens pour compresser plusieurs intégrations en une seule représentation dense, permettant ainsi une récupération efficace grâce à l'indexation HNSW.

• Le pooling de jetons permet de fusionner intelligemment les embeddings redondants tout en assurant la maintenance de l’intégrité sémantique, réduisant ainsi la surcharge de calcul au moment de la requête.

Elasticsearch offre une boîte à outils puissante pour personnaliser et optimiser les applications de recherche selon vos besoins. Que vous privilégiez la vitesse de récupération, la qualité de classement ou l'efficacité de stockage, ces outils et techniques vous permettent d'équilibrer les performances et la qualité selon vos besoins pour vos applications du monde réel.

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.

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 !

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 !