Exécutez et validez une migration de modèle IA pour les agents Copilot Studio

Les sections suivantes s’appliquent à chaque changement de modèle, qu’il s’agisse d’une mise à niveau proactive ou d’une réponse à un départ à la retraite. Définir d’abord les portes, capturer une base à partir du modèle actuel, puis parcourir les phases.

Définir les portes d’acceptation de la migration

Définir les critères d’acceptation avant d’évaluer le modèle candidat, afin que l’évaluation de l’agent produise une décision au lieu d’un seul ensemble de scores. Incluez ce qui suit :

  • Taux minimum global de réussite
  • Taux de réussite requis pour les scénarios critiques pour l’entreprise
  • Défaillances critiques qui bloquent la migration quel que soit le score agrégé
  • Latence autorisée et variation de fiabilité
  • Sécurité, conformité et approbation régionale
  • Consommation acceptable ou impact sur les coûts
  • Approbation obligatoire du propriétaire et de l’approbateur de libération

Comparez le modèle actuel et le modèle candidat en utilisant la même configuration d’agent, les mêmes données de test, l’ensemble de test, les profils utilisateurs et les hypothèses de l’environnement. Étudiez les régressions individuelles au lieu de vous fier uniquement à un score moyen.

Les résultats des modèles sont probabilistes. Exécutez plusieurs scénarios importants lorsque la variabilité peut influencer la décision.

Établir une base d’évaluation réutilisable

Avant de changer le modèle, créez un ensemble de tests qui représente les scénarios critiques pour l’entreprise et les scénarios à haute fréquence de l’agent. Exécutez l’ensemble de tests avec le modèle de production actuel pour établir une base.

Utilisez à la fois le chat test et l’évaluation des agents :

Les méthodes de test disponibles dépendent de l’ensemble de l’agent, donc vérifiez-les avant de concevoir l’ensemble de test. En savoir plus dans Confirmez quelles méthodes de test votre agent soutient.

Évaluer le comportement complet de l’agent

N’approuvez pas un modèle de remplacement simplement parce que son taux de réussite global est similaire à celui du modèle actuel.

Couvrir les zones suivantes. Chacun est un comportement qui change souvent lorsque le modèle change, donc un ensemble de tests qui omet une zone ne peut pas détecter de régression.

Zone d’évaluation Ce qu’un changement de modèle peut briser Comment vérifier
Qualité des réponses Pertinence, complétude, exactitude, clarté et cohérence sur les questions que l’agent reçoit le plus souvent. Qualité générale
Ancrage et connaissance Le modèle répond à partir des données d’entraînement au lieu de la source de connaissances configurée, supprime les citations ou gère différemment les sources incomplètes ou contradictoires. Qualité générale
Abstention Le modèle répond à une question hors champ de jeu au lieu de refuser ou d’escalader. Qualité générale, ou personnalisé avec des labels Répondu et Refusé
Instructions suivantes Les instructions suivies de manière fiable par le modèle sont ignorées, telles que les règles d’escalade, les limites, les comportements interdits ou une clause de non-responsabilité obligatoire. Correspondance de mots-clés sur les phrases requises, ou Personnalisé avec des libelles spécifiques à chaque instruction
Valeurs fixes et format de sortie Une valeur précise telle qu’un numéro de téléphone, un code ou un identifiant est paraphrasée ou inventée, ou la forme de la sortie change et casse un analyseur ou une intégration de canal en aval. Correspondance exacte, ou correspondance mot-clé dans le format requis
Sélection et retenue des outils Le modèle sélectionne un outil différent, n’appelle aucun, ou appelle un outil lorsqu’aucun outil n’est nécessaire. Utilisation de l’outil avec les outils ou sujets attendus définis, plus une révision de la carte d’activité
Entrées d’outils et séquençage Les paramètres sont extraits, formatés ou par défaut différemment, ou les étapes d’une tâche multitool sont réorganisées, fusionnées ou supprimées. Utilisation des outils avec tous les outils attendus, plus la qualité générale
Confirmation et gestion des pannes Le modèle cesse de demander une confirmation avant qu’une action conséquente ne soit révélée, ou une erreur d’outil est manifestée différemment au lieu d’être rapportée. Personnalisé avec des labels de confirmation, plus une correspondance de mots-clés sur la langue d’erreur attendue
Comportement multi-tours Le contexte des tours précédents est perdu ou réinterprété, ou les clarifications, changements de sujet et récupération sont gérés différemment. Qualité générale sur un ensemble de tests de conversation
Entrée désordonnée et conflictuelle Une gestion plus faible des fautes de frappe, des fragments et de l’intention floue, ou une réponse différente aux tentatives d’injection prompte et de dérogation de rôle. Qualité générale, plus des étiquettes Custom avec Refus et Conformes
Sécurité et conformité Gestion des contenus nuisibles, accès aux données, permissions, traitement régional et exigences d’IA responsable. Étiquettes personnalisées, accompagnées d’une revue responsable de l’IA
Latence et fiabilité Temps de réponse, délais d’attente, variabilité, échecs d’appels et reprises dans des conditions représentatives. Non rapporté par l’évaluation. Mesurez dans le chat de test et la surveillance de la production.
Consommation et coût Copilot : Consommation de crédit ou autres coûts liés au modèle pour des scénarios représentatifs. Non rapporté par l’évaluation. Mesurez les rapports de capacité et de consommation.
Langues et canaux Qualité et comportement à travers les langues prises en charge, les profils utilisateurs et les canaux de déploiement. Exécutez le jeu de tests pour chaque langue, profil utilisateur et canal qui compte

