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.

C'est précisément pour cela que nous avons créé des tableaux de bord en lecture seule. C'est le niveau de contrôle que vous attendiez. Partagez vos tableaux de bord en toute confiance, sans craindre que la prochaine personne qui dispose d'un accès en modification ne les modifie ou ne les altère.

Remarque : les autorisations en lecture seule sont disponibles dans Elastic Cloud Serverless et à partir de la version 9.3 pour Elastic Cloud Hosted et Elastic autogéré.

Quand l'option "tout le monde peut modifier" pose problème

Dans Kibana, le partage est généralement synonyme d'autorisations au niveau de l'espace. Si quelqu'un peut créer des tableaux de bord dans un espace, il peut également modifier ou supprimer ceux des autres. C'est génial pour collaborer jusqu'à ce que ce ne soit plus le cas. Une modification accidentelle peut entraîner de mauvaises décisions, une perte de confiance et beaucoup de nettoyage.

Nous avons entendu les solutions de contournement : "On ajoute "lecture seule" dans le nom du tableau de bord et on espère que les gens le remarqueront." Ou encore : "On les étiquette et on croise les doigts." L'espoir n'est pas un modèle d'autorisations. Il vous fallait un moyen efficace de verrouiller un tableau de bord sans en interdire l'accès à tous.

Ce qui ne va pas

Deb et Kevin ont tous deux un accès en modification au tableau de bord de surveillance des logs dans l'espace Opérations. Kevin apporte quelques modifications aux graphiques. À son retour, Deb constate que les chiffres ne correspondent plus à ce qu'elle a présenté. Elle doit alors rechercher ce qui a été modifié (souvent de mémoire), le corriger et se demander combien de rapports erronés ont été diffusés.

Tableaux de bord en lecture seule : droits d'accès et contrôle adaptés

Les tableaux de bord en lecture seule résolvent ce problème en vous permettant de contrôler si d'autres utilisateurs peuvent les modifier. Lorsque vous partagez un tableau de bord, vous avez le choix entre : modifier (par défaut, comme aujourd'hui) ou afficher. En mode affichage, vous seul (et les administrateurs de Kibana) pouvez le modifier ou le supprimer. Tous les autres peuvent l'ouvrir, l'utiliser et lui faire confiance, mais ils ne peuvent pas le modifier.

Ce que vous obtenez

• Intégrité du tableau de bord : en mode affichage, les autres utilisateurs disposant d'un accès en modification dans l'espace ne peuvent ni modifier ni supprimer le tableau de bord. S'ils tentent de le faire, un message leur indique qu'il est verrouillé. Vos graphiques et votre logique restent intacts.

• Vous gardez le contrôle : vous êtes le propriétaire. Vous pouvez toujours modifier, affiner et mettre à jour. Le partage en lecture seule ne vous empêche pas d'accéder au contenu ; il verrouille la version visible par tous les autres utilisateurs.

• Cycle de vie flexible : vous pouvez à tout moment repasser un tableau de bord en mode "modifiable". Et les administrateurs Kibana peuvent toujours gérer tous les tableaux de bord (par exemple, si le propriétaire quitte l'entreprise). Il n'y a pas d'impasse.

Vous pouvez partager largement des tableaux de bord finalisés et stratégiques, en ayant l'assurance qu'ils resteront cohérents. Cette fonctionnalité est disponible dans tous les niveaux et offres Elastic, y compris Serverless.

Qui peut faire quoi ?

Référence rapide par rôle :

• Propriétaire du tableau de bord : vous l'avez créé ; vous disposez d'un accès complet en modification.

• Administrateur Kibana : peut gérer tous les tableaux de bord.

• Utilisateur avec droit de modification dans l'espace : peut créer et modifier ses tableaux de bord ; ne peut ni modifier ni supprimer les tableaux de bord en mode lecture seule.

• Utilisateur avec droit d'affichage dans l'espace : peut uniquement consulter (et afficher) les tableaux de bord.

Action

Propriétaire du tableau de bord

Administrateur Kibana

Utilisateur avec modification de l'espace

Utilisateur avec droit d'affichage dans l'espace

Afficher et consulter les tableaux de bord

✔

✔

✔

✔

Créer de nouveaux tableaux de bord

✔

✔

✔

✘

Modifier/supprimer les tableaux de bord modifiables

✔

✔

✔

✘

Modifier ou supprimer les tableaux de bord en lecture seule

✔

✔

✘

✘

Comment activer le mode lecture seule

Vous pouvez activer le mode lecture seule lors de l'enregistrement d'un nouveau tableau de bord ou ultérieurement depuis le menu Partager.

Lors de l’enregistrement d’un nouveau tableau de bord

• Créez votre tableau de bord, puis cliquez sur Enregistrer.

• Dans la fenêtre modale "Enregistrer en tant que nouveau tableau de bord", recherchez Autorisations.

• Passez de Peut modifier à Peut afficher.

• Cliquez sur Save (Enregistrer). Et le tour est joué ! C'est en lecture seule pour tous les autres utilisateurs.

Pour un tableau de bord que vous possédez déjà

• Ouvrez le tableau de bord.

• Ouvrez le menu Partager le tableau de bord.

• Dans la fenêtre de partage, recherchez Autorisations et sélectionnez Affichage uniquement. La modification s'applique immédiatement ; les autres utilisateurs dans l'espace ne peuvent plus le modifier ni le supprimer.

• Vous pouvez survoler l'action Partager avec la souris pour voir le type d'autorisations dont dispose un tableau de bord donné.

Voir quels tableaux de bord sont verrouillés

Dans la liste principale des tableaux de bord, les tableaux de bord que vous ne pouvez ni modifier ni supprimer sont signalés par une case à cocher désactivée. Cela permet de repérer facilement les tableaux de bord en lecture seule.

Sur le tableau de bord, vous constaterez également que l'action Modifier est désactivée et qu'une info-bulle apparaît, expliquant que le tableau de bord a été configuré en lecture seule.

Faites l'essai

Les tableaux de bord en lecture seule sont désormais disponibles. Créez un tableau de bord, passez-le en mode Affichage uniquement et partagez-le. Votre équipe dispose ainsi d'une source unique d'information fiable, et vous avez l'esprit tranquille. Fini les mentions "Ne pas modifier" dans le titre.

Nous aimerions savoir comment vous utilisez les tableaux de bord en lecture seule. Partagez vos commentaires sur notre forum communautaire.

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).

Lors de l'optimisation d'Elasticsearch pour des charges de travail à forte simultanéité, l'approche standard consiste à maximiser la RAM afin de conserver l'ensemble des documents de travail en mémoire et d'obtenir une faible latence de recherche. Par conséquent, best_compression est rarement l'option choisie pour les charges de travail de recherche, car il est principalement perçu comme une mesure d'économie d'espace pour les cas d'utilisation d'Elastic Observability et d'Elastic Security où l'efficacité du stockage est prioritaire.

Dans ce blog, nous démontrons que lorsque la taille de l'ensemble de données dépasse nettement le cache de page du système d'exploitation, best_compression améliore les performances de recherche et l'efficacité des ressources en réduisant le goulot d'étranglement des E/S.

La configuration

Notre cas d'utilisation est une application de recherche à forte simultanéité qui s'exécute sur des instances Elastic Cloud optimisées pour le processeur.

• Volume de données : ~500 millions de documents

• Infrastructure : 6 instances Elastic Cloud (Elasticsearch Service) (chaque instance : 1,76 To de stockage | 60 Go de RAM | 31,9 vCPU)

• Rapport mémoire/stockage : la RAM peut recevoir environ 5 % du volume total de données

Les symptômes : latence élevée

Nous avons constaté qu'aux alentours de 19:00, lorsque le nombre de requêtes augmentait fortement, la latence de recherche s'est considérablement dégradée. Comme le montrent les figures 1 et 2, lorsque le trafic atteignait un pic d'environ 400 requêtes par minute et par instance Elasticsearch, le temps de réponse moyen des requêtes chutait à plus de 60 ms.

L'utilisation du processeur est restée relativement faible après le traitement initial des connexions, indiquant que le calcul n'était pas le facteur limitant.

Une forte corrélation est apparue entre le volume de requêtes et les défauts de page. À mesure que les requêtes augmentaient, nous avons observé une hausse proportionnelle des défauts de page, avec un pic aux alentours de 400k/minute. Cela indique que l'ensemble de données actif ne pouvait pas être contenu dans le cache de pages.

Parallèlement, l'utilisation du tas JVM semblait normale et saine. Cela a permis d'exclure les problèmes de récupération de mémoire et de confirmer que le goulot d'étranglement était lié aux entrées/sorties.

Le diagnostic : I/O bound

Le système était limité par les E/S. Elasticsearch s'appuie sur le cache de pages du système d'exploitation pour fournir les données d'index depuis la mémoire. Lorsque l'index est trop volumineux pour le cache, les requêtes entraînent des lectures disque coûteuses. Bien que la solution classique consiste à effectuer un scaling horizontal (ajout de nœuds/RAM), nous souhaitions d'abord optimiser au maximum nos ressources existantes.

La solution

Par défaut, Elasticsearch utilise la compression LZ4 pour ses segments d'index, qui offre un bon compromis entre vitesse et taille. Nous avons émis l'hypothèse que le passage à best_compression (qui utilise zstd) réduirait la taille des index. Une empreinte mémoire plus faible permet d'intégrer une plus grande partie de l'index dans le cache de pages, moyennant une augmentation négligeable de la charge CPU (pour la décompression) au profit d'une réduction des E/S disque.

