Ce que la rétrocompatibilité implique pour l'API Kibana Dashboards

Pendant la préversion technique, la forme de l'API pouvait changer d'une version à l'autre.[1] Ce n'est plus le cas. La disponibilité générale (DG) signifie :

• Rétrocompatibilité totale. De nouveaux champs et types de panneaux seront ajoutés au fil du temps, mais les champs et comportements existants demeureront inchangés. Toute modification majeure susceptible de rompre la compatibilité sera examinée avec la plus grande attention et ne sera introduite que dans une nouvelle version majeure de la pile technologique.

• Prête pour la production avec compatibilité totale. L'API bénéficie des garanties de compatibilité complète d'Elastic. Vous pouvez l'utiliser en toute sécurité dans les environnements de production pour les déploiements automatisés, la promotion de l'environnement et la gestion programmatique des tableaux de bord.

Nouveaux points de terminaison de l'API Kibana pour les panneaux Tags, Markdown et Links

Elastic 9.5 introduit également un nouveau point de terminaison autonome pour le panneau Tags, qui vous permet de catégoriser et filtrer les tableaux de bord. Vous pouvez désormais les gérer par programmation via des points de terminaison CRUD dédiés, ce qui facilite leur organisation à grande échelle dans différents environnements.

De nouveaux points de terminaison pour les panneaux Markdown et Liens sont désormais disponibles dans Serverless et seront intégrés dans la prochaine version de la pile (9.6).

Quels types de panneaux l'API Kibana Dashboards prend-elle en charge ?

L'API Dashboards prend en charge tous les panneaux par valeur de la version 9.5 (ceux définis directement dans un tableau de bord, par opposition aux panneaux de bibliothèque enregistrés pour être réutilisés). Chaque type de panneau pris en charge dispose d'un schéma typé et validé.

Type de panneau

État

Graphiques XY

Compatibles

Métriques

Compatibles

Circulaires

Compatibles

Jauge

Compatibles

Carte thermique

Compatibles

Tables de données

Compatibles

Arborescence

Compatibles

Sessions Discover

Compatibles

Contrôles

Compatibles

Markdown

Compatibles

Liens

Compatibles

Panneaux ML

Compatibles

Panneaux Observability

Compatibles

Maps

Bientôt disponible

Vega

Bientôt disponible

Comment gérer les tableaux de bord Kibana sous forme de code

L'API Dashboards permet un workflow complet de tableaux de bord sous forme de code : exportez un tableau de bord au format JSON propre et facilement comparable, validez-le dans Git comme source de référence, examinez les modifications via des requêtes pull et déployez la même définition dans les environnements de développement, de préproduction et de production. Une fois qu'un tableau de bord est géré sous forme de code, considérez Git comme source de référence unique : les modifications effectuées directement dans l'interface utilisateur seront écrasées lors du prochain déploiement.

La principale difficulté lors du transfert d'un tableau de bord entre des espaces, des clusters ou des environnements est que les tableaux de bord font référence à des objets (data views ou visualisations de bibliothèques, par exemple) au moyen d'identifiants. Comme ces identifiants sont générés automatiquement et varient d'un environnement à l'autre, un tableau de bord exporté depuis un environnement peut pointer vers des objets inexistants dans un autre. Il existe trois méthodes pour gérer cette situation, présentées ici de la plus automatisée à la moins automatisée :

• Utilisez Terraform. Le fournisseur Elastic Stack Terraform suit chaque ressource et associe automatiquement les identifiants par environnement, afin que les références restent cohérentes lorsque vous faites passer un tableau de bord de l'environnement de développement à l'environnement de production.

• Définissez par valeur les panneaux Elasticsearch Query Language (ES|QL). La méthode la plus portable pour créer un panneau consiste à définir sa visualisation à l'aide d'ES|QL directement dans le tableau de bord. Une requête ES|QL lit les données à partir des index qui y sont spécifiés ; le panneau ne contient donc aucune référence externe à des data views ou à des objets de bibliothèque. On obtient ainsi un tableau de bord entièrement autonome et portable.

• Attribuer les identifiants correspondants. Si vous référencez des objets enregistrés, tels que des data views ou des visualisations de bibliothèque, créez-les avec un identifiant spécifique en utilisant la méthode PUT (upsert) plutôt que POST (qui génère automatiquement un identifiant). Utilisez des identifiants explicites et lisibles, comme logs-prod, afin qu'ils soient faciles à reconnaître et à réutiliser d'un environnement à l'autre.

Pour une présentation détaillée de ces modèles de portabilité et du workflow complet des tableaux de bord sous forme de code, consultez la documentation Gérer les tableaux de bord sous forme de code.

Création d'un tableau de bord Kibana avec l'API Dashboards en utilisant PUT

Voici un exemple rapide de création d'un tableau de bord avec un panneau de métriques, utilisant la méthode PUT au lieu de POST pour attribuer un identifiant personnalisé basé sur le nom du tableau de bord (service-health-overview). La même logique s'applique à la création de visualisations autonomes enregistrées dans la bibliothèque.

Roadmap de l'API Kibana Dashboards : Maps, Vega et points de terminaison autonomes

Nous travaillons activement à étendre la surface de l'API. La prise en charge des panneaux Maps et Vega est la prochaine étape, avec ajout de schémas typés. Nous développons également des points de terminaison CRUD autonomes pour les sessions Discover (au-delà de leur prise en charge actuelle en tant que panneaux de tableau de bord), les panneaux Vega, Maps et les Annotations, le tout dissocié du cycle de vie des tableaux de bord.

Pour les définitions complètes des schémas, consultez la documentation de l'API Dashboards. Pour les utilisateurs de Terraform, le fournisseur Elastic Stack Terraform prend en charge l'API Dashboards en DG.

Remarque

1. Les points de terminaison principaux restent inchangés par rapport à la préversion technique. Si vous avez développé des intégrations pour la version 9.4, elles fonctionneront avec la version 9.5. Les seuls changements entraînant une rupture de compatibilité sont deux modifications mineures concernant la liste des tableaux de bord et les formats d'unité de durée ; elles sont documentées ici.

Les modèles d'IA les plus puissants fonctionnent sur des infrastructures cloud distantes accessibles via une API web ; vous devez donc faire confiance à votre fournisseur de services d'IA pour garantir la sécurité, la disponibilité du service et la stabilité des tarifs. Il est difficile de concilier des exigences légitimes en matière de fiabilité, de confidentialité, de maîtrise des coûts et de bonne gouvernance des données avec une utilisation de l'IA toujours plus puissante, sophistiquée et gourmande en ressources.

Les réglementations gouvernementales, les décisions de justice et les décisions commerciales prises dans l'intérêt de tiers ont récemment conduit à restreindre l'accès à certains services. Or, même s'il est possible de se tourner vers d'autres solutions, les modèles d'IA ne sont pas des composants que l'on peut remplacer au gré de ses envies. Les applications qui exploitent les embeddings sémantiques nécessitent l'accès aux mêmes modèles lors de l'interrogation que lors de l'ingestion des données ; perdre l'accès à votre modèle d'embedding revient donc à paralyser votre système de recherche.

