Architecture de référence de conversation de bout en bout OpenAI

Les applications de chat d’entreprise peuvent autonomiser les employés grâce à l’interaction conversationnelle. Cela est particulièrement vrai en raison des progrès continus des modèles de langage, tels que les modèles GPT d’OpenAI et les modèles LLaMA de Meta. Ces applications de chat se composent d’une interface utilisateur (UI) de chat, de référentiels de données contenant des informations spécifiques au domaine pertinentes pour les requêtes de l’utilisateur, de modèles de langage qui raisonnent sur les données spécifiques au domaine pour produire une réponse pertinente, et d’un orchestrateur qui supervise l’interaction entre ces composants.

Cet article fournit une architecture de base pour construire et déployer des applications de chat d’entreprise utilisant les modèles de langage Azure OpenAI Service. L’architecture utilise le flux d’invite pour créer des flux exécutables. Ces flux exécutables orchestrent le flux de travail des invites entrantes vers les magasins de données pour récupérer des données de base pour les modèles de langage, ainsi que d’autres logiques Python nécessaires. Le flux exécutable est déployé sur un point de terminaison en ligne géré avec des capacités de calcul gérées.

L’hébergement de l’interface utilisateur de conversation personnalisée suit les instructions d’application web des services d’application de base pour déployer une application web sécurisée, redondante interzone et hautement disponible sur Azure App Service. Dans cette architecture, App Service communique avec la solution de plateforme en tant que service (PaaS) Azure via une intégration de réseau virtuel sur des points de terminaison privés. L’App Service de l’interface utilisateur de chat communique avec le point de terminaison en ligne géré pour le flux via un point de terminaison privé. L’accès public à Azure AI Studio est désactivé.

Le hub Azure AI Studio est configuré avec une isolation de réseau virtuel managé qui nécessite l’approbation de toutes les connexions sortantes. Avec cette configuration, un réseau virtuel géré est créé, ainsi que des points de terminaison privés gérés permettant la connectivité à des ressources privées, telles que Azure Storage, Azure Container Registry et Azure OpenAI. Ces connexions privées sont utilisées pendant la rédaction et le test des flux, ainsi que par les flux déployés sur la capacité de calcul Machine Learning.

Un hub est la ressource Azure AI Studio de niveau supérieur qui offre un moyen central de régir la sécurité, la connectivité et d’autres préoccupations sur plusieurs projets. Cette architecture ne nécessite qu’un seul projet pour sa charge de travail. Si vous avez des expériences supplémentaires qui nécessitent différents flux d’invite avec une logique différente, potentiellement à l’aide de différentes ressources principales telles que des magasins de données, vous pouvez envisager d’implémenter celles dans un autre projet.

Architecture

Téléchargez un fichier Visio de cette architecture.

Composants

De nombreux composants de cette architecture sont identiques à ceux de l’architecture de chat de bout en bout basique d’Azure OpenAI. La liste suivante ne met en évidence que les changements apportés à l'architecture de base.

• Azure OpenAI est utilisé à la fois dans l’architecture basique et dans cette architecture de base. Azure OpenAI est un service entièrement géré qui fournit un accès API REST aux modèles de langage d’Azure OpenAI, y compris les ensembles de modèles GPT-4, GPT-3.5-Turbo et embeddings. L’architecture de base tire parti des fonctionnalités d’entreprise telles que le réseau virtuel et la liaison privée que l’architecture de base n’implémente pas.
• Azure AI Studio est une plateforme idéale pour créer, tester et déployer des solutions d'intelligence artificielle. Dans cette architecture, AI Studio est utilisé pour concevoir, tester et déployer la logique d'orchestration du flux d'invite dans l'application de chat. Dans cette architecture, Azure AI Studio fournit le réseau virtuel managé pour la sécurité réseau. Pour plus d’informations, consultez la section réseau pour plus d’informations.
• Application Gateway agit comme un équilibreur de charge de couche 7 (HTTP/S) et un routeur de trafic Web. Il utilise le routage basé sur le chemin d’URL pour distribuer le trafic entrant entre les zones de disponibilité et décharge le chiffrement pour améliorer les performances de l’application.
• Web Application Firewall (WAF) est un service cloud natif qui protège les applications web contre les attaques courantes telles que l’injection SQL et le scripting inter-site. Web Application Firewall fournit une visibilité sur le trafic entrant et sortant de votre application Web, permettant ainsi de surveiller et sécuriser l’application.
• Azure Key Vault est un service qui stocke et gère de manière sécurisée les secrets, les clés de chiffrement et les certificats. Il centralise la gestion des informations sensibles.
• Le réseau virtuel Azure est un service qui vous permet de créer des réseaux virtuels privés isolés et sécurisés dans Azure. Pour une application web sur App Service, vous avez besoin d’un sous-réseau de réseau virtuel pour utiliser des points de terminaison privés pour une communication sécurisée entre les ressources.
• Private Link permet aux clients d’accéder aux services PaaS (platform as a service) Azure directement à partir de réseaux virtuels privés sans utiliser d’adresse IP publique.
• Azure DNS est un service d’hébergement pour les domaines DNS, qui offre une résolution de noms à l’aide de l’infrastructure Microsoft Azure. Les zones DNS privées permettent de mapper le nom de domaine complet (FQDN) d'un service à l'adresse IP d'un point de terminaison privé.

Autres solutions

Cette architecture comporte plusieurs composants qui peuvent être pris en charge par d’autres services Azure qui peuvent s’aligner mieux sur vos exigences fonctionnelles et non fonctionnelles de votre charge de travail. Voici quelques alternatives à prendre en compte.

Espaces de travail Azure Machine Learning (et expériences du portail)

Cette architecture utilise Azure AI Studio pour générer, tester et déployer des flux d’invite. Vous pouvez également utiliser des espaces de travail Azure Machine Learning, car les deux services ont des fonctionnalités qui se chevauchent. Bien que AI Studio soit un bon choix si vous concevez une solution de flux d’invite, certaines fonctionnalités qu’Azure Machine Learning offre actuellement une meilleure prise en charge. Pour plus d’informations, consultez la comparaison des fonctionnalités. Nous vous recommandons de ne pas combiner et de faire correspondre Azure AI Studio et Azure Machine Learning. Si votre travail peut être entièrement effectué dans AI Studio, utilisez AI Studio. Si vous avez toujours besoin de fonctionnalités à partir d’Azure Machine Learning Studio, continuez à utiliser Azure Machine Learning Studio.

Composants de la couche Application

Il existe plusieurs offres de services d’application managées disponibles dans Azure qui peuvent servir de couche Application pour le front-end de l’interface utilisateur de conversation. Consultez Choisir un service de calcul Azure pour tous les calculs et choisir un service de conteneur Azure pour les solutions de conteneur. Par exemple, alors qu’Azure Web Apps et Web App for Containers ont été sélectionnés pour l’API de l’interface utilisateur de conversation et l’hôte de flux d’invite respectivement, des résultats similaires peuvent être obtenus avec Azure Kubernetes Service (AKS) ou Azure Container Apps. Choisissez la plateforme d’application de votre charge de travail en fonction des exigences fonctionnelles et non fonctionnelles spécifiques de la charge de travail.

Hébergement de flux d’invite

