Partager via

Architecture de référence de référence de conversation Azure AI Foundry

Azure OpenAI Service
Azure AI services
Azure App Service
Azure Monitor

Les applications de conversation d’entreprise peuvent permettre aux employés d’utiliser des interactions conversationnelles avec des agents IA. Cette fonctionnalité est de plus en plus puissante grâce à des progrès continus dans les modèles de langage, tels que les modèles GPT d’OpenAI et les kits SDK d’orchestration comme le noyau sémantique. Ces applications de conversation se composent généralement des composants suivants :

  • Interface utilisateur de conversation intégrée à une application d’entreprise plus grande. Il fournit aux utilisateurs une expérience conversationnelle avec d’autres fonctions métier.

  • Référentiels de données qui contiennent des informations spécifiques au domaine pertinentes pour les requêtes utilisateur.

  • Modèles de langage qui raisonner sur les données spécifiques au domaine pour produire des réponses pertinentes.

  • Orchestrateur ou agent qui supervise les interactions entre les sources de données, les modèles de langage et l’utilisateur final.

Cet article fournit une architecture de base pour vous aider à créer et déployer des applications de conversation d’entreprise à l’aide d’Azure AI Foundry et d’Azure OpenAI dans les modèles Foundry. Cette architecture utilise un seul agent hébergé dans azure AI Foundry Agent Service. L’agent reçoit des messages utilisateur, puis interroge les magasins de données pour récupérer des informations de base pour le modèle de langage.

L’interface utilisateur de conversation suit les instructions d’application web Azure App Service de base sur le déploiement d’une application web sécurisée, redondante interzone et hautement disponible sur App Service. Dans cette architecture, App Service communique avec la solution PaaS (Platform as a Service) Azure via l’intégration de réseau virtuel sur des points de terminaison privés. Dans l’architecture de l’interface utilisateur de conversation, App Service communique avec l’agent sur un point de terminaison privé. L’accès public au portail Azure AI Foundry et aux agents est désactivé.

Important

Cet article ne décrit pas les composants ou les décisions d’architecture de l’architecture d’application web App Service de base. Lisez cet article pour obtenir des conseils architecturaux sur l’hébergement de l’application web qui contient votre interface utilisateur de conversation.

Cette architecture utilise la configuration de l’agent standard de l’agent Foundry Agent pour activer la sécurité, la conformité et le contrôle de niveau entreprise. Dans cette configuration, vous apportez votre propre réseau pour l’isolation réseau et vos propres ressources Azure pour stocker l’état de conversation et d’agent. Toutes les communications entre les composants d’application et les services Azure se produisent sur des points de terminaison privés, ce qui garantit que le trafic de données reste dans le réseau virtuel de votre charge de travail. Le trafic sortant des agents achemine strictement via le Pare-feu Azure, qui applique des règles de sortie.

Conseil / Astuce

L’implémentation de référence du service De l’agent Foundry présente une implémentation de conversation de bout en bout de référence sur Azure. Il sert de base pour développer des solutions personnalisées à mesure que vous passez à la production.

Architecture

Diagramme montrant une architecture de conversation standard de bout en bout qui utilise Azure AI Foundry.

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

Flux de travail

  1. Un utilisateur d’application interagit avec une interface utilisateur de conversation. Les requêtes sont routées via Azure Application Gateway. Le pare-feu d’applications web Azure inspecte ces demandes avant de les transférer au service App Service principal.

  2. Lorsque l’application web reçoit une requête ou une instruction utilisateur, elle appelle l’agent conçu à des fins. L’application web communique avec l’agent via le Kit de développement logiciel (SDK) Azure AI Agent. L’application web appelle l’agent sur un point de terminaison privé et s’authentifie auprès d’Azure AI Foundry à l’aide de son identité managée.

  3. L’agent traite la demande de l’utilisateur en fonction des instructions de son invite système. Pour répondre à l’intention de l’utilisateur, l’agent utilise un modèle de langage configuré et des outils connectés et des magasins de connaissances.

  4. L’agent se connecte à la base de connaissances (Recherche Azure AI) dans le réseau privé via un point de terminaison privé.

  5. Demandes adressées à des magasins de connaissances externes ou à des outils tels que Wikipédia ou Bing, parcourez le Pare-feu Azure pour l’inspection et l’application de la stratégie de sortie.

  6. L’agent se connecte à son modèle de langage configuré et transmet le contexte approprié.

  7. Avant que l’agent retourne la réponse à l’interface utilisateur, il conserve la requête, la réponse générée et une liste de magasins de connaissances consultés dans une base de données mémoire dédiée. Cette base de données conserve l’historique complet des conversations, qui permet des interactions contextuelles et permet aux utilisateurs de reprendre des conversations avec l’agent sans perdre le contexte antérieur.

    Les API Azure AI Foundry prennent en charge le développement d’expériences utilisateur qui gèrent plusieurs conversations simultanées et isolées dans le contexte.

Composants

Cette architecture s’appuie sur l’architecture de référence de la conversation Azure AI Foundry de base. Cette architecture introduit davantage de services Azure pour répondre aux exigences de l’entreprise en matière de fiabilité, de sécurité et de contrôle opérationnel. Chacun des composants suivants joue un rôle spécifique dans une solution de conversation d’entreprise de production :

  • Le service De l’agent Foundry fournit la couche d’orchestration pour les interactions de conversation. Il héberge et gère les agents qui effectuent les tâches suivantes :

    • Traiter les demandes des utilisateurs
    • Coordonner les appels à des outils et à d’autres agents
    • Appliquer la sécurité du contenu
    • Intégrer à l’identité d’entreprise, à la mise en réseau et à l’observabilité

    La configuration de l’agent standard garantit l’isolation du réseau et assure un contrôle sur le stockage des données. Vous fournissez des ressources Azure dédiées pour l’état de l’agent, l’historique des conversations et le stockage de fichiers, que le service De l’agent Foundry gère exclusivement. Les autres composants d’application de la charge de travail ne doivent pas utiliser ces ressources requises.

    • Azure Cosmos DB pour NoSQL héberge la base de données mémoire de cette charge de travail, appelée enterprise_memory, dans votre abonnement. Cette base de données stocke l’état opérationnel de l’agent, y compris les threads de conversation et les définitions d’agent. Cette conception garantit que l’historique des conversations et la configuration de l’agent sont isolés, auditables et gérés en fonction des exigences de gouvernance des données. Le service De l’agent Foundry gère la base de données, ses collections et ses données.

    • Un compte de stockage Azure dédié stocke les fichiers chargés pendant les sessions de conversation. L’hébergement de ce compte dans votre abonnement fournit un contrôle d’accès granulaire, des fonctionnalités d’audit et une conformité avec les stratégies de résidence ou de rétention des données. Le service De l’agent Foundry gère les conteneurs et le cycle de vie des données au sein de ces conteneurs.

    • Une instance de recherche IA dédiée stocke un index de recherche et segmenté des fichiers chargés à partir de conversations avec l’agent. Il stocke également les fichiers statiques ajoutés en tant que sources de connaissances lors de la création de l’agent. Le service De l’agent Foundry gère l’index, le schéma et les données, et utilise sa propre stratégie de segmentation et sa logique de requête.

  • Application Gateway sert de point d’entrée sécurisé et évolutif pour tout le trafic HTTP et HTTPS vers l’interface utilisateur de conversation. Il fournit l’arrêt TLS (Transport Layer Security) et le routage basé sur le chemin. Il distribue également les requêtes entre les zones de disponibilité, qui prennent en charge la haute disponibilité et les performances pour la couche Application web. Son serveur principal est App Service qui héberge le code de l’application.

    • Le pare-feu d’applications web Azure s’intègre à Application Gateway pour protéger l’interface utilisateur de conversation contre les vulnérabilités et attaques web courantes. Il inspecte et filtre les requêtes HTTP, qui fournissent une couche de sécurité pour les applications publiques.

    • Azure Key Vault stocke et gère en toute sécurité les certificats TLS requis par Application Gateway. La gestion centralisée des certificats dans Key Vault prend en charge la rotation automatisée, l’audit et la conformité aux normes de sécurité organisationnelles. Cette architecture ne nécessite pas de clés stockées ou d’autres secrets.

  • Le réseau virtuel Azure fournit une isolation réseau pour tous les composants. Lorsque vous placez des ressources dans un réseau virtuel privé, vous contrôlez le trafic est-ouest et nord-sud, appliquez la segmentation, maintenez le trafic privé et activez l’inspection des flux d’entrée et de sortie. Cette configuration vous aide à répondre aux exigences de sécurité et de conformité.

  • Azure Private Link connecte tous les services PaaS, tels qu’Azure Cosmos DB, Stockage, Recherche IA et Service De l’agent Foundry, au réseau virtuel via des points de terminaison privés. Cette approche garantit que tout le trafic de données reste sur le réseau principal Azure, ce qui élimine l’exposition à l’Internet public et réduit la surface d’attaque.

  • Le Pare-feu Azure inspecte et contrôle tout le trafic sortant (sortant) à partir du réseau virtuel. Elle applique des règles basées sur le nom de domaine complet (FQDN), ce qui garantit que seules les destinations approuvées sont accessibles. Cette configuration permet d’empêcher l’exfiltration des données et de répondre aux exigences de sécurité réseau.

  • Azure DNS fournit des zones DNS (Domain Name System) privées liées au réseau virtuel. Cette fonctionnalité permet la résolution de noms pour les points de terminaison privés, ce qui garantit que toutes les communications de service à service utilisent des adresses IP privées et restent dans la limite du réseau.

  • Le stockage héberge le code de l’application web en tant que fichier ZIP pour le déploiement vers App Service. Cette méthode prend en charge les flux de travail de déploiement sécurisés et automatisés et sépare les artefacts d’application des ressources de calcul.