Pour activer best_compression, nous avons réindexé les données avec le paramètre d'index index.codec: best_compression. Sinon, le même résultat pourrait être obtenu en fermant l'index, en réinitialisant le codec d'index à best_compression, puis en effectuant une fusion de segments.

Résultats

Les résultats ont confirmé notre hypothèse : l'amélioration de l'efficacité du stockage s'est directement traduite par une augmentation substantielle des performances de recherche sans augmentation concomitante de l'utilisation du processeur.

L'application de best_compression a réduit la taille de l'index d'environ 25 %. Bien qu'inférieure à la réduction observée dans les données de log répétitives, cette réduction de 25 % a effectivement augmenté la capacité de notre cache de pages dans les mêmes proportions.

Lors du test de charge suivant (à partir de 17:00), le trafic était encore plus élevé, avec un pic de 500 requêtes par minute et par nœud Elasticsearch.

Malgré la charge plus élevée, l'utilisation du processeur était inférieure à celle de l'exécution précédente. L'utilisation élevée dans le test précédent était probablement due à la surcharge liée à la gestion excessive des défauts de page et à la gestion des E/S de disque.

Surtout, le nombre de défauts de page diminue de manière significative. Même à un débit plus élevé, les erreurs se situent autour de <200k par minute, contre >300k dans le test de référence.

Bien que les résultats concernant les défauts de page soient encore loin d'être optimaux, le temps de réponse aux requêtes a été réduit d'environ 50 %, se maintenant sous la barre des 30 ms même en cas de charge plus importante.

Conclusion : best_compression pour la recherche

Pour les cas d'utilisation de recherche où le volume de données dépasse la mémoire physique disponible, best_compression est un levier puissant d'optimisation des performances.

La solution classique aux erreurs de cache consiste à scaler pour augmenter la RAM. Cependant, en réduisant l'empreinte de l'index, nous avons atteint le même objectif : maximiser le nombre de documents dans le cache de pages. Notre prochaine étape consistera à explorer l'index trié afin d'optimiser davantage l'espace de stockage et d'améliorer encore les performances de nos ressources existantes.

Mais en corrigeant ce cas précis, vous risquez de détériorer d’autres requêtes, faute de pouvoir tester chaque cas manuellement. Mais comment vérifier, vous ou votre équipe QA, si une modification d’une requête a un effet en cascade sur les autres ? Et surtout, comment s’assurer que les modifications apportées ont réellement amélioré une requête ?

Vers une évaluation systématique

C’est là que les listes de jugement prennent tout leur sens. Plutôt que de recourir à des tests manuels et subjectifs à chaque changement, vous pouvez définir un ensemble fixe de requêtes pertinentes pour votre cas d’usage, avec leurs résultats attendus.

Cet ensemble vous sert de référence. À chaque modification, vous l’utilisez pour déterminer si votre recherche s’est effectivement améliorée ou non.

Ce qui rend cette approche si précieuse :

• Élimine l’incertitude : plus besoin de vous demander si vos changements impactent d’autres requêtes – les données vous le diront.

• Met fin aux tests manuels : une fois les ensembles de jugement enregistrés, le test devient automatique.

• Accompagne les changements : vous pouvez mettre en évidence des métriques claires qui confirment les bénéfices d’une modification.

Comment constituer votre liste de jugement

L’une des façons les plus simples de commencer consiste à choisir une requête représentative et à sélectionner manuellement les documents pertinents. Deux approches sont possibles pour construire cette liste :

• Jugements binaires : Chaque document associé à une requête reçoit une étiquette simple : pertinent (1) ou non pertinent (0).

• Jugements gradués : chaque document reçoit ici un score selon différents niveaux. Exemple : une échelle de 0 à 4, semblable à une échelle de Likert, où 0 signifie « pas du tout pertinent » et 4 « totalement pertinent », avec des nuances comme « pertinent », « plus ou moins pertinent », etc.

Les jugements binaires sont adaptés lorsque l’intention de recherche est bien définie : ce document doit-il apparaître dans les résultats ou non ?

Les jugements gradués sont utiles lorsque la frontière est plus floue : certains résultats sont meilleurs que d’autres. On peut ainsi distinguer des résultats « très pertinents », « pertinents » ou « inutiles », et utiliser des métriques qui prennent en compte l’ordre des résultats ainsi que les retours des utilisateurs. Mais les échelles graduées présentent aussi des inconvénients : les évaluateurs peuvent interpréter différemment les niveaux de notation, ce qui nuit à la cohérence des jugements. De plus, comme les métriques graduées accordent plus de poids aux notes élevées, une légère variation (par exemple, noter 3 au lieu de 4) peut entraîner un changement bien plus important dans la métrique que ce que l’évaluateur avait anticipé. Cette part de subjectivité rend les jugements gradués plus bruyants et plus difficiles à gérer dans le temps.

Dois-je classer les documents moi-même ?

Pas forcément, car il existe plusieurs façons de créer votre liste de jugement, chacune avec ses avantages et ses inconvénients :

• Jugements explicites : des experts métier examinent chaque couple requête/document et évaluent manuellement le niveau de pertinence. Cela garantit qualité et contrôle, mais c’est moins scalable.

• Jugements implicites : cette méthode déduit les documents pertinents à partir du comportement réel des utilisateurs : clics, taux de rebond, achats, etc. Elle permet de collecter automatiquement des données, mais celles-ci peuvent être biaisées. Par exemple, les utilisateurs ont tendance à cliquer plus souvent sur les premiers résultats, même s’ils ne sont pas pertinents.

• Jugements générés par l’IA : cette dernière option utilise des modèles (comme les LLM) pour évaluer automatiquement les requêtes et les documents – on parle souvent de jurys LLM. C’est rapide et facilement scalable, mais la qualité des données dépend du modèle utilisé et de la pertinence de ses données d’entraînement vis-à-vis de vos objectifs métier. Comme pour les évaluations humaines, les jurys LLM peuvent introduire leurs propres biais ou incohérences. Il est donc essentiel de valider leurs résultats à l’aide d’un ensemble restreint de jugements de confiance. Les modèles LLM sont de nature probabiliste, il n’est donc pas rare de voir un modèle LLM attribuer des scores différents à un même résultat, même avec un paramètre de température réglé sur 0.

Voici quelques recommandations pour choisir la méthode la plus adaptée à la création de votre ensemble de jugement :

• Décidez des fonctionnalités critiques pour lesquelles seuls les utilisateurs peuvent vraiment juger (prix, marque, langue, style, détails du produit, etc.). Si ces éléments sont critiques, vous avez besoin de jugements explicites – au moins pour une partie de votre liste de jugement.

• Utilisez des jugements implicites lorsque votre moteur de recherche génère déjà suffisamment de trafic pour que vous puissiez exploiter les clics, conversions et temps passés comme métriques de tendance. Il reste essentiel d’interpréter ces résultats avec prudence, en les comparant à des jugements explicites afin d’éviter tout biais (ex. : les utilisateurs ont tendance à cliquer sur les premiers résultats, même si des documents plus pertinents apparaissent plus bas).

Pour y remédier, des techniques de réduction des biais de position permettent d’ajuster ou de repondérer les données de clics afin de mieux refléter l’intérêt réel des utilisateurs. Parmi les approches possibles :

• Changement d’ordre des résultats : permet de modifier l’ordre des résultats de recherche pour un sous-ensemble d’utilisateurs afin d’évaluer l’effet de la position sur les clics.

• Les modèles de clic incluent : Dynamic Bayesian Network (DBN), User Browsing Model (UBM), etc. Ces modèles statistiques estiment la probabilité qu’un clic reflète un véritable intérêt et non simplement une position dans la page, en prenant en compte des facteurs comme le défilement, la durée du clic, la séquence de navigation, et le retour aux résultats.

Exemple : application de notation de films

Produits requis

Pour exécuter cet exemple, vous avez besoin d'un cluster Elasticsearch 8.x en cours d'exécution, en local ou sur Elastic Cloud Hosted (hébergé ou sans serveur), ainsi que d'un accès à l'API REST ou à Kibana.

Imaginez une application dans laquelle les utilisateurs peuvent publier leurs avis sur des films et aussi rechercher des films à regarder. Comme ces textes sont rédigés par les utilisateurs eux-mêmes, ils peuvent contenir des fautes de frappe ou de nombreuses variations dans la façon de s’exprimer. Il est donc essentiel que le moteur de recherche puisse interpréter cette diversité et fournir des résultats utiles aux utilisateurs.

Afin de pouvoir tester différentes requêtes sans impacter le comportement global de la recherche, l’équipe métier de votre entreprise a créé l’ensemble de jugement binaire suivant, basé sur les recherches les plus fréquentes :

Requête

DocID

Texte

Performance de DiCaprio

doc1

La performance de DiCaprio dans The Revenant était époustouflante.

Performance de DiCaprio

doc2

Inception montre Leonardo DiCaprio dans l’un de ses rôles les plus emblématiques.

Performance de DiCaprio

doc3

Brad Pitt offre une performance solide dans ce thriller criminel.

Performance de DiCaprio

doc4

Une aventure riche en action avec des effets visuels impressionnants.

films tristes qui vous font pleurer

doc5

