Architecture de référence de Microsoft Foundry pour le chat

Foundry Tools

Azure App Service

Azure Monitor

Microsoft Foundry

Service Foundry Agent

Les applications de conversation d’entreprise permettent aux employés d’interagir avec des agents IA via des conversations en langage naturel. Ces applications utilisent des modèles de langage, tels que des modèles GPT OpenAI et des kits de développement open source, tels que le Microsoft Agent Framework. 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.

• Définition d’orchestration persistante ou agent de longue durée qui supervise les interactions entre les sources de données, les modèles de langage et l’utilisateur.

Cet article fournit une architecture de base pour vous aider à créer et déployer des applications de conversation d’entreprise à l’aide de Foundry et Azure modèles OpenAI. Cette architecture utilise un seul agent basé sur des invites persisté dans le service d'agent Foundry. 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 baseline Azure App Service application web 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é. Cette architecture bloque l’accès public au portail et aux agents Foundry.

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. Pour obtenir des conseils sur l’hébergement de l’application web qui contient votre interface utilisateur de conversation, consultez cet article.

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

Conseil / Astuce

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

Architecture

Le diagramme présente une architecture détaillée Azure pour le déploiement d’une solution IA. À gauche, un utilisateur se connecte via Azure Application Gateway avec un pare-feu d’applications web, qui fait partie d’un réseau virtuel. Cette passerelle est liée à des zones DNS privées et protégée par Azure protection DDoS. Sous la passerelle, les points de terminaison privés se connectent à des services comme App Service, Azure Key Vault et Azure Storage, qui sont utilisés pour le déploiement d’applications clientes. App Service est géré avec une identité et s’étend sur trois zones. Application Insights et Azure Monitor fournissent une surveillance et Microsoft Entra ID gèrent l’authentification. À droite, le réseau virtuel contient plusieurs sous-réseaux : intégration d’App Service, point de terminaison privé, intégration de Foundry, intégration Azure agent IA, Azure Bastion, jump box, build agents et Azure Firewall. Chaque sous-réseau héberge des points de terminaison ou des services spécifiques, tels que le stockage, Foundry, Azure AI Search et Azure Cosmos DB, tous connectés via des points de terminaison privés. Le trafic sortant du réseau passe par Azure Firewall pour atteindre des sources Internet. À l’extrême droite, une zone distincte représente Foundry, qui inclut un compte et un projet. Les identités managées connectent le service De l’agent Foundry au projet Foundry, qui accède à son tour à un modèle OpenAI Azure. Le diagramme utilise des cercles numérotés pour indiquer le flux logique. Il montre comment les requêtes utilisateur transitent par le réseau, interagissent avec différents points de terminaison et se connectent enfin aux services Foundry et de stockage, avec des dépendances clairement regroupées et étiquetées.

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 acheminées via Azure Application Gateway. Azure Web Application Firewall inspecte ces requêtes avant de les transférer à l’instance App Service principale.

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 les points de terminaison de l’agent via le Microsoft Agent Framework. L’application web appelle l’agent sur un point de terminaison privé et s’authentifie auprès de Foundry à l’aide de son identité managée.

3. L’agent traite la demande de l’utilisateur en fonction des instructions de son message système. Pour répondre à l’intention de l’utilisateur, l’agent dispose d’un modèle de langage configuré et d’outils connectés. Dans cette architecture, les outils incluent l’outil Azure AI Search permettant de baser les données et l’outil de recherche Web Search pour les données web.

4. L’agent se connecte à Azure AI Search en utilisant l'outil de recherche IA dans le réseau privé par un point de terminaison privé.

5. Les demandes adressées à la plupart des outils externes, tels que la recherche web ou les outils d’API personnalisés, parcourent Azure Firewall 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 les détails d’appel de l’outil dans la conversation. Cet objet de conversation, stocké dans Azure Cosmos DB, conserve l’historique d’interaction complet en tant qu’éléments de conversation (messages, appels d’outils et sorties d’outils). Cet historique prend en charge les interactions prenant en charge le contexte et permet aux utilisateurs de reprendre des conversations avec l’agent sans perdre le contexte antérieur.

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

Components

Cette architecture s’appuie sur l’architecture de référence de la conversation 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 Foundry Agent est un environnement d’exécution natif cloud qui permet aux agents intelligents de fonctionner de manière sécurisée et autonome. Dans cette architecture, le service Foundry Agent fournit un environnement d'exécution géré pour un agent basé sur des commandes et s’intègre aux services Azure. Il héberge et gère les agents qui effectuent les tâches suivantes :

  • Traiter les demandes des utilisateurs
  • Orchestrer 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, mais le service De l’agent Foundry les 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 est un service de base de données de documents distribué à l’échelle mondiale. Dans cette architecture, elle héberge la base de données mémoire de la 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 conversations 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 Agent Foundry gère la base de données, ses collections et ses données.

  • Azure Storage est un service de stockage cloud pour les données non structurées. Dans cette architecture, elle fournit un stockage dédié pour 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 Agent Foundry gère les conteneurs et le cycle de vie des données au sein de ces conteneurs.

  • La recherche IA est une solution de recherche managée qui fournit des fonctionnalités de recherche. Dans cette architecture, le service Foundry Agent utilise la Recherche par IA pour stocker un index segmenté et consultable de fichiers téléversés via l'outil de Recherche de fichiers au cours des conversations avec l'agent. La recherche IA stocke également les fichiers statiques segmentés que vous ajoutez en tant que sources de connaissances lors de la création de l’agent. Ces fichiers restent disponibles dans tous les appels de l’agent. Le service Agent Foundry gère l’index, le schéma et les données, et utilise sa propre stratégie de partitionnement et sa logique de requête.

• Application Gateway est un équilibreur de charge de trafic web et un contrôleur de remise d’application. Dans cette architecture, elle 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 également la terminaison TLS (Transport Layer Security) et le routage basé sur le chemin. Application Gateway répartit les demandes entre les zones de disponibilité, qui supportent la haute disponibilité et les performances pour la couche applicative web. Son serveur principal est l’instance App Service qui héberge le code de l’application.

  • Azure Web Application Firewall est un service natif cloud qui protège les applications web contre les attaques web courantes. Dans cette architecture, elle 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 est un service cloud permettant de stocker et d’accéder en toute sécurité aux secrets, clés et certificats. Dans cette architecture, elle 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.

• Azure Virtual Network est le bloc de construction fondamental pour les réseaux privés dans Azure. Dans cette architecture, elle fournit une isolation réseau pour tous les composants pour vous aider à répondre aux exigences de sécurité et de conformité. 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 fournissez une inspection des flux d’entrée et de sortie.

• Azure Private Link est un service réseau qui fournit une connectivité privée d’un réseau virtuel à Azure services PaaS. Dans cette architecture, elle connecte tous les services PaaS, tels que Azure Cosmos DB, Stockage, Recherche IA et Service De l’Agent Foundry, au réseau virtuel via des points de terminaison privés. Private Link vous permet de vous assurer que tout le trafic de données reste sur le Azure principal, ce qui élimine l’exposition à l’Internet public et réduit la surface d’attaque.

• Azure Firewall est un service de sécurité réseau géré et basé sur le cloud. Dans cette architecture, elle inspecte et contrôle tout le trafic sortant (sortant) à partir du réseau virtuel. Il applique également 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 est un service d’hébergement pour les domaines DNS (Domain Name System) qui fournit la résolution de noms. Dans cette architecture, elle fournit des zones DNS privées liées au réseau virtuel. Il gère 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.

• Azure Storage est un service de stockage cloud pour les données non structurées et structurées. Dans cette architecture, elle prend en charge les workflows de déploiement sécurisés et automatisés et sépare les artefacts d’application des ressources de calcul. Il héberge le code de l’application web en tant que fichier ZIP pour le déploiement sur App Service.

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 chat

Approche actuelle : Cette architecture utilise le service Foundry Agent pour orchestrer les flux d’exécution d’agent basés sur les invites, notamment extraire des données de base via des outils connectés, appeler des modèles IA et appliquer un comportement de réponse cohérent en fonction des instructions au niveau du système et de l’historique conversationnel de l’agent. Le service d’agent Foundry fournit une orchestration sans code et non déterministe pour les charges de travail conversationnelles d’IA. Il gère les demandes de conversation, l’état de conversation, l’appel d’outils, la sécurité du contenu et l’intégration avec l’identité, la mise en réseau et l’observabilité. Le service prend en charge la persistance du contexte conversationnel et de l’état de l’agent via un modèle de données prédéfini déployé dans une base de données au sein de votre abonnement.

approche Alternative : Vous pouvez héberger des agents et implémenter une logique d’exécution personnalisée à l’aide de frameworks tels que Agent Framework, Semantic Kernel, LangChain ou code personnalisé qui respecte le protocole Foundry. Dans cette alternative, le service de l’Agent Foundry continue de gérer l’orchestration et l’état des conversations, tandis que le code de votre agent renforce ou étend le comportement d’exécution dans ces limites de protocole. Utilisez des agents hébergés pour déployer et exécuter des agents conteneurisés, déterministes et pilotés par code sur le service Foundry Agent. La plateforme gère les fonctionnalités d’infrastructure et d’orchestration de base.

Envisagez d’utiliser des agents hébergés au lieu d’agents basés sur des invites lorsque votre charge de travail nécessite une ou plusieurs des fonctionnalités suivantes :

• L’utilisation de modèles non pris en charge par le service Foundry Agent ou l’intégration avec les outils non exposés par le service

• Contrôle précis et déterministe sur le chemin d’exécution de l’agent, y compris les modèles d’orchestration explicites, les systèmes externes ou les appels d’outils, l’ingénierie d’invite, la connexion avec plusieurs agents ou l’intervention humaine dans la boucle

• Réutilisation de bases de code ou de bibliothèques existantes qui gèrent des processus métier complexes

• Audit, inspection ou certification du code de l’agent à des fins de sécurité, de conformité ou de réglementation

• Routage des demandes de client avancées pour l’expérimentation

• Pratiques de déploiement sécurisées au-delà du cycle de vie des agents hébergés standard

• Configuration du runtime de l’agent affinée, y compris les paramètres d’allocation de processeur et de mémoire ou de mise à l’échelle automatique

• Mémoire étendue stockée dans une base de données distincte aux côtés de l'état de conversation du service 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

Current approach : 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 nativement aux fonctionnalités de mise en réseau et de sécurité d'Azure.

approche Alternative : Vous pouvez utiliser d’autres plateformes de calcul gérées par Azure, comme 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 par IA et de classement sémantique.

