LLM et Azure OpenAI dans le schéma de génération augmentée de récupération (RAG) (version préliminaire)

Important

Cette fonctionnalité est en version préliminaire. Ces informations concernent une fonctionnalité en préversion qui peut être considérablement modifiée avant son lancement. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Cet article propose un exemple illustratif d’utilisation des grands modèles linguistiques (LLM) et d’Azure OpenAI dans le contexte du modèle de génération augmentée de récupération (RAG). En particulier, il explore la manière dont ces technologies peuvent être appliquées aux zones d’atterrissage souveraines, tout en tenant également compte des garde-fous importants.

Scénario

Un scénario courant de déploiement SLZ consiste à utiliser les LLM pour engager des conversations avec vos propres données via le schéma de génération augmentée de récupération (RAG). Ce modèle vous permet d’utiliser les capacités de raisonnement des LLM et de générer des réponses basées sur vos données spécifiques sans nécessiter un réglage fin du modèle. Il facilite l’intégration transparente des LLM dans vos processus ou solutions métier existants.

Cloud pour la souveraineté – Architecture de référence IA et LLM

Microsoft Cloud for Sovereignty fournit une architecture de référence qui illustre une architecture typique de génération augmentée de récupération (RAG) au sein d’une zone d’atterrissage souveraine (SLZ). Il fournit un aperçu des choix technologiques de mise en œuvre courants et recommandés, de la terminologie, des principes technologiques, des environnements de configuration courants et de la composition des services applicables.

Téléchargez un PDF imprimable de ce schéma de l’architecture de référence.

Les étapes/flux de données clés sont les suivants :

Zones d’atterrissage d’application

Dans la hiérarchie des groupes d’administration, ces services sont placés dans un abonnement au sein d’un groupe d’administration non confidentiel.

Sources de données et pipelines de transformation

Des sources de données et des pipelines de transformation existent souvent au sein d’une organisation pour les opérations sectorielles. Lors de l’intégration d’applications LLM, telles que les implémentations RAG, avec des données existantes, elles deviennent de nouvelles charges de travail.

Pour garantir le contrôle du flux de données, l’architecture de référence recommande des domaines de données alignés zones d’atterrissage de données pour les sources de données et les lieux de données. des pipelines de transformation proches de ces sources pour créer des produits de données utilisés par les applications LLM. Cette approche garantit une gestion précise des données fournies à la solution basée sur LLM, qui est hébergée séparément.

Les composants de transformation de données utilisent différentes technologies et services pour transformer les données en un format qui peut être recherché et utilisé par une application basée sur LLM via une recherche sémantique ou vectorielle à des fins de mise à la terre. Ces pipelines peuvent fonctionner de manière autonome ou utiliser des services d’IA, tels que les services d’IA Azure ou Azure OpenAI, pour transformer les données afin de les placer dans une base de données de recherche vectorielle ou de recherche sémantique.

Lors de l’utilisation des services d’IA, le peering réseau les rend toujours disponibles (via le hub ou directement) via leurs points de terminaison privés. Pour des raisons de gouvernance, de sécurité et de conformité, les composants de transformation des données ont le pouvoir de déterminer quelles données et dans quel format sont fournies à une base de données de recherche pour la charge de travail LLM.

Les composants de transformation de données peuvent utiliser différents types de sources de données pour offrir des données avec le résultat optimal aux bases de données de recherche sur lesquelles s’appuient les charges de travail LLM. Ces sources de données peuvent être des bases de données SQL, des lacs de données ou même des machines virtuelles hébergeant des solutions de données personnalisées, en fonction de l’environnement client.

Les sources de données ne doivent pas être accessibles directement par l’application Orchestrator, mais ces ressources doivent uniquement être disponibles à l’intérieur des limites privées du réseau virtuel. Cela impose l’intégration directe du Microsoft Azure réseau virtuel (par exemple, comme c’est le cas pour les machines virtuelles), des services Private Link ou des points de terminaison des services de réseau virtuel (uniquement si l’intégration Private Link ou directe du réseau virtuel n’est pas disponible).

Composants associés à l’IA et aux LLM

Les composants liés à l’IA et au LLM doivent être hébergés en tant que charges de travail dans leur propre abonnement sous le groupe de gestion Corp ou En ligne (selon que l’accès public est requis ou non). Ces composants sont les suivants :

Azure OpenAI Service encapsule les opérations des LLM comme GPT et des incorporations de texte comme Ada, les rendant accessibles via les API standard fournies par Azure OpenAI à l’application Orchestrator.

Une application Orchestrator fait office de frontal avec une API ou une interface basée sur l’UX, et orchestre les différentes étapes requises pour créer des expériences basées sur RAG. Il s’agit souvent d’une application Web ou d’une API Web. Il s’agit généralement des mesures suivantes :