Les modèles de tarification de l'IA accentuent ce risque. Les récentes informations financières communiquées par les principaux fournisseurs d'IA donnent aux clients de bonnes raisons de s'inquiéter d'éventuelles hausses de prix. Le recours à des produits aux coûts imprévisibles accroît encore les risques associés à des investissements massifs dans l'IA, dont le retour sur investissement peut s'avérer aléatoire.

Jina On-Prem est la réponse d'Elastic à ces défis.

Qui a besoin d'une IA sur site ?

L'hébergement local et le contrôle direct de vos modèles d'IA répondent à diverses contraintes techniques, exigences sectorielles et impératifs commerciaux.

Une installation locale réduit les frais payés à vos fournisseurs de services d'IA, mais elle fait peser sur votre organisation les coûts liés au matériel et à la fiabilité de l'accès. Selon votre volume d'utilisation, cette option peut s'avérer plus économique. Toutefois, d'autres contraintes justifient d'envisager l'exploitation de votre propre système d'IA. Si l'un des problèmes décrits ci-dessous concerne votre entreprise, envisagez une solution d'IA locale telle que Jina On-Prem. Cette liste n'est pas exhaustive.

Cas d'utilisation

Pourquoi sur site

Exemple

Air gap/haute sécurité

Aucune transmission de données sortante ; isolation complète du réseau

Défense, renseignement, recherche classifiée

Conformité réglementaire

Souveraineté des données ; aucune transmission transfrontalière ni exposition à des tiers

Santé (Health Insurance Portability and Accountability Act [HIPAA]), finance, entreprises de l'UE (Règlement général sur la protection des données [RGPD])

Sensible à la latence

Dépendance réseau nulle ; aucune tolérance aux échecs de connexion

Robotique, edge computing, véhicules, navires

Prévisibilité des coûts

Coût d'infrastructure fixe vs tarification au jeton avec des tarifs futurs incertains

Charges de travail d'inférence continue à fort volume

Réduction de la responsabilité

Aucune exposition de données de tiers ; préservation de la confidentialité des communications et du devoir de diligence

Cabinets d'avocats, organismes publics

Pourquoi les systèmes air gap et protégés par pare-feu ont besoin d'une IA sur site

Les systèmes air gap et protégés par un pare-feu ne peuvent pas utiliser d'API d'IA externes. Jina On-Prem s'exécute entièrement au sein de votre infrastructure, sans aucune connexion sortante.

Pour les organisations qui gèrent des données particulièrement sensibles, les questions de sécurité et de confidentialité sont primordiales. Il est peu utile d'investir dans la protection de vos données sensibles si vous les confiez aussitôt à un tiers distant dont les mesures de sécurité pourraient être insuffisantes ou qui pourrait être soumis aux exigences d'un gouvernement étranger.

Les employés des organisations qui manipulent des données sensibles reçoivent souvent une formation sur la gestion sécurisée de ces données. Toutefois, cette mesure perd de son efficacité dès lors qu'ils disposent de navigateurs web susceptibles d'accéder à n'importe quelle page d'Internet pendant qu'ils traitent ces informations. L'isolation constitue la mesure de sécurité la plus efficace, qu'elle soit assurée par une séparation physique totale ou par des pare-feux très restrictifs, mais elle entrave considérablement l'utilisation de services externes, quels qu'ils soient.

IA sur site pour les systèmes sensibles à la latence et à haute disponibilité

Le logiciel en tant que service (SaaS) et le cloud computing constituent un compromis entre le coût lié à l'hébergement de services hautement accessibles et fiables sur vos propres infrastructures et le choix de confier cette tâche à un tiers. Toutefois, ces solutions s'accompagnent d'une latence variable, d'interruptions de service et d'une perte totale de contrôle en cas de dysfonctionnement. Les services d'IA ne font pas exception à la règle : si votre système de recherche devient indisponible parce que vous ne pouvez plus accéder à votre modèle d'embedding, ce compromis pourrait apparaître bien moins avantageux.

Par ailleurs, le recours à une IA externe comporte toujours des risques difficiles à anticiper ou à gérer. L'accès à Internet et la latence du réseau peuvent se dégrader sans préavis, sous l'effet d'événements politiques, d'intempéries ou du passage d'ancres de navires sur des câbles sous-marins à fibre optique. Les gouvernements peuvent, et l'ont fait récemment, recourir à des interdictions d'exportation pour bloquer soudainement l'accès à des modèles d'IA. Les fournisseurs de services d'IA retirent parfois certains modèles pour inciter les utilisateurs à adopter des versions plus récentes. Il convient donc de mettre en balance la flexibilité et la maîtrise des coûts qu'offrent les services externes avec les risques de dépendance qu'ils engendrent.

IA sur site pour le respect des exigences du RGPD, de la loi HIPAA et de souveraineté des données

Les organisations qui collectent des données personnelles sont soumises à des réglementations de plus en plus strictes qui diffèrent souvent d'une juridiction à l'autre et peuvent imposer des exigences contradictoires. Ainsi, les règles HIPAA imposent des protections des données très strictes aux prestataires de santé américains, et des législations strictes sur la protection générale des données au Canada, dans l'Union européenne et dans de nombreuses juridictions asiatiques exigent que toutes les entreprises qui traitent des informations personnelles le fassent de manière sécurisée et limitent la transmission de ces données à des tiers ou à d'autres juridictions. Ces règles peuvent même imposer des obligations à des entités étrangères si elles comptent des clients dans ces juridictions. Les institutions financières sont souvent soumises à des règles encore plus strictes et assument, en matière de sécurité de l'information, la même responsabilité directe que celle qui leur incombe pour se prémunir contre d'autres formes d'activités criminelles.

La conformité réglementaire peut être incompatible avec les services d'IA tiers, en particulier si leur utilisation implique un transfert de données transfrontalier.

En outre, des événements récents montrent que les règles restreignant la localisation physique des espaces de stockage de données ne constituent pas nécessairement une garantie de protection fiable lorsque les fournisseurs internationaux de services cloud sont soumis à des pressions de la part de gouvernements étrangers. Les législations locales peuvent présenter des divergences d'une juridiction à l'autre, ce qui impose le stockage et le traitement des données au niveau local et rend impossible le recours à des services tiers. Dans certains cas, la seule solution consiste à internaliser l'ensemble de vos processus, y compris vos systèmes d'IA.

Risques de responsabilité liés à la transmission de données à des tiers dans le cadre de l'IA

Les lois sur la protection des données et les obligations de vigilance reconnues concernant les données sensibles entraînent régulièrement des conséquences en matière de responsabilité, parfois très lourdes. Vous pouvez être tenu pour responsable de la manière dont des prestataires de services tiers traitent vos données. Si les tribunaux et les procédures judiciaires peuvent offrir certaines protections a posteriori face à des prestataires peu fiables, ces recours ne sont ni disponibles ni généralement efficaces contre les acteurs de la sécurité nationale, les forces de l'ordre ou les cybercriminels.

Pour les gouvernements, des cas ont déjà été signalés où des fournisseurs de services cloud transfrontaliers ont divulgué des informations sensibles de l'État à des acteurs étrangers.