approche Alternative : Vous pouvez utiliser d’autres plateformes de données pour baser les connaissances, telles que 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 multimodel ou du Kit de développement logiciel (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 classique pour la génération augmentée par récupération (RAG), mais pas toujours requise. Pour plus d’informations, consultez Choose 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.

Historique des conversations gérées par le client

Approche actuelle : Cette architecture utilise des conversations gérées par le service dans le service de l’agent Foundry pour conserver l’historique des discussions dans Azure Cosmos DB. Le service fournit une continuité multitour et intersession sans exiger que le client gère l’état et fournit automatiquement la conversation complète en tant que contexte pendant la génération de réponse.

Autre approche : L’application cliente gère l’historique des conversations au lieu de le déléguer au service d’agent. Chaque réponse est générée sans état et le client transfère les éléments de sortie des réponses précédentes en tant qu’entrée aux requêtes suivantes.

Tenez compte de l’historique des conversations gérées par le client lorsque votre charge de travail remplit une ou plusieurs des conditions suivantes :

• Rétention de données zéro. La conformité ou les exigences réglementaires interdisent la persistance côté serveur du contenu de conversation.

• Contrôle de fenêtre de contexte personnalisé. Vous devez inclure, exclure, résumer ou compacter localement les tours précédents de manière sélective avant de les envoyer au modèle.

• Plusieurs canaux d’expérience utilisateur avec sémantique de session indépendante. Le même agent est consommé par différentes applications (web, mobile, voix) qui ont chacun besoin de leur propre gestion, stockage et stratégies de rétention de session.

Cette approche déplace la responsabilité de la persistance de l’état, de la gestion du contexte, de la gouvernance des données de conversation et de l’isolation de session vers votre code d’application. Étant donné que l’état de conversation réside dans un magasin de données que vous possédez, vous devez appliquer vos propres processus de sauvegarde, de réplication et de restauration.

Prenez en compte les limites de contexte et l'augmentation de la taille de la charge utile de la requête HTTP à cause du transfert des éléments de conversation. Pour assurer la fiabilité multi-tour, utilisez un stockage persistant tel qu'Azure Cosmos DB ou la base de données de votre application existante plutôt qu'un état uniquement en mémoire.

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 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 des Kits de développement logiciel (SDK) Foundry. 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

• Assistance éphémère par agent contextuel pour des expériences d'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.

Orchestration à agent unique ou multi-agent

Approche actuelle : Cette architecture de référence utilise un seul agent qui a accès à tous les outils nécessaires pour gérer efficacement la plupart des interactions utilisateur.

Autre approche : Vous pouvez orchestrer plusieurs agents spécialisés, où chaque agent se concentre sur des domaines spécifiques, utilise différents modèles ou accède à des ensembles d’outils distincts.

Envisagez une approche multiagente lorsque votre charge de travail présente les caractéristiques suivantes :

• Les demandes couvrent plusieurs domaines d’expertise, comme l’analyse financière, l’examen juridique et la mise en œuvre technique. Les agents spécialisés fournissent des réponses plus approfondies et plus précises dans leurs domaines respectifs.

• Les informations nécessitent différents niveaux d’autorisation. Un agent de ressources humaines (RH) peut accéder aux données des employés, tandis qu’un agent de service client accède uniquement aux informations de produit. Les architectures multiagentes prennent en charge les limites de sécurité granulaires au niveau de l’agent.

• Différentes interactions de requête bénéficient de différents modèles. Un modèle léger gère des questions simples, tandis qu’un modèle plus puissant traite des tâches de raisonnement complexes. Cette approche optimise les coûts et la latence.

• L'expérience de chat sert d'interface pour les processus métier qui impliquent des étapes séquentielles ou parallèles nécessitant différents spécialistes.

Les approches multiagentes présentent une complexité de coordination et une latence accrue en raison de la communication entre les agents. Pour les scénarios bien définis sans exigences strictes d’isolation d’accès, un seul agent qui utilise un modèle et les outils appropriés répondent aux exigences.

Le service d'agent Foundry prend en charge la connexion d'agents Foundry à des agents et outils externes via des protocoles standard. Vous pouvez vous connecter à des outils hébergés sur des serveurs MCP (Model Context Protocol) et à d’autres agents via des points de terminaison Agent-to-Agent (A2A). Les deux types de connexion se comportent comme des points de terminaison HTTP externes du point de vue de l’agent. Ils nécessitent des règles de pare-feu pour la sortie et la configuration d’authentification appropriée.

Pour plus d’informations sur l’implémentation de plusieurs agents coordonnés, consultez les modèles d’orchestration des agents IA. Cet article traite des approches séquentielles, concurrentes, de discussion de groupe, de transfert et d’orchestration magnétique. Vous pouvez implémenter certains patrons dans le service Agent Foundry. D’autres modèles nécessitent une orchestration auto-hébergée à l’aide d’un KIT de développement logiciel (SDK) tel que Agent Framework.

Considérations

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

Appliquez cette architecture et les conseils de conception pour les charges de travail AI sur Azure pendant la phase de conception de votre charge de travail.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d'informations, veuillez consulter la liste de vérification de la conception pour la fiabilité.

L’architecture d’application web App Service de référence se concentre sur la redondance de zone 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 zones de la région peuvent rester inchangé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 Foundry et AI Search.

Redondance de zone dans votre couche d’orchestration

Les déploiements d’entreprise nécessitent généralement une redondance de zone pour réduire le risque d’interruption de service par rapport aux défaillances au niveau de la zone. Dans Azure, la redondance de zone signifie que vous utilisez des ressources qui prennent en charge zones d’indisponibilité et déployez au moins trois instances, ou activez la redondance au niveau de la plateforme où le contrôle d’instance direct n’est pas disponible.

Dans cette architecture, 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 Foundry Agent, qui sont Azure Cosmos DB, Storage et la recherche IA. Le service agent Foundry gère les données de ces services, mais vous configurez leur reliabilité dans les paramètres de votre abonnement.

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

• Utilisez la redondance de zone dans votre compte Azure Cosmos DB pour NoSQL. Cette configuration garantit la réplication synchrone des données entre plusieurs zones, ce qui réduit le risque de perte de données ou de temps d’arrêt d’une défaillance à une seule zone.

  Envisagez également distribution globale pour atténuer les pannes régionales dans Azure Cosmos DB.

• Utilisez le stockage redondant interzone (ZRS) pour votre compte de stockage. Pour une résilience plus élevée, utilisez le stockage géoredondant interzone (GZRS) qui combine la redondance interzone et régionale.

• Configurez votre instance de recherche IA avec au moins trois réplicas. Cette configuration garantit que le service distribue les copies entre les zones distinctes de votre région.

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 sources de données 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 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 de modèle Foundry

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-centre de données, vous devez utiliser un déploiement global ou un modèle de zone de données.

Pour les scénarios de conversation d'entreprise, déployez à la fois un modèle de zone de données provisionnée et un modèle de zone de données standard. Configurez le débordement 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.

Foundry ne prend pas en charge les mécanismes d’équilibrage de charge ou de basculement avancés, tels que le routage en boucle ou le circuit breaker, 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 Azure API Management. Cette approche vous permet d’implémenter des stratégies de routage, de vérifications d'état, 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 des API pour votre agent. Pour plus d’informations, consultez Utilisez une passerelle devant plusieurs déploiements ou instances OpenAI Azure.

Fiabilité dans la recherche dans l'IA pour les connaissances de l'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 d’indicateurs et de logs 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 aide à éviter le stranglement dû à un volume élevé de requêtes, à 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 Azure Firewall

Azure Firewall 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 Azure Firewall across toutes les zones de disponibilité dans 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 Azure Firewall 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 détectez des échecs de connexion ou des problèmes de débit, passez en revue les métriques de pare-feu et les journaux pour identifier et résoudre l’épuisement SNAT ou d’autres goulots d’étranglement.

Isoler les dépendances du service Agent Foundry des 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 de l'Agent Foundry parmi les éléments de charge de travail qui utilisent les mêmes services Azure. Plus précisément, ne partagez pas les ressources de recherche d'IA, de Azure Cosmos DB ou de stockage entre le service d'agent et d'autres composants d'application. Au lieu de cela, déployez 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 effets 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 alignés sur les 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, configurez un compte et une base de données distincts Azure Cosmos DB à 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, comme 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, comme l’exécution de demandes de droits d’oubli (RTBF). Traitez les données sous-jacentes comme interdites d'accès et ne faites que les surveiller.

Conception multirégion

Cette architecture utilise des zones de disponibilité pour la haute disponibilité dans une seule région Azure. Ce n’est pas 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 actif-actif, actif-passif ou actif-froid
• Processus de basculement régional et de rétablissement pour atteindre les objectifs de temps de récupération (RTO) 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 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 :

• Ancrage des outils de données et de leurs magasins de données
• Modèles d’hébergement et de point de terminaison d’inférence
• La couche d'orchestration ou d'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. Les pannes régionales sont donc 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, vous devez donc planifier un plan de reprise d'activité. 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ées aux conversations. La couche d’orchestration de l’agent peut également conserver l’état spécifique aux flux de conversations. Dans cette architecture, le service Foundry Agent 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 reprise après sinistre et vos opérations de reprise.

Le service d'agent Foundry ne fournit pas de capacités de récupération d'urgence intégrées. Il ne dispose pas de fonctionnalités permettant de répliquer l’état, de créer des sauvegardes ou d’effectuer des restaurations à un point dans le temps. La récupération est effectuée par le biais de la reconstruction, et non de la promotion d’un réplica. Un incident peut supprimer définitivement des agents, des conversations et des données de connaissances. Préparez-vous à la possibilité d'une perte totale de l'état pour le contenu et fixez des objectifs de récupération avec les parties prenantes en conséquence.

Les mesures compensatoires suivantes, basées sur le guide DR (Disaster Recovery) du service Foundry Agent, réduisent la probabilité et l'étendue de la perte de données, sans toutefois l'éliminer complètement.

• Azure Cosmos DB : Activez sauvegarde continue pour la base de données enterprise_memory. 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 conversations de chat. 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 Microsoft Support pour obtenir de l’aide sur les options de restauration d’index disponibles. 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 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 ZRS, contactez Microsoft support pour restaurer des données. Ce processus pourrait augmenter votre RTO (Recovery Time Objective). Comme pour la recherche IA, si votre interface utilisateur de chat ne prend pas en charge le téléchargement de fichiers et si vous n’avez pas d’agents utilisant des fichiers statiques comme connaissances, il est possible que vous n’ayez pas besoin d’un plan de récupération d’urgence pour les conteneurs blob.

• Cohérence transactionnelle : Si le stockage d'état pour votre charge de travail fait référence à des identificateurs d’agent IA Azure, tels que les ID de conversation ou les ID d’agent, coordonnez la récupération sur toutes les bases de données concernées. La restauration d’un sous-ensemble de dépendances uniquement peut entraîner des données orphelines ou incohérentes. Concevez vos processus de reprise après sinistre 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 messages système et les paramètres dans la gestion du code source. Cette pratique vous permet de redéployer des agents à partir d’une bonne configuration connue si vous perdez la couche d’orchestration. Évitez d’apporter des modifications non tracées à la configuration de l’agent via le portail Foundry ou les API de plan de données. Cette approche garantit que vos agents déployés restent reproductibles.

• Projets de fonderie : Utilisez une identité managée affectée par l'utilisateur pour un projet. Si le projet est supprimé accidentellement, une identité managée affectée par l’utilisateur vous permet de réutiliser vos attributions de rôles existantes lorsque vous recréez le projet et son hôte de capacité. Cette approche réduit la coordination requise avec les dépendances de projet pendant la récupération.

Pour renforcer la protection des dépendances du service Foundry Agent, ajoutez un verrou de suppression de ressource à chaque service. Cette pratique permet de protéger contre la perte catastrophique d’état dans la recherche IA, les Azure Cosmos DB et le stockage.

Avant de passer en production, élaborez un manuel d'opérations de récupération qui traite des défaillances à la fois de l’état géré par l’application et de celui géré par l’agent.

Security

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 plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

Cette architecture étend les bases de sécurité établies dans l’architecture de référence de conversation Foundry de base. Il ajoute 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 de Azure services.

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 gérées assignées par l'utilisateur. Dans les deux cas, appliquez les principes suivants :

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

  • Le compte Foundry
  • Chaque projet 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 à leur 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.

Connections

Les connexions définissent comment un compte Foundry ou un projet individuel s’authentifie et utilise une dépendance externe. Créez des connexions au niveau du projet lorsque cela est possible. Supprimez les connexions inutilisées. Préférez l’authentification basée sur Microsoft Entra ID pour toutes les connexions.

Si une connexion ne prend pas en charge Microsoft Entra ID, vous devez fournir un secret, comme une clé API. Stockez ces secrets dans un coffre de clés dédié et auto-hébergé sur Azure. Configurez une connexion Azure Key Vault pour le compte Foundry afin que le service puisse lire et écrire les secrets qu’il gère.

Utilisez ce coffre de clés uniquement pour Foundry. Ne le partagez pas avec d’autres composants de charge de travail. Toutes les connexions non-Microsoft Entra ID dans tous les projets du compte stockent leurs informations confidentielles dans ce coffre. D’autres composants de charge de travail n’ont pas besoin d’accéder à ces secrets pour utiliser les fonctionnalités Foundry. N'accordez pas d'autorisations de lecture ou d'écriture sur ce coffre à d'autres composants, sauf si vous avez une exigence opérationnelle claire ou si vous acceptez ce compromis.

Cette architecture comprend deux connexions basées sur une clé API : les métriques Application Insights pour Foundry et l’outil Recherche web. Lorsque vous étendez cette architecture avec des outils qui appellent des points de terminaison HTTP externes, tels que des serveurs MCP ou des API définies par OpenAPI, chaque outil ajoute une connexion de projet qui porte ses informations d’identification d’authentification.

Si vous utilisez des clés gérées par le client pour le chiffrement, vous pouvez héberger les clés gérées par le client et les secrets de connexion dans le même coffre dédié, si vos stratégies de gouvernance de sécurité autorisent la colocalisation des clés de chiffrement et des secrets.

Accès des employés du portail Foundry

Lorsque vous intégrez des employés aux projets Foundry, attribuez les autorisations minimales requises pour leur rôle. Utilisez Microsoft Entra ID groupes et Azure contrôle d’accès en fonction du rôle (Azure 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. Mais comprenez les limitations et les risques.

Le portail 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 Azure limités peuvent avoir une visibilité sur les données sensibles, telles que les conversations de chat, les définitions d’agent et la configuration. Cette conception du portail 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, révoquez ou bloquez l’accès au portail 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 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). Les nouveaux agents de ces projets contournent votre périmètre de sécurité prévu. Imposez la création de projets exclusivement par le biais de vos processus d'IaC contrôlés et auditables.

Attributions et connexions de rôles de projet 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 à privilège minimum, isolez vos ressources des dépendances du service de l’agent Foundry.

Tous les agents d’un projet 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 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 connections vers des ressources externes à partir de Foundry, utilisez l’authentification basée sur Microsoft Entra ID 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 Foundry, car les connexions au niveau du compte 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. Créez uniquement des connexions au niveau du projet.

Isolation des conversations

Service d’agent Foundry n’applique pas l’autorisation par utilisateur individuel sur les conversations. L’identité du serveur d’applications possède des informations d’identification au niveau du projet qui lui permettent de lire ou d’écrire dans n’importe quelle conversation en utilisant son propre ID. Si l’application de l’interface utilisateur de conversation transmet directement un ID de conversation fourni par le client au service d’agent sans validation, un utilisateur peut accéder ou injecter des messages dans la conversation d’un autre utilisateur. Il s’agit d’une vulnérabilité d’autorisation déficiente au niveau des objets.

Votre serveur d’applications doit appliquer le contrôle de la conversation. Ne vous fiez pas aux identificateurs de conversation du client. Sur chaque demande, vérifiez que l’utilisateur authentifié possède la conversation référencée avant de transférer la demande au service agent.

Networking

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 entrant et sortant 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 d'Azure Firewall

• 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

Le diagramme s'apparente à l'architecture de chat de bout en bout de référence. Il inclut l’architecture OpenAI Azure et trois flux réseau numérotés. Le flux entrant et le flux d’App Service vers Azure services PaaS sont copiés à partir de l’architecture web App Service de base. Le flux du service Agent Foundry affiche une flèche à partir du point de terminaison privé Foundry dans le réseau virtuel privé qui pointe vers le service Agent Foundry. La deuxième flèche numérotée dans le flux du service de l'agent Foundry montre les appels de l'agent virtuel de l'IA Azure dans le réseau privé qui passent par des points de terminaison privés. La troisième flèche numérotée montre une flèche de l’interface virtuelle vers une zone de Azure Firewall, qui indique que tous les appels à Internet transitent par ce pare-feu.

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

Lorsque l’interface utilisateur de conversation communique avec l’agent déployé dans 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 Foundry.

2. Lorsque l’agent accède à Azure services PaaS, 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 Azure Firewall.

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é. Étant donné que cette architecture utilise des points de terminaison privés et des UDR dans votre réseau virtuel, elle ne prend pas en charge la fonctionnalité de périmètre de sécurité réseau des projets Foundry.

Entrée à Foundry

Cette architecture bloque l’accès public au plan de données Foundry en autorisant le trafic uniquement via une liaison privée pour Foundry. Vous pouvez accéder à la plupart du portail 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 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é, d’une connexion Azure ExpressRoute ou d’une connexion VPN de site à site.

Toutes les interactions programmatiques avec le plan de données de l’agent doivent également utiliser ces points de terminaison privés. Les exemples incluent des appels depuis l'application web ou du code d'orchestration externe qui déclenche l'inférence d'un modèle. Les points de terminaison privés sont définis au niveau du compte, et non au niveau du projet, de sorte que tous les projets au sein du compte partagent les mêmes points de terminaison et exposition réseau. Vous ne pouvez pas segmenter l’accès réseau au niveau du projet.

Pour prendre en charge cette configuration, configurez DNS pour les points de terminaison d’API FQDN 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 Foundry via un point de terminaison privé dans le même réseau.

Un diagramme

Une flèche pointe d’un auteur d’agent, vers Azure Bastion, vers la zone de raccourci, vers un point de terminaison privé Foundry (portail), puis vers le projet Foundry qui contient le service De l’agent Foundry. À partir du projet Foundry, une flèche pointe vers une interface virtuelle dans le sous-réseau d’intégration de l’agent IA Azure. Une flèche finale pointe de l’interface virtuelle vers les points de terminaison privés des dépendances du service Foundry Agent. Ces dépendances sont la recherche IA, les Azure Cosmos DB et le stockage.

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

Cette architecture achemine tout le trafic réseau sortant de la fonctionnalité de service d'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 des points de terminaison privés et les noms de domaine entièrement qualifiés 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 NSG 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 Azure Firewall. 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 se connecte à un serveur MCP à https://contoso.com/mcp ou appelle une API externe via une définition d’outil OpenAPI, configurez Azure Firewall pour autoriser le trafic vers ces noms de domaine complets spécifiques sur le port 443 à partir de ce sous-réseau et assurez-vous que le groupe de sécurité réseau autorise ce trafic.

Note

Tous les outils de connaissances connectés à vos agents ne transitent pas par ce sous-réseau. Par exemple, l’outil Web Search appelle api.bing.microsoft.com, que vous pouvez vous attendre à acheminer via Azure Firewall en autorisant le port 443 à partir de ce sous-réseau. Mais le service d’agent appelle cet outil par le biais d’un mécanisme interne qui contourne entièrement le sous-réseau de sortie. Testez toutes les connexions intégrées de connaissances et d’outils pour votre charge de travail afin de vérifier s’ils s’alignent sur vos stratégies de contrôle de sortie réseau.

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 d'usage 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	-
App Service snet-appServicePlan	Aucun trafic autorisé	Points de terminaison privés et Azure Monitor	Oui	Vers Azure Monitor
Service d'agent Foundry 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 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 Azure Bastion	Points de terminaison privés et Internet	Oui	En fonction des besoins de la machine virtuelle
Azure Bastion AzureBastionSubnet	Consultez NSG access and Azure Bastion	Consultez NSG access and Azure Bastion	Non	-
Azure Firewall 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 Azure Firewall.

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

• Déployez un plan Azure protection DDoS 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 l'ensemble du trafic sortant. Utilisez le tunneling forcé même sur les sous-réseaux où vous ne vous attendez pas à du trafic sortant. 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.

Paramétrage du pare-feu d’applications web

Les applications de messagerie produisent fréquemment du contenu qui déclenche des faux positifs des règles de gestion du pare-feu d'applications web. Les invites utilisateur et les réponses de modèle contiennent souvent des extraits de code, des instructions SQL ou des fragments HTML. Le contenu de conversation peut déclencher des faux positifs dans de nombreuses catégories de règles managées, notamment l’exécution de code à distance, l’inclusion de fichiers locaux et les règles de renseignement sur les menaces. Dans les conversations à plusieurs tours, le score d’anomalie OWASP s’accumule entre les messages jusqu’à ce que le WAF bloque la requête avec une erreur HTTP 403, ce qui signifie que le blocage peut apparaître spontanément à mesure que les conversations sont plus longues.

Pour résoudre ce problème, ajustez votre stratégie WAF en créant des exclusions délimitées au champ corps de la demande qui contient des messages de conversation. Limiter les exclusions aux groupes de règles affectés plutôt que de désactiver les règles de manière globale. Vérifiez également que les limites d’inspection du corps de la demande prennent en charge les tailles de charge utile typiques dans vos interactions de conversation.

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 locales ou basées sur des clés dans des services tels que les outils Foundry et les 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, comme les clés gérées par le client.

• Limitez la création de ressources, comme 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 la liste de vérification de conception pour l’optimisation des coûts.

Cette estimation des prix Azure inclut uniquement les composants de cette architecture, afin que vous puissiez la personnaliser pour qu’elle corresponde à votre utilisation. Les composants les plus coûteux dans le scénario sont Azure Cosmos DB, la recherche IA et la protection DDoS. D’autres coûts notables incluent le calcul de l’interface utilisateur de conversation et d'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 configurer 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 agent Foundry gère l'allocation des 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. 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 par IA avec une seule réplique au lieu des trois répliques recommandées.

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

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

  • Le classificateur sémantique dans la recherche en IA

  • Les fonctionnalités d’écriture de passerelle et de multirégion dans Azure Cosmos DB

• Pour éviter les frais de bande passante inter-régions, déployez les Azure Cosmos DB, le service de stockage et la recherche d'IA dans la même région Azure que le service d'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 les capacités inutilisées dans les unités de requête ou de recherche, ce qui permet une réduction des 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 de Foundry exécute la logique de l’agent de manière non déterministe. Il peut appeler des outils connectés, notamment des outils de récupération des connaissances, des outils d’API personnalisés ou d’autres agents, pour chaque requête, même si cet outil n’est pas pertinent 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 outils que la plupart des appels d’agent sont susceptibles d’utiliser. Évitez de connecter des outils rarement nécessaires ou qui entraînent des coûts élevés pour chaque appel, sauf s’ils sont essentiels.

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

• Utilisez les métriques et les journaux Foundry pour surveiller les outils que l’agent appelle, la fréquence à laquelle il les appelle et les coûts associés. Passez régulièrement en revue ces données pour identifier les modèles d’utilisation inattendus ou les pics de coûts, et ajustez le message d'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 lorsque vous intégrez des API basées sur l’utilisation. Si vous avez besoin de coûts prévisibles, envisagez d’héberger automatiquement l’orchestrateur à l’aide du code déterministe.

Azure modèles OpenAI

Les déploiements de modèles dans 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 :

• Gérer les clients Les demandes clientes entraînent la plupart des coûts dans un modèle de consommation. Vous devez donc contrôler le comportement de l’agent.

  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 de jeton comme max_tokens et max_completion_tokens par le biais de la logique de l’agent. Ce contrôle est uniquement disponible dans une 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 plus de jetons, ce qui augmente le coût. Les invites qui n'ont pas de 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 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-4.1 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 les métriques d’utilisation du 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.

• 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 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 Azure Firewall comme point de contrôle de sortie. Pour optimiser les coûts, utilisez le niveau De base de Azure Firewall, 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 une zone 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é. Pour obtenir un exemple qui utilise des ressources partagées, consultez la version de la zone d’atterrissage de cette architecture.

Microsoft Defender for Cloud

Utilisez les plans de protection des charges de travail cloud suivants pour couvrir les ressources associées dans cette architecture.

Plan	Avantage
Microsoft Defender pour les serveurs	Détecte les vulnérabilités et surveille l’intégrité des fichiers pour aider à empêcher les jump boxes hautement privilégiés et les agents de compilation de devenir des vecteurs de menace.
Microsoft Defender pour App Service	Surveille les journaux, les machines hôtes et les interfaces de gestion de vos composants d'interface utilisateur de chat.
Microsoft Defender pour Azure Cosmos DB	Surveille les interactions de base de données pour détecter les signes d’utilisation incorrecte potentielle ou d’accès non autorisé aux données de conversation et aux définitions d’agent.
Microsoft Defender pour les services IA	Alertes sur les tentatives de jailbreakage ou les fuites de données en fonction des demandes et réponses de l’agent. Si votre organisation utilise Microsoft Purview, ce plan fournit également une intégration à Microsoft Purview Data Security Posture Management for AI (DSPM pour IA).

Si votre organisation utilise une solution SIEM (Security Information and Event Management) ou Microsoft Purview, assurez-vous que toutes les données client répliquées dans ces magasins de données, telles que les invites et les réponses, résident dans une région qui répond aux exigences de souveraineté des données de votre charge de travail.

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 Liste de vérification 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.

Lorsque vous planifiez vos environnements d’expérimentation, de test et de production, établissez des ressources Foundry distinctes et isolées, y compris des dépendances.

Agent de calcul

Microsoft gère la plateforme de calcul sans serveur pour les API REST du service Foundry Agent et la logique d'orchestration de l'implémentation. 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.

Kit de développement logiciel (SDK) d’interaction d’agent

Utilisez Microsoft Agent Framework comme Kit de développement logiciel (SDK) runtime dans votre application cliente pour l’envoi de messages à des agents, la gestion des conversations et le traitement des réponses. Agent Framework prend en charge C# et Python. Si votre application cliente nécessite JavaScript ou Java, utilisez le Kit de développement logiciel (SDK) Foundry directement pour ces interactions d’exécution.

Utilisez le Kit de développement logiciel (SDK) Foundry pour les opérations de gestion de plateforme, quel que soit le choix de votre kit SDK client. La création et le contrôle de version des définitions d’agent managé de manière centralisée appartiennent aux pipelines CI/CD et aux processus IaC, et non dans le code de l’application cliente.

Pour plus d’informations sur l’intégration de l'Agent Framework avec Foundry, consultez le fournisseur Microsoft Agent Framework Foundry.

Supervision

Comme pour l'architecture de base, cette architecture envoie des données de diagnostic de tous les services à l'espace de travail Log Analytics de votre charge de travail. La configuration capture toutes les catégories de journaux disponibles pour chaque service, à l’exception d’App Service. En production, vous n’avez peut-être pas besoin de chaque catégorie de log. Par exemple, l'application d'interface utilisateur de conversation sur App Service peut nécessiter uniquement AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogs et AppServiceAuthenticationLogs. Paramétrez les flux de journaux pour répondre à vos besoins opérationnels.

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

• Alertes de recherche d’IA
• Alertes des services IA
• alertes Web Apps

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

Vos jump boxes et machines virtuelles d'agent de build résident dans un emplacement hautement privilégié, ce qui donne à ces machines virtuelles un accès réseau direct au plan de données des composants de l'architecture. Assurez-vous que ces machines virtuelles émettent suffisamment de journaux pour indiquer quand les utilisateurs y accèdent, qui y accèdent et ce que font les utilisateurs sur ces machines.

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 suivies via le portail 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 les sdk Foundry 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’agents que vous pouvez déployer indépendamment pour des changements de petite taille et incrémentiels. 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 d'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 des dossiers des versions d'agents actives, ainsi que leurs dépendances comme les modèles, les sources de données et les outils. Déployez de nouvelles versions d’agent en même temps que les versions existantes pour prendre en charge le déploiement progressif, la restauration et la migration contrôlée des utilisateurs ou des sessions.

  Foundry prend en charge en mode natif les versions immuables de l’agent. Chaque fois que vous apportez des modifications à une définition d’agent, Foundry crée un instantané de version qui conserve la configuration précédente. Utilisez cet historique de version intégré pour les pistes d’audit et les cibles de restauration.

  Toutes les variantes d’exécution ne nécessitent pas de nouvelle version. Les entrées structurées paramétrent les définitions d’agent. Le client fournit des valeurs réelles au moment de la demande, afin qu’une version unique de l’agent puisse servir des configurations spécifiques à l’utilisateur ou spécifiques au contexte sans redéployer.

  Note

  Limitez les entrées structurées au texte d’instruction, comme l’injection d’un nom d’utilisateur dans l’invite système. Évitez d'utiliser des modèles pour les propriétés des points de terminaison d'outils, comme les URL du serveur MCP. Les points de terminaison d’outils basés sur des modèles permettent au client appelant de rediriger l’agent vers des services externes arbitraires au moment de l’exécution, ce qui nuit à la posture de gouvernance statique de cette architecture. Votre liste de contrôle d'accès FQDN de pare-feu bloque toujours les destinations non approuvées, mais la définition de l'agent elle-même ne documente plus les points de terminaison que l'agent est conçu pour atteindre.

• Appliquer le contrôle d’accès et l’isolation des données au niveau de l’utilisateur. Dans cette architecture, la couche application de l’interface utilisateur de conversation est la limite d’accès entre les utilisateurs finaux et vos agents. L’API de projet Foundry se trouve derrière des points de terminaison privés et n’est pas directement accessible aux consommateurs. Votre code d’application doit authentifier les utilisateurs finaux via Microsoft Entra ID et étendre chaque conversation et ses données associées à l’identité authentifiée.

  Lorsque vous utilisez des API au niveau du projet, tout principal disposant du rôle d’utilisateur IA Azure sur le projet Foundry peut interagir avec tous les agents de ce projet. La couche d'authentification et d'autorisation de votre application, plutôt que le RBAC du projet Foundry, détermine quels utilisateurs peuvent accéder à vos agents et conversations. Concevez votre gestion de session pour empêcher l’accès aux données inter-utilisateurs et appliquez les stratégies de gouvernance et de rétention des données de votre charge de travail aux données de conversation que votre application stocke.

• Planifiez le déploiement progressif et le repli. Foundry ne fournit pas de support intégré pour les déploiements bleu-vert ou canari des agents. Si vous avez besoin de ces modèles de déploiement ou de la migration contrôlée d’utilisateurs entre les versions de l’agent, implémentez une couche de routage, comme 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’effet et d’effectuer un basculement complet lorsque vous êtes prêt.

• Coordonner la suppression de l’agent. 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 Foundry.

Efficacité des performances dans la recherche IA

Dans le service Agent Foundry, vous ne contrôlez pas les requêtes spécifiques envoyées à vos index, car les agents sont sans utilisation de 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, qui prend en charge les charges de travail de production qui ont des objectifs stricts de niveau de service (SLA). Le modèle de consommation fournit un service au mieux et peut rencontrer des interférences dues à des voisins.

• 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 IA Azure

Azure agents IA 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 améliorer les performances par le biais de la conception de l’agent :

• Réduisez le nombre 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 tous les outils configurés pour chaque requête.

• Utilisez Azure Monitor et Application Insights pour suivre les temps d’appel de l’agent, les latences des outils et les taux d’erreur. Passez régulièrement en revue ces indicateurs pour identifier les lenteurs dans les connexions des outils.

• Concevoir des invites système qui guident l’agent à utiliser efficacement les connexions. Par exemple, demandez à l’agent d’interroger les outils de données de base 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 sans serveur s'adapte 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 du service agent Foundry.

L’application de l’interface utilisateur de conversation dans cette implémentation de référence est de base et montre comment communiquer avec les points de terminaison de l’agent. Pour obtenir des exemples d’expériences d’interface utilisateur de conversation plus avancées, consultez le référentiel d’applications web de l’agent Foundry.

Contributeurs

Microsoft conserve cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

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

Autres contributeurs :

• Raouf Aliouat | Ingénieur logiciel senior
• Freddy Ayala | Architecture de solution cloud
• Prabal Deb | Ingénieur logiciel principal
• Ritesh Modi | Ingénieur logiciel principal
• Ryan Pfalz | Responsable du programme technique senior

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

Étape suivante

• architecture de conversation Baseline Foundry dans une zone d’atterrissage Azure

Ressources associées

• charges de travail d’IA sur Azure
• Modèles Azure OpenAI
• Garde-fous et contrôles
• Modèles d’orchestration d’agent IA

Les applications de conversation d’entreprise permettent aux employés d’interagir avec des agents IA via des conversations en langage naturel. Ces applications utilisent des modèles de langage, tels que des modèles GPT OpenAI et des kits de développement open source, tels que le Microsoft Agent Framework. 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.

• Définition d’orchestration persistante ou agent de longue durée qui supervise les interactions entre les sources de données, les modèles de langage et l’utilisateur.

Cet article fournit une architecture de base pour vous aider à créer et déployer des applications de conversation d’entreprise à l’aide de Foundry et Azure modèles OpenAI. Cette architecture utilise un seul agent basé sur des invites persisté dans le service d'agent Foundry. 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 baseline Azure App Service application web 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é. Cette architecture bloque l’accès public au portail et aux agents Foundry.

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. Pour obtenir des conseils sur l’hébergement de l’application web qui contient votre interface utilisateur de conversation, consultez cet article.

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

Conseil / Astuce

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

Architecture

Le diagramme présente une architecture détaillée Azure pour le déploiement d’une solution IA. À gauche, un utilisateur se connecte via Azure Application Gateway avec un pare-feu d’applications web, qui fait partie d’un réseau virtuel. Cette passerelle est liée à des zones DNS privées et protégée par Azure protection DDoS. Sous la passerelle, les points de terminaison privés se connectent à des services comme App Service, Azure Key Vault et Azure Storage, qui sont utilisés pour le déploiement d’applications clientes. App Service est géré avec une identité et s’étend sur trois zones. Application Insights et Azure Monitor fournissent une surveillance et Microsoft Entra ID gèrent l’authentification. À droite, le réseau virtuel contient plusieurs sous-réseaux : intégration d’App Service, point de terminaison privé, intégration de Foundry, intégration Azure agent IA, Azure Bastion, jump box, build agents et Azure Firewall. Chaque sous-réseau héberge des points de terminaison ou des services spécifiques, tels que le stockage, Foundry, Azure AI Search et Azure Cosmos DB, tous connectés via des points de terminaison privés. Le trafic sortant du réseau passe par Azure Firewall pour atteindre des sources Internet. À l’extrême droite, une zone distincte représente Foundry, qui inclut un compte et un projet. Les identités managées connectent le service De l’agent Foundry au projet Foundry, qui accède à son tour à un modèle OpenAI Azure. Le diagramme utilise des cercles numérotés pour indiquer le flux logique. Il montre comment les requêtes utilisateur transitent par le réseau, interagissent avec différents points de terminaison et se connectent enfin aux services Foundry et de stockage, avec des dépendances clairement regroupées et étiquetées.

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 acheminées via Azure Application Gateway. Azure Web Application Firewall inspecte ces requêtes avant de les transférer à l’instance App Service principale.

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 les points de terminaison de l’agent via le Microsoft Agent Framework. L’application web appelle l’agent sur un point de terminaison privé et s’authentifie auprès de Foundry à l’aide de son identité managée.

3. L’agent traite la demande de l’utilisateur en fonction des instructions de son message système. Pour répondre à l’intention de l’utilisateur, l’agent dispose d’un modèle de langage configuré et d’outils connectés. Dans cette architecture, les outils incluent l’outil Azure AI Search permettant de baser les données et l’outil de recherche Web Search pour les données web.

4. L’agent se connecte à Azure AI Search en utilisant l'outil de recherche IA dans le réseau privé par un point de terminaison privé.

5. Les demandes adressées à la plupart des outils externes, tels que la recherche web ou les outils d’API personnalisés, parcourent Azure Firewall 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 les détails d’appel de l’outil dans la conversation. Cet objet de conversation, stocké dans Azure Cosmos DB, conserve l’historique d’interaction complet en tant qu’éléments de conversation (messages, appels d’outils et sorties d’outils). Cet historique prend en charge les interactions prenant en charge le contexte et permet aux utilisateurs de reprendre des conversations avec l’agent sans perdre le contexte antérieur.

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

Components

Cette architecture s’appuie sur l’architecture de référence de la conversation 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 Foundry Agent est un environnement d’exécution natif cloud qui permet aux agents intelligents de fonctionner de manière sécurisée et autonome. Dans cette architecture, le service Foundry Agent fournit un environnement d'exécution géré pour un agent basé sur des commandes et s’intègre aux services Azure. Il héberge et gère les agents qui effectuent les tâches suivantes :

  • Traiter les demandes des utilisateurs
  • Orchestrer 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, mais le service De l’agent Foundry les 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 est un service de base de données de documents distribué à l’échelle mondiale. Dans cette architecture, elle héberge la base de données mémoire de la 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 conversations 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 Agent Foundry gère la base de données, ses collections et ses données.

  • Azure Storage est un service de stockage cloud pour les données non structurées. Dans cette architecture, elle fournit un stockage dédié pour 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 Agent Foundry gère les conteneurs et le cycle de vie des données au sein de ces conteneurs.

  • La recherche IA est une solution de recherche managée qui fournit des fonctionnalités de recherche. Dans cette architecture, le service Foundry Agent utilise la Recherche par IA pour stocker un index segmenté et consultable de fichiers téléversés via l'outil de Recherche de fichiers au cours des conversations avec l'agent. La recherche IA stocke également les fichiers statiques segmentés que vous ajoutez en tant que sources de connaissances lors de la création de l’agent. Ces fichiers restent disponibles dans tous les appels de l’agent. Le service Agent Foundry gère l’index, le schéma et les données, et utilise sa propre stratégie de partitionnement et sa logique de requête.

• Application Gateway est un équilibreur de charge de trafic web et un contrôleur de remise d’application. Dans cette architecture, elle 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 également la terminaison TLS (Transport Layer Security) et le routage basé sur le chemin. Application Gateway répartit les demandes entre les zones de disponibilité, qui supportent la haute disponibilité et les performances pour la couche applicative web. Son serveur principal est l’instance App Service qui héberge le code de l’application.

  • Azure Web Application Firewall est un service natif cloud qui protège les applications web contre les attaques web courantes. Dans cette architecture, elle 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 est un service cloud permettant de stocker et d’accéder en toute sécurité aux secrets, clés et certificats. Dans cette architecture, elle 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.

• Azure Virtual Network est le bloc de construction fondamental pour les réseaux privés dans Azure. Dans cette architecture, elle fournit une isolation réseau pour tous les composants pour vous aider à répondre aux exigences de sécurité et de conformité. 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 fournissez une inspection des flux d’entrée et de sortie.

• Azure Private Link est un service réseau qui fournit une connectivité privée d’un réseau virtuel à Azure services PaaS. Dans cette architecture, elle connecte tous les services PaaS, tels que Azure Cosmos DB, Stockage, Recherche IA et Service De l’Agent Foundry, au réseau virtuel via des points de terminaison privés. Private Link vous permet de vous assurer que tout le trafic de données reste sur le Azure principal, ce qui élimine l’exposition à l’Internet public et réduit la surface d’attaque.

• Azure Firewall est un service de sécurité réseau géré et basé sur le cloud. Dans cette architecture, elle inspecte et contrôle tout le trafic sortant (sortant) à partir du réseau virtuel. Il applique également 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 est un service d’hébergement pour les domaines DNS (Domain Name System) qui fournit la résolution de noms. Dans cette architecture, elle fournit des zones DNS privées liées au réseau virtuel. Il gère 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.

• Azure Storage est un service de stockage cloud pour les données non structurées et structurées. Dans cette architecture, elle prend en charge les workflows de déploiement sécurisés et automatisés et sépare les artefacts d’application des ressources de calcul. Il héberge le code de l’application web en tant que fichier ZIP pour le déploiement sur App Service.

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 chat

Approche actuelle : Cette architecture utilise le service Foundry Agent pour orchestrer les flux d’exécution d’agent basés sur les invites, notamment extraire des données de base via des outils connectés, appeler des modèles IA et appliquer un comportement de réponse cohérent en fonction des instructions au niveau du système et de l’historique conversationnel de l’agent. Le service d’agent Foundry fournit une orchestration sans code et non déterministe pour les charges de travail conversationnelles d’IA. Il gère les demandes de conversation, l’état de conversation, l’appel d’outils, la sécurité du contenu et l’intégration avec l’identité, la mise en réseau et l’observabilité. Le service prend en charge la persistance du contexte conversationnel et de l’état de l’agent via un modèle de données prédéfini déployé dans une base de données au sein de votre abonnement.

approche Alternative : Vous pouvez héberger des agents et implémenter une logique d’exécution personnalisée à l’aide de frameworks tels que Agent Framework, Semantic Kernel, LangChain ou code personnalisé qui respecte le protocole Foundry. Dans cette alternative, le service de l’Agent Foundry continue de gérer l’orchestration et l’état des conversations, tandis que le code de votre agent renforce ou étend le comportement d’exécution dans ces limites de protocole. Utilisez des agents hébergés pour déployer et exécuter des agents conteneurisés, déterministes et pilotés par code sur le service Foundry Agent. La plateforme gère les fonctionnalités d’infrastructure et d’orchestration de base.

Envisagez d’utiliser des agents hébergés au lieu d’agents basés sur des invites lorsque votre charge de travail nécessite une ou plusieurs des fonctionnalités suivantes :

• L’utilisation de modèles non pris en charge par le service Foundry Agent ou l’intégration avec les outils non exposés par le service

• Contrôle précis et déterministe sur le chemin d’exécution de l’agent, y compris les modèles d’orchestration explicites, les systèmes externes ou les appels d’outils, l’ingénierie d’invite, la connexion avec plusieurs agents ou l’intervention humaine dans la boucle

• Réutilisation de bases de code ou de bibliothèques existantes qui gèrent des processus métier complexes

• Audit, inspection ou certification du code de l’agent à des fins de sécurité, de conformité ou de réglementation

• Routage des demandes de client avancées pour l’expérimentation

• Pratiques de déploiement sécurisées au-delà du cycle de vie des agents hébergés standard

• Configuration du runtime de l’agent affinée, y compris les paramètres d’allocation de processeur et de mémoire ou de mise à l’échelle automatique

• Mémoire étendue stockée dans une base de données distincte aux côtés de l'état de conversation du service 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

Current approach : 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 nativement aux fonctionnalités de mise en réseau et de sécurité d'Azure.

approche Alternative : Vous pouvez utiliser d’autres plateformes de calcul gérées par Azure, comme 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 par IA et de classement sémantique.

approche Alternative : Vous pouvez utiliser d’autres plateformes de données pour baser les connaissances, telles que 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 multimodel ou du Kit de développement logiciel (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 classique pour la génération augmentée par récupération (RAG), mais pas toujours requise. Pour plus d’informations, consultez Choose 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.

Historique des conversations gérées par le client

Approche actuelle : Cette architecture utilise des conversations gérées par le service dans le service de l’agent Foundry pour conserver l’historique des discussions dans Azure Cosmos DB. Le service fournit une continuité multitour et intersession sans exiger que le client gère l’état et fournit automatiquement la conversation complète en tant que contexte pendant la génération de réponse.

Autre approche : L’application cliente gère l’historique des conversations au lieu de le déléguer au service d’agent. Chaque réponse est générée sans état et le client transfère les éléments de sortie des réponses précédentes en tant qu’entrée aux requêtes suivantes.

Tenez compte de l’historique des conversations gérées par le client lorsque votre charge de travail remplit une ou plusieurs des conditions suivantes :

• Rétention de données zéro. La conformité ou les exigences réglementaires interdisent la persistance côté serveur du contenu de conversation.

• Contrôle de fenêtre de contexte personnalisé. Vous devez inclure, exclure, résumer ou compacter localement les tours précédents de manière sélective avant de les envoyer au modèle.

• Plusieurs canaux d’expérience utilisateur avec sémantique de session indépendante. Le même agent est consommé par différentes applications (web, mobile, voix) qui ont chacun besoin de leur propre gestion, stockage et stratégies de rétention de session.

Cette approche déplace la responsabilité de la persistance de l’état, de la gestion du contexte, de la gouvernance des données de conversation et de l’isolation de session vers votre code d’application. Étant donné que l’état de conversation réside dans un magasin de données que vous possédez, vous devez appliquer vos propres processus de sauvegarde, de réplication et de restauration.

Prenez en compte les limites de contexte et l'augmentation de la taille de la charge utile de la requête HTTP à cause du transfert des éléments de conversation. Pour assurer la fiabilité multi-tour, utilisez un stockage persistant tel qu'Azure Cosmos DB ou la base de données de votre application existante plutôt qu'un état uniquement en mémoire.

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 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 des Kits de développement logiciel (SDK) Foundry. 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

• Assistance éphémère par agent contextuel pour des expériences d'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.

Orchestration à agent unique ou multi-agent

Approche actuelle : Cette architecture de référence utilise un seul agent qui a accès à tous les outils nécessaires pour gérer efficacement la plupart des interactions utilisateur.

Autre approche : Vous pouvez orchestrer plusieurs agents spécialisés, où chaque agent se concentre sur des domaines spécifiques, utilise différents modèles ou accède à des ensembles d’outils distincts.

Envisagez une approche multiagente lorsque votre charge de travail présente les caractéristiques suivantes :

• Les demandes couvrent plusieurs domaines d’expertise, comme l’analyse financière, l’examen juridique et la mise en œuvre technique. Les agents spécialisés fournissent des réponses plus approfondies et plus précises dans leurs domaines respectifs.

• Les informations nécessitent différents niveaux d’autorisation. Un agent de ressources humaines (RH) peut accéder aux données des employés, tandis qu’un agent de service client accède uniquement aux informations de produit. Les architectures multiagentes prennent en charge les limites de sécurité granulaires au niveau de l’agent.

• Différentes interactions de requête bénéficient de différents modèles. Un modèle léger gère des questions simples, tandis qu’un modèle plus puissant traite des tâches de raisonnement complexes. Cette approche optimise les coûts et la latence.

• L'expérience de chat sert d'interface pour les processus métier qui impliquent des étapes séquentielles ou parallèles nécessitant différents spécialistes.

Les approches multiagentes présentent une complexité de coordination et une latence accrue en raison de la communication entre les agents. Pour les scénarios bien définis sans exigences strictes d’isolation d’accès, un seul agent qui utilise un modèle et les outils appropriés répondent aux exigences.

Le service d'agent Foundry prend en charge la connexion d'agents Foundry à des agents et outils externes via des protocoles standard. Vous pouvez vous connecter à des outils hébergés sur des serveurs MCP (Model Context Protocol) et à d’autres agents via des points de terminaison Agent-to-Agent (A2A). Les deux types de connexion se comportent comme des points de terminaison HTTP externes du point de vue de l’agent. Ils nécessitent des règles de pare-feu pour la sortie et la configuration d’authentification appropriée.

Pour plus d’informations sur l’implémentation de plusieurs agents coordonnés, consultez les modèles d’orchestration des agents IA. Cet article traite des approches séquentielles, concurrentes, de discussion de groupe, de transfert et d’orchestration magnétique. Vous pouvez implémenter certains patrons dans le service Agent Foundry. D’autres modèles nécessitent une orchestration auto-hébergée à l’aide d’un KIT de développement logiciel (SDK) tel que Agent Framework.

Considérations

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

Appliquez cette architecture et les conseils de conception pour les charges de travail AI sur Azure pendant la phase de conception de votre charge de travail.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d'informations, veuillez consulter la liste de vérification de la conception pour la fiabilité.

L’architecture d’application web App Service de référence se concentre sur la redondance de zone 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 zones de la région peuvent rester inchangé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 Foundry et AI Search.

Redondance de zone dans votre couche d’orchestration

Les déploiements d’entreprise nécessitent généralement une redondance de zone pour réduire le risque d’interruption de service par rapport aux défaillances au niveau de la zone. Dans Azure, la redondance de zone signifie que vous utilisez des ressources qui prennent en charge zones d’indisponibilité et déployez au moins trois instances, ou activez la redondance au niveau de la plateforme où le contrôle d’instance direct n’est pas disponible.

Dans cette architecture, 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 Foundry Agent, qui sont Azure Cosmos DB, Storage et la recherche IA. Le service agent Foundry gère les données de ces services, mais vous configurez leur reliabilité dans les paramètres de votre abonnement.

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

• Utilisez la redondance de zone dans votre compte Azure Cosmos DB pour NoSQL. Cette configuration garantit la réplication synchrone des données entre plusieurs zones, ce qui réduit le risque de perte de données ou de temps d’arrêt d’une défaillance à une seule zone.

  Envisagez également distribution globale pour atténuer les pannes régionales dans Azure Cosmos DB.

• Utilisez le stockage redondant interzone (ZRS) pour votre compte de stockage. Pour une résilience plus élevée, utilisez le stockage géoredondant interzone (GZRS) qui combine la redondance interzone et régionale.

• Configurez votre instance de recherche IA avec au moins trois réplicas. Cette configuration garantit que le service distribue les copies entre les zones distinctes de votre région.

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 sources de données 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 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 de modèle Foundry

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-centre de données, vous devez utiliser un déploiement global ou un modèle de zone de données.

Pour les scénarios de conversation d'entreprise, déployez à la fois un modèle de zone de données provisionnée et un modèle de zone de données standard. Configurez le débordement 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.

Foundry ne prend pas en charge les mécanismes d’équilibrage de charge ou de basculement avancés, tels que le routage en boucle ou le circuit breaker, 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 Azure API Management. Cette approche vous permet d’implémenter des stratégies de routage, de vérifications d'état, 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 des API pour votre agent. Pour plus d’informations, consultez Utilisez une passerelle devant plusieurs déploiements ou instances OpenAI Azure.

Fiabilité dans la recherche dans l'IA pour les connaissances de l'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 d’indicateurs et de logs 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 aide à éviter le stranglement dû à un volume élevé de requêtes, à 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 Azure Firewall

Azure Firewall 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 Azure Firewall across toutes les zones de disponibilité dans 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 Azure Firewall 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 détectez des échecs de connexion ou des problèmes de débit, passez en revue les métriques de pare-feu et les journaux pour identifier et résoudre l’épuisement SNAT ou d’autres goulots d’étranglement.

Isoler les dépendances du service Agent Foundry des 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 de l'Agent Foundry parmi les éléments de charge de travail qui utilisent les mêmes services Azure. Plus précisément, ne partagez pas les ressources de recherche d'IA, de Azure Cosmos DB ou de stockage entre le service d'agent et d'autres composants d'application. Au lieu de cela, déployez 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 effets 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 alignés sur les 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, configurez un compte et une base de données distincts Azure Cosmos DB à 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, comme 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, comme l’exécution de demandes de droits d’oubli (RTBF). Traitez les données sous-jacentes comme interdites d'accès et ne faites que les surveiller.

Conception multirégion

Cette architecture utilise des zones de disponibilité pour la haute disponibilité dans une seule région Azure. Ce n’est pas 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 actif-actif, actif-passif ou actif-froid
• Processus de basculement régional et de rétablissement pour atteindre les objectifs de temps de récupération (RTO) 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 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 :

• Ancrage des outils de données et de leurs magasins de données
• Modèles d’hébergement et de point de terminaison d’inférence
• La couche d'orchestration ou d'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. Les pannes régionales sont donc 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, vous devez donc planifier un plan de reprise d'activité. 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ées aux conversations. La couche d’orchestration de l’agent peut également conserver l’état spécifique aux flux de conversations. Dans cette architecture, le service Foundry Agent 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 reprise après sinistre et vos opérations de reprise.

Le service d'agent Foundry ne fournit pas de capacités de récupération d'urgence intégrées. Il ne dispose pas de fonctionnalités permettant de répliquer l’état, de créer des sauvegardes ou d’effectuer des restaurations à un point dans le temps. La récupération est effectuée par le biais de la reconstruction, et non de la promotion d’un réplica. Un incident peut supprimer définitivement des agents, des conversations et des données de connaissances. Préparez-vous à la possibilité d'une perte totale de l'état pour le contenu et fixez des objectifs de récupération avec les parties prenantes en conséquence.

Les mesures compensatoires suivantes, basées sur le guide DR (Disaster Recovery) du service Foundry Agent, réduisent la probabilité et l'étendue de la perte de données, sans toutefois l'éliminer complètement.

• Azure Cosmos DB : Activez sauvegarde continue pour la base de données enterprise_memory. 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 conversations de chat. 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 Microsoft Support pour obtenir de l’aide sur les options de restauration d’index disponibles. 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 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 ZRS, contactez Microsoft support pour restaurer des données. Ce processus pourrait augmenter votre RTO (Recovery Time Objective). Comme pour la recherche IA, si votre interface utilisateur de chat ne prend pas en charge le téléchargement de fichiers et si vous n’avez pas d’agents utilisant des fichiers statiques comme connaissances, il est possible que vous n’ayez pas besoin d’un plan de récupération d’urgence pour les conteneurs blob.

• Cohérence transactionnelle : Si le stockage d'état pour votre charge de travail fait référence à des identificateurs d’agent IA Azure, tels que les ID de conversation ou les ID d’agent, coordonnez la récupération sur toutes les bases de données concernées. La restauration d’un sous-ensemble de dépendances uniquement peut entraîner des données orphelines ou incohérentes. Concevez vos processus de reprise après sinistre 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 messages système et les paramètres dans la gestion du code source. Cette pratique vous permet de redéployer des agents à partir d’une bonne configuration connue si vous perdez la couche d’orchestration. Évitez d’apporter des modifications non tracées à la configuration de l’agent via le portail Foundry ou les API de plan de données. Cette approche garantit que vos agents déployés restent reproductibles.

• Projets de fonderie : Utilisez une identité managée affectée par l'utilisateur pour un projet. Si le projet est supprimé accidentellement, une identité managée affectée par l’utilisateur vous permet de réutiliser vos attributions de rôles existantes lorsque vous recréez le projet et son hôte de capacité. Cette approche réduit la coordination requise avec les dépendances de projet pendant la récupération.

Pour renforcer la protection des dépendances du service Foundry Agent, ajoutez un verrou de suppression de ressource à chaque service. Cette pratique permet de protéger contre la perte catastrophique d’état dans la recherche IA, les Azure Cosmos DB et le stockage.

Avant de passer en production, élaborez un manuel d'opérations de récupération qui traite des défaillances à la fois de l’état géré par l’application et de celui géré par l’agent.

Security

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 plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

Cette architecture étend les bases de sécurité établies dans l’architecture de référence de conversation Foundry de base. Il ajoute 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 de Azure services.

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 gérées assignées par l'utilisateur. Dans les deux cas, appliquez les principes suivants :

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

  • Le compte Foundry
  • Chaque projet 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 à leur 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.

Connections

Les connexions définissent comment un compte Foundry ou un projet individuel s’authentifie et utilise une dépendance externe. Créez des connexions au niveau du projet lorsque cela est possible. Supprimez les connexions inutilisées. Préférez l’authentification basée sur Microsoft Entra ID pour toutes les connexions.

Si une connexion ne prend pas en charge Microsoft Entra ID, vous devez fournir un secret, comme une clé API. Stockez ces secrets dans un coffre de clés dédié et auto-hébergé sur Azure. Configurez une connexion Azure Key Vault pour le compte Foundry afin que le service puisse lire et écrire les secrets qu’il gère.

Utilisez ce coffre de clés uniquement pour Foundry. Ne le partagez pas avec d’autres composants de charge de travail. Toutes les connexions non-Microsoft Entra ID dans tous les projets du compte stockent leurs informations confidentielles dans ce coffre. D’autres composants de charge de travail n’ont pas besoin d’accéder à ces secrets pour utiliser les fonctionnalités Foundry. N'accordez pas d'autorisations de lecture ou d'écriture sur ce coffre à d'autres composants, sauf si vous avez une exigence opérationnelle claire ou si vous acceptez ce compromis.

Cette architecture comprend deux connexions basées sur une clé API : les métriques Application Insights pour Foundry et l’outil Recherche web. Lorsque vous étendez cette architecture avec des outils qui appellent des points de terminaison HTTP externes, tels que des serveurs MCP ou des API définies par OpenAPI, chaque outil ajoute une connexion de projet qui porte ses informations d’identification d’authentification.

Si vous utilisez des clés gérées par le client pour le chiffrement, vous pouvez héberger les clés gérées par le client et les secrets de connexion dans le même coffre dédié, si vos stratégies de gouvernance de sécurité autorisent la colocalisation des clés de chiffrement et des secrets.

Accès des employés du portail Foundry

Lorsque vous intégrez des employés aux projets Foundry, attribuez les autorisations minimales requises pour leur rôle. Utilisez Microsoft Entra ID groupes et Azure contrôle d’accès en fonction du rôle (Azure 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. Mais comprenez les limitations et les risques.

Le portail 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 Azure limités peuvent avoir une visibilité sur les données sensibles, telles que les conversations de chat, les définitions d’agent et la configuration. Cette conception du portail 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, révoquez ou bloquez l’accès au portail 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 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). Les nouveaux agents de ces projets contournent votre périmètre de sécurité prévu. Imposez la création de projets exclusivement par le biais de vos processus d'IaC contrôlés et auditables.

Attributions et connexions de rôles de projet 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 à privilège minimum, isolez vos ressources des dépendances du service de l’agent Foundry.

Tous les agents d’un projet 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 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 connections vers des ressources externes à partir de Foundry, utilisez l’authentification basée sur Microsoft Entra ID 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 Foundry, car les connexions au niveau du compte 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. Créez uniquement des connexions au niveau du projet.

Isolation des conversations

Service d’agent Foundry n’applique pas l’autorisation par utilisateur individuel sur les conversations. L’identité du serveur d’applications possède des informations d’identification au niveau du projet qui lui permettent de lire ou d’écrire dans n’importe quelle conversation en utilisant son propre ID. Si l’application de l’interface utilisateur de conversation transmet directement un ID de conversation fourni par le client au service d’agent sans validation, un utilisateur peut accéder ou injecter des messages dans la conversation d’un autre utilisateur. Il s’agit d’une vulnérabilité d’autorisation déficiente au niveau des objets.

Votre serveur d’applications doit appliquer le contrôle de la conversation. Ne vous fiez pas aux identificateurs de conversation du client. Sur chaque demande, vérifiez que l’utilisateur authentifié possède la conversation référencée avant de transférer la demande au service agent.

Networking

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 entrant et sortant 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 d'Azure Firewall

• 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

Le diagramme s'apparente à l'architecture de chat de bout en bout de référence. Il inclut l’architecture OpenAI Azure et trois flux réseau numérotés. Le flux entrant et le flux d’App Service vers Azure services PaaS sont copiés à partir de l’architecture web App Service de base. Le flux du service Agent Foundry affiche une flèche à partir du point de terminaison privé Foundry dans le réseau virtuel privé qui pointe vers le service Agent Foundry. La deuxième flèche numérotée dans le flux du service de l'agent Foundry montre les appels de l'agent virtuel de l'IA Azure dans le réseau privé qui passent par des points de terminaison privés. La troisième flèche numérotée montre une flèche de l’interface virtuelle vers une zone de Azure Firewall, qui indique que tous les appels à Internet transitent par ce pare-feu.

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

Lorsque l’interface utilisateur de conversation communique avec l’agent déployé dans 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 Foundry.

2. Lorsque l’agent accède à Azure services PaaS, 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 Azure Firewall.

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é. Étant donné que cette architecture utilise des points de terminaison privés et des UDR dans votre réseau virtuel, elle ne prend pas en charge la fonctionnalité de périmètre de sécurité réseau des projets Foundry.

Entrée à Foundry

Cette architecture bloque l’accès public au plan de données Foundry en autorisant le trafic uniquement via une liaison privée pour Foundry. Vous pouvez accéder à la plupart du portail 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 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é, d’une connexion Azure ExpressRoute ou d’une connexion VPN de site à site.

Toutes les interactions programmatiques avec le plan de données de l’agent doivent également utiliser ces points de terminaison privés. Les exemples incluent des appels depuis l'application web ou du code d'orchestration externe qui déclenche l'inférence d'un modèle. Les points de terminaison privés sont définis au niveau du compte, et non au niveau du projet, de sorte que tous les projets au sein du compte partagent les mêmes points de terminaison et exposition réseau. Vous ne pouvez pas segmenter l’accès réseau au niveau du projet.

Pour prendre en charge cette configuration, configurez DNS pour les points de terminaison d’API FQDN 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 Foundry via un point de terminaison privé dans le même réseau.

Un diagramme

Une flèche pointe d’un auteur d’agent, vers Azure Bastion, vers la zone de raccourci, vers un point de terminaison privé Foundry (portail), puis vers le projet Foundry qui contient le service De l’agent Foundry. À partir du projet Foundry, une flèche pointe vers une interface virtuelle dans le sous-réseau d’intégration de l’agent IA Azure. Une flèche finale pointe de l’interface virtuelle vers les points de terminaison privés des dépendances du service Foundry Agent. Ces dépendances sont la recherche IA, les Azure Cosmos DB et le stockage.

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

Cette architecture achemine tout le trafic réseau sortant de la fonctionnalité de service d'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 des points de terminaison privés et les noms de domaine entièrement qualifiés 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 NSG 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 Azure Firewall. 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 se connecte à un serveur MCP à https://contoso.com/mcp ou appelle une API externe via une définition d’outil OpenAPI, configurez Azure Firewall pour autoriser le trafic vers ces noms de domaine complets spécifiques sur le port 443 à partir de ce sous-réseau et assurez-vous que le groupe de sécurité réseau autorise ce trafic.

Note

Tous les outils de connaissances connectés à vos agents ne transitent pas par ce sous-réseau. Par exemple, l’outil Web Search appelle api.bing.microsoft.com, que vous pouvez vous attendre à acheminer via Azure Firewall en autorisant le port 443 à partir de ce sous-réseau. Mais le service d’agent appelle cet outil par le biais d’un mécanisme interne qui contourne entièrement le sous-réseau de sortie. Testez toutes les connexions intégrées de connaissances et d’outils pour votre charge de travail afin de vérifier s’ils s’alignent sur vos stratégies de contrôle de sortie réseau.

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 d'usage 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	-
App Service snet-appServicePlan	Aucun trafic autorisé	Points de terminaison privés et Azure Monitor	Oui	Vers Azure Monitor
Service d'agent Foundry 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 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 Azure Bastion	Points de terminaison privés et Internet	Oui	En fonction des besoins de la machine virtuelle
Azure Bastion AzureBastionSubnet	Consultez NSG access and Azure Bastion	Consultez NSG access and Azure Bastion	Non	-
Azure Firewall 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 Azure Firewall.

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

• Déployez un plan Azure protection DDoS 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 l'ensemble du trafic sortant. Utilisez le tunneling forcé même sur les sous-réseaux où vous ne vous attendez pas à du trafic sortant. 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.

Paramétrage du pare-feu d’applications web

Les applications de messagerie produisent fréquemment du contenu qui déclenche des faux positifs des règles de gestion du pare-feu d'applications web. Les invites utilisateur et les réponses de modèle contiennent souvent des extraits de code, des instructions SQL ou des fragments HTML. Le contenu de conversation peut déclencher des faux positifs dans de nombreuses catégories de règles managées, notamment l’exécution de code à distance, l’inclusion de fichiers locaux et les règles de renseignement sur les menaces. Dans les conversations à plusieurs tours, le score d’anomalie OWASP s’accumule entre les messages jusqu’à ce que le WAF bloque la requête avec une erreur HTTP 403, ce qui signifie que le blocage peut apparaître spontanément à mesure que les conversations sont plus longues.

Pour résoudre ce problème, ajustez votre stratégie WAF en créant des exclusions délimitées au champ corps de la demande qui contient des messages de conversation. Limiter les exclusions aux groupes de règles affectés plutôt que de désactiver les règles de manière globale. Vérifiez également que les limites d’inspection du corps de la demande prennent en charge les tailles de charge utile typiques dans vos interactions de conversation.

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 locales ou basées sur des clés dans des services tels que les outils Foundry et les 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, comme les clés gérées par le client.

• Limitez la création de ressources, comme 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 la liste de vérification de conception pour l’optimisation des coûts.

Cette estimation des prix Azure inclut uniquement les composants de cette architecture, afin que vous puissiez la personnaliser pour qu’elle corresponde à votre utilisation. Les composants les plus coûteux dans le scénario sont Azure Cosmos DB, la recherche IA et la protection DDoS. D’autres coûts notables incluent le calcul de l’interface utilisateur de conversation et d'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 configurer 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 agent Foundry gère l'allocation des 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. 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 par IA avec une seule réplique au lieu des trois répliques recommandées.

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

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

  • Le classificateur sémantique dans la recherche en IA

  • Les fonctionnalités d’écriture de passerelle et de multirégion dans Azure Cosmos DB

• Pour éviter les frais de bande passante inter-régions, déployez les Azure Cosmos DB, le service de stockage et la recherche d'IA dans la même région Azure que le service d'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 les capacités inutilisées dans les unités de requête ou de recherche, ce qui permet une réduction des 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 de Foundry exécute la logique de l’agent de manière non déterministe. Il peut appeler des outils connectés, notamment des outils de récupération des connaissances, des outils d’API personnalisés ou d’autres agents, pour chaque requête, même si cet outil n’est pas pertinent 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 outils que la plupart des appels d’agent sont susceptibles d’utiliser. Évitez de connecter des outils rarement nécessaires ou qui entraînent des coûts élevés pour chaque appel, sauf s’ils sont essentiels.

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

• Utilisez les métriques et les journaux Foundry pour surveiller les outils que l’agent appelle, la fréquence à laquelle il les appelle et les coûts associés. Passez régulièrement en revue ces données pour identifier les modèles d’utilisation inattendus ou les pics de coûts, et ajustez le message d'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 lorsque vous intégrez des API basées sur l’utilisation. Si vous avez besoin de coûts prévisibles, envisagez d’héberger automatiquement l’orchestrateur à l’aide du code déterministe.

Azure modèles OpenAI

Les déploiements de modèles dans 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 :

• Gérer les clients Les demandes clientes entraînent la plupart des coûts dans un modèle de consommation. Vous devez donc contrôler le comportement de l’agent.

  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 de jeton comme max_tokens et max_completion_tokens par le biais de la logique de l’agent. Ce contrôle est uniquement disponible dans une 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 plus de jetons, ce qui augmente le coût. Les invites qui n'ont pas de 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 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-4.1 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 les métriques d’utilisation du 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.

• 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 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 Azure Firewall comme point de contrôle de sortie. Pour optimiser les coûts, utilisez le niveau De base de Azure Firewall, 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 une zone 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é. Pour obtenir un exemple qui utilise des ressources partagées, consultez la version de la zone d’atterrissage de cette architecture.

Microsoft Defender for Cloud

Utilisez les plans de protection des charges de travail cloud suivants pour couvrir les ressources associées dans cette architecture.

Plan	Avantage
Microsoft Defender pour les serveurs	Détecte les vulnérabilités et surveille l’intégrité des fichiers pour aider à empêcher les jump boxes hautement privilégiés et les agents de compilation de devenir des vecteurs de menace.
Microsoft Defender pour App Service	Surveille les journaux, les machines hôtes et les interfaces de gestion de vos composants d'interface utilisateur de chat.
Microsoft Defender pour Azure Cosmos DB	Surveille les interactions de base de données pour détecter les signes d’utilisation incorrecte potentielle ou d’accès non autorisé aux données de conversation et aux définitions d’agent.
Microsoft Defender pour les services IA	Alertes sur les tentatives de jailbreakage ou les fuites de données en fonction des demandes et réponses de l’agent. Si votre organisation utilise Microsoft Purview, ce plan fournit également une intégration à Microsoft Purview Data Security Posture Management for AI (DSPM pour IA).

Si votre organisation utilise une solution SIEM (Security Information and Event Management) ou Microsoft Purview, assurez-vous que toutes les données client répliquées dans ces magasins de données, telles que les invites et les réponses, résident dans une région qui répond aux exigences de souveraineté des données de votre charge de travail.

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 Liste de vérification 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.

Lorsque vous planifiez vos environnements d’expérimentation, de test et de production, établissez des ressources Foundry distinctes et isolées, y compris des dépendances.

Agent de calcul

Microsoft gère la plateforme de calcul sans serveur pour les API REST du service Foundry Agent et la logique d'orchestration de l'implémentation. 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.

Kit de développement logiciel (SDK) d’interaction d’agent

Utilisez Microsoft Agent Framework comme Kit de développement logiciel (SDK) runtime dans votre application cliente pour l’envoi de messages à des agents, la gestion des conversations et le traitement des réponses. Agent Framework prend en charge C# et Python. Si votre application cliente nécessite JavaScript ou Java, utilisez le Kit de développement logiciel (SDK) Foundry directement pour ces interactions d’exécution.

Utilisez le Kit de développement logiciel (SDK) Foundry pour les opérations de gestion de plateforme, quel que soit le choix de votre kit SDK client. La création et le contrôle de version des définitions d’agent managé de manière centralisée appartiennent aux pipelines CI/CD et aux processus IaC, et non dans le code de l’application cliente.

Pour plus d’informations sur l’intégration de l'Agent Framework avec Foundry, consultez le fournisseur Microsoft Agent Framework Foundry.

Supervision

Comme pour l'architecture de base, cette architecture envoie des données de diagnostic de tous les services à l'espace de travail Log Analytics de votre charge de travail. La configuration capture toutes les catégories de journaux disponibles pour chaque service, à l’exception d’App Service. En production, vous n’avez peut-être pas besoin de chaque catégorie de log. Par exemple, l'application d'interface utilisateur de conversation sur App Service peut nécessiter uniquement AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogs et AppServiceAuthenticationLogs. Paramétrez les flux de journaux pour répondre à vos besoins opérationnels.

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

• Alertes de recherche d’IA
• Alertes des services IA
• alertes Web Apps

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

Vos jump boxes et machines virtuelles d'agent de build résident dans un emplacement hautement privilégié, ce qui donne à ces machines virtuelles un accès réseau direct au plan de données des composants de l'architecture. Assurez-vous que ces machines virtuelles émettent suffisamment de journaux pour indiquer quand les utilisateurs y accèdent, qui y accèdent et ce que font les utilisateurs sur ces machines.

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 suivies via le portail 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 les sdk Foundry 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’agents que vous pouvez déployer indépendamment pour des changements de petite taille et incrémentiels. 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 d'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 des dossiers des versions d'agents actives, ainsi que leurs dépendances comme les modèles, les sources de données et les outils. Déployez de nouvelles versions d’agent en même temps que les versions existantes pour prendre en charge le déploiement progressif, la restauration et la migration contrôlée des utilisateurs ou des sessions.

  Foundry prend en charge en mode natif les versions immuables de l’agent. Chaque fois que vous apportez des modifications à une définition d’agent, Foundry crée un instantané de version qui conserve la configuration précédente. Utilisez cet historique de version intégré pour les pistes d’audit et les cibles de restauration.

  Toutes les variantes d’exécution ne nécessitent pas de nouvelle version. Les entrées structurées paramétrent les définitions d’agent. Le client fournit des valeurs réelles au moment de la demande, afin qu’une version unique de l’agent puisse servir des configurations spécifiques à l’utilisateur ou spécifiques au contexte sans redéployer.

  Note

  Limitez les entrées structurées au texte d’instruction, comme l’injection d’un nom d’utilisateur dans l’invite système. Évitez d'utiliser des modèles pour les propriétés des points de terminaison d'outils, comme les URL du serveur MCP. Les points de terminaison d’outils basés sur des modèles permettent au client appelant de rediriger l’agent vers des services externes arbitraires au moment de l’exécution, ce qui nuit à la posture de gouvernance statique de cette architecture. Votre liste de contrôle d'accès FQDN de pare-feu bloque toujours les destinations non approuvées, mais la définition de l'agent elle-même ne documente plus les points de terminaison que l'agent est conçu pour atteindre.

• Appliquer le contrôle d’accès et l’isolation des données au niveau de l’utilisateur. Dans cette architecture, la couche application de l’interface utilisateur de conversation est la limite d’accès entre les utilisateurs finaux et vos agents. L’API de projet Foundry se trouve derrière des points de terminaison privés et n’est pas directement accessible aux consommateurs. Votre code d’application doit authentifier les utilisateurs finaux via Microsoft Entra ID et étendre chaque conversation et ses données associées à l’identité authentifiée.

  Lorsque vous utilisez des API au niveau du projet, tout principal disposant du rôle d’utilisateur IA Azure sur le projet Foundry peut interagir avec tous les agents de ce projet. La couche d'authentification et d'autorisation de votre application, plutôt que le RBAC du projet Foundry, détermine quels utilisateurs peuvent accéder à vos agents et conversations. Concevez votre gestion de session pour empêcher l’accès aux données inter-utilisateurs et appliquez les stratégies de gouvernance et de rétention des données de votre charge de travail aux données de conversation que votre application stocke.

• Planifiez le déploiement progressif et le repli. Foundry ne fournit pas de support intégré pour les déploiements bleu-vert ou canari des agents. Si vous avez besoin de ces modèles de déploiement ou de la migration contrôlée d’utilisateurs entre les versions de l’agent, implémentez une couche de routage, comme 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’effet et d’effectuer un basculement complet lorsque vous êtes prêt.

• Coordonner la suppression de l’agent. 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 Foundry.

Efficacité des performances dans la recherche IA

Dans le service Agent Foundry, vous ne contrôlez pas les requêtes spécifiques envoyées à vos index, car les agents sont sans utilisation de 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, qui prend en charge les charges de travail de production qui ont des objectifs stricts de niveau de service (SLA). Le modèle de consommation fournit un service au mieux et peut rencontrer des interférences dues à des voisins.

• 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 IA Azure

Azure agents IA 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 améliorer les performances par le biais de la conception de l’agent :

• Réduisez le nombre 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 tous les outils configurés pour chaque requête.

• Utilisez Azure Monitor et Application Insights pour suivre les temps d’appel de l’agent, les latences des outils et les taux d’erreur. Passez régulièrement en revue ces indicateurs pour identifier les lenteurs dans les connexions des outils.

• Concevoir des invites système qui guident l’agent à utiliser efficacement les connexions. Par exemple, demandez à l’agent d’interroger les outils de données de base 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 sans serveur s'adapte 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 du service agent Foundry.

L’application de l’interface utilisateur de conversation dans cette implémentation de référence est de base et montre comment communiquer avec les points de terminaison de l’agent. Pour obtenir des exemples d’expériences d’interface utilisateur de conversation plus avancées, consultez le référentiel d’applications web de l’agent Foundry.

Contributeurs

Microsoft conserve cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

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

Autres contributeurs :

• Raouf Aliouat | Ingénieur logiciel senior
• Freddy Ayala | Architecture de solution cloud
• Prabal Deb | Ingénieur logiciel principal
• Ritesh Modi | Ingénieur logiciel principal
• Ryan Pfalz | Responsable du programme technique senior

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

Étape suivante

• architecture de conversation Baseline Foundry dans une zone d’atterrissage Azure

Ressources associées

• charges de travail d’IA sur Azure
• Modèles Azure OpenAI
• Garde-fous et contrôles
• Modèles d’orchestration d’agent IA