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

Les applications de chat d’entreprise permettent aux employés de gagner en autonomie par le biais d’une interaction conversationnelle. Cela est particulièrement vrai grâce à l’amélioration continue des modèles de langage volumineux tels que les modèles GPT d’OpenAI et les modèles LLaMA de Meta. Ces applications de conversation se composent d’une interface utilisateur pour la conversation, de référentiels de données contenant des informations spécifiques au domaine pertinentes pour les requêtes de l’utilisateur, des modèles de langage volumineux (LLM) qui raisonnaient 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 la création et le déploiement d’applications de conversation d’entreprise qui utilisent des modèles de langage volumineux Azure OpenAI. L’architecture utilise le flux d'invite Azure Machine Learning (AML) pour créer des flux exécutables qui orchestrent le workflow à partir d’invites entrantes vers des magasins de données pour extraire des données de base pour les LLM, ainsi que toute autre logique Python requise. Le flux exécutable est déployé sur un cluster de calcul Azure Machine Learning derrière un point de terminaison en ligne managé.

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 les services PaaS Azure via l’intégration de réseau virtuel sur des points de terminaison privés. De même, l’interface utilisateur de conversation App Service communique avec le point de terminaison en ligne managé pour le flux sur un point de terminaison privé et l’accès public à l’espace de travail Azure 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 managé est créé, ainsi que des points de terminaison privés managés qui permettent la connectivité à des ressources privées telles que l’espace de travail Stockage Azure, Azure Container Registry et Azure OpenAI. Ces connexions privées sont utilisées lors des phases de création et de test du flux, et via les flux déployés sur la capacité de calcul Machine Learning.

Architecture

Figure 1 : architecture de conversation de bout en bout de référence avec OpenAI

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

Composants

La plupart des composants de cette architecture sont identiques aux ressources de l’application web des services d’application de base, car l’interface utilisateur de conversation qui héberge dans cette architecture suit l’architecture de l’application web App Service de base. Les composants mis en évidence dans cette section se concentrent sur les composants utilisés pour générer et orchestrer des flux de conversation, ainsi que les services de données et les services qui exposent les modules LLM.

• Azure Machine Learning est un service cloud managé qui permet d'effectuer l'apprentissage, de déployer et de gérer des modèles Machine Learning. Cette architecture utilise plusieurs autres fonctionnalités d’Azure Machine Learning utilisées pour développer et déployer des flux exécutables pour les applications IA optimisées par des modèles de langage volumineux (LLM) :
  • Le flux d'invite Azure Machine Learning est un outil de développement qui vous permet de générer, d’évaluer et de déployer des flux qui lient des invites utilisateur, des actions via du code Python et des appels à des LLM. Le flux d'invite est utilisé dans cette architecture comme couche qui orchestre les flux entre l’invite, les différents magasins de données et le LLM.
  • Les points de terminaison en ligne gérés permettent de déployer un flux pour une interface en temps réel. Dans cette architecture, ils sont utilisés comme point de terminaison PaaS pour l’interface utilisateur de conversation afin d’appeler les flux d'invite hébergés par Azure Machine Learning.
• Stockage Azure est utilisé pour conserver les fichiers sources de flux d'invite pour le développement du flux d'invite.
• Azure Container Registry vous permet de créer, de stocker et de gérer des images conteneur et des artefacts dans un conteneur privé pour tous les types de déploiement de conteneur. Dans cette architecture, les flux sont empaquetés sous forme d’images conteneur et stockés dans Azure Container Registry.
• Azure OpenAI est un service entièrement managé qui fournit un accès API REST aux modèles de langage volumineux d’Azure OpenAI, notamment à l’ensemble 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. Azure AI Search est inclus dans l’architecture, car il s’agit d’un service courant utilisé dans les flux derrière les applications de conversation. Azure AI Search peut être utilisé pour récupérer et indexer des données pertinentes pour les requêtes utilisateur. Le flux d'invite implémente le modèle RAG (Retrieval Augmented Generation) pour extraire de l’invite la requête appropriée, interroger la recherche IA et utiliser les résultats comme données de base pour le modèle Azure OpenAI.

