Guide de conception d’une solution d’inférence RAG multilocataire sécurisée

La génération augmentée de récupération (RAG) est un modèle permettant de créer des applications où les modèles fondamentaux sont utilisés pour raisonner sur des informations propriétaires ou d’autres informations qui ne sont pas accessibles publiquement sur Internet. En règle générale, une application cliente appelle une couche d’orchestration qui récupère des informations pertinentes à partir d’un magasin de données, comme une base de données vectorielle. La couche d’orchestration transmet ces données dans le cadre du contexte en tant que données de base au modèle fondamental.

Une solution multilocataire est utilisée par plusieurs clients, où chaque client (locataire) se compose de plusieurs utilisateurs de la même organisation, société ou groupe. Dans les scénarios multilocataires, vous devez vous assurer que les locataires, ou les individus au sein des locataires, ne peuvent incorporer que des données de base qu’elles sont autorisées à voir.

Bien qu’il existe des préoccupations multilocataires au-delà de s’assurer que les utilisateurs accèdent uniquement aux informations qu’ils sont censés voir, cet article se concentre sur cet aspect de la multilocataire. L’article commence par une vue d’ensemble des architectures RAG à locataire unique, aborde les défis liés à l’architecture multilocataire avec RAG et certaines approches courantes à suivre, et conclut par des considérations et recommandations multilocataires sécurisées.

Architecture RAG à locataire unique avec orchestrateur

Figure 1. Architecture RAG monolocataire

Workflow

Dans cette architecture RAG à locataire unique, un orchestrateur a la responsabilité d’extraire les données de locataire propriétaire pertinentes des magasins de données et de les fournir en tant que données de base au modèle fondamental. Voici un flux de travail de haut niveau :

1. Un utilisateur émet une demande à l’application web intelligente.
2. Un fournisseur d’identité authentifie le demandeur.
3. L’application intelligente appelle l’API orchestrator avec la requête utilisateur et le jeton d’autorisation de l’utilisateur.
4. La logique d’orchestration extrait la requête de l’utilisateur et appelle le magasin de données approprié pour extraire les données de base pertinentes pour la requête. Les données de base sont ajoutées à l’invite envoyée au modèle fondamental, par exemple un modèle exposé dans Azure OpenAI, à l’étape suivante.
5. La logique d’orchestration se connecte à l’API d’inférence du modèle fondamental et envoie l’invite qui inclut les données de base récupérées. Les résultats sont retournés à l’application intelligente.

Pour plus d’informations sur les détails de RAG, consultez Conception et développement d’une solution RAG.

Architecture RAG à locataire unique avec accès direct aux données

Une variante de l’architecture RAG à locataire unique tire parti de la capacité du service Azure OpenAI à s’intégrer directement aux magasins de données tels que Recherche Azure. Dans cette architecture, vous n’avez pas votre propre orchestrateur, ou votre orchestrateur a moins de responsabilités. L’API Azure OpenAI a la responsabilité d’appeler le magasin de données pour extraire les données de base et transmettre ces données au modèle de langage. Vous avez, à son tour, moins de contrôle sur les données de base pour extraire et la pertinence de ces données.

Figure 2 : Architecture RAG à locataire unique avec accès direct aux données à partir du service Azure OpenAI

Workflow

Dans cette architecture RAG, le service fournissant le modèle fondamental a la responsabilité d’extraire les données de locataire propriétaire appropriées des magasins de données et d’utiliser ces données comme base de données au modèle fondamental. Voici un flux de travail de haut niveau (les étapes italiques sont identiques à l’architecture RAG à locataire unique avec workflow d’orchestrateur) :

1. Un utilisateur émet une demande à l’application web intelligente.
2. Un fournisseur d’identité authentifie le demandeur.
3. L’application intelligente appelle ensuite le service Azure OpenAI avec la requête utilisateur.
4. Le service Azure OpenAI se connecte aux magasins de données pris en charge, tels qu’Azure AI Search et le stockage Blob Azure pour extraire les données de base. Les données de base sont utilisées dans le contexte lorsque le service Azure OpenAI appelle le modèle de langage OpenAI. Les résultats sont retournés à l’application intelligente.

Pour prendre en compte cette architecture dans une solution multilocataire, le service, tel qu’Azure OpenAI, qui accède directement aux données de base doit prendre en charge la logique multilocataire requise par votre solution.

