Le connecteur Semantic Kernel Elasticsearch Vector Store, prêt à l'emploi, prend en charge les abstractions du Semantic Kernel vector store, ce qui permet aux développeurs de brancher très facilement Elasticsearch en tant que magasin vectoriel lors de la création d'agents d'intelligence artificielle.

Elasticsearch est solidement ancré dans la communauté des logiciels libres et a récemment adopté la licence AGPL. Associés au noyau sémantique Microsoft open-source, ces outils offrent une solution puissante, prête pour l'entreprise. Vous pouvez commencer localement en démarrant Elasticsearch en quelques minutes en exécutant cette commande curl -fsSL https://elastic.co/start-local | sh (voir start-local pour plus de détails) et évoluer vers des versions hébergées dans le nuage ou auto-hébergées tout en mettant en production vos agents d'IA.

Dans ce blog, nous verrons comment utiliser le connecteur Semantic Kernel Elasticsearch Vector Store lors de l'utilisation de Semantic Kernel. Une version Python du connecteur sera disponible à l'avenir.

Scénario de haut niveau : Construire une application RAG avec Semantic Kernel & Elasticsearch

Dans la section suivante, nous présentons un exemple. À un niveau élevé, nous construisons une application RAG (Retrieval Augmented Generation) qui prend la question d'un utilisateur en entrée et renvoie une réponse. Nous utiliserons Azure OpenAI(un LLM local peut également être utilisé) comme LLM, Elasticsearch comme magasin de vecteurs et Semantic Kernel (.net) comme cadre pour relier tous les composants ensemble.

Si vous n'êtes pas familier avec les architectures RAG, vous pouvez vous familiariser rapidement avec cet article : https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

La réponse est générée par le LLM qui est alimenté par le contexte, pertinent pour la question, récupéré à partir du vectorstore Elasticsearch. La réponse inclut également la source qui a été utilisée comme contexte par le LLM.

Exemple de GCR

Dans cet exemple spécifique, nous créons une application qui permet aux utilisateurs de poser des questions sur les hôtels stockés dans une base de données interne. L'utilisateur peut par exemple rechercher un hôtel spécifique, en fonction de différents critères, ou demander une liste d'hôtels.

Pour la base de données d'exemple, nous avons généré une liste d'hôtels contenant 100 entrées. La taille de l'échantillon est volontairement réduite pour vous permettre d'essayer la démo du connecteur aussi facilement que possible. Dans une application réelle, le connecteur Elasticsearch montrerait ses avantages par rapport à d'autres options, telles que l'implémentation du magasin vectoriel `InMemory`, en particulier lorsque l'on travaille avec de très grandes quantités de données.

L'application de démonstration complète se trouve dans le référentiel du connecteur Elasticsearch vector store.

Commençons par ajouter les paquets NuGet et les directives nécessaires à notre projet :

Nous pouvons maintenant créer notre modèle de données et le doter d'attributs spécifiques au Semantic Kernel pour définir le schéma du modèle de stockage et quelques indications pour la recherche textuelle :

Les attributs du schéma du modèle de stockage (`VectorStore*`) sont les plus pertinents pour l'utilisation réelle du connecteur Elasticsearch Vector Store, à savoir :

• VectorStoreRecordKey pour marquer une propriété d'une classe d'enregistrement comme étant la clé sous laquelle l'enregistrement est stocké dans un magasin vectoriel.

• VectorStoreRecordData pour marquer une propriété d'une classe d'enregistrement comme "data".

• VectorStoreRecordVector pour marquer une propriété d'une classe d'enregistrement en tant que vecteur.

Tous ces attributs acceptent divers paramètres facultatifs qui peuvent être utilisés pour personnaliser davantage le modèle de stockage. Dans le cas de VectorStoreRecordKey , par exemple, il est possible de spécifier une fonction de distance différente ou un type d'indice différent.

Les attributs de recherche de texte (TextSearch*) seront importants dans la dernière étape de cet exemple. Nous y reviendrons plus tard.

Dans l'étape suivante, nous initialisons le moteur du noyau sémantique et obtenons des références aux services de base. Dans une application réelle, l' injection de dépendances devrait être utilisée au lieu d'accéder directement à la collection de services. La même chose s'applique à la configuration et aux secrets codés en dur, qui doivent être lus à l'aide d'un fournisseur de configuration:

Le service vectorStoreCollection peut maintenant être utilisé pour créer la collection et ingérer quelques enregistrements de démonstration :

