Ingénierie des comportements agentiques

Les modèles de langage volumineux (LLMs) ne sont pas déterministes par nature. La même entrée peut ne pas toujours produire la même sortie. Les méthodes de test traditionnelles luttent pour tenir compte de cette variabilité. Comment pouvez-vous adapter votre processus de développement afin d’avoir l’assurance que votre système fonctionnera systématiquement comme prévu ?

La transformation de l’IA d’entreprise soulève plus de questions : Comment protéger et régir les connaissances exclusives ? Comment concevez-vous un comportement fiable ? Comment utiliser des preuves d’exécution pour améliorer le système au fil du temps ?

L’ingénierie du comportement agentique (ABE), comme proposé par cet article, est une méthodologie indépendante de la plateforme pour spécifier, ancrer, contrôler, vérifier et observer le comportement des agents IA. La méthodologie vous aide à clarifier les besoins de l’utilisateur et du système, à définir les résultats attendus, à faire respecter les limites d’exécution et à vérifier les modifications par rapport à des scénarios représentatifs. Les tests traditionnels peuvent confirmer qu’une implémentation spécifique fonctionne comme prévu, mais elle ne parvient souvent pas à détecter complètement la dérive comportementale causée par les changements de modèles, d’invites, d’outils ou de sources de données. ABE répond à ce défi en rendant le comportement souhaité explicite et vérifiable en continu, ce qui permet aux équipes de faire évoluer des systèmes agentiques sans perdre confiance dans leurs résultats.

Concepts clés

L’artefact clé dans ABE est le contrat de comportement. Le contrat définit le comportement requis séparément de l’implémentation afin que les attentes restent explicites et vérifiables au fur et à mesure que le système change. Dans les systèmes agentiques, les modèles, les prompts, les implémentations d’outils, les sources de connaissances, la mémoire, les stratégies, l’orchestration et l’accès utilisateur peuvent tous changer au fil du temps. Utilisez des contrats de comportement pour évaluer l’effet de ces modifications sur le comportement requis afin d’identifier tout écart et d’y remédier.

Contrat de comportement

Un contrat de comportement définit ce qu’un agent doit et ne doit pas faire dans une situation circonscrite. Il spécifie :

• La situation, les acteurs et le périmètre dans lequel le contrat s’applique.
• Résultats acceptables et caractéristiques de résultat requises.
• Conclusions, divulgations, actions et effets secondaires interdits.
• Preuve requise avant que l’agent puisse conclure ou agir.
• Comportement lorsque les éléments probants sont insuffisants ou que les dépendances échouent.
• Remontée, approbation et conditions d’arrêt.

Le contrat rend explicites les exigences applicables de sécurité et d’IA responsable. Définissez ces exigences pendant la conception afin que votre équipe puisse les incorporer dans l’implémentation et la vérification dès le début. Pour obtenir des conseils sur la définition des responsabilités et des stratégies propres aux charges de travail, consultez IA responsable dans les charges de travail Azure.

Un contrat de comportement partage un principe avec la conception par contrat : rendre explicites les obligations logicielles. Il définit le comportement requis sans prescription d’une implémentation, de sorte que les exigences peuvent rester stables à mesure que l’implémentation change.

Utilisez un contrat pour une situation délimitée et plusieurs scénarios pour ses variantes. Créez un autre contrat lorsque les acteurs, l’autorité, les preuves requises ou les résultats acceptables changent matériellement.

Les équipes de produit et d’ingénierie gèrent conjointement le contrat de comportement en tant qu’artefact versionné. Le Product Owner, avec l’appui des experts du domaine, approuve le comportement prévu et les résultats attendus. L’ingénierie corédige les contraintes techniques et les exigences en matière de preuves, et conserve les définitions de scénarios testables, la couverture, le contrôle de version et la vérification.

Passez en revue les modifications apportées aux attentes comportementales conjointement et effectuez une révision de sécurité et de risque si nécessaire. La maintenance technique qui préserve ces attentes doit suivre le processus d’examen d’ingénierie de l’équipe. Pour obtenir des conseils connexes, consultez Responsabilité de la spécification fonctionnelle et Responsabilités relatives à la stratégie de test.

Exemple : Approuver les avis sur les produits à faible risque

Un site Web de vente au détail exige que son équipe chargée des normes vérifie la conformité des avis des clients sur les produits à une stratégie d'utilisation acceptable avant leur publication. L’équipe de gestion de la charge de travail souhaite qu’un agent approuve les soumissions à faible risque et envoie des cas plus risqués ou incertains à l’équipe des standards. L’objectif est de réduire la révision manuelle tout en conservant les normes de publication du site.

Le tableau suivant présente un contrat de comportement versionné pour cet agent.

Vous pouvez conserver le contrat au format JSON, YAML, Markdown, un document Word ou PDF. Choisissez un format que vos product owners, experts métier et ingénieurs peuvent examiner et versionner ensemble. JSON ou YAML permet aux outils de lire plus facilement des champs individuels. Quel que soit le format que vous choisissez, conservez une version faisant autorité et liez les scénarios et les résultats d’évaluation à celui-ci.

Dans cet exemple, la politique autorise les commentaires négatifs sur les produits et nécessite un examen humain des soumissions contenant des informations personnelles. Un client soumet :

La batterie ne dure qu’une heure. Je ne le rachèterais pas.