Architecture multilocataire dans l’architecture RAG

Dans les solutions mutualisées, les données de locataire peuvent exister dans un magasin spécifique au locataire ou coexister avec d’autres locataires dans un magasin multilocataire. Il peut également y avoir des données dans un magasin partagé entre les locataires. Seules les données que l’utilisateur est autorisé à voir doivent être utilisées comme données de base. Les utilisateurs ne doivent voir que les données courantes (tous les locataires) ou les données de leur locataire avec des règles de filtrage appliquées pour s’assurer qu’elles voient uniquement les données qu’ils sont autorisées à voir.

Figure 3 : Architecture RAG - avec plusieurs locataires de magasin de données

Workflow

Ce flux de travail est le même que dans l’architecture RAG à locataire unique avec orchestrateur à l’exception de l’étape 4.

1. Un utilisateur émet une demande à l’application web intelligente.
2. Un fournisseur d’identité authentifie le demandeur.
3. L’application intelligente appelle l’API orchestrator avec la requête utilisateur et le jeton d’autorisation de l’utilisateur.
4. La logique d’orchestration extrait la requête de l’utilisateur à partir de la requête et appelle les magasins de données appropriés pour extraire les données de base autorisées par le locataire et pertinentes pour la requête. Les données de mise à la terre sont intégrées à la requête, qui est ensuite envoyée à Azure OpenAI. Certaines ou toutes les étapes suivantes sont impliquées :
   1. La logique d’orchestration extrait les données de base de l’instance de magasin de données spécifique au locataire appropriée, ce qui risque d’appliquer des règles de filtrage de sécurité pour retourner uniquement les données que l’utilisateur est autorisé à accéder.
   2. La logique d’orchestration extrait les données de base du locataire appropriés à partir du magasin de données mutualisé, ce qui risque d’appliquer des règles de filtrage de sécurité pour retourner uniquement les données que l’utilisateur est autorisé à accéder.
   3. La logique d’orchestration extrait les données d’un magasin de données partagé entre les locataires.
5. La logique d’orchestration se connecte à l’API d’inférence du modèle fondamental et envoie l’invite qui inclut les données de base récupérées. Les résultats sont retournés à l’application intelligente.

Considérations relatives à la conception pour les données mutualisées dans RAG

Choix des modèles d’isolation de magasin

Il existe deux approches architecturales principales pour le stockage et les données dans des scénarios multilocataires : magasin par locataire et magasins mutualisés. Ces approches sont en plus des magasins qui contiennent des données partagées entre les locataires. Cette section traite de chaque approche. Notez que votre solution multilocataire peut utiliser une combinaison de ces approches.

Magasin par locataire

Dans le magasin par locataire, comme le suggère le nom, chaque locataire a son propre magasin. Les avantages de cette approche incluent l’isolation des données et des performances. Les données de chaque locataire sont encapsulées dans son propre magasin. Dans la plupart des services de données, les magasins isolés ne sont pas sensibles au problème de voisin bruyant d’autres locataires. Cette approche simplifie également l’allocation des coûts, car l’intégralité du coût d’un déploiement de magasin peut être attribuée à un seul locataire.

Les défis de cette approche incluent potentiellement des frais de gestion et d’exploitation plus élevés et des coûts plus élevés. Cette approche ne doit pas être prise en compte lorsqu’il existe un grand nombre de petits locataires tels que des scénarios d’entreprise à consommateur. Cette approche peut également s’exécuter contre les limitations du service.

Dans le contexte de ce scénario d’IA, un magasin par locataire signifie que les données de base nécessaires pour intégrer la pertinence dans le contexte proviennent d’un magasin de données existant ou nouveau qui contient uniquement des données de base pour le locataire. Dans cette topologie, l’instance de base de données est le discriminateur utilisé par locataire.

Magasins multilocataire

Dans les magasins multilocataires, plusieurs données de locataires coexistent dans le même magasin. Les avantages de cette approche incluent le potentiel d’optimisation des coûts, la possibilité de gérer un nombre plus élevé de locataires que le modèle store par locataire et une surcharge de gestion inférieure en raison du nombre inférieur d’instances de magasin.

