Pour les nouveaux utilisateurs, c’est le moyen le plus rapide de mettre en place une recherche vectorielle de haute qualité. Si vous utilisez déjà Elasticsearch, la nouvelle offre permet de bénéficier de la recherche vectorielle sur la plateforme où se trouvent déjà vos données, sans aucun nouveau système à adopter. La base vectorielle Elasticsearch prend en charge divers scénarios, de l’ancrage d’un grand modèle de langage (LLM) à l’ajout de fonctionnalités de récupération et de mémoire pour un agent IA, en passant par le traitement de centaines de milliards de vecteurs. Lancez un nouveau projet et commencez en quelques minutes.

Un seul moteur pour tous les cas d'utilisation vectoriels

La base vectorielle Elasticsearch est conçue pour tous ceux qui créent des applications à l'aide de vecteurs :

• RAG : récupérez le contexte adapté pour votre LLM grâce à la récupération vectorielle dense et clairsemée, ou optez pour la recherche hybride combinant à la fois la récupération vectorielle et lexicale. La qualité de votre génération s’améliore avec la qualité de votre récupération.

• Agents IA : offrez aux agents une récupération rapide et filtrée des documents et de la mémoire conversationnelle, avec les faibles latences qu’exigent les boucles d’agents à étapes multiples.

• Recherche sémantique : faites correspondre selon le sens, et non par mots-clés, avec un seul type de champ et sans aucun code de pipeline.

• Recommandations et similarité : trouvez les plus proches voisins parmi des produits, des images ou tout autre contenu dont vous disposez, à grande échelle.

Tout ce dont votre charge de travail vectorielle a besoin, optimisé et prêt à l'emploi

Créer une application vectorielle implique de relier plusieurs éléments distincts : configurer et héberger des modèles d’embedding, indexer vos documents via ces modèles, stocker efficacement les vecteurs, appliquer le modèle d’embedding à chaque requête, effectuer des correspondances avec le stockage de vecteurs, et enfin, récupérer les documents correspondant aux résultats. La base vectorielle Elasticsearch gère tout cela pour vous, sans configuration ni paramétrage supplémentaire.

Indexation vectorielle avec le mode d’indexation vectordb_document

Le mode d’indexation vectordb_document, une nouvelle configuration d’index spécialement conçue pour les charges de travail axées sur les vecteurs, est activé par défaut, vous bénéficiez ainsi des paramètres que choisiraient des experts. Voici ce que cela active :

• bfloat16 par défaut : les vecteurs sont stockés à la moitié de la taille de float32 avec un impact négligeable sur le rappel, réduisant votre empreinte disque d’environ la moitié avant même que la quantification n’entre en jeu.

• Vecteurs sources exclus : dans Elasticsearch, vos plongements figurent déjà dans les structures d’index utilisées pour la recherche ; conserver une deuxième copie brute dans _source ne fait qu’augmenter le stockage et ralentir la récupération des résultats. Nous excluons le doublon afin que les réponses soient renvoyées plus rapidement et que vous stockiez moins.

• Les bons fichiers préchargés dans le cache : les structures de données auxquelles les requêtes vectorielles accèdent en premier sont préchauffées en mémoire à l’avance, de sorte que votre première (et votre millième) requête soit ultra-rapide.

• Fusion parallèle : la fusion regroupe les segments dans des structures vectorielles mieux organisées, ce qui améliore à la fois le rappel et la latence, et l’exécution de ces fusions en multithread vous permet d’y parvenir plus rapidement.

Stockage vectoriel, compression et optimisation automatique

• Vos vecteurs sont compressés automatiquement. La quantification binaire optimisée (BBQ) réduit l’empreinte mémoire des vecteurs jusqu’à 32 fois tout en préservant le rappel, et DiskBBQ réduit encore davantage les besoins en mémoire pour les charges de travail à grande échelle. 

• Optez pour l’auto-étalonnage, qui ajuste la quantification de chaque segment en fonction de vos données et la réajuste à chaque fusion à mesure que les données dérivent. Lors des tests sur 18 ensembles de données, le nombre de requêtes par seconde (QPS) s’est amélioré en moyenne de 16,7 %, avec des gains de rappel pour la plupart d’entre eux.

Embeddings sur une inférence GPU gérée

• Générez des embeddings grâce aux modèles natifs d’embedding et de reclassement de Jina AI, ou importez des modèles tiers, le tout sur des GPU gérés via Elastic Inference Service (EIS), sans aucun serveur de modèles à gérer. Ou optez pour l’auto-hébergement, si vous préférez votre propre infrastructure.

• Le type de champ semantic_text gère automatiquement la segmentation et l’embedding, ainsi que l’interrogation, ce qui représente la voie la plus simple vers la recherche sémantique sur le marché. 

Recherche hybride et recherche vectorielle filtrée

• La recherche hybride est intégrée, combinant la récupération en texte intégral et vectorielle dans une seule requête. Combinez les résultats grâce à la fusion des rangs réciproques (RRF) ou à tout autre mécanisme de combinaison de votre choix. La recherche vectorielle est généralement la partie de la recherche hybride la plus difficile à bien configurer. Avec la base vectorielle Elasticsearch, vous maîtrisez la situation et l’ensemble de votre stack hybride s’améliore. 

• Avec la recherche vectorielle filtrée, appliquez des filtres de métadonnées dans le cadre même de la récupération vectorielle, et non après coup, ce qui dégrade le rappel.

Entreprise dès le premier jour

Vous bénéficiez également du contrôle d’accès basé sur les rôles (RBAC), du logging d’audit, et des certifications de conformité qui font généralement défaut aux bases vectorielles pure-play.

Abordable à grande échelle et prévisible

La base vectorielle Elasticsearch est conçue pour rester abordable à mesure de votre croissance : les compressions BBQ et DiskBBQ, qui maintiennent un stockage linéaire et une faible utilisation de la mémoire, permettent un scaling vers des centaines de milliards de vecteurs sans faire exploser votre facture. Et ce que vous payez est basé sur des chiffres que vous connaissez déjà : la quantité de données que vous stockez, ce que vous indexez, ainsi que la capacité de recherche dont vous avez besoin. Estimez votre nombre de documents et les dimensions de vos vecteurs, ainsi que votre charge de requêtes, et vous pourrez déterminer ce que vous paierez avant de créer le projet. Vous pouvez également comprendre votre facture ligne par ligne à la fin du mois. Il n’y a pas d’unités de calcul opaques, ni de frais imprévus pour les opérations en arrière-plan.

Comment démarrer avec la base vectorielle Elasticsearch

Créez un projet de Base vectorielle sans serveur

Créez un nouveau projet de base vectorielle sans serveur dans Elastic Cloud. Dirigez vos données vers le point de terminaison, et vous êtes prêt à indexer.

Créer un index à l’aide de semantic_text

Le mode d’index vectoriel gère la configuration vectorielle. L’utilisation de semantic_text signifie que la configuration des embeddings et du chunking est gérée pour vous, tout comme la configuration de l’index, sur une inférence GPU gérée, sans aucun pipeline d’embedding à créer.

Ingérer des documents

Indexez du texte, et les embeddings sont générés pour vous.

Exécuter une requête de recherche sémantique

Interrogez le même champ sémantique que vous venez de créer :

Et vous obtenez des résultats :

La recherche sémantique n’est qu’un début. Exécutez des requêtes entièrement textuelles ou combinez les deux dans des requêtes hybrides. Vous pouvez même créer vos propres requêtes vectorielles pour bénéficier d’un contrôle total. Suivez le guide de démarrage rapide de la recherche sémantique dans la documentation pour obtenir toutes les instructions.