Une histoire bouleversante d’amour et de perte qui m’a fait pleurer pendant des heures.

films tristes qui vous font pleurer

doc6

Un des films les plus tristes jamais réalisés — apportez des mouchoirs !

films tristes qui vous font pleurer

doc7

Une comédie légère qui vous fera rire

films tristes qui vous font pleurer

doc8

Une épopée de science-fiction pleine d’action et de rebondissements.

Création de l'index :

Requête BULK :

Voici la requête Elasticsearch utilisée par l’application :

Du jugement aux métriques

À elles seules, les listes de jugement fournissent peu d’informations : elles ne font qu’exprimer une attente vis-à-vis des résultats de nos requêtes. Elles révèlent tout leur intérêt lorsqu’elles servent à calculer des métriques objectives pour évaluer les performances de la recherche.

Aujourd’hui, la plupart des métriques les plus courantes incluent

• Précision : mesure la proportion de résultats réellement pertinents parmi tous les résultats de recherche.

• Rappel : mesure la proportion de documents pertinents que le moteur de recherche a trouvés parmi tous les résultats.

• Gain Cumulé Actualisé (DCG) : mesure la qualité du classement des résultats, en tenant compte du fait que les documents les plus pertinents devraient apparaître en haut de la liste.

• Rang réciproque moyen (MRR) : mesure la position du premier résultat pertinent. Plus un document est haut dans la liste, plus son score est élevé.

En reprenant l’exemple de l’application de notation de films, nous allons calculer la métrique de rappel pour vérifier si des informations sont ignorées par nos requêtes.

Dans Elasticsearch, nous pouvons utiliser les listes de jugement pour calculer ces métriques via l’API Ranking Evaluation. Cette API prend en entrée la liste de jugement, la requête et la métrique à évaluer, puis retourne une valeur qui correspond à une comparaison du résultat de la requête avec la liste de jugement.

Lançons la liste de jugement pour les deux requêtes dont nous disposons :

Nous allons utiliser deux requêtes avec rank_eval : une pour la requête sur DiCaprio et une autre pour les films tristes. Chaque requête est accompagnée de sa propre liste de jugement (notations). Il n’est pas nécessaire d’évaluer tous les documents : ceux qui ne figurent pas dans la liste de notation sont simplement considérés comme non jugés. Pour effectuer les calculs, la métrique de rappel ne prend en compte que l’« ensemble pertinent », c’est-à-dire les documents jugés pertinents dans l’évaluation.

Dans ce cas, la requête sur DiCaprio obtient un rappel de 1, tandis que celle sur les films tristes obtient 0. Autrement dit, nous avons récupéré tous les résultats pertinents pour la première requête, et aucun pour la seconde. Le rappel moyen est donc de 0,5.

Peut-être que nous sommes trop stricts avec le paramètre minimum_should_match : en exigeant que 100 % des mots de la requête soient présents dans les documents, nous risquons d’écarter des résultats pertinents. Supprimons le paramètre minimum_should_match, afin qu’un document soit considéré comme pertinent dès qu’un seul mot de la requête est présent.

Comme vous pouvez le constater, en supprimant le paramètre minimum_should_match dans l'une des deux requêtes, nous obtenons maintenant un rappel moyen de 1 dans les deux cas.

En résumé, supprimer la clause minimum_should_match : 100 % permet d’obtenir un rappel parfait pour les deux requêtes.

Nous l'avons fait ! N'est-ce pas ?

Pas si vite !

En augmentant le rappel, on élargit la gamme des résultats possibles. Cependant, chaque ajustement implique un compromis. D’où l’importance de définir des cas de test complets, en utilisant plusieurs métriques pour évaluer les changements.

Les listes de jugement et les métriques vous évitent d’avancer à l’aveugle lorsque vous apportez des modifications, car vous disposez désormais de données pour les justifier. La validation n’est plus manuelle ni répétitive, et vous pouvez tester vos changements sur plusieurs cas d’usage, et non plus un seul. Les tests A/B vous permettent également de tester en conditions réelles la configuration qui convient le mieux à vos utilisateurs et à votre cas d’utilisation, bouclant ainsi la boucle entre métriques techniques et résultats concrets.

Recommandations finales pour l’utilisation des listes de jugement

Travailler avec des listes de jugement ne consiste pas seulement à mesurer : c’est aussi construire un cadre vous permettant d’itérer en toute confiance. Pour y parvenir, voici quelques recommandations :

1. Démarrez petit, mais démarrez. Il n’est pas nécessaire d’avoir 10 000 requêtes avec 50 listes de jugement chacune. Vous devez seulement identifier les 5 à 10 requêtes les plus critiques pour votre cas d’utilisation, et définir les documents que vous attendez en haut des résultats. Cela vous donne déjà une base de travail. En général, on commence par les principales requêtes et celles qui ne renvoient aucun résultat. Vous pouvez aussi tester en partant d’une métrique simple comme la précision, puis monter en complexité.

2. Validez avec les utilisateurs. Complétez les résultats chiffrés par des tests A/B en production. De cette façon, vous saurez si les modifications prometteuses dans les métriques ont aussi un véritable impact.

3. Gardez la liste vivante. Votre cas d’utilisation évoluera, tout comme vos requêtes critiques. Mettez régulièrement à jour votre liste de jugement pour refléter les nouveaux besoins.

4. Intégrez-la à vos workflows. Intégrez les listes de jugement dans vos pipelines de développement. Assurez-vous que chaque modification de configuration, de synonymes ou d’analyse de texte soit automatiquement validée à partir de votre liste de référence.

5. Connectez les savoir-faire techniques à la stratégie. Ne vous limitez pas à des métriques techniques comme la précision ou le rappel. Utilisez les résultats d’évaluation pour éclairer vos décisions métier.

Qu'est-ce que le découpage récursif ?

Le découpage récursif parcourt une liste de sections fournies en séparant les modèles afin de diviser progressivement un document en segments plus petits jusqu'à ce qu'ils atteignent une taille maximale souhaitée.

Comment configurer le découpage récursif ?

Les valeurs configurables fournies par l'utilisateur pour le découpage récursif sont les suivantes :

• (obligatoire) max_chunk_size: Le nombre maximum de mots dans un bloc.

• L'un ou l'autre :

  • separators: Une liste de motifs de chaînes regex qui seront utilisés pour découper le document en morceaux.

  • separator_group: Une chaîne qui correspondra à une liste par défaut de séparateurs définis par Elastic à utiliser pour des types de documents spécifiques. Actuellement, markdown et plaintext sont disponibles.

Comment fonctionne le découpage récursif ?

Le processus de découpage récursif d'un document d'entrée, d'un max_chunk_size (mesuré en mots) et d'une liste de chaînes de séparation est le suivant :

1. Si le document d'entrée est déjà compris dans la taille maximale des morceaux, il renvoie un seul morceau couvrant l'ensemble du document d'entrée.

2. Découper le texte en morceaux potentiels sur la base des occurrences du séparateur. Pour chaque morceau potentiel :

   1. Si le morceau potentiel ne dépasse pas la taille maximale, il est ajouté à la liste des morceaux à renvoyer à l'utilisateur.

   2. Sinon, répétez l'étape 2, en utilisant uniquement le texte du morceau potentiel et en le séparant à l'aide du séparateur suivant dans la liste. S'il n'y a plus de séparateurs à essayer, il faut se rabattre sur le découpage en phrases.

Exemples de configuration du découpage récursif

Outre la taille des morceaux, la principale configuration du découpage récursif consiste à sélectionner les séparateurs à utiliser pour diviser vos documents. Si vous ne savez pas par où commencer, Elasticsearch propose quelques groupes de séparateurs par défaut qui peuvent être utilisés pour des cas d'utilisation courants.

Utilisation de groupes de séparation

Pour utiliser un groupe séparateur, il suffit d'indiquer le nom du groupe que vous souhaitez utiliser lors de la configuration des paramètres de regroupement. Par exemple :

Vous obtiendrez ainsi une stratégie de découpage récursif qui utilise la liste de séparateurs ["(?<!\\n)\\n\\n(?!\\n)", "(?<!\\n)\\n(?!\\n)")]. Cela fonctionne bien pour les applications génériques de texte brut, en séparant deux caractères de retour à la ligne, suivis d'un caractère de retour à la ligne.

Nous proposons également un groupe de séparateurs markdown qui utilisera la liste des séparateurs :

Cette liste de séparateurs fonctionnera bien pour les cas d'utilisation généraux de markdown, en séparant chacun des 6 niveaux d'en-tête et les caractères de coupure de section.

Lors de la création d'une ressource (point d'inférence/champ textuel sémantique), la liste des séparateurs correspondant au groupe de séparateurs du moment sera stockée dans vos configurations. Si le groupe de séparateurs est mis à jour ultérieurement, cela ne modifiera pas le comportement des ressources déjà créées.

Utilisation d'une liste de séparateurs personnalisée

Si l'un des groupes de séparateurs prédéfinis ne convient pas à votre cas d'utilisation, vous pouvez définir une liste personnalisée de séparateurs répondant à vos besoins. Notez que des expressions régulières peuvent être fournies dans la liste des séparateurs. Voici un exemple de paramètres de regroupement configurés avec des séparateurs personnalisés :

La stratégie de découpage en morceaux découpera 2 caractères de nouvelle ligne, suivis d'un caractère de nouvelle ligne, et enfin une chaîne de caractères “<my-custom-separator>”.