Les défis liés à l’utilisation des magasins partagés incluent la nécessité de garantir l’isolation des données, la gestion des données, le potentiel d’antimodèle voisin bruyant et la difficulté à allouer des coûts aux locataires. S’assurer que l’isolation des données est la préoccupation la plus importante de cette approche. Vous avez la responsabilité d’implémenter l’approche de sécurité pour vous assurer que les locataires sont uniquement en mesure d’accéder à leurs données. La gestion des données peut également être un défi si les locataires ont des cycles de vie de données différents qui peuvent nécessiter des opérations telles que la création d’index selon des planifications différentes.

Certaines plateformes ont des fonctionnalités dont vous pouvez tirer parti lorsque vous implémentez l’isolation des données client dans des magasins partagés. Par exemple, Azure Cosmos DB prend en charge nativement le partitionnement et le partitionnement, et il est courant d’utiliser un identificateur de locataire comme clé de partition pour fournir un niveau d’isolation entre les locataires. Azure SQL et Postgres Flex prennent en charge la sécurité au niveau des lignes, bien que cette fonctionnalité ne soit pas couramment utilisée dans les solutions mutualisées, car vous devez concevoir votre solution autour de ces fonctionnalités si vous envisagez de les utiliser dans votre magasin multilocataire.

Dans le contexte de ce scénario d’INTELLIGENCE artificielle, cela signifierait que les données de base pour tous les locataires sont issues du même magasin de données, de telle sorte que votre requête vers ce magasin de données doit contenir un discriminateur de locataire pour garantir que les réponses sont limitées à ramener uniquement les données pertinentes dans le contexte du locataire.

Magasins partagés

Les solutions mutualisées ont souvent des données partagées entre les locataires. Dans un exemple de solution multilocataire pour le domaine de la santé, il peut y avoir une base de données qui stocke des informations médicales générales ou des informations qui ne sont pas spécifiques au locataire.

Dans le contexte de ce scénario d’IA, il s’agirait d’un magasin de données de base généralement accessible qui n’a pas spécifiquement besoin de filtrer en fonction de n’importe quel locataire, car les données sont pertinentes et autorisées pour tous les locataires du système.

Identité

L’identité est un aspect clé des solutions multilocataires, notamment le RAG multilocataire sécurisé. L’application intelligente doit s’intégrer à un fournisseur d’identité (IdP) pour authentifier l’identité de l’utilisateur. La solution RAG multilocataire a besoin d’un répertoire d’identité où les identités faisant autorité ou les références aux identités sont stockées. Cette identité doit transiter par la chaîne de requêtes, ce qui permet aux services en aval tels que l’orchestrateur ou même le magasin de données lui-même d’identifier l’utilisateur.

Vous avez également besoin d’un moyen de mapper un utilisateur à un locataire afin de pouvoir accorder l’accès à ces données de locataire.

Définir vos exigences de locataire et d’autorisation

Lors de la création d’une solution RAG mutualisée, vous devez définir ce qu’est un locataire pour votre solution. Les deux modèles courants à choisir sont b2B (business-to-business) et b2C (business-to-consumer). Cette détermination vous aide à vous informer des domaines que vous devez prendre en compte lorsque vous concevez votre solution. Comprendre le nombre de locataires est essentiel pour décider du modèle de magasin de données. Un grand nombre de locataires peut nécessiter un modèle avec plusieurs locataires par magasin, tandis qu’un nombre plus petit peut permettre un magasin par modèle de locataire. La quantité de données par locataire est également importante. Si les locataires ont de grandes quantités de données qui peuvent vous empêcher d’utiliser des magasins multilocataires en raison de limitations de taille sur le magasin de données.

Dans les charges de travail existantes qui sont développées pour prendre en charge ce scénario IA, vous avez peut-être déjà fait ce choix. En règle générale, vous serez en mesure d’utiliser votre topologie de stockage de données existante pour les données de base si ce magasin de données peut fournir une pertinence suffisante et répondre à toutes les autres exigences non fonctionnelles. Toutefois, si vous introduisez de nouveaux composants tels qu’un magasin de recherche vectorielle dédié comme magasin de base dédié, vous devez prendre cette décision, en tenant compte de facteurs tels que votre stratégie d’empreinte de déploiement actuelle, l’impact du plan de contrôle d’application et les différences de cycle de vie des données par locataire (telles que les situations de paiement à la performance).)