Prêtez une attention particulière au suivi des instructions et à la latence. Un modèle candidat peut améliorer la qualité des réponses mais introduire des réponses plus lentes, un comportement de sélection d’outil différent ou des échecs dans des instructions fiables avec le modèle précédent.

Confirmez quelles méthodes de test votre agent supporte

Les méthodes de test disponibles pour votre agent dépendent de son harnais.

Pour en savoir plus :

Construire et maintenir l’ensemble de tests

  • Couvrez d’abord les parcours heureux critiques pour l’entreprise et les requêtes à fort volume, puis les cas difficiles : cas limites, entrées adverses, requêtes à refuser ou escalader, défaillances d’outils, longues conversations et requêtes multilingues.
  • Partez du vrai trafic. Les thèmes analytiques et les conversations enregistrées produisent des cas de test plus représentatifs que ceux inventés.
  • Privilégiez la couverture plutôt que le vernissage. Un ensemble plus large de cas imparfaits présente plus de régressions qu’un petit ensemble de cas parfaitement formulés.
  • Notez d’abord le modèle actuel, puis le candidat. C’est la comparaison, et non le chiffre absolu, qui vous indique si la migration est sûre.
  • Gardez l’ensemble avec l’agent en contrôle de version, et relancez-le sans modification à chaque changement de modèle.
  • Divisez l’ensemble par zone à risque. Un ensemble de tests alimenté par le faisceau standard peut contenir jusqu’à 100 cas de test, donc utilisez des ensembles séparés pour la précision des connaissances, le comportement de l’outil et les scénarios sensibles à la sécurité.
  • Exportez les résultats. Les résultats d’évaluation sont conservés pendant 89 jours, donc exportez-les en CSV pour conserver un enregistrement des scores obtenus par chaque modèle au moment de la migration.
  • Convertir les incidents de production et les retours utilisateurs en nouveaux tests de régression.

En savoir plus sur la conception et l’opérationnalisation de l’évaluation des agents.

Note

L’évaluation de l’agent mesure la justesse et la performance, pas l’éthique de l’IA ou les problèmes de sécurité. Un agent peut réussir chaque cas test et quand même fournir une réponse inappropriée. Utilisez des avis responsables sur l’IA et des filtres de sécurité de contenu en parallèle de l’évaluation.

Automatisez les évaluations récurrentes

Copilot Studio supporte l’exécution d’évaluations via l’API Power Platform, afin que vous puissiez intégrer la validation des modèles dans les flux de travail de publication et les pipelines d’intégration continue. Pour un grand domaine d’agents, l’automatisation est ce qui rend les tests répétés à candidats durables plutôt que manuels. En savoir plus sur les évaluations d’Automate avec l’API Power Platform.