Cela montre comment Semantic Kernel réduit l'utilisation d'un magasin de vecteurs, avec toute sa complexité, à quelques simples appels de méthodes.

Sous le capot, un nouvel index est créé dans Elasticsearch et tous les mappages de propriétés nécessaires sont créés. Notre ensemble de données est ensuite intégré de manière totalement transparente dans le modèle de stockage et finalement stocké dans l'index. Voici à quoi ressemblent les mappings dans Elasticsearch.

Le site embeddings.GenerateEmbeddingsAsync() appelle de manière transparente le service Azure AI Embeddings Generation configuré.

La dernière étape de cette démonstration est encore plus magique.

Avec un seul appel à InvokePromptAsync, toutes les opérations suivantes sont effectuées lorsque l'utilisateur pose une question sur les données :

1. L'intégration de la question de l'utilisateur est générée.

2. Le magasin de vecteurs est parcouru à la recherche d'entrées pertinentes

3. Les résultats de la requête sont insérés dans un modèle d'invite

4. La requête proprement dite, sous la forme de l'invite finale, est envoyée au service d'achèvement de chat de l'IA.

Vous vous souvenez des attributs TextSearch* que nous avons définis précédemment dans notre modèle de données ? Ces attributs nous permettent d'utiliser les espaces réservés correspondants dans notre modèle d'invite, qui sont automatiquement remplis avec les informations provenant de nos entrées dans le magasin de vecteurs.

La réponse finale à notre question "Veuillez m'indiquer tous les hôtels qui disposent d'un bar sur le toit." est la suivante :

La réponse se réfère correctement à l'entrée suivante dans notre fichier hotels.csv

Cet exemple montre très bien comment l'utilisation de Microsoft Semantic Kernel permet une réduction significative de la complexité grâce à ses abstractions bien pensées, tout en permettant un très haut niveau de flexibilité. En changeant une seule ligne de code, par exemple, le magasin de vecteurs ou les services d'intelligence artificielle utilisés peuvent être remplacés sans qu'il soit nécessaire de remanier une autre partie du code.

Dans le même temps, le cadre fournit un ensemble considérable de fonctionnalités de haut niveau, telles que la fonction `InvokePrompt`, ou le système de plugin de modèle ou de recherche.

L'application de démonstration complète se trouve dans le référentiel du connecteur Elasticsearch vector store.

Quelles sont les autres possibilités offertes par Elasticsearch ?

• Nouveau mappage semantic_text d'Elasticsearch : Simplifier la recherche sémantique

• Classement sémantique dans Elasticsearch à l'aide d'extracteurs

• Techniques avancées de RAG partie 1 : Traitement des données

• Techniques avancées de RAG, partie 2 : Requêtes et tests

• Construire RAG avec Llama 3 open-source et Elastic

• Un tutoriel sur la construction d'un agent local utilisant LangGraph, LLaMA3 et Elasticsearch vector store à partir de zéro

Elasticsearch & Semantic Kernel : Quelle est la prochaine étape ?

• Nous avons montré comment le magasin vectoriel Elasticsearch peut être facilement intégré au Semantic Kernel lors de la construction d'applications GenAI en .NET. Restez à l'écoute pour une prochaine intégration de Python.

• Comme Semantic Kernel construit des abstractions pour des fonctions de recherche avancées telles que la recherche hybride, la connexion Elasticsearch permettra aux développeurs .NET de les mettre en œuvre facilement tout en utilisant Semantic Kernel.

Dans ce billet, nous examinerons les moyens de protéger les informations personnelles identifiables (PII) et les données sensibles lors de l'utilisation de LLM publics dans un flux RAG (Retrieval Augmented Generation). Nous explorerons le masquage des IIP et des données sensibles à l'aide de bibliothèques open source et d'expressions régulières, ainsi que l'utilisation de LLM locaux pour masquer les données avant d'invoquer un LLM public.

Avant de commencer, rappelons la terminologie utilisée dans ce billet.

Terminologie

LlamaIndex est un cadre de données de premier plan pour la création d'applications LLM (Large Language Model). LlamaIndex fournit des abstractions pour les différentes étapes de la construction d'une application RAG (Retrieval Augmented Generation). Des structures telles que LlamaIndex et LangChain fournissent des abstractions afin que les applications ne soient pas étroitement liées aux API d'un LLM spécifique.

