Zephyrnet-logo

Verbeter Amazon Connect en Lex met generatieve AI-mogelijkheden | Amazon-webservices

Datum:

Effectieve selfservice-opties worden steeds belangrijker voor contactcenters, maar het goed implementeren ervan brengt unieke uitdagingen met zich mee.

Amazon-Lex biedt uw Amazon Connect contactcenter met chatbotfunctionaliteiten zoals automatische spraakherkenning (ASR) en mogelijkheden voor natuurlijk taalbegrip (NLU) via spraak- en tekstkanalen. De bot neemt spraak- of tekstinvoer in natuurlijke taal, herkent de intentie achter de invoer en vervult de intentie van de gebruiker door het juiste antwoord op te roepen.

Bellers kunnen verschillende accenten, uitspraak en grammatica hebben. In combinatie met achtergrondgeluid kan dit het lastig maken voor spraakherkenning om uitspraken nauwkeurig te begrijpen. 'Ik wil mijn bestelling volgen' kan bijvoorbeeld ten onrechte worden herkend als 'Ik wil mijn houder in een vrachtwagen vervoeren'. Mislukte bedoelingen als deze frustreren klanten die zichzelf moeten herhalen, verkeerd worden omgeleid of worden geëscaleerd naar live agenten, wat bedrijven meer kost.

Amazonebodem democratiseert fundamentele modeltoegang (FM) voor ontwikkelaars om moeiteloos generatieve, op AI gebaseerde applicaties voor het moderne contactcenter te bouwen en te schalen. FM's geleverd door Amazon Bedrock, zoals Amazone Titan en Antropische Claude, zijn vooraf getraind in datasets op internetschaal die hen sterke NLU-mogelijkheden bieden, zoals zinsclassificatie, vraag en antwoord, en verbeterd semantisch begrip ondanks spraakherkenningsfouten.

In dit bericht onderzoeken we een oplossing die FM's van Amazon Bedrock gebruikt om de intentieherkenning van Amazon Lex geïntegreerd met Amazon Connect te verbeteren, waardoor je klanten uiteindelijk een verbeterde zelfbedieningservaring krijgen.

Overzicht van de oplossing

De oplossing maakt gebruik van Amazon Connect, Amazon-Lex , AWS Lambda en Amazonebodem in de volgende stappen:

  1. Een Amazon Connect-contactstroom kan worden geïntegreerd met een Amazon Lex-bot via de GetCustomerInput blok.
  2. Wanneer de bot de intentie van de beller niet herkent en standaard overgaat op de fallback-intentie, wordt een Lambda-functie geactiveerd.
  3. De Lambda-functie neemt de transcriptie van de klantuiting en geeft deze door aan een basismodel in Amazon Bedrock
  4. Met behulp van de geavanceerde mogelijkheden voor natuurlijke taal bepaalt het model de intentie van de beller.
  5. De Lambda-functie geeft de bot vervolgens opdracht om de oproep naar de juiste intentie te routeren voor uitvoering.

Door Amazon Bedrock-basismodellen te gebruiken, zorgt de oplossing ervoor dat de Amazon Lex-bot de intenties begrijpt, ondanks spraakherkenningsfouten. Dit resulteert in een soepele routering en uitvoering, waardoor escalaties naar agenten en frustrerende herhalingen voor bellers worden voorkomen.

Het volgende diagram illustreert de oplossingsarchitectuur en workflow.

In de volgende paragrafen gaan we dieper in op de belangrijkste componenten van de oplossing.

Lambda-functies en het LangChain Framework