Quelle est la suite pour la recherche vectorielle dans Elasticsearch

Nous travaillons déjà sur les prochaines améliorations :

• Meilleure prise en charge de la mutualisation : si vos données doivent rester séparées par entité, nous vous donnons les moyens de le faire plus rapidement et avec moins de code.

• Optimisation automatique des index : d’un « tout nouvel index » à « entièrement optimisé », avec le moins d’ajustements possible.

• Améliorations continues de l’infrastructure : ajustement continu des paramètres et de l’infrastructure de la base vectorielle afin que vous bénéficiiez toujours du meilleur débit et des réponses les plus rapides.

Essayez la base vectorielle Elasticsearch sur Elastic Cloud Serverless

Passez d’un projet vide à une requête vectorielle hybride et filtrée en quelques minutes, avec des réglages par défaut prêts pour la production qui s’ajustent pour vous. Créez des applications d'IA rapides et scalables, pas de l'infrastructure.

Commencez sur Elastic Cloud Serverless, ou plongez dans la documentation complète et la référence de l’API.

Elastic Cloud Serverless vous permet déjà de gérer les mises à niveau de l’infrastructure et des versions. CPS va encore plus loin. Nous avons remplacé le peering réseau complexe et la gestion manuelle des certificats par un modèle simple de liaison. Désormais, vous pouvez considérer vos projets Elastic Cloud Serverless comme de simples espaces de noms pour vos données. Que vous soyez confronté à des lois strictes sur la résidence des données, à l’isolation des données des locataires ou que vous cherchiez simplement à éviter les frais de sortie réseau exorbitants liés à la duplication des logs, CPS vous permet de rechercher vos données exactement là où elles se trouvent en une seule requête.

Dans cet article, nous verrons comment fonctionne le CPS, comment contrôler les recherches à l’aide de balises de projet et en quoi ce nouveau modèle diffère de la recherche cross-cluster (CCS) traditionnelle.

Comment relier des projets pour une recherche inter-projets

Pour commencer à utiliser la recherche inter-projets, reliez les projets dans la console Elastic Cloud ou dans l’API. La liaison est simple et unidirectionnelle : choisissez un projet d’origine, puis connectez les projets dans laquelle la recherche doit s’effectuer. Ces liens peuvent porter sur plusieurs pays, fournisseurs cloud et types de projets, afin que vos données restent là où elles doivent être, sans pour autant renoncer à une expérience de recherche unifiée.

Une fois le lien créé, il prend généralement effet en une minute environ. Si vous avez déjà Kibana ouvert, actualisez pour voir les nouvelles fonctionnalités de recherche inter-projets.

Comment la recherche inter-projets interroge tous les projets liés par défaut

Une fois les projets liés, la recherche inter-projets transforme des projets séparés en une seule surface logique de recherche. Si vos logs concernent plusieurs projets, une requête comme FROM logs* permet de rechercher le projet d’origine et tout projet lié contenant des données correspondantes. Vous n’avez pas besoin de nommer chaque cible distante à l’avance.

C’est une amélioration majeure par rapport à la recherche inter-clusters. Dans CCS, pour accéder à des données locales et distantes, il faut souvent écrire ce type de code : FROM logs*,*:logs*. Pour les utilisateurs, cela signifie une moindre complexité des requêtes. Pour les équipes, cela nous rapproche d’un véritable tableau de bord unique à travers des données distribuées.

Pour plus d’informations concernant ce sujet, consultez la documentation du modèle de recherche CPS .

Si vous souhaitez obtenir des détails techniques sur la façon dont nous avons construit ce système, consultez Comment la recherche inter-projets (CPS) fonctionne dans Elasticsearch Serverless.

Contrôle des recherches via le routage de projet

La recherche par défaut dans tous les projets liés est pratique et utile pour de nombreux workflows, mais toutes les recherches ne doivent pas nécessairement s’étendre à l’ensemble. La recherche inter-projets introduit le routage de projets, qui permet de limiter une requête à un sous-ensemble spécifique de projets.

Il fonctionne grâce aux balises de projet définies dans Elastic Cloud. Chaque projet possède des attributs intégrés tels que son alias, son fournisseur cloud et sa région. Vous pouvez également ajouter vos propres tags pour refléter la façon dont votre organisation perçoit son domaine, comme environment:prod, environment:test, une unité commerciale ou un nom client. Elasticsearch peut alors utiliser ces métadonnées pour décider quels projets liés doivent participer à une rechercher.

Tous les endpoints Elasticsearch qui prennent en charge la recherche inter-projets acceptent un paramètre project_routing. Dans l’aperçu technique, le routage est limité à l’utilisation d’alias de projet. Par exemple, si vous attribuez à project_routing la valeur _alias:my-linked-project, la requête est envoyée uniquement au projet lié, tandis que _alias:_origin maintient la requête sur le projet d’origine. Au fil du temps, ce modèle ouvre la porte à un routage beaucoup plus riche, où la portée de la recherche peut suivre la structure logique de votre organisation au lieu de la disposition physique de votre infrastructure.

Consultez les documents de routage du projet pour obtenir des exemples et plus de détails sur leur fonctionnement.

Routage par défaut de projet au niveau spatial Kibana

Par exemple, lorsque vous avez besoin de plus de précision pour le routage de recherche, la recherche dans tous les projets liés peut déclencher une multitude de faux positifs dans vos règles Kibana ou des résultats déroutants dans vos tableaux de bord existants. Pour corriger cela, vous pouvez définir une portée de projet par défaut au niveau spatial dans Kibana. Il s’agit d’un préréglage sûr pour cet espace spécifique pour que tous les tableaux de bord, les sessions Discover et les règles d’alerting le respectent automatiquement. Les analystes peuvent toujours modifier manuellement la portée pendant une investigation s’ils ont besoin d’une vue plus large.

Cela est important pour les équipes partageant un projet central, telles que les MSP, les MSSP et les centres d’excellence : vous pouvez attribuer à chaque équipe son propre espace Kibana et le limiter à l’interrogation de leurs projets clients spécifiques, garantissant ainsi des expériences adaptées à chaque locataire. Les analystes peuvent toujours modifier manuellement la portée pendant une investigation s’ils ont besoin d’une vue plus large.

Vous pouvez configurer cet espace par défaut avant ou après avoir lié vos projets dans l’interface utilisateur du cloud. Mais comme CPS active immédiatement le comportement « rechercher tout » dès qu’un lien est créé, il est recommandé de définir d’abord les paramètres par défaut Kibana pour garantir que vos règles de détection existantes ne se retrouvent pas soudainement sur un immense ensemble de données globales et ne submergent pas votre équipe.

Utilisation des balises dans les recherches

En plus d’utiliser des balises pour le routage des projets, vous pouvez également utiliser des balises dans vos requêtes ES|QL et _search. Cela peut être utile pour identifier la provenance de chaque enregistrement ou ligne d’un ensemble de résultats, ou pour trier, filtrer ou agréger par ces balises.

Par exemple, si vous souhaitez savoir de quel projet provient chaque ligne d’une réponse ES|QL, vous pouvez ajouter la balise _project._alias à la requête ES|QL :

et cela vous permet d’utiliser _project._alias dans d’autres parties de la requête, y compris les clauses KEEP, afin de le voir dans le résultat final :

Pour plus d’exemples d’utilisation des balises dans les requêtes, consultez ce document qui décrit comment les utiliser à la fois dans les API de recherche et en ES|QL.

Si vous souhaitez en savoir plus sur les détails techniques concernant l’ajout de balises à Search et aux requêtes ES|QL, consultez Recherche inter-projets plus rapide dans Elasticsearch Serverless avec balises de projet et routage.