La décision attendue est d’approuver la soumission. Le dossier de décision cite la règle de politique applicable et explique que le texte décrit une expérience produit et ne contient aucun contenu nécessitant une révision humaine dans le cadre de cette politique.

Si la soumission comprend des informations personnelles, la décision attendue consiste à l’envoyer pour examen humain et à la conserver non publiée. Si la politique actuelle ne peut pas être récupérée, la soumission reste également non publiée.

L'application applique les autorisations et vérifie la soumission avant de publier un avis approuvé. Pour évaluer la décision de l’agent, comparez-la à la décision attendue de l’équipe de normes pour cette soumission.

Bibliothèque de scénarios

La bibliothèque de scénarios transforme le contrat de comportement en scénarios utilisateur concrets. Chaque scénario définit une requête ou une tâche, des éléments de preuve et des conditions de dépendance, ainsi qu’un résultat attendu. Elle applique le contrat de comportement sans en modifier les exigences.

Les experts du produit et du domaine valident les scénarios et les résultats attendus. L'équipe d'ingénierie assure la maintenance des définitions du contrat et de sa couverture.

Le tableau suivant montre comment la bibliothèque de scénarios applique le contrat de comportement aux situations représentatives de l’agent d’évaluation des produits :

Commencez les tests avec des cas synthétiques : des soumissions fictives et des réponses simulées du service de stratégie. La collecte des données de référence peut empêcher l’équipe d’ingénierie de terminer l’implémentation des fonctionnalités. Les cas synthétiques révèlent les lacunes du contrat ou de l'implémentation et donnent aux experts du domaine le temps de terminer la sélection et la validation des données de référence.

Utilisez des cas synthétiques pour guider les experts métier (SME) dans la collecte de cas de charge de travail réels pour un jeu de données de référence distinct. Le jeu de données doré étend les scénarios à l’aide de la même structure : les requêtes réelles, les preuves correspondantes et les résultats attendus validés par les experts métier (SME). Un scénario peut comporter de nombreux cas de référence.

Pour le scénario d’avis négatif, l’équipe chargée des normes collecte les soumissions réelles qui critiquent un produit, mais respectent la politique de publication. Ils conservent les entrées de test approuvées et la version de politique applicable, puis établissent la décision attendue. Les cas synthétiques orientent la collecte. Ils ne sont pas intégrés au jeu de données de référence.

La vérité terrain correspond à un résultat attendu ou à des éléments justificatifs validés par des experts du domaine, dont l'exactitude peut être établie, et non à une sortie enregistrée d'un agent. Consultez Utiliser les données appropriées pour l'évaluation.

Utilisez les scénarios pendant une preuve de concept pour comparer les implémentations en fonction du même contrat et des mêmes limites de coût et de latence. Pour l'agent chargé des avis sur les produits, vous testeriez les décisions d'approbation et les transferts vers une révision humaine par rapport aux résultats attendus par l'équipe chargée des normes. Enregistrez la conception et les compromis dans un ADR (architecture decision record) et conservez les scénarios de test de régression.

Liez chaque cas à sa version de scénario et de contrat, et enregistrez s’il est synthétique ou issu de données de charge de travail réelles. Conservez les scénarios indépendamment des prompts afin que le comportement requis reste testable à mesure que l’implémentation change.

Ajoutez des cas limites et des échecs de production ayant fait l'objet d'une révision. Si les périmètres de sécurité relèvent du périmètre, incluez les scénarios d’injection de prompt, d’usage abusif et d’exfiltration issus du red teaming de l’IA et de la modélisation des menaces.

Conservez les jeux de développement, de régression et de mise en production protégés distincts. Réservez certains cas de test pour la vérification des mises en production et ne les utilisez pas pour développer ou régler l’implémentation. Restreindre l’accès à ces cas et à leurs résultats attendus. Si un cas conduit à une modification de l'implémentation, déplacez-le vers la suite de tests de régression et remplacez-le par un autre cas validé par des experts du domaine.

Enveloppe opérationnelle

La plage de fonctionnement couvre un sous-ensemble des exigences non fonctionnelles de la charge de travail. Il définit les limites de ressources et d’exécution, telles que la latence, le coût, l’utilisation des jetons, les nouvelles tentatives, les appels d’outils et le temps passé à attendre l’approbation.

Le contrat définit le comportement attendu. L’enveloppe définit les limites opérationnelles dans lesquelles le système doit fonctionner. Un contrat peut faire référence à une version de l’enveloppe de fonctionnement lorsque ces limites font partie de ses critères d’acceptation. Versionnez l’enveloppe indépendamment afin que les limites opérationnelles puissent changer sans redéfinir les exigences comportementales qui n’ont pas changé. Les contrats de comportement et les enveloppes d’exploitation ne nécessitent pas de relation un-à-un.

Replay

Concevoir pour la réexécution

Replay, comme le suggère le nom, réexécute les étapes d’inférence de votre système en fournissant des réponses d’outil et d’API collectées ou des résultats RAG. Cette approche vous aide à paramétrer votre prompt et à identifier les preuves manquantes. Il évite les appels répétés aux API actives ou aux outils MCP (Model Context Protocol), qui peuvent être coûteux, soumis à une limitation de débit ou retourner des données qui changent au fil du temps.