Elasticsearch est proposé par Elastic. Elastic est un leader de l'industrie avec Elasticsearch, un magasin de données évolutif et une base de données vectorielle qui prend en charge la recherche en texte intégral pour la précision, la recherche vectorielle pour la compréhension sémantique, et la recherche hybride pour le meilleur des deux mondes. Elasticsearch est un moteur de recherche et d'analyse RESTful distribué, un magasin de données évolutif et une base de données vectorielle. Les fonctionnalités d'Elasticsearch que nous utilisons dans ce blog sont disponibles dans la version gratuite et ouverte d'Elasticsearch.

La génération assistée par récupération (RAG) est une technique ou un modèle d'IA dans lequel les LLM sont dotés de connaissances externes pour générer des réponses aux questions des utilisateurs. Cela permet d'adapter les réponses du programme d'éducation et de formation tout au long de la vie à un contexte spécifique et de les rendre moins génériques.

Les encastrements sont des représentations numériques de la signification d'un texte ou d'un média. Il s'agit de représentations de dimensions inférieures d'informations de dimensions supérieures.

RAG et protection des données

En règle générale, les grands modèles linguistiques (LLM) permettent de générer des réponses sur la base des informations disponibles dans le modèle, qui peut être formé à partir de données Internet. Toutefois, pour les questions pour lesquelles les informations ne sont pas disponibles dans le modèle, les MFR doivent être alimentés par des connaissances externes ou des détails spécifiques qui ne sont pas contenus dans le modèle. Ces informations peuvent se trouver dans votre base de données ou dans votre système de connaissances interne. La génération améliorée par récupération (RAG) est une technique dans laquelle, pour une requête d'utilisateur donnée, vous récupérez d'abord le contexte/l'information pertinente des systèmes externes (au LLM) (par exemple votre base de données) et envoyez ce contexte avec la requête d'utilisateur au LLM pour générer une réponse plus spécifique et plus pertinente.

Cela rend la technique RAG très efficace pour les applications de réponse aux questions, de création de contenu et partout où une compréhension approfondie du contexte et des détails est bénéfique.

Par conséquent, dans une filière RAG, vous courez le risque d'exposer des informations internes telles que des PII (informations personnelles identifiables) et des informations sensibles (par exemple des noms, des dates de naissance, des numéros de compte, etc.

