Protéger les informations sensibles et PII dans RAG avec Elasticsearch et LlamaIndex

Elasticsearch dispose d'intégrations natives avec les outils et fournisseurs d'IA générative leaders du secteur. Consultez nos webinars sur le dépassement des bases de RAG ou sur la création d'applications prêtes à l'emploi avec la Base vectorielle Elastic.

Pour élaborer les meilleures solutions de recherche pour votre cas d'utilisation, commencez un essai gratuit d'Elastic Cloud ou essayez Elastic sur votre machine locale dès maintenant.

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.

Les clients ont fait part de diverses réclamations liées à l'eau, notamment des dégâts d'eau dans les sous-sols, des éclatements de canalisations, des dommages causés aux toits par la grêle et des inondations en cas de fortes pluies. Ces demandes ont engendré des frustrations en raison de refus de demandes fondés sur des motifs tels que l'absence de notification en temps utile, les problèmes d'entretien, l'usure progressive et les dommages préexistants. Les clients ont fait part de leur déception, de leur stress et de leur charge financière à la suite de ces refus, et ont demandé des évaluations équitables et des examens approfondis de leurs demandes d'indemnisation. Certains clients ont également été confrontés à des retards dans le traitement des demandes d'indemnisation, ce qui a aggravé leur mécontentement à l'égard du service fourni par la compagnie d'assurance.

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 :

Client : Bonjour, je m'appelle Matthew Lopez, je suis né le 12 octobre 1984 et j'habite au 456 Cedar St, Smalltown, NY 34567. Mon numéro de police est TUV8901. Agent : Bonjour, Matthew. Comment puis-je vous aider aujourd'hui ? Le client : Bonjour, je suis extrêmement déçu de la décision de votre société de refuser ma demande d'indemnisation.

Texte masqué par le CustomPostProcessor.

Client : Bonjour, je m'appelle [MASKED], [MASKED] est [DOB MASKED], et j'habite au 456 Cedar St, [MASKED], [MASKED] 34567. Mon numéro de police est [MASKED]. Agent : Bonjour, [MASQUÉ]. Comment puis-je vous aider aujourd'hui ? Le client : Bonjour, je suis extrêmement déçu de la décision de votre société de refuser ma demande d'indemnisation.

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

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

Des clients ont déposé des demandes d'indemnisation pour des dommages causés par des incendies à leurs propriétés. Dans un cas, une demande d'indemnisation pour des dommages causés par l'incendie d'un garage a été refusée parce que l'incendie criminel était exclu de la couverture. Un autre client a déposé une demande d'indemnisation pour des dommages causés par un incendie à sa maison, qui étaient couverts par sa police. En outre, un client a signalé un incendie dans sa cuisine et a reçu l'assurance que les dommages causés par l'incendie étaient couverts.

Utilisation de LLM locaux via

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

Des clients ont déposé des demandes d'indemnisation pour des dommages causés par des incendies à leurs propriétés. Dans un cas, une demande d'indemnisation pour des dommages causés par l'incendie d'un garage a été refusée parce que l'incendie criminel était exclu de la couverture. Un autre client a déposé une demande d'indemnisation pour des dommages causés par un incendie à sa maison, qui étaient couverts par sa police. En outre, un client a signalé un incendie dans sa cuisine et a reçu l'assurance que les dommages causés par l'incendie étaient couverts.

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.