Generativ dataintelligens

AI

Förbättra Amazon Connect och Lex med generativa AI-funktioner | Amazon webbtjänster

Republiserad av Platon
Republiserad av Platon

Datum:

Visningar: 0

Effektiva självbetjäningsalternativ blir allt viktigare för kontaktcenter, men att implementera dem väl innebär unika utmaningar.

Amazon Lex tillhandahåller din Amazon Connect kontaktcenter med chatbot-funktioner som automatisk taligenkänning (ASR) och naturlig språkförståelse (NLU) via röst- och textkanaler. Boten tar naturligt språk eller textinmatning, känner igen avsikten bakom inmatningen och uppfyller användarens avsikt genom att anropa lämpligt svar.

Uppringare kan ha olika accenter, uttal och grammatik. I kombination med bakgrundsljud kan detta göra det utmanande för taligenkänning att korrekt förstå uttalanden. Till exempel, "Jag vill spåra min beställning" kan feligenkännas som "Jag vill lasta min innehavare." Misslyckade avsikter som dessa frustrerar kunder som måste upprepa sig själva, blir omdirigerade felaktigt eller eskaleras till live-agenter – vilket kostar företagen mer.

Amazonas berggrund demokratiserar tillgången till grundläggande modell (FM) för utvecklare att enkelt bygga och skala generativa AI-baserade applikationer för det moderna kontaktcentret. FMs levererade av Amazon Bedrock, som t.ex Amazon Titan och Antropisk Claude, är förtränade på datauppsättningar i internetskala som ger dem starka NLU-funktioner som meningsklassificering, fråga och svar och förbättrad semantisk förståelse trots taligenkänningsfel.

I det här inlägget utforskar vi en lösning som använder FMs levererade av Amazon Bedrock för att förbättra avsiktsigenkänningen av Amazon Lex integrerad med Amazon Connect, vilket i slutändan levererar en förbättrad självbetjäningsupplevelse för dina kunder.

Översikt över lösningen

Lösningen använder Amazon Connect, Amazon Lex , AWS Lambdaoch Amazonas berggrund i följande steg:

  1. Ett Amazon Connect-kontaktflöde integreras med en Amazon Lex-bot via GetCustomerInput blockera.
  2. När boten misslyckas med att känna igen uppringarens avsikt och som standard använder reservavsikten, utlöses en Lambda-funktion.
  3. Lambdafunktionen tar utskriften av kundens yttrande och skickar det till en grundmodell i Amazon Bedrock
  4. Med hjälp av sina avancerade naturliga språkfunktioner bestämmer modellen uppringarens avsikt.
  5. Lambdafunktionen dirigerar sedan boten att dirigera samtalet till rätt avsikt för uppfyllelse.

Genom att använda Amazon Bedrock-grundmodeller gör lösningen det möjligt för Amazon Lex-boten att förstå avsikter trots taligenkänningsfel. Detta resulterar i smidig routing och uppfyllelse, förhindrar upptrappningar till agenter och frustrerande upprepningar för uppringare.

Följande diagram illustrerar lösningsarkitekturen och arbetsflödet.

I de följande avsnitten tittar vi på nyckelkomponenterna i lösningen mer i detalj.

Lambdafunktioner och LangChain Framework

När Amazon Lex-boten anropar Lambda-funktionen skickar den ett händelsemeddelande som innehåller botinformation och transkriptionen av yttrandet från den som ringer. Med hjälp av detta händelsemeddelande hämtar Lambda-funktionen dynamiskt botens konfigurerade avsikter, avsiktsbeskrivning och avsiktsyttrande och skapar en prompt med Langkedja, som är ett ramverk för maskininlärning med öppen källkod (ML) som gör det möjligt för utvecklare att integrera stora språkmodeller (LLM), datakällor och applikationer.

En Amazon Bedrock-fundamentmodell anropas sedan med hjälp av prompten och ett svar tas emot med den förväntade avsikten och konfidensnivån. Om konfidensnivån är större än en inställd tröskel, till exempel 80 %, returnerar funktionen den identifierade avsikten till Amazon Lex med en åtgärd för att delegera. Om konfidensnivån är under tröskeln återgår den till standardvärdet FallbackIntent och en åtgärd för att stänga den.

Inlärning i sammanhang, snabb konstruktion och modellanrop

Vi använder kontextinlärning för att kunna använda en grundmodell för att utföra denna uppgift. Inlärning i sammanhang är förmågan för LLM:er att lära sig uppgiften med precis vad som står i prompten utan att vara förutbildade eller finjusterade för den specifika uppgiften.

I prompten ger vi först instruktionerna som beskriver vad som behöver göras. Sedan hämtar Lambda-funktionen dynamiskt och injicerar Amazon Lex-botens konfigurerade avsikter, avsiktsbeskrivningar och avsiktsyttringar i prompten. Slutligen ger vi den instruktioner om hur den ska producera sitt tänkande och slutliga resultat.