Collectez les données nécessaires à la réexécution en production. Supprimez ou masquez les données sensibles conformément à la politique avant l’analyse ou la révision par un expert métier. Conservez les charges utiles des réponses et les arguments des requêtes correspondantes sans modifier la signification du cas. Si la suppression des informations sensibles élimine des éléments de preuve nécessaires, utilisez un jeu de données de test approuvé et documentez cette limitation.

Faites examiner et sélectionner les données issues de la production par un expert du domaine avant de les ajouter au jeu de données de référence ou de les utiliser pour créer des substituts de test. Les substituts de test peuvent simuler des réponses. La réexécution peut ainsi prendre en charge des scénarios nouveaux et existants sans nécessiter de données de production. Consultez Simuler des réponses avec Dev Proxy et Jeux de données d'évaluation dans Microsoft Foundry.

Configurer et exécuter la réexécution

Gérez les versions des jeux de données de réexécution utilisés pour l'évaluation et les tests de régression. Pour comparer une mise à jour avec la base de référence, exécutez les deux implémentations sur la même version du jeu de données, en utilisant les mêmes cas et les mêmes versions de l’évaluateur. Conservez les autres conditions de test cohérentes, à l’exception de la modification que vous testez. Lorsque vous ajoutez ou modifiez des cas, créez une nouvelle version du jeu de données et réexécutez les deux implémentations.

Pendant le développement, vous pouvez rejouer un plus petit ensemble de cas pour vérifier le comportement que vous modifiez. Si vous n’avez pas encore enregistré de réponses pour un nouveau scénario, utilisez des réponses simulées et étiquetez-les dans le jeu de données.

Choisissez l'objectif de l'exécution :

La configuration d’exécution s’étend au-delà du jeu de données et des évaluateurs. Elle inclut également le prompt, le modèle, les serveurs API/MCP, les bibliothèques de prise en charge et d'autres composants. Lorsque vous exécutez des évaluations, vous devez disposer d'une hypothèse claire et de modifications corrélées afin de vous assurer que chaque exécution ne modifie qu'un ensemble minimal d'éléments. Cela vous permet de mesurer correctement l’impact et d’éviter d’exécuter la même mise à jour plusieurs fois en raison de lacunes dans la tenue des registres.

Replay ne remplace pas les tests unitaires ou d’intégration. Chaque test vérifie un aspect différent du système logiciel, et ils sont tout aussi importants. Consultez Tester et évaluer les charges de travail IA.

Le diagramme suivant illustre le processus de réexécution partagé.

Exemple : vérifier une modification apportée à un agent chargé des avis sur les produits

Supposons que la version 42 de l’agent d’examen des produits approuve une soumission qui aurait dû être transmise à l’équipe des standards, car elle contient des informations personnelles. L'équipe prépare le cas en appliquant les mesures de protection des données de réexécution et utilise un test de développement ciblé tout en révisant l'implémentation de la version candidate 43.

1. Configurez une exécution d’évaluation pour le candidat 43. Le jeu de données d'évaluation doit inclure des cas normaux, ainsi que des avis négatifs conformes, des soumissions incertaines et des défaillances de dépendances. Mettez-le à jour avec des cas qui testent la fonctionnalité (règle d’informations personnelles). La mise à jour crée une nouvelle version du jeu de données. Exécutez l'évaluation et la version de référence sur le nouveau jeu de données. Rejouez le jeu de données complet pour mesurer la précision de la décision, le coût et la latence par scénario.

2. Mettez à jour le jeu de données de vérification de mise en production avec le nouveau cas d’usage et obtenez une version mise à jour. Référencez la version étendue du jeu de données et définissez les seuils d’acceptation. Réexécutez la version candidate 43 et la version de référence 42 sur la même suite de tests étendue et avec les mêmes éléments de preuve enregistrés.

3. Vérifiez les cas existants et nouveaux par rapport aux attentes révisées. Comptez approve pour les commentaires négatifs conformes et human_review pour les soumissions contenant des informations personnelles. Vérifiez que les soumissions en attente de révision humaine restent non publiées.

4. Enregistrez les résultats et les traces par cas avec leur version de configuration. Calculez les métriques pour chaque scénario. Utilisez les résultats de l'évaluation pour améliorer l'implémentation et les résultats de la vérification de la mise en production pour déterminer si la version candidate peut être publiée. Une amélioration globale ne compense pas le non-respect d'une exigence obligatoire.

Architecture

Pour utiliser la méthodologie ABE pour concevoir les fonctionnalités de votre charge applicative, commencez par la découverte des problèmes et formalisez le comportement attendu dans un contrat. Ensuite, déterminez si la charge de travail nécessite une exécution pilotée par l’agent. Collaborez avec le propriétaire de l’entreprise et l’équipe d’ingénierie pour clarifier les besoins et les hypothèses des utilisateurs. Déduisez les scénarios des contrats de comportement, identifiez les connaissances et les éléments de preuve dont le système a besoin, et déterminez les contrôles que le système environnant doit appliquer.

Le contrat de comportement et la bibliothèque de scénarios relient le système à deux boucles et guident l’implémentation et l’amélioration. La boucle interne du développeur vérifie les modifications avant la mise en production. La boucle externe de production collecte les preuves d’exécution et les commentaires pour identifier les défaillances ou les exigences modifiées.