Flux d'invite Azure 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 entre une invite dans une interface utilisateur de conversation personnalisée
• Cette invite est envoyée au back-end par le code de l’interface
• L’intention de l’utilisateur (question ou directive) est extraite de l’invite par le back-end
• (facultatif) Le back-end détermine le ou les magasins de données qui contiennent des données pertinentes pour l’invite de l’utilisateur
• Le back-end interroge le ou les magasins de données appropriés
• Le back-end envoie l’intention, les données de base pertinentes et tout historique fourni dans l’invite au LLM.
• Le back-end retourne le résultat pour qu’il puisse être 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. Dans cette architecture, le flux d'invite Azure Machine Learning a été choisi, car il offre une expérience simplifiée pour générer, tester et déployer des flux qui orchestrent entre les invites, les magasins de données de back-end et les LLM.

Mise en réseau

En plus de l’accès basé sur l’identité, la sécurité réseau est au cœur de l’architecture de conversation de bout en bout de référence grâce à OpenAI. À partir d’un niveau élevé, l’architecture réseau garantit les éléments suivants :

• Un point d’entrée unique et sécurisé pour le trafic de l’interface utilisateur de conversation
• Le trafic réseau est filtré
• Les données en transit sont chiffrées de bout en bout avec TLS
• L’exfiltration de données est minimisée en conservant le trafic dans Azure via une liaison privée
• Les ressources réseau sont logiquement regroupées et isolées les unes des autres par le biais de la segmentation réseau

Flux réseau

Figure 2 : Flux réseau de l’architecture de conversation de bout en bout de référence avec OpenAI

Deux flux dans ce diagramme sont abordés dans l’application web des services d’application de base : 1. flux entrant allant de l’utilisateur final à l’interface utilisateur de conversation et 2. flux reliant App Service aux services Azure PaaS. Pour plus d’informations sur ces flux, consultez cet article. Cette section se concentre sur le flux de point de terminaison en ligne Azure Machine Learning. Les détails suivants concernent le flux allant de l’interface utilisateur de conversation en cours d’exécution dans l’application web App Service de référence au flux déployé vers la capacité de calcule Azure Machine Learning :

1. L’appel provenant de l’interface utilisateur de conversation hébergée par App Service est acheminé via un point de terminaison privé vers le point de terminaison en ligne Azure 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 équilibreur de charge et 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 dans Azure Machine Learning

Dans cette architecture, l’accès public à l’espace de travail Azure Machine Learning est désactivé et l’accès peut se produire via un accès privé, dans la mesure où il suit le point de terminaison privé pour la configuration de l’espace de travail Azure Machine Learning. En effet, 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, en autorisant votre interface utilisateur de conversation hébergée dans App Service à se connecter aux services PaaS non exposés à l’Internet public, y compris les points de terminaison Azure Machine Learning.

L’accès au point de terminaison privé est également nécessaire pour la connexion à l’espace de travail Azure Machine Learning pour la création de flux.

Figure 3 : Flux réseau d'un créateur de flux d'invite Azure Machine Learning

Le diagramme illustre un créateur de flux d'invite se connectant via Azure Bastion à une jumpbox de machine virtuelle. À partir de cette jumpbox, le créateur peut se connecter à l’espace de travail Machine Learning via un point de terminaison privé dans le même réseau que la jumpbox. 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 allant du réseau virtuel managé Azure Machine Learning aux services PaaS Azure

Il est recommandé que l’espace de travail Azure Machine Learning soit configuré pour l’isolation du réseau virtuel managé avec une configuration qui nécessite que toutes les connexions sortantes soient approuvées. Cette architecture suit cette recommandation. Il existe deux types de règles de trafic sortant approuvé. Les règles de trafic sortant requises concernent les ressources requises pour que la solution fonctionne, comme Azure Container Registry et Stockage Azure. Les règles de trafic sortant définies par l’utilisateur concernent les ressources personnalisées, comme Azure OpenAI ou Azure AI Search, que votre workflow va utiliser. Il vous incombe de configurer des règles de trafic sortant définies par l’utilisateur, tandis que les règles de trafic sortant requises sont configurées lors de la création du réseau virtuel managé.