Mettre à jour les artefacts d’agent affectés par un changement de modèle

Un changement de modèle affecte rarement uniquement le cadre du modèle. Traduisez les conseils du fournisseur en artefacts d’agent que vous contrôlez, puis validez chaque changement par rapport à votre référence d’évaluation. Une correction qui n’est pas retestée est une supposition.

Artéfact Changement typique
Instructions de l’assistant Rendre explicites les attentes implicites, supprimer les solutions de contournement écrites pour le modèle précédent, réénoncer sans ambiguïté les limites et les règles d’escalade ainsi que les comportements interdits, résoudre les instructions contradictoires et calibrer l’action indépendante que l’agent doit entreprendre.
Instructions pour le sujet et le nœud Appliquez le même traitement au niveau du sujet et vérifiez que les nœuds de réponse générative se comportent toujours comme prévu.
Descriptions d’outils et d’actions Réécriture pour plus de clarté. Cette description est ce que le modèle lit pour décider s’il faut appeler un outil et quand ; les descriptions vagues provoquent à la fois des surappels et des sous-appels.
Descriptions des paramètres d’entrée et de sortie Resserrez le format, les unités, les exemples, ainsi que la sémantique obligatoire ou optionnelle afin que la génération des paramètres reste correcte.
Configuration de la source de connaissances Revérifiez la sélection de la source, le cadrage et les instructions de mise à la terre, et vérifiez le comportement de citation.
Instructions de mise en forme des réponses Reformulez explicitement la structure, la longueur, les avertissements et les valeurs exactes requises, car les modèles plus récents modifient la verbosité par défaut.
Confirmation et portes de sécurité Réaffirmer des exigences explicites de confirmation avant les actions conséquentes.
Consommateurs en aval Mettez à jour les flux Power Automate, les cartes adaptatives, les intégrations de canaux et tout analyseur qui lit la sortie de l’agent.
Le set de test lui-même Ajoutez les nouveaux schémas de défaillance découverts lors de la migration.

Phases de migration

Les phases suivantes mettent les sections précédentes dans l’ordre d’exécution. Utilisez-les comme plan de travail pour le changement de modèle d’un seul agent, que ce soit proactif ou motivé par une retraite.

Phase 0 : Préparation

  1. Confirmez que le modèle candidat est valide selon les prérequis : généralement disponible ou par défaut, disponible dans la région, posture cross-geo acceptable, activé par l’administrateur, et la bonne catégorie d’utilisation pour l’objectif de l’agent.
  2. Lisez les instructions de mise à jour du fournisseur de modèles et notez les instructions et les changements d’outils qu’il implique.
  3. Identifier les agents concernés à partir de l’inventaire, de l’environnement d’enregistrement, des propriétaires et de la criticité.
  4. Confirmez quelles méthodes d’essai d’évaluation supporte le harnais de l’agent.
  5. Définissez et approuvez les portes d’acceptation de la migration.

Phase 1 : Référence du modèle actuel

  1. Construisez ou rafraîchez l’ensemble de tests de régression afin qu’il couvre les scénarios critiques pour l’entreprise et les situations à haute fréquence.
  2. Exécutez l’ensemble de tests avec le modèle de production actuel pour établir la base. Faites cela tant que le modèle actuel est encore en place, car après que le modèle change, la base ne peut plus être reconstruite.
  3. Enregistrer la latence et la consommation de crédit Copilot séparément. Les évaluations ne les signalent pas.
  4. Exportez les résultats en CSV pour préserver l’enregistrement au-delà de la période de rétention.