Comment la recherche inter-projets gère les projets d’origine et les projets liés de manière égale

Si vous avez utilisé CCS, vous savez peut-être que le cluster local est traité différemment des clusters distants à plusieurs égards.

• Les erreurs provenant du cluster local sont traitées différemment de celles provenant de clusters distants. En particulier, CCS utilise le paramètre skip_unavailable pour contrôler le comportement des erreurs provenant de clusters distants, mais ce paramètre n’existe pas pour le cluster local.

• Le cluster local n’a pas d’« alias de cluster », donc l’expression d’indice *:logs* recherche tous les projets distants, mais saute le cluster local. Pour rechercher les deux, il faut utiliser l’expression d’indice logs*,*:logs*.

Dans CPS, nous avons modifié ces deux comportements pour mettre le projet d’origine et les projets liés sur un pied d’égalité.

Premièrement, le paramètre skip_unavailable n’est pas utilisé dans Elastic Cloud Serverless. C’est vous qui décidez si vous souhaitez obtenir des résultats partiels lors d’une recherche via le paramètre allow_partial_search_results dans _search ou _async_search ou le paramètre allow_partial_results dans ES|QL.

Deuxièmement, dans Elastic Cloud Serverless, le projet d’origine a un alias de projet. Il est défini dans Elastic Cloud comme toutes les balises de projet. Ainsi, dans CPS, toutes les requêtes ci-dessous sont équivalentes, elles ciblent tous les projets avec un index « logs » :

Remarque : il existe une différence importante entre l’expression qualifiée *:logs et l’expression non qualifiée logs en ce qui concerne la gestion des erreurs liées aux indices manquants. Pour plus de détails, consultez la rubrique consacrée aux expressions de recherche non qualifiées et qualifiées dans la documentation publique.

Modèle de contrôle d’accès et de sécurité pour la recherche inter-projets

Elastic a créé un nouveau modèle de sécurité basé sur le cloud, Universal Identity and Access Management (UIAM), qui permet un principe clé pour la recherche inter-projets : les projets et les données auxquels vous pouvez accéder ne dépendent pas de l’endroit où vous y accédez.

Que vous lanciez une recherche à partir de votre projet principal d’observabilité ou d’un projet d’analyse ponctuel, votre accès aux données associées reste le même, puisque les droits d’accès ont été définis de manière centralisée. Le modèle d’authentification et d’autorisation basé sur le cloud utilise le service cloud UIAM pour garantir que vos autorisations d’accès sont uniformes, quel que soit le projet d’origine.

Essayez la recherche inter-projets

Finalement, Elastic Cloud Serverless et CPS permettent ensemble de réduire les difficultés opérationnelles et vous offrent des solutions supplémentaires pour organiser les données en fonction de critères logiques plutôt que physiques ou opérationnelles. La recherche inter-projets permet à vos utilisateurs de se concentrer uniquement sur l’organisation logique de leurs données, offrant ainsi une expérience de recherche unifiée sans les complexités physiques du passé.

Aujourd’hui, tout devient beaucoup plus simple. Les clés API Elastic Cloud peuvent désormais être utilisées pour s’authentifier directement auprès des API Elasticsearch et Kibana dans Elastic Cloud Serverless. Vous pouvez désormais utiliser un seul identifiant pour gérer les ressources de votre organisation et exécuter des opérations sur les données, comme des requêtes Elasticsearch Query Language (ES|QL), l’ingestion de données et l’alerting.

Voyons pourquoi nous avons conçu cette solution, comment nous avons mis en place une couche d’identité distribuée à l’échelle mondiale pour la rendre possible, et comment elle pose les bases d’une recherche interprojets.

Le fardeau de la gestion des secrets

Mettre en place des pipelines CI/CD fiables, des workflows GitOps ou une automatisation Terraform autour des plateformes de données a un coût caché : la prolifération des secrets.

Dans le modèle précédent, les développeurs étaient confrontés à une gestion de l’authentification fragmentée :

• Plan de contrôle (clés API Elastic Cloud) : clés au périmètre de l’organisation utilisées pour créer des projets, inviter des utilisateurs et gérer la facturation via l’API Elastic Cloud.

• Plan de données (clés API Elasticsearch) : Clés de portée projet créées à l'intérieur d'un projet Serverless spécifique pour interagir avec Elasticsearch et Kibana API.

Cela signifiait que votre script de déploiement devait s’authentifier auprès d’Elastic Cloud, provisionner un projet Serverless, extraire une clé API Elasticsearch nouvellement générée depuis ce projet, puis injecter cette seconde clé dans l’application en aval ou l’outil d’automatisation, ce qui entraînait des pipelines complexes, des journaux d’audit fragmentés et un risque accru de fuite d’identifiants.

Authentification unifiée dans Elastic Cloud Serverless

Avec cette version, cette séparation disparaît pour les projets Serverless. Vous pouvez désormais créer une clé API Elastic Cloud explicitement autorisée pour les API Cloud, Elasticsearch et Kibana.

• Avant : une clé API Elastic Cloud était strictement un jeton du plan de contrôle. Elle permettait de créer des projets, de gérer la facturation et d’inviter des utilisateurs, mais présentait une limite stricte : elle ne pouvait pas être utilisée pour appeler les API Elasticsearch ou Kibana au sein de ces projets. Vous aviez toujours besoin d’une seconde clé, spécifique au projet, pour les opérations sur les données.

• Maintenant : en optant pour l'accès aux API Cloud, Elasticsearch et Kibana lors de la création d'une clé API Elastic Cloud, la limite stricte est supprimée pour Serverless. Cette clé API devient un véritable identifiant unifié. Il conserve sa capacité à gérer l'infrastructure de votre organisation, tout en bénéficiant d'un accès natif pour interroger, ingérer et analyser les données de tout projet Serverless autorisé.

En unifiant cela avec une seule clé API Elastic Cloud, vous disposez d’une identité unique pouvant être définie par périmètre, auditée, renouvelée et révoquée comme une seule entité. Chaque appel API, qu’il serve à provisionner un nouveau projet ou à exécuter une requête ES|QL, apparaît sous le même identifiant dans vos journaux d’audit, vous offrant une trace unique à suivre lors des enquêtes d’incident ou des audits de conformité. La rotation des identifiants devient une opération en une seule étape, au lieu d’une mise à jour coordonnée entre les secrets du plan de contrôle et du plan de données. Et comme les rôles sont attribués par projet, une seule clé peut couvrir plusieurs projets : gérer l’ingestion dans votre projet d’observabilité et exécuter des requêtes dans votre projet de sécurité, sans avoir à manipuler des identifiants distincts pour chacun.

Il est important de noter qu' unifié ne signifie pas tout-puissant. En utilisant le payload role_assignments, vous pouvez restreindre la portée d'une clé unifiée à un seul projet et à un rôle spécifique (lecture seule, par exemple), ce qui garantit que le rayon d'impact reste totalement contenu si un identifiant est exposé. En cas de départ d'un développeur ou de mise hors service d'une application, vous pouvez révoquer une seule clé depuis la console Elastic Cloud, ce qui met immédiatement fin à l'accès à la fois au plan de contrôle et à tous les projets Elasticsearch associés.

(Remarque : pour les déploiements Elastic Cloud Hosted/gérés, les clés API Cloud ne gèrent toujours que le plan de contrôle.) La prise en charge de l’extension aux API de la stack hébergée est prévue dans une prochaine version.)

Automatiser vos workflows

La mise en route est simple. Vous pouvez configurer cela entièrement via la console Elastic Cloud ou l'automatiser en utilisant l'API Elastic Cloud.

