Création d'applications d'IA avec une sécurité de niveau entreprise à l'aide de RAG et FGA

Cet article est écrit par Bartosz Pietrucha

Introduction

Créer des applications LLM de niveau entreprise est une nécessité dans l'environnement commercial actuel. Si l'accessibilité des modèles et des API s'améliore, un défi de taille demeure : assurer leur sécurité et gérer efficacement leurs autorisations.

Pour résoudre ce problème, l'autorisation fine (FGA) et la génération augmentée de récupération (RAG) sont des stratégies efficaces pour créer des applications d'IA sécurisées et contextuelles qui maintiennent un contrôle d'accès strict. Dans cet article, nous explorerons comment FGA et RAG peuvent être appliqués dans un environnement de soins de santé tout en protégeant les données sensibles.

Nous le ferons en vous guidant dans la mise en œuvre d'un système d'autorisation de contrôle d'accès basé sur les relations (ReBAC) qui prend en charge les mises à jour en temps réel avec trois outils : AstraDB, Langflow et Permit.io.

Exemple de cas d'utilisation : applications de soins de santé

Pour mieux comprendre la complexité de l'autorisation dans les applications LLM et les solutions proposées par FGA et RAG, nous pouvons examiner le domaine des soins de santé numériques, car il présente un exemple parfait où les capacités d'IA et une sécurité stricte sont essentielles. Les prestataires de soins de santé souhaitent de plus en plus tirer parti des LLM pour rationaliser les flux de travail, améliorer la prise de décision et fournir de meilleurs soins aux patients. Les médecins et les patients souhaitent un accès facile aux dossiers médicaux grâce à des interfaces d'IA intuitives telles que les chatbots.

Cependant, les données médicales sont très sensibles et doivent être soigneusement réglementées. Même si les LLM peuvent fournir des informations intelligentes, nous devons nous assurer qu’ils accèdent et révèlent uniquement les informations que les utilisateurs sont autorisés à voir. Les médecins, par exemple, ne devraient voir que les diagnostics provenant des centres médicaux qui leur sont attribués, et les patients ne devraient pouvoir accéder qu'à leur propre dossier.

Sécurité grâce à une autorisation précise

En continuant avec l'exemple des soins de santé numériques, regardons un exemple d'application médicale.

Cette application comprend plusieurs ressources, quelques rôles et quelques relations entre ces entités :

1. Types de ressources :

   • Centres médicaux (par exemple, Londres, Varsovie)
   • Visites (par exemple, visite du matin, visite de l'après-midi)
   • Diagnostics (par exemple, diabète, maux de tête, virus)

2. Rôles :

   • Médecins (par exemple, Dr Bartosz)
   • Patients (par exemple, Gabriel, Olga)

3. Relations :

   • Les médecins sont affectés aux centres médicaux
   • Les visites appartiennent aux centres médicaux
   • Les diagnostics font partie des visites
   • Les patients sont connectés à leurs visites

Comme vous pouvez le constater, les relations hiérarchiques de nos ressources signifient que la mise en œuvre d'un contrôle d'accès traditionnel basé sur les rôles, où les autorisations sont attribuées directement, sera insuffisante.

La complexité de l'autorisation de ces applications nous obligera à utiliser des solutions d'autorisation plus fines (FGA) - dans ce cas, le contrôle d'accès basé sur les relations (ReBAC).

ReBAC, un modèle d'autorisation inspiré de l'article de Google sur Zanzibar, dérive les autorisations des relations entre les entités du système - contrairement au contrôle d'accès basé sur les rôles (RBAC) traditionnel, où les autorisations sont attribuées directement.

La puissance de ReBAC réside dans la manière dont les autorisations sont dérivées de ces relations. Regardons une représentation visuelle de notre exemple :

Dans l'exemple ci-dessus, le Dr Bartosz a accès au diagnostic du virus non pas grâce à une autorisation directement accordée mais plutôt parce qu'il est affecté au centre médical de Varsovie, qui contient la visite de l'après-midi, qui contient le diagnostic. . Ainsi, les relations entre ces ressources forment une chaîne qui nous permet d'en déduire des autorisations d'accès.

L'utilisation de cette approche présente des avantages évidents :

• Il modélise naturellement les structures organisationnelles du monde réel
• Les autorisations s'adaptent automatiquement à mesure que les relations changent
• Il offre un contrôle précis tout en restant évolutif

Mais le défi ne s'arrête pas là : comme nous construisons un système qui doit fonctionner avec les LLM, il doit avoir la capacité d'évaluer ces chaînes relationnelles en temps réel. Dans la section suivante, nous apprendrons comment créer une implémentation qui permet cela.

Avant de continuer, passons en revue rapidement les règles d'autorisation dont nous voulons nous assurer qu'elles sont en place :

1. Seuls les médecins ayant des relations valides avec un centre médical peuvent voir ses visites
2. L'accès aux diagnostics est automatiquement issu de ces relations
3. Les changements dans les relations (par exemple, la réaffectation du médecin) affectent immédiatement les droits d'accès

Ces exigences peuvent être satisfaites grâce à l'utilisation de la génération augmentée de récupération (RAG).

Génération augmentée de récupération (RAG)

RAG (Retrieval Augmented Generation) est une technique qui améliore les résultats du LLM en combinant deux étapes clés : d'abord, récupérer des informations pertinentes à partir d'une base de connaissances, puis utiliser ces informations pour augmenter le contexte du LLM pour une génération plus précise. Bien que RAG puisse fonctionner avec des bases de données traditionnelles ou des magasins de documents, les bases de données vectorielles sont particulièrement puissantes à cet effet car elles peuvent effectuer une recherche de similarité sémantique, trouvant des informations conceptuellement liées même lorsque les mots-clés exacts ne correspondent pas.

En pratique, cela signifie que lorsqu'un utilisateur pose des questions sur des « problèmes cardiaques », le système peut récupérer des documents pertinents sur des « problèmes cardiaques » ou des « maladies cardiovasculaires », ce qui rend les réponses du LLM à la fois plus précises et plus complètes. La partie « génération » implique ensuite que le LLM synthétise ce contexte récupéré avec ses connaissances pré-entraînées pour produire des réponses pertinentes et factuelles fondées sur vos données spécifiques.

Pour notre implémentation, nous utiliserons AstraDB comme base de données vectorielles. AstraDB offre les avantages suivants :

• Il stocke et recherche efficacement les intégrations
• Il évolue bien avec la croissance des données
• Il s'intègre bien aux chaînes LLM comme Langflow (que nous aborderons plus tard dans l'article)