Une fois que vous avez défini ce qu’est un locataire pour votre solution, vous devez ensuite définir vos exigences d’autorisation pour les données. Bien que les locataires accèdent uniquement aux données de leur locataire, vos exigences d’autorisation peuvent être plus granulaires. Par exemple, dans une solution de santé, vous pouvez avoir des règles telles que :

• Un patient ne peut accéder qu’à ses propres données de patient
• Un professionnel de la santé peut accéder aux données de ses patients
• Un utilisateur financier peut accéder uniquement aux données relatives aux finances
• Un auditeur clinique peut voir toutes les données des patients
• Tous les utilisateurs peuvent accéder aux connaissances médicales de base dans un magasin de données partagé

Dans une application RAG basée sur des documents, vous pouvez restreindre l’accès des utilisateurs aux documents en fonction d’un schéma d’étiquetage ou de niveaux de confidentialité définis sur des documents.

Une fois que vous avez une définition de ce qu’est un locataire et que vous avez une compréhension claire des règles d’autorisation, utilisez ces informations comme exigences pour votre solution de magasin de données.

Filtrage

Le filtrage, également appelé filtrage de sécurité, fait référence à l’exposition uniquement des données aux utilisateurs qu’ils sont autorisés à voir. Dans un scénario RAG multilocataire, un utilisateur peut être mappé à un magasin spécifique au locataire. Cela ne signifie pas que l’utilisateur doit pouvoir accéder à toutes les données de ce magasin. Dans Définir vos exigences de locataire et d’autorisation, nous avons abordé l’importance de définir les exigences d’autorisation pour vos données. Ces règles d’autorisation doivent être utilisées comme base pour le filtrage.

Le filtrage peut être effectué à l’aide de fonctionnalités de plateforme de données telles que la sécurité au niveau des lignes ou nécessite une logique personnalisée, des données ou des métadonnées. Là encore, ces fonctionnalités de plateforme ne sont pas couramment utilisées dans les solutions mutualisées en raison de la nécessité de concevoir votre système autour de ces fonctionnalités.

Encapsulation de la logique de données mutualisée

Il est recommandé d’avoir une API devant le mécanisme de stockage que vous utilisez. L’API agit en tant que gardien de contrôle, en appliquant que les utilisateurs n’ont accès qu’aux informations auxquelles ils doivent accéder.

Figure 4. Architecture RAG multilocataire avec une API encapsulant une logique d’accès aux données de locataire mutualisée

Comme indiqué précédemment dans cet article, l’accès utilisateur aux données peut être limité par :

• Locataire de l’utilisateur
• Fonctionnalités de la plate-forme
• Règles de filtrage/découpage de sécurité personnalisées.

Cette couche doit avoir les responsabilités suivantes :

• Acheminer la requête vers un magasin spécifique au locataire dans un modèle store par locataire
• Sélectionner uniquement les données du locataire de l’utilisateur dans les magasins multilocataires
• Utiliser l’identité appropriée pour un utilisateur pour prendre en charge la logique d’autorisation compatible avec la plateforme
• Appliquer une logique de découpage de sécurité personnalisée
• Stocker les journaux d’accès des informations de base à des fins d’audit

Le code qui doit accéder aux données du locataire ne doit pas être en mesure d’interroger directement les magasins back-end. Toutes les demandes de données doivent transiter par cette couche API. Cette couche d’API fournit un point de gouvernance unique ou une couche de sécurité au-dessus de vos données de locataire. Cette approche permet au locataire et à l’utilisateur d’accéder à la logique d’autorisation d’accès aux données de saigner dans différentes zones de l’application. Cette logique est encapsulée dans la couche API. Cette encapsulation facilite la validation et le test de la solution.

Résumé

Lors de la conception d’une solution d’inférence RAG multilocataire, vous devez tenir compte de la façon d’concevoir la solution de données de base pour vos locataires. Découvrez le nombre de locataires et la quantité de données par locataire que vous stockez. Ces informations vous aident à concevoir votre solution de location de données. Nous vous recommandons d’implémenter une couche d’API qui encapsule la logique d’accès aux données, y compris la logique multilocataire et de filtrage.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

• John Downs | Ingénieur logiciel principal
• Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data &AI

Étapes suivantes

Ressources associées

• Architecture de solution SaaS et multilocataire
• Architecture de référence de chat de bout en bout de base pour OpenAI
• Architecture de référence de conversation de bout en bout OpenAI
• Accédez à Azure OpenAI et à d'autres modèles de langage via une passerelle