Le processus de l'interface utilisateur reste le même, mais vous pouvez désormais sélectionner l'accès aux API Cloud, Elasticsearch et Kibana dans l'affectation des rôles du projet.

Voici comment créer une clé unifiée de façon programmatique en utilisant l’API Elastic Cloud. Notez le tableau application_roles, car c’est ce qui donne à la clé un accès natif au plan de données Elasticsearch :

Une fois créée, il vous suffit de transmettre exactement la même clé dans l'en-tête Authorization: ApiKey à api.elastic-cloud.com et à vos points de terminaison Elasticsearch Serverless spécifiques.

En coulisses : conception d’une couche d’identité distribuée

Faire fonctionner une clé API Cloud à la fois sur le plan de contrôle et sur le plan de données ne se résume pas à transmettre un jeton. Cela nécessite de résoudre un défi fondamental des systèmes distribués.

Historiquement, les clés API Cloud étaient stockées dans un cluster de sécurité global centralisé. Cela fonctionne bien pour les opérations du plan de contrôle, où une latence plus élevée est acceptable. Cependant, les requêtes de données Elasticsearch nécessitent une latence extrêmement faible. Nous ne pouvons pas nous permettre un aller-retour à travers le globe vers un plan de contrôle central pour valider chaque requête de recherche ou d’ingestion.

Pour résoudre ce problème, nous avons introduit une nouvelle architecture d’authentification reposant sur un datastore distribué à l’échelle mondiale. Le diagramme de séquence suivant montre un client envoyant une requête Elasticsearch à l’aide d’une clé API Elastic Cloud, illustrant comment l’authentification s’effectue entièrement dans la région locale, sans aller-retour vers le plan de contrôle global. Elasticsearch délègue l’authentification au service IAM régional, qui valide la clé et résout ses attributions de rôles à partir d’une réplique locale de la base de données distribuée à l’échelle mondiale. Une fois autorisé, Elasticsearch exécute la requête et renvoie les résultats au client.

Persistance distribuée à l’échelle mondiale

Au lieu de s’appuyer uniquement sur un cluster de sécurité centralisé, les clés API Elastic Cloud et leurs définitions de rôles associées sont désormais stockées dans une base de données distribuée à l’échelle mondiale et hautement disponible. Cette base de données synchronise les données de gestion des identités et des accès (IAM) entre le plan de contrôle global et les plans de données régionaux où vos projets Serverless s’exécutent réellement.

Validation locale avec IAM régional

Lorsque votre client envoie une requête à Elasticsearch à l’aide d’une clé API Elastic Cloud, la requête ne revient pas vers le plan de contrôle global. Elle est plutôt redirigée vers le nouveau service IAM régional. Celui-ci valide la clé à partir de la réplique locale de la base de données, garantissant une authentification avec une latence quasi nulle et totalement isolée des pannes du plan de contrôle global.

Mappage dynamique des rôles

L'authentification n'est que la moitié de la bataille ; le système doit également autoriser la demande. Le service IAM régional traduit instantanément vos attributions de rôles au niveau du cloud (par exemple, application_roles) en privilèges Elasticsearch natifs. Elasticsearch peut alors autoriser et exécuter la requête localement, sans jamais avoir besoin d’un index .security local.

La base de la recherche interprojets

Cette architecture d'identité distribuée est un élément fondamental pour l'avenir de la plateforme Elastic.

L'identité et l'accès étant désormais unifiés et synchronisés à l'échelle mondiale, nous disposons du framework nécessaire pour transmettre votre identité en toute sécurité entre différents projets. Cela permet d'activer les capacités de recherche inter-projets (CPS) à venir pour Serverless.

Avec CPS, vous pourrez interroger des données couvrant plusieurs projets Serverless distants, par exemple en combinant des charges de travail de sécurité et d’observabilité, aussi simplement que s’il s’agissait d’un seul jeu de données. En s’appuyant sur des clés API unifiées, le système peut automatiquement évaluer vos autorisations sur l’ensemble des projets simultanément, sans vous obliger à configurer des relations de confiance complexes, des certificats ou des identifiants dupliqués pour chaque projet cible.

En savoir plus

Êtes-vous prêt à simplifier votre stack ?

• Lisez la documentation sur les clés API d'Elastic Cloud pour savoir comment attribuer l'accès à la pile.

• Consultez la référence Create API key (Elastic Cloud API) pour automatiser la génération de clés.

• Consultez les clés API Elastic pour une comparaison complète des types de clés sur la plateforme Elastic.

Commencez ou continuez à construire dans Elastic Cloud dès aujourd’hui.

Avis de non-responsabilité

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

La soirée commence à s'animer

Vous organisez une fête de pizza. Vous avez quelques amis qui vous aident à servir, chacun posté à différents endroits dans la pièce. Vous offrez une pizza à chaque ami, et ils commencent à distribuer des tranches aux clients affamés à leur arrivée.

Au début, tout se passe bien. Les invités arrivent au compte-gouttes, vos amis servent des parts de pizza, tout le monde est content. Mais bientôt, la nouvelle de vos pizzas au levain se répand. On n'arrête pas de sonner à la porte. Les invités affluent. Très vite, une foule se forme autour de l'un de vos amis, celui qui tient la pizza pepperoni que tout le monde semble vouloir.

Votre ami avec la pizza au pepperoni est débordé. Les clients attendent, deviennent impatients et une longue file d'attente s'est formée. Pendant ce temps, votre ami avec la pizza margherita reste debout et presque personne ne lui demande une part.

Que faire ?

Vous commandez encore deux pizzas pepperoni et vous en distribuez à d'autres amis. Maintenant, trois amis ont de la pizza pepperoni au lieu d'un seul. La foule se disperse, et, tout à coup, vous pouvez servir trois fois plus d'invités à la fois.

Certains éléments deviennent clairs à mesure que vous organisez des fêtes :

• Les pizzas n'ont pas toutes le même succès. Certaines sont très demandées, d'autres moins. Inutile de prévoir des "exemplaires" supplémentaires de celles qui sont peu appréciées. Il vous faut davantage de celles qui attirent les foules.

• Commandez d'autres pizzas avant que la file d'attente ne devienne trop longue. Si vous attendez que votre ami soit complètement dépassé et que les invités partent mécontents, vous avez attendu trop longtemps. Mieux vaut commander une pizza supplémentaire quand vous voyez une foule se former.

• Ne jetez pas les pizzas trop vite. Ce n'est pas parce que la foule autour de la pizza pepperoni s'est clairsemée pendant cinq minutes que l'affluence est terminée. Peut-être sont-ils simplement en train de se resservir à boire, ou même de discuter entre eux (est-ce que ça se fait encore ?). Prévoyez des pizzas supplémentaires. Si l'accalmie se prolonge, vous pourrez les mettre de côté.

• Vous ne pouvez distribuer autant de pizzas que vous avez d'amis qui vous aident. Si vous n'avez que quatre amis pour vous aider, dix pizzas ne changeront rien au résultat. Seules quatre peuvent être servies à la fois. Adaptez le nombre de pizzas à vos serveurs disponibles.

• Quand un ami s'en va, prenez sa pizza. Si l'un de vos amis doit partir, prenez sa pizza immédiatement. Vous ne pouvez pas laisser les pizzas sans surveillance. Donnez-la à quelqu'un d'autre, ou mettez-la de côté.

Des pizzas aux répliques

Faisons le lien avec Elasticsearch.