• extraire des données des moteurs de recherche sémantiques pour une mise à la terre rapide
• extraire des données de sources de données pour une mise à la terre rapide
• enchaîner correctement les différentes requêtes au LLM

L’application Orchestrator conserve l’historique des requêtes envoyées et des réponses reçues pour garantir que le service Azure OpenAI est mis à la terre en fonction des interactions précédentes. Par exemple, dans une expérience de type chat telle que ChatGPT ou Bing Chat, l’application Orchestrator conserve ou met en cache l’historique de la session de conversation afin qu’elle soit prise en compte dans le flux de conversation par le backend du service LLM.

Dans un environnement En ligne , l’application Orchestrator point de terminaison doit être la seule fournie via un point de terminaison public protégé par un pare-feu d’application Web et des services de protection DDoS. Si hébergé dans un Corp. Dans un environnement sans points de terminaison publics, Orchestrator est soit hébergé sur un service directement intégré au réseau virtuel, tel que des machines virtuelles ou des groupes de machines virtuelles identiques, soit utilise des services prenant en charge les points de terminaison de service de liaison privée ou de réseau virtuel, comme c’est le cas pour Azure. Services d’applications.

Les services de recherche fournissent des données provenant de diverses sources de données dans un format optimisé pour une utilisation efficace afin de mettre en place rapidement des services LLM. Microsoft propose une combinaison de vectorisation et de recherche sémantique pour obtenir les meilleurs résultats pour une mise à la terre rapide basée sur des services de recherche, pris en charge par Recherche Azure AI. En utilisant classement sémantique améliore de manière mesurable la pertinence de la recherche en utilisant la compréhension de la langue pour classer les résultats de recherche. Cela améliore l’expérience utilisateur des applications RAG, car l’invite de mise à la terre devient plus précise grâce à de meilleurs résultats de recherche du service de recherche avant d’envoyer une demande au LLM.

UN combinaison de services d’IA peut être utilisé pour créer des expériences personnalisées pour les utilisateurs finaux via Orchestrator ou pour optimiser les processus d’ingestion de données. Imaginez utiliser un service de reconnaissance de formulaire tel que Intelligence documentaire Azure AI pour extraire des informations structurées à partir de formulaires et traiter et résumer efficacement les entrées des utilisateurs. Ce service peut ensuite collaborer avec un LLM pour résumer les principales conclusions de ces entrées de formulaire reconnues. Un autre scénario consiste à utiliser un service de reconnaissance de documents pour convertir des documents dans divers formats tels que des PDF ou des documents Word en texte. Par la suite, un service d’intégration de texte LLM peut vectoriser ce texte reconnu pour une analyse plus approfondie.

Les services de liaison privée sont déployés pour tous les composants de telle sorte que tous les services ne soient accessibles que dans le réseau privé environnement. La seule exception pourrait être l’application Orchestrator, qui, si elle est hébergée dans un En ligne zone d’atterrissage, peut être proposé publiquement derrière un pare-feu d’application Web ou des services comparables.

Composants de l’infrastructure

Les composants d’infrastructure peuvent être hébergés soit dans le cadre de la charge de travail, soit de manière centralisée dans un hub ou un abonnement d’identité.

L’élément central de l’infrastructure de la mise en œuvre d’une zone d’atterrissage souveraine est le Plateforme de connectivité, qui est un réseau virtuel fourni par chaque déploiement de zone d’atterrissage souveraine. Il est placé dans le abonnement connectivité au sein du plate-forme groupe de gestion.

Les composants réseau partagés sont placés dans le réseau virtuel du concentrateur. Ces composants incluent généralement :

• Circuits ExpressRoute ou passerelles VPN pour la connectivité au réseau d’entreprise d’une société, d’une agence ou d’une organisation.

• Les pare-feu peuvent être mis en œuvre à l’aide d’appareils ou d’une combinaison d’offres de pare-feu Azure, y compris le pare-feu d’application Web. Ces solutions permettent l’inspection, le filtrage et le routage du trafic.

• Composants de protection DDoS pour protéger les charges de travail contre les attaques par déni de service distribué.

• Zones DNS privées pour tous les types de services utilisés dans l’ensemble du paysage du centre de données virtuel mis en œuvre avec des zones d’atterrissage.

• Peering de réseau virtuel pour connecter des réseaux virtuels de diverses charges de travail telles que des sources de données, des transformations et des composants LLM via le réseau hub.

• Les politiques contrôlent le flux de trafic à travers les pare-feu du hub si nécessaire.

Considérations