Les règles de trafic sortant peuvent être des points de terminaison privés, des étiquettes de service ou des FQDN pour les points de terminaison publics externes. Dans cette architecture, la connexion aux services Azure tels qu’Azure Container Registry, Stockage Azure, Azure Key Vault, le service Azure OpenAI et Azure AI Search est effectuée via une liaison privée. Bien qu’absentes dans cette architecture, certaines opérations courantes qui peuvent nécessiter la configuration d’une règle de trafic sortant FQDN téléchargent un package pip, clonent un dépôt GitHub, téléchargent des images conteneur de base à partir de référentiels externes.

Segmentation et sécurité du réseau virtuel

Le réseau de cette architecture comporte des sous-réseaux distincts pour les éléments 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 qui limite le trafic entrant et sortant pour ces sous-réseaux à ce qui est requis. Le tableau suivant montre une vue simplifiée des règles de groupe de sécurité réseau que la base de référence ajoute à chaque sous-réseau. Le tableau donne le nom de la règle et la fonction.

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.

• Activez la protection DDoS pour le réseau virtuel avec un sous-réseau qui fait partie d’une passerelle applicative avec une adresse IP publique.
• Ajoutez un groupe de sécurité réseau à chaque sous-réseau si possible. Vous devez utiliser les règles les plus strictes qui activent les fonctionnalités complètes de la solution.
• Utilisation de groupes de sécurité d’application. Les groupes de sécurité d'application vous permettent de regrouper des groupes de sécurité réseau, ce qui facilite la création de règles pour les environnements complexes.

Filtrage de contenu et monitoring des abus

Le service Azure OpenAI inclut un système de filtrage de contenu qui utilise un ensemble de modèles de classification pour détecter et empêcher des catégories spécifiques de contenu potentiellement dangereux dans les invites d’entrée et les saisies semi-automatiques de sortie. Les catégories de contenu potentiellement dangereux incluent le contenu à caractère haineux, sexuel, violent (envers soi-même ou autrui), vulgaire, ainsi que le jailbreak (contenu conçu pour contourner les contraintes d’un LLM). 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é. À vous d'ajuster les paramètres en fonction de vos besoins.

Outre le filtrage de contenu, le service Azure OpenAI inclut des fonctionnalités de monitoring des abus. Le monitoring des abus est une opération asynchrone conçue pour détecter et atténuer les instances de contenu récurrent et/ou de comportements qui suggèrent l’utilisation du service d’une manière susceptible d’enfreindre le code de conduite Azure OpenAI. Vous pouvez demander une exemption de monitoring des abus et d'évaluation humaine, par exemple si vos données sont très sensibles ou si des stratégies internes ou des réglementations juridiques applicables empêchent le traitement des données en vue de 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 un temps d’arrêt, les autres zones 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é. Consultez la base de référence pour des conseils plus détaillés.

Cette section traite de la fiabilité du point de vue des composants de cette architecture qui ne sont pas abordés dans la base de référence App Service, notamment Azure Machine Learning, Azure OpenAI et Azure AI Search.

Redondance zonale pour les déploiements de flux

Les déploiements d’entreprise nécessitent généralement au moins une redondance zonale. Pour ce faire dans Azure, les ressources doivent prendre en charge des zones de disponibilité et vous devez déployer au moins les instances de la ressource ou permettre la prise en charge de la plateforme lorsque le contrôle d’instance n’est pas disponible. Actuellement, la capacité de calcul Azure Machine Learning ne permet pas la prise en charge des zones de disponibilité. Pour atténuer l’impact potentiel d’une catastrophe au niveau du centre de données sur les composants AML, il est nécessaire d’établir des clusters dans différentes régions, ainsi que de déployer un équilibreur de charge afin de distribuer les appels entre ces clusters. L'utilisation de contrôles d’intégrité permet de s'assurer que les appels sont routés uniquement vers des clusters qui fonctionnent correctement.