Bien que vos données soient sécurisées lorsque vous utilisez une base de données vectorielle comme Elasticsearch (grâce à divers leviers tels que le contrôle d'accès basé sur les rôles, la sécurité au niveau du document, etc.), il convient d'être prudent lorsque vous envoyez des données à l'extérieur vers un LLM public.

La protection des informations d'identification personnelle (PII) et des données sensibles est cruciale lors de l'utilisation de grands modèles de langage (LLM), et ce pour plusieurs raisons :

• Conformité en matière de protection de la vie privée: De nombreuses régions disposent de réglementations strictes, telles que le règlement général sur la protection des données (RGPD) en Europe ou le California Consumer Privacy Act (CCPA) aux États-Unis, qui imposent la protection des données personnelles. Le respect de ces lois est nécessaire pour éviter les conséquences juridiques et les amendes.

• Confiance des utilisateurs: Garantir la confidentialité et l'intégrité des informations sensibles permet de renforcer la confiance des utilisateurs. Les utilisateurs sont plus enclins à utiliser et à interagir avec des systèmes dont ils pensent qu'ils protègent leur vie privée.

• Sécurité des données: La protection contre les violations de données est essentielle. Les données sensibles exposées aux MLD sans garanties adéquates peuvent faire l'objet d'un vol ou d'une utilisation abusive, entraînant des dommages potentiels tels que l'usurpation d'identité ou la fraude financière.

• Considérations éthiques: D'un point de vue éthique, il est important de respecter la vie privée des utilisateurs et de traiter leurs données de manière responsable. Un mauvais traitement des IPI peut conduire à la discrimination, à la stigmatisation ou à d'autres conséquences négatives pour la société.

• Réputation de l'entreprise: Les entreprises qui ne protègent pas les données sensibles peuvent voir leur réputation entachée, ce qui peut avoir des effets négatifs à long terme sur leurs activités, notamment la perte de clients et de revenus.

• Réduction des risques d'abus: Le traitement sécurisé des données sensibles permet d'éviter l'utilisation malveillante des données ou du modèle, comme l'entraînement des modèles sur des données biaisées ou l'utilisation des données pour manipuler ou nuire à des personnes.

Dans l'ensemble, une protection solide des IPI et des données sensibles est nécessaire pour garantir la conformité légale, maintenir la confiance des utilisateurs, assurer la sécurité des données, respecter les normes éthiques, protéger la réputation de l'entreprise et réduire le risque d'abus.

Récapitulatif rapide

Dans l'article précédent, nous avons expliqué comment mettre en œuvre l'expérience Q&A en utilisant une technique RAG avec Elasticsearch comme base de données vectorielle tout en utilisant LlamaIndex et un Mistral LLM fonctionnant localement. Ici, nous nous appuyons sur cette base.

La lecture de l'article précédent est facultative car nous allons maintenant discuter/récapituler rapidement ce que nous avons fait dans l'article précédent.

Nous disposions d'un échantillon de données de conversations de centre d'appel entre des agents et des clients d'une compagnie d'assurance habitation fictive. Nous avons créé une application RAG simple qui répond à des questions telles que "Quels sont les problèmes liés à l'eau pour lesquels les clients déposent des réclamations ?

Voici comment se présentait le flux à un niveau élevé.

Pendant la phase d'indexation, nous avons chargé et indexé des documents en utilisant le pipeline LlamaIndex. Les documents ont été regroupés et stockés dans la base de données vectorielles Elasticsearch avec leur intégration.

Pendant la phase d'interrogation, lorsque l'utilisateur pose une question, LlamaIndex récupère les documents similaires les plus pertinents par rapport à l'interrogation. Ces documents les plus pertinents, accompagnés de la requête, ont été envoyés au Mistral LLM local, qui a ensuite généré la réponse à renvoyer à l'utilisateur. N'hésitez pas à consulter l'article précédent ou à explorer le code.

Dans l'article précédent, le LLM fonctionnait localement. Cependant, en production, vous pouvez vouloir utiliser un LLM externe fourni par diverses entreprises comme OpenAI, Mistral, Anthropic, etc. Cela peut être dû au fait que votre cas d'utilisation nécessite un modèle de base plus important ou que l'exécution locale n'est pas une option en raison des besoins de production de l'entreprise tels que l'évolutivité, la disponibilité, les performances, etc.

L'introduction d'un LLM externe dans votre pipeline RAG vous expose à un risque de fuite involontaire de données sensibles et d'informations confidentielles vers les LLM. Dans cet article, nous allons explorer les options permettant de masquer les informations PII dans le cadre de votre processus RAG avant d'envoyer des documents à un LLM externe.

RAG avec un LLM public

Avant d'aborder la question de la protection des informations confidentielles et sensibles dans un pipeline RAG, nous allons d'abord construire une application RAG simple utilisant LlamaIndex, la base de données vectorielle Elasticsearch et OpenAI LLM.

Produits requis

Nous aurons besoin des éléments suivants.

• Elasticsearch est opérationnel en tant que base de données vectorielle pour le stockage des embeddings. Suivez les instructions de l'article précédent sur l'installation d'Elasticsearch.

• Clés d'API ouvertes pour l'IA.

Application simple du RAG

Pour référence, le code entier peut être trouvé dans ce dépôt Github(branch:protecting-pii). Le clonage du dépôt est facultatif car nous allons parcourir le code ci-dessous.

Dans votre IDE préféré, créez une nouvelle application Python avec les 3 fichiers ci-dessous.

• index.py où se trouve le code lié à l'indexation des données.

• query.py où se trouve le code lié à l'interrogation et à l'interaction avec le LLM.

• .env où se trouvent les propriétés de configuration telles que les clés d'API.

Nous devons installer quelques paquets. Nous commençons par créer un nouvel environnement virtuel python dans le dossier racine de votre application.

Activez l'environnement virtuel et installez les paquets requis ci-dessous.

Configurer les propriétés de connexion d'OpenAI et d'Elasticsearch dans le fichier .env fichier.

Indexation des données

Téléchargez le fichier conversations.json qui contient les conversations entre les clients et les agents du centre d'appel de notre compagnie d'assurance habitation fictive. Placez le fichier dans le répertoire racine de l'application avec les 2 fichiers python et le fichier .env. que vous avez créé précédemment. Vous trouverez ci-dessous un exemple du contenu du fichier.

Passez le code ci-dessous dans index.py qui se charge de l'indexation des données.

L'exécution du code ci-dessus crée un index dans Elasticsearch, stocke les embeddings dans l'index Elasticsearch nommé convo_index.

Si vous avez besoin d'explications sur la LlamaIndex IngestionPipeline, veuillez vous référer à l'article précédent dans la section Create IngestionPipeline.

Interrogation

Dans l'article précédent, nous avons utilisé un LLM local pour les requêtes.

Dans ce billet, nous utilisons le LLM public, OpenAI, comme indiqué ci-dessous.

Le code ci-dessus affiche la réponse d'OpenAI comme suit.

Les clients ont fait part de diverses réclamations liées à l'eau, notamment des dégâts des eaux dans les sous-sols, des éclatements de canalisations, des dommages causés aux toits par la grêle, et des refus de demandes d'indemnisation pour des raisons telles que l'absence de notification en temps utile, des problèmes d'entretien, l'usure progressive et les dommages préexistants. Dans chaque cas, les clients ont exprimé leur frustration face aux refus de demandes d'indemnisation et ont demandé des évaluations et des décisions équitables concernant leurs demandes d'indemnisation.

Masquage des IIP dans le RAG

Ce que nous avons couvert jusqu'à présent consiste à envoyer des documents tels quels à OpenAI avec la requête de l'utilisateur.

Dans le pipeline RAG, une fois que le contexte pertinent est extrait d'un magasin vectoriel, nous avons la possibilité de masquer les IIP et les informations sensibles avant d'envoyer la requête et le contexte au mécanisme d'apprentissage tout au long de la vie.

Il existe plusieurs façons de masquer les informations PII avant de les envoyer à un MLD externe, chacune d'entre elles ayant ses propres mérites. Nous examinons ci-dessous quelques-unes des options possibles

1. Utilisation de bibliothèques NLP comme spacy.io ou Presidio (bibliothèque open source gérée par Microsoft).

2. Utiliser LlamaIndex prêt à l'emploi NERPIINodePostprocessor.

3. Utilisation de LLM locaux via PIINodePostprocessor

Une fois que vous avez implémenté la logique de masquage en utilisant l'une des méthodes ci-dessus, vous pouvez configurer la LlamaIndex IngestionPipeline avec un PostProcessor (votre propre PostProcessor personnalisé ou l'un des PostProcessors prêts à l'emploi de LlamaIndex).

Utilisation des bibliothèques NLP

Dans le cadre du pipeline RAG, nous pouvons masquer les données sensibles à l'aide de bibliothèques NLP. Nous utiliserons le paquet spacy.io dans cette démonstration.

Créez un nouveau fichier query_masking_nlp.py et ajoutez le code ci-dessous.

La réponse du LLM est présentée ci-dessous.

Dans le code ci-dessus, lors de la création du moteur de requête de l'index Llama, nous fournissons un CustomPostProcessor.

La logique invoquée par le QueryEngine est définie dans la méthode _postprocess_nodes de CustomPostProcessor. Nous utilisons la bibliothèque SpaCy.io pour détecter les entités nommées dans nos documents et nous utilisons ensuite des expressions régulières pour remplacer ces noms ainsi que les informations sensibles avant d'envoyer les documents au LLM.

À titre d'exemple, voici des parties de conversations originales et de la conversation masquée créée par le CustomPostProcessor.

Texte original :

Texte masqué par le CustomPostProcessor.

Remarque :

Identifier et masquer les IPI et les informations sensibles n'est pas une tâche aisée. Couvrir les différents formats et la sémantique des informations sensibles nécessite une bonne compréhension de votre domaine et de vos données. Bien que le code présenté ci-dessus puisse fonctionner pour certains cas d'utilisation, il se peut que vous deviez le modifier en fonction de vos besoins et de vos tests.

Utiliser le LlamaIndex prêt à l'emploi NERPIINodePostprocessor

LlamaIndex a facilité la protection des informations PII dans un pipeline RAG en introduisant les éléments suivants NERPIINodePostprocessor.

La réponse est la suivante

Utilisation de LLM locaux via PIINodePostprocessor

Nous pourrions également utiliser un LLM fonctionnant localement ou dans votre réseau privé pour effectuer le travail de masquage avant d'envoyer les données à un LLM public.

Nous utiliserons Mistral fonctionnant sur Ollama sur votre machine locale pour effectuer le masquage.

Exécuter Mistral localement

Téléchargez et installez Ollama. Après avoir installé Ollama, lancez la commande suivante pour télécharger et exécuter mistral

Le téléchargement et l'exécution locale du modèle pour la première fois peuvent prendre quelques minutes. Vérifiez si le mistral fonctionne en posant une question telle que la suivante : "Ecrivez un poème sur les nuages" et vérifiez si le poème vous plaît. Gardez ollama en marche car nous aurons besoin d'interagir avec le modèle mistral plus tard par le biais du code.

Créez un nouveau fichier appelé query_masking_local_LLM.py et ajoutez le code ci-dessous.

La réponse ressemble à ce qui est indiqué ci-dessous

Conclusion

Dans cet article, nous avons montré comment protéger les informations confidentielles et les données sensibles lors de l'utilisation de LLM publics dans un flux RAG. Nous avons démontré qu'il y avait plusieurs façons d'y parvenir. Il est fortement recommandé de tester ces approches en fonction de votre cas d'utilisation et de vos besoins avant de les adopter.

Avant de commencer, nous allons examiner quelques termes.

Terminologie

LlamaIndex est un cadre de données de premier plan pour la création d'applications LLM (Large Language Model). LlamaIndex fournit des abstractions pour les différentes étapes de la construction d'une application RAG (Retrieval Augmented Generation). Des structures telles que LlamaIndex et LangChain fournissent des abstractions afin que les applications ne soient pas étroitement liées aux API d'un LLM spécifique.

Elasticsearch est proposé par Elastic. Elastic est un leader de l'industrie avec Elasticsearch, un moteur de recherche et d'analyse qui prend en charge la recherche en texte intégral pour la précision, la recherche vectorielle pour la compréhension sémantique, et la recherche hybride pour le meilleur des deux mondes. Elasticsearch est un magasin de données évolutif et une base de données vectorielle. Les fonctionnalités d'Elasticsearch que nous utilisons dans ce blog sont disponibles dans la version gratuite et ouverte d'Elasticsearch.

Retrieval Augment Generation (RAG) est une technique/un modèle d'IA dans lequel les LLM sont dotés de connaissances externes pour générer des réponses aux requêtes des utilisateurs. Cela permet d'adapter les réponses du programme d'éducation et de formation tout au long de la vie à un contexte spécifique et les réponses sont plus spécifiques.

Mistral propose des modèles LLM open-source et optimisés pour les entreprises. Dans ce tutoriel, nous utiliserons leur modèle open source mistral-7b qui fonctionne sur votre ordinateur portable. Si vous ne souhaitez pas exécuter le modèle sur votre ordinateur portable, vous pouvez utiliser la version en nuage, auquel cas vous devrez modifier le code de ce blog afin d'utiliser les clés et les paquets API appropriés.

Ollama permet d'exécuter des LLM localement sur votre ordinateur portable. Nous utiliserons Ollama pour exécuter localement le modèle open source Mistral-7b.

Les encastrements sont des représentations numériques de la signification d'un texte ou d'un média. Il s'agit de représentations de dimensions inférieures d'informations de dimensions supérieures.

Construire une application RAG avec LlamaIndex, Elasticsearch & Mistral : Aperçu du scénario

Scénario :

Nous disposons d'un échantillon de données (sous forme de fichier JSON) de conversations entre des agents et des clients d'une compagnie d'assurance habitation fictive. Nous allons créer une application RAG simple qui peut répondre à des questions telles que

Give me summary of water related issues.

Débit élevé

Mistral LLM fonctionne localement à l'aide d'Ollama.

Ensuite, nous chargeons les conversations du fichier JSON en tant que Documents dans le magasin ElasticsearchStore (qui est un magasin VectorStore soutenu par Elasticsearch). Lors du chargement des documents, nous créons des enchâssements à l'aide du modèle Mistral exécuté localement. Nous stockons ces encastrements ainsi que les conversations dans le magasin vectoriel Elasticsearch de LlamaIndex(ElasticsearchStore).

Nous configurons une ligne d'ingestion LlamaIndex et lui fournissons le LLM local que nous utilisons, dans ce cas Mistral fonctionnant via Ollama.

Lorsque nous posons une question telle que "Donnez-moi un résumé des problèmes liés à l'eau", Elasticsearch effectue une recherche sémantique et renvoie les conversations liées aux problèmes de l'eau. Ces conversations, ainsi que la question initiale, sont envoyées au LLM local pour générer une réponse.

Étapes de la création de l'application RAG

Exécuter Mistral localement

Téléchargez et installez Ollama. Après avoir installé Ollama, lancez la commande suivante pour télécharger et exécuter mistral

Le téléchargement et l'exécution locale du modèle pour la première fois peuvent prendre quelques minutes. Vérifiez si le mistral fonctionne en posant une question telle que la suivante : "Ecrivez un poème sur les nuages" et vérifiez si le poème vous plaît. Gardez ollama en marche car nous aurons besoin d'interagir avec le modèle mistral plus tard par le biais du code.

Installer Elasticsearch

Faites fonctionner Elasticsearch en créant un déploiement dans le nuage(instructions ici) ou en l'exécutant dans Docker(instructions ici). Vous pouvez également créer un déploiement autonome d'Elasticsearch au niveau de la production en commençant ici.

Si vous utilisez le déploiement dans le nuage, saisissez la clé API et l'ID du nuage pour le déploiement, comme indiqué dans les instructions. Nous les utiliserons plus tard.

Application RAG

Pour référence, le code complet peut être trouvé dans ce dépôt Github. Le clonage de la base de données est facultatif car nous allons parcourir le code ci-dessous.

Dans votre IDE préféré, créez une nouvelle application Python avec les 3 fichiers ci-dessous.

• index.py où se trouve le code lié à l'indexation des données.

• query.py où se trouve le code lié à l'interrogation et à l'interaction avec le LLM.

• .env où se trouvent les propriétés de configuration telles que les clés d'API.

Nous devons installer quelques paquets. Nous commençons par créer un nouvel environnement virtuel python dans le dossier racine de votre application.

Activez l'environnement virtuel et installez les paquets requis ci-dessous.

Indexation des données

Téléchargez le fichier conversations.json qui contient les conversations entre les clients et les agents du centre d'appel de notre compagnie d'assurance habitation fictive. Placez le fichier dans le répertoire racine de l'application avec les 2 fichiers python et le fichier .env. que vous avez créé précédemment. Vous trouverez ci-dessous un exemple du contenu du fichier.

Nous définissons une fonction appelée get_documents_from_file dans index.py qui lit le fichier json et crée une liste de documents. Les objets document sont l'unité de base de l'information avec laquelle LlamaIndex travaille.

Créer un pipeline d'ingestion

Tout d'abord, ajoutez au fichier .env l'Elasticsearch CloudID et les clés API que vous avez obtenues dans la section Install Elasticsearch. Votre fichier .env devrait ressembler à ce qui suit (avec des valeurs réelles).

LlamaIndex IngestionPipeline vous permet de composer un pipeline à l'aide de plusieurs composants. Ajoutez le code ci-dessous au fichier index.py.

Comme nous l'avons déjà mentionné, la LlamaIndex IngestPipeline peut être composée de plusieurs éléments. Nous ajoutons 3 composants au pipeline dans la ligne pipeline = IngestionPipeline(....

• SentenceSplitter: Comme on peut le voir dans la définition de get_documents_from_file(), chaque document possède un champ texte qui contient la conversation trouvée dans le fichier json. Ce champ de texte est un long texte. Pour que la recherche sémantique fonctionne bien, elle doit être décomposée en morceaux de textes plus petits. La classe SentenceSplitter s'en charge pour nous. Ces morceaux sont appelés nœuds dans la terminologie de LlamaIndex. Les nœuds contiennent des métadonnées qui renvoient au document auquel ils appartiennent. Vous pouvez également utiliser Elasticsearch Ingestpipeline pour le découpage, comme indiqué dans ce blog.

• OllamaEmbedding: Les modèles d'incorporation convertissent un texte en nombres (également appelés vecteurs). La représentation numérique nous permet d'effectuer une recherche sémantique où les résultats de la recherche correspondent à la signification du mot plutôt que d'effectuer une simple recherche textuelle. Nous fournissons à l'IngestionPipeline le site OllamaEmbedding("mistral"). Les morceaux que nous découpons à l'aide de SentenceSplitter sont envoyés au modèle Mistral qui s'exécute sur votre machine locale via Ollama, mistral crée alors des embeddings pour les morceaux.

• ElasticsearchStore: Le magasin vectoriel ElasticsearchStore de LlamaIndex sauvegarde les embeddings créés dans un index Elasticsearch. ElasticsearchStore se charge de créer et d'alimenter le contenu de l'index Elasticsearch spécifié. Lors de la création de l'ElasticsearchStore (référencé par es_vector_store), nous fournissons le nom de l'index Elasticsearch que nous voulons créer (calls dans notre cas), le champ de l'index dans lequel nous voulons stocker les embeddings (conversation_vector dans notre cas) et le champ dans lequel nous voulons stocker le texte (conversation dans notre cas). En résumé, selon notre configuration, ElasticsearchStore crée un nouvel index dans Elasticsearch avec conversation_vector et conversation comme champs (parmi d'autres champs créés automatiquement).