Un exemple de découpage récursif en action

Voyons un exemple de découpage récursif en action. Pour cet exemple, nous utiliserons les paramètres de découpage suivants avec une liste personnalisée de séparateurs qui découpent un document markdown en utilisant les deux premiers niveaux d'en-tête :

Examinons un simple document Markdown non tronqué :

Utilisons maintenant les paramètres de découpage définis ci-dessus pour découper le document en morceaux :

Remarque : la nouvelle ligne à la fin de chaque morceau (à l'exception du morceau 3) n'est pas mise en évidence, mais elle est incluse dans les limites du morceau.

Commencez dès aujourd'hui à utiliser le découpage récursif !

Pour plus d'informations sur l'utilisation de cette fonctionnalité, consultez la documentation sur la configuration des paramètres de regroupement.

Lisez le blog Building AI Agentic Workflows with Elasticsearch pour en savoir plus sur la "vue d'ensemble" de cet effort, ou Your First Elastic Agent : From a Single Query to an AI-Powered Chat pour une introduction plus pratique.

Dans ce blog, nous allons nous intéresser à l'une des premières choses qui se produisent lorsque vous commencez à discuter et vous présenter quelques-unes des améliorations récentes que nous avons apportées.

Que se passe-t-il ici ?

Lorsque vous discutez avec vos données Elasticsearch, notre agent IA par défaut suit ce flux standard :

1. Inspecter l'invite.

2. Identifiez l'index susceptible de contenir les réponses à cette question.

3. Générer une requête pour cet index, sur la base de l'invite.

4. Effectuez une recherche dans cet index avec cette requête.

5. Synthétiser les résultats.

6. Les résultats peuvent-ils répondre à l'invitation ? Si oui, répondez. Si ce n'est pas le cas, répétez l'opération, mais essayez quelque chose de différent.

Cela ne devrait pas sembler trop nouveau - il s'agit simplement de Retrieval Augmented Generation (RAG). Et comme on peut s'y attendre, la qualité de vos réponses dépend fortement de la pertinence de vos premiers résultats de recherche. En travaillant à l'amélioration de la qualité de nos réponses, nous avons donc accordé une attention toute particulière aux requêtes générées à l'étape 3 et exécutées à l'étape 4. Et nous avons remarqué une tendance intéressante.

Souvent, lorsque nos premières réponses étaient "mauvaises", ce n'était pas parce que nous avions lancé une mauvaise requête. C'est parce que nous avions choisi le mauvais index à interroger. Les étapes 3 et 4 ne nous posaient généralement pas de problème - c'était l'étape 2.

Que faisions-nous ?

Notre mise en œuvre initiale était simple. Nous avions construit un outil (appelé index_explorer) qui faisait effectivement un _cat/indices pour lister tous les indices disponibles, puis demandait au LLM d'identifier lequel de ces indices correspondait le mieux au message/à la question/à l'invitation de l'utilisateur. Vous pouvez voir cette mise en œuvre originale ici.

Dans quelle mesure cela a-t-il fonctionné ? Nous n'étions pas sûrs ! Nous avions des exemples clairs de dysfonctionnements, mais notre premier défi était de quantifier notre situation actuelle.

Établir une base de référence

Cela commence par des données

Nous avions besoin d'un ensemble de données en or pour mesurer l'efficacité d'un outil à sélectionner le bon indice à partir d'une demande de l'utilisateur et d'un ensemble préexistant d'indices. Comme nous ne disposions pas d'un tel ensemble de données, nous en avons créé un.

Reconnaissance : Il ne s'agit pas d'une "meilleure pratique", nous le savons. Mais parfois, il est préférable d'aller de l'avant plutôt que de faire du surplace. Le progrès, la perfection SIMPLE.

Nous avons généré des indices de semences pour plusieurs domaines différents à l'aide de cette invite. Ensuite, pour chaque domaine généré, nous avons généré quelques indices supplémentaires en utilisant cette invite (l'objectif étant ici de semer la confusion pour le LLM avec des négatifs durs et des exemples difficiles à classer). Ensuite, nous avons édité manuellement chaque index généré et ses descriptions. Enfin, nous avons généré des requêtes de test à l'aide de cette invite, ce qui nous a permis d'obtenir des échantillons de données tels que les suivants :

et des cas de test tels que :

Élaboration d'un harnais de test

À partir de là, la procédure a été très simple. Script up a tool that could :

1. Faire table rase du passé avec un cluster Elasticsearch cible.

2. Créer tous les indices définis dans le jeu de données cible.

3. Pour chaque scénario de test, exécutez l'outil index_explorer (nous disposons d'une API pour l'exécution de l'outil).

4. Comparez l'indice du résultat à l'indice attendu et saisissez le résultat.

5. Une fois tous les scénarios de test terminés, les résultats sont présentés sous forme de tableau.

L'enquête dit...

Les premiers résultats ont été, sans surprise, médiocres.

Dans l'ensemble, 77,14% ont identifié avec précision le bon indice. Et ce, dans le meilleur des cas, c'est-à-dire lorsque tous les indices ont des noms appropriés et sémantiquement significatifs. Quiconque a déjà fait un `PUT test2/_doc/foo {...}` sait que vos index n'ont pas toujours des noms significatifs.

Nous disposons donc d'une base de référence, qui montre qu'il y a beaucoup de place pour l'amélioration. Il était temps de faire de la science ! 🧪

Expérimentation

Hypothèse 1 : Les cartographies aideront à

L'objectif est ici d'identifier un index qui contiendra des données pertinentes pour le message original. La partie d'un index qui décrit le mieux les données qu'il contient est le mappage de l'index. Même sans saisir d'échantillons du contenu de l'index, le fait de savoir que l'index possède un champ prix de type double implique que les données représentent quelque chose à vendre. Un champ auteur de type texte implique des données linguistiques non structurées. L'association des deux pourrait impliquer que les données sont des livres, des histoires ou des poèmes. De nombreux indices sémantiques peuvent être déduits de la seule connaissance des propriétés d'un index. Dans une branche locale, j'ai donc ajusté notre `.index_explorer` pour envoyer les mappings complets d'un index (ainsi que son nom) au LLM afin qu'il prenne sa décision.

Le résultat (à partir des journaux Kibana) :