Toutefois, même si vous ne craignez ni les gouvernements étrangers ni les pirates informatiques, et que vos prestataires externes de services d'IA sont eux-mêmes sécurisés, le simple fait qu'ils soient externes peut engendrer des risques de responsabilité.

Par exemple, dans la plupart des juridictions, les communications entre avocats et clients bénéficient de protections juridiques spécifiques, et les cabinets d'avocats sont soumis à des obligations strictes concernant l'enregistrement ou le stockage de ces informations. Aux États-Unis, cette confidentialité des communications est si célèbre qu'il constitue un élément central de nombreux scénarios de films et de séries télévisées. Or, ce privilège peut être perdu si des informations sont communiquées à une personne n'étant pas couverte par ce secret ; des évolutions récentes suggèrent que les prestataires externes de services d'IA pourraient entrer dans cette catégorie.

Il est possible, du moins aux États-Unis, que le simple recours à des services d'IA tiers via une API Internet, comme l'intégration de modèles assurant des services d'indexation, enfreigne des règles de confidentialité essentielles. Un cabinet d'avocats pourrait faire l'objet de poursuites, de sanctions disciplinaires ou d'une radiation du barreau pour la simple utilisation d'un logiciel hébergé en externe, même en l'absence de toute faille de sécurité.

IA sur site pour les systèmes hors ligne, en périphérie et physiquement isolés

Les systèmes informatiques ne sont pas isolés uniquement pour des raisons de sécurité. Par exemple, les véhicules en déplacement ne peuvent pas dépendre d'un accès à Internet pour assurer des fonctions essentielles. Les navires et les aéronefs sont dotés de systèmes informatiques embarqués très complets qui doivent fonctionner sans connexion Internet et ne peuvent donc pas recourir à des services d'IA externes. Les plateformes offshore, les installations isolées en pleine nature, ainsi que les services informatiques situés dans l'Arctique, l'Antarctique ou sur de petites îles dépourvues de liaisons physiques adéquates avec les réseaux mondiaux, sont autant d'exemples d'installations qui tirent parti de l'hébergement local de tous les services dont elles ont besoin. À mesure que l'IA prend de l'importance dans l'informatique d'entreprise, il devient crucial de prendre en compte ces contraintes.

Les applications émergentes de l'IA aux systèmes physiques (robotique et autres cas d'utilisation confinés à un espace donné ou axés sur le monde extérieur, tels que les systèmes de gestion logistique ou même les caisses de supermarché) peuvent être connectées à l'Internet mondial, mais elles ne tolèrent ni les interruptions de connexion ni les pics de latence. Si leur fonctionnement repose sur un système d'IA, celui-ci doit être aussi local et fiable que possible.

Qui n'a pas besoin d'une IA sur site ?

Les services logiciels à distance et l'IA externalisée présentent des avantages. L'exécution de modèles d'IA peut nécessiter des processeurs coûteux et énergivores, dont la durée de vie est notoirement courte. L'accès à du matériel de haute qualité est particulièrement difficile à l'heure actuelle en raison de facteurs liés au marché et de chocs économiques externes. Dans ce contexte, il peut être judicieux de payer au jeton consommé pour utiliser une API externe, plutôt que de supporter les lourds investissements initiaux qu'implique une IA locale.

Les API externes constituent la solution la plus pertinente pour les utilisateurs occasionnels. Si vous exploitez des modèles d'IA principalement pour le traitement de données par lots à des fins d'analyse plutôt que pour faire fonctionner un système de recherche devant rester disponible en permanence, il est peu judicieux d'investir dans du matériel coûteux et des installations locales.

De plus, lorsque vos processus de traitement de données reposent déjà sur le cloud (comme c'est le cas, par exemple, d'un site e-commerce hébergé dans le cloud pour des raisons de fiabilité et d'accessibilité), le recours à des services d'IA intégrés à cette même infrastructure peut s'avérer plus rentable que de déployer votre propre modèle d'IA sous licence. Dans la mesure où vous dépendez déjà de votre fournisseur de services cloud, dépendre également de ses services d'IA n'ajoute pas de risque significatif.

Si votre cas d'utilisation correspond à cette description, les modèles Jina AI sont disponibles sur EIS, AWS Marketplace et Google Cloud Platform spécifiquement pour répondre à vos besoins.

Le tableau ci-dessous résume les facteurs clés. Votre réponse dépend de vos données, de votre infrastructure et de votre modèle d'utilisation.

Facteur

Sur site privilégié

API Cloud privilégiée

Modèle d'utilisation

Inférence continue ou à volume élevé

Traitement intermittent ou par lots

Sensibilité des données

Réglementées, souveraines ou classifiées

Aucune restriction transfrontalière ou liée à des tiers

Environnement réseau

Air gap, protégé par un pare-feu ou peu fiable

Internet stable et permanent

Infrastructure existante

Disposer de matériel GPU ou pouvoir s'en procurer

Déjà hébergé dans le cloud avec une IA en colocation

Modèle de coût

Matériel fixe + licence ; prévisible à grande échelle

Au jeton ; plus faible au départ, variable à long terme

Tolérance à la latence

Aucune (robotique, périphérie, temps réel)

La variabilité du réseau est acceptable

Responsabilité opérationnelle

Votre équipe gère le matériel et la disponibilité

Le fournisseur gère le matériel et les mises à jour ; vous gérez l'intégration

Vous devez évaluer les coûts et les avantages au regard de votre situation et de vos cas d'utilisation spécifiques, en tenant compte des points soulevés dans la section précédente qui vous concernent. Cette analyse coûts-avantages évoluera sans aucun doute avec le temps. Il est impossible de prédire l'avenir du secteur de l'IA ou l'évolution des prix du matériel, même à court terme.

Présentation de Jina On-Prem

Pour les utilisateurs pouvant tirer parti de services d'IA locaux, nous lançons Jina On-Prem, une suite d'installation entièrement autonome pour les modèles haute performance de Jina AI.

Les modèles de Jina AI égalent la précision de modèles d'embedding bien plus volumineux, tout en réduisant les coûts de calcul, l'empreinte mémoire et les besoins matériels. Ils sont ainsi le choix idéal pour les utilisateurs qui souhaitent ou doivent héberger leur IA sur site. Des licences commerciales sont disponibles avec des solutions scalables dont le tarif est proportionnel à l'utilisation afin de répondre aux cas d'utilisation de toute envergure.

Quels schémas d'API Jina On-Prem prend-il en charge ?

• Disponibles sous la forme d'une collection complète de dépendances pour une installation locale ou d'un conteneur Docker que vous pouvez installer et exécuter en quelques minutes.

• Les installations Jina On-Prem ne font pas appel à des systèmes externes.

  • Aucun appel au hub Hugging Face ni à aucun registre de modèles (HF_HUB_OFFLINE=1 et TRANSFORMERS_OFFLINE=1 sont intégrés).

  • Pas de serveur de licence.

  • Pas de points de terminaison de télémétrie ou de logging.

• Compatibles avec le matériel basé sur processeur et sur GPU, avec détection automatique du GPU.

• Les 28 modèles Jina AI sont tous disponibles, y compris les derniers modèles d'embeddings multimodaux jina-embeddings-v5-omni et jina-reranker-v3.

• Accès via des schémas API d'IA standards : API Jina, OpenAI, Cohere, Voyage AI et Gemini. Jina On-Prem est une solution clé en main pour les applications conçues sur ces schémas.

• Remplacement direct pour les modèles servis par EIS. Jina On-Prem s'intègre directement aux déploiements Elastic air gap.

Configuration matérielle requise pour les modèles sur site Jina AI

Les exigences matérielles varient selon les modèles Jina. Le tableau ci-dessous présente les recommandations pour les modèles les plus récents utilisant des GPU. Il n'est pas nécessaire de disposer d'une puissance supérieure à celle d'un GPU NVIDIA L4, bien qu'un modèle A100 soit recommandé pour les modèles d'embedding v5. Notre modèle d'embedding le plus récent nécessite actuellement un minimum de 8 Go de VRAM.

Modèle

VRAM minimum

GPU recommandé

jina-embeddings-v5-text-nano

2 Go

T4/L4

jina-embeddings-v5-text-small

3 Go

L4/A10G

jina-embeddings-v5-omni-small

8 Go

L4/A10G/A100

jina-reranker-v3

3 Go

L4

jina-clip-v2

4 Go

L4

jina-code-embeddings-1.5b

4 Go

L4

ReaderLM-v2

4 Go

L4

Si vous utilisez plus d'un modèle à la fois, les besoins en VRAM augmenteront. Pour plus d'informations, veuillez consulter la page Dimensionnement et matériel.

Comment installer Jina On-Prem avec Docker

Le moyen le plus rapide de démarrer est d'installer Docker (si ce n'est pas déjà fait) et de suivre les instructions sur la page Démarrage rapide de Jina On-Prem.