ABE organise ce travail autour de cinq responsabilités d'ingénierie : spécifier, ancrer, contrôler, vérifier et observer. Ces responsabilités sont logiques, et non cinq services requis ou des étapes d’exécution séquentielles. Le travail sur une seule fonctionnalité peut s’étendre sur plusieurs domaines de responsabilité.

L’IA responsable et la sécurité sont des enjeux transversaux dans les cinq responsabilités du système. La responsabilité spécifier explicite les attentes en matière d'IA responsable et les exigences de sécurité dans les contrats de comportement. La responsabilité contrôler met en œuvre les règles d'accès et les mesures de protection de l'exécution qui permettent de respecter ces exigences.

Spécifier et ancrer permettent d'effectuer des vérifications préliminaires de l'état de préparation et de la faisabilité du projet. Spécifier définit le problème et les critères de réussite. Ground évalue si les informations requises sont disponibles et utilisables selon les exigences d’accès applicables. Utilisez ces résultats pour identifier les lacunes avant de vous engager dans la mise en œuvre, puis valider les hypothèses restantes dans une preuve de concept. Pour plus d’informations, consultez Aligner la stratégie technique avec les exigences métier.

Utilisez le contrat de comportement et la bibliothèque de scénarios pour comparer les conceptions réalisables. Une implémentation déterministe ou un flux de travail fixe avec des étapes assistées par modèle peuvent répondre aux exigences. Choisissez une approche agentique lorsque l’évaluation présente des avantages qui justifient son coût supplémentaire, sa latence et sa complexité opérationnelle. Pour obtenir des conseils sur le choix d’une approche d’exécution, consultez les flux de travail fixes par rapport aux systèmes dirigés par l’agent.

Spécifier

Utilisez la pensée de conception pour comprendre le besoin réel de l’utilisateur avant de choisir ce qui et comment automatiser. Collaborez avec les utilisateurs, les responsables métier et les experts métier pour convenir des résultats jugés acceptables, des contraintes et du comportement en cas d’échec.

Capturez ces exigences dans un contrat de comportement versionné et dérivez des scénarios de test pour créer la bibliothèque de scénarios. Les équipes de produit et d’ingénierie passent en revue les modifications apportées au comportement attendu ensemble. Pour répondre aux préoccupations liées à l’IA responsable et à la sécurité, impliquez des experts du domaine, des spécialistes des risques et des spécialistes de la sécurité. Versionnez le contrat de comportement et la bibliothèque de scénarios. Les notes de publication doivent indiquer les versions prises en charge et publiées du contrat et de la bibliothèque de scénarios.

Passez en revue les modifications requises en même temps que la feuille de route du produit et vérifiez à nouveau l’implémentation par rapport à celles-ci. Pour les charges de travail multi-agents, définissez un contrat de bout en bout et ajoutez des contrats de transfert où les responsabilités, les exigences de preuve ou les autorisations changent.

Pour l'agent chargé des avis sur les produits, convenez avec l'équipe chargée des normes des soumissions pouvant être approuvées automatiquement, des cas nécessitant une révision humaine et de la manière de gérer l'indisponibilité du service de stratégie ou de la file d'attente de révision.

Le diagramme suivant montre comment le contrat de comportement et la bibliothèque de scénarios guident l’implémentation et la vérification. Utilisez la bibliothèque de scénarios pour guider la curation du jeu de données d’or et définir des critères d’évaluation. Signalez les résultats par scénario, y compris le nombre de cas testés, afin qu’un score global ne masque pas les lacunes. Les résultats examinés à partir de l’évaluation et de la production peuvent entraîner des mises à jour de la bibliothèque de scénarios ou du contrat de comportement.

Pour les techniques de découverte, consultez Effectuer des recherches sur les utilisateurs et partager les insights.

Terre

Ancrer régit les connaissances et les éléments de preuve transmis à votre agent, notamment les informations récupérées, les réponses des outils, les règles métier et la mémoire. Il prépare des informations pertinentes et validées pour chaque tâche tout en préservant leur source et leur autorité. La provenance, la fraîcheur et la sensibilité sont des attributs clés qui doivent être correctement représentés.

Pour préparer des informations régies pour l'agent :

• Sélectionnez des sources faisant autorité et attribuez des propriétaires pour les gérer.
• Identifiez les exigences d'accès et préservez les métadonnées relatives aux autorisations et à la sensibilité pour la responsabilité Contrôler.
• Préparez les informations dans un format exploitable par l'agent, sans perdre leur signification métier, leur source ni leur version.

Pendant la conception, assurez-vous que les sources peuvent fournir les éléments de preuve exigés par le contrat de comportement. Pour l'agent chargé des avis sur les produits, associez chaque évaluation au texte intégral de la soumission, à sa révision et à la version de la stratégie applicable. Si des éléments de preuve requis sont manquants ou inaccessibles, résolvez le problème de données ou d'accès, réduisez la portée ou différez la fonctionnalité concernée.

À l'exécution, la couche de récupération indique si une recherche a renvoyé des données, n'a trouvé aucune correspondance ou a échoué. L’application utilise cet état, ainsi que les métadonnées de preuve, pour déterminer s’il faut continuer ou appliquer la réponse prévue par le contrat en cas de preuves insuffisantes.