Alternatives

Cette architecture inclut plusieurs composants que vous pouvez remplacer par d’autres services ou approches Azure, en fonction des exigences fonctionnelles et non fonctionnelles de votre charge de travail. Tenez compte des alternatives et compromis suivants.

Orchestration de conversation

Approche actuelle : Cette architecture utilise le service Foundry Agent pour orchestrer les flux de conversation, notamment extraire des données de base à partir de magasins de connaissances et appeler des modèles Azure OpenAI. Le service De l’agent Foundry fournit une orchestration sans code et non déterministe. Il gère les demandes de conversation, la gestion des threads, l’appel d’outils, la sécurité du contenu et l’intégration avec l’identité, la mise en réseau et l’observabilité. Il fournit une solution de base de données mémoire native.

Autre approche : Vous pouvez héberger automatiquement la couche d’orchestration à l’aide d’infrastructures telles que le noyau sémantique ou LangChain. Utilisez ces frameworks pour implémenter des flux de conversation déterministes, pilotés par le code et une logique d’orchestration personnalisée.

Considérez cette alternative si votre charge de travail nécessite les fonctionnalités suivantes :

  • Contrôle précis et déterministe sur la séquence d’orchestration, l’appel d’outils ou l’ingénierie rapide

  • Intégration avec une logique métier personnalisée ou des systèmes externes que Foundry Agent Service ne prend pas en charge en mode natif

  • Routage avancé des demandes clientes pour les pratiques d’expérimentation ou de déploiement sécurisé

  • Solution de base de données de mémoire personnalisée qui diffère de la solution de service de l’agent Foundry natif

L’orchestration auto-hébergée augmente la complexité opérationnelle et vous oblige à gérer le calcul, la mise à l’échelle et la sécurité.

Composants de la couche Application

Approche actuelle : Le site web frontal de l’interface utilisateur de conversation est hébergé sur la fonctionnalité Web Apps d’App Service, qui fournit une plateforme managée et évolutive pour les applications web. Web Apps s’intègre en mode natif avec les fonctionnalités de mise en réseau et de sécurité Azure.

Autre approche : Vous pouvez utiliser d’autres plateformes de calcul gérées par Azure, telles qu’Azure Container Apps ou Azure Kubernetes Service (AKS), pour héberger la couche Application.

Considérez cette alternative si votre charge de travail répond à l’une des conditions suivantes :

  • Une autre plateforme de calcul prend mieux en charge certains cas d’usage et les services de colocalisation sur cette plateforme peuvent améliorer l’efficacité des coûts et simplifier les opérations

  • Votre application nécessite une mise à l’échelle, une orchestration ou une mise en réseau personnalisée plus sophistiquée

App Service reste l’option préférée pour sa simplicité dans l’hébergement d’applications web et de leurs API.

Magasin de données de base (connaissances)

Approche actuelle : Cette architecture utilise la recherche IA comme magasin de données principal pour la mise au point des connaissances. Il utilise les fonctionnalités de recherche vectorielle de recherche ia et de classement sémantique.

Autre approche : Vous pouvez utiliser d’autres plateformes de données pour baser les connaissances, telles qu’Azure Cosmos DB, Azure SQL Database ou d’autres magasins de données OLTP (Online Transaction Processing). Votre plateforme de données dépend de votre patrimoine de données existant, des exigences de fraîcheur des données et des exigences de requête.

Considérez cette alternative si votre charge de travail répond à l’une des conditions suivantes :

  • Vous gérez déjà vos connaissances de base dans une base de données transactionnelle ou opérationnelle existante

  • Vous avez besoin d’une prise en charge multimodèle ou sdk non disponible dans la recherche IA

  • Vous devez intégrer des sources de données spécialisées ou des systèmes hérités

La recherche vectorielle est courante pour la génération augmentée par récupération, mais pas toujours nécessaire. Pour plus d’informations, consultez Choisir un service Azure pour la recherche vectorielle. Avant de choisir un magasin de données, évaluez les modèles d’accès aux données, la latence et les besoins en scalabilité de votre charge de travail.

Agent prédéfini ou agent créé dynamiquement

Approche actuelle : L’implémentation de référence utilise un agent défini de manière statique qui est déployé en tant que microservice dans Azure AI Foundry. La logique et les sources de données de l’agent sont configurées au moment du déploiement et restent inchangées jusqu’à la prochaine version de l’application. Cette approche fonctionne bien lorsque le comportement de l’agent et les sources de données sont stables et contrôlés par le biais de processus DevOps.

Autre approche : Vous pouvez créer ou modifier dynamiquement des agents au moment de l’exécution à l’aide du Kit de développement logiciel (SDK) Azure AI Agent. Cette approche permet à l’application d’instancier des agents à la demande, d’ajuster les invites système ou de reconfigurer les connexions en fonction du contexte utilisateur ou de la logique métier.

Tenez compte des agents dynamiques si votre charge de travail nécessite les fonctionnalités suivantes :

  • Comportement d’agent personnalisé ou sources de données pour chaque utilisateur ou session

  • Modifications fréquentes ou programmatiques apportées à la configuration de l’agent

  • Prise en charge éphémère de l’agent spécifique au contexte pour les expériences utilisateur avancées

La gestion dynamique des agents augmente la flexibilité, mais introduit également le fardeau de la gestion du cycle de vie. Vérifiez que vous disposez des contrôles appropriés pour la création, la modification et le nettoyage de l’agent.

Choisissez l’approche de l’agent qui s’aligne sur les exigences de l’expérience utilisateur de votre charge de travail.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Appliquez cette architecture et les charges de travail IA aux conseils de conception Azure pendant la phase de conception de votre charge de travail.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

L’architecture d’application web App Service de base se concentre sur la redondance zonale pour les services régionaux clés. Les zones de disponibilité sont des emplacements physiquement distincts au sein d’une région qui fournissent une redondance lorsque vous déployez deux instances ou plus. Si une zone subit un temps d’arrêt, d’autres personnes de la région risquent de ne pas être affectées. L’architecture distribue également les instances et les configurations des services Azure entre les zones de disponibilité. Pour plus d’informations, consultez application web redondante interzone hautement disponible.