Des conteneurs Docker préconfigurés sont disponibles pour les 28 modèles Jina. Il vous suffit d'en télécharger un et de le transférer vers votre environnement cible pour faire fonctionner les modèles Jina AI en moins de cinq minutes.

Pour les builds multimodaux ou personnalisés, ou pour télécharger l'ensemble complet des dépendances pour une installation en dehors d'un conteneur, suivez les étapes indiquées dans le guide de regroupement.

Votre installation Jina On-Prem prend en charge l'ensemble des fonctionnalités de l'API Jina et d'EIS ainsi que la génération d'embeddings via les API OpenAI, Cohere, Voyage AI et Gemini, afin de pouvoir s'intégrer dans des applications préexistantes à l'aide d'interfaces standard. Consultez la documentation de l'API pour plus d'informations.

Les modèles Jina, y compris les modèles installés avec Jina On-Prem, sont disponibles selon diverses conditions de licence, les derniers modèles étant gratuits pour un usage non commercial sous licence CC BY-NC 4.0. Pour obtenir une licence Jina On-Prem à des fins commerciales, veuillez contacter Elastic Sales.

Cet article explique comment les endpoints de requête, de découverte et de métadonnées s’appuient sur les travaux d’ingestion et de requête antérieurs pour former cette surface API. Les articles connexes vont plus loin sur les éléments spécifiques :

• La prise en charge native de PromQL dans ES|QL couvre la manière dont les requêtes PromQL sont traduites en plans d’exécution ES|QL.

• Transférer des métriques Prometheus à Elasticsearch avec Remote Write couvre la configuration de l’ingestion.

• Comment fonctionne l'ingestion d'écriture à distance de Prometheus dans Elasticsearch couvre les aspects internes de l'écriture à distance.

Ce travail est encore en cours. Les sections ci-dessous indiquent ce qui est actuellement pris en charge et quelles parties évoluent encore.

La surface de l'API

Aujourd’hui, les interfaces API compatibles avec Prometheus se répartissent en trois catégories.

Endpoints de requête

Les endpoints de requête permettent aux clients compatibles avec Prometheus d’évaluer les expressions PromQL :

• GET /_prometheus/api/v1/query_range évalue une expression PromQL sur une fenêtre de temps (résultats matriciels).

• GET /_prometheus/api/v1/query évalue à un instant donné (résultats vectoriels). Actuellement implémenté en tant que requête à courte portée qui renvoie le dernier échantillon.

Seul GET est pris en charge pour les endpoints de requête actuellement. Certains clients utilisent par défaut la méthode POST. Vous devrez peut-être les configurer pour utiliser la méthode GET. La convention Prometheus POST utilise des corps application/x-www-form-urlencoded, que la couche HTTP d’Elasticsearch rejette comme protection CSRF avant que la requête n’atteigne le gestionnaire.

Pour connaître l’état complet de la couverture de PromQL, consultez l’article connexe sur PromQL dans ES|QL.

Points de terminaison des métadonnées

Les endpoints de métadonnées fournissent les informations de découverte dont les clients ont besoin pour l’autocomplétion, les listes déroulantes de variables et la navigation dans les métriques.

Les endpoints des séries, des étiquettes et des valeurs d’étiquette acceptent tous les sélecteurs match[] et une plage de temps (start/end). Le paramètre match[] prend un sélecteur de série Prometheus comme http_requests_total{job="api"} et limite la réponse aux séries temporelles qui correspondent. Les réponses restent ainsi rapides et pertinentes sur les clusters comportant un grand nombre de métriques. Par exemple :

La première renvoie toutes les séries pour http_requests_total où job="api", avec leurs ensembles d’étiquettes complets. La seconde renvoie uniquement les noms des étiquettes qui existent sur les séries http_requests_total. Le troisième renvoie uniquement les valeurs de instance qui apparaissent sur les séries correspondantes.

GET /_prometheus/api/v1/metadata est différent : il retourne le type et l’unité pour chaque métrique, éventuellement filtrés par nom via un paramètre metric.

Il n’accepte pas les sélecteurs match[] ni aucune plage horaire. Dans Prometheus, les métadonnées sont collectées à partir de cibles de scrape actives (les lignes HELP, TYPE et UNIT qu’elles exposent). La réponse n’implique donc pas de scan des données. Elasticsearch ne dispose pas d’un dépôt dédié de métadonnées comme celui-ci, donc l’implémentation actuelle découvre les métadonnées des métriques en visitant les données temporelles des dernières 24 heures. Cela permet de maintenir la rapidité de la requête sans nécessiter un balayage complet de l’index. Cette analyse en 24 heures est aujourd’hui corrigée : l’API de métadonnées Prometheus ne divulgue pas les paramètres start ni end qu’Elasticsearch pourrait utiliser pour la rendre ajustable par l’utilisateur.

Le fonctionnement des endpoints des métadonnées, y compris les commandes TS_INFO et METRICS_INFO qui les alimentent, est expliqué ci-dessous.

Index de pré-filtrage

Tous les endpoints de requête et de métadonnées acceptent un segment de chemin {index} optionnel après /_prometheus/ :

Il limite les index Elasticsearch sur lesquels la requête est en exécution avant le début de toute évaluation d’expression. Sur les clusters comportant de nombreux flux de données entre équipes ou environnements, cela évite de scanner des index non pertinents et peut réduire de manière significative la latence des requêtes. Vous pouvez configurer des sources de données distinctes par modèle d’indexation afin de fournir aux équipes un accès limité à leurs propres métriques.

