Testowanie agentów konwersacyjnych za pomocą Direct Line

Direct Line API pełni funkcję interfejsu komunikacyjnego, umożliwiając aplikacjom klienckim interakcję z agentami konwersacyjnymi zbudowanymi w Copilot Studio. Interfejs API Direct Line ułatwia przesyłanie wiadomości między aplikacją kliencką a agentem za pośrednictwem strumieni WebSocket lub żądań HTTP. W testach wydajności Direct Line umożliwia narzędziom do testów obciążeniowych symulowanie rzeczywistych zachowań użytkowników, generowanie obciążenia i mierzenie czasów odpowiedzi.

Komunikuj się z Direct Line przy użyciu protokołu WebSocket

Agentów konwersacyjnych utworzonych za pomocą programu Copilot Studio można wdrożyć w aplikacjach internetowych jako osadzone iframes lub przy użyciu niestandardowej kanwy. Obie opcje wdrożenia wykorzystują komunikację WebSocket z Direct Line. Jeśli wdrożysz swojego agenta konwersacyjnego do aplikacji za pomocą jednej z tych metod, skrypt testów wydajności powinien wykorzystywać komunikację za pomocą protokołu WebSocket, aby generować obciążenie imitujące rzeczywiste zachowanie użytkownika i mierzyć wydajność z dużą dokładnością.

Aplikacje klienckie korzystające z Direct Line i komunikacji WebSocket powinny postępować według następującego schematu:

1. Aby rozpocząć rozmowę, aplikacja kliencka musi najpierw uzyskać token rozmowy. Jeśli agent jest skonfigurowany przy użyciu klucza tajnego Direct Line, uzyskaj token, wywołując regionalny punkt końcowy Direct Line. Tokeny dla agentów niekorzystających z sekretów można uzyskać z punktu końcowego tokena.
2. Aplikacja kliencka rozpoczyna rozmowę za pomocą tokena i otrzymuje identyfikator rozmowy oraz URL strumienia WebSocket.
3. Wiadomości użytkownika są wysyłane przez żądanie HTTP POST zawierające identyfikator rozmowy.
4. Wiadomości od agenta konwersacyjnego są odbierane za pośrednictwem strumienia WebSocket.

Komunikuj się z Direct Line przy użyciu HTTP GET

Jeśli Twoje narzędzie do testów obciążeniowych nie może korzystać z komunikacji WebSocket lub jeśli Twoja aplikacja kliencka nie używa komunikacji WebSocket, możesz otrzymywać aktywności, wysyłając żądanie HTTP GET zamiast tego. Jak pokazano na poniższym diagramie, proces inicjacji rozmowy się nie zmienia.

Mierz czas odpowiedzi

Aby ocenić wpływ obciążenia na środowisko użytkownika, upewnij się, że Twoje skrypty testów wydajności mierzą i raportują czas odpowiedzi dla następujących kroków:

Monitorowanie czasu odpowiedzi dla Generate Token, Start Conversation i Send Activity jest proste dla narzędzi do testowania obciążenia, ponieważ te czynności wykorzystują standardowe żądania HTTP. Jednak mierzenie czasu odpowiedzi agenta na wiadomości użytkownika jest bardziej skomplikowane z poniższych powodów:

• Wysyłanie i odbieranie aktywności za pośrednictwem Direct Line odbywa się asynchronicznie. Gdy wiadomość użytkownika jest wysyłana poprzez żądanie Send Activity, odpowiedź nie stanowi wiadomości od agenta. potwierdza jedynie, że wiadomość użytkownika została pomyślnie wysłana.

• W zależności od projektu, agent konwersacyjny może wysłać dowolną liczbę wiadomości w odpowiedzi na wiadomość użytkownika. Dlatego w większości przypadków należy mierzyć czas potrzebny agentowi na odpowiedź jako czas między wiadomością użytkownika a ostatnią wiadomością agenta. W poniższym przykładzie pojedyncza wiadomość użytkownika wyzwala trzy wiadomości agenta, pomiędzy którymi wykonywane są wywołania API. Każda wiadomość wraca po około dwóch sekundach; jednak z perspektywy użytkownika agent potrzebuje sześciu sekund, aby odpowiedzieć na jego żądanie.

  

Zidentyfikuj ostatnią odpowiedź agenta

Aby zmierzyć czas, jaki agent potrzebuje na udzielenie pełnych odpowiedzi, Twój skrypt do testów wydajności musi:

• Zidentyfikuj ostatnią wiadomość agenta, która następuje po wiadomości użytkownika
• Oblicz różnicę czasu między nimi

Protokół podstawowy używany przez Copilot Studio nie zawiera pojęcia „ostatniej odpowiedzi”, ponieważ zarówno agenci, jak i użytkownicy mogą wysyłać wiadomości w dowolnym momencie. Dlatego Twój skrypt do testów wydajności musi zakładać, że jeśli agent nie wyśle wiadomości w określonym czasie, nie będą wysyłane kolejne wiadomości aż do wysłania kolejnej wiadomości użytkownika. Implementacja tej logiki różni się w zależności od tego, jak twój skrypt komunikuje się z Direct Line.

Korzystanie z elementów WebSocket

Podczas komunikacji z Direct Line za pośrednictwem WebSocket, załóżmy, że agent nie wysyła więcej komunikatów, gdy nie można odczytać więcej ramek z WebSocket. Możesz zauważyć to jako miniony czas podczas próby odczytania kolejnej klatki, choć dokładne zachowanie zależy od implementacji. W przypadku implementacji referencyjnej wykorzystującej WebSockets rozważ użycie HTTP GET.

Użyj metody HTTP GET

Skrypty testujące wydajność wykorzystujące HTTP GET zamiast WebSockets powinny przepytywać punkt końcowy Aktywności, aby uzyskać cały zestaw komunikatów użytkownika i agenta. Podczas sondowania upewnij się, że zapewniasz agentowi wystarczająco dużo czasu na odpowiedź. Na przykład, jeśli agent musi wywołać interfejs API zaplecza, aby odpowiedzieć na zapytanie użytkownika, a interfejs API potrzebuje do pięciu sekund na odpowiedź, skrypt nie powinien odpytywać punktu końcowego aktywności, dopóki nie minie pięć sekund.

Poniższy uproszczony pakiet zbiorczy reprezentuje odpowiedź wracającą z punktu końcowego aktywności:

[
  {
    "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"
  }
]

Podczas analizowania obciążenia i obliczania czasów odpowiedzi, weź pod uwagę następujące wytyczne:

• Wiadomości od agenta mają właściwość role: bot, podczas gdy wiadomości od użytkownika nie posiadają właściwości role.
• Wiadomości agenta wysyłane w odpowiedzi na wiadomości użytkownika mają właściwość replyToId, której wartość pochodzi z właściwości id wiadomości użytkownika.
• Można obliczyć czas odpowiedzi agenta jako różnicę czasu między wiadomością użytkownika a ostatnią wiadomością agenta odpowiadającą na tę wiadomość użytkownika.

Informacje pokrewne

• Zaplanuj przepustowość i limity żądań
• Planowanie i tworzenie testu wydajności agenta konwersacyjnego