Habilidad B2B de Alice: del prototipo al primer rublo guardado

No hace mucho tiempo, en San Petersburgo, se celebró la segunda conferencia de Conversaciones , dedicada a la IA conversacional, en la que tuve la suerte de hablar como orador. El tema fue desarrollar un prototipo de habilidad B2B para una gran empresa. El informe describió cómo lograron "hacer amigos" con los servicios web relativamente lentos y la infraestructura cerrada de la empresa. Esto se discutirá debajo del corte.

Si de repente no sabes cuáles son las habilidades de Alice, mira debajo del spoiler: describe brevemente qué es qué.

Idea

¿Cómo empezó todo? El 13 de marzo de 2018, anunciaron la prueba beta de la plataforma Yandex.Dialogs (habilidades de Alice). En ese momento, muchos ya estaban interesados ​​en el asistente virtual, lo que significa que era una gran oportunidad para trabajar con una audiencia bastante grande. La idea de un bot de chat ha estado girando en mi cabeza durante mucho tiempo, así que decidí que sería interesante hacer algo de habilidad en su tiempo libre en función de ello. Y si también puede aportar beneficios en el trabajo, generalmente será excelente.

Nuestra empresa ofrece una gama completa de servicios en el campo del turismo de negocios, lo que significa que puede desarrollar una habilidad que ayuda al usuario a realizar un viaje de negocios.
Luego estuve en el equipo para el desarrollo de una aplicación móvil, con la que puede encontrar opciones de vuelo y hoteles para viajes de negocios, y organizar los adecuados. Uno de los indicadores clave, por el que luchamos para aumentar, fue la cantidad de descargas. Surgió la idea de que si la habilidad llevará a los usuarios a la aplicación, entonces nos ayudará a aumentar estos indicadores. Esto fue necesario para verificar el uso de este proyecto.

Para que una habilidad sea útil para cualquiera, debe resolver una tarea específica del usuario. En este caso, busque opciones para un viaje de negocios. Es decir, la habilidad debe reunir información sobre dónde ir y mostrar los resultados en una aplicación móvil. Por lo tanto, el usuario recibirá las opciones deseadas utilizando una interacción de voz interesante y continuará trabajando en nuestra aplicación, lo que significa que los desarrolladores recibirán el aumento deseado en el rendimiento.

Resulta que la habilidad debería funcionar de esta manera: saludar al usuario; encuéntralo por su nombre; haga preguntas aclaratorias y, por lo tanto, obtenga los parámetros de viaje necesarios: ciudades (de dónde y dónde) y fechas. A continuación se muestran los parámetros reconocidos. Si todo está correcto, inicie la búsqueda y proporcione un enlace a la aplicación.

Recursos y limitaciones

Para completar su tarea, la habilidad debe interactuar con nuestras API internas, y su servicio web debe publicarse en algún lugar. Por un lado, podría colocarse en el trabajo, pero, como ya se mencionó, el desarrollo se llevó a cabo en el tiempo libre, por lo tanto, no quería depender de ningún recurso de la empresa especialmente asignado. Entonces, tenía que aprovechar lo que está disponible por defecto.

Por ejemplo, un servidor de prueba. Los desarrolladores tienen suficientes derechos para implementar una aplicación web en ella, pero solo estará disponible en la red interna de la compañía, porque el servidor no sobresale. Al mismo tiempo, tiene acceso a Internet, lo que significa que se puede usar.

El servicio web de habilidades debe ser accesible desde el exterior (para que Alice tenga a dónde enviar las solicitudes), por lo que debe colocarse en un alojamiento externo.

Para que la habilidad pueda cumplir con su tarea, necesita un servicio web de la empresa que pueda buscar perfiles y ciudades, y que sea accesible desde el exterior. La API de la aplicación móvil es adecuada para esto, aunque tiene sus propios matices. Consisten en el hecho de que puede conectarse a la API en nombre de un solo usuario específico, lo que significa que el rango de perfiles disponibles para la búsqueda será limitado. Y lo más desagradable: los resultados de una búsqueda lanzada a través de la API solo llegarán a este usuario. Sin embargo, tiene la funcionalidad necesaria, lo que significa que puede trabajar con él.