Le déploiement de flux d’invite n’est pas limité aux clusters de calcul Machine Learning, et cette architecture illustre qu’avec une alternative dans Azure App Service. Les flux sont finalement une application conteneurisée peut être déployée sur n’importe quel service Azure compatible avec les conteneurs. Ces options incluent des services tels qu’Azure Kubernetes Service (AKS), Azure Container Apps et Azure App Service. Choisissez un service de conteneur Azure en fonction des exigences de votre couche d’orchestration.

Par exemple, l’hébergement d’un flux d’invite sur un autre calcul est une considération à prendre en compte plus loin dans cet article.

Magasin de données de base

Bien que cette architecture mène à Azure AI Search, votre choix de magasin de données pour vos données de base est une décision architecturale spécifique à votre charge de travail. De nombreuses charges de travail sont en fait polyglotte et ont des sources et technologies disparates pour la mise sur pied des données. Ces plateformes de données proviennent de magasins de données OLTP existants, de bases de données natives cloud telles qu’Azure Cosmos DB, par le biais de solutions spécialisées telles qu’Azure AI Search. Une caractéristique courante, mais non obligatoire, pour un tel magasin de données est la recherche vectorielle. Consultez Choisir un service Azure pour la recherche vectorielle pour explorer les options de cet espace.

Remarques et recommandations

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

L’architecture d’application web App Service de base se concentre sur la redondance zonale pour les services régionaux clés. Les zones de disponibilité sont des emplacements physiquement séparés au sein d’une région. Ils fournissent une redondance au sein d’une région pour les services de prise en charge lorsque deux instances ou plus y sont déployées. Lorsqu’une zone subit une interruption, les autres zones au sein de la région peuvent ne pas être affectées. L’architecture garantit également suffisamment d’instances des services Azure et de la configuration de ces services pour qu’ils soient répartis entre les zones de disponibilité. Pour plus d’informations, veuillez consulter la référence de base pour examiner ces directives.

Cette section aborde la fiabilité du point de vue des composants de cette architecture non traités dans la référence de base App Service, y compris Machine Learning, Azure OpenAI et AI Search.

Redondance zonale pour les déploiements de flux

Les déploiements d’entreprise nécessitent généralement une redondance zonale. Pour obtenir une redondance zonale dans Azure, les ressources doivent prendre en charge les zones de disponibilité et vous devez déployer au moins trois instances de la ressource ou activer la prise en charge de la plateforme lorsque le contrôle des instances n’est pas disponible. Actuellement, la capacité de calcul Machine Learning ne prend pas en charge les zones de disponibilité. Pour atténuer l’impact potentiel d’une catastrophe au niveau du centre de données sur les composants Machine Learning, il est nécessaire d’établir des clusters dans diverses régions ainsi que de déployer un équilibrage de charge pour distribuer les appels entre ces clusters. Vous pouvez utiliser des vérifications de l’état pour vous assurer que les appels sont uniquement routés vers des clusters fonctionnant correctement.

Il existe des alternatives aux clusters de calcul Machine Learning tels qu’Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps et Azure App Service. Chacun de ces services prend en charge les zones de disponibilité. Pour obtenir une redondance zonale pour l’exécution des flux d’invites, sans la complexité supplémentaire d’un déploiement multirégion, vous devez déployer vos flux sur l’un de ces services.

Le diagramme suivant montre une architecture alternative où les flux d’invite sont déployés sur App Service. App Service est utilisé dans cette architecture, car la charge de travail l’utilise déjà pour l’interface utilisateur de conversation et ne profiterait pas de l’introduction d’une nouvelle technologie dans la charge de travail. Les équipes de charge de travail qui connaissent bien AKS doivent envisager son déploiement dans cet environnement, en particulier si AKS est utilisé pour d’autres composants de la charge de travail.

Le diagramme est numéroté pour les zones notables dans cette architecture :

1. Les flux sont toujours créés dans le flux d’invite et l’architecture réseau n’est pas modifiée. Les auteurs de flux se connectent toujours à l’expérience de création dans le projet AI Studio via un point de terminaison privé, et les points de terminaison privés managés sont utilisés pour se connecter aux services Azure lors du test de flux.

2. Cette ligne pointillée indique que les flux exécutables conteneurisés sont poussés vers Container Registry. Non montré dans le diagramme sont les pipelines qui conteneurisent les flux et poussent vers Container Registry. Le calcul dans lequel ces pipelines s’exécutent doit avoir une ligne de vue réseau pour les ressources telles que le registre de conteneurs Azure et le projet AI Studio.

3. Une autre application web est déployée sur le même plan App Service qui héberge déjà l’interface utilisateur de conversation. La nouvelle application web héberge le flux d’invite conteneurisé, colocalisée sur le même plan App Service qui s’exécute déjà à un minimum de trois instances, réparties entre les zones de disponibilité. Ces instances App Service se connectent à Container Registry via un point de terminaison privé lorsqu’elles chargent l’image du conteneur du flux d’invite.

4. Le conteneur de flux d’invite doit se connecter à tous les services dépendants pour l’exécution du flux. Dans cette architecture, le conteneur du flux d’invite se connecte à AI Search et Azure OpenAI. Les services PaaS qui n’étaient exposés qu’au sous-réseau du point de terminaison privé géré par Machine Learning doivent maintenant également être exposés dans le réseau virtuel afin que la ligne de vue puisse être établie depuis App Service.

Azure OpenAI - fiabilité

Azure OpenAI ne prend actuellement pas en charge les zones de disponibilité. Pour atténuer l’impact potentiel d’une catastrophe au niveau du centre de données sur les déploiements de modèles dans Azure OpenAI, il est nécessaire de déployer Azure OpenAI dans différentes régions, ainsi que de déployer un équilibreur de charge afin de distribuer les appels entre les régions. Vous pouvez utiliser des vérifications de l’état pour vous assurer que les appels sont uniquement routés vers des clusters fonctionnant correctement.

Pour prendre en charge plusieurs instances de manière efficace, nous recommandons d’externaliser les fichiers de réglage fin, par exemple vers un compte de stockage géoredondant. Cette approche minimise l’état stocké dans l’Azure OpenAI pour chaque région. Vous devez toujours régler les fichiers de chaque instance pour héberger le modèle de déploiement.

Il est important de surveiller le débit requis en termes de jetons par minute (TPM) et de requêtes par minute (RPM). Assurez-vous que suffisamment de TPM est assigné à partir de votre quota pour répondre à la demande de vos déploiements et éviter que les appels à vos modèles déployés ne soient limités. Une passerelle telle qu’Azure Gestion des API peut être déployée devant votre service ou services Azure OpenAI et peut être configurée pour une nouvelle tentative en cas d’erreurs temporaires et de limitation. API Management peut également être utilisé comme un circuit breaker pour empêcher le service d’être submergé par des appels, dépassant son quota. Pour en savoir plus sur l’ajout d’une passerelle pour des problèmes de fiabilité, consultez Access Azure OpenAI et d’autres modèles de langage via une passerelle.

AI Search - fiabilité

Déployez AI Search avec le niveau de tarification Standard ou supérieur dans une région qui prend en charge les zones de disponibilité, et déployez trois réplicas ou plus. Les réplicas se répartissent automatiquement entre les zones de disponibilité.

Tenez compte des instructions suivantes pour déterminer le nombre approprié de réplicas et de partitions :

• Surveillez AI Search.

• Utilisez les métriques et les journaux de surveillance et l’analyse des performances pour déterminer le nombre approprié de réplicas afin d’éviter les limitations basées sur les requêtes et les partitions et d’éviter les limitations basées sur les index.

