Opzioni self-service efficaci stanno diventando sempre più cruciali per i contact center, ma implementarle correttamente presenta sfide uniche.

Amazon-Lex fornisce il tuo Amazon Connect contact center con funzionalità di chatbot come il riconoscimento vocale automatico (ASR) e la comprensione del linguaggio naturale (NLU) attraverso canali vocali e testuali. Il bot accetta il parlato in linguaggio naturale o l'input di testo, riconosce l'intento dietro l'input e soddisfa l'intento dell'utente invocando la risposta appropriata.

I chiamanti possono avere accenti, pronuncia e grammatica diversi. In combinazione con il rumore di fondo, ciò può rendere difficile la comprensione accurata delle dichiarazioni da parte del riconoscimento vocale. Ad esempio, "Voglio monitorare il mio ordine" potrebbe essere riconosciuto erroneamente come "Voglio trasportare il mio titolare". Intenti falliti come questi frustrano i clienti che devono ripetersi, vengono indirizzati in modo errato o vengono inoltrati ad agenti attivi, costando di più alle aziende.

Roccia Amazzonica democratizza l'accesso al modello fondamentale (FM) per consentire agli sviluppatori di creare e scalare senza sforzo applicazioni generative basate sull'intelligenza artificiale per il contact center moderno. FM consegnati da Amazon Bedrock, ad esempio Titano Amazzonico ed Claudio antropico, sono preaddestrati su set di dati su scala Internet che offrono loro potenti funzionalità NLU come la classificazione delle frasi, domande e risposte e una migliore comprensione semantica nonostante gli errori di riconoscimento vocale.

In questo post, esploriamo una soluzione che utilizza FM forniti da Amazon Bedrock per migliorare il riconoscimento delle intenzioni di Amazon Lex integrato con Amazon Connect, offrendo in definitiva un'esperienza self-service migliorata per i tuoi clienti.

Panoramica della soluzione

La soluzione usa Amazon Connect, Amazon-Lex , AWS Lambdae Roccia Amazzonica nei seguenti passaggi:

1. Un flusso di contatti Amazon Connect si integra con un bot Amazon Lex tramite GetCustomerInput blocco.
2. Quando il bot non riesce a riconoscere l'intento del chiamante e utilizza per impostazione predefinita l'intento di fallback, viene attivata una funzione Lambda.
3. La funzione Lambda prende la trascrizione dell'espressione del cliente e la trasmette a un modello di base in Amazon Bedrock
4. Utilizzando le sue funzionalità avanzate di linguaggio naturale, il modello determina l'intento del chiamante.
5. La funzione Lambda indirizza quindi il bot a instradare la chiamata all'intento corretto per l'adempimento.

Utilizzando i modelli base di Amazon Bedrock, la soluzione consente al bot Amazon Lex di comprendere gli intenti nonostante gli errori di riconoscimento vocale. Ciò si traduce in un instradamento e un'esecuzione fluidi, evitando escalation verso gli agenti e ripetizioni frustranti per i chiamanti.

Il diagramma seguente illustra l'architettura della soluzione e il flusso di lavoro.

Nelle sezioni seguenti esamineremo più in dettaglio i componenti chiave della soluzione.

Funzioni Lambda e LangChain Framework

Quando il bot Amazon Lex richiama la funzione Lambda, invia un messaggio di evento che contiene le informazioni sul bot e la trascrizione dell'espressione del chiamante. Utilizzando questo messaggio di evento, la funzione Lambda recupera dinamicamente gli intenti configurati del bot, la descrizione dell'intento e le espressioni di intenti e crea un prompt utilizzando LangChain, un framework di machine learning (ML) open source che consente agli sviluppatori di integrare modelli linguistici di grandi dimensioni (LLM), origini dati e applicazioni.

Viene quindi richiamato un modello di fondazione Amazon Bedrock utilizzando il prompt e viene ricevuta una risposta con l'intento e il livello di confidenza previsti. Se il livello di confidenza è maggiore di una soglia impostata, ad esempio 80%, la funzione restituisce l'intento identificato ad Amazon Lex con un'azione per delegare. Se il livello di confidenza è inferiore alla soglia, viene ripristinato il valore predefinito FallbackIntent e un'azione per chiuderlo.

Apprendimento in contesto, ingegneria rapida e invocazione di modelli

Usiamo l'apprendimento in contesto per essere in grado di utilizzare un modello di base per svolgere questo compito. L'apprendimento in contesto è la capacità degli LLM di apprendere l'attività utilizzando esattamente ciò che viene richiesto senza essere pre-addestrati o ottimizzati per l'attività particolare.

Nel prompt, forniamo innanzitutto le istruzioni che descrivono in dettaglio cosa è necessario fare. Quindi, la funzione Lambda recupera e inserisce dinamicamente gli intenti configurati, le descrizioni degli intenti e le espressioni di intenti del bot Amazon Lex nel prompt. Infine, gli forniamo istruzioni su come produrre il suo pensiero e il risultato finale.