Le diagramme d’architecture de référence montre un exemple d’architecture représentatif impliquant les composants typiques d’une charge de travail basée sur LLM RAG dans le contexte d’une zone d’atterrissage souveraine. Il y a plusieurs considérations à garder à l’esprit, qui n’ont pas été abordées dans les sections précédentes.

Alignement avec les principes du Well-Architected Framework et du Cloud Adoption Framework

Dans les sections précédentes, certains aspects d’alignement liés au Well-Architected Framework (WAF) et au Cloud Adoption Framework (CAF) ont été brièvement mentionnés. Il est important de noter que toutes les décisions architecturales doivent être entièrement alignées sur les principes fondamentaux de zone d’atterrissage CAF et Azure, analyse à l’échelle du cloud CAF et le WAF, y compris la perspective WAF sur Azure OpenAI.

Considérations sur la conception des infrastructures liées aux garde-corps

Bien que la gestion des garde-corps soit une procédure standard dans les environnements de zone d’atterrissage, d’autres considérations doivent être prises en compte dans plusieurs domaines pour les charges de travail LLM et AI. Il est préférable de suivre les normes de conformité Azure Security Baseline et les normes de l’initiative Politique de base de souveraineté lors de la conception et de la définition de l’infrastructure. pour l’abonnement à la charge de travail.

Les principales considérations à souligner pour les applications basées sur LLM RAG à partir de ces normes sont les suivantes :

Résidence des données et sélection de la région

La souveraineté impose des exigences strictes en matière de résidence des données et peut donc restreindre les déploiements à des régions Azure spécifiques dans une SLZ. La sélection d’une région pour les charges de travail LLM est limitée par la disponibilité des services requis :

• Vérifiez qu’Azure OpenAI et Azure AI Search sont tous deux disponibles dans votre région cible où vous hébergez vos données et votre charge de travail pour des raisons de résidence des données et/ou de proximité. De plus, ces services sont importants, du point de vue des performances, pour l’expérience de l’utilisateur final de l’application.

• Deuxièmement, lorsque l’on examine Azure OpenAI, la disponibilité des modèles LLM respectifs est importante, car tous les modèles ne sont pas également disponibles dans toutes les régions.

• Si les sources de données ou autres services cognitifs ne sont pas disponibles dans votre région cible désignée, vous pourrez peut-être les trouver et les exploiter dans une autre région conformément à vos exigences de résidence des données. Toutefois, le service Azure OpenAI et recherche Azure AI doivent se trouver dans la même région que l’application Orchestrator pour des raisons de performances.

Mise en réseau

Les points de terminaison publics ne sont pas autorisés dans les environnements Corp. Par conséquent, tous les services doivent être encapsulés dans un réseau virtuel. Selon le service, il peut offrir des fonctionnalités d’encapsulation directe telles que des machines virtuelles ou des clusters AKS, un lien privé ou des points de terminaison de service de réseau virtuel. Les point de terminaison de service de réseau virtuel doivent être remplacés par liaison privée dans la mesure du possible.

En plus de l’encapsulation, l’accès public doit être désactivé pour tous les services. Enfin, l’application des stratégies à l’aide de la stratégie Azure doit être activée de telle sorte que l’accès public ne puisse jamais être activé accidentellement pour les services pour lesquels les stratégies de refus correspondantes ne peuvent pas être créées. La stratégie de défense en profondeur consiste à permettre les capacités d’audit correspondantes pour tous les services.

Chiffrer au repos et en transit

La plupart des services dans Azure prennent en charge les fonctionnalités de chiffrement en transit et au repos. Activez le chiffrement au repos et en transit sur tous les services lorsqu’ils sont disponibles. Activez la dernière version de TLS, actuellement TLS 1.2, pour le chiffrement de transit.

Identités gérées

Utilisez des identités gérées pour tous les services et la communication de service à service afin d’éviter de gérer les secrets des informations d’identification.

Rotation des clés dans Key Vault

Chaque fois que des actifs de sécurité tels que des certificats sont requis, activez la rotation des clés pour ces secrets dans Key Vault afin de maintenir la conformité.

Groupes de sécurité des réseaux et des applications

Dans un environnement souverain et sécurisé, l’utilisation de groupes de sécurité réseau (NSG) et de groupes de sécurité d’application (ASG) est imposée. Les groupes de sécurité manquants entraînent des déploiements non conformes. Les ports SSL habituels sont utiles pour la plupart des services sur lesquels reposent les charges de travail LLM/RAG puisqu’ils sont basés sur HTTPS. Des ports spécifiques sont requis pour l’ingestion de données depuis les sources vers les bases de données de recherche et vectorielles. Les IP publiques ne sont pas autorisées dans les zones d’atterrissage Corp. Tous les services doivent être accessibles uniquement dans le réseau virtuel, ce qui nécessite l’utilisation de points de terminaison de service de liaison privée ou de réseau virtuel pour Services PaaS.