Azure AI Studio - Fiabilité

Si vous effectuez un déploiement sur des clusters de calcul derrière le point de terminaison en ligne géré par Machine Learning, tenez compte des instructions suivantes concernant la mise à l’échelle :

• Mettez automatiquement à l’échelle vos points de terminaison en ligne pour vous assurer qu’une capacité suffisante est disponible pour répondre à la demande. Si les signaux d’utilisation ne sont pas suffisamment opportuns en raison d’une utilisation en rafale, envisagez de surapprovisionner pour éviter un impact sur la fiabilité dû à un nombre insuffisant d’instances disponibles.

• Envisagez de créer des règles de mise à l’échelle basées sur des métriques de déploiement telles que la charge du processeur, et sur des métriques de point de terminaison telles que la latence des requêtes.

• Jamais moins de trois instances ne doivent être déployées pour un déploiement de production actif.

• Évitez les déploiements sur des instances en cours d’utilisation. Déployez plutôt sur un nouveau déploiement et déplacez le trafic une fois le déploiement prêt à recevoir le trafic.

Les points de terminaison en ligne managés agissent en tant qu’équilibreur de charge et routeur pour le calcul managé qui s’exécute derrière eux. Vous pouvez configurer le pourcentage de trafic qui doit être routé vers chaque déploiement, tant que les pourcentages s’ajoutent à 100 %. Vous pouvez également déployer un point de terminaison en ligne managé avec un trafic de 0 % acheminé vers n’importe quel déploiement. Si, comme dans l’implémentation de référence fournie, vous utilisez l’infrastructure en tant que code (IaC) pour déployer vos ressources, y compris vos points de terminaison en ligne managés, il existe une préoccupation de fiabilité. Si vous avez configuré le trafic pour acheminer vers des déploiements (créés via l’interface CLI ou Azure AI Studio) et que vous effectuez un déploiement IaC ultérieur qui inclut le point de terminaison en ligne managé, même s’il ne met pas à jour le point de terminaison en ligne managé de quelque manière que ce soit, le trafic de point de terminaison revient au routage du trafic de 0 %. En effet, cela signifie que vos flux d’invite déployés ne seront plus accessibles tant que vous n’aurez pas ajusté le trafic à l’endroit où vous le souhaitez.

Conception multirégion

Cette architecture n’est pas conçue pour être un tampon régional dans une architecture multirégion. Il fournit une haute disponibilité dans une seule région en raison de son utilisation complète des zones de disponibilité, mais manque de composants clés pour rendre cette solution véritablement prête pour une solution multirégion. Il s’agit de certains composants ou considérations manquants dans cette architecture :

• Entrée et routage globaux
• Stratégie de gestion DNS
• Stratégie de réplication des données (ou isolation)
• Désignation active active, active-passive ou active-froid
• Stratégie de basculement et de restauration automatique pour atteindre le RTO et le RPO de votre charge de travail
• Décisions relatives à la disponibilité des régions pour les expériences des développeurs dans la ressource Azure Studio Hub

Si les exigences de votre charge de travail nécessitent une stratégie multirégion, vous devez investir dans des efforts de conception supplémentaires autour des composants et des processus opérationnels en plus de ce qui est présenté dans cette architecture. Vous concevez pour prendre en charge l’équilibrage de charge ou le basculement aux couches suivantes :

• Données d’ancrage
• Hébergement de modèles
• Couche Orchestration (flux d’invite dans cette architecture)
• Interface utilisateur côté client

En outre, vous aurez besoin de maintenir la continuité de l’activité dans l’observabilité, les expériences du portail et les préoccupations de l’IA responsable, telles que la sécurité du contenu.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Cette architecture étend l’empreinte de sécurité mise en œuvre dans l’architecture de chat de bout en bout basique avec Azure OpenAI. Alors que l'architecture de base utilise des identités gérées et des attributions de rôles attribuées par le système, cette nouvelle architecture s'appuie sur des identités gérées par l'utilisateur avec des attributions de rôles créées manuellement.

L’architecture met en œuvre un périmètre de sécurité réseau, ainsi que le périmètre d’identité mis en œuvre dans l’architecture de base. D’un point de vue réseau, la seule chose qui devrait être accessible depuis Internet est l’interface utilisateur de chat via Application Gateway. Du point de vue de l’identité, l’interface utilisateur de conversation doit authentifier et autoriser les requêtes. Les identités managées sont utilisées, le cas échéant, pour authentifier les applications auprès des services Azure.

En plus des considérations réseau, cette section décrit les considérations de sécurité pour la rotation des clés et l’affinement des modèles Azure OpenAI.

Gestion des identités et des accès

Lorsque vous utilisez des identités gérées par l'utilisateur, voici quelques conseils à suivre :

• Créez des identités managées distinctes pour les ressources Azure AI Studio et Machine Learning suivantes, le cas échéant :
  • AI Studio Hub
  • Projets AI Studio pour la création et la gestion de flux
  • Points de terminaison en ligne dans le flux déployé si le flux est déployé sur un point de terminaison en ligne géré
• Implémentez des contrôles d’accès par identité pour l’interface utilisateur de chat en utilisant Microsoft Entra ID

Créez des projets distincts et des points de terminaison en ligne pour différents flux d’invite que vous souhaitez isoler d’autres utilisateurs du point de vue des autorisations. Créez une identité managée distincte pour chaque projet et point de terminaison en ligne managé. Donnez aux auteurs de flux d’invite l’accès uniquement aux projets dont ils ont besoin.

Lorsque vous intégrez des utilisateurs à des projets Azure AI Studio pour effectuer des fonctions telles que des flux de création, vous devez effectuer des attributions de rôles de privilège minimum pour les ressources dont ils ont besoin.

Rôles de gestion des accès basés sur les rôles Machine Learning

Comme dans l’architecture de base, le système crée automatiquement des attributions de rôles pour les identités managées affectées par le système. Étant donné que le système ne connaît pas les fonctionnalités du hub et des projets que vous pouvez utiliser, il crée des attributions de rôles qui prennent en charge toutes les fonctionnalités potentielles. Les attributions de rôles créées automatiquement peuvent dépasser les privilèges d’approvisionnement en fonction de votre cas d’usage. Par exemple, le rôle « Contributeur » attribué au hub pour le registre de conteneurs, où il nécessite probablement l’accès « Lecteur » au plan de contrôle. Si vous devez limiter davantage les autorisations pour les objectifs de privilège minimum, vous devez utiliser des identités affectées par l’utilisateur. Vous allez créer et gérer vous-même ces attributions de rôle.

En raison de la charge de maintenance de la gestion de toutes les affectations requises, cette architecture favorise l’excellence opérationnelle par rapport aux attributions absolues de rôles de privilège minimum. Notez que vous devez effectuer toutes les affectations répertoriées dans le tableau.