Cette section traite de la fiabilité des composants non couverts dans l’architecture de base d’App Service, en particulier Azure AI Foundry et RECHERCHE IA.

Redondance de zone dans votre couche d’orchestration

Les déploiements d’entreprise nécessitent généralement une redondance zonale pour réduire le risque d’interruption de service à partir des défaillances au niveau de la zone. Dans Azure, la redondance zonale signifie l’utilisation de ressources qui prennent en charge les zones de disponibilité et le déploiement d’au moins trois instances, ou l’activation de la redondance au niveau de la plateforme où le contrôle d’instance direct n’est pas disponible.

Dans cette architecture, Azure AI Foundry héberge la fonctionnalité Service De l’agent Foundry. La fiabilité de l’agent dépend de la disponibilité des dépendances du service De l’agent Foundry, qui sont Azure Cosmos DB, Stockage et Recherche IA. Le service De l’agent Foundry gère les données de ces services, mais vous configurez leur fiabilité dans votre abonnement.

Pour obtenir une redondance zonale pour la couche d’orchestration, suivez les recommandations suivantes :

Si votre agent s’intègre à d’autres dépendances spécifiques à la charge de travail, telles que les connexions d’outils personnalisées ou les magasins de connaissances externes, assurez-vous que ces dépendances répondent à vos exigences de disponibilité et de redondance. Toute dépendance à zone unique ou non redondante peut compromettre la fiabilité globale de la couche d’orchestration.

Le portail AI Foundry, ses API de plan de données et la fonctionnalité service De l’agent Foundry ne fournissent pas de contrôles directs pour la redondance de zone.

Fiabilité dans l’hébergement du modèle Azure AI Foundry

Azure AI Foundry fournit des modèles en tant que service (MaaS) hébergeant plusieurs options de déploiement. Ces options prennent principalement en charge la gestion des quotas et du débit, plutôt que la haute disponibilité traditionnelle au sein d’une région. Les déploiements de modèles standard fonctionnent dans une seule région et ne prennent pas en charge les zones de disponibilité. Pour obtenir une disponibilité multi-centres de données, vous devez utiliser un déploiement global ou de zone de données.

Pour les scénarios de conversation d’entreprise, déployez à la fois un modèle standard de zone de données approvisionné et de zone de données . Configurez le basculement pour gérer l’excès de trafic ou les défaillances. Si votre charge de travail ne nécessite pas de faible latence ou une résidence et un traitement stricts des données géographiques, utilisez des déploiements globaux pour une résilience maximale.

Azure AI Foundry ne prend pas en charge les mécanismes avancés d’équilibrage de charge ou de basculement, tels que le routage de tourniquet ou le rupture de circuit, pour les déploiements de modèles. Si vous avez besoin d’une redondance granulaire et d’un contrôle de basculement au sein d’une région, hébergez votre logique d’accès au modèle en dehors du service managé. Par exemple, vous pouvez créer une passerelle personnalisée à l’aide de Gestion des API Azure. Cette approche vous permet d’implémenter des stratégies de routage, de contrôle d’intégrité et de basculement personnalisées. Mais il augmente également la complexité opérationnelle et déplace la responsabilité de la fiabilité de ce composant à votre équipe.

Vous pouvez également exposer des modèles frontés par passerelle en tant qu’outils personnalisés basés sur l’API ou magasins de connaissances pour votre agent. Pour plus d’informations, consultez Utiliser une passerelle devant plusieurs déploiements ou instances Azure OpenAI.

Fiabilité dans la recherche d’ia pour les connaissances d’entreprise

Déployez la recherche IA à l’aide du niveau tarifaire Standard ou supérieur dans une région qui prend en charge les zones de disponibilité. Configurez au moins trois réplicas pour vous assurer que le service distribue des instances entre des zones de disponibilité distinctes. Cette configuration offre une résilience aux défaillances au niveau de la zone et prend en charge la haute disponibilité pour les opérations de recherche.

Pour déterminer le nombre optimal de réplicas et de partitions pour votre charge de travail, utilisez les méthodes suivantes :

  • Surveillez la recherche IA à l’aide de métriques et de journaux intégrés. Suivez la latence des requêtes, la limitation et l’utilisation des ressources.

  • Utilisez les métriques de surveillance et les journaux et l’analyse des performances pour déterminer le nombre approprié de réplicas. Cette approche vous permet d’éviter la limitation du volume de requêtes élevé, des partitions insuffisantes ou des limitations d’index.

  • Assurez-vous de la fiabilité de l’indexation en évitant les interruptions de l’indexation périodique ou des erreurs d’indexation. Envisagez l’indexation dans un index hors connexion et échangez de votre index actif vers votre index reconstruit après avoir validé l’intégrité des données.

Fiabilité dans le Pare-feu Azure

Le Pare-feu Azure est un point de contrôle de sortie critique dans cette architecture, mais représente un point de défaillance unique pour tout le trafic sortant. Pour atténuer ce risque, déployez le Pare-feu Azure sur toutes les zones de disponibilité de votre région. Cette configuration permet de maintenir la connectivité sortante si une zone devient indisponible.

Si votre charge de travail nécessite un volume élevé de connexions sortantes simultanées, configurez le Pare-feu Azure avec plusieurs adresses IP publiques. Cette approche distribue les connexions SNAT (Source Network Address Translation) sur plusieurs préfixes d’adresses IP, ce qui réduit le risque d’épuisement des ports SNAT. L’épuisement SNAT peut entraîner une perte totale ou intermittente de la connectivité sortante pour les agents et d’autres composants de charge de travail, ce qui peut entraîner un temps d’arrêt des fonctionnalités ou une dégradation des performances.

Surveillez l’utilisation du port SNAT et l’intégrité du pare-feu. Si vous observez des échecs de connexion ou des problèmes de débit, passez en revue les métriques et journaux de pare-feu pour identifier et résoudre l’épuisement SNAT ou d’autres goulots d’étranglement.

Isoler les dépendances du service De l’agent Foundry à partir de composants de charge de travail similaires

Pour optimiser la fiabilité et réduire le rayon d’explosion des défaillances, isolez strictement les dépendances du service De l’agent Foundry d’autres composants de charge de travail qui utilisent les mêmes services Azure. Plus précisément, ne partagez pas la recherche IA, Azure Cosmos DB ou les ressources de stockage entre le service d’agent et d’autres composants d’application. Au lieu de cela, approvisionnez des instances dédiées pour les dépendances requises du service d’agent.

Cette séparation offre deux avantages clés :

  • Il contient des défaillances ou une dégradation des performances sur un segment de charge de travail unique, ce qui empêche les impacts en cascade sur les fonctionnalités d’application non liées.

  • Il vous permet d’appliquer des processus opérationnels ciblés, tels que la sauvegarde, la restauration et le basculement. Ces processus sont ajustés aux exigences de disponibilité et de récupération spécifiques du flux de charge de travail qui utilise ces ressources.

Par exemple, si votre application d’interface utilisateur de conversation doit stocker l’état transactionnel dans Azure Cosmos DB, provisionnez un compte et une base de données Azure Cosmos DB distincts à cet effet, plutôt que de réutiliser le compte ou la base de données gérée par le service De l’agent Foundry. Même si le coût ou la simplicité opérationnelle motive le partage des ressources, le risque d’un événement de fiabilité affectant les fonctionnalités de charge de travail non liées l’emporte sur les économies potentielles dans la plupart des scénarios d’entreprise.

Important

