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

Un seul moteur pour tous les cas d'utilisation vectoriels

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

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

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

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

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

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

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

Indexation vectorielle avec le mode d’indexation vectordb_document

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

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

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

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

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

Stockage vectoriel, compression et optimisation automatique

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

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

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

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

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

Recherche hybride et recherche vectorielle filtrée

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

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

Entreprise dès le premier jour

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

Abordable à grande échelle et prévisible

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

Comment démarrer avec la base vectorielle Elasticsearch

Créez un projet de Base vectorielle sans serveur

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

Créer un index à l’aide de semantic_text

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

Ingérer des documents

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

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

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

Et vous obtenez des résultats :

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

Quelle est la suite pour la recherche vectorielle dans Elasticsearch

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

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

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

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

Essayez la base vectorielle Elasticsearch sur Elastic Cloud Serverless

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

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

Qu'est-ce que le rappel ?

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

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

Produits requis

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

Le code fourni utilise les éléments suivants :

• Elasticsearch 9.3+

• Python 3.10+

• Un fichier .env avec vos identifiants Elasticsearch

L’ensemble de données

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

Chaque document comporte quatre champs :

Champ

Type

`title`

Texte

description

Texte

marque

mot-clé

Catégorie

mot-clé

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

La puissance et les limites de la recherche lexicale

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

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

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

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

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

Les cas d’échec

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

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

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

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

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

Pourquoi il est conseillé de mesurer le rappel

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

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

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

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

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

Configuration de l'évaluation

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

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

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

Mesurer le rappel de référence du BM25

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

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

Voici le résultat.

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

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

Ajout de la recherche vectorielle avec les embeddings Jina

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

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

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

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

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

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

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

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

Étape 3 : indexer les produits

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

Recherche hybride : combinaison de BM25 et de vecteurs avec RRF

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

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

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

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

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

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

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

Voici le résultat.

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

Résultats : avant et après

Voici un comparatif complet des trois approches :

Voici le résultat.

Méthode

Recall@10

BM25 (Lexical)

0,43

Hybride (BM25 + vecteurs)

0,75

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

Conclusion

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

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

Étapes suivantes

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

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

• Consultez la documentation sur la recherche hybride avec Elasticsearch

• En savoir plus sur rank_evall’API

Comme nous l’avons vu dans l’article précédent, cette régularité, permise par l’appel de fonctions, constitue la pierre angulaire de la fiabilité du système, bien au-delà d’un simple gain d’efficacité. Une fois que nous avons éliminé les erreurs structurelles de la boucle d'évaluation, les résultats sur les scénarios standards (tels que ceux du jeu de données de niveau 4) se sont considérablement améliorés.

Il reste cependant une interrogation manifeste à laquelle il nous faut répondre :

Cette méthode est-elle toujours viable lorsque les données et les processus s’avèrent véritablement désordonnés ?

En pratique, ce ne sont pas les cas élémentaires qui mettent en défaut les systèmes de réconciliation d’entités. La résolution d’entités s’effondre dès que les noms se heurtent à la diversité des langues, des contextes culturels, des alphabets, des périodes historiques ou des structures administratives différentes. Le système s’effondre quand l’identification repose sur des titres honorifiques, des changements de noms de sociétés ou des translittérations aléatoires, et que seul le contexte environnant permet d’identifier l’entité physique derrière la mention textuelle.

Donc, pour le dernier billet de cette série, nous avons soumis le système à ce que nous avons appelé le défi ultime.

Qu’est-ce qui fait de ce test le « défi ultime » ?

Nous avons soumis le système à des tests progressifs, en employant des ensembles de données de plus en plus sophistiqués au fil des étapes de validation. Au moment d’atteindre le palier 4, le système gérait déjà des données hybrides mêlant appellations familières, titres honorifiques et variantes linguistiques, exigeant une analyse contextuelle fine. Les tests ont prouvé la pertinence de l’architecture globale, tout en révélant que des erreurs de structure de données, comme des syntaxes JSON incorrectes, bridaient artificiellement les performances de récupération.

Avec les appels de fonctions en place, nous avions enfin une base stable. Cela nous a donné l'occasion de poser une question plus intéressante :

Un pipeline unifié peut-il gérer plusieurs types de problèmes de résolution d'entités simultanément ?

Cet ensemble de données de test a été élaboré spécifiquement pour mettre à l’épreuve cette variable critique, en ne laissant aucune place à l’approximation.

Au lieu de se concentrer sur une seule difficulté (comme les surnoms ou la translittération), cet ensemble de données combine plus de 50 types de défis distincts, notamment :

• Conventions de dénomination culturelles.

• Références basées sur les titres.

• Relations commerciales et changements historiques de nom.

• Mentions multilingues et systèmes d’écriture croisés.

• Des défis complexes qui combinent plusieurs des éléments ci-dessus.

L'essentiel, ce n'est pas d'optimiser pour un cas d'utilisation restreint. Il s'agit de vérifier si le modèle de conception tient la route lorsque les règles changent d'une entité à l'autre.

L'ensemble de données en un coup d’œil

L'ensemble de données du défi ultime consiste en :

• 50 entités, couvrant des personnes, des organisations et des institutions.

• ~60 articles, dont la structure et la complexité linguistique varient.

• 51 catégories de défis distinctes, regroupées globalement en :

  • Conventions de dénomination culturelles.

  • Titres et contexte professionnel.

  • Relations commerciales et organisationnelles.

  • Les défis du multilinguisme et de la translittération.

  • Scénarios combinés et cas limites.

Plus tôt dans cette série, nous avons vu que l’utilisation de l’IA générative (GenAI) pour créer des jeux de données peut s’avérer être une arme à double tranchant. Sans elle, il serait extrêmement difficile de rassembler des données de test suffisamment vastes et diversifiées. Toutefois, sans un contrôle rigoureux, le modèle incline naturellement vers la simplification des cas de test.

On a remarqué, lors d’un premier passage de génération, que l’IA avait inséré des mentions telles que « le président russe » comme synonymes directs dans la fiche d’identité de Vladimir Poutine. Bien que cela paraisse logique à première vue, une telle approche invalide le test en supprimant la nécessité de comprendre le contexte pour identifier l’entité. Que se passe-t-il si l’article traite de la Russie des années 1990 ? L’objectif est que l’intelligence du moteur réside dans sa capacité d’inférence contextuelle plutôt que dans une simple table de correspondance statique.

C'est pourquoi cet ensemble de données a été délibérément conçu pour que les raccourcis ne fonctionnent pas. Les alias ne sont pas explicitement énumérés lorsque le système est censé en déduire la signification. Les phrases descriptives ne sont pas pré-liées à des entités. Les bonnes correspondances dépendent souvent du contexte de l'article, et pas seulement du texte local.

Remarque importante : bien que nous démontrions les capacités du système dans divers scénarios, il s'agit toujours d'un prototype éducatif. Les systèmes de production gérant la surveillance d'entités sanctionnées dans le monde réel nécessiteraient une validation supplémentaire, des contrôles de conformité, des pistes d'audit et une gestion spécialisée pour les cas d'utilisation sensibles.

Pourquoi ces scénarios sont difficiles

Dès le premier article de cette série, nous avons introduit un exemple simple mais ambigu : « La nouvelle mise à jour de Swift est arrivée ! » Le défi réside dans le fait que « Swift » peut renvoyer à plusieurs entités du monde réel, selon le contexte. Cet exemple illustre une vérité plus profonde : le langage naturel est intrinsèquement ambigu.

La résolution d’entités n’est donc pas seulement un problème de correspondance de chaînes de caractères. Nous utilisons instinctivement notre bagage culturel et le contexte immédiat pour interpréter les références, une opération mentale si fluide qu’elle nous semble totalement naturelle.

Voici quelques cas courants :

• L’expression « le président » est une coquille vide si elle n’est pas ancrée dans une géographie et une époque données.

• Le nom d’une entreprise peut désigner une société mère, une filiale ou une ancienne marque, selon la date à laquelle l’article a été rédigé.

• Le nom d’une personne peut apparaître dans des ordres différents, des alphabets variés ou des translittérations diverses, selon la langue et la culture.

• La même phrase peut légitimement faire référence à des entités différentes dans des contextes différents, et le système doit être en mesure de rejeter les correspondances avec autant d'assurance qu'il les accepte.

Aucun système de règles figées ne peut, à lui seul, traiter l’intégralité de ces nuances de manière satisfaisante. Cette approche explique pourquoi ce prototype applique une séparation des préoccupations aussi stricte :

• Elasticsearch réduit l'espace réservé aux candidats de manière efficace et transparente.

• Le LLM n’est utilisé que là où un jugement est requis, et il est contraint de justifier sa décision.

• La récupération et le raisonnement demeurent des étapes distinctes.

Cette distinction devient encore plus importante à mesure que la diversité des types de défis augmente.

Comment le système gère la diversité sans recourir à des cas particuliers

L'un des résultats les plus intéressants de cette évaluation est ce qui n’a pas changé :

• Nous n'avons pas ajouté de logique spéciale pour les noms japonais.

• Nous n'avons pas ajouté de règles personnalisées pour les patronymes arabes.

• Nous n'avons pas ajouté de mapping codé en dur pour les noms d'entreprises historiques.

À la place, le système s’est appuyé sur les mêmes ingrédients fondamentaux présentés plus tôt dans cette série :

• Entités enrichies par le contexte et indexées pour la recherche sémantique.

• La récupération hybride (exacte, alias et sémantique) dans Elasticsearch.

• Un ensemble restreint et bien défini de candidats.

• Le jugement du LLM est contraint par l’appel de fonctions et des schémas minimaux.

Cela suggère que la flexibilité du système provient de la représentation et de l'architecture, et non d'une collection de règles qui ne cesse de croître.

Lorsque le système réussit, c’est parce que les bons candidats ont été récupérés et que le LLM dispose d’assez de contexte pour expliquer pourquoi une référence correspond (ou non) à une entité spécifique.

Résultats : Comment s’est-il comporté ?

Sur l’ensemble de données du défi ultime, le système a produit les résultats globaux suivants :

• Précision : ~91 %

• Rappel : ~86 %

• Score F1 : ~89 %

• Taux d'acceptation des LLM : ~72 %

Performances selon les types de défis

L’analyse des résultats par type de défi révèle des forces et des limites bien précises :

Les performances les plus solides (un score F1 de 100 %) ont été observées dans des domaines tels que :

• Appariement entre différents systèmes d’écriture (entités commerciales en cyrillique, coréen ou chinois).

• Scénarios en hébreu (patronymes, titres professionnels, titres religieux, translittération).

• Hiérarchies d’entreprises (aérospatiale, industrie diversifiée, conglomérats multidivisionnels).

• Titres professionnels (académiques, militaires, politiques, religieux).

• Scénarios japonais combinés impliquant plusieurs systèmes d'écriture.

Une performance solide (score F1 de 80 à 99 %) a été enregistrée dans les catégories suivantes :

• Personnalités politiques internationales (98 %).

• Changements de noms historiques (90 %).

• Hiérarchies d’entreprise complexes (89 %).

• Noms de sociétés japonais (93 %).

• Translittération entre différents systèmes d’écriture (86 %).

• Patronymes arabes (86 %).

Les domaines les plus difficiles sont les suivants :

• Translittération avancée (chinois, coréen) : 0 % F1.

• Certains scénarios japonais (titres honorifiques, ordre des noms, variations du système d’écriture) : ~67 % F1.