Conservez les définitions métier et les règles dans des ressources versionnées gérées par la charge de travail, indépendamment des prompts et des modèles. Utilisez un contrat de données ou un modèle sémantique pour définir la structure et la signification des informations échangées avec d’autres agents et systèmes.

Le tableau suivant distingue les définitions métier des éléments de preuve propres à une requête donnée. Une plateforme d’ontologie ou de modèle sémantique peut aider à organiser ces définitions lorsque les agents et les systèmes ont besoin de concepts et de relations métier partagés.

Pour obtenir des exemples d’implémentation, consultez liaison de données de l’ontologie Fabric (préversion) et modèles sémantiques Power BI.

Vous pouvez établir un moteur de règles ou un flux de travail pour appliquer des règles métier dans du code déterministe avant de transmettre les résultats à l’agent. Testez ces règles de façon répétée par rapport aux cas examinés par des experts du domaine pour vérifier que l’implémentation correspond à la politique prévue et réduire l’incertitude d’implémentation.

Lors de l'assemblage du contexte, identifiez la source et le niveau d'autorité des directives métier, des éléments de preuve actuels et de la mémoire. Définissez ce que l’agent peut écrire en mémoire et combien de temps le conserver. La mémoire ne doit pas remplacer les enregistrements faisant autorité et ne peut pas être traitée comme des prompts ou des instructions.

Le diagramme suivant montre comment préparer et combiner des connaissances, des preuves et de la mémoire pour l’agent.

Contrôle

Contrôler protège la charge de travail grâce à l'authentification, à l'autorisation et à la gouvernance à l'exécution. Il établit qui peut accéder au système, ce que chaque appelant et agent peut faire, et quelles actions nécessitent une approbation. Appliquez ces décisions dans le code d’application et les services connectés, et non dans le modèle.

Suivez les bonnes pratiques de sécurité et effectuez la modélisation des menaces pour déterminer les protections d’exécution à implémenter. Un diagramme de flux de données (DFD) montre comment les informations se déplacent entre les appelants, les agents, les outils et les magasins de données, y compris l’emplacement où elles franchissent les limites de confiance. Utilisez cette analyse pour déterminer où appliquer les vérifications d’accès, restreindre le partage de données et exiger des approbations.

Ces limites de confiance font partie de votre défense contre les attaques. Par exemple, le contenu récupéré ou les réponses d’outil peuvent contenir des instructions malveillantes. Les contrôles d’accès et les points de validation doivent toujours s’appliquer si le modèle suit ces instructions. Suivez les principes de la défense en profondeur et du Confiance nulle. Associez ces contrôles à d'autres mesures de défense contre l'injection de prompt, plutôt que de considérer une seule mesure de protection comme suffisante.

Authentifiez les identités de l'appelant et de l'agent, puis autorisez chaque accès aux données et chaque action sur les outils en fonction de la tâche et de la ressource cible. Appliquez le principe du moindre privilège et faites respecter les exigences d'accès définies dans la responsabilité Ancrer. Lors de la délégation du travail, conservez le contexte d’autorisation et les références de preuves de l’appelant, puis vérifiez à nouveau les autorisations à chaque transfert. La délégation ne doit pas étendre l’autorité. Si l’accès est refusé, suivez le chemin d’arrêt ou d’escalade défini au lieu de contourner le déni via un autre outil ou agent.

La gouvernance à l'exécution impose également les approbations requises, les étapes obligatoires du flux de travail et les limites opérationnelles, telles que les budgets et les limites de débit. Réessayez uniquement les opérations pouvant être répétées sans risque. Lorsqu'une limite est atteinte, appliquez le comportement d'arrêt ou de repli défini dans le contrat. Ces contrôles complètent la conception globale de résilience de la charge de travail.

Dans l’exemple de l’agent d’examen des produits, l’accès est limité à la soumission affectée, à la politique applicable et aux actions de modération. Le flux de publication vérifie les autorisations, la révision de la soumission et la version de la stratégie avant de publier un avis approuvé. Ne donnez pas à l'agent les autorisations nécessaires pour modifier les stratégies ou effectuer des actions sur les comptes clients.

Le diagramme suivant montre comment les actions proposées sont évaluées et enregistrées.

Pour un exemple de récupération, consultez Concevoir une solution d'inférence RAG sécurisée pour les environnements multilocataires. Pour obtenir des conseils sur l’identité et la protection par couches, consultez Identité, accès et moindre privilège et Principes de conception de la sécurité.

Pour obtenir des exemples de contrôles d’exécution implémentés via l’orchestration de flux de travail, consultez les modèles multi-agents orientés flux de travail.

Vérifier

Verify combine les vérifications à cas unique avec l’évaluation au niveau du jeu de données dans la boucle interne du développeur.

Vérifier un cas unique

Pendant l’implémentation, exécutez ou rejouez un cas de test à l’aide de réponses enregistrées ou simulées. Inspectez la trace d’exécution pour comparer les preuves, les appels d’outils, les décisions de contrôle et les résultats avec le contrat de comportement et le scénario. Utilisez les résultats pour déboguer et affiner l’implémentation.

Evaluations

Exécutez des évaluations sur un jeu de données versionné pour mesurer le comportement dans les scénarios pris en charge. Définissez des métriques et des seuils d’acceptation à partir du contrat de comportement. Le tableau suivant décrit les scénarios et les mesures associées pour l’agent d’évaluation des produits.