Identité managée	Étendue	Affectations de rôles
Identité managée hub	Contributeur	Groupe de ressources
Identité managée hub	Hub	Administrateur Azure AI
Identité managée hub	Container Registry	Contributeur
Identité managée hub	Key Vault	Contributeur
Identité managée hub	Key Vault	Administrateurs
Identité managée hub	Compte de stockage	Lecteur
Identité managée hub	Compte de stockage	Contributeur de compte de stockage
Identité managée hub	Compte de stockage	Contributeur aux données Blob du stockage
Identité managée hub	Compte de stockage	Contributeur privilégié des données du fichier de stockage
Identité managée hub	Compte de stockage	Contributeur aux données de table du stockage
Identité managée du projet	Project	Administrateur Azure AI
Identité managée du projet	Container Registry	Contributeur
Identité managée du projet	Key Vault	Contributeur
Identité managée du projet	Key Vault	Administrateurs
Identité managée du projet	Compte de stockage	Lecteur
Identité managée du projet	Compte de stockage	Contributeur de compte de stockage
Identité managée du projet	Compte de stockage	Contributeur aux données Blob du stockage
Identité managée du projet	Compte de stockage	Contributeur privilégié des données du fichier de stockage
Identité managée du projet	Compte de stockage	Contributeur aux données de table du stockage
Identité managée de point de terminaison en ligne	Project	Secrets de connexion de l’espace de travail Azure Machine Learning
Identité managée de point de terminaison en ligne	Project	Rédacteur de métriques AzureML
Identité managée de point de terminaison en ligne	Container Registry	ACRPull
Identité managée de point de terminaison en ligne	Azure OpenAI	Utilisateur OpenAI Cognitive Services
Identité managée de point de terminaison en ligne	Compte de stockage	Contributeur aux données Blob du stockage
Identité managée de point de terminaison en ligne	Compte de stockage	Lecteur des données blob du stockage
App Service (lorsque le flux d’invite est déployé sur App Service)	Azure OpenAI	Utilisateur OpenAI Cognitive Services
Utilisateur du portail (développement de flux d’invite)	Azure OpenAI	Utilisateur OpenAI Cognitive Services
Utilisateur du portail (développement de flux d’invite)	Compte de stockage	Contributeur aux données Blob de stockage (utiliser l’accès conditionnel)
Utilisateur du portail (développement de flux d’invite)	Compte de stockage	Contributeur privilégié des données du fichier de stockage

Il est important de comprendre que le hub AI Studio dispose de ressources Azure partagées entre des projets, comme un compte de stockage et Container Registry. Si vous avez des utilisateurs qui n’ont besoin d’accéder qu’à un sous-ensemble des projets, envisagez d’utiliser des conditions d’attribution de rôle, pour les services Azure qui les prennent en charge, afin de fournir un accès au moins privilégié aux ressources. Par exemple, les objets blob dans Stockage Azure prennent en charge les conditions d’attribution de rôle. Pour un utilisateur qui nécessite l’accès à un sous-ensemble des projets, au lieu d’attribuer des autorisations par conteneur, utilisez des conditions d’accès aux rôles pour limiter les autorisations aux conteneurs d’objets blob utilisés par ces projets. Chaque projet a un GUID unique qui sert de préfixe pour les noms des conteneurs d’objets blob utilisés dans ce projet. Ce GUID peut être utilisé dans les conditions d’attribution de rôle.

Le hub a besoin d’avoir Contributor accès au groupe de ressources hub pour lui permettre de créer et de gérer des ressources hub et de projet. Effet secondaire de ce que le hub a un accès au plan de contrôle à n’importe quelle ressource également dans le groupe de ressources. Toutes les ressources Azure qui ne sont pas directement liées au hub et à ses projets doivent être créées dans un groupe de ressources distinct. Nous vous recommandons de créer, au minimum, deux groupes de ressources pour une équipe de charge de travail à l’aide d’un hub Azure AI Studio autogéré. Un groupe de ressources pour contenir le hub, ses projets et toutes ses dépendances directes, comme le registre de conteneurs Azure, Key Vault, et ainsi de suite. Un groupe de ressources pour contenir tout le reste de votre charge de travail.

Nous vous recommandons de réduire au minimum l’utilisation des ressources Azure nécessaires pour l’opération du hub (Container Registry, Compte de stockage, Coffre de clés, Application Insights) par d’autres composants de vos charges de travail. Par exemple, si vous devez stocker des secrets dans le cadre de votre charge de travail, vous devez créer un coffre de clés distinct en dehors du coffre de clés associé au hub. Le coffre de clés hub doit uniquement être utilisé par le hub pour stocker les secrets du hub et du projet.

Assurez-vous que pour chaque projet distinct, les attributions de rôles pour ses dépendances ne fournissent pas d’accès aux ressources dont l’utilisateur du portail et l’identité managée managée du point de terminaison en ligne ne nécessitent pas. Par exemple, l’attribution Cognitive Services OpenAI User de rôle à Azure OpenAI accorde l’accès à tous les déploiements de cette ressource. Il n’existe aucun moyen de restreindre les auteurs de flux ou les identités managées de point de terminaison en ligne managées avec cet accès d’attribution de rôle à des déploiements de modèles spécifiques dans Azure OpenAI. Pour les scénarios tels que celui-ci, nos conseils sont de déployer des services tels qu’Azure OpenAI et Azure AI Search par projet et de ne pas déployer de ressources sur ces services qui circulent avec des auteurs ou des identités managées de point de terminaison en ligne managées ne doivent pas avoir accès à ces services. Par exemple, déployez uniquement des modèles sur l’instance Azure OpenAI du projet auquel le projet a besoin d’accès. Déployez uniquement des index sur l’instance Azure AI Search du projet auquel le projet doit avoir accès.

Mise en réseau

En plus de l’accès basé sur l’identité, la sécurité du réseau est au cœur de l’architecture de chat de bout en bout utilisant OpenAI. À un niveau élevé, l’architecture réseau assure que :

• Il n’y a qu’un seul point d’entrée sécurisé pour le trafic de l’interface utilisateur de chat.
• Le trafic réseau est filtré.
• Les données en transit sont cryptées de bout en bout avec Transport Layer Security (TLS).
• L’exfiltration de données est minimisée en utilisant Private Link pour maintenir le trafic dans Azure.
• Les ressources réseau sont logiquement regroupées et isolées les unes des autres par segmentation du réseau.

Flux réseau

Deux flux dans ce diagramme sont couverts dans l’architecture de l’application web de base App Service : Le flux entrant de l’utilisateur final vers l’interface utilisateur de chat (1) et le flux de l’App Service vers les services PaaS Azure (2). Cette section se concentre sur le flux du point de terminaison en ligne de Machine Learning. Le flux suivant va de l’interface utilisateur de chat exécutée dans l’application web de base App Service au flux déployé sur la capacité de calcul Machine Learning :

1. L’appel de l’interface utilisateur de chat hébergée par App Service est routé via un point de terminaison privé vers le point de terminaison en ligne Machine Learning.
2. Le point de terminaison en ligne achemine l’appel vers un serveur exécutant le flux déployé. Le point de terminaison en ligne agit à la fois comme un équilibrage de charge (Load Balancer) et un routeur.
3. Les appels envoyés aux services Azure PaaS requis par le flux déployé sont acheminés via des points de terminaison privés managés.

Entrée vers Machine Learning

Dans cette architecture, l’accès public à l’espace de travail Machine Learning est désactivé. Les utilisateurs peuvent accéder à l’espace de travail via un accès privé car l’architecture suit la configuration du point de terminaison privé pour l’espace de travail Machine Learning. En fait, les points de terminaison privés sont utilisés dans l’ensemble de cette architecture afin de compléter la sécurité basée sur l’identité. Par exemple, votre interface utilisateur de chat hébergée par App Service peut se connecter à des services PaaS non exposés à Internet public, y compris les points de terminaison Machine Learning.

