Chaque année, les catastrophes naturelles contraignent les responsables de la gestion des urgences, les commandants militaires et les autorités de sécurité publique à prendre des décisions aux enjeux considérables dans des délais très courts. Ces décisions reposent traditionnellement sur des chaînes d'appel, des feuilles de calcul et des connaissances institutionnelles réparties entre des dizaines de personnes. À elle seule, la surcharge liée à la coordination fait perdre un temps précieux.

Cet article montre comment Elastic permet de disposer d'un système de coordination agentique réactif et autonome pour la réponse aux catastrophes. Ce système détecte une menace, analyse les aspects logistiques et prend des mesures automatiquement. Pour illustrer ce concept, nous avons créé une simulation : un ouragan fictif de catégorie 4 menaçant le littoral de Hampton Roads déclenche le déplacement automatisé de plus de 137 000 personnes réparties sur sept installations militaires.

Avertissement : ceci est un scénario entièrement fictif élaboré à des fins de démonstration. L’ouragan ELARA-26 n’existe pas. Les emplacements des installations reposent sur des données géographiques réelles et accessibles au public issues de l'ensemble de données MIRTA (Military Installations, Ranges and Training Areas) du département de la Défense des États-Unis. Toutes les données opérationnelles, telles que les effectifs, la capacité de logement, les ressources, les adresses e-mail de contact et les profils de mission, sont entièrement fictives. Rien dans cette démonstration ne reflète la préparation opérationnelle, les capacités ou les procédures opérationnelles militaires réelles.

Pourquoi la réponse automatisée aux catastrophes nécessite une coordination géospatiale et agentique

Lorsqu'une catastrophe naturelle menace les infrastructures critiques, le défi de la coordination est immédiat :

• Quelles installations se trouvent dans la zone d'impact ?

• Combien de membres du personnel doivent être déplacés ?

• Où peuvent-ils aller, et ces installations ont-elles la capacité nécessaire ?

• Qui doit être informé immédiatement ?

Ces questions n'attendent pas. Les réponses non plus.

Déploiement du pipeline : prérequis et configuration

Suivez les instructions ici dans le dépôt d'exemples pour déployer un cluster Elastic local avec Elastic Inference Service (EIS) via Cloud Connect.

Fonctionnement du pipeline agentique de réponse aux catastrophes d'Elasticsearch

Le pipeline comporte sept couches qui fonctionnent ensemble de bout en bout :

1. Ingestion de données : les événements de catastrophe du Système mondial d'alerte et de coordination en cas de catastrophe (GDACS) sont envoyés à Elasticsearch.

2. Pipeline d'ingestion : les données GeoJSON sont ingérées et normalisées selon Elastic Common Schema (ECS).

3. Enrichissement géospatial : le polygone de la zone touchée par l'événement est confronté aux limites indexées des installations militaires.

4. Alerting : une règle de détection Kibana se déclenche lorsqu'une catastrophe recoupe une installation.

5. Automatisation du workflow : l'alerte déclenche un workflow Kibana qui lance une conversation avec un agent IA.

6. Raisonnement de l'IA : l'agent analyse les installations concernées, leurs actifs et les installations de soutien les plus proches afin de déterminer la relocalisation de l'ensemble des actifs et du personnel.

7. Notifications par e-mail: l'agent envoie des e-mails à tous les destinataires concernant le personnel et/ou les actifs entrants et sortants.

Passons en revue chaque couche.

Étape 1 : Indexation des installations militaires avec limites géographiques

La base repose sur l'ensemble de données DoD MIRTA provenant de source.coop/seerai/hifld. Cet ensemble fournit une géométrie de type Point pour chaque installation, à savoir des coordonnées de centroïde plutôt que de polygones délimitant l'intégralité du périmètre.

Chaque document d'installation dans l'index 'mitra-facilities' est enrichi de données de profil opérationnel (toutes fictives), au-delà de ce que fournit MIRTA :

C'est cet index riche qui permet à l'agent IA de prendre des décisions d'affectation intelligentes. Il ne s'agit pas simplement d'identifier des bases à proximité, mais de repérer celles qui disposent de capacités de logement disponibles, de types de missions compatibles et de la logistique nécessaire pour accueillir les ressources entrantes.

Étape 2 : Ingestion et normalisation des événements GDACS

GDACS publie des données GeoJSON en temps réel concernant les séismes, les cyclones tropicaux, les inondations, les feux de forêt, les volcans et les sécheresses. Nous intégrons ce flux dans un flux de données (logs-gdacs.events-*) à l'aide d'un pipeline d'ingestion personnalisé qui normalise les données GeoJSON brutes au format de champs ECS.

À noter que le pipeline d'ingestion GDACS effectue plusieurs opérations :

Extraction de la géométrie : le centroïde est stocké sous forme de 'geo_point' pour l'affichage cartographique, et le polygone d'impact est stocké sous forme de 'geo_shape' dans 'gdacs.affected_area', un champ qui sera utilisé ultérieurement pour les requêtes de recoupement.

Normalisation de la gravité : chaque type de catastrophe présente une échelle de gravité différente. Un cyclone tropical se mesure par la vitesse du vent en km/h, tandis qu'un séisme s'évalue selon la magnitude de Richter. Le pipeline convertit toutes ces mesures en un score normalisé allant de 0 à 100 :

Le score de gravité normalisé est ensuite associé à une étiquette de niveau de gravité (faible, moyen, élevé, critique) utilisée pour la correspondance du niveau de gravité de l'alerte dans la règle de détection.

Alignement ECS : event.kind : alerte, event.category : menace, horodatages mappés sur event.start/event.end et un _id stable basé sur une empreinte pour la déduplication.

Étape 3 : Enrichissement géospatial - identifier les installations affectées au moment de l'indexation

La politique d'enrichissement 'geo_match' d'Elasticsearch fait correspondre le polygone de la zone sinistrée à chaque périmètre d'installation lors de l'indexation, sans nécessiter de jointure au moment de la requête. Au lieu d'effectuer une requête lors de la recherche, nous utilisons un processeur d'enrichissement dans le pipeline d'ingestion pour faire correspondre le polygone d'impact de la catastrophe avec chaque limite d'installation au moment où le document est indexé.

La politique d'enrichissement est une politique 'geo_match' :

Le processeur s'exécute à la fin du pipeline d'ingestion :

INTERSECTS permet de détecter toute installation dont la limite touche ou chevauche le polygone de la catastrophe, y compris en cas d'intersection partielle. Par conséquent, chaque document d'événement GDACS est enregistré avec un tableau imbriqué 'affected_facilities' indiquant précisément quelles installations se trouvent dans la zone d'impact. Aucune requête de jointure n'est nécessaire.

Étape 4 : Règle de détection – alerting en cas d'impact sur les installations

Une règle de détection Kibana surveille le flux de données logs-gdacs.events-* et se déclenche lorsqu'un événement GDACS a été enrichi avec au moins une infrastructure affectée :

La règle s'exécute selon une planification horaire (couvrant une fenêtre allant de 'now-1h' à 'now') et utilise une correspondance dynamique de la gravité ; le champ 'gdacs.severity_level', calculé par le pipeline d'ingestion, détermine automatiquement la gravité de l'alerte.

La gravité de l'alerte détermine également le score de risque via le mapping de champs :

Lorsque la règle se déclenche, elle transmet à un workflow Kibana l'intégralité du contexte de l'alerte, y compris le tableau 'affected_facilities' enrichi contenant les noms, types et emplacements des installations.

Étape 5 : Automatisation des workflows – relier l'alerte à l'agent

Les workflows Kibana gèrent la transition entre la détection et la réponse. Le workflow de réponse aux catastrophes naturelles est déclenché par l'alerte :

L'intégralité de la charge utile de l'alerte (type de catastrophe, gravité, zone touchée et liste des installations impactées) est transmise à l'agent IA en tant que contexte initial. L'agent prend ensuite le relais.

Étape 6 : L'agent IA – des données à l'action coordonnée

L'agent mitra.response utilise l'intégralité de la charge utile d'alerte et, au cours d'une seule boucle agentique, évalue le périmètre, trouve les établissements d'accueil, affecte le personnel et envoie des notifications d'évacuation et de prise en charge, le tout sans intervention humaine.

L'agent dispose de deux outils :

• mitra.nearest_facilityinterroge l'index mitra-facilities à l'aide d'une requête geo_shape, triée par distance par rapport à une coordonnée donnée, et renvoie jusqu'à 50 installations actives à proximité disposant de capacités d'accueil.

• mitra.send_email itère sur un tableau JSON d'objets d'installation et transmet des notifications formatées d'évacuation ou de réception.

L'ensemble d'instructions de l'agent définit un workflow clair :

1. Évaluer la situation. Analyser l'alerte, identifier les installations touchées et déterminer l'ampleur de la catastrophe.

2. Faire l'inventaire de ce qui doit être déplacé. Effectifs, ressources critiques, besoins en hébergement par établissement.

3. Rechercher les installations de destination. Appeler mitra.nearest_facility pour chaque installation concernée, en excluant celles qui se trouvent encore dans la zone de danger.

4. Prendre des décisions d'allocation. Raisonner sur les solutions monosite par rapport aux solutions multisites, la compatibilité des branches, la capacité d'hébergement, le support technique des actifs.

5. Envoyer les e-mails de coordination. Transmettre les ordres d'évacuation aux établissements d'origine et les notifications d'admission aux établissements d'accueil.

6. Générer un rapport récapitulatif. Produire un court résumé, à transmettre dans le chat pour examen, de toutes les installations concernées, de l'effectif total, des actifs déplacés, des installations de destination et de toute préoccupation.

La logique d'affectation de l'agent respecte des contraintes réelles : ne pas dépasser la capacité d'hébergement, privilégier les réaffectations au sein d'une même branche lorsque c'est possible, utiliser des bases interarmées pour les excédents multibranches et prioriser la distance afin de minimiser le temps de trajet.

L'outil d'installation la plus proche

La requête de workflow sous-jacente utilise geo_shape avec un filtre de cercle et un tri _geo_distance :

La capacité disponible est calculée au moment de la requête via un champ de script qui soustrait l'effectif actuel de la capacité d'hébergement. L'agent utilise cette information pour répartir le personnel entre les différentes destinations sans dépasser les limites.

Ouragan ELARA-26 : coordination agentique de 137 000 personnes, de bout en bout

L'ouragan ELARA-26 est une tempête de catégorie 4 (vitesse maximale de 213 km/h) dont l'arrivée sur les côtes est prévue dans la région de Hampton Roads, en Virginie. Lors de l'intégration de l'événement GDACS, le polygone de la zone touchée recoupe sept installations militaires majeures de la région. La règle de détection se déclenche. Le workflow initie une conversation entre agents.

Au sein d'une seule boucle agentique, l'agent :

• a identifié sept installations dans la zone d'impact pour un total de 137 372 membres du personnel ;

• a appelé mitra.nearest_facility pour trouver des établissements d'accueil situés en dehors de la trajectoire de la tempête ;

• a réparti le personnel entre neuf établissements d'accueil en fonction de la capacité d'hébergement disponible et de la distance ;

• a généré et envoyé des ordres d'évacuation aux sept installations concernées ;

• a généré et envoyé des notifications d'admission aux neuf installations destinataires ;

• a généré un récapitulatif complet de coordination, semblable à ce qui suit :

Sites évacués :

Installation

Personnel

Base navale de Norfolk

50 000

Base expéditionnaire interarmées Little Creek-Fort Story

18 000

Base aéronavale Oceana

15 355

Annexe Dam Neck de la base aéronavale d'Oceana

17 509

Réserve militaire d'État de la Garde nationale Camp Pendleton

9 707

Base interarmées Langley-Eustis

15 000

Base d'armement naval de Yorktown

11 801

Installations d'accueil :

Installation

Distance

Personnel entrant

Fort Gregg-Adams

97 km

~40 000

Base du Corps des Marines de Quantico

148 km

~30 000

Installation de soutien naval d'Indian Head

151 km

~30 000

Base interarmées Andrews

180 km

~30 000

Base aéronavale de Patuxent River

141 km

~10 000

Camp Butner de la Garde nationale

174 km

~5 000

Site d'entraînement de la Garde nationale Bethany Beach

209 km

~4 707

Base de Rivanna

140 km

~7 500

Centre d'approvisionnement général de la Défense

22 km

~6 000

Les moyens redéployés comprennent des véhicules de transport, des hélicoptères, des patrouilleurs, des unités médicales, des engins du génie, des groupes électrogènes, des remorques-citernes, des kits d'hébergement et des systèmes de communication.

Notifications par e-mail automatisées

Une fois son plan d'affectation finalisé, l'agent a appelé mitra.send_email et a envoyé 16 e-mails en une seule opération : des ordres d'évacuation destinés aux sept installations concernées et des avis d'admission adressés aux neuf établissements d'accueil. Chaque message précisait l'établissement de destination, le nombre de personnes transférées, les ressources à déplacer ainsi qu'un contact de coordination. Ce qui aurait nécessité des heures de chaînes d'appels téléphoniques a été accompli automatiquement dès que l'agent a achevé son raisonnement.

Extension de la réponse agentique aux catastrophes avec la RAG et l'ancrage des politiques

Cette démo repose uniquement sur des données structurées, telles que les capacités, les distances et l'état opérationnel. Les fonctionnalités de recherche sémantique et de génération augmentée par récupération (RAG) d'Elastic contribuent à rendre l'agent nettement plus intelligent, grâce à deux ajouts :

Récupération des réponses historiques : indexation des anciens rapports post-intervention, des résumés d'incidents de l'Agence fédérale de gestion des urgences (FEMA) et des archives de réponse aux catastrophes sous forme d'embeddings vectoriels. Lorsqu'un nouvel événement se déclenche, l'agent peut effectuer une recherche sémantique sur la manière dont des événements similaires ont été traités, afin d'éclairer les décisions d'allocation grâce aux connaissances institutionnelles plutôt qu'aux seuls calculs de capacité.

Ancrage dans les politiques et la doctrine : indexation des directives de gestion des urgences du DoD, des plans de continuité des opérations des installations et des orientations du commandement. L'agent peut récupérer et citer les politiques réelles régissant une réponse, garantissant ainsi que chaque décision est fondée sur la doctrine plutôt que sur une inférence.

Ces deux fonctionnalités suivent la même approche Elastic native : un pipeline d'inférence génère des embeddings au moment de l'indexation, et un outil de recherche sémantique est exposé à l'agent. Le pipeline de coordination reste le même. L'agent devient simplement plus intelligent.

Pourquoi Elasticsearch est la plateforme idéale pour la réponse agentique dans le secteur public

Ce n'est pas un chatbot. Ce n'est pas un tableau de bord. C'est un système de workflow agentique réactif, lequel a détecté une menace, analysé un problème logistique complexe et coordonné le déplacement de 137 000 personnes sans intervention humaine. Ce type de résultat n'est possible que parce que chaque fonctionnalité dont il dépend repose sur une plateforme unique et unifiée.

La prise en charge géospatiale d'Elasticsearch (geo_point, geo_shape, stratégies d'enrichissement et tri basé sur la distance) gère le raisonnement spatial qui rend possibles la détection des recoupements et la recherche d'installations à grande échelle. La recherche sémantique et les embeddings vectoriels ancrent les agents dans la réalité, garantissant que le raisonnement de l'IA repose sur ce qui se trouve réellement dans vos données plutôt que sur des hypothèses hallucinées. Le moteur de détection de Kibana, Workflows, Agent Builder et les outils d'Agent Builder connectent l'ensemble au sein d'un pipeline allant de l'événement brut à l'action coordonnée, sans nécessiter le moindre code de liaison externe.

Aucune autre plateforme ne réunit ces capacités comme le fait Elastic. L'alliance de l'indexation en temps réel, de la précision géospatiale, de la recherche sémantique et de l'orchestration par agents, le tout au sein d'une même pile technologique intégrant sécurité et observabilité de niveau entreprise, distingue Elastic des outils qui excellent dans un seul de ces domaines tout en vous obligeant à assembler vous-même les autres éléments.

Réponse géospatiale agentique pour la gestion des urgences, les services d'incendie, les forces de l'ordre et la santé publique

La même architecture s'applique partout où les personnes, les installations, et les événements en temps réel se recoupent. Les données spécifiques changent. Le pipeline ne change pas.

Gestion des urgences : la FEMA et les services de gestion des urgences des États peuvent cartographier l'emplacement des abris, les zones de déploiement et les populations vulnérables en regard des polygones de conditions météorologiques extrêmes émis par le National Weather Service (NWS), déclenchant ainsi le prépositionnement automatisé des ressources avant qu'une tempête ne touche terre.

Services d'incendie et de secours d'urgence : les services d'incendie peuvent superposer l'emplacement des unités et les zones d'intervention aux périmètres des feux de forêt ou aux clusters d'incendies de structures, en acheminant automatiquement les demandes d'entraide vers les unités disponibles les plus proches dotées de l'équipement adapté.

Forces de l'ordre : les organismes peuvent corréler les lieux d'incidents en cours avec les zones scolaires, les infrastructures critiques et la position des agents, déclenchant ainsi des notifications de confinement géolocalisées ou le déploiement de ressources sans attendre un tri manuel.

Sécurité des établissements scolaires : les districts scolaires peuvent monitorer les flux de menaces en temps réel par rapport au périmètre des campus. Lorsqu'une menace franchit le périmètre d'une école, un agent peut immédiatement avertir l'administration, déclencher les communications de confinement et coordonner la réponse des forces de l'ordre, avant même qu'un coordinateur ne décroche son téléphone.

Santé publique : les services de santé peuvent comparer les données de surveillance des maladies ou les zones de risques environnementaux avec les emplacements des établissements de soin, les couches de densité de population et les inventaires des dépôts de fournitures afin d'acheminer les ressources là où elles sont le plus nécessaires.

Secteur

Cas d'utilisation

Capacité Elastic

Gestion des urgences

Croiser les emplacements des abris aux polygones de phénomènes météorologiques violents du NWS

Enrichissement geo_shape + workflows Kibana

Incendie et SMU

Superposer les emplacements des unités aux périmètres des feux de forêt

Routage géospatial + requête de recherche de l'installation la plus proche

Application de la loi

Corréler les incidents avec les zones scolaires et les positions des agents

Règles d'alerte tenant compte de la géolocalisation + répartition des agents

Sécurité des établissements scolaires

Monitorer les flux de menaces par rapport aux périmètres de campus

Règles de détection + notification automatisée

Santé publique

Croiser les zones de danger avec les emplacements des établissements de soin et les dépôts de ravitaillement

Recherche sémantique + enrichissement géospatial

Les données varient selon les scénarios, mais le schéma sous-jacent reste identique : ingestion, enrichissement lors de l'indexation, détection des recoupements, déclenchement d'une réponse agentique et exécution de l'action. Elastic fournit aux organismes du secteur public une plateforme permettant de concevoir cette solution une seule fois et de l'adapter partout.

La publication et la date de publication des fonctionnalités ou fonctions décrites dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.

Nous avons récemment contribué au projet open source mastra-ai/mastra en ajoutant la prise en charge d'Elasticsearch en tant que base de données vectorielle. Avec cette nouvelle option, vous avez la possibilité d’utiliser Elasticsearch de manière native au sein de Mastra pour le stockage de vos plongements sémantiques. En plus des vecteurs, Elasticsearch propose une suite de fonctionnalités avancées pour répondre à toutes vos exigences en matière d’ingénierie de contexte. (par exemple, recherche hybride et reclassement).

Cet article détaille la création d'un agent chargé de mettre en œuvre une architecture RAG (Retrieval Augmented Generation) à l'aide d'Elasticsearch. Nous présenterons un projet de démonstration dans lequel une approche agentique est utilisée pour interagir avec un corpus de données de films de science-fiction stockées dans Elasticsearch. Le projet est disponible à l’adresse elastic/mastra-elasticsearch-example.

Mastra

Mastra est un framework TypeScript qui permet de créer des applications d'IA agentiques.

La structure du projet dans Mastra se présente comme suit :

Dans Mastra, vous pouvez créer des agents, outils, workflows et scores.

Un agent est une classe qui accepte un message en entrée et produit une réponse en sortie. Un agent peut utiliser des outils, de grands modèles de langage (LLM) et une mémoire (figure 1).

Les outils d’un agent lui permettent d’interagir avec le « monde extérieur », par exemple en communiquant avec une API Web ou en effectuant une opération interne, comme l’interrogation d’Elasticsearch. Le composant mémoire est crucial pour stocker l'historique des conversations, y compris les entrées et sorties passées. Ce contexte stocké permet à l’agent de fournir des réponses plus éclairées et pertinentes aux questions futures en utilisant ses interactions passées.

Les workflows permettent de définir des séquences complexes de tâches en utilisant des étapes claires et structurées, plutôt que de se fier au raisonnement d’un seul agent (figure 2). Ils vous donnent un contrôle total sur la manière dont les tâches sont décomposées, comment les données circulent entre elles et ce qui est exécuté à chaque fois. Les workflows s'exécutent en utilisant le moteur d'exécution intégré par défaut ou peuvent être déployés sur des workflow runners.

Dans Mastra, vous pouvez également définir des scores : des tests automatisés qui évaluent les sorties des agents à l'aide de méthodes basées sur des modèles, des règles et des statistiques. Les scoreurs renvoient des scores : des valeurs numériques (généralement entre 0 et 1) qui quantifient dans quelle mesure une sortie répond à vos critères d'évaluation. Ces scores vous permettent de suivre objectivement les performances, de comparer différentes approches et d'identifier les domaines à améliorer dans vos systèmes d'IA. Les évaluateurs peuvent être personnalisés avec vos propres invites et fonctions de notation.

Elasticsearch

Pour exécuter le projet de démonstration, nous devons avoir une instance Elasticsearch en cours d'exécution. Vous pouvez activer un essai gratuit sur Elastic Cloud ou l’installer localement en utilisant le script start-local :

Cela installera Elasticsearch et Kibana sur votre ordinateur et générera une clé API à utiliser pour configurer l’intégration Mastra.

La clé API sera affichée comme sortie de la commande précédente et stockée dans un fichier .env dans le dossier elastic-start-local.

Installation et configuration de la démo

Nous avons créé un dépôt elastic/mastra-elasticsearch-example contenant le code source du projet de démonstration. L'exemple rapporté dans le référentiel illustre comment créer un agent dans Mastra qui implémente une architecture RAG pour récupérer des documents depuis Elasticsearch.

Nous avons fourni un ensemble de données pour la démo sur les films de science-fiction. Nous avons extrait 500 films de l'ensemble de données IMDb sur Kaggle.

La première étape consiste à installer les dépendances du projet avec npm, en utilisant la commande suivante :

Ensuite, nous devons configurer le fichier .env qui contiendra les paramètres. Nous pouvons générer ce fichier en copiant la structure du fichier .env.example, à l'aide de la commande suivante :

Nous pouvons maintenant modifier le fichier .env, en ajoutant les informations manquantes :

Le nom de l’index Elasticsearch est scifi-movies. Si vous le souhaitez, vous pouvez le modifier en utilisant la variable env ELASTICSEARCH_INDEX_NAME.

Nous avons utilisé OpenAI comme service d’intégration, ce qui signifie que vous devez fournir une clé API pour OpenAI dans la variable OPENAI_API_KEY environnement.

Le modèle de plongement utilisé dans l'exemple est openai/text-embedding-3-small, avec une dimension de plongement de 1536.

Pour obtenir la réponse finale, nous avons utilisé le modèle openai/gpt-5-nano afin de réduire les coûts.

La structure RAG autorise l’usage d’un LLM moins sophistiqué en bout de chaîne, puisque la mission critique d’ancrage de la réponse dans des données fiables est assurée en amont par le moteur de recherche (Elasticsearch).

Le LLM plus petit n'est responsable que de deux tâches principales :

• Reformuler/intégrer la requête : conversion de la question en langage naturel de l'utilisateur en une question vectorielle intégrée pour la recherche sémantique.

• Synthétiser la réponse : prendre les éléments contextuels (documents/films) les plus pertinents récupérés et les synthétiser pour obtenir une réponse cohérente, finale et lisible par l'homme, en suivant les instructions rapides fournies.

Puisque le processus RAG fournit le contexte factuel précis nécessaire à la réponse, le LLM final n’a pas besoin d’être massif ou extrêmement complexe, et il n’est pas nécessaire qu’il possède toutes les connaissances requises au sein de ses propres paramètres (domaine où excellent les modèles volumineux et coûteux). Il agit essentiellement comme un outil sophistiqué de résumé et de formatage de texte pour le contexte fourni par Elasticsearch, plutôt que comme une base de connaissances à part entière. Cela permet l’utilisation de modèles comme gpt-5-nano pour l’optimisation des coûts et de la latence.

Après la configuration du fichier .env , vous pouvez ingérer les films dans Elasticsearch à l'aide de la commande suivante :

Vous devriez obtenir la sortie suivante :

Le mapping de l’index des films de science-fiction contient les champs suivants :

• plongement, vecteur dense de dimension 1536, similarité cosinus.

• description, texte contenant la description du film.

• réalisateur, texte contenant le nom du réalisateur.

• titre, texte contenant le titre du film.

Nous avons généré les vecteurs d'inclusion en utilisant le titre et la description. Puisque le titre et la description sont deux champs distincts, la concaténation des deux garantit que le vecteur d’inclusion résultant capture à la fois l’identité spécifique et unique (titre) et le contexte descriptif riche (description) du film, conduisant à des résultats de recherche sémantiques plus précis et complets. Cette entrée combinée donne au modèle d'intégration une meilleure représentation unique du contenu du document pour le rapprochement par similarité.

Exécutez la démo

Vous pouvez exécuter la démo avec la commande suivante :

Cette commande lancera une application web à localhost :4111 pour accéder à Mastra Studio (figure 3).

Mastra Studio offre une interface utilisateur interactive pour construire et tester vos agents, ainsi qu'une API REST qui expose votre application Mastra en tant que service local. Cela vous permet de commencer à construire immédiatement sans vous soucier de l'intégration.