Dans notre analogie, les pizzas sont des répliques (copies de vos shards d'index), vos amis qui aident à servir sont des nœuds de recherche, les invités affamés sont des requêtes de recherche, et cette pizza très prisée autour de laquelle se presse la foule correspond à un index très sollicité (hot) avec une charge de recherche élevée.

Lorsque le trafic de recherche augmente sur un indice donné, nous créons des répliques supplémentaires et les distribuons sur vos nœuds de recherche. Toute réplique peut traiter n'importe quelle requête pour cet index, tout comme un ami tenant une pizza pepperoni peut en distribuer des parts. Plus de répliques signifie un débit plus élevé : trois répliques peuvent traiter trois fois plus de requêtes par seconde qu'une seule réplique.

Mesurer la faim

Avant de décider du nombre de pizzas à commander, nous devons connaître l'appétit de la foule.

Elasticsearch suit la charge de recherche pour chaque partition. Cet indicateur mesure l'activité de recherche gérée par une partition. Nous agrégeons ces données pour l'ensemble des partitions d'un index afin d'appréhender la demande de recherche totale.

Ce qui importe le plus, c'est la charge de recherche relative : quelle proportion du trafic de recherche total de votre projet est allouée à chaque index ? Si un index reçoit 60 % des recherches tandis qu'un autre n'en reçoit que 5 %, nous savons où augmenter la capacité.

Les mathématiques derrière les pizzas

Nous calculons le nombre optimal de répliques en suivant cette formule :

Où :

• L = la charge de recherche relative de l'index (entre 0 et 1).

• N = le nombre de nœuds de recherche souhaités dans votre projet.

• S = le nombre de partitions dans l'index.

• X = un seuil pour éviter les points chauds (0,5 par défaut).

Un exemple : quatre nœuds de recherche, un index avec deux shards primaires recevant 80 % du trafic de recherche :

Cet index hot obtient quatre répliques réparties sur les nœuds de recherche.

Le seuil X (0,5 par défaut) est important. Nous n'attendons pas qu'une réplique soit complètement saturée ; nous augmentons la capacité lorsqu'elle en est à la moitié. Distribuez les pizzas supplémentaires dès que vous voyez le monde arriver, et non lorsque les clients sont déjà partis.

Augmenter la capacité rapidement, la réduire lentement

Lorsque la charge de recherche augmente, nous ajoutons immédiatement des répliques. Inutile de faire attendre les utilisateurs.

Lorsque la charge de recherche diminue, nous attendons un peu avant d'agir. Nous devons observer une faible demande stable pendant environ 30 minutes avant de réduire le nombre de répliques. (Ceci afin de gérer les pics de trafic, où une période d'accalmie ne signifie pas que la charge est terminée.)

C'est important, car l'ajout d'une réplique a un coût. La nouvelle réplique copie les données et initialise ses caches avant de traiter efficacement les requêtes. Supprimer des répliques trop rapidement signifie payer constamment ce coût initial, car le trafic fluctue naturellement.

Respecter les limites de la topologie

Le nombre de répliques ne peut jamais dépasser le nombre de nœuds de recherche. Avoir plus de répliques que de nœuds n'apporte aucun avantage (vous ne pouvez servir qu'autant de pizzas que vous avez d'amis qui vous aident à en servir des parts).

Lorsque des nœuds sont retirés de votre projet, nous réduisons immédiatement le nombre de répliques en conséquence. Pas besoin d'attendre la fin du cooldown, car il ne peut y avoir de répliques non attribuées. Dès qu'un ami s'en va, nous retirons sa part.

Une vision plus globale du Serverless

Les répliques pour l'équilibrage de charge de recherche fonctionnent de pair avec d'autres systèmes d'autoscaling :

• L'autoscaling de la recherche ajuste le nombre de nœuds de recherche (combien d'amis aident).

• Les répliques pour l'équilibrage de la charge de recherche distribuent le trafic en ajustant le nombre de répliques par index (le nombre de pizzas de chaque type dont nous avons besoin).

• Le partitionnement automatique du flux de données optimise le nombre de partitions pour les écritures (comment découper chaque pizza, abordé dans l'article précédent).

Un principe de conception important : les répliques pour l'équilibrage de charge ne déclenchent pas directement l'autoscaling de la recherche. En répartissant les requêtes de recherche sur un plus grand nombre de répliques, nous pouvons augmenter l'utilisation des ressources sur l'ensemble de vos nœuds de recherche. Cette utilisation accrue active ensuite notre logique d'autoscaling existante afin d'ajouter de la capacité si nécessaire. Les répliques pour l'équilibrage de charge permettent à l'autoscaling de remplir sa fonction, en garantissant que vos nœuds de recherche sont effectivement utilisés, au lieu de voir tout le trafic se concentrer sur une seule réplique tandis que les autres nœuds restent inactifs.

Ce que cela signifie pour vous

Vous n'avez pas besoin de prédire quels index seront les plus sollicités. Vous n'avez pas besoin d'ajuster manuellement les répliques lorsque les schémas de trafic changent. Vous n'avez pas besoin de vous réveiller à 3 heures du matin parce qu'un pic de trafic a saturé votre index le plus sollicité.

Le système surveille les zones d'affluence et commande des pizzas supplémentaires pour ces zones. Les index peu sollicités ne gaspillent pas de ressources en répliques inutiles. Les index très sollicités obtiennent la capacité dont ils ont besoin. Votre budget est ainsi investi là où c'est le plus important.

Conclusion

Dans l'article sur le partitionnement automatique, nous avons veillé à ce que vos pizzas soient découpées correctement. Désormais, grâce aux répliques pour l'équilibrage de charge de recherche, nous nous assurons que vous ayez suffisamment de pizzas, entre de bonnes mains, lorsque la foule affamée arrive.

Essayez Elastic Cloud Serverless et laissez-nous nous occuper la logistique des pizzas.

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

Fonctionnalités principales d'Agent Builder

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

Agent Builder vous permet de :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Votre agent, vos règles

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

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

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

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

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

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

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

Que pouvez-vous construire ?

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

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

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

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

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

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

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

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

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

Nous avons effectué une mise à niveau majeure de l'infrastructure pour tous les projets Elastic Cloud Serverless exécutés sur AWS, en migrant vers du matériel plus récent et plus performant. Cette modification a été déployée automatiquement sur tous les projets sans serveur. Vous bénéficiez maintenant d'un débit plus élevé et d'une latence plus faible pour les projets sans serveur Elasticsearch, Elastic Observability et Elastic Security sur AWS.

Principaux avantages en termes de performances pour les développeurs

La nouvelle infrastructure matérielle d'AWS sous-tend tout ce que vous faites avec Elastic Cloud Serverless, ce qui se traduit par des avantages tangibles au niveau de la vitesse et de la réactivité de vos applications.

Latence des requêtes réduite… débit accru

Le matériel amélioré augmente considérablement la vitesse des ressources de calcul ; vos requêtes de recherche sont ainsi traitées plus rapidement que jamais.

• Recherche et recherche vectorielle : que vous exécutiez des recherches full text traditionnelles ou que vous utilisiez la recherche vectorielle de pointe pour vos applications d'IA générative et de génération augmentée par récupération (RAG), vous constaterez une diminution notable de la latence. Une analyse comparative interne a révélé une diminution moyenne de 35 % de la latence de recherche.

• Indexation plus rapide : les taux d'ingestion de données sont optimisés, vous permettant d'indexer d'énormes volumes de données et des documents complexes avec un débit accru. Ceci est crucial pour les applications qui nécessitent une visibilité des données en temps quasi‑réel. L'évaluation comparative interne a montré une augmentation moyenne de 26 % du débit d'indexation.

Performances constantes sous charge

Elastic Cloud Serverless est conçu pour s'adapter automatiquement et dynamiquement en temps réel à la demande, minimisant ainsi la latence, quelle que soit votre charge de travail. Grâce à cette amélioration matérielle, le scaling est désormais plus performant et réactif.

• Gestion facile des pics de charge : qu'il s'agisse d'une augmentation soudaine du trafic utilisateur ou d'une ingestion massive de données par lots, la nouvelle infrastructure garantit un scaling vertical plus efficace sur vos ressources de recherche et d'indexation afin de maintenir une latence faible de façon constante.

• Découplage optimisé calcul‑stockage : l'architecture sans serveur sépare le calcul et le stockage, ce qui permet aux charges de travail de scaler indépendamment pour des performances et une rentabilité optimales. Le matériel plus rapide améliore la couche de calcul, maximisant l'efficacité de cette conception découplée.

Sous le capot : résultats des analyses comparatives internes

Pour quantifier l'impact de la mise à niveau de notre infrastructure AWS, l'équipe d'ingénierie d'Elastic a mené des tests de performance internes complets sur un large éventail de charges de travail sans serveur. Ces charges de travail ont fourni des preuves concrètes des améliorations de performances que vous pouvez attendre de vos applications, quel que soit votre cas d'utilisation.

L'approche d'analyse comparative

Nous avons concentré nos tests sur les indicateurs clés qui influencent directement l'expérience développeur et la réactivité des applications : le temps de réponse (c'est-à-dire la latence) et le débit lors des opérations de recherche et d'indexation.

