Search AI Lake : Elastic renomme son architecture « stateless » pour mieux surfer sur la genAI

D’une architecture « stateless » au serverless et à Search AI Lake

Ladite architecture se nomme désormais Search AI Lake et propulse l’offre Elastic Cloud Serverless. Celle-ci est actuellement disponible en préversion technique privée. Pour l’instant, elle couvre « 70 à 80 % » des usages dans les domaines couverts par l’éditeur : la recherche de documents, l’observabilité et la cybersécurité (SIEM).

« Nous avons déjà un certain nombre de clients qui utilisent Elastic Cloud Serverless. Nous avons obtenu des retours assez évocateurs sur le comportement de la plateforme et nous avons prévu de lancer une bêta publique en octobre prochain », annonce Yannick Fhima, directeur de l’architecture des solutions SEMEA (South EMEA) chez Elastic.

« Ces clients sont principalement des startups et des e-commerçants. Nos gros clients n’ont pas basculé, car nous n’avons pas encore basculé l’ensemble des fonctions que nous proposons sur notre offre existante ».

« Toutes les données sont stockées dans un espace de stockage objet type S3, et le cache joue le rôle de “hot” pour répondre rapidement aux requêtes. »

Actuellement, les grands comptes exploitent majoritairement Elastic Cloud, Hosted Elastic Stack sur AWS, GCP ou Azure. « Toute la pile de logiciels ELK (Elasticsearch, Logstash, Kibana) est gérée par les opérateurs Elastic, mais les clients doivent décider eux-mêmes de la quantité de ressources nécessaires à leur traitement, la stratégie de mise à l’échelle ascendante et descendante », explique Yannick Fhima. « Elastic Cloud Serverless offre un point d’entrée vers lequel les clients peuvent envoyer leurs données et nous avons automatisé la plateforme pour qu’elle s’adapte aux charges de travail ».

En matière de stockage de données, Elastic Cloud Serverless doit éliminer la gestion du tiering (hot, warm, cold, frozen), un objectif que l’éditeur avait partiellement atteint avec la version 7.10 d’Elasticsearch.

Avec la plateforme SaaS et serverless, « toutes les données sont stockées dans un espace de stockage objet type S3, et le cache joue le rôle de “hot” pour répondre rapidement aux requêtes », rappelle le responsable de l’architecture des solutions. « Les clients n’ont plus à gérer le transvasage des données entre différents espaces de stockage ».

« Les clients n’ont plus à gérer le transvasage des données entre différents espaces de stockage. »

Quant à l’indexation et la recherche, elles sont gérées par deux tiers distincts. « Nous pouvons mettre à l’échelle de manière indépendante l’ingestion de la recherche », assure Yannick Fhima.

L’éditeur chercherait ainsi à couvrir les usages en temps réel et lié à l’IA, avance-t-il.

Une recherche hybride

Au vu du nom de l’architecture stateless, « Search AI Lake », Elastic surfe éhontément sur la vague de l’IA générative. Et pour cause, la tendance technologique serait sur la liste des priorités des clients de l’éditeur.

« Il y a quatre ans, nous avons mis sur pied une fonctionnalité de recherche vectorielle sans savoir qu’elle nous servirait à déployer des systèmes RAG », vante le directeur de l’architecture des solutions. Précisons qu’Elastic hérite des fonctionnalités d’Apache Lucene, l’un des projets open source en amont d’ELK.

Rapidement, Elastic a misé sur une hybridation de la recherche, en mêlant algorithme d’indexation vectorielle et de recherche « classique » par mot clé, type BM25.

L’éditeur prend en charge plusieurs types d’algorithmes de recherche vectorielle, Knn « brute force » ou A(k)NN. Dans le second cas, Elastic s’appuie par défaut sur HNSW (Hierarchical Navigable Small world), un index orienté graphe issu de Lucene.  