Nous avons fourni un agent Elasticsearch qui utilise l'outil createVectorQueryTool de Mastra comme outil pour exécuter une recherche sémantique à l'aide d'Elasticsearch. Cet agent utilise l'approche RAG pour rechercher des documents pertinents (c'est-à-dire des films) pour répondre à la question de l'utilisateur.

Cet agent utilise la consigne suivante :

Si vous cliquez sur le menu Mastra Studio > Agents et sélectionnez Agent Elasticsearch, vous pouvez tester l’agent via un système de chat. Par exemple, vous pouvez demander des informations sur les films de science-fiction en posant la question suivante :

Trouvez 5 films ou séries télévisées sur les OVNI.

Vous remarquerez que l’agent exécutera le vectorQueryTool. Vous pouvez cliquer sur l'outil invoqué pour voir l'entrée et la sortie. À la fin de l’exécution, le LLM répondra à votre question, compte tenu du contexte issu de l’index des films de science-fiction d’Elasticsearch (figure 4).

Mastra exécute les étapes suivantes en interne :

1. Conversion vectorielle : La question de l'utilisateur, trouvez 5 films ou séries télévisées sur les OVNI, est convertie en une intégration vectorielle à l'aide du modèle openai/text-embedding-3-small d'OpenAI.

2. Recherche vectorielle : ce plongement sémantique sert alors à effectuer une requête au sein d’Elasticsearch par le biais d’une recherche vectorielle.

3. Récupération des résultats : Elasticsearch renvoie un ensemble de 10 films très pertinents par rapport à la requête (c'est-à-dire ceux dont les vecteurs sont les plus proches du vecteur de la requête de l'utilisateur).

4. Génération de réponses : Les films récupérés et la question originale de l'utilisateur sont envoyés au LLM, en particulier à openai/gpt-5-nano. Le LLM traite ces informations et génère une réponse finale, en s'assurant que la demande de l'utilisateur pour cinq résultats est satisfaite.

L'agent Elasticsearch

Ici, nous avons rapporté le code source d'Elasticsearch Agent.

L'outil vectorQueryTool est l'outil invoqué pour mettre en œuvre la partie extraction de l'exemple RAG. Il utilise l’implémentation ElasticSearchVector qu’Elastic a apportée à Mastra.

L’agent est une instance de la classe agent qui utilise le vectorQueryTool, l’invite et un composant de mémoire. On remarque que le code nécessaire pour l’interconnexion entre Elasticsearch et un agent est extrêmement réduit.

Conclusion

Cet article a mis en lumière la facilité et l'efficacité de l'association entre Elasticsearch et la structure Mastra pour développer des solutions d'IA agentiques avancées. Nous avons plus spécifiquement exploré la conception d’un agent RAG pouvant mener des recherches sémantiques sur un ensemble de données relatives à des films de science-fiction indexés sous Elasticsearch.

L’un des enseignements majeurs réside dans la contribution directe d’Elastic à la communauté Mastra, permettant d’intégrer nativement Elasticsearch comme magasin de vecteurs. Cette intégration réduit considérablement la barrière à l'entrée, comme le montre le code source de l'agent Elasticsearch. En utilisant ElasticSearchVector et createVectorQueryTool, la configuration complète pour connecter Elasticsearch à votre agent ne nécessite qu'un nombre minimal de lignes de code de configuration.

Elasticsearch propose plusieurs fonctionnalités avancées pour améliorer la pertinence des résultats. Par exemple, la recherche hybride améliore considérablement la précision en combinant la recherche lexicale et la recherche vectorielle. Une autre fonctionnalité intéressante est le reranking utilisant les derniers modèles Jina qui peuvent être appliqués à la fin de la recherche hybride. Pour en savoir plus sur ces techniques, consultez les articles suivants d'Elasticsearch Labs :

• Recherche hybride Elasticsearch par Valentin Crettaz

• Présentation des modèles Jina, de leurs fonctionnalités et de leurs cas d'usage dans Elasticsearch par Scott Martens

Nous vous encourageons également à explorer l’exemple fourni et à commencer à créer vos propres agents alimentés par les données avec Mastra et Elasticsearch. Pour plus d'informations sur Mastra, vous pouvez consulter la documentation officielle ici.

Dans cet article, nous examinerons les avantages de la création d’un serveur MCP Elasticsearch personnalisé et expliquerons comment en créer un en TypeScript pour connecter Elasticsearch aux applications alimentées par des modèles LLM.

Pourquoi créer un serveur Elasticsearch MCP personnalisé ?

Elastic propose quelques alternatives pour les serveurs MCP :

• Serveur MCP Elastic Agent Builder pour Elasticsearch 9.2+

• Serveur MCP Elasticsearch pour les anciennes versions (Python)

Si vous avez besoin de plus de contrôle sur la façon dont votre serveur MCP interagit avec Elasticsearch, la création de votre propre serveur personnalisé vous donne la flexibilité de l'adapter exactement à vos besoins. Par exemple, le point de terminaison MCP d'Agent Builder est limité aux requêtes du langage de requête Elasticsearch (ES|QL), tandis qu'un serveur personnalisé vous permet d'utiliser le langage de requête DSL complet. Vous gagnez également le contrôle sur la façon dont les résultats sont formatés avant d'être transmis au LLM et pouvez intégrer des étapes de traitement supplémentaires, comme la summarisation alimentée par OpenAI que nous mettrons en œuvre dans ce tutoriel.

À la fin de cet article, vous aurez un serveur MCP dans TypeScript qui recherche les informations stockées dans un index Elasticsearch, les résume et fournit des citations. Nous utiliserons Elasticsearch pour la récupération, le modèle gpt-4o-mini d'OpenAI pour résumer et générer des citations, et Claude Desktop comme client MCP et interface utilisateur pour recevoir les requêtes des utilisateurs et fournir des réponses. Le résultat final est un assistant de connaissances interne qui aide les ingénieurs à découvrir et à synthétiser les bonnes pratiques dans l'ensemble de la documentation technique de leur organisation.

Produits requis

• Node.js 20 +

• Elasticsearch

• Clé API OpenAI

• Claude Desktop

Qu'est-ce que le MCP ?

MCP est une norme ouverte, créée par Anthropic, qui fournit des connexions bidirectionnelles sécurisées entre les LLM et les systèmes externes, comme Elasticsearch. Vous pouvez en savoir plus sur l'état actuel du MCP dans cet article.

Le paysage des MCP évolue chaque jour, avec des serveurs disponibles pour un large éventail de cas d'utilisation. De plus, il est facile de créer votre propre serveur MCP personnalisé, comme nous le montrerons dans cet article.

Clients MCP

Il existe une longue liste de clients MCP disponibles, chacun ayant ses propres caractéristiques et limitations. Par souci de simplicité et de popularité, nous utiliserons Claude Desktop comme client MCP. Il servira d'interface de chat où les utilisateurs pourront poser des questions en langage naturel, et il invoquera automatiquement les outils exposés par notre serveur MCP pour rechercher des documents et générer des résumés.

Créer un serveur Elasticsearch MCP

Grâce au SDK TypeScript, nous pouvons facilement créer un serveur qui comprend comment interroger nos données Elasticsearch à partir d'une requête utilisateur.

Voici les étapes dans cet article pour intégrer le serveur Elasticsearch MCP avec le client Claude Desktop :

1. Configurer le serveur MCP pour Elasticsearch.

2. Chargez le serveur MCP dans Claude Desktop.

3. Testez-le.

Configurez le serveur MCP pour Elasticsearch

Pour commencer, initialisons une application Node :

Cela créera un fichier package.json, et avec lui, nous pourrons commencer à installer les dépendances nécessaires pour cette application.

• @elastic/elasticsearch nous donnera accès à la bibliothèque de Node.js Elasticsearch.

• @modelcontextprotocol/sdk fournit les outils du noyau pour créer et gérer un serveur MCP, enregistrer les outils et gérer la communication avec les clients MCP.

• OpenAI permet d'interagir avec les modèles OpenAI pour générer des résumés ou des réponses en langage naturel.

• ZODaide à définir et valider des schémas structurés pour les données d’entrée et de sortie dans chaque outil.

ts-node, @types/node et typescript seront utilisés pendant le développement pour écrire le code et compiler les scripts.

Configurer l’ensemble de données

Pour fournir les données que Claude Desktop peut interroger via notre serveur MCP, nous utiliserons un ensemble de données simulé de base de connaissances interne. Voici à quoi ressemblera un document issu de cet ensemble de données :

Pour ingérer les données, nous avons préparé un script qui crée un index dans Elasticsearch et y charge l’ensemble de données. Vous pouvez le trouver ici.

Serveur MCP

Créez un fichier nommé index.ts et ajoutez le code suivant pour importer les dépendances et gérer les variables d’environnement :

Aussi, initialisons les clients pour gérer les appels Elasticsearch et OpenAI :

Pour rendre notre implémentation plus robuste et garantir des entrées et des sorties structurées, nous définirons des schémas en utilisant zod. Cela nous permet de valider les données au moment de l'exécution, de détecter les erreurs tôt et de rendre les réponses des outils plus faciles à traiter de manière programmatique :

Pour en savoir plus sur les sorties structurées, cliquez ici.

Maintenant, initialisons le serveur MCP :

Définition des outils MCP

Une fois que tout est configuré, nous pouvons commencer à écrire les outils qui seront exposés par notre serveur MCP. Ce serveur expose deux outils :

• search_docs: Recherche des documents dans Elasticsearch à l'aide de la recherche full-text.

• summarize_and_cite: Résume et synthétise les informations provenant de documents précédemment récupérés pour répondre à la question d'un utilisateur. Cet outil ajoute également des citations faisant référence aux documents sources.

Ensemble, ces outils forment un workflow simple de « récupération puis synthèse », où un outil extrait les documents pertinents et l'autre utilise ces documents pour générer une réponse synthétisée et citée.

Format de réponse de l'outil

Chaque outil peut accepter des paramètres d'entrée arbitraires, mais il doit répondre avec la structure suivante :

• Contenu : il s'agit de la réponse de l'outil dans un format non structuré. Ce champ est généralement utilisé pour renvoyer du texte, des images, de l’audio, des liens ou des plongements. Pour cette application, il sera utilisé pour renvoyer un texte formaté contenant les informations générées par les outils.

• structuredContent : il s'agit d'un retour facultatif utilisé pour fournir les résultats de chaque outil dans un format structuré. Ceci est utile à des fins de programmation. Bien qu'il ne soit pas utilisé dans ce serveur MCP, il peut être utile si vous souhaitez développer d'autres outils ou traiter les résultats de manière programmée.

En gardant cette structure à l’esprit, entrons dans le vif du sujet en examinant chaque outil en détail.

Outil de recherche

Cet outil effectue une recherche full-text dans l’index Elasticsearch pour récupérer les documents les plus pertinents selon la requête de l’utilisateur. Il met en évidence les correspondances clés et offre un aperçu rapide avec des scores de pertinence.

Nous configurons fuzziness: “AUTO” pour que la tolérance aux fautes de frappe soit variable en fonction de la longueur du jeton analysé. Nous configurons également title^2 pour qu'il augmente le score des documents dont la correspondance se fait sur le champ du titre.

outil summarize_and_cite

Cet outil génère un résumé basé sur les documents récupérés lors de la recherche précédente. Il utilise le modèle gpt-4o-mini d’OpenAI pour synthétiser les informations les plus pertinentes afin de répondre à la question de l’utilisateur, en fournissant des réponses dérivées directement des résultats de recherche. Outre le résumé, il renvoie également les métadonnées de citation des documents sources utilisés.

Enfin, il faut démarrer le serveur avec stdio. Cela signifie que le client MCP communiquera avec notre serveur en lisant et en écrivant dans ses flux d'entrée et de sortie standard. StDIO est l’option de transport la plus simple et fonctionne bien pour les serveurs MCP locaux lancés en sous-processus par le client. Ajoutez le code suivant à la fin du fichier :

Compilez le projet en utilisant la commande suivante :

Cela créera un dossier dist, dans lequel se trouvera un fichier index.js.

Chargez le serveur MCP dans Claude Desktop.

Suivez ce guide pour configurer le serveur MCP avec Claude Desktop. Dans le fichier de configuration Claude, nous devons définir les valeurs suivantes :

La valeur args doit pointer vers le fichier compilé dans le dossier dist . Vous devez également définir les variables d'environnement dans le fichier de configuration avec les noms exacts définis dans le code.

Testez-le

Avant d’exécuter chaque outil, cliquez sur Recherche et Outils pour vous assurer que les outils sont activés. Vous pouvez également activer ou désactiver chaque option ici :

Enfin, testons le serveur MCP depuis le chat Claude Desktop et commençons à poser des questions :

Pour la question « Recherche de documents sur les méthodes d’authentification et le contrôle d’accès basé sur les rôles », l’outil search_docs est exécuté et renvoie les résultats suivants :

La réponse est : « Super ! J'ai trouvé 5 documents pertinents sur les méthodes d'authentification et le contrôle d'accès basé sur les rôles. Voici ce qui a été découvert : »

L'appel d'outil renvoie les documents sources dans le cadre de sa charge utile de réponse, qui sont ensuite utilisés pour générer des citations.

Il est également possible d'enchaîner plusieurs outils dans une même interaction. Dans ce cas, Claude Desktop analyse la question de l’utilisateur et détermine qu’il doit d’abord appeler search_docs pour récupérer les documents pertinents, puis transmettre ces résultats à summarize_and_cite pour générer la réponse finale, le tout sans nécessiter d’invites séparées de la part de l’utilisateur :

Dans ce cas, pour la requête « Quelles sont les principales recommandations pour améliorer l’authentification et le contrôle d’accès dans l’ensemble de nos systèmes ? Veuillez inclure des références. », Nous avons obtenu les résultats suivants :

Comme à l’étape précédente, nous pouvons voir la réponse de chaque outil à cette question :

Note : Si un sous-menu apparaît demandant si vous approuvez l’utilisation de chaque outil, sélectionnez Toujours autoriser ou Permettre une fois.

Conclusion

Les serveurs MCP représentent une étape importante vers la standardisation des outils LLM pour les applications locales et distantes. Bien que la compatibilité totale soit encore en cours de développement, nous avançons rapidement dans cette direction.

Dans cet article, nous avons appris à créer un serveur MCP personnalisé en TypeScript qui connecte Elasticsearch aux applications basées sur LLM. Notre serveur propose deux outils : search_docs pour récupérer les documents pertinents à l'aide de Query DSL ; et summarize_and_cite pour générer des résumés avec des citations via des modèles OpenAI et Claude Desktop comme interface utilisateur client.

L'avenir de la compatibilité entre les différents fournisseurs côté client et côté serveur semble prometteur. Les prochaines étapes consistent à ajouter davantage de fonctionnalités et de flexibilité à votre agent. Vous trouverez un article pratique expliquant comment paramétrer vos requêtes à l'aide de modèles de rechercher pour gagner en précision et en flexibilité.

Ce billet se concentre sur la question suivante : quelles sont les bonnes interfaces de recherche dont un agent a besoin pour construire son propre contexte ? Il couvre d'abord les compromis entre les outils de shell et les outils de base de données dédiés. Il propose ensuite un framework pratique pour trouver les interfaces adaptées aux besoins de votre agent.

Que signifie concrètement pour un agent le terme « contexte de construction » ?

Dans les premiers pipelines de Retrieval-Augmented Generation (RAG), le développeur concevait un pipeline de recherche fixe, et le grand modèle de langage (LLM) était un récepteur passif du contexte. C'était une limitation fondamentale : le contexte était récupéré à chaque requête, qu'il soit nécessaire ou non, sans vérification qu'il aidait réellement.

Avec le passage au RAG agentique, les agents ont désormais accès à un ensemble d’outils de recherche pour construire leur propre contexte. Par exemple, Claude Code [1] et Cursor [2] permettent tous deux à l’agent de choisir entre différents outils de recherche et même de les combiner pour des requêtes chaînées, en fonction de ce que la tâche exige réellement.

Quelles interfaces de recherche existent pour l'ingénierie contextuelle ?

Le contexte peut se trouver à différents endroits, par exemple sur le Web, dans un système de fichiers local ou dans une base de données. Un agent peut interagir avec chacune de ces sources de données hors contexte à l'aide de différents outils :

• Les outils Shell peuvent exécuter des commandes shell et accéder au système de fichiers local. Quelques exemples d’outils shell intégrés sont l’outil bash de Claude API, l’outil exécutif d’OpenClaw, et l’outil shell de LangChain.

• Les outils de base de données dédiés, tels que les outils d’un serveur Model Context Protocol (MCP) (par exemple, le serveur MCP Elastic Agent Builder) ou les outils personnalisés (par exemple, run_esql(query) ou db_list_index()), peuvent interroger les bases de données.

• Les outils de recherche de fichiers dédiés peuvent rechercher et lire des fichiers locaux (ou téléchargés) (sans accès complet au shell). Quelques exemples d'outils de recherche de fichiers intégrés sont l'outil de recherche de fichiers de Gemini API ou l'outil de recherche de fichiers d'OpenAI.

• Les outils de recherche Web peuvent extraire des informations du web.

• Les outils de mémoire stockent et rappellent la mémoire à long terme (quelle que soit la manière dont elle est stockée).

Comme vous pouvez le voir, l’outil shell est polyvalent et peut être utilisé pour récupérer du contexte à partir de différentes sources de données, notamment :

• Système de fichiers : l'agent explore la structure des répertoires (ls, find), recherche le contenu pertinent (grep, cat) et répète l'opération jusqu'à ce qu'il ait construit un contexte suffisant.

• Base de données : l’agent peut utiliser des outils d’interface en ligne de commande (CLI) de base de données (par exemple, elasticsearch-sql-cli), appeler des API HTTP via curl, ou exécuter des scripts, ce qui est particulièrement utile en combinaison avec les compétences de l’agent, qui sont des exemples réutilisables et documentés injectés dans le contexte de l’agent pour guider l’utilisation correcte des outils (par exemple, Elastic Agent Skills pour Elasticsearch).

• Web : l’agent peut exécuter des recherches web via une commande curl à travers l’API d’un fournisseur de recherche.

Cependant, l'outil shell fournit un accès système direct et nécessite donc des mesures de sécurité, telles que l'exécution dans un environnement sandbox isolé et le logging de toutes les commandes exécutées.

Quand utiliser quelles interfaces de recherche

L'interface de recherche appropriée dépend de vos données, de vos modèles de requête et de votre cas d'utilisation. Cette section constitue un point de départ pratique.

Les systèmes de fichiers ne rendent pas les bases de données obsolètes

Le débat entre systèmes de fichiers et bases de données ne porte pas sur la couche de stockage. Par exemple, LangChain explique que son système de mémoire ne stocke pas réellement la mémoire dans un véritable système de fichiers. Au lieu de cela, il stocke la mémoire dans une base de données et la représente sous la forme d'un ensemble de fichiers pour l'agent [3].

Les systèmes de fichiers sont particulièrement adaptés aux cas d'utilisation natifs basés sur les fichiers, tels que les agents de codage. Ils fonctionnent également bien comme bloc-notes temporaire ou mémoire de travail pour les scénarios à utilisateur unique ou à agent unique où la concurrence n'est pas une préoccupation. Dans ces cas, un système de fichiers physique ou la représentation des données sous forme de système de fichiers vous offre une certaine flexibilité avant de vous engager dans une interface dédiée.

Mais le stockage par système de fichiers présente de réels inconvénients, tels qu'une faible concurrence, l'application manuelle du schéma et les transactions atomiques. Ces problèmes deviennent plus évidents lorsque votre application doit scaler ou passer à un scénario multi-agents. Quiconque ignore ces inconvénients est condamné à réinventer péniblement des bases de données de moindre qualité, sans bénéficier des décennies d'ingénierie qui sous-tendent la sécurité des transactions ou le contrôle d'accès que les bases de données de production offrent déjà. De plus, dans la plupart des contextes d'entreprise, on ne choisit pas d'utiliser ou non une base de données puisqu'elle est déjà en place et stocke des données essentielles à l'activité.

Outil shell + système de fichiers

Un outil shell est le point de départ naturel pour la recherche dans le système de fichiers. Actuellement, les agents de codage sont à l'origine de nombreux progrès dans le champ. Parce qu'ils travaillent avec du code dans des fichiers locaux, ce sont naturellement des cas d'utilisation gourmands en fichiers. Par conséquent, les LLM sont affinés lors de la phase de post-entraînement pour les tâches de codage. C'est pourquoi de nombreux LLM savent non seulement écrire du code, mais aussi utiliser des commandes shell et naviguer dans les systèmes de fichiers.

L'utilisation d'un outil shell avec des CLI intégrées, comme ls et grep, pour rechercher des fichiers est efficace. Avec grep, une requête comme « Trouver tous les fichiers qui importent matplotlib» est rapide, précise et peu coûteuse. Mais lorsque l'agent doit gérer des requêtes conceptuelles, comme « Comment notre application gère-t-elle une authentification défaillante ? », La correspondance de motifs avec grep peut rapidement atteindre ses limites. Plusieurs alternatives qui apportent des capacités de recherche sémantique à la ligne de commande ont émergé pour combler ce manque, notamment jina-grep.

Cependant, grep et plusieurs de ses alternatives de recherche sémantique fonctionnent en O(n) sur le corpus. Pour les cas d'utilisation sur des bases de code, cela peut convenir. Cependant, si vos données s'accumulent, la latence deviendra perceptible. Dans ce cas, un datastore indexé devient nécessaire pour assurer la maintenance des performances.

Outil shell + base de données

Une autre façon d'ajouter des capacités de recherche, telles que la recherche sémantique ou hybride, à vos données est de les stocker dans une base de données, comme le fait Cursor, par exemple. De plus, lorsque les données nécessitent des jointures relationnelles complexes ou des agrégations, une interface de base de données est non négociable.

Lorsque les données se trouvent dans une base de données plutôt que dans le système de fichiers, un outil shell peut servir d'interface de base de données légère pour certains cas d'utilisation. Si vos requêtes sont assez simples pour une interface de ligne de commande ou un appel curl, un outil de base de données dédié peut ajouter de la complexité inutile.

Cette approche est également adaptée aux premières étapes de l’exploration, lorsque vous ne savez pas encore quels modèles de requête votre agent développera réellement. Dans ce cas, les compétences des agents peuvent donner à l’agent suffisamment de structure pour effectuer des requêtes correctement sans avoir recours à un outil spécialement conçu. Cependant, lorsque l'agent doit effectuer de nombreuses itérations pour déterminer la meilleure façon d'interroger la base de données pour des tâches répétitives, la surcharge de jetons associée à l'utilisation d'un outil shell comme interface ne justifie plus l'avantage de simplicité qu'offre l'évitement d'un outil supplémentaire.

Outil de base de données dédié

Des outils de base de données spécialisés deviennent nécessaires, surtout lorsque les modèles de requêtes répétées sont structurés ou analytiques. Un article de blog de Vercel et Braintrust a comparé des agents utilisant différents ensembles d'outils de recherche pour des tâches de récupération réelles sur des données semi-structurées, telles que les tickets de service client et les transcriptions d'appels de vente (par exemple : « Combien de problèmes ouverts mentionnent la « sécurité » ? » ou « Trouver les problèmes où quelqu'un a signalé un bug et où quelqu'un a ensuite soumis une PR prétendant le corriger ? »). [4].

Les agents utilisant des outils de base de données dédiés consommaient moins de jetons, étaient plus rapides et faisaient moins d'erreurs que ceux utilisant uniquement un outil shell et un système de fichiers. La leçon à retenir est que les outils de base de données directs constituent le meilleur choix lorsque la requête exige un raisonnement analytique sur des données semi-structurées.

Combinaison d'interfaces de recherche

Aucune interface de recherche unique ne traite correctement toutes les requêtes. Par exemple, Cursor combine des outils shell (pour les recherches via grep) et des outils de recherche sémantique, et permet à l'agent de sélectionner l'outil approprié en fonction de la requête de l'utilisateur. Ils indiquent que l'agent choisit grep pour faire correspondre des symboles ou des chaînes spécifiques, la recherche sémantique pour les questions conceptuelles ou liées au comportement, et les deux pour les tâches exploratoires.

L'expérience Vercel rapporte la même chose : son agent hybride, ayant accès à la fois à un outil en ligne de commande (shell) et à un outil de base de données dédié, a obtenu les meilleures performances parmi tous les agents testés, en utilisant d'abord les outils de base de données dédiés, puis en vérifiant les résultats en parcourant le système de fichiers avec la commande « grep ». Cependant, cette approche utilise plus de tokens et de temps pour le choix et la vérification des outils.

Le schéma est identique dans les deux exemples : la composition Beats toute interface unique, mais elle implique un compromis en termes de coût et de latence supplémentaires.

Recommandations pratiques pour trouver les bons outils

Le bon ensemble d'interfaces de recherche est restreint, ciblé et spécifique aux schémas de requêtes réels de votre agent. La bonne pratique actuelle est d'avoir un agent avec le moins d'outils possible au lieu d'avoir un agent avec des centaines d'outils MCP. En effet, le fait d'exposer d'emblée tous les outils possibles a pour inconvénient de gonfler la fenêtre contextuelle et d'embrouiller l'agent quant à l'outil à utiliser. Par exemple, Claude Code ne disposerait que d'une vingtaine d'outils.

L'idée de la divulgation progressive est plutôt de commencer avec un ensemble minimal d'outils et de laisser l'agent découvrir des capacités supplémentaires uniquement lorsqu'il en a besoin. Les recherches menées par Anthropic [5] et Cursor [6] ont montré que cette approche permet de réaliser une économie de tokens de 47%–85%. Claude Code, par exemple, implémente cela directement, permettant à l'agent de découvrir progressivement comment interroger une API ou une base de données, sans que cette connaissance ne consomme du contexte à chaque appel de LLM.

Une fois que vous vous êtes familiarisé avec les modèles de requête de l’agent, vous pouvez revoir l’ensemble des outils de recherche auxquels l’agent a accès par défaut. Une façon utile d'envisager ce compromis est le principe « plancher bas, plafond haut » pour décider quels outils doivent être retenus. Les outils à haut plafond ne limitent pas le potentiel de l’agent. Par exemple, un outil shell polyvalent permet à l’agent d’écrire des requêtes de base de données complètes, y compris celles ambiguës, mais au prix d’une surcharge de raisonnement, d’une latence plus élevée et d’une fiabilité moindre.

Les outils à plancher surbaissé sont à l'opposé. Ce sont des outils spécialisés qui répondent à des requêtes spécifiques et sont immédiatement accessibles à l'agent avec un minimum de frais de raisonnement, ce qui permet de réduire les coûts et d'accroître la fiabilité. Mais ils nécessitent un travail d’ingénierie préalable, ne peuvent pas couvrir toutes les requêtes possibles, et peuvent compliquer le choix du bon outil pour l’agent.

Pensez à chaque outil sur un spectre : les outils à seuil bas sont faciles à utiliser correctement par l'agent mais sont limités en portée. Les outils à haut potentiel sont polyvalents, mais nécessitent davantage de réflexion pour être utilisés efficacement.

La plupart des agents ont besoin d'une combinaison de différents outils de recherche. Mais chaque outil doit mériter son ajout. Nous recommandons de commencer par un outil de recherche polyvalent (par exemple un outil search_database() ou un outil shell). Réutilisez ensuite les logs de commandes que vous conservez déjà à des fins de sécurité pour suivre ce que votre agent fait réellement, y compris les appels d’outils, les nouvelles tentatives et le nombre d’appels par requête utilisateur. Et, lorsque vous voyez un modèle de requête se répéter ou échouer, c'est le signal pour créer un outil spécialement conçu à cet effet.

Résumé

Le débat système de fichiers contre base de données détourne l'attention de la véritable question que les ingénieurs doivent se poser : quelles sont les bonnes interfaces de recherche dont un agent a besoin pour construire son propre contexte ? La réponse est, selon toute vraisemblance, pas une seule.

Un outil shell est un outil polyvalent pour interagir avec différentes sources hors contexte et constitue ainsi un bon point de départ. Mais il est moins efficace et précis pour les cas d'utilisation avec des requêtes analytiques structurées que les outils de base de données dédiés.

L'objectif est de trouver l'ensemble minimal d'outils de recherche qui gère bien les modèles de requêtes réels de votre agent. Commencez avec un outil shell, et consignez ce que fait réellement votre agent dans les logs. Lorsque vous constatez qu'un schéma de requête se répète et échoue, il est temps de concevoir des outils spécialisés.

Références

1. Thariq (Anthropic). Leçons tirées de la construction du code Claude : voir comme un agent (2026).

2. Cursor : Documentation. Recherche sémantique et agentique (2026).

3. Harrison Chase (LangChain). Comment nous avons construit le système de mémoire d'Agent Builder (2026).

4. Ankur Goyal (Braintrust) et Andrew Qu (Vercel). Tester si « bash est tout ce dont vous avez besoin » (2026).

5. Anthropic. Présentation de l'utilisation d'outils avancés sur la plateforme de développement Claude (2025).

6. Cursor. Découverte dynamique du contexte (2026).

Produits requis

• Elasticsearch 9.3 ou Elastic Cloud Serverless : vous pouvez créer un déploiement dans le cloud en suivant ces instructions, ou utiliser le démarrage rapide start-local à la place.

• Python 3.12 : téléchargez Python ici.

• Jeton d'accès Hugging Face.

Complétions de chat utilisant un point de terminaison d'inférence Hugging Face

Nous allons d'abord créer un exemple pratique connectant Elasticsearch à un point de terminaison d'inférence Hugging Face afin de générer des recommandations alimentées par l'IA à partir d'une collection d'articles de blog. Pour la base de connaissances de l'application, nous utiliserons un ensemble de données d'articles de blogs d'entreprise, qui contiennent des informations précieuses mais souvent difficiles à consulter.

Avec ce point de terminaison, la recherche sémantique extrait les articles les plus pertinents pour une requête donnée, et un LLM Hugging Face génère de courtes recommandations contextuelles sur la base de ces résultats.

Examinons d'abord les grandes lignes du flux d'informations que nous allons mettre en place :

Dans cet article, nous allons tester la capacité de SmolLM3-3B àà allier sa taille compacte à de puissantes fonctionnalités de raisonnement multilingue et d'appel d'outils. À partir d'une requête de recherche, nous enverrons tous les contenus correspondants (en anglais et en espagnol) au LLM afin de générer une liste d'articles recommandés, accompagnés d'une description personnalisée basée sur la requête et les résultats de recherche.

Voici à quoi pourrait ressembler l'interface utilisateur d'un site d'articles doté d'un système de génération de recommandations par IA.

Vous trouverez la mise en œuvre complète de cette application dans le notebook associé.

Configuration des points de terminaison d’inférence Elasticsearch

Pour utiliser le point de terminaison d'inférence Hugging Face d'Elasticsearch, nous avons besoin de deux éléments importants : une clé API Hugging Face et une URL de point de terminaison Hugging Face en cours d'exécution. Cela devrait ressembler à ceci :

Le point de terminaison d'inférence Hugging Face dans Elasticsearch prend en charge différents types de tâches : text_embedding, completion, chat_completion et rerank. Dans cet article de blog, nous utilisons chat_completion, car nous avons besoin que le modèle génère des recommandations conversationnelles basées sur les résultats de recherche et un prompt système. Ce point de terminaison nous permet d'effectuer des complétions de chat directement depuis Elasticsearch de manière simple grâce à l'API Elasticsearch :

Ceci va constituer le cœur de l'application, recevant la requête et les résultats de recherche qui seront ensuite traités par le modèle. La théorie étant posée, passons à la mise en œuvre de l'application.

Configuration du point de terminaison d'inférence sur Hugging Face

Pour déployer le modèle Hugging Face, nous allons utiliser le service de déploiement en un clic de Hugging Face, une solution simple et rapide pour déployer des points de terminaison de modèles. Notez qu'il s'agit d'un service payant et que son utilisation peut engendrer des coûts supplémentaires. Cette étape créera l'instance du modèle qui servira à générer les recommandations d'articles.

Vous pouvez choisir un modèle dans le catalogue accessible en un clic :

Sélectionnons le modèle SmolLM3-3B :

À partir d'ici, veuillez récupérer l'URL du point de terminaison Hugging Face :

Comme indiqué dans la documentation Elasticsearch relative aux points de terminaison d'inférence Hugging Face, la génération de texte nécessite un modèle compatible avec l'API OpenAI. Pour cette raison, nous devons ajouter le sous-chemin /v1/chat/completions à à l'URL de point de terminaison Hugging Face. Le résultat final ressemblera à ceci :

Une fois ces éléments en place, nous pouvons commencer à coder dans un notebook Python.

Génération de la clé API Hugging Face

Créez un compte Hugging Face et obtenez un jeton API en suivant ces instructions. Vous avez le choix entre trois types de jetons : un jeton granulaire (recommandé pour la production, car il ne donne accès qu'à des ressources spécifiques), un jeton de lecture (pour un accès en lecture seule) ou un jeton d'écriture (pour un accès en lecture et en écriture). Pour ce tutoriel, un jeton de lecture suffit, car nous n'avons besoin d'appeler que le point de terminaison d'inférence. Enregistrez cette clé pour la prochaine étape.

Configuration du point de terminaison d'inférence Elasticsearch

Tout d'abord, déclarons un client Elasticsearch Python :

Ensuite, nous allons créer un point de terminaison d'inférence Elasticsearch qui utilise le modèle Hugging Face. Ce point de terminaison nous permettra de générer des réponses en fonction des articles de blog et du prompt transmis au modèle.

Ensemble de données

L'ensemble de données contient les articles de blog sur lesquels des requêtes seront exécutées ; il s'agit d'un ensemble de contenus multilingues utilisé tout au long du workflow :

Mappings Elasticsearch

Une fois l'ensemble de données défini, nous devons créer un schéma de données adapté à la structure des articles de blog. Les mappings d'index suivants seront utilisés pour stocker les données dans Elasticsearch :

Ici, nous pouvons voir plus clairement comment les données sont structurées. Nous utiliserons la recherche sémantique pour récupérer les résultats basés sur le langage naturel, ainsi que la propriété copy_to pour copier le contenu du champ dans le champ semantic_text. De plus, le champ title contient deux sous-champs : le sous-champ original stocke le titre en anglais ou en espagnol, selon la langue d'origine de l'article, et le sous-champ translated_title n'est présent que pour les articles en espagnol et contient la traduction anglaise du titre original.

Ingestion des données

L'extrait de code suivant ingère l'ensemble de données des articles de blog dans Elasticsearch à l'aide de l'API Bulk :

Maintenant que nous avons intégré les articles dans Elasticsearch, nous devons créer une fonction capable de rechercher dans le champ semantic_text :

Nous avons également besoin d'une fonction qui appelle le point de terminaison d'inférence. Dans ce cas, nous appellerons le point de terminaison en utilisant le type de tâche chat_completionpour obtenir des réponses en streaming :

Nous pouvons maintenant écrire une fonction qui appelle la fonction de recherche sémantique, ainsi que le point de terminaison d'inférence chat_completions et le point de terminaison de recommandations, afin de générer les données qui seront allouées dans les fiches :

Enfin, nous devons extraire les informations et les mettre en forme pour l'impression :

Faisons un test en posant une question sur les articles de blog relatifs à la sécurité :

Nous pouvons voir ici les fiches générées par le workflow dans la console :

Vous trouverez les résultats complets, y compris tous les résultats et la réponse du LLM dans ce fichier.

Nous recherchons des articles portant sur le thème "Security et vulnérabilités". Cette question est utilisée comme requête de recherche sur les documents stockés dans Elasticsearch. Les résultats récupérés sont ensuite transmis au modèle, qui génère des recommandations basées sur leur contenu. Comme nous pouvons le constater, le modèle a parfaitement réussi à générer des textes courts et attrayants qui incitent le lecteur à cliquer dessus.

Conclusion

Cet exemple illustre comment combiner Elasticsearch et Hugging Face pour créer un système centralisé, rapide et performant pour les applications d'IA. Cette approche réduit les interventions manuelles et offre une grande flexibilité grâce au vaste catalogue de modèles de Hugging Face. L'utilisation de SmolLM3-3B, en particulier, montre comment des modèles multilingues compacts peuvent fournir un raisonnement pertinent et une génération de contenu efficace lorsqu'ils sont associés à la recherche sémantique. Ensemble, ces outils constituent une base scalable et performante pour le développement d'applications d'analyse de contenu intelligentes et multilingues.

L'extension est disponible en tant que projet open source ici.

Qu'est-ce que Gemini CLI et comment l'installer ?

Gemini CLI est un agent d’IA open source qui intègre les modèles Gemini de Google directement dans la ligne de commande. Il permet aux développeurs d’interagir avec l’IA depuis le terminal pour effectuer des tâches telles que générer du code, éditer des fichiers, exécuter des commandes shell et récupérer des informations sur le web.

Contrairement aux interfaces de chat classiques, Gemini CLI s'intègre à votre environnement de développement local, ce qui signifie qu'il peut comprendre le contexte du projet, modifier des fichiers, assurer l'exécution des compilations ou des tests et automatiser les workflows directement dans le terminal. Il est donc utile aux développeurs, aux ingénieurs de fiabilité des sites (SRE) et aux ingénieurs qui souhaitent un codage assisté par l'IA et une automatisation sans quitter leur workflow en ligne de commande.

Le CLI Gemini s’installe à l’aide de plusieurs gestionnaires de paquets. La méthode la plus courante passe par npm :

Si vous souhaitez connaître d’autres options d’installation, consultez la page officielle d’installation.

Après l’installation, lancez la CLI en exécutant :

Vous voyez un écran, comme illustré sur la figure 1 :

Configurer Elasticsearch

Nous avons besoin d'une instance Elasticsearch en cours d'exécution. Si vous souhaitez utiliser le serveur Model Context Protocol (MCP), vous devez également installer Kibana 9.3+. Pour utiliser le langage de requête Elasticsearch (ES|QL) (esql) décrit ci-dessous, Kibana n’est pas requise.

Vous pouvez activer un essai gratuit sur Elastic Cloud ou l’installer localement en utilisant le script start-local :

Cela installera Elasticsearch et Kibana sur votre ordinateur et générera une clé API à utiliser pour configurer Gemini CLI.

La clé API sera affichée comme sortie de la commande précédente et stockée dans un fichier .env fichier dans le dossier elastic-start-local.

Si vous utilisez Elasticsearch sur site (par exemple, en utilisant start-local), et que vous souhaitez utiliser Elastic Agent Builder avec MCP, vous devez aussi connecter un grand modèle de langage (LLM). Vous pouvez consulter cette page de documentation pour comprendre les différentes options.

Si vous utilisez Elastic Cloud (ou Elastic Cloud Serverless), vous disposez déjà d’une connexion LLM préconfigurée.

Installez l'extension Elasticsearch

Vous pouvez installer l'extension Elasticsearch pour Gemini CLI avec la commande suivante :

Vous pouvez vérifier que les extensions ont été installées avec succès en ouvrant Gemini et en exécutant la commande suivante :

L'extension Elasticsearch devrait être disponible.

Si vous souhaitez utiliser l'intégration MCP, vous devez avoir une version d'Elasticsearch 9.3+ installée. Vous avez besoin de l’URL de votre serveur MCP depuis Kibana :

• Obtenez l'URL de votre serveur MCP dans Agents > Voir tous les outils > Gérer MCP > Copier l'URL du serveur MCP.

• L'URL se présentera comme suit : https://your-kibana-instance/api/agent_builder/mcp

Vous avez besoin de l’URL de l'endpoint Elasticsearch. Ce message apparaît généralement en haut de la page Elasticsearch de Kibana. Si vous utilisez Elasticsearch avec start-local, vous avez déjà l'endpoint dans la clé ES_LOCAL_URL dans le fichierstart-local .env.

Vous avez également besoin d’une clé API. Si vous exécutez Elasticsearch avec start-local, vous avez déjà le ES_LOCAL_API_KEY dans le fichier start-local .env. Sinon, vous pouvez créer une clé API en utilisant l’interface Kibana, comme indiqué ici :

• Dans Kibana : Stack Management > Security > Clés API > Créer une clé API.

• Nous suggérons de définir uniquement les privilèges de lecture pour la clé API, en activant le privilège feature_agentBuilder.read comme indiqué ici.

• Copiez la valeur de la clé API encodée.

Définissez les variables d'environnement requises dans votre shell :

Installer l'ensemble de données d'exemple

Vous pouvez installer l'ensemble de données eCommerce orders disponible dans Kibana. Il comprend un seul index nommé kibana_sample_data_ecommerce, contenant des informations sur 4 675 commandes provenant d'un site web. Pour chaque commande, nous disposons des informations suivantes :

• Informations client (nom, identifiant, date de naissance, e-mail, etc.).

• Date de la commande.

• ID de commande.

• Produits (liste de tous les produits avec prix, quantité, identification, catégorie, réduction et autres détails).

• SKU.

• Prix total (hors taxes, taxes incluses).

• Quantité totale.

• Informations géographiques (ville, pays, continent, localisation, région).

Pour installer les données d'exemple, ouvrez la page Intégrations dans Kibana (recherchez « Intégrations » dans la barre de recherche supérieure) et installez l'ensemble de données « Échantillons de données ». Pour plus de détails, consultez la documentation ici.

Le but de cet article est de montrer à quel point il est facile de configurer la CLI Gemini pour se connecter à Elasticsearch et interagir avec l'index kibana_sample_data_ecommerce.

Comment utiliser le MCP d’Elasticsearch

Vous pouvez vérifier la connexion à l'aide de la commande suivante dans Gemini :

Le elastic-agent-builder devrait être activé, comme le montre la figure 2 :

Elasticsearch fournit un ensemble d'outils par défaut. Voir la description ici.

Grâce à ces outils, vous pouvez interagir avec Elasticsearch, en posant des questions telles que :

• Give me the list of all the indexes available in Elasticsearch.

• How many customers are based in the USA in the kibana_sample_data_ecommerce index of Elasticsearch?

En fonction de la question, Gemini utilisera un ou plusieurs des outils disponibles pour tenter d'y répondre.

Les commandes /elastic

Dans l’extension Elasticsearch pour Gemini CLI, nous avons également ajouté/elastic commandes.

Si vous exécutez la commande /help, vous verrez toutes les options /elastic disponibles (Figure 3) :

Ces commandes peuvent être utiles si vous souhaitez exécuter directement un outil spécifique du serveur MCP elastic-agent-builder. Par exemple, en utilisant la commande suivante, vous pouvez obtenir le mapping de kibana_sample_data_ecommerce :

Ces commandes sont essentiellement des raccourcis permettant d’exécuter des outils spécifiques, plutôt que de s’en remettre au modèle Gemini pour déterminer l’outil à invoquer.

Comment utiliser les compétences Elasticsearch

Cette extension inclut également une compétence d’agent pour ES|QL, le langage de requête canalisé d’Elasticsearch (ES|QL) disponible dans Elasticsearch. Agent Skills est un format ouvert qui fournit aux agents IA de codage, comme Gemini CLI, des instructions personnalisées pour des tâches spécifiques. Ils utilisent un concept appelé divulgation progressive, ce qui signifie que seule une brève description de la compétence est ajoutée au prompt système initial. Lorsque vous demandez à l’agent d’effectuer une tâche, comme interroger Elasticsearch, il fait correspondre la requête à la compétence pertinente et charge dynamiquement les instructions détaillées. Il s’agit d’un moyen efficace de gérer les budgets de tokens tout en fournissant à l’IA exactement le contexte dont elle a besoin.

La compétence esqlest conçue pour permettre à Gemini CLI d’écrire et d’exécuter des requêtes ES|QL directement sur votre cluster. ES|QL est un langage de requête puissant qui rend l'exploration des données, l'analyse des logs et les agrégations très intuitives. Avec cette compétence activée, vous n'avez pas besoin de rechercher la syntaxe ES|QL ; vous pouvez simplement poser des questions en langage naturel à l'interface en ligne de commande Gemini sur vos données, et l'agent se chargera du reste.

Les exécutions sont réalisées à l'aide de simples commandes curl lancées dans un terminal. L’intégration d’Elasticsearch à n’importe quelle architecture est simplifiée par la richesse de ses API REST.

Ce que la compétenceesql offre :

• Recherche d'index et de schémas : L'agent peut utiliser les outils intégrés de la compétence pour dresser la liste des index disponibles et récupérer le mapping des champs. Par exemple, avant d’écrire une requête pour l’ensemble de données eCommerce, l’agent peut effectuer une exécution de vérification de schéma sur kibana_sample_data_ecommerce afin de comprendre les champs disponibles, comme taxful_total_price ou category.

• Traduction transparente en langage naturel : La compétence donne à l'agent plus qu'un simple manuel de référence ; elle lui fournit un guide spécifique pour interpréter l'intention de l'utilisateur. Dès que vous tapez une demande en langage naturel, par exemple « Afficher le temps de réponse moyen groupé par service », l’agent s’appuie sur les modèles intégrés de la compétence pour convertir vos mots en commandes, filtres et agrégations ES|QL appropriés.

• Autocorrection : en cas d’échec d’une requête (erreur de syntaxe ou de type, par exemple), la compétence transmet la requête ainsi que l’erreur Elasticsearch précise. L’agent peut alors la rectifier immédiatement et retenter l’opération sans que vous ayez à intervenir.

Comme la compétence esql est également disponible sous forme d'outil sur le serveur MCP elastic-agent-builder, nous devons désactiver ce serveur temporairement. Vous pouvez utiliser la commande suivante pour le désactiver :

Ensuite, vous pouvez simplement taper une invite comme celle-ci dans votre interface de ligne de commande Gemini :

L’agent devra :

• Reconnaissez la nécessité de la compétence esql.

• Consultez le schéma de kibana_sample_data_ecommerce.

• Construisez une requête ES|QL, comme : FROM kibana_sample_data_ecommerce | STATS total_revenue = SUM(taxful_total_price) BY category.keyword | SORT total_revenue DESC | LIMIT 5.

• Exécutez la requête auprès de l’API Elasticsearch.

• Présentez la réponse finale directement dans le terminal.

Nous avons cité ici un exemple de réponse de Gemini à la question précédente :

Il est intéressant de noter comment le modèle Gemini génère la réponse finale en montrant toutes les étapes qu’il suit. On peut voir ici l’influence de la compétence sur la démarche de réflexion du modèle. Dès que le modèle identifie la nécessité d’utiliser une compétence ou d’exécuter une commande shell, il sollicite une autorisation via l’approche supervision humaine dans la boucle.

Grâce à la gestion automatisée de la découverte de schéma, de la génération de requêtes et de leur exécution, la compétence esql vous libère des contraintes techniques pour vous focaliser uniquement sur l’analyse des résultats. Vous obtiendrez les données dont vous avez besoin, correctement formatées et directement dans votre terminal, sans jamais écrire une seule ligne de code ni basculer vers une autre application.

Conclusion

Dans cet article, nous avons présenté l'extension Elasticsearch pour Gemini CLI que nous avons récemment publiée. Cette extension vous permet d'interagir avec votre instance Elasticsearch en utilisant Gemini et le serveur Elasticsearch MCP fourni par Elastic Agent Builder, disponible à partir de la version 9.3.0, ainsi que la commande /elastic.

De plus, l'extension comprend également une compétence esql qui convertit la demande d'un utilisateur en langage naturel en une requête ES|QL. Cette compétence est très pratique quand l’usage du serveur MCP est impossible, puisque les échanges s’appuient sur l’exécution de commandes curl basiques dans le terminal. L’intégration d’Elasticsearch à tous vos projets est simplifiée par la richesse de ses API REST. C’est particulièrement utile lors du développement d’applications d’IA agentique.

Pour plus d’informations sur notre extension Gemini CLI, visitez le dépôt de projets ici.

C'est pourquoi nous mettons en open source les compétences Elastic Agent : une expertise native de la plateforme pour Elasticsearch, Kibana, Elastic Observability et Elastic Security. Ajoutez-les dans l'environnement d'exécution de l'agent que vous utilisez déjà, et améliorez votre agent en le faisant passer d'un statut de "généraliste" qui devine un grand nombre de syntaxes à un statut d'expert, capable par exemple d'utiliser un grand nombre de normes architecturales comme le font les équipes d'ingénieurs d'Elastic. Cette première version technique se concentre sur les compétences avec une compatibilité maximale pour Elastic Cloud Serverless, mais évoluera rapidement pour inclure une meilleure prise en charge des anciennes versions de la pile.

De plus, Elastic résout ce problème sur les deux fronts. Pour les agents sur la plateforme Elastic, Elastic Agent Builder (désormais disponible en version générale) vous permet de créer et de discuter avec des agents IA qui héritent des contrôles d'accès de vos données, utilisent des outils de recherche et d'analyse intégrés, et travaillent en contexte aux côtés de vos tableaux de bord, alertes et investigations. Nous travaillons dur pour garantir des expériences exceptionnelles d’agent sur la plateforme Elastic. Mais tous les agents ne se trouvent pas au sein d’Elastic. Votre équipe utilise déjà Cursor, Claude Code ou d'autres environnements d'exécution, et ces agents doivent également maîtriser Elastic. C'est là que les compétences des agents entrent en jeu.

Pourquoi les agents rencontrent-ils des difficultés avec les plateformes spécialisées

Les grands modèles de langage (LLM) sont des généralistes remarquablement compétents. Ils peuvent écrire en Python, expliquer les manifestes Kubernetes et restructurer les composants React car leurs données d'entraînement sont riches en exemples. Mais lorsqu’il s’agit de travaux spécifiques à la plateforme, ceux qui impliquent des langages de requête propriétaires, des interfaces API complexes et des bonnes pratiques spécifiques à un domaine, ils échouent de manière prévisible.

Pour Elasticsearch, l'écart se manifeste concrètement :

• Le langage de requête Elasticsearch (ES|QL) est un nouveau domaine. Les LLM sont fortement entraînés au SQL, mais ES|QL est un langage de requête canalisé avec une syntaxe différente, des fonctions différentes et une sémantique différente. Les agents écrivent fréquemment des requêtes qui semblent plausibles mais ne s'analysent pas. Ils confondent WHERE et | WHERE, inventent des fonctions qui n'existent pas et passent complètement à côté du modèle de composition canalisé.

• Les surfaces API sont larges et profondes. Elasticsearch, Kibana et Elastic Security exposent des centaines d'API dans les domaines de la recherche, de l'ingestion, de l'alerting, des règles de détection, de la gestion des cas, des tableaux de bord et plus encore. Un agent ne disposant que de données d'entraînement générales doit deviner quel point de terminaison appeler, à quoi ressemble le corps de la requête et comment gérer la réponse. Il se trompe suffisamment souvent pour éroder la confiance.

• Les bonnes pratiques ne figurent pas dans les données d'entraînement. Quand devez-vous utiliser semantic_text plutôt qu'un pipeline de plongement personnalisé ? Comment structurer un pipeline d'ingestion pour un CSV de 10 Go ? Quelle est la bonne syntaxe de règle de détection pour une technique MITRE ATT&CK ? Les agents polyvalents ne disposent pas de connaissances spécifiques à Elastic organisées et structurées de manière fiable et chargées par défaut. Ils devraient aller les chercher, et même s'ils le faisaient, les documents bruts ne reflètent pas toujours les jugements et les bonnes pratiques que les praticiens qualifiés appliquent.

Résultat : les développeurs passent plus de temps à corriger les sorties des agents qu'à écrire le code eux-mêmes. Ce n'est pas l'expérience pour laquelle ils se sont engagés.

Compétences des agents : connaissances de la plateforme, destinées aux agents

Les compétences des agents sont des répertoires autonomes d'instructions, de scripts et de matériel de référence que les environnements d'exécution des agents peuvent charger de manière dynamique. Lorsqu’une compétence est active, l’agent a accès au bon contexte au bon moment : syntaxe de requête, modèles d’API, logique de validation, exemples pratiques, afin de pouvoir exécuter correctement les tâches du premier coup.

Chaque compétence suit la spécification ouverte agentskills.io : un dossier avec un fichier SKILL.md contenant des métadonnées et des instructions structurées. Aucun format propriétaire, pas de dépendance. Les compétences fonctionnent à travers les environnements d'exécution des agents, notamment Cursor, Claude Code, GitHub Copilot, Windsurf, Gemini CLI, Cline, Codex, et bien d’autres.

Contenu de la version initiale v0.1.0

Le premier ensemble de compétences couvre cinq domaines de l’Elastic Stack :

• Interagir avec les API Elasticsearch (recherche, indexation, clustering)

• Création et gestion de contenu Kibana tels que les tableaux de bord, les alertes, les connecteurs et plus encore.

• Expertise de domaine pour Elastic Observability

• Expertise de domaine pour Elastic Security

• Créer des agents efficaces dans Agent Builder

Les compétences sont composables

Les compétences ne sont pas monolithiques. Elles sont modulaires de par leur conception. Votre agent charge uniquement les compétences pertinentes pour la tâche en cours. Vous travaillez sur une requête ES|QL ? La compétence ES|QL est activée. Vous souhaitez créer un tableau de bord à partir de ces résultats ? La compétence tableaux de bord se lance. Évaluer la santé de votre application ? La compétence de santé des services entre en jeu. Enquêter sur une alerte de sécurité ? Les compétences de triage s'enchaînent avec celles de gestion de cas et de réponse au fur et à mesure que l'enquête progresse.

Cette composabilité signifie que vous n'avez pas besoin d'une invite unique et massive qui tente de tout couvrir. Chaque compétence comporte exactement le contexte requis par son domaine, ni plus ni moins.

Pour les développeurs d'applications de recherche et d'IA

Si vous chargez des données dans Elasticsearch, que vous rédigez des requêtes ou que vous migrez des index, les compétences réduisent le cycle de génération de code, de détection d'erreurs et de recherche dans la documentation pour trouver ce qui n'a pas fonctionné.

Demandez à votre agent de charger un fichier CSV ; celui-ci utilisera un outil d’ingestion en continu qui gérera la contre-pression et déduira les mapping à partir des données. Il ne s'agit pas d'une boucle _bulk exécutée à la main qui épuise la mémoire dès le premier fichier volumineux. Demandez-lui de faire une requête auprès d’ES|QL, et il découvre vos véritables noms d’index et schémas de champs, puis écrit des requêtes valides canalisées avec la bonne syntaxe, les agrégations appropriées et la sélection de fonctionnalités adaptée à la version, et non une supposition SQL nécessitant trois tours de débogage. Demandez-lui de réindexer sur plusieurs clusters, et il suit le workflow complet : il crée la destination avec des mappings explicites, ajuste les paramètres de débit, effectue l'exécution de la tâche de manière asynchrone et restaure les paramètres de production une fois celle-ci terminée, et non pas un simple appel _reindex qui saute la moitié des étapes qu’un opérateur expérimenté suivrait.

Au lieu d'un agent qui vous donne un point de départ plausible à corriger, vous en obtenez un qui encode la discipline opérationnelle qui permet à la sortie de fonctionner réellement.

Exemples d'impacts de l'utilisation des compétences d'Elastic Agent

Eval

Ce que la compétence a changé

es-requêtes-d'audit-échecs-de-connexion

Utilisation des modèles de requête du log d'audit à partir de la compétence au lieu d'une recherche générique

es-autorisation-mapping-de-rôle-ldap

Émission de la structure correcte de l'appel d'API de mapping des rôles

esql-requête-de-base

Écriture de la syntaxe canalisée d'ES|QL via Query DSL

esql-gestion-des-erreurs

Priorité au schéma au lieu de deviner les noms des champs

esql-découverte de schéma

Ne devinez jamais le nom d'un index

es-ingestion-csv-avec-inférence

Utilisation de --infer-mapping uniquement, évitant de le combiner avec --source-format CSV qui crée un index vide

es-ingestion-fichier-json

Utilisation d'une approche d'ingestion robuste capable de traiter des fichiers volumineux

es-réindexer-local-asynchrone

Création de l’index de destination avec les répliques : 0 et refresh_interval : « -1 », puis réindexation asynchrone. Base : pas de préparation

es-sécurité-403-privilèges

Suivi d'un workflow de diagnostic de la compétence pour les erreurs de privilège au lieu de conseils génériques.

Pour les équipes de sécurité

Security répète quotidiennement les mêmes workflows opérationnels : trier les alertes, ajuster les règles de détection, gérer les dossiers. Les compétences de l'agent encodent ces connaissances procédurales afin que votre agent IA puisse exécuter correctement ces workflows, en appelant les bonnes API dans le bon ordre et avec les bons noms de champ. Pour une présentation pratique qui vous permettra de passer de zéro à un environnement Elastic Security complet sans quitter votre IDE, consultez la section Prise en main d'Elastic Security depuis votre agent d'IA.

Pour les équipes d'observabilité et d'opérations

Les nouvelles compétences des agents pour Elastic Observability réduisent les tâches opérationnelles liées à l'instrumentation de systèmes complexes, à la gestion des SLO, au tri des données complexes et à l'évaluation de l'état des services. L'intégration de l'expertise native d'Elastic directement dans les agents IA permet aux équipes d'exécuter des workflows d'observabilité complexes en utilisant un langage naturel simple. Cela permet aux équipes SRE et chargées des opérations de résoudre les incidents plus rapidement et d'assurer la maintenance de systèmes fiables plus facilement. Pour en savoir plus, consultez cet article de blog.

Open source, spécifications ouvertes, piloté par la communauté

Nous publions les compétences d'agent sous la licence Apache 2.0, car nous pensons que les connaissances des agents doivent être ouvertes. La spécification agentskills.io que suivent les compétences est un standard ouvert, et non un format propriétaire d'Elastic. Nous voulons que les compétences soient le fruit d'un effort communautaire, et non d'un lieu clos.

Une partie d'un tableau plus vaste

Agent Skills fait partie d'une initiative plus vaste visant à faire d'Elasticsearch la plateforme de données la plus adaptée aux agents disponible sur le marché. Pour les agents hébergés sur la plateforme Elasticsearch, Agent Builder va plus loin en reprenant les contrôles d'accès et les autorisations de vos données, en fournissant des outils intégrés et personnalisés pour la recherche et l'analyse, et en permettant aux utilisateurs d'interagir avec les agents en contexte, au sein de leurs tableaux de bord, alertes et enquêtes. Enfin, la prise en charge des compétences sera bientôt disponible dans Agent Builder, offrant aux développeurs la flexibilité nécessaire pour tirer parti des compétences Elastic Agent ainsi que de celles provenant de toute autre source, afin de permettre un chat sécurisé et enrichi par le contexte, ainsi qu'une automatisation sur la plateforme Elasticsearch.

Pour les agents qui vivent ailleurs, nous investissons dans l'écosystème ouvert :

• Extension du serveur Model Context Protocol (MCP) : Extension du point de terminaison MCP dans Agent Builder avec davantage d'outils au-delà des opérations actuelles de recherche, ES|QL et d'index.

• Améliorations de l'authentification : faciliter la connexion sécurisée des agents, dans le but d'éliminer le copier-coller manuel des clés API.

• Documentation lisible par LLM : publication des fichiers llms.txt et AGENTS.md afin que les agents puissent découvrir et comprendre les API Elastic par eux-mêmes.

• Une interface de ligne de commande (CLI) pour les flux de travail des agents : Un outil de ligne de commande qui facilite la gestion des connexions et les opérations courantes pour les agents.

Les compétences sont la partie que vous pouvez utiliser aujourd'hui. Le reste est à venir.

Lancez-vous

Avant de commencer : Les agents de codage d’IA fonctionnent avec de vraies informations d’identification, un véritable accès au shell et, souvent, avec toutes les autorisations de l’utilisateur qui les exécute. Lorsque ces agents sont orientés vers des workflows de sécurité, les enjeux sont plus élevés : vous confiez à un système automatisé l’accès à la logique de détection, aux actions de réponse et aux télémétries sensibles. Le profil de risque de chaque organisation est différent. Avant d’activer les workflow de sécurité pilotés par l’IA, évaluez les données auxquelles l’agent peut accéder, les actions qu’il peut entreprendre et ce qui se passe s’il se comporte de manière inattendue.

Installez les compétences Elastic Agent dans votre environnement d'exécution de l'agent :

npx skills add elastic/agent-skills

Cela détecte automatiquement vos agents d'exécution installés et place les compétences dans le répertoire de configuration approprié. A partir de là, votre agent les récupère automatiquement.

Vous pouvez également consulter directement le catalogue de compétences et installer manuellement des compétences individuelles en copiant le dossier de compétences dans le répertoire de configuration de votre agent.

Vous n'avez pas encore de cluster Elasticsearch ? Démarrer un essai gratuit d'Elastic Cloud. Il faut environ une minute pour obtenir un environnement entièrement configuré.

Explorez le projet :

• Répertoire des compétences des agents

• Spécifications d'agentskills.io

• Documentation Elasticsearch

• Essai gratuit d'Elastic Cloud

Les intégrations configurent une ou plusieurs entrées Filebeat pour assurer la collecte des données. Pour collecter des données via des API HTTP, nous avons souvent utilisé l’entrée HTTP JSON. Cependant, même les API de type listing les plus simples peuvent varier considérablement dans leurs détails. Le modèle de transformations configurées en YAML de l’entrée HTTP JSON peut alors devenir contraignant, voire parfois insuffisant pour exprimer la logique de collecte requise.

L’entrée Common Expression Language (CEL) a été introduite afin de permettre une interaction plus souple avec les API HTTP. CEL est un langage conçu pour être intégré dans des applications nécessitant un moyen rapide, sûr et extensible d’exprimer des conditions et des transformations de données. L’entrée CEL permet au créateur d’intégration d’écrire une expression unique capable de lire les paramètres, de suivre son propre état, d’effectuer des requêtes, de traiter les réponses et, au final, de renvoyer des événements prêts à être ingérés.

Dans cet article, nous examinons les différences entre CEL et d’autres langages de programmation, les extensions apportées pour l’entrée CEL, ainsi que la puissance et la souplesse qu’il apporte à l’expression de votre logique de collecte de données.

CEL et son fonctionnement dans l’entrée

CEL est un langage d’expressions. Il ne comporte pas d’instructions. Lorsque vous écrivez en CEL, vous ne décrivez pas une suite d’actions à exécuter à l’aide d’instructions. Vous indiquez plutôt la valeur à produire en rédigeant une expression. Chaque expression CEL renvoie une valeur. De petites expressions peuvent être combinées pour former une expression plus large, capable de produire un résultat selon des règles plus complexes. Nous verrons plus loin comment utiliser des expressions pour des usages généralement exprimés à l’aide d’instructions dans d’autres langages.

CEL est volontairement un langage non Turing-complet. Il n’autorise pas les boucles non bornées. Nous verrons également comment traiter des listes et des maps à l’aide de macros. En évitant les boucles non bornées, le langage garantit un temps d’exécution prévisible et limité pour chaque expression.

L’entrée CEL est configurée avec un programme CEL (une expression) et un état initial. L’état est fourni en entrée au programme. Le programme est évalué afin de produire un état de sortie. Si l’état de sortie comprend une liste d’événements, ceux-ci sont extraits puis publiés. Le reste de l’état de sortie est utilisé comme entrée pour l’évaluation suivante. Si l’état de sortie contient un ou plusieurs événements et que l’indicateur want_more: true, l’évaluation suivante est effectuée immédiatement ; sinon, l’entrée attend la fin de l’intervalle configuré avant de poursuivre. Voici un schéma simplifié du flux de contrôle de l’entrée :

La sortie de chaque évaluation est transmise comme entrée à l’évaluation suivante, tant que l’entrée s’exécute. Les données de sortie sous la clé « cursor» sont persistées sur disque et rechargées après le redémarrage de l’entrée, mais le reste de l’état n’est pas conservé entre les redémarrages.

Le langage CEL lui-même offre des fonctionnalités limitées et évite les effets de bord, mais il est extensible. L’implémentation cel-go ajoute certaines fonctionnalités, comme la prise en charge des syntaxes et des types optionnels. La bibliothèque Mito s’appuie sur cel-go et enrichit ses capacités, notamment en permettant l’exécution de requêtes HTTP. L’entrée CEL utilise la version de CEL fournie par Mito.

Travailler avec Mito

Pour créer ou déboguer une intégration à l’aide de l’entrée CEL, il est essentiel de comprendre l’état de sortie que votre programme CEL produira à partir d’un état d’entrée donné. Pendant le développement, il peut être contraignant d’exécuter votre programme CEL via l’entrée, au sein de l’ensemble de la Suite Elastic. Pour accélérer la boucle de rétroaction, vous pouvez utiliser l’outil de commande en ligne de Mito. Il vous permet d’exécuter un programme CEL directement et d’observer la sortie générée pour une entrée donnée.

Mito est écrit en Go et peut être installé comme suit :

Lorsque vous exécutez un programme CEL avec Mito, vous lui fournissez généralement deux fichiers : un fichier JSON contenant l’état d’entrée initial, et un autre fichier avec le code source de votre programme CEL :

Pour faciliter le copier-coller, les exemples de cet article sont écrits sous forme de commandes uniques qui permettent au shell de créer des fichiers temporaires à la volée, en enveloppant le contenu de chaque fichier dans <(echo '...content...'). Dans votre propre développement, travailler avec des fichiers réels sera plus facile.

Récupération des tickets depuis GitHub

L'exemple suivant inclut un programme CEL complet qui récupérera des données sur les problèmes depuis l'API GitHub. Son état d'entrée initial contient l'URL du point de terminaison de l'API et quelques informations sur la manière dont il doit gérer la pagination. Le programme CEL utilise les données dans l’état d’entrée pour générer une requête. Il va décoder la réponse, produire des événements à partir de celle-ci, et les renvoyer en tant que partie de son état de sortie.

Sa première évaluation produit la sortie suivante :

Les événements seront supprimés et, lorsqu’ils seront exécutés dans l’entrée CEL, ils seront publiés pour ingestion. Le reste de la sortie sera transmis à l’évaluation suivante du programme CEL en tant qu’état d’entrée.

Pour comprendre le fonctionnement de ce programme CEL, nous allons examiner quelques exemples CEL plus simples et détailler davantage le fonctionnement de l’entrée CEL.

Les bases de CEL

Dans le langage CEL, il n’y a pas d’instructions ; uniquement des expressions. Toute expression CEL valide est évaluée pour produire une valeur finale. Voici l’une des plus petites expressions CEL que vous puissiez écrire, ainsi que sa sortie :

De nombreuses expressions simples sont intuitives. Les opérations mathématiques ne sont prises en charge que sur des valeurs de même type (par exemple, int avec int), convertissez donc les types selon vos besoins (ici de int à double) :

Il n’y a pas de variables dans le langage CEL, mais une expression peut recevoir un nom et être utilisée dans une expression plus large grâce à la macro as de Mito. Dans cet exemple, l’expression (1 + 1) évalue la valeur 2, et .as(n, ...) donne à cette valeur le nom n pour l’utilisation dans l’expression "one plus one is "+string(n):

Il est également possible d’accumuler des informations dans une carte et de les utiliser plus tard dans l’expression, comme démontré ici avec with:

Regardez à nouveau cet exemple. Remarquez que la partie imbriquée, ({ "data": data, "size": size(data), }), nous donne la forme de la valeur finale. C'est une carte avec les clés "data" et "size". Les valeurs de ces clés dépendent de data, qui est défini par la partie extérieure de l’expression. Lire les expressions CEL de l'intérieur vers l'extérieur peut aider à voir rapidement ce qu'elles renverront.

CEL ne possède pas d’instructions de flux de contrôle, comme if, mais le branchement conditionnel peut être réalisé avec l’opérateur ternaire :

Les boucles non bornées et la récursion ne sont pas prises en charge, car CEL n’est pas un langage Turing-complet. Le temps d’exécution est donc prévisible et proportionnel à la taille des données d’entrée et à la complexité de l’expression.

Bien que les boucles non bornées ne soient pas possibles dans des expressions CEL individuelles, vous pouvez traiter des listes et des cartes à l’aide de macros comme map :

Dans cette section, nous avons abordé les points suivants :

• Les chaînes de caractères, les nombres, les listes et les maps.

• La concaténation de chaînes.

• Les opérations mathématiques.

• Le transtypage.

• Les conditions.

• La nomination des sous-expressions.

• Le traitement des collections.

Ensuite, nous verrons comment effectuer des requêtes HTTP.

Requêtes

Mito étend CEL en lui donnant la possibilité d'effectuer des requêtes HTTP :

Les requêtes peuvent être construites explicitement avant leur exécution. Cela permet d’utiliser différentes méthodes HTTP et d’ajouter des en-têtes ainsi qu’un corps de requête.

Dans cet exemple, nous construisons une URL avec l’aide de format_query, ajoutons un en-tête à la requête, et analysons le corps de la réponse avec decode_json. Lorsque l'option -log_requests est sélectionnée, Mito log des informations détaillées au format JSON sur chaque demande et réponse.

Gestion de l’état et des évaluations

Maintenant que nous avons vu comment effectuer des requêtes et passé en revue les bases de CEL nécessaires pour produire l’état de sortie souhaité, examinons de plus près ce que nous devons placer dans l’état de sortie et comment cela nous permet d’orienter les traitements ultérieurs.

Le programme CEL d'une intégration doit s'assurer que son état de sortie peut être utilisé comme entrée de l'évaluation suivante. La configuration définit l'état initial, qui doit être répété dans la sortie avec toutes les modifications appropriées. Une façon simple de le faire est d’utiliser state.with({ ... }), pour répéter la carte d’état avec quelques dérogations. Un modèle courant pour les petits programmes consiste à envelopper l'ensemble du programme dans state.with(), de sorte que la propagation de l'état ne doive pas être répétée dans chaque branche qui génère des données de sortie (par exemple, succès, erreurs).

Lorsque des valeurs d’état sont initialisées par une évaluation plutôt que codées en dur dans l’état d’entrée initial, le programme devra vérifier la présence d’une valeur existante avant de définir la valeur initiale. La prise en charge de la syntaxe et des types optionnels peut aider à résoudre ce problème. En utilisant un point d'interrogation avant le nom du champ dans une clé de carte, l'accès devient facultatif : il peut ou non aboutir à une valeur, mais d'autres accès facultatifs sont possibles et il est facile de fournir une valeur par défaut si aucune valeur n'est présente :

Dans cet exemple, la valeur du compteur lue à partir de l'état est convertie en int car tous les nombres sont sérialisés dans l'état sous forme de nombres à virgule flottante, conformément aux conventions établies par JSON et le type Number de JavaScript. Il convient également de noter que "want_more": true est respecté ici par Mito, mais lorsqu’elle est exécutée dans l’entrée CEL, l’évaluation ne sera répétée que si la sortie contient également des événements.

C’est une exigence des programmes CEL exécutés par l’entrée CEL de retourner une clé "events" dans leur carte de sortie. Sa valeur peut être une liste de cartes d’événements, une liste vide ou une carte d’événement unique. Le cas d’événement unique est généralement utilisé pour les erreurs. L’événement sera publié par l’entrée, mais sa valeur sera également journalisée, et s’il définit une valeur error.message, celle-ci sera utilisée pour mettre à jour l’état de santé de la Fleet de l’intégration. Si votre programme ne produit qu’un seul événement sans erreur, il est préférable de l’inclure dans une liste.

Reprenons la sortie de notre programme de récupération des tickets GitHub présenté précédemment :

Le programme gérait effectivement son état de la manière suivante :

• Répétition des valeurs d’état initiales dans url, per_page, et max_pages.

• Ajout d’état qui devrait être maintenu lors des redémarrages dans cursor.page.

• Les événements prêts à être publiés dans la liste events.

• Demande de réévaluation immédiate avec want_more: true.

Maintenant que vous maîtrisez l’accès optionnel, la gestion de l’état, les bases de CEL et les requêtes HTTP, le programme complet de récupération des tickets GitHub devrait être plus clair. Essayez de l’exécuter avec Mito et d’expérimenter quelques modifications.

Conclusion et ressources

Dans cet article, nous avons expliqué ce qu’est le langage CEL et comment il a été étendu dans la bibliothèque Mito pour une utilisation dans l’entrée CEL. Nous avons illustré la flexibilité de CEL à travers un programme exemple qui récupère des informations sur des tickets via l’API GitHub, et détaillé les éléments nécessaires à sa compréhension : accès aux paramètres dans l’état initial, interaction avec les API HTTP, renvoi d’événements destinés à l’ingestion et gestion de l’état pour les exécutions ultérieures du programme.

Pour aller plus loin et créer des intégrations à l’aide de l’entrée CEL, plusieurs ressources méritent votre attention :

• Entrée CEL - Documentation Filebeat

• Documentation Mito

• Langage d'expression commun - site web cel.dev

• Créer une intégration - Documentation Elastic

Et sans doute la ressource la plus précieuse pour créer des intégrations avec l’entrée CEL reste le code CEL des intégrations Elastic existantes, disponible sur GitHub :

cel.yml.hbs fichiers du dépôt des intégrations Elastic – GitHub

Nous avons tous été témoins de l’essor des agents d’IA. Ils se révèlent particulièrement performants pour le résumé de textes, l’écriture de scripts et l’extraction de réponses issues de bases documentaires. Pourtant, dans les domaines du DevOps et de la fiabilité système (SRE), nous faisions face à un obstacle particulièrement frustrant. L’immense majorité des agents reste confinée au modèle du support client. S’ils analysent et échangent, ils demeurent incapables d’intervenir directement sur les couches d’infrastructure dont ils ont la charge.

Lors de notre récent hackathon, nous avons pris le parti de briser définitivement cette contrainte.

Nous avons conçu l’Infrastructure augmentée : un copilote d’infrastructure qui ne se contente pas de vous conseiller, mais qui crée, déploie, surveille et répare également votre environnement de production.

Le problème : copier, reformater, coller

Les agents standards fonctionnent en vase clos. Face à une panne majeure représentant une perte de 5 millions de dollars, l’assistance d’un agent standard se limite à la simple lecture du protocole de remise en service. Mais c’est toujours à vous d’effectuer le travail. Il vous reste encore à extraire le code, à en assurer la compatibilité avec votre environnement, puis à procéder manuellement à sa saisie dans la console.

Nous recherchions un agent capable de faire la part des choses entre le discours sur Kubernetes et l’exécution technique sur Kubernetes.

Au cœur du système : présentation d’Elastic Agent Builder.

Pour concevoir cette solution, nous ne sommes pas partis d’une page blanche. Nous l’avons conçue sur la base d’Elastic Agent Builder. À titre de rappel, Elastic Agent Builder est une architecture logicielle dédiée au développement rapide d’agents, agissant comme interface entre un modèle de langage (LLM), tel que Google Gemini, et les données propriétaires hébergées dans Elasticsearch.

Agent Builder peut être utilisé pour l’IA conversationnelle en l’ancrant sur des données internes, comme des documents ou des logs. Mais sa fonctionnalité la plus puissante est la possibilité d’assigner des outils. Ces outils permettent au LLM de sortir de l’interface de discussion pour accomplir des tâches spécifiques. Nous avons compris qu’en exploitant tout le potentiel de cette fonction, l’Agent Builder pourrait devenir un véritable pilier de l’automatisation.

Mise en œuvre : création de la première version

Dès le début du projet, notre ambition était de permettre aux agents d’exercer une action concrète sur leur environnement externe. Une idée a germé : pourquoi ne pas créer un « runner », un logiciel chargé d’exécuter sur la machine hôte toutes les instructions générées par l’agent ? Puis, nous avons envisagé ceci : et si les « runners », Elastic Agent Builder et l’utilisateur communiquaient en temps réel, comme lors d’une conférence téléphonique ?

Nous avons commencé par concevoir un projet Python, Augmented Infrastructure Runners, qui consistait essentiellement en une boucle while(true) qui interrogeait chaque seconde l’API des conversations d’Elastic Agent Builder pour y détecter une syntaxe spécifique que nous avions créée :

Nous avons ensuite mis à jour l’invite pour l’enseigner sur notre nouvelle syntaxe d’appel d’outil. Bill contribue à la maintenance de FastMCP, la solution de référence en Python pour le développement de serveurs conformes au Model Context Protocol (MCP). Il a entrepris d’utiliser le client FastMCP conjointement avec ce nouveau runner afin de coupler les serveurs MCP et d’exposer leurs outils au sein de l’environnement d’exécution. Lorsque l’agent voyait cela, il exécutait l’appel de l’outil et publiait les résultats dans la conversation, comme si l’utilisateur lui-même les avait envoyés. Cela incitait le LLM à répondre au résultat, et c’est ainsi que tout a commencé !

C’était génial mais cela posait deux problèmes principaux :

1. L’agent se contenterait de projeter l’intégralité des données JSON au beau milieu de l’échange avec l’utilisateur.

2. Dans l’API des conversations, les messages n’étaient accessibles qu’une fois le tour de parole terminé, soit après l’émission de la réponse par le LLM.

Nous nous sommes alors attachés à trouver comment déporter cette tâche en tâche de fond.

Nous avons ensuite choisi de donner à l’agent un outil appelé call_external_tool avec deux arguments : le tool_name et les arguments JSON sous forme de chaîne de caractères. Cet appel d’outil externe ne renvoie rien, mais il est important de noter qu’il est visible dans la requête GET envoyée à l’API des conversations. Nous avons ensuite donné aux runners l’autorisation d’écrire des documents directement dans Elasticsearch, que l’agent Elastic Agent Builder pouvait récupérer si nécessaire. L’agent fonctionne toujours en réponse à un message d’utilisateur. Nous devons donc démarrer l’agent avec un message d’utilisateur afin qu’il recherche des résultats et poursuive le traitement. Aussi, nous avons demandé aux agents d’insérer un court message dans le chat pour reprendre la conversation :

Ainsi, nous avions désormais des appels d’outils externes. Cependant, en raison du deuxième problème mentionné ci-dessus, nous avons dû supprimer cette dernière partie de démarrage. Sinon, chaque appel à un outil externe nécessitait un cycle complet de conversation pour récupérer les résultats !

Pour aller plus loin : présentation des workflows

En plus des appels d’outils via ES|QL et la recherche d’index, les agents d’Agent Builder peuvent solliciter des outils Elastic basés sur des workflows. Les workflows Elastic offrent une méthode flexible et simple à gérer pour exécuter une séquence arbitraire d’actions et de logiques. Dans notre cas, le rôle du workflow se limite à l’enregistrement d’une demande d’outil externe dans Elasticsearch et à la transmission d’un identifiant (ID) pour le suivi des résultats. Le résultat est une définition de workflow simple, articulée comme suit :

Ainsi, au lieu de compter sur l’écriture de la requête d’appel d’outil dans la conversation, les runners peuvent simplement interroger l’index Elasticsearch distributed-tool-requests pour de nouvelles requêtes d’outils externes et faire un rapport des résultats dans un autre index Elasticsearch avec l’execution.id fourni.

Cela élimine les deux principaux problèmes mentionnés ci-dessus :

1. L’historique de la conversation n’est plus encombré par les données de transfert des appels d’outils externes.

2. Comme les runners interrogent l’index Elasticsearch au lieu de l’historique de conversation, ils ne sont plus bloqués par l’achèvement du cycle d’échange pour que les requêtes d’outils externes deviennent visibles.

L’intérêt principal de ce deuxième point est que l’exécution des requêtes vers les outils externes débute pendant que l’agent « réfléchit », sans attendre que le tour de parole soit terminé. Cela nous permet d’instruire le LLM, via le prompt système, d’interroger les résultats de l’outil externe jusqu’à ce qu’ils soient disponibles, éliminant ainsi le besoin d’un message de relance. Dans l’ensemble, cette approche fluidifie l’interaction : le LLM est désormais capable de gérer simultanément plusieurs appels d’outils externes lors d’une seule itération. Cela lui permet de traiter des requêtes utilisateur complexes de manière groupée, plutôt que de fragmenter le processus.

Mise en place

Pour rapprocher le LLM et la baie de serveurs, nous avons développé une architecture spécifique en exploitant les fonctionnalités des outils d’Agent Builder :

1. Les runners de l’infrastructure augmentée : Nous avons déployé des runners légers à l’intérieur des environnements cibles (serveurs, clusters Kubernetes, comptes cloud). Ces runners sont connectés directement à Elastic, en utilisant des endpoints sécurisés et des secrets accessibles uniquement à chacun des runners.

2. Récupération ES|QL : Le copilote utilise ES|QL d’Elastic pour effectuer des recherches hybrides. Il ne se contente pas de rechercher des connaissances, il recherche des capacités. Il interroge les exécuteurs connectés pour voir quels outils sont disponibles (par exemple, list_ec2_instances, install_helm_chart).

3. Exécution du workflow : Une fois que l’agent a décidé d’un plan d’action, il crée un workflow structuré.

4. Boucle de rétroaction : Les runners exécutent la commande localement et rapportent les résultats dans Elasticsearch. Le copilote lit le résultat de l’index et décide de l’étape suivante.

Démonstration : transformer un incident critique en levier d’observabilité

Dans la vidéo, nous avons présenté deux scénarios distincts démontrant la puissance de cette architecture.

Scénario 1 : DevOps à la rescousse

Le point de départ est un incident critique : un utilisateur confronté à une perte de 5 millions de dollars due à un défaut de visibilité dans son cluster Kubernetes.

• La demande : « Comment m’assurer que cela ne se reproduise plus ? »

• Action : L’agent ne s’est pas contenté de fournir un tutoriel. Il a identifié le cluster, créé les espaces de nom nécessaires, généré des secrets Kubernetes, installé l’opérateur OpenTelemetry et a immédiatement fourni un lien vers un tableau de bord APM en direct.

• Le résultat : Une observabilité complète de Kubernetes et des informations sur les applications sans que l’utilisateur n’écrive une seule ligne de YAML.

Scénario 2 : Transfert de Security

En sécurité des infrastructures, un principe de base prévaut : l’impossibilité de protéger ce qui échappe à notre visibilité. En pleine intervention de secours DevOps, l’agent identifie une occasion d’optimiser la sécurité globale de l’infrastructure.

En s’appuyant sur une alerte générée lors d’une analyse Elastic Observability, nous illustrons la capacité d’un analyste sécurité à interagir en langage naturel avec son infrastructure. L’objectif est double : recenser précisément les ressources cloud existantes et mettre en œuvre les solutions de protection indispensables.

• Découverte : Le copilote a énuméré les ressources AWS pour le spécialiste de la sécurité et a identifié une lacune critique : une instance Amazon Elastic Compute Cloud (EC2) et un cluster Amazon Elastic Kubernetes Service (EKS) avec des points de terminaison publics dépourvus de protection des points de terminaison.

• Remédiation : Avec une simple approbation, le copilote a déployé Elastic Security détection et réponse étendues (XDR) et détection et réponse cloud (CDR) sur les ressources vulnérables, assurant la sécurité de l’environnement en temps réel.

• Le résultat : Protection des ressources AWS déployées avec une sécurité totale à l’exécution.

Perspectives : Vers une infrastructure intégralement augmentée

Ce projet démontre la capacité d’Elastic Agent Builder à agir comme le centre de pilotage de vos opérations distribuées. Notre champ d’action dépasse désormais le cadre strict de l’infrastructure. Les capacités de notre technologie de runner s’étendent à :

• Synthetics augmenté : Diagnostiquer les erreurs TLS chez les runners du monde entier.

• Développement augmenté : Création de requêtes d’extraction et implémentation de CAPTCHA sur les services frontend.

• Opérations augmentées : reconfiguration automatique des résolveurs DNS en cas de panne.

Essayez par vous-même

Nous pensons que l’avenir de l’IA ne se limite pas à l’assistance par chat, mais aussi à une infrastructure augmentée. Il s’agit d’avoir un partenaire qui peut déployer, réparer, observer et protéger à vos côtés.

Consultez le code et essayez-le par vous-même avec des runners distribués (GitHub) et Elastic Agent Builder sur Elastic Cloud Serverless dès aujourd'hui !

• Créez un projet sans serveur sur Elastic Cloud.

• Déployez le code vers un runner.

• Configurez le runner.

• Configurez votre fichier mcp.json.

• Démarrez l’agent, qui créera automatiquement votre agent et ses outils.

• Dialoguez avec un agent capable de raisonner, de planifier et d’exécuter des actions sur vos runners distribués !

L’équipe : Alex, Bill, Gil, Graham et Norrie

Les agents gagnent du terrain en raison de leur potentiel d'amélioration de l'efficacité et de l'expérience client. Mais dans la pratique, il est difficile de fournir aux agents le bon contexte, en particulier lorsqu'ils travaillent sur des données d'entreprise hétérogènes et non structurées. Les développeurs doivent gérer les outils, les prompts, l'état, la logique de raisonnement, les modèles, et surtout récupérer un contexte pertinent à partir des sources métier pour garantir des résultats et des actions précis. Elastic Agent Builder fournit ces composants essentiels pour développer des agents sécurisés, fiables et contextuels.

Fonctionnalités principales d'Agent Builder

Agent Builder est le résultat des investissements à long terme d'Elastic dans la pertinence de la recherche et la génération augmentée par récupération, et contribue à faire d'Elasticsearch la meilleure base de données vectorielle pour simplifier le développement d'agents d'IA contextuels et axés sur les données.

Agent Builder vous permet de :

• Commencer immédiatement avec un agent conversationnel intégré capable de répondre aux questions, d'effectuer des analyses et de mener des investigations sur n'importe quelles données dans Elasticsearch.

• Passer rapidement des données non structurées complexes à un agent personnalisé grâce à une expérience de développement basée sur la configuration.

• Bénéficier de la pertinence d'une recherche hybride de pointe grâce à ES|QL intégré ou à des outils personnalisés pour améliorer la qualité du contexte et la fiabilité des agents.

• Exécuter des workflows complexes (préversion) sous forme d'outils réutilisables pour enrichir les données, mettre à jour les enregistrements, envoyer des messages et plus encore pour l'automatisation basée sur des règles.

• Vous connecter à des sources de données externes à Elasticsearch à l'aide de workflows et de MCP pour corréler et combiner le contexte pour les agents.

• Intégrer à n'importe quel framework agentique ou d'application à l'aide d'outils intégrés et personnalisés exposés via MCP, et possibilité de se connecter à un MCP externe (préversion), prise en charge d'A2A et support technique API complet.

• Étendre les capacités d'Agent Builder avec l'intégration de solutions tierces comme LlamaIndex pour le traitement complexe de documents ou Arcade.dev pour un accès sécurisé et structuré aux outils.

Pour étendre les fonctionnalités d'Agent Builder, nous lançons Elastic Workflows, notre nouvelle solution d'automatisation basée sur des règles, actuellement disponible en préversion technique. Pour les tâches organisationnelles, les agents ont parfois besoin de la certitude et de la fiabilité des actions basées sur des règles, qui sont souvent nécessaires pour mettre en œuvre une logique métier spécifique. Elastic Workflows offre aux agents une méthode simple et déclarative pour orchestrer des systèmes internes et externes afin d'effectuer des actions, de collecter des données et du contexte, et de les transformer. Entièrement composables, pilotés par les événements et flexibles, les workflows peuvent être exposés comme outils à un agent via MCP.

Passez des données à l'agent en quelques minutes

Le développement d'agents peut prendre des semaines de travail préparatoire pour consolider des datastores distincts, construire des pipelines manuels, optimiser les requêtes et gérer une orchestration complexe. Agent Builder réduit le temps de développement des agents en supprimant le besoin de datastores séparés, de bases vectorielles, de pipelines RAG, de couches de recherche, de traducteurs de requêtes et d'orchestrateurs d'outils, vous permettant ainsi de vous concentrer sur la logique de l'agent et la livraison de l'application.

Agent Builder intègre nativement les primitives de la plateforme Elasticsearch pour accélérer le développement d'agents.

• Commencez avec un agent conversationnel intégré qui peut immédiatement discuter et raisonner avec vos données indexées.

• Intégrez des agents dans des applications, des tableaux de bord ou des systèmes CI/CD avec un accès interactif via Kibana, des API, ou MCP et A2A.

• Utilisez des outils par défaut pour comprendre la structure de vos données, sélectionner l'index approprié, générer des requêtes hybrides, sémantiques et structurées optimisées, et créer des visualisations configurables à l'aide d'ES|QL basées sur des prompts en langage naturel.

Pour aller plus loin, essayez une procédure pas à pas complète.

Développez sur Elasticsearch, une plateforme de données complète pour l'ingénierie du contexte

En matière d'agents d'IA, la qualité du contexte est essentielle pour un raisonnement efficace et pour limiter les risques d'hallucinations. Dans de nombreux cas, les données métier nécessaires à l'exécution d'une tâche constituent l'élément de contexte le plus crucial. Elasticsearch, base de données vectorielle hautement scalable et leader en matière de pertinence, offre déjà de nombreuses primitives performantes d'ingénierie du contexte. L'ingénierie du contexte va au-delà de la simple génération augmentée par récupération : elle permet de personnaliser et de dimensionner la manière dont les données sont extraites, classées, filtrées et présentées aux agents, contribuant ainsi à réduire le bruit et l'ambiguïté.

Elasticsearch fournit un moteur de contexte qui combine la recherche lexicale, la recherche vectorielle et le filtrage structuré pour la récupération, ce qui améliore considérablement les performances des LLM en garantissant que le modèle opère sur un contexte pertinent et précis. Cette fonctionnalité est prise en charge par la récupération agentique, ainsi que par des outils intégrés et une logique de recherche qui sélectionnent automatiquement les index appropriés et transforment le langage naturel en requêtes optimisées pour le contexte.

Avec Agent Builder, vous avez l'assurance que les agents reçoivent en priorité le contexte le plus pertinent grâce à des options de contrôle de la pertinence et du classement afin d'affiner la logique de notation, de classement et de filtrage. Elasticsearch vous permet de contrôler ce qui est important, pourquoi c'est important et comment l'ordre de priorité est établi, au lieu de vous fier à un comportement de récupération opaque. L'ensemble repose sur Elasticsearch, une plateforme de données scalable qui permet de stocker et de gérer toutes vos données (texte, vecteurs, métadonnées, logs, etc.) sur une seule et même plateforme, simplifiant ainsi la gestion du contexte pour les agents.

Exécutez des workflows complexes en tant qu'outils réutilisables

Si les agents d'IA permettent de raisonner sur des tâches complexes, l'automatisation repose en grande partie sur l'exécution fiable d'actions basées sur des règles qui appliquent une logique métier spécifique. Elastic Workflows offre une méthode simple et déclarative pour orchestrer les systèmes internes et externes afin d'effectuer des actions, collecter du contexte ou des données et les intégrer aux agents. Définis en YAML, les workflows sont entièrement composables de manière à les rendre aussi simples ou complexes que l'exige la tâche à accomplir. Les agents disposent ainsi d'un moyen efficace d'interagir avec la plateforme et les solutions Elasticsearch, de même qu'avec des applications tierces.

L'intégration d'un workflow avec Agent Builder peut se faire en trois étapes (prérequis : activez les workflows avec les détails fournis ici)

1. Créez et enregistrez un nouveau workflow à l'aide de l'éditeur simple basé sur YAML avec autocomplétion et tests intégrés.

2. Créez un nouvel outil dans Agent Builder avec le type "Workflow" et fournissez une description pour aider l'agent à déterminer quand utiliser l'outil de workflow.

3. Ajoutez l'outil de workflow à votre agent personnalisé.

4. Et voilà ! L'agent peut maintenant déclencher le workflow directement depuis une conversation.

Votre agent, vos règles

Agent Builder ne vous enferme pas dans un seul paradigme de développement. Au contraire, il est conçu pour permettre des approches de développement ouvertes et flexibles pour les agents avec un contrôle total des données, de la pertinence, des modèles, de l'interopérabilité, de la sécurité et de la conception des agents.

Les définitions d'agents personnalisés vous permettent de choisir précisément les outils auxquels un agent peut accéder, d'intégrer des prompts système personnalisés, d'adapter ses instructions et de définir des limites de sécurité. Les agents restent indépendants du modèle, ce qui vous permet de configurer avec flexibilité un LLM de votre choix, qu'il soit natif ou issu de l'écosystème étendu, sans être lié à un fournisseur unique.

Créez des outils extensibles qui encapsulent la logique spécifique au domaine (par exemple, des filtres d'index spécifiques, des jointures ES|QL, des pipelines analytiques) et sécurisez leur utilisation en production. La prise en charge API complète assure l'interopérabilité avec d'autres frameworks d'agents, grâce à une compatibilité native avec le protocole MCP (Model Context Protocol). L'intégration A2A vous permet d'exposer vos agents Elastic à d'autres frameworks, services et applications clientes, en réutilisant la même logique d'ingénierie des données et du contexte.

Agent Builder permet un développement flexible et ouvert, et il est conçu pour s'intégrer facilement aux frameworks et plateformes d'agents les plus populaires. Ces intégrations peuvent être essentielles pour fournir des agents efficaces. Comme l'explique Sam Partee, cofondateur d'Arcade.dev,

"Les systèmes agentiques échouent aujourd'hui, car la connexion de l'IA aux outils et aux données est complexe. Elastic Agent Builder avec Arcade.dev offre aux développeurs un moyen structuré et sécurisé de gérer la manière dont les agents récupèrent le contexte, raisonnent et agissent, permettant ainsi de passer de la démo à la phase de production."

Agent Builder tire également parti de l'extensibilité d'Elasticsearch pour gérer des données complexes. Comme le décrit Jerry Liu, PDG de LlamaIndex ,

"L'extraction du contexte d'entreprise à partir de sources de données non structurées est essentielle à la création d'agents performants. Elastic Agent Builder, associé au traitement de documents complexes de LlamaIndex, renforce la couche de contexte critique, aidant les équipes à récupérer, traiter et préparer les données afin que les agents puissent raisonner avec plus de précision et obtenir de meilleurs résultats."

Que pouvez-vous construire ?

Agent Builder est déjà exploité dans de nombreux cas d'utilisation. Vous trouverez ci-dessous quelques exemples et architectures de référence pour vous familiariser avec les agents :

• Automatiser l'infrastructure : dans les scénarios de support, les agents sont utilisés pour lire, analyser et dialoguer, mais jusqu'à présent, ils ne peuvent pas interagir directement avec l'infrastructure qu'ils sont appelés à gérer. L'équipe d'ingénierie d'Elastic a développé un agent pour la gestion automatisée de l'infrastructure dans le cadre d'un hackathon. L'agent enquête activement sur les problèmes liés à l'infrastructure des applications et prend des mesures automatisées. Il utilise des workflows pour optimiser les configurations, répondre aux problèmes et scaler les ressources, le tout basé sur une compréhension intelligente des logs d'infrastructure.

• Analyse des menaces de sécurité : un agent de vulnérabilité de sécurité a été développé avec Elastic Agent Builder, MCP et Elasticsearch. Il automatise l'analyse des menaces en corrélant les données de sécurité internes avec les renseignements sur les menaces externes. L'agent effectue une recherche sémantique sur les incidents et configurations historiques, enrichit les résultats avec des données Internet en temps réel et applique un raisonnement LLM pour évaluer la pertinence environnementale, hiérarchiser les risques et proposer des mesures correctives concrètes. Voir l'architecture de référence.

• Support technique client : les agents peuvent effectuer de nombreuses tâches de support, notamment la synthèse des cas, la déduplication et la création de tickets, ainsi que des investigations techniques approfondies. Agent Builder facilite ces opérations grâce à une recherche hybride en plusieurs étapes permettant de trouver uniquement les problèmes, solutions et procédures les plus pertinents, de formuler des hypothèses sur les causes profondes et de proposer des plans de remédiation. Agent Builder peut simplifier l'architecture des systèmes de support complexes et accélérer les délais de livraison.

• Découverte de produits et de contenus : Agent Builder simplifie le processus d'exposition de catalogues produits complexes pour des expériences conversationnelles, tout en permettant aux organisations de conserver la flexibilité nécessaire pour inclure leur propre logique métier et leurs propres exigences.

• Créez le vôtre : participez au hackathon Agent Builder, qui se déroulera du 22 janvier au 27 février 2026. Collaborez avec la communauté pour créer des agents d'IA contextuels à plusieurs étapes qui combinent la recherche, les workflows, les outils et le raisonnement pour automatiser des tâches concrètes*

Commencez à créer des agents personnalisés dès maintenant

Commencez avec un essai Elastic Cloud, et consultez la documentation ici. Pour les clients existants, Agent Builder est disponible dans Cloud Serverless et avec le niveau Enterprise dans Elastic Cloud Hosted et autogéré.

* Cliquez ici pour connaître les modalités, conditions et critères d'éligibilité pour le hackathon

L’un des moyens de briser la vitre : adopter des agents vocaux, autrement dit des agents IA capables de comprendre la voix humaine et de produire un son de synthèse. Grâce à l’essor des transcriptions à faible latence, des modèles de langage de grande taille (LLM) rapides et des systèmes de synthèse vocale au rendu naturel, cette vision devient réalité.

Pour réellement créer de la valeur, les agents vocaux doivent aussi avoir accès aux données métier. Dans ce billet, nous verrons comment fonctionnent les agents vocaux et comment en créer un pour ElasticSport, une boutique fictive d’équipements de sport de plein air, à l’aide de LiveKit et Elastic Agent Builder. Notre agent vocal sera sensible au contexte et s’appuiera sur nos données.

Fonctionnement

Le monde des agents vocaux repose sur deux grands paradigmes : le premier s’appuie sur des modèles de conversion vocale directe (speech-to-speech), le second sur une chaîne vocale composée de reconnaissance vocale, de LLM et de synthèse vocale. Les modèles speech-to-speech ont leurs avantages, mais les chaînes vocales permettent une personnalisation bien plus poussée des technologies employées et de la gestion du contexte, ainsi qu’un contrôle plus fin du comportement de l’agent. Nous allons nous concentrer sur le modèle basé sur la chaîne vocale.

Composants clés

Transcription (reconnaissance vocale)

La transcription est le point d’entrée de la chaîne vocale. Le composant de transcription reçoit des trames audio brutes en entrée, convertit la voix en texte, puis restitue ce texte en sortie. Le texte transcrit est mis en mémoire tampon jusqu’à ce que le système détecte la fin de la prise de parole de l’utilisateur – c’est alors que la génération par le LLM démarre. Plusieurs prestataires tiers proposent des transcriptions à faible latence. Lors de votre sélection, tenez compte de la latence et de la précision de transcription, et vérifiez que le fournisseur prend en charge les transcriptions en flux continu.

Exemples d’API tierces : AssemblyAI, Deepgram, OpenAI, ElevenLabs

Détection de prise de parole

La détection de prise de parole est le composant de la chaîne qui identifie la fin de l’intervention de l’utilisateur, déclenchant ainsi la génération. Une méthode courante consiste à utiliser un modèle de détection d’activité vocale (VAD), comme Silero VAD. Le VAD s’appuie sur le niveau d’énergie du signal audio pour détecter la présence de parole et identifier la fin de l’intervention. Cependant, un VAD seul ne peut pas distinguer une pause de la fin d’une prise de parole. C’est pourquoi on l’associe souvent à un modèle de fin d’énoncé, capable de prédire si l’utilisateur a terminé de parler, en se basant sur la transcription provisoire ou l’audio brut.

Exemples (Hugging Face) : livekit/turn-detector, pipecat-ai/smart-turn-v3

Agent

L’agent constitue le cœur de la chaîne vocale. Il est chargé de comprendre l’intention, de récupérer le bon contexte et de formuler une réponse sous forme de texte. Elastic Agent Builder, avec ses fonctions de raisonnement intégrées, sa bibliothèque d’outils et son intégration aux workflows, permet de créer un agent capable d’exploiter vos données et d’interagir avec des services externes.

LLM (texte à texte)

Pour choisir un LLM dans Elastic Agent Builder, deux critères principaux sont à prendre en compte : les benchmarks de raisonnement du LLM et le temps jusqu’au premier jeton (TTFT).

Les benchmarks de raisonnement mesurent la capacité du LLM à produire des réponses pertinentes. Les benchmarks à privilégier sont ceux qui évaluent la cohérence des conversations à plusieurs tours et les capacités cognitives, comme MT-Bench et le jeu de données Humanity’s Last Exam, respectivement.

Les benchmarks TTFT évaluent la rapidité avec laquelle le modèle génère son premier jeton en sortie. Il existe d’autres types de benchmarks de latence, mais le TTFT est particulièrement crucial pour les agents vocaux, car la synthèse vocale peut démarrer dès réception du premier jeton. Résultat : une latence réduite entre les prises de parole et une conversation plus naturelle.

Il faut souvent faire un compromis entre ces deux critères, car les modèles plus rapides obtiennent généralement de moins bons résultats aux tests de raisonnement.

Exemples (Hugging Face) : openai/gpt-oss-20b, openai/gpt-oss-120b

Synthèse (texte à la parole)

La dernière étape de la chaîne consiste à convertir le texte en parole grâce à un modèle de synthèse vocale. Ce composant est chargé de convertir le texte généré par le LLM en parole audible. Comme pour les LLM, la latence est un critère important lors du choix d’un fournisseur de synthèse vocale. La latence de la synthèse vocale se mesure au temps jusqu’au premier octet (TTFB). C’est le délai nécessaire pour recevoir le tout premier octet audio. Un TTFB plus court permet aussi de réduire la latence entre les prises de parole.

Exemples : ElevenLabs, Cartesia, Rime

Construction du pipeline vocal

Elastic Agent Builder peut s’intégrer dans une chaîne vocale à différents niveaux :

1. Outils Agent Builder uniquement : reconnaissance vocale → LLM (avec outils Agent Builder) → synthèse vocale

2. Agent Builder en tant que MCP : reconnaissance vocale → LLM (avec accès Agent Builder via MCP) → synthèse vocale

3. Agent Builder comme noyau central : reconnaissance vocale → Agent Builder → synthèse vocale

Pour ce projet, j’ai choisi d’utiliser Agent Builder comme solution centrale. Cette approche permet de tirer pleinement parti des fonctionnalités d’Agent Builder et des workflows. Le projet s’appuie sur LiveKit pour orchestrer la reconnaissance vocale, la détection de prise de parole et la synthèse vocale. Il implémente également un nœud LLM personnalisé, directement intégré à Agent Builder.

Agent vocal de support technique Elastic

Nous allons créer un agent vocal de support personnalisé pour une boutique de sport fictive, appelée ElasticSport. Les clients pourront appeler la ligne d’assistance, demander des recommandations de produits, consulter les fiches produit, vérifier le statut de leurs commandes, et recevoir les informations par message texte. Pour cela, nous devons commencer par configurer un agent personnalisé et créer des outils permettant d’exécuter des requêtes Elasticsearch Query Language (ES|QL) ainsi que des workflows.

Configuration de l'agent

Invite

L’invite détermine la personnalité que doit adopter l’agent et la façon dont il doit répondre. Il existe également quelques invites spécifiques à la voix, qui garantissent une synthèse vocale fluide et permettent de gérer élégamment les incompréhensions.

Workflows

Nous allons ajouter un petit workflow permettant d’envoyer un SMS via l’API de messagerie de Twilio. Ce workflow sera exposé à l’agent personnalisé sous forme d’outil, afin que l’agent puisse envoyer un SMS à l’appelant pendant l’appel. Cela permet à l’appelant, par exemple, de demander : « Pouvez-vous m’envoyer plus de détails sur X par SMS ? »

Outils ES|QL

Les outils suivants permettent à l’agent de fournir des réponses pertinentes, basées sur des données réelles. Le dépôt d’exemple contient un script d’initialisation de Kibana avec des jeux de données produits, commandes et base de connaissances.

• Product.search

Le jeu de données produit contient 65 produits fictifs. Voici un exemple de document :

Les champs « name » et « description » sont mappés sur semantic_text, ce qui permet au LLM d’effectuer une recherche sémantique via ES|QL pour retrouver les produits pertinents. La requête de recherche hybride effectue une correspondance sémantique sur les deux champs, en appliquant une pondération légèrement supérieure au champ « name » grâce à un boost.

La requête récupère d’abord les 20 meilleurs résultats, classés selon leur score de pertinence initial. Ces résultats sont ensuite reclassés en fonction de leur champ « description » à l’aide du modèle d’inférence .rerank-v1-elasticsearch , puis réduits aux cinq produits les plus pertinents.

• Knowledgebase.search

Les jeux de données de la base de connaissances contiennent des documents structurés comme suit, avec les champs de titre et de contenu stockés sous forme de texte sémantique :

L’outil utilise une requête similaire à celle de product.search :

• Orders.search

Le dernier outil que nous allons ajouter permet de récupérer les commandes à partir de order_id :

Une fois l’agent configuré et les workflows ainsi que les outils ES|QL associés, vous pouvez tester l’agent dans Kibana.

Au-delà de l’agent de support ElasticSport, l’agent, les workflows et les outils peuvent être adaptés à d’autres cas d’usage, comme un agent commercial pour qualifier des prospects, un agent de dépannage à domicile, un système de réservation pour restaurant ou encore un agent de planification de rendez-vous.

La dernière étape consiste à connecter l’agent que nous venons de créer à LiveKit, à la synthèse vocale et à la reconnaissance vocale. Le dépôt mentionné à la fin de ce billet contient un nœud LLM personnalisé pour Elastic Agent Builder, compatible avec LiveKit. Il vous suffit de remplacer AGENT_ID par le vôtre et de le connecter à votre instance Kibana.

Premiers pas

Consultez le code et testez-le vous-même ici.

Après tout, tout ce qui figure dans le contexte influence les réponses de l’IA. Le principe de l'entrée et de la sortie des déchets est vrai.

Dans cet article, nous allons présenter ce que signifie la mémoire à court et à long terme pour les agents IA, en particulier :

• La différence entre la mémoire à court terme et la mémoire à long terme.

• Comment elles se rapportent aux techniques de génération augmentée de récupération (RAG) avec des bases vectorielles, comme Elasticsearch, et pourquoi une gestion attentive de la mémoire est nécessaire.

• Les risques liés à la négligence de la mémoire, y compris le débordement de contexte et l'empoisonnement contextuel.

• Les bonnes pratiques, telles que l'élagage du contexte, la synthèse et la récupération uniquement des informations pertinentes, permettent de maintenir la mémoire de l'agent à la fois utile et sécurisée.

• Enfin, nous examinerons comment la mémoire peut être partagée et propagée dans les systèmes multi-agents pour permettre une collaboration sans confusion grâce à Elasticsearch.

Mémoire à court terme versus mémoire à long terme dans les agents d’IA

La mémoire à court terme dans un agent IA fait généralement référence au contexte ou à l’état immédiat de la conversation — essentiellement, l’historique de discussion actuel ou les messages récents dans la session active. Cela inclut la dernière requête de l’utilisateur et les échanges récents d’allers-retours. C’est très similaire aux informations qu’une personne garde en tête lors d’une conversation en cours.

Les frameworks d'IA maintiennent souvent cette mémoire transitoire dans l'état de l'agent (par exemple, en utilisant un pointeur de contrôle pour stocker l'état de la conversation, comme le montre cet exemple de LangGraph). La mémoire à court terme est limitée à une session, c'est-à-dire qu'elle existe dans le cadre d'une conversation ou d'une tâche unique et qu'elle est réinitialisée ou effacée à la fin de cette session, à moins qu'elle ne soit explicitement sauvegardée ailleurs. Un exemple de mémoire à court terme liée à une session serait le chat temporairedisponible dans ChatGPT.

La mémoire à long terme, en revanche, désigne les informations qui persistent au fil des conversations ou des sessions. Il s'agit des connaissances qu'un agent conserve au fil du temps, des faits qu'il a appris précédemment, des préférences de l'utilisateur ou de toute autre donnée que nous lui avons demandé de garder en mémoire de manière permanente.

La mémoire à long terme est généralement mise en œuvre en stockant et en récupérant les données à partir d'une source externe, telle qu'un fichier ou une base vectorielle située en dehors de la fenêtre contextuelle immédiate. Contrairement à l'historique de discussion à court terme, la mémoire à long terme n’est pas automatiquement incluse dans chaque requête. Au lieu de cela, sur la base d'un scénario donné, l'agent doit le rappeler ou le retrouver lorsque les outils pertinents sont invoqués. En pratique, la mémoire à long terme peut inclure les informations de profil de l’utilisateur, des réponses ou analyses antérieures produites par l’agent, ou une base de connaissances que l’agent peut consulter.

Par exemple, si vous avez un agent planificateur de voyage, la mémoire à court terme contiendrait les détails de la demande de voyage actuelle (dates, destination, budget) et toutes les questions de suivi dans cette conversation ; tandis que la mémoire à long terme pourrait stocker les préférences générales de voyage de l'utilisateur, les itinéraires passés et d'autres faits partagés lors de sessions précédentes. Lorsque l'utilisateur revient plus tard, l'agent peut puiser dans cette base de données à long terme (par exemple, l'utilisateur aime les plages et les montagnes, dispose d'un budget moyen de 100 000 INR, a une liste de lieux à visiter et préfère découvrir l'histoire et la culture plutôt que les attractions pour enfants) afin de ne pas traiter l'utilisateur comme une page blanche à chaque fois.

La mémoire à court terme (historique des conversations) fournit un contexte immédiat et une continuité, tandis que la mémoire à long terme fournit un contexte plus large dans lequel l'agent peut puiser en cas de besoin. Les cadres d'agents d'IA les plus avancés permettent les deux : ils gardent la trace des dialogues récents pour maintenir le contexte et proposent des mécanismes pour rechercher ou stocker des informations dans un référentiel à plus long terme. La gestion de la mémoire à court terme garantit qu'elle reste dans la fenêtre de contexte, tandis que la gestion de la mémoire à long terme aide l'agent à ancrer les réponses sur la base d'interactions et de personas antérieures.

Mémoire et RAG en ingénierie contextuelle

Comment pouvons-nous donner à un agent IA une mémoire à long terme utile en pratique ?

La mémoire sémantique, souvent mise en œuvre par le biais de la retrieval-augmented generation (RAG), constitue l'une des principales approches pour la mémoire à long terme. Cela consiste à couler le LLM avec un stockage de connaissances externe ou un datastore vectoriel, comme Elasticsearch. Lorsque le LLM a besoin d'informations au-delà de ce qui est contenu dans l'invite ou dans son entraînement intégré, il effectue une récupération sémantique contre Elasticsearch et injecte les résultats les plus pertinents dans l'invite en tant que contexte. Ainsi, le contexte effectif du modèle inclut non seulement la conversation récente (mémoire à court terme), mais aussi des faits pertinents à long terme récupérés à la volée. Le LLM fonde ensuite sa réponse sur son propre raisonnement et les informations récupérées, combinant efficacement la mémoire à court terme et la mémoire à long terme pour produire une réponse plus précise et contextuelle.

Elasticsearch peut être utilisé pour mettre en place une mémoire à long terme pour les agents d’IA. Voici un exemple de haut niveau montrant comment le contexte peut être récupéré depuis Elasticsearch pour la mémoire à long terme.

De cette façon, l’agent « se souvient » en recherchant des données pertinentes plutôt que de tout stocker dans son invite limitée, ce qui entraîne différents risques.

L'utilisation de RAG avec Elasticsearch ou tout stockage de vecteurs offre de multiples avantages :

Premièrement, il étend la connaissance du modèle au-delà de son seuil d'apprentissage. L’agent peut récupérer des informations à jour ou des données spécifiques au domaine que le LLM pourrait ne pas connaître. Ceci est crucial pour les questions concernant des événements récents ou des sujets spécialisés.

Deuxièmement, récupérer le contexte à la demande aide à réduire les hallucinations, surtout que les LLM ne sont pas entraînés sur des données propriétaires ou très spécialisées par rapport à votre cas d'utilisation spécifique, ce qui est très susceptible de les exposer à des hallucinations. Au lieu que le LLM devine ou invente de nouvelles informations comme il a été incité par évaluation, comme l’a souligné un article récent d’OpenAI (Why Language Models Hallucinate), le modèle peut être fondé sur des références factuelles provenant d’Elasticsearch. Bien entendu, le LLM dépend de la fiabilité des données du référentiel vectoriel pour prévenir véritablement la désinformation, et les données pertinentes sont extraites conformément aux mesures de pertinence fondamentales.

Troisièmement, RAG permet à un agent de travailler avec des bases de connaissances bien plus vastes que tout ce que vous pourriez inclure dans une invite. Au lieu d'insérer des documents entiers, comme de longs documents de recherche ou des documents politiques, dans la fenêtre contextuelle et de risquer une surcharge ou un empoisonnement du contexte du raisonnement du modèle par une information non pertinente, RAG s'appuie sur le découpage. Les documents volumineux sont divisés en morceaux plus petits et sémantiquement significatifs, et le système ne récupère que les quelques segments les plus pertinents pour la requête. Ainsi, le modèle n'a pas besoin d'un contexte d'un million de mots pour paraître bien informé ; il lui suffit d'avoir accès aux bons morceaux d'un corpus beaucoup plus vaste.

Il est important de noter qu’à mesure que les fenêtres contextuelles des LLM se sont agrandies (certains modèles supportent désormais des centaines de milliers, voire des millions de jetons), un débat a surgi sur la question de savoir si RAG est « mort ». Pourquoi ne pas intégrer toutes les données dans l'invite ? Si vous êtes du même avis, reportez-vous à cet excellent article de mes collègues Jeffrey Rengifo et Eduard Martin, Longer context ≠ better : Why RAG still matters. Cela évite le problème du « déchets en entrée, déchets en sortie » : le LLM reste concentré sur les quelques morceaux qui comptent, plutôt que de parcourir du bruit.

Cela dit, l'intégration d'Elasticsearch ou de n'importe quelle mémoire vectorielle dans une architecture d'agent d'IA offre une mémoire à long terme. L'agent stocke les connaissances à l'extérieur et les intègre au contexte de la mémoire en cas de besoin. Cela pourrait être implémenté sous forme d’architecture, où après chaque requête utilisateur, l’agent effectue une recherche sur Elasticsearch pour des informations pertinentes puis ajoute les premiers résultats à l’invite avant d’appeler le LLM. La réponse peut également être enregistrée dans le stockage à long terme si elle contient de nouvelles informations utiles (création d'une boucle d'apprentissage). En utilisant cette mémoire basée sur la récupération, l’agent reste informé et à jour, sans avoir à tout condenser dans chaque invite, même si la fenêtre de contexte prend en charge un million de tokens. Cette technique est une pierre angulaire de l'ingénierie contextuelle, combinant les forces de la récupération d'informations et de l'IA générative.

Voici un exemple d'état de conversation géré en mémoire utilisant le système de points de contrôle de LangGraph pour la mémoire à court terme pendant la session. (Reportez-vous à notre application d'ingénierie contextuelle.)

Voici comment il stocke les points de contrôle :

Pour la mémoire à long terme, voici comment nous effectuons une recherche sémantique sur Elasticsearch pour récupérer des conversations précédentes pertinentes en utilisant des vecteurs d'intégration après la résumé et l'indexation des points de contrôle dans Elasticsearch.

Maintenant que nous avons exploré comment la mémoire à court terme et la mémoire à long terme sont indexées et récupérées à l’aide des points de contrôle de LangGraph dans Elasticsearch, prenons un moment pour comprendre pourquoi l'indexation et le vidage des conversations complètes peut être risqué.

Risques liés à une mauvaise gestion de la mémoire de contexte

Alors que nous parlons beaucoup d’ingénierie du contexte, ainsi que de la mémoire à court et à long terme, comprenons ce qui se passe si nous ne gérons pas bien la mémoire et le contexte d’un agent.

Malheureusement, de nombreux problèmes peuvent survenir lorsque le contexte d’une IA devient extrêmement long ou contient des informations erronées. Au fur et à mesure que les fenêtres contextuelles s’agrandissent, de nouveaux modes de défaillance apparaissent, comme :

• Empoisonnement contextuel

• Distraction contextuelle

• Confusion de contexte

• Conflit de contexte

• Fuite de contexte et conflits de connaissances

• Hallucinations et désinformation.

Examinons ces problèmes et les autres risques qui découlent d'une mauvaise gestion du contexte :

Empoisonnement contextuel

L'empoisonnement du contexte fait référence au fait que des informations incorrectes ou nuisibles apparaissent dans le contexte et « empoisonne » les sorties ultérieures du modèle. Un exemple courant est une hallucination du modèle qui est traitée comme un fait et insérée dans l'historique de la conversation. Le modèle pourrait alors s'appuyer sur cette erreur dans les réponses ultérieures, aggravant la faute. Dans les boucles itératives d'agents, une fois qu'une fausse information s'est intégrée dans le contexte partagé (par exemple, dans un résumé des notes de travail de l'agent), elle peut être renforcée à maintes reprises.

Les chercheurs de DeepMind, dans la publication du rapport Gemini 2.5 (TL;DR, consultez ici), ont observé ce phénomène chez un agent joueur de Pokémon delongue date : si l'agent hallucinait un état de jeu erroné et que celui-ci était enregistré dans son contexte (sa mémoire des objectifs), il formait des stratégies absurdes autour d'un objectif impossible et se retrouvait bloqué. En d'autres termes, une mémoire empoisonnée peut envoyer l'agent sur la mauvaise voie indéfiniment.

L'empoisonnement du contexte peut se produire de manière innocente (par erreur) ou même de manière malveillante, par exemple via des attaques par injection de requêtes où un utilisateur ou un tiers introduit une instruction cachée ou une fausse information que l'agent mémorise ensuite et suit.

Contre-mesures recommandées :

S’appuyant sur les informations de Wiz, Zerlo et Anthropic, les contre-mesures contre l’empoisonnement du contexte visent à empêcher que des informations erronées ou trompeuses ne pénètrent dans l’invite, la fenêtre de contexte ou le pipeline de récupération d’un LLM. Parmi les principales étapes, citons :

• Vérifiez constamment le contexte : surveillez la conversation ou le texte récupéré afin de détecter tout élément suspect ou nuisible, et pas seulement l’invite de départ.

• Utilisez des sources fiables : attribuez une note ou un label aux documents en fonction de leur crédibilité afin que le système privilégie les informations fiables et ignore les données mal notées.

• Repérez les données inhabituelles : utilisez des outils qui détectent les contenus bizarres, déplacés ou manipulés, et supprimez-les avant que le modèle ne les utilise.

• Filtrez les entrées et les sorties : ajoutez des garde-fous pour que les textes nuisibles ou trompeurs ne puissent pas facilement entrer dans le système ou être répétés par le modèle.

• Mettez le modèle à jour avec des données propres : actualisez régulièrement le système avec des informations vérifiées afin de corriger les éventuelles données erronées.

• Supervision humaine : faites examiner les sorties importantes par des personnes ou comparez-les à des sources connues et fiables.

De simples habitudes utilisateur sont également utiles : réinitialiser les longues conversations, ne partager que les informations pertinentes, découper les tâches complexes en étapes plus simples et conserver des notes claires en dehors du modèle.

Ensemble, ces mesures créent une défense en couches qui protège les LLM contre l'empoisonnement du contexte et maintient les sorties précises et dignes de confiance.

Sans les contre-mesures mentionnées ici, un agent pourrait se souvenir d'instructions, comme ignorer des lignes directrices antérieuresou des faits triviaux insérés par un attaquant, ce qui conduirait à des sorties nuisibles.

Distraction contextuelle

On parle de distraction contextuelle lorsqu'un contexte devient si long que le modèle se concentre excessivement sur le contexte, négligeant ce qu'il a appris pendant la formation. Dans les cas extrêmes, cela ressemble à un oubli catastrophique, c'est-à-dire que le modèle « oublie » effectivement ses connaissances sous-jacentes et s'attache excessivement aux informations qui lui sont présentées. Des études précédentes ont montré que les LLM perdent souvent leur concentration lorsque l'invite est extrêmement longue.

L'agent Gemini 2.5, par exemple, prenait en charge une fenêtre d'un million de jetons, mais dès que son contexte dépassait un certain seuil (de l'ordre de 100 000 jetons dans une expérience), il commençait à s'attacher à répéter ses actions passées au lieu de proposer de nouvelles solutions. En un sens, l’agent est devenu prisonnier de sa longue histoire. Il a continué à regarder son long log de mouvements précédents (le contexte) et à les imiter, plutôt que d'utiliser ses connaissances d'entraînement sous-jacentes pour concevoir des stratégies nouvelles et inédites.

C'est contreproductif. Nous voulons que le modèle utilise un contexte pertinent pour faciliter le raisonnement, et non qu'il prenne le pas sur sa capacité de réflexion. Fait notable, même les modèles disposant de fenêtres très larges présentent une forme de dégradation du contexte : leurs performances se détériorent de manière non uniforme à mesure que le nombre de jetons augmente. Il semble exister un budget d’attention : tout comme les humains ont une mémoire de travail limitée, un LLM dispose d’une capacité finie pour traiter les jetons, et plus ce budget est sollicité, plus sa précision et sa concentration diminuent.

Pour atténuer ce problème, vous pouvez empêcher la distraction contextuelle en utilisant la segmentation, en concevant les bonnes informations, en résumant régulièrement le contexte et en appliquant des techniques d’évaluation et de surveillance pour mesurer la précision de la réponse à l’aide de la notation.

Ces méthodes permettent au modèle de rester ancré dans un contexte pertinent et dans sa formation sous-jacente, ce qui réduit le risque de distraction et améliore la qualité globale du raisonnement.

Confusion de contexte

La confusion contextuelle se produit lorsque le modèle utilise du contenu superflu dans le contexte pour générer une réponse de faible qualité. Un bon exemple est de fournir à un agent un large éventail d'outils ou de définitions d'API qu'il peut utiliser. Si bon nombre de ces outils n'ont aucun rapport avec la tâche en cours, le modèle peut tout de même essayer de les utiliser de manière inappropriée, simplement parce qu'ils sont présents dans le contexte. Les expériences ont montré que fournir plus d'outils ou de documents peut nuire aux performances s'ils ne sont pas tous nécessaires. L’agent commence à faire des erreurs, comme appeler la mauvaise fonction ou référer un texte sans importance.

Dans un cas, un petit modèle Llama 3.1 8B a échoué à une tâche lorsqu'on lui a donné 46 outils à prendre en compte, mais a réussi lorsqu'on ne lui a donné que 19 outils. Ces outils supplémentaires ont créé de la confusion, même si le contexte respectait les limites de longueur. Le problème sous-jacent est que toute information contenue dans l'invite sera prise en compte par le modèle. Si un système ne sait pas ignorer quelque chose, ce quelque chose pourrait influencer sa sortie de manière indésirable. Des éléments non pertinents peuvent « détourner » une partie de l'attention du modèle et l'induire en erreur (par exemple, un document non pertinent pourrait amener l'agent à répondre à une question différente de celle posée). La confusion contextuelle se manifeste souvent par la production, par le modèle, d'une réponse de faible qualité intégrant un contexte non pertinent. Se référer à l'article de recherche : Less is More: Optimizing Function Calling for LLM Execution on Edge Devices.

Cela nous rappelle qu'il n'est pas toujours préférable d'avoir plus de contexte, surtout si ce n'est pas organisé pour des raisons de pertinence.

Conflit de contexte

Il y a conflit de contexte lorsque des éléments du contexte se contredisent, provoquant des incohérences internes qui font dérailler le raisonnement du modèle. Un conflit peut survenir si l'agent accumule plusieurs éléments d'information qui sont en conflit.

Par exemple, imaginez un agent qui a récupéré des données de deux sources : l'une dit Le vol A part à 17 h, et l'autre dit Le vol A part à 18 h. Si les deux faits se retrouvent dans le contexte, le modèle pauvre n'a aucun moyen de savoir lequel est correct ; il peut s'embrouiller ou produire une réponse incorrecte ou non similaire.

Le conflit de contexte se produit aussi fréquemment dans les conversations à plusieurs tours, lorsque les tentatives de réponse antérieures du modèle sont encore présentes dans le contexte avec des informations affinées ultérieurement.

Une étude menée par Microsoft et Salesforce montre que si l'on divise une requête complexe en plusieurs échanges avec un chatbot (en ajoutant progressivement des détails), la précision finale diminue considérablement, comparée à la fourniture de tous les détails en une seule requête. Pourquoi ? Parce que les premiers tours contiennent des réponses intermédiaires partielles ou incorrectes du modèle, et que celles-ci restent dans le contexte. Lorsque le modèle tente par la suite de répondre avec toutes les informations, sa mémoire contient encore ces tentatives erronées, qui entrent en conflit avec les informations corrigées et l'éloignent de la bonne voie. En substance, le contexte de la conversation entre en conflit avec lui-même. Le modèle peut utiliser par inadvertance un élément de contexte obsolète (d'un tour précédent) qui ne s'applique plus après l'ajout de nouvelles informations.

Dans les systèmes agents, le conflit de contexte est particulièrement dangereux, car un agent peut combiner des sorties provenant de différents outils ou sous-agents. Si ces sorties divergent, le contexte agrégé est incohérent. L'agent pourrait alors se retrouver bloqué ou produire des résultats absurdes en essayant de réconcilier les contradictions. Prévenir les conflits de contexte implique de s’assurer que le contexte est frais et cohérent,par exemple en effaçant .ou en mettant à jour toute information obsolète et en ne mélangeant pas les sources qui n’ont pas été vérifiées pour leur cohérence.

Fuite de contexte et conflits de connaissances

Dans les systèmes où plusieurs agents ou utilisateurs partagent un stockage de mémoire, il existe un risque de fuite d'informations entre les contextes.

Par exemple, si les intégrations de données de deux utilisateurs distincts résident dans la même base vectorielle sans un contrôle d’accès approprié, un agent répondant à la requête de l’utilisateur A pourrait accidentellement récupérer une partie de la mémoire de l’utilisateur B. Cette fuite intercontextuelle peut révéler des informations privées ou simplement créer de la confusion dans les réponses.

Selon le Top 10 de l'OWASP pour les applications LLM, les bases vectorielles multitenant doivent se prémunir contre de telles fuites :

Selon LLM08:2025 Vector and Embedding Weaknesses, l'un des risques courants est la fuite de contexte :

Un autre aspect est qu'un LLM peut avoir du mal à remplacer ses connaissances intégrées par de nouvelles informations de mémoire. Si le modèle a été formé sur la base d'un fait et que le contexte retrouvé dit le contraire, le modèle peut ne pas savoir à quoi se fier. Sans une conception appropriée, l'agent pourrait confondre les contextes ou ne pas mettre à jour les anciennes connaissances avec de nouvelles preuves, conduisant à des réponses obsolètes ou incorrectes.

Hallucinations et désinformation.

Si l'hallucination (le LLM invente des informations plausibles mais fausses) est un problème connu, même sans contexte prolongé, une mauvaise gestion de la mémoire peut l'amplifier.

Si la mémoire de l'agent manque d'un fait crucial, le modèle peut simplement combler cette lacune par une supposition, et si cette supposition entre ensuite dans le contexte (en l'empoisonnant), l'erreur persiste.

Le rapport de sécurité OWASP LLM (LLM09:2025 Désinformation) met en évidence la désinformation comme une vulnérabilité fondamentale : les LLM peuvent produire des réponses confiantes mais fabriquées, et les utilisateurs peuvent leur accorder trop de crédit. Un agent dont la mémoire à long terme est mauvaise ou obsolète peut citer en toute confiance une information qui était vraie l'année dernière mais qui est fausse aujourd'hui, à moins que sa mémoire ne soit mise à jour.

Une dépendance excessive à la sortie de l'IA (par l'utilisateur ou l'agent lui-même dans la boucle) peut aggraver cette situation. Si personne ne vérifie jamais les informations en mémoire, l'agent peut accumuler de fausses informations. C’est pourquoi la méthode RAG est souvent utilisée pour réduire les hallucinations : en se référant à une source faisant autorité, le modèle n’a pas besoin d’inventer des faits. Mais si votre recherche aboutit au mauvais document (par exemple, un document contenant des informations erronées) ou si une hallucination précoce n'est pas élaguée, le système peut propager ces informations erronées dans toutes ses actions.

En résumé : une mauvaise gestion de la mémoire peut conduire à des sorties incorrectes et trompeuses, ce qui peut être préjudiciable, surtout si les enjeux sont importants (par exemple, de mauvais conseils dans le domaine financier ou médical). Un agent doit disposer de mécanismes pour vérifier ou corriger le contenu de sa mémoire, et non simplement faire confiance de manière inconditionnelle à ce qui se trouve dans le contexte.

En résumé, doter un agent d'IA d'une mémoire infiniment longue ou déverser tout ce qui est possible dans son contexte n' est pas une recette pour le succès.

Bonnes pratiques pour la gestion de la mémoire dans les applications LLM

Pour éviter les pièges ci-dessus, les développeurs et les chercheurs ont élaboré un certain nombre de bonnes pratiques pour gérer le contexte et la mémoire dans les systèmes d'IA. Ces pratiques visent à maintenir le contexte de travail de l'IA allégé, pertinent et actualisé. Voici quelques-unes des stratégies clés, accompagnées d'exemples de leur utilité.

RAG : utiliser le contexte ciblé.

Une grande partie de RAG a déjà été abordée dans la section précédente, ceci constitue donc un rappel pratique et concis :

• Utilisez une récupération ciblée, pas un chargement en masse : récupérez uniquement les extraits les plus pertinents au lieu d'insérer des documents entiers ou des historiques de conversation complets dans l'invite.

• Considérez RAG comme un rappel de mémoire à la demande : récupérez le contexte uniquement lorsqu’il est nécessaire, plutôt que de tout conserver d’un échange à l’autre.

• Privilégiez des stratégies de récupération sensibles à la pertinence : des approches telles que la recherche sémantique top-k, la fusion de rangs réciproques (Reciprocal Rank Fusion) ou le filtrage par configuration d’outils permettent de réduire le bruit et d’améliorer l’ancrage.

• Des fenêtres de contexte plus larges ne suppriment pas le besoin de RAG : deux paragraphes hautement pertinents sont presque toujours plus efficaces que 20 pages vaguement liées.

Cela dit, RAG ne vise pas à ajouter plus de contexte ; il s’agit d’ajouter le bon contexte.

Chargement des outils

Le loadout d’outils consiste à donner à un modèle uniquement les outils dont il a réellement besoin pour une tâche. Le terme vient du jeu : vous choisissez une configuration qui convient à la situation. Trop d'outils vous ralentissent ; les mauvais sont à l'origine de l'échec. Les LLM se comportent de la même manière, selon l'article de recherche Less is more. Une fois que vous dépassez ~30 outils, les descriptions commencent à se chevaucher et le modèle se trouve dérouté. Plus de 100 outils, l'échec est presque garanti. Ce n’est pas un problème de fenêtre contextuelle, c’est une confusion de contexte.

Une solution simple et efficace est RAG-MCP. Au lieu de saisir tous les outils dans l'invite, les descriptions d'outils sont stockées dans une base vectorielle et seuls les outils les plus pertinents sont récupérés par demande. En pratique, cela permet de réduire la taille de l'équipement et de le concentrer, de raccourcir considérablement les instructions et d'améliorer la précision de la sélection des outils jusqu'à 3 fois.

Les modèles plus petits atteignent ce plafond encore plus tôt. La recherche montre qu'un modèle 8B échoue avec des dizaines d'outils mais réussit une fois que la configuration est réduite. La sélection dynamique des outils, parfois précédée d’une réflexion par un LLM sur ce dont il pense avoir besoin, peut améliorer les performances de 44 %, tout en réduisant la consommation d’énergie et la latence. La principale leçon est que la plupart des agents n’ont besoin que de quelques outils, mais à mesure que votre système se développe, la configuration des outils et le RAG-MCP deviennent des choix de conception de premier ordre.

Élagage du contexte : limiter la longueur de l'historique de conversation

Si une conversation se poursuit sur de nombreux tours, l'historique de discussion accumulé peut devenir trop volumineux pour tenir, entraînant un débordement de contexte ou devenant trop distrayant pour le modèle.

Le rognage consiste à supprimer ou à raccourcir par programmation les parties les moins importantes du dialogue au fur et à mesure qu'il grandit. Une forme simple consiste à supprimer les tours de parole les plus anciens lorsque vous atteignez une certaine limite, en ne conservant que les N derniers messages. Un élagage plus sophistiqué pourrait supprimer les digressions non pertinentes ou les instructions précédentes devenues inutiles. L'objectif est de ne pas encombrer la fenêtre contextuelle par les anciennes actualités.

Par exemple, si l’agent a résolu un sous-problème il y a 10 échanges et que nous sommes passés à autre chose depuis, nous pourrions supprimer cette partie de l’historique du contexte (en supposant qu’elle ne sera plus nécessaire). De nombreuses implémentations basées sur le chat font cela : elles assurent la maintenance d'une fenêtre dynamique de messages récents.

La suppression peut être aussi simple que le fait d’« oublier » les premières parties d’une conversation une fois qu’elles ont été résumées ou jugées non pertinentes. Ce faisant, nous réduisons le risque d'erreurs de débordement du contexte et nous réduisons également la distraction du contexte, de sorte que le modèle ne voit pas et ne se laisse pas distraire par un contenu ancien ou hors sujet. Cette approche ressemble beaucoup à celle des humains, qui ne se souviennent peut-être pas de chaque mot d’une conférence d’une heure, mais en retiennent les points essentiels.

Si vous avez des doutes sur l'élagage de contexte, comme le souligne l'auteur Drew Breunig ici, l'utilisation du modèle Provence (`naver/provence-reranker-debertav3-v1`), un élagueur de contexte léger (1,75 Go), efficace et précis pour la réponse aux questions, peut faire la différence. Il peut réduire de gros documents à seulement le texte le plus pertinent pour une requête donnée. Vous pouvez l'appeler à des intervalles précis.

Voici comment nous invoquons le modèle `provence-reranker` dans notre code pour élaguer le contexte :

Nous utilisons le modèle de reranker Provence (`naver/provence-reranker-debertav3-v1`) pour évaluer la pertinence des phrases. La filtration basée sur des seuils conserve les phrases au-dessus du seuil de pertinence. Nous introduisons également un mécanisme de repli, qui permet de revenir au contexte d'origine en cas d'échec de l'élagage. Enfin, le logging des statistiques permet de suivre le pourcentage de réduction en mode verbeux.

Synthèse du contexte : condenser les anciennes informations au lieu de les supprimer entièrement

Le résumé va de pair avec le découpage. Lorsque l’historique ou la base de connaissances devient trop vaste, vous pouvez utiliser le LLM pour générer un bref résumé des points importants et utiliser ce résumé à la place du contenu complet par la suite, comme nous l’avons fait dans notre code ci-dessus.

Par exemple, si un assistant IA a eu une conversation de 50 tours, au lieu d'envoyer tous les 50 tours au modèle au tour 51 (ce qui ne rentrera probablement pas), le système pourrait prendre les tours 1 à 40, demander au modèle de les résumer en un paragraphe, et ensuite ne fournir que ce résumé plus les 10 derniers tours dans la prochaine invite. De cette façon, le modèle reste conscient de ce qui a été discuté sans avoir besoin de tous les détails. Les premiers utilisateurs de chatbots faisaient cela manuellement en demandant : « Pouvez-vous résumer ce dont nous avons parlé jusqu'à présent ? » puis en continuant dans une nouvelle session avec le résumé. Maintenant, cela peut être automatisé. Le résumé permet non seulement d'économiser de l'espace dans la fenêtre contextuelle, mais aussi de réduire la confusion et la distraction en éliminant les détails supplémentaires et en ne conservant que les faits saillants.

Voici comment nous utilisons les modèles OpenAI (vous pouvez utiliser n’importe quel LLM) pour condenser le contexte tout en préservant toutes les informations pertinentes, en éliminant la redondance et la duplication.

Il est important de noter que lorsque le contexte est résumé, le modèle est moins susceptible d'être submergé par des détails insignifiants ou des erreurs passées (en supposant que le résumé soit exact).

Cependant, le résumé doit être fait avec soin. Un mauvais résumé peut omettre un détail crucial ou même introduire une erreur. Il s’agit essentiellement d’une autre invite adressée au modèle (« résumez ceci »), ce qui peut entraîner des hallucinations ou une perte de nuances. Une bonne pratique consiste à résumer de manière incrémentielle et peut-être conserver certains faits canoniques non résumés.

Néanmoins, il s'est avéré très utile. Dans le scénario de l'agent Gemini, le fait de résumer le contexte tous les 100 000 jetons environ a permis de contrecarrer la tendance du modèle à se répéter. Le résumé agit comme une mémoire compressée de la conversation ou des données. En tant que développeurs, nous pouvons mettre cela en œuvre en demandant à un agent d'appeler périodiquement une fonction de résumé (peut-être un LLM plus petit ou une routine dédiée) sur l'historique de la conversation ou un long document. Le résumé résultant remplace le contenu original dans la consigne. Cette tactique est largement utilisée pour limiter les contextes et distiller l'information.

Quarantaine contextuelle : isolez les contextes lorsque c'est possible

Cela est plus pertinent dans les systèmes d'agents complexes ou les workflows à plusieurs étapes. L'idée de la segmentation du contexte est de diviser une grande tâche en sous-tâches plus petites et isolées, chacune ayant son propre contexte, de sorte que vous n'accumuliez jamais un contexte énorme qui contient tout. Chaque sous-agent ou sous-tâche travaille sur une partie du problème dans un contexte précis, puis un agent de niveau supérieur, un superviseur ou un coordinateur intègre les résultats.

La stratégie de recherche d’Anthropic utilise plusieurs sous-agents, chacun examinant un aspect différent d’une question, avec ses propres fenêtre de contexte, et un agent principal qui lit les résultats synthétisés de ces sous-agents. Cette approche parallèle et modulaire signifie qu'aucune fenêtre contextuelle unique ne devient trop volumineuse. Cela réduit également le risque de mélange d'informations non pertinentes, chaque fil de discussion reste sur le sujet (pas de confusion de contexte), et il ne transporte pas de bagages superflus lors de la réponse à sa sous-question spécifique. Dans un sens, c'est comme suivre des fils de réflexion distincts qui ne partagent que leurs résultats, et non l'ensemble de leur processus de réflexion.

Dans les systèmes multi-agents, cette approche est essentielle. Si l'agent A gère la tâche A et l'agent B gère la tâche B, il n'y a aucune raison pour que l'un ou l'autre agent consomme le contexte complet de l'autre, sauf si c'est vraiment nécessaire. Les agents ne peuvent échanger que les informations nécessaires. Par exemple, l'agent A peut transmettre un résumé consolidé de ses résultats à l'agent B via un agent superviseur, tandis que chaque sous-agent assure la maintenance de son propre fil de contexte dédié. Cette configuration ne nécessite pas d'intervention humaine ; elle repose sur un agent de supervision doté d'outils activés avec un partage de contexte minimal et contrôlé.

Néanmoins, concevoir votre système de manière à ce que les agents ou les outils fonctionnent avec un chevauchement minimal du contexte nécessaire peut grandement améliorer la clarté et les performances. Pensez-y comme à des microservices pour l'IA, chaque composant s'occupe de son contexte, et vous passez des messages entre eux de manière contrôlée, au lieu d'un contexte monolithique. Ces bonnes pratiques sont souvent utilisées de manière combinée. Cela vous offre également la possibilité de supprimer l'historique trivial, de résumer les anciens messages ou conversations importants, de décharger les logs détaillés vers Elasticsearch pour un contexte à long terme et d'utiliser la récupération pour retrouver tout élément pertinent en cas de besoin.

Comme indiqué ici, le principe directeur est que le contexte est une ressource limitée et précieuse. Vous souhaitez que chaque élément de l'invite soit utile, c'est-à-dire qu'il contribue à la qualité de la sortie. Si quelque chose en mémoire ne joue pas son rôle (ou pire, provoque activement de la confusion), alors il devrait être élagué, résumé ou tenu à l'écart.

En tant que développeurs, nous pouvons désormais programmer le contexte comme nous programmons du code, en décidant quelles informations inclure, comment les formater et quand les omettre ou les mettre à jour. En suivant ces pratiques, nous pouvons fournir aux agents LLM le contexte indispensable pour effectuer des tâches sans être victimes des modes de défaillance décrits précédemment. Le résultat : des agents qui retiennent ce qu’ils doivent, oublient ce qui leur est inutile et récupèrent ce dont ils ont besoin juste à temps.

Conclusion

La mémoire n'est pas quelque chose que l'on ajoute à un agent, c'est quelque chose que l'on développe. La mémoire à court terme est le bloc-notes de travail de l'agent, et la mémoire à long terme est son stock de connaissances durable. RAG est le pont entre les deux, transformant un datastore passif, comme Elasticsearch, en un mécanisme de rappel actif qui peut ancrer les sorties et maintenir l'agent à jour.

Mais la mémoire est une arme à double tranchant. Dès que vous laissez le contexte se développer sans contrôle, vous invitez l'empoisonnement, la distraction, la confusion et les conflits, et dans les systèmes partagés, même des fuites de données. C’est pourquoi le travail de mémoire le plus important n’est pas de « stocker davantage », mais de « mieux sélectionner » : récupérer de manière sélective, élaguer avec rigueur, résumer avec soin et éviter de mélanger des contextes non liés, sauf si la tâche l’exige réellement.

En pratique, une bonne ingénierie du contexte ressemble à une bonne conception de systèmes : des contextes plus petits et suffisants, des interfaces contrôlées entre les composants, et une séparation claire entre l'état brut et l'état distillé que vous voulez réellement que le modèle voie. Si l'on procède correctement, on ne se retrouve pas avec un agent qui se souvient de tout, mais avec un agent qui se souvient des bonnes choses, au bon moment et pour la bonne raison.

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.

Nous avons récemment contribué au projet open source Google MCP Toolbox for Databases en ajoutant la prise en charge d'Elasticsearch en tant que base de données.

Grâce à cette nouvelle fonctionnalité, vous pouvez désormais utiliser Google MCP Toolbox pour vous connecter à Elasticsearch et "dialoguer" directement avec vos données.

Elasticsearch

Nous avons besoin d'une instance Elasticsearch en cours d'exécution. Vous pouvez activer un essai gratuit sur Elastic Cloud ou l'installer localement via le script start-local :

Cela installera Elasticsearch et Kibana sur votre ordinateur et générera une clé API à utiliser pour configurer Google MCP Toolbox.

La clé API sera affichée comme sortie de la commande précédente et stockée dans un fichier .env dans le dossier elastic-start-local.

Installer l'ensemble de données d'exemple

Après l'installation, connectez-vous à Kibana en utilisant le nom d'utilisateur elastic et le mot de passe généré par le script "start-local" (stocké dans un fichier .env).

Vous pouvez installer l'ensemble de données eCommerce orders disponible dans Kibana. Il comprend un seul index nommé kibana_sample_data_ecommerce contenant des informations sur 4 675 commandes provenant d'un site web. Pour chaque commande, nous disposons des informations suivantes :

• Informations client (nom, identifiant, date de naissance, e-mail, etc.)

• Date de la commande

• ID de la commande

• Produits (liste de tous les produits avec prix, quantité, ID, catégorie, réduction, etc.)

• SKU

• Prix total (hors taxes, taxes incluses)

• Quantité totale

• Informations géographiques (ville, pays, continent, localisation, région)

Pour installer les données d'exemple, ouvrez la page Intégrations dans Kibana (recherchez "Integration" dans la barre de recherche supérieure), puis installez l'ensemble de données "Sample Data". Pour plus de détails, consultez la documentation ici : https://www.elastic.co/docs/explore-analyze/#gs-get-data-into-kibana.

Cet article a pour but de montrer combien il est facile de configurer Google MCP Toolbox pour se connecter à Elasticsearch et interagir avec l'index kibana_sample_data_ecommerce en utilisant le langage naturel.

Google MCP Toolbox

Google MCP Toolbox est un serveur MCP open source conçu pour faciliter l'interaction sécurisée et efficace des applications et des agents IA avec les bases de données. Auparavant appelé "GenAI Toolbox for Databases", le projet a été renommé après l'adoption d'une compatibilité totale avec le protocole MCP (Model Context Protocol). Son objectif est de supprimer les tâches complexes traditionnellement requises lors de la connexion d'agents à des bases de données en gérant en arrière-plan les pools de connexion, l'authentification, l'observabilité et d'autres aspects opérationnels.

Essentiellement, la boîte à outils permet aux développeurs de définir des outils réutilisables de haut niveau qui encapsulent les interactions avec la base de données. Ces outils peuvent ensuite être invoqués par n'importe quel client compatible MCP, tel qu'un agent IA, sans que le client n'ait à implémenter des requêtes SQL de bas niveau ni à gérer des connexions de base de données. Cette approche réduit considérablement la quantité de code répétitif nécessaire à la création d'agents compatibles avec les bases de données, permettant ainsi d'intégrer des opérations de données avancées en seulement quelques lignes de logique applicative. Une fois qu'un outil est défini, il peut être partagé entre plusieurs agents, frameworks, ou langages (Figure 1).

L'un des principaux avantages de la boîte à outils est le modèle de sécurité intégré. Les flux d'authentification tels que OAuth2 et OIDC sont pris en charge de manière native, ce qui permet aux développeurs d'éviter de manipuler ou de stocker des informations sensibles d'identification de base de données dans les agents. La plateforme fournit également des fonctionnalités d'observabilité via OpenTelemetry, y compris les métriques et le traçage, ce qui est essentiel pour le débogage, la surveillance et les déploiements en production. De manière générale, MCP Toolbox sert d'interface unifiée, sécurisée et extensible pour interagir avec vos données depuis n'importe quel système compatible MCP.

Comment installer MCP Toolbox

Vous pouvez installer le serveur MCP Toolbox sur Linux en utilisant la commande suivante :

Si vous souhaitez l'installer sur macOS ou Windows, vous pouvez suivre les instructions détaillées ici.

Configurer Toolbox pour Elasticsearch

Pour configurer MCP Toolbox pour Elasticsearch, nous devons créer un fichier tools.yaml comme suit :

Vous devez remplacer la valeur <insert-here-api-key> par une clé API Elasticsearch valide. Si vous exécutez Elasticsearch localement avec la commande "start-local", vous trouverez la clé API dans le fichier .env généré par start-local, sous la variable ES_LOCAL_API_KEY. Si vous utilisez Elastic Cloud, vous pouvez générer une clé API en suivant la procédure décrite ici.

Les outils précédents contiennent la requête ES|QL suivante pour Elasticsearch :

Si vous ne connaissez pas ES|QL, il s'agit d'un langage de requête développé par Elastic, similaire à SQL, qui peut être utilisé pour effectuer des recherches sur un ou plusieurs indices. Pour en savoir plus sur ES|QL, consultez la documentation officielle ici.

La requête ci-dessus recherche toutes les commandes stockées dans l'index kibana_sample_data_ecommerce qui contiennent le nom du client spécifié, en utilisant le paramètre ?name (le point d'interrogation indique un paramètre).

Le nom du client est défini dans la configuration YAML précédente en utilisant le type chaîne et la description "The customer name" (nom du client).

Cet outil peut être utilisé pour répondre à des questions sur les commandes d'un client, par exemple : Combien de commandes le client Foo a-t-il passées en octobre 2025 ?

Les descriptions des outils et de leurs paramètres sont essentielles pour extraire les informations pertinentes de la requête en langage naturel de l'utilisateur. Cette extraction est réalisée à l'aide de la capacité d'appel de fonctions d'un grand modèle de langage (LLM). En pratique, un LLM peut déterminer quelle fonction (outil) doit être exécutée pour obtenir les informations nécessaires, ainsi que les paramètres appropriés pour cette fonction.

Pour plus d'informations sur les appels de fonctions, nous vous invitons à lire l'article OpenAI function calling with Elasticsearch (en anglais) par Ashish Tiwari.

Exécuter le serveur Toolbox

Vous pouvez exécuter le serveur MCP Toolbox à l'aide du fichier "tools.yaml" précédent avec la commande suivante :

Le paramètre –ui exécute une application web à l'adresse http://127.0.0.1:5000/ui (Figure 2).

Sélectionnez Tools (Outils) > customer-orders et insérez un nom de client dans le paramètre name (par ex. Gwen Sanders), puis cliquez sur le bouton Run Tool (Exécuter l'outil). Une réponse JSON devrait s'afficher comme illustré dans la figure 3.

La configuration est terminée et MCP Toolbox peut exécuter l'outil customer-orders pour communiquer avec Elasticsearch, en lançant la requête ES|QL.

Utiliser MCP Toolbox avec Gemini CLI

Nous pouvons utiliser n'importe quel client MCP pour communiquer avec MCP Toolbox for Databases. Par exemple, nous pouvons choisir Gemini CLI, un outil en ligne de commande permettant d'utiliser Gemini. Si vous souhaitez installer Gemini CLI, suivez les instructions indiquées ici.

Gemini CLI propose une extension préconfigurée pour MCP Toolbox, disponible sur gemini-cli-extensions/mcp-toolbox. Vous pouvez installer cette extension en exécutant la commande suivante :

Après l'installation, vous devez accéder au répertoire dans lequel vous avez stocké le fichier de configuration "tools.yaml" pour MCP Toolbox et exécuter Gemini CLI comme suit (cette étape est nécessaire pour que Gemini CLI soit automatiquement configuré avec MCP Toolbox) :

Un message de sortie devrait s'afficher comme illustré dans la figure 4.

Vous pouvez vérifier si la boîte à outils MCP est connectée en utilisant la commande suivante :

Vous devriez voir s'afficher mcp_toolbox avec les outils customer-orders répertoriés (Figure 5).

Si MCP Toolbox est connecté à Gemini CLI, nous pouvons maintenant poser quelques questions, telles que : "Indiquez-moi les commandes pour la cliente Gwen Sanders". Gemini CLI demande alors l'autorisation d'exécuter l'outil "customer-orders" depuis le serveur mcp_toolbox (voir Figure 6).

Après confirmation, Gemini CLI exécute la requête dans MCP Toolbox, reçoit une réponse JSON et l'utilise pour mettre en forme la réponse (Figure 7).

La réponse de Gemini CLI indique que Gwen Sanders a passé une seule commande de 2 produits, pour un prix total de 132 EUR.

SDK MCP Toolbox

Google MCP Toolbox propose également un SDK pour accéder à toutes les fonctionnalités depuis un programme écrit en Go, Python et Javascript.

Par exemple, le SDK Python est disponible sur Github à la page suivante : https://github.com/googleapis/mcp-toolbox-sdk-python.

Nous devons créer un agent simple pour nous connecter à MCP Toolbox. Nous devons installer les packages suivants :

Et créer un nouveau projet d'agent à l'aide la commande suivante :

Cela créera un nouveau répertoire nommé my_agent contenant un fichier agent.py.

Mettez à jour le fichier my_agent/agent.py avec le contenu suivant pour vous connecter à Toolbox :

Créez un fichier .env avec votre clé API Google :

Enfin, nous pouvons lancer l'exécution de l'agent et observer les résultats. Pour ce faire, exécutez la commande suivante :

Ou, vous pouvez le servir via une interface web :

Dans les deux cas, vous pouvez interagir avec MCP Toolbox à l'aide d'une interface de questions-réponses. Par exemple, vous pouvez poser la question précédente : Indiquez-moi les commandes de la cliente Gwen Sanders.

Pour plus d'informations sur les différents SDK, consultez cette page de documentation.

Conclusion

Dans cet article, nous avons démontré l'intégration d'Elasticsearch pour Google MCP Toolbox for Databases. À l'aide d'un simple fichier de configuration YAML, nous pouvons définir un ensemble d'outils qui traduisent les questions en langage naturel en requêtes Elasticsearch en utilisant le langage ES|QL.

Nous avons montré comment interagir avec l'ensemble de données "kibana_sample_data_ecommerce", qui contient des commandes provenant d'un site web. Avec ce fichier de configuration, nous pouvons simplement lancer l'exécution du serveur MCP Toolbox et nous y connecter depuis n'importe quel client MCP.

Enfin, nous avons démontré comment utiliser Gemini CLI en tant que client pour nous connecter à MCP Toolbox for Databases et interroger les données e-commerce stockées dans Elasticsearch. Nous avons exécuté une requête en langage naturel pour récupérer des informations sur les commandes d'un client spécifique identifié par son nom.

À mesure que l'écosystème MCP se développe, ce modèle – des définitions d'outils légères soutenues par une infrastructure sécurisée et prête pour la production – crée de nouvelles possibilités pour construire des agents de plus en plus performants et sensibles aux données avec un minimum d'efforts. Qu'il s'agisse d'expérimenter localement les ensembles de données Elastic ou d'intégrer des fonctionnalités de recherche dans une application plus vaste, MCP Toolbox fournit une base fiable et extensible pour interagir avec vos données Elasticsearch en langage naturel.

Pour en savoir plus sur le développement d'applications d'IA agentique, consultez l'article Construire des workflows d'IA agentique avec Elasticsearch par Anish Mathur et Dana Juratoni.

Pour plus d'informations sur Google MCP Toolbox, consultez la page vhttps://googleapis.github.io/genai-toolbox/getting-started/introduction/.

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.

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

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

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

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

Prérequis

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

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

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

• Compte Google (pour Google Colab)

• Compte ngrok (fonctionne avec le niveau gratuit)

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

Comprendre les exigences du connecteur ChatGPT MCP

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

Outil de recherche

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

Ce qu'il reçoit :

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

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

Ce qu'il renvoie : 

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

  • id - Identifiant de document unique

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

  • url - Lien vers l'issue/la PR

Dans notre implémentation :

Outil de récupération

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

Ce qu'il reçoit :

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

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

Ce qu'il renvoie :

• Objet de document complet contenant :

  • id - Identifiant de document unique

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

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

  • url - Lien vers l'issue/la PR

  • type - Type de document (issue, pull_request)

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

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

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

  • created_date - Date de création

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

  • labels - Balises associées au document

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

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

Issues GitHub et ensemble de données de PR

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

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

Cet ensemble de données comprend :

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

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

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

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

Mappings de l'index

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

Créer le serveur MCP

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

Outil de recherche

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

Points clés :

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

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

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

• Ajustement des paramètres RRF :

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

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

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

Outil de récupération

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

Points clés :

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

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

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

Déployer sur Google Colab

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

Étape 1 : Ouvrir le notebook Google Colab

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

Étape 2 : Configurer vos identifiants

Vous aurez besoin de trois informations :

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

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

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

Obtenir votre token ngrok

1. Créez un compte gratuit sur ngrok

2. Accédez à votre tableau de bord ngrok

3. Copier votre jeton d'authentification

Ajouter des secrets à Google Colab

Dans le notebook Google Colab :

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

2. Ajoutez ces trois secrets :

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

Étape 3 : Exécuter le notebook

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

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

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

4. La sortie affichera quelque chose comme :

Se connecter à ChatGPT

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

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

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

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

3. Cliquez sur Create (Créer).

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

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

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

• Nom : Elasticsearch MCP

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

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

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

Tester le serveur MCP

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

Prompt 1 : Recherchez les issues

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

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

Demande d'appel d'outil :

Réponse de l'outil :

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

En coulisses

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

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

2. Elasticsearch effectue une recherche hybride.

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

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

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

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

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

Prompt 2 : Obtenez tous les détails

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

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

Demande d'appel d'outil :

Réponse de l'outil :

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

En coulisses

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

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

2. Elasticsearch extrait le document complet

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

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

Conclusion

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

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

Introduction au RAG agentique

La Génération Augmentée de Récupération(RAG) est devenue la pierre angulaire des applications basées sur le LLM, permettant aux modèles de fournir des réponses optimales en récupérant le contexte pertinent basé sur les requêtes de l'utilisateur. Les systèmes RAG améliorent la précision et le contexte des réponses LLM en s'appuyant sur des informations externes provenant d'API ou de magasins de données, au lieu d'être limités à des connaissances LLM préformées. D'autre part, les agents d'intelligence artificielle fonctionnent de manière autonome, prenant des décisions et des mesures pour atteindre les objectifs qui leur sont assignés.

Le RAG agentique est un cadre qui unifie les forces de la génération augmentée par la recherche et du raisonnement agentique. Il intègre le RAG dans le processus décisionnel de l'agent, ce qui permet au système de choisir dynamiquement les sources de données, d'affiner les requêtes pour une meilleure récupération du contexte, de générer des réponses plus précises et d'appliquer une boucle de rétroaction pour améliorer continuellement la qualité des résultats.

Principales caractéristiques du RAG agentic

Le cadre agentique des RAG constitue une avancée majeure par rapport aux systèmes traditionnels de RAG. Au lieu de suivre un processus de recherche fixe, il s'appuie sur des agents dynamiques capables de planifier, d'exécuter et d'optimiser les résultats en temps réel.

Examinons quelques-unes des principales caractéristiques qui distinguent les pipelines RAG agentiques :

• Prise de décision dynamique: Le RAG agentique utilise un mécanisme de raisonnement pour comprendre l'intention de l'utilisateur et acheminer chaque requête vers la source de données la plus pertinente, produisant ainsi des réponses précises et adaptées au contexte.

• Analyse complète des requêtes : Agentic RAG analyse en profondeur les requêtes des utilisateurs, y compris les sous-questions et leur intention générale. Il évalue la complexité des requêtes et sélectionne de manière dynamique les sources de données les plus pertinentes pour récupérer les informations, garantissant ainsi des réponses précises et complètes.

• Collaboration en plusieurs étapes: Ce cadre permet une collaboration en plusieurs étapes grâce à un réseau d'agents spécialisés. Chaque agent s'occupe d'une partie spécifique d'un objectif plus large, travaillant de manière séquentielle ou simultanée pour atteindre un résultat cohérent.

• Mécanismes d'auto-évaluation: Le pipeline RAG agentique utilise l'autoréflexion pour évaluer les documents récupérés et les réponses générées. Il peut vérifier si les informations extraites répondent entièrement à la requête, puis vérifier l'exactitude, l'exhaustivité et la cohérence factuelle des résultats.

• Intégration avec des outils externes: Ce flux de travail peut interagir avec des API externes, des bases de données et des sources d'information en temps réel, en incorporant des informations actualisées et en s'adaptant dynamiquement à l'évolution des données.

Modèles de flux de travail des RAG agentiques

Les modèles de flux de travail définissent la manière dont l'IA agentique structure, gère et orchestre les applications basées sur le LLM de manière fiable et efficace. Plusieurs cadres et plateformes, tels que LangChain, LangGraph, CrewAI et LlamaIndex, peuvent être utilisés pour mettre en œuvre ces flux de travail agentiques.

1. Chaîne de récupération séquentielle: Les flux de travail séquentiels divisent les tâches complexes en étapes simples et ordonnées. Chaque étape améliore les données de l'étape suivante, ce qui permet d'obtenir de meilleurs résultats. Par exemple, lors de la création d'un profil de client, un agent peut extraire les détails de base d'un CRM, un autre récupère l'historique des achats dans une base de données de transactions, et un dernier agent combine ces informations pour générer un profil complet en vue de recommandations ou de rapports.

2. Chaîne de recherche de routage: Dans ce modèle de flux de travail, un agent routeur analyse l'entrée et la dirige vers le processus ou la source de données la plus appropriée. Cette approche est particulièrement efficace lorsqu'il existe plusieurs sources de données distinctes se chevauchant très peu. Par exemple, dans un système de service à la clientèle, l'agent de routage classe les demandes entrantes, telles que les problèmes techniques, les remboursements ou les réclamations, et les achemine vers le service approprié pour un traitement efficace.

3. Chaîne de recherche parallèle: Dans ce modèle de flux de travail, plusieurs sous-tâches indépendantes sont exécutées simultanément et leurs résultats sont ensuite agrégés pour générer une réponse finale. Cette approche permet de réduire considérablement le temps de traitement et d'accroître l'efficacité du flux de travail. Par exemple, dans un flux de travail parallèle de service à la clientèle, un agent récupère les demandes antérieures similaires et un autre consulte les articles pertinents de la base de connaissances. Un agrégateur combine ensuite ces résultats pour produire une résolution complète.

4. Chaîne de travail de l'Orchestrator: Ce flux de travail présente des similitudes avec la parallélisation en raison de l'utilisation de sous-tâches indépendantes. Cependant, une distinction essentielle réside dans l'intégration d'un agent orchestrateur. Cet agent est chargé d'analyser les requêtes des utilisateurs, de les segmenter dynamiquement en sous-tâches au cours de l'exécution et d'identifier les processus ou outils appropriés nécessaires pour formuler une réponse précise.

Construire un pipeline RAG agentique à partir de zéro

Pour illustrer les principes du RAG agentique, concevons un flux de travail utilisant LangChain et Elasticsearch. Ce flux de travail adopte une architecture basée sur le routage, où plusieurs agents collaborent pour analyser les requêtes, récupérer les informations pertinentes, évaluer les résultats et générer des réponses cohérentes. Vous pouvez vous référer à ce carnet Jupyter pour suivre cet exemple.

Le flux de travail commence par l'agent routeur, qui analyse la requête de l'utilisateur pour sélectionner la méthode de recherche optimale, c'est-à-dire l'approche vectorstore, websearch ou composite. Le magasin vectoriel gère la recherche traditionnelle de documents basée sur le RAG, la recherche sur le web récupère les informations les plus récentes qui ne sont pas stockées dans le magasin vectoriel, et l'approche composite combine les deux lorsque des informations provenant de sources multiples sont nécessaires.

Si les documents sont jugés appropriés, l'agent de synthèse génère une réponse claire et adaptée au contexte. Toutefois, si les documents sont insuffisants ou non pertinents, l'agent de réécriture des requêtes reformule la requête pour améliorer la recherche. Cette requête révisée réinitialise alors le processus de routage, ce qui permet au système d'affiner sa recherche et d'améliorer le résultat final.

Produits requis

Ce flux de travail s'appuie sur les composants de base suivants pour exécuter l'exemple de manière efficace :

• Python 3.10

• Bloc-notes Jupyter

• Azure OpenAI

• Elasticsearch

• LangChain

Avant de poursuivre, vous serez invité à configurer l'ensemble des variables d'environnement requises pour cet exemple.

Sources de données

Ce processus est illustré à l'aide d'un sous-ensemble du jeu de données AG News. L'ensemble des données comprend des articles d'actualité dans diverses catégories, telles que International, Sports, Affaires et Science/Technologie.

Le module ElasticsearchStore est utilisé à partir de langchain_elasticsearch comme magasin de vecteurs. Pour la recherche, nous mettons en œuvre la stratégie SparseVectorStrategy, en utilisant ELSER, le modèle d'intégration propriétaire d'Elastic. Il est essentiel de confirmer que le modèle ELSER est correctement installé et déployé dans votre environnement Elasticsearch avant d'initier le magasin de vecteurs.

La fonctionnalité de recherche sur le web est mise en œuvre à l'aide de DuckDuckGoSearchRun des outils de la communauté LangChain, ce qui permet au système de récupérer efficacement des informations en direct sur le web. Vous pouvez également envisager d'utiliser d'autres API de recherche qui peuvent fournir des résultats plus pertinents. Cet outil a été choisi car il permet d'effectuer des recherches sans avoir besoin d'une clé API.

L'extracteur composite est conçu pour les requêtes qui nécessitent une combinaison de sources. Il est utilisé pour fournir une réponse complète et contextuelle précise en récupérant simultanément des données en temps réel sur le web et en consultant les informations historiques du magasin de vecteurs.

Mise en place des agents

Dans l'étape suivante, les agents LLM sont définis pour fournir des capacités de raisonnement et de prise de décision au sein de ce flux de travail. Les chaînes LLM que nous créerons sont les suivantes router_chain, grade_docs_chain, rewrite_query_chain, et summary_chain.

L'agent routeur utilise un assistant LLM pour déterminer la source de données la plus appropriée pour une requête donnée au moment de l'exécution. L'agent de classement évalue la pertinence des documents récupérés. Si les documents sont jugés pertinents, ils sont transmis à l'agent de synthèse pour générer un résumé. Dans le cas contraire, l'agent de réécriture reformule la requête et la renvoie au processus de routage pour une nouvelle tentative de recherche. Vous trouverez les instructions pour tous les agents dans la section chaînes LLM du carnet de notes.

Le site llm.with_structured_output contraint les résultats du modèle à suivre un schéma prédéfini par le BaseModel sous la classe RouteQuery, ce qui garantit la cohérence des résultats. La deuxième ligne compose un RunnableSequence en reliant router_prompt à router_structured, formant un pipeline dans lequel l'invite d'entrée est traitée par le modèle de langage pour produire des résultats structurés et conformes au schéma.

Définir les nœuds d'un graphique

Cette partie consiste à définir les états du graphe, qui représentent les données circulant entre les différents composants du système. Une spécification claire de ces états garantit que chaque nœud du flux de travail sait à quelles informations il peut accéder et les mettre à jour.

Une fois les états définis, l'étape suivante consiste à définir les nœuds du graphe. Les nœuds sont en quelque sorte les unités fonctionnelles du graphique qui effectuent des opérations spécifiques sur les données. Il y a 7 nœuds différents dans notre pipeline.

Le nœud query_rewriter a deux fonctions dans le flux de travail. Tout d'abord, il réécrit la requête de l'utilisateur à l'aide du site rewrite_query_chain pour améliorer la recherche lorsque les documents évalués par l'agent d'autoréflexion sont jugés insuffisants ou non pertinents. Deuxièmement, il sert de compteur pour savoir combien de fois la requête a été réécrite.

Chaque fois que le nœud est invoqué, il incrémente le site retry_count stocké dans l'état du flux de travail. Ce mécanisme empêche le flux de travail d'entrer dans une boucle infinie. Si le site retry_count dépasse un seuil prédéfini, le système peut passer à un état d'erreur, à une réponse par défaut ou à toute autre condition prédéfinie de votre choix.

Compilation du graphique

La dernière étape consiste à définir les arêtes du graphe et à ajouter toutes les conditions nécessaires avant de le compiler. Chaque graphe doit partir d'un nœud de départ désigné, qui sert de point d'entrée au flux de travail. Les arêtes du graphique représentent le flux de données entre les nœuds et peuvent être de deux types :

• Arêtes droites : Ils définissent un flux direct et inconditionnel d'un nœud à l'autre. Chaque fois que le premier nœud termine sa tâche, le flux de travail passe automatiquement au nœud suivant le long de la ligne droite.

• Arêtes conditionnelles : Elles permettent au flux de travail de se ramifier en fonction de l'état actuel ou des résultats du calcul d'un nœud. Le nœud suivant est sélectionné dynamiquement en fonction de conditions telles que les résultats de l'évaluation, les décisions de routage ou le nombre de tentatives.

Votre premier pipeline RAG agentique est donc prêt et peut être testé à l'aide de l'agent compilé.

Test du pipeline RAG agentique

Nous allons maintenant tester ce pipeline en utilisant trois types de requêtes distinctes, comme indiqué ci-dessous. Il convient de noter que les résultats peuvent varier et que les exemples présentés ci-dessous n'illustrent qu'un résultat potentiel.

Pour la première requête, le routeur sélectionne websearch comme source de données. La requête échoue à l'évaluation de l'autoréflexion et est ensuite redirigée vers l'étape de réécriture de la requête, comme le montre la sortie.

Ensuite, nous examinons un exemple où vectorstore est utilisé, avec la deuxième requête.

La requête finale est dirigée vers la recherche composite, qui utilise à la fois le magasin de vecteurs et la recherche sur le web.

Dans le flux de travail ci-dessus, le RAG agentique détermine intelligemment quelle source de données utiliser lors de la recherche d'informations pour une requête de l'utilisateur, améliorant ainsi la précision et la pertinence de la réponse. Vous pouvez créer des exemples supplémentaires pour tester l'agent et examiner les résultats pour voir s'ils produisent des résultats intéressants.

Meilleures pratiques pour l'élaboration de flux de travail agentiques de RAG

Maintenant que nous comprenons le fonctionnement du RAG agentique, examinons quelques bonnes pratiques pour la mise en place de ces flux de travail. Le respect de ces lignes directrices contribuera à maintenir l'efficacité du système et à en faciliter l'entretien.

• Préparez-vous à des solutions de repli: Planifiez à l'avance des stratégies de repli pour les scénarios dans lesquels une étape du flux de travail échoue. Il peut s'agir de renvoyer des réponses par défaut, de déclencher des états d'erreur ou d'utiliser d'autres outils. Cela permet au système de gérer les défaillances de manière gracieuse sans interrompre le flux de travail global.

• Mettre en œuvre une journalisation complète: Essayez de mettre en œuvre la journalisation à chaque étape du flux de travail, comme les tentatives, les résultats générés, les choix de routage et les réécritures de requêtes. Ces journaux permettent d'améliorer la transparence, de faciliter le débogage et d'affiner les messages-guides, le comportement de l'agent et les stratégies de recherche au fil du temps.

• Sélectionner le modèle de flux de travail approprié: Examinez votre cas d'utilisation et sélectionnez le modèle de flux de travail qui répond le mieux à vos besoins. Utilisez des flux séquentiels pour le raisonnement étape par étape, des flux parallèles pour les sources de données indépendantes et des modèles d'orchestrateur-worker pour les requêtes multi-outils ou complexes.

• Incorporer des stratégies d'évaluation: Intégrer des mécanismes d'évaluation à différents stades du processus. Il peut s'agir d'agents d'autoréflexion, de classement des documents extraits ou de contrôles de qualité automatisés. L'évaluation permet de vérifier que les documents récupérés sont pertinents, que les réponses sont exactes et que toutes les parties d'une requête complexe sont traitées.

Défis

Si les systèmes agentiques RAG offrent des avantages significatifs en termes d'adaptabilité, de précision et de raisonnement dynamique, ils s'accompagnent également de certains défis qui doivent être relevés lors de leur conception et de leur mise en œuvre. Voici quelques-uns des principaux défis à relever :

• Flux de travail complexes: Au fur et à mesure de l'ajout d'agents et de points de décision, le flux de travail global devient de plus en plus complexe. Cela peut augmenter les risques d'erreurs ou de défaillances au moment de l'exécution. Dans la mesure du possible, donnez la priorité à la rationalisation des flux de travail en éliminant les agents redondants et les points de décision inutiles.

• Évolutivité: Il peut être difficile de faire évoluer les systèmes RAG agentiques pour traiter de grands ensembles de données et des volumes d'interrogation élevés. Incorporer des stratégies efficaces d'indexation, de mise en cache et de traitement distribué pour maintenir les performances à l'échelle.

• Orchestration et surcharge de calcul: L'exécution de flux de travail avec plusieurs agents nécessite une orchestration avancée. Cela implique une programmation minutieuse, la gestion des dépendances et la coordination des agents afin d'éviter les goulets d'étranglement et les conflits, autant d'éléments qui ajoutent à la complexité globale du système.

• Complexité de l'évaluation: L'évaluation de ces flux de travail présente des défis inhérents, car chaque étape nécessite une stratégie d'évaluation distincte. Par exemple, l'étape RAG doit être évaluée en fonction de la pertinence et de l'exhaustivité des documents récupérés, tandis que les résumés générés doivent être vérifiés en termes de qualité et d'exactitude. De même, l'efficacité de la reformulation de la requête nécessite une logique d'évaluation distincte pour déterminer si la requête réécrite améliore les résultats de la recherche.

Conclusion

Dans cet article de blog, nous avons présenté le concept de RAG agentique et souligné comment il améliore le cadre traditionnel de RAG en incorporant des capacités autonomes de l'IA agentique. Nous avons exploré les caractéristiques principales du RAG agentique et les avons démontrées à l'aide d'un exemple pratique, en construisant un assistant de nouvelles utilisant Elasticsearch comme magasin de vecteurs et LangChain pour créer le cadre agentique.

En outre, nous avons discuté des meilleures pratiques et des principaux défis à prendre en compte lors de la conception et de la mise en œuvre d'un pipeline RAG agentique. Ces idées sont destinées à guider les développeurs dans la création de systèmes agentiques robustes, évolutifs et efficaces qui combinent de manière effective la recherche, le raisonnement et la prise de décision.

Prochaines étapes

Le flux de travail que nous avons mis en place est simple et laisse une large place aux améliorations et à l'expérimentation. Nous pouvons l'améliorer en expérimentant divers modèles d'intégration et en affinant les stratégies de recherche. En outre, l'intégration d'un agent de reclassement pour hiérarchiser les documents récupérés pourrait être bénéfique. Un autre domaine d'exploration concerne le développement de stratégies d'évaluation pour les cadres agentiques, en particulier l'identification d'approches communes et réutilisables applicables à différents types de cadres. Enfin, l'expérimentation de ces cadres sur des ensembles de données plus vastes et plus complexes.

En attendant, si vous avez des expériences similaires à partager, nous serions ravis de les connaître ! N'hésitez pas à nous faire part de vos commentaires ou à vous connecter avec nous via notre canal Slack communautaire ou nos forums de discussion.

Ressources

• Self-RAG : Apprendre à retrouver, générer et critiquer par l'autoréflexion

• Génération assistée par récupération agentique : Une enquête sur la recherche agentique et la génération augmentée : une enquête sur la recherche agentique et la génération augmentée

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

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

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

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

Générer du contexte avec la recherche hybride

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

Précision supérieure & efficacité

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

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

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

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

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

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

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

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

Renforcement de la sécurité

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

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

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

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

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

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

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

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

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

Outils hybrides basés sur la recherche

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

Présentation de l'Agent Builder

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

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

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

Recherche de modèles

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

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

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

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

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

Elastique comme la banque de mémoire unifiée

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

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

Conclusion

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

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

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.

Dans ce blog, nous utiliserons Mastra pour construire un agent de connaissance qui se souvient de ce que les utilisateurs disent et peut rappeler les informations pertinentes plus tard, en utilisant Elasticsearch comme mémoire et backend de récupération. Vous pouvez facilement étendre ce même concept à des cas d'utilisation réels, comme des agents d'assistance qui peuvent se souvenir de conversations et de résolutions antérieures, ce qui leur permet d'adapter les réponses à des utilisateurs spécifiques ou de trouver des solutions plus rapidement en fonction du contexte antérieur.

Suivez ici les étapes de sa construction. Si vous vous perdez ou si vous voulez simplement exécuter un exemple fini, consultez le repo ici.

Qu'est-ce que Mastra ?

Mastra est un framework TypeScript open-source pour la construction d'agents d'intelligence artificielle avec des parties interchangeables pour le raisonnement, la mémoire et les outils. Sa fonction de rappel sémantique permet aux agents de se souvenir des interactions passées et de les retrouver en stockant les messages sous forme d'enchâssements dans une base de données vectorielle. Cela permet aux agents de conserver le contexte et la continuité de la conversation à long terme. Elasticsearch est un excellent magasin de vecteurs pour activer cette fonctionnalité, car il prend en charge la recherche vectorielle dense efficace. Lorsque le rappel sémantique est déclenché, l'agent introduit les messages antérieurs pertinents dans la fenêtre contextuelle du modèle, ce qui permet à ce dernier d'utiliser le contexte récupéré comme base de son raisonnement et de ses réponses.

Ce qu'il faut pour commencer

• Node v18+

• Elasticsearch (version 8.15 ou plus récente)

• Clé API Elasticsearch

• Clé API OpenAI

Note : Vous en aurez besoin parce que la démo utilise le fournisseur OpenAI, mais Mastra prend en charge d'autres SDK d'IA et fournisseurs de modèles communautaires, vous pouvez donc facilement l'échanger en fonction de votre configuration.

Construire un projet Mastra

Nous utiliserons le CLI intégré de Mastra pour fournir l'échafaudage de notre projet. Exécutez la commande :

Vous obtiendrez une série d'invites, commençant par :

1. Donnez un nom à votre projet.

2. Nous pouvons conserver cette valeur par défaut ; n'hésitez pas à la laisser vide.

3. Pour ce projet, nous utiliserons un modèle fourni par OpenAI.

4. Sélectionnez l'option "Skip for now" car nous allons stocker toutes nos variables d'environnement dans un fichier `.env` que nous configurerons plus tard.

5. Nous pouvons également ignorer cette option.

Une fois l'initialisation terminée, nous pouvons passer à l'étape suivante.

Installation des dépendances

Ensuite, nous devons installer quelques dépendances :

• ai - Ensemble de SDK d'IA de base qui fournit des outils pour gérer les modèles d'IA, les invites et les flux de travail en JavaScript/TypeScript. Mastra est construit sur le SDK AI de Vercel, nous avons donc besoin de cette dépendance pour permettre les interactions du modèle avec votre agent.

• @ai-sdk/openai - Plugin qui connecte le SDK AI aux modèles OpenAI (comme GPT-4, GPT-4o, etc.), permettant des appels API en utilisant votre clé API OpenAI.

• @elastic/elasticsearch - Client Elasticsearch officiel pour Node.js, utilisé pour se connecter à votre Elastic Cloud ou à votre cluster local pour l'indexation, la recherche et les opérations vectorielles.

• dotenv - Charge les variables d'environnement à partir d'un fichier .env dans le fichier process.env, vous permettant d'injecter en toute sécurité des informations d'identification telles que des clés d'API et des points d'extrémité Elasticsearch.

Configuration des variables d'environnement

Créez un fichier .env dans le répertoire racine de votre projet si vous n'en avez pas déjà un. Vous pouvez également copier et renommer l'exemple .env que j'ai fourni dans le répertoire. Dans ce fichier, nous pouvons ajouter les variables suivantes :

Voilà qui conclut la configuration de base. À partir de là, vous pouvez déjà commencer à construire et à orchestrer des agents. Nous allons aller plus loin et ajouter Elasticsearch en tant que couche de stockage et de recherche vectorielle.

Ajouter Elasticsearch comme magasin de vecteurs

Créez un nouveau dossier appelé stores et ajoutez-y ce fichier. Avant que Mastra et Elastic ne proposent une intégration officielle de Elasticsearch vector store, Abhi Aiyer(Mastra CTO) a partagé ce prototype de classe appelé ElasticVector. Simplement, il relie l'abstraction mémoire de Mastra aux capacités vectorielles denses d'Elasticsearch, de sorte que les développeurs peuvent utiliser Elasticsearch comme base de données vectorielle pour leurs agents.

Examinons plus en détail les éléments importants de l'intégration :

Ingestion du client Elasticsearch

Cette section définit la classe ElasticVector et met en place la connexion du client Elasticsearch avec un support pour les déploiements standards et sans serveur.

• ElasticVectorConfig extends ClientOptions: Ceci crée une nouvelle interface de configuration qui hérite de toutes les options du client Elasticsearch (comme node, auth, requestTimeout) et ajoute nos propriétés personnalisées. Cela signifie que les utilisateurs peuvent passer n'importe quelle configuration Elasticsearch valide avec nos options spécifiques au serveur.

• extends MastraVector: Cela permet à ElasticVector d'hériter de la classe de base MastraVector de Mastra, qui est une interface commune à laquelle se conforment toutes les intégrations de magasins vectoriels. Cela garantit qu'Elasticsearch se comporte comme n'importe quel autre backend vectoriel Mastra du point de vue de l'agent.

• private client: Client: Il s'agit d'une propriété privée qui contient une instance du client JavaScript Elasticsearch. Cela permet à la classe de s'adresser directement à votre cluster.

• isServerless et deploymentChecked: Ces propriétés fonctionnent ensemble pour détecter et mettre en cache si nous sommes connectés à un déploiement Elasticsearch standard ou sans serveur. Cette détection se fait automatiquement lors de la première utilisation ou peut être configurée explicitement.

• constructor(config: ClientOptions): Ce constructeur prend un objet de configuration (contenant vos identifiants Elasticsearch et des paramètres serverless optionnels) et l'utilise pour initialiser le client dans la ligne this.client = new Client(config).

• super(): Il appelle le constructeur de base de Mastra, ce qui lui permet d'hériter de la journalisation, des aides à la validation et d'autres crochets internes.

À ce stade, Mastra sait qu'il existe un nouveau magasin de vecteurs appelé ElasticVector

Détection du type de déploiement

Avant de créer des index, l'adaptateur détecte automatiquement si vous utilisez Elasticsearch standard ou Elasticsearch Serverless. C'est important car les déploiements sans serveur ne permettent pas la configuration manuelle des shards.

Ce qui se passe :

• Vérifie d'abord si vous avez explicitement défini isServerless dans la configuration (ignore l'autodétection).

• Appelle l'API info() d'Elasticsearch pour obtenir des informations sur les clusters.

• Vérifie le build_flavor field (les déploiements sans serveur renvoient serverless).

• Renvoie à la vérification du slogan si la saveur de la construction n'est pas disponible

• Met en cache le résultat afin d'éviter les appels répétés à l'API

• Déploiement standard par défaut en cas d'échec de la détection

Exemple d'utilisation :

Création du magasin "memory" dans Elasticsearch

La fonction ci-dessous met en place un index Elasticsearch pour le stockage des embeddings. Il vérifie si l'index existe déjà. Si ce n'est pas le cas, il en crée un avec le mappage ci-dessous qui contient un champ dense_vector pour stocker les embeddings et les métriques de similarité personnalisées.

Quelques points à noter :

• Le paramètre dimension est la longueur de chaque vecteur d'intégration, qui dépend du modèle d'intégration utilisé. Dans notre cas, nous allons générer des embeddings en utilisant le modèle text-embedding-3-small d'OpenAI, qui produit des vecteurs de taille 1536. Nous l'utiliserons comme valeur par défaut.

• La variable similarity utilisée dans la correspondance ci-dessous est définie à partir de la fonction d'aide const similarity = this.mapMetricToSimilarity(metric), qui prend la valeur du paramètre metric et la convertit en un mot-clé compatible avec Elasticsearch pour la métrique de distance choisie.

  • Par exemple : Mastra utilise des termes généraux pour la similarité vectorielle comme cosine, euclidean, et dotproduct. Si nous devions passer la métrique euclidean directement dans le mappage Elasticsearch, une erreur se produirait car Elasticsearch s'attend à ce que le mot-clé l2_norm représente la distance euclidienne.

• Compatibilité sans serveur : Le code omet automatiquement les paramètres de shard et de réplique pour les déploiements sans serveur, car ils sont gérés automatiquement par Elasticsearch Serverless.

Enregistrement d'un nouveau souvenir ou d'une nouvelle note après une interaction

Cette fonction prend les nouveaux embeddings générés après chaque interaction, ainsi que les métadonnées, puis les insère ou les met à jour dans l'index à l'aide de l'API bulk d'Elastic. L'API bulk regroupe plusieurs opérations d'écriture en une seule demande ; cette amélioration de nos performances d'indexation garantit que les mises à jour restent efficaces alors que la mémoire de notre agent ne cesse de croître.

Interrogation des vecteurs similaires pour le rappel sémantique

Cette fonction est au cœur de la fonction de rappel sémantique. L'agent utilise la recherche vectorielle pour trouver des enregistrements similaires dans notre index.

Sous le capot :

• Exécute une requête kNN (k-nearest neighbors) à l'aide de l'API knn dans Elasticsearch.

• Récupère les K premiers vecteurs similaires au vecteur d'entrée de la requête.

• Possibilité d'appliquer des filtres de métadonnées pour limiter les résultats (par exemple, recherche uniquement dans une catégorie ou une période spécifique).

• Renvoie des résultats structurés comprenant l'identifiant du document, le score de similarité et les métadonnées stockées.

Création de l'agent de connaissance

Maintenant que nous avons vu la connexion entre Mastra et Elasticsearch à travers l'intégration ElasticVector, créons l'agent de connaissance lui-même.

Dans le dossier agents, créez un fichier appelé knowledge-agent.ts. Nous pouvons commencer par connecter nos variables d'environnement et initialiser le client Elasticsearch.

Ici, nous :

• Utilisez dotenv pour charger nos variables à partir de notre fichier .env.

• Vérifiez que les informations d'identification Elasticsearch sont injectées correctement et que nous pouvons établir une connexion réussie avec le client.

• Passez le point de terminaison Elasticsearch et la clé API dans le constructeur ElasticVector pour créer une instance de notre magasin vectoriel que nous avons défini plus tôt.

• Spécifiez éventuellement isServerless: true si vous utilisez Elasticsearch Serverless. Cela permet d'éviter l'étape d'autodétection et d'améliorer le temps de démarrage. S'il est omis, l'adaptateur détectera automatiquement votre type de déploiement lors de la première utilisation.

Ensuite, nous pouvons définir l'agent à l'aide de la classe Agent de Mastra.

Les champs que nous pouvons définir sont les suivants :

• name et instructions: lui donner une identité et une fonction première.

• model: Nous utilisons gpt-4o d'OpenAI à travers le paquet @ai-sdk/openai.

• memory:

  • vector: Pointe vers notre magasin Elasticsearch, de sorte que les embeddings sont stockés et récupérés à partir de ce magasin.

  • embedder: Quel modèle utiliser pour générer des embeddings ?

  • semanticRecall décident de la manière dont le rappel fonctionne :

    • topK: Nombre de messages sémantiquement similaires à récupérer.

    • messageRange: Quelle partie de la conversation doit être incluse dans chaque match.

    • scope: Définit la limite de la mémoire.

Presque terminé. Il ne nous reste plus qu'à ajouter cet agent nouvellement créé à notre configuration Mastra. Dans le fichier appelé index.ts, importez l'agent de connaissance et insérez-le dans le champ agents.

Les autres champs sont les suivants :

• storage: Il s'agit du magasin de données interne de Mastra pour l'historique des exécutions, les mesures d'observabilité, les scores et les caches. Pour plus d'informations sur le stockage Mastra, cliquez ici.

• logger: Mastra utilise Pino, qui est un enregistreur JSON structuré et léger. Il capture des événements tels que le démarrage et l'arrêt de l'agent, les appels d'outils et les résultats, les erreurs et les temps de réponse du LLM.

• observability: Contrôle le suivi de l'IA et la visibilité de l'exécution pour les agents. Il suit :

  • Début/fin de chaque étape du raisonnement.

  • Quel modèle ou outil a été utilisé.

  • Entrées et sorties.

  • Notes et évaluations

Test de l'agent avec Mastra Studio

Félicitations ! Si vous êtes arrivé jusqu'ici, vous êtes prêt à faire fonctionner cet agent et à tester ses capacités de rappel sémantique. Heureusement, Mastra fournit une interface de chat intégrée, ce qui nous évite d'avoir à créer notre propre interface.

Pour démarrer le serveur de développement Mastra, ouvrez un terminal et exécutez la commande suivante :

Après le regroupement initial et le démarrage du serveur, celui-ci devrait vous fournir une adresse pour le terrain de jeu.

Collez cette adresse dans votre navigateur et vous serez accueilli par le Mastra Studio.

Sélectionnez l'option knowledgeAgent et discutez.

Pour vérifier rapidement si tout est bien branché, donnez-lui des informations telles que : "L'équipe a annoncé que les ventes d'octobre ont augmenté de 12%, principalement grâce aux renouvellements de contrats d'entreprise. La prochaine étape consistera à élargir le champ d'action aux clients du marché intermédiaire". Ensuite, démarrez un nouveau chat et posez une question du type : "Sur quel segment de clientèle avons-nous dit que nous devions nous concentrer ensuite ?". L'agent de connaissance doit pouvoir se souvenir des informations que vous lui avez communiquées lors de la première conversation. Vous devriez obtenir une réponse du type

Une telle réponse signifie que l'agent a stocké avec succès notre message précédent sous forme d'éléments intégrés dans Elasticsearch et qu'il l'a récupéré ultérieurement à l'aide d'une recherche vectorielle.

Inspection de la mémoire à long terme de l'agent

Rendez-vous sur l'onglet memory dans la configuration de votre agent dans le Studio Mastra. Cela vous permet de voir ce que votre agent a appris au fil du temps. Chaque message, réponse et interaction qui est intégré et stocké dans Elasticsearch fait partie de cette mémoire à long terme. Vous pouvez effectuer une recherche sémantique dans les interactions passées pour retrouver rapidement les informations ou le contexte que l'agent a appris précédemment. Il s'agit essentiellement du même mécanisme que celui utilisé par l'agent lors du rappel sémantique, mais ici, vous pouvez l'inspecter directement. Dans l'exemple ci-dessous, nous recherchons le terme "ventes" et nous obtenons en retour toutes les interactions qui contiennent un élément relatif aux ventes.

Conclusion

En connectant Mastra et Elasticsearch, nous pouvons donner à nos agents de la mémoire, qui est une couche clé dans l'ingénierie contextuelle. Grâce au rappel sémantique, les agents peuvent construire un contexte au fil du temps, en fondant leurs réponses sur ce qu'ils ont appris. Cela signifie des interactions plus précises, plus fiables et plus naturelles.

Cette intégration précoce n'est que le point de départ. Le même modèle peut permettre aux agents d'assistance de se souvenir des tickets précédents, aux robots internes de retrouver la documentation pertinente ou aux assistants d'IA de se souvenir des détails d'un client au cours d'une conversation. Nous travaillons également à l'intégration officielle de Mastra, afin de rendre cette association encore plus transparente dans un avenir proche.

Nous sommes impatients de voir ce que vous allez construire. Essayez-le, explorez Mastra et ses fonctions de mémoire, et n'hésitez pas à partager vos découvertes avec la communauté.

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.

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

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

Que se passe-t-il ici ?

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

1. Inspecter l'invite.

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

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

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

5. Synthétiser les résultats.

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

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

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

Que faisions-nous ?

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

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

Établir une base de référence

Cela commence par des données

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

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

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

et des cas de test tels que :

Élaboration d'un harnais de test

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

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

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

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

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

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

L'enquête dit...

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

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

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

Expérimentation

Hypothèse 1 : Les cartographies aideront à

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

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

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

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

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

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

Nous avons essayé.

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

Hypothèse 3 : Descriptions dans le mapping _meta

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Résultats

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

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

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

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

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

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

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

Étape 0 : Notre ensemble de données

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

financial_accounts: Portefeuilles de clients avec profils de risque

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

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

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

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

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

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

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

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

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

En bref : jonctions et garde-corps

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

1. La jointure LOOKUP

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

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

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

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

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

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

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

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

Le chemin de l'interface utilisateur

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

1. Naviguer vers Agents

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

2. Remplissez le formulaire avec les informations suivantes :

• ID de l'outil : find_client_exposure_to_negative_news

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

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

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

• Étiquettes: retrieval et risk-analysis

Les étiquettes sont utilisées pour regrouper plusieurs outils

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

i. Voici la recherche que l'agent utilisera

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

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

4. Testez-le !

• Cliquez sur Save & test.

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

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

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

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

Le chemin de l'API

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

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

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

L'art de la proposition

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

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

Voyons pourquoi cette incitation est si efficace :

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

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

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

Le chemin de l'interface utilisateur

1. Naviguez vers Agents.

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

2. Complétez les informations de base :

• ID de l'agent : financial_assistant.

• Instructions : Copiez le message ci-dessus.

• Étiquettes: Finance.

• Nom d'affichage : Financial Assistant.

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

3. De retour en haut, cliquez sur Outils.

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

4. Cliquez sur Enregistrer.

Le chemin de l'API

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

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

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

Le chemin de l'interface utilisateur

1. Naviguez jusqu'à Agents dans Kibana.

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

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

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

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

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

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

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

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

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

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

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

Le chemin de l'API

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

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

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

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

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

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

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

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

Conclusion : À vous de construire

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

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

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

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

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

Restez à l'écoute et bonne construction !

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

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

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

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

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

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

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

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

Création d'agents dans la plate-forme

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

Agents

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

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

1. Interpréter votre contribution et votre objectif

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

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

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

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

L'agent par défaut

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

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

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

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

Agents des douanes

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

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

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

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

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

Outils

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

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

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

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

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

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

Normes ouvertes et interopérabilité

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

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

Protocole de contexte de modèle (MCP)

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

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

Agent à agent (A2A)

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

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

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

Recherche et évaluation

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

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

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

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

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

Security

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

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

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

Ce qui vient ensuite

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

1. Engagement en faveur des normes Open Source &

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

2. Valeur du contexte

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

3. Focus sur les flux de données agentiques

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

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

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

5. Intégré dans la plate-forme

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

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

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

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 !

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.

1. Clonez le dépôt : Téléchargez le code de l'outil depuis GitHub en utilisant git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent aet naviguez dans le répertoire avec cd serverless-ai-agent.

2. Configurer l'environnement : Créez un environnement virtuel (facultatif) avec python -m venv venv et activez-le (source venv/bin/activate ou venv\Scripts\activate sous Windows). Ensuite, installez les paquets Python nécessaires à l'aide de pip install -r requirements.txt.

3. Configurer les informations d'identification : Créez un fichier .env à la racine du projet et remplissez-le avec l'URL de votre API Elasticsearch (ES_URL), la clé API (API_KEY), la région (REGION) et la clé API OpenAI (OPENAI_API_KEY).

4. Exécutez l'outil : Exécutez l'outil en lançant python main.py dans votre terminal. Cela démarre l'agent d'intelligence artificielle et présente une invite pour vos commandes.

5. Gérer les projets en langage naturel : Interagissez avec l'outil en utilisant des commandes en langage naturel comme "Créer un projet sans serveur nommé mon_projet", "Obtenir le statut du projet sans serveur nommé mon_projet", ou "Supprimer le projet sans serveur nommé mon_projet". L'IA interprétera vos commandes et exécutera les fonctions correspondantes.

Arrière-plan

Ce petit outil en ligne de commande vous permet de gérer vos projets Serverless Elasticsearch en anglais simple. Il s'adresse à une IA (dans ce cas, OpenAI) pour comprendre ce que vous voulez dire et appeler les bonnes fonctions à l'aide de LlamaIndex !

Que peut faire l'agent Elasticsearch Serverless AI ?

• Créer un projet: Créez un nouveau projet Serverless Elasticsearch.

• Supprimer un projet: Supprimer un projet existant (oui, il nettoie après vous).

• Obtenir l'état d'avancement du projet: Vérifiez l'état d'avancement de votre projet.

• Obtenir les détails du projet: Obtenez tous les détails croustillants de votre projet.

Consultez le code sur GitHub.

Fonctionnement de l'agent Elasticsearch Serverless AI

Lorsque vous tapez quelque chose comme :

"Créer un projet sans serveur nommé mon_projet."

...voici ce qui se passe en coulisses :

• Entrée de l'utilisateur & contexte : Votre commande en langage naturel est envoyée à l'agent d'intelligence artificielle.

• Description des fonctions : L'agent IA connaît déjà quelques fonctions, telles que create_ess_project, delete_ess_project, get_ess_project_status et get_ess_project_details, parce que nous lui avons fourni des descriptions détaillées. Ces descriptions indiquent à l'IA le rôle de chaque fonction et les paramètres dont elle a besoin.

• Traitement par le LLM : Votre demande et les informations relatives à la fonction sont envoyées au LLM. Cela signifie que l'IA voit :

  • La requête de l'utilisateur: Votre instruction en langage clair.

  • Fonctions disponibles & descriptions: Détails sur les fonctions de chaque outil afin de pouvoir choisir le bon.

  • Contexte/Info historique de la conversation: Comme il s'agit d'une conversation, il se souvient de ce qui a été dit auparavant.

• Appel de fonction & réponse : L'IA détermine quelle fonction appeler, transmet les bons paramètres (comme le nom de votre projet), puis la fonction est exécutée. La réponse vous est renvoyée dans un format convivial.

En bref, nous envoyons à la fois votre requête en langage naturel et une liste de descriptions détaillées d'outils au mécanisme d'apprentissage tout au long de la vie afin qu'il puisse "comprendre" et choisir l'action appropriée à votre demande.

Mise en place de l'agent d'intelligence artificielle

Prérequis :

Avant d'exécuter l'agent AI, assurez-vous que les éléments suivants sont en place :

1. Python (v3.7 ou plus récent) installé.

2. Compte Elasticsearch serverless configuré sur Elastic Cloud.

3. Compte OpenAI pour interagir avec le modèle linguistique.

Les étapes :

1. Clonez le référentiel :

2. Créer un environnement virtuel (facultatif mais recommandé) : Si vous êtes confronté à des problèmes liés à l'environnement, vous pouvez créer un environnement virtuel pour l'isoler :

3. Installez les dépendances : Assurez-vous que toutes les dépendances requises sont installées en exécutant le programme :

4. Configurez votre environnement : Créez un fichier .env à la racine du projet avec les variables suivantes. Voici un exemple de fichier .env.example pour vous aider :

Assurez-vous que vous disposez des valeurs correctes pour ES_URL, API_KEY, et OPENAI_API_KEY. Vous trouverez vos clés API dans les tableaux de bord respectifs des services.

5. Fichier de projets : l'outil utilise un fichier projects.json pour stocker vos correspondances de projets (noms de projets et détails). Ce fichier sera créé automatiquement s'il n'existe pas déjà.

Exécution de l'agent d'intelligence artificielle

Vous verrez apparaître une invite comme celle-ci :

Tapez votre commande et l'agent d'intelligence artificielle fera son travail ! Lorsque vous avez terminé, tapez exit ou quit pour partir.

Quelques détails supplémentaires

• Intégration du LLM: Le LLM reçoit à la fois votre requête et des descriptions détaillées de chaque fonction disponible. Cela l'aide à comprendre le contexte et à décider, par exemple, s'il faut appeler create_ess_project ou delete_ess_project.

• Description des outils: Chaque outil de fonction (créé à l'aide de FunctionTool.from_defaults) a une description sympathique. Cette description est incluse dans l'invite envoyée au LLM afin qu'il "sache" quelles actions sont disponibles et ce que chaque action attend.

• Persistance: Vos projets et leurs détails sont enregistrés dans projects.json, afin de ne pas avoir à ressaisir les informations à chaque fois.

• Journalisation verbeuse: L'agent est configuré en mode verbeux, ce qui est idéal pour le débogage et pour voir comment vos instructions sont traduites en appels de fonction.

Exemple d'utilisation d'un agent IA Elasticsearch