Pour implémenter notre pipeline RAG, nous utiliserons également LangFlow, un framework open source qui rend la construction de ces systèmes intuitive grâce à son interface visuelle. Les systèmes LangFlow peuvent être développés avec un environnement Python exécuté localement ou sur la plateforme DataStax hébergée dans le cloud. Dans notre cas, nous choisissons la deuxième option en créant une base de données AstraDB sans serveur (vecteur) sous : https://astra.datastax.com

Dans notre implémentation, les contrôles d'autorisation doivent avoir lieu à un moment crucial - après avoir récupéré les données de la base de données vectorielles mais avant de les fournir au LLM comme contexte. De cette façon, nous maintenons l'efficacité de la recherche en trouvant d'abord toutes les informations pertinentes, puis en filtrant les données non autorisées avant qu'elles n'atteignent le LLM. Le LLM ne peut utiliser et révéler que les informations que l'utilisateur est autorisé à voir.

Ces contrôles de sécurité sont mis en œuvre à l'aide de Permit.io, qui fournit l'infrastructure permettant d'évaluer des chaînes relationnelles complexes en temps réel. À mesure que vos données augmentent et que les relations deviennent plus complexes, le système continue de garantir que chaque élément d'information n'est accessible qu'aux personnes disposant de l'autorisation appropriée.

Pour commencer avec Permit, vous pouvez facilement créer un compte gratuit en visitant le site Web à l'adresse https://app.permit.io. Une fois votre compte gratuit créé, vous aurez accès au tableau de bord de Permit, où vous pourrez configurer vos politiques d'autorisation, gérer les utilisateurs et les rôles et intégrer Permit dans vos applications. Le niveau gratuit offre toutes les fonctionnalités nécessaires pour créer un exemple de soins de santé numériques avec contrôle d'accès basé sur les relations (ReBAC).

LangFlow et Permit proposent tous deux des comptes gratuits pour commencer à travailler, vous n'avez donc rien à payer pour construire un tel système et voir comment il fonctionne par vous-même.

Guide de mise en œuvre

Avant de plonger dans les détails de mise en œuvre, il est important de comprendre l'outil que nous utiliserons : Langflow. Construit sur LangChain, Langflow est un framework open source qui simplifie la création d'applications LLM complexes via une interface visuelle. LangChain fournit une base solide en proposant des composants standardisés pour les opérations LLM courantes telles que le fractionnement de texte, la génération d'intégration et les invites de chaîne de pensée. Ces composants peuvent être assemblés dans de puissants pipelines qui gèrent tout, de l'ingestion de données à la génération de réponses.

Ce qui rend Langflow particulièrement précieux pour notre cas d'utilisation est son interface de création visuelle, qui nous permet de construire ces pipelines en connectant les composants graphiquement - de la même manière que vous pourriez dessiner un organigramme. Cette approche visuelle facilite la compréhension et la modification du flux de données à travers notre application, depuis la saisie initiale de l'utilisateur jusqu'à la réponse finale autorisée. De plus, la nature open source de Langflow signifie qu'il est à la fois gratuit et peut être étendu avec des composants personnalisés, ce qui est crucial pour la mise en œuvre de nos contrôles d'autorisation.

Notre solution Langflow exploite deux flux distincts mais interconnectés pour fournir un accès sécurisé aux informations médicales :

1. Flux d'ingestion

