Partager via

Concevoir une solution d’inférence RAG multilocataire sécurisée

  • Article

Retrieval-Augmented Generation (RAG) est un modèle permettant de créer des applications qui utilisent des modèles fondamentaux pour raisonner sur des informations propriétaires ou d’autres données 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 mutualisée est utilisée par plusieurs clients. Chaque client ou 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 personnes au sein des locataires ne peuvent incorporer que des données de base auxquelles ils sont autorisés à accéder.

Il existe des préoccupations liées à l'architecture multilocataire autres que le fait de veiller à ce que les utilisateurs accèdent uniquement aux informations auxquelles ils sont autorisés à accéder. Toutefois, cet article se concentre sur cet aspect spécifique de l’architecture mutualisée. Cet article commence par une vue d’ensemble des architectures RAG à locataire unique. Il aborde les défis que vous pouvez rencontrer dans la mutualisation avec RAG et certaines approches courantes à adopter. Il décrit également les considérations et recommandations relatives à l'architecture multilocataire destinées à améliorer la sécurité.

Remarque

Cet article décrit plusieurs fonctionnalités spécifiques à Azure OpenAI Service, telles que la fonctionnalité Azure OpenAI Sur vos données. Toutefois, vous pouvez appliquer la plupart des principes décrits dans cet article aux modèles IA fondamentaux sur n’importe quelle plateforme.

Architecture RAG à locataire unique avec un orchestrateur

Diagramme montrant une architecture RAG qui utilise une instance de base de données monolocataire.

Flux de travail

Dans cette architecture RAG monolocataire, un orchestrateur extrait les données de locataire propriétaire pertinentes des magasins de données et les fournit en tant que données de base au modèle fondamental. Les étapes suivantes décrivent 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 de l’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, comme 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, consultez Conception et développement d’une solution RAG.

Architecture RAG monolocataire avec accès direct aux données

Cette variante de l’architecture RAG monolocataire utilise la fonctionnalité Sur vos données d’Azure OpenAI pour s’intégrer directement aux stockages de données tels qu’Azure AI Search. Dans cette architecture, vous n’avez pas votre propre orchestrateur, ou votre orchestrateur a moins de responsabilités. L’API Azure OpenAI appelle le magasin de données pour extraire les données de base et passer ces données au modèle de langage. Cette méthode vous donne moins de contrôle sur les données de référence à récupérer et sur la pertinence de ces données.

Remarque

Azure OpenAI est géré par Microsoft. Il s’intègre au magasin de données, mais le modèle lui-même ne s’intègre pas au magasin de données. Le modèle reçoit des données de base de la même façon que lorsqu’un orchestrateur récupère les données.

Diagramme montrant une architecture RAG qui utilise l’accès direct Azure OpenAI à une instance de base de données monolocataire.

Flux de travail

Dans cette architecture RAG, le service qui fournit le modèle de base extrait les données de locataire propriétaire appropriées à partir des magasins de données et utilise ces données comme données de base au modèle fondamental. Les étapes suivantes décrivent un flux de travail de haut niveau. Les étapes en italiques sont identiques à l’architecture RAG monolocataire précédente ayant un 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 Azure OpenAI avec la requête de l’utilisateur.
  4. Azure OpenAI se connecte aux magasins de données pris en charge, tels que la recherche IA et le stockage Blob Azure, pour extraire des données de référence. Les données de base sont utilisées dans le contexte quand Azure OpenAI appelle le modèle de langage OpenAI. Les résultats sont retournés à l’application intelligente.

Si vous souhaitez utiliser cette architecture dans une solution mutualisée, le service qui accède directement aux données de base, comme Azure OpenAI, doit prendre en charge la logique multilocataire requise par votre solution.

Architecture multilocataire dans le modèle 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. Les données peuvent également se trouver dans un magasin partagé entre les locataires. Seules les données autorisées par l’utilisateur à accéder doivent être utilisées comme données de base. L’utilisateur doit voir uniquement les données communes, les données pour tous les locataires ou les données de son locataire filtrées pour s’assurer qu’il ne voit que les données auxquelles il est autorisé à accéder.

Diagramme montrant une architecture RAG qui utilise une base de données partagée, une base de données mutualisée et deux bases de données monolocataires.

Flux de travail

