Las opciones de autoservicio efectivas son cada vez más críticas para los centros de contacto, pero implementarlas bien presenta desafíos únicos.

Amazon lex proporciona su Amazon conectar centro de contacto con funcionalidades de chatbot como reconocimiento automático de voz (ASR) y capacidades de comprensión del lenguaje natural (NLU) a través de canales de voz y texto. El bot toma voz o texto en lenguaje natural, reconoce la intención detrás de la entrada y cumple la intención del usuario al invocar la respuesta adecuada.

Las personas que llaman pueden tener diversos acentos, pronunciación y gramática. Combinado con el ruido de fondo, esto puede dificultar que el reconocimiento de voz comprenda las declaraciones con precisión. Por ejemplo, "Quiero realizar un seguimiento de mi pedido" puede confundirse con "Quiero transportar a mi titular". Intentos fallidos como estos frustran a los clientes que tienen que repetir lo que dicen, ser enrutados incorrectamente o ser remitidos a agentes en vivo, lo que cuesta más a las empresas.

lecho rocoso del amazonas democratiza el acceso al modelo fundamental (FM) para que los desarrolladores creen y escalen sin esfuerzo aplicaciones generativas basadas en IA para el centro de contacto moderno. FM entregados por Amazon Bedrock, como Titán Amazonas y Claude antrópico, están previamente entrenados en conjuntos de datos a escala de Internet que les brindan sólidas capacidades NLU, como clasificación de oraciones, preguntas y respuestas, y una comprensión semántica mejorada a pesar de los errores de reconocimiento de voz.

En esta publicación, exploramos una solución que utiliza FM entregados por Amazon Bedrock para mejorar el reconocimiento de la intención de Amazon Lex integrado con Amazon Connect y, en última instancia, brindar una experiencia de autoservicio mejorada para sus clientes.

Resumen de la solución

La solución utiliza Amazon conectar, Amazon lex , AWS Lambday lecho rocoso del amazonas en los siguientes pasos:

1. Un flujo de contacto de Amazon Connect se integra con un bot de Amazon Lex a través de GetCustomerInput bloquear.
2. Cuando el bot no reconoce la intención de la persona que llama y utiliza de forma predeterminada la intención alternativa, se activa una función Lambda.
3. La función Lambda toma la transcripción de la expresión del cliente y la pasa a un modelo básico en Amazon Bedrock.
4. Utilizando sus capacidades avanzadas de lenguaje natural, el modelo determina la intención de la persona que llama.
5. Luego, la función Lambda indica al bot que dirija la llamada a la intención correcta para su cumplimiento.

Al utilizar los modelos básicos de Amazon Bedrock, la solución permite que el bot de Amazon Lex comprenda las intenciones a pesar de los errores de reconocimiento de voz. Esto da como resultado un enrutamiento y un cumplimiento sin problemas, evitando derivaciones a los agentes y repeticiones frustrantes para las personas que llaman.

El siguiente diagrama ilustra la arquitectura y el flujo de trabajo de la solución.

En las siguientes secciones, analizamos los componentes clave de la solución con más detalle.

Funciones Lambda y LangChain Framework

Cuando el bot de Amazon Lex invoca la función Lambda, envía un mensaje de evento que contiene información del bot y la transcripción de la expresión de la persona que llama. Al utilizar este mensaje de evento, la función Lambda recupera dinámicamente las intenciones configuradas, la descripción de la intención y las expresiones de intención del bot y crea un mensaje usando LangChain, que es un marco de aprendizaje automático (ML) de código abierto que permite a los desarrolladores integrar grandes modelos de lenguaje (LLM), fuentes de datos y aplicaciones.

Luego se invoca un modelo de base de Amazon Bedrock mediante el mensaje y se recibe una respuesta con la intención y el nivel de confianza previstos. Si el nivel de confianza es mayor que un umbral establecido, por ejemplo 80 %, la función devuelve la intención identificada a Amazon Lex con una acción para delegar. Si el nivel de confianza está por debajo del umbral, el valor predeterminado vuelve al valor predeterminado. FallbackIntent y una acción para cerrarlo.

Aprendizaje en contexto, ingeniería rápida e invocación de modelos.

Utilizamos el aprendizaje en contexto para poder utilizar un modelo básico para realizar esta tarea. El aprendizaje en contexto es la capacidad que tienen los LLM de aprender la tarea utilizando solo lo que está en el mensaje sin estar previamente capacitados o ajustados para la tarea en particular.