Remarque sur Remote Write

Pour l’ingestion, Elasticsearch expose également l’endpoint standard Prometheus Remote Write :

• POST /_prometheus/api/v1/write ingère des séries temporelles via le protocole Prometheus Remote Write v1. v2 n’est pas encore pris en charge.

Remote Write écrit dans les flux de données temporelles existants d’Elasticsearch (TSDS), et non dans une couche de stockage spécifique à Prometheus. Les étiquettes Prometheus deviennent des dimensions TSDS, et les noms des métriques deviennent des champs dans le mapping des index. L’article sur l’architecture de l’écriture à distance couvre le mapping complet en détail, notamment comment les types de métriques sont déduits et comment les étiquettes sont stockées avec un préfixe labels..

Fonctionnement

En interne, tous les endpoints fonctionnent de la même manière : ils analysent les paramètres HTTP entrants, construisent un plan de requête ES|QL, l’exécutent sur des flux de données temporelles et convertissent le résultat en colonnes au format JSON attendu par les clients Prometheus.

TS_INFO et METRICS_INFO

Les endpoints des métadonnées doivent répondre à des questions telles que « quelles étiquettes existent ? » ou « quels types de métriques sont définis ? » sur des millions de séries temporelles, sans analyser chaque point de données.

En interne, les endpoints de métadonnées Prometheus répondent à ces questions en construisant des plans ES|QL autour de deux nouvelles commandes de traitement : METRICS_INFO et TS_INFO. Vous n’avez pas besoin d’utiliser ces commandes directement pour utiliser l’API Prometheus, mais elles constituent les primitives d’exécution fondamentales qui sous-tendent les réponses aux métadonnées. Toutes deux fonctionnent en ne visitant qu’un seul document par série temporelle pour extraire ses métadonnées, plutôt que de parcourir tous les échantillons. Cela signifie que leur coût évolue avec le nombre de séries temporelles distinctes, et non en fonction du nombre de points de données.

METRICS_INFO renvoie une ligne par métrique distincte avec son nom, son type, son unité et ses champs de dimension associés. TS_INFO est plus granulaire : une ligne par combinaison (métrique, série temporelle), incluant les valeurs réelles des dimensions en tant qu'objet JSON.

Un article de blog dédié à TS_INFO et METRICS_INFO sera bientôt publié, abordant le modèle d’exécution en deux phases, la façon dont ils s’adaptent et la façon de les utiliser directement dans les requêtes ES|QL au-delà de l’API Prometheus.

Comment les points de terminaison des métadonnées les utilisent

Chaque endpoint des métadonnées construit un plan ES|QL avec l’une de ces commandes à son noyau.

/api/v1/labels et /api/v1/series utilisent TS_INFO, car ils ont besoin de détails par série temporelle (quelles étiquettes existent, quelles valeurs de dimension identifient chaque série). /api/v1/metadata et /api/v1/label/__name__/values utilisent METRICS_INFO, car ils n’ont besoin que d’informations métriques (noms, types et unités métriques).

/api/v1/label/{name}/values pour les étiquettes ordinaires (autres que __name__), n’utilisez aucune des deux commandes. Les étiquettes régulières comme job ou instance sont de véritables champs de dimensions dans l’index, de sorte que l’endpoint peut les interroger directement avec une agrégation group-by. Lorsque des sélecteurs match[] sont fournis, ils sont traduits en une clause WHERE qui filtre la série temporelle avant l’exécution de l’agrégation.

Le label __name__ nécessite une stratégie différente car il n’est pas toujours présent sous forme de champ de dimension. Prometheus Remote Write stocke labels.__name__, mais les mesures ingérées par d’autres voies (OpenTelemetry, l’API Bulk) ne les contiennent pas. Le nom de la métrique est encodé dans le nom même du champ (par exemple, metrics.http_requests_total). Vous pourriez consulter les correspondances d’index pour énumérer les noms des champs, mais les correspondances seules ne vous indiquent pas quelle métrique a quelles dimensions, et elles ne peuvent pas être filtrées par les valeurs d’étiquettes d’un sélecteur match[]. METRICS_INFO peut faire les deux : il énumère les noms des métriques dans les index tout en respectant les filtres WHERE en amont.

Dans tous les cas, la couche API gère la conversion vers les conventions Prometheus : elle supprime les préfixes de stockage labels. et metrics., et synthétise __name__ pour les métriques non-Prometheus qui en sont dépourvues.

Conclusion

Résultat : tout client compatible avec Prometheus peut interroger et explorer les métriques Elasticsearch par le biais d’endpoints qu’il comprend déjà. Les mesures d’écriture à distance, les mesures OpenTelemetry et les mesures indexées par d’autres chemins sont toutes affichées avec la même API et les mêmes index TSDS.

Toutes les API Prometheus mentionnées ici sont désormais disponibles en préversion technique dans Elasticsearch Serverless. Pour les clusters autogérés et les déploiements hébergés par Elastic Cloud Hosted, disponibles en préversion technique dans Elasticsearch 9.4, à l’exception de GET /_prometheus/api/v1/metadata. Pour expérimenter localement, utilisez start-local.

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

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.

Les modèles Jina se répartissent en trois grandes catégories, conçues pour faciliter le traitement, l’organisation et la recherche d’informations :

• Modèles d’embedding sémantique

• Modèles de reclassification

• Petits modèles de langage génératif

Modèles d’embedding sémantique

L’idée derrière les embeddings sémantiques est qu’un modèle d’IA peut apprendre à représenter certains aspects du sens d’une entrée en s’appuyant sur la géométrie d’espaces à très grande dimension.

On peut considérer un embedding sémantique comme un point (techniquement un vecteur) dans un espace à plusieurs dimensions. Un modèle d’embedding est un réseau de neurones qui reçoit des données numériques en entrée (souvent du texte ou une image) et renvoie l’emplacement du point correspondant dans un espace multidimensionnel, sous forme de coordonnées numériques. Si le modèle est efficace, la distance entre deux embeddings sémantiques est proportionnelle à la similarité de sens des objets correspondants.

Pour comprendre l’intérêt de cette approche dans les applications de recherche, imaginez les embeddings des mots « chien » et « chat » comme des points dans l’espace :

Un bon modèle d’embedding générera une représentation du mot « félin » bien plus proche de « chat » que de « chien », tandis que « canidé » sera plus proche de « chien » que de « chat », car ces mots partagent un sens très proche :

Si un modèle est multilingue, nous nous attendrions à la même chose pour les traductions de « chat » et « chien » :

Les modèles d’embedding traduisent la similarité ou la différence de sens entre des éléments en relations spatiales entre leurs représentations vectorielles. Les illustrations ci-dessus sont en deux dimensions pour faciliter la visualisation, mais les modèles d’embedding produisent des vecteurs comportant des dizaines, voire des milliers de dimensions. Cela leur permet de capturer les subtilités du sens dans des textes entiers, en leur associant un point dans un espace comportant des centaines, voire des milliers de dimensions, pour des documents pouvant contenir des milliers de mots.

Embeddings multimodaux