• Test des charges de travail : les tests comprenaient des opérations de recherche à haute simultanéité typiques des applications destinées aux utilisateurs, des requêtes de recherche vectorielle complexes et l'ingestion/l'indexation de données à fort volume pour des cas d'utilisation d'observabilité et de sécurité. Plus précisément, notre méthodologie de test a utilisé des ensembles de données accessibles au public pour Rally, l'outil d'évaluation comparative d'Elastic.

  • wikipedia: Un ensemble de données issu d'un instantané du contenu textuel de Wikipédia, pour mesurer les performances de recherche textuelle à usage général.

  • MSMARCO-Passage-Ranking: Un ensemble de données issu de Microsoft Machine Reading Comprehension (MS MARCO), pour mesurer les performances de recherche sur des champs vectoriels épars.

  • OpenAI_Vector: Un ensemble de données issu du NQ de BEIR et enrichi d'embeddings générés par le modèle text-embedding-ada-002 d'OpenAI, pour évaluer les performances de recherche sur des champs vectoriels denses.

• Mesure : nous avons comparé les performances de l'ancienne et de la nouvelle infrastructure, en mesurant la latence au 99e percentile (P99) afin de capturer les performances les plus mauvaises et le nombre d'opérations par seconde, en tenant compte de la latence de queue. Chaque piste a été exécutée cinq fois pour chaque profil de matériel afin de garantir la cohérence des résultats.

• L'objectif : Notre objectif était de valider la capacité de l'infrastructure à fournir des performances plus rapides et plus prévisibles de manière constante, même pendant les périodes d'autoscaling rapide.

Résumé des données de performance

Les résultats confirment des gains d'efficacité et de rapidité significatifs. Ces gains se traduisent directement par des temps de réponse plus courts pour vos utilisateurs et par une réduction des coûts opérationnels grâce à la possibilité d'effectuer la même quantité de travail avec moins de ressources de calcul.

Les tableaux suivants décrivent en détail les améliorations quantitatives. Plus les valeurs sont élevées, meilleur est le débit ; plus les valeurs sont faibles, meilleure est la latence.

Résultats des recherches de référence :

Référence

Comparatif

Ancienne infrastructure

Nouvelle infrastructure

Différentiel

'wikipedia' (texte brut)

Débit des opérations de recherche (ops/s)

729

1107

+52 %

'wikipedia' (texte brut)

Latence des opérations de recherche (p99, ms)

56

35

-37 %

`MSMARCO-Passage-Ranking` (vecteurs épars)

Débit des opérations de recherche (ops/s)

22

31

+40 %

`MSMARCO-Passage-Ranking` (vecteurs épars)

Latence des opérations de recherche (p99, ms)

108

67

-38 %

'OpenAI_Vector' (vecteurs denses)

Débit des opérations de recherche (ops/s)

475

624

+31 %

'OpenAI_Vector' (vecteurs denses)

Latence des opérations de recherche (p99, ms)

35

22

-37 %

Résultats de référence de l'indexation :

Référence

Comparatif

Ancienne infrastructure

Nouvelle infrastructure

Différentiel

'wikipedia' (texte brut)

Débit des opérations de recherche (ops/s)

2 845

3 220

+13 %

'wikipedia' (texte brut)

Latence des opérations de recherche (p99, ms)

1769

1120

-37 %

`MSMARCO-Passage-Ranking` (vecteurs épars)

Débit des opérations de recherche (ops/s)

7087

8 900

+26 %

`MSMARCO-Passage-Ranking` (vecteurs épars)

Latence des opérations de recherche (p99, ms)

824

677

-18 %

'OpenAI_Vector' (vecteurs denses)

Débit des opérations de recherche (ops/s)

2972

3187

+7%

'OpenAI_Vector' (vecteurs denses)

Latence des opérations de recherche (p99, ms)

2946

2944

0 %

L'avantage supplémentaire : réduction des coûts

Bien que notre priorité soit de fournir des performances à faible latence, l'efficacité du nouveau matériel a également un impact direct et positif sur les coûts des projets Elasticsearch.

La tarification d'Elasticsearch Serverless est basée sur l'utilisation : vous ne payez que pour les ressources d'ingestion et de recherche que vous consommez. Grâce à un matériel plus récent et plus rapide, vos charges de travail s'exécuteront souvent avec moins de ressources, ce qui se traduit par une réduction des coûts pour la plupart des projets. Vous bénéficiez ainsi de performances optimales sans le surcoût : l'efficacité par excellence.

Qu'est-ce que cela signifie pour vous, le développeur ?

Cette mise à niveau de l'infrastructure est entièrement gérée par Elastic ; vous n'avez donc rien à faire, aucune migration ni modification de configuration. L'amélioration est immédiate et automatique pour tous vos projets sans serveur sur AWS.

Cette mise à niveau vous permet de :

• Créez des applications plus rapides : concentrez-vous sur la vélocité des fonctionnalités, en sachant que votre plateforme de recherche sous-jacente offre la vitesse exigée par vos utilisateurs.

• Innovez en confiance : déployez de nouvelles fonctionnalités de recherche, d'observabilité et de sécurité, y compris des capacités d'IA complexes telles que la recherche vectorielle et le classement par pertinence, sachant que la plateforme peut gérer la charge à des performances optimales.

• Simplifiez votre stack : utilisez un service entièrement géré qui prend en charge l'infrastructure, la planification de la capacité et le scaling, et concentrez‑vous sur votre code et vos données.

1. Clonez le dépôt : Téléchargez le code de l'outil depuis GitHub en utilisant git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent aet naviguez dans le répertoire avec cd serverless-ai-agent.

2. Configurer l'environnement : Créez un environnement virtuel (facultatif) avec python -m venv venv et activez-le (source venv/bin/activate ou venv\Scripts\activate sous Windows). Ensuite, installez les paquets Python nécessaires à l'aide de pip install -r requirements.txt.

3. Configurer les informations d'identification : Créez un fichier .env à la racine du projet et remplissez-le avec l'URL de votre API Elasticsearch (ES_URL), la clé API (API_KEY), la région (REGION) et la clé API OpenAI (OPENAI_API_KEY).

4. Exécutez l'outil : Exécutez l'outil en lançant python main.py dans votre terminal. Cela démarre l'agent d'intelligence artificielle et présente une invite pour vos commandes.