Le déploiement de flux d'invites n’est pas limité aux clusters de calcul Azure Machine Learning. Le flux exécutable, en tant qu’application conteneurisée, peut être déployé sur n’importe quel service Azure compatible avec les conteneurs. Ces options incluent des services tels qu’Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps (ACA) et Azure App Service. Chacun de ces services prend en charge les zones de disponibilité. Pour obtenir une redondance zonale pour l’exécution des flux d’invites, sans la complexité supplémentaire d’un déploiement multirégion, vous devez déployer vos flux sur l’un de ces services.

Voici une autre architecture dans laquelle les flux d’invites sont déployés sur Azure 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.

Figure 4 : Autre architecture de conversation de bout en bout dans laquelle OpenAI déploie des flux d’invites vers Azure App Services

Sur ce diagramme, les zones remarquables de l'architecture sont numérotées :

1. Les flux sont toujours créés dans le flux d’invite Azure Machine Learning et l’architecture réseau d’Azure Machine Learning n’est pas modifiée. Les auteurs de flux se connectent toujours à l’expérience de création de l’espace de travail via un point de terminaison privé et les points de terminaison privés managés sont utilisés pour se connecter aux services Azure lors du test des flux.
2. Cette ligne en pointillés indique que les flux exécutables conteneurisés sont envoyés à Azure Container Registry (ACR). Les pipelines qui conteneurisent les flux et les envoient à ACR ne sont pas illustrés.
3. Il existe une autre application web déployée sur le même plan App Service qui héberge déjà l’interface utilisateur de conversation. La nouvelle application web héberge le flux d’invite conteneurisé, colocalisé sur le même plan App Service qui s’exécute déjà à un minimum de trois instances, répartis entre les zones de disponibilité. Ces instances App Service se connectent à ACR sur un point de terminaison privé lors du chargement de l’image conteneur de 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 qui serait pour Azure AI Search et Azure OpenAI Service. Les services PaaS qui ont été exposés uniquement au sous-réseau de point de terminaison privé managé AML doivent désormais être exposés dans le réseau virtuel afin que la ligne de vue puisse être établie à partir d’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. L'utilisation de contrôles d’intégrité permet de s'assurer que les appels sont routés uniquement vers des clusters qui fonctionnent correctement.

Pour prendre en charge plusieurs instances efficacement, nous vous recommandons d’externaliser des fichiers de réglage précis, tels qu’un compte de Stockage Azure géoredondant. Cela réduit l’état stocké dans Azure OpenAI service par région. Le réglage précis doit toujours être effectué par instance pour héberger le déploiement de modèles.

Il est important de surveiller le débit requis en termes de jetons par minute (TPM) et de requêtes par minute (RPM) afin de vous assurer que vous avez affecté suffisamment de TPM de votre quota pour répondre à la demande de vos déploiements et d'éviter que les appels vers vos modèles déployés ne soient limités. Une passerelle telle qu’Azure API Management (APIM) peut être déployée devant votre ou vos services OpenAI et peut être configurée pour refaire des tentatives en cas d’erreurs temporaires et de limitation. APIM peut également être utilisé comme disjoncteur pour empêcher le service d’être submergé d'appels, et donc de dépasser le quota.

Azure AI Search - fiabilité

Déployez Azure AI Search avec au minimum le niveau tarifaire Standard 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 :

• Suivez les instructions pour surveiller Azure AI Search.
• Utilisez la surveillance des métriques et des journaux ainsi que l’analyse des performances pour déterminer le nombre approprié de réplicas afin d’éviter la limitation basée sur les requêtes et le nombre de partitions afin d'éviter la limitation basée sur l’index.

Azure Machine Learning - fiabilité

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