Les modèles multimodaux étendent le principe des embeddings sémantiques à d’autres types de contenu que le texte – notamment les images. On s’attend donc à ce qu’un embedding d’image soit proche de celui d’une description fidèle de cette image :

Les embeddings sémantiques offrent de nombreux cas d’usage. Ils peuvent notamment servir à créer des classificateurs efficaces, à regrouper les données (data clustering), ou encore à effectuer des tâches comme la déduplication ou l’analyse de la diversité des données – des fonctionnalités clés dans les environnements big data où les volumes à traiter sont trop importants pour être gérés manuellement.

L’usage principal des embeddings concerne la recherche d’informations. Elasticsearch peut stocker des objets de récupération avec des embeddings comme clés. Les requêtes sont converties en vecteurs d’embedding, et une recherche renvoie les objets stockés dont les clés sont les plus proches du vecteur d’embedding de la requête.

Là où la recherche vectorielle traditionnelle (par vecteur unique ou vecteur clairsemé) utilise des vecteurs basés sur les mots ou les métadonnées dans les documents et les requêtes, la recherche par embeddings (ou vecteurs denses) utilise des significations évaluées par l’IA plutôt que des mots. Cela les rend en général plus flexibles et plus précis que les méthodes de recherche classiques.

Apprentissage par représentation de type matriochka

Le nombre de dimensions d’un embedding et la précision des valeurs qu’il contient ont un impact significatif sur les performances. Les espaces très dimensionnels et les nombres de très grande précision permettent de représenter des informations très complexes et détaillées, mais nécessitent des modèles d’IA plus coûteux à entraîner et à exécuter. Les vecteurs générés occupent également plus d’espace de stockage et nécessitent davantage de ressources de calcul pour mesurer les distances entre eux. L’utilisation de modèles d’embedding sémantique implique donc un compromis important entre précision et consommation de ressources.

Pour maximiser la flexibilité côté utilisateur, les modèles Jina sont entraînés avec une technique appelée Matryoshka Representation Learning. Cette méthode pousse le modèle à prioriser les distinctions sémantiques importantes dans les premières dimensions du vecteur, ce qui permet ensuite de tronquer les dimensions les plus élevées sans perte significative de performance.

Concrètement, cela signifie que les utilisateurs des modèles Jina peuvent choisir le nombre de dimensions qu’ils souhaitent attribuer à leurs embeddings. Réduire le nombre de dimensions entraîne une perte de précision, mais la dégradation des performances reste mineure. Pour la plupart des tâches, les performances des modèles Jina diminuent d’environ 1 à 2 % chaque fois que l’on réduit la taille des embeddings de 50 %, jusqu’à une réduction d’environ 95 %.

Récupération asymétrique

La similarité sémantique est généralement mesurée de façon symétrique. La valeur obtenue en comparant « chat » à « chien » est la même que celle obtenue en comparant « chien » à « chat ». Mais lorsqu’on utilise des embeddings pour la recherche d’informations, les résultats sont meilleurs si l’on casse cette symétrie et qu’on encode les requêtes différemment des objets à retrouver.

Cela tient à la façon dont les modèles d’embedding sont entraînés. Les données d’entraînement contiennent des éléments similaires, comme des mots, dans des contextes variés, et les modèles apprennent à en déduire le sens en comparant les similitudes et les différences contextuelles entre ces éléments.

Ainsi, il se peut par exemple que le mot « animal » apparaisse rarement dans les mêmes contextes que « chat » ou « chien », et que l’embedding du mot « animal » ne soit donc pas particulièrement proche de ceux de « chat » ou « chien ».

Cela réduit la probabilité qu’une requête sur le mot « animal » retourne des documents traitant de chats et de chiens — ce qui est précisément l’effet inverse de l’objectif recherché. On encode donc le mot « animal » différemment selon qu’il s’agit d’une requête ou d’un objet cible à retrouver :

La recherche asymétrique consiste à utiliser un modèle différent pour les requêtes, ou à entraîner un modèle d’embedding de façon spécifique pour encoder différemment les éléments selon qu’ils sont stockés pour la recherche ou utilisés comme requêtes.

Embeddings multi-vecteurs

Les embeddings simples sont efficaces pour la recherche d’informations car ils s’intègrent bien au fonctionnement d’une base indexée : les objets à retrouver sont stockés avec un unique vecteur d’embedding utilisé comme clé de recherche. Lorsque les utilisateurs interrogent le magasin de documents, leurs requêtes sont converties en vecteurs d’embedding, et les documents dont la clé est la plus proche de celle de la requête (dans l’espace vectoriel de haute dimension) sont retournés comme correspondances candidates.

Les embeddings multi-vecteurs fonctionnent différemment. Au lieu de générer un vecteur de longueur fixe pour représenter une requête ou un objet stocké, ils produisent une séquence d’embeddings représentant des parties plus petites de ces éléments. Ces parties sont généralement des jetons ou mots pour les textes, ou des fragments d’image pour les données visuelles. Ces embeddings traduisent le sens de chaque élément dans son contexte.

Par exemple, prenons ces phrases:

• She had a heart of gold.

• She had a change of heart.

• She had a heart attack.

En apparence, ces phrases sont très similaires, mais un modèle multi-vecteur générerait probablement des embeddings très différents pour chaque occurrence du mot « heart », car son sens varie dans le contexte de chaque phrase:

Comparer deux objets à l’aide de leurs embeddings multi-vecteurs revient souvent à calculer leur distance de Chamfer : on compare chaque élément d’un embedding avec ceux de l’autre, puis on additionne les distances minimales. D’autres systèmes, y compris les modules de reclassification Jina présentés plus bas, transmettent ces données à un modèle d’IA spécifiquement entraîné à évaluer leur similarité. Ces deux approches offrent généralement une précision supérieure à la simple comparaison de vecteurs uniques, car les embeddings multi-vecteurs capturent beaucoup plus d’informations contextuelles.

Toutefois, les embeddings multivecteurs sont peu adaptés à l’indexation. Ils sont souvent utilisés dans les tâches de reclassification, comme illustré dans le modèle jina-colbert-v2 présenté dans la section suivante.

Modèles d’embedding Jina

Jina Embeddings v4

jina-embeddings-v4 est un modèle multilingue et multimodal de 3,8 milliards de paramètres (3,8 × 10⁹), compatible avec des textes dans une grande diversité de langues. Il repose sur une architecture innovante qui exploite les connaissances visuelles et linguistiques pour améliorer les performances dans les deux domaines, en particulier dans les tâches de recherche d’images — notamment la recherche de documents visuels. Cela signifie qu’il est capable de traiter des images comme des graphiques, des présentations, des captures d’écran, des pages scannées ou des schémas — des types d’images courants contenant souvent du texte embarqué, en dehors du champ des modèles de vision entraînés sur des scènes du monde réel.

Nous avons optimisé ce modèle pour différentes tâches à l’aide d’adaptateurs compacts LoRA (Low-Rank Adaptation). Cette approche nous permet d’entraîner un modèle unique capable de se spécialiser dans plusieurs tâches sans perte de performance, pour un coût mémoire ou calculatoire minimal.

Principales fonctionnalités :

