Planlæg og lav en konversationsagent præstationstest

Samtaleagenter, der er bygget med Copilot Studio, kører på en platform, der automatisk skaleres for at understøtte stigninger i efterspørgsel og belastning. Dog bruger samtaleagenter ofte brugerdefineret logik eller kald til backend-API'er, hvilket introducerer latenstid, fordi den tilpassede logik er ineffektiv, eller fordi de underliggende API'er og backend-systemer ikke skalerer godt.

Ydelsestest vurderer en agents ydeevne og stabilitet under varierende belastningsmønstre. Den identificerer potentielle problemer, efterhånden som brugerbasen vokser, og sikrer, at agenten forbliver funktionel og responsiv. Hvis du ikke tester din samtaleagent under belastning, kan den fungere godt under udvikling og test, men fejle under reel brugertrafik.

Før du tager fat på de tekniske aspekter af performancetest, skal du definere acceptkriterier, der fanger den ønskede brugeroplevelse, og identificere samtalebrugsscenarier, der genererer forskellige belastningsmønstre. Denne artikel dækker kort planlægningsfasen af performance-testning og giver vejledning om de tekniske detaljer i at generere belastning for dine samtaleagenter.

Planlæg din præstationstest

En performance test-plan bør have et defineret mål og specifikke acceptkriterier. For eksempel måler nogle tests et systems ydeevne under standardbelastning, mens andre tests genererer mere ekstreme belastninger, der bevidst får systemet til at blive ikke-responsivt. Når du måler ydeevnen for samtaleagenter, der er bygget med Copilot Studio, skal du designe test for enten at måle agentens baselineydeevne eller den forventede tunge belastning, men ikke konfigurere test til at generere overdreven stress.

Forstå brugeradfærd

Start din testplan med at analysere, hvordan brugerne forventes at opføre sig på tværs af forskellige samtale-anvendelsestilfælde. Fra et load testing-perspektiv kan brugeradfærd variere mellem brugsscenarier med hensyn til, hvad brugerne siger eller spørger om (for eksempel "Jeg vil booke en flyrejse" eller "Hvad er jeres returpolitik?"), antallet af brugere, der driver en bestemt anvendelsessituation, og brugernes engagementsmønstre (for eksempel brugere, der forbinder alle på én gang ved middagstid versus en gradvis opbygning i løbet af dagen).

Følgende tabel beskriver den forventede brugeradfærd for en banksamtaleagent.

Opret en testplan

Når du har defineret brugeradfærden ud fra brugssituationer og engagementmønstre, så tænk over detaljerne i din performancetestplan. Som minimum bør en performancetestplan for en samtaleagent specificere et mål, testscenarier, nøgleindikatorer, detaljerede testdata og succeskriterier.

Hvis dit team allerede har defineret samtalescenarier til evalueringer enten via oprettelse af testcases i produktet eller ved hjælp af Copilot Studio Kit, kan du genbruge disse scenarier for at begynde at oprette din testplan.

Følgende eksempeltestplan er for en banksamtaleagent. Planen bruger de tidligere identificerede samtalebrugsscenarier til at definere et baseline testscenarie og et load testing-scenarie. Test af baseline vurderer normal ydeevne og identificerer problemer under almindelig brug, mens mere belastning kan afsløre, hvordan systemet håndterer spidsbelastning af brugeraktivitet.

Arbejd sammen med tekniske og forretningsmæssige interessenter for at udvikle en testplan, der passer til din organisations behov. Enig i de vigtigste parametre, der er skitseret i eksemplet. Lær om at bruge værktøjer som Apache JMeter til at oprette testscripts i Performance-testreferenceeksempler og retningslinjer.

Simulér flere dialogrunder

Testdataene, der er angivet i planen, indebærer, at den planlagte performance-test driver samtaler over flere ture. Samtaler med flere ture er serier af frem og tilbage beskeder, der sendes mellem de simulerede brugere og samtaleagenten. Ydelsestests bør drive samtaler over flere dialogomgange, for at sikre, at den genererede belastning ligner reel brugeradfærd. Desuden aktiveres nogle langvarige handlinger eller API-kald kun, når brugere træffer en bestemt række valg eller sender et bestemt mønster af beskeder i en samtale.

I det følgende eksempel kalder bankens backend-API kun, efter at brugeren har valgt opsparingskonto. Svartiden for den første besked er kortere end et sekund, fordi kun agentens intensionsgenkendelsesmotor er involveret. Den sidste besked venter på svar fra et backend API, hvilket medfører ekstra forsinkelse. Uden at simulere en samtale med flere omgange ville der ikke være opstået nogen ydelsesproblemer.

At simulere samtaler med flere ture kræver planlægning både når du forbereder testdata og bygger testscripts. Inkluder en række brugerudtalelser i dine testdata, der fremkalder komplette samtaleflows, som vist i eksemplet. Sørg for, at dine testscripts sender flere ytringer i en enkelt samtale.

Relaterede oplysninger

• Design og operationaliser agentevaluering
• Arkitektagentløsninger: Evalueringsrammer
• Arkitektagentløsninger: Almindelige evalueringsrammer