En el mensaje, primero proporcionamos las instrucciones que detallan lo que se debe hacer. Luego, la función Lambda recupera e inyecta dinámicamente las intenciones configuradas, las descripciones de intención y las expresiones de intención del bot de Amazon Lex en el mensaje. Finalmente, le brindamos instrucciones sobre cómo generar su pensamiento y resultado final.

La siguiente plantilla de mensaje se probó en los modelos de generación de texto Anthropic Claude Instant v1.2 y Anthropic Claude v2. Usamos etiquetas XML para mejorar mejor el rendimiento del modelo. También agregamos espacio para que el modelo piense antes de identificar la intención final para mejorar su razonamiento para elegir la intención correcta. El {intent_block} contiene los ID de intención, las descripciones de intención y las expresiones de intención. El {input} El bloque contiene la expresión transcrita de la persona que llama. Se agregan tres comillas invertidas (“`) al final para ayudar al modelo a generar un bloque de código de manera más consistente. A <STOP> Se agrega una secuencia para evitar que se genere más.

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

Una vez invocado el modelo, recibimos la siguiente respuesta del modelo básico:

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

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

Filtrar intenciones disponibles según los atributos de la sesión de flujo de contacto

Al utilizar la solución como parte de un flujo de contacto de Amazon Connect, puede mejorar aún más la capacidad del LLM para identificar la intención correcta especificando el atributo de sesión. available_intents existentes "Obtener opiniones de los clientes" bloque con una lista de intenciones separadas por comas, como se muestra en la siguiente captura de pantalla. Al hacerlo, la función Lambda solo incluirá estas intenciones especificadas como parte del mensaje al LLM, lo que reducirá la cantidad de intenciones que el LLM tiene que razonar. Si el available_intents Si no se especifica el atributo de sesión, se utilizarán todas las intenciones del bot de Amazon Lex de forma predeterminada.

Respuesta de la función Lambda a Amazon Lex

Una vez que el LLM ha determinado la intención, la función Lambda responde en el formato específico requerido por Amazon Lex para procesar la respuesta.

Si se encuentra una intención coincidente por encima del umbral de confianza, se devuelve un tipo de acción de diálogo Delegate para indicarle a Amazon Lex que utilice la intención seleccionada y posteriormente devuelva la intención completa a Amazon Connect. El resultado de la respuesta es el siguiente:

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

Si el nivel de confianza está por debajo del umbral o no se reconoció una intención, se mostrará un tipo de acción de diálogo Cerrar se devuelve para indicarle a Amazon Lex que cierre el FallbackIntenty devuelva el control a Amazon Connect. El resultado de la respuesta es el siguiente:

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

El código fuente completo de este ejemplo está disponible en GitHub.

Requisitos previos

Antes de comenzar, asegúrese de tener los siguientes requisitos previos:

Implementar la solución

Para implementar la solución, complete los siguientes pasos:

1. Clonar el repositorio

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

2. Ejecute el siguiente comando para inicializar el entorno y crear un Registro de contenedores elásticos de Amazon (Amazon ECR) para la imagen de nuestra función Lambda. Proporcione la región de AWS y el nombre del repositorio de ECR que desea crear.

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

3. Actualizar el ParameterValue campos en el scripts/parameters.json archivo:
   • ParameterKey ("AmazonECRImageUri") – Ingrese la URL del repositorio del paso anterior.
   • ParameterKey ("AmazonConnectName") – Introduzca un nombre único.
   • ParameterKey ("AmazonLexBotName") – Introduzca un nombre único.
   • ParameterKey ("AmazonLexBotAliasName") – El valor predeterminado es “prodversión”; puedes cambiarlo si es necesario.
   • ParameterKey ("LoggingLevel") – El valor predeterminado es “INFORMACIÓN”; puedes cambiarlo si es necesario. Los valores válidos son DEBUG, WARN y ERROR.
   • ParameterKey ("ModelID") – El valor predeterminado es “anthropic.claude-instant-v1”; puedes cambiarlo si necesitas usar un modelo diferente.
   • ParameterKey ("AmazonConnectName") – El valor predeterminado es “0.75”; puede cambiarlo si necesita actualizar la puntuación de confianza.
4. Ejecute el comando para generar la pila de CloudFormation e implementar los recursos:

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

Si no desea crear el flujo de contacto desde cero en Amazon Connect, puede importar el flujo de muestra proporcionado con este repositorio. filelocation: /contactflowsample/samplecontactflow.json.

1. Inicia sesión en tu Instancia de Amazon Connect. A la cuenta se le debe asignar un perfil de seguridad que incluya permisos de edición para flujos.
2. En la consola de Amazon Connect, en el panel de navegación, en enrutamiento, escoger Flujos de contacto.
3. Crea un nuevo flujo del mismo tipo que el que estás importando.
4. Elige Guardar e importar flujo.
5. Seleccione el archivo a importar y elija Importa.

Cuando el flujo se importa a un flujo existente, el nombre del flujo existente también se actualiza.

1. Revise y actualice las referencias resueltas o no resueltas según sea necesario.
2. Para guardar el flujo importado, elija Guardar. Para publicar, elija Guardar y publicar.
3. Después de cargar el flujo de contacto, actualice las siguientes configuraciones:
   • Actualizar el GetCustomerInput bloques con el nombre y la versión correctos del bot de Amazon Lex.
   • En Administrar número de teléfono, actualice el número con el flujo de contacto o IVR importado anteriormente.

Verificar la configuración

Verifique que la función Lambda creada con la pila de CloudFormation tenga una función de IAM con permisos para recuperar bots e información de intención de Amazon Lex (permisos de lista y lectura) y permisos adecuados de Amazon Bedrock (permisos de lista y lectura).

En su bot de Amazon Lex, para su alias e idioma configurados, verifique que la función Lambda esté configurada correctamente. Para el FallBackIntent, confirma eso Fulfillmentis establecido en Active para poder ejecutar la función siempre que el FallBackIntent se activa

En este punto, su bot de Amazon Lex ejecutará automáticamente la función Lambda y la solución debería funcionar sin problemas.

Prueba la solución

Veamos un ejemplo de configuración de intención, descripción y expresión en Amazon Lex y veamos qué tan bien se desempeña el LLM con entradas de muestra que contienen errores tipográficos, gramaticales e incluso un idioma diferente.

La siguiente figura muestra capturas de pantalla de nuestro ejemplo. El lado izquierdo muestra el nombre de la intención, su descripción y una expresión de muestra de una sola palabra. Sin mucha configuración en Amazon Lex, el LLM puede predecir la intención correcta (lado derecho). En esta prueba, tenemos un mensaje de cumplimiento simple con la intención correcta.

Limpiar

Para limpiar sus recursos, ejecute el siguiente comando para eliminar el repositorio de ECR y la pila de CloudFormation:

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

Conclusión

Al utilizar Amazon Lex mejorado con LLM proporcionados por Amazon Bedrock, puede mejorar el rendimiento del reconocimiento de intenciones de sus bots. Esto proporciona una experiencia de autoservicio perfecta para un conjunto diverso de clientes, reduciendo la brecha entre acentos y características de habla únicas y, en última instancia, mejorando la satisfacción del cliente.

Para profundizar y aprender más sobre la IA generativa, consulte estos recursos adicionales:

Para obtener más información sobre cómo puede experimentar con la solución de autoservicio generativa impulsada por IA, consulte Implemente la respuesta de preguntas de autoservicio con la solución QnABot en AWS impulsada por Amazon Lex con Amazon Kendra y modelos de lenguaje de gran tamaño..

Acerca de los autores

Hamza Nadeem es un arquitecto de soluciones especializado en Amazon Connect en AWS, con sede en Toronto. Trabaja con clientes en todo Canadá para modernizar sus centros de contacto y brindar soluciones a sus desafíos comerciales y desafíos únicos de participación del cliente. En su tiempo libre, Hamza disfruta viajar, jugar al fútbol y probar nuevas recetas con su esposa.

Parag Srivastava es un arquitecto de soluciones en Amazon Web Services (AWS), que ayuda a los clientes empresariales a adoptar y migrar con éxito a la nube. Durante su carrera profesional, se ha involucrado ampliamente en proyectos complejos de transformación digital. También le apasiona la creación de soluciones innovadoras en torno a los aspectos geoespaciales de las direcciones.

ross alas es arquitecto de soluciones en AWS con sede en Toronto, Canadá. Ayuda a los clientes a innovar con soluciones de IA/ML e IA generativa que conducen a resultados comerciales reales. Ha trabajado con una variedad de clientes de comercio minorista, servicios financieros, tecnología, productos farmacéuticos y otros. En su tiempo libre le encanta el aire libre y disfrutar de la naturaleza con su familia.

Sangeetha Kamatkar es arquitecto de soluciones en Amazon Web Services (AWS), y ayuda a los clientes con la adopción y migración exitosa de la nube. Trabaja con los clientes para crear arquitecturas de nube altamente escalables, flexibles y resistentes que aborden los problemas comerciales de los clientes. En su tiempo libre, escucha música, mira películas y disfruta de la jardinería durante el verano.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/machine-learning/enhance-amazon-connect-and-lex-with-generative-ai-capabilities/