L’accès par point de terminaison privé est également requis pour se connecter à l’espace de travail Machine Learning pour la rédaction des flux.

Le diagramme illustre un créateur de flux d’invite se connectant via Azure Bastion à une jumpbox de machine virtuelle. Depuis ce jump box, l’auteur peut se connecter à l’espace de travail Machine Learning via un point de terminaison privé dans le même réseau que le jump box. La connexion au réseau virtuel peut également être effectuée via ExpressRoute ou des passerelles VPN et l’appairage de réseaux virtuels.

Passer du réseau virtuel managé Azure AI Studio aux services PaaS Azure

Nous vous recommandons de configurer le hub Azure AI Studio pour l’isolation du réseau virtuel managé qui nécessite que toutes les connexions sortantes soient approuvées. Cette architecture suit cette recommandation. Il existe deux types de règles de trafic sortant approuvé. Les règles de trafic sortant requises concernent les ressources nécessaires au bon fonctionnement de la solution, telles que Container Registry et Storage. Les règles de trafic sortant définies par l’utilisateur concernent les ressources personnalisées, telles que Azure OpenAI ou AI Search, que votre flux de travail va utiliser. Vous devez configurer les règles de trafic sortant définies par l’utilisateur. Les règles de trafic sortant requises sont configurées lors de la création du réseau virtuel géré. Le réseau virtuel managé est déployé à la demande lorsque vous l’utilisez pour la première fois et qu’il est persistant à partir de là.

Les règles de trafic sortant peuvent être des points de terminaison privés, des étiquettes de service ou des noms de domaine complets (FQDN) pour des points de terminaison publics externes. Dans cette architecture, la connectivité aux services Azure tels que Container Registry, Storage, Azure Key Vault, Azure OpenAI et AI Search est établie via Private Link. Bien que non incluses dans cette architecture, certaines opérations courantes pouvant nécessiter la configuration d’une règle de trafic sortant FQDN incluent le téléchargement d’un package pip, le clonage d’un référentiel GitHub ou le téléchargement d’images de conteneurs de base depuis des référentiels externes.

Segmentation et sécurité du réseau virtuel

Le réseau de cette architecture comporte des sous-réseaux séparés pour les besoins suivants :

• Application Gateway

• Composants d’intégration App Service

• Points de terminaison privés

• Azure Bastion

• Machine virtuelle jumpbox

• Sous-réseaux de formation et de scoring : ces deux éléments sont destinés à apporter votre propre calcul lié à l’entraînement et à l’inférence. Dans cette architecture, nous ne faisons pas d’entraînement et nous utilisons le calcul managé.

• Notation

Chaque sous-réseau a un groupe de sécurité réseau (NSG) qui limite le trafic entrant et sortant de ces sous-réseaux à ce qui est strictement nécessaire. Le tableau suivant montre une vue simplifiée des règles NSG ajoutées à chaque sous-réseau dans l’architecture de base. Le tableau fournit le nom de la règle et sa fonction.

Sous-réseau	Trafic entrant	Règle de trafic sortant
snet-appGateway	Autorisations pour les adresses IP sources de nos utilisateurs de l’interface utilisateur de chat (comme Internet public), plus les éléments requis pour le service.	Accès au point de terminaison privé de l’App Service, plus les éléments requis pour le service.
snet-PrivateEndpoints	Autoriser uniquement le trafic provenant du réseau virtuel.	Autoriser uniquement le trafic en direction du réseau virtuel.
snet-AppService	Autoriser uniquement le trafic provenant du réseau virtuel.	Autoriser l’accès aux points de terminaison privés et à Azure Monitor.
AzureBastionSubnet	Veuillez consulter les directives dans travailler avec l'accès NSG et Azure Bastion.	Veuillez consulter les directives dans travailler avec l'accès NSG et Azure Bastion.
snet-jumpbox	Autoriser le protocole de bureau à distance (RDP) entrant et SSH à partir du sous-réseau de l'hôte Azure Bastion.	Autoriser l’accès aux points de terminaison privés
snet-agents	Autoriser uniquement le trafic provenant du réseau virtuel.	Autoriser uniquement le trafic en direction du réseau virtuel.
snet-training	Autoriser uniquement le trafic provenant du réseau virtuel.	Autoriser uniquement le trafic en direction du réseau virtuel.
snet-scoring	Autoriser uniquement le trafic provenant du réseau virtuel.	Autoriser uniquement le trafic en direction du réseau virtuel.

Tout autre trafic est explicitement refusé.

Tenez compte des points suivants lors de l’implémentation de la segmentation et de la sécurité du réseau virtuel.

• Activer DDoS Protection pour le réseau virtuel avec un sous-réseau faisant partie d'un gateway d'application avec une adresse IP publique.

• Ajoutez un groupe de sécurité réseau à chaque sous-réseau si possible. Utiliser les règles les plus strictes qui permettent le bon fonctionnement de la solution.

• Utiliser des groupes de sécurité d’application pour regrouper les NSG. Le regroupement des NSG facilite la création de règles pour les environnements complexes.

Rotation des clés

Il existe un service dans cette architecture qui utilise l’authentification basée sur des clés : le point de terminaison en ligne géré par Machine Learning. Étant donné que vous utilisez l’authentification basée sur des clés pour ce service, il est important de :

• Stocker la clé dans un stockage sécurisé, comme Key Vault, pour un accès à la demande par des clients autorisés, tels que l’application Web Azure hébergeant le conteneur de flux d’invite.

• Implémenter une stratégie de rotation de clé. Si vous faites pivoter manuellement les clés, créez une stratégie d’expiration de clé et utilisez Azure Policy pour surveiller si la clé a été pivotée.

Réglage fin du modèle OpenAI

Si vous ajustez les modèles OpenAI dans votre implémentation, considérez les recommandations suivantes :

• Si vous téléchargez des données de formation pour le réglage fin, envisagez d’utiliser des clés gérées par le client pour chiffrer ces données.

• Si vous stockez des données de formation dans un stockage tel qu’Azure Blob Storage, envisagez d’utiliser une clé gérée par le client pour le chiffrement des données, une identité managée pour contrôler l’accès aux données, et un point de terminaison privé pour se connecter aux données.

Gouvernance par la politique

Pour aider à garantir l’alignement avec la sécurité, envisagez d’utiliser Azure Policy et une politique réseau afin que les déploiements soient conformes aux exigences de la charge de travail. L’utilisation de l’automatisation de la plateforme par la politique réduit le fardeau des étapes de validation manuelles et assure la gouvernance même si les pipelines sont contournés. Envisagez les politiques de sécurité suivantes :

• Désactiver l’accès par clé ou autre authentification locale dans des services tels que les services Azure AI et Key Vault.
• Exiger une configuration spécifique des règles d’accès réseau ou des NSG.
• Exiger le chiffrement, comme l’utilisation de clés gérées par le client.

Attributions de rôles Azure AI Studio pour Azure Key Vault

