Kør effektiviteten med CI/CD bedste praksis på Amazon Lex

Lad os sige, at du har identificeret en use case i din organisation, som du gerne vil håndtere via en chatbot. Du har stiftet bekendtskab med Amazon Lex, byggede en prototype og lavede et par prøveinteraktioner med botten. Du kunne lide den overordnede oplevelse og ønsker nu at implementere botten i dit produktionsmiljø, men er ikke sikker på bedste praksis for Amazon Lex. I dette indlæg gennemgår vi den bedste praksis for udvikling og implementering af Amazon Lex-bots, så du kan strømline ende-til-ende bots livscyklus og optimere dine operationer.

Vi har tidligere dækket planlægnings-, design- og konfigurationsfaserne blogindlæg. Vi foreslår, at du gennemgår disse indlæg for at hjælpe dig med at opbygge engagerende samtaler med din bot, før du fortsætter. Når du først har konfigureret botten, bør du teste den internt og gentage bottendefinitionen. Du er nu klar til at implementere det i dit produktionsmiljø (såsom et callcenter), hvor botten behandler live-samtaler. Når den først er i produktion, bør du overvåge den løbende for at sikre, at den opfylder dine ønskede forretningsmål. Denne cyklus gentages, når du tilføjer nye use cases og forbedringer.

Lad os gennemgå den bedste praksis for udvikling, test, implementering og overvågning af bots.

Udvikling

Overvej følgende bedste praksis, når du udvikler din bot:

• Administrer bot-skema via kode – Amazon Lex-konsollen giver en brugervenlig grænseflade, når du designer og konfigurerer botten, men er afhængig af manuelle handlinger for at replikere opsætningen. Vi anbefaler at konvertere bot-skemaet til kode efter færdiggørelse af designet for at forenkle dette trin. Du kan bruge API'er or AWS CloudFormation (Se Oprettelse af Amazon Lex V2-ressourcer med AWS CloudFormation) for at administrere bot'en ​​programmatisk.
• Checkpoint bot-skema med botversionering – Checkpointing er en almindelig tilgang, der ofte bruges til at vende en applikation tilbage til en sidst kendte stabil tilstand. Amazon Lex tilbyder denne funktionalitet via bot versionering. Vi anbefaler at bruge en ny version ved hver milepæl i din udviklingsproces. Dette giver dig mulighed for at foretage trinvise ændringer af din botdefinition, med en nem måde at gendanne dem, hvis de ikke virker som forventet.
• Identificer datahåndteringskrav og konfigurer passende kontroller – Amazon Lex følger AWS model med fælles ansvar, som omfatter retningslinjer for databeskyttelse for at overholde brancheforskrifter og med din virksomheds egne databeskyttelsesstandarder. Derudover overholder Amazon Lex compliance-programmer såsom SOC, PCI og FedRAMP. Amazon Lex giver mulighed for at sløre slots, der anses for at være følsomme. Du bør identificere dine krav til databeskyttelse og konfigurere de relevante kontroller i din bot.

Test

Når du har en botdefinition, bør du teste botten for at sikre, at den fungerer efter hensigten og er konfigureret korrekt. For eksempel skal den have tilladelser til at udløse andre tjenester, som f.eks AWS Lambda funktioner. Derudover bør du også teste botten for at bekræfte, at den er i stand til at fortolke forskellige typer brugeranmodninger. Overvej følgende bedste praksis for test:

• Identificer testdata – Du bør indsamle relevante testdata for at teste bot-ydeevne. Testdataene bør omfatte en omfattende repræsentation af forventede brugersamtaler med botten, især for IVR-brugstilfælde, hvor botten skal forstå stemmeinput. Testdataene bør dække forskellige talestile og accenter. Sådanne testdata kan give oplevelsesvalidering for din målkundebase.
• Identificer brugeroplevelsesmetrics – Det kan være svært at definere samtaleoplevelsen. Du er nødt til at forudse og planlægge alle de forskellige måder, brugere kan interagere med botten på. Hvordan guider du den, der ringer op uden at lyde for præskriptiv? Hvordan genopretter du, hvis den, der ringer op, giver forkerte eller ufuldstændige oplysninger? For at styre dialogen gennem mange forskellige scenarier bør du sætte et klart mål, der dækker forskellige talestile, akustiske forhold og modalitet, og identificere objektive målinger, som du kan spore. For eksempel vil en objektiv indikator være "90 % af samtalerne skal have mindre end to gen-prompter afspillet for brugeren," versus en subjektiv indikator som "de fleste samtaler bør ikke bede brugerne om at gentage deres input."
• Evaluer brugeroplevelsen undervejs – I nogle tilfælde kan tilsyneladende små ændringer have stor indflydelse på brugeroplevelsen. Overvej f.eks. en situation, hvor du ved et uheld introducerer en tastefejl i det regulære udtryk, der bruges til en konto-id-slottype, hvilket fører til, at bot igen beder brugeren om at give input igen. Du bør evaluere brugeroplevelsen og investere i en automatiseret test for at generere nøglemålinger. Du kan henvise til Evaluering af en automatisk talegenkendelsestjeneste , Test af nøjagtighed og regression med Amazon Connect og Amazon Lex for eksempler på, hvordan man tester og genererer nøglemålinger.

Deployment