Phase 2 : Évaluer le candidat dans un environnement hors production

  1. Préparez une copie non produite de l’agent, en suivant les directives du Copilot Studio pour la gestion du cycle de vie de l’application et les tests de l’agent. Configurez l’environnement pour qu’il représente la production :

    • Utilisez les mêmes instructions d’agent, sujets, configuration des connaissances, outils, flows, connecteurs, langages et hypothèses de sécurité.
    • Utilisez des identités et des connexions représentatives pour les tests.
    • Appliquez les mêmes politiques de données et les mêmes contrôles administratifs pertinents.
    • Confirmez la disponibilité régionale et si un mouvement de données entre les zones géographiques est nécessaire.
    • Notez toute différence entre le test et la production qui pourrait influencer le résultat.

  2. Changez de modèle. Allez sur la page Aperçu de l’agent et sélectionnez le modèle principal candidat dans la section Modèle . Des paramètres distincts existent pour le raisonnement profond, les réponses génératives et le créateur d’invites, donc vérifiez si l’agent utilise ces fonctionnalités et s’il faut aussi les changer.

  3. Relancez le même ensemble de tests, inchangé, contre le modèle candidat.

  4. Comparez les deux courses aux portes d’acceptation pour identifier les améliorations et les régressions.

  5. Inspectez l’orchestration de manière qualitative dans le chat de test, en utilisant la carte d’activité pour confirmer quels outils ont été sélectionnés, dans quel ordre et avec quels paramètres.

  6. Mesurez la latence et la consommation pour le candidat et comparez-les avec la référence initiale.

Phase 3 : Corriger

  1. Mettez à jour les artefacts de l’agent affectés par le changement de modèle, puis relancez l’ensemble de tests sur l’agent corrigé. En savoir plus sur Improve agents en utilisant un triage et une remédiation basés sur l’évaluation.
  2. Itérer jusqu’à ce que les limites d’acceptation soient remplies, ou conclure que le modèle candidat n’est pas adapté et documenter pourquoi. Décider de ne pas améliorer est un résultat légitime et fondé sur des preuves.

Phase 4 : Approbation et déploiement

  1. Obtenez l’approbation des portes d’acceptation par le propriétaire de l’agent et l’approbateur de libération, y compris l’approbation de sécurité et de conformité lorsque des modèles inter-géo ou externes sont impliqués.
  2. Déploiement via le processus ALM établi, en promouvant la solution du test à la production. Ne modifie pas manuellement l’agent de production.
  3. Organisez le déploiement lorsque le canal le permet. Publiez d’abord à un public pilote ou à une seule chaîne, observez le résultat, puis élargissez les résultats.

Phase 5 : Surveiller et fermer

  1. Surveillez le comportement de la production par rapport aux portes d’acceptation.
  2. Ajoutez les nouveaux schémas de défaillance découverts à l’ensemble de tests de régression.
  3. Fermez la migration seulement après que les critères d’acceptation soient satisfaits en production.
  4. Conserver les preuves d’évaluation et le dossier de décision de migration pour l’audit et pour le prochain événement du cycle de vie.

Important

Le chemin de retour en arrière pour un changement de modèle consiste à redéployer la version de la solution précédemment validée, ce qui est plus lent qu’un basculement de configuration. Cette différence rend la porte d’évaluation de la phase 2 si importante. Détecter une régression avant le déploiement coûte moins cher que d’en inverser une par la suite.

Surveiller après la migration

Le travail sur le cycle de vie du modèle se poursuit après le déploiement. Moniteur:

  • Résultats d’évaluation des agents et taux de réussite dans les scénarios critiques.
  • Analyses de production, transcriptions, activités, erreurs et retours utilisateurs.
  • Échecs dans le suivi des instructions et dans la sélection des outils.
  • Latence, délais d’attente et fiabilité.
  • La consommation change.
  • Questions de sécurité, de conformité et de traitement régional.

Lorsque la surveillance de production identifie un nouveau schéma de défaillance, ajoutez un cas représentatif à l’ensemble de tests de régression. Cette pratique améliore l’évaluation suivante du modèle et transforme l’apprentissage en production en une base de qualité durable.

La télémétrie au niveau environnemental émet OpenTelemetry GenAI s’étend aux Insights d’application, incluant le modèle utilisé pour chaque invocation d’agent. Utilisez-le pour confirmer sur quel trafic de production de modèles fonctionne réellement, et pour comparer la sélection et la fiabilité des outils avant et après une migration.

  • Last updated on