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.

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

1. Utilisation de l'API _mapping pour récupérer des informations sur les champs

2. Utilisation de l'API _search pour afficher les valeurs des champs

3. Affichage des sous-champs

4. Synthetic _source

5. Champs d'exécution

1. Utilisation de l'API _mapping pour récupérer des informations sur les champs

L'API _mapping vous permet de récupérer la définition du mappage pour un ou plusieurs index. Il s'agit d'informations sur les champs, leurs types de données et d'autres propriétés. Pour récupérer le mappage d'un index spécifique, utilisez la requête suivante :

Par exemple, si vous avez un index nommé my_index, vous pouvez récupérer son mapping avec la requête suivante :

La réponse comprendra la définition du mappage pour l'index, qui contient des informations sur les champs et leurs propriétés.

Il est également possible de récupérer la cartographie d'un champ spécifique. Cela peut s'avérer utile si votre cartographie est assez vaste et que vous souhaitez vous concentrer sur un domaine spécifique. Pour récupérer la correspondance d'un champ spécifique, utilisez la requête suivante :

Vous pouvez également récupérer les correspondances de plusieurs champs en séparant leurs noms par des virgules, comme dans la requête suivante :

2. Utilisation de l'API _search pour afficher les valeurs des champs

Pour afficher les valeurs des champs d'un index Elasticsearch, vous pouvez utiliser l'API _search. L'API _search vous offre plusieurs moyens de contrôler les champs renvoyés ; les deux principaux sont les suivants :

1. _source: Le champ _source contient le corps du document JSON original tel qu'il a été indexé, y compris les modifications apportées par les pipelines d'ingestion ou les étapes de prétraitement. Pour afficher des champs spécifiques du document source, il faut mettre en œuvre le filtrage de la source, comme nous le verrons ci-dessous.

2. fields: Le paramètre fields vous permet d'extraire des champs spécifiques de vos documents lors d'une recherche, sur la base du mappage de l'index. Contrairement à _source, fields peut également renvoyer des valeurs provenant de champs stockés, de valeurs documentaires ou de champs d'exécution sans faire référence à _source, bien que pour les champs standard sans valeurs documentaires ou paramètres stockés, il se réfère à _source. Cela peut apporter de nombreux avantages, notamment en termes de performances, comme nous le verrons ci-dessous.

Utilisation du champ _source

Par défaut, l'API _search renvoie le champ _source, qui contient le document JSON original qui a été indexé. Pour afficher des champs spécifiques, vous pouvez ajouter des filtres dans le paramètre _source de la demande de recherche ; c'est ce qu'on appelle le filtrage à la source.

Voici un exemple de demande de recherche qui renvoie les valeurs des champs title et author pour les documents de l'index my_index:

Dans cet exemple, le paramètre _source spécifie les champs à renvoyer.

Si vous avez besoin d'encore plus de contrôle, vous pouvez utiliser les propriétés includes et excludes de l'objet _source. Par exemple, la requête ci-dessous renvoie le champ de premier niveau title et tous les sous-champs de author à l'exception de author.description.

Dans cet exemple, nous utilisons le modèle author.* pour récupérer tous les sous-champs directs de l'objet author . Nous excluons ensuite explicitement author.description afin que seuls les autres champs relatifs à l'auteur soient renvoyés. Notez que cela n'améliore pas les performances, puisqu'il faut toujours charger et analyser la source JSON, mais cela permet de réduire la taille de la réponse envoyée sur le réseau.

Utilisation du paramètre champs

Vous pouvez utiliser le paramètre fields pour filtrer les champs renvoyés dans la réponse de recherche. L'utilisation de fields par rapport à _source présente plusieurs avantages, notamment

• Amélioration des performances : fields peut renvoyer des valeurs directement à partir de champs stockés ou de valeurs de documents sans avoir à charger l'intégralité du site _source, ce qui réduit la taille de la charge utile de la réponse.

• Sortie formatée : Pour les champs standard, fields peut se référer à _source pour récupérer les valeurs, mais il s'appuie sur le mappage de l'index pour formater correctement la sortie, comme les dates formatées, afin de les rendre cohérentes avec ce qui est utilisé pour les agrégations et les tris.

• Accès aux champs d'exécution : fields peut renvoyer des champs d'exécution qui n'existent pas sur le site original _source.

• D'autres avantages peuvent être trouvés ici.

Par exemple, pour obtenir uniquement les champs title et author dans l'index my_index, vous pouvez utiliser la requête de recherche suivante :