Le flux d'ingestion est responsable du chargement des diagnostics dans AstraDB avec leurs intégrations respectives. Nous utilisons MistralAI pour générer des intégrations pour chaque diagnostic, permettant ainsi d'effectuer ultérieurement des recherches sémantiques sur les données de diagnostic. Les éléments clés impliqués dans ce flux sont :

• Créer une liste : Ce composant est utilisé pour créer une liste de diagnostics à ingérer dans AstraDB.
• MistralAI Embeddings : Ce composant génère des intégrations pour chaque diagnostic, qui sont stockées dans AstraDB.
• AstraDB : AstraDB sert de magasin de vecteurs où les diagnostics et leurs intégrations sont stockés pour une récupération ultérieure.

2. Flux de discussion

Le flux de discussion est chargé d'interagir avec les utilisateurs et de leur fournir les données de diagnostic requises. Les images ci-dessous sont censées être lues de gauche à droite (le côté droit de la première continue comme le côté gauche de la seconde) :

? Remarque : Il existe un composant supplémentaire «_ Pip Install» _ qui n'est exécuté qu'une seule fois pour installerpermis module. En effet, nous implémentons LangFlow sur la plateforme low-code DataStax. Cette étape équivaut à exécuter pip install permit localement.

La séquence d'opérations dans le Chat Flow est la suivante :

1. Entrée utilisateur : L'utilisateur lance l'interaction en tapant une requête.

• Exemple : "Avons-nous des patients avec un diagnostic de diabète ?"

1. Récupérer les diagnostics : AstraDB est interrogé pour les diagnostics pertinents en fonction de la saisie de l'utilisateur.

• Exemple de résultat de recherche (marqué de 1 sur l'image du flux ci-dessus) :

1. Filtrer les données en fonction des autorisations : Avant d'envoyer la réponse au composant de traitement suivant, créant le contexte pour que LLM réponde à la requête initiale, nous filtrons les diagnostics récupérés à l'aide d'un composant PermitFilter personnalisé pour garantir que l'utilisateur a le droit pour visualiser chaque diagnostic.

• Exemple de résultats filtrés (marqués de 2 sur l'image de flux ci-dessus) :

1. Générer une réponse : Une fois filtrés, les diagnostics autorisés sont utilisés comme contexte pour générer une réponse à l'invite utilisateur à l'aide de MistralAI.

• Exemple d'invite avec contexte filtré avec étape d'autorisation :

Seasonal Migraine
Flu virus with high fever

---
You are a doctor's assistant and help to retrieve information about patients' diagnoses.
Given the patients' diagnoses above, answer the question as best as possible.
The retrieved diagnoses may belong to multiple patients.

Question: list all the recent diagnoses

Answer: 

Composant PermitFilter

Pour exécuter le composant PermitFilter, qui joue un rôle crucial dans notre implémentation, nous avons besoin d'une instance en cours d'exécution du point de décision politique (PDP) de Permit. Le PDP est chargé d'évaluer les politiques et de prendre des décisions quant à savoir si une action donnée est autorisée pour un utilisateur et une ressource spécifiques. En appliquant cette vérification d'autorisation avant que le contexte atteigne le modèle de langage, nous empêchons la fuite d'informations sensibles et garantissons l'application des politiques de contrôle d'accès.

Voyez-le en action

L'implémentation complète est disponible dans notre référentiel GitHub, où vous trouverez :

• Composants LangFlow personnalisés
• Code d'intégration Permit.io
• Instructions de configuration détaillées
• Exemples de requêtes et de réponses

Pour commencer à interagir avec notre assistant IA avec les contrôles d'autorisation mis en œuvre, nous pouvons simplement démarrer le terrain de jeu LangFlow. Dans l'exemple ci-dessous, je suis authentifié en tant que bartosz@health.app, ce qui signifie que j'ai accès uniquement aux visites de l'après-midi et aux visites du soir sansVisites du matin avec diabète. Cela signifie que le LLM ne dispose pas d'informations sur le diabète dans son contexte.

Conclusion

Sécuriser l'accès aux données de santé sensibles tout en tirant parti des capacités LLM est à la fois une priorité et un défi. En combinant RAG et autorisation fine, nous pouvons créer des applications d’IA à la fois intelligentes et sécurisées. Les principaux avantages sont :

• Réponses contextuelles via RAG
• Contrôle d'accès précis grâce à ReBAC
• Modélisation naturelle des relations organisationnelles
• Une sécurité évolutive qui s'adapte à l'évolution des relations

À l'aide d'outils tels que LangFlow et Permit.io, les prestataires de soins de santé peuvent mettre en œuvre des systèmes de contrôle d'accès basés sur les relations qui répondent de manière dynamique aux changements de rôle et de relation, garantissant que les données ne sont accessibles qu'aux personnes autorisées. En intégrant ces solutions, les organismes de santé peuvent exploiter efficacement l'IA pour améliorer les soins aux patients sans compromettre la sécurité.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!