Comparez la version candidate et la version de référence à l'aide du même jeu de données et des mêmes versions de l'évaluateur. Pour plus d’informations, consultez Configurer et exécuter le replay de session.

Signaler les résultats par scénario afin que les scores globaux ne masquent pas les régressions. Répétez les cas de test pour vérifier la cohérence. Définissez le nombre d’exécutions et de critères d’acceptation avant l’évaluation. Enregistrez le contrat de comportement, le jeu de données, l’évaluateur et la version du seuil avec les résultats.

Testez les cas d’exécution prolongée et le comportement d’échec aux limites de fonctionnement. Définissez les nombres d’étapes et d’appels d’outils, mais exigez un chemin d’accès exact uniquement lorsque le contrat en spécifie un. Pour les charges de travail multi-agents, testez les transferts ainsi que les résultats de bout en bout.

Exécutez ces vérifications en même temps que les tests unitaires et d’intégration. Bloquez les mises en production qui ne respectent pas les seuils requis pour les scénarios. Pour obtenir des conseils sur la mise en production, consultez la Liste de contrôle du parcours d'adoption.

Observer

Observer analyse les exécutions en production afin d'identifier les comportements réussis, les échecs et leurs causes. Le système doit collecter les commentaires des utilisateurs pour faciliter l’analyse. Démarrez l’analyse avec la classification des scénarios :

1. Classez les exécutions enregistrées en fonction de la tâche et du contexte d'exécution. Faire correspondre chaque exécution au scénario applicable et aux versions de contrat. Signalez les cas inhabituels ou ambigus pour examen.

2. Comparez le résultat avec le comportement attendu du scénario et combinez ces informations avec les commentaires des utilisateurs pour évaluer la réussite ou l’échec. Laissez les cas non évalués lorsque les éléments disponibles sont insuffisants.

3. Examinez les défaillances à l’aide de traces et de commentaires des réviseurs. Regroupez les résultats par cause, tels que les lacunes de connaissances, l’implémentation ou les défaillances liées aux dépendances, ou les exigences peu claires.

4. Demandez aux propriétaires de produits, aux experts du domaine et aux ingénieurs de passer en revue les résultats et de décider ce qu’il faut changer. Validez les résultats attendus avant d’ajouter des cas préparés à la couverture des tests de régression. Enregistrez la raison de chaque modification et vérifiez-la avant la mise en production.

Dans l’exemple de l’agent de révision de produit, le routage d’une soumission contenant des informations personnelles vers l’examen humain tout en la conservant non publiée est un comportement réussi. L’approuver est un exemple d’échec. Une demande visant à prendre en charge l'examen d'images indique plutôt un changement potentiel de périmètre.

Capturez l’entrée de tâche, les demandes d’outils et les réponses, le contenu récupéré fourni au modèle et la sortie. Conservez les versions des sources, les décisions de contrôle et les échecs. Lier les commentaires de l’utilisateur et du réviseur au run et à la mise en production. Réduisez les données capturées, appliquez les limites d’accès et de rétention et suivez les instructions de préparation des données de replay avant l’analyse ou la curation du jeu de données.

Pour voir un exemple de mise en relation des résultats de production et de l'évaluation, consultez la boucle de qualité de l'observabilité des agents.

Liste de contrôle du parcours d’adoption

Commencez par une implémentation minimale viable centrée sur un comportement ayant des conséquences importantes dans votre charge de travail.

La plus petite implémentation d’ABE utile n’est pas une plateforme. Il s’agit d’un comportement explicite, rejouable, évalué et soumis à validation. La première boucle opérationnelle repose sur Spécifier et Vérifier. Évitez de créer une plateforme généraliste avant que l'équipe puisse utiliser un contrat unique pour prévenir, détecter ou diagnostiquer un problème comportemental réel.

1. Sélectionnez une situation bien délimitée et importante, identifiez les responsables produit et ingénierie, et faites appel à des experts du domaine.
2. Rédigez un contrat de comportement unique, soumis à une revue, qui inclut les éléments de preuve et les états d'échec.
3. Définissez des scénarios couvrant les cas normaux, les cas limites, les preuves insuffisantes et les défaillances des dépendances. Générez des cas synthétiques à partir de ces scénarios pour commencer le test.
4. Utilisez les cas synthétiques pour guider les experts métier dans la collecte et l’organisation des cas de charge de travail réels pour un jeu de données d’or distinct.
5. Capturez ou simulez des réponses stables des outils et des sources de connaissances pour permettre leur rejeu.
6. Ajouter des vérifications déterministes et uniquement les évaluateurs basés sur les jugements requis par le contrat.
7. Exécutez les scénarios d’intégration continue et bloquez les mises en production en cas de défaillances critiques.
8. Enregistrez suffisamment d’informations à partir des exécutions en production pour identifier le contrat, l’implémentation, le chemin d’accès aux preuves et le résultat.
9. Transformez les résultats de production examinés en scénarios de régression.

Les modifications apportées aux prompts, aux paramètres du modèle et au code d’application peuvent modifier le comportement de l’agent. Validez ces modifications avant de les utiliser en production. Enregistrez les versions que vous avez testées, la configuration de l’évaluation et les résultats. Suivez les pratiques de déploiement sécurisées pour introduire progressivement des modifications et planifier la récupération en cas de problème. Incluez les modifications de configuration dans le plan de reprise.