Dans la requête ci-dessus, nous attribuons la valeur false au champ _source afin de ne pas renvoyer le document source. Cela peut réduire considérablement la taille de la charge utile de la réponse, mais n'oubliez pas que cela ne fonctionne que si les champs title et author sont de type keyword , pour lesquels doc_values est activé par défaut. Si le champ n'a pas été activé par doc_values et que _source a été défini sur false, Elasticsearch n'aura aucun moyen de les récupérer et ils seront ignorés dans la réponse.

Il est important de noter que la réponse fields renvoie toujours un tableau de valeurs pour chaque champ, même s'il n'y a qu'une seule valeur. Cela est dû au fait qu'Elasticsearch n'a pas de type de tableau dédié, et que tout champ peut avoir plusieurs valeurs. Pour plus d'informations sur les tableaux dans Elasticsearch, cliquez ici.

Autres moyens d'extraire des champs

Bien que l'extraction de champs à l'aide de _source ou fields soit la méthode recommandée, il existe d'autres méthodes pour des cas d'utilisation spécifiques, comme par exemple :

Champs de valeur du document : Si vous souhaitez éviter _source, vous pouvez effectuer une recherche en utilisant le paramètre docvalue_fields . Doc values stocke les mêmes valeurs de champ que _source mais dans une structure de données sur disque, optimisée pour les tris et les agrégations.

Comme il s'agit d'une valeur distincte des valeurs stockées sur _source, vous pouvez demander des champs spécifiques sans avoir à charger l'ensemble du site _source. Cette option est utile si vous interrogez des documents volumineux, mais que vous n'avez besoin que de quelques petits champs prenant en charge des valeurs de documents. Un autre cas d'utilisation de docvalue_fields est celui où vous souhaitez utiliser un formatage personnalisé pour les champs date et numeric, comme nous le verrons dans l'exemple ci-dessous.

Notez que cela ne fonctionne que pour les champs pour lesquels vous avez activé doc_values ou pour les types de champs pour lesquels cette option est activée par défaut, tels que keyword, date, les types numériques et boolean, et non pour text ou annotated_text.

Dans cet exemple, nous utilisons le paramètre docvalue_fields pour récupérer les champs title, author et published sans charger le document _source complet :

Lorsque cette requête est exécutée, Elasticsearch récupère les valeurs directement à partir de son magasin en colonnes sur disque au lieu de référencer le site _source pour chaque document. Le champ published est retourné avec le format epoch_millis au lieu du format par défaut, grâce au paramètre format fourni dans la requête.

Champs stockés : Si vous avez explicitement marqué des champs spécifiques comme étant stockés dans le mappage, vous pouvez utiliser le paramètre stored_fields pour filtrer ces champs. C'est utile si vous voulez des réponses légères avec seulement ces champs spécifiques ou pour les champs que vous avez délibérément stockés pour les retrouver plus tard. Il est stocké séparément de _source, de sorte que cette méthode est également utile pour éviter de devoir charger _source.

Il est important de noter que cette option est désactivée par défaut et qu'elle n'est généralement pas recommandée. Utilisez plutôt le filtrage des sources pour renvoyer certains sous-ensembles du document source original.

Dans l'exemple de requête ci-dessous, nous utilisons le paramètre stored_fields pour récupérer le champ summary, dont la configuration de mappage d'index est "store”: true.

Lorsque cette requête est exécutée, Elasticsearch vérifie si ce champ a été marqué par ”store”: true, s'il ne le trouve pas, il l'ignore complètement.

3. Affichage des sous-champs

Si votre index contient des sous-champs, vous pouvez utiliser la notation point pour spécifier le chemin d'accès au champ dans le paramètre fields. Notez que les sous-champs sont différents du type de champ imbriqué. Par exemple, si vous avez un sous-champ nommé address.city, vous pouvez l'inclure dans la réponse de recherche comme suit :

Dans cet exemple, la réponse de la recherche comprendra les valeurs des champs title, author et address.city.

4. Synthétique _source

Si vous souhaitez conserver la fonctionnalité de _source tout en économisant de l'espace disque, vous avez la possibilité d'utiliser le site synthétique _source dans votre mappage d'index. Synthetic _source est une fonctionnalité qui permet à Elasticsearch de reconstruire _source à partir de données existantes telles que des champs stockés et des valeurs de documents, même lorsque _source est désactivé. Cela vous permet d'économiser beaucoup d'espace de stockage au prix d'une vitesse légèrement inférieure au moment de l'interrogation, car la reconstruction se fait à la volée. Activez cette fonction en utilisant les valeurs ci-dessous dans vos paramètres d'index :