5. Gérer les projets en langage naturel : Interagissez avec l'outil en utilisant des commandes en langage naturel comme "Créer un projet sans serveur nommé mon_projet", "Obtenir le statut du projet sans serveur nommé mon_projet", ou "Supprimer le projet sans serveur nommé mon_projet". L'IA interprétera vos commandes et exécutera les fonctions correspondantes.

Arrière-plan

Ce petit outil en ligne de commande vous permet de gérer vos projets Serverless Elasticsearch en anglais simple. Il s'adresse à une IA (dans ce cas, OpenAI) pour comprendre ce que vous voulez dire et appeler les bonnes fonctions à l'aide de LlamaIndex !

Que peut faire l'agent Elasticsearch Serverless AI ?

• Créer un projet: Créez un nouveau projet Serverless Elasticsearch.

• Supprimer un projet: Supprimer un projet existant (oui, il nettoie après vous).

• Obtenir l'état d'avancement du projet: Vérifiez l'état d'avancement de votre projet.

• Obtenir les détails du projet: Obtenez tous les détails croustillants de votre projet.

Consultez le code sur GitHub.

Fonctionnement de l'agent Elasticsearch Serverless AI

Lorsque vous tapez quelque chose comme :

"Créer un projet sans serveur nommé mon_projet."

...voici ce qui se passe en coulisses :

• Entrée de l'utilisateur & contexte : Votre commande en langage naturel est envoyée à l'agent d'intelligence artificielle.

• Description des fonctions : L'agent IA connaît déjà quelques fonctions, telles que create_ess_project, delete_ess_project, get_ess_project_status et get_ess_project_details, parce que nous lui avons fourni des descriptions détaillées. Ces descriptions indiquent à l'IA le rôle de chaque fonction et les paramètres dont elle a besoin.

• Traitement par le LLM : Votre demande et les informations relatives à la fonction sont envoyées au LLM. Cela signifie que l'IA voit :

  • La requête de l'utilisateur: Votre instruction en langage clair.

  • Fonctions disponibles & descriptions: Détails sur les fonctions de chaque outil afin de pouvoir choisir le bon.

  • Contexte/Info historique de la conversation: Comme il s'agit d'une conversation, il se souvient de ce qui a été dit auparavant.

• Appel de fonction & réponse : L'IA détermine quelle fonction appeler, transmet les bons paramètres (comme le nom de votre projet), puis la fonction est exécutée. La réponse vous est renvoyée dans un format convivial.

En bref, nous envoyons à la fois votre requête en langage naturel et une liste de descriptions détaillées d'outils au mécanisme d'apprentissage tout au long de la vie afin qu'il puisse "comprendre" et choisir l'action appropriée à votre demande.

Mise en place de l'agent d'intelligence artificielle

Prérequis :

Avant d'exécuter l'agent AI, assurez-vous que les éléments suivants sont en place :

1. Python (v3.7 ou plus récent) installé.

2. Compte Elasticsearch serverless configuré sur Elastic Cloud.

3. Compte OpenAI pour interagir avec le modèle linguistique.

Les étapes :

1. Clonez le référentiel :

2. Créer un environnement virtuel (facultatif mais recommandé) : Si vous êtes confronté à des problèmes liés à l'environnement, vous pouvez créer un environnement virtuel pour l'isoler :

3. Installez les dépendances : Assurez-vous que toutes les dépendances requises sont installées en exécutant le programme :

4. Configurez votre environnement : Créez un fichier .env à la racine du projet avec les variables suivantes. Voici un exemple de fichier .env.example pour vous aider :

Assurez-vous que vous disposez des valeurs correctes pour ES_URL, API_KEY, et OPENAI_API_KEY. Vous trouverez vos clés API dans les tableaux de bord respectifs des services.

5. Fichier de projets : l'outil utilise un fichier projects.json pour stocker vos correspondances de projets (noms de projets et détails). Ce fichier sera créé automatiquement s'il n'existe pas déjà.

Exécution de l'agent d'intelligence artificielle

Vous verrez apparaître une invite comme celle-ci :

Tapez votre commande et l'agent d'intelligence artificielle fera son travail ! Lorsque vous avez terminé, tapez exit ou quit pour partir.

Quelques détails supplémentaires

• Intégration du LLM: Le LLM reçoit à la fois votre requête et des descriptions détaillées de chaque fonction disponible. Cela l'aide à comprendre le contexte et à décider, par exemple, s'il faut appeler create_ess_project ou delete_ess_project.