Följande promptmall testades på textgenereringsmodellerna Anthropic Claude Instant v1.2 och Anthropic Claude v2. Vi använder XML-taggar för att förbättra modellens prestanda. Vi lägger också till utrymme för modellen att tänka innan den identifierar den slutliga avsikten för att bättre förbättra dess resonemang för att välja rätt avsikt. De {intent_block} innehåller avsikts-ID:n, avsiktsbeskrivningar och avsiktsyttrande. De {input} blocket innehåller det transkriberade yttrandet från den som ringer. Tre backticks (“`) läggs till i slutet för att hjälpa modellen att mata ut ett kodblock mer konsekvent. A <STOP> sekvensen läggs till för att stoppa den från att generera ytterligare.

"""
Human: You are a call center agent. You try to understand the intent given an utterance from the caller.

The available intents are as follows, the intent of the caller is highly likely to be one of these.
<intents>
{intents_block} </intents>
The output format is:
<thinking>
</thinking>

<output>
{{
     "intent_id": intent_id,
     "confidence": confidence
}}
</output><STOP>

For the given utterance, you try to categorize the intent of the caller to be one of the intents in <intents></intents> tags.
If it does not match any intents or the utterance is blank, respond with FALLBCKINT and confidence of 1.0.
Respond with the intent name and confidence between 0.0 and 1.0.
Put your thinking in <thinking></thinking> tags before deciding on the intent.

Utterance: {input}

Assistant: ```"""

Efter att modellen har åberopats får vi följande svar från grundmodellen:

<thinking>
The given utterance is asking for checking where their shipment is. It matches the intent order status.
</thinking>

{
    "intent": "ORDERSTATUSID",
    "confidence": 1.0
}
```

Filtrera tillgängliga intents baserat på kontaktflödessessionsattribut

När du använder lösningen som en del av ett Amazon Connect-kontaktflöde kan du ytterligare förbättra LLM:s förmåga att identifiera rätt avsikt genom att ange sessionsattributet available_intents i "Få kundinput" block med en kommaseparerad lista över avsikter, som visas i följande skärmdump. Genom att göra det kommer Lambda-funktionen endast att inkludera dessa specificerade avsikter som en del av uppmaningen till LLM, vilket minskar antalet avsikter som LLM har att resonera igenom. Om available_intents sessionsattributet inte är specificerat, alla avsikter i Amazon Lex-bot kommer att användas som standard.

Lambdafunktionssvar på Amazon Lex

Efter att LLM har bestämt avsikten, svarar Lambda-funktionen i specifikt format krävs av Amazon Lex för att bearbeta svaret.

Om en matchande avsikt hittas över konfidensgränsen, returnerar den en dialogtyp Delegate att instruera Amazon Lex att använda den valda avsikten och därefter returnera den avslutade avsikten tillbaka till Amazon Connect. Svarsutgången är som följer:

{
    "sessionState": {
        "dialogAction": {
        "type": "Delegate"
        },
        "intent": {
        "name": intent,
        "state": "InProgress",
        }
    }
}

Om konfidensnivån är under tröskeln eller om en avsikt inte kändes igen, en dialogåtgärdstyp Stäng returneras för att instruera Amazon Lex att stänga FallbackIntent, och returnera kontrollen tillbaka till Amazon Connect. Svarsutgången är som följer:

{
    "sessionState": {
        "dialogAction": {
        "type": "Close"
        },
        "intent": {
        "name": intent,
        "state": "Fulfilled",
        }
    }
}

Den fullständiga källkoden för detta exempel finns tillgänglig i GitHub.

Förutsättningar

Se till att du har följande förutsättningar innan du sätter igång:

Implementera lösningen

Följ följande steg för att implementera lösningen:

  1. Klona förvaret 
    git clone https://github.com/aws-samples/amazon-connect-with-amazon-lex-genai-capabilities
cd amazon-connect-with-amazon-lex-genai-capabilities

  2. Kör följande kommando för att initiera miljön och skapa en Amazon Elastic Container Registry (Amazon ECR) förråd för vår Lambda-funktions bild. Ange AWS-regionen och ECR-förrådets namn som du vill skapa. 
    bash ./scripts/build.sh region-name repository-name

  3. Uppdatera ParameterValue fält i scripts/parameters.json fil:
    • ParameterKey ("AmazonECRImageUri") – Ange arkivets URL från föregående steg.
    • ParameterKey ("AmazonConnectName") – Ange ett unikt namn.
    • ParameterKey ("AmazonLexBotName") – Ange ett unikt namn.
    • ParameterKey ("AmazonLexBotAliasName") – Standard är "prodversion"; du kan ändra det om det behövs.
    • ParameterKey ("LoggingLevel") – Standard är “INFO”; du kan ändra det om det behövs. Giltiga värden är DEBUG, WARN och ERROR.
    • ParameterKey ("ModelID") – Standardinställningen är "anthropic.claude-instant-v1"; du kan ändra den om du behöver använda en annan modell.
    • ParameterKey ("AmazonConnectName") – Standardinställningen är "0.75"; du kan ändra det om du behöver uppdatera konfidenspoängen.
  4. Kör kommandot för att generera CloudFormation-stacken och distribuera resurserna: 
    bash ./scripts/deploy.sh region cfn-stack-name

Om du inte vill bygga upp kontaktflödet från början i Amazon Connect kan du importera provflödet som medföljer detta förråd filelocation: /contactflowsample/samplecontactflow.json.

  1. Logga in på din Amazon Connect-instans. Kontot måste tilldelas en säkerhetsprofil som inkluderar redigeringsbehörigheter för flöden.
  2. På Amazon Connect-konsolen, i navigeringsfönstret, under Rutthanteringväljer Kontaktflöden.
  3. Skapa ett nytt flöde av samma typ som det du importerar.
  4. Välja Spara och importera flöde.
  5. Välj filen som ska importeras och välj Importera.

När flödet importeras till ett befintligt flöde uppdateras även namnet på det befintliga flödet.

  1. Granska och uppdatera eventuella lösta eller olösta referenser vid behov.
  2. För att spara det importerade flödet, välj Save. För att publicera, välj Spara och publicera.
  3. När du har laddat upp kontaktflödet uppdaterar du följande konfigurationer:
    • Uppdatera GetCustomerInput block med rätt Amazon Lex-botnamn och -version.
    • Under Hantera telefonnummer uppdaterar du numret med kontaktflödet eller IVR som importerats tidigare.

Verifiera konfigurationen

Verifiera att Lambda-funktionen skapad med CloudFormation-stacken har en IAM-roll med behörigheter att hämta bots och avsiktsinformation från Amazon Lex (lista- och läsbehörigheter) och lämpliga Amazon Bedrock-behörigheter (lista- och läsbehörigheter).

I din Amazon Lex-bot, för ditt konfigurerade alias och språk, verifiera att Lambda-funktionen var korrekt inställd. För FallBackIntent, bekräfta det Fulfillmentis satt till Active för att kunna köra funktionen närhelst FallBackIntent är triggad.

Vid denna tidpunkt kommer din Amazon Lex-bot automatiskt att köra Lambda-funktionen och lösningen bör fungera sömlöst.

Testa lösningen

Låt oss titta på ett exempel på avsikt, beskrivning och yttrandekonfiguration i Amazon Lex och se hur väl LLM presterar med exempelinmatningar som innehåller stavfel, grammatikfel och till och med ett annat språk.

Följande bild visar skärmdumpar av vårt exempel. Den vänstra sidan visar avsiktsnamnet, dess beskrivning och ett exempel på ett ord. Utan mycket konfiguration på Amazon Lex kan LLM förutsäga rätt avsikt (höger sida). I det här testet har vi ett enkelt uppfyllelsemeddelande från rätt avsikt.

Städa upp

För att rensa upp dina resurser, kör följande kommando för att ta bort ECR-förvaret och CloudFormation-stacken:

bash ./scripts/cleanup.sh region repository-name cfn-stack-name

Slutsats

Genom att använda Amazon Lex förstärkt med LLM:er levererade av Amazon Bedrock kan du förbättra avsiktsigenkänningsprestandan för dina bots. Detta ger en sömlös självbetjäningsupplevelse för en mångsidig uppsättning kunder, överbryggar klyftan mellan accenter och unika talegenskaper och ökar i slutändan kundnöjdheten.

För att dyka djupare och lära dig mer om generativ AI, kolla in dessa ytterligare resurser:

För mer information om hur du kan experimentera med den generativa AI-drivna självbetjäningslösningen, se Implementera självbetjäningsfrågor med QnABot på AWS-lösningen som drivs av Amazon Lex med Amazon Kendra och stora språkmodeller.

Om författarna

Hamza Nadeem är en Amazon Connect Specialist Solutions Architect på AWS, baserad i Toronto. Han arbetar med kunder i hela Kanada för att modernisera deras kontaktcenter och tillhandahålla lösningar på deras unika utmaningar och affärskrav. På fritiden tycker Hamza om att resa, fotboll och att testa nya recept med sin fru.

Parag Srivastava är en lösningsarkitekt på Amazon Web Services (AWS), som hjälper företagskunder med framgångsrik molnadoption och migrering. Under sin yrkeskarriär har han varit mycket involverad i komplexa digitala transformationsprojekt. Han brinner också för att bygga innovativa lösningar kring geospatiala aspekter av adresser.

Ross Ack är en lösningsarkitekt på AWS baserad i Toronto, Kanada. Han hjälper kunder att förnya sig med AI/ML och Generative AI-lösningar som leder till verkliga affärsresultat. Han har arbetat med en mängd olika kunder från detaljhandel, finansiella tjänster, teknik, läkemedel och andra. På fritiden älskar han att vara ute och njuta av naturen med sin familj.

Sangeetha Kamatkar är en lösningsarkitekt på Amazon Web Services (AWS), som hjälper kunder med framgångsrik molnadoption och migrering. Hon arbetar med kunder för att skapa mycket skalbara, flexibla och motståndskraftiga molnarkitekturer som tar itu med kundernas affärsproblem. På fritiden lyssnar hon på musik, tittar på film och njuter av trädgårdsarbete under sommaren.

plats_img

Senaste intelligens

plats_img

Copyright @ 2024 Plato Technologies Inc.