Parmi les avantages de l'utilisation de la version synthétique de _source , citons : l'affichage complet du document lors de l'utilisation de l'API _search, le filtrage des sources et la compatibilité avec d'autres fonctionnalités et outils tels que Kibana qui s'attendent à ce que _source soit disponible, tout en évitant d'avoir à stocker le document _source dans son intégralité.

5. Champs d'exécution

Les champs d'exécution vous permettent de définir des champs scriptés au moment de la requête ou dans votre mappage d'index sous un bloc d'exécution. Ces champs ne sont jamais indexés, de sorte que l'ajout d'un champ d'exécution n'augmente pas la taille de l'index mais n'apparaîtra jamais dans _source. Les champs d'exécution définis dans le mappage sont persistants et disponibles pour toutes les requêtes, tandis que les champs d'exécution définis au moment de la requête sont temporaires et ne sont disponibles que dans cette requête de recherche.

Le principal avantage de l'utilisation des champs d'exécution est la possibilité d'ajouter des champs aux documents après les avoir ingérés, ce qui simplifie vos décisions en matière de mappage. Les champs d'exécution sont également très utiles pour enrichir vos documents avec des valeurs qui n'existent pas dans le document original mais qui sont générées à l'aide d'un script, comme le formatage d'une chaîne de caractères ou le calcul d'un score.

Il convient également de noter que les champs d'exécution peuvent nuire aux performances, car un script devra être exécuté pour chaque document de l'ensemble des résultats. Pour récupérer un champ d'exécution, vous pouvez également utiliser le paramètre fields de l'API _search.

Conclusion

L'affichage des champs d'un index Elasticsearch peut aller de la simple récupération des valeurs à l'aide du mappage d'index ou de _source, à des méthodes plus avancées utilisant fields, docvalue_fields, ou des champs d'exécution pour un meilleur contrôle et une plus grande efficacité. Il est essentiel de comprendre les compromis entre les différentes méthodes pour optimiser vos expériences de recherche. Qu'il s'agisse d'optimiser les charges utiles, d'enrichir des documents ou d'utiliser le site synthétique _source pour économiser de l'espace de stockage, Elasticsearch vous offre de nombreux outils et fonctionnalités pour trouver les données dont vous avez besoin, de la manière dont vous en avez besoin. Ces techniques peuvent vous aider à comprendre la structure de vos données, à identifier des champs spécifiques et à résoudre des problèmes.

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 !

Qu'est-ce que le protocole de contexte de modèle (MCP) ?

Pour ceux qui ne connaissent pas, Model Context Protocol est une norme ouverte qui offre un moyen structuré et bidirectionnel de connecter les modèles d'IA à diverses sources de données et à divers outils, ce qui leur permet de générer des réponses plus pertinentes et mieux informées. Il est communément appelé "port USB-C pour les applications d'intelligence artificielle".

Voici un schéma architectural qui met en évidence son caractère bidirectionnel :

Il s'agit d'un changement important pour les praticiens de l'IA, car l'un des principaux défis de la mise à l'échelle des applications d'IA est de devoir créer des intégrations personnalisées pour chaque nouvelle source de données. MCP offre une architecture durable et réutilisable pour la gestion et la fourniture de contexte aux modèles. Il est indépendant des modèles et des serveurs et est entièrement open source.

MCP est la dernière itération d'une lignée de spécifications d'API visant à normaliser l'intégration entre les applications. Dans le passé, nous avions OpenAPI pour les services RESTful, GraphQL pour l'interrogation des données et gRPC pour la communication des microservices. MCP ne partage pas seulement la rigueur structurée de ces anciennes spécifications, mais l'intègre également dans un cadre d'IA générative, ce qui facilite l'intégration des agents dans différents systèmes sans avoir recours à des connecteurs personnalisés. À bien des égards, MCP vise à faire pour les agents d'intelligence artificielle ce que HTTP a fait pour le web. Tout comme HTTP a normalisé la communication entre les navigateurs et les sites web, MCP cherche à normaliser la façon dont les agents d'intelligence artificielle interagissent avec le monde des données qui les entoure.

MCP par rapport à d'autres protocoles d'agents