• Description des outils: Chaque outil de fonction (créé à l'aide de FunctionTool.from_defaults) a une description sympathique. Cette description est incluse dans l'invite envoyée au LLM afin qu'il "sache" quelles actions sont disponibles et ce que chaque action attend.

• Persistance: Vos projets et leurs détails sont enregistrés dans projects.json, afin de ne pas avoir à ressaisir les informations à chaque fois.

• Journalisation verbeuse: L'agent est configuré en mode verbeux, ce qui est idéal pour le débogage et pour voir comment vos instructions sont traduites en appels de fonction.

Exemple d'utilisation d'un agent IA Elasticsearch

Où nous avons commencé

La première version d'Elasticsearch a été publiée en 2010 en tant que moteur de recherche évolutif distribué permettant aux utilisateurs de rechercher rapidement des informations critiques et de les faire remonter à la surface. Douze ans et plus de 65 000 modifications plus tard, Elasticsearch continue de fournir aux utilisateurs des solutions éprouvées à une grande variété de problèmes de recherche. Grâce aux efforts de plus de 1 500 contributeurs, dont des centaines d'employés d'Elastic à temps plein, Elasticsearch a constamment évolué pour relever les nouveaux défis qui se présentent dans le domaine de la recherche.

Au début de la vie d'Elasticsearch, lorsque des problèmes de perte de données ont été soulevés, l'équipe d'Elastic a entrepris un effort pluriannuel pour réécrire le système de coordination des clusters afin de garantir que les données reconnues sont stockées en toute sécurité. Lorsqu'il est apparu clairement que la gestion des index dans les grands clusters était un problème, l'équipe a travaillé à la mise en œuvre d'une solution ILM complète pour automatiser ce travail en permettant aux utilisateurs de prédéfinir des modèles d'index et des actions de cycle de vie. Les utilisateurs ayant constaté la nécessité de stocker des quantités importantes de données métriques et de séries chronologiques, diverses fonctionnalités telles qu'une meilleure compression ont été ajoutées afin de réduire la taille des données. Comme le coût de stockage pour la recherche de grandes quantités de données froides augmentait, nous avons investi dans la création d'instantanés consultables (Searchable Snapshots ) comme moyen de rechercher des données d'utilisateur directement sur des magasins d'objets à faible coût.

Ces investissements jettent les bases de la prochaine évolution d'Elasticsearch. Avec la croissance des services cloud-native et des nouveaux systèmes d'orchestration, nous avons décidé qu'il était temps de faire évoluer Elasticsearch pour améliorer l'expérience de travail avec les systèmes cloud-native. Nous pensons que ces changements offrent des possibilités d'amélioration des opérations, des performances et des coûts lors de l'exécution d'Elasticsearch sur Elastic Cloud.

Où nous allons - Adopter une architecture sans état

L'une des principales difficultés rencontrées lors de l'exploitation ou de l'orchestration d'Elasticsearch réside dans le fait qu'il dépend de nombreux éléments d'état persistants, et qu'il s'agit donc d'un système avec état. Les trois éléments principaux sont le translog, le magasin d'index et les métadonnées de la grappe. Cet état signifie que le stockage doit être persistant et ne peut être perdu lors du redémarrage ou du remplacement d'un nœud.

L'architecture Elasticsearch existante sur Elastic Cloud doit dupliquer l'indexation sur plusieurs zones de disponibilité pour assurer la redondance en cas de panne. Nous avons l'intention de transférer la persistance de ces données des disques locaux vers un magasin d'objets, comme AWS S3. En nous appuyant sur des services externes pour le stockage de ces données, nous supprimerons le besoin de réplication de l'indexation, ce qui réduira considérablement le matériel associé à l'ingestion. Cette architecture offre également des garanties de durabilité très élevées grâce à la manière dont les magasins d'objets en nuage tels que AWS S3, GCP Cloud Storage et Azure Blob Storage répliquent les données à travers les zones de disponibilité.

Le fait de décharger le stockage de l'index dans un service externe nous permettra également de réarchitecturer Elasticsearch en séparant les responsabilités d'indexation et de recherche. Au lieu d'avoir des instances primaires et répliquées gérant les deux charges de travail, nous avons l'intention d'avoir un niveau d'indexation et un niveau de recherche. La séparation de ces charges de travail permettra de les dimensionner indépendamment et de mieux cibler le choix du matériel en fonction des cas d'utilisation respectifs. Il permet également de résoudre un problème de longue date, à savoir que la charge de recherche et la charge d'indexation peuvent avoir un impact l'une sur l'autre.

Après une phase expérimentale de plusieurs mois, nous sommes convaincus que ces services de stockage d'objets répondent aux exigences que nous envisageons pour le stockage des index et des métadonnées des grappes. Nos tests et benchmarks indiquent que ces services de stockage peuvent répondre aux besoins d'indexation élevés des plus grands clusters que nous avons vus dans Elastic Cloud. En outre, la sauvegarde des données dans le magasin d'objets réduit les coûts d'indexation et permet de régler facilement les performances de la recherche. Pour rechercher des données, Elasticsearch utilisera le modèle Searchable Snapshots, qui a fait ses preuves, dans lequel les données sont conservées en permanence dans le magasin d'objets natif du nuage et les disques locaux sont utilisés comme caches pour les données auxquelles on accède fréquemment.

Pour faciliter la différenciation, nous décrivons notre modèle existant comme étant la réplication "de nœud à nœud". Dans l'étage chaud de ce modèle, l'étage primaire et l'étage réplique effectuent tous deux les mêmes tâches lourdes pour gérer l'ingestion et répondre aux demandes de recherche. Ces nœuds sont "stateful" en ce sens qu'ils s'appuient sur leurs disques locaux pour conserver en toute sécurité les données des ensembles qu'ils hébergent. En outre, les cartes primaires et les cartes répliques communiquent en permanence pour rester synchronisées. Pour ce faire, ils répliquent les opérations effectuées sur le groupe primaire vers le groupe réplique, ce qui signifie que le coût de ces opérations (CPU, principalement) est supporté pour chaque réplique spécifiée. Les mêmes unités de stockage et nœuds qui effectuent ce travail pour l'ingestion servent également à répondre aux demandes de recherche, de sorte que le dimensionnement et la mise à l'échelle doivent être effectués en tenant compte des deux charges de travail.

Au-delà de la recherche et de l'acquisition de données, les unités dans le modèle de réplication nœud à nœud gèrent d'autres responsabilités intensives, telles que la fusion de segments Lucene. Bien que cette conception ait ses mérites, nous avons vu beaucoup d'opportunités basées sur ce que nous avons appris avec nos clients au fil des ans et sur l'évolution de l'écosystème plus large de l'informatique dématérialisée.

La nouvelle architecture permet de nombreuses améliorations immédiates et futures :

1. Il est possible d'augmenter considérablement le débit d'ingestion sur le même matériel ou, pour voir les choses autrement, d'améliorer considérablement l'efficacité pour la même charge de travail d'ingestion. Cette augmentation provient de la suppression de la duplication des opérations d'indexation pour chaque réplique. Les opérations d'indexation gourmandes en ressources humaines n'ont lieu qu'une seule fois au niveau de l'indexation, qui achemine ensuite les segments résultants vers un magasin d'objets. À partir de là, les données sont prêtes à être consommées telles quelles par le niveau de recherche.

2. Vous pouvez séparer le calcul du stockage pour simplifier la topologie de votre cluster. Aujourd'hui, Elasticsearch dispose de plusieurs niveaux de données (contenu, chaud, tiède, froid et gelé) pour faire correspondre les données au profil du matériel. Le niveau "chaud" est destiné à la recherche en temps quasi réel et le niveau "gelé" est destiné aux données moins fréquemment recherchées. Bien que ces niveaux apportent de la valeur, ils augmentent également la complexité. Dans la nouvelle architecture, les niveaux de données ne seront plus nécessaires, ce qui simplifiera la configuration et le fonctionnement d'Elasticsearch. Nous séparons également l'indexation de la recherche, ce qui réduit encore la complexité et nous permet de faire évoluer les deux charges de travail de manière indépendante.

3. Vous pouvez réduire les coûts de stockage au niveau de l'indexation en diminuant la quantité de données qui doivent être stockées sur un disque local. Actuellement, Elasticsearch doit stocker une copie complète du shard sur les nœuds chauds (à la fois primaires et répliqués) à des fins d'indexation. Avec l'approche sans état qui consiste à indexer directement le magasin d'objets, seule une partie de ces données locales est nécessaire. Pour les cas d'utilisation de type append only, seules certaines métadonnées devront être stockées pour l'indexation. Cela permettra de réduire considérablement le stockage local nécessaire à l'indexation.

4. Vous pouvez réduire les coûts de stockage associés aux requêtes de recherche. En faisant du modèle des instantanés consultables le mode natif de recherche des données, le coût de stockage associé aux requêtes de recherche diminuera de manière significative. En fonction des besoins des utilisateurs en matière de latence de recherche, Elasticsearch permettra des ajustements pour augmenter la mise en cache locale des données fréquemment demandées.

Analyse comparative - 75% amélioration du débit d'indexation

Afin de valider cette approche, nous avons mis en œuvre une vaste démonstration de faisabilité dans laquelle les données n'étaient indexées que sur un seul nœud et la réplication était assurée par des magasins d'objets dans le nuage. Nous avons constaté que nous pouvions améliorer le débit d'indexation de 75% en supprimant la nécessité de dédier du matériel à la réplication de l'indexation. En outre, le coût de l'unité centrale associé à la simple extraction des données du magasin d'objets était bien inférieur à l'indexation des données et à leur écriture locale, comme c'est le cas aujourd'hui pour la couche chaude. Cela signifie que les nœuds de recherche pourront consacrer entièrement leur CPU à la recherche.

Ces tests de performance ont été réalisés sur un cluster de deux nœuds avec les trois principaux fournisseurs de clouds publics (AWS, GCP et Azure). Nous avons l'intention de continuer à développer des benchmarks plus importants au fur et à mesure de la mise en place d'une implémentation sans état de la production.

Débit d'indexation

Utilisation de l'unité centrale

Apatrides pour nous, économies pour vous

L'architecture sans état d'Elastic Cloud vous permettra de réduire la surcharge d'indexation, de faire évoluer indépendamment l'ingestion et la recherche, de simplifier la gestion des niveaux de données et d'accélérer les opérations, telles que la mise à l'échelle ou la mise à niveau. Il s'agit de la première étape vers une modernisation substantielle de la plateforme Elastic Cloud.

Participez à notre vision d'Elasticsearch sans état d'âme

Vous souhaitez tester cette solution avant tout le monde ? Vous pouvez nous contacter sur discuss ou sur le canal slack de notre communauté. Nous serions ravis de recevoir vos commentaires pour nous aider à définir l'orientation de notre nouvelle architecture.