Les étapes suivantes décrivent un flux de travail de haut niveau. Les étapes en italique sont identiques à l’architecture RAG à locataire unique avec un flux de travail 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 l’API orchestrator avec la requête de l’utilisateur et le jeton d’autorisation de l’utilisateur.
  4. La logique d’orchestration extrait la requête de l’utilisateur à partir de la demande et appelle les sources de données appropriées pour extraire les données de base autorisées par le locataire et pertinentes pour la requête. Les données de base sont ajoutées à l’invite envoyée à Azure OpenAI à l’étape suivante. Certaines ou toutes les étapes suivantes sont incluses :
    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 et applique potentiellement des règles de filtrage de sécurité pour retourner uniquement les données auxquelles l’utilisateur est autorisé à accéder.
    2. La logique d'orchestration extrait les données de base du locataire approprié à partir du stockage de données multitenant et applique potentiellement des règles de filtrage de sécurité pour retourner uniquement les données auxquelles 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

Tenez compte des options suivantes lorsque vous concevez votre solution d’inférence RAG multilocataire.

Choisir un modèle d’isolation de magasin

Les deux approches architecturales principales pour le stockage et les données dans des scénarios multilocataires sont le magasin par locataire et les magasins multilocataires. Ces approches s'ajoutent aux magasins qui contiennent des données partagées entre les locataires. Votre solution mutualisée peut utiliser une combinaison de ces approches.

Magasins dédiés par locataire

Dans les magasins dédiés pour chaque locataire, 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 sujets au problème d'interférence causé par d'autres locataires. Cette approche simplifie également l’allocation des coûts, car le coût entier d’un déploiement de magasin peut être attribué à un seul locataire.

Cette approche peut présenter des défis tels que l’augmentation de la gestion et des frais opérationnels et des coûts plus élevés. Vous ne devez pas utiliser cette approche si vous avez un grand nombre de petits locataires, comme dans les scénarios business-to-consumer. Cette approche peut également atteindre ou dépasser les limites de 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é pour chaque locataire.

Magasins multi-locataires

Dans les magasins multilocataires, les données de plusieurs 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 de magasins partagés incluent le besoin d’isolation et de gestion des données, le potentiel pour les antimodèles de voisins bruyants et l’allocation de coûts plus complexe aux locataires. L’isolation des données est la préoccupation la plus importante lorsque vous utilisez cette approche. Vous devez implémenter des approches sécurisées pour vous assurer que les locataires peuvent uniquement accéder à leurs données. La gestion des données peut également être difficile si les locataires ont des cycles de vie de données différents qui nécessitent des opérations telles que la création d’index selon des planifications différentes.

Certaines plateformes ont des fonctionnalités que vous pouvez utiliser 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 sharding des données. Il est courant d’utiliser un identificateur de locataire comme clé de partition pour fournir une certaine isolation entre les locataires. Azure SQL et Azure Database pour PostgreSQL - Serveur flexible prennent en charge la sécurité au niveau des lignes. Toutefois, ces fonctionnalités ne sont généralement pas utilisées 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 cadre de ce scénario d'intelligence artificielle, les données de base pour tous les locataires se mélangent dans le même entrepôt de données. Par conséquent, votre requête à ce magasin de données doit inclure un discriminateur de locataire pour vous assurer que les réponses sont limitées pour ramener uniquement les données pertinentes dans le contexte du locataire.

Magasins partagés

Les solutions mutualisées partagent souvent des données entre locataires. Dans un exemple de solution multilocataire pour le domaine de la santé, une base de données peut stocker 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, le magasin de données de base est généralement accessible et n’a pas besoin de filtrer en fonction de locataires spécifiques, 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, y compris les solutions RAG multilocataires. L’application intelligente doit s’intégrer à un fournisseur d’identité pour authentifier l’identité de l’utilisateur. La solution RAG multilocataire a besoin d’un répertoire d’identité qui stocke les identités faisant autorité ou les références aux identités. Cette identité doit transiter par la chaîne de requêtes et autoriser les services en aval, tels que l’orchestrateur ou le magasin de données lui-même, à identifier l’utilisateur.

Vous avez également besoin d’un moyen d'associer un utilisateur à un locataire afin de pouvoir accorder l’accès à des données de ce locataire.

Définir vos exigences de locataire et d’autorisation

