Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
Odiseo: cuando crear un chatbot es cosa de niños Grado en Ingeniería Informática Trabajo Fin de Grado Autor: Jonathan Verdú Verdú Tutor/es: David Tomás Díaz Julio 2022 Odiseo: cuando crear un chatbot es cosa de niños Autor Jonathan Verdú Verdú Tutor/es David Tomás Díaz DPTO Lenguajes y Sistemas Informáticos ALICANTE, Julio 2022 V Agradecimientos El esfuerzo de este trabajo no habría sido posible sin el apoyo y el cariño de personas como mi familia que, desde el primer momento, me dieron ánimos, enseñándome a ser constante y haciendo todo lo posible para que estuviese cómodo y concentrado. Agradezco también haber hecho caso a los consejos y experiencias de mis compañeros de carrera, que me han acompañado durante 4 largos años, compartiendo momentos únicos y ayudándome a superar todas las pruebas. Por último, quiero hacer menciones a mis amigos de toda la vida, que incondicionalmente, me han aportado su opinión sobre el trabajo y, por supuesto, a mi tutor David, la única persona que me ha sabido guiar durante todo el proyecto y me ha sabido aconsejar sabiamente, como buen profesor y especialista en su campo. Es, sin duda, a todas esas personas a las que les dedico mi aportación con este proyecto y lo que representa para mí y para todas aquellas personas que lo necesiten. VII El sabio no dice todo lo que piensa, pero siempre piensa todo lo que dice. Sócrates Solo aquellos que miran con los ojos de los niños se pueden perder en el objeto de su admiración. Eberhard Arnold https://proverbia.net/autor/frases-de-socrates IX Índice de contenidos 1. Introducción .............................................................................................. 1 2. Objetivos ................................................................................................... 6 3. Metodología .............................................................................................. 8 3.1 Investigaciones previas ........................................................................ 9 3.2 Herramientas de planificación y gestión de tiempo ........................... 11 4. Estado de la cuestión ............................................................................... 13 5. Marco teórico .......................................................................................... 23 5.1 Hablar con una máquina .................................................................... 23 5.2 Intenciones del usuario ....................................................................... 25 5.3 Procesamiento de lenguaje natural (PLN) ......................................... 27 5.3.1 Problemas del lenguaje humano .................................................. 29 5.3.2 Soluciones del algoritmo ............................................................. 32 6. Herramientas y tecnologías ..................................................................... 36 6.1 Administrador de base de datos MongoDB ....................................... 36 6.1.1 Conexión y librería Mongoose .................................................... 38 6.2 Visual Studio Code ............................................................................ 38 6.2.1 Node Javascript ............................................................................ 39 6.3 Data Cloud Heroku ............................................................................ 40 6.3.1 Servidor local Ngrok .................................................................... 41 6.4 Control de versiones Github .............................................................. 42 6.5 Servidor de ImgBB ............................................................................ 44 6.6 Google Cloud ..................................................................................... 45 6.6.1 Credenciales Cloud SDK ............................................................. 49 6.6.2 Google Dialogflow....................................................................... 50 6.6.3 Google Actions ............................................................................ 53 7. Arquitectura del sistema .......................................................................... 56 7.1 Gestión de los datos ........................................................................... 58 7.1.1 Justificación de los datos ............................................................. 60 X ÍNDICE DE CONTENIDOS 7.1.2 Aviso legal ................................................................................... 61 7.1.3 Persistencia de los datos .............................................................. 62 7.1.4 Proceso de recopilación y almacenamiento ................................. 64 7.2 Gestión del aprendizaje automático ................................................... 71 7.2.1 Emparejamiento de intenciones ................................................... 72 7.2.2 Gestión de webhooks y fulfillment .............................................. 74 7.3 Gestión del servidor ........................................................................... 76 7.3.1 Concurrencia de usuarios ............................................................. 78 7.3.2 Funcionalidades de control .......................................................... 80 7.4 Interfaces del usuario final ................................................................. 82 8. Conclusiones ........................................................................................... 85 Bibliografía .................................................................................................. 87 Anexos ......................................................................................................... 89 A1. Historia del PLN ............................................................................ 89 A2. Herramientas de desarrollo para PLN ............................................ 90 A3. Aplicaciones actuales de PLN ....................................................... 91 A4. Documento de política de privacidad de Odiseo ........................... 92 XI Índice de figuras Figura 3.1: Planificación temporal del proyecto mediante un diagrama de Gantt .............................................................................................................. 8 Figura 3.2: Resumen de cambios en un archivo del proyecto en Github .. 12 Figura 3.3: Vista general del proyecto en Github ...................................... 12 Figura 4.1: Consulta de una reserva de viaje a través de TravelClub ....... 14 Figura 4.2: Petición de una compra online a través de Eroski Supermarkets ..................................................................................................................... 14 Figura 4.3: Comandos de voz recibidos por el dispositivo Echo .............. 15 Figura 4.4: Ejemplo de comunicación domótica con el asistente Siri ....... 16 Figura 4.5: Diseño de asistentes por LiveChat Software ........................... 17 Figura 4.6: Diseño de asistentes por Boost.AI .......................................... 17 Figura 4.7: Conversación con Differ ......................................................... 19 Figura 4.8: Sistema de evaluación con Hubert .......................................... 20 Figura 4.9: Conversación con DulcineIA .................................................. 22 Figura 5.1: Boceto esquemático sobre el ciclo de la comunicación .......... 23 Figura 5.2: Comparación del cerebro humano con el PLN ....................... 25 Figura 5.3: Esquema de funcionamiento Dialogflow y sus componentes . 26 Figura 5.4:Ejemplo de análisis sintáctico en una oración compuesta ...... 29 Figura 5.5: Ejemplo de un árbol de decisiones para detectar el fin de una expresión ..................................................................................................... 33 Figura 5.6: Esquema sobre el funcionamiento de reconocimiento interno de Dialog Flow ............................................................................................ 34 Figura 6.1: Esquema de una colección de datos embebida para MongoDB ..................................................................................................................... 37 Figura 6.2: Interfaz del cluster MongoDB Atlas ....................................... 37 Figura 6.3: Biblioteca de extensiones en Visual Studio Code ................... 39 Figura 6.4: Consola de despliegue en Heroku ........................................... 40 Figura 6.5: Terminal ejecutado por una conexión de Ngrok ..................... 42 Figura 6.6: Interfaz de cambios en Github Desktop .................................. 44 Figura 6.7: Biblioteca de imágenes utilizadas para Odiseo en el servidor ImgBB ......................................................................................................... 45 Figura 6.8: Esquema de servicios ofrecidos por Google Cloud Platform . 46 Figura 6.9: Panel administrativo de Google Cloud Platform .................... 48 XII ÍNDICE DE FIGURAS Figura 6.10: Estadísticas de rendimiento por Dialogflow del proyecto Odiseo .......................................................................................................... 48 Figura 6.11: Comprobación de credenciales de Odiseo a través de la Shell Cloud SDK .................................................................................................. 50 Figura 6.12: Interfaz de desarrollo de Dialogflow..................................... 51 Figura 6.13: Validaciones de entrenamiento en Dialogflow ..................... 52 Figura 6.14: Funcionalidades de la API de Dialogflow ............................ 52 Figura 6.15: Diseño de interacciones en Actions Console ........................ 54 Figura 6.16: Respuesta del asistente de voz Odiseo, el mochuelo inteligente .................................................................................................... 55 Figura 7.1: Esquema estructural del asistente educativo Odiseo .............. 56 Figura 7.2: Fragmento del documento de política de privacidad de Odiseo ..................................................................................................................... 62 Figura 7.3: Esquema genérico para la base de datos de Odiseo ................ 63 Figura 7.4: Ejemplo de consulta para una base de datos MongoDB ......... 64 Figura 7.5: Ejemplos de Odiseo pidiendo información al usuario ............ 65 Figura 7.6: Ejemplos de Odiseo mostrando error por la validación al usuario ......................................................................................................... 67 Figura 7.7: Ejemplo de Odiseo mostrando error por la validación de una pregunta ....................................................................................................... 69 Figura 7.8: Ejemplo de Odiseo mostrando un control de los inputs pendientes .................................................................................................... 70 Figura 7.9: Conexión entre API Node.js y MongoDB Atlas ..................... 71 Figura 7.10: Comparación entre intents de Odiseo y opciones del interfaz ..................................................................................................................... 73 Figura 7.11: Información recogida por el webhook de una intención ....... 75 Figura 7.12: Conexión pública entre Dialogflow y el servidor de Odiseo 76 Figura 7.13: Vista general del código del servidor y los archivos utilizados ..................................................................................................................... 78 Figura 7.14: Proceso de conexión con concurrencia entre usuario y servidor ........................................................................................................ 79 Figura 7.15: Ejemplo de datos almacenados en User storage ................... 81 Figura 7.16: Comunicación entre las dos interfaces a través de Enviar pregunta ....................................................................................................... 83 Figura 8.1: Hitos históricos sobre el PLN ................................................. 89 XIII Índice de tablas Tabla 7.1: Datos generales recogidos por la aplicación ............................. 59 Tabla 7.2: Referencias de variables reutilizables ....................................... 60 1 1. Introducción El auge y la globalización de la Inteligencia Artificial (IA), nos ha permitido conocer un mundo dónde los asistentes de voz son cada vez más comunes en los dispositivos electrónicos. Sin embargo, aunque parezca algo novedoso, ya en la década de los sesenta se introdujo el primer dispositivo conversacional [1], conocido como ELIZA1. En 1966, el profesor Joseph Weizenbaum, del Instituto Tecnológico de Massachusetts, originó el primer bot conversacional para que hablase por escrito con un humano, simulando comprensión y empatía. Esta tecnología, a su vez, se basaba en el test de Turing2, quien en 1950 (dieciséis años antes), publicaba su artículo Computing Machinery and Intelligence3 cuando trabajaba en la Universidad de Mánchester. El artículo documentaba un experimento [2] dónde actuaban diferentes sujetos humanos y una máquina simulando una conversación natural. La particular propuesta de Alan Turing, diseñada para averiguar los límites de la IA, puso en evidencia la capacidad que tenía dicha máquina de confundir al interlocutor, cuando éste no podía diferenciarla de una persona real. El esfuerzo de las primeras investigaciones sobre sistemas inteligentes provocó una carrera tecnológica, por parte de los mejores ingenieros, hasta conseguir en pleno siglo XXI, un impacto revolucionario en la sociedad. La integración de esta inteligencia robótica se ha convertido en un hecho en nuestras vidas y herramientas como los sistemas de navegación y seguridad 1 Acceso al emulador psicológico que imita al programa clásico y original (http://deixilabs.com/eliza.html) 2 Acceso al emulador visual simplificado que imita el experimento, con algunas limitaciones (https://umhsapiens.com/eres-un-robot-aprueba-el-test-de-turing/) 3 Artículo en formato PDF extraído de su versión original (https://www.csee.umbc.edu/courses/471/papers/turing.pdf) http://deixilabs.com/eliza.html https://umhsapiens.com/eres-un-robot-aprueba-el-test-de-turing/ https://www.csee.umbc.edu/courses/471/papers/turing.pdf 2 INTRODUCCIÓN de los coches autónomos, el traductor, el corrector de palabras o los asistentes de voz de las compañías telefónicas, demuestran su importancia. Muchos hogares, por ejemplo, cuentan con asistentes digitales, como Echo, Siri o Cortana, que les permiten automatizar tareas y consultar búsquedas de información. Otros sectores empresariales como las grandes marcas, utilizan chatbots [3] para facilitar un soporte guiado al usuario, cuando necesita realizar un pago, una compra o una reserva a través de internet. Estas aplicaciones, además, permiten mejorar la eficiencia operativa de la empresa al reducir el coste del servicio al cliente, así como los turnos del personal, ya que se encuentran disponibles las 24h. En el dominio educativo [4] también se han estado desarrollando asistentes interactivos. Muchas de estas herramientas se presentan como ayudas para el aprendizaje: juegos educativos, plataformas de comunicación con los profesores, sistemas de organización para los alumnos o inclusoaplicaciones de evaluación con reglas preestablecidas. Como podemos observar, la presencia de estas aplicaciones podemos encontrarla en cualquier ámbito, lo que significa que dependemos constantemente de su uso y debemos confiar en la información que nos ofrecen. Este contexto social nos lleva a justificar la importancia del trabajo que a continuación se va a presentar, ya que se trata del desarrollo de un agente conversacional o chatbot. Hoy en día el desarrollo de estas aplicaciones se ha simplificado enormemente gracias a herramientas que ofrecen una interfaz de programación, como puede ser DialogFlow de Google4 (una herramienta de análisis y desarrollo gratuita para chatbots). Sin embargo, crear una IA capaz de comunicarse con un humano no es tan sencillo, ya que se tiene que 4 Acceso a Google Dialogflow (https://cloud.google.com/dialogflow/) https://cloud.google.com/dialogflow/ 3 INTRODUCCIÓN afrontar el problema de la ambigüedad y variabilidad del lenguaje humano usando técnicas de Procesamiento del Lenguaje Natural (PLN). Además, el apoyo humano juega un papel importante, ya que independientemente del tipo de enfoque y la plataforma, la intervención humana es crucial para configurar, capacitar y optimizar el sistema del chatbot. En otras palabras, se necesitan personas con conocimientos en el campo computacional para entrenar esa inteligencia. Pero, en ese caso, surgen algunas preguntas cómo: ¿Sería posible entrenar una IA de manera sencilla y sin conocimientos informáticos? ¿Se puede desarrollar una aplicación genérica para cualquier uso? ¿Se puede entrenar de forma ilimitada a un agente?. Para solventar todas estas dudas, nace el proyecto Odiseo, el proyecto desarrollado en este TFG. Odiseo, conocido como “el mochuelo inteligente” o “el asistente educativo”, nace precisamente de la idea de conseguir un asistente virtual, capaz de ser intuitivo para todas aquellas personas que no están familiarizadas con el uso de las tecnologías. Además, su sistema de aprendizaje sobrepasa los límites de los bots convencionales, pues a diferencia de los propios asistentes de Google o Alexa, que sólo son capaces de responder intenciones predefinidas, Odiseo es capaz de almacenar preguntas de los propios usuarios como intenciones, lo que permite que cualquier persona pueda adaptarlo para uso personal. El sistema está diseñado como un bot genérico de aplicación general a cualquier ámbito. Sin embargo, en este proyecto nos hemos querido centrar en algo más específico, como es el ámbito educativo. Concretamente, su interfaz permite que profesores y alumnos puedan desarrollar de manera colaborativa su base de conocimiento, además de la interacción convencional en la que se realizan consultas y se reciben respuestas por parte del chatbot 4 INTRODUCCIÓN una vez entrenado. Su estructura, además, permite una autenticación segura de los usuarios respetando su privacidad. Dispone de dos modos de uso interactivos: bien a través de su web, como agente de chat5, o bien a través del propio asistente de Google como agente de voz6. Gracias a este último, los alumnos también podrán participar en la propuesta de nuevas cuestiones que los profesores revisarán, confirmando o rechazando su integración (simulando un sistema de evaluación). Teniendo en cuenta su usabilidad con comandos de voz (que facilita el acceso a usuarios con unas competencias digitales más limitadas), sus ilustraciones adaptadas a un público infantil y sus menús personalizados para un contexto educativo, Odiseo es la herramienta ideal para aprender, compartir y divertirse. Una herramienta colaborativa que cualquier usuario puede utilizar, desde los más jóvenes hasta los más seniors, incluyendo todas las edades. Comprendiendo la importancia del proyecto, a continuación se detalla cómo sigue la estructura de esta memoria. En la Sección 2 definiremos los objetivos que se han propuesto durante el proyecto. En la Sección 3 hablaremos de la metodología utilizada y de la gestión del tiempo durante su desarrollo. En la Sección 4 abordaremos el estado de la cuestión, donde compararemos nuestro sistema con herramientas similares del mercado. En la Sección 5 explicaremos con detalle los fundamentos y las bases de funcionamiento de los chatbots y del PLN. En la Sección 6 nos centraremos en las herramientas utilizadas durante su implementación. En la Sección 7 analizaremos la estructura y los esquemas de relación de datos utilizados 5 Acceso a la interfaz web, diseñada para profesores (https://odiseo-chatbot.herokuapp.com/) 6 Acceso a la interfaz de voz, con un estilo infantil, diseñada para alumnos (https://assistant.google.com/services/invoke/uid/000000ea15df3d39/alm/CgRnuCCfEgIQAQ== ?hl=es) https://odiseo-chatbot.herokuapp.com/ https://assistant.google.com/services/invoke/uid/000000ea15df3d39/alm/CgRnuCCfEgIQAQ==?hl=es https://assistant.google.com/services/invoke/uid/000000ea15df3d39/alm/CgRnuCCfEgIQAQ==?hl=es 5 INTRODUCCIÓN en su ejecución. En la Sección 8 realizaremos algunas conclusiones acerca de todo lo que se ha estado trabajando. Por último, las referencias y anexos se muestran al final de este documento. Todo el código de este proyecto se encuentra disponible en el siguiente enlace de Github, para que el lector pueda consultar libremente los detalles de implementación: https://github.com/jonaverd/chatbot-project https://github.com/jonaverd/chatbot-project 6 2. Objetivos El objetivo general de este proyecto es el desarrollo y entrenamiento de un robot conversacional educativo, capaz de interactuar con los usuarios de manera autónoma. Para su elaboración se han cumplimentado como requisitos los siguientes objetivos principales: • Comprender la complejidad de un chatbot y su arquitectura de integración en los dispositivos digitales. • Investigar el funcionamiento de las técnicas de PLN aplicadas al desarrollo de chatbots. • Aprender el uso de la herramienta Dialogflow de Google para desarrollar y entrenar un chatbot personalizado. • Analizar la aplicación del chatbot desarrollado en un entorno con usuarios reales. Durante la fase de desarrollo, se han tenido en cuenta otras pautas que mejoran y optimizan la calidad de este proyecto. Los siguientes objetivos secundarios complementan a los ya mencionados anteriormente: • Diseñar una interfaz intuitiva para los usuarios, haciendo posible su integración en páginas web y dispositivos móviles. • Investigar la documentación sobre la API de DialogFlow, para descubrir y desarrollar funcionalidades más complejas que su interfaz básica no permite. 7 OBJETIVOS • Comunicar el chatbot con un servidor, a través de eventos, para procesar y almacenar la información del usuario. • Facilitar la conexión de un servidor público, que permita una concurrencia de usuarios y una disponibilidad las 24h. • Investigar el uso de Google Actions7 y su integración, como asistente de voz del proyecto. • Conocer el uso de bases de datos no relacionales y su aplicación para almacenar y recuperar estructuras sencillas de datos. • Aplicar conocimientos sobre Javascript y entornos de programación, para facilitar la integración de una API personalizada, para la gestión y desarrollo del proyecto. 7 Acceso a Google Actions (https://developers.google.com/assistant/console) https://developers.google.com/assistant/console 8 3. Metodología En este apartado se va a explicar la planificación que hemos seguido para lograr la consecución de los objetivos, como las investigaciones previas de aprendizaje, la gestión del tiempo y el control de versiones. Este proyecto no ha hecho uso de ninguna metodología estándar de desarrollo y, por lo tanto, se debe valorar la gestión personal que se ha realizado durante su elaboración. A continuación, se muestraun diagrama de Gantt8 (Figura 3.1) para resumir la planificación temporal de todo el proyecto. Figura 3.1: Planificación temporal del proyecto mediante un diagrama de Gantt 8 Visualización web del diagrama (https://www.canva.com/design/DAFEKeHzX9I/GalQbOe1ugn2EsXXea7kmA/edit?utm_content =DAFEKeHzX9I&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton) https://www.canva.com/design/DAFEKeHzX9I/GalQbOe1ugn2EsXXea7kmA/edit?utm_content=DAFEKeHzX9I&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton https://www.canva.com/design/DAFEKeHzX9I/GalQbOe1ugn2EsXXea7kmA/edit?utm_content=DAFEKeHzX9I&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton 9 METODOLOGÍA 3.1 Investigaciones previas En primer lugar, para hacer frente a la finalidad inicial del proyecto, se tuvo que investigar durante las primeras semanas el funcionamiento básico de un chabot y de qué manera se utilizaba en los dispositivos actuales (como los asistentes personales). Estos agentes conversacionales suponían, al mismo tiempo, una investigación sobre el PLN ya que se basan, precisamente, en dichos algoritmos. Por este motivo, durante las siguientes semanas se buscó información sobre el funcionamiento de esta tecnología y su relación con el lenguaje humano. Una vez conocida la información básica sobre los chatbots, se necesitaba empezar con la creación de uno propio. Para ello, se tomó la propuesta de la herramienta DialogFlow de Google, gracias a que era gratuita, innovadora y fácil de manejar. Esta herramienta tomó los siguientes meses de desarrollo e investigación para conocer mejor su API y las características que ofrecía el uso de sus webhooks. Cuando hablamos de webhooks, nos referimos a los eventos desencadenados por Dialogflow. Cada vez que un usuario interactúa con el agente, éste desencadena un evento que normalmente provoca una petición web. Si interceptamos estas peticiones a través de un servidor intermedio (técnica conocida como fulfillment), podremos conocer la información que se está escribiendo en el chat. Durante su programación, se tomó en cuenta el aprendizaje de Ngrok9, ya que las pruebas con DialogFlow, requerían una conexión pública teniendo un servidor en local. También se aprovechó la ocasión durante esos meses para repasar conceptos relacionados sobre Javascript, Node.js10, llamadas 9 Acceso y descarga Ngrok (https://ngrok.com/) 10 Acceso y descarga Node.js (https://nodejs.org/es/) https://ngrok.com/ https://nodejs.org/es/ 10 METODOLOGÍA asíncronas, creación de servidores, peticiones HTML y entornos de programación como Visual Studio Code11. A mitad del proyecto se consiguió un modelo básico de funcionamiento, lo que supuso el siguiente paso: la integración con la base de datos y su enfoque educativo. Aprovechando la oportunidad, se investigó sobre las bases de datos no relacionales como MongoDB12, por su libertad de restricciones para estructuras sencillas de datos en comparación con las relacionales. Cuando finalizó el modelo definitivo con la base de datos integrada, se propuso una entidad para el chatbot, con un nombre, un eslogan y un logotipo. Durante los siguientes meses, se arreglaron bugs y fallos de la interfaz que provocaban faltas de usabilidad. Para los últimos meses de desarrollo, se estuvo trabajando en la publicación de un hosting público como Heroku13, lo que permitía una disponibilidad de acceso las 24h sin usar un servidor local y se aprovechó para añadir la concurrencia de usuarios. Además, se tuvieron en cuenta otras integraciones adicionales, como el asistente de voz de Google Actions, aprovechando un estudio sobre el mismo. Por último, se decidió que la interfaz web se enfocaría en un tono más serio para la enseñanza de los profesores, mientras que la de voz se presentaría infantilizada para el aprendizaje de los alumnos, siendo ésta última más accesible para cualquier usuario. 11 Acceso y descarga Visual Studio Code (https://code.visualstudio.com/) 12 Acceso a MongoDB (https://www.mongodb.com/) 13 Acceso a Heroku (https://www.heroku.com/) https://code.visualstudio.com/ https://www.mongodb.com/ https://www.heroku.com/ 11 METODOLOGÍA 3.2 Herramientas de planificación y gestión de tiempo En cuanto a la gestión del tiempo, establecíamos un recordatorio con los avances a conseguir o investigar durante las horas de trabajo de ese día, cumpliendo con los plazos de entrega. Estas horas de trabajo podían variar de entre 6 a 8 horas, según su situación, contando días laborales. Cada dos semanas, aproximadamente, se llevaba a cabo una revisión obligatoria por parte del profesor responsable, para comprobar y confirmar los avances establecidos en las sesiones anteriores. Aunque no se han hecho uso de herramientas externas de planificación, se ha llevado un control estricto de las sesiones de trabajo gracias a la herramienta de Github14, una web de alojamiento de código con control de versiones. Cada una de estas versiones reflejan los cambios de código que se actualizaban en cada interacción, demostrando un progreso de desarrollo. A continuación, se muestran unas imágenes de Github, dónde se pueden observar cambios en los diferentes archivos del proyecto como en la Figura 3.2, así como una pequeña presentación de uso, para otorgarle más visibilidad como en la Figura 3.3. 14 Acceso a Github (https://github.com) https://github.com/ 12 METODOLOGÍA Figura 3.2: Resumen de cambios en un archivo del proyecto en Github Figura 3.3: Vista general del proyecto en Github 13 4. Estado de la cuestión Durante las últimas décadas, el consumo de la tecnología ha implicado una necesidad de innovación por parte de todas las empresas. Nuestra sociedad se ha modernizado y, por lo tanto, es lógico pensar que los consumidores buscan cada vez más un mercado competitivo en los sectores informáticos. Si nos centramos en el mercado de la inteligencia artificial, por ejemplo, podemos observar una gran demanda por los asistentes conversacionales. Estas aplicaciones se están convirtiendo en un estándar, debido a la digitalización que están sufriendo muchos sectores [3]. Podemos encontrar algunos ejemplos en el sector de viajes y ocio, como Gol Airlines15, TravelClub16 (representado en la Figura 4.1), Stubhub17; en el sector energético, como Naturgy18, Butagaz19; en supermercados y comercios, como Benefit Cosmetics20, Eroski Supermarkets21 (representado en la Figura 4.2); en el campo sanitario, como DKV22; o en el sector logístico, como Correos23. Estas herramientas, sin embargo, se diseñan con el propósito limitado de facilitar operaciones con dicha empresa. Mediante su IA son capaces de resolver consultas sencillas de atención al cliente o la gestión de algunas transacciones (compras, reservas, verificaciones, etc.) 15 Asistente Gol Airlines (https://www.voegol.com.br/es-ar/atencion/chat-gal) 16 Asistente TravelClub (https://www.travelclub.es/ayuda.cfm#) 17 Web Stubhub con asistente desplegable (https://www.stubhub.es/) 18 Asistente Naturgy (https://www.naturgy.es/asistente_virtual) 19 Asistente Butagaz (https://www.butagaz.fr/contact?contact[mode]=chat&contact[account]=GEC) 20 Web Benefit Cosmetics con asistente desplegable (https://www.benefitcosmetics.com/en-us) 21 Web Eroski Supermarkets con asistente desplegable (https://supermercado.eroski.es/en/) 22 Web DKV con asistente desplegable (https://dkv.es/particulares) 23 Web Correos con asistente desplegable (https://www.correos.es/es/es/atencion-al-cliente) https://www.voegol.com.br/es-ar/atencion/chat-gal https://www.travelclub.es/ayuda.cfm https://www.stubhub.es/ https://www.naturgy.es/asistente_virtual https://www.butagaz.fr/contact?contact%5bmode%5d=chat&contact%5baccount%5d=GEC https://www.benefitcosmetics.com/en-us https://supermercado.eroski.es/en/https://dkv.es/particulares https://www.correos.es/es/es/atencion-al-cliente 14 ESTADO DE LA CUESTIÓN Figura 4.1: Consulta de una reserva de viaje a través de TravelClub Figura 4.2: Petición de una compra online a través de Eroski Supermarkets 15 ESTADO DE LA CUESTIÓN En el mercado de estas aplicaciones, también podemos encontrarnos con asistentes personales con una IA algo más avanzada. Su sistema les permite conversar con una persona, realizando búsquedas de información más complejas, detectar emociones o incluso automatizar procesos (aparatos inteligentes o sistemas de domótica24). Muchos de estos asistentes son conocidos, como puede ser: Alexa25, el asistente de voz de Amazon (representado en la Figura 4.3); el propio Asistente de Google26; Siri27, el asistente de voz de Apple (representado en la Figura 4.4); Cortana28, como asistente de Microsoft; o Bixby29, el asistente digital de Samsung. Figura 4.3: Comandos de voz recibidos por el dispositivo Echo 24 La domótica es el conjunto de tecnologías que posibilitan la automatización de determinadas acciones de los objetos de una vivienda. 25 Web Alexa (https://developer.amazon.com/es-ES/alexa) 26 Web Google Assistant (https://assistant.google.com/) 27 Web Siri (https://www.apple.com/es/siri/) 28 Web Cortana (https://apps.microsoft.com/store/detail/cortana/9NFFX4SZZ23L?hl=en- us&gl=US) 29 Web Bixby (https://www.samsung.com/us/apps/bixby/) https://developer.amazon.com/es-ES/alexa https://assistant.google.com/ https://www.apple.com/es/siri/ https://apps.microsoft.com/store/detail/cortana/9NFFX4SZZ23L?hl=en-us&gl=US https://apps.microsoft.com/store/detail/cortana/9NFFX4SZZ23L?hl=en-us&gl=US https://www.samsung.com/us/apps/bixby/ 16 ESTADO DE LA CUESTIÓN Figura 4.4: Ejemplo de comunicación domótica con el asistente Siri La dificultad de competir en un mercado tan extenso, no sólo reside en la variedad de estas aplicaciones, sino en su facilidad de desarrollo. Existen “frameworks” o herramientas de desarrollo capaces de crear estos asistentes de manera personalizada y sencilla, integrando sus funcionalidades en cualquier contexto. En este proyecto, hemos tenido en cuenta la utilización de Google Dialogflow para las funcionalidades de Odiseo. Sin embargo, existen otras alternativas de diseño, utilizadas por empresas de comunicaciones que ofrecen soluciones de integración para otros comercios. Algunos ejemplos los podemos encontrar en: Chatbot30, por LiveChat 30 Diseño con Chatbot LiveChat Software (https://www.chatbot.com/features/) https://www.chatbot.com/features/ 17 ESTADO DE LA CUESTIÓN Software (representado en la Figura 4.5); Drift31, Boost.AI32 (representado en la Figura 4.6), Kore33, UChat34, etc. Figura 4.5: Diseño de asistentes por LiveChat Software Figura 4.6: Diseño de asistentes por Boost.AI 31 Diseño con Drift (https://www.drift.com/solutions/real-time-personalization/) 32 Diseño con Boost.AI (https://www.boost.ai/product) 33 Diseño con Kore (https://kore.ai/platform/virtual-assistant/) 34 Diseño con UChat (https://www.uchat.com.au/features) https://www.drift.com/solutions/real-time-personalization/ https://www.boost.ai/product https://kore.ai/platform/virtual-assistant/ https://www.uchat.com.au/features 18 ESTADO DE LA CUESTIÓN Como se puede observar, el uso público de estas herramientas supone un desafío si se desea presentar un trabajo único. Esta es la reflexión, por la que nos hemos centrado en ofrecer algo diferente a los chatbots convencionales. La ventaja competitiva de Odiseo frente a estas aplicaciones reside en su capacidad de entrenamiento. A diferencia de los asistentes personales (configurados sólo para detectar ciertas entradas), Odiseo es capaz de almacenar cualquier entrada del usuario como una intención. Esto supone, una configuración guiada del asistente, sin tener que programarlo desde cero (sin utilizar frameworks complicados). Además, su interfaz intuitiva permite que cualquier persona sin conocimientos técnicos (¡hasta un niño!) pueda alimentar sus enseñanzas de IA. Otra de las ventajas de Odiseo es su capacidad de adaptación, ya que a diferencia de los asistentes empresariales (limitados a las operaciones de su sector), Odiseo puede integrarse en cualquier ámbito, según lo que el usuario desee. En nuestro caso, hemos aprovechado su capacidad de intenciones para ofrecer una herramienta de apoyo educativo, una herramienta sencilla de utilizar y de uso práctico, con el objetivo final de formar una comunidad de opiniones, donde todos puedan participar, aportando sus conocimientos. La palabra “colaborativo” resume el propósito que Odiseo destaca frente a otros chatbots. No obstante, debemos tener en cuenta que el campo educativo [4] también se ha digitalizado, lo que supone otro reto si deseamos destacar en dicho contexto. Una de las referencias vigentes por excelencia es el proyecto EDUBOTS35 (fundado por la comisión europea en 2019 junto a la organización de ERASMUS) 35 Proyecto EDUBOTS (https://www.edubots.eu/edubots-about-the-project) https://www.edubots.eu/edubots-about-the-project 19 ESTADO DE LA CUESTIÓN La propuesta de EDUBOTS [5] no sería posible sin el apoyo de diferentes socios, entre los que se encuentran universidades como la de Granada, la de Zagreb (Croacia) o la de Leeds (West Yorkshire, Inglaterra). La finalidad de este proyecto se basa en la construcción de una comunidad (un objetivo similar al de Odiseo) que intenta incluir educadores de todos los países europeos, ofreciéndoles la oportunidad de aprender conceptos básicos de los chatbots y su práctica enfocada a la educación superior. Este proyecto se sostiene, además, con dos grandes interfaces: • Differ36 (representado en la Figura 4.7) como plataforma de chat, que estimula la colaboración de los estudiantes para conectarse y chatear, encontrar respuestas u obtener ayuda de sus compañeros. • Hubert37 (representado en la Figura 4.8) impulsado por una IA que facilita la evaluación formativa y el feedback de entrevistas con plantillas educativas. Figura 4.7: Conversación con Differ 36 Web Differ (https://www.differ.chat/for-universities) 37 Web Hubert (https://www.hubert.ai/) https://www.differ.chat/for-universities https://www.hubert.ai/ 20 ESTADO DE LA CUESTIÓN Figura 4.8: Sistema de evaluación con Hubert Además, algunas de sus prácticas incluyen estudios donde se investigan qué ventajas ofrecen respecto a los sistemas tradicionales de enseñanza y de qué manera se pueden aplicar, así como el fomento de conferencias para acercar su uso a un público menos acostumbrado. Sin embargo, EDUBOTS no es el único proyecto que podemos destacar. Actualmente, una de las propuestas más cercanas es 1MillionBot38, una startup39 fundada y dirigida por el exrector de la Universidad de Alicante, Andrés Pedreño, cuya financiación alcanza los 8,2 millones de euros [6]. Con una sede en Alicante y otra en Madrid, ofrece un servicio muy efectivo en cuanto a chatbots conversacionales que garantizan un porcentaje de más del 90% de respuestas acertadas interactuando con el usuario, ya sea por texto o por voz. Además, la compañía es perfectamente integrable con otras 38 Web oficial 1MillionBot (https://1millionbot.com/) 39 Una startup se define como una empresa emergente, normalmente con un alto componente tecnológico y con grandes posibilidades de crecimiento que, por lo general, respalda una idea innovadora sobresaliendo en la línea general del mercado. https://1millionbot.com/ 21 ESTADO DE LA CUESTIÓN plataformas basadas en IA y PLN como Dialogflow Google o Watson- IBM40. Gracias a este proyecto, empresas como Bankia, el periódico Información, portales de empleo y otras entidades gubernamentales disponen de chatbots personalizadospara sus necesidades, contando con sistemas de IA avanzada. Cabe destacar que 1MillionBot se conecta con bases de datos y CRM’s41 líderes en el mercado y está integrado vía voz con Google Home y Amazon Echo, desde donde se están desarrollando sus productos. Uno de sus productos y servicios, concretamente para el contexto educativo, es DulcineIA42, una chatbot diseñada para resolver dudas sobre palabras, expresiones o referencias relacionadas con la novela del Quijote, escrita por Miguel de Cervantes (como se muestra en la Figura 4.9). Debido a que la novela es compleja de leer por su contexto histórico, DulcineIA es un ejemplo de uso, donde una sencilla herramienta de IA (como Odiseo), es capaz de facilitar y acercar la literatura clásica a un público estudiantil. Además, DulcineIA es una actividad subvencionada por el Ministerio de Cultura y Deporte y cuenta con la colaboración del Instituto Cervantes. Con este último dato acerca de 1MillionBot, podemos afirmar que existen potentes sistemas de IA aplicados en el dominio educativo. Si bien existen chatbots en el dominio educativo, los principales proyectos suelen estar enfocados en etapas académicas más avanzadas. A día de hoy son pocas las herramientas de IA que se adaptan a niveles de enseñanza primaria, que se caracterizan precisamente por tener un público más sensible, como son los niños. Una herramienta como Odiseo, permite que un público 40 Soluciones IA WatsonIBM (https://www.ibm.com/watson) 41 La gestión de las relaciones con los clientes o CRM es una estrategia para gestionar todas las relaciones e interacciones de una empresa con sus clientes potenciales y existentes. 42 Web DulcineIA (https://1millionbot.com/chatbot-dulcineia/) https://www.ibm.com/watson https://1millionbot.com/chatbot-dulcineia/ 22 ESTADO DE LA CUESTIÓN más joven se acerque a las tecnologías y puedan, no sólo comprender su uso responsable y su aportación como herramienta de apoyo, sino también colaborar en una comunidad educativa capaz de aportarles los conocimientos necesarios de enseñanza primaria. Además de este elemento diferenciador con respecto a los sistemas revisados, Odiseo presenta una característica única que permite a sus usuarios entrenar al chatbot a través de la propia interfaz de conversación, alimentando su base de conocimiento de manera natural sin necesidad de ningún tipo de noción a nivel tecnológico sobre estos sistemas. Figura 4.9: Conversación con DulcineIA 23 5. Marco teórico Los agentes conversacionales, como Odiseo, ofrecen un entorno de conexión en tiempo real. Esto significa que cada interacción con el agente depende de la información introducida en dicho momento por el usuario. Para comprender el funcionamiento de este sistema, es necesario que primero entendamos cuáles son las necesidades de una aplicación de este tipo. 5.1 Hablar con una máquina Como en cualquier diálogo entre dos personas, debe de existir un intercambio de información, es decir, un flujo de datos, donde emisor y receptor puedan comprender la finalidad del mensaje final. Como se muestra en la Figura 5.1, si el emisor no comunica bien el mensaje, es posible que el receptor no pueda entenderlo, y por lo tanto, no sería posible una retroalimentación coherente por su parte. Figura 5.1: Boceto esquemático sobre el ciclo de la comunicación 24 MARCO TEÓRICO En un chatbot ocurre algo similar. Como ya habíamos explicado en la Sección 1 de Introducción, un asistente conversacional simula un diálogo entre una máquina y un humano. Para que este diálogo sea posible, deben de existir unas condiciones de conducta, donde la máquina sea capaz de: • Analizar las palabras que escucha y entender su significado. • Reconocer, en cualquier momento, una orden y ejecutarla. • Diferenciar qué tipos de datos está recibiendo y procesarlos, según sea el caso. • Informar de errores en tiempo de ejecución. • Ofrecer un servicio rápido, respuestas coherentes y estar activa de forma indefinida. Como se puede observar, una de las condiciones más importantes es el reconocimiento de palabras. Si lo comparamos con un ser humano, cuando nos encontramos hablando con otra persona, nuestro cerebro es capaz de procesar la información, almacenarla temporalmente y generar una respuesta ante dicha situación. Esta respuesta, por lo general, suele ser inmediata ya que solemos pensar lo que vamos a decir antes de hablar. En la figura 5.2, podemos encontrar una comparativa entre el cerebro humano y el procesamiento de una máquina, para comprender mejor este proceso. Cuando hablamos con una máquina, su código es el que debe procesar toda la información que recibe. Una vez analizada, su obligación será generar una respuesta automática, simulando que la máquina está hablando con nosotros, porque entiende lo que le decimos, y nos responde según el caso. Sin embargo, la programación de una tarea así, se puede complicar mucho, ya que para la máquina cualquier entrada es una cadena de texto y no puede diferenciar el significado de cada palabra. 25 MARCO TEÓRICO Figura 5.2: Comparación del cerebro humano con el PLN Para solucionar este problema, su programación necesita un algoritmo capaz de reconocer cualquier palabra y diferenciarla, por ejemplo, de una frase hecha, el nombre de una persona, un lugar geográfico, una fecha histórica o la orden de un programa. Este algoritmo o inteligencia adoptada por la máquina, se puede definir como las intenciones del usuario. 5.2 Intenciones del usuario Según la Real Academia Española, la palabra “intención” está definida como: ” Determinación de la voluntad en orden a un fin.” Dicho de otro modo: “El propósito o voluntad de realizar algo, con un fin determinado o un objetivo.” Esta definición la entendemos bien, cuando estamos conversando con otra persona. Consideremos el ejemplo de que una persona pueda tener distintas 26 MARCO TEÓRICO intenciones, ya sea, provocar nuestra risa con una historia graciosa, devolver un saludo o solicitarnos ayuda con una tarea. Independientemente de la situación, nuestras respuestas están influenciadas por las intenciones del emisor. Para una máquina, las intenciones del usuario implican unos comportamientos ante ciertos contextos. De esta manera, si nuestra intención es saludar, la máquina deberá devolvernos el saludo; si le pedimos una orden al programa, deberá respondernos con un menú interactivo. Sea cual sea la intención, la interacción con el sistema es constante y la máquina no será capaz de adivinar cuál será la siguiente intención del usuario, hasta que se produzca. Por este motivo, la máquina debe estar entrenada para identificar nuestras intenciones. Así, no sólo conseguiremos que nos entienda, sino que también será capaz de responder en cualquier momento de la conversación, cambiando de tema, como en una conversación natural. Figura 5.3: Esquema de funcionamiento Dialogflow y sus componentes 27 MARCO TEÓRICO Para aclarar estas ideas, en la Figura 5.3 se puede observar como un usuario conversa con el agente, introduciendo datos a través de un input o entrada a la aplicación. Esta información es procesada como una intención para el sistema. Una vez analizada, se devuelve la respuesta asociada o correspondiente a dicha intención. A nivel informático estas intenciones se pueden programar con un algoritmo de PLN. Su objetivo principal es la identificación de palabras y el reconocimiento del lenguaje. Como habíamos mencionado antes, el reconocimiento de palabras es fundamental, si queremos que la máquina pueda procesar nuestras intenciones. Sin embargo, el lenguaje natural humano, es más complicado de lo que parece. 5.3 Procesamiento de lenguaje natural (PLN) Históricamente se ha trabajadoen algoritmos que permitan traducir lenguas naturales de forma computacional. Para más información consulte el Anexo A1 sobre historia del PLN. Sin embargo, no sólo se trata de IA, sino de la comprensión de nuestro propio pensamiento. Según un artículo publicado en 2019 por DataCentric [8], una empresa especializada en asesoramiento y smart data43 para compañías multinacionales: “El PLN o NLP es la práctica del entendimiento de cómo las personas organizamos nuestros pensamientos, sentimientos, lenguaje y comportamiento. Un campo que se extiende hasta las ciencias de la computación, inteligencia artificial y lingüística en el estudio de las interacciones entre las computadoras y los seres humanos. El objetivo es 43 Similar al Big Data, el Smart Data es capaz de recopilar grandes volúmenes de datos al instante, pero en este caso el sistema también es capaz de analizarla. 28 MARCO TEÓRICO poder dotar a la máquina de la capacidad de interpretar el texto simulando la habilidad humana de entender el lenguaje.” Como se cita en la definición, lo primero que debemos tener en cuenta es la estructura principal del lenguaje humano, para ser capaces de simularla artificialmente [9]. En esta sección no se van a explicar detalles sobre el campo de la lingüística, ya que podría tratarse de un tema muy extenso y no pertenece a la rama de este proyecto. Sin embargo, es importante que entendamos algunos conceptos básicos del lenguaje, para comprender las conversaciones con un chatbot. A grandes rasgos, esta estructura se define mediante unas capas de análisis. Cada capa se corresponde con un aspecto del lenguaje : • Análisis morfológico. Un análisis que puede distinguir los tipos de palabras (verbos, sustantivos, preposiciones, etc.) y sus variaciones (género, número, tiempo, etc.) • Análisis sintáctico. Un análisis que puede separar unas frases de otras y, de esta manera, analizar las partes que las componen (sujeto, verbo, predicado) para extraer su sentido. • Análisis semántico. Un análisis que puede extraer el significado, no solo de las palabras individuales, sino de las frases de las que forman parte y del discurso en su conjunto, resolviendo así ambigüedades. • Análisis pragmático. Un análisis que puede extraer la intención del texto más allá de los límites de la frase, permitiendo diferenciar factores como la ironía, la ambigüedad, el estado de ánimo o las referencias sobre otras palabras. 29 MARCO TEÓRICO Una vez analizadas las capas previas, se puede estructurar cada frase del texto y generar así una cadena lineal de palabras, con sus correspondientes concordancias según el idioma. Para comprender mejor la complejidad de esta estructura, se muestra la Figura 5.4 con uno de estos análisis. Figura 5.4: Ejemplo de análisis sintáctico en una oración compuesta Lo importante de esta complejidad, no es conocer sus definiciones, ni tampoco sus símbolos, o de qué manera se construye cada palabra del lenguaje humano, sino comprender la cantidad de elementos que intervienen en una simple conversación, concretamente, a la hora de analizar computacionalmente una oración o frase del usuario. Con esta reflexión, podemos debatir cuáles son las dificultades a las que se enfrenta un sistema de PLN, ya que pueden presentarse como errores en el sistema, debido a la falta de reconocimiento artificial. 5.3.1 Problemas del lenguaje humano Principalmente las dificultades con el entendimiento o el reconocimiento de palabras son consecuencia de la complejidad lingüística que tiene el ser 30 MARCO TEÓRICO humano. El lenguaje natural, por lo general, dispone de un vocabulario muy variado y siempre depende del contexto del hablante. Para comprender el desafío que presenta un sistema de PLN, primero debemos conocer algunos problemas [10] derivados de nuestra propia habla: • Ambigüedad. A nivel léxico, se puede presentar palabras que se escriban o se pronuncien iguales, pero con contextos muy diferentes. Un ser humano sería capaz de comprender su significado según el tema de la conversación. Por ejemplo: “Él se dedica a fabricar cascos”. Puede referirse a fabricar las protecciones que se utilizan en la cabeza o bien las partes delanteras de los barcos. • Sinonimia. A nivel semántico, pueden existir palabras con una similitud de significados, lo que supone que varias palabras se utilicen para la misma referencia. Por ejemplo: “casa, hogar, residencia o vivienda”. Todas son válidas para conocer el lugar donde vive una persona. • Variabilidad del lenguaje. Según ciertas situaciones, el hablante puede variar su registro lingüístico, lo que supone que para un mismo significado puedan existir diferentes palabras (similar al punto anterior). Dentro de esta categoría, encontramos: o Variación diatópica o geográfica. La lengua puede diferir de un lugar a otro, según la región del hablante. Por ejemplo: “adolescente” se puede traducir como “teeneger” en inglés o “chavo” en mejicano. Además, pueden aparecer distintos dialectos para una misma región, según la pronunciación. Por ejemplo: “el toscano, napolitano, siciliano o veneciano son algunos dialectos hablados en Italia”. o Variación diastrática o social. Dentro de una misma localidad, los hablantes que comparten unos rasgos socioeconómicos, 31 MARCO TEÓRICO pueden adoptar una forma cultural y lingüística que los diferencia de otros grupos sociales. Por ejemplo: “Liarla parda, estar to’ ciego, pasarse tres pueblos”. Utilizados cuando una persona “crea un problema muy grande”, “está borracha” o “ha exagerado mucho”, respectivamente. o Variación diafásica o contextual. Ocurre cuando el hablante emplea una modalidad de expresión diferente dependiendo de su entorno, intenciones o la persona que va a recibir el mensaje. Por ejemplo: “La manera de hablar con tu familia, no es la misma que cuando estás entre amigos o hablando con un profesor”. o Variación diacrónica o del momento histórico. Esta variedad tiene en cuenta la evolución que ha experimentado una lengua a lo largo de la historia, ya sea por cuestiones de uso o las influencias procedentes de otras lenguas. Por ejemplo: “cama, aguardar, luene, yuso”. Se tratan de expresiones del castellano antiguo, que actualmente significan “pierna, mirar, lejos y abajo” respectivamente. • Ironías o sarcasmos. A nivel pragmático, pueden aparecer oraciones que no significan lo que realmente se está diciendo, o incluso que se digan con intenciones contrarias. Por ejemplo: “Uy, estoy temblando de miedo” (ironía verbal). En realidad no está temblando. • Anáforas y catáforas. El uso de ciertas palabras que hacen referencia a otros elementos de la oración. Por ejemplo: “Juan y Pepe fueron a pescar; éste pescó una trucha de tres kilos y aquél otra de cinco”. Las palabras éste y aquél, se refieren a Juan y Pepe, respectivamente. • Separación entre palabras. Por lo general, en la lengua escrita se deben separar las palabras para que mantengan un sentido lógico, tanto 32 MARCO TEÓRICO gramatical como contextual. Sin embargo, pueden existir lenguas, como el chino mandarín, donde no existe ningún tipo de separación entre las palabras y puede suponer un problema a la hora de analizarlas. Por ejemplo: “ 请稍等。”. Leído como “qǐng shāo děng”. Traducido como “Un momento, por favor.” • Otros imperfectos. Como pueden ser acentos extranjeros, regionalismos o errores de mecanografiado. Por ejemplo: “¿Puedes contarme munchisme?”. Corregido como “¿Puedes contarme un chiste? La palabra “munchisme”, no sería reconocida. Muchos de estos problemas pueden convertirse en impedimentos a la hora de entrenar un agente conversacional. Por este motivo, debemos procurar discernir la mayor cantidad de significados posibles, para generar una conversación lo más naturalposible. 5.3.2 Soluciones del algoritmo Según la investigación que recoge Iberdrola [11] (líder energético global) sobre el PLN, los primeros modelos sobre el análisis del lenguaje natural se basaban, principalmente, en codificar manualmente todas las reglas del lenguaje. Este sistema era capaz de distinguir algunas características como: tiempos verbales, conjugaciones o raíces morfológicas, extrayendo el significado de cada palabra. A partir de los años 80 y 90 se produjo la conocida revolución estadística, lo que permitió utilizar árboles de análisis, en vez de escribir conjuntos de reglas y excepciones. Estos nuevos sistemas se conocen como “algoritmos inferencia estadística” y son utilizados, sobretodo, para analizar cualquier texto y realizar comparaciones en busca de patrones. 33 MARCO TEÓRICO La ventaja que nos ofrecen los modelos estadísticos es la fiabilidad a la hora de comprender nuevas palabras o de detectar errores, como pueden ser palabras mal escritas u omitidas por accidente. La mayoría de los sistemas actuales utilizan una combinación entre ambos: modelos simbólicos y modelos estadísticos. En concreto, los sistemas de procesamiento de lenguaje natural realizan varios tipos de análisis, utilizando árboles de inferencia estadística como se aprecia en la Figura 5.5. Estos análisis se corresponden con los mencionados anteriormente, en la Sección 5.3 sobre las capas del lenguaje, como el morfológico, el sintáctico, el semántico y el pragmático. Figura 5.5: Ejemplo de un árbol de decisiones para detectar el fin de una expresión 34 MARCO TEÓRICO Dichos análisis permiten, no sólo identificar los términos de la oración, sino detectar significados de cada palabra y emparejar con una intención del usuario en concreto. Estos emparejamientos también son posibles gracias a los patrones de uso. Un ejemplo de uso podría ser el saludo a una máquina. Podríamos vincular todas las oraciones que empiecen por “Hola”, “Buenas tardes'' o “Hey!” con una intención de saludo. Estas oraciones se podrían clasificar para detectar entidades, incluyendo nombres de persona o referencias hacia el sistema, como en nuestro caso: “Hola, Odiseo” Otras investigaciones sobre el campo del PLN, recomiendan también el uso de diccionarios y bases de conocimiento con referencias ya programadas, junto estas correlaciones estadísticas, para resolver las ambigüedades léxicas, por ejemplo. Para más información acerca de herramientas de procesamiento, consulte el Anexo A2 sobre herramientas de desarrollo para PLN. En este proyecto, sólo se destacará el uso de DialogFlow . Figura 5.6: Esquema sobre el funcionamiento de reconocimiento interno de Dialog Flow 35 MARCO TEÓRICO En la Figura 5.6, podemos observar un esquema de funcionamiento interno de cómo, en nuestro caso, se utilizan los sistemas de reconocimiento de Dialog Flow, para este algoritmo. En la Sección 6 de Herramientas, se puede encontrar más información acerca de la interfaz de DialogFlow, y los componentes informáticos utilizados en este proyecto. Para concluir este apartado se dejan unas referencias en el Anexo A3 para demostrar el uso de estos algoritmos en aplicaciones ya conocidas, como la comparación de textos o el autocorrector de los teléfonos. Con esta información, podemos entender mejor la arquitectura de un sistema conversacional y sus componentes relacionados con la lingüística. A continuación, se hablará sobre la estructura concreta de este trabajo así como su funcionamiento, para un uso concreto como es el educativo. 36 6. Herramientas y tecnologías En este apartado se van a detallar todas las herramientas y tecnologías utilizadas para el desarrollo de este proyecto, resumiendo brevemente sus características y justificando su utilización. Se facilitarán unas referencias a pie de página para que el lector de este documento pueda acceder a la información oficial de cada una. Como en la siguiente sección se definirá el diseño y estructura del proyecto, aquí sólo nos centraremos en nombrar cada herramienta por separado, haciendo una explicación de su funcionamiento interno. 6.1 Administrador de base de datos MongoDB MongoDB es una base de datos orientada a documentos que ofrece una gran escalabilidad, flexibilidad y un modelo de consultas e indexación avanzado. Esto quiere decir que en lugar de guardar los datos en registros, guarda los datos en documentos. Estos documentos, como se muestra en la Figura 6.1, son almacenados en BSON, que es una representación binaria de JSON. Una de las diferencias más importantes con respecto a las bases de datos relacionales, es que no es necesario seguir ninguna estructura. Los documentos de una misma colección (concepto similar a una tabla de una base de datos relacional) pueden tener esquemas diferentes. Esta característica permite que sea ideal para un proyecto como Odiseo, donde no es necesario tener relaciones estrictas ni esquemas de almacenamiento complejos. 37 HERRAMIENTAS Y TECNOLOGÍAS Figura 6.1: Esquema de una colección de datos embebida para MongoDB Su nube MongoDB Atlas44 permite hasta 5Gb de almacenamiento de forma gratuita y estable. Gracias a este servidor, podemos disponer de una base de datos siempre online y accesible de forma segura. Además, su interfaz de analíticas nos permite visualizar las conexiones entrantes y los registros consultados, como se puede observar en la Figura 6.2. Figura 6.2: Interfaz del cluster MongoDB Atlas 44 Documentación nube MongoDB Atlas (https://www.mongodb.com/docs/atlas/) https://www.mongodb.com/docs/atlas/ 38 HERRAMIENTAS Y TECNOLOGÍAS 6.1.1 Conexión y librería Mongoose Sin embargo, aunque MongoDB nos permita acceder a un almacenamiento de datos, necesitamos: • Registrarnos con una cuenta de usuario • Conseguir una cadena de conexión con el cluster • Conocer sus comandos para realizar consultas a través de nuestra API Para facilitar estas tareas hemos optado por utilizar una librería de Visual Studio Code conocida como Mongoose45. Esta librería contiene la lógica necesaria para trabajar con un mapeado de objetos (ODM), es decir, una capa adicional a MongoDB que permite definir objetos con un esquema fuertemente tipado asignado a un documento MongoDB. Gracias a esta utilidad, podemos definir nuestros esquemas de datos dentro del propio código y preocuparnos sólo de los comandos de Mongoose que simplifican las consultas a la base de datos de MongoDB. 6.2 Visual Studio Code Visual Studio Code46 (VS Code) es un editor de código fuente desarrollado por Microsoft. Se trata de un software libre y multiplataforma, compatible con Windows, GNU/Linux y MacOS. Esta herramienta ha sido imprescindible para trabajar con el proyecto. Su interfaz y sus complementos (Figura 6.3) nos han permitido desarrollar el código de la API de manera rápida y cómoda. 45 Documentación librería Mongoose (NPM) (https://mongoosejs.com/docs/guide.html) 46 Documentación IDE Visual Studio Code (https://code.visualstudio.com/docs) https://mongoosejs.com/docs/guide.html https://code.visualstudio.com/docs 39 HERRAMIENTAS Y TECNOLOGÍAS Figura 6.3: Biblioteca de extensiones en Visual Studio Code Además cuenta con integraciones para Git, lo que nos permite realizar versiones del código, en distintas ramas, de forma segura. 6.2.1 Node Javascript El uso de Node.js47 nos permitió idear un entorno de ejecución de JavaScript orientado a eventos asíncronos. Node.js está diseñado para crear aplicaciones network escalables. Como Odiseo trabaja precisamente con peticiones web y consultas a la base de datos, es importante destacar el uso de llamadas asíncronas con Javascript. Estas llamadas permiten a la aplicación seguir funcionando mientras esperan larespuesta de las consultas anteriores, ya que se tratan de consultas a APIs externas y no podemos controlar cuándo llega el resultado. 47 Documentación lenguaje Node Javascript (https://nodejs.org/es/docs/) https://nodejs.org/es/docs/ 40 HERRAMIENTAS Y TECNOLOGÍAS Además, el uso de Javascript nos permite trabajar con páginas web utilizando HTML y CSS (para la interfaz de Odiseo), así como atender muchas conexiones simultáneamente (concurrencia de usuarios). 6.3 Data Cloud Heroku Heroku48 es una plataforma de servicios en la nube que permite alojar y administrar servidores con una gran escalabilidad. En entornos empresariales, Heroku se ha convertido en un estándar por su despliegue de aplicaciones. En nuestro caso, nos ha permitido trabajar con un alojamiento online 24h. Figura 6.4: Consola de despliegue en Heroku 48 Documentación servicio Heroku (https://devcenter.heroku.com/) https://devcenter.heroku.com/ 41 HERRAMIENTAS Y TECNOLOGÍAS Para utilizar este servicio solo es necesario indicar el lenguaje de backend (Node.js) o la base de datos empleada, preocupándonos sólo del desarrollo interno de nuestra aplicación. Una vez publicado el código (gracias a su sistema tipo Git), su consola (Figura 6.4) desplegará la aplicación, detectando los comandos de arranque establecidos (como npm start). La calidad y comodidad de este servicio es ideal para una aplicación como Odiseo, pues uno de los requisitos para trabajar con la herramienta de Dialogflow, o dicho de otro modo, con las intenciones de un chatbot, es precisamente el empleo de una URL pública. Para evitar la dependencia de un servidor local, hemos optado por el uso de una nube pública. Además, gracias a su escalabilidad, Heroku nos permite gestionar la concurrencia de usuarios de manera óptima. 6.3.1 Servidor local Ngrok Ngrok49 es un servicio que nos permite crear nuestro servidor local en un subdominio para poder visualizarlo fuera de la LAN, a través de internet; por ejemplo, para realizar pruebas donde necesitamos un túnel donde recibir las conexiones o “portforwarding”. Durante el desarrollo de Odiseo no disponíamos de un hosting público como Heroku, lo que suponía el uso de nuestra propia red para que los usuarios pudieran acceder al chatbot. 49 Documentación herramienta Ngrok (https://ngrok.com/docs) https://ngrok.com/docs 42 HERRAMIENTAS Y TECNOLOGÍAS Como hemos explicado antes, el uso de la herramienta Dialogflow requiere una url pública para sus peticiones web. Esto conlleva el uso temporal de una herramienta como Ngrok para realizar pruebas de conexión y acceso. Su consola (Figura 6.5) permite establecer una IP pública con un protocolo seguro (HTTPS) y visualizar las conexiones entrantes. Figura 6.5: Terminal ejecutado por una conexión de Ngrok 6.4 Control de versiones Github Comprada por Microsoft en 2018, Github50 se ha convertido en la plataforma más utilizada para alojar el código de los desarrolladores. Su sistema se basa en el control de versiones conocido como Git. Git51 es un proyecto de código abierto y maduro (con un mantenimiento activo) que desarrolló originalmente Linus Torvalds, el famoso creador del kernel del sistema operativo Linux, en 2005. 50 Documentación servicio Github (https://docs.github.com/en) 51 Documentación herramienta Git (https://git-scm.com/doc) https://docs.github.com/en https://git-scm.com/doc 43 HERRAMIENTAS Y TECNOLOGÍAS Gracias al servidor de Github muchos programadores pueden publicar el código de sus aplicaciones a través de repositorios donde trabajan de manera colaborativa y comparten opiniones. La herramienta también ofrece una interfaz, donde cada programador puede solicitar un “pull request” para que un administrador revise su código. Si se aprueban los nuevos cambios, este código pasaría a la rama principal o de desarrollo. Como se ha explicado en la Sección 3 de Metodología, esta herramienta ha sido clave para controlar la evolución de Odiseo, pues su sistema de ramas permite trabajar en paralelo distintas versiones de la aplicación de manera que podemos testearla sin miedo a estropear la versión definitiva o ya publicada. Muchas empresas utilizan este sistema para auditar los cambios que publican sus empleados y mantener una organización de tareas (gracias a su tablero de etiquetas). En nuestro caso, hemos aprovechado algunas ventajas: • Mantener una copia de seguridad del código original. • Publicar un repositorio online donde se pueda visualizar el código del proyecto, sin necesidad de abrir un editor de manera local. • Controlar los cambios del proyecto diariamente justificando su avance. Además, su versión de escritorio (como se muestra en la Figura 6.6) nos permite publicar y descargar cambios desde el repositorio web, sin necesidad de conocer ningún comando típico de Git, facilitando el desarrollo. 44 HERRAMIENTAS Y TECNOLOGÍAS Figura 6.6: Interfaz de cambios en Github Desktop 6.5 Servidor de ImgBB ImgBB52 es un servicio de alojamiento de imágenes gratuito. Su popularidad reside en su interfaz minimalista (reflejada en la Figura 6.7) que le permite ser más eficiente, comparado con otras herramientas. Simplemente arrastrando y soltando con un clic, podemos publicar imágenes en nuestra cuenta. Existe una limitación para cargar archivos de hasta 32 MB, que incluye los principales formatos de imagen permitidos. No se restringe la cantidad de imágenes que se pueden subir ni la cantidad de tiempo que pueden permanecer en línea. 52 Documentación servicio ImgBB (https://imgbb.com/) https://imgbb.com/ 45 HERRAMIENTAS Y TECNOLOGÍAS Estas características hacen de ImgBB una herramienta ideal, si lo que necesitamos son imágenes activas las 24h y almacenadas de forma segura como las que utiliza nuestro chatbot. Además, ni siquiera es necesario registrarse en la página. ImgBB es fácil de usar y ofrece todo tipo de enlaces de inserción para páginas web embebidas u otras plataformas. Figura 6.7: Biblioteca de imágenes utilizadas para Odiseo en el servidor ImgBB 6.6 Google Cloud Google Cloud Platform53 (GCP) es una suite de infraestructuras y servicios online que Google utiliza a nivel empresarial. Gracias a esta plataforma, todas las herramientas de Google (que antes se ofrecían por separado) están disponibles en la nube. 53 Documentación servicio Google Cloud (https://cloud.google.com/docs/) https://cloud.google.com/docs/ 46 HERRAMIENTAS Y TECNOLOGÍAS Figura 6.8: Esquema de servicios ofrecidos por Google Cloud Platform Básicamente, GCP nos aporta todas las herramientas necesarias para diseñar, hacer testings y lanzar aplicaciones desde GCloud con mucha más seguridad y escalabilidad que cualquier otra herramienta, gracias a la propia infraestructura de Google (como se muestra en la Figura 6.8). Podemos encontrar algunas funcionalidades como: • Computing: Puesta en marcha de aplicaciones y máquinas virtuales en la nube. • Networking: Configuración de redes, incluyendo información de DNS, VPN, IP. • Storage: Almacenamiento de datos MySQL y NoSQL con escalabilidad. • Big Data: Consulta y procesamiento de Big Data con análisis. • Machine Learning: Aprendizaje automático aplicando patrones. 47 HERRAMIENTAS Y TECNOLOGÍAS Concretamente, las empresas cuentan con una gran ventaja al utilizar estos servicios de Google, ya que se tratan de herramientas muy complejas de desarrollar y desplegar. Además, Google garantiza ciertos beneficios en comparación con otras marcas: • Open Source: Con la posibilidad de personalizar las herramientas, al tratarse de una tecnología flexible, escalable y de código abierto. • Seguro: Con fiabilidad y disponibilidad. Sin ningún periodo inactivo y con redes privadaspara evitar ciberataques. • Innovador: Con las últimas novedades del mercado, permitiendo la transformación digital en diferentes sectores. • Asequible: Algunas de sus herramientas son gratis. Y las que son de pago, tienen precios muy competitivos, para que cualquier empresa se pueda beneficiar de GCloud. Estas características y ventajas nos permiten justificar el uso de Dialogflow y Google Actions, ya que se tratan de herramientas exclusivas de esta plataforma y son requisitos para la elaboración de este TFG. Además, su interfaz administrativo, como se muestran en la Figura 6.9 y Figura 6.10, permite analizar los costes de uso y extraer algunas estadísticas de rendimiento. 48 HERRAMIENTAS Y TECNOLOGÍAS Figura 6.9: Panel administrativo de Google Cloud Platform Figura 6.10: Estadísticas de rendimiento por Dialogflow del proyecto Odiseo 49 HERRAMIENTAS Y TECNOLOGÍAS 6.6.1 Credenciales Cloud SDK El uso de la plataforma de Google requiere unas configuraciones previas, sobre todo a la hora de integrar su API. Para facilitar esta tarea hemos tenido que utilizar el panel de administración de proyectos GCP, así como el terminal de escritorio Cloud SDK54, el cual se conecta directamente con la plataforma. Una vez registrado el proyecto en la nube, se pueden configurar algunos parámetros obligatorios como: • Habilitar la facturación para otorgar acceso a un pago, en caso de sobrepasar los límites. • Habilitar la API de Dialogflow para utilizar sus funciones de chatbots. • Habilitar los registros de auditoría, en caso de hacer un seguimiento de los cambios. • Configurar la autenticación, recomendando el uso de una cuenta de servicio. Estas credenciales o claves públicas permiten acceso a las aplicaciones alojadas en la Cloud. Gracias a la herramienta de línea de comandos GCloud SDK (Figura 6.11), podemos interactuar con los servicios de la plataforma, incluyendo comandos de autenticación y comprobación de credenciales. Esta última tarea, nos ahorra tiempo para no tener que configurarlas cada vez que se arranque Odiseo. 54 Documentación herramienta SDK Cloud (https://cloud.google.com/sdk/docs/) https://cloud.google.com/sdk/docs/ 50 HERRAMIENTAS Y TECNOLOGÍAS Figura 6.11: Comprobación de credenciales de Odiseo a través de la Shell Cloud SDK 6.6.2 Google Dialogflow Dialogflow55 es una herramienta de creación de chatbots capaz de entender el lenguaje natural y procesarlo. El sistema provee una infraestructura para recrear conversaciones y construir diálogos con el fin de interactuar con el usuario de manera fluida. Desde su compra en 2016, Google lo ha incorporado como herramienta en su nube. Dialogflow destaca entre sus competidores debido al amplio abanico de interfaces de conversación que llega a abarcar: Google Home, Skype, Telegram, Twitter, Messenger, páginas web, telefonía, coches y otros dispositivos. Actualmente soporta más de 14 idiomas y se mejora cada día para hacer frente al uso de abreviaturas y fallos ortográficos. 55 Documentación herramienta Dialogflow (https://cloud.google.com/dialogflow/docs/) https://cloud.google.com/dialogflow/docs/ 51 HERRAMIENTAS Y TECNOLOGÍAS Gracias a esta herramienta hemos podido elaborar nuestro chatbot desde una interfaz gráfica (Figura 6.12), la cual permite definir algunos elementos como: intenciones del agente56, entidades, frases de entrenamiento, respuestas enriquecidas, acciones y parámetros, o contextos de conversación. Figura 6.12: Interfaz de desarrollo de Dialogflow Además, trae unas vistas de análisis y entrenamiento (Figura 6.13), para corregir y validar la IA del agente ante situaciones reales. Dialogflow permite el uso de webhooks capaces de ofrecernos información de entrada, procedente de la petición web que envía el chat; y su integración con fulfillment, para conectarnos desde un servidor web externo. Por último, cabe destacar el uso de las funciones de su API. Aunque su interfaz gráfica nos permite definir intenciones, el proyecto Odiseo 56 Un intent categoriza, define y mapea la intención del usuario con el fin de reaccionar con una acción o respuesta. 52 HERRAMIENTAS Y TECNOLOGÍAS necesitaba acceso completo a nivel interno. Esto ha provocado, el estudio de su documentación (Figura 6.14) para recurrir a funciones como: crear intenciones desde nuestro código o modificar su estructura con JSON’s enriquecidos para respuestas más personalizadas. Figura 6.13: Validaciones de entrenamiento en Dialogflow Figura 6.14: Funcionalidades de la API de Dialogflow 53 HERRAMIENTAS Y TECNOLOGÍAS 6.6.3 Google Actions Actions on Google57 es una plataforma que permite crear acciones para el Asistente de Google58. Estas acciones son, en realidad, las interacciones que se entablan con el asistente y que permiten dar respuesta por voz a las peticiones del usuario. Algunos ejemplos los encontramos cuando queremos conocer el clima actual o comprar algo vía internet. Otra característica del Actions es que se puede usar en múltiples dispositivos, como teléfonos móviles, smartwatches o televisiones. Los usuarios pueden invocar acciones por su nombre59, pero también pueden añadir una frase para indicar exactamente qué tienen que hacer. Este es el caso de Odiseo, dónde además de utilizarlo como chatbot, integramos el asistente de Google para ofrecer respuestas guiadas por voz. Los usuarios tan sólo tienen que invocarlo desde su teléfono y seguir las instrucciones que nuestro agente les ofrece. Gracias a su interfaz visual de desarrollo (Figura 6.15), podemos diseñar distintos esquemas de interacción y acciones para nuestro asistente. Por lo general, suele admitir una exportación del proyecto de Dialogflow, así que no es necesario crearlo desde cero. Además, antes de publicarlo oficialmente, podemos realizar pruebas con su emulador online, seleccionando la interfaz final a la que irá destinado. Esto nos permite depurar errores de innovación y verificar las respuestas que se están produciendo desde la consola. 57Documentación herramienta Google Actions (https://developers.google.com/assistant/docs) 58 Asistente virtual de Google para permitir conversaciones entre los usuarios y Google, dando respuesta a alguna necesidad. 59 Generalmente invocadas con la expresión “Ok Google, hablar con…” https://developers.google.com/assistant/docs 54 HERRAMIENTAS Y TECNOLOGÍAS Figura 6.15: Diseño de interacciones en Actions Console Para utilizar una acción no es necesario instalarla, pero antes de que los usuarios puedan usarla es necesario enviarla a producción para que pueda ser aprobada. Las aprobaciones son revisadas por los administradores de Google y exigen unas condiciones estrictas60 que debe cumplir la aplicación. Por ejemplo: • La acción debe tener un nombre específico, con una pronunciación clara. • La acción debe contener una declaración visible, para consultar su política de privacidad de datos (en el Anexo A4 se recoge el documento de privacidad de Odiseo) • Queda prohibida la representación de contenido sexual, violento o ilegal que infrinjan las políticas de Google Actions. 60 Política de restricciones (https://developers.google.com/assistant/console/publish) https://developers.google.com/assistant/console/publish 55 HERRAMIENTAS Y TECNOLOGÍAS • La acción debe contener una descripción clara y un propósito público, sin incluir términos como “prueba”. • La acción debe haber realizado un test y pasado por las distintas versiones alpha, beta, etc. Si nuestra acción es aprobada, Google la dejará disponible en su biblioteca de asistentes, para poder invocarla públicamente desde cualquier dispositivo, como se muestra en la Figura 6.16. Figura 6.16: Respuesta del
Compartir