Si vous colocalisez des données spécifiques à la charge de travail avec les dépendances de l’agent pour des raisons de coût ou d’exploitation, n’interagissez jamais directement avec les données gérées par le système, telles que les collections, les conteneurs ou les index, que le service Foundry Agent crée. Ces détails d’implémentation interne ne sont pas documentés et peuvent être modifiés sans préavis. L’accès direct peut interrompre le service de l’agent ou entraîner une perte de données. Utilisez toujours les API de plan de données du service Foundry Agent pour la manipulation des données et traitez les données sous-jacentes comme opaques et surveillées uniquement.

Conception multirégion

Cette architecture utilise des zones de disponibilité pour la haute disponibilité dans une seule région Azure. Il ne s’agit pas d’une solution multirégion. Il ne contient pas les éléments critiques suivants requis pour la résilience régionale et la récupération d’urgence (DR) :

  • Entrée globale et routage du trafic
  • Gestion DNS pour le basculement
  • Stratégies de réplication ou d’isolation des données entre les régions
  • Désignation active active, active-passive ou active-froid
  • Processus de basculement régional et de restauration automatique pour atteindre les objectifs de temps de récupération (RPO) et les objectifs de point de récupération (RPO)
  • Prise en compte de la disponibilité des régions pour les expériences des développeurs, notamment le portail Azure AI Foundry et les API de plan de données

Si votre charge de travail nécessite une continuité d’activité si une panne régionale se produit, vous devez concevoir et implémenter des composants et des processus opérationnels supplémentaires au-delà de cette architecture. Plus précisément, vous devez traiter l’équilibrage de charge et le basculement à chaque couche architecturale, notamment les domaines suivants :

  • Bases de données (magasins de connaissances)
  • Modèles d’hébergement et de point de terminaison d’inférence
  • Couche orchestration ou agent
  • Trafic d’interface utilisateur accessible par l’utilisateur et points d’entrée DNS

Vous devez également vous assurer que les contrôles d’observabilité, de surveillance et de sécurité du contenu restent opérationnels et cohérents entre les régions.

Cette architecture de base ne dispose pas de fonctionnalités multirégions. Par conséquent, les pannes régionales sont susceptibles de provoquer une perte de service au sein de votre charge de travail.

Récupération d’urgence

Les architectures de conversation contiennent des composants avec état. La planification de la récupération d’urgence est donc essentielle. Ces charges de travail nécessitent généralement un magasin de mémoire pour les sessions de conversation actives ou suspendues. Ils nécessitent également un stockage pour des données supplémentaires, telles que des documents ou des images, ajoutés aux threads de conversation. La couche d’orchestration de l’agent peut également conserver l’état spécifique aux flux de conversation. Dans cette architecture, Foundry Agent Service utilise Azure Cosmos DB, Storage et AI Search pour conserver l’état opérationnel et transactionnel. Le cycle de vie et le couplage de cet état entre les composants déterminent votre stratégie de récupération d’urgence et vos opérations de récupération d’urgence.

Pour le service De l’agent Foundry, vérifiez que vous pouvez récupérer toutes les dépendances à un point cohérent dans le temps. Cette approche permet de maintenir l’intégrité transactionnelle sur les trois dépendances externes.

Les recommandations suivantes traitent de la récupération d’urgence pour chaque service :

  • Azure Cosmos DB : Activez la sauvegarde continue pour la enterprise_memory base de données. Cette configuration fournit une restauration à un point dans le temps (PITR) avec un RPO de sept jours, qui inclut des définitions d’agent et des threads de conversation. Testez régulièrement votre processus de restauration pour confirmer qu’il répond à votre RTO et que les données restaurées restent disponibles pour le service de l’agent. Restaurez toujours sur le même compte et la même base de données.

  • Recherche d’IA : La recherche IA ne dispose pas de fonctionnalités de restauration intégrées et ne prend pas en charge la manipulation directe des index. Si une perte de données ou une altération se produit, vous devez contacter le support Microsoft pour obtenir de l’aide sur la restauration des index. Cette limitation peut affecter considérablement votre RTO. Si votre interface utilisateur de conversation ne prend pas en charge les chargements de fichiers et que vous n’avez pas d’agents qui utilisent des fichiers statiques en tant que connaissances, il se peut que vous n’ayez pas besoin d’un plan de récupération d’urgence pour la recherche IA.

    Conservez une source de vérité distincte et régulièrement mise à jour pour votre entreprise. Cette pratique garantit que vous pouvez reconstruire des index si nécessaire.

  • Stockage: Si vous disposez d’un compte de stockage géoredondant, utilisez le basculement géré par le client pour les conteneurs d’objets blob utilisés par le service Foundry Agent. Cette configuration vous permet de lancer le basculement lors d’une panne régionale. Si vous utilisez uniquement un stockage redondant interzone, contactez le support Microsoft pour restaurer des données. Ce processus peut étendre votre RTO. Comme avec la recherche IA, si votre interface utilisateur de conversation ne prend pas en charge les chargements de fichiers et que vous n’avez pas d’agents qui utilisent des fichiers statiques en tant que connaissances, vous n’avez peut-être pas besoin d’un plan de récupération d’urgence pour les conteneurs d’objets blob.

  • Cohérence transactionnelle : Si le magasin d’état de votre charge de travail fait référence à des identificateurs d’agent Azure AI, tels que des ID de thread ou des ID d’agent, coordonnez la récupération dans tous les magasins de données pertinents. La restauration d’un sous-ensemble de dépendances uniquement peut entraîner des données orphelines ou incohérentes. Concevez vos processus de récupération d’urgence pour maintenir l’intégrité référentielle entre votre charge de travail et l’état du service d’agent.

  • Définitions et configuration de l’agent : Définissez les agents en tant que code. Stocker les définitions d’agent, les connexions, les invites système et les paramètres dans le contrôle de code source. Cette pratique vous permet de redéployer des agents à partir d’une configuration correcte connue si vous perdez la couche d’orchestration. Évitez d’apporter des modifications non tracées à la configuration de l’agent via le portail AI Foundry ou les API de plan de données. Cette approche garantit que vos agents déployés restent reproductibles.

Avant de passer à la production, créez un runbook de récupération qui traite les défaillances dans l’état appartenant à l’application et l’état appartenant à l’agent.

Sécurité

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

Cette architecture étend la base de sécurité établie dans l’architecture de référence de la conversation Azure AI Foundry de base. La principale différence est l’ajout d’un périmètre de sécurité réseau en même temps que le périmètre d’identité de l’architecture de base. Du point de vue du réseau, Application Gateway est la seule ressource exposée à Internet. Elle rend l’application d’interface utilisateur de conversation disponible pour les utilisateurs. Du point de vue de l’identité, l’interface utilisateur de conversation doit authentifier et autoriser les requêtes. Utilisez des identités managées lorsque cela est possible pour authentifier des applications auprès des services Azure.

Cette section décrit les considérations relatives à la mise en réseau et à la sécurité pour la rotation des clés et le réglage précis du modèle Azure OpenAI.

Gestion de l’identité et de l’accès

Cette architecture utilise principalement les identités managées affectées par le système pour l’authentification de service à service. Vous pouvez également utiliser des identités managées affectées par l’utilisateur. Dans les deux cas, appliquez les principes suivants :

  • Isoler les identités par ressource et fonction. Provisionnez des identités managées distinctes pour les composants suivants :

    • Compte Azure AI Foundry
    • Chaque projet Azure AI Foundry
    • L’application web
    • Tout code d’orchestrateur ou d’intégration personnalisé

  • Attribuez une identité à une ressource Azure uniquement si cette ressource doit s’authentifier en tant que client auprès d’un autre service Azure.

  • Utilisez des types d’identité adaptés à usage. Si possible, utilisez des identités de charge de travail pour les applications et l’automatisation, et utilisez des identités d’agent pour les agents IA.

Accès des employés du portail Azure AI Foundry