Lorsque vous construisez une solution RAG multilocataire, vous devez définir ce qu’est un locataire pour votre solution. Les deux modèles courants à choisir sont des modèles business-to-business et business-to-consumer. Le modèle que vous choisissez vous aide à déterminer les autres facteurs que vous devez prendre en compte lorsque vous générez votre solution. Comprendre le nombre de locataires est essentiel pour choisir le modèle de magasin de données. Un grand nombre de locataires peut nécessiter un modèle qui a plusieurs locataires pour chaque magasin. Un plus petit nombre de locataires peut permettre un modèle de magasin par locataire. La quantité de données pour chaque locataire est également importante. Les locataires qui ont de grandes quantités de données peuvent vous empêcher d’utiliser des magasins multilocataires en raison de limitations de taille concernant le magasin de données.

Si vous envisagez d’étendre une charge de travail existante pour prendre en charge ce scénario IA, vous avez peut-être déjà pris cette décision. En règle générale, vous pouvez 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 envisagez d’introduire de nouveaux composants, tels qu’un magasin de recherche vectorielle dédié comme magasin d'ancrage dédié, vous devez toujours prendre cette décision. Tenez compte de facteurs tels que votre stratégie de déploiement actuelle, l'impact du plan de contrôle de votre application et les différences de cycle de vie des données par locataire, comme dans les situations de paiement à la performance.

Après avoir défini ce qu’est un locataire pour votre solution, vous devez définir vos exigences d’autorisation pour les données. Les locataires accèdent uniquement aux données de leur locataire, mais 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 liées 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 un document, vous pouvez restreindre l’accès des utilisateurs aux documents en fonction d’un schéma d’étiquetage ou de niveaux de confidentialité attribués aux 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 des données

Restreindre l'accès uniquement aux données que les utilisateurs sont autorisés à consulter est connu sous le nom de filtrage ou filtrage de sécurité. 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. Définir vos exigences de locataire et d’autorisation décrit l’importance de définir les exigences d’autorisation pour vos données. Vous devez utiliser ces règles d’autorisation comme base pour le filtrage.

Vous pouvez utiliser des fonctionnalités de plateforme de données telles que la sécurité au niveau des lignes pour implémenter le filtrage. Vous pouvez également avoir besoin d’une logique personnalisée, de données ou de métadonnées. Ces fonctionnalités de plateforme ne sont généralement pas utilisées dans les solutions mutualisées, car vous devez concevoir votre système autour de ces fonctionnalités.

Encapsuler une logique de données multilocataire

Nous vous recommandons d’avoir une API devant le mécanisme de stockage que vous utilisez. L’API agit comme un gardien de contrôle qui permet de s’assurer que les utilisateurs n’ont accès qu’aux informations auxquelles ils sont autorisés à accéder.

Diagramme montrant une architecture RAG avec une base de données partagée, une base de données mutualisée et deux bases de données monolocataires. Une couche API se trouve entre l’orchestrateur et les bases de données.

L’accès des utilisateurs aux données peut être limité par :

  • Le locataire de l’utilisateur.
  • Fonctionnalités de la plateforme.
  • Règles de filtrage ou de découpage de sécurité personnalisées.

La couche API doit :

  • Routez la requête vers un magasin dédié au locataire dans un modèle magasin-par-locataire.
  • Sélectionnez uniquement les données du locataire de l’utilisateur dans les magasins multilocataires.
  • Utilisez l’identité appropriée pour un utilisateur pour prendre en charge la logique d’autorisation compatible avec la plateforme.
  • Imposer une logique de filtrage de sécurité personnalisée.
  • Stockez les journaux d’accès des informations de base à des fins d’audit.

Le code qui doit accéder aux données des clients ne doit pas avoir la capacité d’interroger directement les systèmes de stockage de données. Toutes les demandes de données doivent transiter par la couche API. Cette couche d’API fournit un point unique de gouvernance ou de sécurité au-dessus de vos données de locataire. Cette approche empêche la logique d'autorisation d'accès aux données des locataires et des utilisateurs d'atteindre d'autres parties 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é

Lorsque vous concevez une solution d’inférence RAG multilocataire, vous devez envisager l’architecture de la solution de données de base pour vos locataires. Comprendre 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 la logique de filtrage.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étape suivante

Conception et développement d’une solution RAG