Il seguente modello di prompt è stato testato sui modelli di generazione di testo Anthropic Claude Instant v1.2 e Anthropic Claude v2. Utilizziamo tag XML per migliorare meglio le prestazioni del modello. Aggiungiamo anche spazio affinché il modello possa riflettere prima di identificare l'intento finale per migliorare meglio il suo ragionamento per scegliere l'intento giusto. IL {intent_block} contiene gli ID di intento, le descrizioni di intento e le espressioni di intento. IL {input} il blocco contiene l'espressione trascritta dal chiamante. Alla fine vengono aggiunti tre apici inversi (“`) per aiutare il modello a produrre un blocco di codice in modo più coerente. UN <STOP> viene aggiunta una sequenza per impedirne la generazione ulteriore.

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

Dopo che il modello è stato invocato, riceviamo la seguente risposta dal modello di fondazione:

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

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

Filtra gli intenti disponibili in base agli attributi della sessione del flusso di contatti

Quando si utilizza la soluzione come parte di un flusso di contatti Amazon Connect, è possibile migliorare ulteriormente la capacità di LLM di identificare l'intento corretto specificando l'attributo di sessione available_intents nel "Ottieni input dai clienti" bloccare con un elenco di intenti separati da virgole, come mostrato nello screenshot seguente. In questo modo, la funzione Lambda includerà solo questi intenti specificati come parte della richiesta a LLM, riducendo il numero di intenti su cui LLM deve ragionare. Se la available_intents L'attributo session non è specificato, tutti gli intenti nel bot Amazon Lex verranno utilizzati per impostazione predefinita.

Risposta della funzione Lambda ad Amazon Lex

Dopo che LLM ha determinato l'intento, la funzione Lambda risponde nel file formato specifico richiesto da Amazon Lex per elaborare la risposta.

Se viene trovato un intento corrispondente al di sopra della soglia di confidenza, restituisce un tipo di azione di dialogo Delegate per istruire Amazon Lex a utilizzare l'intento selezionato e successivamente restituire l'intento completato ad Amazon Connect. L'output della risposta è il seguente:

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

Se il livello di confidenza è inferiore alla soglia o un intento non è stato riconosciuto, viene generato un tipo di azione di dialogo Chiudi viene restituito per istruire Amazon Lex a chiudere il file FallbackIntente restituisci il controllo ad Amazon Connect. L'output della risposta è il seguente:

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

Il codice sorgente completo per questo esempio è disponibile in GitHub.

Prerequisiti

Prima di iniziare, assicurati di avere i seguenti prerequisiti:

Implementa la soluzione

Per implementare la soluzione, completare i seguenti passi:

1. Clona il repository

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

2. Eseguire il comando seguente per inizializzare l'ambiente e creare un file Registro dei contenitori Amazon Elastic (Amazon ECR) per l'immagine della nostra funzione Lambda. Fornisci il nome della regione AWS e del repository ECR che desideri creare.

   bash ./scripts/build.sh region-name repository-name

3. Aggiorna il ParameterValue campi in scripts/parameters.json file:
   • ParameterKey ("AmazonECRImageUri") – Inserisci l'URL del repository dal passaggio precedente.
   • ParameterKey ("AmazonConnectName") – Immettere un nome univoco.
   • ParameterKey ("AmazonLexBotName") – Immettere un nome univoco.
   • ParameterKey ("AmazonLexBotAliasName") – L'impostazione predefinita è “prodversion”; puoi cambiarlo se necessario.
   • ParameterKey ("LoggingLevel") – L'impostazione predefinita è “INFO”; puoi cambiarlo se necessario. I valori validi sono DEBUG, WARN ed ERROR.
   • ParameterKey ("ModelID") – Il valore predefinito è “anthropic.claude-instant-v1”; puoi cambiarlo se hai bisogno di usare un modello diverso.
   • ParameterKey ("AmazonConnectName") – Il valore predefinito è “0.75”; puoi cambiarlo se hai bisogno di aggiornare il punteggio di confidenza.
4. Esegui il comando per generare lo stack CloudFormation e distribuire le risorse:

   bash ./scripts/deploy.sh region cfn-stack-name

Se non desideri creare il flusso di contatti da zero in Amazon Connect, puoi importare il flusso di esempio fornito con questo repository filelocation: /contactflowsample/samplecontactflow.json.

1. Accedi al tuo Istanza Amazon Connect. All'account deve essere assegnato un profilo di sicurezza che includa le autorizzazioni di modifica per i flussi.
2. Nella console Amazon Connect, nel riquadro di navigazione, sotto efficientescegli Flussi di contatto.
3. Crea un nuovo flusso dello stesso tipo di quello che stai importando.
4. Scegli Flusso di salvataggio e importazione.
5. Seleziona il file da importare e scegli Importare.