Lorsque vous intégrez des employés à des projets Azure AI Foundry, attribuez les autorisations minimales requises pour leur rôle. Utilisez les groupes d’ID Microsoft Entra et le contrôle d’accès en fonction du rôle (RBAC) pour appliquer la séparation des tâches. Par exemple, distinguez les développeurs d’agents des scientifiques des données qui gèrent des tâches de réglage précis. Toutefois, tenez compte des limitations et des risques.

Le portail Azure AI Foundry exécute de nombreuses actions à l’aide de l’identité du service plutôt que de l’identité de l’employé. Par conséquent, les employés qui ont des rôles RBAC limités peuvent avoir une visibilité sur les données sensibles, telles que les threads de conversation, les définitions d’agent et la configuration. Cette conception du portail AI Foundry peut ignorer par inadvertance vos contraintes d’accès souhaitées et exposer plus d’informations que prévu.

Pour atténuer le risque d’accès non autorisé, limitez l’utilisation du portail dans les environnements de production aux employés qui ont un besoin opérationnel clair. Pour la plupart des employés, désactivez ou bloquez l’accès au portail Azure AI Foundry en production. Utilisez plutôt des pipelines de déploiement automatisé et une infrastructure en tant que code (IaC) pour gérer la configuration de l’agent et du projet.

Traitez la création de projets dans un compte Azure AI Foundry comme une action privilégiée. Les projets créés via le portail n’héritent pas automatiquement de vos contrôles de sécurité réseau établis, tels que les points de terminaison privés ou les groupes de sécurité réseau (NSG). Et de nouveaux agents dans ces projets contournent votre périmètre de sécurité prévu. Appliquez exclusivement la création de projet par le biais de vos processus IaC contrôlés et auditables.

Attributions et connexions de rôle de projet Azure AI Foundry

Pour utiliser le service De l’agent Foundry en mode Standard, le projet doit disposer d’autorisations administratives sur les dépendances du service De l’agent Foundry. Plus précisément, l’identité managée du projet doit avoir des attributions de rôles élevées sur le compte de stockage, la recherche IA et le compte Azure Cosmos DB. Ces autorisations fournissent un accès presque complet à ces ressources, notamment la possibilité de lire, d’écrire, de modifier ou de supprimer des données. Pour maintenir l’accès au moins privilégié, isolez vos ressources de charge de travail des dépendances du service De l’agent Foundry.

Tous les agents d’un projet AI Foundry unique partagent la même identité managée. Si votre charge de travail utilise plusieurs agents qui nécessitent l’accès à différents ensembles de ressources, le principe du privilège minimum vous oblige à créer un projet Azure AI Foundry distinct pour chaque modèle d’accès d’agent distinct. Cette séparation vous permet d’attribuer uniquement les autorisations minimales requises à l’identité managée de chaque projet, ce qui réduit le risque d’accès excessif ou inattendu.

Lorsque vous établissez des connexions à des ressources externes à partir d’Azure AI Foundry, utilisez l’authentification basée sur l’ID Microsoft Entra si disponible. Cette approche élimine la nécessité de conserver des secrets prépartagés. Limitez chaque connexion afin que seul le projet propriétaire puisse l’utiliser. Si plusieurs projets nécessitent l’accès à la même ressource, créez une connexion distincte dans chaque projet plutôt que de partager une seule connexion entre les projets. Cette pratique applique des limites d’accès strictes et empêche les futurs projets d’hériter de l’accès qu’ils n’ont pas besoin.

Évitez de créer des connexions au niveau du compte Azure AI Foundry. Ces connexions s’appliquent à tous les projets actuels et futurs du compte. Ils peuvent accorder par inadvertance un accès étendu aux ressources, violer les principes des privilèges minimum et augmenter le risque d’exposition de données non autorisées. Préférez uniquement les connexions au niveau du projet.

Réseautage

En plus de l’accès basé sur l’identité, cette architecture nécessite une confidentialité réseau.

La conception du réseau comprend les protections suivantes :

  • Un point d’entrée unique et sécurisé pour tout le trafic de l’interface utilisateur de conversation, qui réduit la surface d’attaque

  • Trafic réseau de sortie et de sortie filtré à l’aide d’une combinaison de groupes de sécurité réseau, d’un pare-feu d’applications web, d’itinéraires définis par l’utilisateur (UDR) et de règles de pare-feu Azure

  • Chiffrement de bout en bout des données en transit à l’aide de TLS

  • Confidentialité du réseau à l’aide de Private Link pour toutes les connexions de service PaaS Azure

  • Segmentation logique et isolation des ressources réseau, avec des sous-réseaux dédiés pour chaque regroupement de composants majeurs pour prendre en charge les stratégies de sécurité granulaires

Flux réseau

Diagramme montrant deux flux de mise en réseau à partir de l’architecture d’application web App Service de base et du flux de mise en réseau du service de l’agent Foundry.

L’architecture de l’application web App Service de référence décrit le flux entrant de l’utilisateur vers l’interface utilisateur de conversation et le flux d’App Service vers les services PaaS Azure. Cette section se concentre sur les interactions de l’agent.

Lorsque l’interface utilisateur de conversation communique avec l’agent déployé dans Azure AI Foundry, les flux réseau suivants se produisent :

  1. L’interface utilisateur de conversation hébergée par App Service lance des requêtes HTTPS via un point de terminaison privé vers le point de terminaison de l’API du plan de données Azure AI Foundry.

  2. Lorsque l’agent accède aux services PaaS Azure, tels que les dépendances de service, les magasins de connaissances personnalisés ou les outils personnalisés, il envoie des requêtes HTTPS du sous-réseau délégué aux points de terminaison privés de ces services.

  3. Lorsque l’agent accède aux ressources en dehors du réseau virtuel, y compris les API basées sur Internet ou les services externes, il est forcé d’acheminer ces requêtes HTTPS à partir du sous-réseau délégué via le Pare-feu Azure.

Les points de terminaison privés servent de contrôle de sécurité critique dans cette architecture en complément de la sécurité basée sur l’identité.

Entrée vers Azure AI Foundry

Cette architecture désactive l’accès public au plan de données Azure AI Foundry en autorisant uniquement le trafic via une liaison privée pour Azure AI Foundry. Vous pouvez accéder à la majeure partie du portail Azure AI Foundry via le site web du portail, mais toutes les fonctionnalités au niveau du projet nécessitent un accès réseau. Le portail s’appuie sur les API de plan de données de votre compte AI Foundry, qui sont accessibles uniquement via des points de terminaison privés. Par conséquent, les développeurs et les scientifiques des données doivent accéder au portail par le biais d’une zone de rebond, d’un réseau virtuel appairé ou d’une connexion EXPRESSRoute ou vpn de site à site.

Toutes les interactions programmatiques avec le plan de données de l’agent, comme à partir de l’application web ou à partir du code d’orchestration externe lors de l’appel de l’inférence de modèle, doivent également utiliser ces points de terminaison privés. Les points de terminaison privés sont définis au niveau du compte, et non au niveau du projet. Par conséquent, tous les projets au sein du compte partagent le même ensemble de points de terminaison. Vous ne pouvez pas segmenter l’accès réseau au niveau du projet, et tous les projets partagent la même exposition réseau.

Pour prendre en charge cette configuration, configurez DNS pour les points de terminaison d’API FQDN Azure AI Foundry suivants :

  • privatelink.services.ai.azure.com
  • privatelink.openai.azure.com
  • privatelink.cognitiveservices.azure.com

Le diagramme suivant montre comment un développeur IA se connecte via Azure Bastion à une zone de rebond de machine virtuelle. À partir de cette zone de rebond, l’auteur peut accéder au projet dans le portail Azure AI Foundry via un point de terminaison privé dans le même réseau.

Diagramme montrant comment un utilisateur se connecte à une machine virtuelle de zone de rebond via Azure Bastion.

Contrôler le trafic à partir du sous-réseau de l’agent Azure AI Foundry

