Tester les agents conversationnels en utilisant Direct Line

L’API Direct Line agit comme une interface de communication permettant aux applications clientes d’interagir avec des agents conversationnels construits avec Copilot Studio. L’API Direct Line facilite la transmission des messages entre l’application cliente et l’agent via des flux WebSocket ou des requêtes HTTP. Pour les tests de performance, Direct Line permet aux outils de test de charge de reproduire le comportement réel de l’utilisateur, de générer de la charge et de mesurer les temps de réponse.

Communiquer avec la ligne directe à l’aide de WebSockets

Les agents conversationnels construits avec Copilot Studio sont déployés dans des applications web soit sous forme d’iframes intégrés, soit en utilisant un canevas personnalisé. Les deux options de déploiement utilisent la communication WebSocket avec Direct Line. Si votre agent conversationnel est déployé sur une application en utilisant l’une de ces méthodes, votre script de test de performance doit utiliser la communication WebSocket pour générer une charge ressemblant au comportement réel de l’utilisateur et mesurer la performance avec un haut degré de confiance.

Les applications clientes utilisant la communication Direct Line et WebSocket doivent suivre ce processus :

1. Pour initier une conversation, une application cliente doit d’abord obtenir un jeton de conversation. Si votre agent est configuré avec un secret Direct Line, obtenez un jeton en appelant le point de terminaison régional Direct Line. Les jetons pour les agents n’utilisant pas de secrets peuvent être obtenus à partir du point d’arrivée du jeton.
2. L’application cliente lance une conversation en utilisant le jeton, et reçoit un identifiant de conversation ainsi qu’une URL de flux WebSocket.
3. Les messages utilisateur sont envoyés en envoyant une requête HTTP POST avec l’identifiant de conversation.
4. Les messages de l’agent conversationnel sont reçus via le flux WebSocket.

Communiquer avec Direct Line en utilisant HTTP GET

Si votre outil de test de charge ne peut pas utiliser la communication WebSocket, ou si votre application orientée client n’utilise pas la communication WebSocket, vous pouvez recevoir des activités en envoyant plutôt HTTP GET. Comme montré dans le schéma suivant, le flux d’initiation de conversation ne change pas.

Mesure des temps de réponse

Pour évaluer comment la charge affecte l’expérience utilisateur, assurez-vous que les scripts de test de performance suivent et rapportent le temps de réponse pour les étapes suivantes :

Le suivi des temps de réponse pour Générer un jeton, lancer une conversation et envoyer une activité est simple pour les outils de test de charge, car ces étapes utilisent des requêtes HTTP standard. Cependant, mesurer le temps nécessaire à un agent pour répondre aux messages de l’utilisateur est plus complexe, pour les raisons suivantes :

• Les activités d’envoi et de réception via Direct Line suivent un schéma asynchrone. Lorsqu’un message utilisateur est envoyé via une requête d’Activité d’Envoi, la réponse n’est pas un message de l’agent. Au contraire, cela confirme simplement que le message utilisateur a été publié avec succès.

• D’après sa conception, un agent conversationnel peut envoyer n’importe quel nombre de messages en réponse à un message utilisateur. Par conséquent, dans la plupart des cas, vous devriez mesurer le temps nécessaire à un agent pour répondre comme le temps qui s’écoule entre un message utilisateur et le dernier message d’agent. Dans l’exemple suivant, un seul message utilisateur déclenche trois messages agents, avec des appels API intermédiaires. Chaque message met environ deux secondes à revenir ; cependant, du point de vue de l’utilisateur, il faut six secondes à l’agent pour répondre à sa demande.

  

Identifiez la dernière réponse de l’agent

Pour mesurer le temps qu’il faut à un agent pour terminer ses réponses, votre script de test de performance doit :

• Identifier le dernier message agent qui suit un message utilisateur
• Calculez la différence de temps entre les deux

Le protocole sous-jacent utilisé par Copilot Studio n’a pas de concept de « dernière réponse », car les agents et les utilisateurs peuvent envoyer des messages à tout moment. Par conséquent, votre script de test de performance doit supposer que si l’agent n’envoie pas de message dans un délai donné, aucun autre message ne sera envoyé avant que le message utilisateur suivant ne soit envoyé. L’implémentation de cette logique varie selon la façon dont votre script communique avec Direct Line.

Utilisez WebSockets

Lors de la communication avec Direct Line via WebSockets, supposons que l’agent n’envoie plus aucun message lorsque plus aucune trame ne peut être lue depuis le WebSocket. Vous pouvez voir cela indiqué par un délai d’attente lors de la lecture de la trame suivante, bien que le comportement exact dépende de votre implémentation. Pour une implémentation de référence utilisant WebSockets, envisagez d’utiliser HTTP GET.

Utilisez HTTP GET

Les scripts de test de performance utilisant HTTP GET au lieu de WebSockets devraient interroger le point de terminaison Activités pour obtenir l’ensemble complet des messages utilisateur et agent. Lors du sondage, veillez à laisser suffisamment de temps à votre agent pour répondre. Par exemple, si votre agent doit appeler une API backend pour répondre à une requête utilisateur, et que l’API met jusqu’à 5 secondes à répondre, votre script ne devrait pas interroger le terminau Activités avant que 5 secondes ne se soient écoulées.

La charge utile simplifiée suivante représente la réponse provenant du point de terminaison Activités :

[
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000012",
    "timestamp": "2025-01-07T09:12:22.0329242Z",
    "from": {
      "id": "a688eb7d-092a-42a8-8ef5-73123b9c2aaa",
      "name": ""
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "I also want to set up a new account",
  },
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000017",
    "timestamp": "2025-01-07T09:12:24.5478686Z",
    "from": {
      "id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
      "name": "Load Testing",
      "role": "bot"
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "Sure, please bear with me as I set up your new account",
    "replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012",
  },
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000018",
    "timestamp": "2025-01-07T09:12:33.1960413Z",
    "from": {
      "id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
      "name": "Load Testing",
      "role": "bot"
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "Almost done! Thank you for your patience",
    "replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012",
  },
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000019",
    "timestamp": "2025-01-07T09:12:41.9166159Z",
    "from": {
      "id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
      "name": "Load Testing",
      "role": "bot"
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "All done! Your new account is now active.",
    "inputHint": "acceptingInput",
    "replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012"
  }
]

Lorsque vous analysez la charge utile et calculez les temps de réponse, considérez les directives suivantes :

• Les messages de l’agent ont la propriété role: bot, tandis que les messages de l’utilisateur n’ont aucune role propriété.
• Les messages d’agent envoyés en réponse aux messages utilisateur ont la propriété replyToId, qui a une valeur équivalente à id la propriété du message utilisateur.
• Vous pouvez calculer les temps de réponse de l’agent comme la différence de temps entre le message utilisateur et le dernier message agent qui répond au message utilisateur.