Le paysage des protocoles d'agents se développe rapidement, avec plus d'une douzaine de normes émergentes en concurrence pour définir la manière dont les agents interagissent. Laurie Voss de LlamaIndex décrit comment la plupart peuvent être catégorisés en 2 types : les protocoles inter-agents qui se concentrent sur les agents qui parlent entre eux et les protocoles orientés vers le contexte comme MCP qui se concentrent sur la fourniture d'un contexte structuré aux LLMs.

D'autres protocoles populaires comme A2A (Agent to Agent) de Google, ACP (Agent Communication Protocol) de Cisco et IBM, et Agora, visent à permettre les négociations entre agents, la création de coalitions et même des systèmes d'identité décentralisés. MCP adopte une approche un peu plus pragmatique en ce sens qu'il se concentre sur la manière dont les agents accèdent aux outils et aux données et pas nécessairement sur la manière dont ils communiquent entre eux (bien que MCP puisse également permettre cela à l'avenir de différentes manières).

Actuellement, ce qui distingue MCP, c'est sa traction et son élan. Comme React dans les premiers jours des frameworks frontaux, MCP a commencé avec un problème de niche et est maintenant l'un des protocoles d'agent les plus adoptés et les plus extensibles dans la pratique.

Récapitulation du sommet : Évolution des priorités pour le MCP

Le sommet a accueilli des intervenants de Anthropic, Okta, OpenAI, AWS, GitHub et bien d'autres. Les discussions ont porté sur l'amélioration des protocoles de base et sur leur mise en œuvre dans le monde réel, et ont mis en évidence les priorités immédiates et à long terme. Ces exposés ont montré que l'on s'éloignait de l'expérimentation précoce et de l'appel à de simples outils pour passer à la construction de systèmes d'IA fiables, évolutifs et modulaires en utilisant le MCP comme base.

Plusieurs orateurs ont évoqué un avenir où le MCP est plus qu'un simple protocole, il peut devenir le fondement d'un web orienté vers l'intelligence artificielle. Tout comme JavaScript permet aux utilisateurs de cliquer et d'interagir avec les pages web, MCP pourrait permettre aux agents d'effectuer ces mêmes actions en notre nom. Par exemple, dans le domaine du commerce électronique, au lieu de naviguer manuellement sur un site web pour faire des achats, les utilisateurs pourraient simplement demander à un agent de se connecter, de trouver un produit spécifique, de l'ajouter à leur panier et de passer à la caisse.

Il ne s'agit pas non plus d'une pure spéculation ou d'un battage médiatique : PayPal a présenté sa nouvelle boîte à outils pour agents et son serveur MCP lors du sommet, qui permet exactement cette expérience de commerce agentique. Grâce à MCP qui fournit un accès sécurisé et fiable aux outils et aux sources de données, les agents ne se contenteront pas de lire le web, ils pourront agir en conséquence. Aujourd'hui, MCP est déjà une norme puissante qui a le vent en poupe et, à terme, elle pourrait devenir la norme des interactions utilisateur améliorées par l'IA sur l'ensemble du web.

Mise à jour du projet MCP : Transport, élicitation et outils structurés

Jerome Swannack, l'un des principaux contributeurs à MCP, a fait part de quelques mises à jour de la spécification du protocole au cours des six derniers mois. Les principaux objectifs de ces changements sont les suivants

1. Pour activer le MCP à distance avec l'ajout du HTTP en continu

2. Permettre des modèles d'interaction entre agents plus riches grâce à l'ajout de schémas d'élicitation et de sortie d'outils.

MCP étant un logiciel libre, les développeurs peuvent déjà mettre en œuvre des modifications telles que le protocole HTTP fluide. Les schémas d'élicitation et de sortie de l'outil ne sont pas encore publiés ; ils sont à l'état de projet et peuvent évoluer.

Streamable HTTP (publié le 26 mars 2025): Une mise à jour technique importante a été l'introduction du protocole HTTP en flux continu en tant que nouveau mécanisme de transport. Il remplace les événements envoyés par le serveur (SSE) par un modèle bidirectionnel plus évolutif qui prend en charge le codage de transfert par morceaux et la transmission progressive de messages sur une seule connexion HTTP. Cela vous permet de déployer des serveurs MCP sur une infrastructure cloud comme AWS Lambda et de prendre en charge les contraintes du réseau d'entreprise sans connexions à longue durée de vie ni nécessité de polling.