Wanneer de Amazon Lex-bot de Lambda-functie aanroept, verzendt deze een gebeurtenisbericht met botinformatie en de transcriptie van de uiting van de beller. Met behulp van dit gebeurtenisbericht haalt de Lambda-functie dynamisch de geconfigureerde intenties, de intentiebeschrijving en de intentie-uitingen van de bot op en bouwt een prompt op met behulp van LangChain, een open source machine learning (ML)-framework waarmee ontwikkelaars grote taalmodellen (LLM's), gegevensbronnen en applicaties kunnen integreren.

Vervolgens wordt een Amazon Bedrock-basismodel aangeroepen met behulp van de prompt en wordt een antwoord ontvangen met het voorspelde intentie- en betrouwbaarheidsniveau. Als het betrouwbaarheidsniveau groter is dan een ingestelde drempel, bijvoorbeeld 80%, retourneert de functie de geïdentificeerde intentie naar Amazon Lex met een actie om delegeren. Als het betrouwbaarheidsniveau onder de drempel ligt, wordt het standaardniveau teruggezet FallbackIntent en een actie om het te sluiten.

In-context leren, snelle engineering en modelaanroep

We gebruiken in-context leren om een ​​basismodel te kunnen gebruiken om deze taak te volbrengen. In-context leren is de mogelijkheid voor LLM's om de taak te leren met behulp van precies wat er in de prompt staat, zonder vooraf getraind of verfijnd te zijn voor de specifieke taak.

In de prompt geven we eerst de instructie waarin wordt beschreven wat er moet gebeuren. Vervolgens haalt de Lambda-functie dynamisch de geconfigureerde intents, intentbeschrijvingen en intentuitingen van de Amazon Lex-bot op en injecteert deze in de prompt. Ten slotte geven we het instructies over hoe het de denkwijze en het eindresultaat kan weergeven.

De volgende promptsjabloon is getest op tekstgeneratiemodellen Anthropic Claude Instant v1.2 en Anthropic Claude v2. We gebruiken XML-tags om de prestaties van het model beter te verbeteren. We voegen ook ruimte toe aan het model om na te denken voordat de uiteindelijke intentie wordt geïdentificeerd, zodat de redenering voor het kiezen van de juiste intentie beter kan worden verbeterd. De {intent_block} bevat de intentie-ID's, intentiebeschrijvingen en intentie-uitingen. De {input} blok bevat de getranscribeerde uiting van de beller. Aan het einde zijn drie backticks (“`) toegevoegd om het model te helpen een codeblok consistenter uit te voeren. A <STOP> Er wordt een reeks toegevoegd om te voorkomen dat deze verder wordt gegenereerd.

"""
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: ```"""

Nadat het model is aangeroepen, ontvangen we de volgende reactie van het funderingsmodel:

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

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

Filter beschikbare intenties op basis van sessiekenmerken van de contactstroom

Wanneer u de oplossing gebruikt als onderdeel van een Amazon Connect-contactstroom, kunt u het vermogen van de LLM om de juiste intentie te identificeren verder verbeteren door het sessiekenmerk op te geven available_intents in de “Krijg input van klanten” blok met een door komma's gescheiden lijst met intenties, zoals weergegeven in de volgende schermafbeelding. Door dit te doen zal de Lambda-functie alleen deze gespecificeerde intenties opnemen als onderdeel van de prompt aan de LLM, waardoor het aantal intenties waar de LLM doorheen moet redeneren wordt verminderd. Als de available_intents sessiekenmerk niet is opgegeven, worden standaard alle intenties in de Amazon Lex-bot gebruikt.

Lambda-functiereactie op Amazon Lex

Nadat de LLM de bedoeling heeft bepaald, reageert de Lambda-functie in de specifiek formaat vereist door Amazon Lex om het antwoord te verwerken.

Als een overeenkomende intentie wordt gevonden boven de betrouwbaarheidsdrempel, retourneert deze een dialoogactietype Delegate om Amazon Lex te instrueren om de geselecteerde intentie te gebruiken en vervolgens de voltooide intentie terug te sturen naar Amazon Connect. De responsuitvoer is als volgt:

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

Als het betrouwbaarheidsniveau onder de drempel ligt of als een intentie niet is herkend, wordt er een dialoogactietype uitgevoerd Sluiten wordt teruggestuurd om Amazon Lex de opdracht te geven het bestand te sluiten FallbackIntenten geef de besturing terug aan Amazon Connect. De responsuitvoer is als volgt:

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

De volledige broncode voor dit voorbeeld is beschikbaar in GitHub.

Voorwaarden

Voordat u aan de slag gaat, moet u ervoor zorgen dat u aan de volgende vereisten voldoet:

Implementeer de oplossing

Voer de volgende stappen uit om de oplossing te implementeren:

  1. Kloon de opslagplaats
    git clone https://github.com/aws-samples/amazon-connect-with-amazon-lex-genai-capabilities
    cd amazon-connect-with-amazon-lex-genai-capabilities

  2. Voer de volgende opdracht uit om de omgeving te initialiseren en een Amazon Elastic Container-register (Amazon ECR) repository voor de afbeelding van onze Lambda-functie. Geef de AWS-regio en ECR-repositorynaam op die u wilt maken.
    bash ./scripts/build.sh region-name repository-name

  3. Werk het ParameterValue velden in de scripts/parameters.json file:
    • ParameterKey ("AmazonECRImageUri") – Voer de repository-URL uit de vorige stap in.
    • ParameterKey ("AmazonConnectName") – Voer een unieke naam in.
    • ParameterKey ("AmazonLexBotName") – Voer een unieke naam in.
    • ParameterKey ("AmazonLexBotAliasName") – De standaardwaarde is “prodversion”; je kunt het indien nodig wijzigen.
    • ParameterKey ("LoggingLevel") – De standaardinstelling is “INFO”; u kunt het indien nodig wijzigen. Geldige waarden zijn DEBUG, WARN en ERROR.
    • ParameterKey ("ModelID") – De standaardwaarde is “anthropic.claude-instant-v1”; u kunt dit wijzigen als u een ander model wilt gebruiken.
    • ParameterKey ("AmazonConnectName") – De standaardwaarde is “0.75”; u kunt dit wijzigen als u de betrouwbaarheidsscore moet bijwerken.
  4. Voer de opdracht uit om de CloudFormation-stack te genereren en de bronnen te implementeren:
    bash ./scripts/deploy.sh region cfn-stack-name

Als je de contactstroom niet helemaal opnieuw wilt opbouwen in Amazon Connect, kun je de voorbeeldstroom importeren die bij deze repository wordt geleverd filelocation: /contactflowsample/samplecontactflow.json.

  1. Meld u aan bij uw Amazon Connect-instantie. Aan het account moet een beveiligingsprofiel worden toegewezen dat bewerkingsmachtigingen voor stromen omvat.
  2. Op de Amazon Connect-console, in het navigatievenster, onder Routing, kiezen Contact stromen.
  3. Maak een nieuwe stroom van hetzelfde type als degene die u importeert.
  4. Kies Opslaan en importeren stroom.
  5. Selecteer het bestand dat u wilt importeren en kies import.

Wanneer de stroom in een bestaande stroom wordt geïmporteerd, wordt de naam van de bestaande stroom ook bijgewerkt.

  1. Controleer en update eventuele opgeloste of onopgeloste verwijzingen indien nodig.
  2. Om de geïmporteerde stroom op te slaan, kiest u Bespaar. Kies om te publiceren Opslaan en publiceren.
  3. Nadat u de contactstroom heeft geüpload, werkt u de volgende configuraties bij:
    • Werk het GetCustomerInput blokken met de juiste Amazon Lex-botnaam en -versie.
    • Werk onder Telefoonnummer beheren het nummer bij met de eerder geïmporteerde contactstroom of IVR.

Controleer de configuratie

Controleer of de Lambda-functie die is gemaakt met de CloudFormation-stack een IAM-rol heeft met machtigingen om bots en intentie-informatie op te halen uit Amazon Lex (lijst- en leesmachtigingen) en de juiste Amazon Bedrock-machtigingen (lijst- en leesmachtigingen).

Controleer in uw Amazon Lex-bot voor uw geconfigureerde alias en taal of de Lambda-functie correct is ingesteld. Voor de FallBackIntent, bevestig dat Fulfillmentis ingesteld op Active om de functie te kunnen uitvoeren wanneer de FallBackIntent wordt geactiveerd.

Op dit punt zal uw Amazon Lex-bot automatisch de Lambda-functie uitvoeren en de oplossing zou naadloos moeten werken.

Test de oplossing

Laten we eens kijken naar een voorbeeld van een intentie, beschrijving en uitingconfiguratie in Amazon Lex en zien hoe goed de LLM presteert met voorbeeldinvoer die typefouten, grammaticafouten en zelfs een andere taal bevat.

De volgende afbeelding toont schermafbeeldingen van ons voorbeeld. Aan de linkerkant worden de naam van de intentie, de beschrijving ervan en een voorbeelduiting van één woord weergegeven. Zonder veel configuratie op Amazon Lex kan de LLM de juiste bedoeling voorspellen (rechterkant). In deze test hebben we een eenvoudig vervullingsbericht van de juiste intentie.

Opruimen

Om uw bronnen op te schonen, voert u de volgende opdracht uit om de ECR-repository en CloudFormation-stack te verwijderen:

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

Conclusie

Door Amazon Lex te gebruiken, uitgebreid met LLM's geleverd door Amazon Bedrock, kunt u de intentieherkenningsprestaties van uw bots verbeteren. Dit zorgt voor een naadloze zelfbedieningservaring voor een gevarieerde groep klanten, overbrugt de kloof tussen accenten en unieke spraakkenmerken en verbetert uiteindelijk de klanttevredenheid.

Bekijk deze aanvullende bronnen om dieper te duiken en meer te leren over generatieve AI:

Voor meer informatie over hoe u kunt experimenteren met de generatieve AI-aangedreven selfservice-oplossing, zie Implementeer self-service vraagbeantwoording met de QnABot op AWS-oplossing mogelijk gemaakt door Amazon Lex met Amazon Kendra en grote taalmodellen.


Over de auteurs

Hamza Nadeem is een Amazon Connect Specialist Solutions Architect bij AWS, gevestigd in Toronto. Hij werkt samen met klanten in heel Canada om hun contactcenters te moderniseren en oplossingen te bieden voor hun unieke uitdagingen op het gebied van klantbetrokkenheid en zakelijke vereisten. In zijn vrije tijd houdt Hamza van reizen, voetbal en het uitproberen van nieuwe recepten met zijn vrouw.

Parag Srivastava is een Solutions Architect bij Amazon Web Services (AWS) en helpt zakelijke klanten met succesvolle cloudacceptatie en -migratie. Tijdens zijn professionele carrière is hij veelvuldig betrokken geweest bij complexe digitale transformatieprojecten. Hij is ook gepassioneerd door het bouwen van innovatieve oplossingen rond geospatiale aspecten van adressen.

Roos Helaas is een Solutions Architect bij AWS, gevestigd in Toronto, Canada. Hij helpt klanten innoveren met AI/ML en generatieve AI-oplossingen die tot echte bedrijfsresultaten leiden. Hij heeft gewerkt met een verscheidenheid aan klanten uit de detailhandel, financiële dienstverlening, technologie, farmacie en anderen. In zijn vrije tijd houdt hij van het buitenleven en geniet hij samen met zijn gezin van de natuur.

Sangeetha Kamatkar is een Solutions Architect bij Amazon Web Services (AWS) en helpt klanten met succesvolle cloudadoptie en -migratie. Ze werkt samen met klanten aan het creëren van zeer schaalbare, flexibele en veerkrachtige cloudarchitecturen die de zakelijke problemen van klanten aanpakken. In haar vrije tijd luistert ze naar muziek, kijkt ze films en houdt ze van tuinieren in de zomer.

spot_img

Laatste intelligentie

spot_img