Plus de garde-fous en matière de sécurité et de souveraineté

Les garde-fous les plus importants et les plus évidents abordés dans les sections précédentes pour la conception de votre infrastructure et de vos applications sont réutilisables même en dehors des zones d’atterrissage souveraines ou Azure. D’autres politiques globales sont liées à des ressource managée de manière centralisée telles que les espace de travail Log Analytics ou les déploiements Microsoft Sentinel dans les zones d’atterrissage à l’échelle de l’entreprise. Lors du processus de conception de votre infrastructure et de vos applications, il est crucial de prendre en compte ces ressource managée de manière centralisée. Négliger de le faire peut entraîner des efforts et du temps supplémentaires après le déploiement. Heureusement, la fonctionnalité de conformité aux politiques d’Azure peut identifier les ressources non conformes après le déploiement. De plus, les zones d’atterrissage Sovereign et Azure fournissent des stratégies DeployIfNotExists pour de nombreuses ressources, simplifiant encore davantage le processus.

Voici quelques exemples de ces garde-fous :

• Activation de la connexion aux espaces de travail Log Analytics gérés de manière centralisée.

• Intégration avec Azure Security Center ou Microsoft Defender pour cloud.

• Intégration avec les informations de sécurité et les suites gestion d’événement (SIEM) telles que Microsoft Sentinel.

• Intégration avec des pare-feu gérés de manière centralisée, des pare-feux d’application Web ou une protection DDoS.

Ce ne sont là que quelques garde-fous que vous pourriez identifier comme exigences après votre déploiement initial. Nous vous recommandons de tester vos déploiements dans une zone d’atterrissage de test et d’intégrer de manière itérative un respect de ces garde-fous dans votre infrastructure et la base de code de votre application. Si cela n’est pas tout à fait possible, bon nombre de ces garde-fous peuvent être résolus après le déploiement avec DeployIfNotExists stratégies.

Déployez ce scénario

Pour profiter des grands modèles linguistiques (LLM) et d’Azure OpenAI basé sur Modèle de génération augmentée de récupération (RAG) dans les zones d’atterrissage souveraines, vous devez d’abord déployer et configurer une zone d’atterrissage souveraine (SLZ) et appliquer les initiatives politiques de base en matière de souveraineté. Pour une présentation détaillée d’une SLZ et de toutes ses fonctionnalités, consultez la documentation sur la Zone d’atterrissage souveraine sur GitHub.

SLZ fournit un environnement offrant des garde-fous via des politiques et des ensembles de politiques, l’application de la sécurité et une infrastructure de base cohérente pour le déploiement de charges de travail et d’applications. La SLZ est basée sur les Zones d’atterrissage Azure et les étend avec des protections et des contrôles de sécurité spécifiques aux exigences de souveraineté.

Pour aider à accélérer le délai de rentabilisation des clients tout en les aidant à atteindre leurs objectifs de conformité, Microsoft Cloud for Sovereignty inclut des modèles de charge de travail prêts à l’emploi qui peuvent être déployés et exploités de manière cohérente et reproductible. Les modèles de charge de travail sont alignés sur les Initiatives de stratégie de référence en matière de souveraineté, le Portefeuille de stratégies Cloud for Sovereignty et les Stratégies par défaut de la zone d’atterrissage Azure.

Modèle d’informations Assistant agent

Le modèle d’informations Assistant agent fournit un point de départ pointer aux organisations pour créer leur propre capacité d’IA générative personnalisée afin d’étendre la puissance de Azure OpenAI aux utilisateurs de l’organisation et à leurs données de domaine sans affiner le modèle. Vous pouvez le déployer dans le Cloud pour la souveraineté et l’aligner sur l’architecture de référence et les conseils fournis dans cet article. Le modèle d’informations Assistant agent est compatible avec le groupe de gestion Sovereign Landing Zone Online à l’aide de la configuration de déploiement en mode sécurisé . La prise en charge du périmètre du groupe de gestion Corp arrive bientôt.

Le modèle agent est une combinaison de code, de documentation et de ressources pédagogiques fournies gratuitement aux clients et partenaires qui peuvent aider à accélérer le délai de rentabilisation.

Pour plus d’informations sur la manière de déployer et de configurer les informations Assistant, consultez la documentation du modèle d’informations Assistant agent sur GitHub. Pour les cas d’utilisation que vous pouvez réaliser avec ce modèle agent, voir Informations Assistant Vidéo.