Elicitation (publié le 18 juin 2025): L'élicitation permet aux serveurs de définir un schéma sur la façon dont ils veulent que le contexte soit structuré à partir d'un client. Essentiellement, le serveur peut décrire ce dont il a besoin et le type d'entrée qu'il attend. Cela a plusieurs implications : Les constructeurs de serveurs peuvent créer des interactions agentiques plus complexes. Les concepteurs de clients peuvent mettre en œuvre des interfaces utilisateur dynamiques qui s'adaptent à ces schémas. Cependant, l'élicitation ne doit pas être utilisée pour extraire des informations sensibles ou personnellement identifiables des utilisateurs. Les développeurs doivent suivre les meilleures pratiques pour s'assurer que les messages d'élicitation restent sûrs et appropriés, en particulier au fur et à mesure que le MCP évolue. Ceci est lié à des problèmes de sécurité plus larges que nous aborderons plus loin dans ce billet.

Schémas de sortie d'outil (publié le 18 juin 2025): Ce concept permet au client et au LLM de connaître à l'avance les formes de sortie de l'outil. Les schémas de sortie des outils permettent aux développeurs de décrire les résultats attendus d'un outil. Ces schémas répondent à l'une des principales limites de l'appel direct d'outils, à savoir l'utilisation inefficace de la fenêtre contextuelle. La fenêtre contextuelle est considérée comme l'une des ressources les plus importantes lorsque vous travaillez avec des LLM. Lorsque vous appelez directement un outil, celui-ci renvoie un contenu brut qui est entièrement transféré dans le contexte du LLM. Les schémas de sortie des outils peuvent vous aider à mieux utiliser vos jetons et la fenêtre contextuelle en permettant au serveur MCP de fournir des données structurées. Voici quelques bonnes pratiques concernant les outils en général.

Ensemble, ces nouvelles mises à jour et les ajouts futurs aideront le MCP à devenir un protocole d'agent plus modulaire, typé et prêt pour la production.

Caractéristiques de puissance sous-utilisées : Échantillonnage et racines

Bien qu'ils ne soient pas nouveaux dans la spécification MCP, l'échantillonnage et les racines ont été mis en évidence lors de la présentation. Ces deux primitives sont actuellement négligées et sous-explorées, mais elles peuvent contribuer de manière significative à des interactions plus riches et plus sûres entre les agents.

Échantillonnage - Les serveurs peuvent demander des compléments au client : L'échantillonnage permet aux serveurs MCP de demander des compléments au LLM côté client. Cela ajoute à la nature bidirectionnelle du protocole, où le serveur ne se contente pas de répondre aux demandes ; il peut inciter et demander au modèle du client de générer une réponse. Cela permet au client de garder un contrôle total sur le coût, la sécurité et le modèle utilisé par le serveur MCP. Ainsi, dans le cas de l'utilisation d'un serveur MCP externe avec un modèle préconfiguré, vous n'aurez pas besoin de fournir vos propres clés API ou de configurer votre propre abonnement à ce modèle, car le serveur peut simplement demander le modèle déjà connecté au client. Cela permet d'obtenir des comportements d'agents plus complexes et plus interactifs.

Racines - Accès limité aux ressources : Lesracines ont été conçues pour permettre aux clients d'informer les serveurs des ressources et des espaces de travail pertinents sur lesquels ils doivent se concentrer. Il s'agit d'un outil puissant pour définir le champ d'action des serveurs. Il est important de noter que les racines sont "informatives et non strictement exécutoires", ce qui signifie qu'elles ne définissent pas de droits ou de permissions pour les serveurs ou les agents MCP. En d'autres termes, vous ne pouvez pas vous fier uniquement aux racines pour empêcher un serveur ou un agent d'exécuter certains outils ou d'effectuer des actions d'écriture. En ce qui concerne les racines, les autorisations doivent toujours être gérées du côté du client, avec des mécanismes d'approbation par l'utilisateur. Par ailleurs, les développeurs doivent toujours veiller à utiliser des serveurs conçus pour respecter les limites fixées par les racines et utiliser les meilleures pratiques.

Authentification des agents : OAuth 2.1 et métadonnées protégées

Cette section se concentre sur OAuth 2.1, la dernière itération d'OAuth 2.0, qui supprime les flux non sécurisés et consolide les meilleures pratiques.

La prise en charge d'OAuth était un sujet très attendu, d'autant plus que la sécurité et l'évolutivité sont considérées comme les principaux obstacles qui empêchent MCP de devenir la norme pour la connexion des agents aux outils. Aaron Parecki (éditeur d'OAuth 2.1 et expert en normes d'identité chez Okta) a expliqué comment MCP peut adopter un flux OAuth propre et évolutif qui décharge les développeurs de serveurs de la majeure partie de la complexité. La spécification d'autorisation officielle OAuth 2.1 a été récemment publiée dans la dernière révision du protocole le 18 juin 2025.