• Suivez les instructions pour mettre à l’échelle automatiquement vos points de terminaison en ligne afin de vous assurer que suffisamment de capacité est disponible pour répondre à la demande. Si les signaux d’utilisation n'arrivent pas en temps suffisamment opportun à cause d'une utilisation sporadique, songez à effectuer un surapprovisionnement afin de ne pas nuire à la fiabilité en raison d'un nombre d’instances disponibles trop faible.
• 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é. Du point de vue du réseau, la seule chose qui doit être accessible à partir d’Internet est l’interface utilisateur de conversation via App 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.

La sécurité réseau a été abordée dans la section dédiée à la mise en réseau. Cette section traite de la gestion des identités et des accès ainsi que des considérations de sécurité relatives à la rotation des clés et au réglage précis 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 distinctes pour les ressources AML suivantes, le cas échéant :
  • Espace de travail : utilisé pendant la création et la gestion de flux
  • Instance de calcul : utilisée lors du test de flux
  • Point de terminaison en ligne : utilisé par le flux déployé s’il est déployé sur un point de terminaison en ligne géré
• Implémenter des contrôles d’accès d'identités pour l’interface utilisateur de conversation à l’aide de Microsoft Entra ID

Rôles RBAC dans Azure Machine Learning

Il existe cinq rôles par défaut que vous pouvez utiliser pour gérer l’accès à votre espace de travail Azure Machine Learning : Scientifique des données AzureML, Opérateur de calcul AzureML, Lecteur, Contributeur et Propriétaire. En plus de ces rôles par défaut, il existe le rôle de Lecteur de secrets de connexion de l’espace de travail AzureML et le rôle d'Utilisateur du registre AzureML qui accordent l’accès aux ressources de l’espace de travail, telles que les secrets et le registre de ce dernier.

Cette architecture suit le principe de privilège minimum en affectant uniquement des rôles aux identités ci-dessus là où ils sont requis. Les attributions de rôles sont les suivantes.

Rotation des clés

Il existe deux services dans cette architecture qui utilisent l’authentification basée sur des clés : Azure OpenAI et le point de terminaison en ligne géré Azure Machine Learning. Étant donné que vous utilisez l’authentification basée sur des clés pour ces services, il est important de :

• Stocker la clé dans un magasin sécurisé tel qu’Azure Key Vault pour l’accès à la demande à partir de clients autorisés (par exemple, l’application web Azure hébergeant le conteneur de flux d’invite).
• Implémenter une stratégie de rotation de clé. Si vous optez pour la rotation de clé manuelle, vous devez créer une stratégie d’expiration de clé et utiliser la Azure Policy pour surveiller si la rotation de clé a été effectuée.

Réglage précis des modèles OpenAI

Si vous optez pour le réglage précis des modèles OpenAI dans votre implémentation, tenez compte des conseils suivants :

• Si vous chargez des données d’apprentissage pour un réglage précis, envisagez d’utiliser des clés gérées par le client pour chiffrer ces données.
• Si vous stockez des données d’apprentissage dans un magasin tel que Azure Blob Storage, envisagez d’utiliser une clé gérée par le client pour le chiffrement des données, utilisez une identité managée pour contrôler l’accès aux données et un point de terminaison privé pour vous connecter aux données.

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 plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

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

Azure Search - efficacité des performances

Suivez les instructions pour analyser les performances dans Azure AI Search.

Azure OpenAI - efficacité des performances

• Déterminez si votre application nécessite un débit provisionné ou si elle utilisera le modèle d’hébergement (consommation) partagé. Le débit provisionné offre une capacité de traitement réservée pour vos déploiements de modèles OpenAI, offrant 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 (consommation) partagé, qui est basé sur le principe du « meilleur effort » et peut avoir à supporter un voisin bruyant ou autres sources de stress sur la plateforme.
• Pour le débit provisionné, vous devez surveiller l’utilisation gérée par le provisionnement

Azure Machine Learning - efficacité des performances

En cas de déploiement sur des points de terminaison en ligne Azure Machine Learning :