L’identité managée Azure AI Studio nécessite des attributions de rôles de plan de contrôle (Contributeur) et de plan de données (Administrateur Key Vault). Cela implique que cette identité aura un accès en lecture et écriture à tous les secrets, clés et certificats stockés dans Azure Key Vault. Si votre charge de travail a des services autres qu’Azure AI Studio qui nécessitent l’accès aux secrets, clés ou certificats dans Key Vault, votre charge de travail ou votre équipe de sécurité peut ne pas être à l’aise avec l’identité managée Azure AI Studio Hub ayant accès à ces artefacts. Dans ce cas, envisagez de déployer une instance Key Vault spécifiquement pour le hub Azure AI Studio et d’autres instances Azure Key Vault, selon les besoins d’autres parties de votre charge de travail.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Pour afficher un exemple de tarification pour ce scénario, utilisez la calculatrice de prix Azure. Vous devez personnaliser l’exemple pour correspondre à votre utilisation car cet exemple inclut seulement les composants présents dans l’architecture. Les composants les plus coûteux du scénario sont DDoS Protection et le pare-feu déployé dans le cadre du point de terminaison en ligne managé. D’autres coûts notables sont l’interface utilisateur de conversation et le calcul de flux d’invite et la recherche IA. Optimisez ces ressources pour économiser le plus de coûts.

Compute

Le flux d’invite prend en charge plusieurs options pour héberger les flux exécutables. Les options comprennent des points de terminaison en ligne gérés dans Machine Learning, AKS, App Service et Azure Kubernetes Service. Chacune de ces options a son propre modèle de facturation. Le choix de la capacité de calcul affecte le coût global de la solution.

Azure OpenAI

Azure OpenAI est un service basé sur la consommation, et comme avec n’importe quel service basé sur la consommation, le contrôle de la demande par rapport à l’offre est le principal contrôle des coûts. Pour ce faire spécifiquement dans Azure OpenAI, vous devez utiliser une combinaison d’approches :

• Contrôler les clients. Les requêtes des clients sont la principale source de coûts dans un modèle de consommation, donc contrôler le comportement des clients est crucial. Tous les clients doivent :

  • être approuvés ; éviter d’exposer le service de telle sorte qu’il prenne en charge l’accès gratuit pour tous ; Limitez l’accès à la fois par le réseau et les contrôles d’identité, tels que les clés ou le contrôle d’accès basé sur les rôles (RBAC).

  • être auto-contrôlés. Exiger que les clients utilisent les contraintes de limitation par jetons offertes par les appels d’API, telles que max_tokens et max_completions.

  • Utiliser le traitement par lot, le cas échéant. Examiner les clients pour vous assurer qu’ils effectuent correctement le traitement par lot des invites.

  • Optimiser l’entrée d’invites et la longueur de réponse. Les invites plus longues consomment davantage de jetons, augmentant le coût, cependant les invites qui n’ont pas suffisamment de contexte n’aident pas les modèles à produire de bons résultats. Créez des invites concises qui fournissent suffisamment de contexte pour permettre au modèle de générer une réponse utile. De même, assurez-vous d’optimiser la limite de la longueur de la réponse.

• Azure OpenAI playground doit être utilisé selon les besoins et sur des instances de préproduction, de sorte que ces activités n’entraînent pas de coûts de production.

• Sélectionnez le bon modèle d’IA. Le choix du modèle joue également un rôle important dans le coût global d’Azure OpenAI. Tous les modèles ont leurs avantages et leurs inconvénients et sont facturés individuellement. Utilisez le modèle correct pour le cas d’utilisation afin de vous assurer que vous ne dépensez pas trop pour un modèle plus coûteux alors qu’un modèle moins cher donne des résultats acceptables. Dans cette implémentation de référence de conversation, GPT 3.5-turbo a été choisi plutôt que GPT-4 afin d’économiser sur les coûts de déploiement de modèle tout en obtenant des résultats suffisants.

• Bien comprendre les points de rupture de la facturation. Le réglage fin est facturé à l’heure. Pour être le plus efficace, vous devez utiliser autant de temps disponible par heure pour améliorer les résultats de réglage fin tout en évitant de glisser juste dans la période de facturation suivante. De même, le coût pour 100 images générées est le même que le coût pour une image. Optimisez les points de rupture de prix à votre avantage.

• Bien comprendre les modèles de facturation. Azure OpenAI est également disponible dans un modèle de facturation basé sur l’engagement par le biais de l’offre de débit provisionné. Après avoir des modèles d’utilisation prévisibles, envisagez de passer à ce modèle de facturation pré-achetée s’il est plus rentable à votre volume d’utilisation.

• Définissez les limites d’approvisionnement. Assurez-vous que tout le quota d’approvisionnement est alloué uniquement aux modèles qui sont censés faire partie de la charge de travail, sur une base par modèle. Le débit pour les modèles déjà déployés n’est pas limité à ce quota provisionné tant que le quota dynamique est activé. Le quota ne se traduit pas directement en coûts et ces coûts peuvent varier.

• Surveillez l’utilisation du paiement à l’utilisation. Si vous utilisez une tarification à l’utilisation, surveillez l’utilisation de TPM et RPM. Utilisez ces informations pour éclairer les décisions de conception architecturale telles que les modèles à utiliser, et optimiser les tailles de prompt.

• Surveillez l’utilisation du débit approvisionné. Si vous utilisez le débit approvisionné, surveillez l’utilisation gérée par l’approvisionnement pour vous assurer que vous n’utilisez pas moins que le débit approvisionné que vous avez acheté.

• Gestion des coûts. Suivez les conseils concernant l’utilisation des fonctionnalités de gestion des coûts avec OpenAI pour surveiller les coûts, définir des budgets pour gérer les coûts et créer des alertes pour notifier les parties prenantes des risques ou des anomalies.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

Tous les services, à l'exception d'App Service, sont configurés pour capturer l'ensemble des journaux.

Comme dans l’architecture de base, cette architecture utilise l’exécution automatique pour minimiser la charge opérationnelle. L’exécution automatique est une option de calcul serverless au sein de Machine Learning qui simplifie la gestion du calcul et délègue la plupart de la configuration du flux d’invite au fichier requirements.txt et à la configuration flow.dag.yaml de l’application en cours d’exécution. Cela rend ce choix peu coûteux en maintenance, éphémère et axé sur les applications. Utiliser Compute Instance Runtime ou une capacité de calcul externalisée, comme dans cette architecture, nécessite un cycle de vie de calcul plus géré par l’équipe de la charge de travail, et doit être choisi lorsque les exigences de la charge de travail dépassent les capacités de configuration de l’option de runtime automatique.

Surveillance

Comme dans l’architecture de base, des diagnostics sont configurés pour tous les services. Lorsque vous passez en production, il est conseillé de supprimer les sources de journaux qui ne contribuent pas directement, afin d'éviter qu'elles n'ajoutent du bruit ou des coûts à votre charge de travail. App Service est configuré pour capturer AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs et AppServicePlatformLogs. En production, tous les journaux sont probablement excessifs. Paramétrez les flux de journaux en fonction de vos besoins opérationnels. Pour cette architecture, les journaux Azure Machine Learning utilisés par le projet Azure AI Studio qui sont intéressants sont les suivants : AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEvent et AmlModelsEvent.

Évaluez la création d’alertes personnalisées pour les ressources dans cette architecture telles que celles trouvées dans les alertes de base Azure Monitor. Par exemple :

• Alertes Container Registry
• Alertes Machine Learning et Azure OpenAI
• Alertes Azure Web Apps

Veillez à suivre l’utilisation des jetons par rapport à vos déploiements de modèles Azure OpenAI. Dans cette architecture, le flux d’invite effectue le suivi de l’utilisation des jetons via son intégration à Azure Application Insights.