Cette architecture achemine tout le trafic réseau sortant (sortant) à partir de la fonctionnalité service De l’agent Foundry via un sous-réseau délégué au sein de votre réseau virtuel. Ce sous-réseau sert de point de sortie unique pour les trois dépendances de service requises de l’agent et les connexions d’outils ou sources de connaissances externes utilisées par l’agent. Cette conception permet de réduire les tentatives d’exfiltration de données à partir de la logique d’orchestration.

En forçant ce chemin de sortie, vous bénéficiez d’un contrôle total sur le trafic sortant. Vous pouvez appliquer des règles de groupe de sécurité réseau granulaires, un routage personnalisé et un contrôle DNS à tout le trafic de l’agent qui quitte le service.

Le service d’agent utilise la configuration DNS du réseau virtuel pour résoudre les enregistrements de point de terminaison privé et les noms de domaine complets externes requis. Cette configuration garantit que les demandes de l’agent génèrent des journaux DNS, qui prennent en charge l’audit et la résolution des problèmes.

Le groupe de sécurité réseau attaché au sous-réseau de sortie de l’agent bloque tout le trafic entrant, car aucune entrée légitime ne doit se produire. Les règles de groupe de sécurité réseau sortantes autorisent uniquement l’accès aux sous-réseaux de points de terminaison privés au sein du réseau virtuel et au port TCP (Transmission Control Protocol) 443 pour le trafic lié à Internet. Le groupe de sécurité réseau refuse tout autre trafic.

Pour restreindre davantage le trafic Internet, cette architecture applique un UDR au sous-réseau, qui dirige tout le trafic HTTPS via le Pare-feu Azure. Le pare-feu contrôle les noms de domaine complets auxquels l’agent peut accéder via des connexions HTTPS. Par exemple, si l’agent doit uniquement accéder à Grounding avec les API publiques Bing, configurez le Pare-feu Azure pour autoriser le trafic vers le port 443 à api.bing.microsoft.com partir de ce sous-réseau. Toutes les autres destinations sortantes sont refusées.

Segmentation et sécurité du réseau virtuel

Cette architecture segmente le réseau virtuel en affectant chaque groupe de composants majeur à son propre sous-réseau. Chaque sous-réseau a un groupe de sécurité réseau dédié qui limite le trafic entrant et sortant uniquement à ce que le composant requiert.

Le tableau suivant récapitule la configuration du groupe de sécurité réseau et du pare-feu pour chaque sous-réseau.

Nom de l’utilisation ou du sous-réseau Trafic entrant (NSG) Trafic sortant (NSG) UDR vers le pare-feu Règles de sortie du pare-feu
Points de terminaison privés
snet-privateEndpoints		 Réseau virtuel Aucun trafic autorisé Oui Aucun trafic autorisé
Application Gateway
snet-appGateway		 Adresses IP sources de l’interface utilisateur de conversation, telles que l’Internet public et les sources requises pour le service Sous-réseau de point de terminaison privé et éléments requis pour le service Non -
Service d'application
snet-appServicePlan		 Aucun trafic autorisé Points de terminaison privés et Azure Monitor Oui Vers Azure Monitor
Service d’agent de la fonderie
snet-agentsEgress		 Aucun trafic autorisé Points de terminaison privés et Internet Oui Seuls les noms de domaine complets publics que vous autorisez vos agents à utiliser
Machines virtuelles de la zone de raccourci
snet-jumpBoxes		 Sous-réseau d’Azure Bastion Points de terminaison privés et Internet Oui En fonction des besoins de la machine virtuelle
Agents de build
snet-buildAgents		 Sous-réseau d’Azure Bastion Points de terminaison privés et Internet Oui En fonction des besoins de la machine virtuelle
Azure Bastion
AzureBastionSubnet		 Voir l’accès au groupe de sécurité réseau et Azure Bastion Voir l’accès au groupe de sécurité réseau et Azure Bastion Non -
Pare-feu Azure
AzureFirewallSubnet
AzureFirewallManagementSubnet		 Aucun groupe de sécurité réseau Aucun groupe de sécurité réseau Non -

Cette conception refuse explicitement tout autre trafic, soit par le biais de règles de groupe de sécurité réseau, soit par défaut dans le Pare-feu Azure.

Lorsque vous implémentez la segmentation et la sécurité réseau dans cette architecture, suivez les recommandations suivantes :

  • Déployez un plan Azure DDoS Protection sur l’adresse IP publique Application Gateway pour atténuer les attaques volumétriques.

  • Attachez un groupe de sécurité réseau à chaque sous-réseau qui le prend en charge. Appliquez les règles les plus strictes possibles sans perturber les fonctionnalités requises.

  • Appliquez le tunneling forcé à tous les sous-réseaux pris en charge afin que votre pare-feu de sortie puisse inspecter tout le trafic sortant. Utilisez le tunneling forcé même sur les sous-réseaux où vous ne vous attendez pas à la sortie. Cette méthode ajoute une mesure de défense en profondeur qui protège contre une mauvaise utilisation intentionnelle ou accidentelle du sous-réseau.

Gouvernance par la politique

Pour vous aligner sur la base de référence de sécurité de votre charge de travail, utilisez Azure Policy et les stratégies réseau pour vous assurer que toutes les ressources de charge de travail répondent à vos besoins. L’automatisation de la plateforme par le biais de la stratégie réduit le risque de dérive de la configuration de la sécurité et permet de réduire les activités de validation manuelle.

Envisagez d’implémenter les types de stratégies de sécurité suivants pour renforcer votre architecture :

  • Désactivez les méthodes d’authentification basées sur des clés ou d’autres méthodes d’authentification locales dans des services tels que les services Azure AI et Key Vault.

  • Exiger une configuration explicite des règles d’accès réseau, des points de terminaison privés et des groupes de sécurité réseau.

  • Exiger le chiffrement, tel que les clés gérées par le client.

  • Limitez la création de ressources, telles que la limitation des régions ou des types de ressources.

Optimisation des coûts

L’optimisation des coûts se concentre sur 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.

Cette estimation des tarifs Azure fournit un exemple de tarification pour cette architecture. Cet exemple inclut uniquement les composants de cette architecture. Personnalisez-le pour qu’il corresponde à votre utilisation. Les composants les plus coûteux dans le scénario sont Azure Cosmos DB, AI Search et DDoS Protection. D’autres coûts notables incluent le calcul de l’interface utilisateur de conversation et Application Gateway. Optimisez ces ressources pour réduire les coûts.

Service d’agent de la fonderie

Lorsque vous utilisez le déploiement standard, vous devez provisionner et gérer les dépendances du service dans votre propre abonnement Azure.

Les recommandations suivantes expliquent comment optimiser les coûts pour ces services requis :

  • Le service De l’agent Foundry gère l’allocation d’unités de requête (RU) sur Azure Cosmos DB. Pour réduire les coûts à long terme, achetez une capacité réservée pour Azure Cosmos DB. Aligner les réservations avec votre durée d’utilisation et votre volume attendus. N’oubliez pas que la capacité réservée nécessite un engagement initial et manque de flexibilité si les modèles d’utilisation de votre charge de travail changent considérablement.

  • Si votre scénario de conversation ne nécessite pas de chargements de fichiers, excluez cette fonctionnalité dans votre application. Dans ce cas, appliquez les modifications de configuration suivantes :

    • Utilisez un niveau de stockage localement redondant (LRS) pour le compte de stockage.
    • Configurez la recherche IA avec un seul réplica au lieu des trois réplicas recommandés.

  • Supprimez régulièrement les agents inutilisés et leurs threads associés à l’aide du Kit de développement logiciel (SDK) ou des API REST. Les agents et threads obsolètes continuent d’utiliser le stockage et peuvent augmenter les coûts dans Azure Cosmos DB, Stockage et Recherche IA.

  • Désactivez les fonctionnalités sur les ressources dépendantes dont votre charge de travail ne nécessite pas, telles que les fonctionnalités suivantes :

    • Le ranker sémantique dans la recherche IA
    • Fonctionnalités d’écriture de passerelle et multirégion dans Azure Cosmos DB

  • Pour éviter les frais de bande passante inter-régions, déployez Azure Cosmos DB, Stockage et Recherche IA dans la même région Azure que le service De l’agent Foundry.

  • Évitez de colocaliser des données spécifiques à la charge de travail dans les mêmes ressources Azure Cosmos DB ou AI Search que le service Foundry Agent utilise. Dans certains cas, vous pouvez partager ces ressources pour réduire la capacité inutilisée dans les unités de requête ou les unités de recherche, ce qui réduit les coûts. Envisagez uniquement le partage de ressources après une évaluation approfondie des risques pour la fiabilité, la sécurité et les compromis sur les performances.