Dans cette implémentation, les responsabilités OAuth peuvent être réparties entre le client MCP et le serveur. La majeure partie du flux d'authentification est initiée et gérée par le client MCP, le serveur n'intervenant qu'à la fin pour recevoir et vérifier le jeton sécurisé. Cette scission permet de résoudre un problème critique de mise à l'échelle, à savoir comment s'authentifier à travers de nombreux outils sans exiger des développeurs qu'ils configurent chaque connexion, et garantit que les développeurs de serveurs MCP n'ont pas à devenir des experts OAuth.

Deux points saillants de l'exposé :

1. Métadonnées des ressources protégées: Les serveurs MCP peuvent publier un fichier JSON décrivant leur objectif, leurs points d'accès et leurs méthodes d'authentification. Cela permet aux clients de démarrer des flux OAuth avec seulement l'URL du serveur, ce qui simplifie le processus de connexion. En savoir plus : Corrigeons OAuth dans MCP

2. Prise en charge des IDP et du SSO: les entreprises peuvent intégrer des fournisseurs d'identité pour gérer l'accès de manière centralisée. C'est une victoire pour l'expérience de l'utilisateur et la sécurité. Les utilisateurs n'auraient pas besoin de cliquer sur dix écrans de consentement différents et les équipes de sécurité pourraient observer chaque connexion.

En transférant la logique OAuth au client et en s'appuyant sur les métadonnées des serveurs, l'écosystème MCP évite un goulot d'étranglement majeur. Le MCP s'aligne ainsi plus étroitement sur la manière dont les API modernes sont sécurisées dans les environnements de production d'aujourd'hui.

Lecture complémentaire : OAuth 2 simplifié.

Défis de sécurité dans un écosystème composable

Les nouveaux développements s'accompagnent également de nouvelles surfaces d'attaque. Arjun Sambamoorthy, de Cisco, énumère les principales menaces qui pèsent sur le paysage MCP :

Profils

Description

Remédiation & meilleures pratiques

Injection rapide & Empoisonnement des outils

Un moyen d'injecter une invite malveillante dans le contexte du système LLM ou dans la description de l'outil, amenant le LLM à effectuer des actions involontaires telles que la lecture de fichiers ou la fuite de données.

Utilisez des outils tels que MCP Scan pour vérifier les métadonnées des outils. Validez les descriptions et les paramètres avant de les inclure dans les invites. Enfin, envisagez de mettre en place des approbations d'utilisateurs pour les outils à haut risque. Pour plus de détails, voir le guide OWASP Prompt Injection dans la liste de lectures complémentaires sous le tableau.

Attaques par échantillonnage

Dans le contexte de MCP, l'échantillonnage ouvre la porte au serveur MCP pour effectuer des attaques d'injection rapide sur le LLM.

Désactiver l'échantillonnage pour les serveurs non fiables et envisager d'ajouter des approbations humaines en boucle pour les demandes d'échantillonnage.

Serveurs MCP malveillants

Dans les collections actuelles de serveurs MCP, il est difficile de contrôler chacun d'entre eux pour garantir la sécurité. Des serveurs malveillants peuvent discrètement collecter vos données et les exposer à des acteurs malveillants.

Ne vous connectez qu'à des serveurs MCP provenant de registres de confiance ou de listes internes. Exécuter des serveurs tiers dans des conteneurs avec sandboxing.

Outils d'installation MCP malveillants

Les installateurs de ligne de commande et les scripts sont pratiques pour mettre en œuvre rapidement des serveurs ou des outils MCP, mais vous risquez d'installer du code non vérifié et compromis.

Installer dans des environnements "sandbox" et valider les signatures des paquets. Ne jamais effectuer de mise à jour automatique à partir de sources non vérifiées.

Pour lutter contre ce problème, Arjun suggère d'utiliser un registre MCP de confiance pour gérer toutes les vérifications (un sujet qui était au cœur de l'actualité - pour plus de détails, voir les deux premiers éléments de la liste de lecture ci-dessous), ainsi que d'utiliser cette liste de contrôle de la sécurité.

Lecture complémentaire :

• Meilleures pratiques officielles de sécurité MCP

• Top 10 des candidatures au LLM de l'OWASP

• Recherche sur les menaces HiddenLayer