Quando il flusso viene importato in un flusso esistente, viene aggiornato anche il nome del flusso esistente.

1. Rivedere e aggiornare eventuali riferimenti risolti o non risolti, se necessario.
2. Per salvare il flusso importato, scegli Risparmi. Per pubblicare, scegli Salva e pubblica.
3. Dopo aver caricato il flusso di contatti, aggiorna le seguenti configurazioni:
   • Aggiorna il GetCustomerInput blocchi con il nome e la versione corretti del bot Amazon Lex.
   • In Gestisci numero di telefono, aggiorna il numero con il flusso di contatti o l'IVR importato in precedenza.

Verifica la configurazione

Verifica che la funzione Lambda creata con lo stack CloudFormation disponga di un ruolo IAM con autorizzazioni per recuperare bot e informazioni sugli intenti da Amazon Lex (autorizzazioni di elenco e lettura) e autorizzazioni Amazon Bedrock appropriate (autorizzazioni di elenco e lettura).

Nel bot Amazon Lex, per l'alias e la lingua configurati, verifica che la funzione Lambda sia stata impostata correttamente. Per il FallBackIntent, confermare che Fulfillmentis impostato Active per poter eseguire la funzione ogni volta che FallBackIntent E 'attivato.

A questo punto, il tuo bot Amazon Lex eseguirà automaticamente la funzione Lambda e la soluzione dovrebbe funzionare perfettamente.

Prova la soluzione

Diamo un'occhiata a un esempio di configurazione di intenti, descrizioni ed espressioni in Amazon Lex e vediamo come funziona LLM con input di esempio che contengono errori di battitura, errori grammaticali e persino una lingua diversa.

La figura seguente mostra gli screenshot del nostro esempio. Il lato sinistro mostra il nome dell'intento, la sua descrizione e un'espressione di esempio di una sola parola. Senza molta configurazione su Amazon Lex, LLM è in grado di prevedere l'intento corretto (lato destro). In questo test, abbiamo un semplice messaggio di adempimento dall'intento corretto.

ripulire

Per pulire le tue risorse, esegui il comando seguente per eliminare il repository ECR e lo stack CloudFormation:

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

Conclusione

Utilizzando Amazon Lex potenziato con LLM forniti da Amazon Bedrock, puoi migliorare le prestazioni di riconoscimento degli intenti dei tuoi bot. Ciò fornisce un'esperienza self-service fluida per un gruppo diversificato di clienti, colmando il divario tra accenti e caratteristiche vocali uniche e, in definitiva, migliorando la soddisfazione del cliente.

Per approfondire e saperne di più sull'intelligenza artificiale generativa, consulta queste risorse aggiuntive:

Per ulteriori informazioni su come sperimentare la soluzione self-service generativa basata sull'intelligenza artificiale, vedere Distribuisci la risposta self-service alle domande con la soluzione QnABot su AWS basata su Amazon Lex con Amazon Kendra e modelli linguistici di grandi dimensioni.

Informazioni sugli autori

Hamza Nadeem è un Amazon Connect Specialist Solutions Architect presso AWS, con sede a Toronto. Lavora con clienti in tutto il Canada per modernizzare i loro contact center e fornire soluzioni alle sfide specifiche di coinvolgimento dei clienti e ai requisiti aziendali. Nel tempo libero, Hamza ama viaggiare, giocare a calcio e provare nuove ricette con sua moglie.

Parag Srivastava è un Solutions Architect presso Amazon Web Services (AWS), che aiuta i clienti aziendali ad adottare e migrare con successo il cloud. Durante la sua carriera professionale, è stato ampiamente coinvolto in complessi progetti di trasformazione digitale. È anche appassionato di costruire soluzioni innovative intorno agli aspetti geospaziali degli indirizzi.

Ross Ahimè è un Solutions Architect presso AWS con sede a Toronto, Canada. Aiuta i clienti a innovare con soluzioni AI/ML e AI generativa che portano a risultati aziendali reali. Ha lavorato con una varietà di clienti del settore vendita al dettaglio, servizi finanziari, tecnologia, farmaceutico e altri. Nel tempo libero ama la vita all'aria aperta e godersi la natura con la sua famiglia.

Sangeetha Kamatkar è un Solutions Architect presso Amazon Web Services (AWS), che aiuta i clienti nell'adozione e nella migrazione del cloud con successo. Collabora con i clienti per creare architetture cloud altamente scalabili, flessibili e resilienti che risolvano i problemi aziendali dei clienti. Nel tempo libero ascolta musica, guarda film e si dedica al giardinaggio durante l'estate.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/enhance-amazon-connect-and-lex-with-generative-ai-capabilities/