Pour relier le tout, nous exécutons le pipeline en appelant pipeline.run(documents=documents).

Lancez le script index.py pour exécuter le pipeline d'ingestion :

Une fois l'exécution du pipeline terminée, nous devrions voir un nouvel index dans Elasticsearch appelé calls. En exécutant une simple requête elasticsearch à l'aide de la Dev Console, vous devriez être en mesure de voir les données chargées avec les embeddings.

Pour résumer ce que nous avons fait jusqu'à présent, nous avons créé des documents à partir d'un fichier JSON, nous les avons divisés en morceaux, nous avons créé des embeddings pour ces morceaux et nous avons stocké les embeddings (et la conversation textuelle) dans un magasin vectoriel (ElasticsearchStore).

Interrogation

Le VectorStoreIndex llamaIndex vous permet de retrouver des documents pertinents et d'interroger des données. Par défaut, VectorStoreIndex stocke les intégrations en mémoire dans un SimpleVectorStore. Cependant, des entrepôts de vecteurs externes (comme ElasticsearchStore) peuvent être utilisés à la place pour rendre les enregistrements persistants.

Ouvrez le site query.py et collez le code ci-dessous

Nous définissons un LLM local (local_llm) pour indiquer le modèle Mistral fonctionnant sur Ollama. Ensuite, nous créons un VectorStoreIndex (index) à partir du magasin de vecteurs ElasticssearchStore que nous avons créé précédemment, puis nous obtenons un moteur de requête à partir de l'index. Lors de la création du moteur de requête, nous référençons le LLM local qui doit être utilisé pour répondre, nous fournissons également (similarity_top_k=10) pour configurer le nombre de documents qui doivent être récupérés dans le magasin vectoriel et envoyés au LLM pour obtenir une réponse.

