Qu'est-ce qu'un générateur de tableaux de bord Kibana ?

Et si vous pouviez décrire le tableau de bord que vous souhaitez en langage clair et le voir apparaître, avec des graphiques interactifs, une mise en page par glisser-déposer et une exportation vers Kibana en un clic ?

C'est exactement ce que fait example-mcp-dashbuilder. Il s'agit d'une application open source (Model Context Protocol (MCP)) qui connecte les assistants IA à Elasticsearch, vous permettant de créer des tableaux de bord Kibana complets par chat. Pas besoin de cliquer dans les menus. Pas de configurations de visualisation à écrire manuellement. Il suffit de décrire ce dont vous avez besoin, et l'IA explore vos données, écrit les requêtes en langage de requête Elasticsearch (ES|QL), construit les graphiques et propose un tableau de bord interactif en direct, le tout dans la fenêtre de chat de votre éditeur.

Du prompt au tableau de bord en quelques secondes

Voici à quoi cela ressemble concrètement. Vous tapez quelque chose comme :

"Crée-moi un tableau de bord de trafic web à partir de logstash-* avec le nombre total de requêtes, les nombre d'octets transférés au fil du temps, les principales sources géographiques et une répartition des codes de réponse"

L'IA va alors :

1. Découvre vos données : liste les index, inspecte les mappings de champs.

2. Rédige des requêtes ES|QL : adaptées à votre schéma, utilisant les bonnes agrégations.

3. Crée des visualisations : graphiques à barres, graphiques linéaires, métriques avec sparklines, cartes thermiques, graphiques circulaires.

4. Organise tout : sections pliables, titres compréhensibles, mise en page adéquate.

5. Affiche un aperçu interactif : directement dans le chat, avec des infobulles, un sélecteur de temps et un système de glisser-déposer.

Chaque graphique apparaît en ligne au fur et à mesure qu'il est créé, ce qui vous permet de voir les progrès réalisés en temps réel. Ensuite, view_dashboard affiche le tableau de bord complet avec tous les panneaux disposés dans la grille à 48 colonnes de Kibana.

Aperçu du graphique unique intégré.

Propulsé par ES|QL

Toutes les recherches de données utilisent ES|QL, le langage de requête d'Elasticsearch. L'IA ne se contente pas de traiter les requêtes brutes, elle utilise aussi une connaissance intégrée d'ES|QL ainsi que des informations sur la structure de vos données pour écrire des requêtes correctes et efficaces pour chaque type de visualisation.

Le serveur inclut une référence ES|QL complète en tant que ressource MCP. Avant d'écrire une requête, l'IA lit cette référence pour comprendre les commandes, fonctions et schémas disponibles. Associée à un guide des bonnes pratiques de visualisation de données (également utilisé comme ressource), l'IA sait non seulement comment interroger, mais aussi ce qui génère une bonne visualisation :

• Utilisez BUCKET(@timestamp, 1 day) pour les séries temporelles ; toujours SORT par le champ temporel.

• Limitez les graphiques circulaires à six tranches avec | SORT value DESC | LIMIT 6.

• Choisissez des graphiques à barres pour les comparaisons de catégories, des graphiques linéaires pour les tendances, des métriques pour les indicateurs clés de performance (KPIs).

Exploration de données pilotée par l'IA avec analyse ouverte

Créer un tableau de bord que vous avez déjà imaginé est une chose. Se demander "Qu'y a-t-il d'intéressant dans cet index?" et obtenir une réponse utile est plus difficile ; cela exige que l'IA sache explorer, et pas seulement dessiner.

Example-mcp-dashbuilder propose une ressource analysis://guidelines qui définit un flux d'exploration structuré : profiler les données, effectuer des agrégations ciblées, faire apparaître des schémas dignes d'être étudiés, créer des graphiques pour les résultats les plus intéressants et proposer des requêtes d'exploration que l'utilisateur pourrait souhaiter ensuite. Des expressions déclencheurs, telles que "analyser mes logs" ou "trouver des tendances dans cet index", incitent l'IA à lire le playbook avant toute autre action. Ainsi, une requête ouverte produit une analyse cohérente plutôt qu'une multitude de graphiques aléatoires.

Résultat : vous pouvez fournir à l'IA un index inconnu et obtenir en retour un point de départ : un tableau de bord accompagné d'une courte liste de questions du type "Voici ce que j'ai remarqué, voulez-vous que j'approfondisse certains de ces points ?".

Exportation et importation du tableau de bord Kibana : le processus complet

C'est au niveau de l'exportation/importation que example-mcp-dashbuilder devient réellement utile pour les équipes qui travaillent déjà avec Kibana. example-mcp-dashbuilder est un outil à part entière, une interface de tableau de bord conversationnelle intégrée à votre éditeur, mais qui ne confine pas votre travail à cet éditeur. Les tableaux de bord créés ici peuvent être transférés vers Kibana à votre guise, et inversement, les tableaux de bord Kibana existants peuvent être importés pour une édition assistée par l'IA.

Exporter vers Kibana

Lorsque vous êtes satisfait de votre tableau de bord, une commande permet de l'exporter :

"Exporter ce tableau de bord vers Kibana"

Chaque panneau est traduit en une véritable visualisation Kibana Lens. La traduction préserve :

• Requêtes ES|QL : transférées directement en tant que sources de données Lens ES|QL.

• Positions de la grille : le même système à 48 colonnes que celui utilisé par Kibana, votre mise en page est donc identique.

• Couleurs personnalisées : Palettes de séries, arrière-plans de métriques, rampes de couleurs de carte thermique.

Le résultat est un tableau de bord Kibana entièrement fonctionnel. Pas une capture d'écran. Pas une intégration. Un vrai tableau de bord que vous pouvez partager et continuer à modifier dans Kibana.

Tableau de bord Kibana et tableau de bord dans le chat Cursor côte à côte.

Importer depuis Kibana

L'aller-retour fonctionne également dans l'autre sens :

"Importer le tableau de bord Kibana avec l'identifiant abc-123"

Cette opération récupère un tableau de bord Kibana existant, traduit ses visualisations Lens en configurations de graphiques éditables, préserve la disposition de la grille et les sections, puis charge le tout dans example-mcp-dashbuilder. À partir de là, vous pouvez le modifier en langage naturel et le réexporter.

L'IA devient ainsi un collaborateur de votre workflow Kibana existant, sans le remplacer.

Thèmes et couleurs personnalisés

Vous souhaitez un tableau de bord personnalisé ? Il suffit de demander :

"Créer un tableau de bord à thème rose avec des couleurs personnalisées"

Chaque type de visualisation prend en charge la configuration personnalisée des couleurs :

• Graphiques : palette accepte un tableau de couleurs hexadécimales pour les séries et les tranches.

• Métriques : color définit la couleur de fond.

• Cartes thermiques : colorRamp définit le gradient, des valeurs faibles aux valeurs élevées.

L'IA interprète naturellement les demandes de thème. Par exemple, si vous dites "Thème Océan", elle choisira des bleus et des turquoises. Si vous dites "Respecter les couleurs de notre marque" et fournissez les valeurs hexadécimales, elles seront automatiquement intégrées à Kibana lors de l'exportation.

Un tableau de bord thématique avec des couleurs personnalisées.

Fonctionnement de example-mcp-dashbuilder : architecture MCP

example-mcp-dashbuilder est basé sur MCP, la norme ouverte permettant de connecter les assistants IA à des outils et données externes. Voici l'architecture générale :

Le serveur MCP expose 25 outils directement accessibles à l'IA, permettant notamment l'exécution de requêtes ES|QL et l'exportation de tableaux de bord. Il propose également quelques outils internes "application uniquement", utilisés par l'aperçu intégré pour récupérer des données, enregistrer les modifications de mise en page et détecter les champs temporels. Trois ressources sont disponibles : un guide des bonnes pratiques de visualisation des données, une documentation de référence ES|QL et un playbook d'analyse approfondie, déclenché par des prompts ouverts ("analyse mes logs", "qu'y a-t-il d'intéressant dans cet index"). Le serveur fonctionne via les E/S standard (stdio) ou HTTP. Le protocole HTTP prend en charge les réponses par flux et la gestion des sessions, permettant ainsi à plusieurs clients de se connecter simultanément.

L'application MCP est l'aperçu interactif. Elle est développée avec React, Elastic Charts, et l'interface utilisateur Elastic, le tout intégré dans un seul fichier HTML autonome. Lorsque l'IA appelle view_dashboard ou crée un graphique, l'hôte affiche ce HTML dans une iframe en sandbox. L'application communique avec le serveur exclusivement via le protocole MCP Apps, en utilisant callServerTool() sur postMessage pour récupérer les données, enregistrer les mises en page et détecter les champs temporels. Il n'y a pas de serveur local, pas de port à configurer, aucune dépendance réseau externe.

Cela signifie qu'il fonctionne avec n'importe quel client compatible MCP : Cursor, Claude Desktop, Claude.ai, VS Code avec Copilot et bien d'autres.

Quels sont les types de graphiques pris en charge par example-mcp-dashbuilder ?

Au moment de la rédaction de cet article, six types de graphiques couvrant les scénarios de tableaux de bord les plus courants sont pris en charge :

Type

Idéal pour

Exemple

À barres

Comparaison des catégories

Requêtes par source géographique

Linéaire

Tendances au fil du temps

Octets transférés par heure

Zone

Volume au fil du temps

Volume de requêtes au fil du temps

Tarte

Partie du tout (six tranches maximum)

Distribution des codes de réponse

Métrique

KPI unique avec sparkline

Nombre total de requêtes avec tendance horaire

Carte thermique

Schémas en deux dimensions

Requêtes par jour de la semaine et heure

Les tableaux de bord prennent en charge les sections pliables pour l'organisation, un sélecteur temporel avec détection automatique des champs temporels, ainsi que la possibilité d'enregistrer et de basculer entre plusieurs tableaux de bord ; les sessions de chat parallèles restent isolées les unes des autres via un dashboardId intégré à chaque appel d'outil.

Comment installer et exécuter example-mcp-dashbuilder

example-mcp-dashbuilder est open source et prêt à être utilisé. Vous aurez besoin de Node.js 22+, d'une instance Elasticsearch (locale ou Elastic Cloud) et d'un client compatible MCP.

Claude Desktop : téléchargez la dernière version .mcpb depuis GitHub Releases, et double-cliquez dessus. Claude Desktop vous demandera vos identifiants Elasticsearch.

Cursor/Claude Code/VS Code Copilot : indiquez à votre configuration MCP l'emplacement de l'archive tar publiée ; pas de clone, pas de npm install :

Définissez ES_NODE, ES_API_KEY (ou ES_USERNAME / ES_PASSWORD) et KIBANA_URL comme variables d'environnement. Si vous préférez travailler à partir de la source, clonez le dépôt et exécutez npm run setup pour lancer un assistant interactif qui gère à la fois Elasticsearch local et Elastic Cloud (Cloud ID + clé API).

Et commence à créer :

"Explorer l'index des logs et me créer le tableau de bord le plus pertinent possible ?"

L'IA prend le relais. 😉

Roadmap : nouveautés à venir concernant example-mcp-dashbuilder

Il s'agit d'une version préliminaire, et nous travaillons activement à son développement. Voici quelques axes sur lesquels nous nous concentrons :

• Autres types de graphiques : jauge, diagramme en anneau, arborescence, table de données et nuage de tags pour correspondre à toutes les capacités de Lens.

• Transférez les tableaux de bord vers Git : inscrivez les configurations des tableaux de bord dans un référentiel pour le contrôle des versions et les workflows de révision du code.

• Meilleure expérience utilisateur en cas d'erreur : commentaires plus détaillés en cas d'échec des requêtes ES|QL, avec des suggestions de solutions courantes.

• Flux d'analyse plus riches : extension du playbook d'analyse approfondie pour couvrir davantage de formes de données (logs, métriques, traces).

Nous serions ravis de savoir ce que vous allez en faire. Essayez-le, signalez les problèmes et faites-nous savoir quelles visualisations et quels workflows seraient les plus utiles pour votre équipe.

GitHub : elastic/example-mcp-dashbuilder

Remerciements

Merci à Walter Rafelsberger et Tim Schnell pour leurs contributions à la mise en œuvre.

FAQ

Qu'est-ce que example-mcp-dashbuilder ? example-mcp-dashbuilder est une application MCP (Model Context Protocol) open source qui connecte les assistants IA à Elasticsearch. Il vous permet de décrire un tableau de bord Kibana en langage clair, de générer automatiquement des requêtes ES|QL, de créer des visualisations et de diffuser un tableau de bord interactif en direct dans la fenêtre de chat de votre éditeur.

Quel langage de requête example-mcp-dashbuilder utilise-t-il pour récupérer les données ? Toutes les récupérations de données utilisent ES|QL, le langage de requête canalisé d'Elasticsearch. Le serveur MCP inclut une référence ES|QL intégrée que l'IA lit avant d'écrire toute requête, garantissant une syntaxe correcte et des agrégations efficaces pour chaque type de visualisation.

Puis-je exporter vers Kibana des tableaux de bord créés avec example-mcp-dashbuilder ? Oui. L'exécution de "Exporter ce tableau de bord vers Kibana" traduit chaque panneau en une véritable visualisation Kibana Lens, préservant les requêtes ES|QL, la mise en page de la grille à 48 colonnes, les couleurs personnalisées et les palettes de séries. Le résultat est un tableau de bord Kibana entièrement fonctionnel, et non une capture d'écran ou une intégration.

Puis-je importer un tableau de bord Kibana existant dans example-mcp-dashbuilder pour une édition assistée par l'IA ? Oui. Il suffit de fournir l'identifiant du tableau de bord Kibana pour le récupérer, convertir ses visualisations Lens en configurations de graphique modifiables et les charger dans example-mcp-dashbuilder. Vous pouvez ensuite modifier le tableau de bord en langage naturel et le réexporter vers Kibana.

Quels sont les clients MCP compatibles avec example-mcp-dashbuilder ? example-mcp-dashbuilder fonctionne avec n'importe quel client compatible MCP, y compris Cursor, Claude Desktop, Claude.ai, et VS Code avec Copilot. Il prend en charge les protocoles stdio et HTTP, sans aucun serveur local ni configuration de port nécessaire.

Quels sont les types de graphiques pris en charge par example-mcp-dashbuilder ? La version actuelle prend en charge six types de graphiques : à barres, linéaire, à aires, en camembert, métriques (avec sparkline) et cartes thermiques. Les ajouts prévus incluent les graphiques à jauge, en anneau, arborescents, tables de données et nuages de tags afin de correspondre à l'ensemble des fonctionnalités de Kibana Lens.

De quoi ai-je besoin pour exécuter example-mcp-dashbuilder ? Vous avez besoin de Node.js 22 ou version ultérieur, d'une instance Elasticsearch (locale ou Elastic Cloud) et d'un client compatible MCP. Définissez les variables d'environnement ES_NODE, ES_API_KEY (ou ES_USERNAME/ES_PASSWORD) et KIBANA_URL. Pour Claude Desktop, téléchargez le fichier .mcpb depuis les versions GitHub et double-cliquez dessus pour l'installer.

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.

Notre objectif était de passer à une approche automatisée et adaptative capable de gérer à la fois l’analyse des logs (extraction de champs) et le partitionnement des logs (identification de la source). Nous avons émis l’hypothèse que les grands modèles de langage (LLM), grâce à leur compréhension inhérente de la syntaxe du code et des modèles sémantiques, pourraient automatiser ces tâches avec une intervention humaine minimale.

Nous sommes heureux d'annoncer que cette fonctionnalité est déjà disponible dans Streams.

Description de l'ensemble de données

Nous avons choisi une Loghubcollection de logs à des fins de PoC. Pour notre enquête, nous avons sélectionné des échantillons représentatifs issus des domaines clés suivants :

• Systèmes distribués : nous avons utilisé le HDFS (Hadoop Distributed File System) et les ensembles de données Spark. Ils contiennent un mélange de messages d'information, de débogage et d'erreur typiques des plateformes de big data.

• Applications serveur et web : les logs des serveurs web Apache et d’OpenSSH ont constitué une source précieuse d’informations sur les accès, les erreurs et les événements liés à la security. Ces éléments sont essentiels pour surveiller le trafic web et détecter les menaces potentielles.

• Systèmes d'exploitation : nous avons inclus les logs de Linux et Windows. Ces ensembles de données représentent les événements communs et semi-structurés au niveau du système auxquels les équipes d’opérations sont confrontés quotidiennement.

• Systèmes mobiles : pour garantir que notre modèle puisse gérer les logs provenant d'environnements mobiles, nous avons inclus l'ensemble de données Android. Ces logs sont souvent volumineux et capturent un large éventail d'activités au niveau de l'application et du système sur les appareils mobiles.

• Superordinateurs : pour tester les performances sur des environnements de calcul haute performance (HPC), nous avons intégré l'ensemble de données BGL (Blue Gene/L), qui présente des logs très structurés avec une terminologie de domaine spécifique.

L'un des principaux avantages de la collection Loghub est que les logs sont en grande partie non nettoyés et non étiquetés, reflétant un environnement de production en direct bruyant avec une architecture de microservices.

Exemples de logs :

De plus, nous avons créé un cluster Kubernetes avec une application web typique et une base de données pour extraire des logs supplémentaires dans le domaine le plus courant.

Exemple de champs de log communs : horodatage, niveau de log (INFO, AVERTISSEMENT, ERREUR), source, message.

Analyse de logs en few-shot avec un LLM

Notre premier ensemble d'expériences s'est concentré sur une question fondamentale : Un LLM peut-il identifier de manière fiable les champs clés et générer des règles de parsing cohérentes pour les extraire ?

Nous avons demandé à un modèle d'analyser des échantillons de journaux bruts et de générer des règles d'analyse de journaux sous forme d'expressions régulières (regex) et de formats Grok. Nos résultats ont montré que cette approche présente beaucoup de potentiel, mais aussi des défis importants dans sa mise en œuvre.

Confiance élevée et conscience du contexte

Les premiers résultats étaient prometteurs. Le LLM a démontré une forte capacité à générer des règles d'analyse qui correspondaient aux exemples fournis avec une grande confiance. Outre la simple correspondance de modèles, le modèle a démontré une capacité de compréhension des logs — il pouvait identifier et nommer correctement la source du log (par exemple, application de suivi de santé, application web Nginx, base de données Mongo).

Le dilemme des échantillons d'entrée « Boucles d'or »

Nos expériences ont rapidement mis en évidence un manque important de robustesse en raison d'une sensibilité extrême à l'échantillon d'entrée. Les performances du modèle fluctuent considérablement en fonction des exemples de logs spécifiques inclus dans l'invite. Nous avons observé un problème de similitude des logs, dans lequel l'échantillon de log devait inclure juste assez de logs diversifiés  :

• Trop homogène (surapprentissage) : si les logs d'entrée sont trop similaires, le LLM a tendance à surspécifier. Il traite les données variables — telles que des noms spécifiques de classes Java dans une trace de pile — comme des parties statiques du modèle. Il en résulte des règles fragiles qui ne couvrent qu'une infime partie des logs et extraient des champs inutilisables.

• Trop hétérogène (confusion) : à l'inverse, si l'échantillon contient une variance de formatage significative, ou pire, des « logs poubelles » comme des barres de progression, des tableaux de mémoire ou de l'art ASCII, le modèle peine à trouver un dénominateur commun. Il en vient souvent à générer des regex complexes et cassés ou à généraliser paresseusement toute la ligne en un seul champ de bloc de message.

La contrainte de la fenêtre contextuelle

Nous avons également rencontré un goulot d'étranglement au niveau de la fenêtre contextuelle. Lorsque les logs d'entrée étaient longs, hétérogènes, ou riches en champs extractibles, la sortie du modèle se détériorait souvent, devenant « désordonnée » ou trop longue pour s'intégrer dans la fenêtre de contexte de sortie. Bien entendu, le découpage aide dans ce cas. En divisant les logs à l'aide de délimiteurs basés sur les caractères et sur les entités, nous pourrions aider le modèle à se concentrer sur l'extraction des champs principaux sans être submergé par le bruit.

L'écart de cohérence et de standardisation

Même lorsque le modèle a généré des règles avec succès, nous avons noté de légères incohérences :

• Variantes de dénomination des services : le modèle propose différents noms pour une même entité (par exemple, en étiquetant la source « Spark », « Apache Spark » et « Spark Log Analytics » dans différentes exécutions).

• Variations dans la dénomination des champs : les noms des champs n'étaient pas normalisés (par exemple, id vs. service.id vs. device.id). Nous avons normalisé les noms en utilisant une nomenclature de champ Elastic standardisée.

• Variance de résolution : la résolution de l'extraction de champ variait en fonction de la similarité des logs d'entrée les uns avec les autres.

Empreinte de format de log

Pour relever le défi de la similarité des logs, nous introduisons une heuristique haute performance : l'empreinte de format de log (LFF).

Au lieu d'introduire des logs bruts et bruyants directement dans un LLM, nous appliquons d'abord une transformation déterministe pour révéler la structure sous-jacente de chaque message. Cette étape de pré-traitement rend abstraites les données variables, générant une « empreinte » simplifiée qui nous permet de regrouper les logs connexes.

La logique de mapping est simple pour garantir la vitesse et la cohérence :

1. Abstraction des chiffres : toute séquence de chiffres (0-9) est remplacée par un simple ‘0’.

2. Abstraction du texte : toute séquence de caractères alphabétiques avec des espaces blancs est remplacée par un seul « a ».

3. Normalisation des espaces blancs : toutes les séquences d'espaces blancs (espaces, tabulations, nouvelles lignes) sont regroupées en un seul espace.

4. La préservation des symboles : la ponctuation et les caractères spéciaux (par exemple, :, [, ], /) sont préservés, car ils sont souvent les indicateurs les plus forts de la structure des logs.

Nous introduisons l'approche de mapping des logs. Les modèles de mapping de base comprennent les éléments suivants :

• Chiffres 0 à 9, quelle que soit leur longueur, de > à « 0 ».

• Texte (caractères alphabétiques avec espaces) de n'importe quelle longueur -> à 'a'.

• Espaces blancs, onglets et nouvelles lignes : > pour un seul espace.

Examinons un exemple de la manière dont ce mapping nous permet de transformer les logs.

Par conséquent, nous obtenons les masques de log suivants :

Remarquez les empreintes digitales des deux premiers logs. Malgré des horodatages, des classes de sources et un contenu de message différents, leurs préfixes (0/0/0 0:0:0 a a.a:) sont identiques. Cet alignement structurel nous permet de regrouper automatiquement ces logs dans le même cluster.

Le troisième log, cependant, produit une empreinte digitale complètement divergente (0-0-0...). Cela nous permet de le séparer algorithmiquement du premier groupe avant même d' invoquer un LLM.

Partie bonus : implémentation instantanée avec ES|QL

C'est aussi simple que de passer cette requête dans Discover.

Décomposition de la requête :

FROM loghub : cible notre index contenant les données de journal brut.

EVAL pattern = ... : la logique du mapping de base. Nous enchaînons les fonctions REPLACE pour effectuer l'abstraction (par exemple, les chiffres en '0', le texte en 'a', etc.) et enregistrons le résultat dans un champ "pattern".

STATS [column1 =] expression1, … BY SUBSTRING(pattern, 0, 15) :

Ceci est une étape du clustering. Nous regroupons les logs qui partagent les 15 premiers caractères de leur schéma et créons des champs agrégés tels que le nombre total de logs par groupe, la liste des sources de données des logs, le préfixe du schéma, 3 exemples de logs

SORT total_count DESC | LIMIT 100 : affiche les 100 schémas de log les plus fréquents

Les résultats de la requête sur LogHub sont affichés ci-dessous :

Comme démontré dans la visualisation, cette approche « sans LLM » partitionne les logs avec une grande précision. Elle a réussi à clusterer complètement 10 sources de données sur 16 (basées sur les étiquettes LogHub) (>90 %) et a atteint un clustering majoritaire dans 13 sources sur 16 (>60 %) — le tout sans nécessiter de nettoyage, de prétraitement ou de réglage fin supplémentaire.

L'empreinte digitale du format du log offre une alternative pragmatique et à fort impact, ainsi qu'un complément aux solutions de ML sophistiquées telles que l'analyse du modèle de log. Il offre des informations immédiates sur les relations entre les logs et gère efficacement les grands ensembles de logs.

• Polyvalence en tant que primitif

Grâce à la mise en œuvre d'ES|QL, LFF sert à la fois d'outil autonome pour des diagnostics/visualisations rapides des données, et d'élément de base dans les pipelines d'analyse des journaux pour les cas d'utilisation à grand volume.

• Flexibilité

LFF est facile à personnaliser et à étendre pour capturer des modèles spécifiques, c'est-à-dire des nombres hexadécimaux et des adresses IP.

• Stabilité déterministe

Contrairement aux algorithmes de clustering basés sur le ML, la logique LFF est simple et déterministe. Les nouveaux logs entrants n'affectent pas rétroactivement les clusters de logs existants.

• Performance et mémoire

Il nécessite peu de mémoire, pas de formation ni de GPU, ce qui le rend idéal pour les environnements à haut débit et en temps réel.

Combiner une empreinte digitale au format log avec un LLM

Pour valider l'architecture hybride proposée, chaque expérience contenait un sous-ensemble aléatoire de 20 % des logs de chaque source de données. Cette contrainte simule un environnement de production réel où les logs sont traités par lots plutôt que comme un bloc monolithique de données historiques.

L’objectif était de démontrer que le LFF agit comme une couche de compression efficace. Nous avons cherché à prouver que des règles d’analyse à haute couverture pouvaient être générées à partir de petits échantillons sélectionnés et généralisées avec succès à l’ensemble de l’ensemble de données.

Pipeline d'exécution

Nous avons mis en œuvre un pipeline à plusieurs étapes qui filtre, regroupe et applique un échantillonnage stratifié aux données avant qu'elles n'atteignent le LLM.

1. clustering hiérarchique en deux étapes

• Sous-classes (correspondance exacte) : les logs sont agrégés par empreintes identiques. Tous les logs d'une sous-classe partagent exactement la même structure de format.

• Nettoyage des aberrations. Nous écartons toutes les sous-classes qui représentent moins de 5 % du volume total des logs. Cela garantit que le LLM se concentre sur le signal dominant et ne sera pas distrait par le bruit ou les logs malformés.

• Métaclasses (correspondance avec le préfixe) : les sous-classes restantes sont regroupées en métaclasses en fonction des N premiers caractères de l'empreinte digitale du format. Nous avons choisi N=5 pour le Log parsing et N=15 pour le Log partitioning lorsque les sources de données sont inconnues.

2. Échantillonnage stratifié. Une fois l'arbre hiérarchique établit, nous construisons l'échantillon de log pour le LLM. L'objectif stratégique est de maximiser la couverture de variance tout en minimisant l'utilisation des jetons.

• Nous sélectionnons des logs représentatifs de chaque sous-classe valide au sein de la métaclasse plus large.

• Pour gérer un cas limite de sous-classes trop nombreuses, nous appliquons un échantillonnage aléatoire pour s'adapter à la taille de la fenêtre cible.

3. Génération de règles Finally, nous demandons au LLM de générer une règle d'analyse regex qui convient à tous les logs dans l'échantillon fourni pour chaque Métaclasse. Pour notre PoC, nous avons utilisé le mini-modèle GPT-4o.

Résultats expérimentaux et observations

Nous avons atteint une précision de parsing de 94 % et une précision de partitionnement de 91 % sur l'ensemble de données Loghub.

La matrice de confusion ci-dessus illustre les résultats du partitionnement des logs. L’axe vertical représente les sources de données réelles, et l’axe horizontal représente les sources de données prédites. L'intensité de la carte thermique correspond au volume de logs, les vignettes plus claires indiquant un nombre plus élevé. L'alignement diagonal démontre la haute fidélité du modèle dans l'attribution des sources, avec un minimum de dispersion.

Nos informations sur les benchmarks de performance :

• Base optimale : une fenêtre contextuelle de 30 à 40 échantillons de logs par catégorie s'est avérée être le « point idéal », produisant régulièrement une analyse syntaxique robuste avec des motifs Regex et Grok.

• Minimisation de l'entrée : nous avons réduit la taille de l'entrée à 10 logs par catégorie pour les motifs Regex et n'avons observé qu'une baisse de 2 % des performances d'analyse, ce qui confirme que l'échantillonnage basé sur la diversité est plus critique que le volume brut.

Elastic Agent Builder simplifie la création d’agents IA connectés aux données. Nous vous expliquons comment faire dans cet article de blog. Voici toutes les étapes pour créer un agent avec un outil MCP capable d’accéder aux données stockées dans Elastic. Nous utiliserons ensuite le SDK Strands Agents et ses fonctionnalités Agent2Agent (A2A) pour piloter l’agent. Le SDK Strands Agents est une plateforme de développement d’IA multi-agents, conçue pour créer des applications autonomes avec juste ce qu’il faut de code pour obtenir les résultats souhaités.

Construisons un agent IA capable de jouer à RPS+, une version revisitée du jeu classique « Pierre, feuille, ciseaux », enrichie de quelques choix supplémentaires pour les joueurs.

Produits requis

Voici ce dont vous avez besoin pour suivre les étapes décrites dans cet article de blog :

• Un éditeur de texte fonctionnant sur votre ordinateur local

  • Nous utiliserons Visual Studio Code pour suivre les exemples présentés dans cet article de blog.

• Python 3.10 ou version supérieure installé localement sur votre machine

Créez un projet sans serveur

La première étape consiste à créer un projet Elasticsearch Serverless, qui inclut Elastic Agent Builder.

Accédez à cloud.elastic.co et créez un nouveau projet Elasticsearch Serverless.

Créer un index et ajouter des données

Ensuite, nous allons ajouter des données à notre projet Elasticsearch. Ouvrez les Developer Tools pour exécuter des commandes : nous allons créer un nouvel index et y insérer des données. Dans le menu principal, sélectionnez Developer Tools.

Copiez-collez la commande PUT suivante dans la zone de saisie de requêtes de la console Developer Tools. Cette commande crée un index Elasticsearch nommé « game-docs ».

Cliquez sur le bouton Envoyer la requête à droite de l’instruction dans Developer Tools. Une notification doit confirmer que l’index game-docs a bien été créé, dans la zone de réponse de Developer Tools.

L’index nommé game-docs est l’endroit idéal pour stocker les données du jeu que nous créons. Ajoutons maintenant un document nommé rps++-md dans cet index, contenant toutes les données nécessaires au jeu. Copiez-collez la commande PUT suivante dans la console Developer Tools.

Cliquez sur le bouton Envoyer la requête à côté de l’instruction pour l’exécuter et ajouter le document rps++-md à l’index game-docs.

Nous avons maintenant des données à interroger, et avec Agent Builder, c’est plus simple que jamais.

Dans le menu de navigation principal, sélectionnez Agents.

Ensuite, il vous suffit de demander à l'agent Elastic AI par défaut, « Quelles données ai-je ? »

L’agent IA Elastic analyse les données et fournit une explication claire des informations disponibles.

Créer un outil

Nous avons maintenant des données dans Elastic, mettons-les à profit. Agent Builder inclut un support natif pour créer des outils MCP, qui permettent aux agents d’accéder aux données dont ils ont besoin pour disposer du bon contexte. Créons un outil simple pour récupérer les données de notre jeu.

Cliquez sur le menu des actions dans Agent Builder.

Dans les options du menu, sélectionnez Afficher tous les outils.

Cliquez sur + Nouvel outil.

Dans le formulaire Créer un outil , sélectionnez ES|QL Saisissez l'outil et entrez les valeurs suivantes.

Pour Tool ID :

Pour Description :

Pour Configuration, saisissez la requête suivante dans la zone de texte ES|QL Query :

Le formulaire Créer outil complété devrait ressembler à ceci. Cliquez sur Enregistrer pour créer l'outil.

Un nouvel outil a été ajouté à notre tableau de bord. Les outils ne sont pas faits pour rester inutilisés : ils doivent être mis à profit. Créons un agent qui saura exploiter notre nouvel outil personnalisé.

Créez un agent et attribuez-lui un outil

Créer un agent est d’une simplicité rafraîchissante avec Agent Builder. Il vous suffit de saisir quelques instructions pour l’agent, avec quelques détails : c’est tout. Créons un agent dès maintenant.

Cliquez sur Gérer les agents.

Cliquez + Nouvel agent.

Saisissez les informations suivantes dans le formulaire Nouvel agent.

Pour l'identification de l'agent, saisissez le texte ci-dessous :

Dans la section texte Instructions personnalisées , saisissez les instructions suivantes :

Pour le Nom d'affichage, entrez le texte ci-dessous :

Pour la Description de l’affichage, saisissez le texte ci-dessous :

Donnez à l'agent l'outil personnalisé que nous avons créé précédemment en cliquant sur l'onglet Outils.

Sélectionnez uniquement example.get_game_docs, l'outil que nous avons créé précédemment.

Cliquez sur Enregistrer pour créer le nouvel agent.

Testons notre nouvel agent. Un lien pratique vous permet de démarrer une conversation avec n’importe quel agent de la liste.

Saisissez simplement « start game » pour lancer la partie. Ça fonctionne !

L’agent affiche son choix pour la partie en haut de sa réponse. Cela permet de visualiser le choix de l’agent et de vérifier que le jeu fonctionne comme prévu. Cela dit, connaître le choix de votre adversaire avant de jouer n’est pas idéal pour une partie de pierre-feuille-ciseaux. Pour peaufiner le jeu, on peut utiliser une plateforme d’orchestration d’agents capable de les piloter via du code.

Le SDK Strands Agents entre en scène.

Strands Agents SDK

Si vous souhaitez essayer de nouveaux frameworks de développement d'agents, le SDK Strands Agents vaut la peine d'être essayé. Le SDK Strands Agents a été publié par AWS (mai 2025) en tant qu'implémentation Python open source, et il existe désormais une version Typescript.

Premiers pas avec le SDK Strands Agents en Python

Lancez vos environnements de développement : nous allons cloner et exécuter une application d’exemple qui utilise Strands Agents pour piloter l’agent RPS+ via le protocole A2A. Créons une version personnalisée du jeu RPS+ dans laquelle le choix de l’agent est révélé après votre propre décision, afin de préserver l’effet de surprise et le côté ludique du jeu Pierre-Feuille-Ciseaux.

Sur votre ordinateur local, ouvrez Visual Studio Code et ouvrez un nouveau terminal.

Dans le terminal que vous venez d’ouvrir, exécutez la commande suivante pour cloner le dépôt Elasticsearch Labs :

Exécution de la commande cd suivante pour changer de répertoire dans le répertoire Elasticsearch Labs :

Ensuite, exécutez cette commande pour ouvrir le dépôt dans Visual Studio Code :

Dans l'explorateur de fichiers de Visual Studio, développez les dossiers supporting-blog-content et agent-builder-a2a-strands-agents , puis ouvrez le fichier elastic_agent_builder_a2a_rps+.py. Voici à quoi ressemble le fichier ouvert dans Visual Studio Code :

Voici le contenu de elastic_agent_builder_a2a_rps+.py que vous devriez voir dans votre éditeur de texte :

Examinons ce qui se passe dans ce code. En commençant par la méthode main() , le code commence par accéder aux variables d’environnement pour l’URL de l’agent et la clé API. Ensuite, nous utilisons ces valeurs pour créer un httpx client que nous pouvons utiliser pour obtenir la carte d'agent de l'agent. Le client utilise ensuite les détails de la carte d’agent pour envoyer une demande de « démarrer la partie » à l’agent. Il est intéressant de noter que nous incluons la valeur random_game_object dans la requête "start game". Cette valeur est un nombre aléatoire généré par le module aléatoire de la bibliothèque standard de Python. La raison pour laquelle nous faisons cela est qu'il s'avère que les puissants LLM (qui rendent possibles les agents IA) ne sont pas très doués pour le hasard. Pas de problème, Python vient à la rescousse.

En poursuivant dans le code, une fois que l’agent a répondu à la requête start game, le code extrait le choix de l’agent et le stocke dans la variable agent_choice. Le reste de la réponse est affiché sous forme de texte à destination de l’utilisateur final. L’utilisateur est ensuite invité à saisir son propre choix d’objet de jeu, qui est envoyé à l’agent. Le code affiche ensuite le choix de l’agent, ainsi que le résultat final du jeu selon l’agent.

Définir l’URL de votre agent et la clé API comme variables d’environnement

Comme l’application d’exemple sera exécutée en local, nous devons fournir au SDK Strands Agents une URL A2A et une clé API pour communiquer avec notre agent. L’application d’exemple utilise un fichier nommé .env pour stocker ces valeurs.

Faites une copie du fichier env.example et nommez le nouveau fichier .env

Retournez dans Elastic Agent Builder pour récupérer les deux valeurs nécessaires.

Sélectionnez Afficher tous les outils dans le menu d'action d'Agent Builder en haut à droite de la page.

Cliquez sur le menu déroulant MCP Server en haut de la page Outils et sélectionnez Copier l’URL MCP Server.

Collez l’URL du serveur MCP dans le fichier .env fichier en remplacement de la valeur d'espace réservé <YOUR-ELASTIC-AGENT-BUILDER-URL> . Nous devons maintenant apporter une modification à l'URL, à savoir remplacer le texte final « mcp » par « a2a », car le protocole A2A est celui que le SDK Agent Strands utilisera pour communiquer avec l'agent exécuté dans Elastic Agent Builder.

L’URL modifiée devrait ressembler à ceci :

L'autre valeur dont nous avons besoin d'obtenir pendant que nous sommes ici dans Elastic Cloud est une clé d'API. Cliquez sur Elasticsearch dans la navigation principale.

Cliquez sur le bouton Copier la clé API pour copier la clé API.

Maintenant, de retour dans Visual Studio Code, collez la Clé d'API dans le fichier .env fichier pour remplacer le texte de l'espace réservé <YOUR-ELASTIC-API-KEY> . Votre .env Le fichier devrait ressembler à ceci :

Lancer l’application d’exemple

Ouvrez un nouveau terminal dans Visual Studio Code.

Commencez par exécuter la commande cd suivante dans le terminal :

Exécutez la commande suivante pour créer un environnement virtuel Python.

Selon le système d’exploitation de votre machine, exécutez la commande suivante pour activer l’environnement virtuel.

• MacOS/Linux

• Windows

L’application d’exemple utilise le SDK Strands Agents, et nous arrivons à l’étape où il faut l’installer. Exécutez la commande suivante pour installer le SDK Strands Agents avec toutes ses dépendances Python.

Il est temps de dégager la rampe de lancement et de commencer le compte à rebours. Nous sommes prêts à lancer cette application. Reculez un peu. Lançons-la avec la commande suivante :

Le défi ? Une partie de RPS+ vous attend. Bravo et bonne chance pour la suite !

Créez vos applications d'IA avec un contexte pertinent

La création d'un agent IA fait désormais partie de vos compétences. Vous avez vu aussi combien il est facile d'utiliser Elastic Agent Builder via A2A dans des frameworks de développement d'agents comme les SDK Strands Agents. Essayez Elastic pour créer des agents IA connectés au contexte pertinent dans vos données personnalisées.

Qu'est-ce que LangGraph ?

LangGraph est un framework pour construire des agents d’IA et les orchestrer dans un workflow afin de créer des applications assistées par l’IA. LangGraph dispose d’une architecture de nodes où nous pouvons déclarer des fonctions représentant des tâches et les assigner comme nodes du workflow. Le résultat de l'interaction de plusieurs nodes sera un graphe. LangGraph fait partie du LangChain écosystème plus large, qui fournit des outils pour construire des systèmes d'IA modulaires et composables.

Pour mieux comprendre l’utilité de LangGraph, résolvons une situation problématique en l’utilisant.

Aperçu de la solution

Dans une société de capital-risque, les investisseurs ont accès à une vaste base de données avec de nombreuses options de filtrage, mais lorsqu'ils veulent combiner des critères, cela devient difficile et lent. Il se peut donc que certaines start-ups pertinentes ne soient pas trouvées pour l'investissement. Cela conduit à passer beaucoup de temps à essayer d'identifier les meilleurs candidats, voire à perdre des opportunités.

Avec LangGraph et Elasticsearch, vous pouvez effectuer des recherches filtrées en utilisant le langage naturel, ce qui évite aux utilisateurs de devoir construire manuellement des requêtes complexes avec des dizaines de filtres. Pour plus de flexibilité, le workflow choisit automatiquement, en fonction de l'entrée de l'utilisateur, entre deux types de requêtes :

• Requêtes d’investissement : elles visent les données financières et de financement des start-up, notamment les tours de table, la valorisation ou le CA. Exemple : « Trouvez des startups avec un financement de série A ou série B entre 8 millions et 25 millions de dollars et un chiffre d’affaires mensuel supérieur à 500 000 $. »

• Requêtes axées sur le marché: elles se concentrent sur les secteurs d’activité, les marchés géographiques ou les modèles économiques, en aidant à identifier des opportunités dans des secteurs ou régions spécifiques. Exemple : « Trouvez des startups de la fintech et de la santé à San Francisco, New York ou Boston. »

Pour garantir la robustesse des requêtes, nous allons faire en sorte que le LLM génère des modèles de recherche au lieu de requêtes DSL complètes. De cette façon, vous obtenez toujours la requête souhaitée, et le LLM n'a qu'à compléter les informations manquantes sans avoir à élaborer la requête dont vous avez besoin à chaque fois.

Ce dont vous avez besoin pour commencer

• Clé API Elasticsearch

• Clé d'API OpenAPI

• Node 18 ou version ultérieure

Instructions étape par étape

Dans cette section, voyons comment l'application sera présentée. Nous utiliserons TypeScript, un sur-ensemble de JavaScript qui ajoute des types statiques. Cela rend le code plus fiable, plus facile à maintenir et plus sûr en détectant les erreurs dès le début, tout en assurant une compatibilité totale avec JavaScript.

Le flux des nœuds se présentera comme suit :

L'image ci-dessus est générée par LangGraph et représente le workflow qui définit l'ordre d'exécution et la logique conditionnelle entre les nodes :

• decideStrategy : utilise un LLM pour rechercher la requête de l'utilisateur et choisir entre deux stratégies de recherche spécialisées, axée sur l'investissement ou axée sur le marché.

• PrepareInvestmentSearch : extrait les valeurs de filtre de la requête et crée un modèle prédéfini mettant l'accent sur les paramètres financiers et liés au financement.

• PrepareMarketSearch: extrait également les valeurs des filtres, mais crée dynamiquement des paramètres en mettant l'accent sur le marché, le secteur et le contexte géographique.

• ExecuteSearch : envoie la recherche construite à Elasticsearch à l'aide d'un modèle de recherche et extrait les documents de démarrage correspondants.

• VisualiserResults : met en forme les résultats finaux sous la forme d'un résumé clair et lisible présentant les principaux attributs de la start-up tels que le financement, le secteur d'activité et le chiffre d'affaires.

Ce flux comprend un branchement conditionnel, fonctionnant comme une instruction « si », qui détermine s'il faut rechercher le chemin d'investissement ou de recherche de marché en fonction de l'entrée de l'utilisateur. Cette logique de décision, pilotée par le LLM, rend le workflow adaptatif et conscient du contexte, un mécanisme que nous explorerons plus en détail dans les sections suivantes.

État de LangGraph

Avant de voir chaque node individuellement, nous devons comprendre comment les nodes communiquent et partagent les données. Pour cela, LangGraph nous permet de définir l'état du workflow. Cela définit l'état partagé qui sera transmis entre les nodes.

L’état agit comme un conteneur partagé stockant les données intermédiaires du workflow : il enregistre d’abord la requête en langage naturel de l’utilisateur, puis la stratégie de recherche choisie, les paramètres prêts pour Elasticsearch, les résultats de recherche et, pour finir, le résultat formaté.

Cette architecture permet à chaque nœud de lire et de modifier l’état, ce qui garantit un flux d’informations constant, de l’entrée de l’utilisateur jusqu’à la visualisation finale.

Configurer l'application

Tout le code de cette section se trouve dans le dépôt elasticsearch-labs.

Dans le dossier où l’application sera installée, ouvrez un terminal et initialisez une application Node.js avec la commande :

Nous pouvons maintenant installer les dépendances nécessaires à ce projet :

• @elastic/elasticsearch: Permet de gérer les requêtes Elasticsearch, comme l’ingestion et la récupération des données.

• @langchain/langgraph: Dépendance JS pour fournir tous les outils LangGraph.

• @langchain/openai: Client OpenAI LLM pour LangChain.

• @langchain/core : Offre les composantes de base essentielles aux applications LangChain, notamment les modèles d’invite.

• dotenv: Dépendance nécessaire pour utiliser les variables d'environnement en JavaScript.

• zod: Dépendance au type de données.

@types/node tsx typescript nous permet d'écrire et d'exécution du code TypeScript.

Créez maintenant les fichiers suivants :

• elasticsearchSetup.ts: Créera les mapping d'index, chargera les données à partir d'un fichier JSON, et ingérera les données dans Elasticsearch.

• main.ts: inclura l’application LangGraph.

• .env: fichier pour stocker les variables d’environnement

Dans le fichier .env, ajoutons les variables d’environnement suivantes :

La clé APIK de l'OpenAPI ne sera pas utilisée directement dans le code ; elle sera utilisée en interne par la bibliothèque @langchain/openai.

Toute la logique concernant la création de mappages, la création de modèles de recherche et l’ingestion des ensembles de données se trouve dans le fichier elasticsearchSetup.ts. Dans les prochaines étapes, nous nous concentrerons sur le fichier main.ts. Vous pouvez également consulter l'ensemble de données pour mieux comprendre l'aspect des données sur le site dataset.json.

Application LangGraph

Dans le fichier main.ts, importons certaines dépendances nécessaires pour consolider l'application LangGraph. Dans ce fichier, vous devez également inclure les fonctions node et la déclaration d’état. La déclaration du graphe sera effectuée dans une méthode main dans les prochaines étapes. Le fichier elasticsearchSetup.ts contiendra les aides Elasticsearch que nous allons utiliser dans les Nodes dans les étapes suivantes.

Ainsi que nous l’avons vu, le client LLM sera mobilisé pour générer les paramètres du modèle de recherche Elasticsearch en fonction de la question de l’utilisateur.

La méthode ci-dessus génère l'image du graphe au format png et utilise l'API Mermaid.INK en arrière-plan. Ceci est utile si vous souhaitez voir comment les nodes de l'application interagissent dans le cadre d'une visualisation stylisée.

Nodes LangGraph

À présent, voyons chaque node en détail :

Node decideSearchStrategy

Le node decideSearchStrategy analyse les entrées de l'utilisateur et détermine s'il convient d'effectuer une rechercher axée sur les investissements ou axée sur le marché. Il utilise un LLM avec un schéma de sortie structuré (défini avec Zod) pour classer le type de requête. Avant de prendre la décision, il récupère les filtres disponibles de l'index en utilisant une agrégation, en garantissant que le modèle dispose d'un contexte à jour sur les industries, les localisations et les données de financement.

Pour extraire les valeurs possibles des filtres et les envoyer au LLM, utilisons une requête d'agrégation pour les récupérer directement depuis l'index Elasticsearch. Cette logique est allouée dans une méthode appelée getAvailableFilters:

Avec la requête d'agrégation ci-dessus, nous avons les résultats suivants :

Découvrez tous les résultats ici.

Pour les deux stratégies, nous allons utiliser la recherche hybride afin de détecter à la fois la partie structurée de la question (filtres) et les parties plus subjectives (sémantique). Voici un exemple des deux requêtes utilisant des modèles de recherche :

Regardez les requêtes détaillées dans le fichier elasticsearchSetup.ts . Dans le node suivant, il sera décidé laquelle des deux requêtes sera utilisée :

Nodes prepareInvestmentSearch et prepareMarketSearch

Les deux nœuds utilisent une fonction d’assistance partagée, extractFilterValues, qui exploite le LLM pour identifier les filtres pertinents mentionnés dans les entrées de l’utilisateur, tels que l’industrie, la localisation, le stade de financement, le modèle économique, etc. Nous utilisons ce schéma pour construire notre modèle de recherche.

Selon l'intention détectée, le workflow sélectionne l'un des deux chemins :

prepareInvestmentSearch : définit des paramètres de rechercher orientés sur la finance, notamment l''étape du financement, le montant du financement, les informations relatives à l''investisseur et au renouvellement. Vous pouvez trouver le modèle complet de requête dans le fichier elasticsearchSetup.ts :

prepareMarketSearch : crée des paramètres orientés vers le marché, axés sur les industries, les régions géographiques et les modèles économiques. Voir l’intégralité de la requête dans le fichier elasticsearchSetup.ts :

Node executeSearch

Ce node prend les paramètres de rechercher générés à partir de l'état et les envoie d'abord à Elasticsearch, en utilisant l'API _render pour visualiser la requête à des fins de débogage, puis envoie une demande pour récupérer les résultats.

Node visualizeResults

Enfin, ce node affiche les résultats d’Elasticsearch.

Par programmation, l'ensemble du graphe ressemble à ceci :

Comme vous pouvez le constater, nous avons une arête conditionnelle où l'application décide quel « chemin » ou node sera exécuté ensuite. Cette fonctionnalité est utile lorsque les workflows nécessitent une logique de branchement, comme le choix entre plusieurs outils ou l’inclusion d’une étape humaine dans la boucle.

Maintenant que vous maîtrisez les fonctionnalités clés de LangGraph, nous pouvons préparer l’application qui exécutera le code :

Rassemblons tout dans une méthode main , ici nous déclarons le graphe avec tous les éléments sous la variable workflow :

La variable de requête simule l'entrée utilisateur saisie dans une barre de recherche hypothétique :

D’après la phrase en langage naturel « Trouvez des startups avec un financement de la série A ou de la série B entre 8 millions et 25 millions de dollars et un chiffre d’affaires mensuel supérieur à 500 000 $ », tous les filtres seront extraits.

Enfin, invoquez la méthode principale :

Résultats

Pour l'entrée envoyée, l'application choisit le chemin axé sur l'investissement et, par conséquent, nous pouvons voir la requête Elasticsearch générée par le workflow, qui extrait les valeurs et les plages de l'entrée de l'utilisateur. Nous pouvons également voir la requête envoyée à Elasticsearch avec les valeurs extraites appliquées, et enfin, les résultats formatés par le nœud visualizeResults avec les résultats.

Testons maintenant le node axé sur le marché en utilisant la requête « Trouver des startups fintech et de la santé à San Francisco, New York ou Boston » :

Enseignements

Pendant le processus d'écriture, j'ai appris :

• Nous devons montrer au LLM les valeurs exactes des filtres, sinon nous attendons de l'utilisateur qu'il saisisse les valeurs exactes des éléments. Pour une faible cardinalité, cette approche convient, mais lorsque la cardinalité est élevée, nous avons besoin d'un mécanisme pour filtrer les résultats

• Utiliser des modèles de recherche rend les résultats bien plus cohérents que de laisser le LLM écrire la requête Elasticsearch, et c’est aussi plus rapide

• Les arêtes conditionnelles constituent un mécanisme puissant pour construire des applications avec de multiples variantes et chemins de branchement.

• La sortie structurée est extrêmement utile lors de la génération d'informations avec des LLM, car elle applique des réponses prévisibles et sécurisées. Cela améliore la fiabilité et réduit les erreurs d'interprétation.

La combinaison de la recherche sémantique et de la recherche structurée par le biais d'une recherche hybride produit des résultats meilleurs et plus pertinents, en équilibrant précision et compréhension du contexte.

Conclusion

Dans cet exemple, nous combinons LangGraph.js avec Elasticsearch pour créer un workflow dynamique capable d'interpréter les requêtes en langage naturel et de décider entre des stratégies de recherche axées sur la finance ou le marché. Cette approche réduit la complexité de la création de requêtes manuelles tout en améliorant la flexibilité et la précision pour les analystes en capital-risque.

Cet article vous montrera comment construire un agent d'IA pour les RH en utilisant GPT-OSS et Elastic Agent Builder. L'agent peut répondre à vos questions sans envoyer de données à OpenAI, Anthropic ou tout autre service externe.

Nous allons utiliser LM Studio pour servir GPT-OSS localement et le connecter à Elastic Agent Builder.

À la fin de cet article, vous disposerez d'un agent d'IA personnalisé capable de répondre à des questions en langage naturel sur les données de vos employés, tout en conservant un contrôle total sur vos informations et votre modèle.

Produits requis

Pour cet article, vous avez besoin de :

• Elastic Cloud hébergé 9.2, déploiement sans serveur ou local.

• Machine avec 32 Go de RAM recommandée (minimum 16 Go pour GPT-OSS 20B)

• LM Studio installé

• Docker Desktop installé

Pourquoi utiliser GPT-OSS ?

Avec un LLM local, vous avez la possibilité de le déployer dans votre propre infrastructure et de l'adapter à vos besoins. Tout cela en gardant le contrôle sur les données que vous partagez avec le modèle et, bien sûr, sans avoir à payer de licence à un fournisseur externe.

OpenAI a publié GPT-OSS le 5 août 2025, dans le cadre de son engagement envers l'écosystème des modèles ouverts.

Le modèle de paramètres 20B offre :

• Capacités d'utilisation des outils

• Inférence efficace

• Compatible avec le SDK OpenAI

• Compatible avec les flux de travail agentiques

Comparaison des points de repère :

Architecture de la solution

L'architecture fonctionne entièrement sur votre machine locale. Elastic (exécuté dans Docker) communique directement avec votre LLM local via LM Studio, et Elastic Agent Builder utilise cette connexion pour créer des agents d'IA personnalisés qui peuvent interroger les données de vos employés.

Pour plus de détails, consultez cette documentation.

Construire un agent d'IA pour les RH : étapes

Nous diviserons la mise en œuvre en 5 étapes :

1. Configurer LM studio avec un modèle local

2. Déployer Elastic local avec Docker

3. Créer le connecteur OpenAI dans Elastic

4. Téléchargement des données des employés vers Elasticsearch

5. Créez et testez votre agent d'intelligence artificielle

Étape 1 : Configurer LM Studio avec GPT-OSS 20B

LM Studio est une application conviviale qui vous permet d'exécuter localement de grands modèles linguistiques sur votre ordinateur. Il fournit un serveur d'API compatible avec OpenAI, ce qui facilite l'intégration avec des outils tels qu'Elastic sans processus de configuration complexe. Pour plus de détails, reportez-vous à la documentation de LM Studio.

Tout d'abord, téléchargez et installez LM Studio depuis le site officiel. Une fois installée, ouvrez l'application.

Dans l'interface de LM Studio :

1. Allez dans l'onglet recherche et cherchez "GPT-OSS"

2. Sélectionnez le site openai/gpt-oss-20b à partir d'OpenAI

3. Cliquez sur télécharger

La taille de ce modèle devrait être d'environ 12,10 Go. Le téléchargement peut prendre quelques minutes, en fonction de votre connexion internet.

Une fois le modèle téléchargé :

1. Aller dans l'onglet du serveur local

2. Sélectionner l'openai/gpt-oss-20b

3. Utiliser le port par défaut 1234

4. Dans le panneau de droite, cliquez sur Charger et réglez la longueur du contexte sur 40K ou plus.

5. Cliquez sur démarrer le serveur

Vous devriez voir ceci si le serveur est en cours d'exécution.

Étape 2 : Déployer Elastic local avec Docker

Nous allons maintenant configurer Elasticsearch et Kibana localement à l'aide de Docker. Elastic fournit un script pratique qui gère l'ensemble du processus d'installation. Pour plus de détails, voir la documentation officielle.

Exécuter le script start-local

Exécutez la commande suivante dans votre terminal :

Ce script va :

• Télécharger et configurer Elasticsearch et Kibana

• Démarrer les deux services à l'aide de Docker Compose

• Activation automatique d'une licence d'essai Platinum de 30 jours

Résultats attendus

Attendez le message suivant et enregistrez le mot de passe et la clé API indiqués ; vous en aurez besoin pour accéder à Kibana :

Accéder à Kibana

Ouvrez votre navigateur et naviguez vers :

Connectez-vous en utilisant les informations d'identification obtenues dans la sortie du terminal.

Activer le constructeur d'agents

Une fois connecté à Kibana, naviguez vers Management > AI > Agent Builder et activez l'Agent Builder.

Étape 3 : Créer le connecteur OpenAI dans Elastic

Nous allons maintenant configurer Elastic pour qu'il utilise votre LLM local.

Connecteurs d'accès

1. Dans Kibana

2. Allez dans Paramètres du projet > Gestion

3. Sous Alertes et aperçus, sélectionnez Connecteurs

4. Cliquez sur Créer un connecteur

Configurer le connecteur

Sélectionnez OpenAI dans la liste des connecteurs. LM Studio utilise le SDK OpenAI, ce qui le rend compatible.

Remplissez les champs avec ces valeurs :

• Nom du connecteur : LM Studio - GPT-OSS 20B

• Sélectionnez un fournisseur OpenAI : Autre (Service compatible avec l'OpenAI)

• URL : http://host.docker.internal:1234/v1/chat/completions

• Modèle par défaut : openai/gpt-oss-20b

• Clé API : testkey-123 (n'importe quel texte fonctionne, car le serveur LM Studio ne nécessite pas d'authentification).

Pour terminer la configuration, cliquez sur Save & test.

Important : Activez l'option "Enable native function calling" (activer l'appel de fonctions natives) ; cette option est nécessaire pour que l'Agent Builder fonctionne correctement. Si vous ne l'activez pas, vous obtiendrez une erreur No tool calls found in the response.

Tester la connexion

Elastic devrait automatiquement tester la connexion. Si tout est configuré correctement, vous obtiendrez un message de réussite comme celui-ci :

Réponse :

Étape 4 : Téléchargement des données des employés vers Elasticsearch

Nous allons maintenant télécharger l'ensemble de données relatives aux employés des RH afin de montrer comment l'agent travaille avec des données sensibles. J'ai généré un ensemble de données fictives avec cette structure.

Structure de l'ensemble de données

Créer l'index avec les correspondances

Tout d'abord, créez l'index avec les correspondances appropriées. Notez que nous utilisons des champs semantic_text pour certains champs clés ; cela permet des capacités de recherche sémantique pour notre index.

Index avec Bulk API

Copiez et collez le jeu de données dans votre Dev Tools dans Kibana et exécutez-le :

Vérifier les données

Exécutez une requête pour vérifier :

Étape 5 : Créer et tester votre agent d'intelligence artificielle

Une fois tout configuré, il est temps de créer un agent d'IA personnalisé à l'aide d'Elastic Agent Builder. Pour plus de détails, voir la documentation Elastic.

Ajouter le connecteur

Avant de pouvoir créer notre nouvel agent, nous devons configurer notre Agent builder pour qu'il utilise notre connecteur personnalisé appelé LM Studio - GPT-OSS 20B, car le connecteur par défaut est Elastic Managed LLM. Pour cela, nous devons aller dans Project Setting > Management > GenAI Settings; nous sélectionnons alors celui que nous avons créé et cliquons sur Save.

Agent d'accès Constructeur

1. Aller aux agents

2. Cliquez sur Créer un nouvel agent

Configurer l'agent

Pour créer un nouvel agent, les champs obligatoires sont l'identifiant de l'agent, le nom d'affichage et les instructions d'affichage.

Mais il existe d'autres options de personnalisation, comme les instructions personnalisées qui indiquent comment votre agent va se comporter et interagir avec vos outils, à la manière d'une invite système, mais pour notre agent personnalisé. Les étiquettes permettent d'organiser les agents, la couleur de l'avatar et le symbole de l'avatar.

Ceux que j'ai choisis pour notre agent sur la base de l'ensemble des données sont les suivants : Agent ID : hr_assistant

Instructions personnalisées :

Étiquettes : Human Resources et GPT-OSS

Nom d'affichage : HR Analytics Assistant

Description de l'affichage :

Une fois toutes les données saisies, nous pouvons cliquer sur Enregistrer notre nouvel agent.

Tester l'agent

Vous pouvez désormais poser des questions en langage naturel sur les données de vos employés, et GPT-OSS 20B comprendra l'intention et générera une réponse appropriée.

Prompt :

Réponse :

Le processus de l'agent a été le suivant :

1. Comprendre votre question à l'aide du connecteur GPT-OSS

2. Générer la requête Elasticsearch appropriée (à l'aide des outils intégrés ou d'ES|QL personnalisés)

3. Récupérer les enregistrements des salariés correspondants

4. Présenter les résultats en langage naturel avec un formatage approprié

Contrairement à la recherche lexicale traditionnelle, l'agent alimenté par GPT-OSS comprend l'intention et le contexte, ce qui facilite la recherche d'informations sans connaître les noms exacts des champs ou la syntaxe de la requête. Pour plus de détails sur le processus de réflexion de l'agent, voir cet article.

Conclusion

Dans cet article, nous avons construit un agent d'IA personnalisé à l'aide de l'Agent Builder d'Elastic pour se connecter au modèle OpenAI GPT-OSS fonctionnant localement. En déployant à la fois Elastic et le LLM sur votre machine locale, cette architecture vous permet de tirer parti des capacités d'IA générative tout en conservant un contrôle total sur vos données, le tout sans envoyer d'informations à des services externes.

Nous avons utilisé GPT-OSS 20B à titre expérimental, mais les modèles officiellement recommandés pour Elastic Agent Builder sont référencés ici. Si vous avez besoin de capacités de raisonnement plus avancées, il existe également la variante de paramètre 120B qui est plus performante pour les scénarios complexes, bien qu'elle nécessite une machine plus sophistiquée pour fonctionner localement. Pour plus de détails, consultez la documentation officielle d'OpenAI.

Au-delà des projets impressionnants, l'expérience de Cal Hacks 12.0 nous a également apporté quelque chose de tout aussi précieux : un retour d'information rapide et non filtré de la part de développeurs qui découvrent notre pile pour la première fois. Les hackathons sont des tests de pression uniques, avec des délais serrés, une absence totale de connaissances préalables et des obstacles imprévisibles (comme les fameuses pannes de WiFi). Ils révèlent exactement les points forts de l'expérience du développeur et ceux sur lesquels il faut encore travailler. Cela est d'autant plus important aujourd'hui que les développeurs interagissent avec la pile Elastic de nouvelles façons, de plus en plus par le biais de flux de travail pilotés par LLM. Dans cet article de blog, nous allons approfondir ce que les participants ont construit avec Agent Builder et ce que nous avons appris au cours du processus.

Les projets gagnants

Première place : AgentOverflow

Stack Overflow reconstruit pour l'ère du LLM et de l'agent.

Pour en savoir plus sur AgentOverflow , cliquez ici.

AgentOverflow s'attaque à un problème que rencontrent la plupart des développeurs d'IA : Les LLM hallucinent, les historiques de conversation disparaissent et les développeurs perdent du temps à résoudre les mêmes problèmes.

AgentOverflow capture, valide et fait réapparaître de véritables paires problème-solution, afin que les développeurs puissent sortir de la spirale de l'hallucination et livrer plus rapidement.

Comment cela fonctionne-t-il ?

1. Partager JSON - le "schéma de solution".

Un clic à partir d'un partage de Claude permet de récupérer, d'extraire et d'assembler une solution de partage JSON, qui est un format structuré contenant :

• Problème

• Contexte

• Code

• Balises

• Vérification des étapes de la solution.

Un validateur (LAVA) vérifie et renforce la structure, l'utilisateur ajoute une ligne de contexte supplémentaire, puis le tout est stocké et indexé dans Elasticsearch.

2. Trouver la solution

Lorsque vous êtes bloqué, cliquez sur Find Solution et AgentOverflow scrapera votre conversation actuelle, l'utilisera pour construire une requête, et lancera une recherche hybride Elasticsearch pour remonter à la surface :

• Corrections classées et validées par la communauté

• Les invites exactes qui ont résolu le problème à l'origine

Cela permet aux développeurs de copier, coller et débloquer rapidement leur session en cours.

3. MCP - injection de contexte pour les LLM

En se connectant aux solutions structurées stockées dans Elasticsearch via MCP (Model Context Protocol), les LLM sont alimentés en contexte à haut signal (code, journaux, configurations, corrections antérieures) au moment de l'exécution sans bruit supplémentaire.

AgentOverflow utilise Agent Builder avec Elasticsearch comme couche de mémoire structurée qui injecte un contexte pertinent dans les LLM. Ils passent ainsi du statut de chatbots passifs à celui de résolveurs de problèmes conscients du contexte.

Deuxième prix : MarketMind

Une vue interprétable en temps réel de l'énergie du marché, alimentée par six agents élastiques.

Pour en savoir plus sur MarketMind , cliquez ici.

MarketMind a gagné sa place en offrant aux traders débutants une plateforme qui convertit les données fragmentées du marché en signaux clairs et en temps réel. Au lieu de jongler avec l'évolution des prix, les fondamentaux, le sentiment et la volatilité sur différents outils, MarketMind consolide toutes ces informations sur une seule plateforme, aidant ainsi les traders à obtenir des informations exploitables. Ce projet a également utilisé des requêtes ES|QL complexes lors de la création de ses agents.

Comment cela fonctionne-t-il ?

1. Collecter des données de marché en temps réel

MarketMind extrait de Yahoo Finance des données sur l'évolution des cours, les fondamentaux, le sentiment, la volatilité et le risque. Ces données sont ingérées et organisées en plusieurs index Elasticsearch.

2. Six agents spécialisés analysent le marché

Chaque agent, créé avec Agent Builder, se concentre sur une couche différente du marché. Ils lisent un index Elasticsearch, calculent leurs propres mesures spécifiques au domaine et génèrent une sortie JSON standardisée avec des scores et un raisonnement.

3. Agréger les signaux dans un modèle unifié d'"énergie de marché".

Les résultats combinés apparaissent sous forme d'impulsions lumineuses autour de chaque action, indiquant si la dynamique se renforce, si le risque augmente ou si le sentiment change.

4. Visualiser les informations

Le frontend a été construit avec React et Next.js, en utilisant TypeScript, des visuels SVG basés sur la physique, et Chart.js pour les graphiques de chandeliers en direct. L'analyse brute est ainsi transformée en un retour d'information exploitable en temps réel.

Autres projets intéressants :

Voici d'autres concurrents de taille qui ont utilisé Elastic dans différentes parties de leur pile :

Vous trouverez ici la liste complète des projets qui ont été soumis à notre circuit.

Ce que nous ont appris les développeurs

• Agent Builder est convivial :

La plupart des équipes n'avaient jamais utilisé Elastic auparavant et étaient encore en mesure de créer des agents rapidement avec peu de soutien. Nous avons organisé un atelier pour ceux qui avaient besoin de plus de conseils, mais la plupart ont été en mesure d'ingérer leurs données et de créer un agent pour effectuer des actions sur ces données.

• Les LLM excellent dans les requêteskNN, mais ont encore besoin d'être guidés dans la création d'ES|QL :

Demander à ChatGPT-5 de générer des requêtes ES|QL renvoyait des informations incorrectes, mélangeant souvent ES|QL et SQL. Alimenter le LLM avec les documents dans un fichier markdown semblait être une solution viable.

• Les fonctions ES|QL en mode instantané ont fait l'objet d'une fuite dans la documentation :

Les fonctions d'agrégation FIRST et LAST ont été glissées involontairement dans nos documents ES|QL. Parce que nous avons fourni ces documents à ChatGPT, le modèle a consciencieusement utilisé ces fonctions, même si elles ne sont pas encore disponibles dans Serverless. Grâce au feedback du groupe, l'ingénierie a rapidement ouvert et fusionné un correctif pour supprimer les fonctions de la documentation publiée(PR #137341).

• Absence d'orientations spécifiques à Serverless :

Une équipe a essayé d'activer LOOKUP JOIN sur un index qui n'a pas été créé en mode consultation. Le message d'erreur les a envoyés à la recherche de commandes qui n'existent pas sur Serverless. Nous avons relayé cette information à l'équipe produit, qui a immédiatement ouvert un correctif pour un message actionnable spécifique à Serverless. À plus long terme, l'objectif est de masquer entièrement la complexité de la réindexation(problème n° 4838).

• Valeur des événements en personne :

Les hackathons en ligne sont formidables, mais rien n'égale la boucle de rétroaction rapide que vous obtenez lorsque vous déboguez épaule contre épaule avec des constructeurs. Nous avons vu des équipes intégrer Agent Builder dans différents cas d'utilisation, repérer où l'expérience des développeurs avec ES|QL pouvait être améliorée, et résoudre les problèmes beaucoup plus rapidement qu'en essayant de le faire sur des canaux asynchrones.

Conclusion

Cal Hacks 12.0 nous a offert plus qu'un week-end de démonstrations intéressantes ; il nous a également permis de comprendre comment les nouveaux développeurs interagissent avec la pile Elastic. En seulement 36 heures, nous avons vu des équipes prendre en main Agent Builder, ingérer des données dans Elasticsearch, concevoir des systèmes multi-agents et tester nos fonctionnalités de différentes manières. L'événement nous a également rappelé pourquoi les événements en personne sont importants. Les boucles de rétroaction rapides, les conversations réelles et le débogage pratique nous ont aidés à comprendre les besoins actuels des développeurs. Nous sommes ravis d'apporter ce que nous avons appris à l'équipe d'ingénieurs. Nous vous donnons rendez-vous au prochain hackathon.

Cet article est le complément de l'article "Creating an LLM Agent newsroom with A2A protocol and MCP in Elasticsearch !", qui expliquait les avantages de la mise en œuvre des architectures A2A et MCP au sein du même agent afin de profiter pleinement des avantages uniques des deux frameworks. Un référentiel est disponible si vous souhaitez exécuter la démo par vous-même.

Voyons comment les agents de notre salle de presse collaborent en utilisant à la fois A2A et MCP pour produire un article. Le référentiel d'accompagnement pour voir les agents en action est disponible ici.

Étape 1 : Attribution de l'histoire

Le chef de l'information (agissant en tant que client) attribue un sujet :

Étape 2 : Le journaliste demande des recherches

L'agent rapporteur reconnaît qu'il a besoin d'informations générales et délègue à l'agent chercheur par l'intermédiaire de l'A2A :

Étape 3 : Le rapporteur demande le contexte historique à l'agent d'archivage

L'agent rapporteur reconnaît que le contexte historique renforcerait l'histoire. Il délègue à l'agent d'archivage (alimenté par l'agent A2A d'Elastic), via A2A, le soin d'effectuer des recherches dans les archives d'articles de la salle de presse alimentées par Elasticsearch :

Étape 4 : L'agent d'archivage utilise l'agent Elastic A2A avec MCP

L'agent d'archivage utilise l'agent A2A d'Elastic, qui à son tour utilise MCP pour accéder aux outils Elasticsearch. Ceci démontre l'architecture hybride où A2A permet la collaboration des agents tandis que MCP fournit l'accès aux outils :

L'agent d'archivage reçoit des données historiques complètes de l'agent A2A d'Elastic et les renvoie au rapporteur :

Cette étape montre comment l'agent A2A d'Elastic s'intègre dans le flux de travail de la salle de presse. L'Archive Agent (un agent spécifique à la salle de presse) se coordonne avec l'A2A Agent d'Elastic (un spécialiste tiers) pour exploiter les puissantes capacités de recherche et d'analyse d'Elasticsearch. L'agent Elastic utilise MCP en interne pour accéder aux outils Elasticsearch, ce qui montre la séparation nette entre la coordination de l'agent (A2A) et l'accès aux outils (MCP).

Étape 5 : Le chercheur utilise les serveurs MCP

L'agent chercheur accède à plusieurs serveurs MCP pour recueillir des informations :

Étape 6 : Le chercheur renvoie les données au rapporteur

L'agent chargé de la recherche renvoie la recherche complète par l'intermédiaire de l'A2A :

Étape 7 : Le journaliste rédige un article

L'agent rapporteur utilise les données de recherche et ses propres capacités LLM pour rédiger l'article. Pendant la rédaction, le Reporter utilise les serveurs MCP pour le style et les modèles :

Étape 8 : le manque de confiance déclenche une nouvelle recherche

L'agent déclarant évalue son projet et constate qu'une créance a un faible degré de confiance. Il envoie une autre demande à l'agent du chercheur :

Le chercheur vérifie l'allégation à l'aide des serveurs MCP de vérification des faits et renvoie les informations mises à jour :

Étape 9 : Le journaliste révise le texte et le soumet au rédacteur en chef

Le rapporteur incorpore les faits vérifiés et envoie le projet complet à l'agent rédacteur par l'intermédiaire de l'A2A :

Étape 10 : Examens des éditeurs à l'aide des outils MCP

L'agent rédacteur utilise plusieurs serveurs MCP pour réviser l'article :

Le rédacteur en chef approuve l'article et le transmet :

Étape 11 : L'éditeur publie via CI/CD

Enfin, l'agent imprimeur publie l'article approuvé en utilisant les serveurs MCP pour le CMS et le pipeline CI/CD :

L'éditeur confirme la publication via A2A :

Voici la séquence complète du flux de travail A2A dans le référentiel d'accompagnement en utilisant les mêmes agents que ceux décrits ci-dessus.

#

De

Pour

Action

Protocole

Description

1

Utilisateur

Chef de l'information

Attribuer l'histoire

HTTP POST

L'utilisateur soumet le sujet et l'angle de l'article

2

Chef de l'information

Interne

Créer une histoire

-

Création d'un enregistrement d'histoire avec un identifiant unique

3

Chef de l'information

Reporter

Affectation des délégués

A2A

Envoi de l'article via le protocole A2A

4

Reporter

Interne

Accepter l'affectation

-

Stockage interne de l'affectation

5

Reporter

Serveur MCP

Générer un plan

MCP/HTTP

Création d'un plan d'article et de questions de recherche

6a

Reporter

Chercheur

Demande de recherche

A2A

Envoie des questions (parallèle avec 6b)

6b

Reporter

Archiviste

Recherche dans les archives

A2A JSONRPC

Recherche d'articles historiques (parallèle avec 6a)

7

Chercheur

Serveur MCP

Questions de recherche

MCP/HTTP

Utilise l'Anthropique via le MCP pour répondre aux questions

8

Chercheur

Reporter

Recherche en matière de retour

A2A

Réponses à la recherche sur les retours

9

Archiviste

Elasticsearch

Index de recherche

API REST ES

Requêtes news_archive index

10

Archiviste

Reporter

Retour à l'archive

A2A JSONRPC

Renvoie les résultats de la recherche historique

11

Reporter

Serveur MCP

Générer un article

MCP/HTTP

Création d'un article dans un contexte de recherche ou d'archives

12

Reporter

Interne

Projet de magasin

-

Sauvegarde interne du projet

13

Reporter

Chef de l'information

Soumettre le projet

A2A

Soumission d'un projet achevé

14

Chef de l'information

Interne

Mise à jour de l'histoire

-

Stocke le projet, met à jour le statut à "draft_submitted"

15

Chef de l'information

Éditeur

Projet de révision

A2A

Routes automatiques vers l'éditeur pour révision

16

Éditeur

Serveur MCP

Article de synthèse

MCP/HTTP

Analyse du contenu à l'aide d'Anthropic via MCP

17

Éditeur

Chef de l'information

Retourner à l'examen

A2A

Envoi d'un retour d'information et de suggestions éditoriales

18

Chef de l'information

Interne

Revue des magasins

-

Stocke les commentaires des éditeurs

19

Chef de l'information

Reporter

Appliquer les modifications

A2A

Acheminement du retour d'information sur l'examen au rapporteur

20

Reporter

Serveur MCP

Appliquer les modifications

MCP/HTTP

Révision de l'article en fonction du retour d'information

21

Reporter

Interne

Projet de mise à jour

-

Mise à jour du projet avec des révisions

22

Reporter

Chef de l'information

Retour Révisé

A2A

Retourne l'article révisé

23

Chef de l'information

Interne

Mise à jour de l'histoire

-

Stocker le projet révisé, statut à "révisé"

24

Chef de l'information

Éditeur

Publier un article

A2A

Routes automatiques vers l'éditeur

25

Éditeur

Serveur MCP

Générer des étiquettes

MCP/HTTP

Création d'étiquettes et de catégories

26

Éditeur

Elasticsearch

Index Article

API REST ES

Indexe l'article dans l'index news_archive

27

Éditeur

Système de fichiers

Sauvegarder la démarque

Fichier E/S

Enregistre l'article au format .md fichier dans /articles

28

Éditeur

Chef de l'information

Confirmer la publication

A2A

Renvoie l'état de réussite

29

Chef de l'information

Interne

Mise à jour de l'histoire

-

Mise à jour du statut de l'article à "publié"

Conclusion

L'A2A et le MCP ont tous deux un rôle important à jouer dans le paradigme moderne de l'infrastructure augmentée-LLM. L'A2A offre une certaine souplesse pour les systèmes multi-agents complexes, mais potentiellement moins de portabilité et une plus grande complexité opérationnelle. MCP offre une approche standardisée pour l'intégration des outils, plus simple à mettre en œuvre et à maintenir, bien qu'il ne soit pas conçu pour gérer l'orchestration multi-agents.

Le choix n'est pas binaire. Comme le montre notre exemple de salle de presse, les systèmes les plus sophistiqués et les plus efficaces soutenus par le LLM combinent souvent les deux approches : les agents se coordonnent et se spécialisent par le biais de protocoles A2A tout en accédant à leurs outils et à leurs ressources par le biais de serveurs MCP. Cette architecture hybride offre les avantages organisationnels des systèmes multi-agents ainsi que les avantages de la normalisation et de l'écosystème du MCP. Cela suggère qu'il n'est peut-être pas nécessaire de faire un choix : il suffit d'utiliser les deux en tant qu'approche standard.

C'est à vous, en tant que développeur ou architecte, de tester et de déterminer le meilleur mélange de ces deux solutions pour obtenir le bon résultat pour votre cas d'utilisation spécifique. Comprendre les points forts, les limites et les applications appropriées de chaque approche vous permettra de construire des systèmes d'IA plus efficaces, plus faciles à maintenir et plus évolutifs.

Que vous construisiez une salle de presse numérique, une plateforme de service à la clientèle, un assistant de recherche ou toute autre application alimentée par le LLM, l'examen attentif de vos besoins de coordination (A2A) et des exigences d'accès aux outils (MCP) vous mettra sur la voie de la réussite.

Ressources supplémentaires

• Elasticsearch Agent Builder : https://www.elastic.co/docs/solutions/search/elastic-agent-builder

• Spécification A2A : https://a2a-protocol.org/latest/specification/

• Intégration A2A et MCP : https://a2a-protocol.org/latest/topics/a2a-and-mcp/

• Modèle de protocole de contexte : https://modelcontextprotocol.io

Une nouvelle façon d'interagir avec les données

L'IA générative (genAI) et l'IA agentique agissent différemment de la recherche traditionnelle. Alors que nous commencions à rechercher des informations par une recherche ("laissez-moi chercher cela sur Google..."), l'action initiale de l'IA générique et des agents se fait généralement par le biais d'un langage naturel saisi dans une interface de dialogue en ligne. L'interface de chat est une discussion avec un LLM qui utilise sa compréhension sémantique pour transformer notre question en une réponse distillée, une réponse résumée semblant provenir d'un oracle qui a une connaissance étendue de toutes sortes d'informations. Ce qui fait vraiment la différence, c'est la capacité du LLM à produire des phrases cohérentes et réfléchies qui rassemblent les éléments de connaissance qu'il fait apparaître - même s'ils sont inexacts ou totalement hallucinés, ils ont une certaine véracité.

Cette vieille barre de recherche avec laquelle nous avons été tellement habitués à interagir peut être considérée comme le moteur RAG que nous utilisions lorsque nous étions nous-mêmes l'agent de raisonnement. Aujourd'hui, même les moteurs de recherche Internet transforment notre expérience de recherche lexicale bien connue en aperçus pilotés par l'IA qui répondent à la requête par un résumé des résultats, ce qui permet aux utilisateurs d'éviter de cliquer et d'évaluer eux-mêmes les résultats individuels.

IA générative & RAG

L'IA générative tente d'utiliser sa compréhension sémantique du monde pour analyser l'intention subjective exprimée dans une demande de chat, puis utilise ses capacités d'inférence pour créer une réponse d'expert à la volée. L'interaction générative de l'IA comporte plusieurs parties : elle commence par l'entrée/la requête de l'utilisateur, les conversations précédentes dans la session de chat peuvent être utilisées comme contexte supplémentaire, et l'instruction qui indique au LLM comment raisonner et quelles sont les procédures à suivre pour construire la réponse. Les messages-guides ont évolué, passant d'une simple orientation du type ", "Expliquez-moi cela comme si j'étais un enfant de cinq ans", à des descriptions complètes de la manière de traiter les demandes. Ces décompositions comprennent souvent des sections distinctes décrivant les détails du personnage/rôle de l'IA, le raisonnement avant la génération/le processus de réflexion interne, les critères objectifs, les contraintes, le format de sortie, le public, ainsi que des exemples pour aider à démontrer les résultats attendus.

En plus de la requête de l'utilisateur et de l'invite du système, la génération augmentée de recherche (RAG) fournit des informations contextuelles supplémentaires dans ce que l'on appelle une "fenêtre contextuelle". RAG a été un ajout essentiel à l'architecture ; c'est ce que nous utilisons pour informer le LLM des pièces manquantes dans sa compréhension sémantique du monde.

Les fenêtres contextuelles peuvent être un peu tatillonnes en ce qui concerne le contenu, l'emplacement et la quantité que vous leur donnez. Le contexte sélectionné est bien sûr très important, mais le rapport signal/bruit du contexte fourni est également important, de même que la longueur de la fenêtre.

Trop peu d'informations

Le fait de fournir trop peu d'informations dans une fenêtre de requête, d'invite ou de contexte peut entraîner des hallucinations, car le LLM ne peut pas déterminer avec précision le contexte sémantique correct à partir duquel générer une réponse. La similarité vectorielle de la taille des morceaux de documents pose également des problèmes - une question courte et simple peut ne pas correspondre sémantiquement aux documents riches et détaillés trouvés dans nos bases de connaissances vectorisées. Des techniques d'expansion des requêtes telles que Hypothetical Document Embeddings (HyDE) ont été développées. Elles utilisent les LLM pour générer une réponse hypothétique qui est plus riche et plus expressive que la requête courte. Le danger ici, bien sûr, est que le document hypothétique est lui-même une hallucination qui éloigne encore plus le LLM du contexte correct.

Trop d'informations

Tout comme pour nous, un excès d'informations dans une fenêtre contextuelle peut submerger un MLD et le rendre confus quant aux éléments importants. Le débordement de contexte (ou "pourriture de contexte") affecte la qualité et les performances des opérations d'IA générative ; il a un impact considérable sur le "budget d'attention" du LLM (sa mémoire de travail) et dilue la pertinence parmi de nombreux éléments concurrents. Le concept de "rotation du contexte" comprend également l'observation selon laquelle les LLM ont tendance à avoir un biais de position - ils préfèrent le contenu au début ou à la fin d'une fenêtre contextuelle au contenu de la section centrale.

Informations distrayantes ou contradictoires

Plus la fenêtre contextuelle est grande, plus il y a de chances qu'elle contienne des informations superflues ou contradictoires qui peuvent distraire le LLM de la sélection et du traitement du contexte correct. D'une certaine manière, il s'agit d'un problème d'entrée et de sortie de déchets : le simple fait de déverser un ensemble de résultats de documents dans une fenêtre contextuelle donne au LLM beaucoup d'informations à mâcher (potentiellement trop), mais en fonction de la manière dont le contexte a été sélectionné, il y a une plus grande possibilité que des informations contradictoires ou non pertinentes s'infiltrent dans le système.

IA agentique

Je vous avais dit qu'il y avait beaucoup de terrain à couvrir, mais nous l'avons fait - nous parlons enfin de sujets liés à l'IA agentique ! L'IA agentique est une nouvelle utilisation très intéressante des interfaces de chat LLM qui développe la capacité de l'IA générative (peut-on déjà l'appeler "ancienne" ?) à synthétiser des réponses basées sur ses propres connaissances et sur les informations contextuelles que vous lui fournissez. Au fur et à mesure que l'IA générative gagnait en maturité, nous avons réalisé qu'il existait un certain niveau de tâches et d'automatisation que nous pouvions confier aux LLM, initialement reléguées à des activités fastidieuses à faible risque qui peuvent facilement être vérifiées/validées par un être humain. En peu de temps, ce champ d'application initial s'est élargi : une fenêtre de discussion LLM peut désormais être l'étincelle qui envoie un agent d'intelligence artificielle planifier, exécuter, évaluer et adapter son plan de manière itérative afin d'atteindre l'objectif spécifié. Les agents ont accès au raisonnement de leur LLM, à l'historique des discussions et à la mémoire de pensée (telle qu'elle est), et ils disposent également d'outils spécifiques qu'ils peuvent utiliser à cette fin. Nous voyons aussi maintenant des architectures qui permettent à un agent de haut niveau de fonctionner comme l'orchestrateur de plusieurs sous-agents, chacun avec ses propres chaînes logiques, ses jeux d'instructions, son contexte et ses outils.

Les agents sont le point d'entrée d'un flux de travail essentiellement automatisé : ils sont autodirigés en ce sens qu'ils sont capables de discuter avec un utilisateur et d'utiliser ensuite la "logique" pour déterminer les outils dont ils disposent pour répondre à la question de l'utilisateur. Les outils sont généralement considérés comme passifs par rapport aux agents et construits pour effectuer un seul type de tâche. Les types de tâches qu'un outil pourrait accomplir sont en quelque sorte illimités (ce qui est vraiment passionnant !), mais l'une des principales tâches des outils est de rassembler des informations contextuelles qu'un agent doit prendre en compte lors de l'exécution de son flux de travail.

En tant que technologie, l'IA agentique en est encore à ses balbutiements et est sujette à l'équivalent LLM du trouble déficitaire de l'attention - elle oublie facilement ce qu'on lui a demandé de faire, et part souvent faire d'autres choses qui ne faisaient pas du tout partie du cahier des charges. Sous cette apparente magie, les capacités de "raisonnement" des LLM sont toujours basées sur la prédiction du prochain jeton le plus probable dans une séquence. Pour que le raisonnement (ou, un jour, l'intelligence artificielle générale (AGI)) devienne fiable et digne de confiance, nous devons être en mesure de vérifier que, lorsqu'on leur donne les informations correctes et les plus récentes, ils raisonnent de la manière que nous attendons d'eux (et nous donnent peut-être ce petit plus auquel nous n'aurions pas pensé nous-mêmes). Pour ce faire, les architectures agentiques devront être capables de communiquer clairement (protocoles), de respecter les flux de travail et les contraintes que nous leur imposons (garde-fous), de se rappeler où elles en sont dans une tâche (état), de gérer leur espace mémoire disponible et de valider que leurs réponses sont exactes et répondent aux critères de la tâche.

Parlez-moi dans une langue que je peux comprendre

Comme c'est souvent le cas dans les nouveaux domaines de développement (en particulier dans le monde des LLM), il existait initialement plusieurs approches pour les communications entre agents et outils, mais elles ont rapidement convergé vers le protocole de contexte de modèle (MCP) en tant que norme de facto. La définition du protocole de contexte de modèle est vraiment dans le nom - c'est le protocole qu'un modèle utilise pour demander et recevoir des informations contextuelles. MCP agit comme un adaptateur universel permettant aux agents LLM de se connecter à des outils et à des sources de données externes ; il simplifie et normalise les API de manière à ce que les différents cadres et outils LLM puissent facilement interopérer. Cela fait de MCP une sorte de point de pivot entre la logique d'orchestration et les invites du système données à un agent pour qu'il les exécute de manière autonome au service de ses objectifs, et les opérations envoyées à des outils pour qu'ils les exécutent de manière plus isolée (isolée au moins par rapport à l'agent qui en est à l'origine).

Cet écosystème est tellement nouveau que chaque direction d'expansion semble être une nouvelle frontière. Nous disposons de protocoles similaires pour les interactions entre agents(Agent2Agent (A2A) natch !) ainsi que d'autres projets visant à améliorer la mémoire de raisonnement des agents(ReasoningBank), à sélectionner le meilleur serveur MCP pour le travail à effectuer(RAG-MCP), et à utiliser l'analyse sémantique telle que la classification "zero-shot" et la détection de motifs sur les entrées et les sorties comme garde-fous pour contrôler ce sur quoi un agent est autorisé à opérer.

Vous avez peut-être remarqué que l'intention sous-jacente de chacun de ces projets est d'améliorer la qualité et le contrôle des informations renvoyées à une fenêtre contextuelle agent/genAI ? Alors que l'écosystème de l'IA agentique continue de développer la capacité à mieux traiter ces informations contextuelles (pour les contrôler, les gérer et les exploiter), il sera toujours nécessaire d'extraire les informations contextuelles les plus pertinentes pour que l'agent puisse les mouliner.

Bienvenue dans l'ingénierie contextuelle !

Si vous êtes familier avec les termes de l'IA générative, vous avez probablement entendu parler de "l'ingénierie des messages" - à ce stade, il s'agit presque d'une pseudo-science à part entière. L'ingénierie des invites est utilisée pour trouver les moyens les meilleurs et les plus efficaces de décrire de manière proactive les comportements que vous souhaitez que le MLD utilise pour générer sa réponse. L'"ingénierie du contexte" étend les techniques d'"ingénierie de l'invite" au-delà du côté de l'agent pour couvrir également les sources de contexte et les systèmes disponibles du côté des outils du protocole MCP, et comprend les thèmes généraux de la gestion, du traitement et de la génération du contexte :

• Gestion du contexte - liée au maintien de l'efficacité de l'état et du contexte dans des flux de travail agentiques de longue durée et/ou plus complexes. Planification itérative, suivi et orchestration des tâches et de l'utilisation des outils pour atteindre les objectifs de l'agent. En raison du "budget d'attention" limité dont disposent les agents, la gestion du contexte concerne principalement les techniques qui permettent d'affiner la fenêtre contextuelle afin de capturer à la fois la portée la plus complète et les éléments les plus importants du contexte (sa précision par rapport à son rappel !). Les techniques comprennent la compression, le résumé et la persistance du contexte des étapes précédentes ou des appels d'outils pour faire de la place dans la mémoire de travail pour le contexte supplémentaire des étapes suivantes.

• Traitement du contexte - Les étapes logiques et, espérons-le, essentiellement programmatiques visant à intégrer, normaliser ou affiner le contexte acquis à partir de sources disparates afin que l'agent puisse raisonner sur l'ensemble du contexte d'une manière quelque peu uniforme. Le travail sous-jacent consiste à faire en sorte que le contexte provenant de toutes les sources (invites, RAG, mémoire, etc.) soit consommé par l'agent le plus efficacement possible.

• Génération de contexte - Si le traitement du contexte consiste à rendre le contexte récupéré utilisable par l'agent, alors la génération de contexte donne à l'agent la possibilité de demander et de recevoir ces informations contextuelles supplémentaires à volonté, mais aussi avec des contraintes.

Les différents éphémères des applications de chat du LLM correspondent directement (et parfois de manière redondante) à ces fonctions de haut niveau de l'ingénierie contextuelle :

• Instructions / invite du système - Les invites constituent l'échafaudage de la manière dont l'activité générative (ou agentique) de l'IA orientera sa réflexion vers la réalisation de l'objectif de l'utilisateur. Les messages-guides constituent un contexte à part entière ; il ne s'agit pas seulement d'instructions tonales - ils comprennent aussi souvent une logique d'exécution des tâches et des règles telles que "réfléchir étape par étape" ou "respirer profondément" avant de répondre afin de s'assurer que la réponse répond pleinement à la demande de l'utilisateur. Des tests récents ont montré que les langages de balisage sont très efficaces pour encadrer les différentes parties d'une invite, mais il faut également veiller à calibrer les instructions de manière à ce qu'elles soient à la fois trop vagues et trop spécifiques ; nous voulons donner suffisamment d'instructions pour que le LLM trouve le bon contexte, mais sans être trop prescriptif au point de passer à côté d'idées inattendues.

• Mémoire à court terme (état/historique) - La mémoire à court terme correspond essentiellement aux interactions de la session de chat entre l'utilisateur et le LLM. Ils sont utiles pour affiner le contexte lors des sessions en direct et peuvent être sauvegardés pour être retrouvés et poursuivis ultérieurement.

• Mémoire à long terme - La mémoire à long terme doit être constituée d'informations utiles pour plusieurs sessions. Et il ne s'agit pas seulement de bases de connaissances spécifiques à un domaine auxquelles on accède par le biais de RAG ; des recherches récentes utilisent les résultats de demandes d'IA agentique/générative antérieures pour apprendre et se référer aux interactions agentiques actuelles. Certaines des innovations les plus intéressantes dans le domaine de la mémoire à long terme sont liées à l'ajustement de la manière dont l'état est stocké et relié afin que les agents puissent reprendre là où ils se sont arrêtés.

• Sortie structurée - La cognition nécessite un effort, il n'est donc pas surprenant que même avec des capacités de raisonnement, les LLM (tout comme les humains) veulent dépenser moins d'effort lorsqu'ils pensent, et en l'absence d'une API ou d'un protocole défini, avoir une carte (un schéma) sur la façon de lire les données renvoyées par un appel d'outil est extrêmement utile. L'inclusion de sorties structurées dans le cadre agentique contribue à rendre ces interactions machine-machine plus rapides et plus fiables, en réduisant les besoins d'analyse.

• Outils disponibles - Les outils peuvent faire toutes sortes de choses, de la collecte d'informations supplémentaires (par exemple, en émettant des requêtes RAG vers les référentiels de données de l'entreprise, ou par le biais d'API en ligne) à l'exécution d'actions automatisées au nom de l'agent (comme la réservation d'une chambre d'hôtel sur la base des critères de la demande de l'agent). Les outils peuvent également être des sous-agents disposant de leur propre chaîne de traitement agentique.

• Retrieval Augmented Generation (RAG) - J'aime beaucoup la description de RAG en tant qu'"intégration dynamique des connaissances". Comme décrit précédemment, le RAG est la technique permettant de fournir les informations supplémentaires auxquelles le LLM n'a pas eu accès lors de sa formation, ou bien il s'agit d'une réitération des idées que nous pensons être les plus importantes pour obtenir la bonne réponse - celle qui est la plus pertinente par rapport à notre requête subjective.

Une puissance cosmique phénoménale, un espace de vie minuscule !

L'IA agentique a tant de nouveaux domaines fascinants et passionnants à explorer ! Il y a encore beaucoup de problèmes traditionnels de recherche et de traitement de données à résoudre, mais aussi de toutes nouvelles catégories de défis qui commencent seulement à être exposés à la lumière du jour dans la nouvelle ère des LLM. Bon nombre des problèmes immédiats auxquels nous sommes confrontés aujourd'hui sont liés à l'ingénierie contextuelle, c'est-à-dire au fait de fournir aux MFR les informations contextuelles supplémentaires dont ils ont besoin sans surcharger leur espace de mémoire de travail, qui est limité.

La flexibilité des agents semi-autonomes ayant accès à un ensemble d'outils (et à d'autres agents) donne lieu à tant de nouvelles idées pour la mise en œuvre de l'IA qu'il est difficile d'imaginer les différentes façons dont nous pourrions assembler les pièces du puzzle. La plupart des recherches actuelles s'inscrivent dans le domaine de l'ingénierie contextuelle et se concentrent sur la construction de structures de gestion de la mémoire capables de gérer et de suivre de plus grandes quantités de contexte. En effet, les problèmes de réflexion approfondie que nous voulons vraiment que les LLM résolvent présentent une complexité accrue et des étapes de réflexion plus longues et multiphases, où la mémorisation est extrêmement importante.

Une grande partie de l'expérimentation en cours dans le domaine consiste à essayer de trouver la gestion optimale des tâches et les configurations d'outils pour alimenter la gueule de l'agent. Chaque appel d'outil dans la chaîne de raisonnement d'un agent entraîne un coût cumulatif, à la fois en termes de calcul pour exécuter la fonction de l'outil et d'impact sur la fenêtre contextuelle limitée. Certaines des dernières techniques de gestion du contexte pour les agents LLM ont provoqué des effets en chaîne involontaires tels que l'"effondrement du contexte", où la compression/le résumé du contexte accumulé pour les tâches de longue durée entraîne trop de pertes. Le résultat souhaité est de disposer d'outils qui renvoient un contexte succinct et précis, sans que des informations superflues ne viennent empiéter sur l'espace mémoire précieux de la fenêtre de contexte.

Tant/trop de possibilités

Nous voulons une séparation des tâches avec la possibilité de réutiliser les outils/composants, il est donc tout à fait logique de créer des outils agentiques dédiés pour se connecter à des sources de données spécifiques - chaque outil peut se spécialiser dans l'interrogation d'un type de référentiel, d'un type de flux de données, ou même d'un cas d'utilisation. Mais attention : dans le but de gagner du temps/de l'argent/de prouver que quelque chose est possible, la tentation sera grande d'utiliser les MLD comme outil de fédération... Essayez de ne pas le faire, nous sommes déjà passés par là! La recherche fédérée agit comme un "traducteur universel" qui convertit une requête entrante dans la syntaxe que le référentiel distant comprend, et qui doit ensuite rationaliser les résultats provenant de sources multiples en une réponse cohérente. La fédération en tant que technique fonctionne bien à petite échelle, mais à grande échelle et surtout lorsque les données sont multimodales, la fédération tente de combler des lacunes qui sont tout simplement trop importantes.

Dans le monde agentique, l'agent serait le fédérateur et les outils (par l'intermédiaire de MCP) seraient les connexions définies manuellement vers des ressources disparates. L'utilisation d'outils dédiés pour accéder à des sources de données non connectées peut sembler être une nouvelle façon puissante d'unir dynamiquement différents flux de données sur la base d'une requête, mais l'utilisation d'outils pour poser la même question à plusieurs sources finira probablement par causer plus de problèmes qu'elle n'en résoudra. Chacune de ces sources de données est probablement constituée de différents types de référentiels, chacun ayant ses propres capacités de récupération, de classement et de sécurisation des données qu'il contient. Ces écarts ou "décalages d'impédance" entre les référentiels augmentent bien entendu la charge de traitement. Ils peuvent également introduire des informations ou des signaux contradictoires, où quelque chose d'apparemment inoffensif comme un décalage de notation peut perturber considérablement l'importance accordée à un élément de contexte renvoyé, et affecter la pertinence de la réponse générée en fin de compte.

Le changement de contexte est également difficile pour les ordinateurs

Lorsque vous envoyez un agent en mission, sa première tâche consiste souvent à trouver toutes les données pertinentes auxquelles il a accès. Tout comme pour les humains, si chaque source de données à laquelle l'agent se connecte fournit des réponses dissemblables et désagrégées, il y aura une charge cognitive (mais pas exactement du même type) associée à l'extraction des éléments contextuels saillants du contenu récupéré. Cela prend du temps/du calcul, et chaque petit morceau s'additionne dans la chaîne logique agentique. Cela conduit à la conclusion que, à l'instar de ce qui est discuté pour MCP, la plupart des outils agentiques devraient plutôt se comporter comme des API - des fonctions isolées avec des entrées et des sorties connues, réglées pour répondre aux besoins de différents types d'agents. Ils parviennent beaucoup mieux à relier les points sémantiques, en particulier lorsqu'il s'agit d'une tâche telle que la traduction du langage naturel en syntaxe structurée, lorsqu'ils disposent d'un schéma auquel se référer (RTFM en effet !).

7ème manche !

Nous avons maintenant abordé l'impact des LLM sur la recherche et l'interrogation de données, ainsi que la manière dont la fenêtre de discussion évolue vers l'expérience de l'IA agentique. Mettons les deux sujets ensemble et voyons comment nous pouvons utiliser nos nouvelles capacités de recherche et d'extraction pour améliorer nos résultats en matière d'ingénierie contextuelle. En route pour la troisième partie : la puissance de la recherche hybride dans l'ingénierie contextuelle!

Les systèmes actuels soutenus par le LLM évoluent rapidement au-delà des applications à modèle unique vers des réseaux complexes où des agents spécialisés travaillent ensemble pour accomplir des tâches que l'informatique moderne n'aurait jamais cru possibles auparavant. Au fur et à mesure que ces systèmes gagnent en complexité, l'infrastructure permettant la communication entre les agents et l'accès aux outils devient l'objectif principal du développement. Deux approches complémentaires sont apparues pour répondre à ces besoins : Les protocoles Agent2Agent (A2A) pour la coordination multi-agents, et le Model Context Protocol (MCP) pour l'accès standardisé aux outils et aux ressources.

Comprendre quand utiliser l'un et l'autre en harmonie ou non peut avoir un impact significatif sur l'évolutivité, la maintenabilité et l'efficacité de vos applications. Cet article explore les concepts et les implémentations de l'A2A dans l'exemple pratique d'une salle de presse numérique, où des agents LLM spécialisés collaborent à la recherche, à la rédaction, à l'édition et à la publication d'articles de presse.

Un référentiel d'accompagnement est disponible ici, et nous examinerons des exemples concrets d'A2A en action vers la fin de l'article, à la section 5.

Produits requis

Le référentiel est constitué d'implémentations basées sur Python des agents A2A. Un serveur API est fourni en Flask, ainsi qu'un service de messagerie Python personnalisé appelé Event Hub, qui achemine les messages pour la journalisation et les mises à jour de l'interface utilisateur. Enfin, une interface utilisateur React est fournie pour une utilisation autonome des fonctionnalités de la salle de presse. Tout est contenu dans une image Docker pour faciliter la mise en œuvre. Si vous souhaitez utiliser les services directement sur votre machine, vous devez vous assurer que ces technologies sont installées :

Langages et moteurs d'exécution

• Python 13.12 - Langage de base du backend

• Node.js 18+ - React UI en option

Cadres de base et SDKS :

• A2A SDK 0.3.8 - Coordination et communication des agents

• Anthropic SDK - Intégration de Claude pour la génération d'IA

• Uvicorn - Serveur ASGI pour l'exécution des agents

• FastMCP 2.12.5+ - Implémentation du serveur MCP

• React 18.2 - Cadre d'interface utilisateur frontale

Données & recherche

• Elasticsearch 9.1.1+ - Indexation et recherche d'articles

Déploiement de Docker (facultatif, mais recommandé)

• Docker 28.5.1+

Section 1 : Qu'est-ce que l'Agent2Agent (A2A) ?

Définition et concepts de base

Agent2Agent (A2A) est un protocole standardisé pour l'interaction entre des agents LLM indépendants. Plutôt que de confier toutes les tâches à un seul système monolithique, l'A2A permet à plusieurs agents spécialisés de communiquer, de coordonner et de collaborer afin d'accomplir des flux de travail complexes qui seraient difficiles, lents ou carrément impossibles à gérer efficacement par un seul agent.

Spécification officielle : https://a2a-protocol.org/latest/specification/

Origines et évolution

Le concept de communication Agent2Agent, ou de systèmes multi-agents, trouve ses racines dans les systèmes distribués, les microservices et la recherche multi-agents qui remonte à plusieurs dizaines d'années. Les premiers travaux sur l'intelligence artificielle distribuée ont jeté les bases d'agents capables de négocier, de coordonner et de collaborer. Ces premiers systèmes étaient destinés à des simulations sociales à grande échelle, à la recherche universitaire et à la gestion des réseaux électriques.

Avec l'arrivée des LLM et la réduction des coûts d'exploitation, les systèmes multi-agents sont devenus accessibles aux marchés "grand public", avec le soutien de Google et de l'ensemble de la communauté des chercheurs en intelligence artificielle. Désormais connu sous le nom de systèmes Agent2Agent, l'ajout du protocole A2A a évolué pour devenir une norme moderne conçue spécifiquement pour l'ère des modèles linguistiques multiples et de grande envergure coordonnant les efforts et les tâches.

Le protocole A2A garantit une communication et une coordination transparentes entre les agents en appliquant des normes et des principes cohérents aux points d'interaction où les MFR se connectent et communiquent. Cette normalisation permet aux agents de différents développeurs - utilisant différents modèles sous-jacents - de travailler ensemble de manière efficace.

Les protocoles de communication ne sont pas nouveaux et sont largement ancrés dans presque toutes les transactions numériques effectuées sur l'internet. Si vous avez tapé https://www.elastic.co/search-labs dans un navigateur pour accéder à cet article, il y a de fortes chances que les protocoles TCP/IP, de transport HTTP et de recherche DNS aient tous été exécutés, ce qui nous garantit une expérience de navigation cohérente.

Caractéristiques principales

Les systèmes A2A reposent sur plusieurs principes fondamentaux qui garantissent une communication fluide. Le fait de s'appuyer sur ces principes garantit que différents agents, basés sur des LLM, des cadres et des langages de programmation différents, interagissent tous de manière transparente.

Voici les quatre grands principes :

• Transmission de messages: Les agents communiquent par le biais de messages structurés dont les propriétés et les formats sont bien définis.

• Coordination: Les agents orchestrent des flux de travail complexes en se déléguant des tâches et en gérant les dépendances sans bloquer les autres agents.

• Spécialisation: Chaque agent se concentre sur un domaine ou une capacité spécifique, devenant ainsi un expert dans son domaine et offrant la possibilité d'accomplir des tâches basées sur cet ensemble de compétences.

• État distribué: L'état et les connaissances sont répartis entre les agents plutôt que centralisés, les agents ayant la possibilité de s'informer mutuellement de l'état d'avancement des tâches et des retours partiels (artefacts).

La salle de presse : Un exemple concret

Imaginez une salle de rédaction numérique alimentée par des agents d'IA, chacun spécialisé dans un aspect différent du journalisme :

• Chef de l'information (coordinateur/client) : Assigne les sujets et supervise le flux de travail

• Agent Reporter: Rédige des articles sur la base de recherches et d'interviews

• Agent de recherche: Recueille des faits, des statistiques et des informations de base

• Agent d'archivage: Recherche d'articles historiques et identification de tendances à l'aide d'Elasticsearch

• Agent rédacteur: Vérifie la qualité, le style et l'optimisation du référencement des articles.

• Agent de publication: Publie les articles approuvés sur la plateforme de blogs via CI/CD

Ces agents ne travaillent pas isolément ; lorsque le chef de l'information confie un article sur l'adoption des énergies renouvelables, le journaliste a besoin du chercheur pour rassembler des statistiques, du rédacteur en chef pour réviser le projet et de l'éditeur pour publier l'article final. Cette coordination s'effectue par le biais de protocoles A2A.

Section 2 : comprendre l'architecture A2A

Rôles de l'agent client et de l'agent distant

Dans l'architecture A2A, les agents jouent deux rôles principaux. L'agent client est chargé de formuler et de communiquer des tâches aux autres agents du système. Il identifie les agents distants et leurs capacités, et utilise ces informations pour prendre des décisions éclairées en matière de délégation de tâches. L'agent client coordonne le flux de travail global, en veillant à ce que les tâches soient correctement réparties et à ce que le système progresse vers ses objectifs.

L'agent à distance, quant à lui, s'occupe des tâches déléguées par les clients. Il fournit des informations ou entreprend des actions spécifiques en réponse à des demandes, mais n'entreprend pas d'actions de manière indépendante. Les agents à distance peuvent également communiquer avec d'autres agents à distance si nécessaire pour s'acquitter des responsabilités qui leur sont confiées, créant ainsi un réseau collaboratif de capacités spécialisées.

Dans notre salle de presse, le chef de l'information joue le rôle d'agent client, tandis que le journaliste, le chercheur, le rédacteur en chef et l'éditeur sont des agents distants qui répondent aux demandes et se coordonnent les uns avec les autres.

Capacités essentielles de l'A2A

Les protocoles A2A définissent plusieurs capacités permettant une collaboration multi-agents :

1. La découverte

Les serveurs A2A doivent annoncer leurs capacités afin que les clients sachent quand et comment les utiliser pour des tâches spécifiques. Pour ce faire, les cartes d'agent sont des documents JSON qui décrivent les capacités, les entrées et les sorties d'un agent. Les cartes d'agent sont disponibles à des points d'extrémité cohérents et bien connus (tels que le point d'extrémité recommandé /.well-known/agent-card.json ), ce qui permet aux clients de découvrir et d'interroger les capacités d'un agent avant d'entamer une collaboration.

Voici un exemple de carte d'agent pour l'agent d'archivage personnalisé d'Elastic "Archie Archivist". Notez que les fournisseurs de logiciels tels qu'Elastic hébergent leurs agents A2A et fournissent une adresse URL pour l'accès :

Cette carte d'agent révèle plusieurs aspects importants de l'agent d'archivage d'Elastic. L'agent s'identifie comme "Archie Archivist" et indique clairement son objectif : aider à trouver des documents d'actualités historiques dans un index Elasticsearch. La carte précise le fournisseur (Elastic) et la version du protocole (0.3.0), ce qui garantit la compatibilité avec d'autres agents conformes à la norme A2A. Plus important encore, le tableau skills énumère les capacités spécifiques offertes par cet agent, notamment une puissante fonctionnalité de recherche et une exploration intelligente de l'index. Chaque compétence définit les modes d'entrée et de sortie qu'elle prend en charge, ce qui permet aux clients de savoir exactement comment communiquer avec cet agent. Cet agent est dérivé du service Agent Builder d'Elastic, qui fournit une suite d'outils et de points d'extrémité d'API natifs soutenus par LLM pour avoir une conversation avec votre magasin de données, et pas seulement pour en extraire des données. L'accès aux agents A2A dans Elasticsearch peut être trouvé ici.

2. Négociation

Les clients et les agents doivent se mettre d'accord sur les méthodes de communication - que les interactions se fassent par le biais de textes, de formulaires, d'iframes ou même d'audio/vidéo - afin de garantir une interaction correcte entre les utilisateurs et l'échange de données. Cette négociation a lieu au début de la collaboration des agents et établit les protocoles qui régiront leur interaction tout au long du flux de travail. Par exemple, un agent du service clientèle basé sur la voix peut négocier pour communiquer via des flux audio, tandis qu'un agent chargé de l'analyse des données peut préférer JSON structuré. Le processus de négociation permet aux deux parties d'échanger efficacement des informations dans un format adapté à leurs capacités et aux exigences de la tâche à accomplir.

Les capacités énumérées dans l'extrait JSON ci-dessus ont toutes des schémas d'entrée et de sortie ; ces schémas définissent la manière dont les autres agents doivent interagir avec cet agent.

3. Gestion des tâches et des états

Les clients et les agents ont besoin de mécanismes pour communiquer l'état des tâches, les changements et les dépendances tout au long de l'exécution des tâches. Il s'agit notamment de gérer l'ensemble du cycle de vie d'une tâche, depuis sa création et son affectation jusqu'aux mises à jour et aux changements d'état. Les statuts typiques sont les suivants : en attente, en cours, terminé ou en échec. Le système doit également suivre les dépendances entre les tâches afin de s'assurer que les travaux préalables sont achevés avant que les tâches dépendantes ne commencent. La gestion des erreurs et la logique de réessai sont également des éléments essentiels, qui permettent au système de se remettre gracieusement des défaillances et de continuer à progresser vers l'objectif principal.

Exemple de message de tâche :

Cet exemple de message de tâche démontre plusieurs aspects clés de la communication A2A.

• La structure du message comprend des métadonnées telles qu'un identifiant de message unique, le type de message envoyé, l'identification de l'expéditeur et du destinataire, et un horodatage pour le suivi et le débogage.

• La charge utile contient les informations relatives à la tâche proprement dite, spécifiant la capacité invoquée sur l'agent distant et fournissant les paramètres nécessaires à l'exécution de cette capacité.

• La section contexte fournit des informations supplémentaires qui aident l'agent récepteur à comprendre le flux de travail général, y compris les délais et les niveaux de priorité qui indiquent comment l'agent doit allouer ses ressources et planifier son travail.

4. La collaboration

Les clients et les agents doivent permettre une interaction dynamique mais structurée, permettant aux agents de demander des clarifications, des informations ou des sous-actions au client, à d'autres agents ou à des utilisateurs. Cela crée un environnement de collaboration dans lequel les agents peuvent poser des questions complémentaires lorsque les instructions initiales sont ambiguës, demander un contexte supplémentaire pour prendre de meilleures décisions, déléguer des sous-tâches à d'autres agents ayant une expertise plus appropriée et fournir des résultats intermédiaires pour obtenir un retour d'information avant de procéder à l'ensemble de la tâche. Cette communication multidirectionnelle garantit que les agents ne travaillent pas de manière isolée, mais qu'ils sont au contraire engagés dans un dialogue permanent qui aboutit à de meilleurs résultats.

Communication distribuée, d'égal à égal

L'A2A permet une communication distribuée où les agents peuvent être hébergés par différentes organisations, certains agents étant maintenus en interne tandis que d'autres sont fournis par des services tiers. Ces agents peuvent fonctionner sur différentes infrastructures - couvrant potentiellement plusieurs fournisseurs de services en nuage ou des centres de données sur site. Ils peuvent utiliser différents LLM sous-jacents, certains agents étant alimentés par des modèles GPT, d'autres par Claude, et d'autres encore par des alternatives à code source ouvert. Les agents peuvent même opérer dans différentes régions géographiques pour se conformer aux exigences en matière de souveraineté des données ou pour réduire les temps de latence. Malgré cette diversité, tous les agents conviennent d'un protocole de communication commun pour l'échange d'informations, ce qui garantit l'interopérabilité indépendamment des détails de la mise en œuvre. Cette architecture distribuée offre une certaine souplesse dans la manière dont les systèmes sont construits et déployés, ce qui permet aux organisations de combiner les agents et les infrastructures les mieux adaptés à leurs besoins spécifiques.

Il s'agit de l'architecture finale de l'application de la salle de presse :

Section 3 : Protocole de contexte de modèle (PCM)

Définition et objectif

Le Model Context Protocol (MCP) est un protocole standardisé développé par Anthropic pour améliorer et renforcer un LLM individuel avec des outils, des ressources et des invites définis par l'utilisateur, ainsi que d'autres ajouts supplémentaires à la base de code. MCP fournit une interface universelle entre les modèles linguistiques et les ressources externes dont ils ont besoin pour accomplir efficacement leurs tâches. Cet article présente l'état actuel du MCP avec des exemples de cas d'utilisation, les tendances émergentes et la propre mise en œuvre d'Elastic.

Concepts de base du MCP

MCP fonctionne selon une architecture client-serveur avec trois composants principaux :

• Clients : applications (comme Claude Desktop ou des applications IA personnalisées) qui se connectent aux serveurs MCP pour accéder à leurs capacités.

• Serveurs: applications qui exposent les ressources, les outils et les messages-guides aux modèles linguistiques. Chaque serveur est spécialisé dans l'accès à des capacités ou à des sources de données spécifiques.

  • Outils: fonctions définies par l'utilisateur que les modèles peuvent invoquer pour effectuer des actions, telles que la recherche dans des bases de données, l'appel à des API externes ou l'exécution de transformations sur les données.

  • Ressources : sources de données que les modèles peuvent lire, servies avec des données dynamiques ou statiques, et accessibles via des modèles d'URI (similaires aux routes REST).

  • Invitations : modèles d'invitations réutilisables avec des variables qui guident le modèle dans l'accomplissement de tâches spécifiques.

Modèle demande-réponse

MCP suit un modèle d'interaction demande-réponse familier, similaire aux API REST. Le client (LLM) demande une ressource ou invoque un outil, puis le serveur MCP traite la demande et renvoie le résultat, que le LLM utilise pour poursuivre sa tâche. Ce modèle centralisé avec des serveurs périphériques offre un modèle d'intégration plus simple que la communication d'agent pair à pair.

MCP dans la salle de presse

Dans notre exemple de salle de presse, les agents individuels utilisent des serveurs MCP pour accéder aux outils et aux données dont ils ont besoin :

• Le chercheur utilise l'agent:

  • Serveur MCP News API (accès aux bases de données d'actualités)

  • Fact-Checking MCP Server (vérification des affirmations par rapport à des sources fiables)

  • Base de données académique MCP Server (articles et recherches universitaires)

• Utilisation de l'agent rapporteur:

  • Guide de style MCP Server (normes de rédaction des salles de presse)

  • Serveur de modèles MCP (modèles et formats d'articles)

  • Bibliothèque d'images MCP Server (photos d'archives et graphiques)

• L'éditeur utilise l'agent:

  • Grammar Checker MCP Server (outils de qualité linguistique)

  • Serveur MCP de détection du plagiat (vérification de l'originalité)

  • Analyse SEO MCP Server (optimisation des titres et des mots-clés)

• L'agent éditeur utilise :

  • Serveur CMS MCP (système de gestion de contenu API)

  • Serveur CI/CD MCP (pipeline de déploiement)

  • Serveur Analytics MCP (suivi et contrôle)

Section 4 : comparaison des architectures

Quand utiliser A2A

L'architecture A2A excelle dans les scénarios nécessitant une véritable collaboration multi-agents. Les flux de travail à plusieurs étapes nécessitant une coordination bénéficient grandement de l'A2A, en particulier lorsque les tâches impliquent plusieurs étapes séquentielles ou parallèles, les flux de travail nécessitant une itération et un affinement, et les processus avec des points de contrôle et des besoins de validation. Dans notre exemple de salle de presse, le flux de travail de l'article exige que le journaliste écrive, mais il peut être nécessaire de revenir au chercheur si la confiance en certains faits est faible, puis de passer au rédacteur en chef et enfin à l'éditeur.

La spécialisation spécifique à un domaine est un autre cas d'utilisation important de l'A2A. Lorsque plusieurs experts dans différents domaines sont nécessaires pour accomplir une tâche plus importante, chaque agent apportant une connaissance approfondie du domaine et des capacités de raisonnement spécialisées pour différents aspects, A2A fournit le cadre de coordination nécessaire pour établir ces connexions. La salle de rédaction en est un parfait exemple : le chercheur se spécialise dans la collecte d'informations, le journaliste dans la rédaction et le rédacteur en chef dans le contrôle de la qualité, chacun ayant une expertise distincte.

La nécessité d'un comportement autonome des agents rend l'A2A particulièrement utile. Les agents capables de prendre des décisions indépendantes, d'adopter un comportement proactif en fonction de l'évolution des conditions et de s'adapter de manière dynamique aux exigences du flux de travail s'épanouissent dans une architecture A2A. L'échelonnement horizontal des fonctions spécialisées est un autre avantage clé : plutôt que d'avoir un seul maître à tout faire, plusieurs agents spécialisés travaillent en coordination, et plusieurs instances du même agent peuvent gérer des tâches secondaires de manière asynchrone. Dans notre salle de presse, par exemple, lors d'une nouvelle de dernière minute, plusieurs agents de Reporter peuvent travailler simultanément sur différents aspects d'un même sujet.

Enfin, les tâches nécessitant une véritable collaboration multi-agents sont idéales pour l'A2A. Cela inclut les mécanismes d'évaluation du LLM en tant que jury, les systèmes de consensus et de vote, et la résolution collaborative de problèmes où de multiples perspectives sont nécessaires pour atteindre le meilleur résultat.

Quand utiliser MCP

Le protocole de contexte de modèle est idéal pour étendre les capacités d'un modèle d'IA unique. Lorsqu'un modèle d'IA unique doit accéder à plusieurs outils et sources de données, MCP fournit la solution parfaite avec un raisonnement centralisé associé à des outils distribués et à une intégration simple des outils. Dans notre exemple de salle de presse, l'agent chercheur (un modèle) doit avoir accès à plusieurs sources de données, notamment l'API des actualités, les services de vérification des faits et les bases de données universitaires, toutes accessibles par l'intermédiaire de serveurs MCP normalisés.

L'intégration d'outils normalisés devient une priorité lorsque le partage et la réutilisation des intégrations d'outils sont importants. MCP se distingue ici par son écosystème de serveurs MCP préconstruits qui réduisent considérablement le temps de développement pour les intégrations courantes. Lorsque la simplicité et la facilité de maintenance sont requises, les modèles demande-réponse de MCP sont familiers aux développeurs, plus faciles à comprendre et à déboguer que les systèmes distribués, et leur complexité opérationnelle est moindre.

Enfin, le MCP est souvent proposé par les fournisseurs de logiciels pour faciliter la communication à distance avec leurs systèmes. Ces serveurs MCP proposés par les fournisseurs réduisent considérablement le temps d'intégration et de développement tout en offrant une interface standardisée avec les systèmes propriétaires, ce qui rend l'intégration beaucoup plus simple que le développement d'API personnalisées.

Quand utiliser les deux (A2A ❤️'s MCP)

De nombreux systèmes sophistiqués bénéficient de la combinaison d'A2A et de MCP, comme l'indique la documentation d'A2A sur l'intégration de MCP. Les systèmes nécessitant à la fois une coordination et une normalisation sont des candidats idéaux pour une approche hybride. A2A s'occupe de la coordination des agents et de l'orchestration du flux de travail, tandis que MCP permet aux agents individuels d'accéder aux outils. Dans notre exemple de salle de presse, les agents se coordonnent via A2A, le flux de travail passant du journaliste au chercheur, puis au rédacteur en chef et à l'éditeur. Cependant, chaque agent utilise des serveurs MCP pour ses outils spécialisés, ce qui crée une séparation architecturale nette.

Plusieurs agents spécialisés, chacun utilisant MCP pour l'accès aux outils, représentent un modèle commun où il y a une couche de coordination des agents gérée par A2A et une couche d'accès aux outils gérée par MCP. Cette séparation claire des préoccupations rend les systèmes plus faciles à comprendre et à entretenir.

Les avantages de la combinaison de ces deux approches sont considérables. Vous bénéficiez des avantages organisationnels des systèmes multi-agents, notamment la spécialisation, l'autonomie et le traitement parallèle, tout en profitant de la normalisation et des avantages de l'écosystème du MCP, tels que l'intégration des outils et l'accès aux ressources. Il existe une séparation claire entre la coordination des agents (A2A) et l'accès aux ressources (MCP) et, surtout, l'A2A n'est pas nécessaire pour les petites tâches telles que l'accès à l'API uniquement - MCP les gère efficacement sans les frais généraux de l'orchestration multi-agents.

FAQ : A2A vs. MCP - Cas d'utilisation

Fonctionnalité

Agent2Agent (A2A)

Protocole de contexte de modèle (MCP)

Hybride (A2A + MCP)

Objectif principal

Coordination multi-agents : Permet à une équipe d'agents spécialisés de travailler ensemble sur des flux de travail complexes à plusieurs étapes.

Amélioration de l'agent unique : Extension des capacités d'un seul LLM/Agent à l'aide d'outils, de ressources et de données externes.

Une force combinée : A2A gère le flux de travail de l'équipe, tandis que MCP fournit des outils à chaque membre de l'équipe.

Exemple d'équipe de salle de presse

La chaîne de travail : Chef de l'information → Reporter → Chercheur → Rédacteur en chef → Éditeur. Il s'agit de la couche de coordination.

Outils individuels de l'agent : L'agent rapporteur accède au serveur de guides de style et au serveur de modèles (via MCP). Il s'agit de la couche d'accès aux outils.

Le système complet : Le journaliste se coordonne avec le rédacteur en chef (A2A) et le journaliste utilise le serveur MCP de la bibliothèque d'images pour trouver un graphique pour l'article.

Quand utiliser quoi ?

Lorsque vous avez besoin d'une véritable collaboration, d'une itération et d'un perfectionnement, ou d'une expertise spécialisée répartie entre plusieurs agents.

Lorsqu'un agent unique a besoin d'accéder à plusieurs outils et sources de données ou nécessite une intégration standardisée avec des systèmes propriétaires.

Lorsque vous avez besoin des avantages organisationnels des systèmes multi-agents et des avantages de normalisation et d'écosystème du MCP.

Prestations de base

Autonomie et mise à l'échelle : Les agents peuvent prendre des décisions indépendantes et le système permet une mise à l'échelle horizontale des fonctions spécialisées.

Simplicité et normalisation : Le raisonnement centralisé facilite le débogage et la maintenance et fournit une interface universelle pour les ressources.

Séparation claire des préoccupations : Facilite la compréhension du système : A2A = travail d'équipe, MCP = accès aux outils.

Conclusion

Il s'agit de la première section de deux articles couvrant la mise en œuvre d'agents basés sur A2A et renforcés par des serveurs MCP pour fournir un support et un accès externe aux données et aux outils. La prochaine partie explorera le code réel pour démontrer qu'ils travaillent ensemble afin d'émuler les activités d'une salle de rédaction en ligne. Bien que les deux cadres soient extrêmement compétents et flexibles, vous verrez à quel point ils se complètent lorsqu'ils travaillent en tandem.

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

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

Comment configurer le découpage récursif ?

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

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

• L'un ou l'autre :

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

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

Comment fonctionne le découpage récursif ?

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

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

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

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

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

Exemples de configuration du découpage récursif

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

Utilisation de groupes de séparation

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

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

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

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

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

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

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

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

Un exemple de découpage récursif en action

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

Examinons un simple document Markdown non tronqué :

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

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

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

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

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

Mais la véritable magie s'opère lorsque vous pouvez introduire ces outils personnalisés et conscients des données dans les environnements où vous passez le plus clair de votre temps. Et si l'agent de votre éditeur de code pouvait accéder en toute sécurité à la base de connaissances privée de votre organisation ?

C'est là qu'intervient le protocole de contexte de modèle (MCP). Elastic Agent Builder est livré avec un serveur MCP intégré qui permet d'accéder aux outils de la plateforme.

Pourquoi utiliser le serveur MCP Elastic Agent Builder ?

Les agents d'IA sont incroyablement puissants, mais leurs connaissances sont généralement limitées aux données sur lesquelles ils ont été formés et aux informations qu'ils peuvent activement rechercher sur l'internet public. Ils ne connaissent pas les documents de conception internes de votre entreprise, les manuels de déploiement spécifiques de votre équipe ou la structure unique des journaux de votre application.

Le défi consiste à donner à votre assistant d'intelligence artificielle le contexte spécialisé dont il a besoin. C'est précisément le problème que le MCP est censé résoudre. MCP est une norme ouverte qui permet à un modèle ou à un agent d'IA de découvrir et d'utiliser des outils externes.

Pour rendre cela possible, l'Elastic Agent Builder expose nativement vos outils personnalisés par le biais d'un serveur MCP intégré. Cela signifie que vous pouvez facilement connecter n'importe quel client compatible MCP, comme Cursor, VS Code ou Claude Desktop, avec les outils spécialisés et sensibles aux données que vous avez construits avec Elastic Agent Builder.

Quand utiliser MCP (et quand ne pas le faire)

Elastic Agent Builder comprend plusieurs protocoles pour prendre en charge différents modèles d'intégration. Il est essentiel de choisir la bonne solution pour mettre en place des flux de travail efficaces en matière d'IA.

• Utilisez MCP pour compléter votre agent d'intelligence artificielle (comme dans Cursor ou VS Code) avec des outils spécialisés. Il s'agit de l'approche ""apportez vos propres outils"", qui permet d'améliorer l'assistant que vous utilisez déjà grâce à un accès sécurisé à vos données privées. Seuls les outils sont exposés par l'intermédiaire du serveur MCP - les agents d'Elastic sont distincts.

• Utilisez le protocole A2A pour permettre à votre agent Elastic personnalisé de collaborer avec d'autres agents autonomes (comme dans Gemini Enterprise de Google). Il s'agit de la délégation d'agent à agent, où chaque agent travaille comme un pair pour résoudre un problème.

• Utilisez les API de l'Agent Builder pour un contrôle programmatique complet lors de la création d'une application personnalisée à partir de zéro.

Pour un développeur qui cherche à obtenir des réponses dans sa documentation interne sans quitter son IDE, le MCP est la solution idéale.

Exemple : vos outils personnalisés dans Cursor avec le serveur MCP Agent Builder

Prenons un exemple pratique que j'utilise quotidiennement. Tout d'abord, j'ai exploré et indexé notre documentation technique interne dans un index Elasticsearch appelé elastic-dev-docs. Nous pourrions utiliser les outils génériques intégrés disponibles dans Agent Builder, mais nous allons créer notre propre outil personnalisé pour interroger cette base de connaissances spécifique.

La raison de la construction d'un outil sur mesure est simple : contrôle et précision. Cette approche nous permet d'exécuter une requête sémantique rapide directement sur notre index elastic-dev-docs. Nous avons un contrôle total sur l'index ciblé et sur la manière dont les données sont extraites.

Voici maintenant comment nous pouvons utiliser cette base de connaissances personnalisée dans un éditeur de code doté d'une intelligence artificielle, comme Cursor.

Étape 1 : Créer un outil de base de connaissances personnalisé dans Agent Builder

Tout d'abord, créez un nouvel outil dans Agent Builder. Une description claire et précise de l'outil est importante car c'est ainsi que tout agent d'IA, qu'il s'agisse de l'agent Elastic interne ou d'un outil externe tel que Cursor se connectant via MCP, découvre et sélectionne votre outil pour la bonne tâche.

Une description solide doit être explicite. Par exemple : "Effectue une recherche sémantique sur l'index elastic-dev-docs pour trouver la documentation d'ingénierie interne, les runbooks et les procédures de mise en production."

L'outil est alors configuré pour effectuer une recherche sémantique dans notre index spécifique. Une fois sauvegardé, il est immédiatement disponible pour être servi.

Avant de le connecter au monde extérieur, vous pouvez le tester directement dans l'interface utilisateur. Il suffit de cliquer sur le bouton Test pour remplir manuellement les paramètres, émuler ce que le LLM fera, et inspecter les résultats pour confirmer que tout fonctionne correctement.

Étape 2 : Connecter le curseur au serveur Elastic MCP

Elastic Agent Builder expose automatiquement tous les outils disponibles via un point de terminaison MCP sécurisé. Vous pouvez trouver l'URL unique de votre serveur dans l'interface utilisateur Outils de Kibana.

Pour se connecter à Cursor, il suffit d'ajouter cette URL à son fichier de configuration, ainsi qu'une clé API Elastic pour l'authentification(découvrez comment créer une clé API ES). Nous utilisons une clé API pour l'autorisation, car elle garantit que les outils ne s'exécutent qu'avec les permissions que vous avez accordées, en respectant toutes vos règles de contrôle d'accès.

La configuration MCP dans le site ~/.cursor/mcp.json de Cursor se présente comme suit :

Une fois la configuration sauvegardée, vous devriez voir l'outil Elastic Agent Builder MCP server disponible dans Cursor.

Étape 3 : Posez vos questions !

Une fois la connexion établie, les agents Cursor peuvent maintenant invoquer vos outils personnalisés pour répondre à vos questions ou guider le processus de génération de code.

Posons une question précise :

"Consulter les étapes pour libérer le service de crawler de la documentation interne de l'ingénierie d'elastic search org"

En coulisses, la magie opère :

1. L'agent du curseur décide de la meilleure façon de répondre à votre question et décide d'appeler la fonction engineering_documentation_internal_search

2. Il invoque l'outil à l'aide d'une requête en langage naturel

3. L'outil effectue une recherche sémantique dans l'index elastic-dev-docs et renvoie les procédures les plus pertinentes et les plus récentes.

Nous obtenons une réponse précise et fiable, basée sur notre documentation interne, sans jamais quitter l'éditeur de code. L'expérience est transparente et puissante.

À vous de construire

Vous avez maintenant vu comment utiliser le serveur MCP intégré dans Elastic Agent Builder pour étendre vos assistants IA avec un accès sécurisé à vos données privées. Pour que les modèles soient réellement utiles, il est essentiel de les ancrer dans vos propres informations.

Pour récapituler, nous avons couvert les principales étapes :

• Choisir le bon protocole pour vos besoins (MCP).

• Création d'un outil de base de connaissances personnalisé.

• Connecter cet outil à un assistant IDE comme Cursor.

Vos agents et vos outils n'ont plus besoin d'être déconnectés de leur contexte le plus précieux. Nous espérons que ce guide vous aidera à créer des flux de travail plus efficaces et tenant compte des données. Bonne construction !

Dans la pile Elastic, il existe de nombreuses applications agentiques alimentées par LLM, telles que le futur agent Elastic AI dans Agent Builder (actuellement en tech preview) et Attack Discovery (GA dans 8.18 et 9.0+), et d'autres sont en cours de développement. Pendant le développement, et même après le déploiement, il est important de répondre à ces questions :

• Comment évaluer la qualité des réponses de ces applications d'IA ?

• Si nous apportons un changement, comment pouvons-nous garantir qu'il s'agit réellement d'une amélioration et qu'il n'entraînera pas une dégradation de l'expérience de l'utilisateur ?

• Comment pouvons-nous facilement tester ces résultats de manière reproductible ?

Contrairement aux tests de logiciels traditionnels, l'évaluation des applications d'IA générative fait appel à des méthodes statistiques, à un examen qualitatif nuancé et à une compréhension approfondie des objectifs des utilisateurs.

Cet article détaille le processus employé par l'équipe de développeurs d'Elastic pour effectuer des évaluations, garantir la qualité des changements avant leur déploiement et contrôler les performances du système. Nous voulons nous assurer que chaque changement est étayé par des preuves, ce qui permet d'obtenir des résultats fiables et vérifiables. Une partie de ce processus est intégrée directement dans Kibana, ce qui reflète notre engagement en matière de transparence dans le cadre de notre éthique des logiciels libres. En partageant ouvertement une partie de nos données d'évaluation et de nos paramètres, nous cherchons à renforcer la confiance de la communauté et à fournir un cadre clair à tous ceux qui développent des agents d'intelligence artificielle ou utilisent nos produits.

Exemples de produits

Les méthodes utilisées dans ce document ont servi de base à l'itération et à l'amélioration de solutions telles que Attack Discovery et Elastic AI Agent. Une brève présentation des deux, respectivement :

Découverte d'attaques par Elastic Security

Attack Discovery utilise les LLM pour identifier et résumer les séquences d'attaques dans Elastic. À partir des alertes d'Elastic Security dans un délai donné (24 heures par défaut), le flux de travail agentique d'Attack Discovery déterminera automatiquement si une ou plusieurs attaques ont eu lieu, ainsi que des informations importantes telles que l'hôte ou les utilisateurs compromis, et les alertes qui ont contribué à la conclusion de l'attaque.

L'objectif est que la solution basée sur le LLM produise un résultat au moins aussi bon que celui d'un humain.

Agent d'IA élastique

L'Elastic Agent Builder est notre nouvelle plateforme pour la création d'agents d'intelligence artificielle sensibles au contexte qui tirent parti de toutes nos capacités de recherche. Il est livré avec l'agent Elastic AI, un agent général préconstruit conçu pour aider les utilisateurs à comprendre et à obtenir des réponses à partir de leurs données par le biais d'une interaction conversationnelle.

L'agent y parvient en identifiant automatiquement les informations pertinentes dans Elasticsearch ou dans les bases de connaissances connectées et en tirant parti d'une série d'outils prédéfinis pour interagir avec elles. Cela permet à l'agent Elastic AI de répondre à un large éventail de requêtes d'utilisateurs, allant de la simple Q&A sur un seul document à des demandes complexes nécessitant une agrégation et des recherches en une ou plusieurs étapes dans plusieurs index.

Mesurer les améliorations au moyen d'expériences

Dans le contexte des agents d'intelligence artificielle, une expérience est une modification structurée et testable du système conçue pour améliorer les performances sur des aspects bien définis (par exemple, l'utilité, l'exactitude, la latence). L'objectif est de répondre de manière définitive à la question suivante "Si nous fusionnons ce changement, pouvons-nous garantir qu'il s'agit d'une véritable amélioration et qu'il ne dégradera pas l'expérience de l'utilisateur ?"

La plupart des expériences que nous menons comprennent généralement

• Une hypothèse : Une affirmation spécifique et falsifiable. Exemple : "L'accès à un outil de découverte d'attaques améliore l'exactitude des requêtes liées à la sécurité.

• Critères de réussite : Des seuils clairs qui définissent ce qu'on entend par "succès". Exemple : "+5% amélioration du score de justesse sur l'ensemble de données de sécurité, pas de dégradation ailleurs".

• Plan d'évaluation : Comment nous mesurons le succès (mesures, ensembles de données, méthode de comparaison)

Une expérience réussie est un processus systématique de recherche. Chaque changement, qu'il s'agisse d'une modification mineure ou d'un changement architectural majeur, suit ces sept étapes afin de garantir que les résultats sont significatifs et exploitables :

• Étape 1 : Identifier le problème

• Étape 2 : Définir les indicateurs

• Étape 3 : Formuler une hypothèse claire

• Étape 4 : Préparation de l'ensemble de données d'évaluation

• Étape 5 : Exécuter l'expérience

• Étape 6 : Analyse des résultats + itération

• Étape 7 : Prendre une décision et la documenter

Un exemple de ces étapes est illustré à la figure 1. Les sous-sections suivantes expliquent chaque étape, et nous développerons les détails techniques de chaque étape dans les documents à venir.

Une démonstration pas à pas avec des exemples réels d'Elastic

Étape 1 : Identifier le problème

Quel est exactement le problème que ce changement vise à résoudre ?

Exemple de découverte d'attaques : Les résumés sont parfois incomplets, ou une activité bénigne est signalée à tort comme une attaque (faux positifs).

Exemple d'agent d'IA élastique : La sélection des outils de l'agent, en particulier pour les requêtes analytiques, est sous-optimale et incohérente, conduisant souvent au choix du mauvais outil. Cela entraîne une augmentation des coûts des jetons et de la latence.

Étape 2 : Définir les indicateurs

Rendre le problème mesurable, afin de pouvoir comparer un changement à l'état actuel.

Les mesures courantes comprennent la précision et le rappel, la similarité sémantique, la factualité, etc. Selon le cas d'utilisation, nous utilisons des vérifications de code pour calculer les mesures, telles que la correspondance des identifiants d'alerte ou des URL correctement récupérés, ou nous utilisons des techniques telles que LLM-as-judge pour des réponses plus libres.

Voici quelques exemples de mesures(non exhaustifs) utilisées dans les expériences :

Attack Discovery

Métrique

Description

Précision & rappel

Faire correspondre les identifiants d'alerte entre les sorties réelles et les sorties prévues afin de mesurer la précision de la détection.

Similitude

Utilisez BERTScore pour comparer la similarité sémantique du texte de la réponse.

Factualité

Les principaux IOC (indicateurs de compromission) sont-ils présents ? Les tactiques de MITRE (taxonomie industrielle des attaques) sont-elles correctement prises en compte ?

Cohérence de la chaîne d'attaque

Comparez le nombre de découvertes pour vérifier si l'attaque a été sur ou sous-déclarée.

Agent d'IA élastique

Métrique

Description

Précision & rappel

Faire correspondre les documents/informations récupérés par l'agent pour répondre à une requête de l'utilisateur avec les informations ou documents réels nécessaires pour répondre à la requête afin de mesurer la précision de la recherche d'informations.

Factualité

Les faits essentiels nécessaires pour répondre à la demande de l'utilisateur sont-ils présents ? Les faits sont-ils dans le bon ordre pour les questions de procédure ?

Pertinence de la réponse

La réponse contient-elle des informations périphériques ou sans rapport avec la requête de l'utilisateur ?

Complétude de la réponse

La réponse répond-elle à toutes les parties de la requête de l'utilisateur ? La réponse contient-elle toutes les informations présentes dans la vérité terrain ?

Validation ES|QL

La syntaxe de l'ES|QL générée est-elle correcte ? Est-il fonctionnellement identique à la vérité de terrain ES|QL ?

Étape 3 : Formuler une hypothèse claire

Établir des critères de réussite clairs en utilisant le problème et les paramètres définis ci-dessus.

Exemple d'agent d'IA élastique :

1. Apporter des modifications aux descriptions des outils relevance_search et nl_search afin de définir clairement leurs fonctions spécifiques et leurs cas d'utilisation.

2. Nous prévoyons d'améliorer la précision de l'invocation des outils de 25%.

3. Nous vérifierons qu'il s'agit d'un résultat positif net en nous assurant qu'il n'y a pas d'impact négatif sur d'autres indicateurs, par exemple l'exactitude et l'exhaustivité des données.

4. Nous pensons que cela fonctionnera parce que des descriptions précises des outils aideront l'agent à sélectionner et à appliquer avec plus de précision l'outil de recherche le plus approprié pour différents types de requêtes, ce qui réduira les erreurs d'application et améliorera l'efficacité globale de la recherche.

Étape 4 : Préparation de l'ensemble de données d'évaluation

Pour mesurer les performances du système, nous utilisons des ensembles de données qui représentent des scénarios réels.

Selon le type d'évaluation que nous menons, nous pouvons avoir besoin de différents types de formats de données, tels que les données brutes transmises à un LLM (par ex. scénarios d'attaque pour la découverte d'attaques) et les résultats attendus. Si l'application est un chatbot, les entrées peuvent être des requêtes d'utilisateurs, et les sorties peuvent être des réponses correctes du chatbot, des liens corrects qu'il aurait dû récupérer, etc.

Exemple de découverte d'attaque :

10 nouveaux scénarios d'attaque

8 épisodes de Oh My Malware (ohmymalware.com)

4 scénarios multi-attaques (créés en combinant les attaques des 2 premières catégories)

3 scénarios bénins

Exemple de jeu de données d'évaluation d'un agent d'IA élastique(lien vers le jeu de données Kibana) :

14 Indices utilisant des ensembles de données open source pour simuler des sources multiples dans KB.

5 Types de requêtes (analytique, recherche de texte, hybride...)

7 Types d'intentions d'interrogation (procédurale, factuelle - classification, enquête ; ...)

Étape 5 : Exécuter l'expérience

Exécuter l'expérience en générant des réponses à partir de l'agent existant et de la version modifiée par rapport à l'ensemble de données d'évaluation. Calculer des paramètres tels que la factualité (voir étape 2).

Nous mélangeons plusieurs évaluations basées sur les paramètres requis à l'étape 2 :

• Évaluation basée sur des règles (par exemple utiliser Python/TypeScript pour vérifier si .json est valide)

• LLM-as-judge (demander à un LLM séparé si une réponse est cohérente avec un document source)

• Examen humain dans la boucle pour les contrôles de qualité des nuances

Étape 6 : Analyse des résultats + itération

Maintenant que nous disposons des mesures, nous analysons les résultats. Même si les résultats satisfont aux critères de réussite définis à l'étape 3, il faut encore procéder à un examen humain avant de fusionner la modification avec la production; si les résultats ne satisfont pas aux critères, il faut procéder à une itération et résoudre les problèmes, puis effectuer les évaluations sur la nouvelle modification.

Nous pensons qu'il faudra quelques itérations pour trouver la meilleure modification avant de procéder à la fusion. De la même manière que l'on exécute des tests logiciels locaux avant de valider un projet, les évaluations hors ligne peuvent être exécutées avec des modifications locales ou plusieurs propositions de modifications. Il est utile d'automatiser l'enregistrement des résultats d'expériences, des scores composites et des visualisations pour rationaliser l'analyse.

Étape 7 : Prendre une décision et la documenter

Sur la base d'un cadre de décision et de critères d'acceptation, décider de fusionner les changements et documenter l'expérience. La prise de décision comporte de multiples facettes et peut prendre en compte des facteurs au-delà de l'ensemble de données d'évaluation, tels que la vérification des scénarios de régression sur d'autres ensembles de données ou l'évaluation du rapport coût-bénéfice d'un changement proposé.

Exemple : Après avoir testé et comparé quelques itérations, choisissez la modification la mieux notée et envoyez-la aux chefs de produit et aux autres parties prenantes concernées pour approbation. Joignez les résultats des étapes précédentes pour vous aider à prendre une décision. Pour plus d'exemples sur la découverte d'attaques, voir Dans les coulisses des fonctions d'IA générative d'Elastic Security.

Conclusion

Dans ce blog, nous avons parcouru le processus de bout en bout d'un flux d'expérimentation, illustrant comment nous évaluons et testons les changements apportés à un système agentique avant de les diffuser aux utilisateurs d'Elastic. Nous avons également fourni quelques exemples d'amélioration des flux de travail basés sur des agents dans Elastic. Dans les prochains billets de blog, nous développerons les détails des différentes étapes, telles que la création d'un bon ensemble de données, la conception de mesures fiables et la prise de décisions lorsque plusieurs mesures sont impliquées.

Mais qu'en est-il si vous souhaitez utiliser vos agents personnalisés avec les applications et les outils de productivité dont vous disposez déjà ?

C'est là qu'intervient le protocole Agent-to-Agent (A2A). A2A est une norme ouverte d'interopérabilité qui permet aux agents de différentes plateformes de communiquer et de collaborer. Et nous l'avons intégré directement dans l'Elastic Agent Builder.

Aujourd'hui, nous allons vous montrer comment prendre un agent personnalisé que vous avez construit et l'exposer à d'autres services, en particulier Gemini Enterprise (anciennement Agentspace).

Le pouvoir des normes ouvertes : l'importance de l'A2A

Dans l'article de blog Votre premier agent Elastic, nous avons montré comment créer des agents personnalisés, tels qu'un agent Assistant financier avec un accès sécurisé à vos données de marché. Mais sa valeur est limitée si vous ne pouvez pas rendre ses informations disponibles dans d'autres environnements, comme Gemini Enterprise, sans avoir à reconstruire votre travail.

C'est ce défi de l'interopérabilité qui freine l'IA agentique. Les agents ont besoin d'un langage commun pour communiquer entre les plateformes, ce qui est précisément le rôle du protocole A2A. Il fournit une couche de communication standard qui vous permet non seulement d'interagir directement avec votre agent, mais qui ouvre également la voie à un avenir où les agents spécialisés de votre organisation pourront collaborer et partager des informations.

Pour rendre cela possible, l'Elastic Agent Builder supporte nativement le protocole A2A à travers deux points de terminaison standard pour tous vos agents :

1. Le point de terminaison de la carte d'agent (GET {your-kibana-url}/api/agent_builder/a2a/{agentId}.json )- Il s'agit de la carte de visite de votre agent personnalisé. Il fournit des métadonnées sur votre agent (nom, description, capacités, etc.) à tout service compatible A2A.

2. Le point de terminaison du protocole A2A (POST {your-kibana-url}/api/agent_builder/a2a/{agentId}) - Il s'agit du canal de communication. D'autres agents envoient leurs demandes ici, et votre agent les traite et renvoie une réponse, conformément à la spécification du protocole A2A.

Testez votre agent avec l'inspecteur A2A

Avant de connecter notre agent à un système de production, il est bon de vérifier qu'il communique correctement. Le moyen le plus simple d'y parvenir est d'utiliser l'inspecteur A2A, un outil spécialement conçu pour tester et déboguer les intégrations A2A.

La mise en route de l'inspecteur est simple. Vous pouvez cloner le dépôt a2a-inspector et suivre les instructions du README pour lancer l'application. Une fois lancée, l'interface utilisateur est disponible par défaut à l'adresse http://localhost:5001/.

Pour connecter l'inspecteur A2A à votre agent, vous devez fournir deux informations essentielles :

• URL de la carte d'agent : Il s'agit du point de terminaison qui décrit votre agent. Pour l'agent assistant financier de notre poste précédent, cette URL serait {your-kibana-url}/api/agent_builder/a2a/financial_assistant.json.

• En-tête d'authentification : Nous utiliserons une clé API standard pour l'authentification.

Une fois que vous avez saisi ces informations dans l'interface utilisateur de l'inspecteur, vous pouvez vous connecter et commencer à dialoguer avec votre agent immédiatement.

Cette simple validation nous donne l'assurance que notre agent est configuré correctement et qu'il est prêt pour l'étape suivante.

En direct ! Votre agent personnalisé dans Gemini Enterprise

Passons maintenant à la partie la plus excitante : donner vie à notre agent financier personnalisé au sein de Gemini Enterprise (anciennement Agentspace). Cette intégration s'appuie sur l'agent Elastic AI, disponible sur Google Cloud Marketplace.

Une fois connecté, Gemini Enterprise utilise le protocole A2A pour communiquer directement avec votre agent. C'est là que la véritable puissance de l'interopérabilité se manifeste : les utilisateurs peuvent désormais accéder aux informations approfondies et axées sur les données de votre agent Elasticsearch personnalisé sans jamais quitter leur environnement familier. Vous pouvez voir votre agent Elastic personnalisé dans la liste des agents :

Imaginez qu'un utilisateur de Gemini Enterprise demande :

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

En coulisses, Gemini Enterprise achemine cette requête via le protocole A2A vers votre agent Elastic personnalisé. Votre agent utilise alors ses outils spécialisés pour interroger vos données, formuler une réponse et la renvoyer. Pour l'utilisateur final, l'expérience est transparente.

Et cela ne s'arrête pas là ! La réponse obtenue avec l'agent Elastic peut maintenant être utilisée comme contexte pour vos prochaines questions qui peuvent déclencher un agent spécialisé différent (par exemple, l'agent Elastic). l'agent de votre plateforme d'investissement pour ajuster l'exposition aux sociétés cotées). Le tout sans quitter votre barre de recherche.

Avec vos agents Elastic déployés sur Gemini Enterprise avec A2A, vous pouvez unifier l'accès, l'orchestration et les flux de travail en éliminant les frictions entre l'IA, la recherche et les systèmes d'entreprise en offrant une interface utilisateur unique où les utilisateurs parlent à leurs données et à leurs outils - le tout en contexte. Pour les utilisateurs, cela signifie moins de changements d'outils et des assistants d'IA plus intuitifs et plus compétents. Pour les organisations, cela signifie une gouvernance cohérente, une évolutivité et une interopérabilité intégrées.

À vous de construire

Vous disposez désormais des outils nécessaires pour que vos agents élastiques soient disponibles partout. En tirant parti du protocole ouvert A2A, vous pouvez étendre la portée de vos agents personnalisés et sensibles aux données.

Dans cet article, nous vous avons présenté les principales étapes :

• Exposer votre agent via la carte d'agent A2A et les points d'extrémité du protocole.

• Tester la connexion avec l'inspecteur A2A.

• Intégrer votre agent en direct dans un service externe tel que Gemini Enterprise de Google.

Vos agents n'ont plus besoin d'être isolés. Nous sommes impatients de voir les systèmes puissants et interconnectés que vous créerez. Bonne construction !

Le moyen le plus simple de commencer est d'essayer gratuitement Elastic Cloud sur Google Cloud Marketplace.

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

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

Étape 0 : Notre ensemble de données

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

financial_accounts: Portefeuilles de clients avec profils de risque

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

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

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

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

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

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

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

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

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

En bref : jonctions et garde-corps

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

1. La jointure LOOKUP

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

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

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

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

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

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

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

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

Le chemin de l'interface utilisateur

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

1. Naviguer vers Agents

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

2. Remplissez le formulaire avec les informations suivantes :

• ID de l'outil : find_client_exposure_to_negative_news

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

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

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

• Étiquettes: retrieval et risk-analysis

Les étiquettes sont utilisées pour regrouper plusieurs outils

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

i. Voici la recherche que l'agent utilisera

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

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

4. Testez-le !

• Cliquez sur Save & test.

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

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

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

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

Le chemin de l'API

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

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

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

L'art de la proposition

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

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

Voyons pourquoi cette incitation est si efficace :

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

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

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

Le chemin de l'interface utilisateur

1. Naviguez vers Agents.

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

2. Complétez les informations de base :

• ID de l'agent : financial_assistant.

• Instructions : Copiez le message ci-dessus.

• Étiquettes: Finance.

• Nom d'affichage : Financial Assistant.

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

3. De retour en haut, cliquez sur Outils.

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

4. Cliquez sur Enregistrer.

Le chemin de l'API

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

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

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

Le chemin de l'interface utilisateur

1. Naviguez jusqu'à Agents dans Kibana.

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

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

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

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

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

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

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

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

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

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

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

Le chemin de l'API

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

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

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

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

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

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

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

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

Conclusion : À vous de construire

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

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

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

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

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

Restez à l'écoute et bonne construction !

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

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

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

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

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

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

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

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

Création d'agents dans la plate-forme

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

Agents

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

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

1. Interpréter votre contribution et votre objectif

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

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

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

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

L'agent par défaut

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

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

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

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

Agents des douanes

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

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

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

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

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

Outils

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

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

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

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

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

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

Normes ouvertes et interopérabilité

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

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

Protocole de contexte de modèle (MCP)

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

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

Agent à agent (A2A)

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

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

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

Recherche et évaluation

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

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

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

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

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

Security

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

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

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

Ce qui vient ensuite

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

1. Engagement en faveur des normes Open Source &

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

2. Valeur du contexte

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

3. Focus sur les flux de données agentiques

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

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

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

5. Intégré dans la plate-forme

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

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

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

Dans cet article, nous allons y parvenir. Nous allons créer une application qui prend une image d'un tableau de bord, analyse nos mappings et génère un tableau de bord sans que nous ayons à toucher à Kibana !

Les étapes:

1. Contexte & flux de travail de l'application

2. Préparer les données

3. Configuration LLM

4. Fonctions d'application

Contexte & flux de travail de l'application

La première idée qui m'est venue à l'esprit a été de laisser le LLM générer l'ensemble des objets sauvegardés au format NDJSON dans Kibana, puis de les importer dans Kibana.

Nous avons essayé une poignée de modèles :

• Gemini 2.5 pro

• GPT o3 / o4-mini-high / 4.1

• Sonnet de Claude 4

• Grok 3

• Deepseek (Deepthink R1)

En ce qui concerne les messages-guides, nous avons commencé par une phrase simple :

Bien que nous ayons parcouru des exemples en quelques images et des explications détaillées sur la manière de construire chaque visualisation, nous n'avons pas eu de chance. Si vous êtes intéressé par cette expérimentation, vous pouvez trouver des détails ici.

Le résultat de cette approche était l'apparition de ces messages lorsque l'on essayait de télécharger vers Kibana les fichiers produits par le LLM :

Cela signifie que le JSON généré est invalide ou mal formaté. Les problèmes les plus fréquents étaient que le LLM produisait des NDJSON incomplets, des paramètres hallucinants ou retournait du JSON normal au lieu de NDJSON, même si nous essayions de faire en sorte qu'il en soit autrement.

Inspirés par cet article - où les modèles de recherche ont mieux fonctionné que le LLM freestyle - nous avons décidé de donner des modèles au LLM au lieu de demander de générer le fichier NDJSON complet et ensuite nous, dans le code, utilisons les paramètres donnés par le LLM pour créer les visualisations appropriées.

Le processus de candidature sera le suivant :

Nous omettons une partie du code pour des raisons de simplicité, mais vous pouvez trouver le code de travail de l'application complète sur ce carnet.

Produits requis

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

1. Python 3.8 ou supérieur

2. Un environnement Venv Python

3. Une instance Elasticsearch en cours d'exécution, ainsi que son point d'accès et sa clé API

4. Une clé d'API OpenAI stockée dans la variable d'environnement OPENAI_API_KEY :

Préparer les données

Pour les données, nous resterons simples et utiliserons les journaux web de l'échantillon Elastic. Pour savoir comment importer ces données dans votre cluster , cliquez ici.

Chaque document contient des informations sur l'hôte qui a envoyé des demandes à l'application, ainsi que des informations sur la demande elle-même et l'état de sa réponse. Vous trouverez ci-dessous un exemple de document :

Prenons maintenant les mappings de l'index que nous venons de charger, kibana_sample_data_logs:

Nous allons transmettre les mappings avec l'image que nous chargerons plus tard.

Configuration LLM

Configurons le LLM pour qu'il utilise la sortie structurée afin d'entrer une image et de recevoir un JSON contenant les informations que nous devons transmettre à notre fonction pour produire les objets JSON.

Nous installons les dépendances :

Elasticsearch nous aidera à récupérer les mappages d'index. Pydantic nous permet de définir des schémas en Python pour demander au LLM de les suivre, et LangChain est le cadre qui facilite l'appel aux LLM et aux outils d'IA.

Nous allons créer un schéma pydantique pour définir les résultats que nous voulons obtenir du LLM. Ce que nous devons savoir à partir de l'image, c'est le type de graphique, le champ, le titre de la visualisation et le titre du tableau de bord :

Pour la saisie de l'image, nous enverrons un tableau de bord que je viens de dessiner :

Nous déclarons maintenant l'appel au modèle LLM et le chargement de l'image. Cette fonction recevra les mappings de l'index Elasticsearch et une image du tableau de bord que nous voulons générer.

Avec with_structured_output, nous pouvons utiliser notre schéma Pydantic Dashboard comme objet de réponse que le LLM produira. Avec Pydantic, nous pouvons définir des modèles de données avec validation, ce qui garantit que la sortie LLM correspond à la structure attendue.

Pour convertir l'image en base64 et l'envoyer en entrée, vous pouvez utiliser un convertisseur en ligne ou le faire en code.

Le LLM connaît déjà le contexte des tableaux de bord Kibana, nous n'avons donc pas besoin de tout expliquer dans l'invite, juste quelques détails pour s'assurer qu'il n'oublie pas qu'il travaille avec Elasticsearch et Kibana.

Décortiquons l'invitation :

Section

Raison

Vous êtes un expert en analyse de tableaux de bord Kibana à partir d'images pour la version 9.0.0 de Kibana.

En insistant sur le fait qu'il s'agit d'Elasticsearch et de la version d'Elasticsearch, nous réduisons la probabilité que le LLM hallucine des paramètres anciens/invalides.

Vous recevrez une image de tableau de bord et un mappage d'index Elasticsearch.

Nous expliquons que l'image concerne les tableaux de bord afin d'éviter toute interprétation erronée de la part du LLM.

Vous trouverez ci-dessous les correspondances d'index pour l'index sur lequel le tableau de bord est basé, ce qui vous aidera à comprendre les données et les champs disponibles. Mappages d'index : {index_mappings}

Il est essentiel de fournir les correspondances afin que le LLM puisse sélectionner les champs valides de manière dynamique. Sinon, nous pourrions coder en dur les correspondances ici, ce qui est trop rigide, ou compter sur le fait que l'image contienne les bons noms de champs, ce qui n'est pas fiable.

N'incluez que les champs pertinents pour chaque visualisation, en fonction de ce qui est visible dans l'image.

Nous avons dû ajouter ce renforcement parce qu'il arrive que l'on essaie d'ajouter des champs qui ne sont pas pertinents pour l'image.

Cela renvoie un objet contenant un tableau de visualisations à afficher :

Traitement de la réponse au mécanisme d'apprentissage tout au long de la vie

Nous avons créé un exemple de tableau de bord 2x2 panneaux à l'adresseet l'avons exporté en JSON à l'aide de l'API Get a dashboard, puis nous avons stocké les panneaux en tant que modèles de visualisation (camembert, barre, métrique) dans lesquels nous pouvons remplacer certains paramètres pour créer de nouvelles visualisations avec différents champs en fonction de la question.

Vous pouvez consulter les fichiers JSON du modèle ici. Notez que nous avons modifié les valeurs de l'objet que nous voulons remplacer plus tard par {variable_name}

Grâce aux informations fournies par le mécanisme d'apprentissage tout au long de la vie, nous pouvons décider du modèle à utiliser et des valeurs à remplacer.

fill_template_with_analysis recevra les paramètres pour un seul panneau, y compris le modèle JSON de la visualisation, un titre, un champ et les coordonnées de la visualisation sur la grille.

Ensuite, il remplacera les valeurs du modèle et renverra la visualisation JSON finale.

Pour faire simple, nous aurons des coordonnées statiques que nous assignerons aux panneaux que le LLM décidera de créer et nous produirons un tableau de bord à grille 2x2 comme l'image ci-dessus.

En fonction du type de visualisation décidé par le LLM, nous choisirons un modèle de fichier JSON et remplacerons les informations pertinentes à l'aide de fill_template_with_analysis , puis nous ajouterons le nouveau panneau à un tableau que nous utiliserons ultérieurement pour créer le tableau de bord.

Lorsque le tableau de bord est prêt, nous utilisons l'API Create a dashboard pour envoyer le nouveau fichier JSON à Kibana afin de générer le tableau de bord :

Pour exécuter le script et générer le tableau de bord, exécutez la commande suivante dans la console :

Le résultat final sera le suivant :

Conclusion

Les LLM démontrent leurs fortes capacités visuelles lorsqu'ils transforment du texte en code ou des images en code. L'API des tableaux de bord permet également de transformer des fichiers JSON en tableaux de bord, et avec un LLM et un peu de code, nous pouvons transformer des images en tableau de bord Kibana.

L'étape suivante consiste à améliorer la flexibilité des visuels des tableaux de bord en utilisant différents paramètres de grille, différentes tailles de tableau de bord et différentes positions. De plus, la prise en charge de visualisations et de types de visualisation plus complexes serait un ajout utile à cette application.

Dans ce billet, nous allons voir comment construire un assistant RAG agentique en utilisant Mastra et une application web JavaScript légère pour interagir avec lui. En connectant cet agent à Elasticsearch, nous lui donnons accès aux données structurées des joueurs et la possibilité d'exécuter des agrégations statistiques en temps réel, afin de vous donner des recommandations fondées sur les statistiques des joueurs. Rendez-vous sur le repo GitHub pour suivre le processus ; le README fournit des instructions sur la manière de cloner et d'exécuter l'application par vos propres moyens.

Voici à quoi il devrait ressembler une fois assemblé :

Remarque : cet article de blog s'appuie sur "Building AI Agents with AI SDK and Elastic" ( Créer des agents d'intelligence artificielle avec AI SDK et Elastic). Si vous ne connaissez pas encore les agents d'intelligence artificielle en général et leur utilité, commencez par là.

Aperçu de l'architecture

Au cœur du système se trouve un grand modèle de langage (LLM), qui agit comme le moteur de raisonnement de l'agent (le cerveau). Il interprète les données de l'utilisateur, décide des outils à appeler et orchestre les étapes nécessaires pour générer une réponse pertinente.

L'agent lui-même est soutenu par Mastra, un cadre d'agent dans l'écosystème JavaScript. Mastra intègre le LLM à une infrastructure dorsale, l'expose en tant que point d'extrémité de l'API et fournit une interface pour définir les outils, les invites du système et le comportement de l'agent.

Sur le frontend, nous utilisons Vite pour mettre en place rapidement une application web React qui fournit une interface de chat pour envoyer des requêtes à l'agent et recevoir ses réponses.

Enfin, nous avons Elasticsearch, qui stocke les statistiques des joueurs et les données de correspondance que l'agent peut interroger et agréger.

Arrière-plan

Passons en revue quelques concepts fondamentaux :

Qu'est-ce que le RAG agentique ?

Les agents d'intelligence artificielle peuvent interagir avec d'autres systèmes, fonctionner de manière indépendante et effectuer des actions en fonction de paramètres définis. Le RAG agentique combine l'autonomie d'un agent d'intelligence artificielle avec les principes de la génération augmentée par récupération, ce qui permet à un LLM de choisir les outils à utiliser et les données à utiliser comme contexte pour générer une réponse. Pour en savoir plus sur le RAG , cliquez ici.

Pourquoi aller plus loin que AI-SDK dans le choix d'un framework ?

Il existe de nombreuses structures d'agents d'IA et vous avez probablement entendu parler des plus populaires comme CrewAI, AutoGen et LangGraph. La plupart de ces cadres partagent un ensemble commun de fonctionnalités, notamment la prise en charge de différents modèles, l'utilisation d'outils et la gestion de la mémoire.

Voici une fiche comparative de Harrison Chase (PDG de LangChain).

Ce qui a suscité mon intérêt pour Mastra, c'est qu'il s'agit d'un framework JavaScript conçu pour les développeurs full-stack afin d'intégrer facilement des agents dans leur écosystème. L'AI-SDK de Vercel permet également de réaliser la plupart de ces tâches, mais c'est lorsque vos projets incluent des flux de travail d'agents plus complexes que Mastra brille. Mastra améliore les modèles de base définis par l'AI-SDK et, dans ce projet, nous les utiliserons en tandem.

Cadres et considérations sur le choix du modèle

Si ces frameworks peuvent vous aider à créer rapidement des agents d'intelligence artificielle, ils présentent néanmoins certains inconvénients. Par exemple, l'utilisation d'autres cadres en dehors des agents d'IA ou de toute couche d'abstraction en général vous fait perdre un peu de contrôle. Si le LLM n'utilise pas les outils correctement ou fait quelque chose que vous ne voulez pas qu'il fasse, l'abstraction rend le débogage plus difficile. Cependant, à mon avis, ce compromis vaut la facilité et la rapidité que vous obtenez lors de la construction, en particulier parce que ces cadres gagnent du terrain et font l'objet d'itérations constantes.

Encore une fois, ces cadres sont agnostiques, ce qui signifie que vous pouvez brancher et utiliser différents modèles. N'oubliez pas que les modèles varient en fonction des ensembles de données sur lesquels ils ont été formés et qu'à leur tour, ils varient en fonction des réponses qu'ils donnent. Certains modèles ne prennent même pas en charge l'appel d'outils. Il est donc possible de changer et de tester différents modèles pour voir lequel vous donne les meilleures réponses, mais gardez à l'esprit que vous devrez probablement réécrire l'invite du système pour chacun d'entre eux. Par exemple, en utilisant Llama3.3 par rapport au GPT-4o, implique beaucoup plus d'invites et d'instructions spécifiques pour obtenir la réponse souhaitée.

Basket-ball fantaisie NBA

Le basket-ball fantaisie consiste à créer une ligue avec un groupe d'amis (attention, selon le degré de compétition de votre groupe, cela peut affecter le statut de vos amitiés), généralement avec de l'argent en jeu. Chacun d'entre vous constitue ensuite une équipe de 10 joueurs pour affronter les 10 joueurs d'un autre ami, en alternance chaque semaine. Les points qui contribuent à votre score global sont les résultats obtenus par chacun de vos joueurs contre leurs adversaires au cours d'une semaine donnée.

Si un joueur de votre équipe se blesse, est suspendu, etc., il y a une liste d'agents libres disponibles pour compléter votre équipe. C'est là qu'intervient une grande partie de la réflexion dans les sports fantastiques, car vous ne disposez que d'un nombre limité de choix et tout le monde est constamment à la recherche du meilleur joueur.

C'est là que notre assistant NBA AI va briller, en particulier dans les situations où vous devez rapidement décider quel joueur choisir. Au lieu de devoir rechercher manuellement les performances d'un joueur contre un adversaire spécifique, l'assistant peut trouver ces données rapidement et comparer les moyennes pour vous donner une recommandation éclairée.

Maintenant que vous connaissez les bases du RAG agentique et du basket-ball fantastique NBA, voyons ce qu'il en est dans la pratique.

Construire le projet

Si vous êtes bloqué à un moment ou à un autre ou si vous ne voulez pas le construire à partir de zéro, veuillez vous référer au repo.

Ce que nous allons couvrir

1. L'échafaudage du projet :

   1. Backend (Mastra) : Utilisez npx create mastra@latest pour échafauder le backend et définir la logique de l'agent.

   2. Frontend (Vite + React) : Utilisez npm create vite@latest pour construire l'interface de chat frontale pour interagir avec l'agent.

2. Mise en place de variables d'environnement

   1. Installer dotenv pour gérer les variables d'environnement.

   2. Créer un fichier .env et fournir les variables nécessaires.

3. Configuration d'Elasticsearch

   1. Mettre en place un cluster Elasticsearch (localement ou sur le cloud).

   2. Installer le client Elasticsearch officiel.

   3. S'assurer que les variables d'environnement sont accessibles.

   4. Établir la connexion avec le client.

4. Acquisition en masse de données NBA dans Elasticsearch

   1. Créez un index avec les mappings appropriés pour permettre les agrégations.

   2. Intégrez en masse les statistiques de jeu des joueurs à partir d'un fichier CSV dans un index Elasticsearch.

5. Définir les agrégations Elasticsearch

   1. Requête pour calculer les moyennes historiques contre un adversaire spécifique.

   2. Requête pour calculer les moyennes de la saison contre un adversaire spécifique.

6. Fichier utilitaire de comparaison des joueurs

   1. Consolidation des fonctions d'aide et des agrégations Elasticsearch.

7. Construction de l'agent

   1. Ajouter la définition de l'agent et l'invite du système.

   2. Installer les outils zod et define.

   3. Ajout d'une configuration intermédiaire pour gérer CORS.

8. Intégration de l'interface utilisateur

   1. Utilisation de la fonction useChat de l'AI-SDK pour interagir avec l'agent.

   2. Créer l'interface utilisateur pour tenir des conversations correctement formatées.

9. Exécution de l'application

   1. Démarrez le backend (serveur Mastra) et le frontend (application React).

   2. Exemples de requêtes et d'utilisation.

10. Et maintenant ? Rendre l'agent plus intelligent

    1. Ajout de capacités de recherche sémantique pour permettre des recommandations plus pertinentes.

    2. Activer l'interrogation dynamique en déplaçant la logique de recherche vers le serveur Elasticsearch MCP (Model Context Protocol).

Produits requis

• Node.js et npm: Le backend et le frontend fonctionnent tous deux sur Node. Assurez-vous d'avoir installé Node 18+ et npm v9+ (qui est fourni avec Node 18+).

• Cluster Elasticsearch : Un cluster Elasticsearch actif, soit localement, soit sur le cloud.

• Clé API OpenAI: Générez-en une sur la page des clés API du portail des développeurs d'OpenAI.

Structure du projet

Étape 1 : Échafaudage du projet

1. Tout d'abord, créez le répertoire nba-ai-assistant-js et naviguez à l'intérieur en utilisant :

Backend :

1. Utilisez l'outil de création Mastra avec la commande :

2. Vous devriez obtenir quelques invites dans votre terminal, pour la première, nous nommerons le projet backend :

3. Ensuite, nous conserverons la structure par défaut pour le stockage des fichiers Mastra, en saisissant src/.

4. Ensuite, nous choisirons OpenAI comme fournisseur LLM par défaut.

5. Enfin, il vous demandera votre clé API OpenAI. Pour l'instant, nous choisirons d'ignorer l'option et nous la fournirons plus tard dans un fichier .env.

Frontend :

1. Naviguez à nouveau vers le répertoire racine et exécutez l'outil de création Vite à l'aide de cette commande : npm create vite@latest frontend -- --template react

Cela devrait créer une application React légère nommée frontend avec un modèle spécifique pour React.

Si tout se passe bien, à l'intérieur de votre répertoire de projet, vous devriez trouver un répertoire backend qui contient le code Mastra et un répertoire frontend avec votre application React.

Étape 2 : Configuration des variables d'environnement

1. Pour gérer les clés sensibles, nous utiliserons le paquetage dotenv pour charger nos variables d'environnement à partir du fichier .env. fichier. Naviguez vers le répertoire backend et installez dotenv:

2. Dans le répertoire du backend, un fichier example.env est fourni avec les variables appropriées à remplir. Si vous créez le vôtre, veillez à inclure les variables suivantes :

Note : Assurez-vous que ce fichier est exclu de votre contrôle de version en ajoutant .env à .gitignore.

Étape 3 : Configuration d'Elasticsearch

Tout d'abord, vous devez disposer d'un cluster Elasticsearch actif. Deux options sont possibles :

• Option A : utiliser Elasticsearch Cloud

  • S'inscrire à Elastic Cloud

  • Créer un nouveau déploiement

  • Obtenez l'URL de votre point de terminaison et la clé API (encodée)

• Option B : Exécuter Elasticsearch localement

  • Installer et exécuter Elasticsearch localement

  • Utilisez http://localhost:9200 comme point d'arrivée

  • Générer une clé API

Installation du client Elasticsearch sur le backend :

1. Tout d'abord, installez le client Elasticsearch officiel dans votre répertoire backend :

2. Créez ensuite un répertoire lib pour contenir les fonctions réutilisables et naviguez-y :

3. À l'intérieur, créez un nouveau fichier appelé elasticClient.js. Ce fichier initialise le client Elasticsearch et l'expose pour qu'il soit utilisé dans votre projet.

4. Comme nous utilisons des modules ECMAScript (ESM), le nom de fichier __dirname and __n'est pas disponible. Pour vous assurer que vos variables d'environnement sont correctement chargées à partir du fichier .env dans le dossier backend, ajoutez cette configuration au début de votre fichier :

5. Maintenant, initialisez le client Elasticsearch en utilisant vos variables d'environnement et vérifiez la connexion :

Maintenant, nous pouvons importer cette instance client dans n'importe quel fichier qui doit interagir avec votre cluster Elasticsearch.

Étape 4 : Intégration en masse des données NBA dans Elasticsearch

Ensemble de données :

Pour ce projet, nous ferons référence aux ensembles de données disponibles dans le répertoire backend/data de la base de données. Notre assistant NBA utilisera ces données comme base de connaissances pour effectuer des comparaisons statistiques et générer des recommandations.

• sample_player_game_stats.csv - Exemple de statistiques de jeu d'un joueur (par exemple, points, rebonds, interceptions, etc.) par match et par joueur sur l'ensemble de sa carrière en NBA. Nous utiliserons cet ensemble de données pour effectuer des agrégations. (Remarque : il s'agit de données fictives, générées à des fins de démonstration et ne provenant pas de sources officielles de la NBA).

• playerAndTeamInfo.js - Remplace les métadonnées sur les joueurs et les équipes qui seraient normalement fournies par un appel à l'API afin que l'agent puisse faire correspondre les noms des joueurs et des équipes aux identifiants. Comme nous utilisons des données d'échantillon, nous ne voulons pas nous encombrer d'une API externe, c'est pourquoi nous avons codé en dur certaines valeurs auxquelles l'agent peut se référer.

Mise en œuvre :

1. Dans le répertoire backend/lib, créez un fichier nommé playerDataIngestion.js.

2. Configurer les importations, résoudre le chemin du fichier CSV et configurer l'analyse. Là encore, puisque nous utilisons ESM, nous devons reconstruire __dirname pour résoudre le chemin d'accès à l'échantillon CSV. Nous importerons également le module Node.js les modules intégrés, fs et readline, pour analyser le fichier CSV donné ligne par ligne.

Cela vous permet de lire et d'analyser efficacement le fichier CSV lorsque nous passons à l'étape de l'ingestion en masse.

3. Créez un index avec la correspondance appropriée. Bien qu'Elasticsearch puisse déduire automatiquement les types de champs avec le mappage dynamique, nous voulons être explicites ici pour que chaque statut soit traité comme un champ numérique. Ceci est important car nous utiliserons ces champs pour les agrégations par la suite. Nous voulons également utiliser le type float pour les statistiques telles que les points, les rebonds, etc., afin de nous assurer que nous incluons des valeurs décimales. Enfin, nous voulons ajouter la propriété de mappage dynamic: 'strict' afin qu'Elasticsearch ne mappe pas dynamiquement les champs non reconnus. 

4. Ajoutez la fonction permettant d'intégrer en masse les données CSV dans votre index Elasticsearch. À l'intérieur du bloc de code, nous sautons la ligne d'en-tête. Ensuite, divisez chaque ligne par une virgule et insérez-les dans l'objet document. Cette étape permet également de les nettoyer et de s'assurer qu'ils sont du bon type. Ensuite, nous plaçons les documents dans le tableau bulkBody avec les informations d'index, qui serviront de charge utile pour l'ingestion en masse dans Elasticsearch.

5. Ensuite, nous pouvons utiliser l'API Bulk d'Elasticsearch avec elasticClient.bulk() pour ingérer plusieurs documents en une seule demande. La gestion des erreurs ci-dessous est structurée de manière à vous indiquer le nombre de documents qui n'ont pas été ingérés et le nombre de documents qui ont été ingérés avec succès.

6. Exécutez la fonction main() ci-dessous pour exécuter séquentiellement les fonctions createIndex() et bulkIngestCsv().

Si vous voyez un journal de console indiquant que l'ingestion en masse a réussi, effectuez une vérification rapide de votre index Elasticsearch pour voir si les documents ont effectivement été ingérés avec succès.

Étape 5 : Définition des agrégations Elasticsearch et consolidation

Ce sont les principales fonctions qui seront utilisées lorsque nous définirons les outils de l'agent IA afin de comparer les statistiques des joueurs entre eux.

1. Naviguez jusqu'au répertoire backend/lib et créez un fichier appelé elasticAggs.js.

2. Ajoutez la requête ci-dessous pour calculer les moyennes historiques d'un joueur contre un adversaire spécifique. Cette requête utilise un filtre bool avec 2 conditions : l'une correspondant à player_id et l'autre à opponent_team_id, afin de récupérer uniquement les jeux pertinents. Nous n'avons pas besoin de renvoyer de documents, nous ne nous intéressons qu'aux agrégations, c'est pourquoi nous définissons size:0. Sous le bloc aggs, nous exécutons plusieurs agrégations métriques en parallèle sur des champs tels que points, rebounds, assists, steals, blocks et fg_percentage pour calculer leurs valeurs moyennes. Les LLM peuvent être aléatoires dans leurs calculs et ce processus est déchargé sur Elasticsearch, ce qui garantit à notre assistant NBA AI l'accès à des données exactes.

3. Pour calculer les moyennes saisonnières d'un joueur contre un adversaire spécifique, nous utiliserons pratiquement la même requête que la requête historique. La seule différence dans cette requête est que le filtre bool est assorti d'une condition supplémentaire pour game_date. Le champ game_date doit se situer dans la fourchette de la saison NBA en cours. Dans ce cas, la fourchette est comprise entre 2024-10-01 et 2025-06-30. Cette condition supplémentaire ci-dessous garantit que les agrégations qui suivent n'isoleront que les matchs de cette saison.

Étape 6 : Utilitaire de comparaison des joueurs

Pour que notre code reste modulaire et facile à maintenir, nous allons créer un fichier utilitaire qui consolide les fonctions d'aide aux métadonnées et les agrégations Elasticsearch. Il s'agit de l'outil principal utilisé par l'agent. Nous y reviendrons plus tard :

1. Créez un nouveau fichier comparePlayers.js dans le répertoire backend/lib.

2. Ajoutez la fonction ci-dessous pour consolider les aides aux métadonnées et la logique d'agrégation Elasticsearch en une seule fonction qui alimente l'outil principal utilisé par l'agent.

Étape 7 : Création de l'agent

Maintenant que vous avez créé les échafaudages frontend et backend, ingéré les données du jeu NBA et établi une connexion à Elasticsearch, nous pouvons commencer à assembler toutes les pièces pour construire l'agent.

Définition de l'agent

1. Accédez au fichier index.ts dans le répertoire backend/src/mastra/agents et ajoutez la définition de l'agent. Vous pouvez spécifier des champs tels que :

• Nom : Donnez à votre agent un nom qui sera utilisé comme référence lorsqu'il sera appelé sur le frontend.

• Instructions/Instructions du système : Une invite système donne au MLD le contexte initial et les règles à suivre pendant l'interaction. Il s'agit d'une invite similaire à celle que les utilisateurs envoient par l'intermédiaire de la boîte de dialogue, mais celle-ci est donnée avant toute entrée de l'utilisateur. Là encore, cela varie en fonction du modèle que vous choisissez.

• Modèle : Quel LLM utiliser (Mastra soutient OpenAI, Anthropic, les modèles locaux, etc.)

• Outils : Une liste de fonctions d'outils que l'agent peut appeler.

• Mémoire : (Facultatif) si nous voulons que l'agent se souvienne de l'historique des conversations, etc. Pour des raisons de simplicité, nous pouvons commencer sans mémoire persistante, bien que Mastra la prenne en charge.

Définition des outils

1. Naviguez jusqu'au fichier index.ts dans le répertoire backend/src/mastra/tools.

2. Installez Zod à l'aide de la commande :

3. Ajouter des définitions d'outils. Notez que nous importons la fonction dans le fichier comparePlayers.js en tant que fonction principale que l'agent utilisera lorsqu'il appellera cet outil. En utilisant la fonction createTool() de Mastra, nous enregistrerons notre playerComparisonTool. Les domaines concernés sont les suivants :

• id: Il s'agit d'une description en langage naturel qui aide l'agent à comprendre ce que fait l'outil.

• input schema: Pour définir la forme de l'entrée de l'outil, Mastra utilise le schéma Zod, qui est une bibliothèque de validation de schéma TypeScript. Zod s'assure que l'agent saisit des données correctement structurées et empêche l'outil de s'exécuter si la structure de l'entrée ne correspond pas.

• description: Il s'agit d'une description en langage naturel qui aide l'agent à comprendre quand il doit appeler et utiliser l'outil.

• execute: La logique qui s'exécute lorsque l'outil est appelé. Dans notre cas, nous utilisons une fonction d'aide importée pour renvoyer des statistiques de performance.

Ajout d'un logiciel intermédiaire pour gérer CORS

Ajouter un middleware dans le serveur Mastra pour gérer CORS. On dit qu'il y a trois choses dans la vie qu'on ne peut pas éviter : la mort, les impôts, et pour les développeurs web, c'est CORS. En bref, le partage des ressources inter-origines est une fonction de sécurité du navigateur qui empêche le front-end d'envoyer des requêtes à un back-end fonctionnant sur un domaine ou un port différent. Même si nous exécutons le backend et le frontend sur localhost, ils utilisent des ports différents, ce qui déclenche la politique CORS. Nous devons ajouter l'intergiciel spécifié dans la documentation de Mastra afin que notre backend autorise ces requêtes depuis le frontend.

1. Naviguez jusqu'au fichier index.ts dans le répertoire backend/src/mastra et ajoutez la configuration pour CORS :

• origin: ['http://localhost:5173']

  • Autorise les demandes provenant uniquement de cette adresse (adresse par défaut de Vite)

• allowMethods: ["GET", "POST"]

  • Méthodes HTTP autorisées. La plupart du temps, il utilisera POST.

• allowHeaders: ["Content-Type", "Authorization", "x-mastra-client-type, "x-highlight-request", "traceparent"],

  • Ils déterminent quels en-têtes personnalisés peuvent être utilisés dans les requêtes

Étape 8 : Intégration de l'interface utilisateur

Ce composant React fournit une interface de chat simple qui se connecte à l'agent IA Mastra en utilisant le hook useChat() de @ai-sdk/react. Nous allons également utiliser ce crochet pour afficher l'utilisation des jetons, les appels d'outils et pour rendre la conversation. Dans l'invite système ci-dessus, nous demandons également à l'agent de produire la réponse en format markdown, nous utiliserons donc react-markdown pour formater correctement la réponse.

1. Dans le répertoire frontend, installez le paquetage @ai-sdk/react pour utiliser le hook useChat().

2. Dans le même répertoire, installez React Markdown pour que nous puissions formater correctement la réponse générée par l'agent.

3. Mettre en œuvre useChat(). Ce hook va gérer l'interaction entre votre frontend et votre agent IA backend. Il gère l'état des messages, les entrées de l'utilisateur, l'état et vous donne des crochets de cycle de vie à des fins d'observabilité. Les options que nous transmettons sont les suivantes :

• api: Ceci définit le point final de votre agent Mastra AI. Le port par défaut est le port 4111 et nous voulons également ajouter la route qui prend en charge les réponses en continu.

• onToolCall: Cette fonction s'exécute chaque fois que l'agent appelle un outil ; nous l'utilisons pour savoir quels outils notre agent appelle.

• onFinish: Cette opération s'exécute après que l'agent a fourni une réponse complète. Même si nous avons activé le streaming, onFinish sera toujours exécuté après la réception du message complet et non après chaque morceau. Ici, nous l'utilisons pour suivre l'utilisation de nos jetons. Cela peut s'avérer utile pour contrôler et optimiser les coûts de la gestion du cycle d'apprentissage tout au long de la vie.

4. Enfin, nous nous rendons au composant ChatUI.jsx dans le répertoire frontend/components pour créer l'interface utilisateur de notre conversation. Ensuite, la réponse est enveloppée dans un composant ReactMarkdown afin de formater correctement la réponse de l'agent.

Étape 9 : Exécution de l'application

Félicitations ! Vous êtes maintenant prêt à exécuter l'application. Suivez ces étapes pour démarrer le backend et le frontend.

1. Dans une fenêtre de terminal, à partir du répertoire racine, naviguez jusqu'au répertoire backend et démarrez le serveur Mastra :

2. Dans une autre fenêtre de terminal, à partir du répertoire racine, naviguez jusqu'au répertoire frontend et démarrez l'application React :

3. Allez dans votre navigateur et naviguez jusqu'à :

http://localhost:5173

Vous devriez voir l'interface de chat. Essayez les exemples suivants :

• "Comparer LeBron James et Stephen Curry"

• "Qui choisir entre Jayson Tatum et Luka Doncic ?"

Et maintenant ? Rendre l'agent plus intelligent

Pour rendre l'assistant plus agentive et les recommandations plus perspicaces, j'ajouterai quelques améliorations clés dans la prochaine itération.

Recherche sémantique pour les nouvelles de la NBA

Il y a une tonne de facteurs qui peuvent affecter les performances des joueurs, dont beaucoup n'apparaissent pas dans les statistiques brutes. Des choses comme les rapports sur les blessures, les changements de composition, ou même une analyse d'après-match, vous ne pouvez les trouver que dans des articles de presse. Pour saisir ce contexte supplémentaire, j'ajouterai des capacités de recherche sémantique afin que l'agent puisse retrouver des articles pertinents de la NBA et tenir compte de ce récit dans ses recommandations.

Recherche dynamique avec le serveur Elasticsearch MCP

Le protocole MCP (Model Context Protocol) devient rapidement la norme pour la connexion des agents aux sources de données. Je vais migrer la logique de recherche dans le serveur Elasticsearch MCP, qui permet à l'agent de construire dynamiquement des requêtes plutôt que de s'appuyer sur les fonctions de recherche prédéfinies que nous fournissons. Cela nous permet d'utiliser davantage de flux de travail en langage naturel et de réduire la nécessité de rédiger manuellement chaque requête de recherche. Pour en savoir plus sur le serveur Elasticsearch MCP et l'état actuel de l'écosystème , cliquez ici.

Ces changements sont déjà en cours, restez à l'écoute !

Conclusion

Dans ce blog, nous avons construit un assistant RAG agentique qui fournit des recommandations personnalisées pour votre équipe de basket-ball fantasy en utilisant JavaScript, Mastra et Elasticsearch. Nous avons couvert :

• Les principes fondamentaux de la RAG agentique et la manière dont la combinaison de l'autonomie d'un agent d'intelligence artificielle avec les outils permettant d'utiliser efficacement la RAG peut déboucher sur des agents plus nuancés et plus dynamiques.

• Elasticsearch et comment ses capacités de stockage de données et ses puissantes agrégations natives en font un partenaire idéal en tant que base de connaissances pour un LLM.

• Le cadre Mastra et la manière dont il simplifie la construction de ces agents pour les développeurs de l'écosystème JavaScript.

Que vous soyez fanatique de basket-ball, que vous cherchiez à construire des agents d'intelligence artificielle, ou les deux comme moi, j'espère que ce blog vous a donné quelques éléments de base pour commencer. Le repo complet est disponible sur GitHub, n'hésitez pas à le cloner et à le modifier. Maintenant, allez gagner cette ligue de fantasy !

Cet article de blog traite de l'utilisation d'Elasticsearch et d'Azure Open AI pour créer un exemple d'application qui démontre comment trouver des résultats exacts lors de la recherche de biens immobiliers très spécifiques tout en fournissant des résultats pertinents lorsqu'une correspondance spécifique n'est pas disponible. Nous verrons toutes les étapes nécessaires à la création d'un index Elasticsearch et d'un modèle de recherche. Ensuite, nous présenterons l'ensemble du processus de création d'une application qui utilise Azure OpenAI pour prendre en compte les requêtes des utilisateurs et les transformer en requêtes de modèles de recherche Elasticsearch qui peuvent produire des résultats étonnamment personnalisés.

Voici une liste de toutes les ressources que nous utiliserons pour créer notre exemple d'application de recherche immobilière :

• Index et modèle de recherche Elasticsearch

• Azure OpenAI

• API Azure Maps

• Codespaces Jupyter Notebook

• Noyau sémantique

• Application C# avec Blazor Frontend

Processus d'interrogation intelligent

Ce flux de travail combine le LLM, les outils LLM et la recherche pour transformer les requêtes en langage naturel en résultats de recherche structurés et pertinents :

• LLM (Large Language Model) - Interprète les requêtes complexes des utilisateurs et orchestre les outils pour extraire les intentions de recherche et enrichir le contexte.

• Outils LLM - Chaque outil LLM est un programme C# que nous avons créé pour cet article. Il existe trois outils :

  • Outil d'extraction de paramètres: il extrait de la requête des attributs clés tels que les chambres, les salles de bain, les caractéristiques et le prix.

  • Outil GeoCode: convertit les noms de lieux en latitude/longitude pour le filtrage spatial.

  • Outil de recherche: remplit un modèle de recherche Elasticsearch avec des paramètres de requête et exécute une recherche. Recherche hybride - Exécute une recherche hybride (texte intégral + vecteur dense) avec inférence ML intégrée. Cette approche stratifiée garantit à l'utilisateur final des expériences de recherche plus intelligentes et adaptées au contexte.

Architecture de l'application

Voici un schéma de l'architecture du système de l'application d'exemple. Nous utiliserons un carnet Jupyter de Codespaces pour interagir avec Elastic Cloud.

Produits requis

Vous n'aurez besoin que de votre navigateur, car nous utiliserons GitHub Codespaces pour cloner l'application d'exemple, la configurer et l'exécuter. Pour la partie Elastic de la solution, nous utiliserons Elastic Cloud pour créer un projet Elasticsearch Serverless. Nous utiliserons Azure Portal pour travailler avec les ressources Azure.

Cloner le repo de l'application exemple dans Codespaces

Commencez par cloner le code de l'application d'exemple. Vous pouvez le faire dans GitHub Codespaces, qui permet de cloner et d'exécuter des applications. Cliquez sur New Codespace.

Ensuite, sélectionnez le repo jwilliams-elastic/msbuild-intelligent-query-demo dans la liste déroulante Repository et cliquez sur Create Codespace.

Créer un fichier .env fichier

Nous utiliserons un carnet Jupyter Python pour accéder et interagir avec Elastic Cloud en utilisant les valeurs de configuration qui sont stockées dans un fichier de configuration. Le fichier de configuration de l'ordinateur portable doit avoir le nom de fichier .env. et vous allez le créer maintenant.

1. Dans GitHub Codespaces, cliquez sur le bouton New File et ajoutez un fichier nommé .env.

2. Ajoutez le contenu suivant au fichier .env nouvellement créé fichier

Comme vous pouvez le voir, nous avons quelques valeurs manquantes, ELASTIC_URL et ELASTIC_API_KEY, qui doivent être ajoutées au fichier .env. fichier. Commençons maintenant par créer un projet Elasticsearch serverless qui servira de backend pour alimenter la fonctionnalité de recherche de notre application d'exemple.

Créer un projet Elastic Serverless

1. Allez sur cloud.elastic.co et cliquez sur Create New Serverless project (Créer un nouveau projet sans serveur).

2. Cliquez sur Suivant pour la solution Elasticsearch

3. Sélection optimisée pour les vecteurs

4. Définir le fournisseur de services en nuage comme étant Azure

5. Cliquez sur Créer un projet sans serveur

6. Cliquez sur " Getting Started" dans le menu de navigation principal et faites défiler vers le bas pour copier les " Connection Details" (détails de connexion).

7. Cliquez sur le bouton Copier pour copier le point de terminaison Elasticsearch à partir des détails de la connexion.

8. Mise à jour du fichier .env pour définir l'URL ELASTIC comme étant le point de terminaison Elasticsearchcopié.

Créer une clé API Elastic

1. Ouvrez la page Elasticsearch Getting Started, cliquez sur New dans la section Add an API Key.

2. Saisir un nom declé

3. Cliquez sur Créer une clé API

4. Cliquez sur le bouton Copier pour copier la valeur de la clé API.

5. De retour dans Codespaces, où nous avons le fichier .envouvert pour édition, collez la valeur copiée pour définir la clé ELASTIC_API_KEY

Ouvrez le Codespaces Notebook et installez les dépendances de la bibliothèque.

Dans l'explorateur de fichiers, sélectionnez le fichier VectorDBSetup.ipynb pour ouvrir le carnet de notes. Une fois le Notebook chargé, recherchez la section du Notebook intitulée Installer les bibliothèques. Cliquez sur le bouton de lecture de la section.

Si c'est la première fois que vous exécutez un Notebook dans GitHub Codespaces, vous serez invité à sélectionner un Codespaces Kernel et à configurer l'environnement Python.

Définir les importations et charger les variables d'environnement à l'aide de Codespaces Notebook

Passez à la section suivante du Carnet de notes intitulée Définir les importations et charger les variables d'environnement. Cliquez sur le bouton de lecture de la section.

Ce code importe les bibliothèques Python utilisées par le Notebook et charge les variables d'environnement à partir du fichier .env que vous avez créée précédemment.

Créer un point de terminaison d'inférence Elastic ML à l'aide de Codespaces Notebook

Passez à la section suivante du Notebook intitulée Create ML inference endpoint (Créer un point de terminaison d'inférence ML). Cliquez sur le bouton de lecture de la section.

Cela créera un nouveau point de terminaison d'inférence ML dans le projet Elasticsearch que nous utiliserons pour générer des enchâssements de texte à partir de nos données. Les text embeddings sont des représentations vectorielles du texte qui seront stockées dans Elasticsearch pour alimenter la recherche sémantique.

Créer un index Elasticsearch avec Codespaces Notebook

Passez à la section suivante du Notebook intitulée Create Elasticsearch index (Créer un index Elasticsearch). Cliquez sur le bouton de lecture de la section.

Cela créera l'index Elasticsearch qui stockera nos données d'exemple et toutes les données vectorielles associées générées via le point de terminaison de l'inférence ML.

Créer un modèle de recherche Elasticsearch à l'aide de Codespaces Notebook

Passez à la section suivante du carnet de notes intitulée Modèle de recherche. Cliquez sur le bouton de lecture de la section.

Cela permet de créer un modèle de recherche, que notre exemple d'application utilisera en tant que modèle rempli avec les mots analysés à partir de la requête de recherche de l'utilisateur. Cela nous permet de configurer et de contrôler à quel point nous sommes spécifiques lorsque nous interrogeons des données dans l'index Elasticsearch.

Ingérer des données dans l'index Elasticsearch à l'aide de Codespaces Notebook

Passez à la section suivante du Carnet de notes , intitulée Acquisition de données sur les biens immobiliers. Cliquez sur le bouton d'exécution de la section.

L'exécution de cette section de code permet de charger en bloc les données de l'exemple contenues dans le fichier properties.jsonl. Au bout de quelques minutes, vous devriez voir apparaître une confirmation indiquant que le processus s'est déroulé avec succès. Vous pouvez confirmer que l'index contient l'enregistrement attendu en allant dans la section Gestion de l'index dans Elastic Cloud.

Créer appsetting.json pour configurer l'application C#

Notre index Elasticsearch étant créé et alimenté en données, nous sommes maintenant prêts à configurer l'application d'exemple pour qu'elle fonctionne avec Elastic et Azure Cloud. L'application d'exemple C# utilise un fichier nommé appsettings.json pour stocker et charger ses informations d'accès telles que les clés API. Vous allez créer le fichier appsettings.json en utilisant l'éditeur de Codespaces.

1. Créer appsettings.json dans le dossier HomeFinderApp

2. Collez le code suivant dans le fichier appsettings.json

3. Trouvez les valeurs Url et ApiKey dans la section ElasticSettings . Définissez les mêmes valeurs que celles que vous avez définies dans le fichier .env dans une étape précédente.

Créer un service Azure OpenAI

Notre application d'exemple va utiliser Azure OpenAI pour analyser la requête de l'utilisateur de l'application et ensuite soumettre une demande à Elasticsearch en remplissant le modèle de recherche pour tenter de communiquer de manière flexible ce que l'utilisateur recherche.

1. Ouvrez un nouvel onglet de navigateur et accédez à AI Foundry | Azure OpenAI dans le portail Azure. Cliquez sur+Créer

2. Dans le formulaire de création, sélectionnez un groupe de ressources.

3. Saisir un nom

4. Choisir un niveau de tarification

5. Cliquez sur Suivant

6. Dans l'onglet Réseau, cliquez sur Suivant

7. Dans l'onglet Tags, cliquez sur Suivant

8. Dans l'onglet Réviser et soumettre, cliquez sur Créer

9. Une fois la création terminée, cliquez sur Aller à la ressource.

10. Sélectionnez Keys and Endpoint dans le menu de navigation de gauche.

11. Copiez le point de terminaison et collez-le dans le fichier appsettings.json que vous avez créé dans l'onglet de votre navigateur où se trouve l'éditeur Codespaces.

12. Retournez ensuite à l'onglet de votre navigateur contenant la clé Azure OpenAI et la page du point de terminaison. Cliquez sur le bouton copier pour la clé 1, et collez la valeur copiée dans le fichier appsettings.json, dans l'onglet de votre navigateur où se trouve l'éditeur Codespaces ouvert.

Ajouter le déploiement du modèle gpt-4o au service Azure Open AI

Super, nous avons maintenant un service Azure OpenAI qui fonctionne, mais il a encore besoin d'un déploiement de modèle pour nous donner les capacités LLM dont notre application d'exemple a besoin. Il existe une multitude de modèles. Déployons gpt-4o puisqu'il est déjà spécifié dans le fichier appsettings.json que vous avez créé.

1. Accédez à Azure AI Foundry et cliquez sur Créer un déploiement.

2. Rechercher gpt-4o et le sélectionner dans les résultats

3. Cliquez sur Confirmer pour le sélectionner

4. Cliquez sur Déployer pour déployer le modèle

Une fois que vous avez déployé avec succès le modèle gpt-4o, vous pouvez sélectionner Déploiements dans le menu de navigation de gauche et confirmer que le déploiement gpt-4o est listé avec l'état " Succeeded".

Créer un compte Azure Maps

Nous voulons que les utilisateurs de notre exemple d'application puissent rechercher des biens immobiliers dans des zones spécifiques, mais sans avoir à être trop précis. Si quelqu'un veut chercher une propriété près du marché local, Azure Maps est un service que l'OpenAI LLM peut utiliser pour obtenir les coordonnées de latitude et de longitude du marché. Les coordonnées peuvent ensuite être incluses dans les requêtes basées sur le modèle de recherche envoyé à Elasticsearch pour les requêtes des utilisateurs qui incluent des emplacements spécifiques et des considérations de géo-distance.

1. Cliquez sur Créer dans les comptes Azure Maps

2. Sélectionner un groupe de ressources

3. Saisir un nom

4. Accepter la licence et la déclaration de confidentialité

5. Cliquez sur Réviser et créer

6. Cliquez sur Créer

7. Une fois la création du compte terminée, cliquez sur Aller à la ressource.

8. Cliquez sur Authentification dans le menu de navigation de gauche

9. Copier la valeur de la clé primaire et la coller comme valeur de l'ApiKey dans la section AzureMapsSettings du fichier appsettings.json, de nouveau dans l'onglet de votre navigateur contenant l'éditeur Codespaces.

Essayez l'application d'exemple

Passons maintenant à la partie la plus amusante. Il est temps d'exécuter l'application d'exemple. Nous avons mis en place tous les détails de configuration ainsi que les ressources Elastic Cloud et Azure Cloud dont nous avons besoin pour faire fonctionner l'application.

1. Ouvrez une fenêtre Terminal dans l'éditeur Codespaces.

2. Utilisez la commande suivante pour modifier le répertoire actif afin qu'il devienne le dossier de l'application d'exemple.

3. Utilisez la commande dotnet suivante pour exécuter l'application.

4. Cliquez sur le bouton Ouvrir dans le navigateur lorsqu'il apparaît.

5. Testez la recherche par défaut, puis testez vos propres recherches personnalisées. Si vous souhaitez obtenir plus de détails sur ce qui est exécuté en amont pour générer les résultats de la recherche, vous pouvez cliquer sur le lien Afficher situé à côté de Invocations d'outils.

Bonus : Si vous voulez vraiment tester GPT-4o, essayez la recherche suivante : Je cherche une propriété près de Disney World Fl avec plus de 30 chambres et plus de 20 salles de bain, une piscine, un garage et près de la plage pour moins de 200K. Cette requête renverra des résultats après plusieurs invocations de l'outil de recherche.

Elastic est votre solution pour Search AI

L'application en cours est un exemple de recherche guidée Gen AI LLM utilisant Elasticsearch via des modèles de recherche comme source de données de base. N'hésitez pas à expérimenter et à personnaliser l'application d'exemple pour créer une expérience de recherche à la fois précise et flexible, afin d'aider vos utilisateurs à trouver ce qu'ils recherchent.

Merci de votre lecture. Essayez Elastic Cloud.

Qu'est-ce que le protocole de contexte de modèle (MCP) ?

Pour ceux qui ne connaissent pas, Model Context Protocol est une norme ouverte qui offre un moyen structuré et bidirectionnel de connecter les modèles d'IA à diverses sources de données et à divers outils, ce qui leur permet de générer des réponses plus pertinentes et mieux informées. Il est communément appelé "port USB-C pour les applications d'intelligence artificielle".

Voici un schéma architectural qui met en évidence son caractère bidirectionnel :

Il s'agit d'un changement important pour les praticiens de l'IA, car l'un des principaux défis de la mise à l'échelle des applications d'IA est de devoir créer des intégrations personnalisées pour chaque nouvelle source de données. MCP offre une architecture durable et réutilisable pour la gestion et la fourniture de contexte aux modèles. Il est indépendant des modèles et des serveurs et est entièrement open source.

MCP est la dernière itération d'une lignée de spécifications d'API visant à normaliser l'intégration entre les applications. Dans le passé, nous avions OpenAPI pour les services RESTful, GraphQL pour l'interrogation des données et gRPC pour la communication des microservices. MCP ne partage pas seulement la rigueur structurée de ces anciennes spécifications, mais l'intègre également dans un cadre d'IA générative, ce qui facilite l'intégration des agents dans différents systèmes sans avoir recours à des connecteurs personnalisés. À bien des égards, MCP vise à faire pour les agents d'intelligence artificielle ce que HTTP a fait pour le web. Tout comme HTTP a normalisé la communication entre les navigateurs et les sites web, MCP cherche à normaliser la façon dont les agents d'intelligence artificielle interagissent avec le monde des données qui les entoure.

MCP par rapport à d'autres protocoles d'agents

Le paysage des protocoles d'agents se développe rapidement, avec plus d'une douzaine de normes émergentes en concurrence pour définir la manière dont les agents interagissent. Laurie Voss de LlamaIndex décrit comment la plupart peuvent être catégorisés en 2 types : les protocoles inter-agents qui se concentrent sur les agents qui parlent entre eux et les protocoles orientés vers le contexte comme MCP qui se concentrent sur la fourniture d'un contexte structuré aux LLMs.

D'autres protocoles populaires comme A2A (Agent to Agent) de Google, ACP (Agent Communication Protocol) de Cisco et IBM, et Agora, visent à permettre les négociations entre agents, la création de coalitions et même des systèmes d'identité décentralisés. MCP adopte une approche un peu plus pragmatique en ce sens qu'il se concentre sur la manière dont les agents accèdent aux outils et aux données et pas nécessairement sur la manière dont ils communiquent entre eux (bien que MCP puisse également permettre cela à l'avenir de différentes manières).

Actuellement, ce qui distingue MCP, c'est sa traction et son élan. Comme React dans les premiers jours des frameworks frontaux, MCP a commencé avec un problème de niche et est maintenant l'un des protocoles d'agent les plus adoptés et les plus extensibles dans la pratique.

Récapitulation du sommet : Évolution des priorités pour le MCP

Le sommet a accueilli des intervenants de Anthropic, Okta, OpenAI, AWS, GitHub et bien d'autres. Les discussions ont porté sur l'amélioration des protocoles de base et sur leur mise en œuvre dans le monde réel, et ont mis en évidence les priorités immédiates et à long terme. Ces exposés ont montré que l'on s'éloignait de l'expérimentation précoce et de l'appel à de simples outils pour passer à la construction de systèmes d'IA fiables, évolutifs et modulaires en utilisant le MCP comme base.

Plusieurs orateurs ont évoqué un avenir où le MCP est plus qu'un simple protocole, il peut devenir le fondement d'un web orienté vers l'intelligence artificielle. Tout comme JavaScript permet aux utilisateurs de cliquer et d'interagir avec les pages web, MCP pourrait permettre aux agents d'effectuer ces mêmes actions en notre nom. Par exemple, dans le domaine du commerce électronique, au lieu de naviguer manuellement sur un site web pour faire des achats, les utilisateurs pourraient simplement demander à un agent de se connecter, de trouver un produit spécifique, de l'ajouter à leur panier et de passer à la caisse.

Il ne s'agit pas non plus d'une pure spéculation ou d'un battage médiatique : PayPal a présenté sa nouvelle boîte à outils pour agents et son serveur MCP lors du sommet, qui permet exactement cette expérience de commerce agentique. Grâce à MCP qui fournit un accès sécurisé et fiable aux outils et aux sources de données, les agents ne se contenteront pas de lire le web, ils pourront agir en conséquence. Aujourd'hui, MCP est déjà une norme puissante qui a le vent en poupe et, à terme, elle pourrait devenir la norme des interactions utilisateur améliorées par l'IA sur l'ensemble du web.

Mise à jour du projet MCP : Transport, élicitation et outils structurés

Jerome Swannack, l'un des principaux contributeurs à MCP, a fait part de quelques mises à jour de la spécification du protocole au cours des six derniers mois. Les principaux objectifs de ces changements sont les suivants

1. Pour activer le MCP à distance avec l'ajout du HTTP en continu

2. Permettre des modèles d'interaction entre agents plus riches grâce à l'ajout de schémas d'élicitation et de sortie d'outils.

MCP étant un logiciel libre, les développeurs peuvent déjà mettre en œuvre des modifications telles que le protocole HTTP fluide. Les schémas d'élicitation et de sortie de l'outil ne sont pas encore publiés ; ils sont à l'état de projet et peuvent évoluer.

Streamable HTTP (publié le 26 mars 2025): Une mise à jour technique importante a été l'introduction du protocole HTTP en flux continu en tant que nouveau mécanisme de transport. Il remplace les événements envoyés par le serveur (SSE) par un modèle bidirectionnel plus évolutif qui prend en charge le codage de transfert par morceaux et la transmission progressive de messages sur une seule connexion HTTP. Cela vous permet de déployer des serveurs MCP sur une infrastructure cloud comme AWS Lambda et de prendre en charge les contraintes du réseau d'entreprise sans connexions à longue durée de vie ni nécessité de polling.

Elicitation (publié le 18 juin 2025): L'élicitation permet aux serveurs de définir un schéma sur la façon dont ils veulent que le contexte soit structuré à partir d'un client. Essentiellement, le serveur peut décrire ce dont il a besoin et le type d'entrée qu'il attend. Cela a plusieurs implications : Les constructeurs de serveurs peuvent créer des interactions agentiques plus complexes. Les concepteurs de clients peuvent mettre en œuvre des interfaces utilisateur dynamiques qui s'adaptent à ces schémas. Cependant, l'élicitation ne doit pas être utilisée pour extraire des informations sensibles ou personnellement identifiables des utilisateurs. Les développeurs doivent suivre les meilleures pratiques pour s'assurer que les messages d'élicitation restent sûrs et appropriés, en particulier au fur et à mesure que le MCP évolue. Ceci est lié à des problèmes de sécurité plus larges que nous aborderons plus loin dans ce billet.

Schémas de sortie d'outil (publié le 18 juin 2025): Ce concept permet au client et au LLM de connaître à l'avance les formes de sortie de l'outil. Les schémas de sortie des outils permettent aux développeurs de décrire les résultats attendus d'un outil. Ces schémas répondent à l'une des principales limites de l'appel direct d'outils, à savoir l'utilisation inefficace de la fenêtre contextuelle. La fenêtre contextuelle est considérée comme l'une des ressources les plus importantes lorsque vous travaillez avec des LLM. Lorsque vous appelez directement un outil, celui-ci renvoie un contenu brut qui est entièrement transféré dans le contexte du LLM. Les schémas de sortie des outils peuvent vous aider à mieux utiliser vos jetons et la fenêtre contextuelle en permettant au serveur MCP de fournir des données structurées. Voici quelques bonnes pratiques concernant les outils en général.

Ensemble, ces nouvelles mises à jour et les ajouts futurs aideront le MCP à devenir un protocole d'agent plus modulaire, typé et prêt pour la production.

Caractéristiques de puissance sous-utilisées : Échantillonnage et racines

Bien qu'ils ne soient pas nouveaux dans la spécification MCP, l'échantillonnage et les racines ont été mis en évidence lors de la présentation. Ces deux primitives sont actuellement négligées et sous-explorées, mais elles peuvent contribuer de manière significative à des interactions plus riches et plus sûres entre les agents.

Échantillonnage - Les serveurs peuvent demander des compléments au client : L'échantillonnage permet aux serveurs MCP de demander des compléments au LLM côté client. Cela ajoute à la nature bidirectionnelle du protocole, où le serveur ne se contente pas de répondre aux demandes ; il peut inciter et demander au modèle du client de générer une réponse. Cela permet au client de garder un contrôle total sur le coût, la sécurité et le modèle utilisé par le serveur MCP. Ainsi, dans le cas de l'utilisation d'un serveur MCP externe avec un modèle préconfiguré, vous n'aurez pas besoin de fournir vos propres clés API ou de configurer votre propre abonnement à ce modèle, car le serveur peut simplement demander le modèle déjà connecté au client. Cela permet d'obtenir des comportements d'agents plus complexes et plus interactifs.

Racines - Accès limité aux ressources : Lesracines ont été conçues pour permettre aux clients d'informer les serveurs des ressources et des espaces de travail pertinents sur lesquels ils doivent se concentrer. Il s'agit d'un outil puissant pour définir le champ d'action des serveurs. Il est important de noter que les racines sont "informatives et non strictement exécutoires", ce qui signifie qu'elles ne définissent pas de droits ou de permissions pour les serveurs ou les agents MCP. En d'autres termes, vous ne pouvez pas vous fier uniquement aux racines pour empêcher un serveur ou un agent d'exécuter certains outils ou d'effectuer des actions d'écriture. En ce qui concerne les racines, les autorisations doivent toujours être gérées du côté du client, avec des mécanismes d'approbation par l'utilisateur. Par ailleurs, les développeurs doivent toujours veiller à utiliser des serveurs conçus pour respecter les limites fixées par les racines et utiliser les meilleures pratiques.

Authentification des agents : OAuth 2.1 et métadonnées protégées

Cette section se concentre sur OAuth 2.1, la dernière itération d'OAuth 2.0, qui supprime les flux non sécurisés et consolide les meilleures pratiques.

La prise en charge d'OAuth était un sujet très attendu, d'autant plus que la sécurité et l'évolutivité sont considérées comme les principaux obstacles qui empêchent MCP de devenir la norme pour la connexion des agents aux outils. Aaron Parecki (éditeur d'OAuth 2.1 et expert en normes d'identité chez Okta) a expliqué comment MCP peut adopter un flux OAuth propre et évolutif qui décharge les développeurs de serveurs de la majeure partie de la complexité. La spécification d'autorisation officielle OAuth 2.1 a été récemment publiée dans la dernière révision du protocole le 18 juin 2025.

Dans cette implémentation, les responsabilités OAuth peuvent être réparties entre le client MCP et le serveur. La majeure partie du flux d'authentification est initiée et gérée par le client MCP, le serveur n'intervenant qu'à la fin pour recevoir et vérifier le jeton sécurisé. Cette scission permet de résoudre un problème critique de mise à l'échelle, à savoir comment s'authentifier à travers de nombreux outils sans exiger des développeurs qu'ils configurent chaque connexion, et garantit que les développeurs de serveurs MCP n'ont pas à devenir des experts OAuth.

Deux points saillants de l'exposé :

1. Métadonnées des ressources protégées: Les serveurs MCP peuvent publier un fichier JSON décrivant leur objectif, leurs points d'accès et leurs méthodes d'authentification. Cela permet aux clients de démarrer des flux OAuth avec seulement l'URL du serveur, ce qui simplifie le processus de connexion. En savoir plus : Corrigeons OAuth dans MCP

2. Prise en charge des IDP et du SSO: les entreprises peuvent intégrer des fournisseurs d'identité pour gérer l'accès de manière centralisée. C'est une victoire pour l'expérience de l'utilisateur et la sécurité. Les utilisateurs n'auraient pas besoin de cliquer sur dix écrans de consentement différents et les équipes de sécurité pourraient observer chaque connexion.

En transférant la logique OAuth au client et en s'appuyant sur les métadonnées des serveurs, l'écosystème MCP évite un goulot d'étranglement majeur. Le MCP s'aligne ainsi plus étroitement sur la manière dont les API modernes sont sécurisées dans les environnements de production d'aujourd'hui.

Lecture complémentaire : OAuth 2 simplifié.

Défis de sécurité dans un écosystème composable

Les nouveaux développements s'accompagnent également de nouvelles surfaces d'attaque. Arjun Sambamoorthy, de Cisco, énumère les principales menaces qui pèsent sur le paysage MCP :

Profils

Description

Remédiation & meilleures pratiques

Injection rapide & Empoisonnement des outils

Un moyen d'injecter une invite malveillante dans le contexte du système LLM ou dans la description de l'outil, amenant le LLM à effectuer des actions involontaires telles que la lecture de fichiers ou la fuite de données.

Utilisez des outils tels que MCP Scan pour vérifier les métadonnées des outils. Validez les descriptions et les paramètres avant de les inclure dans les invites. Enfin, envisagez de mettre en place des approbations d'utilisateurs pour les outils à haut risque. Pour plus de détails, voir le guide OWASP Prompt Injection dans la liste de lectures complémentaires sous le tableau.

Attaques par échantillonnage

Dans le contexte de MCP, l'échantillonnage ouvre la porte au serveur MCP pour effectuer des attaques d'injection rapide sur le LLM.

Désactiver l'échantillonnage pour les serveurs non fiables et envisager d'ajouter des approbations humaines en boucle pour les demandes d'échantillonnage.

Serveurs MCP malveillants

Dans les collections actuelles de serveurs MCP, il est difficile de contrôler chacun d'entre eux pour garantir la sécurité. Des serveurs malveillants peuvent discrètement collecter vos données et les exposer à des acteurs malveillants.

Ne vous connectez qu'à des serveurs MCP provenant de registres de confiance ou de listes internes. Exécuter des serveurs tiers dans des conteneurs avec sandboxing.

Outils d'installation MCP malveillants

Les installateurs de ligne de commande et les scripts sont pratiques pour mettre en œuvre rapidement des serveurs ou des outils MCP, mais vous risquez d'installer du code non vérifié et compromis.

Installer dans des environnements "sandbox" et valider les signatures des paquets. Ne jamais effectuer de mise à jour automatique à partir de sources non vérifiées.

Pour lutter contre ce problème, Arjun suggère d'utiliser un registre MCP de confiance pour gérer toutes les vérifications (un sujet qui était au cœur de l'actualité - pour plus de détails, voir les deux premiers éléments de la liste de lecture ci-dessous), ainsi que d'utiliser cette liste de contrôle de la sécurité.

Lecture complémentaire :

• Meilleures pratiques officielles de sécurité MCP

• Top 10 des candidatures au LLM de l'OWASP

• Recherche sur les menaces HiddenLayer

• Scan MCP

• Guide OWASP sur l'injection d'invites

Prochaines étapes : Registres, gouvernance et écosystème

Un registre centralisé des MCP est en cours d'élaboration et a été l'un des sujets les plus discutés lors du sommet. L'écosystème actuel des serveurs souffre de fragmentation, d'un manque de confiance et d'accessibilité. Il est difficile pour les développeurs de trouver des serveurs MCP, de vérifier ce qu'ils font et de les installer en toute sécurité, en particulier dans un écosystème décentralisé où les métadonnées peuvent être incomplètes ou usurpées.

Un registre centralisé répond directement à ces problèmes en agissant comme une source de vérité fiable, en améliorant la découvrabilité, en garantissant l'intégrité des métadonnées du serveur et en réduisant le risque d'installation d'outils malveillants.

Les objectifs du registre MCP sont les suivants :

• Offrir une source unique de vérité pour les métadonnées des serveurs (ce que fait un serveur, comment s'authentifier, l'installer et l'appeler)

• Se débarrasser des registres tiers incomplets et de la fragmentation, de sorte que lorsqu'un serveur veut être enregistré, il n'a pas à mettre à jour tous les autres registres sur l'internet.

• Fournir un flux d'enregistrement de serveur qui comprend un outil CLI et un fichier server.json qui contient les métadonnées mentionnées précédemment.

L'espoir le plus large est qu'un registre fiable aidera à développer l'écosystème en toute sécurité, en permettant aux développeurs de créer et de partager de nouveaux outils en toute confiance.

La gouvernance est une autre question prioritaire pour Anthropic. Ils ont clairement indiqué que le projet MCP devait rester ouvert et dirigé par la communauté, mais la mise à l'échelle de ce modèle de gouvernance est encore un travail en cours. Ils recherchent actuellement de l'aide dans ce domaine et demandent à toute personne ayant de l'expérience en matière de gouvernance dans les protocoles à source ouverte de les contacter. Cela nous amène à l'autre sujet que je voulais aborder. Tout au long de l'événement, les intervenants ont insisté sur le fait que l'écosystème ne peut se développer qu'avec les contributions des développeurs. Un effort concentré est nécessaire pour faire de MCP la nouvelle norme web et se démarquer des autres protocoles d'agents populaires.

MCP dans le monde réel : Études de cas et démonstrations

Plusieurs organisations ont expliqué comment le MCP est déjà utilisé dans des applications pratiques :

• PayPal - Serveur MCP pour le commerce agentique : PayPal a présenté son nouvel agent-toolkit et son serveur MCP, qui peuvent changer fondamentalement l'expérience d'achat d'un utilisateur. Au lieu de parcourir les médias sociaux pour trouver des articles, comparer les prix et passer à la caisse, les utilisateurs peuvent discuter avec un agent qui se connecte au serveur MCP de PayPal pour gérer toutes ces actions.

• EpicAI.pro - Jarvis : Les développements de MCP nous rapprochent de plus en plus d'un véritable assistant de type Jarvis. Pour ceux qui ne connaissent pas les films d'Iron Man, Jarvis est un assistant IA qui utilise le langage naturel, répond aux entrées multimodales, n'a aucune latence lorsqu'il répond, est proactif en anticipant les besoins de l'utilisateur, gère automatiquement les intégrations et peut passer d'un appareil à l'autre et d'un lieu à l'autre en fonction du contexte. Si nous imaginons Jarvis comme un assistant robotique physique, MCP lui donne des "mains" ou la capacité de gérer des tâches complexes.

• Postman - Générateur de serveur MCP: Fournit une expérience de panier pour les demandes d'API où vous pouvez choisir différentes demandes d'API, les mettre dans un panier et télécharger l'ensemble du panier en tant que serveur MCP.

• Bloomberg - Bloomberg a résolu un goulot d'étranglement important dans le développement de la GenAI en entreprise. Avec près de 10 000 ingénieurs, la société avait besoin d'un moyen standardisé pour intégrer les outils et les agents au sein des équipes. Avec MCP, ils ont transformé leurs outils internes en composants modulaires à distance que les agents peuvent facilement appeler sur une interface unifiée. Cela a permis à leurs ingénieurs de fournir des outils à l'ensemble de l'organisation, tandis que les équipes d'intelligence artificielle se sont concentrées sur la création d'agents plutôt que sur des intégrations personnalisées. Bloomberg prend désormais en charge des flux de travail d'agents évolutifs et sécurisés qui débloquent une interopérabilité totale avec l'écosystème MCP. Bloomberg n'a lié aucune ressource publique, mais c'est ce qu'ils ont présenté en public lors du sommet.

• Block - Block utilise MCP pour alimenter Goose, un agent d'intelligence artificielle interne qui permet aux employés d'automatiser des tâches dans les domaines de l'ingénierie, des ventes, du marketing, etc. Ils ont construit plus de 60 serveurs MCP pour des outils tels que Git, Snowflake, Jira et Google Workspace afin de permettre une interaction en langage naturel avec les systèmes qu'ils utilisent tous les jours. Les employés de Block utilisent désormais Goose pour interroger les données, détecter les fraudes, gérer les incidents, naviguer dans les processus internes et bien plus encore, le tout sans avoir à écrire de code. MCP a aidé Block à adopter l'IA dans de nombreuses fonctions en seulement 2 mois.

• AWS - Serveurs MCP AWS: AWS a présenté un serveur MCP amusant sur le thème de Donjons et Dragons qui simule un lancer de dés, suit les lancers passés et renvoie les résultats à l'aide de HTTP en continu. Cet exemple léger a mis en évidence la facilité avec laquelle il est possible de construire et de déployer des serveurs MCP à l'aide d'outils et d'infrastructures AWS comme Lambda et Fargate. Ils ont également présenté Strands SDK, un kit d'outils open-source pour la création d'agents multimodaux qui interagissent avec les serveurs MCP.

Support MCP dans Elastic Agent Builder

Vous pouvez commencer à expérimenter MCP dès aujourd'hui en utilisant Elastic Agent Builder, qui est le moyen le plus simple de créer des agents directement à partir de vos données. Agent Builder vous permet d'exposer des outils basés sur Elasticsearch à des agents compatibles avec MCP et il est déjà livré avec quelques outils intégrés puissants, notamment :

• platform.core.search - Exécute des recherches à l'aide du DSL Elasticsearch Query complet.

• platform.core.list_indices - Liste de tous les index disponibles dans Elasticsearch (aide les agents à découvrir les données existantes)

• platform.core.get_index_mapping - Récupère les correspondances de champs pour un index spécifique (aide les agents à comprendre la forme et les types de vos données).

• platform.core.get_document_by_id - Recherche d'un document spécifique par son numéro d'identification (pour une recherche précise)

Grâce à ces outils, vous pouvez doter votre agent d'une fonction de recherche et de pertinence au niveau de l'entreprise, ce qui est essentiel pour créer des agents d'intelligence artificielle fiables.

Ce qui rend Agent Builder encore plus puissant, c'est la possibilité de définir et d'exposer vos propres outils personnalisés, adaptés aux besoins de votre application. Ceci est particulièrement utile pour les flux de travail basés sur l'opinion ou répétables lorsque vous souhaitez que l'agent effectue un type de recherche spécifique sur un index spécifique sans avoir à redécouvrir cette logique à chaque fois. Au lieu de dépenser des jetons en planification et en raisonnement pour arriver à la même conclusion, vous pouvez encoder cette intention directement dans un outil, ce qui rend vos agents plus rapides, plus fiables et plus rentables.

Dans l'interface utilisateur de l'Agent Builder, voici un exemple de définition d'outil personnalisé qui utilise ES|QL :

Une fois que vous avez défini vos outils personnalisés, vous pouvez les exposer (ainsi que les outils natifs intégrés) à l'aide de MCP en cliquant sur la liste déroulante Manage MCP et en copiant l'URL du serveur MCP.

Vous pouvez maintenant importer ce point de terminaison MCP dans n'importe quel client qui consomme MCP pour le connecter à Agent Builder et lui donner accès à tous les outils disponibles. Pour plus d'informations, lisez cette introduction à Agent Builder.

Conclusion

Le MCP Dev Summit a clairement montré que le MCP façonne la manière dont ces agents d'intelligence artificielle interagissent entre eux et avec le monde des données qui les entoure. Qu'il s'agisse de connecter un agent aux données de l'entreprise ou de concevoir des agents entièrement autonomes, MCP offre une méthode d'intégration normalisée et composable qui devient rapidement utile à grande échelle. Des protocoles de transport et des modèles de sécurité aux registres et à la gouvernance, l'écosystème MCP mûrit rapidement. Le programme MCP restera ouvert et axé sur la communauté, de sorte que les développeurs d'aujourd'hui ont la possibilité de façonner son évolution.

Qu'est-ce que l'IA de printemps ?

Spring AI 1.0, une solution complète pour l'ingénierie de l'IA en Java, est maintenant disponible après une période de développement significative influencée par les progrès rapides dans le domaine de l'IA. Cette version comprend de nombreuses nouvelles fonctionnalités essentielles pour les ingénieurs en IA.

Java et Spring sont les mieux placés pour profiter de la vague de l'IA. Des tonnes d'entreprises utilisent Spring Boot, ce qui facilite grandement l'intégration de l'IA dans ce qu'elles font déjà. Vous pouvez relier votre logique d'entreprise et vos données à ces modèles d'IA sans trop de difficultés.

Spring AI prend en charge différents modèles et technologies d'IA, tels que :

• Modèles d'images: générer des images à partir de textes.

• Modèles de transcription: prendre des sources audio et les convertir en texte.

• Modèles d'intégration : convertissent des données arbitraires en vecteurs, qui sont des types de données optimisés pour la recherche de similarités sémantiques.

• Modèles de chat : cesdevraient vous être familiers ! Vous avez sans doute déjà eu une brève conversation avec l'un d'entre eux.

Les modèles de dialogue en ligne sont ceux qui semblent le plus faire parler d'eux dans le domaine de l'IA, et à juste titre, ils sont géniaux ! Ils peuvent vous aider à corriger un document ou à écrire un poème. (Ne leur demandez pas de raconter une blague... pour l'instant). Ils sont géniaux, mais ils ont quelques problèmes.

Des solutions d'IA de printemps pour relever les défis de l'IA

Examinons quelques-uns de ces problèmes et leurs solutions dans Spring AI.

Problème

Solution

Cohérence

Les modèles de chat sont ouverts d'esprit et enclins à la distraction.

Vous pouvez les doter d'un système d'incitation pour régir leur forme et leur structure générales

Mémoire

Les modèles d'IA n'ont pas de mémoire et ne peuvent donc pas établir de corrélation entre les messages d'un utilisateur donné et ceux d'un autre utilisateur.

Vous pouvez leur donner un système de mémoire pour stocker les parties pertinentes de la conversation

L'isolement

Les modèles d'IA vivent dans de petits bacs à sable isolés, mais ils peuvent faire des choses vraiment étonnantes si vous leur donnez accès à des outils - des fonctions qu'ils peuvent invoquer lorsqu'ils le jugent nécessaire

Spring AI prend en charge l'appel d'outils, ce qui vous permet d'indiquer au modèle d'IA les outils présents dans son environnement, qu'il peut ensuite vous demander d'invoquer. Cette interaction à plusieurs tours est gérée de manière transparente pour vous

Données privées

Les modèles d'IA sont intelligents, mais ils ne sont pas omniscients ! Ils ne savent pas ce que contiennent vos bases de données propriétaires - et nous pensons que vous ne voudriez pas qu'ils le sachent !

Vous devez informer leurs réponses en remplissant les invites, c'est-à-dire en utilisant le puissant opérateur de concaténation de chaînes pour insérer du texte dans la demande avant que le modèle n'examine la question posée. Des informations de base, si vous voulez. Comment décidez-vous de ce qui doit être envoyé et de ce qui ne doit pas l'être ? Utilisez un magasin de vecteurs pour sélectionner uniquement les données pertinentes et les envoyer ensuite. C'est ce que l'on appelle la génération augmentée par récupération (RAG).

Hallucination

Les modèles de chat de l'IA aiment discuter ! Et parfois, ils le font avec tant d'assurance qu'ils peuvent inventer des choses

Vous devez recourir à l'évaluation - en utilisant un modèle pour valider les résultats d'un autre - pour confirmer des résultats raisonnables.

Bien entendu, aucune application d'IA n'est isolée. Aujourd'hui, les systèmes et services d'IA modernes fonctionnent mieux lorsqu'ils sont intégrés à d'autres systèmes et services. Model Context Protocol(MCP) permet de connecter vos applications d'intelligence artificielle à d'autres services basés sur MCP, quel que soit le langage dans lequel elles sont écrites. Vous pouvez assembler tous ces éléments dans des flux de travail agentiques qui mènent à un objectif plus large.

Le plus beau ? Vous pouvez faire tout cela en vous appuyant sur les idiomes et abstractions familiers auxquels tout développeur Spring Boot est habitué : des dépendances de départ pratiques pour pratiquement tout sont disponibles sur Spring Initializr.

Spring AI fournit des autoconfigurations Spring Boot pratiques qui vous donnent la configuration conventionnelle sur la configuration que vous connaissez et attendez. Spring AI prend en charge l'observabilité avec l'Actuator de Spring Boot et le projet Micrometer. Il est également compatible avec GraalVM et les threads virtuels, ce qui vous permet de créer des applications d'IA super rapides et efficaces qui évoluent.

Pourquoi Elasticsearch ?

Elasticsearch est un moteur de recherche plein texte, vous le savez probablement. Alors pourquoi l'utiliser pour ce projet ? C'est aussi un magasin de vecteurs ! Il s'agit d'un excellent outil, dans lequel les données sont placées à côté du texte intégral. Autres avantages notables :

• Très facile à mettre en place

• Opensource

• Évolutivité horizontale

• La plupart des données libres de votre organisation se trouvent probablement déjà dans un cluster Elasticsearch.

• Fonctionnalité de moteur de recherche complète

• Entièrement intégré à Spring AI!

Si l'on tient compte de tous ces éléments, Elasticsearch remplit toutes les conditions d'un excellent magasin de vecteurs, alors configurons-le et commençons à construire notre application !

Prise en main d'Elasticsearch

Nous allons avoir besoin d'Elasticsearch et de Kibana, la console d'interface utilisateur que vous utiliserez pour interagir avec les données hébergées dans la base de données.

Vous pouvez tout essayer sur votre machine locale grâce aux images Docker et à la page d'accueil d'Elastic.co. Allez-y, faites défiler vers le bas pour trouver la commande curl, exécutez-la et envoyez-la directement dans votre shell :

Il suffit de tirer et de configurer des images Docker pour Elasticsearch et Kibana, et après quelques minutes, elles seront opérationnelles sur votre machine locale, avec les informations d'identification de connexion.

Vous avez également deux urls différentes que vous pouvez utiliser pour interagir avec votre instance Elasticsearch. Suivez les instructions et dirigez votre navigateur vers http://localhost:5601.

Notez également le nom d'utilisateur elastic et le mot de passe affichés sur la console : vous en aurez besoin pour vous connecter (dans l'exemple ci-dessus, il s'agit respectivement de elastic et w1GB15uQ).

L'intégration de l'application

Allez sur la page Spring Initializr et générez un nouveau projet Spring AI avec les dépendances suivantes :

• Elasticsearch Vector Store

• Spring Boot Actuator

• GraalVM

• OpenAI

• Web

Veillez à choisir la dernière et la meilleure version de Java (idéalement Java 24 - au moment de la rédaction de ce document - ou une version plus récente) et l'outil de construction de votre choix. Nous utilisons Apache Maven dans cet exemple.

Cliquez sur Generate, puis décompressez le projet et importez-le dans l'IDE de votre choix. (Nous utilisons IntelliJ IDEA.)

Commençons par le commencement : spécifions les détails de la connexion pour votre application Spring Boot. Sur application.properties,, écrivez ce qui suit :

Nous allons également utiliser la capacité de stockage vectoriel de Spring AI pour initialiser tout ce qui est nécessaire du côté d'Elasticsearch en termes de structures de données, donc spécifier :

Nous allons utiliser OpenAI dans cette démo, en particulier le modèle d'intégration et le modèle de conversation (n'hésitez pas à utiliser le service que vous préférez, tant que Spring AI le prend en charge).

Le modèle d'intégration est nécessaire pour créer des intégrations des données avant de les stocker dans Elasticsearch. Pour qu'OpenAI fonctionne, nous devons spécifier l'adresse API key:

Vous pouvez la définir comme une variable d'environnement telle que SPRING_AI_OPENAI_API_KEY pour éviter d'avoir à la stocker dans votre code source.

Nous allons télécharger des fichiers, donc assurez-vous de personnaliser la quantité de données pouvant être téléchargées vers le conteneur de servlet :

Nous y sommes presque ! Avant de nous plonger dans l'écriture du code, donnons un aperçu de la manière dont cela va fonctionner.

Sur notre machine, nous avons téléchargé le fichier suivant (une liste de règles pour un jeu de société), l'avons renommé en test.pdf et l'avons placé dans ~/Downloads/test.pdf.

Le fichier sera envoyé au point de terminaison /rag/ingest (remplacez le chemin d'accès en fonction de votre configuration locale) :

Cela peut prendre quelques secondes...

En coulisses, les données sont envoyées à OpenAI, qui crée des enchâssements de données ; ces données sont ensuite écrites dans Elasticsearch, à la fois les vecteurs et le texte d'origine.

C'est à partir de ces données, et de tous les enchâssements qu'elles contiennent, que la magie opère. Nous pouvons ensuite interroger Elasticsearch à l'aide de l'interface VectorStore.

Le flux complet se présente comme suit :

• Le client HTTP télécharge le PDF de votre choix vers l'application Spring.

• Spring AI se charge de l'extraction du texte de notre PDF et découpe chaque page en morceaux de 800 caractères.

• OpenAI génère la représentation vectorielle pour chaque morceau.

• Le texte fragmenté et l'intégration sont ensuite stockés dans Elasticsearch.

Enfin, nous émettrons une requête :

Et nous obtiendrons une réponse pertinente :

C'est bien ! Comment cela fonctionne-t-il ?

• Le client HTTP soumet la question à l'application Spring.

• Spring AI obtient la représentation vectorielle de la question auprès d'OpenAI.

• Cette intégration permet de rechercher des documents similaires dans les morceaux Elasticsearch stockés et d'extraire les documents les plus similaires.

• Spring AI envoie ensuite la question et le contexte récupéré à OpenAI pour générer une réponse LLM.

• Enfin, il renvoie la réponse générée et une référence au contexte récupéré.

Plongeons dans le code Java pour voir comment cela fonctionne réellement.

Tout d'abord, la classe Main: il s'agit d'une classe principale standard pour n'importe quelle application Spring Boot.

Il n'y a rien à voir. Continuons...

Ensuite, un contrôleur HTTP de base :

Le contrôleur appelle simplement un service que nous avons construit pour gérer l'ingestion de fichiers et leur écriture dans la base de données vectorielles Elasticsearch, puis pour faciliter les requêtes sur cette même base de données vectorielles.

Examinons le service :

Ce code gère l'ensemble de l'ingestion : étant donné un Spring Framework Resource, qui est un conteneur d'octets, nous lisons les données PDF (présumées être un fichier .PDF - assurez-vous de le valider avant d'accepter des entrées arbitraires !) à l'aide de Spring AI PagePdfDocumentReader, puis nous les tokenisons à l'aide de Spring AI TokenTextSplitter, et enfin nous ajoutons les List<Document>s résultants à l'implémentation de VectorStore, ElasticsearchVectorStore.

Vous pouvez le confirmer en utilisant Kibana : après avoir envoyé un fichier au point de terminaison /rag/ingest, ouvrez votre navigateur sur localhost:5601 et, dans le menu latéral de gauche, naviguez vers Dev Tools. Vous pouvez y émettre des requêtes pour interagir avec les données de l'instance Elasticsearch.

Emettez une requête comme celle-ci :

Passons maintenant aux choses sérieuses : comment récupérer ces données en réponse à des requêtes d'utilisateurs ?

Voici un premier aperçu de la mise en œuvre de la requête, dans une méthode appelée directRag.

Le code est assez simple, mais nous allons le décomposer en plusieurs étapes :

1. Utilisez le site VectorStore pour effectuer une recherche de similitude.

2. Étant donné tous les résultats, récupérer les Documents sous-jacents de Spring AI et extraire leur texte, en les concaténant tous en un seul résultat.

3. Envoyer les résultats du site VectorStore au modèle, accompagnés d'une invite indiquant au modèle ce qu'il doit en faire et de la question de l'utilisateur. Attendez la réponse et renvoyez-la.

Il s'agit de la RAG (retrieval augmented generation). Il s'agit de l'idée que nous utilisons des données provenant d'un magasin de vecteurs pour informer le traitement et l'analyse effectués par le modèle. Maintenant que vous savez comment faire, espérons que vous n'aurez jamais à le faire ! En tout cas, pas de cette manière : Les conseillers de Spring AI sont là pour simplifier encore davantage ce processus.

Advisors vous permet de pré- et post-traiter une requête vers un modèle donné, en plus de fournir une couche d'abstraction entre votre application et le magasin de vecteurs. Ajoutez la dépendance suivante à votre construction :

Ajoutez une autre méthode appelée advisedRag(String question) à la classe :

Toute la logique du modèle RAG est encapsulée dans le site QuestionAnswerAdvisor. Pour le reste, tout se passe comme n'importe quelle demande adressée à ChatModel! C'est bien !

Vous pouvez obtenir le code complet sur GitHub.

Conclusion

Dans cette démo, nous avons utilisé des images Docker et tout fait sur notre machine locale, mais l'objectif ici est de construire des systèmes et des services d'IA dignes d'une production. Il y a plusieurs choses que vous pouvez faire pour que cela devienne une réalité.

Tout d'abord, vous pouvez ajouter Spring Boot Actuator pour surveiller la consommation de jetons. Les jetons sont une approximation du coût de la complexité (et parfois du coût en dollars) d'une demande donnée au modèle.

Vous avez déjà l'Actuator Spring Boot sur le classpath, il suffit donc de spécifier les propriétés suivantes pour afficher toutes les métriques (capturées par le magnifique projet Micrometer.io ) :

Redémarrez votre application. Effectuez une recherche, puis rendez-vous sur : http://localhost:8080/actuator/metrics. Recherchez "token" et vous verrez des informations sur les jetons utilisés par l'application. Veillez à garder un œil sur ce point. Vous pouvez bien sûr utiliser l' intégration de Micrometer pour Elasticsearch pour pousser ces métriques et faire en sorte qu'Elasticsearch agisse comme votre base de données de séries temporelles de choix, aussi !

Il faut alors considérer que chaque fois que nous faisons une requête à un entrepôt de données comme Elasticsearch, ou à OpenAI, ou à d'autres services réseau, nous faisons de l'IO et - souvent - cette IO bloque les threads sur lesquels elle s'exécute. Java 21 et les versions ultérieures intègrent des threads virtuels non bloquants qui améliorent considérablement l'évolutivité. L'activer avec :

Enfin, vous voudrez héberger votre application et vos données dans un endroit où elles pourront prospérer et évoluer. Nous sommes certains que vous avez déjà réfléchi à l'endroit où vous allez exécuter votre application, mais où allez-vous héberger vos données ? Pouvons-nous vous recommander l'Elastic Cloud? Il est sécurisé, privé, évolutif et doté de nombreuses fonctionnalités. Ce que nous préférons ? Si vous le souhaitez, vous pouvez obtenir l'édition Serverless dans laquelle Elastic porte le pager, pas vous !

Ce blog se concentre sur l'exécution et la personnalisation du modèle d'agent de récupération LangChain en utilisant LangGraph Studio et LangGraph CLI. Le modèle fournit un cadre pour la construction d'applications de génération augmentée de recherche (RAG), en tirant parti de divers backends de recherche tels qu'Elasticsearch.

Nous vous guiderons dans la mise en place, la configuration de l'environnement et l'exécution efficace du modèle avec Elastic tout en personnalisant le flux de l'agent.

Produits requis

Avant de poursuivre, assurez-vous que les éléments suivants sont installés :

• Déploiement d'Elasticsearch Cloud ou déploiement d'Elasticsearch sur site (ou créer un essai gratuit de 14 jours sur Elastic Cloud) - Version 8.0.0 ou supérieure

• Python 3.9+

• Accès à un fournisseur de LLM tel que Cohere (utilisé dans ce guide), OpenAI, ou Anthropic/Claude

Création de l'application LangGraph

1. Installer l'interface de programmation LangGraph

2. Créer une application LangGraph à partir de retrieval-agent-template

Un menu interactif vous permettra de choisir parmi une liste de modèles disponibles. Sélectionnez 4 pour Retrieval Agent et 1 pour Python, comme indiqué ci-dessous :

• Dépannage: Si vous rencontrez l'erreur "urllib.error.URLError : <urlopen error [SSL : CERTIFICATE_VERIFY_FAILED] certificate verify failed : unable to get local issuer certificate (_ssl.c:1000)> "

Veuillez exécuter la commande Install Certificate de Python pour résoudre le problème, comme indiqué ci-dessous.

3. Installer les dépendances

À la racine de votre nouvelle application LangGraph, créez un environnement virtuel et installez les dépendances en mode edit afin que vos modifications locales soient utilisées par le serveur :

Mise en place de l'environnement

1. Créez un environnement . fichier

Le fichier .env contient les clés API et les configurations permettant à l'application de se connecter au fournisseur de LLM et de récupération que vous avez choisi. Générer un nouveau fichier .env en dupliquant l'exemple de configuration :

2. Configurez le fichier .env fichier

Le fichier .env est livré avec un ensemble de configurations par défaut. Vous pouvez le mettre à jour en ajoutant les clés et valeurs API nécessaires en fonction de votre configuration. Les clés qui ne sont pas pertinentes pour votre cas d'utilisation peuvent être laissées inchangées ou supprimées.

• Exemple de fichier .env (avec Elastic Cloud et Cohere)

Vous trouverez ci-dessous un exemple de configuration .env pour l'utilisation d'Elastic Cloud en tant que fournisseur d'extraction et de Cohere en tant que LLM, comme démontré dans ce blog :

Note : Bien que ce guide utilise Cohere pour la génération de réponses et l'intégration, vous êtes libre d'utiliser d'autres fournisseurs LLM tels que OpenAI, Claude, ou même un modèle LLM local en fonction de votre cas d'utilisation. Assurez-vous que chaque clé que vous avez l'intention d'utiliser est présente et correctement définie dans le fichier.env.

3. Mise à jour du fichier de configuration -configuration.py

Après avoir configuré votre fichier .env avec les clés API appropriées, l'étape suivante consiste à mettre à jour la configuration du modèle par défaut de votre application. La mise à jour de la configuration garantit que le système utilise les services et les modèles que vous avez spécifiés dans votre fichier .env.

Accédez au fichier de configuration :

Le fichier configuration.py contient les paramètres du modèle par défaut utilisés par l'agent de recherche pour trois tâches principales :

• Modèle d'intégration - convertit les documents en représentations vectorielles

• Modèle de requête - traite la requête de l'utilisateur en un vecteur

• Modèle de réponse - génère la réponse finale

Par défaut, le code utilise les modèles d'OpenAI (par exemple, openai/text-embedding-3-small) et d'Anthropic (par exemple, anthropic/claude-3-5-sonnet-20240620 and anthropic/claude-3-haiku-20240307). Dans ce blog, nous passerons à l'utilisation des modèles Cohere. Si vous utilisez déjà OpenAI ou Anthropic, aucun changement n'est nécessaire.

Exemple de modifications (en utilisant Cohere) :

Ouvrez configuration.py et modifiez les valeurs par défaut du modèle comme indiqué ci-dessous :

Exécution de l'agent de recherche avec LangGraph CLI

1. Lancer le serveur LangGraph

Cette opération permet de démarrer localement le serveur LangGraph API. Si l'opération se déroule correctement, vous devriez voir apparaître quelque chose comme :

URL de l'interface utilisateur d'Open Studio.

Deux graphiques sont disponibles :

• Graphique de récupération: Récupère les données d'Elasticsearch et répond à la requête à l'aide d'un LLM.

• Graphique d'indexation: Indexe les documents dans Elasticsearch et génère des embeddings à l'aide d'un LLM.

2. Configuration du graphe de l'indexeur

• Ouvrez le graphique de l'indexeur.

• Cliquez sur gérer les assistants.

  • Cliquez sur "Ajouter un nouvel assistant", entrez les détails de l'utilisateur comme spécifié, puis fermez la fenêtre.

3. Indexation de documents types

• Indexez les documents types suivants, qui représentent un rapport trimestriel hypothétique pour l'organisation NoveTech :

Une fois les documents indexés, un message de suppression apparaît dans le fil de discussion, comme indiqué ci-dessous.

4. Exécution du graphe de recherche

• Passez au graphique de recherche.

• Saisissez la requête de recherche suivante :

Le système renvoie les documents pertinents et fournit une réponse exacte sur la base des données indexées.

Personnaliser l'agent de recherche

Pour améliorer l'expérience de l'utilisateur, nous introduisons une étape de personnalisation dans le graphe de recherche afin de prédire les trois prochaines questions que l'utilisateur pourrait poser. Cette prédiction est basée sur :

• Contexte des documents extraits

• Interactions avec les utilisateurs précédents

• Dernière requête de l'utilisateur

Les modifications de code suivantes sont nécessaires pour mettre en œuvre la fonction de prédiction des requêtes :

1. Mettez à jour graph.py

• Ajouter la fonction predict_query:

• Modifier la fonction respond pour qu'elle renvoie l'objet response au lieu du message :

• Mise à jour de la structure du graphe afin d'ajouter un nouveau nœud et une nouvelle arête pour predict_query :

2. Mettez à jour prompts.py

• Demande de devis pour la prédiction de guery dans prompts.py:

3. Mettez à jour configuration.py

• Ajouter predict_next_question_prompt:

4. Mettez à jour state.py

• Ajouter les attributs suivants :

5. Réexécutez le graphique de recherche

• Saisissez à nouveau la requête de recherche suivante :

Le système traitera les données et prévoira trois questions connexes que les utilisateurs pourraient poser, comme indiqué ci-dessous.

Conclusion

L'intégration du modèle Retrieval Agent dans LangGraph Studio et CLI offre plusieurs avantages :

• Développement accéléré: Les modèles et les outils de visualisation rationalisent la création et le débogage des flux de recherche, réduisant ainsi le temps de développement.

• Déploiement transparent: La prise en charge intégrée des API et de la mise à l'échelle automatique garantit un déploiement sans heurts dans tous les environnements.

• Des mises à jour faciles : La modification des flux de travail, l'ajout de nouvelles fonctionnalités et l'intégration de nœuds supplémentaires sont simples, ce qui facilite l'évolution et l'amélioration du processus de recherche.

• Mémoire persistante: Le système conserve les états et les connaissances des agents, ce qui améliore la cohérence et la fiabilité.

• Modélisation flexible des flux de travail: Les développeurs peuvent personnaliser la logique de recherche et les règles de communication pour des cas d'utilisation spécifiques.

• Interaction et débogage en temps réel: La possibilité d'interagir avec les agents en cours d'exécution permet de tester et de résoudre les problèmes de manière efficace.

En tirant parti de ces fonctionnalités, les organisations peuvent construire des systèmes de recherche puissants, efficaces et évolutifs qui améliorent l'accessibilité des données et l'expérience de l'utilisateur.

Le code source complet de ce projet est disponible sur GitHub.

À propos d'Amazon Nova

Amazon Nova est une famille de modèles d'intelligence artificielle d'Amazon, disponibles sur Amazon Bedrock et conçus pour offrir de hautes performances et un bon rapport coût-efficacité. Ces modèles fonctionnent avec des entrées texte, image et vidéo, génèrent des sorties textuelles et sont optimisés pour répondre à différents besoins en termes de précision, de vitesse et de coût.

Principaux modèles de l'Amazon Nova

• Amazon Nova Micro : Axé exclusivement sur le texte, ce modèle rapide et économique est idéal pour la traduction, le raisonnement, la complétion de codes et la résolution de problèmes mathématiques. Sa production dépasse les 200 jetons par seconde, ce qui en fait un outil idéal pour les applications nécessitant des réponses instantanées.

• Amazon Nova Lite : un modèle multimodal économique capable de traiter rapidement des images, des vidéos et du texte. Il se distingue par sa rapidité et sa précision, et convient plus particulièrement aux applications interactives et à fort volume où le coût est un facteur déterminant.

• Amazon Nova Pro : L'option la plus avancée, combinant haute précision, vitesse et rentabilité. Idéal pour les tâches complexes telles que le résumé de vidéos, les questions et réponses, le développement de logiciels et les agents d'intelligence artificielle. Les avis d'experts attestent de son excellence en matière de compréhension textuelle et visuelle, ainsi que de sa capacité à suivre des instructions et à exécuter des flux de travail automatisés.

Les modèles Amazon Nova sont adaptés à une variété d'applications, de la création de contenu et de l'analyse de données au développement de logiciels et à l'automatisation des processus alimentés par l'IA.

Ci-dessous, nous allons montrer comment utiliser les modèles Amazon Nova en conjonction avec Elasticsearch pour l'analyse automatisée des avis sur les produits.

Ce que nous ferons :

1. Créer un point de terminaison via Inference API, intégrant Amazon Bedrock avec Elasticsearch.

2. Créer un pipeline à l'aide du processeur d'inférence, qui fera des appels au point d'extrémité de l'API d'inférence.

3. Indexer les avis sur les produits et générer automatiquement une analyse des avis à l'aide du pipeline.

4. Analyser les résultats de l'intégration.

Création d'un point de terminaison dans l'API d'inférence avec Amazon Nova Lite

Tout d'abord, nous configurons l'API Inference pour intégrer Amazon Bedrock à Elasticsearch. Nous définissons Amazon Nova Lite, id amazon.nova-lite-v1:0, comme le modèle à utiliser, car il offre un équilibre entre la vitesse, la précision et le coût.

Remarque : vous devez disposer d'informations d'identification valides pour utiliser Amazon Bedrock. Vous pouvez consulter la documentation relative à l'obtention des clés d'accès ici :

Création du pipeline d'analyse de l'examen

Nous allons maintenant créer un pipeline de traitement qui utilisera le processeur d'inférence pour exécuter une invite d'analyse de révision. Cette invite enverra les données d'évaluation à Amazon Nova Lite, qui les exécutera :

• Classification du sentiment (positif, négatif ou neutre).

• Résumé de l'examen.

• Génération de mots-clés.

• Mesure de l'authenticité (authentique | suspecte | générique).

Révision de l'indexation

Nous indexons maintenant les avis sur les produits à l'aide de l'API Bulk. Le pipeline créé précédemment sera automatiquement appliqué, ajoutant l'analyse générée par le modèle Nova aux documents indexés.

Interrogation et analyse des résultats

Enfin, nous lançons une requête pour voir comment le modèle Amazon Nova Lite analyse et classe les avis. En exécutant GET products/_search, nous obtenons les documents déjà enrichis des champs générés à partir du contenu de la revue.

Le modèle identifie le sentiment prédominant (positif, neutre ou négatif), génère des résumés concis, extrait les mots-clés pertinents et estime l'authenticité de chaque avis. Ces champs permettent de comprendre l'opinion du client sans avoir à lire le texte complet.

Pour interpréter les résultats, nous examinons

• Le sentiment, qui indique la perception globale du produit par le consommateur.

• Le résumé, qui met en évidence les principaux points mentionnés.

• Les mots-clés, qui peuvent être utilisés pour regrouper des avis similaires ou identifier des modèles de retour d'information.

• L'authenticité, qui indique si l'avis semble digne de confiance. Cette fonction est utile pour la curation ou la modération.

Conclusions

L'intégration entre Amazon Nova Lite et Elasticsearch a démontré comment les modèles de langage peuvent transformer des avis bruts en informations structurées et précieuses. En traitant les avis par le biais d'un pipeline, nous avons pu extraire le sentiment, l'authenticité, les résumés et les mots-clés de manière automatique et cohérente.

Les résultats montrent que le modèle peut comprendre le contexte des avis, classer les opinions des utilisateurs et mettre en évidence les points les plus pertinents de chaque expérience. Cela crée un ensemble de données beaucoup plus riche qui peut être exploité pour améliorer les capacités de recherche.

Le protocole de contexte de modèle (MCP) rend cela possible. Il connecte de manière transparente l'IA conversationnelle avec vos bases de données et vos API externes, transformant les demandes complexes en conversations naturelles. Si les LLM modernes sont excellents pour comprendre le langage, leur véritable potentiel se révèle lorsqu'ils sont intégrés à des systèmes du monde réel. MCP comble le fossé qui les sépare, en rendant l'interaction des données plus intuitive et plus efficace.

Dans ce billet, nous allons explorer :

• Architecture MCP - Comment cela fonctionne-t-il sous le capot ?

• Avantages d'un serveur MCP connecté à Elasticsearch

• Construire un serveur MCP alimenté par Elasticsearch

Des moments passionnants nous attendent ! L'intégration de MCP avec votre pile Elastic transforme la façon dont vous interagissez avec l'information, rendant les requêtes complexes aussi intuitives qu'une conversation de tous les jours.

Modèle Contexte Protocole

Model Context Protocol (MCP), développé par Anthropic, est une norme ouverte qui connecte les modèles d'intelligence artificielle à des sources de données externes par le biais de canaux sécurisés et bidirectionnels. Il résout un problème majeur de l'IA : l'accès en temps réel à des systèmes externes tout en préservant le contexte de la conversation.

Architecture MCP

Modèle Contexte L'architecture du protocole se compose de deux éléments clés :

• Clients MCP - Assistants IA et chatbots qui demandent des informations ou exécutent des tâches au nom des utilisateurs.

• Serveurs MCP - Référentiels de données, moteurs de recherche et API qui récupèrent les informations pertinentes ou effectuent les actions demandées (par exemple, appel d'API externes).

Les serveurs MCP exposent quatre capacités principales aux clients :

• Ressources - Données structurées, documents et contenu qui peuvent être récupérés et utilisés comme contexte pour les interactions LLM. Cela permet aux assistants d'IA d'accéder à des informations pertinentes à partir de bases de données, d'index de recherche ou d'autres sources.

• Outils - Fonctions exécutables qui permettent aux LLM d'interagir avec des systèmes externes, d'effectuer des calculs ou de prendre des mesures dans le monde réel. Ces outils étendent les capacités de l'IA au-delà de la génération de texte, en permettant aux assistants de déclencher des flux de travail, d'appeler des API ou de manipuler des données de manière dynamique.

• Invitations - Modèles d'invitations et flux de travail réutilisables pour normaliser et partager les interactions LLM communes.

• Échantillonnage - Demander des compléments LLM par l'intermédiaire du client pour permettre des comportements agentiques sophistiqués tout en maintenant la sécurité et la confidentialité.

Serveur MCP + Elasticsearch

Les systèmes traditionnels de récupération et de génération augmentée (RAG) récupèrent des documents sur la base des requêtes de l'utilisateur, mais le MCP va plus loin : il permet aux agents d'intelligence artificielle de construire et d'exécuter des tâches de manière dynamique et en temps réel. Cela permet aux utilisateurs de poser des questions en langage naturel, comme par exemple :

• "Affichez toutes les commandes de plus de 500 $ passées le mois dernier."

• "Quels sont les produits qui ont reçu le plus d'avis 5 étoiles ?"

Et obtenir des réponses instantanées et précises, sans avoir à rédiger la moindre requête.

MCP atteint cet objectif grâce à

• Sélection dynamique des outils - Les agents choisissent intelligemment les bons outils exposés via les serveurs MCP en fonction de l'intention de l'utilisateur. Les gestionnaires de programmes d'éducation et de formation tout au long de la vie "plus intelligents" sont généralement plus aptes à sélectionner les bons outils avec les arguments appropriés en fonction du contexte.

• Communication bidirectionnelle - Les agents et les sources de données échangent des informations de manière fluide, en affinant les requêtes si nécessaire (par ex. d'abord le mappage de l'index de consultation, puis seulement la construction de la requête ES).

• Orchestration multi-outils - Les flux de travail peuvent exploiter simultanément les outils de plusieurs serveurs MCP.

• Contexte persistant - Les agents se souviennent des interactions précédentes, ce qui permet de maintenir une continuité entre les conversations.

Un serveur MCP connecté à Elasticsearch débloque une puissante architecture de recherche en temps réel. Les agents d'intelligence artificielle peuvent explorer, interroger et analyser les données Elasticsearch à la demande. Vos données peuvent être recherchées par le biais d'une interface de chat simple.

Au-delà de la simple récupération de données, MCP permet d'agir. Il s'intègre à d'autres outils pour déclencher des flux de travail, automatiser des processus et alimenter des systèmes d'analyse. En séparant la recherche de l'exécution, MCP permet aux applications alimentées par l'IA de rester flexibles, à jour et intégrées de manière transparente dans les flux de travail des agents.

Pratique : Serveur MCP pour dialoguer avec vos données Elasticsearch

Pour interagir avec Elasticsearch via un serveur MCP, nous avons au moins besoin des fonctions suivantes :

• Récupérer les indices

• Obtenir des correspondances

• Effectuer des recherches à l'aide du DSL de requête d'Elasticsearch

Notre serveur est écrit en TypeScript, et nous utiliserons le SDK TypeScript officiel du MCP. Pour l'installation, nous recommandons d'installer l'application Claude Desktop (la version gratuite est suffisante) car elle comprend un client MCP intégré. Notre serveur MCP expose essentiellement le client Elasticsearch JavaScript officiel à travers les outils MCP.

Commençons par définir le client Elasticsearch et le serveur MCP :

Nous utiliserons les outils de serveur MCP suivants qui peuvent interagir avec Elasticsearch :

• Liste des index (list_indices) : Cet outil récupère tous les index Elasticsearch disponibles, en fournissant des détails tels que le nom de l'index, l'état de santé et le nombre de documents.

• Obtenir des correspondances (get_mappings) : Cet outil récupère les correspondances de champs pour un index Elasticsearch spécifié, aidant les utilisateurs à comprendre la structure et les types de données des documents stockés.

• Search (recherche) : Cet outil exécute une recherche Elasticsearch à l'aide d'un DSL de requête fourni. Il active automatiquement les surlignages pour les champs de texte, ce qui facilite l'identification des résultats de recherche pertinents.

L'implémentation complète du serveur MCP Elasticsearch est disponible dans le repo elastic/mcp-server-elasticsearch.

Chat avec votre index

Voyons comment configurer le serveur Elasticsearch MCP pour pouvoir poser des questions en langage naturel sur vos données, telles que "Trouver toutes les commandes de plus de 500 $ du mois dernier."

Configurez votre application Claude Desktop

• Ouvrir l'application Claude Desktop

• Naviguer vers Settings > Developer > MCP Servers

• Cliquez sur "Edit Config" et ajoutez cette configuration à votre claude_desktop_config.json:

Note : Cette configuration utilise le paquet @elastic/mcp-server-elasticsearch npm publié par Elastic. Si vous souhaitez développer localement, vous trouverez plus de détails sur l'installation du serveur Elasticsearch MCP ici.

Remplir votre index Elasticseach

• Vous pouvez utiliser nos données d'exemple pour remplir l'index "orders" pour cette démo.

• Cela vous permettra d'essayer des requêtes telles que "Trouver toutes les commandes de plus de 500 $ du mois dernier."

Commencez à l'utiliser

• Ouvrir une nouvelle conversation dans l'application Claude Desktop

• Le serveur MCP se connecte automatiquement

• Commencez à poser des questions sur vos données Elasticsearch !

Regardez cette démo pour voir à quel point il est facile d'interroger vos données Elasticsearch en utilisant le langage naturel :

Comment fonctionne-t-elle ?

À la question "Trouver toutes les commandes de plus de 500 $ du mois dernier", le LLM reconnaît l'intention d'effectuer une recherche dans l'index Elasticsearch avec les contraintes spécifiées. Pour effectuer une recherche efficace, l'agent doit.. :

• Déterminez le nom de l'index : orders

• Comprendre les mappings de l'index orders

• Construire le DSL de requête compatible avec les mappages d'index et enfin exécuter la requête de recherche.

Cette interaction peut être représentée comme suit :

Conclusion

Model Context Protocol améliore la façon dont vous interagissez avec les données Elasticsearch, en permettant des conversations en langage naturel au lieu de requêtes complexes. En associant les capacités de l'IA à vos données, MCP crée un flux de travail plus intuitif et plus efficace qui maintient le contexte tout au long de vos interactions.

Le serveur Elasticsearch MCP est disponible sous forme de paquetage npm public(@elastic/mcp-server-elasticsearch), ce qui facilite l'intégration pour les développeurs. Avec une configuration minimale, votre équipe peut commencer à explorer les données, à déclencher des flux de travail et à obtenir des informations par le biais de simples conversations.

Prêt à en faire l'expérience ? Essayez le serveur Elasticsearch MCP dès aujourd'hui et commencez à discuter avec vos données.

Comment fonctionne la canalisation multimodale RAG ?

1. Collecte d'indices → Images, sons, textes et cartes de profondeur provenant de la scène de crime de Gotham.

2. Génération d'embeddings → Chaque fichier est converti en vecteur à l'aide du modèle multimodal ImageBind.

3. Indexation dans Elasticsearch → Les vecteurs sont stockés pour une récupération efficace.

4. Recherche par similarité → Étant donné un nouvel indice, les vecteurs les plus similaires sont récupérés.

5. Le LLM analyse les preuves → Un modèle GPT-4 synthétise la réponse et identifie le suspect !

Technologies utilisées

• ImageBind → Génère des encastrements unifiés pour différentes modalités.

• Elasticsearch → Permet une recherche vectorielle rapide et efficace.

• LLM (GPT-4, OpenAI) → Analyse les preuves et produit un rapport final.

À qui s'adresse ce blog ?

• Utilisateurs d'Elastic intéressés par la recherche vectorielle multimodale.

• Les développeurs qui cherchent à comprendre le RAG multimodal dans la pratique.

• Toute personne à la recherche de solutions évolutives pour l'analyse de données provenant de sources multiples.

Conditions préalables à la mise en place d'un RAG multimodal : mise en place de l'environnement

Pour résoudre les crimes de Gotham City, vous devez mettre en place votre environnement technologique. Suivez ce guide étape par étape :

1. Exigences techniques

Composant

Spécifications

Système OS

Linux, macOS ou Windows

Python

3.10 ou plus récent

RAM

8 Go minimum (16 Go recommandés)

GPU

Facultatif mais recommandé pour ImageBind

2. Mise en place du projet

Tout le matériel d'enquête est disponible sur GitHub, et nous utiliserons Jupyter Notebook (Google Colab) pour cette expérience interactive de résolution de crimes. Suivez les étapes suivantes pour commencer :

Configuration avec Jupyter Notebook (Google Colab)

1. Accéder à l'ordinateur portable

• Ouvrez notre carnet Google Colab prêt à l'emploi : RAG multimodal avec Elasticsearch.

• Ce carnet contient tout le code et les explications dont vous avez besoin pour suivre le cours.

2. Cloner le référentiel

3. Installer les dépendances

4. Configurer les informations d'identification

Note : Le modèle ImageBind (~2GB) sera téléchargé automatiquement lors de la première exécution.

Maintenant que tout est prêt, plongeons dans les détails et résolvons le crime !

Introduction : Le crime à Gotham City

Par une nuit pluvieuse à Gotham City, un crime choquant secoue la ville. Le commissaire Gordon a besoin de votre aide pour élucider ce mystère. Les indices sont dispersés dans différents formats : images floues, sons mystérieux, textes cryptés et même cartes de profondeur. Êtes-vous prêt à utiliser la technologie d'IA la plus avancée pour résoudre l'affaire ?

Dans ce blog, vous serez guidé pas à pas dans la construction d'un système RAG (Retrieval-Augmented Generation) multimodal qui unifie différents types de données(images, audio, textes et cartes de profondeur) dans un espace de recherche unique. Nous utiliserons ImageBind pour générer des encastrements multimodaux, Elasticsearch pour stocker et récupérer ces encastrements, et un Grand Modèle de Langage (LLM) pour analyser les preuves et générer un rapport final.

Principes fondamentaux : Architecture multimodale RAG

Qu'est-ce qu'un RAG multimodal ?

L'essor du multimodal RAG (Retrieval-Augmented Generation) révolutionne la façon dont nous interagissons avec les modèles d'IA. Traditionnellement, les systèmes RAG travaillent exclusivement avec du texte, récupérant les informations pertinentes dans des bases de données avant de générer des réponses. Toutefois, le monde ne se limite pas au texte : les images, les vidéos et les sons sont également porteurs de connaissances précieuses. C'est pourquoi les architectures multimodales gagnent en importance, permettant aux systèmes d'IA de combiner des informations provenant de différents formats pour obtenir des réponses plus riches et plus précises.

Trois approches principales pour le RAG multimodal

Trois stratégies sont couramment utilisées pour mettre en œuvre un RAG multimodal. Chaque approche présente ses propres avantages et limites, en fonction du cas d'utilisation :

1. Espace vectoriel partagé

Les données provenant de différentes modalités sont mises en correspondance dans un espace vectoriel commun à l'aide de modèles multimodaux tels qu'ImageBind. Cela permet aux requêtes textuelles de récupérer des images, des vidéos et des fichiers audio sans conversion explicite de format.

Avantages :

• Permet la recherche multimodale sans nécessiter de conversion de format explicite.

• Il assure une intégration fluide entre les différentes modalités, permettant une recherche directe dans le texte, l'image, l'audio et la vidéo.

• Évolutif pour divers types de données, ce qui le rend utile pour les applications de recherche à grande échelle.

Inconvénients :

• La formation nécessite de grands ensembles de données multimodales, qui ne sont pas toujours disponibles.

• L'espace d'intégration partagé peut introduire une dérive sémantique, lorsque les relations entre les modalités ne sont pas parfaitement préservées.

• Les biais dans les modèles multimodaux peuvent avoir un impact sur la précision de la recherche, en fonction de la distribution de l'ensemble des données.

2. Une seule modalité ancrée

Toutes les modalités sont converties dans un format unique, généralement du texte, avant d'être extraites. Par exemple, les images sont décrites par des légendes générées automatiquement, et le son est transcrit en texte.

Avantages :

• Simplifie la recherche, car tout est converti en une représentation textuelle uniforme.

• Fonctionne bien avec les moteurs de recherche textuels existants, ce qui élimine la nécessité d'une infrastructure multimodale spécialisée.

• Peut améliorer l'interprétabilité puisque les résultats obtenus sont dans un format lisible par l'homme.

Inconvénients :

• Perte d'informations: Certains détails (par exemple, les relations spatiales dans les images, la tonalité dans le son) peuvent ne pas être entièrement pris en compte dans les descriptions textuelles.

• Dépend de la qualité du sous-titrage/de la transcription: Les erreurs dans les annotations automatiques peuvent réduire l'efficacité de la recherche.

• Elle n'est pas optimale pour les requêtes purement visuelles ou auditives, car le processus de conversion risque de supprimer le contexte essentiel.

3. Récupération séparée

Maintient des modèles distincts pour chaque modalité. Le système effectue des recherches distinctes pour chaque type de données et fusionne ensuite les résultats.

Avantages :

• Permet une optimisation personnalisée par modalité, améliorant la précision de la recherche pour chaque type de données.

• Moins de dépendance à l'égard de modèles multimodaux complexes, ce qui facilite l'intégration des systèmes de recherche existants.

• Permet de contrôler finement le classement et le reclassement, les résultats provenant de différentes modalités pouvant être combinés de manière dynamique.

Inconvénients :

• Nécessite la fusion des résultats, ce qui rend le processus de recherche et de classement plus complexe.

• Peut générer des réponses incohérentes si différentes modalités renvoient des informations contradictoires.

• Coût de calcul plus élevé car des recherches indépendantes sont effectuées pour chaque modalité, ce qui augmente le temps de traitement.

Notre choix : Espace vectoriel partagé avec ImageBind

Parmi ces approches, nous avons choisi l'espace vectoriel partagé, une stratégie qui s'aligne parfaitement avec le besoin de recherches multimodales efficaces. Notre implémentation est basée sur ImageBind, un modèle capable de représenter plusieurs modalités(texte, image, audio et vidéo) dans un espace vectoriel commun. Cela nous permet de

• Effectuer des recherches multimodales entre différents formats de médias sans avoir à tout convertir en texte.

• Utiliser des encastrements très expressifs pour capturer les relations entre les différentes modalités.

• Garantir l'évolutivité et l'efficacité, en stockant des encastrements optimisés pour une recherche rapide dans Elasticsearch.

En adoptant cette approche, nous avons construit un pipeline de recherche multimodale robuste, dans lequel une requête textuelle peut directement récupérer des images ou du son sans prétraitement supplémentaire. Cette méthode permet d'élargir les applications pratiques, de la recherche intelligente dans les grands référentiels aux systèmes de recommandation multimodaux avancés.

La figure suivante illustre le flux de données dans le pipeline RAG multimodal, en mettant en évidence le processus d'indexation, d'extraction et de génération de réponses sur la base de données multimodales :

Comment fonctionne l'espace d'intégration ?

Traditionnellement, les enchâssements de texte proviennent de modèles de langage (par exemple, BERT, GPT). Aujourd'hui, avec des modèles multimodaux natifs comme ImageBind de Meta AI, nous disposons d'une colonne vertébrale qui génère des vecteurs pour de multiples modalités :

• Le texte: Les phrases et les paragraphes sont transformés en vecteurs de même dimension.

• Images (vision): Les pixels sont placés dans le même espace dimensionnel que celui utilisé pour le texte.

• Audio: Les signaux sonores sont convertis en enregistrements comparables à des images et à du texte.

• Cartes de profondeur: Les données relatives à la profondeur sont traitées et donnent lieu à des vecteurs.

Ainsi, tout indice(texte, image, son, profondeur) peut être comparé à un autre en utilisant des mesures de similarité vectorielle comme la similarité cosinusoïdale. Si un échantillon audio de rires et une image du visage d'un suspect sont "proches" dans cet espace, nous pouvons en déduire une certaine corrélation (par exemple, la même identité).

Étape 1 - Collecte d'indices sur la scène de crime

Avant d'analyser les preuves, il faut les collecter. Le crime commis à Gotham a laissé des traces qui peuvent être cachées dans des images, des sons, des textes et même des données de profondeur. Organisons ces indices pour qu'ils alimentent notre système.

Qu'avons-nous ?

Le commissaire Gordon nous a envoyé les fichiers suivants, qui contiennent des preuves recueillies sur la scène de crime selon quatre modalités différentes :

Description de la piste et modalité

a) Images (2 photos)

• crime_scene1.jpg, crime_scene2.jpg → Photos prises sur la scène de crime. Montre des traces suspectes sur le sol.

• suspect_spotted.jpg → Image d'une caméra de sécurité montrant une silhouette s'enfuyant de la scène.

b) Audio (1 enregistrement)

• joker_laugh.wav → Un microphone situé à proximité de la scène de crime a capté un rire sinistre.

c) Texte (1 message)

• Riddle.txt, note2.txt → Des notes mystérieuses ont été trouvées sur place, peut-être laissées par le criminel.

d) Profondeur (1 carte de profondeur)

• depth_suspect.png → Une caméra de sécurité équipée d'un capteur de profondeur a filmé un suspect dans une ruelle voisine.

• jdancing-depth.png → Une caméra de sécurité équipée d'un capteur de profondeur a filmé un suspect descendant la station de métro.

Ces éléments de preuve se présentent sous des formes différentes et ne peuvent être analysés directement de la même manière. Nous devons les transformer en encastrements, c'est-à-dire en vecteurs numériques qui permettront d'effectuer des comparaisons intermodales.

Organisation des dossiers

Avant de commencer le traitement, nous devons nous assurer que tous les indices sont correctement organisés dans le répertoire data/ afin que le pipeline fonctionne correctement.

Structure de répertoire attendue :

Code pour vérifier l'organisation de l'indice

Avant de poursuivre, vérifions que tous les fichiers nécessaires se trouvent au bon endroit.

Exécution du fichier

Résultat attendu (si tous les fichiers sont corrects) :

Résultat attendu (si un fichier est manquant) :

Ce script permet d'éviter les erreurs avant de commencer à générer des embeddings et à les indexer dans Elasticsearch.

Étape 2 - Organiser les preuves

Générer des embeddings avec ImageBind

Pour unifier les indices, nous devons les transformer en représentations vectorielles (embeddings) qui capturent la signification de chaque modalité. Nous utiliserons ImageBind, un modèle de Meta AI qui génère des embeddings pour différents types de données(images, audio, texte et cartes de profondeur) dans un espace vectoriel partagé.

Comment fonctionne ImageBind ?

Pour comparer différents types de preuves(images, audio, texte et cartes de profondeur), nous devons les transformer en vecteurs numériques à l'aide d'ImageBind. Ce modèle permet de convertir n'importe quel type d'entrée dans le même format d'intégration, ce qui permet d'effectuer des recherches intermodales entre les différentes modalités.

Vous trouverez ci-dessous un code optimisé (src/embedding_generator.py) permettant de générer des embeddings pour tout type d'entrée en utilisant les processeurs appropriés pour chaque modalité :

Un tenseur est une structure de données fondamentale dans l'apprentissage automatique et l'apprentissage profond, en particulier lorsque l'on travaille avec des modèles comme ImageBind. Dans notre contexte :

Le tenseur représente les données d'entrée (image, son ou texte) converties dans un format mathématique que le modèle peut traiter. En particulier :

• Pour les images: Le tenseur représente l'image sous la forme d'une matrice multidimensionnelle de valeurs numériques (pixels organisés par hauteur, largeur et canaux de couleur).

• Pour l'audio: Le tenseur représente les ondes sonores comme une séquence d'amplitudes dans le temps.

• Pour le texte: Le tenseur représente les mots ou les tokens sous forme de vecteurs numériques.

Test de la génération d'encastrement :

Testons notre génération d'intégration avec le code suivant. Sauvegardez-le dans 02-stage/test_embedding_generation.py et exécutez-le avec cette commande :

Résultat attendu :

L'image a été transformée en un vecteur à 1024 dimensions.

Étape 3 - Stockage et recherche dans Elasticsearch

À présent que nous avons généré les encastrements pour les éléments de preuve, nous devons les stocker dans une base de données vectorielle afin de permettre des recherches efficaces. Pour ce faire, nous utiliserons Elasticsearch, qui prend en charge les vecteurs denses (dense_vector) et permet d'effectuer des recherches par similarité.

Cette étape consiste en deux processus principaux :

• Indexation des encastrements → Stockage des vecteurs générés dans Elasticsearch.

• Recherche de similarité → Récupère les documents les plus similaires à un nouvel élément de preuve.

Indexer les preuves dans Elasticsearch

Chaque élément de preuve traité par ImageBind (image, son, texte ou profondeur) est converti en un vecteur à 1024 dimensions. Nous devons stocker ces vecteurs dans Elasticsearch pour permettre des recherches ultérieures.

Le code suivant (src/elastic_manager.py) crée un index dans Elasticsearch et configure le mapping pour stocker les embeddings.

Exécution de l'indexation

Maintenant, indexons un élément de preuve pour tester le processus.

Résultat attendu dans Elasticsearch (résumé du document indexé) :

Pour indexer toutes les preuves multimodales, veuillez exécuter la commande Python suivante :

Les preuves sont désormais stockées dans Elasticsearch et prêtes à être récupérées en cas de besoin.

Vérification du processus d'indexation

Après avoir exécuté le script d'indexation, vérifions si toutes nos preuves ont été correctement stockées dans Elasticsearch. Vous pouvez utiliser les outils de développement de Kibana pour exécuter des requêtes de vérification :

1. Vérifiez d'abord si l'index a été créé :

2. Ensuite, vérifiez le nombre de documents par modalité :

3. Enfin, examiner la structure du document indexé :

Résultats attendus :

• Un index nommé `multimodal_content` devrait exister.

• Environ 7 documents répartis entre différentes modalités (vision, audio, texte, profondeur).

• Chaque document doit contenir les champs suivants : embedding, modality, description, metadata et content_path.

Cette étape de vérification permet de s'assurer que notre base de données d'éléments de preuve est correctement constituée avant de procéder aux recherches de similitudes.

Recherche de preuves similaires dans Elasticsearch

Maintenant que les preuves ont été indexées, nous pouvons effectuer des recherches pour trouver les enregistrements les plus similaires à un nouvel indice. Cette recherche utilise la similarité vectorielle pour renvoyer les enregistrements les plus proches dans l'espace d'intégration.

Le code suivant effectue cette recherche.

Tester la recherche - Utiliser l'audio comme requête pour des résultats multimodaux

Testons maintenant la recherche de preuves à l'aide d'un fichier audio suspect. Nous devons générer de la même manière un encapsulage pour le fichier et rechercher des encapsulages similaires :

Résultats attendus dans le terminal :

Nous pouvons maintenant analyser les éléments de preuve retrouvés et déterminer leur pertinence dans le cadre de l'affaire.

Au-delà de l'audio - Explorer les recherches multimodales

Inverser les rôles : Toute modalité peut être une question ""

Dans notre système RAG multimodal, chaque modalité est une requête de recherche potentielle. Dépassons l'exemple de l'audio et explorons comment d'autres types de données peuvent déclencher des enquêtes.

1. Recherche par texte (déchiffrer la note du criminel)

Scénario : Vous avez trouvé un message texte crypté et vous souhaitez trouver des preuves connexes.

Résultats attendus :

2. Recherche d'images (suivi de la scène de crime suspecte)

Scénario : Une nouvelle scène de crime (crime_scene2.jpg) doit être comparée à d'autres éléments de preuve.

Sortie :

3. Recherche d'une carte de profondeur (poursuite 3D)

Scénario : Une carte de profondeur jdancing-depth.png() révèle les motifs d'évasion de l' image.

Sortie

Pourquoi cela est-il important ?

Chaque modalité révèle des connexions uniques:

• Texte → Modèles linguistiques du suspect.

• Images → Reconnaissance de lieux et d'objets.

• Profondeur → reconstruction dela scène en 3D.

Nous disposons désormais d'une base de données de preuves structurée dans Elasticsearch, qui nous permet de stocker et d'extraire efficacement des preuves multimodales.

Résumé de ce que nous avons fait :

• Stockage d'encastrements multimodaux dans Elasticsearch.

• Effectuer des recherches de similitudes, trouver des preuves liées à de nouveaux indices.

• Test de la recherche à l'aide d'un fichier audio suspect, afin de s'assurer que le système fonctionne correctement.

Prochaine étape : Nous utiliserons un LLM (Large Language Model) pour analyser les données extraites et produire un rapport final.

Étape 4 - Faire le lien avec le LLM

Maintenant que les preuves ont été indexées dans Elasticsearch et peuvent être retrouvées par similarité, nous avons besoin d'un LLM (Large Language Model) pour les analyser et générer un rapport final à envoyer au commissaire Gordon. Le LLM sera chargé d'identifier des modèles, de relier des indices et de suggérer un suspect possible sur la base des éléments de preuve récupérés.

Pour cette tâche, nous utiliserons le GPT-4 Turbo, en formulant une demande détaillée afin que le modèle puisse interpréter les résultats de manière efficace.

Intégration du LLM

Pour intégrer le LLM dans notre système, nous avons créé la classe LLMAnalyzer (src/llm_analyzer.py), qui reçoit les preuves extraites d'Elasticsearch et génère un rapport médico-légal en utilisant ces preuves comme contexte d'invite.

Réglage de la température dans l'analyse LLM :

Pour notre système d'analyse criminelle, nous utilisons une température modérée de 0,5. Ce cadre équilibré a été choisi pour les raisons suivantes :

• Il s'agit d'une solution intermédiaire entre les résultats déterministes (trop rigides) et les résultats hautement aléatoires ;

• À 0,5, le modèle conserve une structure suffisante pour fournir des conclusions médico-légales logiques et justifiables ;

• Ce paramètre permet au modèle d'identifier des modèles et d'établir des connexions tout en restant dans des paramètres raisonnables d'analyse médico-légale ;

• Il permet de concilier le besoin de résultats cohérents et fiables avec la capacité de générer des analyses perspicaces.

Cette température modérée permet de garantir que notre analyse médico-légale est à la fois fiable et perspicace, en évitant les conclusions trop rigides et trop spéculatives.

Effectuer l'analyse des données probantes

Maintenant que nous avons l'intégration LLM, nous avons besoin d'un script qui relie tous les composants du système. Ce script va :

• Rechercher des preuves similaires dans Elasticsearch.

• Analyser les preuves récupérées à l'aide du LLM pour produire un rapport final.

Code : Script d'analyse des preuves

Résultats attendus du LLM

Conclusion : Affaire résolue

Après avoir recueilli et analysé tous les indices, le système RAG multimodal a identifié un suspect : Le Joker.

En combinant des images, du son, du texte et des cartes de profondeur dans un espace vectoriel partagé à l'aide d'ImageBind, le système a pu détecter des connexions qu'il aurait été impossible d'identifier manuellement. Elasticsearch a permis d'effectuer des recherches rapides et efficaces, tandis que le LLM a synthétisé les données dans un rapport clair et concluant.

Cependant, le véritable pouvoir de ce système va au-delà de Gotham City. L'architecture multimodale RAG ouvre la voie à de nombreuses applications dans le monde réel:

• Surveillance urbaine : Identification des suspects à partir d'images, de sons et de données de capteurs.

• L'analyse médico-légale : Corrélation d'éléments de preuve provenant de sources multiples pour résoudre des crimes complexes.

• Recommandation multimédia : Création de systèmes de recommandation qui comprennent les contextes multimodaux (par exemple, suggestion de musique sur la base d'images ou de textes).

• Tendances des médias sociaux : Détection des sujets en vogue dans différents formats de données.

Maintenant que vous avez appris à construire un système RAG multimodal, pourquoi ne pas le tester avec vos propres indices?

Partagez vos découvertes avec nous et aidez la communauté à progresser dans le domaine de l'IA multimodale!

Remerciements particuliers

Je tiens à remercier Adrian Cole pour sa précieuse contribution et son examen au cours du processus de définition de l'architecture de déploiement de ce code.

Références

• Construire un système de recherche d'images multimodales en utilisant la recherche KNN et les encastrements CLIP

• Recherche par k-Nearest Neighbor (kNN)

• Documentation officielle de PyTorch sur les tenseurs

• ImageBind : une nouvelle façon de "relier" l'IA à travers les sens

Elasticsearch permet aux utilisateurs de se connecter aux LLM à l'aide de l'API Open Inference, qui prend en charge des fournisseurs tels qu'Amazon Bedrock, Cohere, Google AI, Azure AI Studio, HuggingFace - en tant que service, entre autres.

Ollama est un outil qui vous permet de télécharger et d'exécuter des modèles LLM en utilisant votre propre infrastructure (votre machine/serveur local). Vous trouverez ici une liste des modèles disponibles qui sont compatibles avec Ollama.

Ollama est une excellente option si vous souhaitez héberger et tester différents modèles open source sans avoir à vous soucier des différentes façons dont chacun des modèles pourrait être configuré, ou de la façon de créer une API pour accéder aux fonctions du modèle, car Ollama s'occupe de tout.

L'API d'Ollama étant compatible avec l'API d'OpenAI, nous pouvons facilement intégrer le modèle d'inférence et créer une application RAG à l'aide de Playground.

Produits requis

1. Elasticsearch 8.17

2. Kibana 8.17

3. Python

Étapes

1. Mise en place du serveur Ollama LLM

2. Création de mappings

3. Indexation des données

4. Poser des questions à l'aide de l'aire de jeu

Mise en place du serveur Ollama LLM

Nous allons mettre en place un serveur LLM pour le connecter à notre instance Playground en utilisant Ollama. Nous en aurons besoin :

• Téléchargez et exécutez Ollama.

• Utilisez ngrok pour accéder à votre serveur web local qui héberge Ollama sur Internet.

Télécharger et lancer Ollama

Pour utiliser Ollama, il faut d'abord le télécharger. Ollama est compatible avec Linux, Windows et macOS. Il vous suffit donc de télécharger la version d'Ollama compatible avec votre système d'exploitation ici. Une fois Ollama installé, nous pouvons choisir un modèle dans cette liste de LLMs supportés. Dans cet exemple, nous utiliserons le modèle llama3.2, un modèle général multilingue. Dans le processus d'installation, vous activerez l'outil de ligne de commande pour Ollama. Une fois qu'il est téléchargé, vous pouvez exécuter la ligne suivante :

Ce qui produira un résultat :

Une fois installé, vous pouvez le tester avec cette commande :

Posons une question :

Une fois le modèle en cours d'exécution, Ollama active une API qui s'exécute par défaut sur le port "11434". Faisons une demande à cette API, en suivant la documentation officielle :

Voici la réponse que nous avons reçue :

Notez que la réponse spécifique pour ce point d'accès est un flux.

Exposer un point de terminaison à l'internet en utilisant ngrok

Comme notre point d'extrémité fonctionne dans un environnement local, il n'est pas possible d'y accéder à partir d'un autre point, comme notre instance Elastic Cloud, via l'internet. ngrok nous permet d'exposer un port en offrant une IP publique. Créez un compte dans ngrok et suivez le guide d'installation officiel.

Une fois l'agent ngrok installé et configuré, nous pouvons exposer le port utilisé par Ollama :

Remarque : l'en-tête --host-header="localhost:11434" garantit que l'en-tête "Host" dans les demandes correspond à "localhost:11434."

L'exécution de cette commande renverra un lien public qui fonctionnera tant que le ngrok et le serveur Ollama fonctionneront localement.

Dans "Forwarding", nous pouvons voir que ngrok a généré une URL. Gardez-le pour plus tard.

Essayons à nouveau de faire une requête HTTP vers le point d'accès, en utilisant maintenant l'URL générée par le moteur de recherche :

La réponse devrait être similaire à la précédente.

Création de mappings

Point final ELSER

Pour cet exemple, nous allons créer un point de terminaison d'inférence à l'aide de l'API d'inférence d'Elasticsearch. En outre, nous utiliserons ELSER pour générer les enchâssements.

Pour cet exemple, imaginons que vous ayez une pharmacie qui vend deux types de médicaments :

• Médicaments nécessitant une ordonnance.

• Médicaments qui ne nécessitent pas d'ordonnance.

Cette information serait incluse dans le champ de description de chaque médicament.

Le LLM doit interpréter ce champ, c'est donc le mappage des données que nous utiliserons :

Le champ text_description stockera le texte brut des descriptions tandis que semantic_field, qui est un champ de type semantic_text, stockera les enchâssements générés par ELSER.

La propriété copy_to copiera le contenu des champs name et text_description dans le champ sémantique afin de générer les embeddings pour ces champs.

Indexation des données

Maintenant, indexons les données à l'aide de l'API _bulk.

Réponse :

Poser des questions à l'aide de l'aire de jeu

Playground est un outil Kibana qui vous permet de créer rapidement un système RAG en utilisant des index Elasticsearch et un fournisseur LLM. Vous pouvez lire cet article pour en savoir plus.

Connecter le programme local d'éducation et de formation tout au long de la vie à l'aire de jeux

Nous devons d'abord créer un connecteur qui utilise l'URL publique que nous venons de créer. Dans Kibana, allez sur Search>Playground et cliquez sur "Connect to an LLM".

Cette action fait apparaître un menu sur le côté gauche de l'interface Kibana. Cliquez ensuite sur "OpenAI".

Nous pouvons maintenant commencer à configurer le connecteur OpenAI.

Allez sur "Connector settings" et pour le fournisseur OpenAI, sélectionnez "Other (OpenAI Compatible Service)":

Configurons maintenant les autres champs. Pour cet exemple, nous nommerons notre modèle "medicines-llm". Dans le champ URL, utilisez celle générée par ngrok (/v1/chat/completions). Dans le champ "Modèle par défaut", sélectionnez "llama3.2". Nous n'utiliserons pas de clé API, vous pouvez donc saisir n'importe quel texte au hasard :

Cliquez sur "Sauvegarder" et ajoutez les médicaments de l'index en cliquant sur "Ajouter des sources de données":

Excellent ! Nous avons maintenant accès à Playground en utilisant le LLM que nous exécutons localement en tant que moteur RAG.

Avant de le tester, ajoutons des instructions plus spécifiques à l'agent et augmentons le nombre de documents envoyés au modèle à 10, afin que la réponse dispose du plus grand nombre possible de documents. Le champ contextuel sera semantic_field, qui comprend le nom et la description des médicaments, grâce à la propriété copy_to.

Posons maintenant la question : Puis-je acheter du Clonazepam sans ordonnance ? et voir ce qui se passe :

Comme prévu, nous avons obtenu la bonne réponse.

Étapes suivantes

L'étape suivante consiste à créer votre propre application ! Playground fournit un code script en Python que vous pouvez exécuter sur votre machine et adapter à vos besoins. Par exemple, en le plaçant derrière un serveur FastAPI pour créer un chatbot d'assurance qualité consommé par votre interface utilisateur.

Vous pouvez trouver ce code en cliquant sur le bouton Voir le code dans la partie supérieure droite de l'aire de jeux :

Et vous utilisez les clés de l'API Endpoints & pour générer la variable d'environnement ES_API_KEY requise dans le code.

Pour cet exemple particulier, le code est le suivant :

Pour que cela fonctionne avec Ollama, vous devez modifier le client OpenAI pour qu'il se connecte au serveur Ollama au lieu du serveur OpenAI. Vous pouvez trouver la liste complète des exemples OpenAI et des points de terminaison compatibles ici.

Il faut également changer le modèle en llama3.2 lors de l'appel de la méthode d'achèvement :

Ajoutons notre question : Puis-je acheter du Clonazepam sans ordonnance ? Pour la requête Elasticsearch :

Et aussi à l'appel d'achèvement avec quelques impressions, pour que nous puissions confirmer que nous envoyons les résultats d'Elasticsearch dans le cadre du contexte de la question :

Exécutons maintenant la commande

pip install -qU elasticsearch openai

python main.py

Vous devriez voir quelque chose comme ceci :

Conclusion

Dans cet article, nous pouvons voir la puissance et la polyvalence d'outils comme Ollama lorsque nous les utilisons avec l'API d'inférence Elasticsearch et Playground.

Après quelques étapes simples, nous avions une application RAG fonctionnelle avec un chat qui utilisait un LLM fonctionnant dans notre propre infrastructure à un coût nul. Cela nous permet également de mieux contrôler les ressources et les informations sensibles, tout en nous donnant accès à une variété de modèles pour différentes tâches.

Voici un diagramme de ce que nous allons configurer dans ce tutoriel :

Configuration de l'inférence locale avec Ollama

Ollama est une excellente façon de tester rapidement un ensemble de modèles open source pour l’inférence locale. C'est un outil très apprécié des développeurs en IA.

Lancer Ollama en natif

Une installation locale sur Mac, Linux ou Windows est le moyen le plus facile d’utiliser les capacités GPU que vous pourriez avoir localement, en particulier pour ceux qui possèdent des puces Apple de la série M. Après avoir installé Ollama, vous pouvez télécharger et exécuter Deepseek R1 avec la commande ci-dessous.

Vous pourriez avoir besoin d’ajuster la taille des paramètres pour qu’elle corresponde à votre matériel. Vous trouverez les tailles disponibles ici.

Il est possible de discuter avec le modèle dans le terminal, mais il continue de fonctionner même lorsque vous quittez la commande avec CTRL+d ou que vous tapez « /bye ». Pour voir que le modèle continue de fonctionner, entrez :

Exécution d'Ollama dans un conteneur

Sinon, la façon la plus rapide de faire fonctionner Ollama est d’utiliser un moteur de conteneurs comme Docker. Si l’utilisation du GPU de votre machine locale n’est pas toujours simple, selon l’environnement, la mise en place d'une configuration de test rapide est simple tant que votre conteneur a assez de RAM et d’espace de stockage pour les modèles de plusieurs Go.

Pour faire fonctionner Ollama dans Docker, il suffit d'exécuter :

Un répertoire « ollama » sera créé dans le dossier actuel, puis monté à l’intérieur du conteneur pour y conserver la configuration d’Ollama et les modèles. En fonction du nombre de paramètres employés, leur taille peut aller de quelques Go à plusieurs dizaines de Go, donc veillez à choisir un volume disposant d’un espace libre suffisant.

Remarque : si votre machine est équipée d'un GPU Nvidia, veillez à installer le kit d’outils de conteneur Nvidia et à ajouter « --gpus=all » à la commande « docker run » ci-dessus.

Dès que le conteneur Ollama fonctionne sur votre machine, vous pouvez télécharger un modèle comme deepseek-r1 en utilisant :

À l'instar de l'approche bare metal, il est possible que vous souhaitiez ajuster la taille des paramètres pour qu'elle corresponde à votre matériel. Les tailles disponibles sont indiquées sur le site https://ollama.com/library/deepseek-r1.

Une fois que l'extraction du modèle est terminée, il vous suffit de taper « /bye » pour quitter le prompt. Pour vérifier que le modèle est toujours en cours d’exécution :

Tester notre inférence locale avec une commande curl

Pour tester l'inférence locale avec curl, vous pouvez exécuter la commande suivante. Nous avons recours à stream:false pour faciliter la lecture de la réponse narrative au format JSON :

Test d’Ollama compatible OpenAI et d’une invite de RAG

Pour plus de commodité, Ollama offre également un point de terminaison REST qui imite l'interface d’OpenAI, ce qui le rend compatible avec un grand nombre d'outils, notamment Kibana.

Le test de cette invite plus complexe produit un contenu qui comporte une partie dans laquelle le modèle a été entraîné pour trouver la solution au problème.

Connexion d'Ollama à Kibana

Une excellente façon d’utiliser Elasticsearch est le script de développement « start-local ».

Veillez à ce que votre Kibana et votre Elasticsearch soient en mesure d'atteindre votre Ollama sur le réseau. Si vous avez un environnement Elastic en conteneur local, vous devrez peut-être remplacer « localhost » par « host.docker.internal ». ou « host.conteneurs.internal » afin d’avoir un chemin réseau jusqu'à la machine hôte.

Dans Kibana, accédez à Stack Management > Alertes et informations > Connecteurs.

Ce qu’il faut faire si cette alerte de configuration courante s'affiche

Vous devrez vous assurer que xpack.encryptedSavedObjects.encryptionKey est correctement défini. C'est une erreur courante lors de l'exécution d'une installation locale de Kibana sous Docker, c'est pourquoi je vais énumérer les étapes à suivre dans la syntaxe de Docker pour la corriger.

Pour que les modifications soient conservées à l’arrêt du conteneur, il faut que le répertoire kibana/config soit persistant. Mes volumes de conteneurs Kibana ressemblent à ceci dans docker-compose.yml :

Vous pouvez à présent créer le keystore et y attribuer une valeur afin que les clés des connecteurs ne soient plus stockées en clair.

Afin que les modifications soient appliquées, redémarrez l'ensemble de votre cluster.

Création du connecteur

Depuis l’écran de configuration du connecteur (dans Kibana, accédez à Stack Management > Alertes et informations > Connecteurs), créez un connecteur et sélectionnez le type « OpenAI ».

Configurez le connecteur avec les paramètres suivants

• Nom du connecteur : Deepseek (Ollama)

• Sélectionnez un fournisseur OpenAI : autre (service compatible OpenAI)

• URL : http://localhost:11434/v1/chat/completions

  • Modifiez pour indiquer le bon chemin d'accès à votre ollama. Pensez à remplacer par host.docker.internal ou son équivalent si vous appelez depuis un conteneur.

• Modèle par défaut : deepseek-r1:7b

• Clé API : inventez quelque chose, une entrée est nécessaire mais la valeur n'a pas d'importance

Notez que le test d'un connecteur personnalisé à Ollama dans la configuration du connecteur est actuellement défectueux dans la version 8.17, mais a été corrigé dans la future version 8.18 de Kibana.

Notre connecteur ressemble à ceci :

Intégration des données vectorielles dans Elasticsearch

Si vous connaissez déjà Playground et que vous y avez des données, vous pouvez passer à l'étape Playground ci-dessous. En revanche, si vous avez besoin de données de test rapides, assurez-vous que nos API d'inférence sont configurées. Depuis la version 8.17, les allocations de machine learning sont dynamiques. Pour télécharger et activer le vecteur dense multilingue e5, il suffit d’exécuter la commande suivante dans les Outils de développement de Kibana.

Si ce n'est pas déjà fait, cette opération lancera le téléchargement du modèle e5 depuis les dépôts de modèles d'Elastic.

Chargeons à présent un livre du domaine public comme contexte pour notre RAG. Voici où télécharger « Alice au pays des merveilles » depuis le Projet Gutenberg : lien. Enregistrez-le sous la forme d’un fichier .txt.

Accédez à Elasticsearch > Accueil > Télécharger un fichier

Sélectionnez ou glissez-déposez votre fichier texte, puis cliquez sur le bouton « Importer ».

Sur l'écran « Importer des données », sélectionnez l'onglet « Avancé », puis définissez le nom de l'index sur « book_alice ».

Sélectionnez l’option « Ajouter un champ supplémentaire », elle se trouve juste en dessous de « Champs créés automatiquement ». Sélectionnez « Ajouter un champ de texte sémantique » et changez le point de terminaison d’inférence en « .multilingual-e5-small-elasticsearch ». Sélectionnez Ajouter, puis Importer.

Une fois le chargement et l’inférence terminés, nous pouvons nous rendre sur Playground.

Test de RAG dans Playground

Accédez à Elasticsearch > Playground dans Kibana.

Sur l’écran du Playground, vous devriez voir une coche verte et le message « LLM Connected » (LLM connecté) qui indique qu’il existe un connecteur. Il s'agit du connecteur Ollama que nous venons de créer ci-dessus. Un guide plus complet pour Playground est accessible ici.

Cliquez sur le bouton bleu « Ajouter des sources de données » et sélectionnez l'index book_alice que nous avions fait, ou un autre index que vous avez préalablement configuré qui utilise les API d'inférence pour les plongements.

Deepseek est un modèle de chaîne de pensée présentant de fortes caractéristiques d'alignement. C'est à la fois un avantage et un inconvénient du point de vue de la RAG. L'entraînement de type « chaîne de pensée » peut aider Deepseek à rationaliser des énoncés qui semblent contradictoires dans les citations, mais le fort alignement avec les connaissances acquises lors de l'entraînement peut lui faire préférer sa propre version des faits plutôt que notre contexte. Bien qu'il parte d'une bonne intention, ce fort alignement rend les LLM difficiles à guider quand on aborde des sujets où nos connaissances privées sont en contradiction avec les données d'entraînement, ou n'y sont pas bien représentées.

Dans la configuration de notre Playground, nous avons saisi l'invite système « Vous êtes un assistant pour les tâches de questions-réponses en utilisant les passages pertinents du livre Alice au pays des merveilles » et accepté les autres paramètres par défaut.

À la question « Qui était au goûter ? » nous obtenons la réponse : « Réponse : le lièvre de mars, le chapelier et le loir étaient au goûter. [Citation : positions 1 et 2] », ce qui est exact.

Nous pouvons voir d'après les tags que Deepseek a clairement réfléchi au contenu des citations pour répondre aux questions.

Test des limites d'alignement

Pour tester Deepseek, créons un scénario qui soit un défi intellectuel. Nous allons créer un index de théories du complot que les données d'entraînement de Deepseek connaissent et qui ne sont pas vraies.

Dans les outils de développement de Kibana, créons l'index et les données suivants :

Ces théories du complot seront les données de base pour notre LLM. Même en utilisant une invite système agressive, Deepseek n’accepte pas notre version des faits. Si nos données privées étaient plus fiables, mieux ancrées ou mieux alignées sur les besoins de notre organisation, ce scénario ne serait pas acceptable

À la question test « Les oiseaux sont-ils réels ? » (explication : know your meme), nous obtenons la réponse suivante : « Dans le contexte fourni, les oiseaux ne sont pas considérés comme réels, mais en réalité, ce sont des animaux réels. » [Contexte : position 1]. Ce test prouve que DeepSeek R1 est puissant, même avec le niveau de paramètre 7B… mais ce n'est peut-être pas le meilleur choix pour la RAG, selon notre jeu de données.

Quels sont les enseignements à retenir ?

En résumé :

• L'exécution de modèles en local à l'aide d'outils comme Ollama est une excellente option pour avoir un aperçu de leur comportement.

• Le Deepseek R1 est un modèle de raisonnement qui comporte des avantages et des inconvénients pour les cas d'utilisation comme la RAG.

• Playground est en mesure de se connecter à des infrastructures d'hébergement d'inférence comme Ollama par le biais d'une API REST de type OpenAI, qui devient de facto un standard en cette période de lancement de l'hébergement de l'IA.

Globalement, nous sommes impressionnés par les progrès de la RAG locale, « air gapped ». Les outils d’Elasticsearch, de Kibana et des modèles de poids ouverts disponibles ont considérablement progressé depuis que nous avons écrit pour la première fois sur la recherche IA axée sur la confidentialité en 2023.

La recherche par facettes est un outil puissant dans les plateformes de commerce électronique. Il permet d'organiser et d'affiner les résultats de la recherche en fonction des caractéristiques des éléments affichés. Souvent confondues avec les filtres, les facettes fonctionnent différemment. Les filtres sont des attributs fixes, définis par des informations toujours présentes dans l'index, telles que la catégorie ou le format d'un produit. Les facettes, quant à elles, sont dynamiques et générées à partir des résultats renvoyés par la recherche exécutée.

Imaginez un catalogue de vêtements : des champs tels que "category" (par exemple, t-shirts, pantalons) ou "gender" (par exemple, homme, femme) sont des filtres qui permettent d'affiner les résultats. Les facettes, quant à elles, reflètent des caractéristiques spécifiques des produits apparaissant dans les résultats, telles que les couleurs communes, les tailles disponibles ou les matériaux. Cela permet une expérience de recherche plus adaptable et contextuelle.

Voici une image dans laquelle nous interagissons avec une facette et pouvons voir les résultats de la recherche filtrés par celle-ci.

Comment l'IA peut améliorer la génération de facettes

L'intelligence artificielle est souvent associée à la recherche sémantique et aux enchâssements, mais qu'en est-il des facettes ? Comment l'IA peut-elle être exploitée pour rendre les facettes plus utiles et plus adaptées au contexte de chaque recherche ?

Une possibilité intéressante consiste à utiliser l'IA pour créer de nouvelles catégorisations qui vont au-delà des classifications traditionnelles de l'index. En analysant les caractéristiques spécifiques du contenu, ces nouvelles catégories peuvent fournir une contextualisation plus riche et plus précise, rendant les facettes plus pertinentes et mieux adaptées aux besoins des utilisateurs. Cela permet d'affiner les résultats de manière plus significative par rapport aux catégories de documents originales.

Comment l'IA peut affiner les classifications de films pour de meilleures recherches

Analysons les films suivants, tous classés actuellement dans le genre dramatique :

• Requiem for a Dream Résumé : Les utopies induites par la drogue de quatre habitants de Coney Island sont brisées lorsque leurs addictions deviennent profondes.

• American Beauty CV : Un père de famille de banlieue, sexuellement frustré, traverse une crise de la quarantaine après s'être entiché de la meilleure amie de sa fille.

• Good Will Hunting CV : Will Hunting, concierge au M.I.T., est doué pour les mathématiques, mais a besoin de l'aide d'un psychologue pour trouver un sens à sa vie.

Cette classification des genres ne rend pas compte des différences subtiles ou des contextes uniques de chaque film. En exploitant l'IA pour analyser les synopsis et les thèmes centraux, nous pouvons créer de nouvelles catégories qui reflètent mieux le véritable contexte de chaque film. Par exemple :

• Requiem for a Dream - Nouvelle catégorie : "Addiction et dépendance"

• American Beauty - Nouvelle catégorie : "Crise de la quarantaine"

• Good Will Hunting - Nouvelle catégorie : "Lutte intellectuelle"

Ces nouvelles catégories rendent les recherches beaucoup plus précises tout en offrant aux utilisateurs des filtres plus significatifs pour affiner leurs résultats. Cette approche est particulièrement efficace lorsque les catégories d'origine sont trop génériques, ce qui permet aux utilisateurs de trouver plus facilement ce qu'ils recherchent.

Créer de nouvelles catégories avec GPT-4 : exemple de recherche à facettes

Dans cet exemple, nous montrerons comment un modèle d'IA peut être utilisé pour créer de nouvelles catégories de films qui sont plus précises et alignées sur le contexte de chaque œuvre. Pour démontrer ce processus, nous utiliserons le pipeline de simulation Elastic avec le service d'inférence OpenAI. Un pipeline comprenant plusieurs processeurs sera créé, dont le processeur de script, qui sera chargé de créer l'invite à exécuter dans le processeur d'inférence, capable de déterminer les nouvelles catégories. Les autres processeurs seront utilisés pour manipuler les données et les champs auxiliaires générés pendant l'exécution du pipeline. Il convient de mentionner que cette logique peut également être appliquée à d'autres outils ou modèles similaires.

Tout d'abord, nous devons créer le point de terminaison de l'inférence, où nous définissons le service comme OpenAI, le jeton requis pour accéder au service et le modèle. Dans cet exemple, j'utilise gpt-4o-mini. Pour plus de détails sur le service d'inférence OpenAI, cliquez ici.

Le point final étant créé, nous sommes maintenant prêts à l'utiliser pour créer les nouvelles catégories. Vous trouverez ci-dessous un pipeline qui prend en charge l'ensemble du processus de manipulation des données des documents et de génération des messages. Je vais expliquer en détail la fonction de chaque processeur.

Le premier processeur sera chargé de construire l'invite. Il est très important de détailler clairement les instructions afin que l'IA puisse analyser et identifier correctement les sujets. Dans ce questionnaire, je demande 2 sujets basés sur l'analyse du titre, de la description et des genres des films.

Le pipeline suivant est le pipeline d'inférence, il recevra l'invite et l'enverra à notre point de terminaison generate_topics_ia. La réponse générée par le modèle sera stockée dans le champ résultat.

Ensuite, nous avons trois processeurs utilisés pour manipuler la réponse et la placer dans le champ des sujets, en plus de supprimer les champs temporaires que j'ai créés.

En exécutant ce pipeline, nous obtiendrons les résultats ci-dessous :

Il est à noter que nous avons de nouvelles catégories qui sont plus en rapport avec le contexte des films, même si certains d'entre eux sont initialement du même genre.

Nous pouvons maintenant utiliser ces nouvelles catégories et les indexer avec le document. Ainsi, lors de la génération des facettes, en plus de la catégorie principale, nous avons des sous-catégories plus spécifiques qui sont alignées sur le contexte des films.

En outre, il est possible de vectoriser ces nouvelles catégories et de les utiliser dans des recherches vectorielles. Cela signifie que les nouvelles catégories ne servent pas seulement de filtres, mais qu'elles peuvent également être utilisées pour calculer les similitudes sémantiques avec les termes de recherche, ce qui augmente encore la pertinence des résultats présentés.

Pipeline complet :

Conclusion

L'utilisation de l'IA pour améliorer les facettes peut transformer l'expérience de recherche en rendant les résultats plus spécifiques et contextuels. Contrairement aux catégories fixes, qui sont souvent larges, les catégories générées par l'IA peuvent mieux refléter le contexte. Par exemple, lors de la reclassification des films, nous pouvons saisir le contexte qui échappe aux catégories primaires, ce qui permet d'obtenir des regroupements beaucoup plus pertinents.

Ces nouvelles catégories peuvent être ajoutées à l'index non seulement pour améliorer les facettes, mais aussi pour permettre des recherches vectorielles. Il en résulte une expérience de recherche plus efficace, avec des filtres mieux adaptés au contexte.

Références

https://www.elastic.co/guide/en/elasticsearch/reference/current/infer-service-openai.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/simulate-pipeline-api.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/script-processor.html

Le connecteur Semantic Kernel Elasticsearch Vector Store, prêt à l'emploi, prend en charge les abstractions du Semantic Kernel vector store, ce qui permet aux développeurs de brancher très facilement Elasticsearch en tant que magasin vectoriel lors de la création d'agents d'intelligence artificielle.

Elasticsearch est solidement ancré dans la communauté des logiciels libres et a récemment adopté la licence AGPL. Associés au noyau sémantique Microsoft open-source, ces outils offrent une solution puissante, prête pour l'entreprise. Vous pouvez commencer localement en démarrant Elasticsearch en quelques minutes en exécutant cette commande curl -fsSL https://elastic.co/start-local | sh (voir start-local pour plus de détails) et évoluer vers des versions hébergées dans le nuage ou auto-hébergées tout en mettant en production vos agents d'IA.

Dans ce blog, nous verrons comment utiliser le connecteur Semantic Kernel Elasticsearch Vector Store lors de l'utilisation de Semantic Kernel. Une version Python du connecteur sera disponible à l'avenir.

Scénario de haut niveau : Construire une application RAG avec Semantic Kernel & Elasticsearch

Dans la section suivante, nous présentons un exemple. À un niveau élevé, nous construisons une application RAG (Retrieval Augmented Generation) qui prend la question d'un utilisateur en entrée et renvoie une réponse. Nous utiliserons Azure OpenAI(un LLM local peut également être utilisé) comme LLM, Elasticsearch comme magasin de vecteurs et Semantic Kernel (.net) comme cadre pour relier tous les composants ensemble.

Si vous n'êtes pas familier avec les architectures RAG, vous pouvez vous familiariser rapidement avec cet article : https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

La réponse est générée par le LLM qui est alimenté par le contexte, pertinent pour la question, récupéré à partir du vectorstore Elasticsearch. La réponse inclut également la source qui a été utilisée comme contexte par le LLM.

Exemple de GCR

Dans cet exemple spécifique, nous créons une application qui permet aux utilisateurs de poser des questions sur les hôtels stockés dans une base de données interne. L'utilisateur peut par exemple rechercher un hôtel spécifique, en fonction de différents critères, ou demander une liste d'hôtels.

Pour la base de données d'exemple, nous avons généré une liste d'hôtels contenant 100 entrées. La taille de l'échantillon est volontairement réduite pour vous permettre d'essayer la démo du connecteur aussi facilement que possible. Dans une application réelle, le connecteur Elasticsearch montrerait ses avantages par rapport à d'autres options, telles que l'implémentation du magasin vectoriel `InMemory`, en particulier lorsque l'on travaille avec de très grandes quantités de données.

L'application de démonstration complète se trouve dans le référentiel du connecteur Elasticsearch vector store.

Commençons par ajouter les paquets NuGet et les directives nécessaires à notre projet :

Nous pouvons maintenant créer notre modèle de données et le doter d'attributs spécifiques au Semantic Kernel pour définir le schéma du modèle de stockage et quelques indications pour la recherche textuelle :

Les attributs du schéma du modèle de stockage (`VectorStore*`) sont les plus pertinents pour l'utilisation réelle du connecteur Elasticsearch Vector Store, à savoir :

• VectorStoreRecordKey pour marquer une propriété d'une classe d'enregistrement comme étant la clé sous laquelle l'enregistrement est stocké dans un magasin vectoriel.

• VectorStoreRecordData pour marquer une propriété d'une classe d'enregistrement comme "data".

• VectorStoreRecordVector pour marquer une propriété d'une classe d'enregistrement en tant que vecteur.

Tous ces attributs acceptent divers paramètres facultatifs qui peuvent être utilisés pour personnaliser davantage le modèle de stockage. Dans le cas de VectorStoreRecordKey , par exemple, il est possible de spécifier une fonction de distance différente ou un type d'indice différent.

Les attributs de recherche de texte (TextSearch*) seront importants dans la dernière étape de cet exemple. Nous y reviendrons plus tard.

Dans l'étape suivante, nous initialisons le moteur du noyau sémantique et obtenons des références aux services de base. Dans une application réelle, l' injection de dépendances devrait être utilisée au lieu d'accéder directement à la collection de services. La même chose s'applique à la configuration et aux secrets codés en dur, qui doivent être lus à l'aide d'un fournisseur de configuration:

Le service vectorStoreCollection peut maintenant être utilisé pour créer la collection et ingérer quelques enregistrements de démonstration :

Cela montre comment Semantic Kernel réduit l'utilisation d'un magasin de vecteurs, avec toute sa complexité, à quelques simples appels de méthodes.

Sous le capot, un nouvel index est créé dans Elasticsearch et tous les mappages de propriétés nécessaires sont créés. Notre ensemble de données est ensuite intégré de manière totalement transparente dans le modèle de stockage et finalement stocké dans l'index. Voici à quoi ressemblent les mappings dans Elasticsearch.

Le site embeddings.GenerateEmbeddingsAsync() appelle de manière transparente le service Azure AI Embeddings Generation configuré.

La dernière étape de cette démonstration est encore plus magique.

Avec un seul appel à InvokePromptAsync, toutes les opérations suivantes sont effectuées lorsque l'utilisateur pose une question sur les données :

1. L'intégration de la question de l'utilisateur est générée.

2. Le magasin de vecteurs est parcouru à la recherche d'entrées pertinentes

3. Les résultats de la requête sont insérés dans un modèle d'invite

4. La requête proprement dite, sous la forme de l'invite finale, est envoyée au service d'achèvement de chat de l'IA.

Vous vous souvenez des attributs TextSearch* que nous avons définis précédemment dans notre modèle de données ? Ces attributs nous permettent d'utiliser les espaces réservés correspondants dans notre modèle d'invite, qui sont automatiquement remplis avec les informations provenant de nos entrées dans le magasin de vecteurs.

La réponse finale à notre question "Veuillez m'indiquer tous les hôtels qui disposent d'un bar sur le toit." est la suivante :

La réponse se réfère correctement à l'entrée suivante dans notre fichier hotels.csv

Cet exemple montre très bien comment l'utilisation de Microsoft Semantic Kernel permet une réduction significative de la complexité grâce à ses abstractions bien pensées, tout en permettant un très haut niveau de flexibilité. En changeant une seule ligne de code, par exemple, le magasin de vecteurs ou les services d'intelligence artificielle utilisés peuvent être remplacés sans qu'il soit nécessaire de remanier une autre partie du code.

Dans le même temps, le cadre fournit un ensemble considérable de fonctionnalités de haut niveau, telles que la fonction `InvokePrompt`, ou le système de plugin de modèle ou de recherche.

L'application de démonstration complète se trouve dans le référentiel du connecteur Elasticsearch vector store.

Quelles sont les autres possibilités offertes par Elasticsearch ?

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

• Classement sémantique dans Elasticsearch à l'aide d'extracteurs

• Techniques avancées de RAG partie 1 : Traitement des données

• Techniques avancées de RAG, partie 2 : Requêtes et tests

• Construire RAG avec Llama 3 open-source et Elastic

• Un tutoriel sur la construction d'un agent local utilisant LangGraph, LLaMA3 et Elasticsearch vector store à partir de zéro

Elasticsearch & Semantic Kernel : Quelle est la prochaine étape ?

• Nous avons montré comment le magasin vectoriel Elasticsearch peut être facilement intégré au Semantic Kernel lors de la construction d'applications GenAI en .NET. Restez à l'écoute pour une prochaine intégration de Python.

• Comme Semantic Kernel construit des abstractions pour des fonctions de recherche avancées telles que la recherche hybride, la connexion Elasticsearch permettra aux développeurs .NET de les mettre en œuvre facilement tout en utilisant Semantic Kernel.

• Discutez avec les LLM en mettant en place un ChatLanguageModel et un ChatMemory

• Conserver l'historique du chat en mémoire pour se rappeler le contexte d'une discussion précédente avec un LLM

Cet article de blog traite de la manière de procéder :

• Création d'encastrements vectoriels à partir d'exemples de textes

• Stocker les embeddings vectoriels dans le magasin d'embedding d'Elasticsearch

• Recherche de vecteurs similaires

Créer des embeddings

Pour créer des embeddings, nous devons définir un EmbeddingModel à utiliser. Par exemple, nous pouvons utiliser le même modèle de mistral que celui utilisé dans le billet précédent. Il s'agissait de courir avec l'ollama :

Un modèle est capable de générer des vecteurs à partir d'un texte. Nous pouvons ici vérifier le nombre de dimensions générées par le modèle :

Pour générer des vecteurs à partir d'un texte, nous pouvons utiliser :

Si nous voulons également fournir des métadonnées pour nous permettre de filtrer des éléments tels que le texte, le prix, la date de sortie ou autre, nous pouvons utiliser Metadata.from(). Par exemple, nous ajoutons ici le nom du jeu comme champ de métadonnées :

Si vous souhaitez exécuter ce code, veuillez consulter la classe Step5EmbedddingsTest.java.

Ajouter Elasticsearch pour stocker nos vecteurs

LangChain4j fournit un magasin d'intégration en mémoire. Cette fonction est utile pour exécuter des tests simples :

Mais il est évident que cela ne pourrait pas fonctionner avec un ensemble de données beaucoup plus important car ce datastore stocke tout en mémoire et nous ne disposons pas d'une mémoire infinie sur nos serveurs. Ainsi, nous pourrions plutôt stocker nos enregistrements dans Elasticsearch, qui est par définition "élastique" et peut évoluer avec vos données. Pour cela, ajoutons Elasticsearch à notre projet :

Comme vous l'avez remarqué, nous avons également ajouté le module Elasticsearch TestContainers au projet, afin de pouvoir démarrer une instance Elasticsearch à partir de nos tests :

Pour utiliser Elasticsearch comme magasin d'intégration, il suffit de "" passer du datastore LangChain4j en mémoire au datastore Elasticsearch :

Cela permettra de stocker vos vecteurs dans Elasticsearch dans un index default. Vous pouvez également changer le nom de l'index en quelque chose de plus significatif :

Si vous souhaitez exécuter ce code, veuillez consulter la classe Step6ElasticsearchEmbedddingsTest.java.

Recherche de vecteurs similaires

Pour rechercher des vecteurs similaires, nous devons d'abord transformer notre question en une représentation vectorielle en utilisant le même modèle que celui utilisé précédemment. Nous l'avons déjà fait, il n'est donc pas difficile de le faire à nouveau. Notez que nous n'avons pas besoin des métadonnées dans ce cas :

Nous pouvons construire une requête de recherche avec cette représentation de notre question et demander au magasin d'intégration de trouver les premiers vecteurs :

Nous pouvons maintenant itérer sur les résultats et imprimer certaines informations, comme le nom du jeu qui provient des métadonnées et le score :

Comme on pouvait s'y attendre, cela nous donne "Out Run" comme premier résultat :

Si vous souhaitez exécuter ce code, consultez la classe Step7SearchForVectorsTest.java.

L'envers du décor

La configuration par défaut du magasin Elasticsearch Embedding utilise la requête kNN approximative en arrière-plan.

Mais cela peut être modifié en fournissant une autre configuration (ElasticsearchConfigurationScript) que celle par défaut (ElasticsearchConfigurationKnn) au magasin d'intégration :

L'implémentation de ElasticsearchConfigurationScript exécute en coulisse une requête script_score à l'aide d'une fonction cosineSimilarity.

En principe, lors d'un appel :

Il s'agit maintenant d'un appel :

Dans ce cas, le résultat ne change pas en termes d'ordre "" mais le score est simplement ajusté parce que l'appel cosineSimilarity n'utilise pas d'approximation mais calcule le cosinus pour chacun des vecteurs correspondants :

Si vous souhaitez exécuter ce code, consultez la classe Step7SearchForVectorsTest.java.

Conclusion

Nous avons vu comment vous pouvez facilement générer des embeddings à partir de votre texte et comment vous pouvez stocker et rechercher les voisins les plus proches dans Elasticsearch en utilisant deux approches différentes :

• Utilisation de la requête approximative et rapide knn avec l'option par défaut ElasticsearchConfigurationKnn

• Utilisation de la requête exacte mais plus lente script_score avec l'option ElasticsearchConfigurationScript

La prochaine étape consistera à créer une application RAG complète, sur la base de ce que nous avons appris ici.

LangChain4j fournit une méthode standard pour :

• créer des embeddings (vecteurs) à partir d'un contenu donné, par exemple un texte

• stocker les embeddings dans un magasin d'embeddings

• recherche de vecteurs similaires dans le magasin d'intégration

• discuter avec les LLM

• utiliser une mémoire de chat pour se souvenir du contexte d'une discussion avec un LLM

Cette liste n'est pas exhaustive et la communauté LangChain4j est toujours en train d'implémenter de nouvelles fonctionnalités.

Ce billet couvrira les premières parties principales du cadre.

Ajouter LangChain4j OpenAI à notre projet

Comme dans tous les projets Java, c'est juste une question de dépendances. Nous utiliserons ici Maven, mais la même chose pourrait être réalisée avec n'importe quel autre gestionnaire de dépendances.

Comme première étape du projet que nous voulons construire ici, nous utiliserons OpenAI, il nous suffit donc d'ajouter l'artefact langchain4j-open-ai:

Pour le reste du code, nous utiliserons soit notre propre clé API, que vous pouvez obtenir en créant un compte auprès d'OpenAI, soit celle fournie par le projet LangChain4j à des fins de démonstration uniquement :

Nous pouvons maintenant créer une instance de notre ChatLanguageModel :

Enfin, nous pouvons poser une question simple et obtenir une réponse :

La réponse donnée pourrait être quelque chose comme :

Si vous souhaitez exécuter ce code, consultez la classe Step1AiChatTest.java.

Fournir plus de contexte avec langchain4j

Ajoutons l'artefact langchain4j:

Celui-ci fournit un ensemble d'outils qui peuvent nous aider à construire une intégration LLM plus avancée pour construire notre assistant. Ici, nous allons simplement créer une interface Assistant qui fournit la méthode chat qui appellera automatiquement la méthode ChatLanguageModel que nous avons définie plus tôt :

Il suffit de demander à la classe LangChain4j AiServices de construire une instance pour nous :

Puis appeler la méthode chat(String):

Le comportement est le même qu'auparavant. Pourquoi avons-nous donc modifié le code ? Tout d'abord, c'est plus élégant, mais en plus, vous pouvez maintenant donner des instructions au LLM à l'aide de simples annotations :

C'est maintenant chose faite :

Si vous souhaitez exécuter ce code, consultez la classe Step2AssistantTest.java.

Passer à un autre LLM : langchain4j-ollama

Nous pouvons utiliser le grand projet Ollama. Il est utile d'exécuter un LLM localement sur votre machine.

Ajoutons l'artefact langchain4j-ollama:

Comme nous exécutons l'exemple de code à l'aide de tests, ajoutons des conteneurs de test à notre projet :

Nous pouvons maintenant démarrer/arrêter les conteneurs Docker :

Nous "devons simplement" modifier l'objet model pour qu'il devienne un OllamaChatModel au lieu du OpenAiChatModel que nous utilisions précédemment :

Notez que l'extraction de l'image avec son modèle peut prendre un certain temps, mais au bout d'un moment, vous pouvez obtenir la réponse :

Meilleure mémoire

Si nous posons plusieurs questions, par défaut le système ne se souviendra pas des questions et réponses précédentes. Ainsi, si nous posons la question suivante : "Quand est-il né ?", notre application répondra :

Ce qui est absurde. Nous devrions plutôt utiliser la mémoire de chat :

En posant les mêmes questions maintenant, on obtient une réponse significative :

Conclusion

Dans le prochain article, nous découvrirons comment poser des questions à notre ensemble de données privé en utilisant Elasticsearch comme magasin d'intégration. Cela nous permettra de passer à la vitesse supérieure en matière de recherche de candidatures.

Bienvenue dans la deuxième partie de notre article sur les techniques avancées de RAG ! Dans la première partie de cette série, nous avons mis en place, discuté et implémenté les composants de traitement des données du pipeline RAG avancé :

Dans cette partie, nous allons procéder à l'interrogation et au test de notre mise en œuvre. Allons droit au but !

Table des matières

• Recherche et récupération, génération de réponses

  • Enrichir les requêtes avec des synonymes

  • HyDE (Hypothetical Document Embedding)

  • Recherche hybride

• Expériences

  • Synthèse des résultats

  • Test 1 : Qui vérifie Elastic ?

    • AdvancedRAG

    • SimpleRAG

  • Test 2 : recettes totales en 2023

    • AdvancedRAG

    • SimpleRAG

  • Test 3 : De quel produit la croissance dépend-elle principalement ? Combien ?

    • AdvancedRAG

    • SimpleRAG

  • Test 4 : Décrire le régime d'avantages sociaux des salariés

    • AdvancedRAG

    • SimpleRAG

  • Test 5 : Quelles sont les entreprises acquises par Elastic ?

    • AdvancedRAG

    • SimpleRAG

• Conclusion

• Annexe

  • Prompts

    • Question du RAG - invite à répondre

    • Générateur de requêtes élastiques

    • Questions potentielles : invite à la création d'un générateur

    • Invite du générateur HyDE

  • Exemple de requête de recherche hybride

Recherche et récupération, génération de réponses

Posons notre première question, idéalement une information trouvée principalement dans le rapport annuel. Que diriez-vous de.. :

Appliquons maintenant quelques-unes de nos techniques pour améliorer la requête.

Enrichir les requêtes avec des synonymes

Tout d'abord, améliorons la diversité de la formulation de la requête et transformons-la en une forme qui peut être facilement traitée dans une requête Elasticsearch. Nous ferons appel à GPT-4o pour convertir la requête en une liste de clauses OR. Écrivons ce message :

Appliqué à notre requête, GPT-4o génère des synonymes de la requête de base et du vocabulaire connexe.

Dans la classe ESQueryMaker, j'ai défini une fonction pour diviser la requête :

Son rôle est de prendre cette chaîne de clauses OR et de les diviser en une liste de termes, ce qui nous permet d'effectuer une correspondance multiple sur les champs clés du document :

Finalement, nous avons abouti à cette requête :

Cela permet de couvrir beaucoup plus de bases que la requête initiale, réduisant ainsi le risque de manquer un résultat de recherche en raison de l'oubli d'un synonyme. Mais nous pouvons faire plus.

Haut de page

HyDE (Hypothetical Document Embedding)

Faisons à nouveau appel à GPT-4o, cette fois pour mettre en œuvre HyDE.

Le principe de base de HyDE est de générer un document hypothétique - le type de document qui contiendrait probablement la réponse à la requête initiale. Le caractère factuel ou l'exactitude du document n'est pas en cause. En gardant cela à l'esprit, rédigeons l'invite suivante :

La recherche vectorielle s'appuyant généralement sur la similarité vectorielle cosinusoïdale, HyDE part du principe que l'on peut obtenir de meilleurs résultats en faisant correspondre des documents à des documents plutôt que des requêtes à des documents.

Ce qui nous importe, c'est la structure, le flux et la terminologie. Ce n'est pas tant le cas pour les faits. Le GPT-4o produit un document HyDE comme celui-ci :

Il semble assez crédible, comme le candidat idéal pour les types de documents que nous aimerions indexer. Nous allons l'intégrer et l'utiliser pour la recherche hybride.

Haut de page

Recherche hybride

C'est le cœur de notre logique de recherche. Notre composante de recherche lexicale sera les chaînes de clauses OR générées. Notre composante vectorielle dense sera le document HyDE intégré (également appelé vecteur de recherche). Nous utilisons KNN pour identifier efficacement les documents candidats les plus proches de notre vecteur de recherche. Nous appelons notre composant de recherche lexicale Scoring with TF-IDF and BM25 par défaut. Enfin, les scores des vecteurs lexicaux et denses seront combinés en utilisant le ratio 30/70 recommandé par Wang et al.

Enfin, nous pouvons reconstituer une fonction RAG. Notre RAG, de la question à la réponse, suivra ce flux :

1. Convertir la requête en clauses OR.

2. Générer un document HyDE et l'intégrer.

3. Transmettre ces deux informations à la recherche hybride.

4. Récupérer les n premiers résultats, les inverser de façon à ce que le score le plus pertinent soit le "plus récent" dans la mémoire contextuelle du LLM (Reverse Packing) Reverse Packing Exemple : Requête : "Techniques d'optimisation des requêtes Elasticsearch" Documents récupérés (ordonnés par pertinence) : Ordre inversé pour le contexte LLM : En inversant l'ordre, l'information la plus pertinente (1) apparaît en dernier dans le contexte, recevant potentiellement plus d'attention de la part du LLM pendant la génération de la réponse.

   1. "Utilisez les requêtes bool pour combiner efficacement plusieurs critères de recherche."

   2. "Mettre en œuvre des stratégies de mise en cache pour améliorer les temps de réponse des requêtes."

   3. "Optimiser les mappages d'index pour accélérer les performances de recherche."

   4. "Optimiser les mappages d'index pour accélérer les performances de recherche."

   5. "Mettre en œuvre des stratégies de mise en cache pour améliorer les temps de réponse des requêtes."

   6. "Utilisez les requêtes bool pour combiner efficacement plusieurs critères de recherche."

5. Transmettre le contexte au LLM pour qu'il le génère.

Exécutons notre requête et obtenons notre réponse :

C'est une bonne chose. C'est exact.

Haut de page

Expériences

Il faut maintenant répondre à une question importante. Qu'avons-nous obtenu en investissant tant d'efforts et de complexité supplémentaire dans ces mises en œuvre ?

Faisons une petite comparaison. Le pipeline RAG que nous avons mis en œuvre par rapport à la recherche hybride de base, sans aucune des améliorations que nous avons apportées. Nous allons effectuer une petite série de tests et voir si nous constatons des différences substantielles. Nous appellerons le RAG que nous venons de mettre en œuvre AdvancedRAG et le pipeline de base SimpleRAG.

Synthèse des résultats

Ce tableau résume les résultats de cinq tests effectués sur les deux pipelines RAG. J'ai évalué la supériorité relative de chaque méthode sur la base du détail et de la qualité des réponses, mais il s'agit d'un jugement totalement subjectif. Les réponses réelles sont reproduites sous ce tableau pour votre considération. Ceci étant dit, jetons un coup d'œil sur leurs résultats !

SimpleRAG n'a pas pu répondre aux questions 1 & 5. AdvancedRAG a également répondu de manière beaucoup plus détaillée aux questions 2, 3 et 4. Sur la base de ces détails, j'ai jugé la qualité des réponses d'AdvancedRAG meilleure.

Test

Question

AdvancedRAG Performance

Performance de SimpleRAG

AdvancedRAG Latence

Latence de SimpleRAG

Gagnant

1

Qui audite Elastic ?

A correctement identifié PwC comme étant l'auditeur.

L'auditeur n'a pas été identifié.

11.6s

4.4s

AdvancedRAG

2

Quel a été le revenu total en 2023 ?

A fourni le chiffre d'affaires correct. Inclusion d'un contexte supplémentaire avec les recettes des années précédentes.

A fourni le chiffre d'affaires correct.

13.3s

2.8s

AdvancedRAG

3

De quel produit la croissance dépend-elle principalement ? Combien ?

A correctement identifié l'Elastic Cloud comme étant le facteur clé. Le contexte général des recettes a été inclus & de manière plus détaillée.

A correctement identifié l'Elastic Cloud comme étant le facteur clé.

14.1s

12.8s

AdvancedRAG

4

Décrire le régime d'avantages sociaux des employés

Description complète des régimes de retraite, des programmes de santé et des autres avantages. Incluait des montants de cotisation spécifiques pour différentes années.

A donné un bon aperçu des avantages, y compris la rémunération, les plans de retraite, l'environnement de travail et le programme Elastic Cares.

26.6s

11.6s

AdvancedRAG

5

Quelles sont les entreprises acquises par Elastic ?

A corrigé la liste des acquisitions récentes mentionnées dans le rapport (CmdWatch, Build Security, Optimyze). Il a fourni quelques dates d'acquisition et des prix d'achat.

Échec de la recherche d'informations pertinentes dans le contexte fourni.

11.9s

2.7s

AdvancedRAG

Test 1 : Qui vérifie Elastic ?

AdvancedRAG

SimpleRAG

Résumé: SimpleRAG n'a pas identifié PWC comme étant l'auditeur.

D'accord, c'est assez surprenant. Cela ressemble à un échec de recherche de la part de SimpleRAG. Aucun document relatif à l'audit n'a été retrouvé. Réduisons un peu la difficulté avec le test suivant.

Test 2 : recettes totales en 2023

AdvancedRAG

SimpleRAG

Résumé: les deux RAG ont obtenu la bonne réponse : 1 068 989 000 dollars de recettes totales en 2023.

Ils étaient tous les deux ici. Il semble qu'AdvancedRAG ait acquis un plus grand nombre de documents ? La réponse est certainement plus détaillée et intègre des informations des années précédentes. On peut s'y attendre compte tenu des améliorations que nous avons apportées, mais il est encore trop tôt pour se prononcer.

Augmentons la difficulté.

Test 3 : De quel produit la croissance dépend-elle principalement ? Combien ?

AdvancedRAG

SimpleRAG

Résumé: les deux groupes d'experts ont correctement identifié Elastic Cloud comme le principal moteur de croissance. Cependant, AdvancedRAG fournit plus de détails, en tenant compte des revenus d'abonnement et de la croissance de la clientèle, et mentionne explicitement d'autres offres d'Elastic.

Test 4 : Décrire le régime d'avantages sociaux des salariés

AdvancedRAG

SimpleRAG

Résumé: AdvancedRAG va beaucoup plus en profondeur et en détail, en mentionnant le plan 401K pour les employés basés aux États-Unis, ainsi qu'en définissant les plans de contribution en dehors des États-Unis. Il mentionne également les régimes de santé et de bien-être, mais ne mentionne pas le programme Elastic Cares, que SimpleRAG mentionne.

Test 5 : Quelles sont les entreprises acquises par Elastic ?

AdvancedRAG

SimpleRAG

Résumé: SimpleRAG ne récupère aucune information pertinente sur les acquisitions, ce qui entraîne un échec de la réponse. AdvancedRAG répertorie correctement CmdWatch, Build Security et Optimyze, qui sont les principales acquisitions mentionnées dans le rapport.

Haut de page

Conclusion

D'après nos tests, nos techniques avancées semblent augmenter l'étendue et la profondeur des informations présentées, ce qui pourrait améliorer la qualité des réponses RAG.

En outre, il est possible que la fiabilité soit améliorée, car les questions formulées de manière ambiguë, telles que Which companies did Elastic acquire? et Who audits Elastic, ont été correctement répondues par AdvancedRAG, mais pas par SimpleRAG.

Toutefois, il convient de garder à l'esprit que dans 3 cas sur 5, le pipeline RAG de base, intégrant la recherche hybride mais aucune autre technique, a réussi à produire des réponses qui capturaient la plupart des informations clés.

Il convient de noter qu'en raison de l'incorporation des LLM dans les phases de préparation des données et d'interrogation, la latence d'AdvancedRAG est généralement de 2 à 5 fois supérieure à celle de SimpleRAG. Il s'agit d'un coût important qui pourrait faire en sorte qu'AdvancedRAG ne convienne qu'aux situations où la qualité de la réponse est prioritaire par rapport à la latence.

Les coûts de latence importants peuvent être réduits en utilisant un LLM plus petit et moins cher comme Claude Haiku ou GPT-4o-mini à l'étape de préparation des données. Conservez les modèles avancés pour la génération de réponses.

Cela correspond aux conclusions de Wang et al. Comme le montrent leurs résultats, les améliorations apportées sont relativement progressives. En bref, un simple RAG de base vous permet d'obtenir un produit final décent, tout en étant moins cher et plus rapide. Pour moi, c'est une conclusion intéressante. Pour les cas d'utilisation où la vitesse et l'efficacité sont essentielles, SimpleRAG est un choix judicieux. Pour les cas d'utilisation où chaque goutte de performance doit être extraite, les techniques incorporées dans AdvancedRAG peuvent offrir une solution.

Haut de page

Annexe

Prompts

Question du RAG - invite à répondre

Invitation à faire en sorte que le LLM génère des réponses basées sur la requête et le contexte.

Générateur de requêtes élastiques

Invite à enrichir les requêtes avec des synonymes et à les convertir au format OR.

Questions potentielles : invite à la création d'un générateur

Invite à générer des questions potentielles, à enrichir les métadonnées des documents.

Invite du générateur HyDE

Invite à générer des documents hypothétiques à l'aide de HyDE

Exemple de requête de recherche hybride

L'article récent intitulé Searching for Best Practices in Retrieval-Augmented Generation évalue de manière empirique l'efficacité de diverses techniques d'amélioration des RAG, dans le but de converger vers un ensemble de meilleures pratiques pour les RAG.

Nous mettrons en œuvre quelques-unes des meilleures pratiques proposées, notamment celles qui visent à améliorer la qualité de la recherche (Sentence Chunking, HyDE, Reverse Packing).

Par souci de concision, nous omettons les techniques axées sur l'amélioration de l'efficacité (classification des requêtes et résumé).

Nous mettrons également en œuvre quelques techniques qui n'ont pas été abordées, mais que je trouve personnellement utiles et intéressantes (Metadata Inclusion, Composite Multi-Field Embeddings, Query Enrichment).

Enfin, nous effectuerons un petit test pour voir si la qualité de nos résultats de recherche et des réponses générées s'est améliorée par rapport à la base de référence. C'est parti !

Vue d'ensemble du RAG

RAG vise à améliorer les LLM en récupérant des informations dans des bases de connaissances externes afin d'enrichir les réponses générées. En fournissant des informations spécifiques au domaine, les LLM peuvent être rapidement adaptés à des cas d'utilisation qui sortent du cadre de leurs données de formation ; cela coûte beaucoup moins cher qu'un réglage fin et il est plus facile de les tenir à jour.

Les mesures visant à améliorer la qualité du RAG se concentrent généralement sur deux axes :

1. Améliorer la qualité et la clarté de la base de connaissances.

2. Améliorer la couverture et la spécificité des requêtes de recherche.

Ces deux mesures permettront d'améliorer les chances que le LLM ait accès à des faits et des informations pertinents, et qu'il soit donc moins susceptible d'halluciner ou de s'appuyer sur ses propres connaissances - qui peuvent être dépassées ou non pertinentes.

La diversité des méthodes est difficile à expliquer en quelques phrases. Pour plus de clarté, passons directement à la mise en œuvre.

Table des matières

• Aperçu

  • Table des matières

• Mise en place

• Acquisition, traitement et intégration de documents

  • Ingestion des données

  • Chunking au niveau de la phrase, par jetons

  • Inclusion et génération de métadonnées

    • Phrases clés extraites par TextRank

    • Questions potentielles générées par le GPT-4o

    • Entités extraites par Spacy

  • Enchâssement composite de champs multiples

    • Indexation vers Elastic

• Pause-catalogues

• Annexe

  • Définitions

Mise en place

Tout le code peut être trouvé dans le repo de Searchlabs.

Commençons par le commencement. Vous aurez besoin des éléments suivants :

1. Déploiement d'un nuage élastique

2. Une API LLM - Nous utilisons un déploiement GPT-4o sur Azure OpenAI dans ce carnet.

3. Python version 3.12.4 ou ultérieure

Nous allons exécuter tout le code du cahier main.ipynb.

Allez-y et clonez git le repo, naviguez vers supporting-blog-content/advanced-rag-techniques, puis exécutez les commandes suivantes :

Une fois que c'est fait, créez un fichier .env et remplissez les champs suivants (référencés dans l'exemple .env). Remerciements à mon co-auteur, Claude-3.5, pour ses commentaires utiles.

Ensuite, nous allons choisir le document à ingérer et le placer dans le dossier documents. Pour cet article, nous utiliserons le rapport annuel 2023 d'Elastic N.V. Il s'agit d'un document assez difficile et dense, parfait pour tester nos techniques RAG.

Maintenant que tout est prêt, passons à l'ingestion. Ouvrez main.ipynb et exécutez les deux premières cellules pour importer tous les paquets et initialiser tous les services.

Haut de page

Acquisition, traitement et intégration de documents

Ingestion des données

• Note personnelle : je suis stupéfait par la commodité de LlamaIndex. Avant les LLM et LlamaIndex, l'ingestion de documents de différents formats était un processus pénible de collecte de paquets ésotériques provenant d'un peu partout. Aujourd'hui, il se réduit à un seul appel de fonction. Sauvage.

La commande SimpleDirectoryReader chargera chaque document contenu dans les fichiers directory_path. et .pdf. Elle renvoie une liste d'objets document, que je convertis en dictionnaires Python parce que je trouve qu'ils sont plus faciles à manipuler.

Chaque dictionnaire contient le contenu clé du champ text. Il contient également des métadonnées utiles telles que le numéro de page, le nom du fichier, sa taille et son type.

Haut de page

Chunking au niveau de la phrase, par jetons

La première chose à faire est de réduire nos documents en morceaux d'une longueur standard (pour assurer la cohérence et la maniabilité). Les modèles d'intégration ont des limites de jetons uniques (taille d'entrée maximale qu'ils peuvent traiter). Les jetons sont les unités de base du texte que les modèles traitent. Pour éviter la perte d'informations (tronquage ou omission de contenu), nous devrions fournir un texte qui ne dépasse pas ces limites (en divisant les textes plus longs en segments plus petits).

Le découpage a un impact significatif sur les performances. Idéalement, chaque morceau devrait représenter un élément d'information autonome, capturant des informations contextuelles sur un seul sujet. Les méthodes de découpage comprennent le découpage au niveau des mots, où les documents sont divisés en fonction du nombre de mots, et le découpage sémantique qui utilise un LLM pour identifier les points de rupture logiques.

Le découpage au niveau des mots est bon marché, rapide et facile, mais il risque de diviser les phrases et donc de briser le contexte. Le découpage sémantique devient lent et coûteux, surtout s'il s'agit de documents tels que le rapport annuel Elastic de 116 pages.

Choisissons une approche intermédiaire. Le découpage en phrases est encore simple, mais il permet de préserver le contexte plus efficacement que le découpage en mots, tout en étant nettement moins coûteux et plus rapide. En outre, nous mettrons en œuvre une fenêtre coulissante pour capturer une partie du contexte environnant et atténuer l'impact du découpage des paragraphes.

La classe Chunker utilise le tokenizer du modèle d'intégration pour encoder et décoder le texte. Nous allons maintenant construire des blocs de 512 jetons chacun, avec un chevauchement de 20 jetons. Pour ce faire, nous divisons le texte en phrases, nous tokenisons ces phrases, puis nous ajoutons les phrases tokenisées à notre morceau actuel jusqu'à ce que nous ne puissions plus en ajouter sans dépasser notre limite de tokens.

Enfin, nous décodons les phrases pour les ramener au texte d'origine afin de les intégrer, en les stockant dans un champ appelé original_text. Les morceaux sont stockés dans un champ appelé chunk. Pour réduire le bruit (c'est-à-dire les documents inutiles), nous éliminons tous les documents dont la longueur est inférieure à 50 tokens.

Passons-le en revue nos documents :

Et vous obtenez des morceaux de texte qui ressemblent à ceci :

Haut de page

Inclusion et génération de métadonnées

Nous avons découpé nos documents en morceaux. Il est maintenant temps d'enrichir les données. Je souhaite générer ou extraire des métadonnées supplémentaires. Ces métadonnées supplémentaires peuvent être utilisées pour influencer et améliorer les performances de recherche.

Nous allons définir une classe DocumentEnricher, dont le rôle est de recevoir une liste de documents (dictionnaires Python) et une liste de fonctions du processeur. Ces fonctions s'exécutent sur la colonne original_text des documents et stockent leurs résultats dans de nouveaux champs.

Tout d'abord, nous extrayons les phrases clés à l'aide de TextRank. TextRank est un algorithme basé sur un graphe qui permet d'extraire des phrases et des expressions clés d'un texte en classant leur importance sur la base des relations entre les mots.

Ensuite, nous allons générer des questions potentielles à l'aide de GPT-4o.

Enfin, nous extrairons les entités à l'aide de Spacy.

Le code de chacun d'entre eux étant assez long et complexe, je m'abstiendrai de le reproduire ici. Si vous êtes intéressé, les fichiers sont indiqués dans les exemples de code ci-dessous.

Lançons l'enrichissement des données :

Et regardez les résultats :

Phrases clés extraites par TextRank

Ces phrases clés sont des substituts des thèmes centraux de la rubrique. Si une requête a trait à la cybersécurité, le score de ce morceau sera augmenté.

Questions potentielles générées par le GPT-4o

Ces questions potentielles peuvent correspondre directement aux requêtes des utilisateurs, ce qui permet d'améliorer le score. Nous demandons à GPT-4o de générer des questions auxquelles il est possible de répondre en utilisant les informations trouvées dans le morceau actuel.

Entités extraites par Spacy

Ces entités ont un objectif similaire à celui des phrases clés, mais elles capturent les noms des organisations et des individus, ce que l'extraction des phrases clés peut ne pas faire.

Haut de page

Enchâssement composite de champs multiples

Maintenant que nous avons enrichi nos documents avec des métadonnées supplémentaires, nous pouvons exploiter ces informations pour créer des encastrements plus robustes et tenant compte du contexte.

Faisons le point sur l'état actuel du processus. Nous avons quatre champs d'intérêt dans chaque document.

Chaque champ représente une perspective différente sur le contexte du document, mettant potentiellement en évidence un domaine clé sur lequel le LLM devrait se concentrer.

Il s'agit d'intégrer chacun de ces champs, puis de créer une somme pondérée des intégrations, appelée intégration composite.

Avec un peu de chance, cette intégration composite permettra au système de mieux tenir compte du contexte, tout en introduisant un autre hyperparamètre réglable pour contrôler le comportement de recherche.

Tout d'abord, intégrons chaque champ et mettons à jour chaque document en place, en utilisant notre modèle d'intégration défini localement et importé au début du bloc-notes main.ipynb.

Chaque fonction d'intégration renvoie le champ de l'intégration, qui est simplement le champ d'entrée original avec un postfixe _embedding.

Définissons maintenant les pondérations de notre encastrement composite :

Les pondérations vous permettent d'attribuer des priorités à chaque composant, en fonction de votre cas d'utilisation et de la qualité de vos données. Intuitivement, la taille de ces pondérations dépend de la valeur sémantique de chaque composant. Étant donné que le morceau de texte lui-même est de loin le plus riche, je lui attribue une pondération de 70%. Les entités étant les plus petites, puisqu'il s'agit simplement d'une liste de noms d'organisations ou de personnes, je leur attribue une pondération de 5%. Le réglage précis de ces valeurs doit être déterminé de manière empirique, au cas par cas.

Enfin, écrivons une fonction pour appliquer les pondérations et créer notre intégration composite. Pour gagner de la place, nous supprimerons également tous les composants intégrés.

Nous avons ainsi terminé le traitement des documents. Nous disposons à présent d'une liste d'objets documents qui se présente comme suit :

Indexation vers Elastic

Chargeons nos documents en vrac dans Elastic Search. À cette fin, j'ai défini il y a longtemps un ensemble de fonctions Elastic Helper dans elastic_helpers.py. Il s'agit d'un code très long, nous allons donc nous contenter d'examiner les appels de fonction.

es_bulk_indexer.bulk_upload_documents fonctionne avec n'importe quelle liste d'objets dictionnaires, en tirant parti des mappages dynamiques pratiques d'Elasticsearch.

Rendez-vous sur Kibana et vérifiez que tous les documents ont été indexés. Il devrait y en avoir 224. Pas mal pour un document aussi volumineux !

Haut de page

Pause-catalogues

Faisons une pause, l'article est un peu lourd, je sais. Jetez un coup d'œil à mon chat :

Adorable. Le chapeau a disparu et je soupçonne à moitié qu'elle l'a volé et caché quelque part :(

Félicitations pour avoir réussi à aller aussi loin :)

Rejoignez-moi dans la deuxième partie pour tester et évaluer notre pipeline RAG !

Annexe

Définitions

1. Découpage des phrases

• Technique de prétraitement utilisée dans les systèmes RAG pour diviser le texte en unités plus petites et significatives.

• Processus :

  1. Entrée : Grand bloc de texte (par exemple, document, paragraphe)

  2. Sortie : Segments de texte plus petits (généralement des phrases ou des petits groupes de phrases)

• Objet :

  • Création de segments de texte granulaires et spécifiques au contexte

  • Permet une indexation et une recherche plus précises

  • Améliore la pertinence des informations recherchées dans les systèmes RAG

• Caractéristiques :

  • Les segments sont sémantiquement significatifs

  • Peuvent être indexés et récupérés de manière indépendante

  • Souvent, le contexte est préservé afin de garantir la compréhensibilité autonome.

• Avantages :

  • Améliore la précision de la recherche

  • Permet une augmentation plus ciblée des pipelines RAG

2. HyDE (Hypothetical Document Embedding)

• Une technique qui utilise un LLM pour générer un document hypothétique pour l'expansion des requêtes dans les systèmes RAG.

• Processus :

  1. Requête d'entrée à un LLM

  2. LLM génère un document hypothétique répondant à la requête

  3. Intégrer le document généré

  4. Utiliser l'intégration pour la recherche vectorielle

• Différence essentielle :

  • RAG traditionnel : Correspondance entre la requête et les documents

  • HyDE : fait correspondre des documents à d'autres documents

• Objet :

  • Améliorer les performances de recherche, en particulier pour les requêtes complexes ou ambiguës

  • Saisir un contexte sémantique plus riche qu'une requête courte

• Avantages :

  • Exploite les connaissances du LLM pour élargir les requêtes

  • Peut potentiellement améliorer la pertinence des documents retrouvés

• Défis :

  • Nécessite une inférence LLM supplémentaire, ce qui augmente le temps de latence et le coût.

  • La performance dépend de la qualité du document hypothétique généré

3. Emballage inversé

• Technique utilisée dans les systèmes RAG pour réorganiser les résultats de la recherche avant de les transmettre au LLM.

• Processus :

  1. Le moteur de recherche (par exemple, Elasticsearch) renvoie les documents par ordre décroissant de pertinence.

  2. L'ordre est inversé, le document le plus pertinent étant placé en dernier.

• Objet :

  • Exploite le biais de récence des LLM, qui ont tendance à se concentrer sur les informations les plus récentes dans leur contexte.

  • Veille à ce que les informations les plus pertinentes soient "les plus récentes" dans la fenêtre contextuelle du LLM.

• Exemple : Ordre original : [Plus pertinent, Deuxième plus important, Troisième plus important, ...] Ordre inversé : [..., Troisième plus important, Deuxième plus important, Plus important]

4. Classification des requêtes

• Technique permettant d'optimiser l'efficacité du système RAG en déterminant si une requête nécessite un RAG ou si elle peut être traitée directement par le LLM.

• Processus :

  1. Développer un ensemble de données personnalisé spécifique au programme d'éducation et de formation tout au long de la vie utilisé

  2. Former un modèle de classification spécialisé

  3. Utiliser le modèle pour catégoriser les requêtes entrantes

• Objet :

  • Améliorer l'efficacité du système en évitant le traitement inutile des RAG

  • Diriger les demandes vers le mécanisme de réponse le plus approprié

• Exigences :

  • Ensemble de données et modèle spécifiques au LLM

  • Amélioration continue pour maintenir la précision

• Avantages :

  • Réduction de la charge de calcul pour les requêtes simples

  • Amélioration potentielle du temps de réponse pour les requêtes non RAG

5. Résumé

• Une technique pour condenser les documents récupérés dans les systèmes RAG.

• Processus :

  1. Récupérer les documents pertinents

  2. Générer des résumés concis de chaque document

  3. Utiliser des résumés plutôt que des documents complets dans le pipeline RAG

• Objet :

  • Améliorer la performance du RAG en se concentrant sur les informations essentielles

  • Réduire le bruit et les interférences provenant de contenus moins pertinents

• Avantages :

  • Amélioration potentielle de la pertinence des réponses au programme d'éducation et de formation tout au long de la vie

  • Permet d'inclure un plus grand nombre de documents dans les limites du contexte

• Défis :

  • Risque de perdre des détails importants dans le résumé

  • Frais de calcul supplémentaires pour la génération du résumé

6. Inclusion de métadonnées

• Une technique pour enrichir les documents avec des informations contextuelles supplémentaires.

• Types de métadonnées :

  • Mots clés

  • Titres

  • Dates

  • Coordonnées de l'auteur

  • Les commentaires

• Objet :

  • Augmenter les informations contextuelles disponibles pour le système RAG

  • Fournir aux gestionnaires du droit d'auteur une meilleure compréhension du contenu et de la pertinence des documents

• Avantages :

  • Amélioration potentielle de la précision de la recherche

  • Améliore la capacité du LLM à évaluer l'utilité des documents

• Mise en œuvre :

  • Peut être effectué lors du prétraitement des documents

  • Peut nécessiter des étapes supplémentaires d'extraction ou de génération de données

7. Intégrations composites multi-champs

• Une technique d'intégration avancée pour les systèmes RAG qui crée des intégrations distinctes pour les différents composants du document.

• Processus :

  1. Identifier les champs pertinents (par exemple, le titre, les phrases clés, le résumé, le contenu principal)

  2. Générer des embeddings distincts pour chaque champ

  3. Combiner ou stocker ces encastrements pour les utiliser lors de la recherche.

• Différence par rapport à l'approche standard :

  • Traditionnel : Intégration unique pour l'ensemble du document

  • Composite : Plusieurs encastrements pour différents aspects du document

• Objet :

  • Créer des représentations de documents plus nuancées et tenant compte du contexte

  • Saisir des informations provenant d'une plus grande variété de sources dans un document

• Avantages :

  • Amélioration potentielle des performances sur les requêtes ambiguës ou à multiples facettes

  • Permet une pondération plus souple des différents aspects du document dans la recherche.

• Défis :

  • Complexité accrue de l'intégration des processus de stockage et d'extraction

  • Peut nécessiter des algorithmes d'appariement plus sophistiqués

8. Enrichissement des requêtes

• Une technique qui consiste à ajouter des termes connexes à la requête initiale afin d'améliorer la couverture de la recherche.

• Processus :

  1. Analyser la requête originale

  2. Générer des synonymes et des phrases sémantiquement proches

  3. Complétez la requête avec ces termes supplémentaires

• Objet :

  • Augmenter l'éventail des correspondances potentielles dans le corpus de documents

  • Améliorer les performances de recherche pour les requêtes formulées dans un langage spécifique ou technique

• Avantages :

  • Possibilité de retrouver des documents pertinents qui ne correspondent pas exactement aux termes de la requête initiale.

  • Peut aider à surmonter l'inadéquation du vocabulaire entre les requêtes et les documents

• Défis :

  • Risque de dérive des requêtes en l'absence d'une mise en œuvre rigoureuse

  • Peut augmenter la charge de calcul dans le processus de recherche.

Haut de page

Dans ce billet, nous examinerons les moyens de protéger les informations personnelles identifiables (PII) et les données sensibles lors de l'utilisation de LLM publics dans un flux RAG (Retrieval Augmented Generation). Nous explorerons le masquage des IIP et des données sensibles à l'aide de bibliothèques open source et d'expressions régulières, ainsi que l'utilisation de LLM locaux pour masquer les données avant d'invoquer un LLM public.

Avant de commencer, rappelons la terminologie utilisée dans ce billet.

Terminologie

LlamaIndex est un cadre de données de premier plan pour la création d'applications LLM (Large Language Model). LlamaIndex fournit des abstractions pour les différentes étapes de la construction d'une application RAG (Retrieval Augmented Generation). Des structures telles que LlamaIndex et LangChain fournissent des abstractions afin que les applications ne soient pas étroitement liées aux API d'un LLM spécifique.

Elasticsearch est proposé par Elastic. Elastic est un leader de l'industrie avec Elasticsearch, un magasin de données évolutif et une base de données vectorielle qui prend en charge la recherche en texte intégral pour la précision, la recherche vectorielle pour la compréhension sémantique, et la recherche hybride pour le meilleur des deux mondes. Elasticsearch est un moteur de recherche et d'analyse RESTful distribué, un magasin de données évolutif et une base de données vectorielle. Les fonctionnalités d'Elasticsearch que nous utilisons dans ce blog sont disponibles dans la version gratuite et ouverte d'Elasticsearch.

La génération assistée par récupération (RAG) est une technique ou un modèle d'IA dans lequel les LLM sont dotés de connaissances externes pour générer des réponses aux questions des utilisateurs. Cela permet d'adapter les réponses du programme d'éducation et de formation tout au long de la vie à un contexte spécifique et de les rendre moins génériques.

Les encastrements sont des représentations numériques de la signification d'un texte ou d'un média. Il s'agit de représentations de dimensions inférieures d'informations de dimensions supérieures.

RAG et protection des données

En règle générale, les grands modèles linguistiques (LLM) permettent de générer des réponses sur la base des informations disponibles dans le modèle, qui peut être formé à partir de données Internet. Toutefois, pour les questions pour lesquelles les informations ne sont pas disponibles dans le modèle, les MFR doivent être alimentés par des connaissances externes ou des détails spécifiques qui ne sont pas contenus dans le modèle. Ces informations peuvent se trouver dans votre base de données ou dans votre système de connaissances interne. La génération améliorée par récupération (RAG) est une technique dans laquelle, pour une requête d'utilisateur donnée, vous récupérez d'abord le contexte/l'information pertinente des systèmes externes (au LLM) (par exemple votre base de données) et envoyez ce contexte avec la requête d'utilisateur au LLM pour générer une réponse plus spécifique et plus pertinente.

Cela rend la technique RAG très efficace pour les applications de réponse aux questions, de création de contenu et partout où une compréhension approfondie du contexte et des détails est bénéfique.

Par conséquent, dans une filière RAG, vous courez le risque d'exposer des informations internes telles que des PII (informations personnelles identifiables) et des informations sensibles (par exemple des noms, des dates de naissance, des numéros de compte, etc.

Bien que vos données soient sécurisées lorsque vous utilisez une base de données vectorielle comme Elasticsearch (grâce à divers leviers tels que le contrôle d'accès basé sur les rôles, la sécurité au niveau du document, etc.), il convient d'être prudent lorsque vous envoyez des données à l'extérieur vers un LLM public.

La protection des informations d'identification personnelle (PII) et des données sensibles est cruciale lors de l'utilisation de grands modèles de langage (LLM), et ce pour plusieurs raisons :

• Conformité en matière de protection de la vie privée: De nombreuses régions disposent de réglementations strictes, telles que le règlement général sur la protection des données (RGPD) en Europe ou le California Consumer Privacy Act (CCPA) aux États-Unis, qui imposent la protection des données personnelles. Le respect de ces lois est nécessaire pour éviter les conséquences juridiques et les amendes.

• Confiance des utilisateurs: Garantir la confidentialité et l'intégrité des informations sensibles permet de renforcer la confiance des utilisateurs. Les utilisateurs sont plus enclins à utiliser et à interagir avec des systèmes dont ils pensent qu'ils protègent leur vie privée.

• Sécurité des données: La protection contre les violations de données est essentielle. Les données sensibles exposées aux MLD sans garanties adéquates peuvent faire l'objet d'un vol ou d'une utilisation abusive, entraînant des dommages potentiels tels que l'usurpation d'identité ou la fraude financière.

• Considérations éthiques: D'un point de vue éthique, il est important de respecter la vie privée des utilisateurs et de traiter leurs données de manière responsable. Un mauvais traitement des IPI peut conduire à la discrimination, à la stigmatisation ou à d'autres conséquences négatives pour la société.

• Réputation de l'entreprise: Les entreprises qui ne protègent pas les données sensibles peuvent voir leur réputation entachée, ce qui peut avoir des effets négatifs à long terme sur leurs activités, notamment la perte de clients et de revenus.

• Réduction des risques d'abus: Le traitement sécurisé des données sensibles permet d'éviter l'utilisation malveillante des données ou du modèle, comme l'entraînement des modèles sur des données biaisées ou l'utilisation des données pour manipuler ou nuire à des personnes.

Dans l'ensemble, une protection solide des IPI et des données sensibles est nécessaire pour garantir la conformité légale, maintenir la confiance des utilisateurs, assurer la sécurité des données, respecter les normes éthiques, protéger la réputation de l'entreprise et réduire le risque d'abus.

Récapitulatif rapide

Dans l'article précédent, nous avons expliqué comment mettre en œuvre l'expérience Q&A en utilisant une technique RAG avec Elasticsearch comme base de données vectorielle tout en utilisant LlamaIndex et un Mistral LLM fonctionnant localement. Ici, nous nous appuyons sur cette base.

La lecture de l'article précédent est facultative car nous allons maintenant discuter/récapituler rapidement ce que nous avons fait dans l'article précédent.

Nous disposions d'un échantillon de données de conversations de centre d'appel entre des agents et des clients d'une compagnie d'assurance habitation fictive. Nous avons créé une application RAG simple qui répond à des questions telles que "Quels sont les problèmes liés à l'eau pour lesquels les clients déposent des réclamations ?

Voici comment se présentait le flux à un niveau élevé.

Pendant la phase d'indexation, nous avons chargé et indexé des documents en utilisant le pipeline LlamaIndex. Les documents ont été regroupés et stockés dans la base de données vectorielles Elasticsearch avec leur intégration.

Pendant la phase d'interrogation, lorsque l'utilisateur pose une question, LlamaIndex récupère les documents similaires les plus pertinents par rapport à l'interrogation. Ces documents les plus pertinents, accompagnés de la requête, ont été envoyés au Mistral LLM local, qui a ensuite généré la réponse à renvoyer à l'utilisateur. N'hésitez pas à consulter l'article précédent ou à explorer le code.

Dans l'article précédent, le LLM fonctionnait localement. Cependant, en production, vous pouvez vouloir utiliser un LLM externe fourni par diverses entreprises comme OpenAI, Mistral, Anthropic, etc. Cela peut être dû au fait que votre cas d'utilisation nécessite un modèle de base plus important ou que l'exécution locale n'est pas une option en raison des besoins de production de l'entreprise tels que l'évolutivité, la disponibilité, les performances, etc.

L'introduction d'un LLM externe dans votre pipeline RAG vous expose à un risque de fuite involontaire de données sensibles et d'informations confidentielles vers les LLM. Dans cet article, nous allons explorer les options permettant de masquer les informations PII dans le cadre de votre processus RAG avant d'envoyer des documents à un LLM externe.

RAG avec un LLM public

Avant d'aborder la question de la protection des informations confidentielles et sensibles dans un pipeline RAG, nous allons d'abord construire une application RAG simple utilisant LlamaIndex, la base de données vectorielle Elasticsearch et OpenAI LLM.

Produits requis

Nous aurons besoin des éléments suivants.

• Elasticsearch est opérationnel en tant que base de données vectorielle pour le stockage des embeddings. Suivez les instructions de l'article précédent sur l'installation d'Elasticsearch.

• Clés d'API ouvertes pour l'IA.

Application simple du RAG

Pour référence, le code entier peut être trouvé dans ce dépôt Github(branch:protecting-pii). Le clonage du dépôt est facultatif car nous allons parcourir le code ci-dessous.

Dans votre IDE préféré, créez une nouvelle application Python avec les 3 fichiers ci-dessous.

• index.py où se trouve le code lié à l'indexation des données.

• query.py où se trouve le code lié à l'interrogation et à l'interaction avec le LLM.

• .env où se trouvent les propriétés de configuration telles que les clés d'API.

Nous devons installer quelques paquets. Nous commençons par créer un nouvel environnement virtuel python dans le dossier racine de votre application.

Activez l'environnement virtuel et installez les paquets requis ci-dessous.

Configurer les propriétés de connexion d'OpenAI et d'Elasticsearch dans le fichier .env fichier.

Indexation des données

Téléchargez le fichier conversations.json qui contient les conversations entre les clients et les agents du centre d'appel de notre compagnie d'assurance habitation fictive. Placez le fichier dans le répertoire racine de l'application avec les 2 fichiers python et le fichier .env. que vous avez créé précédemment. Vous trouverez ci-dessous un exemple du contenu du fichier.

Passez le code ci-dessous dans index.py qui se charge de l'indexation des données.

L'exécution du code ci-dessus crée un index dans Elasticsearch, stocke les embeddings dans l'index Elasticsearch nommé convo_index.

Si vous avez besoin d'explications sur la LlamaIndex IngestionPipeline, veuillez vous référer à l'article précédent dans la section Create IngestionPipeline.

Interrogation

Dans l'article précédent, nous avons utilisé un LLM local pour les requêtes.

Dans ce billet, nous utilisons le LLM public, OpenAI, comme indiqué ci-dessous.

Le code ci-dessus affiche la réponse d'OpenAI comme suit.

Les clients ont fait part de diverses réclamations liées à l'eau, notamment des dégâts des eaux dans les sous-sols, des éclatements de canalisations, des dommages causés aux toits par la grêle, et des refus de demandes d'indemnisation pour des raisons telles que l'absence de notification en temps utile, des problèmes d'entretien, l'usure progressive et les dommages préexistants. Dans chaque cas, les clients ont exprimé leur frustration face aux refus de demandes d'indemnisation et ont demandé des évaluations et des décisions équitables concernant leurs demandes d'indemnisation.

Masquage des IIP dans le RAG

Ce que nous avons couvert jusqu'à présent consiste à envoyer des documents tels quels à OpenAI avec la requête de l'utilisateur.

Dans le pipeline RAG, une fois que le contexte pertinent est extrait d'un magasin vectoriel, nous avons la possibilité de masquer les IIP et les informations sensibles avant d'envoyer la requête et le contexte au mécanisme d'apprentissage tout au long de la vie.

Il existe plusieurs façons de masquer les informations PII avant de les envoyer à un MLD externe, chacune d'entre elles ayant ses propres mérites. Nous examinons ci-dessous quelques-unes des options possibles

1. Utilisation de bibliothèques NLP comme spacy.io ou Presidio (bibliothèque open source gérée par Microsoft).

2. Utiliser LlamaIndex prêt à l'emploi NERPIINodePostprocessor.

3. Utilisation de LLM locaux via PIINodePostprocessor

Une fois que vous avez implémenté la logique de masquage en utilisant l'une des méthodes ci-dessus, vous pouvez configurer la LlamaIndex IngestionPipeline avec un PostProcessor (votre propre PostProcessor personnalisé ou l'un des PostProcessors prêts à l'emploi de LlamaIndex).

Utilisation des bibliothèques NLP

Dans le cadre du pipeline RAG, nous pouvons masquer les données sensibles à l'aide de bibliothèques NLP. Nous utiliserons le paquet spacy.io dans cette démonstration.

Créez un nouveau fichier query_masking_nlp.py et ajoutez le code ci-dessous.

La réponse du LLM est présentée ci-dessous.

Dans le code ci-dessus, lors de la création du moteur de requête de l'index Llama, nous fournissons un CustomPostProcessor.

La logique invoquée par le QueryEngine est définie dans la méthode _postprocess_nodes de CustomPostProcessor. Nous utilisons la bibliothèque SpaCy.io pour détecter les entités nommées dans nos documents et nous utilisons ensuite des expressions régulières pour remplacer ces noms ainsi que les informations sensibles avant d'envoyer les documents au LLM.

À titre d'exemple, voici des parties de conversations originales et de la conversation masquée créée par le CustomPostProcessor.

Texte original :

Texte masqué par le CustomPostProcessor.

Remarque :

Identifier et masquer les IPI et les informations sensibles n'est pas une tâche aisée. Couvrir les différents formats et la sémantique des informations sensibles nécessite une bonne compréhension de votre domaine et de vos données. Bien que le code présenté ci-dessus puisse fonctionner pour certains cas d'utilisation, il se peut que vous deviez le modifier en fonction de vos besoins et de vos tests.

Utiliser le LlamaIndex prêt à l'emploi NERPIINodePostprocessor

LlamaIndex a facilité la protection des informations PII dans un pipeline RAG en introduisant les éléments suivants NERPIINodePostprocessor.

La réponse est la suivante

Utilisation de LLM locaux via PIINodePostprocessor

Nous pourrions également utiliser un LLM fonctionnant localement ou dans votre réseau privé pour effectuer le travail de masquage avant d'envoyer les données à un LLM public.

Nous utiliserons Mistral fonctionnant sur Ollama sur votre machine locale pour effectuer le masquage.

Exécuter Mistral localement

Téléchargez et installez Ollama. Après avoir installé Ollama, lancez la commande suivante pour télécharger et exécuter mistral

Le téléchargement et l'exécution locale du modèle pour la première fois peuvent prendre quelques minutes. Vérifiez si le mistral fonctionne en posant une question telle que la suivante : "Ecrivez un poème sur les nuages" et vérifiez si le poème vous plaît. Gardez ollama en marche car nous aurons besoin d'interagir avec le modèle mistral plus tard par le biais du code.

Créez un nouveau fichier appelé query_masking_local_LLM.py et ajoutez le code ci-dessous.

La réponse ressemble à ce qui est indiqué ci-dessous

Conclusion

Dans cet article, nous avons montré comment protéger les informations confidentielles et les données sensibles lors de l'utilisation de LLM publics dans un flux RAG. Nous avons démontré qu'il y avait plusieurs façons d'y parvenir. Il est fortement recommandé de tester ces approches en fonction de votre cas d'utilisation et de vos besoins avant de les adopter.

Avant de commencer, nous allons examiner quelques termes.

Terminologie

LlamaIndex est un cadre de données de premier plan pour la création d'applications LLM (Large Language Model). LlamaIndex fournit des abstractions pour les différentes étapes de la construction d'une application RAG (Retrieval Augmented Generation). Des structures telles que LlamaIndex et LangChain fournissent des abstractions afin que les applications ne soient pas étroitement liées aux API d'un LLM spécifique.

Elasticsearch est proposé par Elastic. Elastic est un leader de l'industrie avec Elasticsearch, un moteur de recherche et d'analyse qui prend en charge la recherche en texte intégral pour la précision, la recherche vectorielle pour la compréhension sémantique, et la recherche hybride pour le meilleur des deux mondes. Elasticsearch est un magasin de données évolutif et une base de données vectorielle. Les fonctionnalités d'Elasticsearch que nous utilisons dans ce blog sont disponibles dans la version gratuite et ouverte d'Elasticsearch.

Retrieval Augment Generation (RAG) est une technique/un modèle d'IA dans lequel les LLM sont dotés de connaissances externes pour générer des réponses aux requêtes des utilisateurs. Cela permet d'adapter les réponses du programme d'éducation et de formation tout au long de la vie à un contexte spécifique et les réponses sont plus spécifiques.

Mistral propose des modèles LLM open-source et optimisés pour les entreprises. Dans ce tutoriel, nous utiliserons leur modèle open source mistral-7b qui fonctionne sur votre ordinateur portable. Si vous ne souhaitez pas exécuter le modèle sur votre ordinateur portable, vous pouvez utiliser la version en nuage, auquel cas vous devrez modifier le code de ce blog afin d'utiliser les clés et les paquets API appropriés.

Ollama permet d'exécuter des LLM localement sur votre ordinateur portable. Nous utiliserons Ollama pour exécuter localement le modèle open source Mistral-7b.

Les encastrements sont des représentations numériques de la signification d'un texte ou d'un média. Il s'agit de représentations de dimensions inférieures d'informations de dimensions supérieures.

Construire une application RAG avec LlamaIndex, Elasticsearch & Mistral : Aperçu du scénario

Scénario :

Nous disposons d'un échantillon de données (sous forme de fichier JSON) de conversations entre des agents et des clients d'une compagnie d'assurance habitation fictive. Nous allons créer une application RAG simple qui peut répondre à des questions telles que

Give me summary of water related issues.

Débit élevé

Mistral LLM fonctionne localement à l'aide d'Ollama.

Ensuite, nous chargeons les conversations du fichier JSON en tant que Documents dans le magasin ElasticsearchStore (qui est un magasin VectorStore soutenu par Elasticsearch). Lors du chargement des documents, nous créons des enchâssements à l'aide du modèle Mistral exécuté localement. Nous stockons ces encastrements ainsi que les conversations dans le magasin vectoriel Elasticsearch de LlamaIndex(ElasticsearchStore).

Nous configurons une ligne d'ingestion LlamaIndex et lui fournissons le LLM local que nous utilisons, dans ce cas Mistral fonctionnant via Ollama.

Lorsque nous posons une question telle que "Donnez-moi un résumé des problèmes liés à l'eau", Elasticsearch effectue une recherche sémantique et renvoie les conversations liées aux problèmes de l'eau. Ces conversations, ainsi que la question initiale, sont envoyées au LLM local pour générer une réponse.

Étapes de la création de l'application RAG

Exécuter Mistral localement

Téléchargez et installez Ollama. Après avoir installé Ollama, lancez la commande suivante pour télécharger et exécuter mistral

Le téléchargement et l'exécution locale du modèle pour la première fois peuvent prendre quelques minutes. Vérifiez si le mistral fonctionne en posant une question telle que la suivante : "Ecrivez un poème sur les nuages" et vérifiez si le poème vous plaît. Gardez ollama en marche car nous aurons besoin d'interagir avec le modèle mistral plus tard par le biais du code.

Installer Elasticsearch

Faites fonctionner Elasticsearch en créant un déploiement dans le nuage(instructions ici) ou en l'exécutant dans Docker(instructions ici). Vous pouvez également créer un déploiement autonome d'Elasticsearch au niveau de la production en commençant ici.

Si vous utilisez le déploiement dans le nuage, saisissez la clé API et l'ID du nuage pour le déploiement, comme indiqué dans les instructions. Nous les utiliserons plus tard.

Application RAG

Pour référence, le code complet peut être trouvé dans ce dépôt Github. Le clonage de la base de données est facultatif car nous allons parcourir le code ci-dessous.

Dans votre IDE préféré, créez une nouvelle application Python avec les 3 fichiers ci-dessous.

• index.py où se trouve le code lié à l'indexation des données.

• query.py où se trouve le code lié à l'interrogation et à l'interaction avec le LLM.

• .env où se trouvent les propriétés de configuration telles que les clés d'API.

Nous devons installer quelques paquets. Nous commençons par créer un nouvel environnement virtuel python dans le dossier racine de votre application.

Activez l'environnement virtuel et installez les paquets requis ci-dessous.

Indexation des données

Téléchargez le fichier conversations.json qui contient les conversations entre les clients et les agents du centre d'appel de notre compagnie d'assurance habitation fictive. Placez le fichier dans le répertoire racine de l'application avec les 2 fichiers python et le fichier .env. que vous avez créé précédemment. Vous trouverez ci-dessous un exemple du contenu du fichier.

Nous définissons une fonction appelée get_documents_from_file dans index.py qui lit le fichier json et crée une liste de documents. Les objets document sont l'unité de base de l'information avec laquelle LlamaIndex travaille.

Créer un pipeline d'ingestion

Tout d'abord, ajoutez au fichier .env l'Elasticsearch CloudID et les clés API que vous avez obtenues dans la section Install Elasticsearch. Votre fichier .env devrait ressembler à ce qui suit (avec des valeurs réelles).

LlamaIndex IngestionPipeline vous permet de composer un pipeline à l'aide de plusieurs composants. Ajoutez le code ci-dessous au fichier index.py.

Comme nous l'avons déjà mentionné, la LlamaIndex IngestPipeline peut être composée de plusieurs éléments. Nous ajoutons 3 composants au pipeline dans la ligne pipeline = IngestionPipeline(....

• SentenceSplitter: Comme on peut le voir dans la définition de get_documents_from_file(), chaque document possède un champ texte qui contient la conversation trouvée dans le fichier json. Ce champ de texte est un long texte. Pour que la recherche sémantique fonctionne bien, elle doit être décomposée en morceaux de textes plus petits. La classe SentenceSplitter s'en charge pour nous. Ces morceaux sont appelés nœuds dans la terminologie de LlamaIndex. Les nœuds contiennent des métadonnées qui renvoient au document auquel ils appartiennent. Vous pouvez également utiliser Elasticsearch Ingestpipeline pour le découpage, comme indiqué dans ce blog.

• OllamaEmbedding: Les modèles d'incorporation convertissent un texte en nombres (également appelés vecteurs). La représentation numérique nous permet d'effectuer une recherche sémantique où les résultats de la recherche correspondent à la signification du mot plutôt que d'effectuer une simple recherche textuelle. Nous fournissons à l'IngestionPipeline le site OllamaEmbedding("mistral"). Les morceaux que nous découpons à l'aide de SentenceSplitter sont envoyés au modèle Mistral qui s'exécute sur votre machine locale via Ollama, mistral crée alors des embeddings pour les morceaux.

• ElasticsearchStore: Le magasin vectoriel ElasticsearchStore de LlamaIndex sauvegarde les embeddings créés dans un index Elasticsearch. ElasticsearchStore se charge de créer et d'alimenter le contenu de l'index Elasticsearch spécifié. Lors de la création de l'ElasticsearchStore (référencé par es_vector_store), nous fournissons le nom de l'index Elasticsearch que nous voulons créer (calls dans notre cas), le champ de l'index dans lequel nous voulons stocker les embeddings (conversation_vector dans notre cas) et le champ dans lequel nous voulons stocker le texte (conversation dans notre cas). En résumé, selon notre configuration, ElasticsearchStore crée un nouvel index dans Elasticsearch avec conversation_vector et conversation comme champs (parmi d'autres champs créés automatiquement).

Pour relier le tout, nous exécutons le pipeline en appelant pipeline.run(documents=documents).

Lancez le script index.py pour exécuter le pipeline d'ingestion :

Une fois l'exécution du pipeline terminée, nous devrions voir un nouvel index dans Elasticsearch appelé calls. En exécutant une simple requête elasticsearch à l'aide de la Dev Console, vous devriez être en mesure de voir les données chargées avec les embeddings.

Pour résumer ce que nous avons fait jusqu'à présent, nous avons créé des documents à partir d'un fichier JSON, nous les avons divisés en morceaux, nous avons créé des embeddings pour ces morceaux et nous avons stocké les embeddings (et la conversation textuelle) dans un magasin vectoriel (ElasticsearchStore).

Interrogation

Le VectorStoreIndex llamaIndex vous permet de retrouver des documents pertinents et d'interroger des données. Par défaut, VectorStoreIndex stocke les intégrations en mémoire dans un SimpleVectorStore. Cependant, des entrepôts de vecteurs externes (comme ElasticsearchStore) peuvent être utilisés à la place pour rendre les enregistrements persistants.

Ouvrez le site query.py et collez le code ci-dessous

Nous définissons un LLM local (local_llm) pour indiquer le modèle Mistral fonctionnant sur Ollama. Ensuite, nous créons un VectorStoreIndex (index) à partir du magasin de vecteurs ElasticssearchStore que nous avons créé précédemment, puis nous obtenons un moteur de requête à partir de l'index. Lors de la création du moteur de requête, nous référençons le LLM local qui doit être utilisé pour répondre, nous fournissons également (similarity_top_k=10) pour configurer le nombre de documents qui doivent être récupérés dans le magasin vectoriel et envoyés au LLM pour obtenir une réponse.

Lancez le script query.py pour exécuter le flux RAG :

Nous envoyons la demande à Give me summary of water related issues (n'hésitez pas à personnaliser query) et la réponse du LLM, qui est accompagnée des documents correspondants, devrait ressembler à ce qui suit.

Quelques mises en garde :

Cet article de blog est une introduction pour débutants à la technique RAG avec Elasticsearch et omet donc la configuration des fonctionnalités qui vous permettront de passer de ce point de départ à la production. Lorsque vous construisez pour des cas d'utilisation en production, vous voudrez prendre en compte des aspects plus sophistiqués comme la possibilité de protéger vos données avec Document Level Security, le découpage de vos données dans le cadre d'un pipeline d'ingestion Elasticsearch ou même l'exécution d'autres tâches de ML sur les mêmes données que celles utilisées pour les cas d'utilisation GenAI/Chat/Q&A.

Vous pouvez également envisager d'obtenir des données et de créer des embeddings à partir de diverses sources externes (par exemple Azure Blob Storage, Dropbox, Gmail, etc.) à l'aide d'Elastic Connectors.

Elastic rend possible tout ce qui précède et plus encore, et fournit une solution d'entreprise complète pour les cas d'utilisation de la GenAI et au-delà.

Quelle est la suite ?

• Vous avez peut-être remarqué que nous envoyons 10 conversations connexes avec la question de l'utilisateur au LLM pour formuler une réponse. Ces conversations peuvent contenir des IPI (informations personnelles identifiables) telles que le nom, la date de naissance, l'adresse, etc. Dans notre cas, le LLM est local, la fuite de données n'est donc pas un problème. Cependant, lorsque vous souhaitez utiliser un LLM fonctionnant dans le nuage (par exemple OpenAI), il n'est pas souhaitable d'envoyer des textes contenant des informations PII. Dans un blog ultérieur, nous verrons comment masquer les informations PII avant de les envoyer aux LLM externes dans le flux RAG.

• Dans ce billet, nous avons utilisé un LLM local. Dans le prochain billet sur le masquage des données PII dans RAG, nous verrons comment passer facilement d'un LLM local à un LLM public.