Pour les nouveaux utilisateurs, c’est le moyen le plus rapide de mettre en place une recherche vectorielle de haute qualité. Si vous utilisez déjà Elasticsearch, la nouvelle offre permet de bénéficier de la recherche vectorielle sur la plateforme où se trouvent déjà vos données, sans aucun nouveau système à adopter. La base vectorielle Elasticsearch prend en charge divers scénarios, de l’ancrage d’un grand modèle de langage (LLM) à l’ajout de fonctionnalités de récupération et de mémoire pour un agent IA, en passant par le traitement de centaines de milliards de vecteurs. Lancez un nouveau projet et commencez en quelques minutes.

Un seul moteur pour tous les cas d'utilisation vectoriels

La base vectorielle Elasticsearch est conçue pour tous ceux qui créent des applications à l'aide de vecteurs :

• RAG : récupérez le contexte adapté pour votre LLM grâce à la récupération vectorielle dense et clairsemée, ou optez pour la recherche hybride combinant à la fois la récupération vectorielle et lexicale. La qualité de votre génération s’améliore avec la qualité de votre récupération.

• Agents IA : offrez aux agents une récupération rapide et filtrée des documents et de la mémoire conversationnelle, avec les faibles latences qu’exigent les boucles d’agents à étapes multiples.

• Recherche sémantique : faites correspondre selon le sens, et non par mots-clés, avec un seul type de champ et sans aucun code de pipeline.

• Recommandations et similarité : trouvez les plus proches voisins parmi des produits, des images ou tout autre contenu dont vous disposez, à grande échelle.

Tout ce dont votre charge de travail vectorielle a besoin, optimisé et prêt à l'emploi

Créer une application vectorielle implique de relier plusieurs éléments distincts : configurer et héberger des modèles d’embedding, indexer vos documents via ces modèles, stocker efficacement les vecteurs, appliquer le modèle d’embedding à chaque requête, effectuer des correspondances avec le stockage de vecteurs, et enfin, récupérer les documents correspondant aux résultats. La base vectorielle Elasticsearch gère tout cela pour vous, sans configuration ni paramétrage supplémentaire.

Indexation vectorielle avec le mode d’indexation vectordb_document

Le mode d’indexation vectordb_document, une nouvelle configuration d’index spécialement conçue pour les charges de travail axées sur les vecteurs, est activé par défaut, vous bénéficiez ainsi des paramètres que choisiraient des experts. Voici ce que cela active :

• bfloat16 par défaut : les vecteurs sont stockés à la moitié de la taille de float32 avec un impact négligeable sur le rappel, réduisant votre empreinte disque d’environ la moitié avant même que la quantification n’entre en jeu.

• Vecteurs sources exclus : dans Elasticsearch, vos plongements figurent déjà dans les structures d’index utilisées pour la recherche ; conserver une deuxième copie brute dans _source ne fait qu’augmenter le stockage et ralentir la récupération des résultats. Nous excluons le doublon afin que les réponses soient renvoyées plus rapidement et que vous stockiez moins.

• Les bons fichiers préchargés dans le cache : les structures de données auxquelles les requêtes vectorielles accèdent en premier sont préchauffées en mémoire à l’avance, de sorte que votre première (et votre millième) requête soit ultra-rapide.

• Fusion parallèle : la fusion regroupe les segments dans des structures vectorielles mieux organisées, ce qui améliore à la fois le rappel et la latence, et l’exécution de ces fusions en multithread vous permet d’y parvenir plus rapidement.

Stockage vectoriel, compression et optimisation automatique

• Vos vecteurs sont compressés automatiquement. La quantification binaire optimisée (BBQ) réduit l’empreinte mémoire des vecteurs jusqu’à 32 fois tout en préservant le rappel, et DiskBBQ réduit encore davantage les besoins en mémoire pour les charges de travail à grande échelle. 

• Optez pour l’auto-étalonnage, qui ajuste la quantification de chaque segment en fonction de vos données et la réajuste à chaque fusion à mesure que les données dérivent. Lors des tests sur 18 ensembles de données, le nombre de requêtes par seconde (QPS) s’est amélioré en moyenne de 16,7 %, avec des gains de rappel pour la plupart d’entre eux.

Embeddings sur une inférence GPU gérée

• Générez des embeddings grâce aux modèles natifs d’embedding et de reclassement de Jina AI, ou importez des modèles tiers, le tout sur des GPU gérés via Elastic Inference Service (EIS), sans aucun serveur de modèles à gérer. Ou optez pour l’auto-hébergement, si vous préférez votre propre infrastructure.

• Le type de champ semantic_text gère automatiquement la segmentation et l’embedding, ainsi que l’interrogation, ce qui représente la voie la plus simple vers la recherche sémantique sur le marché. 

Recherche hybride et recherche vectorielle filtrée

• La recherche hybride est intégrée, combinant la récupération en texte intégral et vectorielle dans une seule requête. Combinez les résultats grâce à la fusion des rangs réciproques (RRF) ou à tout autre mécanisme de combinaison de votre choix. La recherche vectorielle est généralement la partie de la recherche hybride la plus difficile à bien configurer. Avec la base vectorielle Elasticsearch, vous maîtrisez la situation et l’ensemble de votre stack hybride s’améliore. 

• Avec la recherche vectorielle filtrée, appliquez des filtres de métadonnées dans le cadre même de la récupération vectorielle, et non après coup, ce qui dégrade le rappel.

Entreprise dès le premier jour

Vous bénéficiez également du contrôle d’accès basé sur les rôles (RBAC), du logging d’audit, et des certifications de conformité qui font généralement défaut aux bases vectorielles pure-play.

Abordable à grande échelle et prévisible

La base vectorielle Elasticsearch est conçue pour rester abordable à mesure de votre croissance : les compressions BBQ et DiskBBQ, qui maintiennent un stockage linéaire et une faible utilisation de la mémoire, permettent un scaling vers des centaines de milliards de vecteurs sans faire exploser votre facture. Et ce que vous payez est basé sur des chiffres que vous connaissez déjà : la quantité de données que vous stockez, ce que vous indexez, ainsi que la capacité de recherche dont vous avez besoin. Estimez votre nombre de documents et les dimensions de vos vecteurs, ainsi que votre charge de requêtes, et vous pourrez déterminer ce que vous paierez avant de créer le projet. Vous pouvez également comprendre votre facture ligne par ligne à la fin du mois. Il n’y a pas d’unités de calcul opaques, ni de frais imprévus pour les opérations en arrière-plan.

Comment démarrer avec la base vectorielle Elasticsearch

Créez un projet de Base vectorielle sans serveur

Créez un nouveau projet de base vectorielle sans serveur dans Elastic Cloud. Dirigez vos données vers le point de terminaison, et vous êtes prêt à indexer.

Créer un index à l’aide de semantic_text

Le mode d’index vectoriel gère la configuration vectorielle. L’utilisation de semantic_text signifie que la configuration des embeddings et du chunking est gérée pour vous, tout comme la configuration de l’index, sur une inférence GPU gérée, sans aucun pipeline d’embedding à créer.

Ingérer des documents

Indexez du texte, et les embeddings sont générés pour vous.

Exécuter une requête de recherche sémantique

Interrogez le même champ sémantique que vous venez de créer :

Et vous obtenez des résultats :

La recherche sémantique n’est qu’un début. Exécutez des requêtes entièrement textuelles ou combinez les deux dans des requêtes hybrides. Vous pouvez même créer vos propres requêtes vectorielles pour bénéficier d’un contrôle total. Suivez le guide de démarrage rapide de la recherche sémantique dans la documentation pour obtenir toutes les instructions.

Quelle est la suite pour la recherche vectorielle dans Elasticsearch

Nous travaillons déjà sur les prochaines améliorations :

• Meilleure prise en charge de la mutualisation : si vos données doivent rester séparées par entité, nous vous donnons les moyens de le faire plus rapidement et avec moins de code.

• Optimisation automatique des index : d’un « tout nouvel index » à « entièrement optimisé », avec le moins d’ajustements possible.

• Améliorations continues de l’infrastructure : ajustement continu des paramètres et de l’infrastructure de la base vectorielle afin que vous bénéficiiez toujours du meilleur débit et des réponses les plus rapides.

Essayez la base vectorielle Elasticsearch sur Elastic Cloud Serverless

Passez d’un projet vide à une requête vectorielle hybride et filtrée en quelques minutes, avec des réglages par défaut prêts pour la production qui s’ajustent pour vous. Créez des applications d'IA rapides et scalables, pas de l'infrastructure.

Commencez sur Elastic Cloud Serverless, ou plongez dans la documentation complète et la référence de l’API.

Qu'est-ce que le rappel ?

Le rappel mesure, sur une échelle allant de 0 à 1, le nombre de documents réellement souhaités par vos utilisateurs qui apparaissent quelque part dans vos résultats de recherche. Si une requête doit faire apparaître trois produits et que votre recherche ne renvoie que deux d’entre eux dans le top 10, recall@10 = 0.67 pour cette requête. C’est une métrique basée sur des ensembles : la position des documents pertinents dans ces k résultats n’a pas d’importance. Un document pertinent en position 10 compte autant qu’un document en position 1. Un taux de rappel élevé signifie que vous ne perdez pas de résultats pertinents.

Le diagramme montre deux ensembles : tous les documents pertinents (à gauche) et ce que BM25 a réellement récupéré (les 10 premiers, à droite). Seules les intersections comptent pour le rappel, prod_1 et prod_2 ont été trouvés, tandis que prod_3, prod_4 et prod_6 ont été totalement manqués. Résultat : Recall@10 = 2/5 = 0.40.

Produits requis

Entrons dans le vif du sujet pour mieux comprendre le fonctionnement du rappel. Cette démonstration utilise Python. Vous pouvez la suivre dans le cahier d’accompagnement (notebook.ipynb), où chaque bloc de code est une cellule prête à être exécutée.

Le code fourni utilise les éléments suivants :

• Elasticsearch 9.3+

• Python 3.10+

• Un fichier .env avec vos identifiants Elasticsearch

L’ensemble de données

Nous utiliserons un catalogue de produits de 1 000 articles, couvrant des catégories telles que les chaussures, l’électronique, les outils, et bien d’autres.

Chaque document comporte quatre champs :

Champ

Type

`title`

Texte

description

Texte

marque

mot-clé

Catégorie

mot-clé

L’ensemble de données est chargé à partir de dataset.csv.

La puissance et les limites de la recherche lexicale

BM25 est l’algorithme de classement par défaut d’Elasticsearch et de la plupart des moteurs de recherche. Il attribue des scores aux documents en fonction de la fréquence d’apparition de vos termes de requête dans ceux-ci, ajustée en fonction de la longueur du document et de la fréquence de ces termes dans l’ensemble de l’index. Vous disposez d’analyseurs en plus : normalisation des minuscules, troncature et suppression des mots vides. Une requête pour « chaussures de course » correspondra à « Chaussures de course » et probablement aussi à « courir ».

Cette méthode fonctionne bien pour une grande catégorie de requêtes :

• « chaussures de course » associe immédiatement les produits dont le titre correspond exactement à ces termes.

• L’expression « enceinte Bluetooth » fait apparaître des produits audio portables, car les termes apparaissent tels quels.

Les résultats sont déterministes et explicables : un document est bien classé parce que les termes de la requête y apparaissent. La pertinence du débogage est simple.

Les cas d’échec

Essayons maintenant ces requêtes sur le même catalogue :

• « Routine de soins de la peau » : Le mot « routine » n’apparaît dans aucun titre de produit. BM25 peut correspondre partiellement à la requête « soins de la peau », mais les sérums pour le visage, les huiles corporelles et les crèmes hydratantes sont décrits à l’aide de termes comme « vitamine C », « rétinol » ou « éclaircissant », dont aucun ne correspond à la requête. Les produits qui forment une routine de soins de la peau complète sont dispersés dans l’index sans aucun élément commun permettant de les regrouper.

• « Accessoires de voyage pour animaux de compagnie » : il s’agit d’un regroupement de cas d’utilisation, et non d’une catégorie de produits. Un sac kangourou pour chien, un siège auto pour animal et une caisse de voyage sont tous pertinents, mais leurs descriptions parlent de portabilité, de sécurité et de confort plutôt que d’« accessoires de voyage ». BM25 trouve des correspondances pour le terme « animal de compagnie » au sens large, mais ne comporte aucun signal permettant de distinguer les produits spécifiques aux voyages du reste du catalogue pour animaux de compagnie.

Il s'agit d'un problème de rappel. Les documents pertinents se trouvent dans votre index. BM25 ne peut tout simplement pas les trouver car les mots de l'utilisateur et les mots du document ne correspondent pas suffisamment étroitement.

L'ajout de synonymes est utile pour les cas connus. Mais vous ne pouvez pas énumérer toutes les façons dont un utilisateur pourrait exprimer une intention. C'est là que les vecteurs entrent en jeu.

Pourquoi il est conseillé de mesurer le rappel

Avant de résoudre un problème, il faut le quantifier.

Recall@k mesure combien de documents vos utilisateurs souhaitent réellement voir apparaître dans vos résultats de recherche. Au sens strict :

Precision@k mesure les k premiers résultats et combien sont réellement pertinents :

Une grande précision garantit la qualité des résultats obtenus. Dans le commerce électronique, l’absence d’un produit pertinent (faible taux de rappel) est souvent pire que l’affichage d’un résultat légèrement imparfait (précision moindre), car un produit caché est une vente perdue.

L’API d’Elasticsearch rank_eval vous permet de mesurer les deux de manière systématique. Vous fournissez une liste de requêtes, chacune avec un ensemble de documents évalués, et Elasticsearch calcule les métriques pour vous pour l’ensemble des requêtes.

Configuration de l'évaluation

L’API rank_eval nécessite un ensemble de données d’évaluations : un mappage des requêtes vers les documents pertinents pour chacune d’elles, accompagné d’un grade de pertinence (0 = non pertinent, 1 = pertinent, 2 = très pertinent).

Dans le cahier, il s’agit de la liste des jugements :

Le mélange est intentionnel : q1 est une requête que BM25 gère bien (jetons exacts dans les titres des produits), tandis que q2, q3, et q4 sont des requêtes basées sur l’intention où l’intention de l’utilisateur est exprimée sous forme de concept plutôt que de mots-clés spécifiques sur les produits.

Mesurer le rappel de référence du BM25

Commencez par configurer le client Elasticsearch et indexez les données textuelles brutes :

Maintenant, créez la requête rank_eval pour BM25. Chaque requête dans la liste combine une requête avec ses notations :

Voici le résultat.

0.43 Signifie que sur l’ensemble des quatre requêtes, BM25 ne trouve que 43 % des documents qu’il devrait trouver. Le problème se situe principalement dans les requêtes basées sur l’intention : « routine de soins de la peau » ne trouve pas les sérums pour le visage et les huiles corporelles car le mot « routine » n’apparaît jamais dans les titres des produits, et « accessoires de voyage pour animaux de compagnie » renvoie des produits pour animaux de compagnie hors sujet tout en ne trouvant pas les cages et les caisses de transport dont la description précise les fonctionnalités de portabilité et de sécurité plutôt que d’« accessoires de voyage ».

Ceci est notre référence. Nous avons maintenant un chiffre à battre.

Ajout de la recherche vectorielle avec les embeddings Jina

Vector search encode les documents et les requêtes sous forme de vecteurs de grande dimension, composés de centaines ou de milliers de valeurs numériques, chacune encodant une fonctionnalité spécifique des données représentées. Les documents ayant une signification similaire se retrouvent proches les uns des autres dans l’espace vectoriel, même s’ils ne partagent aucun mot. « Équipement de gym » et « kit d’haltères » seront proches l’un de l’autre, car les concepts sont liés. J’ai choisi Elasticsearch comme base vectorielle, car il prend en charge la recherche hybride, ce qui me permet de bénéficier d'emblée à la fois d’une compréhension sémantique et d’une précision par mot-clé.

EIS inclut une prise en charge prête à l’emploi pour l’intégration de modèles via son API d’inférence.

Étape 1 : utiliser les embeddings Jina v5 comme point de terminaison d’inférence

Si votre cluster dispose de ressources GPU (disponibles dans Elastic Cloud et Elasticsearch 9.3+), les embeddings sont générés sur GPU, ce qui est nettement plus rapide que l’inférence CPU, et supprime le compromis de performance qui rendait auparavant l’utilisation des vecteurs coûteuses à grande échelle.

Pourquoi spécifiquement les embeddings Jina ? jina-embeddings-v5-text est un modèle multilingue (plus de 119 langues) avec une fenêtre de contexte de 32 000 jetons et une prise en charge des adaptateurs Low-Rank Adaptation (LoRA) spécifiques à la tâche. Il fonctionne bien pour les courtes descriptions de produits prêtes à l’emploi. En savoir plus sur le modèle jina-embeddings-v5-text ici.

Étape 2 : créer l’index avec un champ sémantique

Le type de champ semantic_text est ici la clé. C’est une abstraction de niveau supérieur par rapport à dense_vector : vous le dirigez vers un point de terminaison d’inférence, et Elasticsearch se charge de générer automatiquement les plongements.

La propriété copy_to sur title et description signifie que le contenu des deux champs est transmis à semantic_field pour intégration, de sorte qu’un seul vecteur capture la représentation complète du produit.

Étape 3 : indexer les produits

Au moment de l’indexation, Elasticsearch appelle le point de terminaison d’inférence pour chaque document et stocke le vecteur d’intégration résultant dans semantic_field. Aucun code supplémentaire n’est nécessaire de votre côté.

Recherche hybride : combinaison de BM25 et de vecteurs avec RRF

L'ajout de vecteurs améliore le taux de rappel, mais le recours exclusif aux vecteurs risque d'entraîner une perte de précision pour les requêtes en correspondance exacte. Les résultats pour « chaussures de course » devraient toujours classer en premier les correspondances exactes. La recherche hybride conserve la composante lexicale spécifiquement pour préserver cette précision.

La recherche hybride avec la Fusion des rangs réciproques (RRF) combine le meilleur des deux :

• BM25 gère les requêtes exactes et quasi-exactes avec une grande précision.

• La recherche sémantique gère les requêtes basées sur l’intention et multilingues avec un rappel élevé.

• RRF fusionne les deux listes classées en un seul classement.

La formule RRF attribue à chaque document un score basé sur son classement dans chaque liste de résultats :

Un document bien classé dans les deux listes obtient un score combiné plus élevé. Le paramètre rank_constant détermine le poids attribué aux documents moins bien classés.

Voici le résultat.

Hybrid s’améliore nettement par rapport à BM25 (0.43) et préserve la précision des requêtes de correspondance exacte, comme « chaussures de course ».

Résultats : avant et après

Voici un comparatif complet des trois approches :

Voici le résultat.

Méthode

Recall@10

BM25 (Lexical)

0,43

Hybride (BM25 + vecteurs)

0,75

Répartition des données par requête :

Conclusion

Tout au long de cet article, nous avons vu que la recherche lexicale BM25 est fiable lorsque les utilisateurs tapent des requêtes exactes, mais qu’elle perd en rappel lorsqu’ils recherchent par intention plutôt que par mots-clés. En utilisant rank_eval, nous avons établi une base reproductible pour mesurer cet écart avec des nombres réels. Ensuite, nous avons ajouté un champ semantic_text alimenté par les embeddings Jina et relancé l’évaluation. Le résultat : la recherche hybride a amélioré le rappel de 0.43 à 0.75, tout en préservant la précision des requêtes à correspondance exacte, bien que la marge réelle dépende de la composition de vos requêtes.

Le modèle s’étend au-delà de cet exemple : collectez les jugements à partir des requêtes réelles de vos utilisateurs, exécutez rank_eval comme référence, ajoutez semantic_text, puis mesurez à nouveau. Vous saurez exactement ce qui s’est amélioré et de combien.

Étapes suivantes

• Découvrez la recherche de rappel et de recherche vectorielle : quantification du rappel et de la recherche vectorielle par Jeff Vestal

• Ajoutez le reclassement pour une précision encore meilleure sur les meilleurs résultats

• Consultez la documentation sur la recherche hybride avec Elasticsearch

• En savoir plus sur rank_evall’API

Comment nous avons conçu Elasticsearch simdvec

Chaque requête de recherche vectorielle dans Elasticsearch, qu'il s'agisse d'un balayage transversal Hierarchical Navigable Small World (HNSW), d'un balayage de fichier inversé (IVF) ou d'une passe de reclassement, se résume au même problème : calculer les distances entre les vecteurs, des millions de fois par requête. Elasticsearch prend en charge un large éventail de types de données et de stratégies de quantification, de float32 à int8, bfloat16, binaire et quantification binaire améliorée (BBQ). Chacune présente des compromis différents entre mémoire, débit et rappel. Derrière tout cela se cache un moteur unique : simdvec.

Nous avons conçu simdvec pour rendre chaque calcul de distance aussi rapide que le permet le matériel. Dans cet article, nous expliquons pourquoi nous l'avons conçu, ce qu'il contient et où il a le plus d'impact.

Construit comme une voiture de course

En tant que passionnés de Formule 1 (l'un d'entre nous a travaillé pour l'écurie Ferrari), nous constatons un parallèle évident. Une Formule 1 est conçue dans un seul but : réaliser le meilleur temps au tour. La puissance du moteur, l'aérodynamisme et la conception du châssis n'ont d'importance que dans la mesure où ils contribuent à cet objectif. Il en va de même pour une base vectorielle, où le débit d'indexation, la latence des requêtes et le rappel sont les facteurs déterminants de sa performance.

Bien que le résultat final soit ce qui compte, atteindre les plus hauts niveaux de performance nécessite que chaque composant contribue de façon optimale. Il ne doit pas être simplement suffisant, mais le meilleur de sa catégorie. Simdvec est conçu dans cet esprit, en se concentrant sur une partie critique du système : le moteur. C'est une bibliothèque de noyaux dédiée, optimisée pour le Single Instruction Multiple Data (SIMD), qui fournit des fonctions de distance C++ natives optimisées et appelées depuis Java via l'interface de fonction étrangère (FFI) Panama. Il prend en charge le scoring en lots, le prefetching des lignes de cache et tous les types et mises en page de vecteurs utilisés dans Elasticsearch.

C'est le moteur derrière chaque requête.

Pourquoi nous avons créé le nôtre

Nous avons commencé en 2023 avec l'API Panama Vector dans Apache Lucene. Elle fonctionnait bien pour les produits scalaires de nombres flottants 32 bits, mais les besoins d'Elasticsearch ont rapidement dépassé ses capacités. Elasticsearch prend en charge une large gamme de types de vecteurs quantifiés : int8, int4, bfloat16, mono-bit et BBQ asymétrique. Chacun possède des stratégies SIMD, des compositions de packs et des exigences d'accumulateur différents. Au-delà de la couverture des types, les méthodes de scoring d'Elasticsearch exigent un débit supérieur à celui d'une simple paire : HNSW doit évaluer plusieurs voisins du graphe en une seule passe, IVF nécessite un scoring en lots de milliers de candidats avec prefetching, et le scoring sur disque doit fonctionner directement sur la mémoire mappée en mémoire sans copie. Nous avons examiné les solutions disponibles, mais aucune ne couvrait l'ensemble des besoins.

Nous avons donc développé simdvec : des noyaux C++ natifs optimisés manuellement, appelés depuis Java via FFI, avec scoring par lots, prefetching et prise en charge de tous les types vectoriels utilisés par Elasticsearch. En étant propriétaires de la bibliothèque, nous maîtrisons l'intégralité de la pile. Lorsque nous ajoutons un nouveau type de quantification comme BBQ, il bénéficie d'un noyau SIMD optimisé intégré à l'ensemble du système. Nous n'attendons pas qu'une bibliothèque tierce le prenne en charge et nous ne faisons aucun compromis sur les performances, quel que soit le type. Chaque requête vectorielle dans Elasticsearch – HNSW, IVF, de reclassement ou hybride – s'exécute sur ce moteur, conçu autour des opérations et des types que nous utilisons réellement.

Simdvec possède des bibliothèques natives distinctes pour x86 et ARM, chacune comportant plusieurs niveaux d'architecture du jeu d'instructions (ISA) sélectionnés au démarrage. La surcharge des appels depuis Java via FFI est très faible, de l'ordre de quelques nanosecondes.

Le panorama

Nous ne sommes pas les seuls à développer des noyaux de distance vectorielle optimisés pour SIMD. L'écosystème est riche et nous souhaitions comprendre les performances de simdvec. Non pas pour classer les projets, mais pour contextualiser et situer le moteur d'Elasticsearch. Nous avons sélectionné trois projets comme points de référence, chacun représentant une approche différente :

• jvector : une bibliothèque Java de recherche de plus proches voisins approximatifs (ANN) qui utilise l'API Panama Vector pour le calcul de distance vectorisé, avec une accélération C native optionnelle sur x86.

• FAISS : un framework de recherche vectorielle open source largement déployé, avec des noyaux AVX2/AVX-512 ajustés manuellement.

• NumKong (anciennement SimSIMD) : une suite complète de plus de 2 000 noyaux SIMD ajustés manuellement, couvrant les fonctions de distance, les opérations matricielles et le calcul géospatial.

Chaque projet répond à un objectif différent et fait l'objet de compromis différents. Nous incluons des numéros de référence provenant d'eux pour donner du contexte à la performance de simdvec sur les opérations spécifiques dont Elasticsearch a besoin.

Comment nous mesurons

Les benchmarks simdvec et jvector sont écrits en Java avec JMH, le harnais de microbenchmark JVM standard, avec la surcharge FFI incluse. Pour les benchmarks NumKong et FAISS, nous avons écrit de petits programmes C/C++ utilisant Google Benchmark, qui est le framework standard de microbenchmark C++. Ces deux frameworks mesurent les temps d'exécution en nanosecondes, après une phase de warmup et un étalonnage des itérations. Nous avons vérifié, grâce à des compteurs de performance matériels, que toutes les bibliothèques utilisent SIMD sur les deux plateformes. L'ensemble du code des benchmarks est disponible publiquement dans les référentiels GitHub associés (et, pour simdvec, dans le référentiel elasticsearch).

Logiciel : JDK 25.0.2, JMH 1.37, GCC 14, Google Benchmark (dernière version).

Un vecteur à la fois

L'opération fondamentale de la recherche vectorielle consiste à calculer la distance entre deux vecteurs. Chaque évaluation de voisinage HNSW, chaque score de candidat IVF, chaque comparaison de reclassement ramène à cette boucle interne.

Nous avons mesuré le débit d'une seule paire à 1 024 dimensions sur les deux plateformes, en commençant par le type float32, le type de référence et celui où l'écosystème est le plus compétitif. Nous avons comparé simdvec à FAISS et jvector ; nous avons exclu NumKong car il utilise des accumulateurs float64 pour float32, ce qui le rend 3,2 à 5,3 fois plus lent (selon la plateforme), privilégiant la précision numérique au débit. Pour une comparaison équitable, nous avons testé NumKong sur int8, où il utilise la même stratégie d'accumulateurs que simdvec.

Sur x86, FAISS AVX-512 est le noyau à paire unique le plus rapide à 23 ns. Simdvec AVX-512 suit à 28 ns, un écart qui reflète la surcharge d'appel FFI. Les deux utilisent le FMA 512 bits avec déroulement par accumulateurs multiples. Au niveau AVX2, les deux sont beaucoup plus proches, 36 ns et 39 ns respectivement, tous deux limités par le registre de 256 bits et les largeurs de chargement en mémoire. jvector arrive à 44 ns grâce à l'API Java Panama Vector. Panama génère un bon code SIMD, mais les intrinsèques C++ optimisées manuellement conservent un avantage.

Sur ARM, simdvec affiche le meilleur temps d'exécution (70 ns), devançant largement jvector (110 ns) et FAISS (156 ns). Simdvec utilise des noyaux NEON optimisés manuellement pour aarch64. Jvector, quant à lui, ne possède aucun code ARM natif et repose sur Panama. FAISS s'appuie sur la vectorisation automatique du compilateur plutôt que sur des fonctions intrinsèques NEON explicites, ce qui explique l'écart plus important. Ceci illustre l'avantage pratique de posséder la bibliothèque de noyaux : lors du passage d'Elasticsearch à Graviton, nous avons intégré des noyaux NEON dédiés. Ni jvector ni FAISS n'ont accordé la même priorité au code natif ARM.

Mais Elasticsearch ne se limite pas aux nombres à virgule flottante 32 bits. La quantification d'Int8 réduit la mémoire d'un facteur 4, la quantification bfloat16 d'un facteur 2 et la quantification BBQ d'un facteur 32. Chaque type nécessite sa propre stratégie SIMD, et simdvec fournit des noyaux natifs optimisés manuellement pour chacun d'entre eux.

Parmi les bibliothèques que nous avons comparées, seule NumKong possède des noyaux comparables pour int8. Nous avons mesuré le produit scalaire int8, la distance euclidienne au carré et le cosinus pour le format int8 sur 1 024 dimensions.

Score Int8 pour une seule paire (1 024 dimensions, ns/vec op – plus bas est mieux)

Sur les deux architectures, NumKong est aussi performant, voire plus rapide, pour les petites et moyennes dimensions, la différence étant principalement due à une surcharge d'appels réduite (appel direct en C contre FFI Java). Pour les grandes dimensions, simdvec rattrape son retard, grâce à une implémentation noyau plus efficace (qui utilise le déroulement en cascade) qui amortit le coût des appels : à mesure que la dimension augmente, cet écart se réduit et finit par s'inverser. Le point de bascule se situe entre 768 et 1 536 dimensions, selon la fonction et l'architecture.

Malgré la surcharge légèrement supérieure de l'interface FFI Java, simdvec rivalise avec les bibliothèques C/C++ fortement optimisées. Non seulement c'est la seule bibliothèque dotée de noyaux optimisés pour float32 et int8, mais elle est également en tête sur ARM et juste derrière FAISS sur x86 (pour float32), et très proche de NumKong sur les deux architectures (pour int8). Enfin, pour bfloat16, int4, binary et BBQ, bien qu'il existe des alternatives, simdvec se distingue par un SIMD ajusté manuellement et adapté à la structure des données de chaque type.

Cependant, un moteur de recherche en production n'évalue pas un vecteur à la fois ; il en évalue des milliers par requête. La question suivante est de savoir ce qui se passe à cette échelle.

Des milliers à la fois

Les performances sur une seule paire ne représentent qu'une partie du problème. En pratique, c'est le comportement des systèmes sous charge qui est important. Une simple requête HNSW peut évaluer des centaines de voisins dans le graphe. Une analyse IVF peut évaluer des milliers d'entrées de listes de publication. Une passe de reclassement peut évaluer des dizaines de milliers de candidats. Le débit sur une seule paire est important, mais ce qui compte davantage, c'est la rapidité avec laquelle il est possible d'évaluer de nombreux vecteurs et la façon dont les performances se dégradent lorsque l'ensemble de travail déborde des caches du processeur.

Simdvec propose un scoring par lots pour tous les types de données. Il ne s'agit pas simplement de boucles sur des noyaux de distance à une seule paire, mais de boucles internes dotées de plusieurs accumulateurs qui chargent le vecteur de requête une fois par pas de dimension et le partagent entre plusieurs vecteurs de documents, avec un prefetching explicite des lignes de cache pour le lot suivant. Ni jvector ni FAISS n'offrent d'équivalent (à l'heure actuelle). Jvector ne dispose pas d'API Bulk ; les appelants calculent donc le score d'une paire à la fois dans une boucle. FAISS expose fvec_inner_products_ny, qui, à l'heure actuelle, est implémenté comme une boucle sur sa fonction de distance à une seule paire, sans amortissement ni prefetching des requêtes.

Float32. Pour mesurer l'impact au niveau du noyau, nous avons évalué une requête unique sur un nombre croissant de vecteurs de documents float32 de 1 024 dimensions, en utilisant des modèles d'accès aléatoire simulant des recherches de voisins dans un graphe dispersé de type HNSW. Les trois tailles d'ensemble de données (32, 625 et 32 500 vecteurs) ont été choisies de manière à ce que l'ensemble de travail dépasse respectivement les caches L1, L2 et L3.

Lorsque les données tiennent dans le cache, simdvec est le plus rapide sur les deux plateformes, mais l'écart reste modeste, car l'arithmétique du noyau est prépondérante. La différence est flagrante lorsque la taille de l'ensemble de travail dépasse le cache L3. Sur x86, simdvec atteint 95 ns par vecteur, contre 165 ns pour FAISS et 412 ns pour jvector. Sur ARM, le constat est identique : simdvec se maintient à 162 ns, tandis que FAISS grimpe à 347 ns et jvector à 476 ns. Le prefetching et l'amortissement des requêtes dans simdvec masquent la latence mémoire, contrairement à une simple boucle sur des noyaux à paire unique. Cet avantage est encore plus manifeste précisément là où les véritables charges de travail de recherche s'exécutent, au cœur de la mémoire principale.

Int8. Le même schéma s'applique aux types quantifiés. Nous avons mesuré le scoring par lots du produit scalaire int8 à 1 024 dimensions avec des tailles d'ensemble de données choisies pour dépasser les mêmes limites de cache L1, L2 et L3, en comparant le scoring par lots de simdvec au scoring de paires individuelles de NumKong dans une boucle.

Sur x86, simdvec est de 1,2 à 1,9 fois plus rapide, grâce à la combinaison du prefetching explicite et du traitement par lots. Sur ARM, simdvec l'emporte également (de 1,7 à 1,9 fois plus rapide) quelle que soit la taille des ensembles de données. Cet avantage provient du traitement par lots de quatre vecteurs simultanément, offrant un parallélisme au niveau mémoire via un modèle d'accès entrelacé. Dans les deux cas, le résultat le plus frappant se situe au niveau des ensembles de données les plus volumineux, là où il est le plus significatif.

Les résultats concernant la distance au carré et le cosinus montrent un schéma similaire, avec des accélérations de 1,4 à 1,8 fois pour ARM, et de 1,3 à 3,0 fois pour x86 (détails ici).

Quand la mémoire est essentielle

Les index vectoriels de production ne tiennent généralement pas dans le cache du processeur. Un index vectoriel de 10 millions d'éléments (int8) à 1 024 dimensions pèse 10 Go. Le scoring des candidats implique le traitement en continu des données depuis la DRAM, et c'est là que l'architecture de scoring par lots fait toute la différence.

Nous avons utilisé des compteurs de performances matérielles pour mesurer ce qui se passe à l'intérieur du processeur pendant le scoring par lots et avons constaté que masquer la latence de la mémoire nécessite deux stratégies fondamentalement différentes, une par architecture.

Sur x86, le prefetching explicite élimine les défauts de cache. Le noyau principal traite les vecteurs séquentiellement, chaque vecteur étant entièrement calculé avant le suivant, tout en émettant des instructions de prefetching pour le lot suivant. Les données futures sont chargées dans le cache L1 avant que le processeur n'en ait besoin.

Sur ARM, la même approche séquentielle s'est avérée peu performante, même avec prefetching. En revanche, le noyau de traitement par lots entrelace les charges de quatre vecteurs à chaque position d'itération, offrant ainsi au moteur hors séquence quatre flux mémoire indépendants. Le processeur ne récupère pas les données plus rapidement, mais le temps d'attente est réduit en ayant toujours une autre opération à traiter pendant que les requêtes mémoire sont en cours de traitement. Une analyse détaillée est disponible dans ce ticket GitHub.

Les chiffres racontent deux histoires différentes :

1. Sur x86, le prefetching réduit les défauts de cache de 139 000 à 19 000 et double le nombre d'instructions par cycle (IPC). L'avantage en termes de traitement par lots s'accroît avec la taille des données, passant de 1,2 fois pour le cache L2 à 2,8 fois pour les caches au-delà du cache L3, car le prefetching masque les allers-retours DRAM de plus en plus coûteux.

2. Sur ARM, le nombre d'échecs de cache reste pratiquement inchangé. Ce qui change, c'est le taux d'utilisation : les blocages du backend diminuent de 40 % car le modèle d'accès entrelacé assure l'alimentation continue du pipeline. Cet avantage reste constant, à 1,8 fois, quelle que soit la taille de l'ensemble de données, car le parallélisme au niveau de la mémoire s'applique que les données proviennent du cache ou de la DRAM.

Deux architectures, deux stratégies, un résultat : à l'échelle de la production, simdvec maintient le pipeline du processeur occupé même lorsque les vecteurs sont dispersés dans la mémoire principale.

Ce que cela signifie pour les utilisateurs d'Elasticsearch

Ces capacités au niveau du noyau s'additionnent. Une simple requête de recherche vectorielle peut calculer des millions d'opérations de distance : parcours de graphe HNSW, scoring des candidats, reclassement. Sur des milliers de requêtes simultanées, chaque opération, même en nanosecondes, se traduit directement par une latence de requête et un débit de cluster optimaux. Que vous utilisiez float32, int8, bfloat16 ou BBQ, que votre index soit en mémoire ou sur disque, simdvec est le moteur sous-jacent, et chacune de ces opérations s'exécute sur ce même moteur, optimisé à la nanoseconde près.

L'essentiel à retenir est qu'à l'échelle de la production, les performances de la recherche vectorielle ne sont pas principalement déterminées par le débit SIMD brut. Elles dépendent surtout de la capacité du système à masquer efficacement la latence mémoire tout en maintenant la capacité de calcul sur des millions de petites opérations.

Les noyaux simdvec s'améliorent à quasiment chaque nouvelle version d'Elasticsearch. Dès l'apparition de nouveaux types de quantification et de plateformes matérielles, des noyaux optimisés sont intégrés. De plus, les types existants continuent de gagner en vitesse grâce à l'amélioration des implémentations déjà disponibles.

Les organisations amassent d’importantes quantités de documents, tels que des tickets d’assistance, des documents juridiques, des flux de nouvelles et des travaux de recherche ; elles doivent comprendre ce qu’ils contiennent avant d’être en mesure de poser les questions pertinentes. Sans libellés ni données d’entraînement, il est impossible de passer en revue manuellement des milliers de documents. La recherche classique n’est d’aucun secours lorsque vous ne savez pas quoi chercher.

Cet article explore une approche native d’Elasticsearch pour le partitionnement de documents sans supervision et le suivi d’histoires temporelles permettant de pallier ce problème de découverte. Au terme de cette lecture, vous pourrez suivre l’évolution de récits de ce type au fil des jours :

Ce que vous découvrirez :

• Pourquoi le recours aux plongements dédiés au clustering (plutôt qu’à la recherche d’information) est crucial pour identifier des thématiques en l’absence de requête explicite.

• Comment la classification centroïde par densité regroupe les documents par sujet en utilisant Elasticsearch k-nearest neighbor (kNN) et par lots msearch.

• Comment significant_text peut étiqueter automatiquement les clusters pour que les thèmes soient lisibles sans avoir à créer de modèle.

• Comment les chaînes d'histoires temporelles relient le clustering quotidien pour montrer comment les thèmes évoluent de jour en jour.

Le pipeline utilise environ 8 500 articles de février 2025 provenant de BBC News et du Guardian comme corpus de test. Le secteur des informations est idéal car il possède une dynamique temporelle explicite, mais ce schéma s’adapte à tout processus de découverte documentaire : audit juridique, contrôle de conformité, synthèse documentaire, triage du support technique.

Pile :

• Jina v5 Plongements de regroupement : des adaptateurs LoRA (Low-Rank Adaptation) spécifiques à la tâche pour le groupement thématique. Jina a rejoint Elastic, et ses modèles sont directement disponibles par le biais du Elastic Inference Service (EIS).

• Elasticsearch : Scalable kNN, étiquetage significant_text et stockage vectoriel.

• DiskBBQ : format d'index vectoriel sur disque combinant une meilleure quantification binaire (BBQ) et un partitionnement hiérarchique par k-means pour l'accélération de l'approximation des plus proches voisins (ANN). Ce partitionnement de l'index est interne à la recherche vectorielle et distinct de l'algorithme de clustering par densité utilisé dans ce billet. bbq_disk stocke les vecteurs quantifiés sur disque et ne conserve que les métadonnées de partition en tas, réduisant considérablement les besoins en ressources par rapport à bbq_hnsw, tout en maintenant un rappel élevé.

• Clustering global + liaison temporelle quotidienne : découverte et évolution des récits.

Ce dont vous aurez besoin :

• Un déploiement Elasticsearch (Elastic Cloud, Elasticsearch Serverless, ou Elastic Self-Managed 8.18+/9.0+) : bbq_disk nécessite une version 8.18 ou plus récente. La partie optionnelle sur le récupérateur de diversité exige la version 9.3+ ou une solution sans serveur.

• Une clé API Jina: Le niveau gratuit comprend 10 millions de jetons, ce qui couvre le pipeline de clustering de noyau (~4,25 millions de jetons). La comparaison facultative entre la récupération et le clustering utilise un second passage de plongement.

• Une clé API Guardian (gratuite).

Configuration

Installez les packs requis :

Facultatif (uniquement si vous exécutez des assistants de scraping depuis ce dépôt) :

Ensuite, configurez les clés API dans un fichier .env à la racine du projet :

Ce bloc-notes appelle load_dotenv(override=True), donc les valeurs locales .env ont la priorité.

Partie 1 : Clustering de découverte — Pourquoi effectuer un clustering de plongements ?

La plupart des recherches vectorielles utilisent des plongements de récupération entraînés pour associer une requête à des documents pertinents. C'est parfait pour les recherches, mais pas pour les découvertes. Lorsque vous souhaitez trouver les sujets qui existent dans un corpus sans aucune requête, vous avez besoin de plongements qui regroupent des documents similaires.

Jina v5 résout ce problème grâce à des adaptateurs LoRA (Low-Rank Adaptation) spécifiques à chaque tâche. Grâce à LoRA, des ajustements de rang réduit sont injectés dans des couches internes spécifiques tandis que le reste du modèle demeure figé, ce qui réaligne ses capacités sur une tâche donnée sans passer par un cycle de réentraînement complet. Le même modèle de base produit des plongements différents selon le paramètre task :

Tâche

Entraîné pour

Cas d'utilisation

retrieval.passage

Correspondance requête-document

Recherche, génération augmentée par récupération (RAG)

clustering

Regroupement de sujets (optimisé pour des clusters serrés)

Découverte, catégorisation

L'adaptateur de clustering est formé pour rapprocher les documents sur le même sujet dans l'espace d'intégration et éloigner les documents sur des sujets différents. La comparaison visuelle ci-dessous montre clairement la différence.

Recherche et clustering : une comparaison visuelle

Pour observer la différence, un échantillon de documents est intégré avec les deux types de tâches. Le clustering est effectué dans l'espace d'intégration original à 1024 dimensions ; l'approximation uniforme et la projection (UMAP) sont utilisées uniquement pour projeter ces intégrations en 2D à des fins de visualisation. L’UMAP conserve la structure de voisinage local, ce qui facilite la comparaison de la segmentation des clusters.

Ci-dessous, le même échantillon de 480 documents est intégré avec les deux types de tâches et projeté en 2D avec UMAP. Cherchez des groupes de couleurs plus serrés et plus séparés dans le panneau de clustering.

Les plongements de recherche (à gauche) répartissent les sujets de manière large ; les plongements de clustering (à droite) produisent des groupes plus serrés et mieux séparés à partir des mêmes documents.

Les plongements de clustering produisent des groupes plus serrés et plus distincts visuellement. Les plongements de recherche répartissent les sujets de manière plus uniforme, ce qui est idéal pour la recherche (similarité à grain fin) ; mais pour la découverte, ce sont les clusters thématiques serrés qui importent.

C’est pourquoi task="clustering" est utilisé pour le reste de cette explication.

Chargement de l'ensemble de données

Le corpus combine deux sources d'actualités pour février 2025 :

• BBC News via l'ensemble de données RealTimeData/bbc_news_alltime de HuggingFace.

• The Guardian via l’API Open Platform de Guardian.

Le fait d'avoir plusieurs sources permet de vérifier que le clustering permet de trouver des sujets plutôt qu'un style spécifique à la source.

Intégration avec la tâche de clustering

L’API de Jina v5 est sollicitée avec le paramètre task="clustering" pour l’ensemble des documents. Les plongements sont mis en cache sur le disque, de sorte que les exécutions ultérieures ignorent complètement l’API.

L'appel d'API est simple. Le paramètre task est la différence clé avec l’utilisation typique de l’intégration :

Le chronométrage ci-dessous correspond à un accès au cache. La première exécution de l'API prend plus de temps, en fonction de la taille du corpus.

Indexation dans un seul index Elasticsearch

Pour le clustering de découverte, le mois entier est placé dans un seul index (docs-clustering-all). Le partitionnement journalier intervient plus tard, pour la liaison temporelle des articles.

Le mappage d'index utilise bbq_disk pour le champ vectoriel :

Un vecteur Float32 de 1024 dimensions représente 4 Ko. bbq_disk utilise des k-moyens hiérarchiques pour partitionner les vecteurs en petits clusters, les quantifier en binaire et stocker les vecteurs en pleine précision sur disque pour les re-noter. Seules les métadonnées des partitions sont conservées en mémoire vive, ce qui permet de maintenir des exigences matérielles minimales, même avec des volumes de données importants. Pour les charges de travail qui peuvent se permettre plus de mémoire, bbq_hnsw construit un graphe Hierarchical Navigable Small World (HNSW) pour des recherches plus rapides à un coût de ressources plus élevé.

Le type de champ dense_vector prend en charge plusieurs stratégies de quantification : bbq_disk et bbq_hnsw sont les meilleurs ajustements pour les plongements de haute dimension comme les vecteurs 1024-dim utilisés ici.

Clustering : classification de centroïdes par sondage de densité

Les algorithmes de partitionnement classiques tels que HDBSCAN partent du principe que l’intégralité de la matrice vectorielle N×d est stockée en mémoire pour exécuter des cycles de mises à jour exhaustifs. Avec 8 495 documents et 1024 dimensions, la charge est supportable (~35 Mo), toutefois la méthode ne peut s’étendre à des millions de documents sans ressources d’infrastructure additionnelles.

Cet algorithme est conceptuellement proche de l’initialisation KMeans++ avec une affectation de Voronoï et un seuil de bruit, mais il utilise la recherche kNN d’Elasticsearch comme primitive de calcul, ce qui permet de réaliser la quasi-totalité du travail côté serveur :

1. Échantillonner 5 % des documents comme sondes de densité (échantillon aléatoire, minimum 50).

2. Densité des sondes par lots via msearch kNN. Chaque sonde lance une requête kNN et enregistre la similarité moyenne de ses voisins. Similarité moyenne élevée = zone dense de l'espace d'intégration. msearch envoie plusieurs requêtes de recherche en un seul appel HTTP, ce qui est crucial ici : le sondage de densité génère des centaines de requêtes kNN, et leur regroupement par lots permet d’éviter la surcharge liée à chaque requête individuelle.

3. Sélection de germes à haute densité avec diversification : les éléments dont la densité est supérieure à la médiane sont classés par ordre décroissant ; ils sont ensuite retenus selon un algorithme glouton, à condition que leur similarité cosinus par rapport aux germes déjà sélectionnés ne dépasse pas un seuil de séparation défini. C’est le seul calcul côté client (~0,01s pour 8k documents).

4. Classez tous les documents par rapport aux centroïdes via msearch kNN: Chaque graine agit comme un centroïd  ; une recherche kNN permet d'extraire les documents proches au-dessus d'un seuil de similarité. Chaque document est affecté au centroïde qui l'a renvoyé avec le score le plus élevé. Les clusters de taille réduite sont dissous pour être classés comme du bruit.

Elasticsearch s'occupe du gros du travail : msearch pour les sondes de densité, msearch pour la classification et significant_text pour l'étiquetage. Pour ce corpus (8 495 documents), l’échantillon de sonde à densité à 5 % lance des requêtes de sonde de 425 kNN, qui msearch se regroupent en neuf appels HTTP (à la taille de lot 50), évitant ainsi une requête par sonde. Combiné à la recherche bbq_disk ANN, cela permet de rendre la phase de clustering rapide et évolutive. Les requêtes kNN utilisent une valeur minimale num_candidates pour la vitesse lors de la passe de clustering ; les requêtes de recherche de production doivent utiliser des valeurs num_candidates plus élevées pour améliorer le rappel au prix de la latence.

Les tailles naturelles des clusters sont déterminées par la densité d'espace intégrée autour de chaque centroïde, et non par une limite k stricte. Les thématiques denses produisent des clusters plus importants ; les thématiques de niche produisent des clusters plus petits.

Pourquoi pas KMeans ou HDBSCAN ?

KMeans suppose des amas sphériques et nécessite la matrice complète N× en mémoire. Pour les corpus qui tiennent dans la mémoire, HDBSCAN est une alternative solide. Il gère des formes de clusters arbitraires et possède une sémantique de densité bien comprise.

L’approche par centroïdes par sondage de densité cible un créneau différent : les corpus pour lesquels vous souhaitez un système unique de stockage, de récupération et de clustering, ou lorsque l’échelle rend les opérations de matrice côté client peu pratiques. Cette approche emploie le kNN d’Elasticsearch en tant que primitive de calcul, prend en charge n’importe quelle taille de cluster et conserve presque tout le traitement côté serveur.

Comprendre le taux de bruit

Le taux de bruit de ~28% est le résultat d'une conception et non d'un mode de défaillance. Les documents qui ne correspondent à aucun cluster dense au similarity_threshold configuré ne sont pas attribués, plutôt que d’être forcés dans une mauvaise correspondance. Cela agit comme un filtre de qualité : les tribunes d’opinion, les articles courts et les articles ponctuels résistent naturellement au clustering, car ils n’ont pas la densité thématique qui définit un groupe cohérent.

Ce seuil peut être modulé : réduire similarity_threshold génère un clustering plus large (plus de documents intégrés, au prix d’une homogénéité moindre), tandis que son augmentation densifie les clusters et rejette davantage d’éléments comme bruit. Pour ce corpus composé de contenus d’actualité variés, un taux de bruit d’environ 30 % constitue un point de fonctionnement raisonnable. Pour les déploiements en production, il convient de régler le seuil selon les exigences de qualité spécifiques au secteur d’activité.

Étiquettes automatiques avec significant_text

Désormais, chaque cluster a besoin d'une étiquette facile à lire. L’agrégation significant_text d’Elasticsearch permet de trouver les termes dont la fréquence est anormalement élevée dans un groupe spécifique (le cluster) comparativement à l’ensemble du corpus.

Techniquement, il emploie une heuristique statistique (le score JLH par défaut) qui pondère les écarts de fréquence absolue et relative, le tout sans « machine learning » ni sollicitation de modèles de langage (LLM). Un groupe sur la politique britannique peut faire apparaître des termes tels que starmer, labour, downing parce que ces termes sont disproportionnellement fréquents dans ce groupe par rapport à l'ensemble du corpus d'actualités.

Pour ce traitement global, le calcul des étiquettes s’effectue directement face à docs-clustering-all ; ainsi, les données de premier plan et de référence sont extraites de la totalité du mois. Dans la partie 2, l’étiquetage utilise le modèle d’index quotidien (docs-clustering-*), un caractère générique (« wildcard ») qui permet aux requêtes de couvrir simultanément tous les index correspondants, afin d’offrir à significant_text un arrière-plan plus large pour un meilleur contraste.

Voici à quoi ressemble une requête minimale :

significant_text sert également de barrière de qualité : les clusters qui ne produisent aucun terme important n'ont pas de vocabulaire distinctif. Il s’agit de regroupements dépourvus de sens qui devraient être réintégrés au bruit de fond au lieu d’être identifiés par un label erroné.

Une étape de nettoyage déterministe légère supprime les termes d’étiquetage parasites (jetons numériques, mots génériques) et se rabat sur un titre représentatif en cas de besoin. Cela permet de conserver les labels Elasticsearch natifs tout en améliorant la lisibilité.

Visualisation des clusters

Les visualisations ci-dessous montrent ce que la passe de clustering global a découvert : une répartition par date des documents regroupés par rapport au bruit, une projection UMAP du mois complet et un graphique de mixité des sources confirmant que les clusters reflètent les sujets plutôt que les sources.

Distribution quotidienne des documents regroupés par rapport aux documents parasites tout au long de février 2025.

Chaque îlot coloré dans l’UMAP représente un cluster : un groupe d’articles sur le même sujet découvert uniquement par similarité d’intégration. Les points gris de bruit correspondent aux articles qui ne s’intègrent pas clairement dans un cluster (souvent des articles courts, des tribunes libres ou des récits isolés).

Le graphique de répartition des sources confirme que les clusters contiennent des articles de BBC News et The Guardian. Le clustering est de trouver des sujets et non des sources, ce qui correspond exactement à ce que la découverte non supervisée devrait produire.

Exploration de l’étendue des clusters avec le récupérateur de diversification

Le kNN simple renvoie les documents les plus similaires au centroïde d'un cluster (le noyau dense). Mais les vrais clusters couvrent des sous-thèmes. Le récupérateur de diversité utilise la pertinence marginale maximale (MMR) pour faire remonter des documents qui sont à la fois pertinents pour le centroïde et différents les uns des autres.

Le paramètre clé est λ (lambda) :

• λ = 1,0 → pertinence pure (identique à la kNN simple).

• λ = 0,0 → diversité pure (résultats à répartition maximale).

• λ = 0,5 → équilibré : cela est pertinent pour le sujet, tout en couvrant différents aspects.

La structure minimale d’une requête de récupérateur se présente comme suit :

Les paramètres type, field, query_vector sont requis au niveau de diversification : field indique à MMR quel champ dense_vector utiliser pour la similarité entre les résultats, et query_vector fournit le point de référence pour le score de pertinence.

Cela vous permet de répondre à la question : « Que couvre réellement ce groupe ? » au lieu de simplement « Quel est son centre ? »

Les résultats simples kNN se regroupent autour d'un angle du sujet : les documents les plus similaires au centroïde et les uns aux autres. Le récupérateur de diversité fait ressortir différentes facettes d’un même cluster : des sous-thématiques, des sources distinctes et des perspectives variées.

La métrique de diversité valide ce point quantitativement : la similarité moyenne entre paires est plus basse avec le récupérateur de diversité, prouvant que les documents obtenus traitent d’un éventail de sujets plus vaste.

C'est utile pour :

• Comprendre ce que recouvre réellement un groupe, pas seulement son centre mais aussi ses bords.

• Générer des résumés. Des documents représentatifs et variés offrent un meilleur matériel pour un LLM.

• Trouver des exemples représentatifs pour l'évaluation humaine ou l'étiquetage en aval.

• Contrôles qualité. Si les divers résultats semblent incohérents, il se peut que le groupe doive être scindé.

Partie 2 : chaînes d’histoires temporelles

Suivi des histoires au fil des jours

La partie 1 a appliqué le clustering à l’ensemble du mois à l’échelle globale pour la découverte de thématiques. En ce qui concerne le flux temporel, le même processus de classification par centroïde avec sondage de densité est appliqué de manière autonome sur les index journaliers, les clusters étant ensuite mis en relation d’un jour à l’autre. Il est important de noter que les clusters journaliers sont distincts des clusters globaux présentés en partie 1 ; chaque jour produit ses propres attributions de groupes et des labels optimisés pour le contenu du jour même.

L'approche de liaison : échantillonnage et requête

Pour chaque cluster le jour A :

1. Prenez quelques exemples de documents représentatifs.

2. Exécutez la recherche kNN sur l'index du jour B.

3. Comptez le nombre de visites par groupe B par jour.

4. Si la fraction de réussite dépasse un seuil (fraction kNN ≥ 0,4), enregistrez un lien.

Cela est rapide (seuls quelques documents par cluster sont interrogés, pas tous) et utilise le kNN natif d'Elasticsearch, aucun outil externe n'est nécessaire.

Une fraction kNN de 100 % signifie que chaque document échantillonné du cluster source s'est retrouvé dans le même cluster cible, ce qui constitue le lien inter-jours le plus fort possible. La plupart des liens ci-dessus concernent le football, ce qui est logique : la couverture de la Premier League est quotidienne et présente une grande cohérence thématique.

Le lien score | operator | gedling → league | striker | season est un exemple de cluster de football local de niche (Gedling étant un club amateur) absorbé par le cluster plus large de la Premier League le jour suivant, un effet naturel du reclustering quotidien à différents niveaux de granularité.

Création de chaînes d’histoires

Une chaîne d'histoires est une séquence de clusters liés sur des jours consécutifs.

Les liens individuels par paires vous indiquent que le cluster « politique britannique » du lundi est relié à celui du mardi. Les chaînes révèlent l’arc complet : une histoire qui commence le lundi, évolue tout au long de la semaine et s’estompe le vendredi.

Les chaînes sont élaborées selon un algorithme glouton à partir de liens présentant une fraction kNN ≥ 0,4 ; ainsi, au moins 40 % des documents du groupe d’origine se retrouvent dans un groupe de destination unique. En partant du cluster le plus ancien, l'algorithme suit toujours le lien sortant le plus fort.

La chaîne la plus longue suit la couverture Ukraine-Russie pendant 19 jours consécutifs, ce qui n'est pas surprenant étant donné l'intensité géopolitique soutenue en février 2025. La deuxième plus longue suit le football de Premier League pendant 19 jours du mois. Des chaînes plus courtes couvrent la saison des récompenses (cinéma/prix, six jours), le rugby du Tournoi des Six Nations (10 jours) et la couverture du leadership politique au Royaume-Uni (sept jours). Chaque chaîne représente un arc narratif que l'algorithme a découvert uniquement à partir de la similarité des indices quotidiens.

Sankey : Visualisation du flux narratif

Un diagramme de Sankey est une visualisation de flux où la largeur des liens représente la force de la connexion. Ici, chaque bande verticale correspond à un jour, chaque nœud à un cluster quotidien (dimensionné selon le nombre de documents), et chaque chemin coloré suit une chaîne narrative au fil du temps. La largeur des liens encode la force du chevauchement kNN : des liens plus épais signifient qu'un plus grand nombre de documents échantillonnés se sont retrouvés dans le cluster cible. Les couleurs sont cohérentes pour chaque chaîne, de sorte qu'un chemin d'une même couleur de gauche à droite se lit comme la progression d'une histoire.

Par exemple, la chaîne Ukraine–Russie (visible comme l’un des parcours les plus longs) s’étend de façon continue du début du mois de février jusqu’à la troisième semaine, avec des liens constamment épais indiquant une forte continuité thématique d’un jour à l’autre.

Des chaînes narratives temporelles se déroulant en février 2025. Chaque chemin coloré est une histoire qui persiste au fil des jours ; la largeur des liens indique la force de chevauchement en kNN.

Ce que cette approche apporte

Cette présentation couvre un pipeline complet de clustering de documents non supervisé construit sur Elasticsearch :

1. Clustering de plongements : les adaptateurs spécifiques aux tâches de Jina v5 produisent des plongements optimisés pour le regroupement thématique, et non seulement pour la correspondance requête-document.

2. Regroupement global par clusters : en traitant le mois entier au sein d’un index unique, on optimise la détection de thèmes transversaux sur l’ensemble de la période.

3. Classification des centroïdes sondés par densité: échantillon 5 %, densité de la sonde via msearch kNN, sélection de diverses graines à haute densité, classification de toutes les substances par rapport aux centroïdes. Elasticsearch gère la puissance de calcul lourde ; seule la sélection des graines s’exécute côté client (~0,01 s).

4. significant_text Étiquetage par pertinence : les tests de signification produisent des étiquettes de clusters pertinentes sans aucun modèle de « machine learning » ni annotation manuelle. Les clusters qui ne produisent aucun terme significatif sont incohérents et sont relégués au rang de bruit : un portail de qualité intégré.

5. Liaison temporelle d'histoires : Les indices quotidiens et l'index croisé kNN par échantillonnage et interrogation retracent l'évolution des articles dans le temps.

Points clés :

• Le type de tâche de plongement est important : les plongements de clustering produisent des groupes thématiques sensiblement plus resserrés.

• Elasticsearch peut servir à la fois de couche de stockage et de moteur de clustering via kNN search.

• La classification par centroïde basée sur la densité conserve presque tous les calculs côté serveur et produit des clusters de tailles naturelles déterminées par la densité de l'espace de plongement.

• significant_text est rapide, interprétable et efficace pour le marquage automatique et le contrôle de la qualité.

Situations dans lesquelles cette approche est utile :

• Vous disposez de texte horodaté et souhaitez effectuer une découverte de thématiques sans données d'entraînement étiquetées.

• Vous voulez une seule pile pour le stockage, la recherche vectorielle, l’étiquetage et la liaison temporelle.

Extensions à explorer :

• Clustering multi-période (cumuls hebdomadaires et mensuels).

• Ingestion en temps réel avec attribution incrémentale de clusters.

• Résumés de cluster générés par LLM en utilisant les termes significant_text comme germes.

• À plus grande échelle, des centroïdes KMeans échantillonnés peuvent servir de points de départ pour le clustering basé sur la densité, réduisant ainsi le coût de la phase de sondage.

Essayez par vous-même

Ajoutez votre propre corpus de documents horodatés ; toute collection de texte contenant des dates fonctionne avec ce pipeline. Le cahier complet et le code de support sont disponibles dans le référentiel associé.

• Démarrez un essai gratuit d’Elastic Cloud: Lancez un cluster géré avec bbq_disk support en quelques minutes.

• Essayez Elasticsearch Serverless : aucune gestion de cluster, une mise à l’échelle automatique et une prise en charge de l’intégralité de ce guide.

Elasticsearch rejetait les métriques arrivant en retard. Ces rejets ont provoqué un retard dans le pipeline, entraînant davantage de données en retard, ce qui a déclenché encore plus de rejets. Finalement, le pipeline s'est complètement arrêté.

Nous avons dû restaurer les données à partir d'un snapshot, les réindexer et repenser le pipeline d'ingestion pour pouvoir les récupérer.

La cause principale n'était pas la gestion du cycle de vie des index (ILM) elle-même. C'étaient les flux de données temporelles (TSDS) et la manière dont ils imposent des index sous-jacents limités dans le temps.

Les TSDS peuvent réduire les besoins de stockage des métriques de 40 à 70 %, mais les modifications architecturales qui optimisent leur fonctionnement influent également sur l'évolution des index. Ces changements sont importants lors de la conception de politiques ILM ou lorsque vos pipelines d'ingestion sont susceptibles de générer des données arrivant en retard.

RÉSUMÉ

Lors de l'utilisation de TSDS :

• Les index sous-jacents acceptent uniquement les documents compris dans une fenêtre temporelle spécifique.

• Si des données en retard arrivent après qu'un index passe en mode froid ou gelé, Elasticsearch rejette ces documents ou les achemine vers le stockage des échecs, si configuré.

Règle de conception :

Qu'est-ce qu'un flux de données temporelles ?

Un flux de données temporelles (TSDS) est un flux de données spécialisé optimisé pour les données de métriques. Les données sont acheminées de manière à ce que les documents associés soient situés dans les mêmes partitions, optimisant ainsi la requête et la récupération. Voici comment Elasticsearch procède :

Chaque document contient :

• Un horodatage.

• Des champs dimensionnels qui identifient les séries temporelles.

• Des champs de métriques qui représentent les valeurs mesurées.

En voici quelques exemples :

• Utilisation du processeur par hôte.

• Latence des requêtes par service.

• Relevés de température par capteur.

Les dimensions identifient ce que nous voulons mesurer, tandis que les métriques représentent des valeurs qui évoluent au fil du temps.

Dimensions

Les dimensions décrivent l'entité mesurée.

Exemples :

Nous les définissons dans les mappings avec :

Des métriques

Les métriques représentent des valeurs numériques et sont définies comme suit :

Types de métriques courants :

• Jauge : valeurs qui montent et descendent.

• Compteur : valeurs qui augmentent jusqu'à la réinitialisation.

Elastic Agent collecte principalement des métriques et des données de logs, donc même si vous n'avez pas activé d'index TSDS manuellement, il est possible que vous en ayez toujours dans votre cluster.

Le champ _tsid

Elasticsearch génère en interne une valeur _tsid à partir des champs de dimensions. Cela permet d'acheminer les documents de dimensions identiques vers la même partition, ce qui améliore :

• Compression.

• Localité de la requête.

• Performance d'agrégation.

La principale différence : les index sous-jacents à durée déterminée

Les flux de données traditionnels écrivent toujours dans l'index sous-jacent le plus récent, appelé index d'écriture, mais TSDS se comporte différemment.

Chaque index TSDS sous-jacent comporte une fenêtre temporelle définie et n'accepte que les documents dont les valeurs @timestamp se situent dans cette fenêtre :

Lorsqu’un document est indexé, Elasticsearch l’achemine vers l’index sous-jacent responsable de cet horodatage, ce qui signifie que, contrairement aux index traditionnels, un TSDS peut écrire simultanément dans plusieurs index sous-jacents.

Par exemple :

• Données en temps réel → dernier index.

• Données tardives → index plus ancien couvrant cette plage horaire.

Conception pour les données arrivant en retard

Dans la réalité, les pipelines d'ingestion fournissent rarement les métriques dans les délais impartis. Les métriques peuvent être retardées par des pannes de réseau, des accumulations de données en cours de route, l'ingestion par lots et la perte d'appareils en périphérie, qui se reconnectent ensuite et commencent à rattraper leur retard.

Les index traditionnels absorbent discrètement ces retards, ce qui n'est pas le cas des TSDS.

Si l'horodatage d'un document se situe en dehors de la plage des index de support inscriptibles, Elasticsearch le rejette, ce qui signifie que votre politique ILM doit tenir compte des données en retard.

La contrainte critique

Les index sous-jacents doivent rester accessibles en écriture suffisamment longtemps pour accepter les données en retard.

Concrètement :

Étant donné que l'ILM mesure l'âge à partir de la substitution, la règle opérationnelle est la suivante :

Par exemple, si les métriques peuvent arriver jusqu'à six heures en retard, les index doivent rester inscriptibles au moins six heures après la substitution.

L'absence de prise en compte de cette contrainte est exactement ce qui a causé l'échec d'ingestion décrit précédemment. Les données arrivées en retard ont été dirigées vers un index antérieur, qui se trouvait déjà dans le niveau froid et était donc bloqué en écriture.

Gestion des documents rejetés

Lorsqu'un TSDS rejette un document, Elasticsearch renvoie une erreur, indiquant que l'horodatage ne se situe pas dans la plage des index inscriptibles. La façon dont votre pipeline d'ingestion gère cette erreur détermine si vous perdez des données ou si l'ingestion est bloquée.

Le principal mécanisme pour la gestion des documents rejetés est le magasin des échecs.

Stockage des échecs (recommandé dans Elasticsearch 9.1+)

Elasticsearch 9.1 a introduit le magasin des échecs, qui capture automatiquement les documents rejetés. Au lieu de renvoyer des erreurs aux clients, Elasticsearch écrit les échecs de documents dans un index d'échec dédié au sein du flux de données.

Vous pouvez examiner les échecs à l'aide de :

L'utilisation du stockage des échecs empêche les pipelines d'ingestion d'être bloqués par des erreurs de rejet, tout en préservant les données rejetées à des fins d'analyse ou de réindexation.

Surveillance des problèmes de rejet

Les problèmes de retard d'arrivée apparaissent généralement d'abord sous forme d'anomalies d'ingestion. Vous les remarquerez peut-être d'abord comme :

• Des chutes soudaines du taux d'indexation.

• Une forte augmentation du nombre de documents rejetés.

• Un nombre croissant d'entrées de stockage des échecs.

• Incohérences entre les nombres d'entrées et de sorties du pipeline.

Les alertes en fonction de ces signaux permet aux opérateurs de détecter les problèmes avant que les pipelines ne s'arrêtent. Les workflows, les tâches de machine learning et d'autres mécanismes peuvent être utilisés pour automatiser la détection et les notifications.

Checklist de migration pour les TSDS et l'ILM

Si vous migrez un cluster de métriques vers TSDS, introduisez une hiérarchisation ILM ou effectuez une mise à niveau vers une version d'Elasticsearch où les métriques sont TSDS par défaut, consultez d'abord ces éléments.

1. Mesurer la latence d'ingestion

Avant de modifier les politiques ILM, déterminez :

• Le délai d'ingestion normal.

• Le délai maximal en cas d'incident.

• Les retards dus aux pipelines de traitement par lots.

Votre conception ILM doit prendre en compte le délai réaliste maximal.

2. Vérifier les fenêtres temporelles d'index

Vérifiez vos index sous-jacents TSDS :

Recherchez :

• time_series.start_time

• time_series.end_time

Ces limites déterminent quels index peuvent accepter des documents. Comprendre ces délais permet de déterminer la date limite de rejet des données.

3. Dimensionner le niveau hot pour les arrivées tardives

Assurez-vous que les index sous-jacents restent modifiables suffisamment longtemps pour les données en retard.

Règle opérationnelle :

• warm_min_age > rollover_max_age + maximum_expected_lateness

N'oubliez pas que les index doivent rester accessibles en écriture pendant au moins six heures si les métriques peuvent arriver avec six heures de retard.

4. Décider comment traiter les documents rejetés

Choisissez une stratégie avant d'activer TSDS :

• Magasin des échecs (recommandé dans Elasticsearch 9.1+).

• File d'attente des messages Logstash non distribuables.

• Index de repli pour les arrivées tardives.

• Accepter une perte de données limitée.

5. Monitorer l'intégrité de l'ingestion

Ajoutez des alertes pour :

• Le taux d'indexation chute.

• Documents refusés.

• Croissance du magasin des échecs.

• Incohérences entre les entrées et les sorties du pipeline.

Les problèmes de données tardives apparaissent souvent d'abord sous forme d'anomalies d'ingestion.

Résumé

Les flux de données temporelles apportent des améliorations majeures en termes de stockage et de performances pour les charges de travail des métriques, mais ils introduisent un changement architectural important : les index sous-jacents sont limités dans le temps, ce qui affecte le comportement de l'ILM.

Lors de l'utilisation de TSDS :

• Les index doivent rester inscriptibles suffisamment longtemps pour accepter les données différées.

• Les pipelines d'ingestion doivent gérer les documents rejetés de manière sécurisée.

La règle essentielle à retenir est la suivante :

Si vous concevez les politiques ILM en tenant compte de cette contrainte, TSDS fonctionne de manière optimale pour les charges de travail de métriques.

En revanche, si vous ignorez cette règle, votre pipeline d'ingestion risque de découvrir ces limites temporelles à ses dépens.

Votre première requête

Commencez par définir un objet CLR (POCO) classique qui correspond à votre index Elasticsearch. Les noms de propriétés sont résolus en noms de colonnes ES|QL via des attributs standard System.Text.Json, comme [JsonPropertyName], ou via un JsonNamingPolicy configuré. Les mêmes règles de sérialisation des sources que celles qui s'appliquent au reste du client s'appliquent également ici.

Une fois le type défini, une requête ressemble à ceci :

Le fournisseur la traduit en ES|QL comme ceci :

Quelques détails à noter :

• Résolution des noms de propriété : p.Price devient price_usd en raison de l'attribut [JsonPropertyName], et p.Brand devient brand conformément à la politique de dénomination camelCase par défaut.

• Capture des paramètres : les variables C# minPrice et brand sont capturées comme paramètres nommés (?minPrice, ?brand). Elles sont envoyées séparément de la chaîne de requête dans la charge utile JSON, ce qui empêche l'injection et permet la mise en cache du plan de requête côté serveur.

• Flux en continu : QueryAsync<T> renvoie IAsyncEnumerable<T>. Les lignes se matérialisent une à une à mesure de leur arrivée depuis Elasticsearch.

Vous pouvez également inspecter la requête générée et ses paramètres sans l'exécuter :

Comment ça marche ? Petit rappel sur LINQ

Le mécanisme qui rend possibles les fournisseurs LINQ est la distinction entre IEnumerable<T> et IQueryable<T>.

Lorsque vous appelez .Where(p => p.Price > 100) sur un IEnumerable<T>, la lambda est compilée en un Func<Product, bool>, un délégué standard que le runtime exécute en interne. C'est le principe du LINQ-to-Objects.

Lorsque vous appelez la même méthode sur un IQueryable<T>, le compilateur C# enveloppe la lambda dans un Expression<Func<Product, bool>> à la place. Il s'agit d'une structure de données qui représente la structure du code plutôt que sa forme exécutable. L'arbre d'expression peut être inspecté, analysé et traduit dans un autre langage au moment de l'exécution.

L’interface IQueryProvider est le point d’extension. Tout fournisseur peut implémenter CreateQuery<T> et Execute<T> pour traduire ces arbres d’expressions dans une langue cible. Entity Framework utilise ceci pour émettre du SQL. Le fournisseur LINQ to ES|QL l'utilise pour émettre ES|QL.

L'arbre d'expression de la requête ci-dessus ressemble à ceci :

Arbre d'expression de l'exemple de requête.

L'arbre est imbriqué de l'intérieur vers l'extérieur : Take englobe OrderByDescending, qui englobe Where, qui englobe From, qui englobe la racine constante EsqlQueryable<Product>. Le prédicat Where est lui-même un sous-arbre des nœuds BinaryExpression pour les opérateurs &&, >=, et les opérateurs ==, avec des feuilles MemberExpression pour les accès aux propriétés et des captures de fermeture pour les variables minPrice et brand. C'est cette structure de données que le fournisseur parcourt pour produire le code ES|QL final.

Sous le capot : le pipeline de traduction

Le chemin d'une expression LINQ vers les résultats de la requête suit un pipeline en six étapes :

Aperçu du pipeline de traduction.

1. Capture de l'arbre d'expressions

Lorsque vous chaînez .Where(), .OrderBy(), .Take() et d’autres opérateurs sur un IQueryable<T>, l’infrastructure standard de LINQ construit un arbre d’expressions. EsqlQueryable<T> met en œuvre IQueryable<T> et délègue à EsqlQueryProvider.

2. Traduction

Lors de l'exécution de la requête (par énumération, appel de ToList() ou utilisation de await foreach)), le EsqlExpressionVisitor parcourt l'arbre d'expressions de l'intérieur vers l'extérieur. Il envoie chaque appel de méthode LINQ à un visiteur spécialisé :

Visiteur

Est traduit

En

WhereClauseVisitor

.Where(predicate)

Condition WHERE

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

GroupByVisitor

.GroupBy().Select()

STATS ... BY

OrderByVisitor

.OrderBy() / .ThenBy()

Champ SORT [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*, Math.*, méthodes string

Plus de 80 fonctions ES|QL

Lors de la traduction, les variables C# référencées dans les expressions sont capturées comme des paramètres nommés.

3. Modèle de requête

Les visiteurs ne produisent pas directement des chaînes de caractères. À la place, ils produisent des objets QueryCommand , une représentation intermédiaire immuable. Un objet FromCommand, un objet WhereCommand, un objet SortCommand et un objet LimitCommand, chacun représentant une commande de traitement ES|QL. Ces objets sont ensuite regroupés dans un modèle EsqlQuery.

Modèle de requête et schéma de commande.

Ce modèle intermédiaire est découplé de l'arbre d'expression et du format de sortie. Il peut être inspecté, intercepté (via IEsqlQueryInterceptor) ou modifié avant d'être formaté.

4. Formatage

EsqlFormatter parcourt chaque QueryCommand dans l'ordre et produit la chaîne ES|QL finale. Chaque commande devient une ligne, séparée par l'opérateur pipe (|) utilisé par ES|QL pour chaîner les commandes de traitement. Les identificateurs contenant des caractères spéciaux sont automatiquement échappés par des guillemets inversés.

5. Exécution

La chaîne ES|QL formatée et les paramètres capturés sont envoyés au point de terminaison /_query d'Elasticsearch sous forme de charge utile JSON. L'interface IEsqlQueryExecutor masque la couche transport, où l'architecture de packages en couches prend tout son sens.

6. Matérialisation

EsqlResponseReader transmet la réponse JSON sans mettre en mémoire tampon l'ensemble des résultats. Un arbre ColumnLayout, précalculé une fois par requête, mappe les noms de colonnes ES|QL plats (comme address.street, address.city) aux propriétés POCO imbriquées. Chaque ligne est assemblée dans une instance T et renvoyée une par une via IEnumerable<T> ou IAsyncEnumerable<T>.

L'architecture en couches

La fonctionnalité LINQ to ES|QL est répartie sur trois packages :

Architecture des packages. Elastic.Esql est le moteur de traduction pur. Il ne dépend d'aucun HTTP et intègre les visiteurs d'expressions, le modèle de requêtes, le formateur et le lecteur de réponses. Vous pouvez l'utiliser de manière autonome pour créer et analyser des requêtes ES|QL sans connexion à Elasticsearch, ce qui est utile pour les tests, la journalisation des requêtes ou la création de votre propre couche d'exécution.

Elastic.Clients.Esql est un client ES|QL léger et autonome. Il ajoute l'exécution HTTP en plus de Elastic.Esql via Elastic.Transport. Si votre application n'a besoin que d'ES|QL et d'aucune autre API Elasticsearch, il s'agit de l'option de dépendance minimale.

Elastic.Clients.Elasticsearch est le client complet Elasticsearch .NET. Il s'appuie également sur Elastic.Esql et expose le fournisseur LINQ via l'espace de noms client.Esql. C'est le point d'entrée recommandé pour la plupart des applications.

Les deux packages de la couche d'exécution fournissent leur propre implémentation de IEsqlQueryExecutor, l'interface de stratégie qui fait le lien entre la traduction et le transport.

Les trois packages sont compatibles avec Native AOT lorsqu'ils sont utilisés avec un JsonSerializerContext généré par la source. Pour le client complet, consultez la documentation Native AOT.

Au-delà des bases

L'exemple ci-dessus traitait du filtrage, du tri et de la pagination. Le fournisseur prend en charge un ensemble d'opérations plus étendu.

Agrégations

GroupBy, associé aux fonctions d'agrégation dans Select, se traduit en ES|QL STATS ... BYpar :

Projections

Select, avec des types anonymes, génère les commandes EVAL, KEEP et RENAME :

Bibliothèque riche en fonctions

Plus de 80 fonctions ES|QL sont disponibles via la classe EsqlFunctions, couvrant la gestion des dates et heures, des chaînes de caractères, des opérations mathématiques, des adresses IP, la correspondance de modèles et le calcul de scores. Les méthodes standard Math.* et string.* se traduisent également par :

LOOKUP JOIN

Les recherches par index croisé se traduisent en ES|QL LOOKUP JOINpar :

Séquence d'échappement pour ES|QL brut

Pour les fonctionnalités ES|QL non encore prises en charge par le fournisseur LINQ, vous pouvez ajouter des fragments bruts :

Requêtes asynchrones côté serveur

Pour les requêtes de longue durée, soumettez-les pour un traitement en arrière-plan sur le serveur :

Les requêtes asynchrones côté serveur sont particulièrement utiles pour les requêtes analytiques de longue durée/le traitement de grands ensembles de données, qui peuvent dépasser les seuils de délai d'expiration habituels, ou dans les environnements sensibles aux délais d'expiration avec équilibreurs de charge, passerelles API ou proxys qui imposent des délais d'expiration HTTP stricts. Les requêtes asynchrones évitent les interruptions de connexion en découplant la soumission et la récupération des résultats.

Premiers pas

LINQ to ES|QL est disponible à partir de :

• Elastic.Clients.Elasticsearch v9.3.4 (branche 9.x)

• Elastic.Clients.Elasticsearch v8.19.18 (branche 8.x)

Installation depuis NuGet :

dotnet add package Elastic.Clients.Elasticsearch

Les points d’entrée sont sur client.Esql:

Méthode

Retours

Cas d'utilisation

Query<T>(...)

IEnumerable<T>

Exécution synchrone

QueryAsync<T>(...)

IAsyncEnumerable<T>

Streaming asynchrone

CreateQuery<T>()

IEsqlQueryable<T>

Composition et inspection avancées

SubmitAsyncQueryAsync<T>(...)

EsqlAsyncQuery<T>

Requêtes de longue durée côté serveur

Pour une description complète des fonctionnalités, notamment les options de requête, l'accès à plusieurs champs, les objets imbriqués et la gestion des champs à valeurs multiples, consultez la documentation LINQ to ES|QL.

Conclusion

LINQ to ES|QL apporte toute la puissance d'expression de LINQ to C# au langage de requêtes ES|QL d'Elasticsearch, vous permettant d'écrire des requêtes fortement typées et composables sans avoir à les concevoir manuellement. Grâce à la capture automatique des paramètres, la matérialisation en flux continu et une architecture de packages modulaire scalable, allant d'une simple traduction à un client Elasticsearch complet, il s'intègre naturellement aux applications .NET de toute taille. applications .NET de toute taille. Installez le client le plus récent, configurez vos expressions LINQ pour qu'elles pointent vers un index, et laissez le fournisseur gérer le reste.

Pour résoudre ce problème, les moteurs de recherche comme Elasticsearch utilisent deux stratégies d'optimisation principales :

1. Recherche approximative (hierarchical navigable small world [HNSW]) : au lieu de parcourir chaque document, nous construisons un graphe de navigation pour accéder rapidement au voisinage probable de la réponse.

2. Quantification : nous compressons les vecteurs (par exemple, de nombres flottants 32 bits à des entiers 8 bits ou même à des valeurs binaires 1 bit) afin de réduire l'utilisation de la mémoire et d'accélérer les calculs.

Mais l'optimisation s'accompagne souvent d'une taxe : la précision.

La crainte est légitime : "Si je compresse mes données et que je prends des raccourcis pendant la recherche, vais-je manquer les meilleurs résultats ?" "Cette optimisation dégrade-t-elle la pertinence de mon moteur de recherche ?"

Pour prouver que la quantification d'Elastic ne dégrade pas les résultats, nous avons construit un banc d'essai reproductible utilisant l'ensemble de données DBPedia-14 pour calculer exactement la précision (en particulier le rappel) que nous sacrifions pour la vitesse lorsque nous utilisons les optimisations par défaut dans Elasticsearch.

tldr : c'est probablement beaucoup moins cher que vous ne le pensez. Consultez le notebook ici, et essayez par vous-même.

Définitions (pour les non-experts)

Avant d'examiner le code, clarifions certains termes.

• Pertinence ou rappel : la pertinence est subjective (ai-je trouvé des choses intéressantes ?). Le rappel est mathématique. Si la base de données contient 10 documents qui correspondent parfaitement à votre requête sur le plan mathématique et que le moteur de recherche en trouve neuf, votre rappel est de 90 % (ou 0,9).

• Recherche exacte (à plat) : parfois appelée méthode "force brute". Le moteur de recherche analyse chaque document dans un index et calcule la distance.

  • Avantages : rappel parfait à 100 %.

  • Inconvénients : coût de calcul élevé et lenteur à grande échelle.

• Recherche approximative (HNSW) : la méthode "raccourci". Le moteur de recherche construit un graphe HNSW. Il parcourt le graphe pour trouver les voisins les plus proches.

  • Avantages : extrêmement rapide et scalable.

  • Inconvénients : vous risquez de manquer un voisin si le parcours du graphe s'arrête trop tôt.

L'expérience : exact versus approximatif

Pour tester le rappel, nous avons utilisé l'ensemble de données DBPedia-14, un grand ensemble de données de titres et de résumés répartis en 14 classes ontologiques, couramment utilisé pour l'entraînement et l'évaluation des modèles de catégorisation de texte. Plus précisément, nous nous concentrerons sur la catégorie "Film". Nous voulions comparer les paramètres de production optimisés à une vérité terrain mathématiquement parfaite.

Pour cette expérience, nous utilisons le modèle jina-embeddings-v5-text-small, un modèle multilingue de pointe qui fait référence dans le secteur de la représentation textuelle. Nous avons choisi ce modèle car il définit la norme actuelle pour les plongements lexicaux haute performance. En combinant l'excellente précision de Jina v5 avec la quantification native d'Elasticsearch, nous pouvons démontrer une architecture de recherche à la fois efficace en termes de calcul et garantissant une qualité de récupération optimale.

Nous avons configuré un index avec un double mapping. Nous avons ingéré le même texte dans deux champs différents simultanément :

1. content.rawavec le type : flat. Cela force Elasticsearch à effectuer une analyse exhaustive de l'ensemble des vecteurs Float32. Cette analyse renvoie des résultats de correspondance exacte qui serviront de référence.

2. contentavec le type semantic_text. Paramètres par défaut utilisant HNSW + Better Binary Quantization (BBQ). Il s'agit du paramétrage standard optimisé pour la production, permettant une correspondance approximative.

Le test Recall@10

Pour notre métrique, nous avons utilisé Recall@10.

Nous avons choisi 50 films au hasard et lancé la même requête sur les deux champs.

• Si la recherche exacte (à plat) indique que les 10 premiers voisins sont les ID [1, 2, 3... 10].

• Et que la recherche approximative (HNSW) renvoie les identifiants [1, 2, 3… 9, 99].

• Nous avons trouvé neuf des 10 premiers correctement. Le score est 0,9.

Voici le mapping que nous avons utilisé :

Les résultats : la "ligne plate" du succès

Nous avons effectué un test d'échelle, en rechargeant l'ensemble de données complet et en le testant par rapport à des index de 1 000 à 40 000 documents.

Voici ce qui est arrivé au score de rappel :

Documents

Score de rappel à 10

1 000

1,000 (100 %)

5 000

0,998 (100 %)

10 000

0,992 (99,4 %)

20,000

0,999 (99,0 %)

40 000

0,992 (98,8 %)

Les résultats étaient incroyablement stables. Même en augmentant l'échelle, la recherche approximative correspondait à la recherche exacte par force brute >99 % du temps.

Pourquoi cela a-t-il si bien fonctionné ?

On pourrait s'attendre à ce que la compression des vecteurs en valeurs binaires nuise davantage à la précision. La raison en est liée à la façon dont Elasticsearch gère la récupération.

La plupart des modèles de plongement actuels génèrent des vecteurs Float32 en sortie, qui sont de grande taille. Pour optimiser la recherche, Elasticsearch utilise la quantification pour les vecteurs de grande dimension. Plus précisément, depuis la version 9.2, il utilise BBQ par défaut.

BBQ utilise un mécanisme de rescoring :

1. Parcours : le moteur de recherche utilise les vecteurs compressés (quantifiés) pour parcourir rapidement le graphe HNSW. Grâce à la petite taille des vecteurs, il peut effectuer un suréchantillonnage efficace, générant ainsi une liste plus longue de candidats (par exemple, les 100 documents les plus similaires) sans dégradation des performances.

2. Rescoring : une fois ces candidats identifiés, le système récupère les valeurs de pleine précision pour ces quelques documents uniquement afin de calculer le classement final et précis.

Vous obtenez le meilleur des deux mondes : la rapidité de la quantification pour les opérations les plus lourdes et la précision des nombres à virgule flottante pour le tri final.

Pouvons-nous faire mieux ?

Il est important de noter que les résultats présentés ici utilisent les paramètres par défaut et un échantillon aléatoire de données. Considérez-les comme un point de départ performant. Bien que Jina v5 soit extrêmement puissant, ces scores de rappel ne constituent pas une garantie universelle pour tous les ensembles de données. Chaque ensemble de données présente ses propres spécificités, et même s'il est possible d'optimiser davantage les paramètres pour obtenir des performances encore meilleures, il est toujours conseillé de réaliser des tests comparatifs avec vos propres données afin d'en déterminer les limites.

Conclusion

Il s'agit d'un test à très petite échelle. L'objectif de cet exercice n'est pas de mesurer le modèle d'intégration ou BBQ en particulier, mais de démontrer comment mesurer facilement le rappel de votre ensemble de données avec une configuration minimale.

Si vous souhaitez effectuer ce test sur vos propres données, vous pouvez consulter le notebook ici et essayer par vous-même.

Dans HNSW, la recherche s'effectue par expansion itérative des nodes candidats dans le graphe, en conservant un ensemble limité des voisins les plus proches découverts jusqu'à présent. Chaque expansion a un coût (opérations vectorielles, recherches aléatoires sur disque, etc.), et le bénéfice marginal de ce coût tend à diminuer à mesure que la recherche progresse.

Une façon d'optimiser le parcours du graphe HNSW est d'interrompre la recherche lorsque la probabilité marginale de trouver de nouveaux les plus proches n'augmente plus. C'est pourquoi, dans Elasticsearch 9.2, nous avons introduit un nouveau mécanisme d'arrêt précoce. Ce mécanisme interrompt la recherche lorsque la visite des nodes du graphe ne fournit pas suffisamment de nouveaux voisins les plus proches, de façon consécutive, pendant un nombre déterminé de fois.

Cet article explique comment nous avons amélioré le mécanisme mentionné d'arrêt précoce dans HNSW afin de mieux l'adapter à différents ensembles de données et distributions de données.

Arrêt précoce dans HNSW

Dans HNSW, la recherche se déroule en étendant itérativement les nodes candidats dans le graphe de proximité, en conservant un ensemble limité des voisins les plus proches découverts jusqu'à présent, jusqu'à avoir exploré l'ensemble du graphe ou répondu à certains critères d'arrêt précoce.

L'arrêt précoce n'est donc pas toujours une optimisation ; il fait partie intégrante de l'algorithme de recherche lui-même. Le moment où nous décidons d'interrompre la recherche détermine l'équilibre entre l'efficacité et le rappel. Dans Elasticsearch, il existe déjà plusieurs façons d'interrompre prématurément une requête sur HNSW :

• Un nombre maximal déterminé de nodes est exploré.

• Un délai d'expiration déterminé est atteint.

Bien que simples et prévisibles, ces règles sont largement indépendantes de ce qu'effectue réellement la recherche. De plus, elles servent principalement à garantir que la requête se termine dans un délai raisonnable pour l'utilisateur final.

Dans un article de blog précédent, nous avons introduit le concept de redondance dans HNSW. En bref, les calculs redondants se produisent lorsque HNSW continue d'évaluer de nouveaux nodes candidats qui ne permettent pas de trouver davantage de voisins les plus proches.

Patience : mesurer les progrès plutôt que les efforts

La notion de patience recadre l'arrêt précoce sur le progrès plutôt que sur l'effort.

Au lieu de demander :

"Combien d'étapes avons-nous franchies ?"

La nouvelle question devient :

« Quelle est la quantité de calcul que nous acceptons de gaspiller, jusqu'à ce que nous perdions espoir ? »

Lors d'une recherche HNSW, l'exploration précoce génère généralement des améliorations maximales de l'ensemble des k meilleurs candidats. Au cours des premières étapes de l'exploration du graphe HNSW, l'ensemble des voisins est mis à jour en continu à mesure que l'algorithme découvre des voisins de plus en plus proches du vecteur de requête. Avec le temps, ces améliorations deviennent plus rares à mesure que la recherche converge. L'arrêt basé sur la patience surveille ce schéma et interrompt la recherche lorsque les améliorations cessent de se produire pendant une période prolongée.

En pratique, lors de l'exploration du graphe HNSW, nous calculons également le taux de saturation de la file d'attente à chaque étape du parcours des nodes candidats. Ce taux mesure le pourcentage de voisins les plus proches restés inchangés lors de la visite du dernier node du graphe (ou l'inverse du nombre de nouveaux voisins introduits lors de la dernière itération). Si ce taux devient trop élevé pendant plusieurs itérations consécutives, l'exploration du graphe est interrompue.

D'un point de vue conceptuel, la patience considère la recherche HNSW comme un processus à rendements décroissants. Lorsque les rendements se stabilisent, continuer à explorer le graphe apporte peu d'avantages.

Ce recadrage est puissant car il lie directement l'arrêt aux résultats observables plutôt qu'à des limites fixes arbitraires.

L'avantage de cette technique d'arrêt précoce intelligent est que les explorations de graphes HNSW ont tendance à visiter un nombre plus restreint de nodes tout en conservant un rappel relatif quasi parfait.

Pour visualiser cela, nous pouvons tracer le nombre de rappels par node visité que nous avons obtenus avec l'arrêt précoce basé sur la patience (étiqueté et=static), par rapport au comportement par défaut du HNSW (étiqueté et=no) sur quelques ensembles de données, FinancialQA et Quora, ainsi que des modèles JinaV3 et E5-small.

Seuils statiques et dynamiques HNSW

Dans Elasticsearch, cela se traduit concrètement par l'utilisation de seuils statiques. Le premier seuil correspond au seuil de saturation, c'est-à-dire le niveau de saturation que nous considérons comme sous-optimal. Le second seuil correspond au nombre de nodes consécutifs du graphe pouvant être visités tout en maintenant une saturation de la file d'attente sous-optimale, soit le seuil de patience.

Lors de l'introduction de cette stratégie d'arrêt précoce dans Elasticsearch 9.2, nous avons opté pour des valeurs par défaut prudentes afin de maximiser le rappel tout en optimisant la latence et la consommation de mémoire. C'est pourquoi nous avons fixé le seuil de saturation à 100 % et le seuil de patience à 30 % (limité) de la valeur de num_candidates dans la requête KNN.

Dans de nombreux cas, ces paramètres ont donné de bons résultats. Cependant, deux requêtes demandant le même nombre de voisins peuvent avoir des comportements de convergence radicalement différents. Certaines requêtes rencontrent des voisinages locaux denses et saturent rapidement ; d'autres doivent parcourir de longs chemins épars avant de trouver des candidats compétitifs. Ces dernières se sont avérées les plus difficiles à gérer efficacement.

De ce fait, nous avons parfois constaté :

• Une surexploration pour les requêtes simples.

• Un arrêt prématuré pour les requêtes complexes.

Nous avons donc estimé que les valeurs de seuil déterminées codifiaient des hypothèses globales sur la convergence, alors que nous pouvions mieux adapter le HNSW à différentes dynamiques.

Rendre l'arrêt précoce de HNSW adaptatif

L'arrêt précoce adaptatif aborde ce problème sous un angle différent. Au lieu d'imposer des seuils d'arrêt prédéfinis, l'algorithme détermine le moment où il doit s'arrêter à partir de la dynamique de recherche elle-même.

Ainsi, au lieu de comparer le taux de saturation de la file d'attente entre deux candidats consécutifs, nous avons décidé d'introduire à la fois un taux de découverte lissé instantané (combien de nouveaux voisins ont été introduits pour une requête q lors de la dernière visite i), ainsi qu'une moyenne glissante et un écart-type d'un tel taux de découverte pendant la visite du graphe (en utilisant l'algorithme de Welford). Ces statistiques sur le taux de découverte sont calculées par requête, permettant ainsi de déterminer différents niveaux de patience pour chacune d'entre elles.

Les seuils auparavant statiques deviennent adaptatifs aux statistiques du taux de découverte : le seuil de saturation devient la moyenne mobile plus l'écart type, tandis que nous faisons en sorte que la patience s'adapte et évolue inversement avec l'écart type.

Les règles de sortie précoce restent les mêmes ; la saturation survient lorsque le taux de découverte instantané est inférieur au seuil de saturation adaptatif. La visite du graphe s'arrête si la saturation persiste pendant un nombre d'explorations de candidats consécutives supérieur au seuil de patience adaptatif.

De cette façon, nous obtenons un comportement qui ne dépend pas du paramètre num_candidates dans la requête KNN (qui peut toujours être défini ou laissé par défaut, indépendamment d'une sortie anticipée) et qui s'adapte mieux à chaque requête et distribution vectorielle de manière dynamique.

Le rappel par node visité sur FinancialQA et Quora avec la stratégie adaptative (étiquetée et=adaptive) indique un rappel plus élevé par node visité, par rapport à la stratégie statique (et=static) et au comportement par défaut de HNSW (et=no).

L'arrêt précoce adaptatif est activé par défaut dans Elasticsearch 9.3 pour les champs vectoriels denses HNSW (et peut éventuellement être désactivé via le même paramètre de niveau d'index).

Sur un corpus de 20 millions de documents, nos benchmarks révèlent qu’Elasticsearch multiplie par 8 le débit d’OpenSearch en recherche vectorielle filtrée, avec un Recall@100 supérieur dans toutes les configurations évaluées. L’ingénierie de contexte va au-delà de la performance brute de la récupération vectorielle. Une pertinence maîtrisée (recherche hybride, filtrage), une exploitation simplifiée et des performances constantes sont tout aussi essentielles pour les équipes lors de l’évolution de leurs workflows. Comme les agents effectuent fréquemment des cycles itératifs de récupération et de raisonnement pour chaque demande, la latence de recherche agit comme un facteur multiplicatif. Toute optimisation ici améliore donc instantanément la réactivité de bout en bout et diminue les coûts d’exploitation.

Pour l'ingénierie du contexte, la récupération n'est pas une étape unique. Les agents et les applications effectuent de manière répétée des exécutions de boucles, telles que récupérer → raisonner → récupérer, pour affiner les requêtes, vérifier les faits, assembler un contexte étayé et accomplir les tâches. Ce schéma est courant dans les workflows d'agents et la Retrieval-Augmented Generation (RAG) itérative. Comme la récupération peut être sollicitée de nombreuses fois pour une seule requête utilisateur, elle ajoute un délai à la réponse et/ou augmente les coûts d’infrastructure.

Pourquoi la performance de la recherche vectorielle est-elle critique ?

Imaginez la réponse d’un assistant d’achat à cette requête : « Il me faut un sac à dos de type bagage à main à moins de 60 $, adapté à un ordinateur de 15 pouces, résistant à l’eau et disponible en livraison d’ici vendredi. »

Dans un environnement de production, il est rare que l’assistant lance une unique recherche vectorielle et en reste là. L’assistant lance une boucle de recherche afin d’élaborer le bon contexte, chaque phase étant soumise à des filtres précis : disponibilité, zone géographique, délais de livraison, image de marque ou encore conformité aux politiques internes.

Étape 1 : interpréter l'intention et traduire en contraintes.

L’agent transforme la requête en filtres structurés et en une recherche sémantique, comme suit :

• Filtres : en stock, livrable à l'utilisateur à son code postal, livraison avant vendredi, prix inférieur à 60 $, annonce valide

• Requête vectorielle : « Sac à dos cabine ordinateur 15 pouces résistant à l’eau »

Étape 2 : récupérer les candidats, puis affiner.

Elle répète souvent la récupération avec des variantes afin de ne pas manquer de bonnes correspondances :

• « sac à dos de voyage cabine compartiment ordinateur »

• « sac à dos de trajet quotidien, résistant à l’eau, ordinateur 15 pouces »

• « sac à dos de cabine léger »

Chaque requête utilise les mêmes filtres d’éligibilité, car récupérer des éléments non pertinents ou indisponibles constitue un gaspillage de contexte.

Étape 3 : Élargir la recherche pour confirmer les détails et réduire les risques.

L’agent effectue une récupération supplémentaire pour valider les attributs déterminants du résultat final :

• Formulation concernant les matériaux et la résistance à l’eau

• Dimensions et compatibilité du compartiment pour ordinateur portable

• Modalités de retour et clauses de garantie

• Options alternatives en cas de stock faible

Ceci est l'ingénierie contextuelle en plusieurs étapes : Récupérer, raisonner, récupérer, assembler.

L’importance de la latence et du rappel dans l’ingénierie de contexte

Ces interactions peuvent impliquer des dizaines d’appels de récupération filtrés par session utilisateur. La latence par appel est donc un multiplicateur direct du temps de réponse de bout en bout, et un faible taux de rappel oblige à des tentatives supplémentaires ou amène l'agent à manquer des éléments éligibles, ce qui dégrade la qualité de la réponse.

À retenir : Dans les systèmes d’ingénierie de contexte, la recherche filtrée des plus proches voisins (ANN) n’est pas une simple requête unique. C’est une suite d’opérations sous contraintes : la performance de la recherche vectorielle se traduit donc directement en termes de latence, de débit et de coûts, alors même que le LLM capte toute l’attention en surface.

Évaluation comparative

Résultats

Dans le graphe 2, chaque point représente une configuration de test. Les performances optimales apparaissent dans le coin supérieur gauche : c’est là que le rappel est le plus important et la latence la plus réduite. Les données d’Elasticsearch se rapprochent davantage du coin supérieur gauche que celles d’OpenSearch, signe d’une vitesse et d’une précision accrues pour une même charge de travail.

Quelques informations clés

• s_n_r_value: Abréviation pour size_numCandidates_rescoreOversample (k et numCandidates sont égaux à numCandidates dans ces tests) ; par exemple, 100_500_1 signifie taille=100, candidats=500 et k=500, rescore oversample=1

• Rappel : Mesure du Rappel@100 pour cette configuration spécifique

• Latence moyenne (ms) : Temps de réponse moyen de bout en bout par requête

• Débit : requêtes par seconde (QPS)

• Pourcentage de rappel : Amélioration relative du rappel pour Elasticsearch comparativement à OpenSearch ((Elasticsearch - OpenSearch) / OpenSearch)

• Latence Xs : latence moyenne d'OpenSearch divisée par la latence moyenne d'Elasticsearch

• Débit Xs : débit Elasticsearch divisé par le débit OpenSearch

Moteur

`s_n_r_value`

Rappel

Latence moyenne (ms)

Débit

Rappel %

Latence Xs

Débit Xs

Elasticsearch

100_250_1

0,7704

25

534,75

9,70 %

2,28

1,91

OpenSearch

100_250_1

0,7023

57,08

279,58

Elasticsearch

100_500_1

0,8577

25,42

524,14

7,20 %

2.4

2

OpenSearch

100_500_1

0,8001

60,9

262,12

Elasticsearch

100_750_1

0,8947

29,67

528,09

5,72 %

2,25

2,21

OpenSearch

100_750_1

0,8463

66,76

239,11

Elasticsearch

100_1000_1

0,9156

29,65

534,5

4,66 %

2,46

2,44

OpenSearch

100_1000_1

0,8748

72,88

219,01

Elasticsearch

100_1500_1

0,9386

31,84

497,3

3,38 %

2,71

2,68

OpenSearch

100_1500_1

0,9079

86,16

185,4

Elasticsearch

100_2000_1

0,9507

34,69

457,2

2,57 %

2,98

2,96

OpenSearch

100_2000_1

0,9269

103,36

154,55

Elasticsearch

100_2500_1

0,9582

37,9

418,43

1,99 %

3,28

3,26

OpenSearch

100_2500_1

0,9395

124,29

128,53

Elasticsearch

100_3000_1

0,9636

41,86

379,4

1,62 %

3,46

3,44

OpenSearch

100_3000_1

0,9482

144,67

110,34

Elasticsearch

100_4000_1

0,9705

50,28

316,21

1,06 %

3,87

3,85

OpenSearch

100_4000_1

0,9603

194,36

82,22

Elasticsearch

100_5000_1

0,9749

58,77

270,91

0,73 %

4,43

4,41

OpenSearch

100_5000_1

0,9678

260,33

61,38

Elasticsearch

100_6000_1

0,9781

66,75

238,59

0,52 %

4,91

4,89

OpenSearch

100_6000_1

0,973

327,44

48,81

Elasticsearch

100_7000_1

0,9804

74,64

213,49

0,38 %

5,28

5,27

OpenSearch

100_7000_1

0,9767

394,24

40,53

Elasticsearch

100_8000_1

0,9823

82,28

193,59

0,27 %

6,86

6,83

OpenSearch

100_8000_1

0,9797

564,14

28,33

Elasticsearch

100_9000_1

0,9837

90,08

176,96

0,16 %

7,63

7,61

OpenSearch

100_9000_1

0,9821

687,25

23,25

Elasticsearch

100_10000_1

0,9848

97,64

163,31

0,08 %

8,38

8,36

OpenSearch

100_10000_1

0,984

818,64

19,53

Par exemple, à 100_9000_1, OpenSearch enregistre en moyenne 687 millisecondes par extraction, contre 90 millisecondes pour Elasticsearch, et dans une boucle de récupération en 10 étapes, cela représente environ 10 × (687 - 90) = six secondes de temps d’attente supplémentaire.

Découvrez les résultats complets.

Méthodologie

À l’aide de Python pour l’envoi des requêtes et le suivi de la latence ainsi que des données statistiques, nous avons soumis les requêtes suivantes aux moteurs. N’oubliez pas que l’efficacité d’un moteur vectoriel repose sur l’ajustement de ses paramètres clés : le nombre de candidats analysés, le niveau d’agressivité du score de pertinence et la quantité de contexte fournie en retour. Ces configurations agissent directement sur le rappel (l’assurance de ne pas manquer la réponse adéquate) et sur la latence (la vélocité du traitement).

Pour nos tests, nous avons conservé les mêmes réglages de sélection de candidats, de nouveau calcul de score et de dimension de contexte que ceux d’un cycle de récupération itératif, puis nous avons mesuré l’efficacité d’Elasticsearch face à ce volume de données. Par la suite, nous avons testé OpenSearch avec une configuration identique afin d’établir un point de comparaison.

OpenSearch

• "size": <RESULT_SIZE>: Nombre de résultats renvoyés au client. Pour ce benchmark, nous avons défini une taille de résultat de 100 pour l’évaluation du Rappel@100.

• "k": <NUMBER_OF_CANDIDATES>: Le nombre de candidats voisins les plus proches.

• "ef_search": <NUMBER_OF_CANDIDATES>: Lle nombre de vecteurs à examiner.

• "oversample_factor": <OVERSAMPLE>: Combien de vecteurs candidats sont récupérés avant réévaluation.

Elasticsearch

• "size": <RESULT_SIZE>: Nombre de résultats renvoyés au client. Pour ce benchmark, nous avons défini une taille de résultat de 100 pour l’évaluation du Rappel@100.

• "k": <NUMBER_OF_CANDIDATES>: Nombre de voisins les plus proches à renvoyer de chaque partition.

• "num_candidates": <NUMBER_OF_CANDIDATES>: Nombre de candidats au plus proche voisin à considérer par partition lors d'une opération de recherche knn.

• "oversample": <OVERSAMPLE>: Combien de vecteurs candidats sont récupérés avant réévaluation.

Exemple

Knn la requête, (100_500_1), serait la suivante :

OpenSearch

Elasticsearch

La configuration complète, ainsi que les scripts Terraform, les manifestes Kubernetes et le code de test de performance, sont disponibles dans ce dépôt dans le dossier es-9.3-vs-os-3.5-vector-search.

Configuration du clustering

Nous avons utilisé six instances cloud de type e2-standard-16 pour nos tests, chacune équipée de 16 vCPUs et de 64 Go de mémoire vive. Nous avons configuré chaque pod Kubernetes hébergeant un node du moteur avec 15 vCPUs et 56 Go de RAM, en réservant 28 Go pour la mémoire de la JVM.

Les tests ont été effectués sur les versions 9.3.0 d’Elasticsearch et 3.5.0 d’OpenSearch. (Lucene 10,3,2). Comme les deux solutions reposent sur la même version de Lucene pour ce test, les écarts de performance constatés au niveau du débit et de la latence ne s’expliquent pas par le moteur de base, mais par la façon dont chaque plateforme orchestre la recherche kNN filtrée et les étapes de calcul de score. Pour ce test, nous avons configuré un index unique comportant trois shards primaires et une réplique (ce qui donne 6 partitions au total, soit 1 par node).

Nous avons par ailleurs mobilisé un serveur séparé, situé dans la même région, afin de faire tourner le client de test et de compiler les données de performance.

L’ensemble de données

Pour ce test de performance, nous avons exploité un catalogue e-commerce de 20 millions de documents (embeddings), afin de simuler une recherche vectorielle avec filtres à l’échelle d’une application de production.

Chaque document représente un élément de catalogue et comprend :

• Un vecteur dense à 128 dimensions utilisé pour la recherche approximative par kNN.

• Champs de métadonnées structurés servant au filtrage (disponibilité, validité des produits, etc.), afin de simuler la récupération de vecteurs voisins restreinte à une sélection de données qualifiées, comme c’est souvent le cas en environnement réel.

Nous avons opté pour ces données car elles reflètent la problématique critique des systèmes de production actuels : le besoin de filtrage systématique qui vient s’ajouter à la recherche vectorielle, exigeant une efficacité maximale tant en termes de précision que de rapidité. Par rapport à des bases de données de petite taille, l’utilisation de 20 millions de documents permet de mieux simuler la charge de travail et la complexité de sélection des candidats rencontrées par les moteurs de recherche vectorielle filtrée dans un environnement réel.

Conclusion

Pour les systèmes d’IA de nouvelle génération, notamment ceux qui reposent sur la gestion dynamique du contexte, la performance brute de la recherche par vecteurs est un élément structurant de l’expérience utilisateur. C’est un facteur multiplicateur. Dans les architectures où les agents enchaînent les étapes de recherche et de réflexion, l’efficacité de la récupération détermine non seulement la rapidité de la réponse finale, mais aussi la pertinence des informations transmises au LLM.

Elasticsearch a fait preuve d’une supériorité constante lors de nos tests, affichant un meilleur rappel et une latence réduite par rapport à OpenSearch, particulièrement lorsque la précision de la recherche repose sur l’identification du document spécifique plutôt que sur une vague ressemblance vectorielle. Sur un ensemble de données contrôlé, la différence est nette, et en production, ces gains s’accumulent au fil de volumes massifs d’appels de récupération, améliorant la réactivité, augmentant la marge de capacité et réduisant les coûts d’infrastructure.

Lecture complémentaire

1. Qu'est-ce que l'ingénierie contextuelle ?

2. L'évolution du rechercher hybride et de l'ingénierie contextuelle

3. L'impact de la pertinence dans l'ingénierie du contexte pour les agents IA

Récapitulatif

Tout d'abord, faisons le point sur la situation. Elasticsearch s'est imposé comme une base de données vectorielle puissante, offrant un ensemble complet de fonctionnalités et des performances élevées pour la recherche de similitudes à grande échelle. Avec des capacités telles que la quantification scalaire, la quantification binaire améliorée (BBQ), les opérations vectorielles SIMD et des algorithmes plus efficaces en termes d'espace disque comme DiskBBQ, il offre déjà des options efficaces et flexibles pour gérer les charges de travail vectorielles.

En intégrant NVIDIA cuVS en tant que module accessible pour les tâches de recherche vectorielle, nous visons à améliorer considérablement les performances et l'efficacité de l'indexation vectorielle afin de mieux prendre en charge les charges de travail vectorielles à grande échelle.

Le défi

L'un des défis les plus complexes dans la création d'une base de données vectorielle haute performance est la construction de l'index vectoriel, le graphe HNSW. La construction de l'index est rapidement dominée par des millions, voire des milliards d'opérations arithmétiques, car chaque vecteur est comparé à de nombreux autres. De plus, les opérations liées au cycle de vie des index, telles que la compression et les fusions, peuvent augmenter davantage la charge de calcul globale liée à l'indexation. À mesure que les volumes de données et les intégrations vectorielles associées augmentent de manière exponentielle, les GPU de calcul accéléré, conçus pour le parallélisme massif et les calculs mathématiques à haut débit, sont idéalement positionnés pour gérer ces charges de travail.

Installez le plugin Elasticsearch-GPU

NVIDIA cuVS est une bibliothèque open source CUDA-X pour la recherche vectorielle accélérée par GPU et le clustering de données, permettant une création rapide d'index et une récupération d'embeddings pour les charges de travail liées à l'IA et aux recommandations.

Elasticsearch utilise cuVS via cuvs-java, une bibliothèque open-source développée par la communauté et gérée par NVIDIA. La bibliothèque cuvs-java est légère et repose sur l'API cuVS C en utilisant Panama Foreign Function pour exposer les fonctionnalités cuVS d'une manière idiomatique Java, tout en restant moderne et performante.

La bibliothèque cuvs-java est intégrée dans un nouveau plug-in Elasticsearch ; par conséquent, l'indexation vectorielle sur le GPU peut être effectuée sur le même node et processus Elasticsearch, sans qu'il soit nécessaire de provisionner du code ou du matériel externe. Lors de la création d'index, si la bibliothèque cuVS est installée et qu'un GPU est présent et configuré, Elasticsearch utilisera le GPU pour accélérer le processus d'indexation vectorielle. Les vecteurs sont transmis au GPU, qui crée un un graphe CAGRA. Ce graphe est ensuite converti au format HNSW, ce qui le rend immédiatement disponible pour la rechercher vectorielle sur le processeur. Le format final du graphe construit est identique à celui qui serait construit sur le CPU ; cela permet à Elasticsearch d'exploiter les GPU pour une indexation vectorielle à haut débit lorsque le matériel sous-jacent le prend en charge, tout en libérant la puissance du CPU pour d'autres tâches (recherche simultanée, traitement des données, etc.).

Accélération de la création d'index

Dans le cadre de l'intégration de l'accélération GPU dans Elasticsearch, plusieurs améliorations ont été apportées à cuvs-java, en mettant l'accent sur l'efficacité de l'entrée/sortie de données et l'invocation de fonctions. L'une des principales améliorations est l'utilisation de cuVSMatrix pour modéliser de manière transparente les vecteurs, qu'ils se trouvent sur le tas Java, hors tas ou dans la mémoire du GPU. Cela permet aux données de se déplacer efficacement entre la mémoire et le GPU, en évitant les copies inutiles de milliards de vecteurs potentiels.

Grâce à cette abstraction sous-jacente sans copie, le transfert vers la mémoire GPU et la récupération du graphe peuvent être effectués directement. Pendant l'indexation, les vecteurs sont d'abord mis en mémoire tampon sur le tas Java, puis envoyés au GPU pour construire le graphe CAGRA. Le graphe est ensuite récupéré à partir du GPU, converti au format HNSW et persisté sur le disque.

Au moment de la fusion, les vecteurs sont déjà stockés sur le disque, contournant ainsi entièrement le tas Java. Les fichiers d'index sont mappés en mémoire et les données sont transférées directement dans la mémoire du GPU. La conception s'adapte également facilement à différentes largeurs de bits, telles que float32 ou int8, et s'étend naturellement à d'autres schémas de quantification.

Roulement de tambour... alors, comment ça fonctionne ?

Avant d'examiner les chiffres, un peu de contexte s'impose. La fusion des segments dans Elasticsearch s'exécute généralement automatiquement en arrière-plan pendant l'indexation, ce qui rend difficile l'évaluation comparative de manière isolée. Pour obtenir des résultats reproductibles, nous avons utilisé la fusion forcée pour déclencher explicitement la fusion des segments dans une expérience contrôlée. Comme la fusion forcée effectue les mêmes opérations de fusion sous-jacentes que la fusion en arrière-plan, ses performances servent d'indicateur utile des améliorations attendues, même si les gains exacts peuvent différer selon les charges de travail d'indexation réelles.

Passons maintenant aux chiffres.

Nos premiers résultats de référence sont très prometteurs. Nous avons exécuté une évaluation comparative sur une instance AWS g6.4xlarge avec un stockage NVMe connecté localement. Un seul node d'Elasticsearch a été configuré pour utiliser le nombre optimal par défaut de threads d'indexation (8, soit un pour chaque noyau physique) et pour désactiver la limitation de fusion (qui est moins applicable avec les disques NVMe rapides).

Pour l'ensemble de données, nous avons utilisé 2,6 millions de vecteurs avec 1 536 dimensions provenant de l' OpenAI Rally vector track, encodés sous forme de chaînes base64 et indexés sous forme de float32 hnsw. Dans tous les scénarios, les graphes créés atteignent des niveaux de rappel allant jusqu'à 95 %. Voici nos conclusions :

• Débit d'indexation : en transférant la construction des graphiques vers le GPU pendant les vidages de mémoire tampon, nous multiplions le débit par environ 12.

• Fusion forcée : une fois l'indexation terminée, le GPU continue d'accélérer la fusion des segments, multipliant par environ 7 la vitesse de la phase de fusion forcée.

• Utilisation du processeur : le transfert de la construction du graphe vers le GPU réduit considérablement l'utilisation moyenne et maximale du processeur. Les graphiques ci-dessous illustrent l'utilisation du CPU pendant l'indexation et la fusion, et mettent en évidence à quel point elle est plus faible lorsque ces opérations sont exécutées sur le GPU. La réduction de l'utilisation du CPU pendant l'indexation GPU permet de libérer des cycles CPU qui peuvent être réaffectés à l'amélioration des performances de recherche.

• Rappel : la précision reste pratiquement identique entre les exécutions CPU et GPU, le graphique généré par le GPU affichant un rappel légèrement supérieur.

Comparaison selon un autre critère : le prix

La comparaison précédente utilisait intentionnellement un matériel identique, la seule différence étant l'utilisation ou non du GPU lors de l'indexation. Cette configuration est utile pour isoler les effets du calcul brut, mais nous pouvons également examiner la comparaison du point de vue des coûts.

Pour un prix horaire à peu près équivalent à celui de la configuration accélérée par GPU, il est possible de provisionner une configuration uniquement sur processeur avec environ deux fois plus de ressources CPU et mémoire comparables : 32 vCPU (AMD EPYC) et 64 Go de RAM, permettant de doubler le nombre de threads d’indexation à 16.

Afin de garantir l'équité et la cohérence de la comparaison, nous avons réalisé cette expérience uniquement sur processeur sur une instance AWS g6.8xlarge, avec le GPU explicitement désactivé. Cela nous a permis de maintenir toutes les autres caractéristiques matérielles constantes tout en évaluant le compromis coût-performance entre l'accélération GPU et l'indexation uniquement sur processeur.

L'instance de processeur plus puissante montre effectivement une performance améliorée par rapport aux benchmarks de la section ci-dessus, comme on pouvait s'y attendre. Cependant, lorsque nous comparons cette instance de processeur plus puissante aux résultats originaux accélérés par GPU, le GPU offre toujours des gains de performance substantiels : ~5x d'amélioration dans le débit d'indexation, et ~6x dans la fusion forcée, tout en construisant des graphes qui atteignent des niveaux de rappel allant jusqu'à 95%.

Conclusion

Dans les scénarios de bout en bout, l'accélération GPU avec NVIDIA cuVS permet d'améliorer de près de 12 fois le débit d'indexation et de réduire de 7 fois la latence de fusion forcée, tout en diminuant considérablement l'utilisation du processeur. Cela démontre que l'indexation vectorielle et les charges de travail de fusion bénéficient considérablement de l'accélération GPU. Sur une comparaison ajustée en fonction des coûts, l'accélération GPU continue d'offrir des gains de performances substantiels, avec un débit d'indexation environ 5 fois supérieur et des opérations de fusion forcée 6 fois plus rapides.

L'indexation vectorielle accélérée par GPU est actuellement prévue pour la préversion technique dans Elasticsearch 9.3, dont la sortie est prévue début 2026.

Plus d'informations à venir.

Pour ce faire, nous utilisons le logiciel SigLIP-2 de Google pour générer des encastrements vectoriels pour les images et le texte, et les stocker dans la base de données vectorielles Elasticsearch. Au moment de la requête, nous convertissons l'entrée de la recherche, texte ou image, en encastrements et exécutons des recherches vectorielles kNN rapides pour extraire les résultats. Cette configuration permet une recherche efficace de texte à image et d'image à image. Une interface utilisateur Streamlit donne vie à ce projet en nous fournissant un frontend qui nous permet non seulement d'effectuer une recherche textuelle pour trouver et afficher les photos correspondantes de l'album, mais aussi d'identifier le sommet de la montagne à partir de l'image téléchargée et d'afficher d'autres photos de cette montagne dans l'album photo. Nous présentons également les mesures que nous avons prises pour améliorer la précision des recherches, ainsi que des conseils et astuces pratiques. Pour une exploration plus approfondie, nous fournissons un dépôt GitHub et un carnet de notes Colab.

Comment cela a commencé

Ce billet a été inspiré par un enfant de 10 ans qui m'a demandé de lui montrer toutes les photos du mont Ama Dablam prises lors de mon trek au camp de base de l'Everest. En parcourant l'album photo, on m'a également demandé d'identifier plusieurs autres pics montagneux, dont certains que je n'arrivais pas à nommer.

Cela m'a donné l'idée d'un projet amusant de vision par ordinateur. Ce que nous voulions réaliser :

• trouver des images d'un sommet de montagne par son nom

• deviner le nom du sommet d'une montagne à partir d'une image et trouver des sommets similaires dans l'album photo

• faire fonctionner les requêtes conceptuelles(personne, rivière, drapeaux de prière, etc.)

Assembler l'équipe de rêve : SigLIP-2, Elasticsearch & Streamlit

Il est rapidement apparu que pour que cela fonctionne, nous devions transformer à la fois le texte ("Ama Dablam") et les images (photos de mon album) en vecteurs pouvant être comparés de manière significative, c'est-à-dire dans le même espace vectoriel. Une fois cette étape franchie, la recherche se résume à "trouver les voisins les plus proches".

Pour générer des enregistrements d'images, nous utilisons un encodeur multilingue vision-langage, de sorte qu'une photo d'une montagne et une phrase comme "Ama Dablam" se retrouvent dans le même espace vectoriel.

SigLIP-2, récemment publié par Google, s'inscrit parfaitement dans ce cadre. Il peut générer des enchâssements sans formation spécifique à une tâche (un réglage zéro) et fonctionne bien pour notre cas d'utilisation : des photos non étiquetées et des pics avec des noms et des langues différents. Parce qu'il est formé à la correspondance texte ↔ image, une photo de montagne prise lors d'une randonnée et un court texte d'incitation se retrouvent proches en tant qu'ancrages, même lorsque la langue ou l'orthographe de la requête varient.

SigLIP-2 offre un excellent rapport qualité-vitesse, prend en charge plusieurs résolutions d'entrée et fonctionne à la fois avec le CPU et le GPU. SigLIP-2 est conçu pour être plus résistant aux photos prises en extérieur que les modèles précédents tels que le CLIP original. Lors de nos tests, SigLIP-2 a toujours produit des résultats fiables. Il est également très bien supporté, ce qui en fait un choix évident pour ce projet.

Ensuite, nous avons besoin d'une base de données vectorielle pour stocker les encastrements et effectuer des recherches puissantes. Il devrait permettre non seulement la recherche par cosinus kNN sur des images intégrées, mais aussi l'application de filtres de géographie et de texte en une seule requête. Elasticsearch convient bien ici : il gère très bien les vecteurs (HNSW kNN sur les champs dense_vector), prend en charge la recherche hybride qui combine le texte, les vecteurs et les requêtes géographiques, et propose d'emblée le filtrage et le tri. Il est également évolutif horizontalement, ce qui permet de passer facilement d'une poignée de photos à des milliers. Le client officiel Elasticsearch Python simplifie la plomberie et s'intègre parfaitement au projet. Enfin, nous avons besoin d'un frontal léger où nous pouvons saisir des requêtes de recherche et afficher les résultats. Pour une démonstration rapide, basée sur Python, Streamlit est une solution idéale. Il fournit les primitives dont nous avons besoin - le téléchargement de fichiers, une grille d'images réactive et des menus déroulants pour le tri et la géolocalisation. Il est facile de le cloner et de l'exécuter localement, et il fonctionne également dans un cahier Colab.

Implémentation

Conception et stratégie d'indexation Elasticsearch

Nous utiliserons deux indices pour ce projet : peaks_catalog et photos.

Index du catalogue des pics

Cet index constitue un catalogue compact des principaux sommets visibles pendant le trek du camp de base de l'Everest. Chaque document de cet index correspond à un sommet de montagne, comme le mont Everest. Pour chaque document relatif à un pic montagneux, nous stockons les noms/alias, les coordonnées facultatives de latitude et de longitude, ainsi qu'un vecteur prototype unique construit en mélangeant les messages-guides SigLIP-2 (+ images de référence facultatives).

Mappage de l'index :

Champ d'application

Type

Exemple

Objectif/Notes

Vecteur/Indexation

id

mot-clé

ama-dablam

Slug/id stable

-

noms

texte + sous-champ mot-clé

["Ama Dablam","Amadablam"]

Alias / noms multilingues ; names.raw pour les filtres exacts

-

latlon

geo_point

{"lat":27.8617,"lon":86.8614}

Coordonnées GPS du pic sous la forme d'une combinaison latitude/longitude (facultatif)

-

elev_m

entier

6812

Élévation (facultatif)

-

texte_embed

dense_vector

768

Prototype mixte (invites et éventuellement 1 à 3 images de référence) pour ce pic

index:true, similarité :"cosine", index_options :{type:"hnsw", m:16, ef_construction:128}

Cet index est principalement utilisé pour des recherches d'image à image, telles que l'identification de sommets de montagne à partir d'images. Nous utilisons également cet index pour améliorer les résultats de recherche texte-image.

En résumé, le site peaks_catalog transforme la question "Quelle est cette montagne ?" en un problème ciblé de plus proche voisin, séparant efficacement la compréhension conceptuelle des complexités des données d'image.

Stratégie d'indexation pour l'index peaks_catalog : Nous commençons par créer une liste des sommets les plus importants visibles lors de la randonnée EBC. Pour chaque pic, nous stockons sa position géographique, son nom, ses synonymes et son altitude dans un fichier yaml. L'étape suivante consiste à générer l'intégration pour chaque pic et à la stocker dans le champ text_embed. Afin de générer des encastrements robustes, nous utilisons la technique suivante :

• Créer un prototype de texte en utilisant :

  • noms des sommets

  • l'ensemble des invites (utilisation de plusieurs invites différentes pour tenter de répondre à la même question), par exemple :

    • "photo naturelle du sommet de la montagne {name} dans l'Himalaya, Népal".

    • "{name} sommet emblématique de la région du Khumbu, paysage alpin"

    • "{name} sommet montagneux, neige, ligne de crête rocheuse"

  • anti-concept optionnel (indiquant à SigLIP-2 ce qu'il ne faut pas faire) : soustraire un petit vecteur pour "peinture, illustration, affiche, carte, logo" afin de privilégier les photos réelles.

• Créer éventuellement un prototype d'image si des images de référence du pic sont fournies.

Nous fusionnons ensuite les prototypes de texte et d'image pour générer l'intégration finale. Enfin, le document est indexé avec tous les champs obligatoires :

Exemple de document provenant de l'index peaks_catalog:

Index des photos

Cet index primaire contient des informations détaillées sur toutes les photos de l'album. Chaque document représente une seule photo, contenant les informations suivantes :

• Chemin d'accès relatif à la photo dans l'album photo. Cette option permet de visualiser l'image correspondante ou de charger l'image dans l'interface de recherche.

• Informations sur le GPS et l'heure de la photo.

• Vecteur dense pour le codage d'images généré par SigLIP-2.

• predicted_peaks qui nous permet de filtrer par nom de pic. Cartographie de l'index

Champ d'application

Type

Exemple

Objectif/Notes

Vecteur / Indexation

chemin

mot-clé

data/images/IMG_1234.HEIC

Comment l'interface utilisateur ouvre la vignette/l'image complète

-

clip_image

dense_vector

768

Intégration d'images SigLIP-2

index:true, similarité :"cosine", index_options :{type:"hnsw", m:16, ef_construction:128}

pics_prédits

mot-clé

["ama-dablam","pumori"]

Les suppositions Top-K au moment de l'indexation (filtre / facette UX bon marché)

-

GPS

geo_point

{"lat":27.96,"lon":86.83}

permet d'utiliser des filtres géographiques

-

heure de la prise de vue

date

2023-10-18T09:41:00Z

temps de capture : tri/filtre

-

Stratégie d'indexation pour l'index des photos : Pour chaque photo de l'album, nous procédons comme suit : Extraire les informations sur les images shot_time et gps à partir des métadonnées de l'image.

• Intégration d'images SigLIP-2: passage de l'image dans le modèle et normalisation L2 du vecteur. Stocker l'intégration dans le champ clip_image.

• Prédire les pics et les stocker dans le champ predicted_peaks. Pour ce faire, nous prenons d'abord le vecteur image de la photo généré à l'étape précédente, puis nous effectuons une recherche rapide par kNN sur le champ text_embed de l'index peaks_catalog. Nous conservons les 3-4 premiers sommets et ignorons les autres.

• Nous calculons le champ _id en effectuant un hachage du nom de l'image et du chemin d'accès. Cela permet de s'assurer qu'il n'y a pas de doublons après plusieurs exécutions.

Une fois que nous avons déterminé tous les champs de la photo, les documents photo sont indexés par lots à l'aide de l'indexation en bloc :

Exemple de document de l'index des photos :

En résumé, l'index des photos est le magasin rapide, filtrable et prêt pour le kNN de toutes les photos de l'album. Sa cartographie est volontairement minimale - juste assez de structure pour permettre une recherche rapide, un affichage propre et une répartition des résultats dans l'espace et dans le temps. Cet index sert aux deux types de recherche. Le script Python permettant de créer les deux indices est disponible ici.

La visualisation des cartes Kibana ci-dessous affiche les documents de l'album photo sous forme de points verts et les pics montagneux de l'index peaks_catalog sous forme de triangles rouges, les points verts correspondant bien au sentier de randonnée du camp de base de l'Everest.

Cas d'utilisation de la recherche

Recherche par nom (texte-image) : Cette fonction permet aux utilisateurs de localiser des photos de sommets de montagne (et même des concepts abstraits comme les "drapeaux de prière") à l'aide de requêtes textuelles. Pour ce faire, l'entrée texte est convertie en un vecteur texte à l'aide de SigLIP-2. Pour la génération de vecteurs de texte robustes, nous utilisons la même stratégie que pour la création d'enchâssements de texte dans l'index peaks_catalog: combinaison de l' entrée texte avec un petit ensemble d'invites, soustraction d'un vecteur anti-concept mineur et application de la normalisation L2 pour produire le vecteur d'interrogation final. Une requête kNN est ensuite exécutée sur le champ photos.clip_image pour récupérer les pics les plus proches, sur la base de la similarité cosinusoïdale pour trouver les images les plus proches. Il est possible de rendre les résultats de la recherche plus pertinents en appliquant des filtres géographiques et de date, et/ou un filtre de terme photos.predicted_peaks dans le cadre de la requête (voir les exemples de requêtes ci-dessous). Cela permet d'exclure les sommets qui ressemblent à d'autres et qui ne sont pas visibles lors de la randonnée.

Requête Elasticsearch avec filtre géographique :

Recherche par image (image à image) : Cette fonction permet d'identifier une montagne sur une photo et de trouver d'autres images de cette même montagne dans l'album photo. Lorsqu'une image est téléchargée, elle est traitée par l'encodeur d'images SigLIP-2 pour générer un vecteur d'image. Une recherche kNN est ensuite effectuée sur le champ peaks_catalog.text_embed pour identifier les noms de pics qui correspondent le mieux. Ensuite, un vecteur de texte est généré à partir des noms de pics correspondants, et une autre recherche kNN est effectuée sur l'index des photos pour localiser les images correspondantes.

Requête Elasticsearch :

Étape 1 : Trouver les noms de pics correspondants

Étape 2 : Effectuer une recherche dans l'index photos pour trouver les images correspondantes (même requête que dans le cas d'utilisation de la recherche texte-image) :

Streamlit UI

Pour réunir le tout, nous avons créé une interface utilisateur Streamlit simple qui nous permet de réaliser les deux cas d'utilisation de la recherche. La barre de gauche affiche une liste déroulante de pics (agrégés à partir de photos.predicted_peaks) avec des cases à cocher et un filtre mini-carte/géo. En haut, il y a un champ de recherche par nom et un bouton d'identification à partir du téléchargement d'une photo. Le volet central présente une grille de vignettes réactive indiquant les scores kNN, les badges de pic prédit et les heures de capture. Chaque image comporte un bouton " Voir l'image" qui permet d'obtenir un aperçu en pleine résolution.

Recherchez en téléchargeant une image : Nous prédisons le pic et trouvons les pics correspondants dans l'album photo.

Recherche par texte: Trouver les sommets correspondants dans l'album à partir d'un texte.

Conclusion

Tout a commencé par la possibilité de voir les photos del'Ama Dablam. s'est transformé en un petit système de recherche multimodale fonctionnel. Nous avons pris des photos brutes de trek, les avons transformées en encastrements SigLIP-2 et avons utilisé Elasticsearch pour effectuer un kNN rapide sur les vecteurs, ainsi que des filtres géo/temporels simples pour faire remonter à la surface les bonnes images en fonction de leur signification. En cours de route, nous avons séparé les préoccupations en deux indices : un minuscule peaks_catalog de prototypes mélangés (pour l'identification) et un index évolutif photos de vecteurs d'images et d'EXIF (pour la recherche). Il est pratique, reproductible et facile à étendre.

Si vous souhaitez l'accorder, vous pouvez jouer avec quelques paramètres :

• Paramètres de temps de recherche : k (nombre de voisins à récupérer) et num_candidates (étendue de la recherche avant la notation finale). Ces paramètres sont abordés dans le blog ici.

• Paramètres de temps d'indexation : m (connectivité du graphique) et ef_construction (précision du temps de construction par rapport à la mémoire). Pour les requêtes, expérimentez avec ef_search également - une valeur plus élevée signifie généralement un meilleur rappel avec un certain compromis en termes de latence. Consultez ce blog pour plus de détails sur ces paramètres.

A l'avenir, des modèles natifs/rerankers pour la recherche multimodale et multilingue seront bientôt intégrés à l'écosystème Elastic, ce qui devrait rendre la recherche d'images/de textes et le classement hybride encore plus performants. ir.elastic.co+1

Si vous souhaitez essayer vous-même :

• GitHub repo : https://github.com/navneet83/multimodal-mountain-peak-search

• Colab quickstart : https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

Notre voyage s'achève donc et il est temps de prendre l'avion du retour. J'espère que cela vous a été utile et si vous le cassez (ou l'améliorez), j'aimerais savoir ce que vous avez changé.

Dans la dernière partie de cette série, nous avons déployé le modèle E5 pré-entraîné d'Elastic (ainsi que d'autres modèles d'intégration de texte multilingue de Hugging Face) et nous nous sommes plongés dans la génération d'intégrations vectorielles denses à partir de vos données textuelles à l'aide d'Elasticsearch et de Kibana. Dans ce blog, nous examinerons les résultats de ces encastrements et mettrons en évidence les avantages significatifs de l'utilisation d'un modèle multilingue.

Maintenant que nous avons notre index coco_multilingual, la recherche nous donnera des documents en plusieurs langues, avec le champ "en" pour référence :

Effectuer une recherche en anglais

Essayons d'effectuer la recherche en anglais et voyons ce qu'il en est :

Ici, même si la requête semble faussement simple, nous recherchons les enchâssements numériques du mot "kitty" dans tous les documents, dans toutes les langues, sous le capot. Et comme nous effectuons une recherche vectorielle, nous pouvons rechercher sémantiquement tous les mots susceptibles d'être liés à "kitty" : "chat", "chaton", "félin", "gatto" (italien), "mèo" (vietnamien), 고양이 (coréen), 猫 (chinois), etc. Ainsi, même si ma requête est en anglais, nous pouvons rechercher du contenu dans toutes les autres langues. Par exemple, la recherche d'un chat lying on something donne des documents en italien, en néerlandais ou en vietnamien. Une question d'efficacité !

Recherche de contenu dans d'autres langues

De même, une recherche par mot-clé pour "chat" en coréen ("고양이") donnera également des résultats significatifs. Ce qui est spectaculaire ici, c'est que nous n'avons même pas de documents en coréen dans cet index !

Cela fonctionne parce que le modèle d'intégration représente le sens dans un espace sémantique partagé, ce qui permet de retrouver des images pertinentes même si la requête est formulée dans une langue différente de celle des légendes indexées.

Augmenter la pertinence des résultats de recherche grâce à la recherche hybride et au reranking

Nous sommes heureux que les résultats pertinents soient apparus comme prévu. Mais dans le monde réel, par exemple dans le commerce électronique ou dans les applications RAG qui doivent se limiter aux 5 à 10 premiers résultats les plus pertinents, nous pouvons utiliser un modèle de classement pour hiérarchiser les résultats les plus pertinents.

Par exemple, une requête demandant "quelle est la couleur du chat ?" en vietnamien donnera un grand nombre de résultats, mais les 1 ou 2 premiers ne seront pas forcément les plus pertinents.

Les résultats mentionnent tous le chat, ou une forme de couleur :

Améliorons donc cela ! Intégrons le modèle de rerank multilingue de Coherepour améliorer le raisonnement correspondant à notre question.

Maintenant, avec les premiers résultats, notre application peut répondre en toute confiance que la couleur du chaton est noire ou brune avec des rayures. Ce qui est encore plus intéressant ici, c'est que notre recherche vectorielle a détecté une omission dans la légende anglaise de l'ensemble de données original. Il est capable de trouver le chat à rayures brunes alors que la traduction anglaise de référence a omis ce détail. C'est la force de la recherche vectorielle.

Conclusion

Dans ce blog, nous avons présenté l'utilité d'un modèle d'intégration multilingue, et comment tirer parti d'Elasticsearch pour intégrer les modèles afin de générer des intégrations, et d'améliorer efficacement la pertinence et la précision avec une recherche hybride et un reranker. Vous pouvez créer votre propre cluster Cloud pour essayer la recherche sémantique multilingue en utilisant notre modèle E5 prêt à l'emploi sur la langue et l'ensemble de données de votre choix.

Dans un monde d'utilisateurs globaux, la recherche d'informations multilingues (CLIR) est cruciale. Au lieu de limiter les recherches à une seule langue, le CLIR vous permet de trouver des informations dans n'importe quelle langue, ce qui améliore l'expérience de l'utilisateur et rationalise les opérations. Imaginez un marché mondial où les clients du commerce électronique pourraient rechercher des articles dans leur langue et où les bons résultats apparaîtraient, sans qu'il soit nécessaire de localiser les données à l'avance. Ou encore, où les chercheurs universitaires peuvent rechercher des articles dans leur langue maternelle, avec nuance et complexité, même si la source est dans une autre langue.

Les modèles d'intégration de textes multilingues nous permettent justement de le faire. Les emboîtements sont un moyen de représenter le sens d'un texte sous forme de vecteurs numériques. Ces vecteurs sont conçus de manière à ce que les textes ayant des significations similaires soient situés à proximité les uns des autres dans un espace à haute dimension. Les modèles d'intégration de textes multilingues sont spécifiquement conçus pour représenter dans un espace vectoriel similaire les mots et les phrases ayant la même signification dans différentes langues.

Les modèles tels que le logiciel libre Multilingual E5 sont formés sur des quantités massives de données textuelles, souvent à l'aide de techniques telles que l'apprentissage contrastif. Dans cette approche, le modèle apprend à distinguer les paires de textes dont le sens est similaire (paires positives) de ceux dont le sens est différent (paires négatives). Le modèle est entraîné à ajuster les vecteurs qu'il produit de manière à maximiser la similarité entre les paires positives et à minimiser la similarité entre les paires négatives. Pour les modèles multilingues, ces données d'entraînement comprennent des paires de textes dans différentes langues qui sont des traductions l'une de l'autre, ce qui permet au modèle d'apprendre un espace de représentation commun pour plusieurs langues. Les enchâssements résultants peuvent ensuite être utilisés pour diverses tâches de NLP, y compris la recherche multilingue, où la similarité entre les enchâssements de texte est utilisée pour trouver des documents pertinents quelle que soit la langue de la requête.

Avantages de la recherche vectorielle multilingue

• Nuance: La recherche vectorielle excelle à capturer le sens sémantique, allant au-delà de la correspondance des mots clés. Ceci est crucial pour les tâches qui nécessitent de comprendre le contexte et les subtilités de la langue.

• Compréhension multilingue: Permet de rechercher efficacement des informations dans plusieurs langues, même lorsque la requête et les documents utilisent un vocabulaire différent.

• Pertinence: Fournit des résultats plus pertinents en se concentrant sur la similarité conceptuelle entre les requêtes et les documents.

"Prenons l'exemple d'un chercheur universitaire qui étudie l'impact des médias sociaux sur le discours politique" dans différents pays. Grâce à la recherche vectorielle, ils peuvent saisir des requêtes telles que "l'impatto dei social media sul discorso politico" (italien) ou "ảnh hưởng của mạng xã hội đối với diễn ngôn chính trị" (vietnamien) et trouver des articles pertinents en anglais, espagnol ou toute autre langue indexée. En effet, la recherche vectorielle identifie les articles qui traitent du concept de l'influence des médias sociaux sur la politique, et pas seulement ceux qui contiennent les mots clés exacts. Cela améliore considérablement l'étendue et la profondeur de leurs recherches.

Se lancer

Voici comment configurer CLIR en utilisant Elasticsearch - avec le modèle E5 qui est fourni dans la boîte. Nous utiliserons l'ensemble de données multilingues COCO, qui contient des légendes d'images dans plusieurs langues, pour nous aider à visualiser deux types de recherches :

1. Requêtes et termes de recherche dans d'autres langues sur un ensemble de données en anglais, et

2. Requêtes en plusieurs langues à partir d'un ensemble de données contenant des documents en plusieurs langues.

Ensuite, nous exploiterons la puissance de la recherche hybride et du reranking pour améliorer encore les résultats de la recherche.

Produits requis

• Python 3.6+

• Elasticsearch 8+

• Client Elasticsearch Python : pip install elasticsearch

Ensemble de données

L'ensemble de données COCO est un ensemble de données de sous-titrage à grande échelle. Chaque image de l'ensemble de données est légendée dans plusieurs langues différentes, avec plusieurs traductions disponibles par langue. À des fins de démonstration, nous indexerons chaque traduction comme un document individuel, avec la première traduction anglaise disponible à titre de référence.

Étape 1 : télécharger l'ensemble de données multilingues COCO

Pour simplifier le blog et faciliter le suivi, nous chargeons ici les 100 premières lignes du restval dans un fichier JSON local à l'aide d'un simple appel à l'API. Vous pouvez également utiliser la bibliothèque de données HuggingFace pour charger le jeu de données complet ou des sous-ensembles du jeu de données.

Si les données sont chargées avec succès dans un fichier JSON, vous devriez voir quelque chose de similaire à ce qui suit :

Data successfully downloaded and saved to multilingual_coco_sample.json

Étape 2 : (Démarrer Elasticsearch) et indexer les données dans Elasticsearch

a) Démarrez votre serveur Elasticsearch local.

b) Lancer le client Elasticsearch.

c) Données d'index

Une fois les données indexées, vous devriez voir quelque chose de similaire à ce qui suit :

Successfully bulk indexed 4840 documents

Indexing complete!

Étape 3 : Déployer le modèle formé E5

Dans Kibana, accédez à la page Stack Management > Trained Models, et cliquez sur Deploy pour le modèle .multilingual-e5-small_linux-x86_64. option. Ce modèle E5 est un petit ordinateur multilingue optimisé pour linux-x86_64, que l'on peut utiliser dès sa sortie de l'emballage. En cliquant sur "Déployer", vous accédez à un écran où vous pouvez ajuster les paramètres de déploiement ou les configurations des vCPUs. Par souci de simplicité, nous utiliserons les options par défaut, en sélectionnant les ressources adaptatives, ce qui permettra de dimensionner automatiquement notre déploiement en fonction de l'utilisation.

Si vous souhaitez utiliser d'autres modèles d'intégration de texte, vous pouvez le faire en option. Par exemple, pour utiliser le BGE-M3, vous pouvez utiliser le client Python Eland d'Elastic pour importer le modèle de HuggingFace.

Accédez ensuite à la page Modèles formés pour déployer le modèle importé avec les configurations souhaitées.

Étape 4 : Vectorisation ou création d'enchâssements pour les données d'origine avec le modèle déployé

Pour créer les enchâssements, nous devons d'abord créer un pipeline d'ingestion qui nous permettra de prendre le texte et de le faire passer par le modèle d'enchâssement de texte d'inférence. Vous pouvez le faire dans l'interface utilisateur de Kibana ou via l'API d'Elasticsearch.

Pour ce faire via l'interface Kibana, après avoir déployé le modèle entraîné, cliquez sur le bouton Test . Cela vous permettra de tester et de prévisualiser les éléments intégrés générés. Créez une nouvelle vue de données pour l'index coco , définissez Data view sur la vue de données coco nouvellement créée, et définissez Field sur description car c'est le champ pour lequel nous voulons générer des embeddings.

Cela fonctionne très bien ! Nous pouvons maintenant créer le pipeline d'ingestion et réindexer nos documents originaux, les faire passer par le pipeline et créer un nouvel index avec les embeddings. Pour ce faire, cliquez sur Créer un pipeline, ce qui vous guidera tout au long du processus de création du pipeline, avec des processeurs auto-remplis nécessaires pour vous aider à créer les embeddings.

L'assistant peut également remplir automatiquement les processeurs nécessaires pour gérer les défaillances lors de l'ingestion et du traitement des données.

Créons maintenant le pipeline d'ingestion. Je nomme le pipeline coco_e5. Une fois le pipeline créé avec succès, vous pouvez immédiatement l'utiliser pour générer les embeddings en réindexant les données indexées d'origine vers un nouvel index dans l'assistant. Cliquez sur Réindexer pour lancer le processus.

Pour des configurations plus complexes, nous pouvons utiliser l'API Elasticsearch.

Pour certains modèles, en raison de la manière dont ils ont été entraînés, il peut être nécessaire d'ajouter certains textes à l'entrée réelle avant de générer les enchâssements, faute de quoi les performances s'en trouveront dégradées.

Par exemple, avec le e5, le modèle s'attend à ce que le texte d'entrée suive "passage : {content of passage}". Utilisons les pipelines d'ingestion pour y parvenir : Nous allons créer un nouveau pipeline d'ingestion vectorize_descriptions. Dans ce pipeline, nous allons créer un nouveau champ temporaire temp_desc, ajouter "passage : " au texte description, faire passer temp_desc par le modèle pour générer des enchâssements de texte, puis supprimer le champ temp_desc.

En outre, nous pourrions vouloir spécifier le type de quantification que nous voulons utiliser pour le vecteur généré. Par défaut, Elasticsearch utilise int8_hnsw, mais ici je veux Better Binary Quantization (ou bqq_hnsw), qui réduit chaque dimension à une précision d'un seul bit. Cela permet de réduire l'empreinte mémoire de 96% (ou 32x) au prix d'une plus grande précision. J'opte pour ce type de quantification parce que je sais que j'utiliserai plus tard un reranker pour améliorer la perte de précision.

Pour ce faire, nous allons créer un nouvel index nommé coco_multi, et spécifier les mappings. La magie réside ici dans le champ vector_description, où nous spécifions que le type de l'index_optionsest bbq_hnsw.

Nous pouvons maintenant réindexer les documents originaux dans un nouvel index, avec notre pipeline d'ingestion qui va "vectoriser" ou créer des embeddings pour le champ des descriptions.

Et c'est tout ! Nous avons déployé avec succès un modèle multilingue avec Elasticsearch et Kibana et appris étape par étape comment créer les vector embeddings avec vos données avec Elastic, soit via l'interface utilisateur Kibana, soit avec l'API Elasticsearch. Dans la deuxième partie de cette série, nous explorerons les résultats et les nuances de l'utilisation d'un modèle multilingue. En attendant, vous pouvez créer votre propre cluster Cloud pour essayer la recherche sémantique multilingue en utilisant notre modèle E5 prêt à l'emploi sur la langue et l'ensemble de données de votre choix.

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 !

Dans cet article, nous examinerons ces types de champs, quand utiliser chacun d'entre eux et comment ils sont liés à la génération d'encarts et aux stratégies d'utilisation, à la fois lors de l'indexation et de l'interrogation.

Type de vecteur dense

Le type de champ dense_vector dans Elasticsearch est utilisé pour stocker des vecteurs denses, qui sont des représentations numériques de données telles que du texte, des images et de l'audio, où presque toutes les dimensions sont pertinentes... Ces vecteurs sont générés à l'aide de modèles d'intégration fournis par des plateformes telles que OpenAI, Cohere ou Hugging Face, et sont conçus pour capturer la signification sémantique globale des données, même si elles ne partagent pas de termes exacts avec d'autres documents.

Dans Elasticsearch, les vecteurs denses peuvent avoir jusqu'à 4096 dimensions en fonction du modèle utilisé. Par exemple, le modèle all-MiniLM-L6-v2 génère des vecteurs de 384 dimensions, tandis que le modèle text-embedding-ada-002 d'OpenAI produit des vecteurs de 1536 dimensions.

Le champ dense_vector est généralement adopté comme type par défaut pour stocker ce type d'intégration lorsqu'un plus grand contrôle est nécessaire, comme l'utilisation de vecteurs pré-générés, l'application de fonctions de similarité personnalisées ou l'intégration avec des modèles externes.

Quand et pourquoi utiliser le type dense_vector ?

Les vecteurs denses sont excellents pour capturer la similarité sémantique entre des phrases, des paragraphes ou des documents entiers. Ils fonctionnent très bien lorsque l'objectif est de comparer le sens global des textes, même s'ils ne partagent pas les mêmes termes.

Le champ de vecteurs denses est idéal lorsque vous disposez déjà d'un pipeline externe de génération d'incrustations utilisant des modèles fournis par des plateformes telles que OpenAI, Cohere ou Hugging Face et que vous souhaitez uniquement stocker et interroger ces vecteurs manuellement. Ce type de champ offre une grande compatibilité avec les modèles d'intégration et une souplesse totale en matière de génération et d'interrogation, ce qui permet de contrôler la manière dont les vecteurs sont produits, indexés et utilisés lors de la recherche.

En outre, il prend en charge différentes formes de recherche sémantique, avec des requêtes telles que k-NN ou script_score pour les cas où il est nécessaire d'ajuster la logique de classement. Ces possibilités font du vecteur dense un outil idéal pour des applications telles que RAG (Retrieval-Augmented Generation), les systèmes de recommandation et les recherches personnalisées basées sur la similarité.

Enfin, le champ vous permet de personnaliser la logique de pertinence, en utilisant des fonctions telles que cosineSimilarity, dotProduct ou l2norm pour adapter le classement aux besoins de votre cas d'utilisation.

Les vecteurs denses restent la meilleure option pour ceux qui ont besoin de flexibilité, de personnalisation et de compatibilité avec des cas d'utilisation avancés comme ceux mentionnés ci-dessus.

Comment utiliser la requête pour un type de vecteur dense ?

Les recherches sur les champs définis comme dense_vector utilisent la requête des k-voisins les plus proches. Cette requête est chargée de trouver les documents dont le vecteur dense est le plus proche du vecteur de la requête. Vous trouverez ci-dessous un exemple d'application d'une requête k-NN à un champ vectoriel dense :

Outre la requête k-NN, s'il est nécessaire de personnaliser la notation des documents, il est également possible d'utiliser la requête script_score, en la combinant avec des fonctions de comparaison vectorielle telles que cosineSimilarity, dotProduct ou l2norm pour calculer la pertinence d'une manière plus contrôlée. Voir l'exemple :

Si vous souhaitez aller plus loin, je vous recommande d'explorer l'article Comment configurer la recherche vectorielle dans Elasticsearch.

Type de vecteur épars

Le type de champ sparse_vector est utilisé pour stocker des vecteurs épars, qui sont des représentations numériques où la plupart des valeurs sont nulles et où seuls quelques termes ont des poids significatifs. Ce type de vecteur est courant dans les modèles basés sur les termes tels que SPLADE ou ELSER (Elastic Learned Sparse EncodeR).

Quand et pourquoi utiliser un type de vecteur peu dense ?

Les vecteurs épars sont idéaux lorsque vous avez besoin d'une recherche plus précise en termes lexicaux, sans sacrifier l'intelligence sémantique. Ils représentent le texte sous forme de paires jeton/valeur, en ne mettant en évidence que les termes les plus pertinents avec les poids associés, ce qui permet de gagner en clarté, en contrôle et en efficacité.

Ce type de champ est particulièrement utile lorsque vous générez des vecteurs basés sur des termes, comme dans les modèles ELSER ou SPLADE, qui attribuent des poids différents à chaque mot en fonction de son importance relative dans le texte.

Pour les cas où vous souhaitez contrôler l'influence de mots spécifiques dans la requête, les types de vecteurs épars vous permettent d'ajuster manuellement le poids des termes afin d'optimiser le classement des résultats.

Parmi les principaux avantages, citons la transparence de la recherche, puisqu'il est possible de comprendre clairement pourquoi un document a été jugé pertinent, et l'efficacité du stockage, puisque seuls les jetons dont la valeur n'est pas nulle sont enregistrés, contrairement aux vecteurs denses qui stockent toutes les dimensions.

En outre, les vecteurs épars sont le complément idéal des stratégies de recherche hybrides et peuvent même être combinés avec des vecteurs denses pour associer la précision lexicale à la compréhension sémantique.

Comment utiliser l'interrogation pour le type de vecteur épars ?

La requête sparse_vector vous permet de rechercher des documents sur la base d'un vecteur de requête au format jeton/valeur. Vous trouverez ci-dessous un exemple de requête :

Si vous préférez utiliser un modèle formé, il est possible d'utiliser un point final d'inférence qui transforme automatiquement le texte de la requête en un vecteur peu dense :

Pour approfondir ce sujet, je vous suggère de lire Understanding sparse vector embeddings with trained ML models (Comprendre les encastrements de vecteurs épars avec des modèles ML formés).

Type de texte sémantique

Le type de champ semantic_text est le moyen le plus simple et le plus direct d'utiliser la recherche sémantique dans Elasticsearch. Il gère automatiquement la génération de l'intégration, à la fois au moment de l'indexation et de l'interrogation, par le biais d'un point final d'inférence. Cela signifie que vous n'avez pas à vous soucier de générer ou de stocker des vecteurs manuellement.

Quand et pourquoi utiliser le texte sémantique ?

Le champ semantic_text est idéal pour ceux qui veulent commencer avec un minimum d'effort technique et sans avoir à manipuler les vecteurs manuellement. Ce champ automatise des étapes telles que la génération de l'encastrement et le mappage de la recherche vectorielle, ce qui rend l'installation plus rapide et plus pratique.

Vous devriez envisager d'utiliser semantic_text si vous appréciez la simplicité et l'abstraction, car il élimine la complexité de la configuration manuelle des mappings, de la génération d'embedding et des pipelines d'ingestion. Il suffit de sélectionner le modèle d'inférence et Elasticsearch s'occupe du reste.

Parmi les principaux avantages, citons la génération automatique de l'intégration, effectuée à la fois pendant l'indexation et l'interrogation, et le mappage prêt à l'emploi, qui est préconfiguré pour prendre en charge le modèle d'inférence sélectionné.

En outre, le champ offre une prise en charge native du découpage automatique des textes longs (text chunking), ce qui permet de diviser les textes volumineux en passages plus petits, chacun ayant sa propre intégration, ce qui améliore la précision de la recherche. La productivité s'en trouve grandement améliorée, en particulier pour les équipes qui souhaitent fournir rapidement de la valeur ajoutée sans avoir à s'occuper de l'ingénierie sous-jacente de la recherche sémantique.

Cependant, bien que semantic_text offre rapidité et simplicité, cette approche présente certaines limites. Il permet d'utiliser des modèles standard du marché, pour autant qu'ils soient disponibles en tant que points de terminaison d'inférence dans Elasticsearch. Cependant, il ne prend pas en charge les encastrements générés de l'extérieur, comme c'est le cas avec le champ dense_vector.

Si vous avez besoin de plus de contrôle sur la manière dont les vecteurs sont générés, si vous souhaitez utiliser vos propres incorporations ou si vous devez combiner plusieurs champs pour des stratégies avancées, les champs dense_vector et sparse_vector offrent la flexibilité nécessaire pour des scénarios plus personnalisés ou spécifiques à un domaine.

Comment utiliser la requête pour le type de texte sémantique ?

Avant semantic_text, il était nécessaire d'utiliser une requête différente selon le type d'intégration (dense ou éparse). Une requête sparse_vector a été utilisée pour les champs peu denses, tandis que les champs dense_vector ont nécessité des requêtes KNN.

Avec le type de texte sémantique, la recherche est effectuée à l'aide de la requête sémantique, qui génère automatiquement le vecteur de la requête et le compare avec les enchâssements des documents indexés. Le type semantic_text vous permet de définir un point final d'inférence pour intégrer la requête, mais si aucun n'est spécifié, le même point final que celui utilisé lors de l'indexation sera appliqué à la requête.

Pour en savoir plus, je vous propose de lire l'article Elasticsearch new semantic_text mapping : Simplifier la recherche sémantique.

Conclusion

Lors du choix de la méthode de mappage des embeddings dans Elasticsearch, il est essentiel de comprendre comment vous souhaitez générer les vecteurs et quel est le niveau de contrôle dont vous avez besoin sur ceux-ci. Si vous recherchez la simplicité, le champ de texte sémantique permet une recherche sémantique automatique et évolutive, ce qui le rend idéal pour de nombreux cas d'utilisation initiaux. Lorsqu'un contrôle plus poussé, des performances plus fines ou une intégration avec des modèles personnalisés sont nécessaires, les champs de vecteurs denses et de vecteurs clairsemés offrent la flexibilité nécessaire.

Le type de champ idéal dépend de votre cas d'utilisation, de l'infrastructure disponible et de la maturité de votre pile d'apprentissage automatique. Plus important encore, Elastic offre les outils nécessaires pour construire des systèmes de recherche modernes et hautement adaptables.

Références

• Type de champ texte sémantique

• Type de champ vectoriel épars

• Type de champ vectoriel dense

• Requête sémantique

• Requête sur les vecteurs épars

• Recherche kNN

• Nouveau mappage semantic_text d'Elasticsearch : Simplifier la recherche sémantique

• Comprendre les encastrements de vecteurs épars à l'aide de modèles ML entraînés

Toutes les requêtes complètes et les résultats mentionnés dans cet article peuvent être trouvés dans notre dépôt de code Elasticsearch Labs.

Pourquoi mettre en œuvre une meilleure quantification binaire (BBQ) dans votre cas d'utilisation ?

Bien que les mathématiques soient intrigantes, elles sont essentielles si vous voulez comprendre pourquoi vos recherches vectorielles restent précises. En fin de compte, il s'agit d'une question de compression, car il s'avère qu'avec les algorithmes actuels de recherche vectorielle, vous êtes limité par la vitesse de lecture des données. Par conséquent, si vous pouvez placer toutes ces données dans la mémoire, vous bénéficiez d'un gain de vitesse significatif par rapport à la lecture à partir du stockage(la mémoire est environ 200 fois plus rapide que les disques SSD).

Il y a quelques points à garder à l'esprit :

• Les indices basés sur les graphes, tels que HNSW (Hierarchical Navigable Small World), sont les plus rapides pour la recherche vectorielle.

  • HNSW : un algorithme de recherche approximative du plus proche voisin qui construit une structure de graphe multicouche pour permettre des recherches de similarité efficaces en haute dimension.

• La vitesse de HNSW est fondamentalement limitée par la vitesse de lecture des données à partir de la mémoire ou, dans le pire des cas, à partir du stockage.

  • L'idéal est de pouvoir charger tous les vecteurs stockés dans la mémoire.

• Les modèles d'intégration produisent généralement des vecteurs avec une précision float32, soit 4 octets par nombre à virgule flottante.

• Enfin, selon le nombre de vecteurs et/ou de dimensions que vous avez, vous pouvez très rapidement manquer de mémoire pour conserver tous vos vecteurs.

Si l'on prend cela pour acquis, on constate qu'un problème se pose rapidement dès que l'on commence à ingérer des millions, voire des milliards de vecteurs, chacun ayant potentiellement des centaines, voire des milliers de dimensions. La section intitulée "Chiffres approximatifs sur les taux de compression" fournit quelques chiffres approximatifs.

De quoi avez-vous besoin pour commencer ?

Pour commencer, vous aurez besoin des éléments suivants :

• Si vous utilisez Elastic Cloud ou on-prem, vous aurez besoin d'une version d'Elasticsearch supérieure à 8.18. Alors que BBQ a été introduit dans la version 8.16, dans cet article, vous utiliserez vector_rescore, qui a été introduit dans la version 8.18.

• En outre, vous devrez également vous assurer qu'il existe un nœud d'apprentissage automatique (ML) dans votre cluster. (Remarque : un nœud ML doté d'un minimum de 4 Go est nécessaire pour charger le modèle, mais vous aurez probablement besoin de nœuds beaucoup plus grands pour des charges de travail de production complètes).

• Si vous utilisez Serverless, vous devrez sélectionner une instance optimisée pour les vecteurs.

• Vous aurez également besoin d'une connaissance de base des bases de données vectorielles. Si vous n'êtes pas encore familiarisé avec les concepts de recherche vectorielle dans Elastic, vous pouvez consulter les ressources suivantes :

  • Naviguer dans une base de données vectorielle élastique

  • Les grandes idées derrière la génération augmentée de recherche

Meilleure implémentation de la quantification binaire (BBQ)

Pour que ce blog reste simple, vous utiliserez les fonctions intégrées lorsqu'elles sont disponibles. Dans ce cas, vous disposez du modèle d'intégration vectorielle .multilingual-e5-small qui s'exécutera directement dans Elasticsearch sur un nœud d'apprentissage automatique. Notez que vous pouvez remplacer le modèle text_embedding par l'intégrateur de votre choix(OpenAI, Google AI Studio, Cohere et bien d'autres). Si le modèle que vous préférez n'est pas encore intégré, vous pouvez également apporter vos propres encastrements vectoriels denses).

Tout d'abord, vous devrez créer un point final d'inférence pour générer des vecteurs pour un morceau de texte donné. Vous exécuterez toutes ces commandes à partir de la console Kibana Dev Tools. Cette commande permet de télécharger le site .multilingual-e5-small. S'il n'existe pas encore, il configurera votre point d'accès ; cette opération peut prendre une minute. Vous pouvez voir le résultat attendu dans le fichier 01-create-an-inference-endpoint-output.json dans le dossier Outputs.

Une fois qu'il est revenu, votre modèle est configuré et vous pouvez tester que le modèle fonctionne comme prévu à l'aide de la commande suivante. Vous pouvez voir le résultat attendu dans le fichier 02-embed-text-output.json dans le dossier Outputs.

Si vous rencontrez des problèmes liés au fait que votre modèle formé n'est affecté à aucun nœud, il se peut que vous deviez démarrer votre modèle manuellement.

Créons maintenant un nouveau mappage avec deux propriétés, un champ de texte standard (my_field) et un champ vectoriel dense (my_vector) avec 384 dimensions pour correspondre à la sortie du modèle d'intégration. Vous pouvez également passer outre l'adresse index_options.type to bbq_hnsw. Vous pouvez voir le résultat attendu dans le fichier 03-create-byte-qauntized-index-output.json dans le dossier Outputs.

Pour s'assurer qu'Elasticsearch génère vos vecteurs, vous pouvez utiliser un pipeline d'ingestion. Ce pipeline nécessite trois éléments : le point final (model_id), le site input_field pour lequel vous souhaitez créer des vecteurs et le site output_field dans lequel vous souhaitez stocker ces vecteurs. La première commande ci-dessous crée un pipeline d'ingestion d'inférence, qui utilise le service d'inférence sous le capot, et la seconde teste le bon fonctionnement du pipeline. Vous pouvez voir le résultat attendu dans le fichier 04-create-and-simulate-ingest-pipeline-output.json dans le dossier Outputs. 

Vous êtes maintenant prêt à ajouter des documents à l'aide des deux premières commandes ci-dessous et à tester le fonctionnement de vos recherches à l'aide de la troisième commande. Vous pouvez vérifier le résultat attendu dans le fichier 05-bbq-index-output.json dans le dossier Outputs. 

Comme nous l'avons recommandé dans cet article, le recalage et le suréchantillonnage sont conseillés lorsque vous passez à des quantités de données non triviales, car ils permettent de maintenir une précision de rappel élevée tout en bénéficiant des avantages de la compression. À partir de la version 8.18 d'Elasticsearch, vous pouvez le faire de cette façon en utilisant rescore_vector. Le résultat attendu se trouve dans le fichier 06-bbq-search-8-18-output.json dans le dossier Outputs.

Comment ces résultats se comparent-ils à ceux que vous obtiendriez avec des données brutes ? Si vous refaites tout ce qui précède mais avec index_options.type: hnsw, vous verrez que les scores sont très comparables. Vous pouvez voir le résultat attendu dans le fichier 07-raw-vector-output.json dans le dossier Outputs.

Chiffres approximatifs sur les taux de compression

Les exigences en matière de stockage et de mémoire peuvent rapidement devenir un défi important lorsque l'on travaille avec la recherche vectorielle. La décomposition suivante illustre comment les différentes techniques de quantification réduisent considérablement l'empreinte mémoire des données vectorielles.

Vecteurs (V)

Dimensions (D)

brut (V x D x 4)

int8 (V x (D x 1 + 4))

int4 (V x (D x 0,5 + 4))

bbq (V x (D x 0,125 + 4))

10,000,000

384

14.31GB

3.61GB

1.83GB

0.58GB

50,000,000

384

71.53GB

18.07GB

9.13GB

2.89GB

100,000,000

384

143.05GB

36.14GB

18.25GB

5.77GB

Conclusion

BBQ est une optimisation que vous pouvez appliquer à vos données vectorielles pour les compresser sans sacrifier la précision. Il convertit les vecteurs en bits, ce qui vous permet d'effectuer des recherches efficaces dans les données et de faire évoluer vos flux de travail d'IA pour accélérer les recherches et optimiser le stockage des données.

Poursuite de l'apprentissage

Si vous souhaitez en savoir plus sur le barbecue, n'hésitez pas à consulter les ressources suivantes :

• Quantification binaire (BBQ) dans Lucene et Elasticsearch

• Meilleure quantification binaire (BBQ) vs quantification par produit

• Quantification scalaire optimisée : Une quantification binaire encore meilleure

• Meilleure quantification binaire (BBQ) : De l'octet au BBQ, le secret d'une meilleure recherche vectorielle par Ben Trent

Démonstration de quantification binaire

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

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

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

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

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

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

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

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

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

Méthodologie

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

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

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

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

• 1 pool de nœuds pour Rallye avec 2 machines e2-standard-4 (16GB RAM et 4 CPUs)

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

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

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

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

Rappel@10

• 10-40-40

• 10-50-50

• 10-100-100

• 10-200-200

• 10-500-500

• 10-750-750

• 10-1000-1000

• 10-1500-1500

• 10-2000-2000

Rappel@50

• 50-150-150

• 50-200-200

• 50-250-250

• 50-500-500

• 50-750-750

• 50-1000-1000

• 50-1200-1200

• 50-1500-1500

• 50-2000-2000

Rappel@100

• 100-200-200

• 100-250-250

• 100-300-300

• 100-500-500

• 100-750-750

• 100-1000-1000

• 100-1200-1200

• 100-1500-1500

• 100-2000-2000

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

Configuration d'OpenSearch Rally

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

Configuration de l'index Opensearch

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

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

Configuration d'Elasticsearch Rally

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

Configuration de l'index Elasticsearch

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

Résultats

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

Rappel @ 10 - simplifié

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

Rappel @ 10 - Détaillé

tâche

latence.moyenne

débit.moyen

avg_recall

Elasticsearch-9.0-BBQ

10-100-100

11.70

513.58

0.89

Elasticsearch-9.0-BBQ

10-1000-100

27.33

250.55

0.95

Elasticsearch-9.0-BBQ

10-1500-1500

35.93

197.26

0.95

Elasticsearch-9.0-BBQ

10-200-200

13.33

456.16

0.92

Elasticsearch-9.0-BBQ

10-2000-2000

44.27

161.40

0.95

Elasticsearch-9.0-BBQ

10-40-40

10.97

539.94

0.84

Elasticsearch-9.0-BBQ

10-50-50

11.00

535.73

0.85

Elasticsearch-9.0-BBQ

10-500-500

19.52

341.45

0.93

Elasticsearch-9.0-BBQ

10-750-750

22.94

295.19

0.94

OpenSearch-2.19-faiss

10-100-100

35.59

200.61

0.94

OpenSearch-2.19-faiss

10-1000-1000

156.81

58.30

0.96

OpenSearch-2.19-faiss

10-1500-1500

181.79

42.97

0.96

OpenSearch-2.19-faiss

10-200-200

47.91

155.16

0.95

OpenSearch-2.19-faiss

10-2000-2000

232.14

31.84

0.96

OpenSearch-2.19-faiss

10-40-40

27.55

249.25

0.92

OpenSearch-2.19-faiss

10-50-50

28.78

245.14

0.92

OpenSearch-2.19-faiss

10-500-500

79.44

97.06

0.96

OpenSearch-2.19-faiss

10-750-750

104.19

75.49

0.96

Rappel à 50 ans - simplifié

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

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

Tâche

Latence Moyenne

Débit moyen

Rappel moyen

Elasticsearch-9.0-BBQ

50-1000-1000

25.71

246.44

0.95

Elasticsearch-9.0-BBQ

50-1200-1200

28.81

227.85

0.95

Elasticsearch-9.0-BBQ

50-150-150

13.43

362.90

0.90

Elasticsearch-9.0-BBQ

50-1500-1500

33.38

202.37

0.95

Elasticsearch-9.0-BBQ

50-200-200

12.99

406.30

0.91

Elasticsearch-9.0-BBQ

50-2000-2000

42.63

163.68

0.95

Elasticsearch-9.0-BBQ

50-250-250

14.41

373.21

0.92

Elasticsearch-9.0-BBQ

50-500-500

17.15

341.04

0.93

Elasticsearch-9.0-BBQ

50-750-750

31.25

248.60

0.94

OpenSearch-2.19-faiss

50-1000-1000

125.35

62.53

0.96

OpenSearch-2.19-faiss

50-1200-1200

143.87

54.75

0.96

OpenSearch-2.19-faiss

50-150-150

43.64

130.01

0.89

OpenSearch-2.19-faiss

50-1500-1500

169.45

46.35

0.96

OpenSearch-2.19-faiss

50-200-200

48.05

156.07

0.91

OpenSearch-2.19-faiss

50-2000-2000

216.73

36.38

0.96

OpenSearch-2.19-faiss

50-250-250

53.52

142.44

0.93

OpenSearch-2.19-faiss

50-500-500

78.98

97.82

0.95

OpenSearch-2.19-faiss

50-750-750

103.20

75.86

0.96

Rappel à 100

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

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

tâche

latence.moyenne

débit.moyen

avg_recall

Elasticsearch-9.0-BBQ

100-1000-1000

27.82

243.22

0.95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224.04

0.95

Elasticsearch-9.0-BBQ

100-1500-1500

35.98

193.99

0.95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403.86

0.88

Elasticsearch-9.0-BBQ

100-2000-2000

45.36

159.88

0.95

Elasticsearch-9.0-BBQ

100-250-250

14.77

433.06

0.90

Elasticsearch-9.0-BBQ

100-300-300

14.61

375.54

0.91

Elasticsearch-9.0-BBQ

100-500-500

18.88

340.37

0.93

Elasticsearch-9.0-BBQ

100-750-750

23.59

285.79

0.94

OpenSearch-2.19-faiss

100-1000-1000

142.90

58.48

0.95

OpenSearch-2.19-faiss

100-1200-1200

153.03

51.04

0.95

OpenSearch-2.19-faiss

100-1500-1500

181.79

43.20

0.96

OpenSearch-2.19-faiss

100-200-200

50.94

131.62

0.83

OpenSearch-2.19-faiss

100-2000-2000

232.53

33.67

0.96

OpenSearch-2.19-faiss

100-250-250

57.08

131.23

0.87

OpenSearch-2.19-faiss

100-300-300

62.76

120.10

0.89

OpenSearch-2.19-faiss

100-500-500

84.36

91.54

0.93

OpenSearch-2.19-faiss

100-750-750

111.33

69.95

0.94

Améliorations apportées au barbecue

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

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

Conclusion

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

Les principales conclusions sont les suivantes :

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

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

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

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

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

Les développeurs peuvent désormais créer leurs applications RAG dans le cadre d'un parcours unifié, en fondant leurs expériences de chat sur leurs données privées d'une manière flexible et à code bas. Que vous construisiez des agents d'IA pour vos clients et vos employés internes ou que vous exploitiez la génération de LLM dans votre logiciel, la plateforme Vertex AI met la pertinence d'Elasticsearch à votre portée avec une configuration minimale. Cette intégration permet une adoption plus facile et plus rapide des modèles Gemini dans les cas d'utilisation en production, faisant passer la GenAI des PoC aux scénarios de la vie réelle.

Dans ce blog, nous vous guiderons dans l'intégration d'Elasticsearch avec la plateforme Vertex AI de Google Cloud pour un ancrage transparent des données et la création d'applications GenAI entièrement personnalisables. Découvrons comment.

Les modèles Vertex AI et Gemini de Google Cloud sont ancrés dans vos données grâce à Elasticsearch

Les utilisateurs qui tirent parti des services et outils Vertex AI pour créer des applications GenAI peuvent désormais accéder à la nouvelle option "Grounding" qui leur permet d'intégrer automatiquement leurs données privées dans leurs interactions conversationnelles. Elasticsearch fait désormais partie de cette fonctionnalité et peut être utilisé via les deux :

• APIs Vertex AI LLM, qui enrichissent directement les modèles Gemini de Google au moment de la génération (de préférence) ;

• Grounded Generation API, utilisée plutôt dans l'écosystème Vertex AI Agent Builder pour construire des expériences agentiques.

Grâce à cette intégration, Elasticsearch, la base de données vectorielle la plus téléchargée et la plus déployée, apportera vos données d'entreprise pertinentes là où elles sont nécessaires dans vos chats internes et en contact avec les clients, ce qui est crucial pour l'adoption réelle de la GenAI dans les processus d'entreprise.

Les API susmentionnées permettront aux développeurs d'adopter cette nouvelle fonctionnalité dans leur code. Cependant, l'ingénierie et les tests rapides restent des étapes cruciales dans le développement de l'application et servent de terrain de jeu initial. Pour ce faire, Elasticsearch est conçu pour être facilement évalué par les utilisateurs dans l'outil de console Vertex AI Studio.

Il suffit de quelques étapes simples pour configurer les points de terminaison Elastic avec les paramètres souhaités (index à rechercher, nombre de documents à récupérer et modèle de recherche souhaité) dans l'onglet "Customize Grounding" de l'interface utilisateur, comme indiqué ci-dessous (notez que pour que cela fonctionne, vous devez saisir la clé API avec le mot "ApiKey" dans l'interface utilisateur et les exemples de code ci-dessous). Vous êtes maintenant prêt à générer vos propres connaissances !

Des applications GenAI prêtes à la production en toute simplicité

Elastic et Google Cloud s'efforcent d'offrir aux développeurs des expériences complètes et agréables. La connexion à Elastic en mode natif dans les API LLM et Grounding Generation réduit la complexité et les frais généraux lors de la création d'applications GAI sur Vertex AI, en évitant les API supplémentaires inutiles et l'orchestration des données tout en s'appuyant sur un seul appel unifié.

Voyons comment cela fonctionne dans les deux cas.

Le premier exemple est exécuté avec l'API LLM :

Dans l'exemple ci-dessus, avec le champ retrieval de l'API demandant la génération de contenu à Gemini 2.0 Flash, nous pouvons définir contextuellement un moteur de recherche pour la demande. Définir api_spec sur "ELASTIC_SEARCH" permet d'utiliser des paramètres de configuration supplémentaires tels que la clé API et le point de terminaison du cluster (nécessaires pour acheminer une requête vers votre cluster Elastic), l'index à partir duquel récupérer les données et le modèle de recherche à utiliser pour votre logique de recherche.

De même, le même résultat peut être obtenu avec l'API "Grounding Generation", en définissant le paramètre groundingSpec:

Dans les deux cas, la réponse contiendra les documents privés les plus pertinents trouvés dans Elasticsearch - et les sources de données connectées connexes - pour répondre à votre requête.

La simplicité ne doit cependant pas être confondue avec un manque de personnalisation pour répondre à vos besoins spécifiques et à vos cas d'utilisation. C'est dans cet esprit que nous l'avons conçu pour vous permettre d'adapter parfaitement la configuration de la recherche à votre scénario.

Une recherche entièrement personnalisable au bout des doigts : modèles de recherche

Pour personnaliser au maximum votre scénario de recherche, nous avons construit, en collaboration avec Google Cloud, l'expérience au-dessus de nos modèles de recherche bien connus. Les modèles de recherche Elasticsearch sont un excellent outil pour créer des requêtes de recherche dynamiques, réutilisables et faciles à maintenir. Ils permettent de prédéfinir et de réutiliser les structures de requête. Ils sont particulièrement utiles lors de l'exécution de requêtes similaires avec des paramètres différents, car ils permettent d'économiser du temps de développement et de réduire le risque d'erreurs. Les modèles peuvent inclure des espaces réservés pour les variables, ce qui rend les requêtes dynamiques et adaptables aux différents besoins de recherche.

Lorsque vous utilisez les API de Vertex AI et Elasticsearch pour l'ancrage, vous devez faire référence à un modèle de recherche souhaité - comme indiqué dans les extraits de code ci-dessus - où la logique de recherche est mise en œuvre et transmise à Elasticsearch. Les utilisateurs d'Elastic Power peuvent gérer, configurer et mettre à jour les approches de recherche de manière asynchrone et les adapter aux indices, modèles et données spécifiques de manière totalement transparente pour les utilisateurs de Vertex AI, les développeurs d'applications web ou les ingénieurs en intelligence artificielle, qui n'ont qu'à spécifier le nom du modèle dans l'API de base.

Cette conception permet une personnalisation complète, mettant à votre disposition les fonctionnalités de recherche étendues d'Elasticsearch dans un environnement Google Cloud AI, tout en garantissant la modularité, la transparence et la facilité d'utilisation pour les différents développeurs, même ceux qui ne sont pas familiers avec Elastic.

Lorsque vous avez besoin d'une recherche BM25, d'une recherche sémantique ou d'une approche hybride entre les deux (avez-vous déjà exploré les récupérateurs? (techniques de recherche composables en un seul appel à l'API de recherche), vous pouvez définir votre logique personnalisée dans un modèle de recherche, que Vertex AI peut automatiquement exploiter.

Cela s'applique également aux modèles d'intégration et de classement que vous choisissez pour gérer les vecteurs et les résultats. En fonction de votre cas d'utilisation, vous pouvez héberger des modèles sur les nœuds ML d'Elastic, utiliser un point de terminaison de service tiers via l'API d'inférence ou exécuter votre modèle local sur site. Cela est possible grâce à un modèle de recherche, dont nous verrons le fonctionnement dans la section suivante.

Commencez par des modèles de référence, puis créez votre propre modèle.

Pour vous aider à démarrer rapidement, nous avons fourni un ensemble d'exemples de modèles de recherche compatibles à utiliser comme référence initiale ; vous pouvez ensuite les modifier et construire vos modèles personnalisés :

• Recherche sémantique avec le modèle ELSER (vecteurs épars et regroupement)

• Recherche sémantique avec le modèle multilingue e5 (vecteurs denses et regroupement)

• Recherche hybride avec le modèle d'insertion de texte de Vertex AI

Vous pouvez les trouver dans ce repo GitHub.

Prenons un exemple : la création d'embeddings avec les API Vertex AI de Google Cloud sur un catalogue de produits. Tout d'abord, nous devons créer le modèle de recherche dans Elasticsearch comme indiqué ci-dessous :

Dans cet exemple, nous allons exécuter une recherche KNN sur deux champs en une seule recherche : title_embedding - le champ vectoriel contenant le nom du produit - et description_embedding - celui contenant la représentation de sa description.

Vous pouvez tirer parti de la syntaxe excludes pour éviter de renvoyer des champs inutiles au LLM, ce qui pourrait provoquer du bruit dans son traitement et avoir un impact sur la qualité de la réponse finale. Dans notre exemple, nous avons exclu les champs contenant des vecteurs et des urls d'images.

Les vecteurs sont créés à la volée au moment de la requête sur l'entrée soumise via un point de terminaison d'inférence de l'API d'intégration de Vertex AI, googlevertexai_embeddings_004, précédemment défini comme suit :

Vous trouverez des informations supplémentaires sur l'utilisation de l'API d'inférence d'Elastic ici.

Nous sommes maintenant prêts à tester notre modèle de recherche :

Les champs params remplaceront les variables que nous avons définies dans les scripts modèles entre doubles crochets. Actuellement, les API Vertex AI LLM et Grounded Generation peuvent envoyer à Elastic les variables d'entrée suivantes :

• "query" - la requête de l'utilisateur à rechercher

• "index_name" - le nom de l'index dans lequel la recherche doit être effectuée

• "num_hits" - le nombre de documents que nous voulons retrouver dans la sortie finale

Voici un exemple de résultat :

La requête ci-dessus est précisément ce que Vertex AI de Google Cloud exécutera en coulisses sur Elasticsearch en se référant au modèle de recherche créé précédemment. Les modèles Gemini utiliseront les documents de sortie pour fonder leur réponse : lorsque vous demandez "De quoi ai-je besoin pour réparer mes cloisons sèches ?", au lieu d'obtenir une suggestion générique, l'agent conversationnel vous fournira des produits spécifiques !

Parcours GenAI de bout en bout avec Elastic et Google Cloud

Elastic s'associe à Google Cloud pour créer des expériences et des solutions GenAI de bout en bout, prêtes à la production. Comme nous venons de le voir, Elastic est le premier ISV à être intégré directement dans l'interface utilisateur et le SDK de la plateforme Vertex AI, ce qui permet des invites et des agents de modèles Gemini transparents et ancrés dans le sol, utilisant nos fonctions de recherche vectorielle. En outre, Elastic s'intègre à Vertex AI et aux modèles d'intégration, de reclassement et d'achèvement de Google AI Studiopour créer et classer des vecteurs sans quitter le paysage Google Cloud, garantissant ainsi les principes de l'IA responsable. En soutenant les approches multimodales, nous facilitons conjointement les applications dans divers formats de données.

Vous pouvez mettre au point, tester et exporter votre code de recherche GenAI via notre terrain de jeu.

Mais il ne s'agit pas seulement de créer des applications de recherche : Elastic exploite les modèles Gemini pour renforcer les opérations informatiques, comme dans les fonctions Elastic AI Assistants, Attack Discovery et Automatic Import, réduisant la fatigue quotidienne des analystes de sécurité et des SRE sur des tâches à faible valeur ajoutée, et leur permettant de se concentrer sur l'amélioration de leur activité. Elastic permet également une surveillance complète de l'utilisation de Vertex AI, en suivant les métriques et les journaux, comme les temps de réponse, les jetons et les ressources, afin de garantir des performances optimales. Ensemble, nous gérons le cycle de vie complet de la GenAI, depuis l'ingestion de données et la génération d'embedding jusqu'à l'ancrage avec la recherche hybride, tout en garantissant une observabilité et une sécurité robustes des outils de la GenAI avec des actions alimentées par LLM.

Découvrez-en plus et essayez-le !

Êtes-vous intéressé(e) par cet essai ? La fonctionnalité est actuellement disponible sur vos projets Google Cloud !

Si vous ne l'avez pas encore fait, l'une des façons les plus simples de démarrer avec Elastic Search AI Platform et d'explorer nos capacités est d'essayer gratuitement Elastic Cloud ou de vous abonner via Google Cloud Marketplace.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout. Elastic, Elasticsearch et les marques associées sont des marques commerciales, des logos ou des marques déposées d'Elasticsearch N.V. aux États-Unis et dans d'autres pays. Tous les autres noms de produits et d'entreprises sont des marques commerciales, des logos ou des marques déposées appartenant à leurs propriétaires respectifs.

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.

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.

Dans le cadre de notre mission visant à ne négliger aucune efficacité, nous explorons les possibilités d'accélération avec ces curieuses puces informatiques, dont vous avez peut-être entendu parler - les GPU NVIDIA ! (Sérieusement, vous n'en avez pas entendu parler ?).

Lorsque nous sommes obsédés par les performances, nous devons explorer plusieurs espaces de problèmes : comment indexer une quantité exponentielle de données, comment en extraire des informations et comment le faire lorsque vos modèles ML sont impliqués. Vous devriez être en mesure d'exploiter tous les avantages disponibles lorsque vous disposez de GPU.

Dans ce billet, nous nous penchons sur notre collaboration avec l'équipe de recherche vectorielle de NVIDIA pour explorer la recherche vectorielle accélérée par le GPU dans Elasticsearch. Ce travail ouvre la voie à des cas d'utilisation où les développeurs pourraient utiliser un mélange de GPU et de CPU pour des applications réelles basées sur Elasticsearch. Une période passionnante !

Elasticsearch GPUs

Nous sommes ravis d'annoncer que l'équipe d'ingénieurs d'Elasticsearch participe à l'élaboration de l'API Java cuVS open-source pour les développeurs, qui expose des bindings pour les algorithmes de recherche vectorielle. Ce travail s'appuie sur notre expérience antérieure en matière de FFI au Panama. Elasticsearch et Apache Lucene utilisent l'API NVIDIA cuVS pour construire le graphe pendant l'indexation. D'accord, nous faisons un bond en avant ; revenons un peu en arrière.

NVIDIA cuVS, une bibliothèque C++ open-source, est au cœur de cette collaboration. Il vise à apporter l'accélération GPU à la recherche vectorielle en fournissant un débit plus élevé, une latence plus faible et des temps de construction d'index plus rapides. Mais Elasticsearch et Apache Lucene sont écrits en Java ; comment cela fonctionnera-t-il ?

C'est là qu'interviennent lucene-cuvs et la collaboration Elastic-NVIDIA-SearchScale pour l'intégrer à l'écosystème Lucene afin d'explorer la recherche vectorielle accélérée par le GPU dans Elasticsearch. Dans la récente version 25.02 de NVIDIA cuVS, nous avons ajouté une API Java pour cuVS. La nouvelle API est expérimentale et continuera d'évoluer, mais elle est actuellement disponible. La question peut se poser : les appels de fonctions Java à des fonctions natives ne sont-ils pas lents ? Plus maintenant ! Nous utilisons la nouvelle interface Panama FFI (Foreign Function Interface) pour les liaisons, ce qui réduit au minimum les frais généraux pour Java par rapport aux appels descendants natifs.

Nous utilisons Panama FFI dans Elasticsearch et Lucene depuis un certain temps déjà. C'est génial ! Mais... il y a toujours un "mais", n'est-ce pas ? FFI est confronté à des problèmes de disponibilité entre les différentes versions de Java. Nous avons surmonté ce problème en compilant l'API cuVS en Java 21 et en encapsulant l'implémentation dans un jar multi-versions ciblant Java 22. Cela permet d'utiliser cuVS Java directement dans Lucene et Elasticsearch.

Ok, maintenant que nous avons l'API Java cuVS, de quoi d'autre avons-nous besoin ?

Deux algorithmes pour l'unité centrale

Elasticsearch prend en charge l'algorithme HNSW pour une recherche KNN approximative évolutive. Cependant, pour tirer le meilleur parti du GPU, nous utilisons un algorithme différent, CAGRA [CUDA ANN GRAph], qui a été spécialement conçu pour les niveaux élevés de parallélisme offerts par le GPU.

Avant de voir comment nous envisageons d'ajouter la prise en charge de CAGRA, examinons comment Elasticsearch et Lucene accèdent aux données d'index par le biais d'un "format de codec". Il s'agit de

1. la représentation sur disque,

2. les interfaces de lecture et d'écriture des données,

3. et les mécanismes permettant de gérer l'architecture à base de segments de Lucene.

Nous mettons en œuvre un nouveau format de vecteur KNN (k-nearest neighbors) qui utilise en interne l'API Java cuVS pour l'indexation et la recherche sur le GPU. À partir de là, nous "plongeons" ce type de codec dans les correspondances d'Elasticsearch avec un type de champ dans l'index. Par conséquent, vos requêtes KNN existantes continuent de fonctionner, que l'index de référence utilise un graphique CAGRA ou HNSW. Bien entendu, cela ne tient pas compte de nombreux détails, que nous prévoyons d'aborder dans un prochain blog. Voici l'architecture de haut niveau d'un Elasticsearch accéléré par le GPU.

Ce nouveau format de codec est par défaut CAGRA. Cependant, il permet également de convertir un graphique CAGRA en un graphique HNSW pour une recherche sur l'unité centrale.

Indexation et recherche sur le GPU : Prendre quelques décisions "fondamentales

Avec l'architecture sans état d'Elasticsearch Serverless, qui sépare l'indexation et la recherche, les responsabilités sont désormais clairement délimitées. Nous choisissons le meilleur profil de matériel pour remplir chacune de ces responsabilités indépendantes.

Nous pensons que les utilisateurs envisageront deux stratégies de déploiement principales :

1. Indexation et recherche sur le GPU : Pendant l'indexation, construire un graphe CAGRA et l'utiliser pendant la recherche - idéal lorsqu'une recherche à très faible latence est requise.

2. Indexation sur GPU et recherche sur CPU : Pendant l'indexation, construire un graphe CAGRA et le convertir en graphe HNSW. Le graphique HNSW est stocké dans l'index, qui peut ensuite être utilisé par l'unité centrale pour effectuer des recherches.

Cette flexibilité permet de proposer différents modèles de déploiement, offrant des compromis entre le coût et la performance. Par exemple, un service d'indexation pourrait utiliser le GPU pour construire et fusionner efficacement des graphes en temps voulu, tout en utilisant un CPU moins puissant pour la recherche.

Voici donc le plan pour la recherche vectorielle accélérée par le GPU dans Elasticsearch

Nous sommes impatients d'apporter aux utilisateurs des gains de performance et de la flexibilité dans les stratégies de déploiement, en proposant différents boutons pour équilibrer le coût et la performance. Voici la session de la NVIDIA GTC 2025 où ce travail a été présenté en détail.

Nous tenons à remercier les équipes d'ingénieurs de NVIDIA et de SearchScale pour leur fantastique collaboration. Dans un prochain blog, nous examinerons plus en détail les détails de la mise en œuvre et l'analyse des performances. Accrochez-vous à vos chapeaux de curiosité 🎩!

Cette première partie se concentre sur une introduction générale aux bases de l'intégration des vecteurs et au fonctionnement de la recherche vectorielle.

Armé de toutes les connaissances acquises dans le premier article, la deuxième partie vous guidera dans les méandres de la mise en place de la recherche vectorielle dans Elasticsearch.

Dans la troisième partie, nous tirerons parti de ce que nous avons appris dans les deux premières parties, nous nous appuierons sur ces connaissances et nous nous pencherons sur la manière de créer de puissantes requêtes de recherche hybrides dans Elasticsearch.

Avant d'entrer dans le vif du sujet de cet article, remontons dans le temps et passons en revue l'histoire des vecteurs, un concept clé de la recherche sémantique.

Les vecteurs ne sont pas nouveaux

Tout le monde s'accorde à dire que depuis l'avènement de ChatGPT en novembre 2022, il ne se passe pas un jour sans que l'on entende ou lise parler de "recherche vectorielle". Elle est omniprésente et si répandue que nous avons souvent l'impression qu'il s'agit d'une nouvelle technologie de pointe qui vient de voir le jour, alors que la vérité est que cette technologie existe depuis plus de six décennies ! Les recherches sur le sujet ont commencé au milieu des années 1960 et les premiers documents de recherche ont été publiés en 1978 par Gerard Salton, un spécialiste de la recherche d'informations, et ses collègues de l'université de Cornell. Les travaux de Salton sur les modèles de vecteurs denses et épars constituent la base de la technologie moderne de recherche vectorielle.

Au cours des 20 dernières années, de nombreux SGBD vectoriels différents basés sur ses recherches ont été créés et mis sur le marché. Il s'agit notamment d'Elasticsearch alimenté par le projet Apache Lucene, qui a commencé à travailler sur la recherche vectorielle en 2019.

Les vecteurs sont aujourd'hui omniprésents et si répandus qu'il est important de bien comprendre leur théorie sous-jacente et leur fonctionnement interne avant de les utiliser. Avant de nous y plonger, examinons rapidement les différences entre la recherche lexicale et la recherche vectorielle afin de mieux comprendre en quoi elles diffèrent et comment elles peuvent se compléter l'une l'autre.

Recherche vectorielle vs. recherche lexicale

Une façon simple de présenter la recherche vectorielle est de la comparer à la recherche lexicale plus conventionnelle à laquelle vous êtes probablement habitué. La recherche vectorielle, également connue sous le nom de recherche sémantique, et la recherche lexicale fonctionnent de manière très différente. La recherche lexicale est le type de recherche que nous utilisons tous depuis des années dans Elasticsearch. Pour résumer très brièvement, il n'essaie pas de comprendre le sens réel de ce qui est indexé et interrogé, mais fait un gros effort pour faire correspondre lexicalement le littéral des mots ou de leurs variantes (pensez à l'extraction, aux synonymes, etc.) que l'utilisateur tape dans une requête avec tous les littéraux qui ont été précédemment indexés dans la base de données à l'aide d'algorithmes de similarité, tels que le TF-IDF.

Comme nous pouvons le voir, les trois documents en haut à gauche sont codés et analysés. Les termes obtenus sont ensuite indexés dans un index inversé, qui associe simplement les termes analysés aux identifiants des documents qui les contiennent. Notez que tous les termes ne sont présents qu'une seule fois et qu'aucun n'est partagé par un document. La recherche de "gentil professeur d'allemand" aboutira à trois documents avec des scores variables, même si aucun d'entre eux ne reflète réellement le sens de la requête.

Comme le montre la figure 2 ci-dessous, la situation devient encore plus délicate lorsqu'il s'agit de polysémie ou d'homographes, c'est-à-dire de mots qui s'écrivent de la même façon mais qui ont des sens différents (droite, paume, bat, signifie, etc.) Prenons le mot "droite", qui peut avoir trois sens différents, et voyons ce qu'il en est.

La recherche de "I'm not right" renvoie à un document dont la signification est exactement opposée à celle du premier résultat obtenu. Si vous recherchez exactement les mêmes termes mais que vous les ordonnez différemment pour produire un sens différent, par exemple "tourner à droite" et "tourner à droite", vous obtiendrez exactement le même résultat (c'est-à-dire le troisième document "Prendre un virage à droite"). Certes, nos requêtes sont trop simplifiées et n'utilisent pas les requêtes plus avancées telles que la correspondance des phrases, mais cela illustre le fait que la recherche lexicale ne comprend pas la véritable signification de ce qui est indexé et de ce qui est recherché. Si cela n'est pas clair, ne vous inquiétez pas, nous reviendrons sur cet exemple dans le troisième article pour voir comment la recherche vectorielle peut être utile dans ce cas.

Pour rendre justice à la recherche lexicale, lorsque vous avez le contrôle sur la façon dont vous indexez vos données structurées (pensez aux mappings, à l'analyse de texte, aux pipelines d'acquisition, etc.) et sur la façon dont vous élaborez vos requêtes (pensez aux requêtes DSL intelligemment conçues, à l'analyse des termes de la requête, etc. Les résultats d'Elasticsearch concernant ses capacités de recherche lexicale sont tout simplement stupéfiants. Ce qu'il a réalisé et à quel point il a popularisé et amélioré le domaine de la recherche lexicale au cours des dernières années est vraiment remarquable.

Cependant, lorsqu'il s'agit de fournir une assistance pour l'interrogation de données non structurées (images, vidéos, audios, texte brut, etc.) à des utilisateurs qui ont besoin de poser des questions en texte libre, la recherche lexicale n'est pas à la hauteur. De plus, il arrive que la requête ne soit même pas un texte, mais une image, comme nous le verrons bientôt. La principale raison pour laquelle la recherche lexicale est inadéquate dans de telles situations est que les données non structurées ne peuvent être ni indexées ni interrogées de la même manière que les données structurées. Lorsqu'il s'agit de données non structurées, la sémantique entre en jeu. Que signifie la sémantique ? Tout simplement, le sens !

Prenons l'exemple simple d'un moteur de recherche d'images (par exemple, Google Image Search ou Lens). Vous glissez et déposez une image, et le moteur de recherche sémantique de Google trouvera et renverra les images les plus similaires à celle que vous avez interrogée. Dans la figure 3 ci-dessous, on peut voir à gauche la photo d'un berger allemand et à droite toutes les photos similaires qui ont été recherchées, le premier résultat étant la même photo que celle qui a été fournie (c'est-à-dire la plus similaire).

Même si cela semble simple et logique pour nous, les humains, c'est une toute autre histoire pour les ordinateurs. C'est ce que la recherche vectorielle permet et contribue à réaliser. Le pouvoir libéré par la recherche vectorielle est énorme, comme le monde l'a récemment constaté. Soulevons maintenant le capot et découvrons ce qui s'y cache.

Vecteurs d'intégration

Comme nous l'avons vu précédemment, avec les moteurs de recherche lexicaux, les données structurées telles que le texte peuvent facilement être transformées en termes qui peuvent être comparés au moment de la recherche, quelle que soit la signification réelle des termes. Les données non structurées, quant à elles, peuvent prendre différentes formes, telles que des objets binaires de grande taille (images, vidéos, audios, etc.), et ne se prêtent pas du tout au même processus de tokénisation. En outre, l'objectif de la recherche sémantique est d'indexer les données de manière à ce qu'elles puissent être recherchées sur la base de la signification qu'elles représentent. Comment y parvenir ? La réponse tient en deux mots : Apprentissage automatique! Ou plus précisément l'apprentissage en profondeur (Deep Learning) !

L'apprentissage profond est un domaine spécifique de l'apprentissage automatique qui repose sur des modèles basés sur des réseaux neuronaux artificiels composés de plusieurs couches de traitement qui peuvent progressivement extraire le véritable sens des données. Le fonctionnement de ces modèles de réseaux neuronaux s'inspire fortement du cerveau humain. La figure 4, ci-dessous, montre à quoi ressemble un réseau neuronal, avec ses couches d'entrée et de sortie ainsi que ses multiples couches cachées :

La véritable prouesse des réseaux neuronaux est qu'ils sont capables de transformer une simple donnée non structurée en une séquence de valeurs à virgule flottante, connues sous le nom de vecteurs d'intégration ou simplement d'intégration. En tant qu'êtres humains, nous comprenons assez bien ce que sont les vecteurs à condition de les visualiser dans un espace à deux ou trois dimensions. Chaque composante du vecteur représente une coordonnée dans un plan 2D x-y ou un espace 3D x-y-z.

Cependant, les vecteurs d'intégration sur lesquels fonctionnent les modèles de réseaux neuronaux peuvent avoir plusieurs centaines, voire des milliers de dimensions et représentent simplement un point dans un espace multidimensionnel. Chaque dimension vectorielle représente une caractéristique des données non structurées. Illustrons cela avec un modèle d'apprentissage profond qui transforme les images en vecteurs d'intégration de 2048 dimensions. Ce modèle transformerait l'image du berger allemand que nous avons utilisée dans la figure 3 en un vecteur d'intégration présenté dans le tableau ci-dessous. Notez que nous ne montrons que les trois premiers et derniers éléments, mais qu'il y aurait 2 042 colonnes/dimensions supplémentaires dans le tableau.

est_rouge

est_chien

ciel bleu

…

no_gras

berger allemand

est_arbre

Berger allemand embeddings

0.0121

0.9572

0.8735

…

0.1198

0.9712

0.0512

Chaque colonne est une dimension du modèle et représente une caractéristique que le réseau neuronal sous-jacent cherche à modéliser. Chaque entrée donnée au modèle sera caractérisée en fonction de sa similarité avec chacune des 2048 dimensions. Par conséquent, la valeur de chaque élément du vecteur d'intégration indique la similarité de cette entrée avec une dimension spécifique. Dans cet exemple, nous pouvons voir que le modèle a détecté une grande similarité entre les chiens et les bergers allemands ainsi que la présence d'un peu de ciel bleu.

Contrairement à la recherche lexicale, où un terme peut correspondre ou non, la recherche vectorielle permet d'avoir une bien meilleure idée de la similitude d'un élément de données non structurées avec chacune des dimensions prises en charge par le modèle. En tant que tels, les vecteurs d'intégration constituent une formidable représentation sémantique des données non structurées.

La sauce secrète

Maintenant que nous savons comment les données non structurées sont découpées par les réseaux neuronaux d'apprentissage profond en vecteurs d'intégration qui capturent la similarité des données selon un grand nombre de dimensions, nous devons comprendre comment fonctionne la mise en correspondance de ces vecteurs. Il s'avère que la réponse est assez simple. Les vecteurs d'intégration qui sont proches les uns des autres représentent des éléments de données sémantiquement similaires. Ainsi, lorsque nous interrogeons une base de données vectorielles, l'entrée de recherche (image, texte, etc.) est d'abord transformée en un vecteur d'intégration à l'aide du même modèle que celui utilisé pour l'indexation de toutes les données non structurées, et l'objectif final est de trouver les vecteurs voisins les plus proches de ce vecteur d'interrogation. Par conséquent, tout ce que nous avons à faire est de trouver comment mesurer la "distance" ou la "similarité" entre le vecteur de la requête et tous les vecteurs existants indexés dans la base de données, c'est à peu près tout.

Distance et similarité

Heureusement pour nous, la mesure de la distance entre deux vecteurs est un problème facile à résoudre grâce à l'arithmétique vectorielle. Examinons donc les fonctions de distance et de similarité les plus populaires qui sont prises en charge par les bases de données de recherche vectorielle modernes, telles qu'Elasticsearch. Attention, mathématiques en perspective !

Distance L1

La distance L1, également appelée distance de Manhattan, de deux vecteurs x et y est mesurée en additionnant la différence absolue par paire de tous leurs éléments. Il est évident que plus la distance d est petite, plus les deux vecteurs sont proches. La formule est assez simple, comme on peut le voir ci-dessous :

Visuellement, la distance L1 peut être illustrée comme le montre la figure 5 ci-dessous :

Prenons deux vecteurs x et y, tels que x = (1, 2) et y = (4, 3), la distance L1 des deux vecteurs serait alors | 1 - 4 | + | 2 - 3 | = 4.

Distance L2

La distance L2, également appelée distance euclidienne, de deux vecteurs x et y est mesurée en additionnant d'abord le carré de la différence par paire de tous leurs éléments, puis en prenant la racine carrée du résultat. Il s'agit du chemin le plus court entre deux points (également appelé hypoténuse). Comme pour L1, plus la distance d est petite, plus les deux vecteurs sont proches :

La distance L2 est indiquée dans la figure 6 ci-dessous :

Réutilisons les deux mêmes vecteurs d'échantillonnage x et y que nous avons utilisés pour la distance L1, et nous pouvons maintenant calculer la distance L2 comme En prenant la racine carrée de 10, on obtient 3,16.

Distance Linf

La distance Linf (pour L infini), également appelée distance de Tchebychev ou distance de l'échiquier, de deux vecteurs x et y est simplement définie comme la plus longue distance entre deux de leurs éléments ou la plus longue distance mesurée le long de l'un des axes/dimensions. La formule est très simple et est illustrée ci-dessous :

Une représentation de la distance Linf est présentée dans la figure 7 ci-dessous :

De nouveau, en prenant les deux mêmes vecteurs d'échantillonnage x et y, nous pouvons calculer la distance à l'infini comme suit : max ( | 1 - 4 | , | 2 - 3 | ) = max (3, 1) = 3.

Similitude du cosinus

Contrairement à L1, L2 et Linf, la similarité en cosinus ne mesure pas la distance entre deux vecteurs x et y, mais plutôt leur angle relatif, c'est-à-dire s'ils pointent tous deux à peu près dans la même direction. Plus la similarité s est élevée, plus les deux vecteurs sont "proches". La formule est à nouveau très simple et illustrée ci-dessous :

La figure 8 ci-dessous présente une façon de représenter la similarité cosinus entre deux vecteurs :

En outre, comme les valeurs du cosinus sont toujours comprises dans l'intervalle [-1, 1], -1 signifie une similarité opposée (c'est-à-dire un angle de 180° entre les deux vecteurs), 0 signifie une similarité sans rapport (c'est-à-dire un angle de 90°) et 1 signifie une similarité identique (c'est-à-dire un angle de 0°), comme le montre la figure 9 ci-dessous :

Réutilisons à nouveau les mêmes vecteurs d'échantillons x et y et calculons la similitude en cosinus à l'aide de la formule ci-dessus. Tout d'abord, nous pouvons calculer le produit en points des deux vecteurs comme suit : . Ensuite, nous multiplions la longueur (également appelée magnitude) des deux vecteurs : + (4^2 + 3^2)^{1/2} = 11,18034. Enfin, nous divisons le produit en points par la longueur multipliée 10 / 11,18034 = 0,894427 (c'est-à-dire un angle de 26°), qui est assez proche de 1, de sorte que les deux vecteurs peuvent être considérés comme assez similaires.

Similitude du produit de points

L'un des inconvénients de la similitude en cosinus est qu'elle ne prend en compte que l'angle entre deux vecteurs et non leur magnitude (c'est-à-dire leur longueur), ce qui signifie que si deux vecteurs pointent à peu près dans la même direction mais que l'un est beaucoup plus long que l'autre, les deux seront tout de même considérés comme similaires. La similarité par produit de points, également appelée produit scalaire ou produit intérieur, améliore cette situation en tenant compte à la fois de l'angle et de la magnitude des vecteurs, ce qui permet d'obtenir une mesure de similarité beaucoup plus précise.

Deux formules équivalentes sont utilisées pour calculer la similitude du produit de points. La première est la même que celle que nous avons vue plus haut dans le numérateur de la similitude du cosinus :

La deuxième formule multiplie simplement la longueur des deux vecteurs par le cosinus de l'angle qui les sépare :

La similitude du produit des points est illustrée dans la figure 10 ci-dessous :

Une dernière fois, nous prenons les vecteurs x et y de l'échantillon et calculons leur produit en points en utilisant la première formule, comme nous l'avons fait pour la similitude du cosinus plus tôt, soit (1 ) + (2 ) = 10.

En utilisant la deuxième formule, nous multiplions la longueur des deux vecteurs : + (4^2 + 3^2)^{1/2} = 11,18034 et multiplions ce résultat par le cosinus de l'angle de 26° entre les deux vecteurs, et nous obtenons 11,18034 (26°) = 10.

Il convient de noter que si tous les vecteurs sont d'abord normalisés (c'est-à-dire que leur longueur est égale à 1), la similitude du produit de points devient exactement la même que la similitude du cosinus (parce que |x| |y| = 1), c'est-à-dire le cosinus de l'angle entre les deux vecteurs. Comme nous le verrons plus loin, la normalisation des vecteurs est une bonne pratique à adopter afin de rendre la magnitude du vecteur non pertinente, de sorte que la similitude se concentre simplement sur l'angle. Il accélère également le calcul de la distance au moment de l'indexation et de l'interrogation, ce qui peut s'avérer problématique lorsque l'on travaille sur des milliards de vecteurs.

Récapitulatif rapide

Nous avons parcouru beaucoup d'informations jusqu'à présent, alors arrêtons-nous un instant et faisons un rapide récapitulatif de notre situation. Nous avons appris que...

• ...la recherche sémantique est basée sur des modèles de réseaux neuronaux d'apprentissage profond qui excellent dans la transformation de données non structurées en vecteurs d'intégration multidimensionnels.

• ...chaque dimension du modèle représente une caractéristique des données non structurées.

• ...un vecteur d'intégration est une séquence de valeurs de similarité (une pour chaque dimension) qui représente le degré de similarité d'un élément donné de données non structurées par rapport à chaque dimension.

• ...plus deux vecteurs sont "proches" (c'est-à-dire les plus proches voisins), plus ils représentent des concepts sémantiquement similaires.

• ...les fonctions de distance (L1, L2, Linf) nous permettent de mesurer la proximité de deux vecteurs.

• ...les fonctions de similitude (cosinus et produit de points) nous permettent de mesurer à quel point deux vecteurs se dirigent dans la même direction.

Le dernier élément qu'il nous reste à examiner est le moteur de recherche vectoriel lui-même. Lorsqu'une requête arrive, elle est d'abord vectorisée, puis le moteur de recherche vectorielle trouve les vecteurs voisins les plus proches du vecteur de la requête. L'approche brute consistant à mesurer la distance ou la similarité entre le vecteur de la requête et tous les vecteurs de la base de données peut fonctionner pour de petits ensembles de données, mais s'avère rapidement insuffisante lorsque le nombre de vecteurs augmente. En d'autres termes, comment pouvons-nous indexer des millions, des milliards, voire des trillions de vecteurs et trouver les plus proches voisins du vecteur interrogé dans un délai raisonnable ? C'est là que nous devons faire preuve d'intelligence et trouver des moyens optimaux d'indexer les vecteurs de manière à ce que nous puissions trouver les plus proches voisins aussi rapidement que possible sans trop dégrader la précision.

Algorithmes et techniques de recherche vectorielle

Au fil des ans, de nombreuses équipes de recherche ont investi beaucoup d'efforts dans le développement d'algorithmes de recherche vectorielle très intelligents. Nous allons ici présenter brièvement les principaux d'entre eux. Selon le cas d'utilisation, certains sont mieux adaptés que d'autres.

Recherche linéaire

Nous avons brièvement abordé la recherche linéaire, ou indexation plate, lorsque nous avons mentionné l'approche brute consistant à comparer le vecteur de la requête à tous les vecteurs présents dans la base de données. Bien qu'elle puisse donner de bons résultats sur de petits ensembles de données, les performances diminuent rapidement lorsque le nombre de vecteurs et de dimensions augmente (complexité O(n)).

Heureusement, il existe des approches plus efficaces, appelées approximation du plus proche voisin (ANN), dans lesquelles les distances entre les vecteurs d'intégration sont calculées à l'avance et les vecteurs similaires sont stockés et organisés de manière à rester proches les uns des autres, par exemple à l'aide de grappes, d'arbres, de hachages ou de graphes. Ces approches sont dites "approximatives" car elles ne garantissent généralement pas une précision de 100%. L'objectif final est de réduire l'étendue de la recherche autant et aussi rapidement que possible afin de se concentrer uniquement sur les zones les plus susceptibles de contenir des vecteurs similaires ou de réduire la dimensionnalité des vecteurs.

Arbres à K dimensions

Un arbre à K dimensions, ou arbre KD, est une généralisation d'un arbre de recherche binaire qui stocke des points dans un espace à k dimensions et fonctionne en divisant continuellement l'espace de recherche en arbres plus petits à gauche et à droite où les vecteurs sont indexés. Au moment de la recherche, l'algorithme doit simplement visiter quelques branches de l'arbre autour du vecteur de la requête (le point rouge dans la figure 11) afin de trouver le plus proche voisin (le point vert dans la figure 11). Si plus de k voisins sont demandés, la zone jaune est étendue jusqu'à ce que l'algorithme trouve d'autres voisins.

Le principal avantage de l'algorithme de l'arbre KD est qu'il nous permet de nous concentrer rapidement sur certaines branches localisées de l'arbre, éliminant ainsi la plupart des vecteurs. Toutefois, l'efficacité de cet algorithme diminue à mesure que le nombre de dimensions augmente, car il faut visiter beaucoup plus de branches que dans les espaces de dimensions inférieures.

Index de fichier inversé

L'approche de l'index inversé des fichiers (IVF) est également un algorithme de partitionnement de l'espace qui affecte les vecteurs proches les uns des autres à leur centroïde commun. Dans l'espace 2D, le diagramme de Voronoï, comme le montre la figure 12, permet de mieux visualiser ce phénomène :

Nous pouvons voir que l'espace 2D ci-dessus est divisé en 20 groupes, chacun ayant son centroïde représenté par des points noirs. Tous les vecteurs d'intégration dans l'espace sont affectés au groupe dont le centroïde est le plus proche. Au moment de la recherche, l'algorithme détermine d'abord le groupe sur lequel il doit se concentrer en trouvant le centroïde le plus proche du vecteur de la requête, puis il peut simplement se concentrer sur cette zone, ainsi que sur les zones environnantes si nécessaire, afin de trouver les voisins les plus proches.

Cet algorithme souffre du même problème que les arbres KD lorsqu'il est utilisé dans des espaces à haute dimension. C'est ce qu'on appelle la malédiction de la dimensionnalité, qui se produit lorsque le volume de l'espace augmente tellement que toutes les données semblent éparses et que la quantité de données nécessaires pour obtenir des résultats plus précis croît de manière exponentielle. Lorsque les données sont éparses, il est plus difficile pour ces algorithmes de partitionnement de l'espace d'organiser les données en grappes. Heureusement pour nous, il existe d'autres algorithmes et techniques qui atténuent ce problème, comme indiqué ci-dessous.

Quantification

La quantification est une approche basée sur la compressionqui nous permet de réduire la taille totale de la base de données en diminuant la précision des vecteurs d'intégration. Ceci peut être réalisé en utilisant la quantification scalaire (SQ) en convertissant les valeurs vectorielles à virgule flottante en valeurs entières. Cela permet non seulement de réduire la taille de la base de données d'un facteur 8, mais aussi de diminuer la consommation de mémoire et d'accélérer le calcul de la distance entre les vecteurs au moment de la recherche.

Une autre technique, appelée quantification par produit (PQ), divise d'abord l'espace en sous-espaces de dimensions inférieures, puis les vecteurs proches les uns des autres sont regroupés dans chaque sous-espace à l'aide d'un algorithme de regroupement (similaire aux k-moyennes).

Il convient de noter que la quantification diffère de la réduction de la dimensionnalité, où le nombre de dimensions est réduit, c'est-à-dire que les vecteurs deviennent simplement plus courts.

Petits mondes navigables hiérarchiques (PMNH)

Si le nom semble complexe, ne vous inquiétez pas, ce n'est pas vraiment le cas ! En résumé, Hierarchical Navigable Small Worlds est un algorithme basé sur un graphe multicouche qui est très populaire et efficace. Il est utilisé par de nombreuses bases de données vectorielles, dont Apache Lucene. La figure 13 ci-dessous présente une représentation conceptuelle de HNSW.

Sur la couche supérieure, nous pouvons voir un graphique de très peu de vecteurs qui ont les liens les plus longs entre eux, c'est-à-dire un graphique de vecteurs connectés avec le moins de similarité. Plus nous plongeons dans les couches inférieures, plus nous trouvons de vecteurs et plus le graphique devient dense, avec de plus en plus de vecteurs proches les uns des autres. Dans la couche la plus basse, on trouve tous les vecteurs, les plus similaires étant les plus proches les uns des autres.

Au moment de la recherche, l'algorithme part de la couche supérieure à un point d'entrée arbitraire et trouve le vecteur le plus proche du vecteur de la requête (représenté par le point gris). Ensuite, il se déplace d'une couche à l'autre et répète le même processus, en partant du même vecteur que celui qu'il a laissé dans la couche précédente, et ainsi de suite, une couche après l'autre, jusqu'à ce qu'il atteigne la couche la plus basse et trouve le voisin le plus proche du vecteur de la requête.

Hachage sensible à la localité (LSH)

Dans la même veine que toutes les autres approches présentées jusqu'à présent, le hachage sensible à la localité vise à réduire considérablement l'espace de recherche afin d'augmenter la vitesse d'extraction. Avec cette technique, les vecteurs d'intégration sont transformés en valeurs de hachage, tout en préservant les informations de similarité, de sorte que l'espace de recherche devient finalement une simple table de hachage qui peut être consultée au lieu d'un graphe ou d'un arbre qui doit être parcouru. Le principal avantage des méthodes basées sur les hachages est que les vecteurs contenant un nombre arbitraire (important) de dimensions peuvent être mis en correspondance avec des hachages de taille fixe, ce qui accélère considérablement le temps de recherche sans sacrifier trop de précision.

Il existe de nombreuses façons de hacher les données en général, et d'intégrer des vecteurs en particulier, mais cet article n'entrera pas dans les détails de chacune d'entre elles. Les méthodes de hachage conventionnelles produisent généralement des hachages très différents pour des données qui semblent très similaires. Les vecteurs d'intégration étant composés de valeurs flottantes, prenons deux exemples de valeurs flottantes considérées comme très proches l'une de l'autre dans l'arithmétique vectorielle (par exemple, 0,73 et 0,74) et soumettons-les à quelques fonctions de hachage courantes. En regardant les résultats ci-dessous, il est évident que les fonctions de hachage courantes ne conservent pas la similarité entre les entrées.

Fonction de hachage

0.73

0.74

MD5

1342129d04cd2924dd06cead4cf0a3ca

0aec1b15371bd979cfa66b0a50ebecc5

SHA1

49d2c3e0e44bff838e1db571a121be5ea874e8d9

a534e76482ade9d9fe4bff3035a7f31f2f363d77

SHA256

99d03fc3771fe6848d675339fc49eeb1cb8d99a12e6358173336b99a2ec530ea

5ecbc825ba5c16856edfdaf0abc5c6c41d0d8a9c508e34188239521dc7645663

Alors que les méthodes de hachage classiques tentent de minimiser les collisions de hachage entre des données similaires, l'objectif principal du hachage sensible à la localité est de faire exactement le contraire, c'est-à-dire de maximiser les collisions de hachage afin que des données similaires tombent dans le même bac avec une forte probabilité. Ainsi, les vecteurs d'intégration qui sont proches les uns des autres dans un espace multidimensionnel seront hachés en une valeur de taille fixe tombant dans le même panier. Comme LSH permet à ces vecteurs hachés de conserver leur proximité, cette technique s'avère très pratique pour le regroupement de données et la recherche du voisin le plus proche.

Tout le travail se fait au moment de l'indexation, lorsque les hachages doivent être calculés, tandis qu'au moment de la recherche, il suffit de hacher le vecteur de la requête pour rechercher le seau contenant les vecteurs d'intégration les plus proches. Une fois le seau candidat trouvé, un deuxième tour a généralement lieu pour identifier les vecteurs voisins les plus proches du vecteur d'interrogation.

Concluons

Pour présenter la recherche vectorielle, nous avons dû couvrir un certain nombre de points dans cet article. Après avoir comparé les différences entre la recherche lexicale et la recherche vectorielle, nous avons appris comment les modèles de réseaux neuronaux d'apprentissage profond parviennent à capturer la sémantique des données non structurées et à transcoder leur signification en vecteurs d'intégration à haute dimension, une séquence de nombres à virgule flottante représentant la similarité des données selon chacune des dimensions du modèle. Il convient également de noter que la recherche vectorielle et la recherche lexicale ne sont pas des techniques de recherche d'informations concurrentes mais complémentaires (comme nous le verrons dans la troisième partie de cette série, lorsque nous nous pencherons sur la recherche hybride).

Nous avons ensuite présenté un élément fondamental de la recherche vectorielle, à savoir les fonctions de distance (et de similarité) qui nous permettent de mesurer la proximité de deux vecteurs et d'évaluer la similarité des concepts qu'ils représentent.

Enfin, nous avons passé en revue les différentes variantes des algorithmes et techniques de recherche vectorielle les plus populaires, qui peuvent être basés sur des arbres, des graphes, des grappes ou des hachages, et dont l'objectif est de se concentrer rapidement sur une zone spécifique de l'espace multidimensionnel afin de trouver les voisins les plus proches sans avoir à visiter l'ensemble de l'espace comme le ferait une recherche linéaire par force brute.

Si vous aimez ce que vous lisez, n'hésitez pas à consulter les autres parties de cette série :

• Partie 2 : Comment configurer la recherche vectorielle dans Elasticsearch

• Partie 3 : Recherche hybride avec Elasticsearch

Le connecteur Semantic Kernel Elasticsearch Vector Store, prêt à l'emploi, prend en charge les abstractions du Semantic Kernel vector store, ce qui permet aux développeurs de brancher très facilement Elasticsearch en tant que magasin vectoriel lors de la création d'agents d'intelligence artificielle.

Elasticsearch est solidement ancré dans la communauté des logiciels libres et a récemment adopté la licence AGPL. Associés au noyau sémantique Microsoft open-source, ces outils offrent une solution puissante, prête pour l'entreprise. Vous pouvez commencer localement en démarrant Elasticsearch en quelques minutes en exécutant cette commande curl -fsSL https://elastic.co/start-local | sh (voir start-local pour plus de détails) et évoluer vers des versions hébergées dans le nuage ou auto-hébergées tout en mettant en production vos agents d'IA.

Dans ce blog, nous verrons comment utiliser le connecteur Semantic Kernel Elasticsearch Vector Store lors de l'utilisation de Semantic Kernel. Une version Python du connecteur sera disponible à l'avenir.

Scénario de haut niveau : Construire une application RAG avec Semantic Kernel & Elasticsearch

Dans la section suivante, nous présentons un exemple. À un niveau élevé, nous construisons une application RAG (Retrieval Augmented Generation) qui prend la question d'un utilisateur en entrée et renvoie une réponse. Nous utiliserons Azure OpenAI(un LLM local peut également être utilisé) comme LLM, Elasticsearch comme magasin de vecteurs et Semantic Kernel (.net) comme cadre pour relier tous les composants ensemble.

Si vous n'êtes pas familier avec les architectures RAG, vous pouvez vous familiariser rapidement avec cet article : https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

La réponse est générée par le LLM qui est alimenté par le contexte, pertinent pour la question, récupéré à partir du vectorstore Elasticsearch. La réponse inclut également la source qui a été utilisée comme contexte par le LLM.

Exemple de GCR

Dans cet exemple spécifique, nous créons une application qui permet aux utilisateurs de poser des questions sur les hôtels stockés dans une base de données interne. L'utilisateur peut par exemple rechercher un hôtel spécifique, en fonction de différents critères, ou demander une liste d'hôtels.

Pour la base de données d'exemple, nous avons généré une liste d'hôtels contenant 100 entrées. La taille de l'échantillon est volontairement réduite pour vous permettre d'essayer la démo du connecteur aussi facilement que possible. Dans une application réelle, le connecteur Elasticsearch montrerait ses avantages par rapport à d'autres options, telles que l'implémentation du magasin vectoriel `InMemory`, en particulier lorsque l'on travaille avec de très grandes quantités de données.

L'application de démonstration complète se trouve dans le référentiel du connecteur Elasticsearch vector store.

Commençons par ajouter les paquets NuGet et les directives nécessaires à notre projet :

Nous pouvons maintenant créer notre modèle de données et le doter d'attributs spécifiques au Semantic Kernel pour définir le schéma du modèle de stockage et quelques indications pour la recherche textuelle :

Les attributs du schéma du modèle de stockage (`VectorStore*`) sont les plus pertinents pour l'utilisation réelle du connecteur Elasticsearch Vector Store, à savoir :

• VectorStoreRecordKey pour marquer une propriété d'une classe d'enregistrement comme étant la clé sous laquelle l'enregistrement est stocké dans un magasin vectoriel.

• VectorStoreRecordData pour marquer une propriété d'une classe d'enregistrement comme "data".

• VectorStoreRecordVector pour marquer une propriété d'une classe d'enregistrement en tant que vecteur.

Tous ces attributs acceptent divers paramètres facultatifs qui peuvent être utilisés pour personnaliser davantage le modèle de stockage. Dans le cas de VectorStoreRecordKey , par exemple, il est possible de spécifier une fonction de distance différente ou un type d'indice différent.

Les attributs de recherche de texte (TextSearch*) seront importants dans la dernière étape de cet exemple. Nous y reviendrons plus tard.

Dans l'étape suivante, nous initialisons le moteur du noyau sémantique et obtenons des références aux services de base. Dans une application réelle, l' injection de dépendances devrait être utilisée au lieu d'accéder directement à la collection de services. La même chose s'applique à la configuration et aux secrets codés en dur, qui doivent être lus à l'aide d'un fournisseur de configuration:

Le service vectorStoreCollection peut maintenant être utilisé pour créer la collection et ingérer quelques enregistrements de démonstration :

Cela montre comment Semantic Kernel réduit l'utilisation d'un magasin de vecteurs, avec toute sa complexité, à quelques simples appels de méthodes.

Sous le capot, un nouvel index est créé dans Elasticsearch et tous les mappages de propriétés nécessaires sont créés. Notre ensemble de données est ensuite intégré de manière totalement transparente dans le modèle de stockage et finalement stocké dans l'index. Voici à quoi ressemblent les mappings dans Elasticsearch.

Le site embeddings.GenerateEmbeddingsAsync() appelle de manière transparente le service Azure AI Embeddings Generation configuré.

La dernière étape de cette démonstration est encore plus magique.

Avec un seul appel à InvokePromptAsync, toutes les opérations suivantes sont effectuées lorsque l'utilisateur pose une question sur les données :

1. L'intégration de la question de l'utilisateur est générée.

2. Le magasin de vecteurs est parcouru à la recherche d'entrées pertinentes

3. Les résultats de la requête sont insérés dans un modèle d'invite

4. La requête proprement dite, sous la forme de l'invite finale, est envoyée au service d'achèvement de chat de l'IA.

Vous vous souvenez des attributs TextSearch* que nous avons définis précédemment dans notre modèle de données ? Ces attributs nous permettent d'utiliser les espaces réservés correspondants dans notre modèle d'invite, qui sont automatiquement remplis avec les informations provenant de nos entrées dans le magasin de vecteurs.

La réponse finale à notre question "Veuillez m'indiquer tous les hôtels qui disposent d'un bar sur le toit." est la suivante :

La réponse se réfère correctement à l'entrée suivante dans notre fichier hotels.csv

Cet exemple montre très bien comment l'utilisation de Microsoft Semantic Kernel permet une réduction significative de la complexité grâce à ses abstractions bien pensées, tout en permettant un très haut niveau de flexibilité. En changeant une seule ligne de code, par exemple, le magasin de vecteurs ou les services d'intelligence artificielle utilisés peuvent être remplacés sans qu'il soit nécessaire de remanier une autre partie du code.

Dans le même temps, le cadre fournit un ensemble considérable de fonctionnalités de haut niveau, telles que la fonction `InvokePrompt`, ou le système de plugin de modèle ou de recherche.

L'application de démonstration complète se trouve dans le référentiel du connecteur Elasticsearch vector store.

Quelles sont les autres possibilités offertes par Elasticsearch ?

• Nouveau mappage semantic_text d'Elasticsearch : Simplifier la recherche sémantique

• Classement sémantique dans Elasticsearch à l'aide d'extracteurs

• Techniques avancées de RAG partie 1 : Traitement des données

• Techniques avancées de RAG, partie 2 : Requêtes et tests

• Construire RAG avec Llama 3 open-source et Elastic

• Un tutoriel sur la construction d'un agent local utilisant LangGraph, LLaMA3 et Elasticsearch vector store à partir de zéro

Elasticsearch & Semantic Kernel : Quelle est la prochaine étape ?

• Nous avons montré comment le magasin vectoriel Elasticsearch peut être facilement intégré au Semantic Kernel lors de la construction d'applications GenAI en .NET. Restez à l'écoute pour une prochaine intégration de Python.

• Comme Semantic Kernel construit des abstractions pour des fonctions de recherche avancées telles que la recherche hybride, la connexion Elasticsearch permettra aux développeurs .NET de les mettre en œuvre facilement tout en utilisant Semantic Kernel.

Outre l'intégration de la recherche hybride, nous vous montrerons comment ajouter des fonctionnalités qui rendront votre solution de recherche encore plus robuste. Il s'agit notamment des facettes et des promotions de produits personnalisées. En outre, nous vous montrerons comment capturer les interactions des utilisateurs et générer des informations précieuses à l'aide de l'outil d'analyse comportementale d'Elastic.

Dans cette mise en œuvre, vous verrez comment construire à la fois l'interface qui permet aux utilisateurs de visualiser et d'interagir avec les résultats de la recherche et l'API responsable du retour des informations. Pour accéder aux dépôts contenant le code source, les liens sont fournis ci-dessous :

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/product-store-search

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/app-product-store

Nous avons divisé ce guide en plusieurs étapes, de la création de l'index à la mise en œuvre de fonctionnalités avancées telles que les facettes et la personnalisation des résultats. À la fin, vous aurez une solution de recherche robuste prête à être utilisée dans un scénario de commerce électronique.

Configuration de l'environnement pour la recherche hybride dans le domaine du commerce électronique

Avant de commencer la mise en œuvre, nous devons mettre en place l'environnement. Vous pouvez choisir d'utiliser un service sur Elastic Cloud ou une solution conteneurisée pour gérer Elasticsearch. Si vous choisissez la conteneurisation, une configuration via Docker Compose peut être trouvée dans ce dépôt : docker-compose.yml.

Création d'index et ingestion de catalogues de produits

L'index sera créé sur la base d'un catalogue de produits cosmétiques, qui comprend des champs tels que le nom, la description, la photo, la catégorie et les étiquettes. Les champs utilisés pour la recherche en texte intégral, tels que "nom" et "description," seront mappés comme text, tandis que les champs utilisés pour les agrégations, tels que "catégorie" et "marque," seront mappés comme keyword pour permettre les facettes.

Le champ "description" sera utilisé pour la recherche vectorielle, car il fournit plus de détails sur les produits. Ce champ sera défini comme dense_vector, stockant la représentation vectorielle de la description.

La correspondance de l'index sera la suivante :

Le script de création de l'index est disponible ici.

Génération de l'intégration

Pour vectoriser les descriptions de produits, nous utilisons le modèle all-MiniLM-L6-v2. Dans ce cas, l'application est responsable de la génération des embeddings avant l'indexation. Une autre option serait d'importer le modèle dans le cluster Elasticsearch, mais pour cet environnement local, nous avons choisi d'effectuer la vectorisation directement dans l'application.

Nous avons utilisé l'ensemble de données sur les cosmétiques disponible sur Kaggle pour alimenter l'index, et pour améliorer l'efficacité de l'ingestion des données, nous avons utilisé le traitement par lots. Au cours de cette même étape d'ingestion, nous générerons les embeddings pour le champ "description" et les indexerons dans le nouveau champ "description_embeddings".

Le processus complet d'ingestion des données peut être suivi et exécuté directement via le carnet Jupyter disponible dans le référentiel. Le carnet de notes fournit un guide étape par étape sur la façon dont les données sont lues, traitées et indexées dans Elasticsearch, ce qui permet de les reproduire et de les expérimenter facilement.

Vous pouvez accéder au carnet en cliquant sur le lien suivant : Cahier d'ingestion.

Mise en œuvre de la recherche hybride

Mettons maintenant en œuvre la recherche hybride. Pour la recherche par mot-clé, nous utilisons la requête multi_match, ciblant les champs "nom," " catégorie," et "description." Cela permet de s'assurer que les documents contenant le terme de recherche dans n'importe lequel de ces champs sont retrouvés.

Pour la recherche vectorielle, nous utilisons la requête KNN. Le terme de recherche doit être vectorisé avant d'exécuter la requête, ce qui est fait à l'aide de la méthode qui vectorise le terme d'entrée. Notez que le modèle utilisé lors de l'ingestion est également utilisé pour le terme de recherche.

La combinaison des deux recherches est réalisée à l'aide de l'algorithme Reciprocal Rank Fusion (RRF) , qui fusionne les résultats des deux requêtes et augmente la précision de la recherche en réduisant le bruit. RRF permet aux recherches par mots-clés et aux recherches vectorielles de fonctionner ensemble, améliorant ainsi la compréhension de la requête de l'utilisateur.

Comparaison des résultats : recherche par mot-clé et recherche hybride

Comparons maintenant les résultats d'une recherche traditionnelle par mot-clé avec ceux d'une recherche hybride. En recherchant "foundation for dry skin" à l'aide de mots-clés, nous obtenons les résultats suivants :

1. Revlon ColorStay Makeup pour peau normale / sècheDescription: Le maquillage Revlon ColorStay offre une couverture longue durée grâce à une formule légère qui ne s'étale pas, ne s'estompe pas et ne s'efface pas. Grâce à la technologie Time Release, cette formule sans huile à l'équilibre hydrique est spécialement conçue pour les peaux normales ou sèches afin de leur apporter une hydratation continue : Le maquillage est confortable et tient jusqu'à 24 heures. Couvrance moyenne à complète.

2. Fond de teint mousse Maybelline Dream SmoothDescription: Pourquoi vous allez l'adorerUn fond de teint crème fouettée unique qui offre 100% une perfection lisse comme un bébé.\N- Peau L'apparence et la sensation d'hydratation durent 14 heures - jamais rugueuse ou sèche. La formule légère offre une couverture parfaitement hydratante. Elle s'intègre parfaitement et donne une sensation de fraîcheur tout au long de la journée. Sans huile, sans parfum, testée par des dermatologues, testée contre les allergies, non comédogène. pour les peaux sensibles.

Analyse: Lors de la recherche de "foundation for dry skin," les résultats ont été obtenus par la correspondance exacte entre les mots-clés de la recherche et les titres et descriptions des produits. Cependant, cette correspondance ne reflète pas toujours le meilleur choix. Par exemple, le maquillage Revlon ColorStay pour peau normale/sèche est une bonne option, car il est spécifiquement formulé pour les peaux sèches. Bien qu'elle soit sans huile, sa formule est conçue pour offrir une hydratation continue. En revanche, nous avons également reçu le fond de teint Maybelline Dream Smooth Mousse, qui, bien que sans huile et mentionnant l'hydratation, est généralement plus recommandé pour les peaux grasses ou mixtes, car les produits sans huile ont tendance à se concentrer sur le contrôle du sébum plutôt qu'à fournir l'hydratation supplémentaire nécessaire aux peaux sèches. Cela met en évidence les limites des recherches par mots clés, qui peuvent renvoyer des produits ne répondant pas entièrement aux besoins spécifiques des personnes ayant la peau sèche.

Maintenant, si l'on effectue la même recherche en utilisant l'approche hybride :

1. CoverGirl Outlast Stay Luminous Foundation Creamy Natural (820):Description: Le fond de teint Outlast Stay Luminous de CoverGirl est parfait pour obtenir un fini rosé et un éclat subtil. Il est sans huile, avec une formule non grasse qui donne à votre peau une luminosité naturelle qui dure toute la journée ! Ce fond de teint, qui dure toute la journée, hydrate la peau tout en offrant une couverture parfaite. Analyse : Ce produit est pertinent car il met l'accent sur l'hydratation, ce qui est essentiel pour les utilisateurs à la peau sèche. Les termes "hydrates skin" et "dewy finish" correspondent à l'intention de l'utilisateur de trouver un fond de teint pour les peaux sèches. La recherche vectorielle a probablement compris le concept d'hydratation et l'a associé à la nécessité d'un fond de teint qui réponde aux besoins des peaux sèches.

2. Revlon ColorStay Makeup pour peau normale / sèche:Description : Le maquillage Revlon ColorStay offre une couverture longue durée grâce à une formule légère qui ne s'estompe pas, ne se décolore pas et ne s'efface pas. Grâce à la technologie Time Release, cette formule sans huile et équilibrant l'hydratation est spécialement conçue pour les peaux normales ou sèches afin de leur apporter une hydratation continue. Analyse : Ce produit répond directement aux besoins des utilisateurs ayant la peau sèche, en mentionnant explicitement qu'il est formulé pour les peaux normales ou sèches. La formule d'équilibre hydrique "" et l'hydratation continue conviennent parfaitement aux personnes à la recherche d'un fond de teint pour les peaux sèches. La recherche vectorielle a permis d'obtenir ce résultat, non seulement en raison de la correspondance des mots clés, mais aussi parce que l'accent est mis sur l'hydratation et que la peau sèche est spécifiquement mentionnée comme cible démographique.

3. Fond de teint sérumDescription : Les fonds de teint sérum sont des formules légères à couvrance moyenne, disponibles dans une gamme complète de 21 teintes. Ces fonds de teint offrent une couvrance modérée d'aspect naturel avec une sensation de sérum très léger. Ils ont une très faible viscosité et sont distribués avec la pompe fournie ou avec le compte-gouttes en verre optionnel disponible séparément si vous le souhaitez. Analyse : Dans ce cas, la description met l'accent sur un fond de teint sérum léger au toucher naturel, ce qui correspond aux besoins des personnes ayant la peau sèche, qui recherchent souvent des produits doux, hydratants et offrant un fini non gélifié. La recherche vectorielle a probablement pris en compte le contexte plus large de la couverture légère et naturelle et de la texture semblable à celle d'un sérum, qui est associée à la rétention de l'humidité et à une application confortable, ce qui la rend pertinente pour les peaux sèches, même si le terme "dry skin" n'est pas explicitement mentionné.

Mise en œuvre des facettes

Les facettes sont essentielles pour affiner et filtrer efficacement les résultats de la recherche, en offrant aux utilisateurs une navigation plus ciblée, en particulier dans les scénarios comportant une grande variété de produits, tels que le commerce électronique. Ils permettent aux utilisateurs d'ajuster les résultats en fonction d'attributs tels que la catégorie, la marque ou le prix, ce qui rend la recherche plus précise. Pour mettre en œuvre cette fonctionnalité, nous utilisons des agrégations de termes sur les champs category et brand, qui ont été définis comme keyword lors de la phase de création de l'index.

Le code complet de la mise en œuvre est disponible ici.

Voir ci-dessous les résultats de la recherche de "foundation for dry skin":

Personnalisation des résultats : requêtes épinglées

Dans certains cas, il peut être avantageux de promouvoir certains produits dans les résultats de recherche. Pour ce faire, nous utilisons les requêtes épinglées, qui permettent à des produits spécifiques d'apparaître en tête des résultats. Ci-dessous, nous effectuerons une recherche sur le terme "Foundation" sans promouvoir aucun produit :

Dans notre exemple, nous pouvons promouvoir les produits qui portent l'étiquette "Gluten Free." En utilisant les identifiants des produits, nous nous assurons qu'ils sont prioritaires dans les résultats de recherche. Plus précisément, nous ferons la promotion des produits suivants : Fond de teint sérum (ID : 1043), Fond de teint couvrance (ID : 1042) et Poudre fixante invisible Realist (ID : 1039).

Nous utilisons des identifiants de produits spécifiques pour nous assurer qu'ils sont prioritaires dans les résultats de la recherche. La structure de la requête comprend une liste d'ID de produits qui doivent être "épinglés" en haut (dans ce cas, les ID 1043, 1042 et 1039), tandis que les autres résultats suivent le flux organique de la recherche, en utilisant une combinaison de conditions telles que le texte de la requête dans les champs "nom", "catégorie", et "description". Il est ainsi possible de promouvoir des éléments de manière contrôlée, en assurant leur visibilité, tout en maintenant le reste de la recherche sur la base de la pertinence habituelle.

Ci-dessous, vous pouvez voir le résultat de l'exécution de la requête avec les produits promus :

Le code d'interrogation complet est disponible ici.

Analyser le comportement de recherche avec l'analyse comportementale

Jusqu'à présent, nous avons déjà ajouté des fonctionnalités pour améliorer la pertinence des résultats de recherche et faciliter la découverte des produits. Nous allons maintenant finaliser notre solution de recherche en incluant une fonctionnalité qui nous aidera à analyser le comportement de recherche des utilisateurs, en identifiant des modèles tels que les requêtes avec ou sans résultats et les clics sur les résultats de la recherche.pour cela, nous utiliserons la fonctionnalité Behavioral Analytics fournie par Elastic. Grâce à lui, en quelques étapes seulement, nous pouvons surveiller et analyser le comportement de recherche des utilisateurs, en obtenant des informations précieuses pour optimiser l'expérience de recherche.

Création de la collection d'analyses comportementales

Notre première action sera de créer une collection, qui sera responsable de la réception de tous les événements d'analyse du comportement. Pour créer la collection, accédez à l'interface Kibana dans Search > Behavioral Analytics. Dans l'exemple ci-dessous, nous avons créé une collection nommée tracking-search.

Intégrer l'analyse comportementale dans l'interface

Notre application frontale a été développée en JavaScript, et pour intégrer Behavioral Analytics, nous suivrons les étapes décrites dans la documentation officielle d'Elastic pour installer le Behavioral Analytics JavaScript Tracker.

Mise en œuvre du tracker JavaScript

Nous allons maintenant importer le client tracker dans notre application et utiliser les méthodes trackPageView, trackSearch, et trackSearchClick pour capturer les interactions des utilisateurs.

Avertissement: Bien que nous utilisions un outil pour collecter les données d'interaction des utilisateurs, il est essentiel d'assurer la conformité avec le GDPR. Cela signifie qu'il faut informer clairement les utilisateurs des données collectées et de la manière dont elles seront utilisées, et leur donner la possibilité de refuser le suivi. En outre, nous devons mettre en œuvre de solides mesures de sécurité pour protéger les informations collectées et respecter les droits des utilisateurs, tels que l'accès aux données et leur suppression, en veillant à ce que toutes les étapes soient conformes aux principes du GDPR.

Étape 1 : Création de l'instance de suivi

Tout d'abord, nous allons créer l'instance de suivi qui surveillera les interactions. Dans cette configuration, nous définissons le point de terminaison cible, le nom de la collection et la clé API :

Étape 2 : Capturer les pages vues

Pour suivre les pages vues, nous pouvons configurer l'événement trackPageView:

Pour plus de détails sur l'événement trackPageView, vous pouvez consulter cette documentation.

Étape 3 : Saisir les requêtes de recherche

Pour suivre les actions de recherche des utilisateurs, nous utiliserons la méthode trackSearch:

Ici, nous collectons le terme de recherche et les résultats de la recherche.

Étape 4 : Suivi des clics sur les résultats de recherche

Enfin, pour capturer les clics sur les résultats de recherche, nous utiliserons la méthode trackSearchClick:

Nous recueillons des informations sur l'identifiant du document cliqué, ainsi que sur le terme et les résultats de la recherche.

Analyse des données dans Kibana

Maintenant que les événements d'interaction avec l'utilisateur sont capturés, nous pouvons obtenir des données précieuses sur les actions de recherche. Kibana utilise l'outil d'analyse comportementale pour visualiser et analyser ces données comportementales. Pour afficher les résultats, il suffit de naviguer vers Search > Behavioral Analytics > My Collection, où une vue d'ensemble des événements capturés s'affichera.

Cette vue d'ensemble nous donne un aperçu général des événements capturés pour chaque action intégrée dans notre interface. Ces informations nous permettent d'obtenir des informations précieuses sur le comportement de recherche des utilisateurs. Cependant, si vous souhaitez créer des tableaux de bord personnalisés avec des mesures plus pertinentes pour votre scénario spécifique, Kibana offre des outils puissants pour construire des tableaux de bord, vous permettant de créer diverses visualisations de vos mesures.

Ci-dessous, j'ai créé quelques visualisations et graphiques pour suivre, par exemple, les termes les plus recherchés au fil du temps, les requêtes qui n'ont donné aucun résultat, un nuage de mots mettant en évidence les termes les plus recherchés et, enfin, une visualisation géographique pour identifier d'où vient l'accès à la recherche.

Conclusion

Dans cet article, nous avons mis en œuvre une solution de recherche hybride qui combine la recherche par mot-clé et la recherche vectorielle, offrant ainsi des résultats plus précis et plus pertinents aux utilisateurs. Nous avons également étudié comment utiliser des fonctionnalités supplémentaires, telles que les facettes et la personnalisation des résultats avec les requêtes épinglées, afin de créer une expérience de recherche plus complète et plus efficace.

En outre, nous avons intégré l'analyse comportementale d'Elastic pour capturer et analyser le comportement des utilisateurs au cours de leurs interactions avec le moteur de recherche. En utilisant des méthodes telles que trackPageView, trackSearch, et trackSearchClick, nous avons pu suivre les requêtes de recherche, les clics sur les résultats de recherche et les pages consultées, ce qui nous a permis d'obtenir des informations précieuses sur le comportement de recherche.

Références

Ensemble de données

https://www.kaggle.com/datasets/shivd24coder/cosmetic-brand-products-dataset

Transformateur

https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2

Fusion de rangs réciproques

https://www.elastic.co/guide/en/elasticsearch/reference/current/rrf.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/retriever.html#rrf-retriever

Requête Knn

https://www.elastic.co/guide/en/elasticsearch/reference/current/knn-search.html

Requête épinglée

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-pinned-query.html

API d'analyse comportementale

https://www.elastic.co/guide/en/elasticsearch/reference/current/behavioral-analytics-apis.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/behavioral-analytics-overview.html

NOTE Si vous êtes familier avec l'ancienne version du client Elasticsearch C# NEST, lisez cet article de blog sur la dépréciation du client NEST et les nouvelles fonctionnalités. NEST était la génération précédente du client .NET, qui a été remplacée par le client Elastic.Clients.Elasticsearch package

• Qu'est-ce que Blazor ?

• Qu'est-ce que l'ESRE ?

• Configuration d'ELSER

• Indexation des données

• Demande de permis de construire

Qu'est-ce que Blazor ?

Blazor est un framework web open source basé sur HTML, CSS et C# créé par Microsoft pour permettre aux développeurs de créer des applications web qui s'exécutent sur le client ou le serveur. Blazor vous permet également de créer des composants réutilisables pour construire des applications plus rapidement ; il permet aux développeurs de construire la vue HTML et les actions en C# dans le même fichier, ce qui aide à maintenir un code lisible et propre. De plus, avec Blazor Hybrid, vous pouvez créer des applications mobiles natives accédant aux capacités de la plateforme native via le code .NET.

Quelques-unes des caractéristiques qui font de Blazor un framework idéal pour travailler :

• Options de rendu côté serveur et côté client

• Composants réutilisables de l'interface utilisateur

• Mises à jour en temps réel avec SignalR

• Gestion intégrée des états

• Système de routage intégré

• Vérifications solides du typage et de la compilation

Pourquoi Blazor ?

Blazor offre plusieurs avantages par rapport à d'autres cadres et bibliothèques : il permet aux développeurs d'utiliser le langage C# pour le code client et le code serveur, en fournissant un typage fort et une vérification au moment de la compilation, ce qui améliore la fiabilité. Il s'intègre parfaitement à l'écosystème .NET, permettant la réutilisation de bibliothèques et d'outils .NET, et offre un support de débogage robuste.

Qu'est-ce que l'ESRE ?

Elasticsearch Relevance Engine™ (ESRE ) est un ensemble d'outils permettant de créer des applications de recherche utilisant l'apprentissage automatique et l'intelligence artificielle au-dessus du puissant moteur de recherche Elasticsearch.

Pour en savoir plus sur l'ESRE, vous pouvez lire notre article de blog ici.

Configuration d'ELSER

Pour tirer parti des capacités ESRE d'Elastic, nous allons utiliser ELSER comme fournisseur de modèle.

Remarque : pour utiliser les modèles ELSER d'Elasticsearch, vous devez disposer d'une licence Platinum ou Enterprise, et d'un nœud de Machine Lerning (ML) dédié d'une taille minimale de 4 Go. Pour en savoir plus, cliquez ici.

Commencez par créer le point d'arrivée de l'inférence :

Si vous utilisez ELSER pour la première fois, il se peut que vous rencontriez une erreur 502 Bad Gateway lorsque le modèle se charge en arrière-plan. Vous pouvez vérifier l'état du modèle sur Machine Learning > Trained Models dans Kibana. Une fois qu'il est déployé, vous pouvez passer à l'étape suivante.

Indexation des données

Vous pouvez télécharger le jeu de données ici et importer les données à l'aide de Kibana. Pour ce faire, allez sur la page d'accueil et cliquez sur "Upload data". Ensuite, téléchargez le fichier et cliquez sur Import. Enfin, allez dans l'onglet Advanced et collez les mappings suivants :

Nous allons créer un index capable d'exécuter des requêtes sémantiques et en texte intégral. Le type de champ semantic_text se chargera du découpage et de l'intégration des données. Notez que nous indexons longDescription comme semantic_text, vous pouvez utiliser copy_to si vous voulez indexer un champ comme semantic_text et text`.

Construire l'application avec Blazor & Elasticsearch

Clé API

La première chose à faire est de créer une clé API pour authentifier nos requêtes à Elasticsearch. La clé API doit être en lecture seule et n'être autorisée qu'à interroger l'index books-blazor.

Vous verrez quelque chose comme ceci :

Enregistrez la valeur du champ de réponse encoded car vous en aurez besoin ultérieurement. Si vous travaillez sur Elastic Cloud, vous aurez également besoin de votre Cloud ID. (Vous pouvez le trouver ici).

Création du projet Blazor

Commencez par installer Blazor et créez un projet d'exemple en suivant les instructions officielles.

Une fois le projet créé, la structure des dossiers et des fichiers doit ressembler à ceci :

Le modèle d'application comprend Bootstrap v5.1.0 pour le stylisme.

Terminez la configuration du projet en installant le client Elasticsearch .NET :

Une fois cette étape terminée, votre page devrait ressembler à ceci :

Structure des dossiers

Nous allons maintenant organiser nos dossiers comme suit :

Les dossiers sont expliqués :

• Components/Pages/Search.razor : page principale contenant la barre de recherche, les résultats et les filtres.

• Composants/Pages/Search.razor.css : les styles de page.

• Components/Elasticsearch/SearchBar.razor : composant de barre de recherche.

• Components/Elasticsearch/Results.razor : composant de résultats.

• Components/Elasticsearch/Facet.razor : composant de filtres.

• Components/Svg/GlassIcon.razor : icône de recherche.

• Components/_Imports.razor : ce fichier importera tous les composants.

• Models/Book.cs : ce fichier contient le schéma du champ livre.

• Models/Response.cs : ce fichier stocke le schéma de la réponse, y compris les résultats de la recherche, les facettes et le nombre total de résultats.

• Services/ElasticsearchService.cs : Service Elasticsearch. Il gère la connexion et les requêtes à Elasticsearch.

Configuration initiale

Commençons par un peu de nettoyage.

Supprimer les fichiers :

• Composants/Pages/Compteur.razor

• Composants/Pages/Météo.razor

• Composants/Pages/Home.razor

• Components/Layout/NavMenu.razor

• Composants/Layout/NavMenu.razor.css

Vérifiez le fichier /Components/_Imports.razor. Vous devriez avoir les importations suivantes :

Intégrer Elastic dans le projet

Maintenant, importons les composants d'Elasticsearch :

Nous allons supprimer la barre latérale par défaut afin de disposer de plus d'espace pour notre application en la supprimant du fichier /Components/Layout/MainLayout.razor:

Entrons maintenant les informations d'identification Elasticsearch pour les secrets d'utilisateur:

Grâce à cette approche, .Net 8 stocke les données sensibles dans un emplacement distinct, en dehors du dossier du projet, et les rend accessibles à l'aide de l'interface IConfiguration. Ces variables seront disponibles pour tout projet .Net qui utilise les mêmes secrets d'utilisateur.

Ensuite, modifions le fichier Program.cs pour lire les secrets et monter le client Elasticsearch :

Tout d'abord, il faut importer les bibliothèques nécessaires :

• BlazorApp.Services : contient le service Elasticsearch.

• Elastic.Clients.Elasticsearch : importe la bibliothèque .Net 8 du client Elasticsearch.

• Elastic.Transport : importe la bibliothèque de transport Elasticsearch, ce qui nous permet d'utiliser la classe ApiKey pour authentifier nos requêtes.

Deuxièmement, insérez le code suivant avant la ligne var app = builder.Build():

Ce code va lire les informations d'identification Elasticsearch à partir des secrets d'utilisateur et créer une instance de client Elasticsearch.

Après l'initialisation du client ElasticSearch, ajoutez la ligne suivante pour enregistrer le service Elasticsearch :

L'étape suivante consistera à construire la logique de recherche dans le fichier /Services/ElasticsearchService.cs:

Tout d'abord, il faut importer les bibliothèques et les modèles nécessaires :

Ensuite, ajoutez la classe ElasticsearchService, le constructeur et les variables :

Configuration de la recherche

Construisons maintenant notre logique de recherche :

• BuildFilters construira les filtres pour la requête de recherche en utilisant les facettes sélectionnées par l'utilisateur.

• BuildHybridQuery construira une requête de recherche hybride qui combine la recherche plein texte et la recherche sémantique.

Ensuite, ajoutez la méthode de recherche :

• SearchBooksAsync: effectuera la recherche en utilisant la requête hybride et renverra les résultats en incluant les agrégations pour construire les facettes.

• FormatFacets: formatera la réponse des agrégations dans un dictionnaire.

• ConvertFacetDictionary: convertit le dictionnaire de facettes dans un format plus lisible.

L'étape suivante consiste à créer les modèles qui représenteront les données renvoyées dans le site hits de la requête Elasticsearch et qui seront imprimées en tant que résultats dans notre page de recherche.

Nous commençons par créer le fichier /Models/Book.cs et y ajouter ce qui suit :

Ensuite, il faut configurer la réponse Elastic dans le fichier /Models/Response.cs et ajouter ce qui suit :

Configuration d'une interface utilisateur de base

Ensuite, ajoutez le composant SearchBar. Dans le fichier /Components/Elasticsearch/SearchBar.razor, ajoutez ce qui suit :

Ce composant contient une barre de recherche et un bouton pour effectuer la recherche.

Blazor offre une grande flexibilité en permettant de générer du HTML dynamiquement en utilisant du code C# dans le même fichier.

Ensuite, dans le fichier /Components/Elasticsearch/Results.razor, nous construirons le composant de résultats qui affichera les résultats de la recherche :

Enfin, nous devons créer des facettes pour filtrer les résultats de la recherche.

Remarque : les facettes sont des filtres qui permettent aux utilisateurs d'affiner les résultats de leur recherche en fonction d'attributs ou de catégories spécifiques, tels que le type de produit, la fourchette de prix ou la marque. Ces filtres sont généralement présentés sous forme d'options cliquables, souvent sous forme de cases à cocher, afin d'aider les utilisateurs à affiner leur recherche et à trouver plus facilement des résultats pertinents. Dans le contexte d'Elasticsearch, les facettes sont créées à l'aide d' agrégations.

Nous configurons les facettes en plaçant le code suivant dans le fichier /Components/Elasticsearch/Facet.razor:

Ce composant lit une agrégation terms sur les champs author, categories et status, puis produit une liste de filtres à renvoyer à Elasticsearch.

Mettons tout cela bout à bout.

Dans le fichier /Components/Pages/Search.razor:

Notre page fonctionne !

Comme vous pouvez le constater, la page est fonctionnelle mais manque de style. Ajoutons quelques feuilles de style CSS pour le rendre plus organisé et plus réactif.

Commençons par remplacer les styles de présentation. Dans le fichier Components/Layout/MainLayout.razor.css:

Ajoutez les styles pour la page de recherche dans le fichier Components/Pages/Search.razor.css:

Notre page commence à s'améliorer :

Mettons-y les dernières touches :

Créez les fichiers suivants :

• Composants/Elasticsearch/Facet.razor.css

• Composants/Elasticsearch/Results.razor.css

Et ajoutez les styles pour Facet.razor.css:

Pour Results.razor.css:

Résultat final :

Pour lancer l'application, vous pouvez utiliser la commande suivante :

dotnet watch

Vous avez réussi ! Vous pouvez désormais rechercher des livres dans votre index Elasticsearch en utilisant la barre de recherche et filtrer les résultats par auteur, catégorie et statut.

Effectuer une recherche plein texte et sémantique

Par défaut, notre application effectuera une recherche hybride utilisant à la fois le texte intégral et la recherche sémantique. Vous pouvez modifier la logique de recherche en créant deux méthodes distinctes, l'une pour le texte intégral et l'autre pour la recherche sémantique, puis en sélectionnant une méthode pour élaborer la requête en fonction des données saisies par l'utilisateur.

Ajoutez les méthodes suivantes à la classe ElasticsearchService dans le fichier /Services/ElasticsearchService.cs:

Ces deux méthodes fonctionnent de manière similaire à la méthode BuildHybridQuery, mais elles n'effectuent qu'une recherche plein texte ou sémantique.

Vous pouvez modifier la méthode SearchBooksAsync pour utiliser la méthode de recherche sélectionnée :

Vous pouvez trouver le formulaire complet ici

Conclusion

Blazor est un framework efficace qui vous permet de construire des applications web en utilisant C#. Elasticsearch est un moteur de recherche puissant qui vous permet de créer des applications de recherche. En combinant les deux, vous pouvez facilement créer des applications de recherche robustes, en tirant parti de la puissance d'ESRE pour créer une expérience de recherche sémantique en peu de temps.

• Discutez avec les LLM en mettant en place un ChatLanguageModel et un ChatMemory

• Conserver l'historique du chat en mémoire pour se rappeler le contexte d'une discussion précédente avec un LLM

Cet article de blog traite de la manière de procéder :

• Création d'encastrements vectoriels à partir d'exemples de textes

• Stocker les embeddings vectoriels dans le magasin d'embedding d'Elasticsearch

• Recherche de vecteurs similaires

Créer des embeddings

Pour créer des embeddings, nous devons définir un EmbeddingModel à utiliser. Par exemple, nous pouvons utiliser le même modèle de mistral que celui utilisé dans le billet précédent. Il s'agissait de courir avec l'ollama :

Un modèle est capable de générer des vecteurs à partir d'un texte. Nous pouvons ici vérifier le nombre de dimensions générées par le modèle :

Pour générer des vecteurs à partir d'un texte, nous pouvons utiliser :

Si nous voulons également fournir des métadonnées pour nous permettre de filtrer des éléments tels que le texte, le prix, la date de sortie ou autre, nous pouvons utiliser Metadata.from(). Par exemple, nous ajoutons ici le nom du jeu comme champ de métadonnées :

Si vous souhaitez exécuter ce code, veuillez consulter la classe Step5EmbedddingsTest.java.

Ajouter Elasticsearch pour stocker nos vecteurs

LangChain4j fournit un magasin d'intégration en mémoire. Cette fonction est utile pour exécuter des tests simples :

Mais il est évident que cela ne pourrait pas fonctionner avec un ensemble de données beaucoup plus important car ce datastore stocke tout en mémoire et nous ne disposons pas d'une mémoire infinie sur nos serveurs. Ainsi, nous pourrions plutôt stocker nos enregistrements dans Elasticsearch, qui est par définition "élastique" et peut évoluer avec vos données. Pour cela, ajoutons Elasticsearch à notre projet :

Comme vous l'avez remarqué, nous avons également ajouté le module Elasticsearch TestContainers au projet, afin de pouvoir démarrer une instance Elasticsearch à partir de nos tests :

Pour utiliser Elasticsearch comme magasin d'intégration, il suffit de "" passer du datastore LangChain4j en mémoire au datastore Elasticsearch :

Cela permettra de stocker vos vecteurs dans Elasticsearch dans un index default. Vous pouvez également changer le nom de l'index en quelque chose de plus significatif :

Si vous souhaitez exécuter ce code, veuillez consulter la classe Step6ElasticsearchEmbedddingsTest.java.

Recherche de vecteurs similaires

Pour rechercher des vecteurs similaires, nous devons d'abord transformer notre question en une représentation vectorielle en utilisant le même modèle que celui utilisé précédemment. Nous l'avons déjà fait, il n'est donc pas difficile de le faire à nouveau. Notez que nous n'avons pas besoin des métadonnées dans ce cas :

Nous pouvons construire une requête de recherche avec cette représentation de notre question et demander au magasin d'intégration de trouver les premiers vecteurs :

Nous pouvons maintenant itérer sur les résultats et imprimer certaines informations, comme le nom du jeu qui provient des métadonnées et le score :

Comme on pouvait s'y attendre, cela nous donne "Out Run" comme premier résultat :

Si vous souhaitez exécuter ce code, consultez la classe Step7SearchForVectorsTest.java.

L'envers du décor

La configuration par défaut du magasin Elasticsearch Embedding utilise la requête kNN approximative en arrière-plan.

Mais cela peut être modifié en fournissant une autre configuration (ElasticsearchConfigurationScript) que celle par défaut (ElasticsearchConfigurationKnn) au magasin d'intégration :

L'implémentation de ElasticsearchConfigurationScript exécute en coulisse une requête script_score à l'aide d'une fonction cosineSimilarity.

En principe, lors d'un appel :

Il s'agit maintenant d'un appel :

Dans ce cas, le résultat ne change pas en termes d'ordre "" mais le score est simplement ajusté parce que l'appel cosineSimilarity n'utilise pas d'approximation mais calcule le cosinus pour chacun des vecteurs correspondants :

Si vous souhaitez exécuter ce code, consultez la classe Step7SearchForVectorsTest.java.

Conclusion

Nous avons vu comment vous pouvez facilement générer des embeddings à partir de votre texte et comment vous pouvez stocker et rechercher les voisins les plus proches dans Elasticsearch en utilisant deux approches différentes :

• Utilisation de la requête approximative et rapide knn avec l'option par défaut ElasticsearchConfigurationKnn

• Utilisation de la requête exacte mais plus lente script_score avec l'option ElasticsearchConfigurationScript

La prochaine étape consistera à créer une application RAG complète, sur la base de ce que nous avons appris ici.

Bienvenue dans la deuxième partie de notre article sur les techniques avancées de RAG ! Dans la première partie de cette série, nous avons mis en place, discuté et implémenté les composants de traitement des données du pipeline RAG avancé :

Dans cette partie, nous allons procéder à l'interrogation et au test de notre mise en œuvre. Allons droit au but !

Table des matières

• Recherche et récupération, génération de réponses

  • Enrichir les requêtes avec des synonymes

  • HyDE (Hypothetical Document Embedding)

  • Recherche hybride

• Expériences

  • Synthèse des résultats

  • Test 1 : Qui vérifie Elastic ?

    • AdvancedRAG

    • SimpleRAG

  • Test 2 : recettes totales en 2023

    • AdvancedRAG

    • SimpleRAG

  • Test 3 : De quel produit la croissance dépend-elle principalement ? Combien ?

    • AdvancedRAG

    • SimpleRAG

  • Test 4 : Décrire le régime d'avantages sociaux des salariés

    • AdvancedRAG

    • SimpleRAG

  • Test 5 : Quelles sont les entreprises acquises par Elastic ?

    • AdvancedRAG

    • SimpleRAG

• Conclusion

• Annexe

  • Prompts

    • Question du RAG - invite à répondre

    • Générateur de requêtes élastiques

    • Questions potentielles : invite à la création d'un générateur

    • Invite du générateur HyDE

  • Exemple de requête de recherche hybride

Recherche et récupération, génération de réponses

Posons notre première question, idéalement une information trouvée principalement dans le rapport annuel. Que diriez-vous de.. :

Appliquons maintenant quelques-unes de nos techniques pour améliorer la requête.

Enrichir les requêtes avec des synonymes

Tout d'abord, améliorons la diversité de la formulation de la requête et transformons-la en une forme qui peut être facilement traitée dans une requête Elasticsearch. Nous ferons appel à GPT-4o pour convertir la requête en une liste de clauses OR. Écrivons ce message :

Appliqué à notre requête, GPT-4o génère des synonymes de la requête de base et du vocabulaire connexe.

Dans la classe ESQueryMaker, j'ai défini une fonction pour diviser la requête :

Son rôle est de prendre cette chaîne de clauses OR et de les diviser en une liste de termes, ce qui nous permet d'effectuer une correspondance multiple sur les champs clés du document :

Finalement, nous avons abouti à cette requête :

Cela permet de couvrir beaucoup plus de bases que la requête initiale, réduisant ainsi le risque de manquer un résultat de recherche en raison de l'oubli d'un synonyme. Mais nous pouvons faire plus.

Haut de page

HyDE (Hypothetical Document Embedding)

Faisons à nouveau appel à GPT-4o, cette fois pour mettre en œuvre HyDE.

Le principe de base de HyDE est de générer un document hypothétique - le type de document qui contiendrait probablement la réponse à la requête initiale. Le caractère factuel ou l'exactitude du document n'est pas en cause. En gardant cela à l'esprit, rédigeons l'invite suivante :

La recherche vectorielle s'appuyant généralement sur la similarité vectorielle cosinusoïdale, HyDE part du principe que l'on peut obtenir de meilleurs résultats en faisant correspondre des documents à des documents plutôt que des requêtes à des documents.

Ce qui nous importe, c'est la structure, le flux et la terminologie. Ce n'est pas tant le cas pour les faits. Le GPT-4o produit un document HyDE comme celui-ci :

Il semble assez crédible, comme le candidat idéal pour les types de documents que nous aimerions indexer. Nous allons l'intégrer et l'utiliser pour la recherche hybride.

Haut de page

Recherche hybride

C'est le cœur de notre logique de recherche. Notre composante de recherche lexicale sera les chaînes de clauses OR générées. Notre composante vectorielle dense sera le document HyDE intégré (également appelé vecteur de recherche). Nous utilisons KNN pour identifier efficacement les documents candidats les plus proches de notre vecteur de recherche. Nous appelons notre composant de recherche lexicale Scoring with TF-IDF and BM25 par défaut. Enfin, les scores des vecteurs lexicaux et denses seront combinés en utilisant le ratio 30/70 recommandé par Wang et al.

Enfin, nous pouvons reconstituer une fonction RAG. Notre RAG, de la question à la réponse, suivra ce flux :

1. Convertir la requête en clauses OR.

2. Générer un document HyDE et l'intégrer.

3. Transmettre ces deux informations à la recherche hybride.

4. Récupérer les n premiers résultats, les inverser de façon à ce que le score le plus pertinent soit le "plus récent" dans la mémoire contextuelle du LLM (Reverse Packing) Reverse Packing Exemple : Requête : "Techniques d'optimisation des requêtes Elasticsearch" Documents récupérés (ordonnés par pertinence) : Ordre inversé pour le contexte LLM : En inversant l'ordre, l'information la plus pertinente (1) apparaît en dernier dans le contexte, recevant potentiellement plus d'attention de la part du LLM pendant la génération de la réponse.

   1. "Utilisez les requêtes bool pour combiner efficacement plusieurs critères de recherche."

   2. "Mettre en œuvre des stratégies de mise en cache pour améliorer les temps de réponse des requêtes."

   3. "Optimiser les mappages d'index pour accélérer les performances de recherche."

   4. "Optimiser les mappages d'index pour accélérer les performances de recherche."

   5. "Mettre en œuvre des stratégies de mise en cache pour améliorer les temps de réponse des requêtes."

   6. "Utilisez les requêtes bool pour combiner efficacement plusieurs critères de recherche."

5. Transmettre le contexte au LLM pour qu'il le génère.

Exécutons notre requête et obtenons notre réponse :

C'est une bonne chose. C'est exact.

Haut de page

Expériences

Il faut maintenant répondre à une question importante. Qu'avons-nous obtenu en investissant tant d'efforts et de complexité supplémentaire dans ces mises en œuvre ?

Faisons une petite comparaison. Le pipeline RAG que nous avons mis en œuvre par rapport à la recherche hybride de base, sans aucune des améliorations que nous avons apportées. Nous allons effectuer une petite série de tests et voir si nous constatons des différences substantielles. Nous appellerons le RAG que nous venons de mettre en œuvre AdvancedRAG et le pipeline de base SimpleRAG.

Synthèse des résultats

Ce tableau résume les résultats de cinq tests effectués sur les deux pipelines RAG. J'ai évalué la supériorité relative de chaque méthode sur la base du détail et de la qualité des réponses, mais il s'agit d'un jugement totalement subjectif. Les réponses réelles sont reproduites sous ce tableau pour votre considération. Ceci étant dit, jetons un coup d'œil sur leurs résultats !

SimpleRAG n'a pas pu répondre aux questions 1 & 5. AdvancedRAG a également répondu de manière beaucoup plus détaillée aux questions 2, 3 et 4. Sur la base de ces détails, j'ai jugé la qualité des réponses d'AdvancedRAG meilleure.

Test

Question

AdvancedRAG Performance

Performance de SimpleRAG

AdvancedRAG Latence

Latence de SimpleRAG

Gagnant

1

Qui audite Elastic ?

A correctement identifié PwC comme étant l'auditeur.

L'auditeur n'a pas été identifié.

11.6s

4.4s

AdvancedRAG

2

Quel a été le revenu total en 2023 ?

A fourni le chiffre d'affaires correct. Inclusion d'un contexte supplémentaire avec les recettes des années précédentes.

A fourni le chiffre d'affaires correct.

13.3s

2.8s

AdvancedRAG

3

De quel produit la croissance dépend-elle principalement ? Combien ?

A correctement identifié l'Elastic Cloud comme étant le facteur clé. Le contexte général des recettes a été inclus & de manière plus détaillée.

A correctement identifié l'Elastic Cloud comme étant le facteur clé.

14.1s

12.8s

AdvancedRAG

4

Décrire le régime d'avantages sociaux des employés

Description complète des régimes de retraite, des programmes de santé et des autres avantages. Incluait des montants de cotisation spécifiques pour différentes années.

A donné un bon aperçu des avantages, y compris la rémunération, les plans de retraite, l'environnement de travail et le programme Elastic Cares.

26.6s

11.6s

AdvancedRAG

5

Quelles sont les entreprises acquises par Elastic ?

A corrigé la liste des acquisitions récentes mentionnées dans le rapport (CmdWatch, Build Security, Optimyze). Il a fourni quelques dates d'acquisition et des prix d'achat.

Échec de la recherche d'informations pertinentes dans le contexte fourni.

11.9s

2.7s

AdvancedRAG

Test 1 : Qui vérifie Elastic ?

AdvancedRAG

SimpleRAG

Résumé: SimpleRAG n'a pas identifié PWC comme étant l'auditeur.

D'accord, c'est assez surprenant. Cela ressemble à un échec de recherche de la part de SimpleRAG. Aucun document relatif à l'audit n'a été retrouvé. Réduisons un peu la difficulté avec le test suivant.

Test 2 : recettes totales en 2023

AdvancedRAG

SimpleRAG

Résumé: les deux RAG ont obtenu la bonne réponse : 1 068 989 000 dollars de recettes totales en 2023.

Ils étaient tous les deux ici. Il semble qu'AdvancedRAG ait acquis un plus grand nombre de documents ? La réponse est certainement plus détaillée et intègre des informations des années précédentes. On peut s'y attendre compte tenu des améliorations que nous avons apportées, mais il est encore trop tôt pour se prononcer.

Augmentons la difficulté.

Test 3 : De quel produit la croissance dépend-elle principalement ? Combien ?

AdvancedRAG

SimpleRAG

Résumé: les deux groupes d'experts ont correctement identifié Elastic Cloud comme le principal moteur de croissance. Cependant, AdvancedRAG fournit plus de détails, en tenant compte des revenus d'abonnement et de la croissance de la clientèle, et mentionne explicitement d'autres offres d'Elastic.

Test 4 : Décrire le régime d'avantages sociaux des salariés

AdvancedRAG

SimpleRAG

Résumé: AdvancedRAG va beaucoup plus en profondeur et en détail, en mentionnant le plan 401K pour les employés basés aux États-Unis, ainsi qu'en définissant les plans de contribution en dehors des États-Unis. Il mentionne également les régimes de santé et de bien-être, mais ne mentionne pas le programme Elastic Cares, que SimpleRAG mentionne.

Test 5 : Quelles sont les entreprises acquises par Elastic ?

AdvancedRAG

SimpleRAG

Résumé: SimpleRAG ne récupère aucune information pertinente sur les acquisitions, ce qui entraîne un échec de la réponse. AdvancedRAG répertorie correctement CmdWatch, Build Security et Optimyze, qui sont les principales acquisitions mentionnées dans le rapport.

Haut de page

Conclusion

D'après nos tests, nos techniques avancées semblent augmenter l'étendue et la profondeur des informations présentées, ce qui pourrait améliorer la qualité des réponses RAG.

En outre, il est possible que la fiabilité soit améliorée, car les questions formulées de manière ambiguë, telles que Which companies did Elastic acquire? et Who audits Elastic, ont été correctement répondues par AdvancedRAG, mais pas par SimpleRAG.

Toutefois, il convient de garder à l'esprit que dans 3 cas sur 5, le pipeline RAG de base, intégrant la recherche hybride mais aucune autre technique, a réussi à produire des réponses qui capturaient la plupart des informations clés.

Il convient de noter qu'en raison de l'incorporation des LLM dans les phases de préparation des données et d'interrogation, la latence d'AdvancedRAG est généralement de 2 à 5 fois supérieure à celle de SimpleRAG. Il s'agit d'un coût important qui pourrait faire en sorte qu'AdvancedRAG ne convienne qu'aux situations où la qualité de la réponse est prioritaire par rapport à la latence.

Les coûts de latence importants peuvent être réduits en utilisant un LLM plus petit et moins cher comme Claude Haiku ou GPT-4o-mini à l'étape de préparation des données. Conservez les modèles avancés pour la génération de réponses.

Cela correspond aux conclusions de Wang et al. Comme le montrent leurs résultats, les améliorations apportées sont relativement progressives. En bref, un simple RAG de base vous permet d'obtenir un produit final décent, tout en étant moins cher et plus rapide. Pour moi, c'est une conclusion intéressante. Pour les cas d'utilisation où la vitesse et l'efficacité sont essentielles, SimpleRAG est un choix judicieux. Pour les cas d'utilisation où chaque goutte de performance doit être extraite, les techniques incorporées dans AdvancedRAG peuvent offrir une solution.

Haut de page

Annexe

Prompts

Question du RAG - invite à répondre

Invitation à faire en sorte que le LLM génère des réponses basées sur la requête et le contexte.

Générateur de requêtes élastiques

Invite à enrichir les requêtes avec des synonymes et à les convertir au format OR.

Questions potentielles : invite à la création d'un générateur

Invite à générer des questions potentielles, à enrichir les métadonnées des documents.

Invite du générateur HyDE

Invite à générer des documents hypothétiques à l'aide de HyDE

Exemple de requête de recherche hybride

L'article récent intitulé Searching for Best Practices in Retrieval-Augmented Generation évalue de manière empirique l'efficacité de diverses techniques d'amélioration des RAG, dans le but de converger vers un ensemble de meilleures pratiques pour les RAG.

Nous mettrons en œuvre quelques-unes des meilleures pratiques proposées, notamment celles qui visent à améliorer la qualité de la recherche (Sentence Chunking, HyDE, Reverse Packing).

Par souci de concision, nous omettons les techniques axées sur l'amélioration de l'efficacité (classification des requêtes et résumé).

Nous mettrons également en œuvre quelques techniques qui n'ont pas été abordées, mais que je trouve personnellement utiles et intéressantes (Metadata Inclusion, Composite Multi-Field Embeddings, Query Enrichment).

Enfin, nous effectuerons un petit test pour voir si la qualité de nos résultats de recherche et des réponses générées s'est améliorée par rapport à la base de référence. C'est parti !

Vue d'ensemble du RAG

RAG vise à améliorer les LLM en récupérant des informations dans des bases de connaissances externes afin d'enrichir les réponses générées. En fournissant des informations spécifiques au domaine, les LLM peuvent être rapidement adaptés à des cas d'utilisation qui sortent du cadre de leurs données de formation ; cela coûte beaucoup moins cher qu'un réglage fin et il est plus facile de les tenir à jour.

Les mesures visant à améliorer la qualité du RAG se concentrent généralement sur deux axes :

1. Améliorer la qualité et la clarté de la base de connaissances.

2. Améliorer la couverture et la spécificité des requêtes de recherche.

Ces deux mesures permettront d'améliorer les chances que le LLM ait accès à des faits et des informations pertinents, et qu'il soit donc moins susceptible d'halluciner ou de s'appuyer sur ses propres connaissances - qui peuvent être dépassées ou non pertinentes.

La diversité des méthodes est difficile à expliquer en quelques phrases. Pour plus de clarté, passons directement à la mise en œuvre.

Table des matières

• Aperçu

  • Table des matières

• Mise en place

• Acquisition, traitement et intégration de documents

  • Ingestion des données

  • Chunking au niveau de la phrase, par jetons

  • Inclusion et génération de métadonnées

    • Phrases clés extraites par TextRank

    • Questions potentielles générées par le GPT-4o

    • Entités extraites par Spacy

  • Enchâssement composite de champs multiples

    • Indexation vers Elastic

• Pause-catalogues

• Annexe

  • Définitions

Mise en place

Tout le code peut être trouvé dans le repo de Searchlabs.

Commençons par le commencement. Vous aurez besoin des éléments suivants :

1. Déploiement d'un nuage élastique

2. Une API LLM - Nous utilisons un déploiement GPT-4o sur Azure OpenAI dans ce carnet.

3. Python version 3.12.4 ou ultérieure

Nous allons exécuter tout le code du cahier main.ipynb.

Allez-y et clonez git le repo, naviguez vers supporting-blog-content/advanced-rag-techniques, puis exécutez les commandes suivantes :

Une fois que c'est fait, créez un fichier .env et remplissez les champs suivants (référencés dans l'exemple .env). Remerciements à mon co-auteur, Claude-3.5, pour ses commentaires utiles.

Ensuite, nous allons choisir le document à ingérer et le placer dans le dossier documents. Pour cet article, nous utiliserons le rapport annuel 2023 d'Elastic N.V. Il s'agit d'un document assez difficile et dense, parfait pour tester nos techniques RAG.

Maintenant que tout est prêt, passons à l'ingestion. Ouvrez main.ipynb et exécutez les deux premières cellules pour importer tous les paquets et initialiser tous les services.

Haut de page

Acquisition, traitement et intégration de documents

Ingestion des données

• Note personnelle : je suis stupéfait par la commodité de LlamaIndex. Avant les LLM et LlamaIndex, l'ingestion de documents de différents formats était un processus pénible de collecte de paquets ésotériques provenant d'un peu partout. Aujourd'hui, il se réduit à un seul appel de fonction. Sauvage.

La commande SimpleDirectoryReader chargera chaque document contenu dans les fichiers directory_path. et .pdf. Elle renvoie une liste d'objets document, que je convertis en dictionnaires Python parce que je trouve qu'ils sont plus faciles à manipuler.

Chaque dictionnaire contient le contenu clé du champ text. Il contient également des métadonnées utiles telles que le numéro de page, le nom du fichier, sa taille et son type.

Haut de page

Chunking au niveau de la phrase, par jetons

La première chose à faire est de réduire nos documents en morceaux d'une longueur standard (pour assurer la cohérence et la maniabilité). Les modèles d'intégration ont des limites de jetons uniques (taille d'entrée maximale qu'ils peuvent traiter). Les jetons sont les unités de base du texte que les modèles traitent. Pour éviter la perte d'informations (tronquage ou omission de contenu), nous devrions fournir un texte qui ne dépasse pas ces limites (en divisant les textes plus longs en segments plus petits).

Le découpage a un impact significatif sur les performances. Idéalement, chaque morceau devrait représenter un élément d'information autonome, capturant des informations contextuelles sur un seul sujet. Les méthodes de découpage comprennent le découpage au niveau des mots, où les documents sont divisés en fonction du nombre de mots, et le découpage sémantique qui utilise un LLM pour identifier les points de rupture logiques.

Le découpage au niveau des mots est bon marché, rapide et facile, mais il risque de diviser les phrases et donc de briser le contexte. Le découpage sémantique devient lent et coûteux, surtout s'il s'agit de documents tels que le rapport annuel Elastic de 116 pages.

Choisissons une approche intermédiaire. Le découpage en phrases est encore simple, mais il permet de préserver le contexte plus efficacement que le découpage en mots, tout en étant nettement moins coûteux et plus rapide. En outre, nous mettrons en œuvre une fenêtre coulissante pour capturer une partie du contexte environnant et atténuer l'impact du découpage des paragraphes.

La classe Chunker utilise le tokenizer du modèle d'intégration pour encoder et décoder le texte. Nous allons maintenant construire des blocs de 512 jetons chacun, avec un chevauchement de 20 jetons. Pour ce faire, nous divisons le texte en phrases, nous tokenisons ces phrases, puis nous ajoutons les phrases tokenisées à notre morceau actuel jusqu'à ce que nous ne puissions plus en ajouter sans dépasser notre limite de tokens.

Enfin, nous décodons les phrases pour les ramener au texte d'origine afin de les intégrer, en les stockant dans un champ appelé original_text. Les morceaux sont stockés dans un champ appelé chunk. Pour réduire le bruit (c'est-à-dire les documents inutiles), nous éliminons tous les documents dont la longueur est inférieure à 50 tokens.

Passons-le en revue nos documents :

Et vous obtenez des morceaux de texte qui ressemblent à ceci :

Haut de page

Inclusion et génération de métadonnées

Nous avons découpé nos documents en morceaux. Il est maintenant temps d'enrichir les données. Je souhaite générer ou extraire des métadonnées supplémentaires. Ces métadonnées supplémentaires peuvent être utilisées pour influencer et améliorer les performances de recherche.

Nous allons définir une classe DocumentEnricher, dont le rôle est de recevoir une liste de documents (dictionnaires Python) et une liste de fonctions du processeur. Ces fonctions s'exécutent sur la colonne original_text des documents et stockent leurs résultats dans de nouveaux champs.

Tout d'abord, nous extrayons les phrases clés à l'aide de TextRank. TextRank est un algorithme basé sur un graphe qui permet d'extraire des phrases et des expressions clés d'un texte en classant leur importance sur la base des relations entre les mots.

Ensuite, nous allons générer des questions potentielles à l'aide de GPT-4o.

Enfin, nous extrairons les entités à l'aide de Spacy.

Le code de chacun d'entre eux étant assez long et complexe, je m'abstiendrai de le reproduire ici. Si vous êtes intéressé, les fichiers sont indiqués dans les exemples de code ci-dessous.

Lançons l'enrichissement des données :

Et regardez les résultats :

Phrases clés extraites par TextRank

Ces phrases clés sont des substituts des thèmes centraux de la rubrique. Si une requête a trait à la cybersécurité, le score de ce morceau sera augmenté.

Questions potentielles générées par le GPT-4o

Ces questions potentielles peuvent correspondre directement aux requêtes des utilisateurs, ce qui permet d'améliorer le score. Nous demandons à GPT-4o de générer des questions auxquelles il est possible de répondre en utilisant les informations trouvées dans le morceau actuel.

Entités extraites par Spacy

Ces entités ont un objectif similaire à celui des phrases clés, mais elles capturent les noms des organisations et des individus, ce que l'extraction des phrases clés peut ne pas faire.

Haut de page

Enchâssement composite de champs multiples

Maintenant que nous avons enrichi nos documents avec des métadonnées supplémentaires, nous pouvons exploiter ces informations pour créer des encastrements plus robustes et tenant compte du contexte.

Faisons le point sur l'état actuel du processus. Nous avons quatre champs d'intérêt dans chaque document.

Chaque champ représente une perspective différente sur le contexte du document, mettant potentiellement en évidence un domaine clé sur lequel le LLM devrait se concentrer.

Il s'agit d'intégrer chacun de ces champs, puis de créer une somme pondérée des intégrations, appelée intégration composite.

Avec un peu de chance, cette intégration composite permettra au système de mieux tenir compte du contexte, tout en introduisant un autre hyperparamètre réglable pour contrôler le comportement de recherche.

Tout d'abord, intégrons chaque champ et mettons à jour chaque document en place, en utilisant notre modèle d'intégration défini localement et importé au début du bloc-notes main.ipynb.

Chaque fonction d'intégration renvoie le champ de l'intégration, qui est simplement le champ d'entrée original avec un postfixe _embedding.

Définissons maintenant les pondérations de notre encastrement composite :

Les pondérations vous permettent d'attribuer des priorités à chaque composant, en fonction de votre cas d'utilisation et de la qualité de vos données. Intuitivement, la taille de ces pondérations dépend de la valeur sémantique de chaque composant. Étant donné que le morceau de texte lui-même est de loin le plus riche, je lui attribue une pondération de 70%. Les entités étant les plus petites, puisqu'il s'agit simplement d'une liste de noms d'organisations ou de personnes, je leur attribue une pondération de 5%. Le réglage précis de ces valeurs doit être déterminé de manière empirique, au cas par cas.

Enfin, écrivons une fonction pour appliquer les pondérations et créer notre intégration composite. Pour gagner de la place, nous supprimerons également tous les composants intégrés.

Nous avons ainsi terminé le traitement des documents. Nous disposons à présent d'une liste d'objets documents qui se présente comme suit :

Indexation vers Elastic

Chargeons nos documents en vrac dans Elastic Search. À cette fin, j'ai défini il y a longtemps un ensemble de fonctions Elastic Helper dans elastic_helpers.py. Il s'agit d'un code très long, nous allons donc nous contenter d'examiner les appels de fonction.

es_bulk_indexer.bulk_upload_documents fonctionne avec n'importe quelle liste d'objets dictionnaires, en tirant parti des mappages dynamiques pratiques d'Elasticsearch.

Rendez-vous sur Kibana et vérifiez que tous les documents ont été indexés. Il devrait y en avoir 224. Pas mal pour un document aussi volumineux !

Haut de page

Pause-catalogues

Faisons une pause, l'article est un peu lourd, je sais. Jetez un coup d'œil à mon chat :

Adorable. Le chapeau a disparu et je soupçonne à moitié qu'elle l'a volé et caché quelque part :(

Félicitations pour avoir réussi à aller aussi loin :)

Rejoignez-moi dans la deuxième partie pour tester et évaluer notre pipeline RAG !

Annexe

Définitions

1. Découpage des phrases

• Technique de prétraitement utilisée dans les systèmes RAG pour diviser le texte en unités plus petites et significatives.

• Processus :

  1. Entrée : Grand bloc de texte (par exemple, document, paragraphe)

  2. Sortie : Segments de texte plus petits (généralement des phrases ou des petits groupes de phrases)

• Objet :

  • Création de segments de texte granulaires et spécifiques au contexte

  • Permet une indexation et une recherche plus précises

  • Améliore la pertinence des informations recherchées dans les systèmes RAG

• Caractéristiques :

  • Les segments sont sémantiquement significatifs

  • Peuvent être indexés et récupérés de manière indépendante

  • Souvent, le contexte est préservé afin de garantir la compréhensibilité autonome.

• Avantages :

  • Améliore la précision de la recherche

  • Permet une augmentation plus ciblée des pipelines RAG

2. HyDE (Hypothetical Document Embedding)

• Une technique qui utilise un LLM pour générer un document hypothétique pour l'expansion des requêtes dans les systèmes RAG.

• Processus :

  1. Requête d'entrée à un LLM

  2. LLM génère un document hypothétique répondant à la requête

  3. Intégrer le document généré

  4. Utiliser l'intégration pour la recherche vectorielle

• Différence essentielle :

  • RAG traditionnel : Correspondance entre la requête et les documents

  • HyDE : fait correspondre des documents à d'autres documents

• Objet :

  • Améliorer les performances de recherche, en particulier pour les requêtes complexes ou ambiguës

  • Saisir un contexte sémantique plus riche qu'une requête courte

• Avantages :

  • Exploite les connaissances du LLM pour élargir les requêtes

  • Peut potentiellement améliorer la pertinence des documents retrouvés

• Défis :

  • Nécessite une inférence LLM supplémentaire, ce qui augmente le temps de latence et le coût.

  • La performance dépend de la qualité du document hypothétique généré

3. Emballage inversé

• Technique utilisée dans les systèmes RAG pour réorganiser les résultats de la recherche avant de les transmettre au LLM.

• Processus :

  1. Le moteur de recherche (par exemple, Elasticsearch) renvoie les documents par ordre décroissant de pertinence.

  2. L'ordre est inversé, le document le plus pertinent étant placé en dernier.

• Objet :

  • Exploite le biais de récence des LLM, qui ont tendance à se concentrer sur les informations les plus récentes dans leur contexte.

  • Veille à ce que les informations les plus pertinentes soient "les plus récentes" dans la fenêtre contextuelle du LLM.

• Exemple : Ordre original : [Plus pertinent, Deuxième plus important, Troisième plus important, ...] Ordre inversé : [..., Troisième plus important, Deuxième plus important, Plus important]

4. Classification des requêtes

• Technique permettant d'optimiser l'efficacité du système RAG en déterminant si une requête nécessite un RAG ou si elle peut être traitée directement par le LLM.

• Processus :

  1. Développer un ensemble de données personnalisé spécifique au programme d'éducation et de formation tout au long de la vie utilisé

  2. Former un modèle de classification spécialisé

  3. Utiliser le modèle pour catégoriser les requêtes entrantes

• Objet :

  • Améliorer l'efficacité du système en évitant le traitement inutile des RAG

  • Diriger les demandes vers le mécanisme de réponse le plus approprié

• Exigences :

  • Ensemble de données et modèle spécifiques au LLM

  • Amélioration continue pour maintenir la précision

• Avantages :

  • Réduction de la charge de calcul pour les requêtes simples

  • Amélioration potentielle du temps de réponse pour les requêtes non RAG

5. Résumé

• Une technique pour condenser les documents récupérés dans les systèmes RAG.

• Processus :

  1. Récupérer les documents pertinents

  2. Générer des résumés concis de chaque document

  3. Utiliser des résumés plutôt que des documents complets dans le pipeline RAG

• Objet :

  • Améliorer la performance du RAG en se concentrant sur les informations essentielles

  • Réduire le bruit et les interférences provenant de contenus moins pertinents

• Avantages :

  • Amélioration potentielle de la pertinence des réponses au programme d'éducation et de formation tout au long de la vie

  • Permet d'inclure un plus grand nombre de documents dans les limites du contexte

• Défis :

  • Risque de perdre des détails importants dans le résumé

  • Frais de calcul supplémentaires pour la génération du résumé

6. Inclusion de métadonnées

• Une technique pour enrichir les documents avec des informations contextuelles supplémentaires.

• Types de métadonnées :

  • Mots clés

  • Titres

  • Dates

  • Coordonnées de l'auteur

  • Les commentaires

• Objet :

  • Augmenter les informations contextuelles disponibles pour le système RAG

  • Fournir aux gestionnaires du droit d'auteur une meilleure compréhension du contenu et de la pertinence des documents

• Avantages :

  • Amélioration potentielle de la précision de la recherche

  • Améliore la capacité du LLM à évaluer l'utilité des documents

• Mise en œuvre :

  • Peut être effectué lors du prétraitement des documents

  • Peut nécessiter des étapes supplémentaires d'extraction ou de génération de données

7. Intégrations composites multi-champs

• Une technique d'intégration avancée pour les systèmes RAG qui crée des intégrations distinctes pour les différents composants du document.

• Processus :

  1. Identifier les champs pertinents (par exemple, le titre, les phrases clés, le résumé, le contenu principal)

  2. Générer des embeddings distincts pour chaque champ

  3. Combiner ou stocker ces encastrements pour les utiliser lors de la recherche.

• Différence par rapport à l'approche standard :

  • Traditionnel : Intégration unique pour l'ensemble du document

  • Composite : Plusieurs encastrements pour différents aspects du document

• Objet :

  • Créer des représentations de documents plus nuancées et tenant compte du contexte

  • Saisir des informations provenant d'une plus grande variété de sources dans un document

• Avantages :

  • Amélioration potentielle des performances sur les requêtes ambiguës ou à multiples facettes

  • Permet une pondération plus souple des différents aspects du document dans la recherche.

• Défis :

  • Complexité accrue de l'intégration des processus de stockage et d'extraction

  • Peut nécessiter des algorithmes d'appariement plus sophistiqués

8. Enrichissement des requêtes

• Une technique qui consiste à ajouter des termes connexes à la requête initiale afin d'améliorer la couverture de la recherche.

• Processus :

  1. Analyser la requête originale

  2. Générer des synonymes et des phrases sémantiquement proches

  3. Complétez la requête avec ces termes supplémentaires

• Objet :

  • Augmenter l'éventail des correspondances potentielles dans le corpus de documents

  • Améliorer les performances de recherche pour les requêtes formulées dans un langage spécifique ou technique

• Avantages :

  • Possibilité de retrouver des documents pertinents qui ne correspondent pas exactement aux termes de la requête initiale.

  • Peut aider à surmonter l'inadéquation du vocabulaire entre les requêtes et les documents

• Défis :

  • Risque de dérive des requêtes en l'absence d'une mise en œuvre rigoureuse

  • Peut augmenter la charge de calcul dans le processus de recherche.

Haut de page

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.

C'est précisément là que les moteurs de recherche vectoriels brillent. Ils peuvent indexer le même texte de manière à ce qu'il puisse être recherché sur la base du sens qu'il représente et de ses relations avec d'autres concepts ayant un sens similaire ou apparenté.

Dans ce blog, nous aborderons brièvement la façon dont les vecteurs sont un concept mathématique idéal pour transmettre le sens d'un texte. Nous approfondirons ensuite les différentes techniques de similarité prises en charge par Elasticsearch lorsqu'il s'agit de rechercher des vecteurs voisins, c'est-à-dire de rechercher des vecteurs ayant une signification similaire, et la manière de les classer.

Que sont les plongements vectoriels ?

Cet article n'aborde pas en profondeur les subtilités des encastrements vectoriels. Si vous souhaitez approfondir ce sujet ou si vous avez besoin d'une introduction avant de poursuivre, nous vous recommandons de consulter le guide suivant.

En bref, les encastrements vectoriels sont obtenus par un processus d'apprentissage automatique (par ex. réseaux neuronaux d'apprentissage profond) qui transforme tout type de données d'entrée non structurées (texte brut, image, vidéo, son, etc.) en données numériques porteuses de sens et de relations. Les différents types de données non structurées nécessitent différents types de modèles d'apprentissage automatique qui ont été formés pour "comprendre" chaque type de données.

Chaque vecteur localise un élément spécifique des données en tant que point dans un espace multidimensionnel et cette localisation représente un ensemble de caractéristiques que le modèle utilise pour caractériser les données. Le nombre de dimensions dépend du modèle d'apprentissage automatique, mais il varie généralement de quelques centaines à quelques milliers. Par exemple, les modèles OpenAI Embeddings peuvent se vanter d'avoir 1536 dimensions, tandis que les modèles Cohere Embeddings peuvent avoir entre 382 et 4096 dimensions. Le type de champ Elasticsearch dense_vector prend en charge jusqu'à 4096 dimensions depuis la dernière version.

La véritable prouesse des encastrements vectoriels réside dans le fait que les points de données qui partagent une signification similaire sont proches les uns des autres dans l'espace. Un autre aspect intéressant est que l'intégration vectorielle permet également de saisir les relations entre les points de données.

Comment comparer les vecteurs ?

Sachant que les données non structurées sont découpées en tranches par des modèles d'apprentissage automatique sous forme de vecteurs qui capturent la similarité des données selon un grand nombre de dimensions, nous devons maintenant comprendre comment fonctionne la mise en correspondance de ces vecteurs. Il s'avère que la réponse est assez simple.

Les vecteurs intégrés qui sont proches les uns des autres représentent des éléments de données sémantiquement similaires. Ainsi, lorsque nous interrogeons une base de données vectorielle, l'entrée de recherche (image, texte, etc.) est d'abord transformée en un vecteur intégré à l'aide du même modèle d'apprentissage automatique que celui utilisé pour l'indexation de toutes les données non structurées, et l'objectif final est de trouver les vecteurs voisins les plus proches de ce vecteur d'interrogation. Par conséquent, tout ce que nous avons à faire est de trouver comment mesurer la distance "" ou la similarité "" entre le vecteur de la requête et tous les vecteurs existants indexés dans la base de données - c'est aussi simple que cela.

Distance, similarité et notation

Heureusement pour nous, la mesure de la distance ou de la similarité entre deux vecteurs est un problème facile à résoudre grâce à l'arithmétique vectorielle. Examinons donc les fonctions de distance et de similarité les plus populaires prises en charge par Elasticsearch. Attention, mathématiques en perspective !

Avant d'entrer dans le vif du sujet, jetons un coup d'œil rapide au système de notation. En réalité, Lucene n'autorise que les scores positifs. Toutes les fonctions de distance et de similarité que nous présenterons prochainement donnent une mesure de la proximité ou de la similarité de deux vecteurs, mais ces chiffres bruts sont rarement adaptés à une utilisation en tant que score car ils peuvent être négatifs. C'est pourquoi la note finale doit être dérivée de la distance ou de la valeur de similarité de manière à ce que la note soit positive et qu'une note plus élevée corresponde à un meilleur classement (c'est-à-dire à des vecteurs plus proches).

Distance L1

La distance L1, également appelée distance de Manhattan, de deux vecteurs et est mesurée en additionnant la différence absolue par paire de tous leurs éléments. Il est évident que plus la distance est faible, plus les deux vecteurs sont proches. La formule de la distance L1 (1) est assez simple, comme on peut le voir ci-dessous :

Visuellement, la distance L1 peut être illustrée comme le montre l'image ci-dessous (en rouge) :

Le calcul de la distance L1 des deux vecteurs suivants : \vec .

Important : il convient de noter que la fonction de distance L1 n'est prise en charge que pour la recherche vectorielle exacte (également appelée recherche par force brute) à l'aide de la script_score requête DSL, mais pas pour la knn recherche approximative kNN à l'aide de l' option de recherche ou de la knn requête DSL.

Distance L2

La distance L2, également appelée distance euclidienne, de deux vecteurs et est mesurée en additionnant d'abord le carré de la différence par paire de tous leurs éléments, puis en prenant la racine carrée du résultat. Il s'agit en fait du chemin le plus court entre deux points. Comme pour L1, plus la distance est faible, plus les deux vecteurs sont proches :

La distance L2 est indiquée en rouge dans l'image ci-dessous :

Réutilisons les deux mêmes vecteurs d'échantillonnage et que nous avons utilisés pour la distance , et nous pouvons maintenant calculer la distance comme \sqrt \approxeq 1,803.

En ce qui concerne la notation, plus la distance entre deux vecteurs est faible, plus ils sont proches (c'est-à-dire plus ils se ressemblent). Pour obtenir un score, nous devons donc inverser la mesure de la distance, de sorte que la distance la plus faible donne le score le plus élevé. La façon dont le score est calculé en utilisant la distance L2 est présentée dans la formule (3) ci-dessous :

En réutilisant les vecteurs d'échantillonnage de l'exemple précédent, leur score serait \frac 0,2352. Deux vecteurs très proches l'un de l'autre auront un score proche de 1, tandis que le score de deux vecteurs très éloignés l'un de l'autre tendra vers 0.

Pour conclure sur les fonctions de distance L1 et L2, une bonne analogie pour les comparer est de considérer A et B comme deux bâtiments à Manhattan, NYC. Un taxi se rendant de A à B devrait emprunter le chemin L1 (rues et avenues), tandis qu'un oiseau utiliserait probablement le chemin L2 (ligne droite).

Similitude du cosinus

Contrairement à L1 et L2, la similarité en cosinus ne mesure pas la distance entre deux vecteurs et , mais plutôt leur angle relatif, c'est-à-dire s'ils pointent tous deux à peu près dans la même direction. Plus la similarité est élevée, plus l'angle entre les deux vecteurs est faible et, par conséquent, plus "" ils sont proches et plus "" leur signification est similaire.

Pour illustrer cela, imaginons deux personnes dans la nature qui regardent dans des directions différentes. Dans la figure ci-dessous, la personne en bleu regarde dans la direction symbolisée par le vecteur et la personne en rouge dans la direction du vecteur . Plus ils orienteront leur regard dans la même direction (c'est-à-dire plus leurs vecteurs se rapprochent), plus leur champ de vision symbolisé par les zones bleues et rouges se chevauchera. Le degré de chevauchement de leur champ de vision correspond à leur similarité cosinusoïdale. Notez toutefois que la personne B regarde plus loin que la personne A (le vecteur est plus long). La personne B peut regarder une montagne au loin à l'horizon, tandis que la personne A peut regarder un arbre à proximité. Pour la similitude du cosinus, cela ne joue aucun rôle puisqu'il s'agit uniquement de l'angle.

Calculons maintenant la similitude en cosinus. La formule (4) est assez simple : le numérateur est le produit de points des deux vecteurs et le dénominateur est le produit de leur magnitude (c'est-à-dire de leur longueur) :

La similarité en cosinus entre et est représentée dans l'image ci-dessous comme une mesure de l'angle qui les sépare (en rouge) :

Faisons un petit détour pour expliquer ce que signifient concrètement ces valeurs de similitude cosinusoïdale. Comme le montre l'image ci-dessous représentant la fonction cosinus, les valeurs oscillent toujours dans l'intervalle

Rappelons que pour que deux vecteurs soient considérés comme similaires, leur angle doit être le plus aigu possible, idéalement proche de , ce qui revient à une similitude parfaite de En d'autres termes, lorsque les vecteurs sont...

1. ...proches l'un de l'autre, le cosinus de leur angle est proche de (c'est-à-dire proche de )

1. ...sans rapport, le cosinus de leur angle est proche de (c'est-à-dire proche de )

1. ...opposé, le cosinus de leur angle est proche de (c'est-à-dire proche de )

Maintenant que nous savons comment calculer la similitude en cosinus entre deux vecteurs et que nous avons une bonne idée de la manière d'interpréter la valeur obtenue, nous pouvons réutiliser les mêmes vecteurs échantillons et et calculer leur similitude en cosinus à l'aide de la formule (4) que nous avons vue précédemment.

Nous obtenons un cosinus similaire de , qui est plus proche de que de . Cela signifie que les deux vecteurs sont quelque peu similaires, c'est-à-dire qu'ils ne sont pas parfaitement similaires, mais qu'ils ne sont pas non plus complètement sans rapport, et qu'ils n'ont certainement pas de signification opposée.

Pour obtenir un score positif à partir de n'importe quelle valeur de similarité en cosinus, nous devons utiliser la formule suivante (5), qui transforme les valeurs de similarité en cosinus oscillant dans l'intervalle en scores dans l'intervalle

Le score pour les vecteurs échantillons et serait donc : \frac 0.8253.

Similitude du produit de points

L'un des inconvénients de la similitude en cosinus est qu'elle ne prend en compte que l'angle entre deux vecteurs et non leur magnitude, ce qui signifie que si deux vecteurs pointent à peu près dans la même direction mais que l'un est beaucoup plus long que l'autre, les deux seront tout de même considérés comme similaires. La similarité du produit de points, également appelée similarité scalaire ou produit intérieur, améliore cette situation en tenant compte à la fois de l'angle et de la magnitude des vecteurs, ce qui permet d'obtenir une mesure de similarité plus précise. Pour que la magnitude des vecteurs n'ait pas d'importance, la similitude du produit de points exige que les vecteurs soient d'abord normalisés, de sorte que nous ne comparons finalement que des vecteurs de longueur unitaire 1.

Essayons à nouveau d'illustrer cela avec les deux mêmes personnes que précédemment, mais cette fois-ci, nous les plaçons au milieu d'une pièce circulaire, de sorte que leur portée visuelle soit exactement la même (c.-à-d. le rayon de la pièce). De la même manière que pour la similarité cosinus, plus ils tournent dans la même direction (c'est-à-dire plus leurs vecteurs se rapprochent), plus leur champ de vision se chevauche. Cependant, contrairement à la similitude de cosinus, les deux vecteurs ont la même longueur et les deux aires ont la même surface, ce qui signifie que les deux personnes regardent exactement la même image située à la même distance. Le degré de chevauchement de ces deux zones correspond à la similitude de leur produit de point.

Avant d'introduire la formule de similarité du produit de points, voyons rapidement comment un vecteur peut être normalisé. C'est assez simple et peut être réalisé en deux étapes triviales :

1. calculer la magnitude du vecteur

2. diviser chaque composante par la valeur obtenue en 1.

Prenons par exemple le vecteur \vec Nous pouvons calculer sa magnitude \Vert \Vert comme nous l'avons vu précédemment lors de l'examen de la similitude du cosinus, c'est-à-dire \sqrt . Ensuite, en divisant chaque composante du vecteur par sa magnitude, on obtient le vecteur normalisé suivant :

En procédant de la même manière pour le deuxième vecteur \vec :

Afin de dériver la formule de similarité du produit en points, nous pouvons calculer la similarité en cosinus entre nos vecteurs normalisés et en utilisant la formule (4), comme indiqué ci-dessous :

Et comme la magnitude des deux vecteurs normalisés est maintenant de , la formule de similitude du produit par points (6) devient simplement... vous l'avez deviné, un produit par points des deux vecteurs normalisés :

Dans l'image ci-dessous, nous montrons les vecteurs normalisés et et nous pouvons illustrer la similarité de leur produit de point comme la projection d'un vecteur sur l'autre (en rouge).

En utilisant notre nouvelle formule (6), nous pouvons calculer la similarité du produit de points de nos deux vecteurs normalisés, ce qui, sans surprise, donne exactement la même valeur de similarité que celle du cosinus :

Lorsque l'on utilise la similarité du produit de points, le score est calculé différemment selon que les vecteurs contiennent des valeurs flottantes ou des valeurs d'octets. Dans le premier cas, le score est calculé de la même manière que pour la similarité en cosinus en utilisant la formule (7) ci-dessous :

Toutefois, lorsque le vecteur est composé de valeurs d'octets, la notation est calculée un peu différemment, comme le montre la formule (8) ci-dessous, où est le nombre de dimensions du vecteur :

En outre, pour obtenir des résultats précis, il faut que tous les vecteurs, y compris le vecteur d'interrogation, aient la même longueur, mais pas nécessairement la même longueur (1).

Similitude maximale du produit intérieur

Depuis la version 8.11, il existe une nouvelle fonction de similarité qui est moins contraignante que la similarité par produit de points, dans la mesure où les vecteurs n'ont pas besoin d'être normalisés. La raison principale est expliquée en détail dans l'article suivant, mais pour résumer très brièvement, certains ensembles de données ne sont pas très bien adaptés à la normalisation de leurs vecteurs (par exemple, Cohere embeddings) et cette normalisation peut entraîner des problèmes de pertinence.

La formule de calcul de la similarité maximale du produit intérieur est exactement la même que celle du produit de points (6). Ce qui change, c'est la manière dont le score est calculé en mettant à l'échelle la similarité maximale du produit intérieur à l'aide d'une fonction par morceaux dont la formule dépend du fait que la similarité est positive ou négative, comme le montre la formule (9) ci-dessous :

Cette fonction par morceaux met à l'échelle toutes les valeurs négatives du produit intérieur maximal dans l'intervalle et toutes les valeurs positives dans l'intervalle

En résumé

C'était un sacré parcours, mathématiquement parlant, mais voici quelques enseignements qui pourraient vous être utiles.

La fonction de similarité que vous pouvez utiliser dépend en fin de compte de la normalisation ou non de vos encastrements vectoriels. Si vos vecteurs sont déjà normalisés ou si votre ensemble de données ne dépend pas de la normalisation des vecteurs (c'est-à-dire que la pertinence n'en souffrira pas), vous pouvez aller de l'avant et normaliser vos vecteurs et utiliser la similarité par produit de points, car elle est beaucoup plus rapide à calculer que celle par cosinus, puisqu'il n'est pas nécessaire de calculer la longueur de chaque vecteur. Lorsque l'on compare des millions de vecteurs, ces calculs peuvent s'avérer très lourds.

Si vos vecteurs ne sont pas normalisés, vous avez deux possibilités :

1. utiliser la similarité en cosinus si la normalisation des vecteurs n'est pas possible

2. utiliser le nouveau produit intérieur maximal de similarité si vous souhaitez que la magnitude de vos vecteurs contribue à la notation parce qu'elle est porteuse de sens (par exemple, Cohere embeddings).

À ce stade, le calcul de la distance ou de la similarité entre les intégrations vectorielles et la manière de dériver leurs scores devraient vous sembler évidents. Nous espérons que cet article vous a été utile.

Il existe une distinction entre l'inspiration et la paraphrase. Il est possible de lire un contenu, de s'en inspirer, puis d'explorer l'idée avec ses propres mots, même si l'on arrive à une conclusion similaire.

Si le plagiat est un sujet de discussion depuis longtemps, l'accélération de la production et de la publication de contenus lui a donné toute sa pertinence et constitue un défi permanent.

Ce défi ne se limite pas aux livres, à la recherche universitaire ou aux documents judiciaires, pour lesquels des contrôles de plagiat sont fréquemment effectués. Elle peut également s'étendre aux journaux et même aux médias sociaux.

Avec l'abondance d'informations et l'accès facile à la publication, comment le plagiat peut-il être contrôlé de manière efficace et à grande échelle ?

Les universités, les organismes publics et les entreprises utilisent divers outils, mais si une simple recherche lexicale permet de détecter efficacement le plagiat direct, la principale difficulté réside dans l'identification du contenu paraphrasé.

Détection du plagiat avec l'IA générative

L'IA générative pose un nouveau défi. Le contenu généré par l'IA est-il considéré comme du plagiat lorsqu'il est copié ?

Les conditions d'utilisation de l'OpenAI, par exemple, précisent que l'OpenAI ne revendiquera pas de droits d'auteur sur le contenu généré par l'API pour les utilisateurs. Dans ce cas, les personnes utilisant leur IA générative peuvent utiliser le contenu généré comme elles le souhaitent, sans le citer.

Toutefois, l'acceptation de l'utilisation de l'IA générative pour améliorer l'efficacité reste un sujet de discussion.

Afin de contribuer à la détection du plagiat, OpenAI a développé un modèle de détection, mais a reconnu par la suite que sa précision n'était pas suffisamment élevée.

"Nous pensons que cette précision n'est pas suffisante pour une détection autonome et qu'elle doit être associée à des approches basées sur les métadonnées, au jugement humain et à l'éducation du public pour être plus efficace."

Le défi persiste ; cependant, grâce à la disponibilité d'outils supplémentaires, il existe désormais davantage d'options pour détecter le plagiat, même dans les cas de paraphrases et de contenu d'IA.

Détecter le plagiat avec Elasticsearch

C'est pourquoi, dans ce blog, nous explorons un autre cas d'utilisation des modèles de traitement du langage naturel (NLP) et de la recherche vectorielle, la détection du plagiat, au-delà de la recherche de métadonnées.

Nous le démontrons à l'aide d'exemples en Python, où nous utilisons un ensemble de données de SentenceTransformers contenant des articles liés au TAL. Nous vérifions que les résumés ne sont pas plagiés en effectuant une "similarité textuelle sémantique" en tenant compte de l'intégration des "résumés" générée à l'aide d'un modèle d'intégration de texte importé au préalable dans Elasticsearch. En outre, pour identifier le contenu généré par l'IA - le plagiat par l'IA, un modèle NLP développé par OpenAI a également été importé dans Elasticsearch.

L'image suivante illustre le flux de données :

Au cours du processus d 'ingestion avec un processeur d'inférence, le paragraphe "abstrait" est mis en correspondance avec un vecteur à 768 dimensions, le "vecteur_abstrait.valeur_prédite".

Cartographie :

La similarité entre les représentations vectorielles est mesurée à l'aide d'une métrique de similarité vectorielle, définie à l'aide du paramètre"similarité".

Cosinus est la métrique de similarité par défaut, calculée comme '(1 + cosinus(query, vector)) / 2'. À moins que vous ne deviez préserver les vecteurs originaux et que vous ne puissiez pas les normaliser à l'avance, la façon la plus efficace d'effectuer une similarité en cosinus est de normaliser tous les vecteurs à une longueur unitaire. Cela permet d'éviter d'effectuer des calculs supplémentaires sur la longueur du vecteur pendant la recherche, et d'utiliser plutôt 'dot_product'.

Dans ce même pipeline, un autre processeur d'inférence contenant le modèle de classification de texte détecte si le contenu est "vrai", probablement écrit par des humains, ou "faux", probablement écrit par une IA, en ajoutant la valeur "openai-detector.predicted_value" à chaque document.

Pipeline d'ingestion :

Au moment de la requête, le même modèle d'intégration de texte est également utilisé pour générer la représentation vectorielle de la requête "texte_modèle" dans un objet "query_vector_builder".

Une recherche par k-voisins les plus proches (kNN) permet de trouver les k vecteurs les plus proches du vecteur de la requête, mesurés par la métrique de similarité.

Le _score de chaque document est dérivé de la similarité, ce qui garantit qu'un score plus élevé correspond à un meilleur classement. Cela signifie que le document est plus similaire d'un point de vue sémantique. Par conséquent, nous imprimons trois possibilités : si le score > est de 0,9, nous considérons qu'il s'agit d'une "forte similarité" ; si < est de 0,7, il s'agit d'une "faible similarité" ; sinon, il s'agit d'une "similarité modérée". Vous avez la possibilité de définir différentes valeurs seuils pour déterminer quel niveau de _score est considéré comme du plagiat ou non, en fonction de votre cas d'utilisation.

En outre, une classification du texte est effectuée afin de vérifier si la requête contient des éléments générés par l'IA.

Requête :

Sortie :

Dans cet exemple, après avoir utilisé l'une des valeurs "abstract" de notre ensemble de données comme requête textuelle "model_text", le plagiat a été identifié. Le score de similarité est de 1,0, ce qui indique un niveau élevé de similarité - un plagiat direct. La requête et le document vectorisés n'ont pas été reconnus comme des contenus générés par l'IA, ce qui était attendu.

Requête :

Sortie :

En mettant à jour la requête "texte_modèle" avec un texte généré par l'IA qui transmet le même message tout en minimisant la répétition de mots similaires, la similarité détectée était toujours élevée, mais le score était de 0,9302529 au lieu de 1,0 - plagiat de paraphrase. On s'attendait également à ce que cette requête, générée par l'IA, soit détectée.

Enfin, si l'on considère la requête textuelle "model_text" comme un texte sur Elasticsearch, qui n'est pas un résumé de l'un de ces documents, la similarité détectée était de 0,68991005, ce qui indique une faible similarité selon les valeurs seuils considérées.

Requête :

Sortie :

Bien que le plagiat ait été correctement identifié dans la requête de texte générée par l'IA, ainsi que dans les cas de paraphrase et de contenu directement copié, la navigation dans le paysage de la détection du plagiat implique la reconnaissance de divers aspects.

Dans le contexte de la détection de contenu généré par l'IA, nous avons exploré un modèle qui apporte une contribution précieuse. Toutefois, il est essentiel de reconnaître les limites inhérentes à la détection autonome, ce qui nécessite l'incorporation d'autres méthodes pour améliorer la précision.

La variabilité introduite par le choix des modèles d'intégration de texte est un autre élément à prendre en considération. Différents modèles, formés avec des ensembles de données distincts, aboutissent à des niveaux de similarité variables, ce qui souligne l'importance des enchâssements de texte générés.

Enfin, dans ces exemples, nous avons utilisé le résumé du document. Cependant, la détection du plagiat porte souvent sur des documents volumineux, ce qui rend essentielle la prise en compte de la longueur du texte. Il est fréquent que le texte dépasse la limite de jetons d'un modèle, ce qui nécessite une segmentation en morceaux avant de construire des embeddings. Une approche pratique consiste à utiliser des structures imbriquées avec dense_vector.

Conclusion

Dans ce blog, nous avons abordé les défis liés à la détection du plagiat, en particulier dans les contenus paraphrasés et générés par l'IA, et comment la similarité textuelle sémantique et la classification des textes peuvent être utilisées à cette fin.

En combinant ces méthodes, nous avons fourni un exemple de détection du plagiat dans lequel nous avons réussi à identifier le contenu généré par l'IA, le plagiat direct et le plagiat paraphrastique.

L'objectif premier était d'établir un système de filtrage qui simplifie la détection, mais l'évaluation humaine reste essentielle pour la validation.

Si vous souhaitez en savoir plus sur la similarité textuelle sémantique et le NLP, nous vous encourageons à consulter les liens suivants :

• Qu'est-ce que la recherche sémantique ?

• Qu'est-ce que le traitement du langage naturel (NLP) ?

• Recherche lexicale et sémantique avec Elasticsearch

• Chunking Large Documents via Ingest pipelines plus nested vectors equals easy passage search (en anglais)

Produits requis

Tout comme dans la première partie de cette série, les conditions suivantes sont requises pour cet exemple :

1. Installation de Go version 1.21 ou ultérieure

2. Créez votre propre répertoire Go en utilisant la structure recommandée et la gestion des paquets décrite dans la documentation Go.

3. Création de votre propre cluster Elasticsearch, alimenté par un ensemble de pages sur les rongeurs, y compris notre sympathique Gopher, tiré de Wikipédia :

Connexion à Elasticsearch

Pour rappel, dans nos exemples, nous utiliserons l'API typée proposée par le client Go. Pour établir une connexion sécurisée pour n'importe quelle requête, il faut configurer le client en utilisant l'une ou l'autre des méthodes suivantes :

1. ID du nuage et clé API si vous utilisez Elastic Cloud

2. URL du cluster, nom d'utilisateur, mot de passe et certificat

La connexion à notre cluster situé sur Elastic Cloud ressemblerait à ceci :

La connexion client peut alors être utilisée pour la recherche, comme le montrent les sections suivantes.

Renforcement manuel pour la recherche hybride

Lors de la combinaison d'un ensemble d'algorithmes de recherche, l'approche traditionnelle consiste à configurer manuellement des constantes pour stimuler chaque type de requête. Plus précisément, un facteur est spécifié pour chaque requête, et l'ensemble des résultats combinés est comparé à l'ensemble prévu pour déterminer le rappel de la requête. Nous répétons ensuite l'opération pour plusieurs ensembles de facteurs et choisissons celui qui se rapproche le plus de l'état souhaité.

Par exemple, la combinaison d'une requête de recherche textuelle unique augmentée d'un facteur de 0.8 avec une requête knn avec un facteur inférieur de 0.2 peut être réalisée en spécifiant le champ Boost dans les deux types de requêtes, comme le montre l'exemple ci-dessous :

Le facteur spécifié dans l'option Boost pour chaque requête est ajouté au score du document. En augmentant le score de notre requête par un facteur plus important que celui de la requête knn, les résultats de la requête par mot-clé sont plus fortement pondérés.

La difficulté du renforcement manuel, en particulier si vous n'êtes pas un expert en recherche, réside dans le fait qu'il nécessite une mise au point pour déterminer les facteurs qui conduiront à l'ensemble de résultats souhaité. Il s'agit simplement d'essayer des valeurs aléatoires pour voir ce qui vous rapproche de l'ensemble des résultats souhaités.

Fusion de rangs réciproques dans la recherche hybride & Go client

Reciprocal Rank Fusion, ou RRF, a été publié en avant-première technique pour la recherche hybride dans Elasticsearch 8.9. Il vise à réduire la courbe d'apprentissage associée à la mise au point et à réduire le temps passé à expérimenter des facteurs pour optimiser l'ensemble des résultats.

Avec la méthode RRF, le score du document est recalculé en combinant les scores par l'algorithme ci-dessous :

L'avantage de l'utilisation de RRF est que nous pouvons utiliser les valeurs par défaut d'Elasticsearch. La constante de classement k est remplacée par défaut par 60. Afin de trouver un compromis entre la pertinence des documents renvoyés et les performances de la requête lors de la recherche sur de grands ensembles de données, la taille de l'ensemble de résultats pour chaque requête considérée est limitée à la valeur de window_size, qui est fixée par défaut à 100 comme indiqué dans la documentation.

k et windows_size peuvent également être configurés dans la configuration Rrf dans la méthode Rank dans le client Go, comme dans l'exemple ci-dessous :

Conclusion

Nous avons vu ici comment combiner la recherche vectorielle et la recherche par mot-clé dans Elasticsearch à l'aide du client Elasticsearch Go.

Consultez le repo GitHub pour tout le code de cette série. Si vous ne l'avez pas encore fait, consultez les parties 1 et 2 pour connaître tous les codes de cette série.

Bonne chasse aux marmottes !

Ressources

1. Guide Elasticsearch

2. Client Elasticsearch Go

3. Qu'est-ce que la recherche vectorielle ? | Elastique

4. Fusion de rangs réciproques

Tout comme les animaux, les langages de programmation et votre sympathique auteur, la recherche a connu une évolution des différentes pratiques qu'il peut être difficile de choisir pour votre propre cas d'utilisation de la recherche. Dans ce blog, nous présenterons une vue d'ensemble de la recherche vectorielle ainsi que des exemples de chaque approche en utilisant Elasticsearch et le client Elasticsearch Go. Ces exemples vous montreront comment trouver des spermophiles et déterminer ce qu'ils mangent en utilisant la recherche vectorielle dans Elasticsearch et Go.

Produits requis

Pour suivre cet exemple, assurez-vous que les conditions préalables suivantes sont remplies :

1. Installation de Go version 1.21 ou ultérieure

2. Création de votre propre repo Go avec l'outil

3. Création de votre propre cluster Elasticsearch, peuplé d'un ensemble de pages sur les rongeurs, y compris pour notre sympathique Gopher, à partir de Wikipedia :

Connexion à Elasticsearch

Dans nos exemples, nous utiliserons l'API typée proposée par le client Go. Pour établir une connexion sécurisée pour n'importe quelle requête, il faut configurer le client en utilisant l'une ou l'autre des méthodes suivantes :

1. ID du nuage et clé API si vous utilisez Elastic Cloud.

2. URL du cluster, nom d'utilisateur, mot de passe et certificat.

La connexion à notre cluster situé sur Elastic Cloud ressemblerait à ceci :

La connexion client peut ensuite être utilisée pour la recherche vectorielle, comme nous le verrons dans les sections suivantes.

Recherche vectorielle

La recherche vectorielle tente de résoudre ce problème en convertissant le problème de recherche en une comparaison mathématique utilisant des vecteurs. Le processus d'intégration de documents comporte une étape supplémentaire consistant à convertir le document à l'aide d'un modèle en une représentation vectorielle dense, ou simplement en un flux de nombres. L'avantage de cette approche est qu'elle permet de rechercher des documents non textuels, tels que des images et des fichiers audio, en les traduisant en un vecteur accompagné d'une requête.

En termes simples, la recherche vectorielle est un ensemble de calculs de distances vectorielles. Dans l'illustration ci-dessous, la représentation vectorielle de notre requête Go Gopherest comparée aux documents de l'espace vectoriel et les résultats les plus proches (désignés par la constante k) sont renvoyés :

En fonction de l'approche utilisée pour générer les enchâssements de vos documents, il y a deux façons différentes de savoir ce que mangent les spermophiles.

Approche 1 : Apportez votre propre modèle

Avec une licence Platinum, il est possible de générer les embeddings dans Elasticsearch en téléchargeant le modèle et en utilisant l'API d'inférence. La mise en place du modèle se fait en six étapes :

1. Sélectionnez un modèle PyTorch à télécharger à partir d'un référentiel de modèles. Pour cet exemple, nous utilisons les phrase-transformers/msmarco-MiniLM-L-12-v3 de Hugging Face pour générer les embeddings.

2. Charger le modèle dans Elastic à l'aide du client Eland Machine Learning pour Python en utilisant les informations d'identification de notre cluster Elasticsearch et le type de tâche text_embeddings. Si Eland n'est pas installé, vous pouvez exécuter l'étape d'importation à l'aide de Docker, comme indiqué ci-dessous :

1. Une fois téléchargé, testez rapidement le modèle sentence-transformers__msmarco-minilm-l-12-v3 avec un exemple de document pour vous assurer que les enchâssements sont générés comme prévu :

1. Créer un pipeline d'ingestion contenant un processeur d'inférence. Cela permettra de générer la représentation vectorielle à l'aide du modèle téléchargé :

1. Créer un nouvel index contenant le champ text_embedding.predicted_value de type dense_vector pour stocker les encastrements vectoriels générés pour chaque document :

1. Réindexer les documents à l'aide du pipeline d'acquisition nouvellement créé pour générer les enchâssements de texte en tant que champ supplémentaire text_embedding.predicted_value sur chaque document :

Nous pouvons maintenant utiliser l'option Knn sur la même API de recherche en utilisant le nouvel index vector-search-rodents, comme le montre l'exemple ci-dessous :

La conversion de l'objet de résultat JSON par unmarshalling se fait exactement de la même manière que dans l'exemple de la recherche par mot-clé. Les constantes K et NumCandidates nous permettent de configurer le nombre de documents voisins à renvoyer et le nombre de candidats à prendre en compte par tesson. Il est à noter que l'augmentation du nombre de candidats accroît la précision des résultats, mais entraîne une requête plus longue, car davantage de comparaisons sont effectuées.

Lorsque le code est exécuté à l'aide de la requête What do Gophers eat?, les résultats renvoyés sont similaires à ceux présentés ci-dessous, ce qui montre que l'article Gopher contient les informations demandées, contrairement à la recherche par mot-clé précédente :

Approche 2 : Inférence du visage étreint API

Une autre option consiste à générer ces mêmes embeddings en dehors d'Elasticsearch et à les intégrer dans votre document. Comme cette option n'utilise pas de nœud d'apprentissage automatique Elasticsearch, elle peut être réalisée sur le niveau gratuit.

Hugging Face expose une API d'inférence gratuite et limitée dans le temps qui, avec un compte et un jeton API, peut être utilisée pour générer manuellement les mêmes enchâssements à des fins d'expérimentation et de prototypage pour vous aider à démarrer. Il n'est pas recommandé pour une utilisation en production. Une approche similaire permet d'invoquer localement vos propres modèles pour générer des embeddings ou d'utiliser l'API payante.

Dans la fonction GetTextEmbeddingForQuery ci-dessous, nous utilisons l'API d'inférence avec notre chaîne de requête pour générer le vecteur renvoyé par une requête POST au point final :

Le vecteur résultant, de type []float32, est alors transmis en tant que QueryVector au lieu d'utiliser l'option QueryVectorBuilder pour exploiter le modèle précédemment téléchargé dans Elastic.

Notez que les options K et NumCandidates restent les mêmes quelles que soient les deux options et que les mêmes résultats sont générés car nous utilisons le même modèle pour générer les encastrements.

Conclusion

Nous avons vu ici comment effectuer une recherche vectorielle dans Elasticsearch en utilisant le client Elasticsearch Go. Consultez le repo GitHub pour tout le code de cette série. Suivez la partie 3 pour avoir une vue d'ensemble de la combinaison de la recherche vectorielle avec les capacités de recherche par mot-clé abordées dans la partie 1 de Go.

D'ici là, bonne chasse aux marmottes !

Ressources

1. Guide Elasticsearch

2. Client Elasticsearch Go

3. Qu'est-ce que la recherche vectorielle ? | Elastique

Compte tenu de cet objectif, dans cet article de blog, nous allons explorer différentes approches de la recherche d'informations à l'aide d'Elasticsearch, en nous concentrant plus particulièrement sur la recherche de texte : recherche lexicale et sémantique.

Produits requis

Pour ce faire, nous fournirons des exemples Python qui démontrent divers scénarios de recherche sur un ensemble de données généré pour simuler des informations sur des produits de commerce électronique.

Cet ensemble de données contient plus de 2 500 produits, chacun accompagné d'une description. Ces produits sont classés en 76 catégories de produits distinctes, chaque catégorie contenant un nombre variable de produits, comme indiqué ci-dessous :

Visualisation du treemap - les 22 premières valeurs de category.keyword (catégories de produits)

Pour l'installation, vous aurez besoin de

• Python 3.6 ou version ultérieure

• Le client Elastic Python

• Déploiement d'Elastic 8.8 ou d'une version ultérieure, avec un nœud d'apprentissage automatique de 8 Go de mémoire

• Le modèle Elastic Learned Sparse EncodeR qui est préchargé dans Elastic a été installé et démarré sur votre déploiement.

Nous utiliserons Elastic Cloud, une version d'essai gratuite est disponible.

Outre les requêtes de recherche présentées dans cet article de blog, un carnet Python vous guidera dans les processus suivants :

• Établir une connexion à notre déploiement Elastic en utilisant le client Python

• Charger un modèle d'intégration de texte dans le cluster Elasticsearch

• Créer un index avec des correspondances pour indexer les vecteurs de caractéristiques et les vecteurs denses.

• Créer un pipeline d'ingestion avec des processeurs d'inférence pour l'intégration et l'expansion du texte

Recherche lexicale - recherche éparse

La manière classique dont les documents sont classés en fonction de leur pertinence par Elasticsearch sur la base d'une requête textuelle utilise l'implémentation Lucene du modèle BM25, un modèle clairsemé pour la recherche lexicale. Cette méthode suit l'approche traditionnelle de la recherche de texte, en recherchant des correspondances de termes exacts.

Pour rendre cette recherche possible, Elasticsearch convertit les données des champs de texte en un format de recherche en effectuant une analyse de texte.

L'analyse de texte est effectuée par un analyseur, un ensemble de règles régissant le processus d'extraction des mots-clés pertinents pour la recherche. Un analyseur doit avoir exactement un tokenizer. Le tokenizer reçoit un flux de caractères et le décompose en tokens individuels (généralement des mots individuels), comme dans l'exemple ci-dessous :

Balisage des chaînes de caractères pour la recherche lexicale

Sortie

Dans cet exemple, nous utilisons l'analyseur par défaut, l'analyseur standard, qui fonctionne bien pour la plupart des cas d'utilisation car il fournit une tokenisation basée sur la grammaire anglaise. La tokenisation permet de faire correspondre des termes individuels, mais chaque token est toujours mis en correspondance de manière littérale.

Si vous souhaitez personnaliser votre expérience de recherche, vous pouvez choisir un autre analyseur intégré. Par exemple, en mettant à jour le code pour utiliser l'analyseur de mots v ides, il décomposera le texte en jetons à partir de tout caractère autre qu'une lettre, avec la possibilité de supprimer les mots vides.

Sortie

Lorsque les analyseurs intégrés ne répondent pas à vos besoins, vous pouvez créer un analyseur personnalisé, qui utilise la combinaison appropriée de zéro ou plusieurs filtres de caractères, un tokenizer et zéro ou plusieurs filtres de jetons.

Dans l'exemple ci-dessus, qui combine un tokenizer et des filtres de jetons, le texte sera mis en minuscules par le filtre de minuscules avant d'être traité par le filtre de jetons de synonymes.

Correspondance lexicale

BM25 mesurera la pertinence des documents par rapport à une requête de recherche donnée sur la base de la fréquence des termes et de leur importance.

Le code ci-dessous effectue une recherche de correspondance, recherchant jusqu'à deux documents en tenant compte des valeurs du champ "description" de l'index "ecommerce-search" et de la requête de recherche. "Meubles confortables pour un grand balcon".

L'affinement des critères pour qu'un document soit considéré comme correspondant à cette requête peut améliorer la précision. Cependant, les résultats plus spécifiques sont assortis d'une plus faible tolérance aux variations.

Sortie

En analysant le résultat, le résultat le plus pertinent est le produit "Barbie Dreamhouse", dans la catégorie "Toys", et sa description est très pertinente car elle inclut les termes "furniture", "large" et "balcony", c'est le seul produit avec 3 termes dans la description qui correspondent à la requête de recherche, le produit est également le seul avec le terme "balcony" dans la description.

Le deuxième produit le plus pertinent est un "Comfortable Rocking Chair" catégorisé en "Indoor Furniture" et sa description inclut les termes "comfortable" et "furniture". Seuls 3 produits dans l'ensemble de données correspondent à au moins 2 termes de cette requête de recherche, et ce produit est l'un d'entre eux.

"Comfortable" apparaît dans la description de 105 produits et "furniture" dans la description de 4 produits avec 4 catégories différentes : Jouets, Mobilier d'intérieur, Mobilier d'extérieur et 'Dog and Cat Supplies & Toys'.

Comme vous pouvez le constater, le produit le plus pertinent par rapport à la requête est un jouet et le deuxième produit le plus pertinent est un meuble d'intérieur. Si vous souhaitez obtenir des informations détaillées sur le calcul du score afin de savoir pourquoi ces documents correspondent, vous pouvez attribuer la valeur true au paramètre explain __query.

Bien que les deux résultats soient les plus pertinents, compte tenu à la fois du nombre de documents et de l'occurrence des termes dans cet ensemble de données, l'intention derrière la requête "Meubles confortables pour un grandbalcon" est de rechercher des meubles pour un grand balcon réel, à l'exclusion, entre autres, des jouets et des meubles d'intérieur.

La recherche lexicale est relativement simple et rapide, mais elle présente des limites car il n'est pas toujours possible de connaître tous les termes et synonymes possibles sans nécessairement connaître l'intention et les requêtes de l'utilisateur. Un phénomène courant dans l'utilisation du langage naturel est l'inadéquation du vocabulaire. % L es recherches montrent qu'en moyenne, dans80 % des cas, des personnes différentes (experts dans le même domaine) nomment la même chose différemment.

Ces limites nous incitent à rechercher d'autres modèles de notation qui intègrent des connaissances sémantiques. Les modèles basés sur des transformateurs, qui excellent dans le traitement de jetons d'entrée séquentiels tels que le langage naturel, capturent le sens sous-jacent de votre recherche en prenant en compte les représentations mathématiques des documents et des requêtes. Cela permet une représentation vectorielle dense et contextuelle du texte, qui alimente la recherche sémantique, un moyen raffiné de trouver du contenu pertinent.

Recherche sémantique - recherche dense

Dans ce contexte, après avoir converti vos données en valeurs vectorielles significatives, l'algorithme de recherche k-nearest neighbor (kNN ) est utilisé pour trouver les représentations vectorielles dans un ensemble de données qui sont les plus similaires à un vecteur d'interrogation. Elasticsearch prend en charge deux méthodes de recherche kNN, le kNN exact par force brute et le kNN approximatif, également connu sous le nom d'ANN.

Le kNN brutal garantit des résultats précis, mais ne s'adapte pas bien aux grands ensembles de données. Le kNN approximatif trouve efficacement les voisins les plus proches approximatifs en sacrifiant une partie de la précision pour améliorer les performances.

Grâce à la prise en charge par Lucene de la recherche kNN et des index vectoriels denses, Elasticsearch tire parti de l'algorithme Hierarchical Navigable Small World (HNSW), qui démontre d'excellentes performances de recherche sur une variété d'ensembles de données de référence. Une recherche kNN approximative peut être effectuée en Python à l'aide du code d'exemple ci-dessous.

Recherche sémantique avec kNN approximatif

Ce bloc de code utilise le kNN d'Elasticsearch pour renvoyer jusqu'à deux produits dont la description est similaire à la requête vectorisée (query_vector_build) de "Meubles confortables pour un grand balcon" en tenant compte de l'intégration du champ "description" dans l'ensemble de données sur les produits.

Les encastrements de produits ont été préalablement générés dans un pipeline d'ingestion avec un processeur d'inférence contenant le logiciel "all-mpnet-base-v2" pour déduire les données qui étaient ingérées dans le pipeline.

Ce modèle a été choisi sur la base de l'évaluation des modèles pré-entraînés à l'aide de "sentence_transformers.evaluation" où différentes classes sont utilisées pour évaluer un modèle pendant la formation. Le modèle "all-mpnet-base-v2" a démontré la meilleure performance moyenne selon le classement Sentence-Transformers et a également obtenu une position favorable sur le Massive Text Embedding Benchmark (MTEB) Leaderboard. Le modèle pré-entraîné microsoft/mpnet-base et affiné sur un ensemble de données de 1B paires de phrases, il cartographie les phrases dans un espace vectoriel dense de 768 dimensions.

Par ailleurs, il existe de nombreux autres modèles qui peuvent être utilisés, en particulier ceux qui sont adaptés aux données spécifiques à votre domaine.

Sortie

Le résultat peut varier en fonction du modèle choisi, des filtres et de la syntonisation approximative de kNN.

Les résultats de la recherche kNN se trouvent tous deux dans la catégorie "Outdoor Furniture", même si le mot "outdoor" n'a pas été explicitement mentionné dans la requête, ce qui souligne l'importance de la compréhension sémantique dans le contexte.

La recherche vectorielle dense offre plusieurs avantages :

• Permettre la recherche sémantique

• Évolutivité pour traiter de très grands ensembles de données

• Flexibilité pour traiter un large éventail de types de données

Cependant, la recherche vectorielle dense présente également ses propres difficultés :

• Choisir le bon modèle d'intégration pour votre cas d'utilisation

• Une fois le modèle choisi, il peut être nécessaire de l'affiner pour optimiser les performances sur un ensemble de données spécifiques au domaine, un processus qui nécessite la participation d'experts du domaine.

• En outre, l'indexation de vecteurs à haute dimension peut être très coûteuse sur le plan informatique

Recherche sémantique - récupération de données éparses apprises

Explorons une autre approche : la récupération éparse apprise, une autre façon d'effectuer une recherche sémantique.

En tant que modèle clairsemé, il utilise l'index inversé basé sur Lucene d'Elasticsearch, qui bénéficie de décennies d'optimisations. Toutefois, cette approche va au-delà du simple ajout de synonymes avec des fonctions de notation lexicale telles que BM25. Au lieu de cela, il incorpore des associations apprises en utilisant une connaissance plus approfondie de la langue pour optimiser la pertinence.

En élargissant les requêtes de recherche pour inclure des termes pertinents qui ne sont pas présents dans la requête originale, l' encodeur de vecteurs épar s Elastic Learned Sparse Encoder améliore les encastrements de vecteurs épars, comme vous pouvez le voir dans l'exemple ci-dessous.

Recherche de vecteurs épars à l'aide d'un codeur épars à apprentissage élastique

Sortie

Les résultats dans ce cas incluent la catégorie "Garden Furniture", qui offre des produits assez similaires à "Outdoor Furniture".

En analysant "ml.tokens", le champ "rank_features" contenant les tokens générés par Learned Sparse Retrieval, il devient évident que parmi les différents tokens générés, il y a des termes qui, bien que ne faisant pas partie de la requête de recherche, sont toujours pertinents dans leur signification, tels que "relax" (confortable), "sofa" (meuble) et "outdoor" (balcon).

L'image ci-dessous présente certains de ces termes en regard de la requête, avec et sans expansion des termes.

Comme nous l'avons observé, ce modèle permet une recherche contextuelle et contribue à atténuer le problème d'inadéquation du vocabulaire tout en fournissant des résultats plus faciles à interpréter. Il peut même être plus performant que les modèles à vecteurs denses lorsqu'aucun recyclage spécifique au domaine n'est appliqué.

Recherche hybride : résultats pertinents grâce à la combinaison de la recherche lexicale et sémantique

En matière de recherche, il n'existe pas de solution universelle. Chacune de ces méthodes de recherche a ses avantages, mais aussi ses inconvénients. En fonction du cas d'utilisation, la meilleure option peut changer. Souvent, les meilleurs résultats obtenus par les différentes méthodes de recherche peuvent être complémentaires. C'est pourquoi, pour améliorer la pertinence, nous chercherons à combiner les points forts de chaque méthode.

Il existe plusieurs façons de mettre en œuvre une recherche hybride, notamment la combinaison linéaire, en attribuant un poids à chaque score, et la fusion des rangs réciproques (RRF), où il n'est pas nécessaire de spécifier un poids.

Elasticsearch : le meilleur des deux mondes avec la recherche lexicale et sémantique

Dans ce code, nous avons effectué une recherche hybride avec deux requêtes ayant la valeur " Unetable à manger et des chaises confortables pour un grand balcon". Au lieu d'utiliser "furniture" comme terme de recherche, nous spécifions ce que nous recherchons, et les deux recherches prennent en compte les mêmes valeurs de champ, "description". Le classement est déterminé par une combinaison linéaire avec un poids égal pour les notes BM25 et ELSER.

Sortie

Dans le code ci-dessous, nous utiliserons la même valeur pour la requête, mais nous combinerons les scores de BM25 (paramètre de requête) et de kNN (paramètre knn) en utilisant la méthode de fusion par rang réciproque pour combiner et classer les documents.

La fonctionnalité RRF est en avant-première technique. La syntaxe sera probablement modifiée avant l'AG.

Sortie

Ici, nous pourrions également utiliser différents champs et valeurs ; certains de ces exemples sont disponibles dans le Python notebook.

Comme vous pouvez le constater, Elasticsearch vous offre le meilleur des deux mondes : la recherche lexicale traditionnelle et la recherche vectorielle, qu'elle soit éparse ou dense, pour atteindre votre objectif et trouver la meilleure réponse possible à votre question.

Si vous souhaitez continuer à vous familiariser avec les approches mentionnées ici, ces blogs peuvent vous être utiles :

• Améliorer la recherche d'informations dans la pile élastique : Recherche hybride

• Recherche vectorielle dans Elasticsearch : La raison d'être de la conception

• Comment obtenir le meilleur de la recherche lexicale et de la recherche alimentée par l'IA avec la base de données vectorielle d'Elastic ?

• Présentation d'Elastic Learned Sparse Encoder : Le modèle d'IA d'Elastic pour la recherche sémantique

• Améliorer la recherche d'information dans la pile Elastic : Présentation d'Elastic Learned Sparse Encoder, notre nouveau modèle de recherche d'information

Elasticsearch fournit une base de données vectorielle, ainsi que tous les outils dont vous avez besoin pour construire une recherche vectorielle :

• Base de données vectorielleElasticsearch

• Cas d'utilisation de la recherche vectorielle avec Elastic

Conclusion

Dans ce billet de blog, nous avons exploré différentes approches de la recherche d'informations à l'aide d'Elasticsearch, en nous concentrant plus particulièrement sur la recherche textuelle, lexicale et sémantique. Pour le démontrer, nous avons fourni des exemples Python illustrant différents scénarios de recherche à l'aide d'un ensemble de données contenant des informations sur des produits de commerce électronique.

Nous avons passé en revue la recherche lexicale classique avec BM25 et discuté de ses avantages et de ses défis, tels que l'inadéquation du vocabulaire. Nous avons souligné l'importance d'intégrer des connaissances sémantiques pour résoudre ce problème. En outre, nous avons abordé la recherche vectorielle dense, qui permet une recherche sémantique, et les défis associés à cette méthode de recherche, notamment le coût de calcul lors de l'indexation de vecteurs à haute dimension.

D'autre part, nous avons mentionné que les vecteurs épars se compriment exceptionnellement bien. Ainsi, nous avons discuté de l'encodeur Learned Sparse Encoder d'Elastic, qui étend les requêtes de recherche pour inclure des termes pertinents qui ne sont pas présents dans la requête originale.

Il n'existe pas de solution unique en matière de recherche. Chaque méthode de recherche a ses avantages et ses inconvénients. C'est pourquoi nous avons également abordé le concept de recherche hybride.

Comme vous pouvez le constater, avec Elasticsearch, vous pouvez bénéficier du meilleur des deux mondes : la recherche lexicale traditionnelle et la recherche vectorielle !

Prêt à commencer ? Consultez le cahier Python disponible et commencez un essai gratuit d'Elastic Cloud.

À mesure que la technologie progresse, les chatbots sont utilisés pour gérer des tâches plus complexes - et rapidement - tout en offrant une expérience personnalisée aux utilisateurs. Le traitement du langage naturel (NLP) permet aux chatbots de traiter le langage de l'utilisateur, d'identifier l'intention derrière son message et d'en extraire des informations pertinentes. Par exemple, la reconnaissance des entités nommées extrait les informations clés d'un texte en les classant dans un ensemble de catégories. L'analyse des sentiments identifie le ton émotionnel, et la réponse aux questions la "réponse" à une requête. L'objectif du NLP est de permettre aux algorithmes de traiter le langage humain et d'effectuer des tâches dont, historiquement, seul l'homme était capable, telles que la recherche de passages pertinents dans de grandes quantités de texte, le résumé de texte et la génération de nouveaux contenus originaux.

Ces capacités avancées de NLP reposent sur une technologie connue sous le nom de recherche vectorielle. Elastic prend en charge de manière native la recherche vectorielle, en effectuant des recherches exactes et approximatives par k-nearest neighbor (kNN), ainsi que le NLP, ce qui permet d'utiliser des modèles personnalisés ou tiers directement dans Elasticsearch.

Dans ce billet de blog, nous allons explorer comment la recherche vectorielle et le NLP fonctionnent pour améliorer les capacités des chatbots et montrer comment Elasticsearch facilite le processus. Commençons par un bref aperçu de la recherche vectorielle.

Recherche vectorielle

Bien que les humains puissent comprendre le sens et le contexte du langage écrit, les machines ne peuvent pas en faire autant. C'est là qu'interviennent les vecteurs. En convertissant le texte en représentations vectorielles (représentations numériques du sens du texte), les machines peuvent surmonter cette limitation. Par rapport à une recherche traditionnelle, au lieu de s'appuyer sur des mots-clés et une recherche lexicale basée sur les fréquences, les vecteurs permettent de traiter des données textuelles à l'aide d'opérations définies pour des valeurs numériques.

Cela permet à la recherche vectorielle de localiser des données qui partagent des concepts ou des contextes similaires en utilisant les distances dans l'espace d'intégration "" pour représenter la similarité à partir d'un vecteur de requête. Lorsque les données sont similaires, les vecteurs correspondants sont similaires.

La recherche vectorielle n'est pas seulement utilisée dans les applications NLP, mais aussi dans divers autres domaines où des données non structurées sont impliquées, y compris le traitement des images et des vidéos.

Dans un flux de chatbot, il peut y avoir plusieurs approches des requêtes des utilisateurs, et par conséquent, il y a différentes façons d'améliorer la recherche d'informations pour une meilleure expérience de l'utilisateur. Étant donné que chaque solution présente ses propres avantages et inconvénients, il est essentiel de tenir compte des données et des ressources disponibles, ainsi que du temps de formation (le cas échéant) et de la précision attendue. Dans la section suivante, nous aborderons ces aspects pour les modèles NLP de réponse aux questions.

Questions-réponses

Un modèle de réponse aux questions (QA) est un type de modèle NLP conçu pour répondre aux questions posées en langage naturel. Lorsque les utilisateurs ont des questions qui nécessitent de déduire des réponses à partir de plusieurs ressources, sans qu'une réponse cible préexistante soit disponible dans les documents, les modèles génératifs d'assurance qualité peuvent être utiles. Toutefois, ces modèles peuvent être coûteux en termes de calcul et nécessiter de grandes quantités de données pour la formation liée au domaine, ce qui peut les rendre moins pratiques dans certaines situations, même si cette méthode peut s'avérer particulièrement utile pour traiter les questions hors domaine.

En revanche, lorsque les utilisateurs posent des questions sur un sujet spécifique et que la réponse se trouve dans le document, des modèles d'assurance qualité extractifs peuvent être utilisés. Ces modèles extraient directement la réponse du document source, fournissant des résultats transparents et vérifiables, ce qui en fait une option plus pratique pour les entreprises ou les organisations qui souhaitent fournir un moyen simple et efficace de répondre aux questions.

L'exemple ci-dessous démontre l'utilisation d'un modèle d'assurance qualité extractif pré-entraîné, disponible sur Hugging Face et déployé dans Elasticsearch, pour extraire des réponses à partir d'un contexte donné :

Déployer les modèles formés.

Ajouter un modèle à un pipeline d'ingestion d'inférence.

Il existe plusieurs façons de traiter les requêtes des utilisateurs et d'extraire des informations, et l'utilisation de modèles linguistiques et de sources de données multiples peut constituer une solution efficace pour traiter des données non structurées. Pour illustrer cela, nous avons un exemple de traitement des données d'un chatbot employé pour répondre à des requêtes avec des réponses prenant en compte des données extraites de documents sélectionnés.

Traitement des données des chatbots : NLP et recherche vectorielle

Comme indiqué ci-dessus, le traitement des données pour notre chatbot peut être divisé en trois parties :

• Traitement vectoriel : Cette partie convertit les documents en représentations vectorielles.

• Traitement des données de l'utilisateur : Cette partie extrait les informations pertinentes de la requête de l'utilisateur et effectue une recherche sémantique et une recherche hybride.

• Optimisation : Cette partie comprend la surveillance et est cruciale pour garantir la fiabilité du chatbot, des performances optimales et une excellente expérience utilisateur.

Traitement vectoriel

Pour la partie traitement, la première étape consiste à déterminer les éléments constitutifs de chaque document, puis à convertir chaque élément en une représentation vectorielle ; ces représentations peuvent être créées pour un large éventail de formats de données.

Plusieurs méthodes peuvent être utilisées pour calculer les embeddings, notamment des modèles pré-entraînés et des bibliothèques.

Il est important de noter que l'efficacité de la recherche et de l'extraction sur ces représentations dépend des données existantes ainsi que de la qualité et de la pertinence de la méthode utilisée.

Au fur et à mesure que les vecteurs sont calculés, ils sont stockés dans Elasticsearch avec un type de champ dense_vector.

Traitement des entrées utilisateur des chatbots

Pour l'utilisateur, après avoir reçu une question, il est utile d'en extraire toutes les informations possibles avant de poursuivre. Cela permet de comprendre l'intention de l'utilisateur et, dans ce cas, nous utilisons un modèle de reconnaissance d'entités nommées (NER) pour nous aider dans cette tâche. Le NER est le processus d'identification et de classification des entités nommées dans des catégories d'entités prédéfinies.

Bien qu'il ne s'agisse pas d'une étape nécessaire, en utilisant des données structurées ou les résultats du modèle NLP ci-dessus ou d'un autre modèle NLP pour catégoriser la requête de l'utilisateur, nous pouvons restreindre la recherche kNN à l'aide d'un filtre. Cela permet d'améliorer les performances et la précision en réduisant la quantité de données à traiter.

Recherche sémantique et recherche hybride

Étant donné que l'invite provient des requêtes des utilisateurs et que le chatbot doit traiter le langage humain avec sa variabilité et son ambiguïté, la recherche sémantique est parfaitement adaptée. Dans Elasticsearch, vous pouvez effectuer une recherche sémantique en une seule étape en passant la chaîne de requête et l'ID du modèle d'intégration dans un objet query_vector_builder. Il vectorise la requête et effectue une recherche kNN pour extraire les k meilleures correspondances qui sont les plus proches de la requête :

Exemple de bout en bout : Comment déployer un modèle d'intégration de texte et l'utiliser pour la recherche sémantique. Elasticsearch utilise l'implémentation Lucene de l'Okapi BM25, un modèle peu dense , pour classer les requêtes de texte en fonction de leur pertinence, tandis que les modèles denses sont utilisés pour la recherche sémantique. Pour combiner les points forts des correspondances vectorielles et des correspondances obtenues à partir de la requête textuelle, il est possible d'effectuer une recherche hybride:

La combinaison de modèles épars et denses permet souvent d'obtenir les meilleurs résultats

Les modèles épars sont généralement plus performants pour les requêtes courtes et les terminologies spécifiques, tandis que les modèles denses s'appuient sur le contexte et les associations. Si vous souhaitez en savoir plus sur la façon dont ces méthodes se comparent et se complètent, nous comparons ici le BM25 à deux modèles denses qui ont été spécifiquement entraînés pour la recherche.

Le résultat le plus pertinent peut généralement être la première réponse donnée à l'utilisateur. Lescore est un nombre utilisé pour déterminer la pertinence du document retourné.

Optimisation des chatbots

Pour améliorer l'expérience utilisateur, les performances et la fiabilité de votre chatbot, en plus de l'application de la notation hybride, vous pouvez incorporer les approches suivantes : Analyse des sentiments : Pour connaître les commentaires et les réactions des utilisateurs au fur et à mesure que le dialogue se déroule, vous pouvez intégrer un modèle d'analyse des sentiments:

Capacités de GPT : Pour améliorer l'expérience globale, vous pouvez combiner la pertinence de recherche d'Elasticsearch avec les capacités de réponse aux questions de GPT d'OpenAI, en utilisant l'API Chat Completion pour renvoyer à l'utilisateur des réponses générées par le modèle, en considérant les k documents les plus importants comme contexte. Invite : "répondre à cette question <user_question> utiliser uniquement ce document <top_search_result>"

Observabilité : Garantir la performance de tout chatbot est crucial, et le suivi est un élément essentiel pour y parvenir. En plus des journaux qui enregistrent les interactions avec le chatbot, il est important de suivre le temps de réponse, la latence et d'autres paramètres pertinents pour le chatbot. Les outilsElastic Observability vous permettent de collecter et d'analyser ces informations.

Résumé

Cet article de blog explique ce que sont le NLP et la recherche vectorielle et présente un exemple de chatbot utilisé pour répondre aux requêtes des utilisateurs en tenant compte des données extraites de la représentation vectorielle des documents.

Comme nous l'avons démontré, en utilisant le NLP et la recherche vectorielle, les chatbots sont capables d'effectuer des tâches complexes qui vont au-delà des données structurées et ciblées. Il s'agit notamment de faire des recommandations et de répondre à des questions spécifiques sur des produits ou des entreprises en utilisant plusieurs sources et formats de données comme contexte, tout en offrant une expérience personnalisée à l'utilisateur.

Les cas d'utilisation vont de la fourniture d'un service à la clientèle, en aidant les clients à répondre à leurs demandes, à l'aide aux développeurs, en fournissant des conseils étape par étape, en suggérant des recommandations ou même en automatisant des tâches. En fonction de l'objectif et des données existantes, d'autres modèles et méthodes peuvent également être utilisés pour obtenir des résultats encore meilleurs et améliorer l'expérience globale de l'utilisateur.

Voici quelques liens sur le sujet qui peuvent être utiles :

1. Comment déployer le traitement du langage naturel (NLP) : Pour commencer

2. Aperçu de la recherche de similarité d'images dans Elasticsearch

3. ChatGPT et Elasticsearch : L'OpenAI rencontre les données privées

4. Monitoring des modèles API et GPT d'OpenAI avec OpenTelemetry et Elastic

5. 5 raisons pour lesquelles les responsables informatiques ont besoin de la recherche vectorielle pour améliorer les expériences de recherche

En intégrant le NLP et la recherche vectorielle native dans Elasticsearch, vous pouvez tirer parti de sa vitesse, de son évolutivité et de ses capacités de recherche pour créer des chatbots très efficaces et performants, capables de traiter de grandes quantités de données, qu'elles soient structurées ou non.

Prêt à commencer ? Commencez un essai gratuit d'Elastic Cloud.

Dans ce billet de blog, nous pouvons avoir utilisé ou nous pouvons faire référence à des outils d'IA générative de tiers, qui sont détenus et exploités par leurs propriétaires respectifs. Elastic n'a aucun contrôle sur les outils de tiers et nous ne sommes pas responsables de leur contenu, de leur fonctionnement ou de leur utilisation, ni de toute perte ou de tout dommage pouvant résulter de votre utilisation de ces outils. Faites preuve de prudence lorsque vous utilisez des outils d'IA avec des informations personnelles, sensibles ou confidentielles. Les données que vous soumettez peuvent être utilisées pour la formation à l'IA ou à d'autres fins. Il n'y a aucune garantie que les informations que vous fournissez resteront sécurisées ou confidentielles. Vous devez vous familiariser avec les pratiques en matière de protection de la vie privée et les conditions d'utilisation de tout outil d'IA générative avant de l'utiliser.

Elastic, Elasticsearch et les marques associées sont des marques commerciales, des logos ou des marques déposées d'Elasticsearch N.V. aux États-Unis et dans d'autres pays. Tous les autres noms de produits et d'entreprises sont des marques commerciales, des logos ou des marques déposées appartenant à leurs propriétaires respectifs.

Ce billet se concentre sur une technique particulière appelée recherche par similarité de texte. Dans ce type de recherche, l'utilisateur saisit une courte requête en texte libre et les documents sont classés en fonction de leur similarité avec la requête. La similarité des textes peut être utile dans divers cas d'utilisation :

• Réponse aux questions : À partir d'une collection de questions fréquemment posées, trouver des questions similaires à celle que l'utilisateur a saisie.

• Recherche d'articles : Dans une collection d'articles de recherche, renvoyer les articles dont le titre est étroitement lié à la requête de l'utilisateur.

• Recherche d'images : Dans un ensemble de données d'images légendées, trouver les images dont la légende est similaire à la description de l'utilisateur.

Une approche simple de la recherche par similarité consisterait à classer les documents en fonction du nombre de mots qu'ils partagent avec la requête. Mais un document peut être similaire à la requête même s'ils n'ont que très peu de mots en commun - une notion plus robuste de similarité prendrait également en compte son contenu syntaxique et sémantique.

La communauté du traitement du langage naturel (NLP) a mis au point une technique appelée "text embedding" qui code les mots et les phrases sous forme de vecteurs numériques. Ces représentations vectorielles sont conçues pour capturer le contenu linguistique du texte et peuvent être utilisées pour évaluer la similarité entre une requête et un document.

Ce billet explore comment les text embeddings et le type dense_vector d'Elasticsearch pourraient être utilisés pour soutenir la recherche de similarité. Nous donnerons d'abord un aperçu des techniques d'intégration, puis nous présenterons un prototype simple de recherche par similarité à l'aide d'Elasticsearch.

Qu'est-ce qu'un encartage de texte ?

Examinons de plus près les différents types d'enchâssement de texte et leur comparaison avec les méthodes de recherche traditionnelles.

Les enchâssements de mots

Un modèle d'intégration de mots représente un mot sous la forme d'un vecteur numérique dense. Ces vecteurs visent à capturer les propriétés sémantiques du mot - les mots dont les vecteurs sont proches les uns des autres devraient être similaires en termes de signification sémantique. Dans une bonne intégration, les directions dans l'espace vectoriel sont liées à différents aspects de la signification du mot. Par exemple, le vecteur pour "Canada" peut être proche de "France" dans une direction, et proche de "Toronto" dans une autre.

Les communautés de recherche et de traitement de texte s'intéressent depuis longtemps aux représentations vectorielles des mots. L'intégration de mots a connu un regain d'intérêt au cours des dernières années, lorsque de nombreuses tâches traditionnelles ont été revues à l'aide de réseaux neuronaux. Certains algorithmes d'intégration de mots ont été développés avec succès, notamment word2vec et GloVe. Ces approches utilisent de grandes collections de textes et examinent le contexte dans lequel chaque mot apparaît pour déterminer sa représentation vectorielle :

• Le modèle word2vec Skip-gram entraîne un réseau neuronal à prédire les mots du contexte autour d'un mot dans une phrase. Les poids internes du réseau donnent l'enchâssement des mots.

• Dans GloVe, la similarité des mots dépend de leur fréquence d'apparition avec d'autres mots du contexte. L'algorithme entraîne un modèle linéaire simple sur les comptes de cooccurrence des mots.

De nombreux groupes de recherche distribuent des modèles qui ont été pré-entraînés sur de grands corpus de textes tels que Wikipedia ou Common Crawl, ce qui permet de les télécharger et de les intégrer dans des tâches en aval. Bien que des versions pré-entraînées soient parfois utilisées directement, il peut être utile d'adapter le modèle à l'ensemble de données et à la tâche spécifiques. Cela se fait souvent en exécutant une étape de "réglage fin" sur le modèle pré-entraîné.

Les mots intégrés se sont révélés très robustes et efficaces, et il est désormais courant d'utiliser les mots intégrés à la place des mots individuels dans les tâches de TAL telles que la traduction automatique et la classification des sentiments.

Enchâssement de phrases

Plus récemment, les chercheurs ont commencé à s'intéresser aux techniques d'intégration qui représentent non seulement des mots, mais aussi des sections de texte plus longues. La plupart des approches actuelles sont basées sur des architectures de réseaux neuronaux complexes et intègrent parfois des données étiquetées lors de la formation afin de faciliter la capture des informations sémantiques.

Une fois entraînés, les modèles sont capables de prendre une phrase et de produire un vecteur pour chaque mot dans son contexte, ainsi qu'un vecteur pour la phrase entière. Comme pour l'intégration de mots, des versions pré-entraînées de nombreux modèles sont disponibles, ce qui permet aux utilisateurs d'éviter le processus d'entraînement coûteux. Alors que le processus d'apprentissage peut être très gourmand en ressources, l'utilisation du modèle est beaucoup plus légère - les modèles d'intégration de phrases sont généralement assez rapides pour être utilisés dans le cadre d'applications en temps réel.

Parmi les techniques courantes d'intégration de phrases, on peut citer InferSent, Universal Sentence Encoder, ELMo et BERT. L'amélioration de l'intégration des mots et des phrases est un domaine de recherche actif, et il est probable que d'autres modèles forts seront introduits.

Comparaison avec les méthodes de recherche traditionnelles

Dans la recherche d'informations traditionnelle, une façon courante de représenter un texte sous forme de vecteur numérique consiste à attribuer une dimension à chaque mot du vocabulaire. Le vecteur d'un texte est alors basé sur le nombre d'occurrences de chaque terme du vocabulaire. Cette façon de représenter un texte est souvent appelée "bag of words," parce que nous comptons simplement les occurrences de mots sans tenir compte de la structure de la phrase.

Les text embeddings diffèrent des représentations vectorielles traditionnelles sur certains points importants :

• Les vecteurs encodés sont denses et relativement peu dimensionnés, avec souvent entre 100 et 1 000 dimensions. En revanche, les vecteurs de sacs de mots sont peu nombreux et peuvent comporter plus de 50 000 dimensions. Les algorithmes d'intégration codent le texte dans un espace de dimension inférieure dans le cadre de la modélisation de sa signification sémantique. Idéalement, les mots et expressions synonymes se retrouvent avec une représentation similaire dans le nouvel espace vectoriel.

• Les encastrements de phrases peuvent prendre en compte l'ordre des mots lors de la détermination de la représentation vectorielle. Par exemple, la phrase "tune in" peut être représentée par un vecteur très différent de "in tune".

• Dans la pratique, les enchâssements de phrases ne s'appliquent pas toujours bien à de grandes parties de texte. Ils ne sont pas couramment utilisés pour représenter un texte plus long qu'un court paragraphe.

Utilisation des embeddings pour la recherche de similitudes

Supposons que nous disposions d'une vaste collection de questions et de réponses. Un utilisateur peut poser une question et nous voulons retrouver la question la plus similaire dans notre collection pour l'aider à trouver une réponse.

Nous pourrions utiliser des enchâssements de texte pour permettre de retrouver des questions similaires :

• Lors de l'indexation, chaque question est traitée par un modèle d'intégration de phrases afin de produire un vecteur numérique.

• Lorsqu'un utilisateur saisit une requête, celle-ci est traitée par le même modèle d'intégration de phrases pour produire un vecteur. Pour classer les réponses, nous calculons la similarité vectorielle entre chaque question et le vecteur de la requête. Pour comparer les vecteurs d'intégration, il est courant d'utiliser la similitude cosinus.

Ce dépôt donne un exemple simple de la façon dont cela pourrait être réalisé dans Elasticsearch. Le script principal indexe environ 20 000 questions de l'ensemble de données StackOverflow, puis permet à l'utilisateur de saisir des requêtes en texte libre dans l'ensemble de données.

Nous verrons bientôt chaque partie du script en détail, mais voyons d'abord quelques exemples de résultats. Dans de nombreux cas, la méthode est capable de capturer la similarité même lorsqu'il n'y a pas de fort chevauchement de mots entre la requête et la question indexée :

• "zippage des fichiers" retours "Compression / décompression des dossiers & Fichiers"

• "déterminer si quelque chose est une IP" renvoie "Comment déterminer si une chaîne de caractères est une IP ou un nom d'hôte ?"

• "traduire des octets en doubles" returns "Convertir des octets en nombres à virgule flottante en Python"

Détails de la mise en œuvre

Le script commence par télécharger et créer le modèle d'intégration dans TensorFlow. Nous avons choisi l'encodeur universel de phrases de Google, mais il est possible d'utiliser de nombreuses autres méthodes d'intégration. Le script utilise le modèle d'intégration tel quel, sans aucune formation ou mise au point supplémentaire.

Ensuite, nous créons l'index Elasticsearch, qui comprend des correspondances pour le titre de la question, les balises et le titre de la question encodé sous forme de vecteur :

Dans le mapping pour dense_vector, nous devons spécifier le nombre de dimensions que les vecteurs contiendront. Lors de l'indexation d'un champ title_vector, Elasticsearch vérifiera qu'il possède le même nombre de dimensions que celui spécifié dans le mapping.

Pour indexer les documents, nous faisons passer le titre de la question par le modèle d'intégration afin d'obtenir un tableau numérique. Ce tableau est ajouté au document dans le champ title_vector.

Lorsqu'un utilisateur saisit une requête, le texte passe d'abord par le même modèle d'intégration et est stocké dans le paramètre query_vector. Depuis la version 7.3, Elasticsearch propose une fonction cosineSimilarity dans son langage de script natif. Pour classer les questions en fonction de leur similitude avec la requête de l'utilisateur, nous utilisons donc une requête script_score :

Nous veillons à transmettre le vecteur de requête en tant que paramètre de script afin d'éviter de recompiler le script() à chaque nouvelle requête. Elasticsearch n'autorisant pas les scores négatifs, il est nécessaire d'en ajouter un à la similarité cosinus.

| Note : ce billet de blog utilisait à l'origine une syntaxe différente pour les fonctions vectorielles qui était disponible dans Elasticsearch 7.3, mais qui a été supprimée dans la version 7.6. |

Limites importantes

La requête script_score est conçue pour envelopper une requête restrictive et modifier les scores des documents qu'elle renvoie. Cependant, nous avons fourni une requête match_all, ce qui signifie que le script sera exécuté sur tous les documents de l'index. Il s'agit d'une limitation actuelle de la similarité vectorielle dans Elasticsearch - les vecteurs peuvent être utilisés pour évaluer les documents, mais pas dans l'étape de recherche initiale. L'aide à la recherche basée sur la similarité des vecteurs est un domaine important des travaux en cours.

Pour éviter de parcourir tous les documents et maintenir des performances élevées, la requête match_all peut être remplacée par une requête plus sélective. La bonne requête à utiliser pour la recherche dépend probablement du cas d'utilisation spécifique.

Bien que nous ayons vu quelques exemples encourageants ci-dessus, il est important de noter que les résultats peuvent également être bruyants et non intuitifs. Par exemple, "zippant les fichiers" attribue également des scores élevés à "Partiel .csproj Fichiers" et "Comment éviter .pyc fichiers ?". Et lorsque la méthode renvoie des résultats surprenants, il n'est pas toujours évident de déboguer le problème - la signification de chaque composante du vecteur est souvent opaque et ne correspond pas à un concept interprétable. Avec les techniques de notation traditionnelles basées sur le chevauchement des mots, il est souvent plus facile de répondre à la question suivante : "pourquoi ce document est-il bien classé ?"

Comme indiqué précédemment, ce prototype est conçu comme un exemple de la manière dont les modèles d'intégration peuvent être utilisés avec les champs vectoriels, et non comme une solution prête à l'emploi. Lors de l'élaboration d'une nouvelle stratégie de recherche, il est essentiel de tester les performances de l'approche sur vos propres données, en veillant à les comparer à une base de référence solide telle qu'une requête de correspondance. Il peut s'avérer nécessaire d'apporter des modifications majeures à la stratégie avant qu'elle n'obtienne des résultats solides, notamment en affinant le modèle d'intégration pour l'ensemble de données cible ou en essayant différentes manières d'intégrer les intégrations, telles que l'expansion des requêtes au niveau des mots.

Conclusions

Les techniques d'intégration constituent un moyen puissant de capturer le contenu linguistique d'un texte. En indexant les enchâssements et en attribuant des notes basées sur la distance vectorielle, nous pouvons comparer les documents en utilisant une notion de similarité qui va au-delà de leur chevauchement au niveau des mots.

Nous sommes impatients d'introduire davantage de fonctionnalités basées sur le type de champ vectoriel. L'utilisation des vecteurs pour la recherche est un domaine nuancé et en développement - comme toujours, nous serions ravis de connaître vos cas d'utilisation et vos expériences sur Github et les forums de discussion!