Faites évoluer cette première boucle à mesure que vous découvrez les besoins de votre charge de travail. Lorsque les agents et les systèmes ont besoin de définitions et de relations métier partagées, un modèle de données sémantique peut fournir cette base. Lorsque les décisions suivent des règles métier explicites, un moteur de règles peut appliquer ces règles en dehors du modèle. Conservez les contrôles d’accès et les preuves d’exécution dont votre charge de travail a besoin dès le début, puis développez la surveillance et l’automatisation à mesure que les risques et les résultats de production le justifient.

Implémenter ABE sur Azure

ABE est indépendant de la plateforme. Azure fournit des services que vous pouvez utiliser pour prendre en charge ses cinq responsabilités d’ingénierie.

Le diagramme suivant associe chaque responsabilité ABE aux services Azure à prendre en compte pour votre charge de travail.

Pour chaque responsabilité d’ingénierie, combinez les fonctionnalités Azure avec les contrats, les contrôles et les processus de révision que votre équipe gère.

Avant de choisir un service Azure, vérifiez que ses fonctionnalités, régions et API correspondent à votre charge de travail. Privilégiez les services en disponibilité générale (GA) et les contrôles gérés par l'application pour l'application obligatoire des règles et les vérifications avant mise en production. Certaines des fonctionnalités mentionnées dans les sections suivantes sont des fonctionnalités en préversion et peuvent ne pas convenir à votre charge de travail.

Spécifier sur Azure

Conservez des contrats, des scénarios, des enveloppes d’exploitation et des configurations de réexécution dans votre référentiel Git existant, par exemple, Azure Repos ou GitHub. Suivez les responsabilités de révision partagée lorsqu’une modification affecte le comportement attendu. Faites appel à une revue d'ingénierie pour la maintenance technique.

Ancrer sur Azure

Connectez l'agent aux sources faisant autorité que vous avez identifiées pour la responsabilité Ancrer. Pour l'agent chargé de l'examen des produits, commencez par utiliser les API d'application existantes du site web pour récupérer les soumissions et la stratégie actuellement approuvée.

Si vous avez besoin d'effectuer des recherches dans plusieurs sources de connaissances, envisagez la récupération agentique dans Recherche Azure AI. Cette fonctionnalité peut renvoyer du contenu d'ancrage, accompagné de références aux sources facultatives et d'un journal d'activité. Mesurez le coût et la latence de l’approche de récupération que vous sélectionnez.

Si vos données métier se trouvent déjà dans Microsoft Fabric, l’outil Fabric IQ peut connecter les agents Microsoft Foundry aux modèles sémantiques et aux éléments d’ontologie. L'intégration et la fonctionnalité d'ontologie sont en version préliminaire. Vérifiez comment la connexion s’authentifie, les données auxquelles elle peut accéder et si les données peuvent quitter le périmètre de conformité Azure.

Gérez les versions des définitions sémantiques séparément de celles de l'implémentation de l'agent, et consignez leurs versions avec les éléments de preuve des tests. l’intégration Git de Fabric prend en charge les éléments d’ontologie en préversion.

Contrôler et exécuter sur Azure

Vous pouvez exécuter des agents de prompt et des agents hébergés personnalisés sur Foundry Agent Service. Pour d’autres exigences de runtime ou de déploiement, envisagez AKS, Azure Container Apps ou Azure App Service. Consultez Choisir un service de calcul Azure pour comparer les options. Implémentez vos règles d’autorisation, d’approbation et d’exécution dans l’application et les services connectés.

Pour les agents Foundry, utilisez identités d’agent Microsoft Entra pour les connexions MCP et agent à agent prises en charge. Lorsque l’agent agit pour un utilisateur, vérifiez à la fois l’habilitation de l’utilisateur et l’habilitation de l’agent. Avant la mise en production, vérifiez l’identité et les autorisations que l’agent utilisera lors de l’exécution.

Gestion des API Azure peut régir les points de terminaison MCP partagés par le biais de stratégies d’authentification, de limites de débit et de quotas. Utilisez le middleware d'Agent Framework pour ajouter des vérifications gérées par l'application aux outils de fonction exécutés par le framework. Pour les outils qui s’exécutent en dehors de cette limite, appliquez l’autorisation et la politique obligatoires sur une passerelle ou un service en aval.

Lorsqu’une action a besoin d’une confirmation humaine, utilisez function-tool approval. Si les approbations de flux de travail doivent être conservées après un redémarrage, configurez un stockage persistant des points de contrôle et restaurez l'état d'approbation en attente avant d'autoriser l'exécution. Pour les outils qui changent d’état, validez les entrées et ajoutez des protections d’idempotency au niveau de l’exécuteur d’action. Gérez les versions de l'orchestration et des paramètres de contrôle avec celles de l'implémentation.

Prompt Shields dans Azure AI Sécurité du Contenu peuvent détecter les tentatives d’injection de prompts dans les prompts utilisateur et les documents d’ancrage. Combinez ces vérifications avec l'autorisation. Définissez dans le contrat de comportement la manière dont la charge de travail réagit au contenu bloqué, puis testez cette réaction.

Pour l’agent d’évaluation des produits, l’accès en lecture est accordé aux soumissions attribuées et à la politique actuelle. L’accès en écriture est limité aux opérations de modération qui approuvent une soumission ou l’acheminent pour révision humaine. Les vérifications de version de la soumission et de la politique sont appliquées dans le flux de travail de publication.

