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

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

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

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

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

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

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

Définitions (pour les non-experts)

Avant d'examiner le code, clarifions certains termes.

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

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

  • Avantages : rappel parfait à 100 %.

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

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

  • Avantages : extrêmement rapide et scalable.

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

L'expérience : exact versus approximatif

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

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

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

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

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

Le test Recall@10

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

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

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

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

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

Voici le mapping que nous avons utilisé :

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

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

Voici ce qui est arrivé au score de rappel :

Documents

Score de rappel à 10

1 000

1,000 (100 %)

5 000

0,998 (100 %)

10 000

0,992 (99,4 %)

20,000

0,999 (99,0 %)

40 000

0,992 (98,8 %)

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

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

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

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

BBQ utilise un mécanisme de rescoring :

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

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

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

Pouvons-nous faire mieux ?

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

Conclusion

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

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

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

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

Étape 0 : Notre ensemble de données

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

financial_accounts: Portefeuilles de clients avec profils de risque

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

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

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

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

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

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

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

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

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

En bref : jonctions et garde-corps

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

1. La jointure LOOKUP

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

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

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

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

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

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

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

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

Le chemin de l'interface utilisateur

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

1. Naviguer vers Agents

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

2. Remplissez le formulaire avec les informations suivantes :

• ID de l'outil : find_client_exposure_to_negative_news

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

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

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

• Étiquettes: retrieval et risk-analysis

Les étiquettes sont utilisées pour regrouper plusieurs outils

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

i. Voici la recherche que l'agent utilisera

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

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

4. Testez-le !

• Cliquez sur Save & test.

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

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

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

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

Le chemin de l'API

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

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

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

L'art de la proposition

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

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

Voyons pourquoi cette incitation est si efficace :

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

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

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

Le chemin de l'interface utilisateur

1. Naviguez vers Agents.

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

2. Complétez les informations de base :

• ID de l'agent : financial_assistant.

• Instructions : Copiez le message ci-dessus.

• Étiquettes: Finance.

• Nom d'affichage : Financial Assistant.

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

3. De retour en haut, cliquez sur Outils.

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

4. Cliquez sur Enregistrer.

Le chemin de l'API

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

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

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

Le chemin de l'interface utilisateur

1. Naviguez jusqu'à Agents dans Kibana.

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

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

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

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

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

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

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

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

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

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

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

Le chemin de l'API

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

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

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

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

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

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

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

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

Conclusion : À vous de construire

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

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

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

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

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

Restez à l'écoute et bonne construction !