Opérations de modèle de langage

Le déploiement de solutions de chat basées sur Azure OpenAI comme cette architecture doit suivre les conseils dans GenAIOps avec flux d’invite avec Azure DevOps et GitHub. De plus, il doit tenir compte des meilleures pratiques pour l’intégration continue et la livraison continue (CI/CD) et les architectures sécurisées par le réseau. Les instructions suivantes traitent de l’implémentation des flux et de leur infrastructure associée en fonction des recommandations GenAIOps. Ces instructions de déploiement n’incluent pas les éléments d’application front-end, qui ne sont pas modifiés dans l’architecture d’application web redondante interzone de référence hautement disponible.

Développement

Le flux d’invite offre à la fois une expérience de création basée sur un navigateur dans Azure AI Studio ou via une extension Visual Studio Code. Les deux options stockent le code du flux sous forme de fichiers. Lorsque vous utilisez Azure AI Studio, les fichiers sont stockés dans un compte de stockage. Lorsque vous travaillez dans Microsoft Visual Studio Code, les fichiers sont stockés dans votre système de fichiers local.

Pour suivre les meilleures pratiques de développement collaboratif, les fichiers sources doivent être conservés dans un référentiel de code source en ligne tel que GitHub. Cette approche facilite le suivi de toutes les modifications de code, la collaboration entre les auteurs de flux et l’intégration avec les flux de déploiement qui testent et valident toutes les modifications de code.

Pour le développement en entreprise, utilisez l'extension Microsoft Visual Studio Code et le SDK/CLI de flux d'invite pour le développement. Les auteurs de flux d'invite peuvent générer et tester leurs flux à partir de Microsoft Visual Studio Code et intégrer les fichiers stockés localement avec le système et les pipelines de contrôle de code source en ligne. Bien que l’expérience basée sur le navigateur soit bien adaptée au développement exploratoire, avec un certain travail, elle peut être intégrée au système de contrôle de code source. Le dossier de flux peut être téléchargé à partir de la page de flux dans le panneau Files, décompressé et envoyé (push) au système de contrôle de code source.

Évaluation

Testez les flux utilisés dans une application de chat comme vous testez d’autres artefacts logiciels. Il est difficile de spécifier et d’affirmer une seule « bonne » réponse pour les sorties de modèles de langage, mais vous pouvez utiliser un modèle de langage lui-même pour évaluer les réponses. Envisagez de mettre en œuvre les évaluations automatisées suivantes de vos flux de modèles de langage :

• Précision de classification : Évalue si le modèle de langage donne une note "correcte" ou "incorrecte" et agrège les résultats pour produire une note de précision.

• Cohérence : évalue la façon dont sont écrites les phrases contenues dans la réponse prédite d’un modèle et avec quel degré de cohérence elles se connectent les unes avec les autres.

• Fluidité : évalue la précision grammaticale et linguistique de la réponse prédite du modèle.

• Adéquation avec le contexte : Évalue dans quelle mesure les réponses prédites par le modèle sont basées sur un contexte préconfiguré. Même si les réponses du modèle de langage sont correctes, si elles ne peuvent pas être validées par rapport au contexte donné, alors de telles réponses ne sont pas adéquates.

• Pertinence : évalue le degré de correspondance des réponses prédites du modèle par rapport à la question posée.

Tenez compte des instructions suivantes lors de l’implémentation d’évaluations automatisées :

• Générez des scores à partir d’évaluations et comparez-les à un seuil de réussite prédéfini. Utilisez ces scores pour signaler la réussite/l’échec des tests dans vos pipelines.

• Certains de ces tests nécessitent des entrées de données préconfigurées de questions, du contexte et une vérité établie.

• Ajoutez suffisamment de paires question-réponse pour vous assurer que les résultats des tests sont fiables (minimum 100-150 paires recommandées). Ces paires question-réponse sont appelées « golden dataset ». Une population plus importante peut être nécessaire en fonction de la taille et du domaine de votre jeu de données.

• Évitez d’utiliser des modèles de langage pour générer des données dans votre ensemble de données de référence.

Flux de déploiement

1. L’ingénieur d’invite/le scientifique de données ouvre une branche de fonctionnalité où travailler sur la tâche ou fonctionnalité spécifique. L'ingénieur de flux/données itère sur le flux en utilisant le flux d'invite pour Microsoft Visual Studio Code, en engageant périodiquement les modifications et en poussant ces modifications à la branche de fonctionnalité.

2. Une fois le développement et l’expérimentation locaux terminés, l’ingénieur d’invite/le scientifique de données ouvre une demande de tirage entre la branche de fonctionnalité et la branche principale. La demande de tirage (PR) déclenche un pipeline PR. Ce pipeline exécute des contrôles de qualité rapides qui doivent inclure :

   • Exécution de flux d’expérimentation
   • Exécution de tests unitaires configurés
   • Compilation de la base de code
   • Analyse statique du code

3. Le pipeline peut contenir une étape qui nécessite qu’au moins un membre de l’équipe approuve manuellement la demande de tirage avant la fusion. L’approbateur ne peut pas être le commiteur et ils doivent avoir une expertise de flux d’invite et une bonne connaissance des exigences du projet. Si la demande de tirage n’est pas approuvée, la fusion est bloquée. Si la demande de tirage est approuvée ou qu’il n’y a pas d’étape d’approbation, la branche de fonctionnalité est fusionnée dans la branche principale.

4. La fusion dans la branche principale déclenche le processus de génération et de mise en production pour l’environnement de développement. Plus précisément :

   1. Le pipeline d’intégration continue est déclenché par la fusion dans la branche principale. Le pipeline d’intégration continue effectue toutes les étapes réalisées dans le pipeline de demande de tirage, ainsi que les étapes suivantes :
   • Flux d’expérimentation
   • Flux d’évaluation
   • Enregistre les flux dans le registre Machine Learning lorsque des modifications sont détectées.
   1. Le pipeline de déploiement continu est déclenché après la fin du pipeline d’intégration continue. Ce flux effectue les étapes suivantes :
   • Déploie le flux du registre Machine Learning vers un point de terminaison en ligne Machine Learning.
   • Exécute des tests d’intégration qui ciblent le point de terminaison en ligne
   • Exécute des tests de détection de fumée qui ciblent le point de terminaison en ligne

5. Un processus d’approbation est intégré au processus de promotion de mise en production : lors de l’approbation, les processus d’intégration continue & et de déploiement continu décrits dans les étapes 4.a. & 4.b. sont répétés, ciblant l’environnement de test. Les étapes a. et b. sont identiques, à l’exception du fait que les tests d’acceptation utilisateur sont exécutés après les tests de détection de fumée dans l’environnement de test.

6. les processus d’intégration continue & et de déploiement continu décrits dans les étapes 4.a. & 4.b. sont exécutés pour promouvoir la mise en production dans l’environnement de production une fois l’environnement de test vérifié et approuvé.

7. Après la mise en production, les tâches opérationnelles de surveillance des métriques de performance et d’évaluation des modèles de langage déployés ont lieu. Cela comprend, entre autres :

   • La détection des dérives de données
   • L’observation de l’infrastructure
   • Gestion des coûts
   • La communication des performances du modèle aux parties prenantes

Aide au déploiement