Når du er tilfreds med bottens ydeevne, vil du gerne implementere botten for at begynde at betjene din produktionstrafik. Når du itererer botten i løbet af dens livscyklus, gentager du implementeringerne, hvilket gør det til en kontinuerlig proces, så det er afgørende at have en strømlinet, automatiseret implementering for at reducere risikoen for fejl. Overvej følgende bedste praksis for implementering:

• Brug et miljø med flere konti – Du bør følge den anbefalede AWS opsætning af multi-konto miljø i din organisation og brug separate AWS-konti til din udviklingsfase og produktionsfase. Hvis du har en tilstedeværelse i flere regioner, bør du også bruge en separat AWS-konto pr. region til produktion. Brug af separate AWS-konti pr. fase giver dig sikkerhed, adgang og faktureringsgrænser for dine AWS-ressourcer.
• Automatiser promovering af en bot fra udvikling til produktion – Når du replikerer bot-opsætningen i din udviklingsfase til din produktionsfase, bør du bruge automatiserede løsninger og minimere manuelle berøringspunkter. Du bør bruge CloudFormation-skabeloner til at oprette dine bots. Alternativt kan du bruge Amazon Lex eksport og import API'er at give en automatiseret måde at kopiere et bot-skema på tværs af konti.
• Udrul ændringer i en trinvis måde – Du bør implementere ændringer til dit produktionsmiljø på en trinvis måde, så ændringer frigives til en delmængde af din produktionstrafik, før de frigives til alle brugere. En sådan tilgang giver dig chancen for at begrænse sprængningsradius, hvis der er problemer med ændringen. En måde du kan opnå dette på er ved at have en to-faset implementeringstilgang: du opretter to aliaser til en bot (for eksempel prod-05 og prod-95). Du knytter først den nye botversion til et alias (prod-05 i dette eksempel). Når du har valideret, at nøglemålingerne opfylder succeskriterierne, knytter du det andet alias (prod-95) til den nye botversion.

Bemærk, at du skal kontrollere distributionen af ​​trafik på klientapplikationen, der bruges til at integrere med Amazon Lex-bots. For eksempel, hvis du bruger Amazon Connect for at integrere med dine bots, kan du bruge en Fordel efter procent kontaktblok i forbindelse med to eller flere Få kundeinput blokke.

Det er vigtigt at bemærke, at Amazon Lex leverer et testalias ud af kassen. Testaliaset er kun beregnet til at blive brugt til ad hoc manuel test via Amazon Lex-konsollen og er ikke beregnet til at håndtere belastninger i produktionsskala. Vi anbefaler at bruge et dedikeret alias til din produktionstrafik.

Overvågning

Overvågning er vigtig for at opretholde pålidelighed, tilgængelighed og en effektiv slutbrugeroplevelse. Du bør analysere din bots metrics og bruge læringen som en feedbackmekanisme til at forbedre botskemaet såvel som din udvikling, test og implementeringspraksis. Amazon Lex understøtter flere mekanismer til overvåge bots. Overvej følgende bedste praksis for overvågning af dine Lex-bots:

• Overvåg konstant og gentag – Amazon Lex integreres med amazoncloudwatch at give næsten-realtids-metrics, der kan give dig nøgleindsigt i dine brugeres interaktioner med botten. Disse indsigter kan hjælpe dig med at få perspektiv på slutbrugeroplevelsen. For at lære mere om de forskellige typer målinger, som Amazon Lex udsender, se Overvågning af Amazon Lex V2 med Amazon CloudWatch. Vi anbefaler at opsætte tærskler for at udløse alarmer. På samme måde giver Amazon Lex dig synlighed i de rå input-ytringer fra dine brugeres interaktioner med botten. Du bør bruge ytringsstatistikker or samtale logs for at få indsigt for at identificere kommunikationsmønstre og foretage passende ændringer i din bot efter behov. For at lære, hvordan du opretter et personligt analyse-dashboard til dine bots, se Overvåg operationelle målinger for din Amazon Lex chatbot.

Den bedste praksis, der diskuteres i dette indlæg, fokuserer primært på Amazon Lex-specifikke use cases. Ud over disse bør du gennemgå og overholde bedste praksis, når du administrerer din cloud-infrastruktur i AWS. Sørg for, at din cloud-infrastruktur er sikker og kun tilgængelig for autoriserede brugere. Du bør også gennemgå og vedtage det relevante Bedste praksis for AWS-sikkerhed i din organisation. Endelig bør du proaktivt gennemgå AWS kvoter for individuelle AWS-tjenester (herunder Amazon Lex-kvoter) og anmod om passende ændringer, hvis det er nødvendigt.

Konklusion

Du kan bruge Amazon Lex til at aktivere sofistikerede samtaler med naturligt sprog og øge kundeserviceeffektiviteten. I dette indlæg gennemgik vi bedste praksis for udvikling, test, implementering og overvågningsfaser af en bots livscyklus. Med disse retningslinjer kan du forbedre slutbrugeroplevelsen og opnå bedre kundeengagement. Begynd at opbygge din Amazon Lex-samtaleoplevelse i dag!

Om forfatteren

Swapandeep Singh er ingeniør hos Amazon Lex-teamet. Han arbejder på at gøre interaktioner med bots smidigere og mere menneskelignende. Uden for arbejdet holder han af at rejse og lære om forskellige kulturer.