• Des performances de pointe en recherche de documents visuels, avec en plus une excellente prise en charge du texte multilingue et des images classiques — surpassant des modèles bien plus volumineux.

• Prise en charge de contextes d’entrée étendus : 32 768 jetons correspondent à environ 80 pages de texte en anglais double interligne, et 20 mégapixels équivalent à une image de 4 500 × 4 500 pixels.

• Taille des embeddings sélectionnée par l’utilisateur, allant de 2048 dimensions au maximum jusqu’à 128 dimensions. Nous avons constaté empiriquement une forte dégradation des performances en dessous de ce seuil.

• Compatibilité avec les embeddings simples et multi-vecteurs. Pour le texte, la sortie multivecteur se compose d’un embedding de 128 dimensions pour chaque jeton d’entrée. Pour les images, un embedding de 128 dimensions est généré pour chaque bloc de 28 × 28 pixels nécessaires à la couverture de l’image.

• Optimisation pour la recherche asymétrique grâce à une paire d’adaptateurs LoRA spécialement entraînés à cet effet.

• Un adaptateur LoRA optimisé pour le calcul de similarité sémantique.

• Prise en charge spécifique des langages de programmation et des frameworks IT, également via un adaptateur LoRA.

Nous avons développé jina-embeddings-v4 comme outil polyvalent pour toute une gamme de tâches : recherche, compréhension du langage naturel et analyse basée sur l’IA. C’est un modèle relativement compact au vu de ses capacités, mais qui demande tout de même des ressources importantes pour être déployé, et convient mieux à une utilisation via une API cloud ou dans un environnement haute performance.

Jina Embeddings v3

jina-embeddings-v3 est un modèle d’embedding multilingue, léger, performant, axé sur le texte, avec moins de 600 millions de paramètres. Il prend en charge jusqu’à 8 192 jetons de texte en entrée et génère des embeddings vectoriels simples, avec des tailles personnalisables (de 1 024 à 64 dimensions).

Nous avons entraînerjina-embeddings-v3 non seulement pour la recherche d’informations et la similarité sémantique, mais aussi pour des tâches de classification, comme l’analyse de sentiments, la modération de contenu, le clustering, l’agrégation de nouvelles et la recommandation. Comme jina-embeddings-v4, ce modèle utilise des adaptateurs LoRA spécialisés pour les cas d’usage suivants :

• Récupération asymétrique

• Similarité sémantique

• Classification

• Clustering

jina-embeddings-v3 est un modèle beaucoup plus compact que jina-embeddings-v4 , avec une taille de contexte en entrée considérablement réduite, mais qui est aussi moins coûteux à exécuter. Malgré cela, il offre des performances très compétitives (bien qu’uniquement sur du texte) et représente un choix pertinent pour de nombreux cas d’usage.

Embeddings de code Jina

Les modèles Jina spécialisés pour l’embedding de code — jina-code-embeddings (0,5 Md et 1,5 Md de paramètres) — prennent en charge 15 langages de programmation ainsi que des textes en anglais dans le domaine de l’informatique et des technologies de l’information. Ce sont des modèles compacts, avec respectivement 500 millions et 1,5 milliard de paramètres. Les deux modèles acceptent jusqu’à 32 768 jetons en entrée et permettent à l’utilisateur de définir la taille des embeddings générés : de 896 à 64 dimensions pour le plus petit, et de 1 536 à 128 pour le plus grand.

Ces modèles prennent en charge la recherche asymétrique, pour cinq spécialisations par type de tâche, en utilisant une méthode de réglage par préfixe plutôt que des adaptateurs LoRA :

• Code vers code. Récupère du code similaire entre différents langages de programmation. Utilisé pour l’alignement de code, l’élimination des doublons, la migration et le refactoring.

• Langage naturel vers code. Permet de retrouver du code correspondant à une requête en langage naturel, un commentaire ou une description.

• Code vers langage naturel. Associe du code source à de la documentation ou à d’autres textes en langage naturel.

• Complétion de code à partir de code. Suggère du code pertinent pour compléter ou améliorer un extrait existant.

• Questions-réponses techniques. Fournit des réponses en langage naturel sur des sujets technologiques, idéal pour des cas d’usage liés à l’assistance technique.

Ces modèles offrent des performances supérieures pour les tâches portant sur la documentation technique et les ressources de développement, à un coût computationnel relativement faible. Ils s’intègrent facilement dans les environnements de développement et les assistants de programmation.

Jina ColBERT v2

jina-colbert-v2 est un modèle d’embedding multivecteur de 560 millions de paramètres. Il est multilingue, entraîné à partir de données couvrant 89 langues, et prend en charge les tailles d’embedding variables et la recherche asymétrique.

Comme mentionné précédemment, les plongements multivecteurs sont peu adaptés à l’indexation mais sont très utiles pour augmenter la précision des résultats d’autres stratégies de recherche. En utilisant jina-colbert-v2, vous pouvez calculer à l’avance les embeddings multivecteurs, puis les utiliser pour reclasser les candidats lors de la recherche, au moment de la requête. Cette méthode est moins précise que l’utilisation directe d’un modèle de reclassification, mais beaucoup plus efficace, car elle consiste uniquement à comparer les embeddings multivecteurs déjà stockés, sans faire appel au modèle d’IA à chaque requête ou comparaison de candidats. Elle est particulièrement adaptée aux cas d’usage où la latence et le coût de calcul d’un modèle de reclassification seraient trop élevés, ou lorsque le nombre de documents candidats est trop important.

Ce modèle produit une séquence d’embeddings, un par jeton d’entrée, et les utilisateurs peuvent choisir des embeddings de 128, 96 ou 64 dimensions. Les correspondances candidates sont limitées à 8 192 jetons. Les requêtes sont encodées de manière asymétrique, ce qui impose à l’utilisateur de spécifier si un texte est une requête ou une correspondance candidate, et de limiter la requête à 32 jetons.

Jina CLIP v2

jina-clip-v2 est un modèle d’embedding multimodal de 900 millions de paramètres, entraîné pour produire des embeddings proches entre un texte et une image décrivant le même contenu. Son usage principal est la recherche d’images à partir de requêtes textuelles, mais c’est aussi un modèle textuel performant. Il permet de réduire les coûts liés à la gestion de modèles distincts pour la recherche texte-texte et texte-image.

Ce modèle prend en charge un contexte d’entrée textuel de 8 192 jetons, et les images sont redimensionnées à 512 × 512 pixels avant génération des embeddings.

Les architectures CLIP (Contrastive Language–Image Pretraining) sont simples à entraîner, produisent des modèles compacts, mais présentent des limites structurelles importantes. Elles ne permettent pas de transférer la connaissance d’un support à un autre pour améliorer les performances. Elles ne peuvent pas utiliser un support pour améliorer leurs performances sur un autre. Ainsi, même si le modèle sait que les mots « chien » et « chat » sont plus proches en sens que ne l’est « voiture », il ne saura pas forcément qu’une image de chien est plus proche d’une image de chat qu’elle ne l’est d’une image de voiture.