• Quelques scénarios en arabe (noms d'entreprises, références institutionnelles) : ~40 % F1.

Ce qui importe ici, c’est de comprendre pourquoi le système a éprouvé des difficultés dans ces cas précis. Les échecs n’étaient pas dus à une défaillance de l’approche globale, mais à des limitations de composants spécifiques, tout particulièrement le modèle de vecteurs denses utilisé pour la recherche sémantique dans certains scénarios multilingues.

La recherche et le jugement étant clairement séparés, il n’est pas nécessaire de réécrire le système pour améliorer les performances. L’intégration d’un modèle d’embedding multilingue plus performant, l’enrichissement du contexte des entités ou l’affinement des stratégies de récupération amélioreraient les résultats dans ces catégories sans modifier l’architecture de noyau.

Du point de vue architectural, c’est le véritable indicateur de réussite.

Ce que ces résultats nous révèlent sur l'architecture du système

Si l'on considère l'ensemble de la série, quelques tendances se dégagent :

• La préparation est plus importante qu'une combinaison intelligente. L’enrichissement des entités avec leur contexte dès le départ réduit considérablement l’ambiguïté par la suite.

• Les LLM sont bien plus précieux en tant que juges qu’en tant qu’outils de recherche. Leur demander d'expliquer pourquoi une correspondance est logique est bien plus efficace que de leur demander de rechercher.

• La fiabilité permet la précision. L'appel de fonction n'a pas seulement nettoyé le JSON ; il a débloqué la récupération qui était déjà latente dans l'étape de récupération.

• La généralisation l’emporte sur la spécialisation. Un petit nombre d’abstractions bien choisies a permis de gérer des dizaines de types de défis sans avoir recours à une logique personnalisée.

Cette approche explique pourquoi le prototype s’appuie nativement sur Elasticsearch tout en limitant l’usage des modèles de langage à une stricte nécessité. L’objectif n’est pas de se substituer aux moteurs de recherche classiques, mais d’apporter une couche d’explication quand la compréhension du contexte est cruciale.

Conclusions

L’enjeu final n’était pas d’atteindre des statistiques idéales, mais de s’attaquer à une interrogation bien plus essentielle :

Une architecture transparente, axée sur rechercher et assistée par LLM, peut-elle gérer l'ambiguïté des entités du monde réel sans s'effondrer en règles ou en boîtes noires ?

Pour ce prototype pédagogique, la réponse est oui, avec des réserves explicites concernant la mise en production, la conformité, la surveillance et la qualité des données. Si vous concevez des systèmes devant justifier pourquoi une correspondance d’entités a été établie, ce modèle mérite une attention toute particulière. J’espère que cette série de publications a démontré que la résolution d’entités n’a rien d’un processus mystérieux. Avec une séparation adéquate des responsabilités, la résolution d’entités devient un processus que l’on peut analyser, mesurer et améliorer.

Ce travail suggère également un modèle d’architecture plus large. On voit apparaître ici un glissement méthodologique important par rapport à l’architecture RAG classique. Au lieu de laisser la recherche alimenter directement la génération, nous introduisons une étape d’évaluation explicite. Le LLM est d’abord utilisé pour juger et vérifier la pertinence des candidats récupérés, et seuls les résultats approuvés sont autorisés à enrichir la génération. Vous pouvez voir cela comme un « Generation-Augmented Retrieval-Augmented Generation with Evaluation », ou GARAGE, parce que tout le monde adore les bons acronymes.

Quels autres cas d'utilisation pourraient bénéficier de ce modèle ? Les systèmes exigeant de la confiance, de la transparence et un raisonnement défendable sont des candidats naturels pour ce modèle. Les travaux futurs dans ce domaine s’annoncent tout aussi passionnants que les résultats présentés ici, et j’ai hâte de voir comment la communauté s’en emparera pour la suite.

Prochaines étapes : À vous de jouer

Envie de voir comment ce système relève le défi le plus complexe ? Consultez le carnet de notes Ultimate Challenge pour une présentation complète avec des implémentations réelles, des explications détaillées et des exemples pratiques.

Le pipeline complet de résolution d'entités démontre les concepts fondamentaux et l'architecture nécessaires à une utilisation en production. Cette structure sert de fondation pour bâtir des outils de veille médiatique capables d’identifier des entités et de justifier chaque correspondance, garantissant ainsi la traçabilité des informations extraites.

1. La nouvelle mise à jour de Swift est arrivée ! Les développeurs sont impatients de tester les nouvelles fonctionnalités.

2. La nouvelle mise à jour de Swift est arrivée ! Le nouvel album sortira le mois prochain.

Avec ce contexte supplémentaire, nous devrions être en mesure d’associer le nom « Swift » à la bonne entité.

Dans l'article précédent, nous avons constitué notre liste de surveillance et enrichi les entités avec un contexte supplémentaire. En reprenant nos exemples ci-dessus, nous devons disposer au minimum des deux entités suivantes dans la liste : Taylor Swift et le langage de programmation Swift. Nous avons également expliqué comment extraire les mentions d’entités à partir d’un texte. Dans ces deux exemples, la mention extraite serait « Swift ». Avec ces éléments en place — la liste de surveillance enrichie et les entités extraites — nous sommes enfin prêts à introduire la vedette du moment : la mise en correspondance des entités.

Rappel : il s’agit d’un prototype pédagogique conçu pour illustrer les concepts de mise en correspondance d’entités. En production, les systèmes peuvent utiliser différents grands modèles de langage (LLM), des règles de correspondance personnalisées, des pipelines d’évaluation spécialisés ou encore des approches d’ensemble combinant plusieurs stratégies de correspondance.

Le problème : pourquoi la mise en correspondance est complexe

Le langage humain est une chose remarquable. L’une de ses caractéristiques les plus intéressantes est sa créativité sans fin. Nous pouvons générer et comprendre un nombre infini de nouvelles phrases. Dès lors, est-il surprenant que les correspondances exactes soient rares en résolution d’entités ? Les auteurs s’efforcent d’être créatifs dès qu’ils le peuvent. Il serait vite fastidieux de devoir écrire et lire les noms complets chaque fois qu’une entité est mentionnée. Ainsi, si les correspondances exactes sont simples, la réalité est que nous avons besoin d’une approche plus sophistiquée de la résolution d’entités : une approche suffisamment robuste pour gérer au moins une partie de la créativité sans limite des auteurs humains. C’est pourquoi nous décomposons le problème en deux étapes : utiliser Elasticsearch pour récupérer des candidats plausibles à grande échelle, puis recourir à un LLM pour déterminer si ces candidats renvoient réellement à la même entité du monde réel.

La solution : une mise en correspondance en trois étapes avec un jugement LLM transparent

Nous vivons un changement de paradigme dans notre manière d’utiliser les ordinateurs. Tout comme l’essor d’Internet nous a fait passer d’une informatique localisée à un réseau mondialement connecté, l’IA générative transforme en profondeur la façon dont le contenu, le code et l’information sont créés. En réalité, le prototype pédagogique qui accompagne cette série a été presque entièrement « vibe codé » à l’aide d’un LLM, avec des instructions soigneusement rédigées par l’auteur. Cela ne signifie pas que les LLM atteignent — ou atteindront — le niveau de productivité propre au langage humain, mais cela veut dire que nous disposons désormais d’une ressource puissante pour faciliter la résolution d’entités.

Un schéma courant avec l'IA générative est la génération augmentée par récupération (RAG). Ici, récupération signifie que l’on récupère des candidats d’entités (et non que l’on génère des réponses), et que le LLM est utilisé exclusivement pour évaluer les correspondances et en expliquer la logique. Bien que je puisse demander à un LLM de prendre en charge l’ensemble du processus de résolution d’entités, de bout en bout, cette approche serait coûteuse, tant en temps qu’en ressources financières. La RAG aide les LLM à accomplir leur tâche en leur fournissant du contexte de manière plus efficace, ce qui leur permet de contribuer plus efficacement à la résolution d’entités.

Pour la partie récupération de la RAG, nous faisons à nouveau appel à Elasticsearch. Nous identifions d’abord des correspondances potentielles en combinant la correspondance exacte, la correspondance sur des alias et la recherche hybride, qui associe recherche par mots-clés et recherche sémantique. Une fois ces correspondances potentielles identifiées, nous les transmettons à un LLM pour évaluation. Le LLM agit comme évaluateur final des correspondances. Nous demandons également au LLM d’expliquer son raisonnement, un élément différenciant important par rapport à d’autres systèmes de résolution d’entités. Sans ces explications, la résolution d’entités reste une boîte noire ; avec elles, nous pouvons comprendre pourquoi une correspondance est pertinente.

Concepts clés : mise en correspondance en trois étapes, recherche hybride et jugement LLM transparent

Qu’est-ce que la mise en correspondance en trois étapes ? Au début de ce projet, nous avons émis l’hypothèse que la recherche sémantique jouerait un rôle clé dans le système, mais toutes les correspondances ne nécessitent pas un niveau de recherche aussi sophistiqué. Afin de trouver des correspondances efficacement, nous adoptons une approche progressive du problème. Tout d’abord, nous vérifions les correspondances exactes à l’aide de la recherche par mots-clés. Si nous trouvons une telle correspondance, le travail est terminé et nous pouvons passer à l’étape suivante. Si la correspondance exacte échoue, nous passons à la correspondance par alias. Dans le prototype, la correspondance par alias est également effectuée à l’aide d’une correspondance exacte sur des mots-clés, par souci de simplicité. En production, cette étape peut être enrichie par des règles de normalisation, de translittération, de correspondance approximative (fuzzy matching) ou par des tables d’alias maintenues. Si, après ces deux premières étapes, aucune correspondance potentielle n’a été trouvée, nous faisons appel à la recherche sémantique via la recherche hybride d’Elasticsearch, utilisant la méthode Reciprocal Rank Fusion (RRF).

Qu’est-ce que la recherche hybride ? Dans Elasticsearch, nous pouvons utiliser la recherche sémantique pour identifier des correspondances pertinentes en tenant compte du contexte. Elasticsearch est largement utilisé pour la recherche vectorielle et la récupération hybride. La similarité sémantique est puissante pour capter le sens, mais elle ne remplace pas le filtrage structuré (par exemple, par plages temporelles, emplacements ou identifiants). Elle est souvent inutile lorsqu’une correspondance exacte est disponible. Elasticsearch s’est d’abord imposé grâce à la recherche lexicale, particulièrement efficace lorsque la recherche sémantique n’est pas adaptée. Pour tirer pleinement parti des deux approches, nous combinons la recherche lexicale et la recherche sémantique au sein d’une requête hybride unique. Nous fusionnons ensuite les résultats afin d’identifier les correspondances les plus probables à l’aide de la méthode RRF. Dans le prototype, les deux premiers résultats deviennent des correspondances potentielles pouvant être soumises à l’évaluation du LLM.

Pourquoi faire appel au jugement LLM ? Les jugements et explications fournis par le LLM permettent à notre système de gérer l’ambiguïté et le contexte de manière transparente. C’est essentiel pour des cas comme « le président », qui peut désigner plusieurs entités selon le contexte. Cela permet également de gérer efficacement les surnoms et les variations culturelles. Enfin, lorsque nous traitons des tâches critiques — comme l’identification d’entités figurant sur des listes de sanctions — il est indispensable de comprendre pourquoi une correspondance a été acceptée afin de pouvoir faire confiance au système. Point essentiel : le LLM ne parcourt pas l’intégralité du corpus. Il évalue uniquement le petit ensemble de candidats renvoyé par Elasticsearch.

Résultats concrets : mise en correspondance avec raisonnement du LLM

Un défi majeur pour toute tâche de traitement automatique du langage naturel est la création d’un document de référence, une « answer key » indiquant quels sont les résultats attendus. Sans cela, il est quasiment impossible d’évaluer la performance d’un système sur une tâche donnée. Or, la création d’un tel document peut s’avérer laborieuse. Pour le prototype de résolution d’entités, nous avons de nouveau fait appel à l'IA générative afin de générer des données sur lesquelles nous pourrions effectuer des tests.

Nous avons d’abord défini plusieurs types de défis, comme les surnoms et la translittération, puis demandé au LLM de créer une collection hiérarchisée de jeux de données, devenant progressivement plus volumineux et plus complexes pour le système. La création des jeux de données s’est révélée moins simple qu’on aurait pu l’espérer. Le LLM avait une forte tendance à « tricher » en rendant la bonne réponse trop facile à trouver. Par exemple, l’un des types de défis portait sur le contexte sémantique. Ce type incluait des cas tels que faire correspondre « auteur russe » à « Leo Tolstoy ». Le LLM a incorrectement défini « auteur russe » comme un alias de « Leo Tolstoy », ce qui supprimait la nécessité d’une recherche hybride pour identifier la correspondance.

Après plusieurs refactorisations pour corriger ce type de problèmes, nous disposions de cinq niveaux d’ensembles de données. Les niveaux 1 à 4 devenaient progressivement plus volumineux et intégraient davantage de types de défis. Le niveau 5 constituait le « défi ultime », composé des exemples les plus complexes issus de tous les types de défis. L’ensemble des données de test est disponible dans un répertoire d’évaluation complet.

Pour évaluer notre approche de résolution d’entités basée sur des prompts, nous avons concentré notre analyse sur le jeu de données de niveau 4. Il est important de noter que l’évaluation a été menée dans le cadre d’une expérience contrôlée afin de nous concentrer sur la qualité de mise en correspondance des entités. Les données de la liste de correspondances ont été préalablement enrichies avec du contexte, et les entités ont été extraites de l’article en amont. Cela a permis de s’assurer que l’évaluation se concentrait sur la correspondance plutôt que sur la précision de l’extraction. Cela isole la qualité de correspondance ; les performances de bout en bout dépendraient en outre du rappel d'extraction et de la qualité d'enrichissement.

Ensemble de données d’évaluation

L'ensemble de données d'évaluation de niveau 4 fournit un test complet des capacités du système : [1]

• Entités de la liste de surveillance : 66 entités couvrant différents types (personnes, organisations, lieux).

• Articles de test : 69 articles couvrant des scénarios réels de résolution d’entités.

• Correspondances attendues : 206 correspondances attendues pour l'ensemble des articles.

• Types de défis : 15 types de défis différents mettant à l'épreuve divers aspects de la résolution d'entités.

Les types de défis inclus dans l’ensemble de données sont les suivants :

• Surnoms : « Bob Smith » → « Robert Smith » (sept articles).

• Titres et titres honorifiques : « Dr. » Sarah Williams » → « Sarah Williams » (cinq articles).

• Contexte sémantique : « auteur russe » → « Leo Tolstoy » (huit articles).

• Noms multilingues : traitement des noms dans différentes écritures (six articles).

• Entités commerciales : variations de noms d’entreprises (sept articles).

• Références exécutives : « PDG de Microsoft » → « Satya Nadella » (cinq articles).

• Dirigeants politiques : références basées sur un titre (cinq articles).

• Initiales : « J. Smith » → « John Smith » (trois articles).

• Variations dans l’ordre des noms : différentes conventions d’ordre des noms (trois articles).

• Noms tronqués : correspondances partielles de noms (trois articles).

• Découpage des noms : noms séparés dans le texte (trois articles).

• Espaces ou tirets manquants : variations de mise en forme (deux articles).

• Translittération : correspondance de noms entre différents systèmes d’écriture (deux articles).

• Défis combinés : plusieurs défis dans un même article (six articles).

• Cas d’entreprise complexes : relations hiérarchiques entre entités commerciales (cinq articles).

Examinons comment la résolution d’entités basée sur des prompts s’est comportée.

Performance globale

Les résultats montrent un fort potentiel pour l’évaluation des correspondances assistée par LLM, mais ils mettent également en évidence un problème significatif de fiabilité. Chaque paire candidate doit être évaluée par le LLM. Des erreurs dans la sortie structurée peuvent réduire la précision et le rappel, même lorsque la phase de récupération fonctionne correctement.

Métrique

Valeur

Précision

83,8 %

Rappel

62,6 %

Score F1

71,7 %

Nombre total de correspondances trouvées

344

Taux d'acceptation des LLM

44,8 %

Taux d'erreur

30,2 %

Le problème du taux d'erreur

Rappelons que la première étape du prototype consiste à créer des paires de correspondances potentielles à l’aide d’Elasticsearch. Chacune de ces correspondances potentielles doit ensuite être évaluée par le LLM. Pour traiter efficacement l’ensemble de ces correspondances, nous regroupons les appels au LLM par lots. Cela réduit les coûts d’API et la latence, mais augmente également le risque d’obtenir un JSON mal formé en sortie. À mesure que la taille des lots augmente, le JSON devient plus long et plus complexe, ce qui accroît la probabilité que le LLM génère un JSON invalide. C’est de là que provient le taux d’erreur de 30 %. Dans cette évaluation, nous avons utilisé une taille de lot de cinq correspondances par requête. Même avec cette taille de lot conservatrice, nous constatons toujours des échecs d'analyse JSON, ce qui fausse considérablement les résultats de l'évaluation.

Prochaine étape : optimiser l’intégration des LLM

Maintenant que nous avons mis en correspondance des entités à l’aide de la recherche sémantique et du jugement d’un LLM, nous disposons d’un pipeline complet de résolution d’entités. Cependant, cette approche introduit un nouveau mode de défaillance : le jugement du modèle peut être correct, mais sa sortie inutilisable. Nous pouvons optimiser l’intégration du LLM afin d’améliorer la fiabilité et la rentabilité. Dans le prochain article, nous verrons comment utiliser le function calling pour produire une sortie structurée, garantissant une structure et un typage sûrs, tout en réduisant les erreurs et les coûts.

Essayez par vous-même

Envie de voir la mise en correspondance d’entités en action ? Consultez le carnet de notes sur l'appariement des entités pour une présentation complète avec des implémentations réelles, des explications détaillées et des exemples pratiques. Le carnet vous montre exactement comment faire correspondre les entités à l'aide de la recherche en trois étapes, de la recherche hybride avec RRF et du jugement raisonné basé sur le LLM.

Rappel : il s’agit d’un prototype pédagogique conçu pour illustrer les concepts. Lors de la mise en œuvre d’un système en production, tenez compte de facteurs supplémentaires tels que la sélection du modèle, l’optimisation des coûts, les exigences en matière de latence, la validation de la qualité, la gestion des erreurs et la supervision — des aspects qui ne sont pas couverts dans ce prototype à visée pédagogique.

Remarques

1. Ces ensembles de données sont synthétiques et conçus à des fins pédagogiques. Ils reflètent des défis réels, mais ne représentent aucun domaine de production spécifique.

Dans cet article, vous apprendrez comment utiliser le paramètre de score minimum pour augmenter la précision de vos résultats de recherche sémantique. Si vous souhaitez tester les exemples fournis dans cet article de blog, accédez au notebook Jupyter associé.

Contexte : précision et rappel

En matière de pertinence de recherche, la précision et le rappel sont des concepts clés. Nous encourageons vivement les lecteurs qui ne les connaissent pas encore à se familiariser avec ces concepts. Voici un résumé.

• Précision : la fraction des résultats de recherche renvoyés qui sont pertinents pour l'utilisateur.

• Rappel : la fraction de tous les documents pertinents du corpus inclus dans l'ensemble des résultats de recherche.

En d'autres termes, la précision consiste à ne renvoyer que les résultats pertinents, tandis que le rappel consiste à renvoyer tous les résultats pertinents. Comme vous pouvez l'imaginer, ces deux exigences sont souvent contradictoires. La recherche sémantique a généralement un rappel très élevé, mais peut être à la peine en termes de précision. Poursuivez votre lecture pour découvrir comment contourner ce problème.

Présentation du paramètre de score minimum

Le paramètre "min_score" nous permet d'améliorer la précision en fixant un score minimum, ce qui tronquera le résultat en supprimant toutes les correspondances dont le score est inférieur au seuil défini. Voici un exemple simple :

Normalisation du score

Définir un score minimum est une bonne chose ; cependant, tous les modèles sémantiques ne renvoient pas un score adapté à un seuil statique. ELSER, par exemple, renvoie un score qui n'est pas limité. Certains scores de modèles denses sont fortement regroupés et n'ont de sens que dans le contexte de la requête spécifique.

Pour la plupart des cas de recherche sémantique, nous recommandons d'utiliser une approche de normalisation avant d'appliquer le "min_score". La normalisation garantit que le score du document se situe dans un intervalle défini. Les extracteurs Elasticsearch proposent deux normalisateurs de ce type, "l2_norm" et "minmax". Le plus couramment utilisé est "minmax", car il est facile à comprendre et fonctionne bien dans de nombreux scénarios. Voici les principales propriétés de "minmax" :

• Les scores des documents sont distribués entre 0 et 1.

• Le document ayant le score le plus élevé est toujours noté 1.

• Le document ayant obtenu le score le plus bas est toujours noté 0.

  • Cela peut le rendre moins adapté à la recherche par mots-clés. Voir la section "Recherche hybride" pour plus de détails.

Voici un exemple de requête sémantique normalisée avec min_score. La taille de la fenêtre de classement a été augmentée à 500 pour nous permettre de renvoyer une liste plus longue de résultats de recherche, en commençant à 100.

La taille a été définie sur une valeur plus élevée que celle habituellement observée en production. Cela nous permet de contrôler la qualité des résultats de recherche et de les optimiser.

Recherche hybride utilisant l'extracteur linéaire

Pour la recherche hybride, l'approche la plus simple consiste à normaliser tous les scores, à leur attribuer des pondérations et à appliquer un score minimal. Notez qu'en choisissant des pondérations dont la somme est égale à 1, le score total reste compris entre 0 et 1. Cela facilite l'interprétation des scores finaux et l'ajustement de min_score. Voici un exemple :

Recherche hybride à l'aide de la RRF

Avec le BM25, nous contrôlons souvent la précision par d'autres moyens, par exemple en utilisant l'opérateur AND ou minimum_should_match. De plus, les requêtes composées de termes uniques, précis et rares entraîneront naturellement des résultats de recherche peu nombreux, souvent tous très pertinents. Cela peut causer les problèmes suivants :

• Les résultats situés plus loin dans le classement reçoivent un score normalisé faible dans l'extracteur BM25, même si le score BM25 absolu est proche des meilleurs résultats.

• Si l'on ajoute un score BM25 très faible au score sémantique, le total peut être considéré comme le score sémantique.

• L'absence de contribution au score BM25 peut entraîner la suppression du document par le min_score threshold.

Comme solution, nous pouvons plutôt utiliser la fusion des rangs réciproques (RRF) pour combiner les résultats BM25 et sémantiques. RRF contourne la difficulté de comparer les scores de différents algorithmes de recherche en se concentrant plutôt sur la position dans chaque ensemble de résultats. Dans ce scénario, le min_score est uniquement appliqué à l'extracteur sémantique.

Conclusion

En utilisant min_score, nous avons montré comment réduire le nombre de faux positifs dans nos ensembles de résultats causés par le fort rappel des algorithmes de recherche sémantique. Pour en savoir plus sur les extracteurs, veuillez consulter cet article de blog et la documentation d'Elasticsearch.

Les connecteurs personnalisés vous donnent la possibilité de combiner vos connecteurs ChatGPT existants avec des sources de données supplémentaires comme Elasticsearch pour obtenir des réponses complètes.

Dans cet article, nous allons créer un serveur MCP qui connecte ChatGPT à un index Elasticsearch contenant des informations sur les issues GitHub internes et les requêtes pull. Cela permet de répondre aux requêtes en langage naturel en utilisant vos données Elasticsearch.

Nous déploierons le serveur MCP en utilisant FastMCP sur Google Colab avec ngrok pour obtenir une URL publique à laquelle ChatGPT peut se connecter, éliminant ainsi le besoin d'une configuration complexe de l'infrastructure.

Pour un aperçu complet de MCP et de son écosystème, reportez-vous à la section État actuel du MCP.

Prérequis

Avant de commencer, vous aurez besoin des éléments suivants :

• Cluster Elasticsearch (8.X ou supérieur)

• Clé API Elasticsearch avec accès en lecture à votre index

• Compte Google (pour Google Colab)

• Compte ngrok (fonctionne avec le niveau gratuit)

• Compte ChatGPT avec un forfait Pro/Entreprise/Business ou Edu

Comprendre les exigences du connecteur ChatGPT MCP

Les connecteurs ChatGPT MCP nécessitent l'implémentation de deux outils : search et fetch. Pour plus de détails, consultez OpenAI Docs.

Outil de recherche

Renvoie une liste de résultats pertinents depuis votre index Elasticsearch en fonction d'une requête utilisateur.

Ce qu'il reçoit :

• Une chaîne unique contenant la requête en langage naturel de l'utilisateur.

• Exemple : "Recherchez les issues liées à la migration d'Elasticsearch."

Ce qu'il renvoie : 

• Un objet avec une clé result contenant un tableau d'objets de résultats. Chaque résultat inclut :

  • id - Identifiant de document unique

  • title - Titre de l'issue ou de la PR

  • url - Lien vers l'issue/la PR

Dans notre implémentation :

Outil de récupération

Récupère le contenu complet d'un document spécifique.

Ce qu'il reçoit :

• Chaîne unique contenant l'ID du document Elasticsearch extrait du résultat de la recherche

• Exemple : "Donnez-moi les détails de la PR-578."

Ce qu'il renvoie :

• Objet de document complet contenant :

  • id - Identifiant de document unique

  • title - Titre de l'issue ou de la PR

  • text - Description complète du problème/PR et détails

  • url - Lien vers l'issue/la PR

  • type - Type de document (issue, pull_request)

  • status - Statut actuel (ouvert, en cours, résolu)

  • priority - Niveau de priorité (faible, moyen, élevé, critique)

  • assignee - Personne en charge de l'issue/la PR

  • created_date - Date de création

  • resolved_date - Date de résolution (le cas échéant)

  • labels - Balises associées au document

  • related_pr - ID de la requête pull associée

Remarque : Cet exemple utilise une structure plate où tous les champs se trouvent au niveau racine. Les exigences d'OpenAI sont flexibles et prennent également en charge les objets de métadonnées imbriqués.

Issues GitHub et ensemble de données de PR

Pour ce tutoriel, nous allons utiliser un ensemble de données interne de GitHub contenant des issues et des requêtes pull. Ceci représente un scénario dans lequel vous souhaitez interroger des données privées et internes via ChatGPT.

L'ensemble de données est accessible ici. Et nous mettrons à jour l'index des données à l'aide de l'API Bulk.

Cet ensemble de données comprend :

• Issues avec description, état, niveau de priorité et personnes en charge

• Requêtes pull avec modifications de code, révisions et informations de déploiement

• Relations entre les issues et les PR (p. ex., la PR-578 corrige l'ISSUE-1889)

• Étiquettes, dates et autres métadonnées

Mappings de l'index

L'index utilise les mappings suivants pour prendre en charge la recherche hybride avec ELSER. Le champ text_semantic est utilisé pour la recherche sémantique, tandis que les autres champs permettent la recherche par mot-clé.

Créer le serveur MCP

Notre serveur MCP implémente deux outils conformes aux spécifications d'OpenAI qui utilisent la recherche hybride pour combiner la sémantique et la correspondance de texte pour de meilleurs résultats.

Outil de recherche

Utilise la recherche hybride avec RRF (fusion des rangs réciproques) qui combine la recherche sémantique avec la correspondance de texte :

Points clés :

• Recherche hybride avec RRF : combine la recherche sémantique (ELSER) et la recherche de texte (BM25) pour de meilleurs résultats.

• Requête à correspondance multiple : Recherches sur plusieurs champs avec boosting (title^3, text^2, assignee^2). Le symbole caret (^) multiplie les scores de pertinence, en privilégiant les correspondances dans les titres plutôt que dans le contenu.

• Fuzzy matching (correspondance approximative) : fuzziness: AUTO gère les fautes de frappe et d'orthographe en autorisant les correspondances approximatives.

• Ajustement des paramètres RRF :

  • rank_window_size: 50 - Spécifie le nombre de résultats principaux de chaque récupérateur (sémantique et texte) pris en compte avant la fusion.

  • rank_constant: 60 - Cette valeur détermine l'influence des documents dans chaque ensemble de résultats sur le classement final.

• Ne renvoie que les champs obligatoires : id, title, url conformément à la spécification d'OpenAI, et évite d'exposer inutilement des champs supplémentaires.

Outil de récupération

Récupère les détails du document par ID de document, s'il existe :

Points clés :

• Recherche par champ d'ID de document : utilise une requête de terme sur le champ personnalisé id

• Renvoie le document complet : inclut le champ complet text avec tout le contenu

• Structure plate : tous les champs au niveau racine, correspondant à la structure de document d'Elasticsearch.

Déployer sur Google Colab

Nous utiliserons Google Colab pour exécuter notre serveur MCP et ngrok pour l'exposer publiquement afin que ChatGPT puisse s'y connecter.

Étape 1 : Ouvrir le notebook Google Colab

Accédez à notre notebook préconfiguré Elasticsearch MCP pour ChatGPT.

Étape 2 : Configurer vos identifiants

Vous aurez besoin de trois informations :

• URL Elasticsearch : l'URL de votre cluster Elasticsearch.

• Clé API Elasticsearch : clé API avec accès en lecture à votre index.

• Jeton d'authentification ngrok : jeton gratuit fourni par ngrok. Nous utiliserons ngrok pour exposer l'URL du MCP à l'Internet afin que ChatGPT puisse s'y connecter.

Obtenir votre token ngrok

1. Créez un compte gratuit sur ngrok

2. Accédez à votre tableau de bord ngrok

3. Copier votre jeton d'authentification

Ajouter des secrets à Google Colab

Dans le notebook Google Colab :

1. Cliquez sur l'icône clé dans la barre latérale gauche pour ouvrir Secrets.

2. Ajoutez ces trois secrets :

3. Activer l'accès aux notebooks pour chaque secret

Étape 3 : Exécuter le notebook

1. Cliquez sur Runtime (Exécution) puis sur Run all (Tout exécuter) pour exécuter toutes les cellules

2. Attendez que le serveur démarre (environ 30 secondes)

3. Recherchez l'URL publique de ngrok dans la sortie

4. La sortie affichera quelque chose comme :

Se connecter à ChatGPT

Nous allons maintenant connecter le serveur MCP à votre compte ChatGPT.

1. Ouvrez ChatGPT et accédez aux Paramètres.

2. Accédez à Connectors (Connecteurs).Si vous utilisez un compte Pro, vous devez activer le mode développeur dans les connecteurs.

Si vous utilisez ChatGPT Enterprise ou Business, vous devez publier le connecteur sur votre espace de travail.

3. Cliquez sur Create (Créer).

Remarque : Dans les espaces de travail Business, Entreprise et Edu, seuls les propriétaires, les administrateurs et les utilisateurs ayant activé l'option correspondante (pour Entreprise/Edu) peuvent ajouter des connecteurs personnalisés. Les utilisateurs ayant un rôle de membre standard ne peuvent pas ajouter de connecteurs personnalisés eux-mêmes.

Une fois qu'un connecteur est ajouté et activé par un propriétaire ou un utilisateur administrateur, il devient accessible à tous les membres de l'espace de travail.

4. Saisissez les informations requises et votre URL ngrok se terminant par /sse/. Notez le "/" après "sse". Cela ne fonctionnera pas sans cet élément :

• Nom : Elasticsearch MCP

• Description : MCP personnalisé pour la recherche et la récupération d'informations GitHub internes.

5. Appuyez sur Créer pour enregistrer le MCP personnalisé.

La connexion est instantanée si votre serveur est en cours d'exécution. Aucune authentification supplémentaire n'est requise, car la clé API Elasticsearch est configurée sur votre serveur.

Tester le serveur MCP

Avant de poser des questions, vous devez sélectionner le connecteur que ChatGPT doit utiliser.

Prompt 1 : Recherchez les issues

Demandez : "Recherchez les issues liées à la migration d'Elasticsearch", puis confirmez l'appel à l'outil d'action.

ChatGPT appellera l'outil search avec votre requête. Vous pouvez voir qu'il recherche des outils disponibles et se prépare à appeler l'outil Elasticsearch, et confirme auprès de l'utilisateur avant de prendre toute action sur l'outil.

Demande d'appel d'outil :

Réponse de l'outil :

ChatGPT traite les résultats et les présente dans un format conversationnel naturel.

En coulisses

Prompt : "Recherchez les issues liées à la migration d'Elasticsearch"

1. Appels de ChatGPT search(“Elasticsearch migration”)

2. Elasticsearch effectue une recherche hybride.

• La recherche sémantique comprend des concepts tels que "mise à niveau" et "compatibilité des versions".

• La recherche de texte trouve des correspondances exactes pour "Elasticsearch" et "migration".

• RRF combine et classe les résultats des deux approches

3. Renvoie les 10 événements les plus pertinents avec id, title, url

4. ChatGPT identifie "ISSUE-1712: migrate from Elasticsearch 7.x to 8.x" (Migrer d'Elasticsearch 7.x vers 8.x) comme résultat le plus pertinent.

Prompt 2 : Obtenez tous les détails

Demandez : "Donnez-moi les détails de l'ISSUE-1889"

ChatGPT comprend que vous souhaitez obtenir des informations détaillées sur un problème spécifique, appelle l'outil fetch et confirme auprès de l'utilisateur avant d'entreprendre des actions sur l'outil.

Demande d'appel d'outil :

Réponse de l'outil :

ChatGPT synthétise les informations et les présente clairement.

En coulisses

Prompt : "Donnez-moi les détails de l'ISSUE-1889"

1. Appels ChatGPT fetch(“ISSUE-1889”)

2. Elasticsearch extrait le document complet

3. Retourne un document complet avec tous les champs au niveau racine

4. ChatGPT synthétise les informations et répond avec les citations appropriées.

Conclusion

Dans cet article, nous avons créé un serveur MCP personnalisé qui connecte ChatGPT à Elasticsearch à l'aide d'outils MCP de recherche et de récupération dédiés, permettant de lancer des requêtes en langage naturel sur des données privées.

Ce modèle MCP fonctionne pour n'importe quel index Elasticsearch, documentation, produit, log ou toute autre donnée que vous souhaitez interroger en langage naturel.

Le problème de l'étendue des scores

Pour préparer le terrain, examinons l'une des principales raisons pour lesquelles la recherche hybride peut s'avérer difficile : la variation des fourchettes de scores. Notre vieil ami BM25 produit des scores non bornés. En d'autres termes, BM25 peut générer des scores allant de près de 0 à (théoriquement) l'infini. En revanche, les requêtes portant sur les champs dense_vector produiront des scores limités entre 0 et 1. Pour aggraver ce problème, semantic_text obscurcit le type de champ utilisé pour indexer les embeddings, de sorte qu'à moins d'avoir une connaissance détaillée de la configuration de votre index et de votre point de terminaison d'inférence, il peut être difficile de savoir quelle sera la plage de scores de votre requête. Cela pose un problème lorsqu'on essaie d'intercaler des résultats de recherche lexicaux et sémantiques, car les résultats lexicaux peuvent prendre le pas sur les résultats sémantiques, même si ces derniers sont plus pertinents. La solution généralement acceptée pour ce problème est de normaliser les scores avant d'entrelacer les résultats. Elasticsearch dispose de deux outils pour cela, les extracteurs linéaires et RRF.

Le récupérateur RRF applique l'algorithme RRF, en utilisant le rang du document comme mesure de la pertinence et en écartant le score. Étant donné que le score n'est pas pris en compte, les écarts de score ne posent pas de problème.

L'extracteur linéaire utilise une combinaison linéaire pour déterminer le score final d'un document. Il s'agit de prendre le score de chaque composante de la requête pour le document, de le normaliser et de l'additionner pour obtenir le score total. Mathématiquement, l'opération peut être exprimée comme suit :

Où N est la fonction de normalisation et SX est le score de la requête X. La fonction de normalisation est essentielle ici, car elle transforme le score de chaque requête pour utiliser le même intervalle. Pour en savoir plus sur le retriever linéaire , cliquez ici.

La décomposition

Les utilisateurs peuvent mettre en œuvre une recherche hybride efficace à l'aide de ces outils, mais cela nécessite une certaine connaissance de votre index. Prenons un exemple avec l'extracteur linéaire, où nous allons interroger un index avec deux champs :

1. semantic_text_field est un champ semantic_text qui utilise E5, un modèle d'intégration de texte.

2. text_field est un champ standard text

1. Nous utilisons une requête match sur notre champ semantic_text, dont la prise en charge a été ajoutée dans Elasticsearch 8.18/9.0.

Lors de la construction de la requête, nous devons garder à l'esprit que semantic_text_field utilise un modèle d'intégration de texte, de sorte que toute requête sur ce site générera un score entre 0 et 1. Nous devons également savoir que text_field est un champ standard de text et que les requêtes sur ce champ génèreront donc un score non borné. Pour créer un ensemble de résultats pertinents, nous devons utiliser un extracteur qui normalisera les résultats des requêtes avant de les combiner. Dans cet exemple, nous utilisons l'extracteur linéaire avec la normalisation minmax, qui normalise le score de chaque requête à une valeur comprise entre 0 et 1.

La construction de la requête dans cet exemple est assez simple car seuls deux champs sont concernés. Toutefois, la situation peut se compliquer très rapidement à mesure que l'on ajoute d'autres champs, de types différents. Cela démontre que la rédaction d'une requête de recherche hybride efficace nécessite souvent une connaissance plus approfondie de l'index interrogé, afin que les scores des composantes de la requête soient correctement normalisés avant d'être combinés. Cela constitue un obstacle à l'adoption plus large de la recherche hybride.

Regroupement de requêtes

Étendons l'exemple : Et si nous voulions interroger un champ text et deux champs semantic_text? Nous pourrions construire une requête comme celle-ci :

Cela semble être une bonne chose à première vue, mais il y a un problème potentiel. Désormais, les matchs sur le terrain semantic_text représentent ⅔ du score total :

Ce n'est probablement pas ce que vous souhaitez, car cela crée un score déséquilibré. Les effets ne sont peut-être pas très visibles dans un exemple comme celui-ci, qui ne comporte que trois champs, mais ils deviennent problématiques lorsqu'un plus grand nombre de champs sont interrogés. Par exemple, la plupart des index contiennent beaucoup plus de champs lexicaux que de champs sémantiques (c.-à-d. dense_vector, sparse_vector, ou semantic_text). Que se passerait-il si nous interrogions un index comportant 9 champs lexicaux et 1 champ sémantique en utilisant le modèle ci-dessus ? Les correspondances lexicales représenteraient 90% du score, ce qui réduirait l'efficacité de la recherche sémantique.

Une solution courante consiste à regrouper les requêtes en catégories lexicales et sémantiques et à pondérer les deux de manière égale. Cela permet d'éviter que l'une ou l'autre catégorie ne domine le score total.

Mettons cela en pratique. À quoi ressemblerait cette approche de requêtes groupées pour cet exemple en utilisant l'outil de recherche linéaire ?

Wow, ça devient verbeux ! Vous avez peut-être même dû faire défiler l'écran de haut en bas plusieurs fois pour examiner l'ensemble de la requête ! Ici, nous utilisons deux niveaux de normalisation pour créer les groupes de requêtes. Mathématiquement, elle peut être exprimée comme suit :

Ce deuxième niveau de normalisation garantit que les requêtes portant sur les champs semantic_text et text sont pondérées de manière égale. Notez que nous omettons la normalisation de second niveau pour text_field dans cet exemple puisqu'il n'y a qu'un seul champ lexical, ce qui vous évite encore plus de verbosité.

Cette structure d'interrogation est déjà lourde, et nous n'interrogeons que trois champs. Il devient de plus en plus difficile à gérer, même pour les praticiens chevronnés de la recherche, au fur et à mesure que l'on interroge davantage de champs.

Le format d'interrogation à champs multiples

Nous avons ajouté le format de requête multi-champs pour les extracteurs linéaires et RRF dans Elasticsearch 8.19, 9.1 et serverless pour simplifier tout cela. Vous pouvez maintenant effectuer la même requête que ci-dessus avec just :

Ce qui réduit la requête de 55 lignes à seulement 9 ! Elasticsearch utilise automatiquement les mappages d'index pour :

• Déterminer le type de chaque champ interrogé

• Regrouper chaque champ dans une catégorie lexicale ou sémantique

• Pondérer chaque catégorie de manière égale dans la note finale

Cela permet à n'importe qui d'exécuter une requête de recherche hybride efficace sans avoir besoin de connaître les détails de l'index ou les points de terminaison d'inférence utilisés.

Lorsque vous utilisez la méthode RRF, vous pouvez omettre le site normalizer, car le rang est utilisé comme indicateur de la pertinence :

Renforcement par champ

Lors de l'utilisation de l'extracteur linéaire, vous pouvez appliquer un boost par champ pour ajuster l'importance des correspondances dans certains champs. Par exemple, disons que vous interrogez quatre champs : deux champs semantic_text et deux champs text:

Par défaut, chaque champ est pondéré de manière égale dans son groupe (lexical ou sémantique). La répartition des points est la suivante :

En d'autres termes, chaque champ représente 25% du score total.

Nous pouvons utiliser la syntaxe field^boost pour ajouter un boost par champ à n'importe quel champ. Appliquons un boost de 2 à semantic_text_field_1 et text_field_1:

La répartition des points est maintenant la suivante :

Chaque groupe de requêtes est toujours pondéré de manière égale, mais la pondération des champs à l'intérieur des groupes a changé :

• semantic_text_field_1 est 66% du score du groupe de requêtes sémantiques, 33% du score total

• text_field_1 est 66% du score du groupe de requêtes lexicales, 33% du score total

ℹ️ Notez que la fourchette de score total ne changera pas lorsqu'une majoration par champ est appliquée. Il s'agit d'un effet secondaire voulu de la normalisation des scores, qui garantit que les scores des requêtes lexicales et sémantiques restent directement comparables entre eux.

ℹ️ Le boosting par champ peut également être utilisé avec le récupérateur RRF dans Elasticsearch 9.2+.

Résolution sur les caractères génériques

Vous pouvez utiliser le caractère générique * dans le paramètre fields pour faire correspondre plusieurs champs. Si l'on reprend l'exemple ci-dessus, cette requête est fonctionnellement équivalente à l'interrogation explicite des sitesemantic_text_field_1, semantic_text_field_2 et text_field_1:

Il est intéressant de noter que le modèle *_field_1 correspond à la fois à text_field_1 et à semantic_text_field_1. La requête sera exécutée comme si chacun des champs avait été explicitement interrogé. Le fait que le site semantic_text_field_1 corresponde aux deux modèles ne pose pas de problème ; tous les noms de champ correspondant sont dédupliqués avant l'exécution de la requête.

Vous pouvez utiliser les caractères génériques de différentes manières :

• Correspondance des préfixes (ex : *_text_field)

• Correspondance en ligne (ex : semantic_*_field)

• Correspondance des suffixes (ex : semantic_text_field_*)

Vous pouvez également utiliser plusieurs caractères génériques pour appliquer une combinaison des éléments ci-dessus, par exemple *_text_field_*.

Champs de requête par défaut

Le format d'interrogation à champs multiples vous permet également d'interroger un index dont vous ignorez tout. Si vous omettez le paramètre fields, il interrogera tous les champs spécifiés par le paramètre d'indexation index.query.default_field:

Par défaut, index.query.default_field est défini comme *. Ce caractère générique permet de résoudre tous les types de champs de l'index qui prennent en charge les requêtes de termes, ce qui est le cas de la plupart d'entre eux. Les exceptions sont les suivantes :

• dense_vector champs

• rank_vector champs

• Champs de géométrie : geo_point, shape

Cette fonctionnalité est particulièrement utile lorsque vous souhaitez effectuer une recherche hybride sur un index fourni par un tiers. Le format d'interrogation à champs multiples vous permet d'exécuter une requête appropriée de manière simple. Il suffit d'exclure le paramètre fields pour que tous les champs applicables soient interrogés.

Conclusion

Le problème de la plage de scores peut faire de la recherche hybride efficace un casse-tête à mettre en œuvre, en particulier lorsque l'on ne dispose que de peu d'informations sur l'index interrogé ou sur les points de terminaison d'inférence utilisés. Le format d'interrogation à champs multiples pour les extracteurs linéaires et RRF atténue cette difficulté en intégrant une approche de recherche hybride automatisée, basée sur le regroupement de requêtes, dans une API simple et facile d'accès. Des fonctionnalités supplémentaires, telles que le renforcement par champ, la résolution des caractères génériques et les champs de requête par défaut, permettent d'étendre les fonctionnalités à de nombreux cas d'utilisation.

Essayez le format d'interrogation à champs multiples dès aujourd'hui

Vous pouvez tester les extracteurs linéaires et RRF avec le format de requête multi-champs dans des projets Elasticsearch Serverless entièrement gérés avec un essai gratuit. Il est également disponible en version stack à partir de 8.19 & 9.1.

Démarrez en quelques minutes sur votre environnement local à l'aide d'une simple commande :

La recherche n'est pas morte, elle s'est simplement déplacée

Nous sommes donc passés d'une recherche de contexte à l'aide d'une zone de texte et de l'utilisation des informations (le contexte) renvoyées pour construire les réponses nous-mêmes, à l'utilisation du langage naturel pour dire à un agent ce que nous voulons et lui permettre de rechercher et de compiler automatiquement la réponse pour nous. Nombreux sont ceux qui, dans le monde de la technologie, soulignent ce changement et proclament que "la recherche est morte" (certes, le monde du référencement et des mots publicitaires est en train de changer: les GEO, par exemple), mais la recherche reste absolument essentielle pour les opérations agentiques - elle est simplement réalisée en grande partie à l'abri des regards par le biais d'outils.

Auparavant, les humains étaient les principaux arbitres de la pertinence subjective : chaque utilisateur a ses propres raisons d'effectuer une recherche, et son expérience personnelle influence la précision relative des résultats. Si nous voulons que les agents parviennent à la même conclusion (ou à une meilleure conclusion) que nous, nous devons nous assurer que les informations contextuelles auxquelles ils ont accès sont aussi proches que possible de notre intention subjective. Nous devons concevoir le contexte dans lequel nous fournissons les LLM en fonction de cet objectif !

Générer du contexte avec la recherche hybride

Je vous rappelle que la recherche hybride d'Elastic combine les points forts de la recherche traditionnelle par mot-clé (flexibilité syntaxique, précision des mots-clés et évaluation de la pertinence) avec la compréhension sémantique de la recherche par similarité vectorielle, et offre plusieurs techniques de reclassement. Cette synergie (il n'y a jamais eu d'usage plus vrai de ce mot !) permet d'obtenir des résultats très pertinents, avec des requêtes qui peuvent être beaucoup plus nuancées dans la manière dont elles ciblent le contenu. Il ne s'agit pas seulement d'appliquer la pertinence subjective à l'une des étapes de la recherche ; il s'agit en fait d'inclure la notation de la pertinence dans la première étape de la recherche, ainsi que tous les autres modes à la fois.

Précision supérieure & efficacité

L'utilisation d'une plateforme de données capable de fournir des services de recherche, d'extraction et de reclassement distribués en tant que principal moteur de recherche contextuelle est très judicieuse. Vous pouvez utiliser une syntaxe d'interrogation avancée pour ajouter la composante manquante de l'intention subjective et filtrer le contenu qui pourrait distraire ou brouiller la valeur des informations contextuelles renvoyées. Vous pouvez sélectionner l'une des options syntaxiques individuelles disponibles ou combiner les modalités dans une recherche unique qui cible chaque type de données de la manière qu'elle comprend le mieux, puis les combiner ou les réordonner avec le reranking. Vous pouvez filtrer la réponse pour qu'elle ne contienne que les champs/valeurs que vous souhaitez, en évitant les données superflues. Au service des agents, cette souplesse de ciblage vous permet de créer des outils extrêmement précis dans la manière dont ils récupèrent le contexte.

Raffinement du contexte (agrégations et signaux non liés au contenu)

Les agrégations peuvent être particulièrement utiles pour façonner le contenu d'un outil dans la fenêtre contextuelle. Les agrégations fournissent naturellement des faits numériques sur la forme des données contextuelles renvoyées, ce qui permet aux LLM de raisonner plus facilement et avec plus de précision. Les agrégations pouvant être imbriquées hiérarchiquement, il est facile d'ajouter des détails à plusieurs niveaux pour que le mécanisme d'apprentissage tout au long de la vie génère une compréhension plus nuancée. Les agrégations peuvent également faciliter la gestion de la taille de la fenêtre contextuelle - vous pouvez facilement réduire le résultat d'une requête de 100 000 documents à quelques centaines de tokens d'informations agrégées.

Les signaux non liés au contenu sont les indicateurs inhérents à vos données qui vous donnent une vue d'ensemble de ce que vous regardez ; il s'agit des caractéristiques supplémentaires des résultats, comme la popularité, la fraîcheur, la géolocalisation, les catégories, la diversité des hôtes ou les fourchettes de prix. Ces éléments d'information peuvent être utiles à l'agent pour évaluer l'importance du contexte qu'il a reçu. Quelques exemples simples permettent d'illustrer au mieux ce propos :

• Renforcer le contenu récemment publié et populaire - Imaginez que vous disposiez d'une base de connaissances contenant des articles. Vous souhaitez trouver des articles pertinents par rapport à la requête d'un utilisateur, mais vous voulez également favoriser les articles qui sont récents et qui ont été jugés utiles par d'autres utilisateurs (par exemple, qui ont un nombre élevé de "likes" ). Dans ce scénario, nous pouvons utiliser une recherche hybride pour trouver les articles pertinents, puis les classer en fonction de leur date de publication et de leur popularité.

• Recherche dans le domaine du commerce électronique avec ajustement des ventes et des stocks - Dans le cadre du commerce électronique, vous souhaitez montrer aux clients les produits qui correspondent à leur recherche, mais vous voulez également promouvoir les produits qui se vendent bien et qui sont en stock. Vous pouvez également déclasser les produits dont le stock est faible afin d'éviter la frustration des clients.

• Priorité aux problèmes de haute gravité dans un système de suivi des bogues - Pour une équipe de développement de logiciels, lorsqu'elle recherche des problèmes, il est essentiel de faire apparaître en premier les problèmes de haute gravité, de haute priorité et ceux qui ont été récemment mis à jour. Vous pouvez utiliser des signaux secondaires tels que "criticité" et "le plus discuté" pour pondérer les différents facteurs de manière indépendante, en veillant à ce que les questions les plus critiques et les plus activement discutées soient placées en tête.

Ces exemples de requêtes et d'autres sont disponibles dans la page de contenu Elasticsearch Labs qui les accompagne.

Renforcement de la sécurité

Un avantage essentiel de l'exploitation d'une couche de vitesse alimentée par la recherche telle qu'Elastic pour l'ingénierie contextuelle est son cadre de sécurité intégré. La plateforme d'Elastic garantit que le contexte fourni aux opérations d'IA agentique et générative respecte et protège les informations privées sensibles grâce à un contrôle d'accès granulaire basé sur les rôles (RBAC) et un contrôle d'accès basé sur les attributs (ABAC). Cela signifie que non seulement les requêtes sont traitées avec efficacité, mais aussi que les résultats sont filtrés en fonction des autorisations spécifiques de l'agent ou de l'utilisateur à l'origine de la demande.

Les agents s'exécutent en tant qu'utilisateur authentifié, de sorte que la sécurité est implicitement appliquée par le biais des fonctions de sécurité intégrées à la plateforme :

• Permissions précises : Définissez l'accès au niveau du document, du champ ou même du terme, en veillant à ce que les agents d'intelligence artificielle ne reçoivent que les données qu'ils sont autorisés à consulter.

• Contrôle d'accès basé sur les rôles (RBAC) : Attribuer des rôles aux agents ou aux utilisateurs, en leur donnant accès à des ensembles de données ou à des fonctionnalités spécifiques en fonction des responsabilités qu'ils ont définies.

• Contrôle d'accès basé sur les attributs (ABAC) : Mettre en œuvre des politiques d'accès dynamiques basées sur les attributs des données, de l'utilisateur ou de l'environnement, permettant une sécurité hautement adaptable et consciente du contexte.

• Sécurité au niveau du document (DLS) et sécurité au niveau du champ (FLS) : Ces capacités garantissent que, même au sein d'un document récupéré, seules les parties autorisées sont visibles, empêchant ainsi l'exposition d'informations sensibles.

• Intégration avec la sécurité de l'entreprise : Intégration transparente avec les systèmes de gestion des identités existants (tels que LDAP, SAML, OIDC) afin d'appliquer des politiques de sécurité cohérentes dans l'ensemble de l'entreprise.

En intégrant ces mesures de sécurité directement dans le mécanisme de récupération du contexte, Elastic agit comme un gardien sécurisé, garantissant que les agents d'intelligence artificielle opèrent dans des limites de données définies, empêchant l'exposition de données non autorisées et maintenant la conformité avec les réglementations en matière de confidentialité des données. Cela est primordial pour instaurer la confiance dans les systèmes d'IA agentique qui traitent des informations confidentielles ou exclusives.

En outre, l'utilisation d'une couche de vitesse unifiée sur les sources de données de l'entreprise permet d'alléger les charges de requêtes ad hoc inattendues sur ces référentiels que les outils agentiques créeraient. Vous disposez d'un lieu unique pour tout rechercher en temps quasi réel, et d'un lieu unique pour appliquer les contrôles de sécurité et de gouvernance.

Outils hybrides basés sur la recherche

La plateforme Elastic comporte certaines fonctionnalités de base (et d'autres sont en cours d'élaboration) qui donnent un coup de fouet à l'ingénierie contextuelle. L'essentiel est que la plateforme offre une multitude de moyens de réaliser des choses, avec la flexibilité de s'adapter, de changer et d'étendre les méthodes au fur et à mesure que l'écosystème de l'IA progresse.

Présentation de l'Agent Builder

Elastic Agent Builder est notre première incursion dans le domaine des outils d'intelligence artificielle conçus pour dialoguer avec les données que vous stockez déjà dans Elastic. Agent Builder offre une interface de chat qui permet aux utilisateurs de créer et de gérer leurs propres agents et outils dans Kibana. Il est livré avec des serveurs MCP et A2A intégrés, des API programmatiques et un ensemble d'outils système prédéfinis pour l'interrogation et l'exploration des index Elasticsearch, ainsi que pour la génération de requêtes ES|QL à partir du langage naturel. Agent Builder vous permet de créer des outils personnalisés qui ciblent et sculptent les données contextuelles renvoyées à l'agent par le biais d'une syntaxe de requête ES|QL expressive.

Comment ES|QL effectue-t-il la recherche hybride ? La capacité de base est obtenue par la combinaison du type de champ semantic_text et descommandesFORK/FUSE (FUSE utilise par défaut RRF pour fusionner les résultats de chaque fourchette). Voici un exemple simple de recherche de produit fictif :

La clause EVAL incluse dans chacune des branches FORK de l'exemple ci-dessus n'est pas strictement nécessaire ; elle n'est incluse que pour démontrer comment vous pouvez suivre la modalité de recherche à partir de laquelle un résultat donné a été retourné.

Recherche de modèles

Supposons que vous souhaitiez faire pointer vos propres outils agentiques externes vers votre déploiement Elastic. Au lieu d'ES|QL, vous souhaitez utiliser des extracteurs à plusieurs niveaux ou réutiliser la syntaxe DSL existante que vous avez développée, et vous voulez également pouvoir contrôler les entrées acceptées par la requête, la syntaxe utilisée pour exécuter la recherche et les champs renvoyés dans le résultat. Les modèles de recherche permettent aux utilisateurs de définir des structures prédéfinies pour les modèles de recherche courants, ce qui améliore l'efficacité et la cohérence de la recherche de données. Ceci est particulièrement bénéfique pour les outils agentiques qui interagissent avec les API de recherche, car ils aident à normaliser le code standard et permettent une itération plus rapide de la logique de recherche. Et si vous devez modifier l'un de ces facteurs, il vous suffit de mettre à jour le modèle de recherche et voilà, les changements sont appliqués. Si vous cherchez un exemple de modèles de recherche en action avec des outils agentiques, jetez un coup d'œil au blog d'Elasticsearch Labs "MCP for intelligent search", qui utilise un modèle de recherche derrière un appel d'outil à partir d'un serveur MCP externe.

Flux de travail intégrés (FTW !)

L'une des choses les plus difficiles à gérer dans notre nouveau monde d'IA agentique est la nature non déterministe des agents "raisonnants" semi-autonomes et autodirigés. L'ingénierie contextuelle est une discipline essentielle de l'IA agentique : il s'agit des techniques qui permettent de limiter les conclusions possibles de notre agent à ce que nous connaissons de la vérité de terrain. Même avec une fenêtre contextuelle très précise et pertinente (lorsque nous sortons du domaine des faits numériques), il nous manque toujours cette petite assurance que la réponse de l'agent est entièrement reproductible et fiable.

Lorsque vous soumettez plusieurs fois la même demande à un agent, les réponses peuvent être essentiellement les mêmes, avec juste une petite différence dans la réponse. C'est généralement bien pour les requêtes simples, peut-être à peine perceptible, et nous pouvons essayer de façonner le résultat à l'aide de techniques d'ingénierie contextuelle. Mais plus les tâches que nous demandons à nos agents sont complexes, plus il y a de chances qu'une ou plusieurs sous-tâches introduisent une variance qui modifie légèrement le résultat final. La situation s'aggravera probablement à mesure que nous commencerons à nous appuyer davantage sur les communications entre agents, et ces écarts deviendront cumulatifs. Cela confirme l'idée que les outils avec lesquels nos agents interagissent doivent être très souples et adaptables pour cibler précisément les données contextuelles, et qu'ils doivent répondre dans un format de sortie attendu. Il indique également que pour de nombreux cas d'utilisation, nous avons besoin de diriger les interactions entre l'agent et l'outil - c'est là que les flux de travail entrent en jeu !

Elastic disposera bientôt de flux de travail entièrement personnalisables, intégrés au cœur de la plateforme. Ces flux de travail pourront fonctionner avec des agents et des outils de manière bidirectionnelle, de sorte que les flux de travail pourront appeler des agents et des outils, et que les agents et les outils pourront appeler des flux de travail. L'intégration complète de ces capacités dans la même plateforme d'IA de recherche, où toutes vos données sont stockées, sera un facteur de transformation. Bientôt, très bientôt !

Elastique comme la banque de mémoire unifiée

En tant que plateforme de données distribuées conçue pour la recherche en temps quasi réel, Elastic remplit naturellement les fonctions de mémoire à long terme pour les systèmes d'IA agentique. Avec l'expérience de chat intégrée d'Agent Builder, nous disposons également d'un suivi et d'une gestion de la mémoire à court terme et de l'historique des chats. Et comme toute la plateforme est fondée sur l'API, il est extrêmement facile d'utiliser Elastic comme plateforme pour conserver les résultats contextuels d'un outil (et pouvoir s'y référer ultérieurement) qui pourraient dépasser la fenêtre contextuelle de l'agent ; cette technique est parfois appelée "prise de notes" dans les cercles de l'ingénierie contextuelle.

Le fait de disposer d'une mémoire à court terme et d'une mémoire à long terme sur la même plateforme de recherche présente de nombreux avantages intrinsèques : imaginez que vous puissiez utiliser les historiques de chat et les réponses contextuelles persistantes pour influencer sémantiquement les futures interactions de chat, ou pour effectuer une analyse des menaces, ou pour créer des produits de données persistants générés automatiquement à partir d'appels d'outils fréquemment répétés... Les possibilités sont infinies !

Conclusion

L'émergence de grands modèles de langage a modifié la façon dont nous pouvons faire correspondre le contenu et les méthodes que nous utilisons pour interroger nos données. Nous nous éloignons rapidement de notre monde actuel, où les humains effectuent les recherches, les considérations contextuelles et le raisonnement logique pour répondre à leurs propres questions, pour passer à un monde où ces étapes sont largement automatisées grâce à l'IA agentique. Pour que nous puissions faire confiance aux réponses générées que nous recevons, nous devons avoir l'assurance que l'agent a pris en compte toutes les informations les plus pertinentes (y compris le facteur de la pertinence subjective) pour générer sa réponse. Notre principale méthode pour rendre l'IA agentique digne de confiance consiste à ancrer les outils qui récupèrent un contexte supplémentaire grâce aux techniques de RAG et d'ingénierie contextuelle, mais la manière dont ces outils effectuent la récupération initiale peut être déterminante pour la précision de la réponse.

La plateforme d'IA Elastic Search offre la flexibilité et les avantages de la recherche hybride, ainsi que plusieurs fonctionnalités intégrées qui aident l'IA agentique en termes de précision, de performance et d'évolutivité ; en d'autres termes, Elastic est une plateforme fantastique pour plusieurs aspects de l'ingénierie contextuelle ! En normalisant la recherche de contexte via une plateforme de recherche, nous simplifions les opérations de l'outil agentique sur plusieurs fronts - et comme l'oxymore "ralentir pour aller plus vite", la simplicité au niveau de la couche de génération de contexte signifie une IA agentique plus rapide et plus digne de confiance.

Comme beaucoup d'entre nous, je suis à la fois heureux et étonné du rythme auquel les capacités de l'IA évoluent. Les grands modèles de langage (LLM) et la recherche vectorielle nous ont d'abord lancés dans la révolution sémantique, où nous ne cherchions plus à trouver des choses à l'aide de mots-clés. Ensuite, les LLM nous ont montré de nouvelles façons d'interagir avec nos données, en utilisant des interfaces de chat pour transformer les demandes en langage naturel en réponses qui distillent de vastes bases de connaissances en résumés facilement consommables. Nous avons maintenant (déjà !) ont les prémices d'une logique automatisée pilotée par le LLM sous la forme de flux de travail "d'IA agentique" qui peuvent comprendre sémantiquement une demande entrante, raisonner sur les étapes à suivre, puis choisir parmi les outils disponibles pour exécuter itérativement des actions afin d'atteindre ces objectifs.

La promesse de l'IA agentique nous oblige à évoluer et à ne plus utiliser principalement l'"ingénierie de l'invite" pour façonner nos interactions génératives avec l'IA, mais à nous concentrer sur la manière dont nous pouvons aider les outils agentiques à obtenir les informations supplémentaires les plus pertinentes et les plus efficaces que le LLM doit prendre en compte lorsqu'il génère ses réponses - l'"ingénierie du contexte" est la prochaine frontière. La recherche hybride est de loin le moyen le plus puissant et le plus souple de faire apparaître un contexte pertinent, et la plateforme Search AI d'Elastic ouvre une toute nouvelle voie pour exploiter les données au service de l'ingénierie contextuelle. Dans cet article, nous allons examiner comment les LLM ont changé le monde de la recherche d'informations sous deux angles, puis comment ils peuvent travailler ensemble pour obtenir de meilleurs résultats. Il y a beaucoup de chemin à parcourir...

Partie I : Comment les LLM ont changé la recherche

Commençons par la façon dont les LLM ont changé la façon dont nous accédons à l'information et dont nous la recherchons.

Notre héritage lexical

Nous vivons tous depuis longtemps dans le monde quelque peu limité de la recherche lexicale (plutôt bien, du mieux que nous pouvons). La recherche est le premier outil que nous utilisons lorsque nous faisons des recherches ou que nous commençons un nouveau projet. Jusqu'à récemment, il nous incombait de formuler nos requêtes de manière à ce qu'elles soient comprises par un moteur de recherche lexical. La recherche lexicale repose sur la mise en correspondance d'une certaine forme de termes d'interrogation avec des mots-clés trouvés dans un corpus de documents, que le contenu soit structuré ou non. Pour qu'une recherche lexicale aboutisse à un document, celui-ci doit correspondre à ce mot-clé (ou disposer d'un vocabulaire contrôlé tel qu'une liste de synonymes ou un dictionnaire pour établir le lien conceptuel).

Exemple de requêtelexicale multi-correspondance

Au moins, les moteurs de recherche ont la possibilité de renvoyer les résultats avec un score de pertinence. Les moteurs de recherche offrent une multitude d'options syntaxiques pour cibler efficacement les données indexées et des algorithmes de pertinence intégrés qui évaluent les résultats en fonction de l'intention de la syntaxe de la requête de l'utilisateur. Les moteurs de recherche bénéficient de décennies de progrès dans les algorithmes de classement par pertinence, ce qui en fait une plate-forme efficace de recherche de données capable de fournir des résultats notés et triés en fonction de leur pertinence par rapport à la requête. Les bases de données et autres systèmes qui utilisent SQL comme principale méthode de recherche de données sont ici désavantagés : il n'y a pas de concept de pertinence dans une requête de base de données ; le mieux qu'ils puissent faire est de trier les résultats par ordre alphabétique ou numérique. La bonne nouvelle, c'est que vous obtiendrez tous les résultats (rappel) avec ces mots-clés, mais qu'ils ne seront pas nécessairement dans un ordre utile par rapport à la raison pour laquelle vous les avez demandés (précision). C'est un point important, comme nous le verrons bientôt...

Entrez dans le dragon (sémantique)

Le potentiel des représentations vectorielles de l'information en tant qu'alternative à la recherche par mot-clé fait l'objet de recherches depuis longtemps. Les vecteurs sont très prometteurs parce qu'ils nous permettent de sortir du mode de correspondance par mot-clé uniquement - parce qu'ils sont des représentations numériques des termes et des poids, les vecteurs permettent de rapprocher mathématiquement les concepts sur la base de la compréhension par un modèle linguistique de la manière dont les termes sont liés les uns aux autres dans le domaine d'apprentissage. Le retard pris par la recherche vectorielle générale s'explique par le fait que les modèles étaient essentiellement limités à des domaines spécifiques et qu'ils n'étaient tout simplement pas assez vastes pour comprendre suffisamment les nombreux concepts différents qu'un terme peut représenter dans des contextes différents.

Ce n'est que lorsque les grands modèles de langage (LLM) sont apparus il y a quelques années, avec leur capacité à s'entraîner sur des quantités de données beaucoup plus importantes (en utilisant des transformateurs et de l'attention), que la recherche vectorielle est devenue pratique - la taille et la profondeur des LLM ont finalement permis aux vecteurs de stocker suffisamment de nuances pour qu'ils puissent réellement capturer le sens sémantique. Cette augmentation soudaine de la profondeur de compréhension a permis aux LLM de remplir un grand nombre de fonctions de traitement du langage naturel (NLP) qui étaient auparavant verrouillées, la plus importante étant peut-être la capacité à déduire le terme suivant le plus probable dans une séquence, compte tenu du contexte de ce qui se trouve dans la séquence jusqu'à présent. L'inférence est le processus qui donne à l'IA générative sa capacité quasi humaine à produire du texte. Le texte généré par l'IA s'appuie sur la compréhension qu'a le LLM de la manière dont les termes sont liés dans ses données d'apprentissage et utilise également la formulation de la demande pour désambiguïser les différents contextes dans lesquels les termes peuvent apparaître.

Aussi magique que soit l'IA générative, les LLM présentent des limites qui entraînent des erreurs de qualité et de précision, communément appelées hallucinations. Les hallucinations se produisent lorsque le LLM n'a pas accès aux informations (ou n'est pas guidé vers le bon contexte) pour fonder sa réponse sur la vérité et que, pour être utile, il génère une réponse confiante et plausible qui a été inventée. Cela s'explique en partie par le fait que les LLM apprennent l'usage de la langue dans de vastes domaines d'informations diverses, mais qu'ils doivent cesser leur formation à un moment donné, de sorte que leur compréhension est soumise à un facteur temporel, ce qui signifie que le modèle ne peut savoir que ce qui était exact jusqu'au moment où il a cessé de se former. Un autre facteur d'hallucinations est que le modèle ne connaît généralement pas les données privées (données non disponibles sur l'internet public), ce qui est particulièrement important lorsque ces données contiennent des termes et une nomenclature spécifiques.

Bases de données vectorielles

Les LLM vectorisent le contenu dans l'espace de leur modèle à l'aide d'une technique appelée "text embedding", qui consiste à intégrer ou à cartographier la signification sémantique du contenu dans la vision du monde du modèle sur la base de la formation qu'il a reçue. Quelques étapes sont nécessaires pour préparer et traiter le contenu à intégrer, notamment le découpage en morceaux et la tokenisation (et la tokenisation des sous-mots). Le résultat est généralement un ensemble de vecteurs denses représentant la compréhension par le modèle de la signification de ce morceau de contenu dans son espace vectoriel. Le découpage est un processus inexact qui vise à adapter le contenu aux limites des contraintes de traitement d'un modèle pour générer des encastrements, tout en essayant de regrouper le texte apparenté dans un morceau à l'aide de constructions sémantiques telles que les indicateurs de phrase et de paragraphe.

La nécessité d'un découpage en morceaux peut entraîner une certaine perte sémantique dans un document incorporé, car les morceaux individuels ne sont pas entièrement associés à d'autres morceaux du même document. L'opacité inhérente aux réseaux neuronaux peut aggraver cette perte - un LLM est véritablement une "boîte noire" dans laquelle les connexions entre les termes et les concepts établies au cours de la formation sont non déterministes et ne peuvent être interprétées par les humains. Cela pose des problèmes d'explicabilité, de reproductibilité, de partialité inconsciente et, potentiellement, de perte de confiance et d'exactitude. Néanmoins, la possibilité de relier sémantiquement des idées, de ne pas être lié à des mots-clés spécifiques lors de la recherche, est extrêmement puissante :

Un exemple de requête sémantique

Les bases de données vectorielles ne sont pas des moteurs de recherche, mais des bases de données ! Lorsqu'une recherche de similarité vectorielle est effectuée, les termes de la requête sont encodés pour trouver un ensemble de coordonnées (d'intégration) dans l'espace vectoriel du modèle. Ces coordonnées sont ensuite utilisées comme œil-de-bœuf pour trouver les documents qui sont les "plus proches voisins" de l'œil-de-bœuf - ce qui signifie que le rang d'un document (ou sa place dans les résultats) est déterminé par la distance de similarité calculée entre les coordonnées de ce document et les coordonnées de la requête. Dans quel sens le classement doit-il primer, lequel des contextes possibles est le plus proche de l'intention de l'utilisateur ? L'image à laquelle je me réfère est une scène du film Stargate, où nous avons les six points de coordonnées qui se croisent pour nous indiquer la destination (l'œil-de-bœuf), mais nous ne pouvons pas nous y rendre sans connaître le "7e symbole" - les coordonnées du point de départ représentant l'intention subjective de l'utilisateur. Ainsi, au lieu que le classement relatif des vecteurs soit basé sur une sphère de similarité toujours plus étendue et indifférenciée, en tenant compte de l'intention subjective de la requête par le biais d'une syntaxe expressive et d'une notation de la pertinence, nous pouvons obtenir quelque chose qui ressemble à un cylindre de pertinence subjective graduée.

Les capacités d'inférence d'un LLM peuvent aider à identifier le contexte le plus probable pour la requête, mais le problème est que sans aide, les coordonnées de la requête entrante ne peuvent être déterminées que par la façon dont le modèle a été formé à l'origine.

D'une certaine manière, on pourrait dire que la similarité vectorielle va à l'extrême opposé d'une correspondance stricte par mot-clé - sa force réside dans sa capacité à surmonter les problèmes d'inadéquation des termes, mais presque jusqu'à la faute: Les LLM tendent à unifier des concepts apparentés plutôt qu'à les différencier. La similarité vectorielle améliore notre capacité à faire correspondre le contenu sur le plan sémantique, mais ne garantit pas la précision car elle peut négliger des mots-clés exacts et des détails spécifiques qui ne sont pas suffisamment désambiguïsés par le modèle. La recherche de similarités vectorielles est puissante en soi, mais nous avons besoin de moyens pour corréler les résultats que nous extrayons d'une base de données vectorielle avec les résultats d'autres méthodes d'extraction.

Techniques de repositionnement

C'est le moment de mentionner une technique générale appelée "reranking", qui consiste à réévaluer ou à normaliser les ensembles de résultats en fonction d'un ordre de classement unifié. Le besoin de reclassement peut être dû au fait que les résultats provenant de sources multiples ou de méthodes de recherche ont des mécanismes de classement/évaluation différents (ou aucun, SQL !), ou le reclassement peut être utilisé pour aligner sémantiquement les résultats provenant de sources non sémantiques sur la requête de l'utilisateur. Le reclassement est une opération de deuxième étape, c'est-à-dire un ensemble de résultats qui ont été collectés par une méthode de recherche initiale (c'est-à-dire le SQL, recherche lexicale, recherche vectorielle) sont ensuite réordonnées avec une méthode de notation différente.

Plusieurs approches sont disponibles, notamment Learning-To-Rank (LTR) et Reciprocal Rank Fusion (RRF) - LTR est utile pour capturer les caractéristiques des résultats de recherche (likes, évaluations, clics, etc.) et les utiliser pour noter et améliorer ou biaiser les résultats. RRF est parfait pour fusionner les résultats obtenus à partir de différentes modalités d'interrogation (par ex. les recherches dans les bases de données lexicales et vectorielles) en une seule liste de résultats. Elastic offre également la possibilité d'ajuster les scores à l'aide de méthodes de reclassement linéaire.

L'une des techniques de reclassement les plus efficaces est cependant le reclassement sémantique, qui utilise la compréhension sémantique d'un LLM pour analyser les vecteurs d'intégration de la requête et des résultats, puis appliquer la notation de la pertinence/le reclassement pour déterminer l'ordre final. Le reranking sémantique nécessite une connexion à un modèle de reranking, bien sûr, et Elasticsearch fournit une API d'inférence qui vous permet de créer des points d'extrémité de rerank qui exploitent des modèles intégrés(Elastic Rerank), des modèles tiers importés ou des services hébergés en externe tels que Cohere ou Google Vertex AI. Vous pouvez ensuite effectuer un reclassement grâce à la syntaxe d'abstraction de la requête du récupérateur:

Exemple d'opération de remise en ordre d'un récupérateur en plusieurs étapes

Ça a l'air bien, non ? Nous pouvons effectuer un reclassement sur des résultats provenant de sources disparates et nous rapprocher d'une compréhension sémantique de tous les types de contenu... Le reclassement sémantique peut être coûteux tant sur le plan du calcul que du temps de traitement nécessaire, et pour cette raison, le reclassement sémantique ne peut être effectué que sur un nombre limité de résultats, ce qui signifie que la manière dont ces résultats initiaux sont récupérés est importante.

La méthode de recherche contextuelle est importante

L'intention subjective est un facteur important dans la détermination de l'exactitude d'un résultat, dans l'évaluation de sa pertinence. Sans la possibilité de prendre en compte l'intention de l'utilisateur lors de l'exécution de la requête (telle qu'elle est exprimée par une syntaxe flexible ou par un reclassement de deuxième niveau), nous ne pouvons que sélectionner les contextes existants déjà encodés dans l'espace de modélisation. La façon dont nous abordons généralement ce manque de contexte est par le biais de techniques telles que Retrieval Augment Generation (RAG). La méthode RAG consiste à déplacer les coordonnées de la requête en incluant des termes connexes supplémentaires issus d'une pré-requête de données contextuelles pertinentes. Le moteur qui fournit ce contexte supplémentaire et sa méthode initiale de recherche sont donc d'autant plus importants pour la précision du contexte !

Passons en revue les différentes méthodes de recherche contextuelle et la manière dont elles peuvent aider ou nuire à une opération RAG :

• La recherche hybride sans moteur de recherche manque encore de pertinence subjective. Si la plateforme qui fournit le RAG est principalement basée sur SQL (ce qui inclut la plupart des plateformes de "lac de données"), elle ne dispose pas d'un système de notation de la pertinence au stade de la recherche initiale. De nombreuses plateformes de lac de données proposent leur propre version de la recherche hybride (et non de la recherche), combinant généralement des techniques de reranking telles que le reranking sémantique et le RRF sur leur recherche basée sur SQL et les résultats de la base de données vectorielles. Un simple tri est manifestement insuffisant pour un classement subjectif, mais même lorsqu'il est utilisé comme base pour une opération de reclassement sémantique à la deuxième étape, SQL comme la recherche à la première étape devient un problème lorsque le reclassement sémantique n'est effectué que sur les "k premiers" résultats - sans un moyen de noter les résultats à la recherche, quelle garantie avons-nous que les meilleurs résultats se trouvent effectivement dans les premiers résultats ?

• La similarité vectorielle n'est pas suffisante pour le RAG. Il s'agit en fait d'un ensemble de problèmes combinés - la perte de l'intégration, les méthodes naïves de regroupement, le mode de calcul de la similarité et la composante manquante cruciale de l'intention subjective. L'un des principaux objectifs de RAG est de fonder les interactions génératives de l'IA sur la vérité objective, à la fois pour éviter les hallucinations et pour informer le LLM des informations privées dont il n'a pas eu connaissance au cours de la formation. Nous pouvons utiliser le contexte supplémentaire fourni par le RAG pour contraindre et orienter les MFR à prendre en compte les liens et les détails que nous savons être les plus importants pour répondre à la question posée. Pour ce faire, nous devons utiliser des approches sémantiques et lexicales.

• RAG (grep/regex) basé sur des fichiers. Certains secteurs de l'univers de l'IA agentique préconisent l'utilisation de fenêtres contextuelles considérablement agrandies qui accèdent aux fichiers locaux via grep et regex pour RAG plutôt que des plates-formes de recherche externes. L'idée est qu'en disposant d'une fenêtre contextuelle beaucoup plus large, les LLM seront en mesure d'établir des connexions conceptuelles au sein de leur propre espace de réflexion plutôt que de s'appuyer sur des éléments fragmentés et de multiples méthodes/plateformes de recherche pour collecter des informations pertinentes. S'il est vrai en théorie que le fait de disposer d'un document entier donne une image plus complète que des segments de document, cela ne peut fonctionner que dans des domaines de données restreints (ou, par exemple, lors de la fourniture de fichiers pour le vibecodage), et même dans ce cas, la méthode de recherche initiale est un balayage de tous les documents avec une correspondance par mot-clé uniquement.

La recherche, c'est plus que l'extraction

Les moteurs de recherche sont conçus pour rendre les requêtes aussi rapides et flexibles que possible. En interne, ils utilisent des structures de données spécialisées pour stocker et récupérer différents types de données de manière adaptée à ces types de données. Elasticsearch permet d'optimiser le stockage et l'interrogation de pratiquement tous les types de données, y compris la recherche lexicale non structurée/texte intégral (correspondance, phrase, proximité, correspondance multiple), la correspondance et le filtrage rapides par mot-clé (correspondance exacte), les plages numériques, les dates, les adresses IP, et est très flexible dans la manière dont il stocke les structures de documents (par ex. les documents imbriqués ou aplatis). Elasticsearch est également une base de données vectorielle native capable de stocker et d'interroger des types de vecteurs épars et denses, et nous continuons à explorer des moyens innovants (par exemple, Better Binary Quantization (BBQ) & DiskBBQ) pour maintenir la fidélité de la recherche tout en améliorant la vitesse, l'évolutivité et les coûts associés au contenu vectorisé. La plateforme Elasticsearch offre également une résilience des données et une haute disponibilité intégrées, ainsi que des fonctionnalités de gestion du cycle de vie des données, telles que les instantanés consult ables, qui vous permettent de conserver les données rarement consultées ou les données conservées à long terme sur un stockage objet rentable, tout en conservant une capacité de recherche totale.

La recherche hybride, c'est le meilleur des mondes

Recherche hybride (et pas seulement recherche hybride !) combine les forces de la recherche lexicale traditionnelle avec la compréhension sémantique des LLM et la recherche par similarité vectorielle. Cette synergie permet de cibler des résultats très pertinents au stade de la recherche grâce à l'une des options syntaxiques souples proposées par un moteur de recherche : options syntaxiques axées sur l'intention et évaluation de la pertinence, recherche de données multimodales, filtrage, agrégations et biais. Avec une syntaxe de recherche telle que ES|QL et des extracteurs à plusieurs niveaux, nous pouvons combiner de manière flexible la recherche traditionnelle avec la recherche sémantique, les filtres et plusieurs techniques de reclassement en une seule requête.

L'un des principaux avantages de la recherche hybride est que vos requêtes peuvent utiliser une syntaxe spécialisée pour plusieurs types de données simultanément. Ces différentes syntaxes d'interrogation peuvent être utilisées non seulement pour trouver des résultats, mais aussi comme filtres ou agrégations sur les résultats. Par exemple, l'analyse géospatiale est l'un des types d'interrogation les plus courants qui est fréquemment combiné à d'autres syntaxes. Vous pouvez par exemple demander des résultats dont les coordonnées géographiques se situent à une distance donnée d'un point, ou demander des agrégations de vos résultats par région, ou encore des agrégations pour suivre et alerter sur les mouvements à l'intérieur ou à l'extérieur d'une zone. Avec la recherche hybride, vous avez la possibilité de combiner des syntaxes pour cibler les résultats de la manière la plus précise possible, afin de retrouver le contenu le plus proche de votre contexte.

Intermède

Cette première partie raconte comment la recherche vectorielle a changé la façon dont nous pouvons récupérer des données et prépare le terrain pour les changements que les LLM ont apportés aux mécanismes d'interrogation que nous utilisons pour interagir avec les données. Nous allons faire comme si nous avions dû diviser ce texte en plusieurs parties pour que les LLM puissent le comprendre sans perdre le contexte... ;-) Nous en apprendrons plus sur les raisons de cette importance dans la Partie II : L'IA agentique et le besoin d'ingénierie contextuelle, et dans la Partie III, nous reviendrons à notre discussion sur la recherche hybride.

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

Comment cela a commencé

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

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

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

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

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

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

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

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

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

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

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

Implémentation

Conception et stratégie d'indexation Elasticsearch

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

Index du catalogue des pics

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

Mappage de l'index :

Champ d'application

Type

Exemple

Objectif/Notes

Vecteur/Indexation

id

mot-clé

ama-dablam

Slug/id stable

-

noms

texte + sous-champ mot-clé

["Ama Dablam","Amadablam"]

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

-

latlon

geo_point

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

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

-

elev_m

entier

6812

Élévation (facultatif)

-

texte_embed

dense_vector

768

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

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

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

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

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

• Créer un prototype de texte en utilisant :

  • noms des sommets

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

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

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

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

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

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

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

Exemple de document provenant de l'index peaks_catalog:

Index des photos

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

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

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

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

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

Champ d'application

Type

Exemple

Objectif/Notes

Vecteur / Indexation

chemin

mot-clé

data/images/IMG_1234.HEIC

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

-

clip_image

dense_vector

768

Intégration d'images SigLIP-2

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

pics_prédits

mot-clé

["ama-dablam","pumori"]

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

-

GPS

geo_point

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

permet d'utiliser des filtres géographiques

-

heure de la prise de vue

date

2023-10-18T09:41:00Z

temps de capture : tri/filtre

-

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

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

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

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

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

Exemple de document de l'index des photos :

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

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

Cas d'utilisation de la recherche

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

Requête Elasticsearch avec filtre géographique :

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

Requête Elasticsearch :

Étape 1 : Trouver les noms de pics correspondants

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

Streamlit UI

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

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

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

Conclusion

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

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

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

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

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

Si vous souhaitez essayer vous-même :

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

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

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

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 !

Rencontrez le retriever linéaire !

Dans ce billet, nous vous présentons le linear retriever, notre dernier ajout pour soutenir la recherche hybride ! Contrairement à rrf, le récupérateur linear calcule une somme pondérée de toutes les requêtes correspondant à un document. Cette approche préserve l'importance relative de chaque document dans un ensemble de résultats tout en permettant un contrôle précis de l'influence de chaque requête sur le score final. Il s'agit donc d'un moyen plus intuitif et plus souple d'affiner la recherche hybride.

Définition d'un récupérateur linéaire où le score final sera calculé comme suit :

C'est aussi simple que cela :

Vous avez remarqué à quel point c'est simple et intuitif ? (et très similaire à rrf!) Cette configuration vous permet de contrôler précisément la contribution de chaque type de requête au classement final, contrairement à rrf, qui s'appuie uniquement sur les classements relatifs.

Une mise en garde subsiste : les scores knn peuvent être strictement limités, en fonction de la métrique de similarité utilisée. Par exemple, avec la similarité en cosinus ou le produit de points de vecteurs normalisés en unités, les scores se situeront toujours dans l'intervalle [0, 1]. En revanche, les scores sur bm25 sont moins prévisibles et n'ont pas de limites clairement définies.

Mise à l'échelle des scores : kNN vs BM25

L'une des difficultés de la recherche hybride réside dans le fait que les différents outils de recherche produisent des résultats sur des échelles différentes. Prenons par exemple le scénario suivant :

La requête A obtient un score :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

Les résultats de la requête B :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

0.63

0.01

0.3

0.4

Vous pouvez voir la disparité ci-dessus : les scores de kNN se situent entre 0 et 1, tandis que les scores de bm25 peuvent varier considérablement. Cette différence rend difficile l'établissement de poids statiques optimaux pour la combinaison des résultats.

La normalisation à la rescousse : le normalisateur MinMax

Pour y remédier, nous avons introduit un normalisateur minmax facultatif qui adapte les scores, indépendamment pour chaque requête, à la plage [0, 1] en utilisant la formule suivante :

Cela permet de préserver l'importance relative de chaque document dans l'ensemble des résultats d'une requête, ce qui facilite la combinaison des scores obtenus par différents extracteurs. Avec la normalisation, les scores deviennent :

La requête A obtient un score :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.01

0.005

0.000

Les résultats de la requête B :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.000

0.465

0.645

Tous les scores se situent désormais dans la fourchette [0, 1] et l'optimisation de la somme pondérée est beaucoup plus simple car nous capturons désormais l'importance (relative à la requête) d'un résultat au lieu de son score absolu et nous maintenons la cohérence entre les requêtes.

Exemple de récupérateur linéaire

Prenons maintenant un exemple pour illustrer ce qui précède et la façon dont le récupérateur linear comble certaines lacunes de rrf. RRF se base uniquement sur les rangs relatifs et ne prend pas en compte les différences de score réelles. Par exemple, compte tenu de ces scores :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

score du rrf

0.03226

0.03252

0.03200

0.03125

rrf classerait les documents comme suit :

Cependant, doc1 a un score bm25 nettement plus élevé que les autres, ce que rrf ne parvient pas à capturer car il ne tient compte que des rangs relatifs. L'outil linear retriever, combiné à la normalisation, prend correctement en compte les scores et leurs différences, ce qui permet d'obtenir un classement plus significatif :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1

0.01

0.005

0

Comme nous pouvons le voir ci-dessus, l'excellent classement de doc1 et score pour bm25 est correctement pris en compte et reflété dans les notes finales. En outre, tous les scores se situent désormais dans la fourchette [0, 1], ce qui nous permet de les comparer et de les combiner de manière beaucoup plus intuitive (et même de mettre en place des processus d'optimisation hors ligne).

La mise en place de l'ensemble

Pour tirer pleinement parti de l'outil de recherche linear et de la normalisation, la demande de recherche devrait ressembler à ce qui suit :

Cette approche combine le meilleur des deux mondes : elle conserve la flexibilité et la notation intuitive du linear retriever, tout en garantissant une mise à l'échelle cohérente des scores grâce à la normalisation MinMax.

Comme tous nos retrievers, le retriever linear peut être intégré à n'importe quel niveau d'un arbre hiérarchique de retrievers, avec une prise en charge de l'explicabilité, de la mise en évidence des correspondances, du regroupement des champs, etc.

Quand choisir le retriever linéaire et pourquoi cela fait une différence

Le linear retriever :

• Préserve l'importance relative en s'appuyant sur les scores réels, et pas seulement sur les rangs.

• Permet un réglage fin avec des contributions pondérées de différentes requêtes.

• Améliore la cohérence grâce à la normalisation, ce qui rend la recherche hybride plus robuste et plus prévisible.

Conclusion

Le récupérateur linear est déjà disponible sur Elasticsearch Serverless, et les versions 8.18 et 9.0 ! D'autres exemples et paramètres de configuration sont également disponibles dans notre documentation. Essayez-le et voyez comment il peut améliorer votre expérience de la recherche hybride - nous attendons vos commentaires. Bonne recherche !