Vérifier sur Azure

Vous pouvez stocker des cas de replay préparés et des résultats de test dans Stockage Blob Azure. Référencez des versions de jeu de données spécifiques dans vos configurations de rejeu et liez des cas dérivés de production à leurs exécutions sources. Limitez l'accès aux cas de validation protégés et aux éléments de preuve de production conservés. Suivez les instructions d’architecture Stockage Blob pour l’accès basé sur l’identité, la protection des données et la rétention.

En utilisant des jeux de données d’évaluation Foundry, vous pouvez noter les réponses terminées ou envoyer des entrées à un agent pour générer et évaluer de nouvelles réponses. Pour un rejeu contrôlé, configurez les adaptateurs de dépendance avant d’appeler l’agent. Publiez des jeux de données en tant que copies d’exécution de votre bibliothèque de scénarios gouvernée et appliquez les mêmes restrictions d’accès de holdout.

Utilisez des vérifications déterministes pour les critères avec des valeurs ou des règles de référence explicites et utilisez des évaluateurs basés sur des modèles pour les critères basés sur les jugements. Les évaluateurs personnalisés de Foundry prennent en charge les deux approches, ainsi que les points de terminaison de scoring externes.

Pour l’agent de révision de produit, une vérification basée sur le code peut comparer la décision structurée avec la décision attendue de l’équipe de normes. Un évaluateur basé sur un modèle peut évaluer si l’explication et la règle de politique citée appuient cette décision, en fonction du texte soumis. Les évaluateurs à base de critères et les évaluateurs personnalisés sont en version préliminaire.

Vérifiez la compatibilité des outils d'évaluation avant d'utiliser les scores dans un mécanisme de contrôle. Pour les conversations contenant Recherche Azure AI ou des appels à l’agent de données Fabric, n’utilisez pas les résultats tool_call_accuracy, tool_input_accuracy, tool_call_success, tool_output_utilization ou groundedness. Utilisez des assertions de contrat déterministes ou une autre méthode d’évaluation prise en charge.

Enregistrez les résultats et traces par cas avec la configuration qui les a produites. Appliquez des seuils de mise en production dans le pipeline et bloquez la mise en production si un scénario requis échoue. Utilisez les mêmes cas de test et les mêmes versions de l’évaluateur lors de la comparaison des implémentations. Si vous entraînez des modèles personnalisés dans Azure Machine Learning, incluez leurs versions dans la configuration.

Observer sur Azure

Le suivi de Foundry utilise la ressource Azure Monitor Application Insights connectée au projet. Instrumentez le code de votre application consacré aux outils et à la récupération afin de capturer tout élément de preuve supplémentaire dont vous avez besoin.

Déterminez le contenu que vous devez enregistrer. L’intégration du suivi côté client Foundry inclut les paramètres d’enregistrement du contenu du message. Vérifiez que votre instrumentation capture les réponses de l’outil requises et le contenu récupéré en même temps que les noms des opérations et les minutages. Réduisez au minimum les charges utiles sensibles ou masquez-en les données avant l'exportation des données de télémétrie, et ne conservez que les éléments de preuve autorisés par votre stratégie en matière de données.

Envisagez d'utiliser l'évaluation des traces (version préliminaire) pour évaluer les traces conservées dans Application Insights qui répondent aux exigences de nettoyage des données. Cette fonctionnalité attribue des scores aux interactions existantes sans relancer les requêtes. Elle prend notamment en charge les traces OpenTelemetry provenant d'agents exécutés en dehors de Foundry. Utilisez ces scores pour examiner le comportement en production, puis vérifiez toute modification de l'implémentation qui en découle au moyen du rejeu et de l'évaluation avant la mise en production. Cette fonctionnalité est en préversion publique, n’a pas de contrat de niveau de service et n’est pas recommandée pour les charges de travail de production. Ne vous fiez pas à celui-ci pour la surveillance de la production ou les décisions de mise en production.

Utilisez les requêtes Log Analytics et les alertes Azure Monitor pour examiner les défaillances comportementales et les dépassements des limites de fonctionnement. L’affichage des détails de l’Agent Application Insights, actuellement en préversion, peut vous aider à examiner les exécutions individuelles. Intégrez les résultats examinés et les cas préparés au cycle suivant de modification et de rejeu.

Contributors

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

Auteurs principaux :

• Yang Song | Ingénieur logiciel principal

Autres contributeurs :

• Chad Kittel | Ingénieur logiciel principal
• Bryan Ostdiek | Scientifique des données principal
• Peter Parker | Ingénieur solutions principal, stratège et architecte cloud IA Azure
• Rama Pyarasani | Responsable des ingénieurs de déploiement multidisciplinaires
• Ronnie Yates | Directeur général de l'ingénierie de déploiement (Forward Deployed Engineering)

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

Étapes suivantes

• Agents dans Microsoft Foundry
• Évaluer vos agents IA
• Recherche agentique dans Recherche Azure AI
• Surveiller les agents IA avec Application Insights
• Contrats comportementaux des agents (document de recherche)

Ressources associées

• Modèles de conception d’agent IA
• Génération augmentée par récupération agentique
• Opérations d'apprentissage automatique