Test samtaleagenter med Direct Line

Direct Line API'en fungerer som en kommunikationsgrænseflade for klientprogrammer, så de kan interagere med agenter, der er lavet med Copilot Studio. Direct Line API'et gør det muligt at overføre beskeder mellem klientprogrammet og agenten via WebSocket-streams eller HTTP-anmodninger. Ved ydeevnetest gør Direct Line det muligt for belastningstestværktøjer at simulere faktisk brugeradfærd, generere belastning og måle svartider.

Kommunikér med Direct Line via WebSockets

Du kan udrulle samtaleagenter, der er bygget med Copilot Studio, i webprogrammer som enten integrerede iframes eller ved hjælp af et brugerdefineret lærred. Begge implementeringsmuligheder bruger WebSocket-kommunikation med Direct Line. Hvis du udruller din samtaleagent til en app ved at bruge en af disse metoder, bør dit ydeevnetest-script bruge WebSocket-kommunikation til at generere belastning, der ligner reel brugeradfærd, og måle ydeevnen med stor sikkerhed.

Klientprogrammer, der bruger Direct Line og WebSocket-kommunikation, bør følge dette forløb:

  1. For at initiere en samtale skal programmet først anskaffe en samtale-token. Hvis din agent er konfigureret med en Direct Line-hemmelighed, skal du hente et token ved at kalde det regionale Direct Line-slutpunkt. Tokens til agenter, der ikke bruger hemmeligheder, kan hentes fra token-slutpunktet.
  2. Klientprogrammet starter en samtale ved at bruge tokenet og modtager et Samtale-ID og en WebSocket-stream-URL.
  3. Brugerbeskeder sendes ved at sende en HTTP POST-anmodning med Samtale-id.
  4. Beskeder fra agenten modtages via en WebSocket-stream.

Skærmbillede, der viser Direct Line-kommunikations forløb via WebSockets.

Kommuniker med Direct Line via HTTP GET

Hvis dit værktøj til belastningstest ikke kan bruge WebSocket-kommunikation, eller hvis dit klientbaserede program ikke bruger WebSocket-kommunikation, kan du modtage aktiviteter ved at sende HTTP GET i stedet. Som vist i det følgende diagram ændrer samtalestart-flowet sig ikke.

Skærmbillede, der viser Direct Line-kommunikationens flow via HTTP GET.

Mål svartider

For at vurdere, hvordan belastning påvirker brugeroplevelsen, skal du sikre, at dine scripts til test af ydeevne måler og rapporterer svartider for følgende trin:

Trin Betydning for brugeroplevelse
Generér token Den tid, det tager at starte en ny samtale
Start samtale Den tid, det tager at starte en ny samtale
Send aktivitet Tiden det tager at sende en ny brugerbesked (inkluderer ikke agentens svar)
Modtag aktiviteter/hent aktiviteter Den tid, det tager for en agent at svare

Sporing af svartider for Generér Token, Start Samtale og Send Aktivitet er ligetil for værktøjer til test af belastning, da disse trin bruger almindelige HTTP-forespørgsler. Det er dog mere komplekst at måle den tid, det tager en agent at svare på brugerbeskeder, af følgende årsager:

  • Afsendelse og modtagelse af aktiviteter via Direct Line følger et asynkront mønster. Når en brugerbesked sendes ved hjælp af en Send aktivitet-anmodning, er svaret ikke en besked fra agenten. I stedet bekræfter den bare, at brugermeddelelsen er sendt.

  • Baseret på sit design kan en samtaleagent sende et vilkårligt antal beskeder tilbage som svar på en brugerbesked. Derfor bør du i de fleste tilfælde måle den tid, det tager en agent at svare, som den tid, der går mellem en brugerbesked og den sidste agentbesked. I det følgende eksempel udløser en enkelt brugerbesked tre agentbeskeder, hvor der udføres API-kald imellem. Hver besked tager cirka to sekunder at blive modtaget; men fra brugerens perspektiv tager det agenten seks sekunder at svare på brugerens anmodning.

    Skærmbillede, der viser svartiden mellem beskederne.

Identificer agentens sidste svar

For at måle den tid, det tager en agent at færdiggøre sine svar, skal dit script til test af ydeevne gøre følgende:

  • Identificere den sidste agentbesked, der følger efter en brugerbesked
  • Beregne tidsforskellen mellem de to

Den underliggende protokol, som Copilot Studio bruger, har ikke noget begreb om et "sidste svar", da både agenter og brugere kan sende beskeder til enhver tid. Derfor skal dit script til test af ydeevne antage, at hvis agenten ikke sender en besked inden for en given tidsramme, så sendes der ikke flere beskeder, før næste brugerbesked er sendt. Implementeringen af denne logik varierer afhængigt af, hvordan dit script kommunikerer med Direct Line.

Brug WebSockets

Når du kommunikerer med Direct Line over WebSockets, skal du antage, at agenten ikke sender flere beskeder, når der ikke kan læses flere billeder fra WebSocket. Det kan vise sig som en timeout, når du forsøger at læse det næste billede, men den præcise adfærd afhænger af din implementering. For en referenceimplementering, der bruger WebSockets, kan du overveje at bruge HTTP GET.

Brug HTTP GET

Scripts til test af ydeevne, der bruger HTTP GET i stedet for WebSockets, bør forespørge slutpunktet Aktiviteter for at hente alle bruger- og agentbeskeder. Ved forespørgsel skal du sikre, at der gives tilstrækkelig tid til, at agenten kan svare. Hvis din agent f.eks. skal kalde et backend-API for at svare på en brugerforespørgsel, og API'et er op til fem sekunder om at svare, bør dit script ikke forespørge slutpunktet Aktiviteter, før der er gået fem sekunder.

Følgende forenklede nyttedata repræsenterer svaret, der kommer tilbage fra slutpunktet Aktiviteter:

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

Når du analyserer nyttedata og beregner svartider, skal du overveje følgende retningslinjer:

  • Beskeder fra agenten har egenskaben role: bot, mens beskeder fra brugeren ikke har nogen role-egenskab.
  • Agentbeskeder, der sendes som svar på brugerbeskeder, har egenskaben replyToId, hvis værdi svarer til egenskaben id for brugerbeskeden.
  • Du kan beregne agentens svartider som tidsforskellen mellem brugerbeskeden og den sidste agentbesked, der svarer på brugerbeskeden.