Entonces, la habilidad en el alojamiento externo interactuará con la API. Por supuesto, es bastante rápido, pero a veces, según los resultados de la prueba, la respuesta no tiene tiempo para llegar a los 1500 ms requeridos (este es el requisito de la plataforma Yandex.Dialogs). Y para poder enviar los resultados al usuario correcto, debe ejecutar un servicio de búsqueda en su nombre, que solo está disponible en la red interna. La API, desafortunadamente, no ayudará en esto, lo que significa que necesita transferir de alguna manera la solicitud de la habilidad directamente a la infraestructura interna.
Resolveremos estos problemas a medida que estén disponibles.

Etapas Problemas y soluciones

Para comenzar, para implementar generalmente el escenario descrito, la habilidad necesita almacenar el estado en algún lugar: etapa, nombre de usuario, ciudad y fecha. No hay mucha información, por lo que no debe implementar una base de datos completa, especialmente porque hay demasiado alboroto con ella. Puede almacenar el estado en el caché.

La elección recayó en Redis . Se mostró bien en las pruebas de respuesta, y también lo usamos estrictamente en el trabajo, lo que significa que si tiene éxito, este proyecto puede transferirse fácilmente a la empresa (y al spoiler, lo cambiamos). Como clave, puede usar el identificador de usuario en la habilidad (indicado en la solicitud) y almacenar los datos de estado en el formato JSON en el valor. Se puede implementar una copia gratuita de Redis en Heroku , y desde hace algún tiempo se admite en Yandex.Cloud .

Ahora analizaremos las etapas de la habilidad con más detalle. En el primer inicio, el usuario ve la frase de bienvenida habitual. Luego, debe nombrar su nombre, según el cual la habilidad buscará un perfil.



Si existe, entonces su nombre debe escribirse en el estado y, dado que se utiliza la memoria caché, se puede incluir el resto de la información necesaria sobre el perfil. Ahora, cuando el cliente regrese a la habilidad, verá un saludo personal. Si la misma persona inicia sesión desde otro dispositivo y nombra su nombre, su perfil también se encontrará en la memoria caché, lo que significa que evitaremos buscar nuevamente a través de la API, lo que ahorra tiempo al procesar la solicitud.

A continuación, se reciben los parámetros del viaje. Como usuario de habilidades de voz, quiero nombrar ciudades y fechas como quiera, por ejemplo, "Peter" y "en una semana". La habilidad debe ser capaz de reconocer tales frases para transferir el nombre completo de la ciudad en la API y realizar una búsqueda en el día deseado. Ahora el servicio web de habilidades recibe inmediatamente esta información directamente en la solicitud:



Pero tal característica apareció alrededor de octubre de 2018, y la habilidad se desarrolló un poco antes, por lo que se eligió Dialogflow para comprender el lenguaje natural. Tiene un excelente sistema de marcado, y de vez en cuando puedes venir a entrenarlo, indicando lo que el usuario quiso decir en una frase dada.

Entonces, el cliente nombra la ciudad y la fecha a su manera, la habilidad pasa sus palabras a Dialogflow y envía el nombre de la ciudad reconocida a la API, desde donde recibe el identificador necesario. La cadena es larga y, por lo tanto, nuevamente es probable que no cumpla con los 1500 ms requeridos.

La solución obvia es almacenar en caché. Y como clave, puede especificar exactamente lo que dijo el usuario, y en el valor almacenar el identificador de ciudad de nuestro sistema. Luego, en el caché puede haber varias entradas para una ciudad, por ejemplo, para las palabras "Peter" y "St. Petersburg". Pero esto no es crítico si el valor no indica demasiada información. En cualquier caso, este enfoque permitirá llenar el caché con ciudades populares solicitadas por otros usuarios, o "calentarlo" de antemano. Esto le permitirá usar Dialogflow y la API con menos frecuencia en el futuro, lo que le ahorrará tiempo nuevamente.

El paso más interesante es comenzar la búsqueda. Existen todos los parámetros necesarios, pero para que los resultados lleguen a la persona adecuada, de alguna manera debe "extraer" el servicio de búsqueda interno. Además, la búsqueda en sí misma lleva bastante tiempo, y las operaciones a largo plazo se realizan mejor no en el mismo servicio web, sino en una aplicación separada.