Cependant, ce modèle souffre également d’un problème connu sous le nom de décalage de modalité : par exemple, un texte sur les chiens pourrait être plus proche, en termes d’embedding, d’un texte sur les chats que d’une image de chien. À cause de cette limitation, nous recommandons d’utiliser CLIP soit pour la recherche texte-image, soit comme modèle textuel seul, mais pas pour combiner les deux dans une même requête.

Modèles de reclassification

Les modèles de reclassification prennent une ou plusieurs correspondances candidates, ainsi qu’une requête en entrée, et les comparent directement, produisant ainsi des correspondances beaucoup plus précises.

En théorie, on pourrait utiliser un reranker directement pour la recherche d’informations, en comparant chaque requête à chaque document stocké, mais cela serait extrêmement coûteux en calcul et peu réaliste, sauf pour de très petites collections. En pratique, les rerankers sont donc surtout utilisés pour réévaluer des listes restreintes de correspondances candidates identifiées par d’autres moyens, comme une recherche par embeddings ou d’autres algorithmes de recherche. Les modèles de reclassification conviennent parfaitement aux architectures de recherche hybrides ou fédérées, où une requête peut être envoyée à plusieurs systèmes de recherche distincts, chacun interrogeant ses propres ensembles de données et retournant des résultats différents. Ils sont très efficaces pour fusionner des résultats hétérogènes en une seule réponse de haute qualité.

La recherche basée sur des embeddings peut représenter un engagement important : elle implique de réindexer toutes vos données stockées et de revoir les attentes des utilisateurs sur les résultats. L’ajout d’un reranker à une solution de recherche existante permet de bénéficier des avantages de l’IA sans avoir à réarchitecturer toute la solution.

Modèles de reclassification Jina

Jina Reranker m0

jina-reranker-m0 est un reclassificateur multimodal de 2,4 milliards de paramètres, qui prend en charge des requêtes textuelles et des candidats textuels et/ou visuels. C’est le modèle de référence pour la recherche documentaire visuelle, idéal pour interroger des bases contenant des PDF, captures d’écran, images modifiées ou documents semi-structurés, qu’ils soient textuels, visuels ou mixtes.

Ce modèle prend une requête et une correspondance candidate, et retourne un score. Lorsque la même requête est utilisée avec différents candidats, les scores sont comparables et peuvent être utilisés pour les classer. Il prend en charge une taille d’entrée totale allant jusqu’à 10 240 jetons, incluant la requête et le texte ou l’image candidat(e). Chaque bloc d’image de 28 × 28 pixels utilisé pour couvrir l’image compte comme un jeton pour le calcul de la taille d’entrée.

Jina Reranker v3

jina-reranker-v3 est un reclassificateur textuel de 600 millions de paramètres avec des performances de pointe pour sa taille. Contrairement à jina-reranker-m0, il traite une requête unique et une liste pouvant aller jusqu’à 64 candidats, puis renvoie leur ordre de classement. Il prend en charge un contexte d’entrée de 131  000 jetons, incluant la requête et tous les candidats.

Jina Reranker v2

jina-reranker-v2-base-multilingual est un modèle compact et polyvalent, intégrant des fonctionnalités supplémentaires comme le support de l’appel de fonction et des requêtes SQL. Pesant moins de 300 millions de paramètres, ce modèle offre un reclassement multilingue rapide, efficace et précis, avec un support supplémentaire pour la sélection de tables SQL et de fonctions externes associées aux requêtes textuelles, ce qui le rend adapté aux cas d’usage orientés agent.

Petits modèles de langage génératif

Les modèles de langage génératif sont des modèles comme ChatGPT d’OpenAI, Google Gemini et Claude d’Anthropic, qui acceptent des entrées textuelles ou multimédias et renvoient des sorties textuelles. Il n’existe pas de frontière claire entre les grands modèles de langage (LLM) et les petits modèles de langage (SLM), mais les difficultés pratiques liées au développement, à l’exploitation et à l’usage de LLM de pointe sont bien connues. Les modèles les plus connus ne sont pas distribués publiquement, donc nous ne pouvons qu’estimer leur taille : ChatGPT, Gemini et Claude seraient dans la fourchette des 1 à 3 milliards de milliards de paramètres (1–3×10¹²).

Exécuter ces modèles, même lorsqu’ils sont en accès libre, dépasse largement les capacités du matériel conventionnel et requiert les puces les plus avancées, organisées en réseaux massivement parallèles. Il est possible d’utiliser des LLM via des API payantes, mais cela implique des coûts importants, une forte latence, et pose des défis en matière de protection des données, de souveraineté numérique et de rapatriement hors du cloud. En outre, les coûts liés à l’entraînement et à la personnalisation de modèles de cette taille peuvent être conséquents.

C’est pourquoi de nombreuses recherches portent sur le développement de modèles plus petits qui, bien qu’ils n’offrent pas toutes les capacités des plus grands LLM, peuvent exécuter certaines tâches spécifiques avec une qualité équivalente et à moindre coût. Les entreprises déploient généralement des logiciels pour répondre à des besoins spécifiques, et les logiciels d’IA n’échappent pas à cette règle : les solutions basées sur des SLM sont souvent préférées aux LLM. Ils peuvent généralement être exécutés sur du matériel standard, sont plus rapides, consomment moins d’énergie et sont beaucoup plus faciles à personnaliser.

L’offre SLM de Jina se développe à mesure que nous cherchons à intégrer l’IA dans des solutions de recherche concrètes.

Jina SLMs

ReaderLM v2

ReaderLM-v2 est un modèle de langage génératif capable de convertir du HTML en Markdown ou en JSON, selon des schémas JSON fournis par l’utilisateur et des instructions en langage naturel.

Le prétraitement et la normalisation des données sont des étapes clés dans le développement de solutions de recherche performantes pour les données numériques, mais les données issues du web sont souvent désordonnées, et les stratégies simples de conversion montrent vite leurs limites. Au contraire, ReaderLM-v2 propose une solution d’IA intelligente, capable de comprendre le chaos d’un arbre DOM brut issu d’une page web, et d’identifier avec robustesse les éléments utiles.

Avec 1,5 milliard de paramètres (1,5 × 10⁹), ils sont mille fois plus compacts que les LLM de dernière génération tout en offrant des performances comparables sur des tâches ciblées.

Jina VLM

jina-vlm est un modèle de langage génératif de 2,4 milliards de paramètres (2,4×10⁹), conçu pour répondre à des questions en langage naturel à propos d’images. Il offre un excellent support pour l’analyse de documents visuels, c’est-à-dire la réponse à des questions sur des captures d’écran, des présentations, des schémas ou d’autres images non naturelles.

Par exemple :

Ils sont également très performants pour la lecture de texte dans des images:

Mais là où jina-vlm excelle vraiment, c'est dans la compréhension du contenu des images informatives et artificielles :

Ou :

jina-vlm Ils conviennent parfaitement pour la génération automatique de légendes, les descriptions de produits, les balises alt pour les images, et les applications d’accessibilité pour les personnes malvoyantes. Ils ouvrent aussi la voie à des systèmes RAG (retrieval-augmented generation) capables d’utiliser des données visuelles et de permettre à des agents d’IA de traiter des images sans intervention humaine.

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