Il joue également sur différents modèles d’embedding, denses (comme le très populaire e5 large v2) et éparses (un modèle maison, ELSER V2), des grands modèles de langage entraînés pour encoder les mots en vecteurs dans des espaces multidimensionnels. En la matière, Elastic propose aussi des intégrations avec les modèles d’embedding d’OpenAI, ceux proposés par Azure AI Studio, AWS (Titan) via Amazon Bedrock et, depuis le 1^er août 2024, de Mistral AI. D’autres LLM de ces fournisseurs peuvent être appelés pour propulser la génération de réponses dans les systèmes RAG.

Des assistants IA pour la recherche, l’observabilité et la sécurité

Voilà pour les éléments sous-jacents. Mais Elastic propose également des assistants, des interfaces permettant de configurer des chatbots pour les usages de recherche en entreprise, d’observabilité et de cybersécurité. En préversion technique, il intègre Playground, un banc d’essai « low-code » pour tester les interfaces d’agents propulsés par différents LLM.

Parmi ces assistants, Elastic met en avant Attack Discovery, lui aussi en préversion technique.

« Attack Discovery découle d’un processus qui récupère les alertes et met automatiquement en avant les alertes les plus pertinentes sur lesquelles l’analyste de sécurité d’un SOC doit se concentrer », résume Yannick Fhima. « Cela doit réduire le temps de recherche de 4 heures à 10 minutes ».

Ici, un LLM est configuré (de préférence Claude 3 Sonnet et Claude 3 Opus) pour générer des « découvertes » c’est-à-dire des analyses de sécurité à partir des alertes concernant de potentielles attaques ciblant des hôtes et utilisateurs spécifiques. Ici, Elastic s’appuie sur le framework MITRE ATT&CK. Le LLM est surtout là pour mettre en musique la description d’une découverte, générer un rapport d’alertes et fournir des recommandations (basiques) de remédiations. Sous le capot, l’éditeur s’appuie sur les fonctionnalités de son SIEM et sur un système RAG.

Elastic affirme que les règles d’anonymisation et de sélection des champs demeurent, mais il recommande à ses clients de configurer correctement les API des LLM tiers. « Par ailleurs, nous offrons des fonctionnalités de LLMOps afin de contrôler les aspects de confidentialité, de sécurité, d’hallucination et de coûts », ajoute Yannick Fhima.

Pour l’instant, ces assistants sont disponibles à travers le cloud et les appels API vers les LLM des fournisseurs Azure, OpenAI, Mistral AI, AWS. Mais Elastic envisage de rendre possibles les cas d’usage dans des environnements sur site.

« Nous observons beaucoup de POC proches du déploiement en production. Ce sont principalement des “chat docs” (pour interroger en langage naturel des bases de documentaire technique), des “chatbots as a service” (c’est-à-dire des interfaces permettant de charger des documents et de les interroger), ainsi que des agents conversationnels », liste Yannick Fhima. « Les clients qui les déploient proviennent du secteur bancaire, des télécoms, de l’industrie et de l’e-commerce. Ces clients parlent davantage de recherche vectorielle que d’IA générative ».

Fédérer les requêtes et unifier les langages

D’ailleurs, l’éditeur prévoit une hybridation des environnements ELK déployés sur site avec les instances cloud Hosted et Serverless.

« Nous proposons de manière native une fonction de recherche fédérée “cross cluster” permettant d’interroger les données stockées dans plusieurs clouds ou sur différents clusters sur site » présente Yannick Fhima. À condition que ces clusters s’appuient sur la même version majeure (8.x et au-delà) ou la dernière version mineure antérieure (7.17 avec la 8.x), précise la documentation.

Enfin, point important et non des moindres, Elastic cherche à rationaliser l’utilisation des langages de requêtes sur sa plateforme. Aujourd’hui, la pile ELK prend en charge sept langages/DSL : Query DSL, EQL, KQL, SQL, Painless et Canvas/Timelion.  

La version 8.14 d’Elasticsearch lancée en juin implique la disponibilité générale d’ES|QL (Elasticsearch Query Language). C’est un langage canalisé (piped) « à la mode SQL » accompagné d’un moteur de requêtes spécifique. « Il a vocation à remplacer tous les langages existants et répondre à tous les cas d’usage », résume le responsable de l’architecture des solutions. Il serait déjà utilisé par des analystes cyber.