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 d’Azure Machine Learning 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 cluster de calcul Machine Learning derrière un point de terminaison en ligne géré.

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 Services. 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 à l’espace de travail Machine Learning est désactivé.

L’espace de travail Machine Learning est configuré avec l’isolation du 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.

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 Private Link, que l’architecture de base n’implémente pas.
• 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é.

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.

Le déploiement des flux d’invite ne se limite pas aux clusters de calcul Machine Learning. Le flux exécutable, étant une application conteneurisée, peut être déployé sur tout service Azure compatible avec les conteneurs. Ces options incluent des services comme Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps et 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 rédigés dans le flux d’invite Machine Learning et l’architecture réseau de Machine Learning reste inchangée. Les auteurs de flux se connectent toujours à l’expérience de rédaction de l’espace de travail via un point de terminaison privé, et les points de terminaison privés gérés sont utilisés pour se connecter aux services Azure lors des tests des 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.

3. Il y a une autre application web déployée sur le même plan App Service qui héberge déjà l’interface utilisateur de chat. La nouvelle application web héberge le flux d’invite conteneurisé, avec une colocation sur le même plan App Service qui fonctionne déjà avec un minimum de trois instances, réparties dans 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 API Management peut être déployée devant votre service OpenAI ou vos services et peut être configurée pour réessayer en cas d’erreurs transitoires et de limitations. 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.

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.

Machine Learning - fiabilité

Si vous déployez sur des clusters de calcul derrière le point de terminaison en ligne géré par Machine Learning, prenez en considération les conseils suivants 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.

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 séparées pour les ressources Machine Learning suivantes, le cas échéant :
  • Espaces de travail pour la rédaction et la gestion des flux
  • Instances de calcul pour tester les 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

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

Il existe cinq rôles par défaut que vous pouvez utiliser pour gérer l’accès à votre espace de travail Machine Learning : AzureML Data Scientist, AzureML Compute Operator, Reader, Contributor et Owner. En plus de ces rôles par défaut, il existe un lecteur des secrets de connexion d’espace de travail Azure Machine Learning et un utilisateur du registre AzureML qui peuvent accorder l’accès aux ressources de l’espace de travail, telles que les secrets de l’espace de travail et le registre.

Étant donné que l'architecture repose sur des identités gérées par l'utilisateur, il vous incombe de définir les attributions de rôles appropriées. Cette architecture suit le principe du moindre privilège en n’assignant des rôles aux identités précédentes que là où c’est nécessaire. Considérez les attributions de rôles suivantes.

Identité managée	Étendue	Affectations de rôles
Identité managée de l’espace de travail	Resource group	Contributeur
Identité managée de l’espace de travail	Compte de stockage de l’espace de travail	Contributeur aux données Blob du stockage
Identité managée de l’espace de travail	Compte de stockage de l’espace de travail	Contributeur privilégié des données du fichier de stockage
Identité managée de l’espace de travail	Coffre de clés de l’espace de travail	Administrateur Key Vault
Identité managée de l’espace de travail	Registre de conteneurs de l’espace de travail	AcrPush
Identité managée de point de terminaison en ligne	Azure OpenAI	Utilisateur OpenAI Cognitive Services
Identité managée de point de terminaison en ligne	Registre de conteneurs de l’espace de travail	AcrPull
Identité managée de point de terminaison en ligne	Compte de stockage de l’espace de travail	Lecteur des données blob du stockage
Identité managée de point de terminaison en ligne	Espace de travail Machine Learning	Lecteur des secrets de connexion de l’espace de travail AzureML
Identité managée de l’instance de calcul	Registre de conteneurs de l’espace de travail	AcrPull
Identité managée de l’instance de calcul	Compte de stockage de l’espace de travail	Lecteur des données blob du stockage

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.

Flux du réseau virtuel géré par Machine Learning vers les services PaaS Azure

Nous recommandons de configurer l’espace de travail Machine Learning pour l’isolation du réseau virtuel géré qui nécessite l’approbation de toutes les connexions sortantes. 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é.

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
• Instances Private Endpoint
• Azure Bastion
• Machine virtuelle jumpbox
• Formation : non utilisée pour l’entraînement de modèle dans cette architecture
• 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 y a deux services dans cette architecture qui utilisent l’authentification basée sur les clés : Azure OpenAI et le point de terminaison en ligne géré par Machine Learning. Étant donné que vous utilisez l’authentification par clé pour ces services, 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 une rotation manuelle des clés, créez une politique d’expiration des clés et utilisez Azure Policy pour surveiller si la clé a été renouvelé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 de l’espace de travail Azure Machine Learning pour Azure Key Vault

L’identité gérée de l’espace de travail Azure Machine Learning nécessite à la fois des attributions de rôle au plan de contrôle (Contributeur) et au 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 comprend des services autres qu’Azure Machine Learning qui nécessitent un accès aux secrets, clés ou certificats dans Key Vault, votre charge de travail ou votre équipe de sécurité pourrait ne pas être à l’aise avec le fait que l’identité gérée de l’espace de travail Azure Machine Learning ait accès à ces artefacts. Dans ce cas, envisagez de déployer une instance Key Vault spécifiquement pour l’espace de travail Azure Machine Learning, et d’autres instances Azure Key Vault selon les besoins pour les 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 dans le scénario sont l’interface utilisateur de chat et la capacité de calcul des flux d’invite et AI Search. Optimisez ces ressources pour économiser le plus de coûts.

Compute

Le flux d’invite Machine Learning 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.

Machine Learning - environnements d’exécution intégrés pour le flux d’invite

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. Tous les services sauf Machine Learning et App Service sont configurés pour capturer tous les journaux. Les diagnostics de Machine Learning sont configurés pour capturer les journaux d’audit qui sont tous les journaux de ressources enregistrant les interactions des utilisateurs avec les données ou les paramètres du service. App Service est configuré pour capturer AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs et AppServicePlatformLogs.

É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

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

Machine Learning prompt flow offre à la fois une expérience de rédaction basée sur un navigateur dans Machine Learning studio ou via une extension Visual Studio Code. Les deux options stockent le code du flux sous forme de fichiers. Lorsque vous utilisez Machine Learning 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.

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éé.

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 Machine Learning
• 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