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

Beaucoup des composants de cette architecture sont les mêmes que les ressources de l’architecture de l’application web de base App Service car la méthode utilisée pour héberger l’interface utilisateur de chat est la même dans les deux architectures. Les composants mis en évidence dans cette section se concentrent sur les composants utilisés pour construire et orchestrer les flux de chat, les services de données et les services qui exposent les modèles de langage.

• Machine Learning est un service cloud géré que vous pouvez utiliser pour entraîner, déployer et gérer des modèles de machine learning. Cette architecture utilise plusieurs autres fonctionnalités de Machine Learning qui sont utilisées pour développer et déployer des flux exécutables pour des applications d’IA alimentées par des modèles de langage:

  • Le flux d’invite Machine Learning (Machine Learning prompt flow) est un outil de développement que vous pouvez utiliser pour construire, évaluer et déployer des flux qui lient les invites des utilisateurs, les actions via du code Python et les appels aux modèles d’apprentissage des langues. Le flux d’invite est utilisé dans cette architecture comme la couche qui orchestre les flux entre l’invite, les différents magasins de données et le modèle de langage.

  • Les points de terminaison en ligne gérés vous permettent de déployer un flux pour l’inférence en temps réel. Dans cette architecture, ils sont utilisés comme un point de terminaison PaaS pour que l’interface utilisateur de chat invoque les flux d’invite hébergés par Machine Learning.

• Storage est utilisé pour conserver les fichiers source du flux d’invite pour le développement de flux d’invite.

• Container Registry vous permet de créer, stocker et gérer des images de conteneurs et des artefacts dans un registre privé pour tous types de déploiements de conteneurs. Dans cette architecture, les flux sont emballés comme des images de conteneurs et stockés dans Container Registry.

• 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. Dans cette architecture, outre l’accès au modèle, il est utilisé pour ajouter des fonctionnalités d’entreprise courantes telles que le réseau virtuel et la liaison privée, la prise en charge des identités managées et le filtrage de contenu.

• Azure AI Search est un service de recherche cloud qui prend en charge la recherche en texte intégral, la recherche sémantique, la recherche vectorielle et la recherche hybride. AI Search est inclus dans l’architecture car c’est un service commun utilisé dans les flux derrière les applications de chat. AI Search peut être utilisé pour récupérer et indexer des données pertinentes pour les requêtes des utilisateurs. Le flux d’invite implémente le modèle RAG (Retrieval Augmented Generation) pour extraire la requête appropriée de l’invite, interroger AI Search et utiliser les résultats comme données de base pour le modèle Azure OpenAI.

Flux d’invite Machine Learning

Le back-end pour les applications de conversation d’entreprise suit généralement un modèle similaire au flux suivant :

• L’utilisateur saisit une invite dans une interface utilisateur (UI) de chat personnalisée.
• Cette invite est envoyée au backend par le code de l’interface.
• L’intention de l’utilisateur, soit question soit directive, est extraite de l’invite par le backend.
• Optionnellement, le backend détermine les magasins de données qui contiennent des données pertinentes pour l’invite de l’utilisateur.
• Le backend interroge les magasins de données pertinents.
• Le backend envoie l’intention, les données de base pertinentes et tout historique fourni dans l’invite au modèle de langage.
• Le backend retourne le résultat pour qu’il soit affiché sur l’interface utilisateur.

Le back-end pourrait être implémenté dans un certain nombre de langues et déployé sur différents services Azure. Cette architecture utilise le flux d’invite Machine Learning car il fournit une expérience simplifiée pour construire, tester et déployer des flux qui orchestrent entre les invites, les magasins de données backend et les modèles de langage.

Exécutions de flux d’invite

Machine Learning peut héberger directement deux types d’exécutions de flux d’invite.

• Exécution automatique : Une option de calcul sans serveur qui gère le cycle de vie et les caractéristiques de performance du calcul et permet une personnalisation du flux d’environnement.

• Exécution d’instance de calcul : Une option de calcul toujours activée dans laquelle l’équipe de travail doit sélectionner les caractéristiques de performance. Cette exécution offre plus de personnalisation et de contrôle de l’environnement.

Les flux d’invite peuvent également être hébergés en dehors de la capacité de calcul Machine Learning sur des plateformes hôtes de conteneurs. Cette architecture utilise App Service pour démontrer l’hébergement externe.

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
• Points de terminaison privés
• 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 l’entrée RDP et SSH depuis le sous-réseau 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 la protection DDoS 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.

Filtrage de contenu et monitoring des abus

Azure OpenAI comprend un système de filtrage de contenu qui utilise un ensemble de modèles de classification pour détecter et prévenir des catégories spécifiques de contenu potentiellement nuisible dans les invites d’entrée et les complétions de sortie. Les catégories de ce contenu potentiellement nuisible incluent la haine, le contenu sexuel, l’automutilation, la violence, les injures et le contournement (contenu conçu pour contourner les contraintes d’un modèle de langage). Vous pouvez configurer le niveau de filtrage du contenu pour chaque catégorie : niveau faible, moyen ou élevé. Cette architecture de référence adopte un niveau de filtrage élevé. Ajustez les paramètres selon vos besoins.

En plus du filtrage de contenu, Azure OpenAI met en œuvre des fonctionnalités de surveillance des abus. La surveillance des abus est une opération asynchrone conçue pour détecter et atténuer les instances de contenu ou de comportements récurrents qui suggèrent une utilisation du service d’une manière qui pourrait violer le code de conduite Azure OpenAI. Vous pouvez demander une exemption de la surveillance des abus et de la révision humaine si vos données sont hautement sensibles ou si des politiques internes ou des réglementations légales applicables empêchent le traitement des données pour la détection des abus.

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 sont assignés à partir de votre quota pour répondre à la demande de vos déploiements et empêcher les appels à vos modèles déployés d’être 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é

Cette architecture implémente à la fois un réseau et un périmètre de sécurité d’identité. 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.

Cette section décrit les considérations en matière de gestion des identités et des accès et de sécurité pour la rotation des clés et le réglage fin du modèle Azure OpenAI.

Gestion des identités et des accès

Les instructions suivantes étendent les instructions de gestion des identités et des accès à la base de référence App Service :

• 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 y a un AzureML Learning Workspace Connection Secrets Reader et un AzureML Registry User 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.

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

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.

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 incluent des points de terminaison en ligne gérés dans Machine Learning, AKS, App Service et Azure Container 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 décrit les processus opérationnels qui déploient une application et la maintiennent 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

Pour minimiser le fardeau opérationnel, le Runtime Automatique est une option de calcul sans serveur dans 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 de l’application en cours d’exécution et la configuration flow.dag.yaml. 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

Les 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 clients 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 LLMOps 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 LLMOps. 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 VS 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 VS 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 VS 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 VS 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 :

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

   b. 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 à évoluer efficacement pour répondre aux demandes des utilisateurs. 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