Connaissances et outils de l’agent

Le service De l’agent Foundry exécute la logique de l’agent de manière non déterministe. Il peut appeler n’importe quel magasin de connaissances connecté, outil ou autre agent pour chaque requête, même si cette ressource n’est pas pertinente pour la requête utilisateur. Ce comportement peut entraîner des appels inutiles aux API externes ou aux sources de données, augmenter les coûts de chaque transaction et introduire des modèles d’utilisation imprévisibles qui compliquent les prévisions budgétaires.

Pour contrôler les coûts et maintenir un comportement prévisible, appliquez les stratégies suivantes :

  • Connectez uniquement les magasins de connaissances, les outils ou les agents susceptibles d’être utilisés avec la plupart des appels d’agent. Évitez de connecter des ressources rarement nécessaires ou qui entraînent des coûts élevés pour chaque appel, sauf s’ils sont essentiels.

  • Concevez et affinez soigneusement l’invite système pour demander à l’agent de réduire les appels externes inutiles ou redondants. L’invite système doit guider l’agent pour utiliser uniquement les connexions les plus pertinentes pour chaque requête.

  • Utilisez la télémétrie Azure AI Foundry pour surveiller les API externes, les magasins de connaissances ou les outils auxquels l’agent accède, la fréquence à laquelle il y accède et les coûts associés. Passez régulièrement en revue cette télémétrie pour identifier les modèles d’utilisation inattendus ou les pics de coûts, puis ajustez l’invite de votre système en fonction des besoins.

  • N’oubliez pas que l’appel non déterministe peut rendre les prévisions de coûts difficiles, en particulier lors de l’intégration à des API limitées. Si vous avez besoin de coûts prévisibles, envisagez d’héberger automatiquement l’orchestrateur à l’aide du code déterministe.

Modèles Azure OpenAI

Les déploiements de modèles dans Azure AI Foundry utilisent l’approche MaaS. Les coûts dépendent principalement de l’utilisation ou de l’allocation préprovisionnée.

Pour contrôler les coûts du modèle de consommation dans cette architecture, utilisez une combinaison des approches suivantes :

  • Contrôler les clients. Les demandes clientes entraînent la plupart des coûts dans un modèle de consommation, de sorte que le contrôle du comportement de l’agent est crucial.

    Pour réduire l’utilisation inutile, effectuez les actions suivantes :

    • Approuver tous les consommateurs de modèles. N’exposez pas les modèles d’une manière qui autorise un accès illimité.

    • Appliquez des contraintes de limitation des jetons telles que max_tokens et max_completions par le biais de la logique de l’agent. Ce contrôle est disponible uniquement dans l’orchestration auto-hébergée. Le service De l’agent Foundry ne prend pas en charge cette fonctionnalité.

    • Optimiser l’entrée d’invites et la longueur de réponse. Les invites plus longues consomment davantage de jetons, ce qui augmente le coût. Invite qui ne disposent pas d’un contexte suffisant réduisent l’efficacité du modèle. Créez des invites concises qui fournissent suffisamment de contexte pour permettre au modèle de générer une réponse utile. Veillez à optimiser la limite de la longueur de la réponse.

      Ce niveau de contrôle est disponible uniquement dans l’orchestration auto-hébergée. Le service De l’agent Foundry ne fournit pas suffisamment de configuration pour prendre en charge cette fonctionnalité.

  • Choisissez le modèle approprié pour l’agent. Sélectionnez le modèle le moins coûteux qui répond aux exigences de votre agent. Évitez d’utiliser des modèles à coût plus élevé, sauf s’ils sont essentiels. Par exemple, l’implémentation de référence utilise GPT-4o au lieu d’un modèle plus coûteux et obtient des résultats suffisants.

  • Surveillez et gérez l’utilisation. Utilisez Microsoft Cost Management et la télémétrie de modèle pour suivre l’utilisation des jetons, définir des budgets et créer des alertes pour les anomalies. Examinez régulièrement les modèles d’utilisation et ajustez les quotas ou l’accès client en fonction des besoins. Pour plus d’informations, consultez Planifier et gérer les coûts pour Azure AI Foundry.

  • Utilisez le bon type de déploiement. Utilisez la tarification de paiement à l’utilisation pour les charges de travail imprévisibles et basculez vers le débit approvisionné lorsque l’utilisation est stable et prévisible. Combinez les deux options lorsque vous établissez une base de référence fiable.

  • Restreindre l’utilisation du terrain de jeu. Pour éviter les coûts de production non planifiés, limitez l’utilisation du terrain de jeu Azure AI Foundry aux environnements de préproduction uniquement.

  • Planifiez soigneusement le réglage et la génération d’images. Ces fonctionnalités ont différents modèles de facturation. Ils sont facturés par heure ou par lot. Planifiez l’utilisation pour s’aligner sur les intervalles de facturation et éviter les déchets.

Ressources de sécurité réseau

Cette architecture nécessite le Pare-feu Azure comme point de contrôle de sortie. Pour optimiser les coûts, utilisez le niveau De base du Pare-feu Azure, sauf si le reste de vos composants de charge de travail nécessite des fonctionnalités avancées. Les niveaux supérieurs ajoutent des coûts, donc utilisez-les uniquement si vous avez besoin de leurs fonctionnalités.

Si votre organisation utilise des zones d’atterrissage Azure, envisagez d’utiliser des ressources de pare-feu partagé et de déni de service distribué (DDoS) pour différer ou réduire les coûts. Les charges de travail qui ont des exigences de sécurité et de performances similaires peuvent tirer parti des ressources partagées. Assurez-vous que les ressources partagées n’introduisent pas de risques opérationnels ou de sécurité. Cette architecture, déployée dans une zone d’atterrissage Azure, utilise des ressources partagées.

Excellence opérationnelle

L’excellence opérationnelle couvre 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.

Les conseils d’excellence opérationnelle suivants n’incluent pas les éléments d’application front-end, qui restent identiques à l’architecture d’application web redondante interzone hautement disponible de référence.

Lors de la planification de vos environnements d’expérimentation, de test et de production, établissez des ressources AI Foundry distinctes et isolées, notamment des dépendances.

Calcul de l’agent

Microsoft gère entièrement la plateforme de calcul serverless pour les API REST d’Azure AI Agent et la logique d’implémentation d’orchestration. Une orchestration auto-hébergée offre un meilleur contrôle sur les caractéristiques et la capacité du runtime, mais vous devez gérer directement les opérations quotidiennes de cette plateforme. Évaluez les contraintes et responsabilités de votre approche pour comprendre les opérations quotidiennes que vous devez implémenter pour prendre en charge votre couche d’orchestration.

Dans les deux approches, vous devez gérer le stockage d’état, comme l’historique des conversations et la configuration de l’agent pour la durabilité, la sauvegarde et la récupération.

Supervision

À l’instar de l’architecture de base, les données de diagnostic de tous les services sont configurées pour être envoyées à l’espace de travail Log Analytics de votre charge de travail. Tous les services, à l’exception d’App Service, capturent tous les journaux. En production, vous n’avez peut-être pas besoin de capturer tous les journaux. Par exemple, l’application de l’interface utilisateur de conversation peut nécessiter AppServiceHTTPLogsuniquement , , AppServiceConsoleLogsAppServiceAppLogs, AppServicePlatformLogset AppServiceAuthenticationLogs. Paramétrez les flux de journaux en fonction de vos besoins opérationnels.