Lancez le script query.py pour exécuter le flux RAG :

Nous envoyons la demande à Give me summary of water related issues (n'hésitez pas à personnaliser query) et la réponse du LLM, qui est accompagnée des documents correspondants, devrait ressembler à ce qui suit.

Quelques mises en garde :

Cet article de blog est une introduction pour débutants à la technique RAG avec Elasticsearch et omet donc la configuration des fonctionnalités qui vous permettront de passer de ce point de départ à la production. Lorsque vous construisez pour des cas d'utilisation en production, vous voudrez prendre en compte des aspects plus sophistiqués comme la possibilité de protéger vos données avec Document Level Security, le découpage de vos données dans le cadre d'un pipeline d'ingestion Elasticsearch ou même l'exécution d'autres tâches de ML sur les mêmes données que celles utilisées pour les cas d'utilisation GenAI/Chat/Q&A.

Vous pouvez également envisager d'obtenir des données et de créer des embeddings à partir de diverses sources externes (par exemple Azure Blob Storage, Dropbox, Gmail, etc.) à l'aide d'Elastic Connectors.

Elastic rend possible tout ce qui précède et plus encore, et fournit une solution d'entreprise complète pour les cas d'utilisation de la GenAI et au-delà.

Quelle est la suite ?

• Vous avez peut-être remarqué que nous envoyons 10 conversations connexes avec la question de l'utilisateur au LLM pour formuler une réponse. Ces conversations peuvent contenir des IPI (informations personnelles identifiables) telles que le nom, la date de naissance, l'adresse, etc. Dans notre cas, le LLM est local, la fuite de données n'est donc pas un problème. Cependant, lorsque vous souhaitez utiliser un LLM fonctionnant dans le nuage (par exemple OpenAI), il n'est pas souhaitable d'envoyer des textes contenant des informations PII. Dans un blog ultérieur, nous verrons comment masquer les informations PII avant de les envoyer aux LLM externes dans le flux RAG.

• Dans ce billet, nous avons utilisé un LLM local. Dans le prochain billet sur le masquage des données PII dans RAG, nous verrons comment passer facilement d'un LLM local à un LLM public.