• Scan MCP

• Guide OWASP sur l'injection d'invites

Prochaines étapes : Registres, gouvernance et écosystème

Un registre centralisé des MCP est en cours d'élaboration et a été l'un des sujets les plus discutés lors du sommet. L'écosystème actuel des serveurs souffre de fragmentation, d'un manque de confiance et d'accessibilité. Il est difficile pour les développeurs de trouver des serveurs MCP, de vérifier ce qu'ils font et de les installer en toute sécurité, en particulier dans un écosystème décentralisé où les métadonnées peuvent être incomplètes ou usurpées.

Un registre centralisé répond directement à ces problèmes en agissant comme une source de vérité fiable, en améliorant la découvrabilité, en garantissant l'intégrité des métadonnées du serveur et en réduisant le risque d'installation d'outils malveillants.

Les objectifs du registre MCP sont les suivants :

• Offrir une source unique de vérité pour les métadonnées des serveurs (ce que fait un serveur, comment s'authentifier, l'installer et l'appeler)

• Se débarrasser des registres tiers incomplets et de la fragmentation, de sorte que lorsqu'un serveur veut être enregistré, il n'a pas à mettre à jour tous les autres registres sur l'internet.

• Fournir un flux d'enregistrement de serveur qui comprend un outil CLI et un fichier server.json qui contient les métadonnées mentionnées précédemment.

L'espoir le plus large est qu'un registre fiable aidera à développer l'écosystème en toute sécurité, en permettant aux développeurs de créer et de partager de nouveaux outils en toute confiance.

La gouvernance est une autre question prioritaire pour Anthropic. Ils ont clairement indiqué que le projet MCP devait rester ouvert et dirigé par la communauté, mais la mise à l'échelle de ce modèle de gouvernance est encore un travail en cours. Ils recherchent actuellement de l'aide dans ce domaine et demandent à toute personne ayant de l'expérience en matière de gouvernance dans les protocoles à source ouverte de les contacter. Cela nous amène à l'autre sujet que je voulais aborder. Tout au long de l'événement, les intervenants ont insisté sur le fait que l'écosystème ne peut se développer qu'avec les contributions des développeurs. Un effort concentré est nécessaire pour faire de MCP la nouvelle norme web et se démarquer des autres protocoles d'agents populaires.

MCP dans le monde réel : Études de cas et démonstrations

Plusieurs organisations ont expliqué comment le MCP est déjà utilisé dans des applications pratiques :

• PayPal - Serveur MCP pour le commerce agentique : PayPal a présenté son nouvel agent-toolkit et son serveur MCP, qui peuvent changer fondamentalement l'expérience d'achat d'un utilisateur. Au lieu de parcourir les médias sociaux pour trouver des articles, comparer les prix et passer à la caisse, les utilisateurs peuvent discuter avec un agent qui se connecte au serveur MCP de PayPal pour gérer toutes ces actions.

• EpicAI.pro - Jarvis : Les développements de MCP nous rapprochent de plus en plus d'un véritable assistant de type Jarvis. Pour ceux qui ne connaissent pas les films d'Iron Man, Jarvis est un assistant IA qui utilise le langage naturel, répond aux entrées multimodales, n'a aucune latence lorsqu'il répond, est proactif en anticipant les besoins de l'utilisateur, gère automatiquement les intégrations et peut passer d'un appareil à l'autre et d'un lieu à l'autre en fonction du contexte. Si nous imaginons Jarvis comme un assistant robotique physique, MCP lui donne des "mains" ou la capacité de gérer des tâches complexes.

• Postman - Générateur de serveur MCP: Fournit une expérience de panier pour les demandes d'API où vous pouvez choisir différentes demandes d'API, les mettre dans un panier et télécharger l'ensemble du panier en tant que serveur MCP.

• Bloomberg - Bloomberg a résolu un goulot d'étranglement important dans le développement de la GenAI en entreprise. Avec près de 10 000 ingénieurs, la société avait besoin d'un moyen standardisé pour intégrer les outils et les agents au sein des équipes. Avec MCP, ils ont transformé leurs outils internes en composants modulaires à distance que les agents peuvent facilement appeler sur une interface unifiée. Cela a permis à leurs ingénieurs de fournir des outils à l'ensemble de l'organisation, tandis que les équipes d'intelligence artificielle se sont concentrées sur la création d'agents plutôt que sur des intégrations personnalisées. Bloomberg prend désormais en charge des flux de travail d'agents évolutifs et sécurisés qui débloquent une interopérabilité totale avec l'écosystème MCP. Bloomberg n'a lié aucune ressource publique, mais c'est ce qu'ils ont présenté en public lors du sommet.

• Block - Block utilise MCP pour alimenter Goose, un agent d'intelligence artificielle interne qui permet aux employés d'automatiser des tâches dans les domaines de l'ingénierie, des ventes, du marketing, etc. Ils ont construit plus de 60 serveurs MCP pour des outils tels que Git, Snowflake, Jira et Google Workspace afin de permettre une interaction en langage naturel avec les systèmes qu'ils utilisent tous les jours. Les employés de Block utilisent désormais Goose pour interroger les données, détecter les fraudes, gérer les incidents, naviguer dans les processus internes et bien plus encore, le tout sans avoir à écrire de code. MCP a aidé Block à adopter l'IA dans de nombreuses fonctions en seulement 2 mois.

• AWS - Serveurs MCP AWS: AWS a présenté un serveur MCP amusant sur le thème de Donjons et Dragons qui simule un lancer de dés, suit les lancers passés et renvoie les résultats à l'aide de HTTP en continu. Cet exemple léger a mis en évidence la facilité avec laquelle il est possible de construire et de déployer des serveurs MCP à l'aide d'outils et d'infrastructures AWS comme Lambda et Fargate. Ils ont également présenté Strands SDK, un kit d'outils open-source pour la création d'agents multimodaux qui interagissent avec les serveurs MCP.

Support MCP dans Elastic Agent Builder

Vous pouvez commencer à expérimenter MCP dès aujourd'hui en utilisant Elastic Agent Builder, qui est le moyen le plus simple de créer des agents directement à partir de vos données. Agent Builder vous permet d'exposer des outils basés sur Elasticsearch à des agents compatibles avec MCP et il est déjà livré avec quelques outils intégrés puissants, notamment :

• platform.core.search - Exécute des recherches à l'aide du DSL Elasticsearch Query complet.

• platform.core.list_indices - Liste de tous les index disponibles dans Elasticsearch (aide les agents à découvrir les données existantes)

• platform.core.get_index_mapping - Récupère les correspondances de champs pour un index spécifique (aide les agents à comprendre la forme et les types de vos données).

• platform.core.get_document_by_id - Recherche d'un document spécifique par son numéro d'identification (pour une recherche précise)

Grâce à ces outils, vous pouvez doter votre agent d'une fonction de recherche et de pertinence au niveau de l'entreprise, ce qui est essentiel pour créer des agents d'intelligence artificielle fiables.

Ce qui rend Agent Builder encore plus puissant, c'est la possibilité de définir et d'exposer vos propres outils personnalisés, adaptés aux besoins de votre application. Ceci est particulièrement utile pour les flux de travail basés sur l'opinion ou répétables lorsque vous souhaitez que l'agent effectue un type de recherche spécifique sur un index spécifique sans avoir à redécouvrir cette logique à chaque fois. Au lieu de dépenser des jetons en planification et en raisonnement pour arriver à la même conclusion, vous pouvez encoder cette intention directement dans un outil, ce qui rend vos agents plus rapides, plus fiables et plus rentables.

Dans l'interface utilisateur de l'Agent Builder, voici un exemple de définition d'outil personnalisé qui utilise ES|QL :

Une fois que vous avez défini vos outils personnalisés, vous pouvez les exposer (ainsi que les outils natifs intégrés) à l'aide de MCP en cliquant sur la liste déroulante Manage MCP et en copiant l'URL du serveur MCP.

Vous pouvez maintenant importer ce point de terminaison MCP dans n'importe quel client qui consomme MCP pour le connecter à Agent Builder et lui donner accès à tous les outils disponibles. Pour plus d'informations, lisez cette introduction à Agent Builder.

Conclusion

Le MCP Dev Summit a clairement montré que le MCP façonne la manière dont ces agents d'intelligence artificielle interagissent entre eux et avec le monde des données qui les entoure. Qu'il s'agisse de connecter un agent aux données de l'entreprise ou de concevoir des agents entièrement autonomes, MCP offre une méthode d'intégration normalisée et composable qui devient rapidement utile à grande échelle. Des protocoles de transport et des modèles de sécurité aux registres et à la gouvernance, l'écosystème MCP mûrit rapidement. Le programme MCP restera ouvert et axé sur la communauté, de sorte que les développeurs d'aujourd'hui ont la possibilité de façonner son évolution.