Les premiers auteurs de l'outil l'avaient prévu. Si le mappage d'un index est une mine d'or d'informations, c'est aussi un bloc de JSON assez verbeux. Et dans un scénario réaliste où vous comparez de nombreux indices (notre ensemble de données d'évaluation en définit 20), ces blobs JSON s'accumulent. Nous voulons donc donner au LLM plus de contexte pour sa décision que de simples noms d'index pour toutes les options, mais pas autant que les mappings complets de chacune d'entre elles.

Hypothèse 2 : des correspondances "aplaties" (listes de champs) en guise de compromis

Nous sommes partis de l'hypothèse que les créateurs d'index utiliseront des noms d'index sémantiquement significatifs. Et si nous étendions cette hypothèse aux noms des champs ? Notre expérience précédente a échoué parce que le mappage de JSON comprend BEAUCOUP de métadonnées et d'éléments parasites.

Le bloc ci-dessus, par exemple, compte 236 caractères et définit un seul champ dans une correspondance Elasticsearch. Alors que la chaîne "description_text" ne comporte que 16 caractères. Le nombre de caractères a été multiplié par près de 15, sans amélioration sémantique significative de la description de ce que ce champ implique à propos des données disponibles. Que se passerait-il si nous récupérions les correspondances pour tous les indices, mais qu'avant de les envoyer au LLM, nous les "aplatissions" en une simple liste de noms de champs ?

Nous avons essayé.

C'est formidable ! Des améliorations dans tous les domaines. Mais pourrions-nous faire mieux ?

Hypothèse 3 : Descriptions dans le mapping _meta

Si le simple fait de nommer les champs sans contexte supplémentaire a provoqué un tel saut, on peut supposer que l'ajout d'un contexte substantiel serait encore plus efficace ! Il n'est pas nécessairement conventionnel que chaque index soit accompagné d'une description, mais il est possible d'ajouter des métadonnées de tout type au niveau de l'index à l'objet _meta de la cartographie. Nous avons repris les index générés et ajouté des descriptions pour chaque index de notre ensemble de données. Tant que les descriptions ne sont pas trop longues, elles devraient utiliser moins de tokens que la cartographie complète et fournir de bien meilleures indications sur les données incluses dans l'index. Notre expérience a validé cette hypothèse.

Une amélioration modeste, et nous sommes maintenant >90% précis dans tous les domaines.

Hypothèse 4 : La somme est plus grande que les parties

Les noms de champs ont permis d'améliorer nos résultats. Les descriptions ont permis d'accroître nos résultats. L'utilisation des descriptions ET des noms de champs devrait donc permettre d'obtenir de meilleurs résultats, n'est-ce pas ?

Les données ont répondu "non" (pas de changement par rapport à l'expérience précédente). La théorie principale était que, puisque les descriptions ont été générées à partir des champs/mappings de l'index, il n'y a pas assez d'informations différentes entre ces deux éléments de contexte pour ajouter quelque chose de "nouveau" lorsqu'on les combine. En outre, la charge utile que nous envoyons pour nos 20 indices de test devient assez importante. Le raisonnement que nous avons suivi jusqu'à présent n'est pas extensible. En fait, il y a de bonnes raisons de croire qu'aucune des expériences que nous avons menées jusqu'à présent ne fonctionnerait sur des clusters Elasticsearch où il y a des centaines ou des milliers d'indices à choisir. Toute approche qui augmente linéairement la taille du message envoyé au LLM à mesure que le nombre total d'indices augmente n'est probablement pas une stratégie généralisable.

Ce dont nous avons vraiment besoin, c'est d'une approche qui nous aide à réduire un grand nombre de candidats aux options les plus pertinentes...

Il s'agit d'un problème de recherche.

Hypothèse 5 : Sélection par recherche sémantique

Si le nom d'un index a une signification sémantique, il peut être stocké sous forme de vecteur et faire l'objet d'une recherche sémantique.

Si les noms des champs d'un index ont une signification sémantique, ils peuvent être stockés sous forme de vecteurs et faire l'objet d'une recherche sémantique.

Si un index possède une description ayant une signification sémantique, il peut lui aussi être stocké sous forme de vecteur et faire l'objet d'une recherche sémantique.

Aujourd'hui, les index Elasticsearch ne rendent aucune de ces informations consultables (peut-être devrions-nous le faire !), mais il était assez simple de bricoler quelque chose qui pouvait combler cette lacune. En utilisant le cadre de connecteur d'Elastic, j'ai construit un connecteur qui produirait un document pour chaque index dans un cluster. Les documents de sortie ressembleraient à quelque chose comme :

J'ai envoyé ces documents vers un nouvel index où j'ai défini manuellement le mappage :

Cela crée un champ unique semantic_content, dans lequel tous les autres champs ayant une signification sémantique sont regroupés et indexés. La recherche dans cet index devient triviale, avec simplement :

L'outil index_explorer modifié est maintenant beaucoup plus rapide, car il n'a pas besoin de faire une demande à un LLM, mais peut demander un seul encastrement pour la requête donnée et effectuer une opération de recherche vectorielle efficace. En prenant le premier hit comme index sélectionné, nous avons obtenu les résultats suivants :

Cette approche est évolutive. Cette approche est efficace. Mais cette approche est à peine meilleure que notre ligne de base. Ce n'est pas surprenant, car l'approche de la recherche est incroyablement naïve. Il n'y a aucune nuance. Aucune reconnaissance du fait que le nom et la description d'un index devraient avoir plus de poids qu'un nom de champ arbitraire que l'index contient. Pas de possibilité de pondérer les correspondances lexicales exactes par rapport aux correspondances synonymes. Cependant, la construction d'une requête très nuancée nécessiterait de supposer BEAUCOUP de choses sur les données disponibles. Jusqu'à présent, nous avons déjà fait des hypothèses importantes sur la signification sémantique des noms d'index et de champs, mais nous devrions aller plus loin et commencer à supposer la signification qu 'ils ont et la manière dont ils sont liés les uns aux autres. Sans cela, nous ne pouvons probablement pas identifier de manière fiable la meilleure correspondance comme premier résultat, mais nous pouvons plus probablement dire que la meilleure correspondance se trouve quelque part dans les N premiers résultats. Nous avons besoin de quelque chose qui puisse consommer des informations sémantiques dans le contexte dans lequel elles existent, en les comparant à celles d'une autre entité qui peut se représenter d'une manière sémantiquement distincte, et juger entre elles. Comme un LLM.

Hypothèse 6 : Réduction du nombre de candidats

Il y a eu bien d'autres expériences que je vais passer sous silence, mais la principale avancée a été d'abandonner le désir de choisir la meilleure correspondance uniquement à partir d'une recherche sémantique, et d'utiliser plutôt la recherche sémantique comme un filtre pour éliminer les indices non pertinents de la considération du LLM. Nous avons combiné la recherche linéaire, la recherche hybride avec RRF et semantic_text pour notre recherche, en limitant les résultats aux 5 premiers indices correspondants.

Ensuite, pour chaque correspondance, nous avons ajouté le nom de l'index, la description et les noms des champs à un message pour le LLM. Les résultats ont été fantastiques :

La plus grande précision de toutes les expériences réalisées à ce jour ! Et comme cette approche n'augmente pas la taille du message proportionnellement au nombre total d'indices, elle est beaucoup plus évolutive.

Résultats

Le premier résultat clair est que notre base de référence peut être améliorée. Cela semble évident rétrospectivement, mais avant le début de l'expérimentation, des discussions sérieuses ont eu lieu sur la question de savoir si nous devions abandonner complètement notre outil index_explorer et nous fier à la configuration explicite de l'utilisateur pour limiter l'espace de recherche. Bien que cela reste une option viable et valable, cette recherche montre qu'il existe des voies prometteuses vers l'automatisation de la sélection de l'indice lorsque les données de l'utilisateur ne sont pas disponibles.

Le résultat suivant a été que le simple fait d'ajouter des caractères de description au problème a un rendement décroissant. Avant cette recherche, nous nous demandions si nous devions investir dans l'extension de la capacité d'Elasticsearch à stocker des métadonnées au niveau des champs. Aujourd'hui, ces valeurs meta sont plafonnées à 50 caractères, et l'on a supposé qu'il faudrait augmenter cette valeur pour pouvoir obtenir une compréhension sémantique de nos champs. Ce n'est manifestement pas le cas, et le LLM semble s'en sortir assez bien avec des noms de domaines. Nous pourrons approfondir cette question ultérieurement, mais elle ne nous semble plus urgente.

Inversement, cela a clairement démontré l'importance d'avoir des métadonnées d'index "consultables". Pour ces expériences, nous avons piraté un index des indices. Mais c'est quelque chose que nous pourrions étudier en l'intégrant directement dans Elasticsearch, en créant des API pour le gérer, ou au moins en établissant une convention à ce sujet. Nous allons évaluer nos options et en discuter en interne, alors restez à l'écoute.

Enfin, cet effort a confirmé l'intérêt de prendre le temps d'expérimenter et de prendre des décisions fondées sur des données. En fait, cela nous a aidés à réaffirmer que notre produit Agent Builder aura besoin de capacités d'évaluation robustes et intégrées au produit. Si nous devons créer un ensemble de tests uniquement pour un outil qui prélève des indices, nos clients auront absolument besoin de moyens pour évaluer qualitativement leurs outils personnalisés au fur et à mesure qu'ils procèdent à des ajustements itératifs.

Je suis impatient de voir ce que nous allons construire, et j'espère que vous l'êtes aussi !

Imaginez un gestionnaire financier qui doit se mettre à niveau avant une réunion avec un client. Au lieu de chercher manuellement dans les fils d'actualité et de croiser les tableaux de bord des portefeuilles, ils peuvent désormais simplement poser une question directe à leur agent personnalisé. C'est l'avantage d'une approche "chat-first". Le gestionnaire a un lien direct et conversationnel avec ses données, en posant des questions telles que : "Quelles sont les dernières nouvelles sur ACME Corp et comment cela affecte-t-il les avoirs de mon client ?" et obtenir une réponse synthétisée et experte en quelques secondes.

Si nous construisons aujourd'hui un expert financier, les applications sont aussi variées que vos données. Le même pouvoir peut créer un analyste en cybersécurité pour traquer les menaces, un ingénieur en fiabilité de site pour diagnostiquer une panne ou un responsable marketing pour optimiser une campagne. Quel que soit le domaine, la mission principale est la même : transformer vos données en un spécialiste avec lequel vous pouvez discuter.

Étape 0 : Notre ensemble de données

Notre jeu de données du jour est un jeu de données synthétique à dominante financière, composé de comptes, de positions d’actifs, d’actualités économiques et de rapports financiers. Bien qu’il soit artificiel, il reproduit une version simplifiée d’un véritable jeu de données financières.

financial_accounts: Portefeuilles de clients avec profils de risque

financial_holdings: Positions en actions/ETF/obligations avec historique des achats

financial_asset_details: Détails sur l'action/ETF/obligation

financial_news: Articles de marché générés par l'IA avec analyse des sentiments

financial_reports: Résultats de l'entreprise et notes des analystes

Vous pouvez charger vous-même cet ensemble de données en suivant le cahier d'accompagnement situé ici.

Étape 1 : La base - Votre logique d'entreprise en tant qu'ES|QL

Toute compétence en matière d'IA commence par un solide morceau de logique. Pour notre agent Financial Manager, nous devons lui apprendre à répondre à une question courante : "Je m'inquiète du sentiment du marché. Pouvez-vous me montrer lesquels de nos clients sont les plus exposés aux mauvaises nouvelles ?" Cette question va au-delà d'une simple recherche. Cela nous oblige à établir une corrélation entre le sentiment du marché et les portefeuilles des clients.

Nous devons trouver les actifs mentionnés dans les articles négatifs, identifier chaque client détenant ces actifs, calculer la valeur de marché actuelle de leur exposition, puis classer les résultats afin d'établir un ordre de priorité pour les risques les plus élevés. Cette analyse complexe et multi-joints est le travail parfait pour notre outil avancé ES|QL.

Voici la requête complète que nous utiliserons. Il est impressionnant, mais les concepts sont simples.

En bref : jonctions et garde-corps

Deux concepts importants sont en jeu dans cette requête et font de l'agent un bâtisseur.

1. La jointure LOOKUP

Depuis des années, l'une des fonctionnalités les plus demandées d'Elasticsearch est la possibilité de joindre des données provenant de différents index sur la base d'une clé commune. Avec ES|QL, c'est désormais possible avec LOOKUP JOIN.

Dans notre nouvelle requête, nous effectuons une chaîne de trois LOOKUP JOIN: d'abord en reliant les nouvelles négatives aux détails des actifs, ensuite en reliant ces actifs aux avoirs des clients, et enfin en les reliant aux informations sur le compte du client. Cela permet d'obtenir un résultat incroyablement riche à partir de quatre indices différents en une seule requête efficace. Cela signifie que nous pouvons combiner des ensembles de données disparates pour créer une réponse unique et perspicace sans avoir à dénormaliser toutes nos données en un index géant au préalable.

2. Les paramètres comme garde-fous du LLM

Vous remarquerez que la requête utilise ?time_duration. Il ne s'agit pas seulement d'une variable, mais d'un garde-fou pour l'IA. Si les grands modèles de langage (LLM) sont excellents pour générer des requêtes, le fait de leur laisser le champ libre sur vos données peut conduire à des requêtes inefficaces, voire incorrectes.

En créant une requête paramétrée, nous obligeons le LLM à travailler dans le cadre de la logique commerciale testée, efficace et correcte qu'un expert humain a déjà définie. Il s'agit d'une méthode similaire à celle utilisée par les développeurs depuis des années pour exposer en toute sécurité les capacités de recherche aux applications. L'agent peut interpréter une demande de l'utilisateur comme "cette semaine" pour remplir le paramètre time_duration, mais il doit utiliser notre structure de requête pour obtenir la réponse. Cela nous permet d'obtenir un équilibre parfait entre flexibilité et contrôle.

En fin de compte, cette requête permet à un expert qui comprend les données d'encapsuler ses connaissances dans un outil. D'autres personnes - et des agents d'intelligence artificielle - peuvent alors utiliser cet outil pour obtenir des résultats corrélés en fournissant simplement un seul paramètre, sans avoir besoin de connaître la complexité sous-jacente.

Étape 2 : Les compétences - Transformer une requête en un outil réutilisable

Une requête ES|QL n'est que du texte jusqu'à ce que nous l'enregistrions en tant qu'outil. Dans l'Agent Builder, un outil est plus qu'une simple requête sauvegardée ; c'est une compétence "" qu'un agent IA peut comprendre et choisir d'utiliser. La magie réside dans la description en langage naturel que nous fournissons. Cette description est la passerelle qui relie la question de l'utilisateur à la logique d'interrogation sous-jacente. Enregistrons la requête que nous venons de construire.

Le chemin de l'interface utilisateur

La création d'un outil dans Kibana est un processus simple.

1. Naviguer vers Agents

• Cliquez sur Outils ou Gérer les outils et cliquez sur le bouton Nouvel outil.

2. Remplissez le formulaire avec les informations suivantes :

• ID de l'outil : find_client_exposure_to_negative_news

i. Il s'agit de l'identifiant unique de l'outil

• Description : "Détermine l'exposition du portefeuille du client aux nouvelles négatives. Cet outil analyse les nouvelles et les rapports récents pour y déceler un sentiment négatif, identifie l'actif associé et trouve tous les clients qui détiennent cet actif. Il renvoie une liste triée en fonction de la valeur de marché actuelle du poste afin de mettre en évidence le risque potentiel le plus élevé."

i. C'est ce que le LLM lit pour décider si cet outil est le bon pour le poste.

• Étiquettes: retrieval et risk-analysis

Les étiquettes sont utilisées pour regrouper plusieurs outils

• Configuration : Coller la requête ES|QL complète de l'étape 1

i. Voici la recherche que l'agent utilisera

3. Cliquez sur Inférer les paramètres de la requête. L'interface utilisateur trouvera automatiquement le site ?time_duration, dont la liste figure ci-dessous. Ajoutez une description simple pour chacun d'entre eux afin d'aider l'agent (et les autres utilisateurs) à comprendre leur fonction.

• time_duration: Le délai pour rechercher des nouvelles négatives. Le format est le suivant : "X heures" DEFAUT 8760 heures

4. Testez-le !

• Cliquez sur Save & test.

• Une nouvelle fenêtre s'ouvre, dans laquelle vous pouvez tester la requête pour vous assurer qu'elle fonctionne comme prévu.

i. Dans time_duration, entrez la plage souhaitée, ici nous utilisons "8760 heures"

• Cliquez sur "Submit" et si tout se passe bien, vous verrez une réponse JSON. Pour vous assurer qu'il fonctionne comme prévu, faites défiler la page vers le bas et regardez l'objet values. C'est là que les documents correspondants sont renvoyés.

5. Cliquez sur le "X" en haut à droite pour fermer la fenêtre de test. Votre nouvel outil apparaît alors dans la liste, prêt à être attribué à un agent.

Le chemin de l'API

Pour les développeurs qui préfèrent l'automatisation ou qui ont besoin de gérer des outils par programme, vous pouvez obtenir le même résultat avec un seul appel d'API. Il suffit d'envoyer une demande POST au point de terminaison /api/agent_builder/tools avec la définition de l'outil.

Étape 3 : Les cerveaux - Créer votre agent personnalisé

Nous avons créé une compétence réutilisable (l'outil). Nous devons maintenant créer l'agent, la personne qui l'utilisera réellement. Un agent est la combinaison d'un MLD, d'un ensemble spécifique d'outils auxquels vous lui donnez accès et, surtout, d'un ensemble d'instructions personnalisées qui agissent comme sa constitution, définissant sa personnalité, ses règles et son objectif.

L'art de la proposition

L'élément le plus important pour créer un agent fiable et spécialisé est la rapidité. Un ensemble d'instructions bien conçues fait la différence entre un chatbot générique et un assistant professionnel ciblé. C'est là que vous fixez les garde-fous, définissez les résultats et donnez à l'agent sa mission.

Pour notre agent Financial Manager, nous utiliserons l'invite suivante.

Voyons pourquoi cette incitation est si efficace :

• Elle définit une personnalité sophistiquée : La première ligne établit immédiatement que l'agent est un assistant spécialisé en intelligence des données ( "),", ce qui donne un ton professionnel et compétent.

• Il fournit un cadre de raisonnement : En disant à l'agent de "Comprendre, Planifier, Exécuter et Synthétiser," nous lui donnons une procédure opérationnelle standard. Cela améliore sa capacité à traiter des questions complexes et à plusieurs étapes.

• Il favorise le dialogue interactif : L'instruction de "poser des questions de clarification" rend l'agent plus robuste. Il minimisera les hypothèses erronées sur les demandes ambiguës, ce qui permettra d'obtenir des réponses plus précises.

Le chemin de l'interface utilisateur

1. Naviguez vers Agents.

• Cliquez sur Outils ou Gérer les outils et cliquez sur le bouton Nouvel outil.

2. Complétez les informations de base :

• ID de l'agent : financial_assistant.

• Instructions : Copiez le message ci-dessus.

• Étiquettes: Finance.

• Nom d'affichage : Financial Assistant.

• Description de l'affichage : An assistant for analyzing and understanding your financial data.

3. De retour en haut, cliquez sur Outils.

• Cochez la case à côté de notre outil find_client_exposure_to_negative_news.

4. Cliquez sur Enregistrer.

Le chemin de l'API

Vous pouvez créer exactement le même agent à l'aide d'une requête POST vers le point de terminaison /api/agent_builder/agents. Le corps de la demande contient toutes les mêmes informations : l'identifiant, le nom, la description, l'ensemble des instructions et une liste des outils que l'agent est autorisé à utiliser.

Étape 4 : La récompense - Avoir une conversation

Notre logique d'entreprise est encapsulée dans un outil et un cerveau "" est prêt à l'utiliser dans notre agent. Il est temps de voir tout cela se concrétiser. Nous pouvons maintenant commencer à discuter avec nos données à l'aide d'un agent spécialisé.

Le chemin de l'interface utilisateur

1. Naviguez jusqu'à Agents dans Kibana.

2. En utilisant le menu déroulant en bas à droite de la fenêtre de chat, passez de l'agent Elastic AI par défaut à l'agent Financial Assistant que nous venons de créer.

3. Posez une question qui permettra à l'agent d'utiliser notre outil spécialisé :

   1. Je m'inquiète du sentiment du marché. Pouvez-vous m'indiquer quels sont nos clients les plus exposés aux mauvaises nouvelles ?

Après quelques instants, l'agent vous renvoie une réponse parfaitement formatée et complète. En raison de la nature des LLM, votre réponse peut être formatée légèrement différemment, mais pour cette exécution, l'agent a renvoyé :

Que s'est-il passé ? Le raisonnement de l'agent

L'agent ne s'est pas contenté de "savoir" la réponse. Elle a exécuté un plan en plusieurs étapes centré sur la sélection du meilleur outil pour le travail. Voici un aperçu de son processus de réflexion :

• L'intention a été identifiée : Il a fait correspondre des mots clés de votre question, comme "risk" et "negative news," à la description de l'outil find_client_exposure_to_negative_news.

• Exécution d'un plan : Il a extrait le délai de votre demande et a lancé un appel unique à cet outil spécialisé.

• Délégation du travail : L'outil a ensuite effectué toutes les opérations lourdes : les jointures enchaînées, les calculs de valeur et le tri.

• Synthèse du résultat : Enfin, l'agent a formaté les données brutes de l'outil en un résumé clair et lisible par l'homme, en suivant les règles de l'invite.

Et nous ne sommes pas obligés de deviner, si nous élargissons notre réflexion et voyons plus de détails.

Le chemin de l'API

Vous pouvez entamer cette même conversation par le biais d'un programme. Il suffit d'envoyer la question d'entrée au point de terminaison de l'API converse, en veillant à spécifier le agent_id de notre financial_manager.

Pour les développeurs : Intégrer l'API

Si l'interface Kibana offre une expérience fantastique et intuitive pour la création et la gestion de vos agents, tout ce que vous avez vu aujourd'hui peut également être réalisé de manière programmatique. L'Agent Builder est construit sur un ensemble d'API, vous permettant d'intégrer cette fonctionnalité directement dans vos propres applications, pipelines CI/CD ou scripts d'automatisation.

Les trois principaux points d'aboutissement avec lesquels vous travaillerez sont les suivants :

• /api/agent_builder/tools: Le point final pour créer, lister et gérer les compétences réutilisables que vos agents peuvent utiliser.

• /api/agent_builder/agents: Le point final pour la définition de vos personas d'agents, y compris leurs instructions très importantes et l'affectation des outils.

• /api/agent_builder/converse: Le point final pour interagir avec vos agents, entamer des conversations et obtenir des réponses.

Pour une démonstration complète et pratique de l'utilisation de ces API pour réaliser chaque étape de ce tutoriel, consultez le bloc-notes Jupyter qui l'accompagne, disponible ici dans notre dépôt GitHub.

Conclusion : À vous de construire

Nous avons commencé par prendre une requête ES|QL et la transformer en une compétence réutilisable. Nous avons ensuite créé un agent d'intelligence artificielle spécialisé, en lui donnant une mission et des règles claires, et nous l'avons doté de cette compétence. Il en résulte un assistant sophistiqué capable de comprendre une question complexe et d'exécuter une analyse en plusieurs étapes pour fournir une réponse précise et fondée sur des données.

Ce flux de travail est au cœur du nouvel Agent Builder d' Elastic. Il est conçu pour être suffisamment simple pour que les utilisateurs non techniques puissent créer des agents via l'interface utilisateur, mais suffisamment nuancé pour que les développeurs puissent créer des applications personnalisées basées sur l'IA à partir de nos API. Plus important encore, il vous permet de connecter en toute sécurité des LLM à vos propres données, régies par la logique experte que vous définissez, et de discuter avec vos données.

Prêt à utiliser des agents pour dialoguer avec vos données ?

La meilleure façon de consolider ce que vous avez appris est de vous salir les mains. Essayez tout ce que nous avons discuté aujourd'hui dans notre atelier pratique interactif et gratuit. Vous suivrez l'ensemble de ce processus et bien d'autres choses encore dans un environnement de type "bac à sable".

Dans un prochain blog, nous vous montrerons comment utiliser une application autonome qui interagit avec notre agent Financial Assistant et nous nous pencherons sur le protocole de contexte de modèle (MCP) qui rend tout cela possible. Dans un autre blog, nous parlerons de la prise en charge par Agent Builder du protocole Agent2Agent, ou A2A, en cours de développement.

Restez à l'écoute et bonne construction !

Agent Builder : Une base pour la construction d'agents d'intelligence artificielle pilotés par les données

La promesse d'un agent d'intelligence artificielle est simple : donnez-lui un objectif et il fera le travail. Mais pour les développeurs, la réalité est une série de défis complexes. Tout d'abord, la qualité d'un agent dépend de sa perception de l'environnement et des outils qui lui sont fournis pour atteindre les objectifs de l'utilisateur. Par ailleurs, fournir le bon contexte à partir d'une mer de données d'entreprise diverses constitue un défi de taille. Enfin, tout cela doit être orchestré par une boucle de raisonnement fiable capable de planifier, d'exécuter et d'apprendre.

Pour résoudre ce problème, les développeurs doivent construire une pile complexe et fragile à partir de zéro. L'architecture actuelle des agents vous oblige à assembler plusieurs éléments disparates : un LLM, une base de données vectorielle, un magasin de métadonnées, des systèmes distincts pour la journalisation et la traçabilité, et un moyen d'évaluer si tout cela fonctionne. Ce n'est pas seulement complexe, c'est aussi coûteux, source d'erreurs, et cela rend difficile l'élaboration des systèmes d'IA de haute qualité et dignes de confiance que vos utilisateurs exigent.

Nous voulons donc simplifier les choses. Pour ce faire, notre approche consiste à prendre les éléments essentiels d'un agent contextuel efficace et à les intégrer directement au cœur d'Elasticsearch grâce à un nouvel ensemble de fonctionnalités appelé Elastic AI Agent Builder. Cette nouvelle couche fournit un cadre avec tous les éléments essentiels pour créer des agents d'intelligence artificielle alimentés par Elasticsearch : un ensemble ouvert de primitives, des protocoles basés sur des normes et un accès sécurisé aux données - afin que vous puissiez construire des systèmes agentiques adaptés aux données et aux exigences du monde réel :

Offrir des expériences d'IA: c'est l'objectif ultime. Avec notre Search AI Platform et vos données comme base, vous pouvez créer n'importe quel type d'application d'IA générative : des interfaces de chat personnalisées aux intégrations avec des frameworks agentiques comme LangChain ou des applications d'entreprise comme Salesforce.

Exploité par des agents & Tools: au-dessus de la plateforme, nous exposons une couche d'abstractions propre et simple. Vous interagissez directement avec les agents et les outils, que vous pouvez personnaliser pour répondre à vos besoins spécifiques. Vous pouvez également accéder aux capacités de la plateforme par le biais d'API robustes et de normes ouvertes telles que MCP et A2A.

La Search AI Platform: il s'agit du moteur de base dans lequel nous avons intégré les composants. La base de données vectorielle avancée, la logique de l'agent, la construction des requêtes, les caractéristiques de sécurité, le traçage pour l'évaluation, tout cela vit ici, géré et optimisé par Elastic.

Libérer la puissance de vos données: la base de tout grand agent est constituée de données de qualité. Notre plateforme commence par la capacité d'ingérer ou de fédérer l'accès à toutes les données de votre entreprise.

Création d'agents dans la plate-forme

Agent Builder, intégré à la Search AI Platform, fournit un cadre complet pour le développement d'agents. Il repose sur cinq piliers clés, chacun d'entre eux étant conçu pour traiter un aspect essentiel de la construction et du déploiement de systèmes d'IA de niveau de production. Voyons comment les agents définissent l'objectif, les outils fournissent les capacités, les normes ouvertes garantissent l'interopérabilité, l'évaluation assure la transparence et la sécurité assure la confiance.

Agents

Les agents sont le plus haut niveau de construction de cette nouvelle couche d'Elasticsearch. Un agent définit l'objectif à atteindre, l'ensemble des outils disponibles pour l'exécution et les sources de données sur lesquelles il peut agir. Les agents ne se limitent pas aux interactions conversationnelles ; ils peuvent alimenter des flux de travail complets, l'automatisation des tâches ou des expériences face à l'utilisateur.

Lorsqu'une demande est adressée à un agent, elle suit un cycle structuré :

1. Interpréter votre contribution et votre objectif

2. Sélectionner l'outil et les arguments adéquats pour l'exécution

3. Raisonner sur la réponse de l'outil

4. Décider si l'on renvoie un résultat ou si l'on poursuit les invocations d'outils.

Elastic se charge de l'orchestration, du contexte et de l'exécution de ce cycle. Les développeurs se concentrent sur la définition de ce que l'agent doit faire : objectifs, outils et données, tandis que le système gère la manière dont le raisonnement et les flux de travail sont exécutés.

L'agent par défaut

Notre premier agent construit sur cette plateforme est un agent conversationnel natif dans Kibana, vous donnant la possibilité d'interagir immédiatement avec vos données. Il offre une expérience prête à l'emploi tout en restant totalement extensible et permet de commencer à interagir avec vos données immédiatement, sans configuration supplémentaire.

Vous pouvez interagir avec cette expérience directement dans Kibana par le biais d'une nouvelle expérience utilisateur de chat ou par le biais de l'API.

L'interrogation de l'agent par défaut via l'API ne nécessite qu'un seul appel :

Comme les conversations ont un état, vous pouvez continuer à interagir avec un agent à l'aide d'un numéro d'identification de la conversation ou récupérer l'historique complet de la conversation :

Agents des douanes

Les développeurs peuvent également créer leurs propres agents personnalisés grâce à des API simples. Les agents encapsulent les instructions, les outils et l'accès aux données, créant ainsi des moteurs de raisonnement sur mesure.

La création d'un agent personnalisé est aussi simple qu'un simple appel à l'API. L'exemple ci-dessous montre un exemple, le champ "configuration" contient tous les détails clés, tels que les instructions ou les outils disponibles :

Une fois créé, l'agent peut être interrogé directement :

Cette approche transforme l'agent d'un système complexe à construire de toutes pièces en une unité simple et déclarative de logique d'entreprise, ce qui vous permet de mettre en place plus rapidement une automatisation intelligente.

Pour savoir comment créer un agent spécialisé à partir de zéro, consultez notre guide détaillé, étape par étape : Votre premier agent Elastic : D'une simple requête à un chat alimenté par l'IA.

Outils

Si les agents définissent ce qu'il faut accomplir, les outils définissent comment.

Les outils exposent les capacités spécifiques du noyau Elastic pour que les agents puissent exécuter et récupérer des informations ou effectuer une action. Les outils peuvent inclure des fonctionnalités de base telles que l'obtention d'index ou de mappages, ou des fonctionnalités plus avancées telles que le langage naturel pour ES|QL.

Elasticsearch est livré avec un ensemble d'outils par défaut optimisés pour les besoins courants. Mais la véritable flexibilité réside dans la création de votre propre système. En définissant les outils, vous décidez exactement quelles requêtes, quels index et quels champs sont exposés à un agent avec ES|QL, ce qui vous permet de contrôler précisément la vitesse, la précision et la sécurité.

L'enregistrement d'un nouvel outil est aussi simple qu'un simple appel à l'API. Vous pouvez créer un outil qui exploite notre ES|QL (Elasticsearch Query Language) pour trouver des informations sur un actif financier spécifique :

Une fois enregistré, vous pouvez attribuer le nouvel outil à vos agents personnalisés, en leur donnant un ensemble de capacités à raisonner et à invoquer chaque fois que cela est nécessaire.

Nous fournissons une plateforme pour créer des outils personnalisés pour vos besoins spécifiques, par exemple avec ES|QL qui transforme l'agent polyvalent en un expert spécifique à un domaine, fondé sur vos données uniques et votre domaine d'activité.

Normes ouvertes et interopérabilité

Les agents et outils Elasticsearch sont exposés via des API standard ouvertes, ce qui facilite leur intégration en tant que blocs fondamentaux dans l'écosystème plus large des cadres agentiques. Notre approche est simple : pas de boîte noire. Nous voulons que vous puissiez prendre la force principale d'Elastic en matière de recherche et l'associer à des capacités complémentaires et à d'autres systèmes agentiques.

Pour rendre cela possible, nous exposons nos capacités par le biais d'API, de protocoles émergents et de normes ouvertes.

Protocole de contexte de modèle (MCP)

Le protocole MCP (Model Context Protocol) est en passe de devenir la norme ouverte pour la connexion des outils entre les systèmes. En prenant en charge MCP, Elasticsearch peut connecter l'IA conversationnelle à vos bases de données, indices et API externes. Avec un serveur MCP distant intégré à la pile Elastic, tout client compatible MCP peut accéder aux outils d'Elastic et les utiliser comme éléments de construction dans vos flux de travail agentiques plus vastes.

Il ne s'agit pas d'une voie à sens unique. Vous pourrez également importer des outils à partir de serveurs MCP externes et les rendre disponibles dans Elasticsearch. Bientôt, les serveurs MCP seront probablement disponibles pour presque tout et seront bien plus complets que tout ce que nous pourrions créer nous-mêmes. Elastic fournit des fonctions de recherche et d'extraction à grande échelle, et vous pouvez les combiner avec des capacités spécialisées d'autres plateformes pour créer des agents efficaces.

Agent à agent (A2A)

Nous travaillons également sur la prise en charge des services d'agent à agent (A2A). Alors que le MCP concerne la connexion des outils, l'A2A concerne la connexion des agents. Avec un serveur A2A, les agents Elastic que vous créez pourront dialoguer directement avec des agents d'autres systèmes : partage de contexte, délégation de tâches et coordination de flux de travail.

Il s'agit d'une interopérabilité au niveau du raisonnement. Votre agent Elastic pourrait se charger de la recherche et de l'extraction, puis confier une tâche à un agent spécialisé dans l'assistance ou les technologies de l'information, et recevoir le résultat en retour de manière transparente. Il en résulte un écosystème d'agents coopérants, chacun faisant ce qu'il fait le mieux.

En fin de compte, l'adoption de MCP et d'A2A renforce notre engagement en faveur du rôle d'Elasticsearch en tant que citoyen de première classe, garantissant une intégration ouverte dans l'ensemble de l'écosystème agentique.

Recherche et évaluation

Au fur et à mesure que la recherche s'intègre aux agents, le défi d'une évaluation efficace devient crucial. Pour déployer en toute confiance des agents dans des environnements d'entreprise réels, vous devez avoir l'assurance qu'ils sont non seulement précis, mais aussi efficaces et fiables. Comment mesurer les performances, diagnostiquer une mauvaise réponse ou améliorer la situation de départ ? Tout commence par la visibilité.

C'est pourquoi nous avons conçu nos API pour la transparence dès le départ. Prenons l'exemple d'une simple interaction avec un agent :

La réponse comprend non seulement la réponse finale, mais aussi la trace complète de l'exécution, détaillant les outils sélectionnés par l'agent, les paramètres utilisés et les résultats de chaque étape.

Une traçabilité et une journalisation complètes sont essentielles pour une boucle d'amélioration continue, et bientôt, vous pourrez stocker et visualiser ces traces d'agents directement dans Elasticsearch. Mieux encore, ces traces sont construites sur le protocole OpenTelemetry, ce qui garantit qu'elles sont normalisées et portables pour l'intégration avec la plateforme d'observabilité de votre choix.

Ce niveau de détail est la base d'une véritable boucle d'amélioration continue. Il vous permet d'élaborer une suite complète de tests, de déboguer les échecs, d'identifier les modes de défaillance afin d'éviter les régressions et de capturer les modèles de réussite afin d'affiner les performances. En fin de compte, cette approche fondée sur les données est la clé de la transformation d'un prototype prometteur en un système d'IA fiable de qualité industrielle.

Security

Au fur et à mesure que les agents et les outils deviennent plus performants, la sécurité n'est plus facultative, elle est fondamentale. L'exposition des API, l'automatisation des tâches et des flux de travail exigent que les systèmes d'entreprise soient fiables. D'autant plus que les agents commencent à automatiser de plus en plus de flux de travail. Il est donc essentiel de pouvoir sécuriser ces flux et de s'assurer qu'ils répondent aux exigences de l'entreprise.

Les capacités ci-dessus héritent toutes des contrôles déjà disponibles dans Elastic aujourd'hui, y compris le contrôle d'accès basé sur les rôles (RBAC) pour les appels d'API et la gestion des clés d'API. Nous étendons également les mêmes contrôles à de nouveaux protocoles tels que le MCP. Cela signifie la prise en charge de normes telles que OAuth, ainsi que la possibilité d'intégrer des mécanismes d'authentification personnalisés.

Notre objectif est de vous donner la flexibilité nécessaire pour expérimenter des agents et des outils, tout en maintenant le niveau de sécurité, de conformité et de gouvernance exigé par votre organisation.

Ce qui vient ensuite

Nous ne nous contentons pas d'ajouter des fonctionnalités, nous développons Elasticsearch pour l'ingénierie contextuelle agentique. Nous prévoyons de poursuivre notre développement sur la base de ces principes :

1. Engagement en faveur des normes Open Source &

Notre engagement en faveur de l'open source et des normes ouvertes garantit que ces capacités restent interopérables avec les cadres agentiques externes. Vous serez toujours en mesure de connecter, d'étendre et de composer des agents à travers votre écosystème tout en gardant le contrôle de vos données et de vos flux de travail.

2. Valeur du contexte

Le contexte d'un agent d'intelligence artificielle est son plus grand atout. La gestion du contexte lorsque les agents effectuent des recherches et des opérations de flux de travail peut être une tâche difficile. Nous nous appuyons sur les points forts d'Elastic pour résoudre les problèmes d'ingénierie contextuelle, en veillant à ce que les informations les plus pertinentes soient toujours disponibles pour votre agent.

3. Focus sur les flux de données agentiques

À l'avenir, les agents constitueront une source de données de plus en plus importante, y compris les résultats des agents (documents générés, rapports, visualisations) et les traces d'exécution des agents (leur raisonnement, les appels d'outils, la mémoire/le contexte). Elastic est bien adapté au traitement de ce type de données, et nous travaillons sur la recherche concernant l'analyse, l'évaluation et l'amélioration automatisée de ces données.

4. Sécurité et sûreté dès la conception

Les agents d'intelligence artificielle posent de nouveaux défis en matière de sécurité et de sûreté. Elastic a toujours été un leader en matière de solutions sécurisées, et nous continuons à intégrer des garde-fous de niveau entreprise, des contrôles d'accès et les principes "zero-trust".

5. Intégré dans la plate-forme

Les capacités de création d'agents d'intelligence artificielle sont intégrées dans la plateforme Elasticsearch. Cela signifie que les capacités au niveau de la plateforme, telles que le traçage, l'évaluation, la visualisation et l'analyse, sont toutes applicables aux agents. Vous souhaitez développer des tableaux de bord basés sur les exécutions des agents - c'est intégré. Vous souhaitez évaluer les performances de l'agent d'IA à l'aide d'une analyse des sentiments - la plateforme le permet. Cela permet de construire un cycle de vie complet autour de vos expériences d'IA.

L'objectif d'Elastic est de vous donner les interfaces pour construire une IA conversationnelle et des flux de travail automatisés qui sont entièrement intégrés, extensibles et ancrés dans vos données. De plus amples détails techniques et des informations sur les progrès réalisés seront bientôt communiqués.

Agent Builder est disponible dès à présent en version privée. Connectez-vous avec nous pour demander l'accès. Vous avez des questions ou des commentaires ? Connectez-vous avec notre communauté de développeurs dans notre espace de travail Slack ou sur notre forum de discussion.

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 !