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 a su centro de contacto de Amazon Connect funcionalidades de chatbot, como capacidades de reconocimiento automático de voz (ASR) y 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.
Amazon Bedrock 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. Los FM entregados por Amazon Bedrock, como Amazon Titan y Anthropic Claude, 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.
Descripción general de la solución
La solución utiliza Amazon Connect, Amazon Lex, AWS Lambda y Amazon Bedrock en los siguientes pasos:
- Un flujo de contacto de Amazon Connect se integra con un bot de Amazon Lex a través de
GetCustomerInput
bloquear. - 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.
- 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.
- Utilizando sus capacidades avanzadas de lenguaje natural, el modelo determina la intención de la persona que llama.
- 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 LangChainque 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.
Una vez invocado el modelo, recibimos la siguiente respuesta del modelo básico:
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
en el “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:
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 Cerca se devuelve para indicarle a Amazon Lex que cierre el FallbackIntent
y devuelva el control a Amazon Connect. El resultado de la respuesta es el siguiente:
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:
- Clonar el repositorio
- Ejecute el siguiente comando para inicializar el entorno y crear un repositorio de Amazon Elastic Container Registry (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.
- Actualizar el
ParameterValue
campos en elscripts/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.
- Ejecute el comando para generar la pila de CloudFormation e implementar los recursos:
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
.
- Inicie sesión en su Instancia de conexión de Amazon. A la cuenta se le debe asignar un perfil de seguridad que incluya permisos de edición para flujos.
- En la consola de Amazon Connect, en el panel de navegación, en Enrutamientoelegir Flujos de contacto.
- Crea un nuevo flujo del mismo tipo que el que estás importando.
- Elegir Guardar e importar flujo.
- Seleccione el archivo a importar y elija Importar.
Cuando el flujo se importa a un flujo existente, el nombre del flujo existente también se actualiza.
- Revise y actualice las referencias resueltas o no resueltas según sea necesario.
- Para guardar el flujo importado, elija Ahorrar. Para publicar, elija Guardar y publicar.
- 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.
- Actualizar el
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
ajustado a Active
para poder ejecutar la función siempre que el FallBackIntent
se desencadena.
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:
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 Implementación de respuestas a preguntas de autoservicio con la solución QnABot en AWS impulsada por Amazon Lex con Amazon Kendra y modelos de lenguaje grandes.
Sobre 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 arquitecto de soluciones en Amazon Web Services (AWS), y ayuda a los clientes empresariales con la adopción y migración exitosa de la nube. Durante su carrera profesional ha estado ampliamente involucrado en proyectos complejos de transformación digital. También le apasiona crear 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.