Nic Raboy es un defensor de las tecnologías modernas de desarrollo web y móvil. Tiene experiencia en Java, JavaScript, Golang y una variedad de frameworks como Angular, NativeScript y Apache Cordova. Nic escribe sobre sus experiencias de desarrollo relacionadas con facilitar la comprensión del desarrollo web y móvil.
No cabe duda de que el futuro va a ser automatizado. Tenemos vehículos autoconducidos automatizados, asistentes de voz, bots de centros de llamadas y de texto, y mucho más. Sin embargo, ¿qué hace falta para llevar la automatización a tu empresa?
La respuesta breve es que no hace falta mucho más que crear aplicaciones estándar si se utilizan las herramientas adecuadas.
En este tutorial vamos a explorar la creación de un chatbot que puede tomar parte de la carga de trabajo de sus empleados humanos mediante el aprovechamiento de Amazon Lex para el aprendizaje profundo y las interfaces conversacionales, Couchbase NoSQL como base de datos, y Node.js para interactuar con la base de datos.
Requisitos para este tutorial
Hay algunos requisitos de software que deben cumplirse para tener éxito con este tutorial y proyecto:
- Couchbase Server 5.0+ debe estar instalado y disponible remotamente.
- Una cuenta AWS.
- Docker o un software de máquina virtual.
Dado que utilizaremos productos de Amazon como Lex y Lambda, es necesario disponer de una cuenta de AWS. Ambos productos son de pago, por lo que un nivel gratuito será más que suficiente. Como usaremos productos de Amazon, estos productos necesitan acceso a Couchbase. Por esta razón, Couchbase no puede ejecutarse desde localhost, debe instalarse en algún lugar remoto. Por último, dado que el SDK de Couchbase Node.js utiliza dependencias nativas, Docker o algún otro software de máquina virtual debe estar disponible para descargar las dependencias como Linux, que es lo que espera Lambda.
Configuración de Amazon Lex para la interacción con el usuario
Antes de entrar en el código, podemos dedicar nuestro tiempo a configurar Lex. Aunque Lambda nos permitirá hacer nuestro bot útil, no necesitas ningún tipo de backend para jugar con Lex.
Ir a Lex en tu portal de AWS y elige crear un nuevo bot personalizado.
Como estamos creando un bot basado en texto, la voz de salida debería ser ninguna. Todo lo demás deben ser los valores predeterminados o lo que considere más apropiado.
Con el bot personalizado creado, el primer paso es empezar a crear intents. Para este ejemplo vamos a crear un Acerca deIntent, GetProfileIntent y UpgradeServiceIntentdos de los cuales utilizarán Couchbase para obtener información.
Empecemos por el Acerca deIntent.
La idea que subyace a la Acerca deIntent es sólo para empezar. No usaremos la base de datos para esta intent, pero eventualmente se conectará a nuestra función Lambda. Esta intent es para darnos información sobre el bot.
Para activar nuestra intención, necesitamos definir algunos enunciados de ejemplo que son básicamente una lista de frases posibles. Tomemos como ejemplo las siguientes:
|
1 2 3 |
que hecho este chatbot qué puede usted dile a me acerca de usted mismo dé me información acerca de este bot |
Las frases anteriores son las que podría preguntar un usuario. Cuantas más, mejor, porque Lex aprenderá de los datos de entrenamiento y podrá rellenar los huecos si alguien pregunta algo que no está en la lista.
Por ahora dejaremos Cumplimiento como Devolver los parámetros al clientepero eventualmente lo cambiaremos a Lambda.
Echemos un vistazo a GetProfileIntent ahora.
Esta intención es un poco diferente porque queremos ser capaces de aceptar información dinámica del usuario, algo que cambiará entre diferentes usuarios. Podemos permitir información dinámica a través de variables de ranura.
Tome como ejemplo los siguientes enunciados que contienen variables de ranura:
|
1 2 |
i necesita algunos información acerca de mi cuenta consiga me algunos información acerca de mi cuenta {AccountId} |
No es necesario que todas las expresiones de ejemplo contengan variables de ranura, pero observe que la variable va entre llaves. Cada variable utilizada puede definirse en la configuración de la intención. Por ejemplo, nuestra AccountId se define como AMAZON.DirecciónEmail con una frase de aviso por defecto.
¿Qué significa esto?
Cuando Lex determina que nuestra variable de ranura existe, debe ser una dirección de correo electrónico válida. Si Lex determina que estamos tratando de ejecutar el comando GetProfileInfo pero la variable no existe, utilizará nuestra frase de aviso para pedir al usuario la información de esa variable. Esto hace que la conversación sea fluida, pero sin omitir ningún dato necesario.
Por último, veamos UpgradeServiceIntent.
En UpgradeServiceIntent es similar a nuestro GetProfileIntentpero esta vez tenemos dos posibles variables de ranura. Tomemos los siguientes ejemplos de enunciados:
|
1 2 |
iMe gustaría {Service} y la información de mi cuenta es {AccountId}. i'd como a actualizar mi servicio a {Servicio} |
Recuerda que dos enunciados de muestra no son suficientes, pero espero que te hagas una idea de cómo se pueden utilizar las variables. La idea es que quieres que la conversación con este chatbot sea fluida, como con una persona real, porque entonces puedes sustituir a la persona real por el bot.
Sin embargo, hay una excepción con el UpgradeServiceIntent variables de ranura. La dirección Servicio es una ranura personalizada que debemos crear.
En nuestro ejemplo queremos crear un CustomServiceSlot donde el nombre no es importante, pero los datos sí. Queremos definir las cosas posibles que pueden existir dentro de la variable. En nuestro ejemplo estamos diciendo que la ranura puede ser cualquiera de los siguientes:
- Plata
- Oro
- Lo último en
Suponemos que los tres puntos anteriores son posibles servicios. Esto es solo un ejemplo y sus necesidades pueden variar.
En este momento puedes guardar cada uno de los tres intentos y construir tu bot.
Desarrollo de la lógica de AWS Lambda con JavaScript simple y Couchbase
Ya tenemos nuestros intentos, nuestras expresiones de ejemplo y nuestras variables de ranura. Es hora de crear la lógica para responder a nuestro usuario cuando los intentos se activan.
Ya deberías tener Couchbase instalado, configurado y listo para funcionar. El objetivo de este tutorial no es cómo configurar Couchbase, sino cómo usarlo con Lex.
Dentro de Couchbase, añade el siguiente documento a tu Bucket:
|
1 2 3 4 |
{ "email": "test@test.com", "servicio": "Plata" } |
Vamos a suponer que el documento anterior es un cliente y que actualmente tiene el plan "Plata", signifique lo que signifique. En teoría, este ejemplo podría ser útil para cualquier organización que tenga una línea telefónica o de chat. Por ejemplo, piensa en Comcast para Internet. Si creas un bot, tus usuarios podrían llamar o chatear y solicitar cambios en su cuenta. El bot podría interpretar esto y hacer los cambios sin que una persona los hiciera.
En tu ordenador, crea un nuevo directorio y ejecuta lo siguiente:
|
1 2 3 |
npm init -y npm instale git+https://github.com/couchbase/couchnode.git#v2.5.1 --save toque índice.js |
Los comandos anteriores crearán un nuevo paquete.json e instale el SDK de Couchbase. Estamos utilizando la URL de GitHub por razones de que tiene dependencias nativas que necesitan ser construidos a partir de la fuente. Si usted no tiene el toque crear un index.js manualmente.
Dentro del index.js añada el siguiente código:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
const Couchbase = requiere("couchbase"); var grupo, cubo; const expedidor = async (evento) => { deje respuesta = { "dialogAction": { "tipo": "Cerrar", "fulfillmentState": "", "mensaje": { "tipo de contenido": "PlainText", "contenido": "" } } }; deje cbResultado; interruptor(evento.currentIntent.nombre) { por defecto: respuesta.dialogAction.fulfillmentState = "Fracasado"; respuesta.dialogAction.mensaje.contenido = "No se ha podido entender la petición".; romper; } devolver respuesta; } const manipulador = (evento) => { si(grupo == null || cubo == null) { grupo = nuevo Couchbase.Grupo("couchbase://COUCHBASE_HOST_HERE"); grupo.autentifique("COUCHBASE_USERNAME", "COUCHBASE_PASSWORD"); cubo = grupo.openBucket("COUCHBASE_BUCKET"); consola.registro(cubo); } devolver expedidor(evento); }; exportaciones.manipulador = manipulador; |
Hay algunas cosas a tener en cuenta en el código anterior. Sólo he añadido información para el host, nombre de usuario, contraseña y Bucket. Tendrás que sustituirla por la de tu instalación real de Couchbase.
Lo que está sucediendo arriba es que estamos creando una función Lambda con una función dispatcher. Cuando Lex recibe un mensaje de chat, crea un objeto request para enviarlo a Lambda. En nuestro escenario, Lambda toma el objeto request y lo introduce en un dispatcher después de establecer una conexión con la base de datos. Dentro del despachador, se crea un objeto de respuesta y se analiza la intención.
A partir de ahora todos los intentos son malos ya que sólo golpearán la condición por defecto. Vamos a cambiar eso.
Empecemos por preocuparnos Acerca deIntent ya que es la más sencilla:
|
1 2 3 4 5 6 7 8 9 10 |
interruptor(evento.currentIntent.nombre) { caso "SobreIntent": respuesta.dialogAction.fulfillmentState = "Cumplido"; respuesta.dialogAction.mensaje.contenido = "Creado por Nic Raboy, The Polyglot Developer"; romper; por defecto: respuesta.dialogAction.fulfillmentState = "Fracasado"; respuesta.dialogAction.mensaje.contenido = "No se ha podido entender la petición".; romper; } |
Si Lex determina que el usuario está pidiendo información y elige la opción Acerca deIntent vamos a responder con un mensaje básico, pero apropiado. De lo contrario, vamos a seguir fallando la solicitud.
Veamos ahora una intención más complicada, por ejemplo, la intención GetProfileIntent:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
caso "GetProfileIntent": cbResultado = await nuevo Promesa((resolver, rechace) => { deje declaración = "SELECT * FROM lexbot WHERE email = $email"; deje consulta = Couchbase.N1qlQuery.fromString(declaración); cubo.consulta(consulta, { correo electrónico: evento.currentIntent.ranuras.AccountId }, (error, resultado) => { si(error) { devolver rechace({ estado: "Fracasado", mensaje: error.mensaje }); } resolver({ estado: "Cumplido", mensaje: JSON.stringify(resultado) }); }); }); respuesta.dialogAction.fulfillmentState = cbResultado.estado; respuesta.dialogAction.mensaje.contenido = cbResultado.mensaje; romper; |
La idea detrás de esta intención es cuando el usuario pide información sobre su perfil, el documento debe ser devuelto. Lo que estamos haciendo es crear un Consulta N1QL con el correo electrónico como condición. Recuerde la Lex AccountId es sólo un correo electrónico para nuestro ejemplo. Los resultados de esa consulta se serializan y se devuelven a Lex para mostrárselos al usuario.
Ahora vamos a complicar las cosas un poco más. Veamos nuestro UpgradeServiceIntent:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
caso "UpgradeServiceIntent": cbResultado = await nuevo Promesa((resolver, rechace) => { deje declaración = ` ACTUALIZACIÓN lexbot SET servicio = $servicio DONDE correo electrónico = $correo electrónico `; deje consulta = Couchbase.N1qlQuery.fromString(declaración); cubo.consulta( consulta, { servicio: evento.currentIntent.ranuras.Servicio, correo electrónico: evento.currentIntent.ranuras.AccountId }, (error, resultado) => { si(error) { devolver rechace({ estado: "Fracasado", mensaje: error.mensaje }); } resolver({ estado: "Cumplido", mensaje: "El servicio se ha actualizado a " + evento.currentIntent.ranuras.Servicio + " por " + evento.currentIntent.ranuras.AccountId }); } ); }); respuesta.dialogAction.fulfillmentState = cbResultado.estado; respuesta.dialogAction.mensaje.contenido = cbResultado.mensaje; romper; |
Vamos a hacer otra consulta N1QL, pero esta vez una consulta ACTUALIZACIÓN funcionamiento. La idea es que el usuario quiera actualizar su servicio. Proporcionan la información de su cuenta y el servicio que desean, y nuestra lógica Lambda se encarga de ello sin intervención humana.
No estamos haciendo ningún saneamiento de datos, pero podríamos.
En este punto nuestra función Lambda está hecha. Podemos responder a tres consultas diferentes a través de un chat humano fluido con Lex. Ahora he mencionado que el SDK de Couchbase usa dependencias nativas. Como el foco de este tutorial no es Lambda, voy a referirte a un tutorial previo que escribí titulado, Implementación de dependencias de Node.js nativo en AWS Lambda.
Después de cargar el paquete Lambda, debe volver al panel de Lex y, para cada intento, elegir Función AWS Lambda como el Cumplimiento opción. Una vez hecho esto, reconstruye y tu chatbot debería obtener sus datos de tu código Lambda, que está obteniendo sus datos de Couchbase.
Conclusión
Acaba de ver cómo crear un chatbot sencillo pero potencialmente útil con Amazon Lex y Couchbase. Los chatbots son muy útiles y probablemente sean el futuro a la hora de sustituir a los humanos en los centros de llamadas u otras líneas de asistencia.
En un escenario de producción, probablemente querrá validar los datos de todo lo que llegue desde Lex. Por ejemplo, comprobar si los datos existen, o incluso hacer las cosas de forma más segura. En este ejemplo podría cambiar el servicio de cualquier persona con sólo proporcionar la dirección de correo electrónico. Probablemente querrá cambiar eso en producción.
Este artículo ha sido publicado por Couchbase Programa de escritura comunitaria