Évaluez des alertes personnalisées, telles que des alertes personnalisées dans les alertes de base Azure Monitor, pour les ressources de cette architecture. Tenez compte des alertes suivantes :

Surveillez l’utilisation des jetons par rapport à vos déploiements de modèle. Dans cette architecture, Azure AI Foundry effectue le suivi de l’utilisation des jetons via son intégration à Application Insights.

Vos machines virtuelles de l’agent de rebond et de build résident dans un emplacement hautement privilégié, ce qui fournit à ces machines virtuelles une ligne de vue réseau au plan de données de tous les composants de votre architecture. Assurez-vous que ces machines virtuelles émettent suffisamment de journaux pour comprendre quand elles sont utilisées, qui les utilise et quelles actions elles effectuent.

Contrôle de version et cycle de vie de l’agent

Traitez chaque agent comme une unité déployable indépendamment au sein de votre charge de travail de conversation, sauf si vous concevez spécifiquement votre application pour créer et supprimer dynamiquement des agents au moment de l’exécution. Ces agents ont des exigences de gestion du cycle de vie similaires aux autres microservices de votre charge de travail.

Pour éviter les interruptions de service, assurez-vous que le déploiement de l’agent sécurisé et contrôlé est implémenté en implémentant les approches suivantes :

  • Définissez les agents en tant que code. Stockez toujours les définitions d’agent, les connexions, les invites système et les paramètres de configuration dans le contrôle de code source. Cette pratique garantit la traçabilité et la reproductibilité. Évitez les modifications non effectuées via le portail Azure AI Foundry.

  • Automatisez le déploiement de l’agent. Utilisez les pipelines d’intégration continue et de déploiement continu (CI/CD) de votre charge de travail. Utilisez le Kit de développement logiciel (SDK) Azure AI Agent pour générer, tester et déployer des modifications de l’agent à partir de vos agents de build connectés au réseau.

    Préférez les pipelines d’agent que vous pouvez déployer indépendamment pour les modifications petites et incrémentielles. Toutefois, assurez-vous que les pipelines offrent suffisamment de flexibilité pour les déployer en même temps que votre code d’application lorsque vous avez besoin de mises à jour coordonnées. Pour prendre en charge cette méthode, couplez librement votre code d’interface utilisateur de conversation et vos agents de conversation afin que les modifications apportées à un composant ne nécessitent pas de modifications simultanées à l’autre.

  • Test avant la production. Validez le comportement de l’agent, les invites et les connexions dans les environnements de préproduction. Utilisez une combinaison de tests automatisés et manuels pour intercepter les régressions, les problèmes de sécurité et les changements inattendus dans le comportement de l’agent.

    Les agents définis dans le service De l’agent Foundry se comportent de manière non déterministe. Vous devez donc déterminer comment mesurer et maintenir votre niveau de qualité souhaité. Créez et exécutez une suite de tests qui vérifie les réponses idéales aux questions et scénarios utilisateur réalistes.

  • Versions et agents de suivi. Affectez des identificateurs de version clairs à chaque agent. Conservez les enregistrements dont les versions de l’agent sont actives, ainsi que leurs dépendances telles que les modèles, les sources de données et les outils. Préférez déployer de nouvelles versions d’agent en même temps que celles existantes pour permettre le déploiement progressif, la restauration et la migration contrôlée des utilisateurs ou des sessions.

  • Planifier la restauration automatique. Azure AI Foundry ne fournit pas de prise en charge intégrée pour les déploiements bleu-vert ou canary des agents. Si vous avez besoin de ces modèles de déploiement, implémentez une couche de routage, telle qu’une passerelle d’API ou un routeur personnalisé, devant l’API de l’agent. Cette couche de routage vous permet de déplacer le trafic de manière incrémentielle entre les versions de l’agent, de surveiller l’impact et d’effectuer un basculement complet lorsque vous êtes prêt.

  • Suppression de l’agent de coordonnées. Lorsque vous supprimez des agents, coordonnez le processus avec les exigences de gestion de l’état et d’expérience utilisateur de votre application. Gérez les sessions de conversation actives de manière appropriée. Selon les exigences fonctionnelles de votre charge de travail, vous pouvez migrer des sessions, épingler des utilisateurs à l’ancienne version de l’agent ou exiger que les utilisateurs démarrent de nouvelles sessions.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement 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 traite de l’efficacité des performances pour la recherche IA, les déploiements de modèles et Azure AI Foundry.

Dans le service De l’agent Foundry, vous ne contrôlez pas les requêtes spécifiques envoyées à vos index, car les agents sont sans code. Pour optimiser les performances, concentrez-vous sur ce que vous pouvez contrôler dans l’index. Observez comment votre agent interroge généralement l’index et appliquez des conseils pour analyser et optimiser les performances dans la recherche IA.

Si le paramétrage du serveur d’index seul ne résout pas tous les goulots d’étranglement, tenez compte des options suivantes :

  • Remplacez la connexion directe à la recherche IA par une connexion à une API que vous possédez. Cette API peut implémenter du code optimisé pour les modèles de récupération de votre agent.

  • Reconcevoir la couche d’orchestration pour utiliser l’alternative auto-hébergée afin de pouvoir définir et optimiser les requêtes dans votre propre code d’orchestrateur.

Efficacité des performances dans les déploiements de modèles

  • Déterminez si votre application a besoin d’un débit provisionné ou peut utiliser le modèle partagé (consommation). Le débit approvisionné fournit une capacité réservée et une latence prévisible, ce qui est important pour les charges de travail de production qui ont des objectifs stricts au niveau du service. Le modèle de consommation fournit un service de meilleur effort et peut souffrir d’effets voisins bruyants.

  • Surveillez l’utilisation gérée par l’approvisionnement pour éviter le surprovisionnement ou le sous-approvisionnement.

  • Choisissez un modèle conversationnel qui répond à vos exigences de latence d’inférence.

  • Déployez des modèles dans la même région de données que vos agents pour réduire la latence réseau.

Performances de l’agent Azure AI

Les agents Azure AI s’exécutent sur un back-end de calcul serverless qui ne prend pas en charge le réglage des performances personnalisé. Toutefois, vous pouvez toujours améliorer les performances par le biais de la conception de l’agent :

  • Réduisez le nombre de magasins de connaissances et d’outils connectés à votre agent de conversation. Chaque connexion supplémentaire augmente potentiellement le runtime total d’un appel d’agent, car l’agent peut appeler toutes les ressources configurées pour chaque requête.

  • Utilisez Azure Monitor et Application Insights pour suivre les temps d’appel de l’agent, les latences des outils et des magasins de connaissances et les taux d’erreur. Passez régulièrement en revue cette télémétrie pour identifier les connexions lentes des connaissances ou des outils.

  • Concevoir des invites système qui guident l’agent pour utiliser efficacement les connexions. Par exemple, demandez à l’agent d’interroger les magasins de connaissances externes uniquement si nécessaire, ou d’éviter les appels d’outils redondants.

  • Surveillez les limites de service ou les quotas susceptibles d’affecter les performances pendant les pics d’utilisation. Surveillez les indicateurs de limitation tels que les réponses HTTP 429 ou 503, même si le calcul serverless est mis à l’échelle automatiquement.

Déployer ce scénario

Pour déployer et exécuter cette implémentation de référence, suivez le guide de déploiement dans l’implémentation de référence de référence du service De l’agent Foundry.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

  • Rob Bagby | Développeur de contenu principal - Modèles et pratiques Azure
  • Chad Kittel | Ingénieur logiciel principal - Modèles et pratiques Azure

Autres contributeurs :

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

Étape suivante