Desarrollo de un asistente virtual empleando el framework Rasa

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Menci´ on en Ingenier´ ıa de Software Desarrollo de un asistente virtual empleando el framework Rasa Autor: Alberto Casta˜ neiras Folgueral Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Menci´ on en Ingenier´ ıa de Software Desarrollo de un asistente virtual empleando el framework Rasa Autor: Alberto Casta˜ neiras Folgueral Tutor: C´ esar Gonz´ alez Ferreras Resumen El desarrollo de asistentes virtuales y chatbots ha experimentado un crecimiento significativo en la ´ultima d´ecada, impulsado por avances en inteligencia artificial y comprensi´on del lenguaje natural (NLU). Este Trabajo de Fin de Grado explora esta evoluci´on mediante el desarrollo de un asistente utilizando el framework Rasa, reconocido por su flexibilidad y robustez en la creaci´on de soluciones de chatbot adaptadas a necesidades espec´ıficas. Rasa se destaca en el ´ambito de los asistentes virtuales por su capacidad para entrenar modelos de di´alogo contextual que pueden gestionar y responder de manera efectiva a interacciones complejas basadas en intenciones y entidades reconocidas. El enfoque del proyecto ha sido aprovechar las capacidades avanzadas de Rasa para desarrollar un asistente virtual cin´efilo que no solo ofrece recomendaciones personalizadas sobre pel´ıculas, sino que tambi´en facilita conversaciones fluidas y naturales con los usuarios. Integrado mediante la aplicaci´on de mensajer´ıa Telegram, el chatbot proporciona a los usuarios acceso a informaci´on detallada sobre pel´ıculas, que incluye tramas, elenco y equipo directivo, gracias a la API de la web TMDB, que es la fuente principal de datos del sistema. Esta interacci´on, potenciada por la comprensi´on del lenguaje natural, permite al asistente comprender y responder a consultas complejas, mejorando la accesibilidad y la experiencia del usuario. Los resultados del proyecto subrayan el impacto transformador de los chatbots, demostrando c´omo plataformas como Rasa pueden ser empleadas para superar limitaciones previas en la interacci´on hombre-m´aquina, y sugieren un futuro prometedor donde los asistentes virtuales juegan un papel clave en la mejora de la experiencia del cliente en diversos sectores. 3 4 Abstract The development of virtual assistants and chatbots has experienced significant growth in the last decade, driven by advances in artificial intelligence and natural language understanding (NLU). This thesis explores this evolution through the development of an assistant using the Rasa framework, recognized for its flexibility and robustness in the creation of chatbot solutions tailored to specific needs. Rasa stands out in the field of virtual assistants for its ability to train contextual dialogue models that can effectively manage and respond to complex interactions based on intentions and recognized entities. The focus of the project has been to leverage Rasa’s advanced capabilities to develop a cinephile virtual assistant that not only offers personalized movie recommendations, but also facilitates fluid and natural conversations with users. Integrated via the Telegram messaging app, the chatbot provides users with access to detailed movie information, including plots, cast and crew, thanks to the TMDB web API, which is the system’s primary source of data. This interaction, powered by natural language understanding, enables the assistant to understand and respond to complex queries, improving accessibility and user experience. The project results underscore the transformative impact of chatbots, demonstrating how platforms such as Rasa can be employed to overcome previous limitations in human-machine interaction, and suggest a promising future where virtual assistants play a key role in improving the customer experience in various sectors. 5 6 ´ Indice general 1. Introducci´on 16 1.1. Contexto......................................... 16 1.2. Motivaci´on........................................ 17 1.3. Objetivo......................................... 17 1.4. Estructura........................................ 18 2. Rasa Framework 20 2.1. Conceptos........................................ 20 2.1.1. NLU....................................... 20 2.1.2. Stories...................................... 22 2.1.3. Rules....................................... 22 2.1.4. Domain ..................................... 23 2.1.5. Slots....................................... 24 2.1.6. Responses.................................... 24 2.1.7. Forms ...................................... 25 2.1.8. Actions ..................................... 25 2.2. Configuraci´on...................................... 26 2.2.1. PipelineNLU .................................. 26 2.2.2. Policies ..................................... 28 2.3. Metodolog´ıaCDD.................................... 29 7 5.11.CU-011 ......................................... 79 5.12.RF-001.......................................... 79 5.13.RF-002.......................................... 80 5.14.RF-003.......................................... 80 5.15.RF-004.......................................... 80 5.16.RF-005.......................................... 80 5.17.RF-006.......................................... 81 5.18.RF-007.......................................... 81 5.19.RF-008.......................................... 81 5.20.RF-009.......................................... 82 5.21.RF-010.......................................... 82 5.22.RF-011.......................................... 82 5.23.RF-011.......................................... 83 5.24.RF-012.......................................... 83 5.25.RF-013.......................................... 83 5.26.RF-014.......................................... 83 5.27.RNF-001......................................... 84 5.28.RI-001.......................................... 84 5.29.RI-002.......................................... 84 5.30.RI-003.......................................... 84 5.31.RI-004.......................................... 85 5.32.Testusabilidad ..................................... 86 5.33.Testusabilidad2 .................................... 88 14 ´ Indice de c´odigos 4.1. Datos de entrenamiento para Saludar. . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2. Datos de entrenamiento para Despedirse. . . . . . . . . . . . . . . . . . . . . . . . 42 4.3. Datos de entrenamiento para Despedirse. . . . . . . . . . . . . . . . . . . . . . . . 43 4.4. Datos de entrenamiento Petici´on de pel´ıcula. . . . . . . . . . . . . . . . . . . . . . 47 4.5. Datos de entrenamiento. Lista de g´eneros. . . . . . . . . . . . . . . . . . . . . . . 48 4.6. Datos de entrenamiento. Formulario movie form . . . . . . . . . . . . . . . . . . . 49 4.7. Datos de entrenamiento. Solicitar resumen. . . . . . . . . . . . . . . . . . . . . . . 52 4.8. Datos de entrenamiento. Solicitar actores. . . . . . . . . . . . . . . . . . . . . . . 53 4.9. Datos de entrenamiento. Solicitar director. . . . . . . . . . . . . . . . . . . . . . . 54 4.10. Datos de entrenamiento. Historias complementarias. . . . . . . . . . . . . . . . . . 55 4.11. Datos de entrenamiento. Informaci´on actor/director. . . . . . . . . . . . . . . . . . 58 4.12. Datos de entrenamiento. Informaci´on pel´ıculas actor/director. . . . . . . . . . . . 59 4.13. Datos de entrenamiento. Plataformas streaming. . . . . . . . . . . . . . . . . . . . 62 4.14. Datos de entrenamiento. Out of scope. . . . . . . . . . . . . . . . . . . . . . . . . 64 4.15. Datos de entrenamiento. NLU fallback. . . . . . . . . . . . . . . . . . . . . . . . . 65 4.16. Datos de entrenamiento. Mejoras de di´alogo. . . . . . . . . . . . . . . . . . . . . . 66 4.17. Datos de entrenamiento. Cambiar de g´enero. . . . . . . . . . . . . . . . . . . . . . 67 4.18. Datos de entrenamiento. Cambiar de plataforma de streaming. . . . . . . . . . . . 68 B.1.Pasosdeinstalaci´on................................... 93 B.2.Pasosdeinstalaci´on................................... 94 B.3.Pasosdeinstalaci´on................................... 94 C.1. Ejemplo de redenciales chatbot para Telegram . . . . . . . . . . . . . . . . . . . . 97 D.1.Pasosdedespliegue................................... 98 D.2.Pasosngrok ....................................... 99 15 Cap´ıtulo 1 Introducci´on 1.1. Contexto El auge de los chatbots ha venido de la necesidad creciente de eficiencia operativa y mejora de la experiencia del cliente en numerosos sectores. Las empresas buscan constantemente maneras de optimizar la atenci´on al cliente, reducir tiempos de espera y costes, y ofrecer servicios accesibles las 24 horas del d´ıa. Los chatbots permiten automatizar respuestas a consultas comunes, manejar transacciones simples y proporcionar asistencia inmediata, lo que puede ser particularmente ´util fuera del horario laboral o durante picos de demanda. No todos los chatbots est´an equipados con Inteligencia Artificial (IA), pero los chatbots modernos utilizan cada vez m´as t´ecnicas de IA conversacional como el NLP para comprender las preguntas de los usuarios y automatizar las respuestas.[3] El Natural Language Processing (Procesamiento del Lenguaje Natural) (NLP) describe la capacidad de una m´aquina para ingerir lo que se le dice, descomponerlo y comprender cu´al es su significado. El objetivo es determinar una acci´on adecuada. El Natural Language Understanding (Comprensi´on del Lenguaje Natural) (NLU) es un subconjunto de NLP que trata con un ´area mucho m´as espec´ıfica. Se enfoca en c´omo manejar mejor las entradas no estructuradas para convertir estas en un formato estructurado, con t´ecnicas de NLU ayudamos a la m´aquina a comprender las conversaciones.[1] La habilidad de los chatbots basados en IA para procesar el lenguaje natural, as´ı como para ofrecer servicios personalizados de manera automatizada, aporta ventajas significativas tanto para las organizaciones como para sus clientes.[3] Disponibilidad: Operan ininterrumpidamente, 24 horas del d´ıa, los 7 d´ıas de la semana, garantizando una l´ınea de asistencia constante y sin interrupciones. Eficacia operativa: Alivian la carga de los agentes humanos gestionando consultas repetitivas, lo que les permite concentrarse en cuestiones m´as complejas y mejorar la calidad del servicio. 16 Reducci´on de costes: Reducen significativamente los gastos asociados con la operaci´on de centros de asistencia y la formaci´on de personal, al minimizar la dependencia de asistencia humana. Integraci´on: Se integran f´acilmente en una amplia variedad de plataformas, incluidas p´aginas web, y aplicaciones de mensajer´ıa como WhatsApp, Telegram, y Facebook Messenger. Esta flexibilidad permite que los chatbots est´en accesibles en el entorno habitual de los usuarios. Mejora de la experiencia del cliente: Ofrecen respuestas r´apidas y precisas, mejorando la satisfacci´on del cliente y reduciendo los tiempos de espera. Escalabilidad: Facilitan la gesti´on de grandes vol´umenes de interacciones simult´aneamente sin comprometer la calidad del servicio. Recolecci´on de datos: Pueden recoger datos de las interacciones con los usuarios, obteniendo valiosa informaci´on sobre productos o servicios, lo que facilita mejoras continuas. Soporte multiling¨ue: Ofrecen soporte en m´ultiples idiomas, eliminando barreras de comunicaci´on en un mercado global.[6] 1.2. Motivaci´on Los primeros chatbots eran esencialmente programas interactivos de preguntas frecuentes basados en un conjunto limitado de preguntas comunes con respuestas preescritas. Con el tiempo, han evolucionado hacia sistemas complejos capaces de gestionar interacciones detalladas, gracias a los avances en IA y NLP. En este contexto, el framework Rasa se destaca como una soluci´on potente por su flexibilidad y capacidad para crear chatbots que no solo responden preguntas, sino que tambi´en comprenden el contexto y las intenciones detr´as de las interacciones. Este Trabajo de Fin de Grado explora las capacidades avanzadas de Rasa desarrollando un asistente virtual especializado en cine, integrado a trav´es de Telegram y alimentado por datos de la API de la web TheMovieDatabase (https://www.themoviedb.org/) (TMDB). Adem´as, este proyecto ha marcado mi primer paso significativo en el mundo de la inteligencia artificial. Este enfoque pr´actico no solo ha enriquecido mi formaci´on acad´emica, sino que tambi´en ha encendido una chispa de curiosidad y posibilidad, abri´endome los ojos a nuevas formas de aplicar las tecnolog´ıas de IA y NLP en situaciones reales. 1.3. Objetivo A continuaci´on se exponen los principales objetivos que abarca este TFG: 17 1. Estudiar los conceptos b´asicos de los chatbots: Explorar la evoluci´on de los chatbots desde simples programas de preguntas frecuentes hasta sistemas avanzados que utilizan inteligencia artificial para manejar conversaciones complejas. 2. Analizar el framework Rasa: Estudiar las capacidades de Rasa como herramienta para el desarrollo de chatbots. Investigar c´omo se integran conceptos de inteligencia artificial como el procesamiento de lenguaje natural dentro del framework. 3. Desarrollar un asistente virtual cin´efilo utilizando Rasa: Dise˜no de conversaciones: Crear y optimizar conversaciones que el chatbot ser´a capaz de mantener con los usuarios. Esto incluye definir intenciones, acciones necesarias e historias para asegurar un flujo coherente en la interacci´on. Integraci´on con Telegram: Configurar Rasa para comunicarse con los usuarios a trav´es de la plataforma de mensajer´ıa Telegram. Extracci´on de informaci´on mediante la API de TMDB: Implementar la conexi´on y extracci´on de datos de pel´ıculas, incluyendo tramas, elenco y direcci´on, desde la API de TMDB para alimentar las respuestas del chatbot. Evaluaci´on del chatbot: Realizar pruebas con usuarios finales para evaluar la efectividad del chatbot. Analizar las conversaciones para identificar mejoras. 1.4. Estructura La memoria sigue la siguiente estructura: Cap´ıtulo 1. Introducci´on: Este cap´ıtulo expone el contexto, la motivaci´on y los objetivos del trabajo de fin de grado. Se explica la relevancia de los chatbots y la inteligencia artificial en la interacci´on actual entre humanos y m´aquinas. Cap´ıtulo 2. Rasa Framework: Aqu´ı se profundiza en el framework Rasa, explicando los conceptos clave, sus productos y la metodolog´ıa (Conversation-Driven Development (Desarrollo guiado por la conversaci´on) (CDD)). Adem´as, se detallan las herramientas que proporciona Rasa para el desarrollo de chatbots. Cap´ıtulo 3. Planificaci´on: Se describe el an´alisis, la planificaci´on y la estimaci´on de iteraciones del proyecto, junto con las fechas de entrega previstas. Este cap´ıtulo tambi´en aborda la metodolog´ıa de gesti´on de proyectos utilizada. Cap´ıtulo 4. Desarrollo: Este cap´ıtulo detalla el proceso de desarrollo del asistente virtual, incluyendo el dise˜no de conversaciones, la integraci´on con Telegram y la implementaci´on de la extracci´on de datos mediante la API de TMDB. Cap´ıtulo 5. Conclusiones y trabajo futuro: Se presentan las conclusiones del proyec- to, los resultados obtenidos y las recomendaciones para trabajos futuros. Se discuten las posibilidades de expansi´on del proyecto y las mejoras tecnol´ogicas propuestas. 18 Finalmente, se incluyen la bibliograf´ıa y los anexos del proyecto que complementan la investigaci´on realizada. 19 Cap´ıtulo 2 Rasa Framework Rasa Open Source es un framework dise˜nado para construir asistentes virtuales de alto rendimiento. La versi´on de Rasa utilizada para el desarrollo del TFG es Rasa 3.x 2.1. Conceptos Rasa utiliza ficheros YAML para almacenar sus datos de entrenamiento, incluyendo datos de NLU, historias y reglas. Los datos de entramiento en Rasa est´an organizados bajo claves. Las principales claves son: nlu,stories yrules 2.1. Cada archivo YAML puede contener m´ultiples claves, pero cada clave solo puede aparecer una vez por archivo. Rasa lee todos los ficheros YAML a su alcance y organiza el contenido por claves. 2.1.1. NLU Los datos de entrenamiento NLU en Rasa consisten en expresiones de los usuarios que se categorizan por intents (intenciones), que representan lo que un usuario intenta transmitir o lograr con su mensaje. Por ejemplo, una intenci´on podr´ıa ser request movie”donde el usuario busca que se le recomiende una pel´ıcula. Cada intenci´on se asocia con m´ultiples ejemplos de posibles expresiones que los usuarios podr´ıan usar para expresar esa intenci´on espec´ıfica. Esto permite al modelo de Rasa aprender y generalizar a partir de las variaciones en la forma de expresar una misma intenci´on. Adem´as, Rasa permite la anotaci´on de entities (entidades) dentro de los datos de entrenamiento. Las entidades son informaci´on espec´ıfica que se extrae de los mensajes (intents), como nombres, tel´efonos o fechas. Por ejemplo, en la intenci´on request movie”, una entidad podr´ıa incluir el g´enero 2.2. La identificaci´on correcta de estas entidades permite al chatbot elaborar respuestas m´as precisas al usuario. 20 Figura 2.1: Ejemplo de archivo YAML con claves Rasa: nlu, stories y rules Figura 2.2: Intent con entity movie genre Para facilitar la extraci´on de las entidades se pueden usar: Expresiones regulares (regex): si tu entidad tiene un estructura que puede ser descrita por una expresi´on regular, como n´umeros de tel´efonos, n´umeros de tarjetas de cr´edito, etc. Tablas de b´usqueda (lookup table): Las tablas de b´usqueda son listas de palabras que se utilizan para generar patrones de expresiones regulares insensibles a may´usculas y min´uscula. Todos los ejemplo en la tabla de b´usqueda se combinan en una gran expresi´on regular. Esta expresi´on regular se utiliza para comprobar si cada ejemplo de entrenamiento contiene coincidencias con las entradas de la tabla de b´usqueda. 2.3 Sin´onimos (synonym): Utilizados para mapear entidades extra´ıdas a un valor que podr´ıa ser diferente del texto literal extra´ıdo. Esto es ´util cuando diferentes entradas del usuario se refieren a la misma cosa bajo diferentes nombres. 2.3 La categorizaci´on efectiva de las intenciones y entidades en los datos de entrenamiento son fundamentales para el desempe˜no del sistema NLU en Rasa, permiti´endole comprender y responder de manera m´as efectiva a las interacciones del usuario. 21 Figura 2.3: Ejemplo de lookup table con synonym 2.1.2. Stories Las historias (stories) son un tipo de datos de entrenamiento utilizados para entrenar el modelo de gesti´on del di´alogo del asistente. Las stories pueden utilizarse para entrenar modelos capaces de generalizar rutas de conversaci´on desconocidas.[13] Cada story en Rasa se identifica por un nombre y se compone de una serie de pasos que simulan una interacci´on entre el usuario y el chatbot. Los pasos incluyen las intenciones del usuario, resultado del sistema NLU integrado en Rasa por lo que no hace falta lidiar con el contenido de los mensajes para construir una story, y acciones del chatbot. Las acciones a ejecutar por el chatbot se definen en el fichero domain. Existen dos tipos de acciones que el chatbot puede llevar a cabo las responses y las acciones personalizadas: Responses: Respuestas predefinidas que el bot puede enviar al usuario, como un mensaje de texto. Se suele proporcionar una bater´ıa de frases a enviar y el chatbot escoge una aleatoria. Acciones Personalizadas: Funciones escritas en Python, usando las librer´ıas que ofrece Rasa, que el chatbot puede ejecutar para realizar tareas m´as complejas, como consultar una base de datos o llamar a una API externa. Las stories son vitales para construir asistentes virtuales que pueden manejar di´alogos complejos y din´amicos. 2.1.3. Rules Las reglas son un tipo de datos de entrenamiento que se utilizan para entrenar el modelo de gesti´on de di´alogos de su asistente. Las reglas describen fragmentos breves de conversaciones 22 Figura 2.4: Ejemplo de regla: despedirse siempre que el usuario tenga intenci´on de despedirse que deben seguir siempre el mismo camino [12]. A diferencia de las historias que permiten cierta generalizaci´on y aprendizaje de patrones conversacionales m´as amplios, las reglas son ideales para gestionar patrones de conversaci´on peque˜nos y espec´ıficos. Para implementar una regla en Rasa, primero debes asegurarte de que la RulePolicy est´a incluida en la configuraci´on de tu modelo, hablaremos del fichero config m´as adelante. Esto permite que las reglas sean reconocidas y utilizadas por el asistente durante las conversaciones. A las reglas se le pueden aplicar condiciones, que son requisitos que deben cumplirse para que la regla sea aplicable. Es importante no sobrecargar tu asistente con demasiadas reglas, ya que esto puede limitar su capacidad para manejar entradas inesperadas de manera flexible. Las reglas deben ser combinadas con historias para crear un asistente robusto. Rules vs Stories Las reglas un tipo de datos de entrenamiento utilizados para manejar trozos de conversaciones que deben seguir siempre el mismo camino [10]. Las reglas pueden ser ´utiles a la hora de implementar: Interacciones de una sola vez: existen mensajes que no necesitan contexto para responderlos. Las reglas son una forma sencilla de asignar intenciones a respuestas, siendo respuestas fijas para estos mensajes. Por ejemplo, Despedirse. Fallback: las reglas son ´utiles para responder a mensajes de usuario de baja confianza con un determinado fallback. Formularios: para la activaci´on de un formulario suele seguir una ruta fija. 2.1.4. Domain El fichero domain (dominio) define el universo en el que opera el asistente. Especif´ıca los intents, entities, slots, responses, forms y actions que el bot debe conocer. En ´el tambi´en se define una configuraci´on para las sesiones de conversaci´on. 23 Cap´ıtulo 3 Planificaci´on 3.1. Metodolog´ıa En la realizaci´on del Trabajo de Fin de Grado opt´e por adoptar la metodolog´ıa scrum y su enfoque ´agil, debido a la propia naturaleza din´amica del desarrollo del chatbots. Esta metodolog´ıa me permite realizar ajustes continuos basados en el feedback obtenido de la interacci´on con usuarios reales. Adem´as se alinea con la metodolog´ıa propuesta por Rasa CDD, que como describ´ı anteriormente, que recomienda sacar versiones cuanto antes del chatbot, darlo a probar a usuarios, anotar las mejoras e implementar esas mejoras. Scrum con su estructura de sprints y revisiones constantes ofrece la experiencia ideal para el desarrollo del chatbot. Para este proyecto se han pensado los siguientes par´ametros: Duraci´on sprint: se establecen 2 semanas por sprint. N´umero de sprints: se realizar´an 8 sprints. Al final de cada sprint se revisar´an las interacciones que los usuarios han tenido con el chatbot y anotar´an todas las mejoras a tener en cuenta en el siguiente sprint. El desarrollo del proyecto se hace durante el segundo cuatrimestre del curso 2023-2024. Siendo el comienzo del primer sprint el d´ıa 26 de febrero. Debido a la compatibilizaci´on del proyecto con mi jornada laboral, la dedicaci´on no ser´a completa, estimando unas 2.5 horas en d´ıas laborables y entre 5 y 6 horas los fines de semana. Esta distribuci´on de tiempo me permitir´a alcanzar m´as de las 300 horas requeridas para el TFG, finalizando el ´ultimo sprint el 16 de junio. A´un se tendr´ıa unos d´ıas de margen para la entrega ordinaria y proporciona varias semanas por si fuese necesario optar por una entrega extraordinaria. En el pr´oximo cap´ıtulo detallar´e el proceso de desarrollo en cada sprint. Esta secci´on proporcionar´a una visi´on clara de c´omo se ha ido construyendo el proyecto semana a semana, destacando 30 los logros clave, los desaf´ıos enfrentados y las soluciones implementadas en cada etapa. 3.2. Riesgos En esta secci´on abordar´e la gesti´on de riesgos detectados en el proyecto, identificando los riesgos principales evaluando su impacto y probabilidad. Entendemos por riesgo cualquier evento que pueda ocurrir y que, de hacerlo, tendr´ıa un efecto adverso en la consecuci´on de los objetivos del proyecto. La gesti´on de estos riesgos implica identificarlos tempranamente, evaluar su impacto y probabilidad de ocurrencia y desarrollar estrategias para mitigarlos. En cada riesgo se detalla una descripci´on, las estimaciones de su impacto y probabilidad antes y despu´es de implementar las medidas propuestas. Los valores de la probabilidad Tabla 3.1 y los del impacto se evaluar´an Tabla 3.2 con los siguientes descriptores cualitativos: bajo, moderado, alto, extremo. Nivel de probabilidad Gama Alta Probabilidad superior al 50 % Significativa 30-50 % de posibilidades de que ocurra Moderada 10-29 % de posibilidades de que ocurra Baja Menos del 10 % de posibilidades de que ocurra Tabla 3.1: Niveles de probabilidad Nivel de probabilidad Gama Alta M´as del 30 % por encima de lo presupuestado gastos presupuestados Significativa Del 20 al 29 % por encima del gasto presupuestado Moderada Del 10 al 19 % por encima de los gastos presupuestados Baja Dentro del 10 % de los gastos presupuestados Tabla 3.2: Niveles de probabilidad A continuaci´on, se enumeran los principales riesgos. 31 Ri01 Falta de experiencia Descripci´on No se tienen los conocimientos suficientes para un abarcar el desarrollo marcado en los sprints Plan de Mitigaci´on Formaci´on durante las primeras semanas de proyecto. Aprender conceptos de chatbots, NLU y Rasa framework. Plan de Contingencia Incorporar un perfil especializado en la materia de una empresa externa o freelancer que pueda resolver las dudas y ayudar a progresar. Valores Probabilidad/Impacto Probabilidad Impacto Antes Moderada Significativa Despu´es Baja Baja Tabla 3.3: Riesgo 01 - Falta de experiencia Ri02 Falta de usuarios Descripci´on No hay un n´umero de usuarios significativo provando el chatbot y aportando el feedback. Plan de Mitigaci´on Crear una campa˜na de comunicaci´on que explique los beneficios y el uso del chatbot. Quiz´as a˜nadir alg´un incentivo. Plan de Contingencia Organizar talleres en vivo o webinars en redes sociales. Valores Probabilidad/Impacto Probabilidad Impacto Antes Moderada Significativa Despu´es Baja Moderada Tabla 3.4: Riesgo 02 - Falta de usuarios 32 Ri03 P´erdida de c´odigo Descripci´on P´erdida de c´odigo Plan de Mitigaci´on Utilizar al menos dos controles de ver- si´on en servidores distintos. Plan de Contingencia Recuperar la versi´on m´as reciente y continuar el trabajo desde esa versi´on. Valores Probabilidad/Impacto Probabilidad Impacto Antes Moderada Alta Despu´es Baja Baja Tabla 3.5: Riesgo 03 - P´erdida de c´odigo Ri04 Telegram sin servicio Descripci´on El principal canal de comunicaci´on con el chatbot se realiza a trav´es de Telegram. Si los servidores de Telegram fallan o son bloquedaos en Espa˜na nos quedar´ıamos sin poder comunicarnos al bot. Plan de Mitigaci´on Adaptar el chatbot para funcionar tambi´en en otras plataformas de mensajer´ıa como WhatsApp o Facebook Messenger, asegurando la continuidad del servicio. Plan de Contingencia Publica el asistente en otra plataforma de mensajer´ıa. Valores Probabilidad/Impacto Probabilidad Impacto Antes Baja Significativa Despu´es Baja Baja Tabla 3.6: Riesgo 04 - Telegram sin servicio 33 Ri05 Enfermedad Descripci´on Enfermedad que obligue al programador a para el trabajo temporalmente. Plan de Mitigaci´on Pol´ıticas de trabajo flexible. Plan de Contingencia Reestimar las tareas y ajustar la planificaci´on. Valores Probabilidad/Impacto Probabilidad Impacto Antes Baja Significativa Despu´es Baja Moderada Tabla 3.7: Riesgo 05 - Enfermedad Ri06 Complejidad elevada Descripci´on Complejidad de los di´alogo es demasiado alta. Plan de Mitigaci´on Comenzar con peque˜nas mejoras en la conversaci´on con el chatbot en vez de intentar abarcar di´alogos extensos y m´as complejos. Plan de Contingencia Evaluar la tarea y ajustar la planificaci´on. Valores Probabilidad/Impacto Probabilidad Impacto Antes Moderada Significativa Despu´es Baja Moderada Tabla 3.8: Riesgo 06 - Complejidad elevada 3.2.1. Matriz de riesgos En la siguiente Tabla 3.9 podemos observar la distribuci´on en la matriz de (impacto/probabilidad) los riesgos identificados. Probabilidad/Impacto Baja Moderada Significativa Alta Alta Significativa Moderada Ri01,Ri02,Ri06 Ri03 Baja Ri04,Ri05 Tabla 3.9: Matriz de riesgos 34 Tras la aplicaci´on de las medidas de mitigaci´on para reducir la probabilidad de ocurrencia del riesgo o reducir el impacto que pueda causar, la matriz de riesgos quedar´ıa de la siguiente forma: Probabilidad/Impacto Baja Moderada SignificativaAlta Alta Significativa Moderada Ri02,Ri05,Ri06 Baja Ri01,Ri03,Ri04 Tabla 3.10: Matriz de riesgos tras los planes de mitigaci´on. 3.3. Distribuci´on temporal La divisi´on por sprints ser´ıa la siguiente: Sprint 1 (30 horas): Se realiz´o una reuni´on inicial con el tutor D. C´esar Gonz´alez Ferreras para discutir los objetivos y expectativas del proyecto. Durante esta sesi´on, se me present´o el framework Rasa el cu´al deb´ıa estudiar y seleccionar un ´ambito en el que aplicarlo para crear un chatbot. Durante los d´ıas siguientes, me dediqu´e a familiarizarme con los conceptos de Rasa y explorar las herramientas que tiene. Tras evaluar las posibilidades de Rasa, finalmente decid´ı que el chatbot se centrar´ıa en proporcionar informaci´on sobre pel´ıculas. Sprint 2 (35 horas): En el Sprint 2, comenc´e a explorar el framework Rasa de forma pr´actica. Configur´e el entorno del proyecto e instal´e todas las dependencias necesarias para empezar. Durante este periodo revis´e los conceptos fundamentales de Rasa para asegurarme de entenderlos bien (ya que era mi introducci´on a un proyecto relacionado con chatbots y NLP) y simult´aneamente probar estos conceptos con el chatbot por defecto que ofrece Rasa. Sprint 3 (63 horas): En el sprint 3 comenc´e a desarrollar la primera versi´on funcional del chatbot. Este prototipo inicial era s´olo era capaz de identificar cuando un usuario solicitaba una recomendaci´on. Tras identificar la intenci´on del usuario como recomendaci´on, el bot preguntaba al usuario por el g´enero de pel´ıcula que buscaba y guardaba la respuesta para procesarla adecuadamente. Adem´as, en este punto consegu´ı explotar e integrar el uso de la API de la web TMDB dentro del proyecto, de donde extraer´ıa la informaci´on proporcionada al usuario sobre pel´ıculas. Finalmente, tengo una segunda sesi´on con el tutor para presentarle los avances y valoramos otras funcionalidades que se pueden aplicar al chatbot. Para facilitar el acceso al chatbot lo conecto a Telegram. Le doy a probar el chatbot a un c´ırculo cercano de amigos y familiares para observar las primeras interacciones hombre-m´aquina. Sprint 4 (50 horas): Al comienzo del sprint 4 analic´e las interacciones del chatbot para identificar posibles patrones y mejoras al a hora de identificar el g´enero. Detect´e un primer problema clave: los g´eneros solicitados por los usuarios necesitan coincidir exactamente con los g´eneros definidos en la API de TMDB. Para solucionarlo implement´e una tabla lookup con todas las opciones posibles de g´enero y a˜nad´ı sin´onimos a los distintos g´eneros seg´un la 35 forma en la que los usuarios se refieren a ese g´enero que surgen de las conversaciones reales, mejorando as´ı la precisi´on a la hora de identificar el g´enero. Tambi´en apliqu´e el patr´on formulario para que cuando se le pregunte el g´enero y el usuario no responda correctamente, se le vuelva a preguntar. Vuelvo publicar un segundo prototipo de chatbot. Sprint 5 (48 horas): En el sprint 5 revis´e los resultados de las interacciones en el chatbot con los nuevos cambios, notando una mejor´ıa respecto a la versi´on anterior. Realizo otra sesi´on con el tutor para mostrar el avance y plantear nuevas funcionalidades. En este punto investigo m´as endpoints que ofrece la API para ofrecer m´as funcionalidad. Comienzo por escribir dos story relacionadas con la pel´ıcula que se le ha recomendado, permitiendo a los usuarios solicitar un resumen de la pel´ıcula, preguntar por los actores principales y qui´en dirigi´o la pel´ıcula. A la hora de responder sobre los actores y directores se le muestra una listado limitado. Publiqu´e una tercera versi´on del chatbot. Sprint 6 (54 horas): En el sprint 6 volv´ı a revisar las interacciones con el chatbot tras la nueva actualizaci´on. Me di cuenta que en ocasiones el bot se perd´ıa en la conversaci´on, tanto a la hora de responder como de interpretar bien que intenci´on estaba expresando el usuario. Para solucionar este problema a˜nad´ı m´as stories de ejemplo para que el modelo conversacional aprendiera de ellos. Tambi´en implemente alguna funcionalidad extra, integre los endpoints para preguntar a la API sobre informaci´on de los actores y directores, y en que otras pel´ıculas trabajaron. En una primera aproximaci´on quer´ıa utilizar una modelo con nombres de personas pre-entrenados, como los que ofrece spaCy pero al pertenecer los nombres a multiples idiomas se complicaba. Al final opt´e por ofrecer en la respuesta una lista de botones con los nombres de los actores, el usuarios al seleccionar uno se le daba informaci´on de ese actor. Publiqu´e una cuarta versi´on del chatbot. Sprint 7 (35 horas): En el sprint 7 volv´ı a analizar las interacciones con el chatbot. En este punto el principal problema es ser´ıa saber guiar al chatbot por el flujo de las conversaciones y adaptarse a respuestas inesperadas que no estaban controladas. Esto supone m´as tiempo de investigaci´on como funcionan los distintos pipelines y policies para ajustar el chatbot. Publico una versi´on. Sprint 8 (40 horas): En este ´ultimo sprint se da por finalizado el chatbot tras aplicar las ´ultimas mejoras en el control de respuestas inesperadas y a˜nadir m´as ejemplos que se extraen de las interacciones. En este sprint se elabora la memoria del trabajo desarrollado. El tiempo de todas las interacciones sumar´ıa un total de 355 horas. 3.4. Costes El Trabajo de Fin de Grado se ha desarrollado en 355 horas. Siendo el rango salarial de un desarrollador Backend con experiencia en Python entre los 20-30K [16]. Si tomamos un salario medio anual dentro del anterior rango, 25.000eal a˜no en el que se trabajan 1.800 horas anuales, 36 seg´un convenio colectivo de consultor´ıas [2]. Tenemos que el coste hora ser´ıan 13,89 e/hora. El coste total del desorrallador ser´ıa de 4.930e. Ya que el proyecto se ha realizado desde el domicilio del trabajador podr´ıa optar a un plus de trabajo flexible y ayuda comedor, alrededor de unos 120 emensuales. Para los 4 meses que ha supuesto el desarrollo del proyecto hace un total de 480e. Coste total: 5.410e. 37 Cap´ıtulo 4 Descripci´on iteraciones En este cap´ıtulo se va a describir en detalle el desarrollo realizado en cada uno de los sprints. Adem´as, expondr´an los desaf´ıos encontrados durante el desarrollo de los di´alogos del chatbot y las estrategias empleadas para resolverlos. 4.1. Sprint 1 En el primer sprint del proyecto tuve una reuni´on inicial con mi tutor D. C´esar Gonz´alez Ferreras, donde discutimos los objetivos y expectativas del Trabajo de Fin de Grado. Durante esta sesi´on, fui introducido al framework Rasa, que iba a utilizar para desarrollar el chatbot. Los siguientes d´ıas me enfoque en estudiar el framework Rasa y familiarizarme con los conceptos clave, los cuales he descrito en Cap´ıtulo 2.1. Mi principal recurso para el aprendizaje fue la documentaci´on oficial proporcionada por Rasa [10], que es muy ´util y completa. Fuera de la documentaci´on me cost´o encontrar recursos tan ´utiles. Tambi´en tom´e lecciones y webinars que ofrece el equipo de Rasa en su canal de Youtube [14]. Tras evaluar las posibilidades que ofrece Rasa y considerar diferentes aplicaciones posibles, decid´ı que el chatbot se especializara en el dominio del cine. Eleg´ı este campo debido a su amplio alcance y la disponibilidad de datos a trav´es de diversas APIs, adem´as de ser un tema de gran inter´es debido a la popularidad de las plataformas de streaming. Esta direcci´on no solo satisfac´ıa los requisitos del proyecto, sino que tambi´en ser´ıa de gran utilidad para un p´ublico amplio y diverso. Investigu´e varias APIs para proporcionara datos sobre pel´ıculas y series. Finalmente me decid´ı por la API de TMDB. Esta API destac´o por su amplia variedad de endpoints que se adaptan perfectamente al objetivo del chatbot. Ofrece acceso a una rica base de datos de pel´ıculas y series, incluyendo detalles como sinopsis, calificaciones, elenco y mucho m´as. 38 Figura 4.1: Configuraci´on del entorno virtual con nix y flake 4.2. Sprint 2 En este segundo sprint quer´ıa profundizar en los conceptos del framework Rasa de forma pr´actica. Lo primero que necesitaba era un entorno de trabajo. Inici´e la configuraci´on del entorno utilizando herramientas nix (y su utilidad flake) y direnv, que ´ultimamente aplico a todos mis proyectos. Estas herramientas garantizan la creaci´on de un entorno de desarrollo consistente y reproducible, independientemente de la m´aquina utilizada, incluyendo todas las dependencias del sistema como la versi´on de Python y librer´ıas necesarias, sin alterar la configuraci´on global de mi terminal. Los ficheros asociados a estas herramientas son flake.nix 4.1, flake.lock y .envrc. Para manejar las librer´ıas de Python que necesito, utilic´e poetry, herramienta para gestionar las dependencias dentro del entorno virtual. La configuraci´on de poetry para este proyecto se describe en los ficheros pyproject.toml 4.2 y poetry.lock. Al comienzo en el proyecto utilizaba la ´ultima versi´on del framework Rasa y Python 3.11 pero semanas posteriores al integrar Telegram, para conectar el chatbot al servicio de mensajer´ıa, la librer´ıa que ofrece Rasa ten´ıa bugs reportados [5]. Con este inconveniente, tuve que reconfigurar las dependencias, utilizando Python 3.10 y la versi´on de Rasa 3.6.6. Decir que utilizo la versi´on de Rasa m´as simple, sin los extras que ofrece para las librer´ıas spaCy, por ejemplo. Otros paquetes de Python que uso en el proyecto es request, que lo utilizo para hacer las llamadas al endpoint de TMDB. 39 Figura 4.6: Arquitectura durante el desarrollo Chatbot procesa el mensaje y ejecuta la acciones necesarias retornando el mensaje de respuestas. 4.3.5. Tracker Tras publicar el chatbot se hac´ıa necesario almacenar las interacciones que los usuarios tienen con ´el, para poder analizar las conversaciones m´as tarde y mejorar los datos de entrenamiento. Rasa ofrece diversas opciones para registrar estas conversaciones. Para mi proyecto, opt´e por utilizar MongoDB, una base de datos no SQL. Para levantar el servicio de MongoDB utilizo docker. Entre los archivos del proyecto existe un compose.yml con dos servicios: MongoDB: base de datos No-SQL, encargada de almacenar las conversaciones. Mongo Express: es una interfaz web para manejar instancias de MongoDB. Finalmente lanzar el chatbot, es necesario ejecutar algunos comandos en la terminal. Primero utilizo el comando rasa run -m models --endpoints endpoints.yml para poner en marcha el servicio con el modelo Rasa entrenado. Paralelamente, en otro terminal, ejecuto rasa run actions que se encargar´a de exponer las acciones personalizadas en el puerto 5055 para el uso del chatbot. Despu´es de configurar todo, la primera versi´on del chatbot ya est´a lista para ser probada por usuarios reales. Esta fase inicial se trata de identificar y corregir posibles errores. 46 4.4. Sprint 4 Al comienzo del sprint 4, tras un par de d´ıas de pruebas, dediqu´e tiempo a examinar las conversaciones de usuarios reales guardadas en la base de datos MongoDB. El formato en que Rasa guarda esta informaci´on en el tracker puede parecer algo ca´otico pero al final te haces a la idea. Sin embargo, recomendar´ıa utilizar alguna herramienta de an´alisis de datos para facilitar y mejorar el an´alisis. Las conclusiones tras analizar las conversaciones fueron: Mejorar el intent request movie: no siempre que el usuario transmit´ıa su intenci´on de solicitar una pel´ıcula el chatbot no lo interpretaba as´ı. Mejorar el intent inform genre: no tengo todos los g´eneros posibles descritos en los datos de entrenamiento, aunque el intent era identificado por Rasa no pod´ıa extraer el entity movie genre. Mejorar el flujo: a veces el usuario ped´ıa una recomendaci´on pero en vez de responder el g´enero, el usuario responde otra cosa, y se pierde el flujo de story. 4.4.1. request movie Para mejorar la capacidad de Rasa para identificar el intent request movie ser´ıa necesario a˜nadir m´as ejemplos de petici´on. A˜nado varios ejemplos m´as sacados de conversaciones reales y otros nuevos. 1nlu : 2- intent : request_movie 3examples : | 4- ¿Qu ´e pel ´ı cula me recomiendas ? 5- Quiero ver una pel´ı cula 6- Recomi ´e ndame una pel ´ı cula 7- ¿Podr ´ıas sugerirme una pel ´ı cula? 8- ¿ Tienes alguna recomendaci ´on de pel ´ı cula ? 9- ¿Qu ´e pel ´ı cula me sugieres ? 10 - Dime una pel ´ıcula 11 - Me recomiendas una pel´ı cula 12 - Me dices una pel ´ıcula 13 - ¿Qu´e pel´ıcula puedo ver ? 14 - Sugi ´ereme una pel ´ı cula 15 - Dame una pel´ı cula para ver 16 - Ay´udame a encontrar una pel´ı cula 17 - Dame una buena pel´ı cula 18 - ¿ Puedes recomendarme alguna pel´ı cula ? 19 - Quiero ver una buena pel´ı cula 20 - ¿Cu ´al pel ´ıcula me sugieres ? C´odigo 4.4: Datos de entrenamiento Petici´on de pel´ıcula. 47 4.4.2. inform genre Para solucionar los problemas a la hora de identificar los g´eneros decido crear una tabla lookup que contenga todos los g´eneros disponibles en la API de TMDB. Varios g´eneros se pueden ser informados de varias formas, por ejemplo, en vez de g´enero Romance el usuario podr´ıa decir Una pel´ıcula rom´antica. O en vez de Western el usuario podr´ıa referirse a este g´enero como Una del oeste oUna pel´ıcula de vaqueros. Esta lista se ir´a mejorando y ampliando con los distintas versiones que usen los usuarios para referirse a un g´enero. 1nlu : 2- synonym: Western 3examples : | 4- Vaqueros 5- Oeste 6- Indios 7- Indios y Vaqueros 8- synonym : Acci ´on 9examples : | 10 - Accion 11 - synonym : Crimen 12 examples : | 13 - Crimenes 14 - synonym: Romance 15 examples : | 16 - Rom ´a ntica 17 - lookup : movie_genre 18 examples : | 19 - Acci ´on 20 - Aventura 21 - Animaci ´on 22 - Comedia 23 - Crimen 24 - Documental 25 - Drama 26 - Familia 27 - Fantas ´ıa 28 - Historia 29 - Terror 30 - M´usica 31 - Misterio 32 - Romance 33 - Ciencia ficci ´on 34 - Suspense 35 - B´elica 36 - Western C´odigo 4.5: Datos de entrenamiento. Lista de g´eneros. 48 4.4.3. Formulario Para mejorar el flujo de recopilaci´on de la informaci´on implmentar´e un forms en el chatbot. Los forms son una herramienta esencial para estructurar la recogida de datos. Primero defino el formulario con los slots necesarios y las reponses de cada slot, es decir, la pregunta que hace el chatbot al usuario para que responda con la informaci´on necesaria para rellenar el slot. Explicar´e este punto m´as en detalle. Rasa admite varias opciones para informar como debe formularse la pregunta al usuario a la hora de rellenar un slot. Las opciones siguen los siguientes patrones y orden: 1. action ask <form name> <slot name> 2. utter ask <form name> <slot name> 3. action ask <slot name> 4. utter ask <slot name> Tambi´en es necesario a˜nadir un par de reglas para manejar el comportamiento del formulario. Una regla para activar el formulario y otra para indicar que se finaliza el formulario. Para activar el formulario primero se define la acci´on movie form, que lleva el nombre del formulario, y luego se activa el bucle del formulario con active loop: movie form. Esto mantiene la conversaci´on en bucle repitiendo las preguntas de los slots hasta que el usuario haya rellenado todos. El formulario acaba cuando todos los slots est´an llenos, la variable active loop se pone a null, y la variable donde se indica cu´al es el siguiente slot a rellenar, requested slot se pone a null. Por ´ultimo, hace falta hacer algunas modificaciones a las acciones personalizadas. Para validar los valores del usuario es necesarios a˜nadir validaciones personalizadas a cada slot que se declara en el formulario. Para validar el g´enero consulto si el valor de movie genre se encuentra en la lista de g´eneros en el endpoint /genre/movie/list en la API TMDB, si el g´enero est´a disponible, almaceno el id en el slot user genre para utilizarlo en futuras consultas a la API. Si el g´enero no es v´alido se vuelve a poner el slot a null para que el chatbot lance de nuevo la pregunta. Adicionalmente he a˜nadido un mensaje para informar la usuario de que el g´enero no es correcto. 1entities: 2- movie_genre 3slots : 4user_genre : 5type : any 6mappings: 7- type : custom 8user_movies_history: 9type: list 10 mappings: 11 - type : custom 49 12 movie_genre: 13 type: text 14 mappings: 15 - type : from_entity 16 entity : movie_genre 17 conditions : 18 - active_loop: movie_form 19 rules : 20 - rule : Activate form 21 steps : 22 - intent : request_movie 23 - action : movie_form 24 - active_loop: movie_form 25 - rule : Finish form 26 condition : 27 - active_loop: movie_form 28 steps : 29 - action : movie_form 30 - active_loop : null 31 - slot_was_set: 32 - requested_slot: null 33 - action: action_find_movie 34 forms : 35 movie_form : 36 required_slots: 37 - movie_genre 38 responses : 39 utter_ask_movie_genre: 40 - text : ¿ Tienes alg ´un g´enero o tipo de pel ´ıcula en mente ? 41 - text : ¿Qu´e g´enero te apetece ver? C´odigo 4.6: Datos de entrenamiento. Formulario movie form He creado un nuevo slot user movies history que me servir´a para almacenar los ids de las pel´ıculas recomendadas al usuario para evitar repetir las mismas. Tambi´en a˜nad´ı m´as informaci´on al mensaje de respuesta que enviaba el chatbot al usuario sobre la pel´ıcula recomendada. Ahora env´ıa, una confirmaci´on del g´enero que busca, una imagen con la portada de la pel´ıcula, el t´ıtulo de la pel´ıcula junto con el a˜no de estreno y la puntuaci´on de la pel´ıcula. Conversaci´on: 4.7 Vuelvo publicar el chatbot con todas estas mejoras para que hagan pruebas usuarios reales. 4.5. Sprint 5 Al comienzo de este sprint revis´e de nuevo las conversaciones con usuarios reales. Los resultados mejoraron bastante. A˜nad´ı alg´un sin´onimo de g´enero m´as. Tras mostrarle los avances al tutor D. C´esar Gonz´alez Ferreras, me propone mejorar la funcio- 50 Figura 4.7: Ejemplo de conversaci´on 51 nalidad del chatbot incluyendo nuevas funcionalidades. Lo primero que reviso es la API de TMDB para ver que opciones me ofrece para a˜nadir m´as funcionalidad. Decido incluir dos nuevas funcionalidades: Solicitar resumen: El chatbot debe comprender cuando se le solicita un resumen de la pel´ıcula y mostrar un mensaje de texto con el resumen. Se tomar´a el id de la ´ultima pel´ıcula guardada en el historial. Solicitar actores: El chatbot debe comprender cuando se le solicita que actores participan en la pel´ıcula y mostrar un listado de los principales. Se tomar´a el id de la ´ultima pel´ıcula guardada en el historial. Solicitar director: El chatbot debe comprender cuando se le solicita que director dirige la pel´ıcula y mostrarlo. Se tomar´a el id de la ´ultima pel´ıcula guardada en el historial. En todas estas historias se trabaja sobre la premisa que el usuario primero ha solicitado una recomendaci´on de pel´ıcula antes de solicitar un resumen o preguntar sobre los actores o directores. Como el comienzo de las 3 historias ser´ıa el mismo, la solicitud de una recomendaci´on, utilizo la opci´on checkpoint para modularizar y simplificar los datos de entrenamiento [10]. Estos puntos de control son muy ´utiles, pero no hay que abusar de ellos ya que ralentizar´a el entrenamiento del modelo. En todas las historias se llama a acciones personalizadas que utilizan endpoints de la API de TMDB. En el caso de que se haya recomendado m´as de una, estas acciones personalizadas siempre toman el id de la ´ultima pel´ıcula guardada en el historial (slot user movies history). 4.5.1. Solicitar resumen El chatbot debe comprender cuando se le solicita un resumen de la pel´ıcula y mostrar un mensaje de texto con el resumen. Para comprender cuando el usuario quiere solicitar un resumen de la pel´ıcula he creado el intent request movie info. 1nlu : 2- intent : request_movie_info 3examples : | 4- ¿De qu´e trata ? 5- ¿Me haces un resumen ? 6- ¿Cu ´al es la sinopsis ? 7- Quiero saber m´as sobre esta pel ´ıcula 8- ¿Qu´e pasa en la pel´ı cula ? 9- ¿Cu´al es el argumento de la pel ´ıcula ? 10 - ¿ Puedes darme detalles sobre la trama ? 11 - ¿De qu´e va la pel ´ıcula ? 12 - ¿Me puedes dar un resumen de la pel ´ı cula ? 52 13 - Cu´e ntame de qu´e trata la pel ´ı cula 14 stories: 15 - story : User request movie 16 steps : 17 - intent : request_movie 18 - action : movie_form 19 - active_loop : movie_form 20 - active_loop : null 21 - slot_was_set: 22 - requested_slot: null 23 - action: action_find_movie 24 - checkpoint : ask_about_movie 25 26 - story : User request movie info 27 steps : 28 - checkpoint : ask_about_movie 29 - intent : request_movie_info 30 - action: action_summary_movie C´odigo 4.7: Datos de entrenamiento. Solicitar resumen. 4.5.2. Solicitar actores El chatbot debe comprender cuando se le solicita que actores participan en la pel´ıcula y mostrar un listado de los principales. Para comprender cuando el usuario quiere solicitar un resumen de la pel´ıcula he creado el intent request movie cast. 1nlu : 2- intent : request_movie_cast 3examples : | 4- ¿Qui ´e nes son los actores principales ? 5- ¿Qui´en act ´ua en la pel´ı cula ? 6- ¿ Que actores salen ? 7- ¿Qui ´e nes son los miembros del reparto ? 8- Dime el elenco de la pel ´ı cula 9- ¿ Qui ´e nes forman el reparto ? 10 - ¿Qui ´e nes son los actores ? 11 stories: 12 - story : User request movie cast 13 steps : 14 - checkpoint : ask_about_movie 15 - intent : request_movie_cast 16 - action: action_movie_cast 17 18 - story : User request movie director 19 steps : 20 - checkpoint : ask_about_movie 21 - intent : request_movie_director 53 22 - action: action_movie_director C´odigo 4.8: Datos de entrenamiento. Solicitar actores. 4.5.3. Solicitar director El chatbot debe comprender cuando se le solicita que director dirige la pel´ıcula y mostrarlo. Para comprender cuando el usuario quiere solicitar un resumen de la pel´ıcula he creado el intent request movie director. 1nlu : 2- intent : request_movie_director 3examples : | 4- ¿Qui´en dirige la pel ´ı cula? 5- ¿Qui´en la dirige pel ´ıcula ? 6- ¿ Qui ´en es el director ? 7- ¿ Qui ´en dirigi ´o la pel ´ı cula ? 8- ¿Qui´en dirige la pel ´ı cula? 9stories: 10 - story : User request movie director 11 steps : 12 - checkpoint : ask_about_movie 13 - intent : request_movie_director 14 - action: action_movie_director C´odigo 4.9: Datos de entrenamiento. Solicitar director. Si el usuario pretende que se le de un resumen de la pel´ıcula, informe los actores o el director sin primero haber solicitado una recomendaci´on el modelo de Rasa activar´a action unlikely intent. Esta respuesta aparece cuando el modelo detecta e interpreta el intent del mensaje pero este aparece en un momento de la conversaci´on que no esperaba. Esta acci´on no mostrar´a ning´un mensaje, es un m´etodo de control y se puede personalizar. En versiones siguientes se controlar´an este tipo de acciones. Publico una nueva versi´on para que la prueben usuarios reales. 4.6. Sprint 6 Comenc´e el sprint 6 como los anteriores, analizando las conversaciones de los usuarios con el chatbot. Detect´e un problema, el comienzo de las conversaciones estaba bastante controlado pero a medida que la conversaci´on segu´ıa y se iban entrelazando las distintas peticiones sobre la pel´ıcula el chatbot dejaba de lanzar las acciones correspondientes. Hac´ıan falta m´as datos de entrenamiento con las m´ultiples historias o ejemplos de historias que se pueden dar. Revisando la documentaci´on la recomendaci´on de Rasa es escribir historias utilizando el aprendizaje interactivo, utilizando el comando rasa interactive. 54 Con el comando rasa interactive se entrena el modelo y despu´es se abre una sesi´on para interectuar con el chatbot donde se podr´an corregir las predicciones del asistente mientras se habla con ´el. El aprendizaje interactivo facilita la escritura de historias hablando con el chatbot y proporcion´andole feedback [10]. As´ı puedo ir ense˜n´andole como se debe comportar. Al finalizar la sesi´on las historias, entities, intents, etc. aprendidos por el bot se exportan a los ficheros de entrenamiento. 1stories: 2- story : User multiple request 1 3steps : 4- checkpoint : ask_about_movie 5- intent : request_movie_info 6- action: action_summary_movie 7- intent : request_movie_director 8- action: action_movie_director 9- intent : request_movie_cast 10 - action: action_movie_cast 11 12 - story : User multiple request 2 13 steps : 14 - checkpoint : ask_about_movie 15 - intent : request_movie_info 16 - action: action_summary_movie 17 - intent : request_movie_cast 18 - action: action_movie_cast 19 - intent : request_movie_director 20 - action: action_movie_director 21 22 - story : User multiple request 3 23 steps : 24 - checkpoint : ask_about_movie 25 - intent : request_movie_cast 26 - action: action_movie_cast 27 - intent : request_movie_info 28 - action: action_summary_movie 29 - intent : request_movie_director 30 - action: action_movie_director 31 32 - story : User multiple request 4 33 steps : 34 - checkpoint : ask_about_movie 35 - intent : request_movie_cast 36 - action: action_movie_cast 37 - intent : request_movie_director 38 - action: action_movie_director 39 40 - story : User multiple request 5 41 steps : 42 - checkpoint : ask_about_movie 43 - intent : request_movie_cast 44 - action: action_movie_cast 45 - intent : request_movie_director 55 Figura 4.10: Formulario din´amico guarda el valor True y entonces la siguiente pregunta ser´a a que plataforma est´a subscrito, aqu´ı deber´a responder una entras las v´alidas por la API. En caso de responder que no tiene ninguna subscripci´on se guarda en el slot has provider False, y esto provoca que se elimine provider de los slots requeridos en el formulario y se elimine la pregunta para saber a que plataforma est´a subscrito. Para validar las respuestas a la pregunta a sobre la plataforma a la que est´a subscrito he utilizado la misma estrategia que con los g´eneros. He buscado que plataformas utiliza la API y he creado una lista de las m´as conocidas en una tabla lookup. Tambi´en he creado algunos sin´onimos para identificar plataformas m´as f´acilmente. 1nlu : 2- intent: affirm 3examples : | 4- Si 5- Vale 6- Perfecto 7- Correcto 8- intent : deny 9examples : | 10 - No 11 - Negativo 12 - Para nada 13 - En absoluto 14 - synonym : Amazon Prime Video 15 examples : | 16 - Amazon 17 - Amazon Prime 18 - Prime Video 19 - Prime 20 - synonym : Disney Plus 21 examples : | 22 - Disney 23 - Disney+ 24 - lookup : provider_type 25 examples : | 26 - Amazon Prime Video 62 27 - Netflix 28 - Apple TV 29 - Disney Plus 30 - HBO Max 31 - Movistar Plus 32 - Atres Player 33 - Youtube 34 - intent : inform_provider 35 examples : | 36 - Estoy suscrito a [ Amazon Prime Video ]( provider_type ) 37 - Tengo [ Amazon Prime Video ]( provider_type ) 38 - Uso [ Amazon Prime Video ]( provider_type ) 39 - Estoy subscrito a [ Netflix ]( provider_type ) 40 - Tengo [ Netflix ]( provider_type ) 41 - Uso [ Netflix ]( provider_type ) 42 forms : 43 movie_form : 44 required_slots: [] 45 slots : 46 user_provider : 47 type : any 48 mappings: 49 - type : custom 50 has_provider: 51 type: bool 52 mappings: 53 - type : from_intent 54 value : true 55 intent: affirm 56 conditions : 57 - active_loop: movie_form 58 - type : from_intent 59 value : false 60 intent : deny 61 conditions : 62 - active_loop: movie_form 63 provider: 64 type: text 65 mappings: 66 - type : from_entity 67 entity : provider_type 68 conditions : 69 - active_loop: movie_form 70 responses : 71 utter_ask_provider : 72 - text : ¿A qu´e plataforma est´as subscrito ? C´odigo 4.13: Datos de entrenamiento. Plataformas streaming. 63 4.7.2. Unhappy Paths Las Unhappy Paths son todos los casos extremos posibles. Por ejemplo, el usuario se niega a dar la informaci´on solicitada, cambia el tema de conversaci´on o corrige algo que ha dicho antes. [10]. En primer lugar voy a controlar los mensajes fuera de lugar, estos son aquellos mensajes que nada tienen que ver con el dominio de mi chatbot, es decir, todos aquellos mensajes que se alejen de lo controlamos en las historias y no existe un intent para identificarlo. Para controlarlo he creado un primer intent general llamado out of scope y otro m´as particular para preguntas relacionadas con el clima out of scope weather. He creado este segundo grupo de intents ya que muchos usuarios hac´ıan referencia al clima y me pareci´o buena idea tratarlo por separado. Los ejemplos de estos dos intent se han extra´ıdo de las conversaciones con usuarios reales. Para responder a estos mensajes he creado un par de reglas. La utilizaci´on de reglas en este caso es adecuada ya que quiero que siempre se le responda a los mensajes out of scope sin importar el contexto de la conversaci´on. 1nlu : 2- intent: out_of_scope_weather 3examples : | 4- ¿C´omo est ´a el clima hoy ? 5- ¿Va a llover ma~nana ? 6- ¿ Cu´al es la temperatura actual ? 7- Dime el pron´o stico del tiempo 8- ¿Qu´e tiempo hace ? 9- ¿ Est ´a soleado ? 10 - ¿ Habr ´a tormenta ? 11 - intent : out_of_scope 12 examples : | 13 - ¿Te gustan los perros ? 14 - Tengo una mascota 15 - Me gustan los gatos 16 - Tengo un loro 17 - Dime un chiste 18 - Quiero encargar comida 19 - Dime el precio de bitcoin 20 rules : 21 - rule : Out of scope 22 steps : 23 - intent : out_of_scope 24 - action : utter_out_of_scope 25 - rule : Out of scope 26 steps : 27 - intent: out_of_scope_weather 28 - action: utter_out_of_scope_weather 29 responses : 30 utter_out_of_scope : 31 - text : Mi prop ´osito es recomendas pel ´ıculas , no tengo informaci ´on sobre esto. 64 32 utter_out_of_scope_weather: 33 - text : No tengo disponible el pron ´o stico del tiempo . C´odigo 4.14: Datos de entrenamiento. Out of scope. Otro unhappy path a controlar son los mensajes con baja confianza NLU, esto sucede cuando un usuario env´ıa un mensaje ambiguo y el modelo Rasa no es capaz de asegurar el intent con cierta precisi´on. Cambio la configuraci´on para aumentar el umbral de confianza que quiero que use el chatbot, establezco el umbral en 0.5. Todos los intents que no se alcancen este umbral se va a predecir el intent nlu fallback. Podemos controlar que sucede que pasa cuando se lanza este intent con una regla y mostrar un mensaje del tipo ”Lo siento, no te entiendo.”. 1pipeline: 2- name : FallbackClassifier 3threshold : 0.5 4rules : 5- rule : Message with low NLU confidence 6steps : 7- intent : nlu_fallback 8- action: utter_please_rephrase 9responses : 10 utter_please_rephrase: 11 - text : Lo siento , no te entiendo . C´odigo 4.15: Datos de entrenamiento. NLU fallback. Por ´ultimo, voy a mejorar el flujo de conversaciones ya que he notado que en conversaciones con usuarios muy largas el chatbot ”se pierde”. Con esto merefiero, que en ocasiones el chatbot no sabe que acci´on aplicar ya que no tiene mucho contexto de en que momento de la conversaci´on est´a. Para mejorarlo creo una acci´on personalizadad para controlar la acci´on que viene por defecto, action unlikely intent. Esta acci´on se lanza cuando el chatbot ha detectado un intent correctamente pero no lo esperaba en ese punto de la conversaci´on. En la acci´on personaliza puedo consultar cu´al fue ´ultimo intent identificado por el chatbot, y ha provocado el action unlikely intent y responder en cosecuencia. Si el intent es sobre solicitar informaci´on de las pel´ıculas y en el slot user movies history contiene datos indica estamos en un estado avanzado de la conversaci´on y no hay problema en lanzar la acci´on correspondiente al intent. Si por otro lado el slot user movies history se encuentra vac´ıo indica que el usuario ha empezado la conversaci´on pidiendo un resumen, por ejemplo, de una pel´ıcula que todav´ıa no se le ha recomendado. Para solucionarlo se activa el formulario para recomendarle primero la pel´ıcula y despu´es continuar con las preguntas relacionadas con ella, siguiendo el Happy Path definido. Lo mismo aplico con las preguntas relacionadas con actores/directores, si el slot user movies history o el slot person id est´an vac´ıos se les debe recomendar una pel´ıcula primero. 65 Figura 4.11: Acci´on ActionUnlikelyIntent Con estos Unhappy Paths controlados el chatbot se presenta bastante robusto contra mensajes inesperados. Por ´ultimo a˜nado algunos intents y rules que mejoran la experiencia del usuario al dialogar con el chatbot pero que no suponen un cambio en las funcionalidades. El chatbot responder´a cuando el usuario indique que le ha gustado la recomendaci´on o cuando exprese que no le ha gustado. Adem´as tambi´en interpretar´a cuando el usuario le da las gracias. 1nlu : 2- intent : dislike_movie 3examples : | 4- No me gusta la pel´ı cula 5- No es lo que esperaba 6- No me gusta 7- Tampoco me gusta 8- Es mala 9- Es muy mala 10 - intent : like_movie 11 examples : | 12 - Me gusta 13 - S´ı, me gusta la pel´ı cula 14 - La ver ´e 15 - Tiene buena pinta 16 - Es interesante 17 - Est ´a bien 18 - Me encanta 66 19 - intent: thanks 20 examples : | 21 - Gracias 22 - Muchas gracias 23 - Te lo agradezco 24 - Gracias por tu ayuda 25 - Agradezco tu asistencia 26 - Gracias , eso es todo 27 - Gracias por la informaci ´on 28 - Muy amable 29 rules : 30 - rule : User dislike movie 31 steps : 32 - intent : dislike_movie 33 - action : utter_sad 34 - rule : User like movie 35 steps : 36 - intent : like_movie 37 - action : utter_happy 38 - rule : User thanks 39 steps : 40 - intent: thanks 41 - action : utter_thanks 42 responses : 43 utter_sad : 44 - text : Lamento que no te haya gustado . 45 utter_happy: 46 - text : Me alegro que te guste 47 utter_thanks: 48 - text : De nada , encantado de ayudar ! C´odigo 4.16: Datos de entrenamiento. Mejoras de di´alogo. 4.7.3. Cambiar g´enero y plataforma Durante el desarrollo me di cuenta que no hab´ıa forma de cambiar el g´enero que el usuario hab´ıa escogido al principio de la conversaci´on. Esto supon´ıa un problema ya que no se le iba a poder recomendar pel´ıculas de otros g´eneros hasta que no expirase la sesi´on y el slot con el g´enero quedase vac´ıo. Cree los intents correspondientes para esta petici´on de cambio y cree una acci´on que borra el contenido del slot movie genre y lanza el formulario de nuevo para que el usuario responda la pregunta sobre el g´enero para aprovechar la validaci´on del dato introducido que tengo en ese formulario. Figura: 4.12. 1nlu : 2- intent : change_genre 3examples : | 4- Quiero cambiar de g´enero 5- Cambiar de g´e nero 67 Figura 4.12: Acci´on cambiar de g´enero 6- Me gustar ´ıa cambiar el g´e nero 7- Quisiera cambiar el g´e nero 8- Cambia el g´enero 9- Quiero otro g´e nero 10 rules : 11 - rule : Change Genre 12 steps : 13 - intent : change_genre 14 - action : action_change_genre 15 - action : movie_form 16 - active_loop: movie_form C´odigo 4.17: Datos de entrenamiento. Cambiar de g´enero. Tambi´en me di cuenta que tendr´ıa el mismo problema con la plataforma de streaming a la que el usuario hab´ıa contestado que estaba subcrito. El usuario no pod´ıa buscar pel´ıculas en otras plataformas o eliminar la que ten´ıa si ya no estaba subscrito. Inclu´ı los intens, rules y acciones necesarias para eliminar los slots. 1nlu : 2- intent : inform_no_provider 3examples : | 4- No uso ninguna plataforma 5- No estoy suscrito 6- Ya no tengo la suscripci ´on 7- Se termin ´o la suscripci ´on 8- No tengo acceso a ning ´un servicio de streaming 9- No tengo suscripciones activas 10 - No estoy suscrito a ning ´un servicio 11 - intent : inform_change_provider 12 examples : | 13 - Tengo nueva suscripci ´on 14 - He cambiado de plataforma 15 - Ahora estoy suscrito a otra plataforma 16 - He cambiado mi suscripci ´on 17 - He actualizado mi suscripci ´on 18 - Me he suscrito a un nuevo servicio 19 rules : 68 20 - rule : Inform no provider 21 condition : 22 - active_loop : null 23 steps : 24 - intent : inform_no_provider 25 - action : action_no_provider 26 - rule : Change provider 27 condition : 28 - active_loop : null 29 steps : 30 - intent : inform_change_provider 31 - action : action_change_provider C´odigo 4.18: Datos de entrenamiento. Cambiar de plataforma de streaming. Finalizando estas mejoras vuelvo a publicar una nueva versi´on del chatbot. 4.8. Sprint 8 En este ´ultimo sprint reviso de nuevo las conversaciones y a˜nado algunos ejemplos y sin´onimos a los datos de entrenamiento. Se da por finalizado el desarrollo del chatbot. Durante las pr´oximas semanas se elaborara la memoria del Trabajo de Fin de Grado. 69 Cap´ıtulo 5 Estado final A lo largo de este cap´ıtulo se detalla el trabajo de an´alisis y pruebas con usuarios realizado. 5.1. An´alisis 5.1.1. Actores Actores que intervienen en el proyecto desarrollado: Usuario: Es la persona que accede a Telegram e inicia una conversaci´on con el chatbot. Este actor interact´ua directamente con el chatbot, solicitando informaci´on y recibiendo respuestas. API TMDB: Es un sistema externo que proporciona una fuente de datos para el chatbot. Ofrece endpoints para realizar consultas espec´ıficas sobre datos de pel´ıculas que el chatbot utiliza para responder al usuario. 5.1.2. Casos de Uso A partir de las reuniones con el tutor sobre la funcionalidad del chatbot y mi investigaci´on sobre las posibilidades del framework Rasa y la API de TMDB, he identificado los siguientes casos de uso: 70 CU-001 Solicitar recomendaci´on Versi´on 1.0 Precondici´on El usuario ha iniciado una conversaci´on con el chatbot Descripci´on El sistema deber´a comportarse como se describe en el siguiente caso de uso cuando el usuario solicite una recomendaci´on de pel´ıcula. Secuencia Paso Acci´on 1 El usuario escribe al chatbot con la intenci´on de que le recomiende una pel´ıcula 2 El sistema procesa el mensaje e identifica la intenci´on. 2.1 Si el sistema ya cuenta con todos los datos necesarios para realizar la recomendaci´on se salta al paso 9 3 El sistema pregunta al usuario si est´a suscrito a alguna plataforma de streaming. 4 El usuario responde. 5 El sistema valida la respuesta. 5.1 Si la respuesta es afirmativa el sistema pregunta a cu´al est´a suscrito. 5.2 El usuario responde. 5.3 El sistema valida la respuesta. 6 El sistema pregunta que g´enero de pel´ıculas le interesa. 7 El usuario responde. 8 El sistema valida la respuesta. 9 El sistema consulta la API TMDB aplicando los filtros con las respuestas del usuario. 10 La API TMDB responde con una lista de pel´ıculas que se pueden recomendar. 11 El sistema ejecuta el caso de uso descrito en la tabla 5.4 para reducir el n´umero de pel´ıculas. 12 El sistema env´ıa un mensaje al usuario con la pel´ıcula recomendada. 13 El sistema ejecuta el caso de uso descrito en la tabla 5.3. Postcondici´on Se le muestra al usuario un mensaje con el t´ıtulo completo de la pel´ıcula junto con el a˜no de estreno, su portada y puntuaci´on.. Excepciones Paso Acci´on 2 El sistema no detecta la intenci´on del usuario y le env´ıa un mensaje indicando que pruebe de nuevo. 5, 5.3, 8 El sistema env´ıa un mensaje indicando que no ha entendido la respuesta del usuario. 5.3 El sistema no encuentra la plataforma de streaming dada en la respuesta en dentro de la API TMDB. 8 El sistema no encuentra el g´enero de pel´ıcula dado en la respuesta en dentro de la API TMDB. Comentarios Tabla 5.1: CU-001 71 Figura 5.1: Diagrama Casos de Uso 78 CU-011 Solicitar informaci´on pel´ıcula Versi´on 1.0 Precondici´on El usuario ha solicitado conocer las pel´ıculas en las que ha trabajado un actor/director. Descripci´on El sistema deber´a comportarse como se describe en el siguiente caso de uso cuando el usuario solicite conocer m´as detalles sobre una pel´ıcula. Secuencia Paso Acci´on 1 El usuario env´ıa un mensaje con la intenci´on de conocer m´as informaci´on sobre una de las pel´ıculas en las que ha trabajado un actor/director. 2 El sistema procesa el mensaje e identifica la intenci´on. 3 El sistema utiliza el id de la pel´ıcula seleccionada para extraer informaci´on de la API TMDB. 4API TMDB responde con informaci´on adicional sobre la pel´ıcula. 5 El sistema env´ıa en un mensaje informaci´on sobre la pel´ıcula. Postcondici´on Se le muestra al usuario un mensaje con el t´ıtulo completo de la pel´ıcula junto con el a˜no de estreno, su portada y puntuaci´on. Excepciones Paso Acci´on 2 El sistema no detecta la intenci´on del usuario y le env´ıa un mensaje indicando que pruebe de nuevo. Comentarios Tabla 5.11: CU-011 5.1.3. Requisitos funcionales RF-001 Solicitar recomendaci´on Dependencias Ninguna Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario solicita que se le recomiende una pel´ıcula. Importancia Alta Comentarios Si los usuarios utilizan nuevas expresiones para solicitar recomendaciones de pel´ıculas, estas deber´ıan integrarse en los datos de entrenamiento para mejorar la capacidad de respuesta del chatbot. Tabla 5.12: RF-001 79 RF-002 Mostrar formulario Dependencias Ninguna Descripci´on El sistema deber´a realizar una serie de preguntas al usuario para conocer sus preferencias cinematogr´aficas y las plataformas de streaming que utiliza. Datos obligatorios que se deben obtener: Confirmaci´on si el usuario est´a suscrito a alguna plataforma y, en caso afirmativo, cu´al. El g´enero de pel´ıculas que prefiere ver. Importancia Alta Comentarios Es necesario que el usuario responda a todas antes de continuar en la conversaci´on. Tabla 5.13: RF-002 RF-003 Saludar Dependencias Ninguna Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario le env´ıa un saludo. Importancia Alta Comentarios El saludo marcar´a el inicio de la mayor´ıa de las historias. Tabla 5.14: RF-003 RF-004 Despedirse Dependencias Ninguna Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario se despide. Importancia Baja Comentarios Tabla 5.15: RF-004 RF-005 Solicitar resumen de pel´ıcula Dependencias 5.12 Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario le solicita un resumen de la pel´ıcula. Importancia Media Comentarios Se tomar´a el id de la ´ultima pel´ıcula guardada en el historial. Tabla 5.16: RF-005 80 RF-006 Solicitar actores Dependencias 5.12 Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario solicita conocer que actores participan en la pel´ıcula. En la respuesta se mostrar´a un listado de los principales actores. Se limitar´a el listado a 5 actores. Importancia Media Comentarios Se tomar´a el id de la ´ultima pel´ıcula guardada en el historial. Tabla 5.17: RF-006 RF-007 Solicitar directores Dependencias 5.12 Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario solicita conocer que directores dirigen la pel´ıcula. En la respuesta se mostrar´a un listado de los directores. Importancia Media Comentarios Se tomar´a el id de la ´ultima pel´ıcula guardada en el historial. Tabla 5.18: RF-007 RF-008 Solicitar informaci´on actor/director Dependencias 5.17, 5.18 Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario solicita informaci´on sobre el actor/director que el usuario indique. Importancia Media Comentarios Tabla 5.19: RF-008 81 RF-009 Solicitar pel´ıculas actor/director Dependencias 5.12 Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario solicita informaci´on sobre otras pel´ıculas en las que aparece el actor/director que se ha comentado recientemente. Se mostrar´a un listado limitado a 5 pel´ıculas. Importancia Media Comentarios Se utiliza el id del ´ultimo actor/director del que se ha hablado. Tabla 5.20: RF-009 RF-010 Solicitar pel´ıculas similares Dependencias 5.12 Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario solicita que se le muestre una pel´ıcula similar a la recomendada. Importancia Baja Comentarios Tabla 5.21: RF-010 RF-011 Mostrar informaci´on pel´ıcula Dependencias Ninguna Descripci´on El sistema deber´a mostrar la siguiente informaci´on de las pel´ıculas: T´ıtulo completo A˜no de estreno Puntuaci´on Imagen con la portada Importancia Baja Comentarios Tabla 5.22: RF-011 82 RF-011 Solicitar informaci´on pel´ıcula Dependencias ?? Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario informaci´on sobre una pel´ıcula Importancia Baja Comentarios Tabla 5.23: RF-011 RF-012 Mostrar informaci´on actor/director Dependencias Ninguna Descripci´on El sistema deber´a mostrar la siguiente informaci´on sobre los actore/directores: Nombre completo Fecha y lugar de nacimiento Peque˜na biograf´ıa Importancia Baja Comentarios Tabla 5.24: RF-012 RF-013 Usuario indica que le gusta la pel´ıcula Dependencias Ninguna Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario indica que le gusta una pel´ıcula. Importancia Baja Comentarios Tabla 5.25: RF-013 RF-014 Usuario indica que no le gusta la pel´ıcula Dependencias Ninguna Descripci´on El sistema deber´a ser capaz de reconocer y responder cuando el usuario indica que no le gusta una pel´ıcula. Importancia Baja Comentarios Tabla 5.26: RF-014 83 5.1.4. Requisitos no funcionales RNF-001 Utilizar el framework Rasa Dependencias Ninguna Descripci´on El sistema deber´a el framework Rasa para construir el chatbot. Importancia Alta Comentarios Tabla 5.27: RNF-001 5.1.5. Requisitos de almacenamiento informaci´on RI-001 Guardar pel´ıcula Dependencias Ninguna Descripci´on El sistema deber´a guardar un historial con los ids de las pel´ıculas recomendadas o mencionadas durante la conversaci´on. Importancia Alta Comentarios Este historial servir´a para no repetir recomendaciones al usuario y para poderle ofrecer informaci´on sobre la ´ultima pel´ıcula comentada. Tabla 5.28: RI-001 RI-002 Guardar actor/director Dependencias Ninguna Descripci´on El sistema deber´a guardar el id del ´ultimo actor/director mencionado durante la conversaci´on. Importancia Alta Comentarios Tabla 5.29: RI-002 RI-003 Guardar g´enero Dependencias Ninguna Descripci´on El sistema deber´a guardar el id del g´enero cinematogr´afico escogido por el usuario. Importancia Alta Comentarios Tabla 5.30: RI-003 84 RI-004 Guardar plataforma streaming Dependencias Ninguna Descripci´on El sistema deber´a guardar el id de la plataforma de streaming a la que este suscrito el usuario. Importancia Alta Comentarios Tabla 5.31: RI-004 5.2. Pruebas con usuarios La mayor parte de las pruebas, los usuarios interactuaron con el chatbot de manera telem´atica y sin mi supervisi´on directa, eligiendo el momento que m´as le conven´ıa. Sin embargo, si que pude realizar test de usabilidad con amigos y familiares cercanos lo que me permiti´o observar la interacci´on directa con los prototipos del chatbot e identificar posibles problemas. A continuaci´on describo los test realizados. 5.2.1. Tests de usabilidad Durante el test yo hac´ıa los roles de facilitador, guiando a los usuarios en las tareas les propon´ıa, y de observador, prestando atenci´on a el comportamiento del usuario y evaluando el prototipo. Este primer test (tabla 5.32) lo realizo con dos usuarios distintos al final del sprint 3, la primera versi´on del prototipo. Resultados: Ambos usuarios han sabido iniciar una conversaci´on con el chatbot sin problemas y le han podido saludar y despedirse sin dificultad. El mensaje inicial donde el chatbot describe su funcionalidad no ha quedado demasiado claro para el usuario 2. Ambos usuarios no han podido obtener una recomendaci´on de una pel´ıcula debido a 3 razones: utilizaban g´eneros de pel´ıculas que no estaban en los datos de entrenamiento, utilizaban expresiones diferentes de los ejemplos en los datos de entrenamiento y respond´ıan con un mensaje que no ten´ıan que ver con la pregunta. Debo mejorar la forma en la que el usuario introduce la informaci´on para ello aplicar´e los siguientes medidas: A˜nadir m´as ejemplos con expresiones sobre como informar el g´enero. Tomar´e ejemplos de las trazas de las conversaciones guardadas. Ampliar los g´eneros de pel´ıculas que el usuario puede responder, para ello utilizar´e una tabla lookup. Usar la estructura formulario para obligar al usuario a responder correctamente. 85 ID Di´alogo Observaciones Puntuaci´on U1 U2 1 Iniciar El usuario localiza al chatbot dentro de Telegram e inicia una conversaci´on 5 5 M´etrica: Si tarda hasta 15 segundos en iniciar la conversaci´on 2 Saludar El usuario env´ıa un saludo al chatbot 5 5 M´etrica: Si introduce alguno de los saludos disponibles en los datos de entrenamiento 3 Saludar El usuario comprende la utilidad del chatbot 5 3 M´etrica: Si hace comentarios o necesita aclaraci´on por parte del facilitador 4 Solicitar recomendaci´on El usuario le solicita al chatbot una recomendaci´on de pel´ıcula 4 4 M´etrica: Si tarda hasta 10 segundos en encontrar una expresi´on que el chatbot entienda como intenci´on de solicitar una recomendaci´on 5 Solicitar recomendaci´on El usuario comprende la pregunta sobre el g´enero de la pel´ıcula 5 5 M´etrica: Si hace comentarios o necesita aclaraci´on por parte del facilitador 6 Solicitar recomendaci´on El usuario es capaz de enviar un g´enero de pel´ıculas v´alido 1 1 M´etrica: Si tarda hasta 10 segundos en encontrar un g´enero disponible en los datos de entrenamiento 7 Despedirse El usuario se despide del chatbot 5 5 M´etrica: Si introduce alguna de las formas de despedirse disponibles en los datos de entrenamiento Tabla 5.32: Test usabilidad 86 El segundo test lo realizo en una fase m´as avanzada del prototipo y con m´as funcionalidades, al final del sprint 7 (tabla 5.33) . Resultados: Se han mejorado las deficiencias respecto al anterior test, el formulario funciona perfectamente y los ejemplos de g´eneros y plataformas de streaming cubren todas las necesidades de los usuarios. Las respuestas del chatbot parecen claras y maneja las entradas inesperadas bastante bien, pero necesita alguna mejora. La satisfacci´on de las pel´ıculas no es muy alta, tal vez habr´ıa que filtrar mejor la informaci´on proporcionada por la API TMDB. Algo que he notado que no estaba como prueba en los test era que en conversaciones muy largas el chatbot perd´ıa el rumbo de la conversaci´on, y fallaba en la detecci´on de algunos intents. 87 B.1. Nix y flakes (Opcional) Nix es una herramienta que simplifica la instalaci´on de paquetes en nuestra terminal. En particular, la uso para gestionar diferentes versiones de Python que necesito en mis proyectos. Por ejemplo, utilizo Python 3.10 para TFG y Python 3.12 en otro, y Nix me permite manejar ambas versiones simult´aneamente sin conflictos, asegurando un entorno de desarrollo organizado y eficiente. Una vez instalado Nix y su modulo flakes, siguiendo las gu´ıas oficiales, es necesario instalar y activar el paquete direnv. Con todo esto instalado (Nix, flakes y direnv) con tan solo entrar al directorio donde hemos clonado el proyecto Nix se encargar´a de descargar Python 3.10 y crear el entorno virtual. Pasos a seguir: 1git clone https :// gitlab . inf .uva .es / albcast / tfg .git 2 3# Acceder al directorio 4cd tfg 5 6# Permitir el uso de direnv 7direnv allow 8 9# Instalar dependencias del proyecto 10 pip install -r requirements . txt C´odigo B.2: Pasos de instalaci´on B.2. Poetry (Opcional) Poetry es una herramienta de gesti´on de dependencias y empaquetamiento para proyectos de Python. Se puede usar como sustituto de pip. Pasos a seguir: 1git clone https :// gitlab . inf .uva .es / albcast / tfg .git 2 3# Acceder al directorio 4cd tfg 5 6# Instalar dependencias del proyecto y crear entorno virtual 7poetry install C´odigo B.3: Pasos de instalaci´on 94 B.3. Ngrok (Opcional) Ngrok tambi´en ser´ıa una herramienta que me ha ayudado durante el desarrollo y que me facilita exponer la API con el modelo de Rasa al mundo para que pueda ser accesible por los servidores de Telegram. Esta herramienta es externa al proyecto, no hay ning´un fichero asociado a ella. Todo los ficheros necesarios para utilizar las distintas herramientas se encuentran en el repositorio del proyecto. 95 Ap´endice C Manual de configuraci´on C.1. Configuraci´on Antes de poner en funcionamiento el es necesario realizar las configuraciones necesarias para poder utilizar los servicios externos de los que dependemos: Telegram y TMDB. C.1.1. Telegram Token para el bot de Telegram Nombre del bot de Telegram URL p´ublica API Key de la API TMDB Dentro del fichero credentials.yml es necesario especificar las los par´ametros necesarios para conectar el chatbot a Telegram. El primer paso es obtener el token de nuestro bot en Telegram. Para conseguirlo, debes mantener una conversaci´on con @BotFather en Telegram, este bot es un asistente que te facilita la creaci´on de otros bots. 1. Busca al usuario @BotFather en Telegram. 2. Utiliza el comando /newbot para crear un nuevo bot. 3. El @BotFather te solicitar´a un nombre para el bot. Debes proporcionar uno que termine en bot o bot. 4. Para finalizar el @BotFather te entrega el token. 96 Tambi´en puedes personalizar el bot a˜nadiendo detalles como una descripci´on, comandos espec´ıficos y una foto de perfil. El siguiente campo en el fichero credentials.yml es verify, en ´el se debe incluir el nombre que se le ha dado al chatbot en Telegram. Por ´ultimo, en el apartado webhook url se le proporciona la url p´ublica para acceder a la API donde est´a el modelo de Rasa expuesto. A la url donde est´e publicado el chatbot es necesario a˜nadirle el siguiente sufijo al path /webhooks/telegram/webhook ya es el webhook correspondiente al servicio de Telegram. Por ejemplo si tenemos nuestro bot bajo el dominio https://example.com debemos escribir la siguiente url https://example.com/webhooks/telegram/webhook. 1telegram: 2access_token : "7148448146: AAFZcMQbz8_Akmy3SqmyiJcl7xf - fEWFpaM " 3verify : " tfgrasabot " 4webhook_url : " https :// example . com / webhooks / telegram / webhook " C´odigo C.1: Ejemplo de redenciales chatbot para Telegram El token de Telegram debe ser privado ya que sino cualquiera podr´ıa hacer uso del token para montar su propia implementaci´on de bot. C.1.2. TMDB Para poder hacer uso de los datos que nos proporciona la API de TMDB es necesario registrarse en su plataforma y obtener un API Key. Este API Key se utiliza en las llamadas a la API para identificarnos, sin ´el no podremos usar la API. Dentro del fichero actions/tmdb.py existe una variable global llamada API KEY se debe sustituir esa variable por la API Key proporcionada. La API Key de TMDB debe ser privada ya que sino cualquiera podr´ıa identificarse con nuestra cuenta en la API. 97 Ap´endice D Manual de despliegue Una vez tengamos las dependencias instaladas y el proyecto configurado podremos ejecutar el proyecto. En primer lugar es necesario entrenar el modelo. Los modelos entrenados por Rasa no se guardan en el repositorio del proyecto por lo que la primera vez que vayamos a desplegar el chatbot es necesario entrenar el modelo. Despu´es lanzamos los contenedores docker con los servicios MongoDB y MongoExpress que nos servir´an para almacenar y analizar las conversaciones. Finalmente lanzamos los procesos con el modelo de Rasa. En un primer terminal levantamos el proceso que levanta la API con el modelo de Rasa. En un segundo terminal levantamos el proceso con la API que contiene las acciones personalizadas. Asumiendo que ya est´a el proyecto descargado, instaladas las dependencias y configurado, nos situamos en la carpeta del proyecto y ejecutamos los siguiente pasos: 1# Entrenar modelo 2rasa train 3 4# Contenedores tracker 5docker compose up -d 6 7# Lanzar proceso con el modelo Rasa 8rasa run -m models -- endpoints endpoints . yml 9 10 # Lanzar segundo proceso con las acciones 11 rasa run actions C´odigo D.1: Pasos de despliegue El proceso que contiene la API con el modelo de Rasa se debe exponer para sea alcanzable por Telegram. Por defecto el puerto que utiliza es el 5005. Opcionalmente si no se quiere exponer directamente el servidor que aloja el proceso a internet 98 se puede utilizar ngrok. 1# Lanzar ngrok con redirecci ´on al puerto 5005 2.\ ngrok http 5005 C´odigo D.2: Pasos ngrok 99 Ap´endice E Manual de usuario Una vez se tenga el chatbot desplegado y listo para usarse el usuario final debe buscar en Telegram al usuario @tfgrasabot como se muestran en E.1. Figura E.1: Nombre del chatbot Para comenzar la conversaci´on pulsamos el bot´on start que provocar´a que se env´ıe un primer mensaje al chatbot con el texto /start. Este texto se tuvo en cuenta en los datos de entrenamiento del chatbot como un ejemplo de saludo. 100 Figura E.2: Comienzo de conversaci´on 101 Ap´endice F C´odigo El c´odigo con el c´odigo desarrollo a lo largo del proyecto se encuentra p´ublicado en el Gitlab de la escuela. Enlace: gitlab.inf.uva.es/albcast/tfg 102 Bibliograf´ıa [1] Javier Cepedano. Diferencias entre NLP, NLU y NLG.https://www.upbe.ai/blog/ diferencias-entre-nlp-nlu-y-nlg/, 2020. (acceso: 17-04-2024). [2] Juan Guti´errez. Convenio colectivo de consultor´ıa.https://planesdefuturo.mapfre.es/ economia-domestica/empleo/convenio-colectivo-consultoria/, 2023. (acceso: 09-06- 2024). [3] IBM. ¿Qu´e es un chatbot? https://www.ibm.com/es-es/topics/chatbots. (acceso: 08- 05-2024). [4] ipglobal. ¿C´omo entiende un Bot? NLU en Rasa.https://www.ipglobal.es/ como-entiende-un-bot-nlu-en-rasa/. (acceso: 11-05-2024). [5] Rasa Jira. When integrating a Telegram bot with the Rasa framework, I am consistently encountering a ‘RuntimeError‘ stating that the event loop is closed. https:// rasa-open-source.atlassian.net/browse/OSS-764, 2024. (acceso: 07-04-2024). [6] Gianna Maderis. Top 22 benefits of chatbots for businesses and customers.https://www. zendesk.es/blog/5-benefits-using-ai-bots-customer-service/, 2024. (acceso: 08-05- 2024). [7] Alan Nichol. Rasa CDD Docs.https://rasa.com/blog/ conversation-driven-development-a-better-approach-to-building-ai-assistants/, 2020. (acceso: 10-05-2024). [8] Rasa. Rasa CDD Docs.https://rasa.com/docs/rasa/ conversation-driven-development. (acceso: 02-03-2024). [9] Rasa. Rasa Config Overview.https://learning.rasa.com/ conversational-ai-with-rasa/pipeline/. (acceso: 10-05-2024). [10] Rasa. Rasa Docs.https://rasa.com/docs/rasa. (acceso: 02-03-2024). [11] Rasa. Rasa Responses Docs.https://rasa.com/docs/rasa/responses. (acceso: 02-03- 2024). [12] Rasa. Rasa Rules Docs.https://rasa.com/docs/rasa/rules. (acceso: 02-03-2024). [13] Rasa. Rasa Stories Docs.https://rasa.com/docs/rasa/stories. (acceso: 02-03-2024). 103