Vous pouvez utiliser les points de terminaison Machine Learning pour déployer des modèles de manière à permettre une flexibilité lors du déploiement en production. Tenez compte des stratégies suivantes pour garantir des performances et une qualité des modèles optimales :

• Déploiements bleu/vert : avec cette stratégie, vous pouvez déployer en toute sécurité votre nouvelle version du service web sur un groupe limité d’utilisateurs ou de requêtes avant de diriger tout le trafic vers le nouveau déploiement.

• Tests A/B : Non seulement les déploiements bleu/vert sont efficaces pour déployer des modifications en toute sécurité, mais ils peuvent également être utilisés pour déployer un nouveau comportement qui permet à un sous-ensemble d’utilisateurs d’évaluer l’impact du changement.

• Incluez le linting des fichiers Python qui font partie du flux d’invite dans vos pipelines. Le linting vérifie la conformité avec les normes de style, les erreurs, la complexité du code, les importations inutilisées et le nommage des variables.

• Lorsque vous déployez votre flux dans l’espace de travail Machine Learning isolé en réseau, utilisez un agent auto-hébergé pour déployer les artefacts vers vos ressources Azure.

• Le registre des modèles Machine Learning ne doit être mis à jour que lorsqu’il y a des modifications du modèle.

• Les modèles de langage, les flux et l’interface utilisateur client doivent être faiblement couplés. Les mises à jour vers les flux et l’interface utilisateur du client peuvent et doivent être en mesure d’être effectuées sans affecter le modèle et vice versa.

• Lorsque vous développez et déployez plusieurs flux, chaque flux doit avoir son propre cycle de vie, ce qui permet une expérience faiblement couplée lors de la promotion des flux de l’expérimentation à la production.

Infrastructure

Lorsque vous déployez les composants de chat de bout en bout Azure OpenAI de base, certains des services approvisionnés sont fondamentaux et permanents dans l’architecture, tandis que d’autres composants sont plus éphémères par nature, leur existence étant liée à un déploiement. En outre, bien que le réseau virtuel managé soit fondamental, il est automatiquement approvisionné lorsque vous créez une instance de calcul qui entraîne certaines considérations.

Composants fondamentaux

Certains composants de cette architecture existent avec un cycle de vie qui s’étend au-delà d’un flux d’invite individuel ou d’un déploiement de modèle. Ces ressources sont généralement déployées une fois dans le cadre du déploiement fondamental par l’équipe de charge de travail, et conservées en dehors des flux d’invite ou déploiements de modèles nouveaux, supprimés ou mis à jour.

• Espace de travail Machine Learning
• Compte de stockage pour l’espace de travail Machine Learning.
• Container Registry
• Recherche AI
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• Machine virtuelle Azure pour la jumpbox

Composants éphémères

Certaines ressources Azure sont plus étroitement couplées à la conception de flux d’invite spécifiques. Cette approche permet à ces ressources d’être liées au cycle de vie du composant et de devenir éphémères dans cette architecture. Les ressources Azure sont affectées lorsque la charge de travail évolue, comme lorsque des flux sont ajoutés ou supprimés ou lorsque de nouveaux modèles sont introduits. Ces ressources sont recréées et les instances antérieures supprimées. Certaines de ces ressources sont des ressources Azure directes et certaines sont des manifestations de plan de données au sein de leur service conteneur.

• Le modèle dans le registre des modèles Machine Learning doit être mis à jour, s’il change, dans le cadre du pipeline CD.

• L’image conteneur doit être mise à jour dans le registre de conteneurs comme faisant partie du pipeline de déploiement continu.

• Un point de terminaison Machine Learning est créé lorsqu’un flux d’invite est déployé si le déploiement référence un point de terminaison qui n’existe pas. Ce point de terminaison doit être mis à jour pour désactiver l’accès public.

• Les déploiements de points de terminaison Machine Learning sont mis à jour lorsqu’un flux est déployé ou supprimé.

• Le coffre de clés de l'interface utilisateur du client doit être mis à jour avec la clé du point de terminaison lorsqu'un nouveau point de terminaison est créé.

Réseau virtuel managé à la demande

Le réseau virtuel managé est automatiquement approvisionné lors de la création d’une instance de calcul. Si vous utilisez l’infrastructure en tant que code pour déployer votre hub et que vous n’avez pas de ressources de calcul AI Studio dans Bicep, le réseau virtuel managé n’est pas déployé et vous recevez une erreur lors de la connexion à Azure AI Studio. Vous devez effectuer une action ponctuelle pour provisionner manuellement le réseau virtuel managé après votre déploiement IaC.

Organisation des ressources

Si vous avez un scénario où le hub appartient de manière centralisée à une équipe autre que l’équipe de charge de travail, vous pouvez choisir de déployer des projets sur des groupes de ressources distincts. Si vous utilisez l’infrastructure infrastrastructure en tant que code, vous pouvez le faire en définissant un autre groupe de ressources dans Bicep. Si vous utilisez le portail, vous pouvez définir la defaultWorkspaceResourceGroup propriété sous le workspaceHubConfig groupe de ressources que vous souhaitez créer pour vos projets.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Cette section décrit l’efficacité des performances du point de vue d’Azure Search, Azure OpenAI et Machine Learning.

Azure Search - efficacité des performances

Suivez les conseils pour analyser les performances dans AI Search.

Azure OpenAI - efficacité des performances

• Déterminez si votre application nécessite un débit approvisionné ou le modèle d’hébergement partagé, ou consommation. Le débit provisionné garantit une capacité de traitement réservée pour vos déploiements de modèles OpenAI, ce qui offre des performances et un débit prévisibles pour vos modèles. Ce modèle de facturation est différent du modèle d’hébergement partagé, ou de consommation. Le modèle de consommation est un best-effort et peut être soumis à des voisins bruyants ou à d’autres stress sur la plateforme.

• Surveillez l’utilisation gérée par l’approvisionnement pour le débit approvisionné.

Machine Learning - efficacité des performances

Si vous déployez sur des points de terminaison en ligne Machine Learning :

• Suivez les conseils sur la manière de mettre à l’échelle automatiquement un point de terminaison en ligne. Faites cela pour rester étroitement aligné avec la demande sans surapprovisionnement excessif, surtout pendant les périodes de faible utilisation.

• Choisissez la référence SKU de machine virtuelle appropriée pour le point de terminaison en ligne afin de répondre à vos objectifs de performances. Testez les performances à la fois d’un nombre d’instances inférieur et de plus grands SKU par rapport à un nombre d’instances plus élevé et de plus petits SKU pour trouver une configuration optimale.

Déployer ce scénario

Pour déployer et exécuter l’implémentation de référence, suivez les étapes dans la section implémentation de référence de base OpenAI de bout en bout.

Contributeurs

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

• Rob Bagby | Modèles & pratiques - Microsoft
• Freddy Ayala | Architecte de solution cloud - Microsoft
• Prabal Deb | Ingénieur logiciel senior - Microsoft
• Raouf Aliouat | Ingénieur logiciel II - Microsoft
• Ritesh Modi | Ingénieur logiciel principal - Microsoft
• Ryan Pfalz | Architecte de solution senior - Microsoft

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

Étape suivante

Ressources associées

• Azure OpenAI
• Modèles de langage Azure OpenAI
• Flux d’invite dans Azure AI Studio
• Isolation du réseau virtuel managé de l’espace de travail
• Configurer un point de terminaison privé pour un espace de travail Machine Learning
• Filtrage du contenu