• Suivez les instructions relatives à la procédure de mise à l’échelle automatique d'un point de terminaison en ligne pour rester étroitement aligné sur la demande, sans surapprovisionnement excessif, en particulier en 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. Vous souhaitez tester les performances avec un nombre d’instances inférieur et des références SKU plus volumineuses par rapport à un nombre d'instances plus important et des références SKU plus petites afin de trouver une configuration optimale.

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 Vue d’ensemble du pilier d’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 en fonction de votre propre utilisation, car cet exemple illustre seulement les composants inclus dans l’architecture. Les composants les plus coûteux dans le scénario sont la capacité de calcul du flux d'invite & de l’interface utilisateur de conversation et Azure AI Search. Vous devez donc chercher à optimiser autour de ces ressources pour réduire les coûts au maximum.

Compute

Le flux d’invite Azure Machine Learning prend en charge plusieurs options pour héberger les flux exécutables. Les options incluent des points de terminaison en ligne managés dans Azure Machine Learning, Azure Kubernetes Service, Azure App Service et Azure Container Service. Chacune de ces options a son propre modèle de facturation. Le choix de la capacité de calcul a un impact sur 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, dans le service Azure OpenAI spécifiquement, vous devez utiliser une combinaison d’approches :

• Contrôler les clients. Les requêtes clients sont la principale source de coût dans un modèle de consommation, et en tant que telle, le contrôle du comportement des clients est essentielle. 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 ; limiter l’accès via des contrôles réseau et d’identité (clé ou 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, veillez à optimiser la limite de la longueur de la réponse.
• L’utilisation du terrain de jeu Azure OpenAI doit être effectuée en fonction des besoins et sur les instances de préproduction, de sorte que ces activités n’entraînent pas de coûts de production.
• Sélectionnez le modèle IA approprié. 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. L’utilisation du modèle adapté à l'utilisation permet de ne pas dépenser trop d'argent sur un modèle plus coûteux alors qu’un modèle moins coûteux génère 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.
• Comprendre les points de rupture de facturation : le réglage précis est facturé à l'heure. Pour être le plus efficace, vous voudrez optimiser chaque heure pour améliorer les résultats de réglage précis tout en évitant de passer à la période de facturation suivante. De la même manière, le coût de 100 images issues de la génération d’images sera le même que pour 1 image. Optimisez les points de rupture de prix à votre avantage.
• Comprendre les modèles de facturation : Azure OpenAI est également disponible dans un modèle de facturation basé sur l’engagement via l’offre de débit provisionné. Une fois que vous avez des modèles d’utilisation prévisibles, songez à passer à ce modèle de facturation préachat si, d'après les calculs, il s'avère être plus rentable avec votre volume d’utilisation.
• Définir des limites de provisionnement : assurez-vous que tous les quotas de provisionnement sont alloués uniquement aux modèles qui sont censés faire partie de la charge de travail, selon une base par modèle. Le débit pour les modèles déjà déployés n’est pas limité à ce quota provisionné alors que le quota dynamique est activé. Notez que le quota ne correspond pas directement aux coûts et que le coût peut varier.
• Surveiller l’utilisation du paiement à l’utilisation : si vous utilisez le paiement à l’utilisation, surveillez l’utilisation des jetons par minute (TPM) et des requêtes par minute (RPM). Utilisez ces informations dans la prise de décisions de conception architecturale, telles que les modèles à utiliser, ainsi que pour optimiser les tailles d’invite.
• Surveiller l’utilisation du débit provisionné : si vous utilisez le débit provisionné, surveillez l’utilisation gérée par le provisionnement pour vous assurer que vous ne sous-utilisez pas le débit provisionné que vous avez acheté.
• Gestion des coûts : suivez les instructions sur 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 informer les parties prenantes des risques ou des anomalies.

Opérations de modèles de langage volumineux (LLMOps)

Le déploiement de solutions de conversation basées sur Azure OpenAI similaires à cette architecture doit suivre les instructions fournies dans LLMOps avec flux d’invite avec Azure DevOps et GitHub. En outre, il doit prendre en compte les meilleures pratiques concernant les architectures CI/CD et 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

Le flux d’invite Azure Machine Learning offre à la fois une expérience de création basée sur un navigateur dans Azure Machine Learning Studio ou via une extension VS Code. Les deux options stockent le code du flux sous forme de fichiers. Lorsque vous utilisez Azure Machine Learning Studio, les fichiers sont stockés dans un compte de stockage Azure. Lorsque vous travaillez dans VS Code, les fichiers sont stockés sur 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 d’entreprise, vous devez utiliser l’extension VS Code et le SDK/l'interface CLI du 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

Vous devez tester les flux utilisés dans une application de conversation, comme tout autre artefact logiciel. Il est difficile de spécifier et d’affirmer une seule réponse « correcte » pour les sorties LLM, mais vous pouvez utiliser un LLM pour évaluer les réponses. Envisagez d’implémenter les évaluations automatisées de vos flux LLM suivantes :

• Précision de la classification : évalue si le LLM obtient un score « correct » ou « incorrect » et agrège les résultats pour générer 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.
• Prise en compte du contexte : évalue la façon dont les réponses prédites du modèle sont basées sur un contexte préconfiguré. Même si les réponses du LLM sont correctes, si elles ne peuvent pas être validées par rapport au contexte donné, ces réponses ne sont pas prises en compte.
• 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 LLM pour générer des données dans votre golden dataset.

Flux de déploiement

Figure 5 : Déploiement du flux d’invite

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 d'invite/le scientifique de données effectue une itération sur le flux à l’aide du flux d’invite pour VS Code, en commitant régulièrement les modifications et en transmettant 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 des évaluations
   • Inscrit les flux dans Azure Machine Learning Registry 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 entre Azure Machine Learning Registry et un point de terminaison en ligne Azure 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 dans un environnement actif, les tâches opérationnelles de surveillance des métriques de performances et l’évaluation du LLM déployé 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

Instructions de déploiement

Les points de terminaison azure Machine Learning vous permettent de déployer des modèles de manière à obtenir une certaine flexibilité lors de la mise 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.
• Test A/B : non seulement les déploiements bleu/vert sont efficaces pour le déploiement sécurisé des modifications, mais ils peuvent également être utilisés pour déployer un nouveau comportement qui permet à un sous-ensemble d’utilisateurs d’évaluer l’impact de la modification.
• 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.
• Lors du déploiement de votre flux sur l’espace de travail Azure Machine Learning isolé du réseau, utilisez un agent auto-hébergé pour déployer des artefacts sur vos ressources Azure.
• Le registre de modèles Azure Machine Learning ne doit être mis à jour qu’en cas de modifications apportées au modèle.
• Le LLM, les flux et l’interface utilisateur du 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.
• Lors du développement et du déploiement de 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

Lors du déploiement des composants de conversation de bout en bout Azure OpenAI de référence, certains des services provisionné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 Azure Machine Learning
• Compte de stockage Azure pour l’espace de travail Azure Machine Learning
• Azure Container Registry
• Azure AI Search
• 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, ce qui permet à ces ressources d’être liées au cycle de vie du composant et de devenir éphémères dans cette architecture. Elles sont affectées lorsque la charge de travail évolue, par exemple quand des flux sont ajoutés ou supprimés ou quand 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 de modèles Azure Machine Learning doit être mis à jour, s’il est modifié, comme faisant partie du pipeline de déploiement continu.
• 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 Azure Machine Learning est créé lorsqu’un flux d’invite est déployé si le déploiement fait 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 du point de terminaison Azure 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éé.

Surveillance

Les diagnostics sont configurés pour tous les services. Tous les services, sauf Azure Machine Learning et Azure App Service, sont configurés pour capturer tous les journaux. Les diagnostics Azure Machine Learning sont configurés pour capturer les journaux d’audit qui sont tous les journaux de ressources qui enregistrent les interactions client avec les données ou les paramètres du service. Azure App Service est configuré pour capturer les journaux AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs et AppServicePlatformLogs.

Déployer ce scénario

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

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.

Étapes suivantes

En savoir plus sur Azure OpenAI

Ressources associées

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