Es hora de usar el servidor disponible de la compañía. En él puede implementar una aplicación que de alguna manera "tomará" información del exterior y realizará tareas a largo plazo, incluida la iniciación de una búsqueda.

Tal aplicación bien podría ser un servicio en segundo plano.

Por el nombre, está claro que esta es una aplicación sin una interfaz de usuario, que debe comenzar su trabajo junto con el inicio del servidor y realizar las acciones planificadas, o acciones en un comando (mensaje) específico. Por lo general, organizamos dicho servicio en el marco de Topshelf , y puede recibir comandos, por ejemplo, de una cola de mensajes basada en el protocolo AMQP .

En resumen, la cola funciona más o menos así: hay un intermediario en el que los remitentes agregan mensajes de cierto tipo. Y hay lectores que se conectan al corredor y obtienen la información necesaria.
Se puede encontrar una descripción más detallada, por ejemplo, en este artículo .

Se encontró una buena solución en la nube en Internet, que proporcionaba una cola de mensajes como servicio: CloudAMQP . Tiene una tarifa gratuita, pero funciona de manera estable. Otro argumento para su elección es que este servicio funciona sobre la base de RabbitMQ , que también utilizamos mucho en el trabajo.

Entonces, echemos un vistazo al trabajo de la habilidad en su conjunto: el servicio web de habilidades interactúa con la API de la aplicación móvil y Dialogflow. Los resultados de las llamadas a ellos se almacenan en caché en Redis, y el estado se almacena allí. Después de confirmar los parámetros del viaje, la habilidad envía un mensaje al corredor con toda la información necesaria. El servicio en segundo plano del servidor de prueba se conecta a él y, cuando aparece un mensaje, comienza la búsqueda y los resultados se envían a la aplicación móvil.


Cuando el cliente lo descarga e instala, los encontrará en sus solicitudes:



Esto completa el trabajo de la habilidad.

Resumen

¿Qué pasó después? Esta habilidad se mostró a varios clientes para obtener comentarios, y esto es lo que descubrimos: los propios usuarios son reacios a cambiar a una aplicación móvil, sin importar cuán genial sea. Para algunos de ellos es más fácil llamar a nuestro agente por teléfono y pedirle que busque lo que necesita.

Como muestra la práctica, en este caso particular, los usuarios están más interesados ​​en interactuar con un asistente de voz. En este caso, reemplaza al agente, lo que le permite ahorrar un poco de tiempo y, al mismo tiempo, motiva a los clientes a descargar la aplicación para continuar trabajando con las opciones que contiene.

Resulta que, gracias a la habilidad, es posible ahorrar ciertos recursos y aumentar algunos indicadores clave, es decir, se confirmó el supuesto del beneficio de la habilidad para nuestra empresa.

Me gustaría enfatizar algunas conclusiones. Obvio: para mantenerse al día con 1500 ms, evite realizar solicitudes innecesarias de servicios web, caché. Puede usar diferentes claves de caché para la misma información. Esto se justifica si al menos una persona ingresa al caché generado por otro usuario. Y lo más importante: es mejor realizar operaciones prolongadas en un servicio de fondo separado: además del hecho de que proporciona descentralización de la habilidad, tendrá menos problemas con el subprocesamiento múltiple y, si es necesario, puede "desplegarse" dentro de la red cerrada de la compañía y "recoger" mensajes desde el exterior.

En lugar de un epílogo

Los chatbots y las habilidades a menudo se escriben en JavaScript y Python (a juzgar por la cantidad de repositorios en GitHub para "chatbot"). Esto también se debe a la fácil publicación en el servidor. Este proyecto fue escrito en C # bajo .net core. En el caso del marco .net clásico, existen ciertas dificultades con la publicación (funciona principalmente en Windows, etc.), pero mucho ha cambiado con la llegada del núcleo .net. Para cada servicio o marco mencionado anteriormente, hay bibliotecas que admiten totalmente esta tecnología. Gracias a esto, la habilidad se puede ejecutar potencialmente en servidores Linux, y aún más en cualquier alojamiento que admita Docker. Si de repente está en una búsqueda creativa, le recomiendo que preste atención a este marco, se convierte en una buena alternativa para desarrollar bots de chat.

PS
UPD 08/01/2019: a partir de ahora, el tiempo de espera para las habilidades es de 3 segundos .