UVaInformer:Una aplicación conversacional basada en Alexa Skills(c)

´ Indice general ´ Indice de cuadros V ´ Indice de figuras VII Resumen IX Agradecimientos XI 1 Introducci´on 1 1.1 Motivaci´on.......................................... 1 1.2 Objetivos........................................... 1 1.3 Contenidosdelamemoria ................................. 2 1.4 Herramientasempleadas .................................. 2 2 Metodolog´ıa y Planificaci´on 3 2.1 Metas............................................. 3 2.2 Restricciones......................................... 3 2.3 Metodolog´ıaadoptada.................................... 4 2.3.1 RolesScrum..................................... 4 2.3.2 Scrumadaptado .................................. 4 2.4 Riesgos............................................ 5 2.5 Matriz de impacto / probabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.6 Seguimiento ......................................... 7 2.6.1 Sprint 0: Estudio te´orico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6.2 Sprint 1: Primera skill ............................... 7 2.6.3 Sprint2:UVaInformer............................... 8 3 Fundamentos te´oricos 9 3.1 Sistemas de Di´alogo Hablado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Arquitectura......................................... 9 3.2.1 Task-oriented dialogue agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2 Chatbots ...................................... 12 3.3 Componentesesenciales................................... 14 3.3.1 Reconocimiento de Habla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.2 Comprensi´on del lenguaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3.3 Gesti´ondeDi´alogo................................. 16 3.3.4 Comunicaci´on con el sistema externo . . . . . . . . . . . . . . . . . . . . . . . 16 3.3.5 Generaci´on de respuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3.6 Salidavocal..................................... 17 4 Plataformas de desarrollo 19 4.1 An´alisis de plataformas existentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1 Siri.......................................... 19 4.1.2 GoogleAssistant .................................. 19 4.1.3 Cortana ....................................... 20 4.1.4 Alexa ........................................ 20 i ii ´ INDICE GENERAL 5 Anatom´ıa de una skill 21 5.1 Proceso de vida de una skill ................................ 21 5.1.1 Reconocimientovocal ............................... 21 5.1.2 Procesamientodedatos .............................. 22 5.2 Partes de una skill ...................................... 22 5.2.1 Wakeword ..................................... 22 5.2.2 Inicializaci´on .................................... 22 5.2.3 InvocationName .................................. 23 5.2.4 Intents........................................ 23 5.2.5 Slots......................................... 23 5.2.6 Utterances...................................... 24 5.3 Tipos de skill ........................................ 24 5.3.1 Custom ....................................... 24 5.3.2 FlashBriefing.................................... 24 5.3.3 SmartHome..................................... 25 5.3.4 Video ........................................ 25 6 Estudio de alternativas 27 6.1 Datosdeinter´es ....................................... 27 6.2 Estudiodeviabilidad .................................... 27 6.2.1 Existencia y ubicaci´on de libros . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2.2 Horariodetutor´ıas................................. 28 6.2.3 Informaci´onb´asica ................................. 28 6.2.4 Disponibilidad horaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.2.5 Gu´ıasdocentes ................................... 29 6.3 Decisi´onfinal......................................... 29 6.3.1 Datos ........................................ 29 6.3.2 Skill ......................................... 29 7 Desarrollo 31 7.1 An´alisisyarquitectura ................................... 31 7.1.1 Intent 1: Informaci´on de profesores . . . . . . . . . . . . . . . . . . . . . . . . 31 7.1.2 Intent 2: Horarios de tutor´ıas . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.2 Dise˜novocal ......................................... 37 7.2.1 Intent 1: Informaci´on de profesores . . . . . . . . . . . . . . . . . . . . . . . . 37 7.2.2 Intent 2: Horarios de tutor´ıas . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.2.3 Arranque de skill .................................. 40 7.2.4 Interacci´on con skill iniciada ........................... 40 7.3 Implementaci´on ....................................... 40 7.3.1 Archivosauxiliares ................................. 40 7.3.2 Intent 1: Informaci´on de profesores . . . . . . . . . . . . . . . . . . . . . . . . 41 7.3.3 Intent 2: Horarios de tutor´ıas . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 7.4 Pruebas............................................ 48 8 Conclusiones y trabajo futuro 51 8.1 Conclusiones......................................... 51 8.2 L´ıneasdetrabajofuturo .................................. 51 A Tutorial: Creaci´on de una Alexa Skill 53 A.1 Build ............................................. 55 A.1.1 Custom ....................................... 56 A.1.2 Invocation...................................... 56 A.1.3 InteractionModel.................................. 56 A.1.4 Assets ........................................ 57 A.2 Code ............................................. 57 A.2.1 util.js ........................................ 58 A.2.2 package.json..................................... 58 A.2.3 local-debugger.js .................................. 58 ´ INDICE GENERAL iii A.2.4 index.js ....................................... 58 A.3 test .............................................. 59 B Tutorial: Ampliaci´on de la skill 61 B.1 Dise˜novocal ......................................... 61 B.2 C´odigo ............................................ 64 Bibliograf´ıa 67 iv ´ INDICE GENERAL ´ Indice de cuadros 2.1 Plantilla para los riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Riesgo1....................................... 5 2.3 Riesgo2....................................... 5 2.4 Riesgo3....................................... 6 2.5 Riesgo4....................................... 6 2.6 Riesgo5....................................... 6 2.7 Tabladeriesgos................................... 6 2.8 Matriz de impacto / probabilidad . . . . . . . . . . . . . . . . . . . . . . . . . 7 v xii ´ INDICE DE FIGURAS Cap´ıtulo 1 Introducci´on 1.1. Motivaci´on La Importancia de entornos de interacci´on vocales est´a relacionada con la facilidad y naturalidad de uso que proporciona el modelo de interacci´on basado en di´alogo. De esta manera, los usuarios pueden entablar una conversaci´on y obtener la informaci´on deseada, imitando lo que ser´ıa una interacci´on t´ıpica cara a cara con una persona. Actualmente la interacci´on entre personas y ordenadores se est´a transformando, m´as all´a de los paradigmas cl´asicos basados en pantalla, teclado y rat´on: sistemas de realidad virtual (gafas de realidad virtual) o de realidad aumentada (pantallas port´atiles que muestran informaci´on a˜nadida a la vista normal, o sistemas de informaci´on auditiva), y sistemas de interacci´on hablada, entre otros, que est´an imponi´endose en entornos dom´esticos, de ocio y profesionales. Entre las ventajas de los asistentes vocales como paradigma de interacci´on, no solo debemos resaltar la naturalidad y facilidad de la interacci´on: los asistentes vocales tambi´en destacan por permitir un en escenarios de “manos libres”: durante la conducci´on, caminando, corriendo o en cualquier tipo de desplazamiento, sin tener que distraer la atenci´on visual y facilitando as´ı aproximaciones multimodales al dise˜no y desarrollo de sistemas de interacci´on. Con la aparici´on de los sistemas vocales y sus respectivas aplicaciones personalizadas, se ha detectado una carencia de ´estas en los ´ambitos educativos, m´as concretamente en las universidades, donde cada alumno cuenta con una gran cantidad de recursos (algunos de ellos descentralizados). Con este proyecto se pretende poner una primera piedra para lo que podr´a ser un asistente vocal (y posiblemente visual) completo para los alumnos de la Universidad de Valladolid. 1.2. Objetivos En este trabajo de fin de grado vamos a intentar alcanzar una serie de objetivos: Comprender y describir la arquitectura y funcionamiento t´ıpico de los sistemas conversacionales. Desarrollar un prototipo funcional de una aplicaci´on vocal, implementada sobre uno de los sistemas comerciales m´as utilizados actualmente. Dotar de funcionalidad efectiva al prototipo desarrollado para ser utilizado por el alumnado de la Universidad de Valladolid. 1 2CAP´ ITULO 1. INTRODUCCI ´ ON 1.3. Contenidos de la memoria Esta memoria est´a estructurada en ocho cap´ıtulos y dos ap´endices, que cubren los siquientes aspectos: Cap´ıtulo 1: Se presenta el proyecto planteado, su motivaci´on y los objetivos que pretende alcanzar. Cap´ıtulo 2: Planteamiento y seguimiento del proceso de gesti´on que seguir´a el proyecto. Cap´ıtulo 3: Exposici´on de conceptos te´oricos sobre los sistemas conversacionales. Cap´ıtulo 4: An´alisis de las plataformas de desarrollo existentes en el mercado. Cap´ıtulo 5: Descomposici´on y explicaci´on de una Alexa skill Cap´ıtulo 6: Conclusiones del estudio sobre las diversas alternativas de desarrollo Cap´ıtulo 7: Dise˜no e implementaci´on de la aplicaci´on. Cap´ıtulo 8: Conclusiones finales y propuestas de desarrollo. Ap´endice A: Gu´ıa paso a paso para la implementaci´on de una custom skill a partir de una plantilla. Ap´endice B: Ejemplo de desarrollo de una custom skill. Bibliografia 1.4. Herramientas empleadas En este proyecto se han utilizado las siguientes herramientas y plataformas: Plataforma de desarrollo Alexa developer console (Plataforma de desarrollo de Alexa): Herramienta de desarrollo interactiva que incluye las cuatro etapas b´asicas de desarrollo de las skills (build, code, test y deploy). Lenguaje Javascript: Para el desarrollo de las funcionalidades, as´ı como la obtenci´on de datos se ha elegido la variante basada en Javascript frente a las alternativas Python y Java (s´olo para offline). Preparaci´on de la Memoria Overleaf: Editor on-line de L A T EXque permite almacenar y compartir los archivos en la nube, lo que facilita poder trabajar simult´aneamente a varias personas desde distintos lugares. paint.net: Editor gr´afico empleado en algunas de las im´agenes presentes en la memoria. Cap´ıtulo 2 Metodolog´ıa y Planificaci´on En este cap´ıtulo se describe y justifica la metodolog´ıa seguida en el desarrollo de la skill, as´ı como metas que se desean alcanzar y los posibles problemas que surjan durante dicho desarrollo. 2.1. Metas Este proyecto se ha desarrollado por una ´unica persona, con todo lo que ello conlleva dado que esa misma persona deber´a hacerse cargo de la gesti´on, direcci´on, desarrollo y pruebas de todo el proyecto, no obstante el modelo a seguir procurar´a imitar en la medida de lo posible un proyecto t´ıpico desarrollado por un equipo, intentando de esta manera alcanzar los mismos objetivos. Calidad: objetivo b´asico de cualquier proyecto que se precie, ligado directamente al desarrollo, no se considerar´a como producto finalizado si no cumple unos m´ınimos de calidad. Este objetivo implica la eliminaci´on de fallos a lo largo de la vida del proyecto as´ı como asegurarse del correcto funcionamiento del producto final. Productividad: Se procurar´a cumplir con el tiempo establecido para la entrega del producto. Reducci´on de riesgos: Con la intenci´on de cumplir con los plazos, se desarrollar´a un plan de contingencia para cada riesgo que pueda surgir por el camino. 2.2. Restricciones Factores que limitan el trabajo de desarrollo de la skill. Tiempo: el tiempo dado para el desarrollo de la skill solo puede extenderse hasta mediados de Octubre. Conocimientos: dado el car´acter novedoso de la propuesta y la carencia de conocimientos previos, as´ı como pr´actica en el desarrollo de este tipo de software, cualquier avance conlleva un estudio previo y por consiguiente un tiempo a˜nadido. Equipo: como se ha descrito con anterioridad el trabajo ser´a desarrollado por una ´unica persona. 3 4CAP´ ITULO 2. METODOLOG´ IA Y PLANIFICACI ´ ON 2.3. Metodolog´ıa adoptada Dado el “peque˜no” tama˜no del proyecto, as´ı como el reducido equipo de trabajo, se ha adoptado una metodolog´ıa ´agil, m´as concretamente Scrum, ya que simplifican de manera significativa todo el proceso de gesti´on. 2.3.1. Roles Scrum En la metodolog´ıa Scrum intervienen principalmente 3 roles, que son los siguientes: Scrum Master: Responsable del cumplimiento de la metodolog´ıa, dado que es la persona con mayor conocimiento sobre esta. Equipo de desarrollo: Personal encargado del desarrollo del producto (AKA: desarrolladores.) Product Owner: M´aximo interesado en el proyecto, normalmente el cliente, tambi´en se encuentra definido este rol como representante de los stakeholders. Aparte de los roles principales, la metodolog´ıa Scrum est´a caracterizada por una serie de eventos, a saber: Scrum meeting: Reuniones, t´ıpicamente diarias, entre los miembros del equipo. Sprint: Marco temporal que marca el desarrollo de distintas partes del proyecto, t´ıpicamente predefinidos a una duraci´on fija, y de los que se espera que al acabar se haya desarrollado una parte funcional del trabajo. Sprint review: Reuni´on que toma lugar al finalizar un sprint, se revisa el desarrollo del mismo y se comprueba si los objetivos prefijados se han alcanzado. Sprint retrospective: Reuni´on que tambi´en toma lugar al finalizar un sprint, pero que tiene como finalidad analizar los objetivos no cumplidos para poder subsanarlos y mejorarlos en el siguiente sprint. 2.3.2. Scrum adaptado Como hemos dicho previamente, y tal y como viene reflejado en las restricciones la metodolog´ıa utilizada se ha tenido que adaptar a las circunstancias. Los roles se han visto modificados de la siguiente manera: Scrum Master/equipo de desarrollo: Se a´unan los 2 roles en uno, dado que los ejecutar´a la misma persona, ´ Alvaro Gonz´alez-Iglesias Gonz´alez. Product Owner: En este caso no ser´a un cliente, pero si la persona m´as interesada en el proyecto, el tutor del trabajo Valent´ın Carde˜noso Payo Los eventos que definimos previamente, se van a ver tambi´en modificados. Para empezar como es obvio, no se realizar´an los Scrum meetings, dado que el equipo de desarrollo est´a compuesto por una ´unica persona. En cuanto a los sprints, se ha acordado estructurar el proyecto en 3 sprints, con una duraci´on estimada de 1 mes por sprint (englobando de esta manera los 3 meses de desarrollo de proyecto). A˜nadido a estos sprints de 1 mes, se realizar´an reuniones de toma de contacto cada 1/2 semanas, en funci´on de la disponibilidad tanto por parte del Product Owner, como del equipo de desarrollo (esto es debido a que coincide con el periodo vacacional, y otra serie de obligaciones, que se detallar´an m´as adelante en los riesgos). 2.4. RIESGOS 5 2.4. Riesgos Debido a que existen diversos factores que pueden tener un impacto negativo en el tiempo de desarrollo del proyecto, es importante realizar un estudio previo para conocer dichos factores y poder tomar medidas en el caso de que sucedan. Este estudio nos permitir´a identificar, definir, y planificar los riesgos que puedan surgir, y para ello nos serviremos de la siguiente plantilla: Identificador Identificador ´unico del riesgo Descripci´on Descripci´on del riesgo Probabilidad Estimaci´on de la probabilidad de ocurrencia del riesgo Consecuencias Consecuencias que puede tener la ocurrencia del riesgo Impacto Nivel de impacto que tendr´ıa en el proyecto el riesgo Plan de contingencia Medidas a adoptar para minimizar el impacto en caso de ocurrir el riesgo Comentarios Notas sobre el riesgo Cuadro 2.1: Plantilla para los riesgos A continuaci´on se enumeran los riesgos que se han detectado en el estudio: Identificador 1 Descripci´on Contracci´on de enfermedad Probabilidad Media Consecuencias Bajar o parar el ritmo de trabajo Impacto Medio Plan de contingencia No existe un plan de actuaci´on para este riesgo ya que una vez sucedido no es posible establecer una contramedida adecuada Comentarios Habitualmente la probabilidad de ocurrencia es baja, pero debido a la pandemia se ha elevado a media Cuadro 2.2: Riesgo 1 Identificador 2 Descripci´on Imposibilidad de desarrollo de las ideas predefinidas Probabilidad Alta Consecuencias Replantear el objetivo de desarrollo Impacto Medio Plan de contingencia Establecer varias v´ıas de desarrollo para poder cambiar en el caso de que alguna de estas acabe en fracaso Comentarios De hacerse un buen estudio previo de las posibilidades el impacto podr´a cambiar de medio a bajo Cuadro 2.3: Riesgo 2 2.5. Matriz de impacto / probabilidad En la siguiente tabla se resumen los riesgos planteados previamente, y adem´as se indica una estimaci´on de la probabilidad de la ocurrencia de cada riesgo, as´ı como una clasificaci´on de su impacto. 6CAP´ ITULO 2. METODOLOG´ IA Y PLANIFICACI ´ ON Identificador 3 Descripci´on Retrasos en el desarrollo Probabilidad Media Consecuencias No alcanzar los objetivos de desarrollo en los tiempos estipulados Impacto Muy Alto Plan de contingencia Aumentar el n´umero de horas diarias de desarrollo Comentarios Debido a la pandemia la probabilidad se ha aumentado, ya que las circunstancias propician que puedan surgir distracciones o problemas Cuadro 2.4: Riesgo 3 Identificador 4 Descripci´on Imposibilidad de acceso a los servicios Probabilidad Baja Consecuencias No poder realizar parte del desarrollo Impacto Alto Plan de contingencia Dividir el desarrollo en secciones on-line y off-line, lo que permitir´a seguir con la parte off-line mientras los servicios se restablecen Comentarios Debido a que parte del desarrollo debe hacerse en plataformas on-line existe la posibilidad de que dicho servicio se vea interrumpido por tareas de mantenimiento Cuadro 2.5: Riesgo 4 Identificador 5 Descripci´on Necesidad excesiva de estudio Probabilidad Alta Consecuencias El tiempo previo al desarrollo se aumenta, por lo que incurrimos en una necesidad de aumentar las horas del mismo posteriormente Impacto Muy Alto Plan de contingencia Intentar establecer objetivos m´as al alcance, y redirigir el desarrollo acorde a las capacidades del equipo Comentarios El car´acter novedoso del proyecto causa una necesidad muy alta de estudio sobre el mismo Cuadro 2.6: Riesgo 5 Identificador Riesgo Impacto Probabilidad 1 Contracci´on de enfermedad 2 33 % 2 Imposibilidad de desarrollo de las ideas predefinidas 2 45 % 3 Retrasos en el desarrollo 4 25 % 4 Imposibilidad de acceso a los servicios 3 10 % 5 Necesidad excesiva de estudio 4 60 % Cuadro 2.7: Tabla de riesgos 2.6. SEGUIMIENTO 7 Partiendo de la tabla anterior se ha podido desarrollar la siguiente matriz de riesgos Impacto/probabilidad Muy baja Baja Media Alta Muy alta Despreciable Marginal 1 2 Cr´ıtico 4 Catastr´ofico 3 5 Cuadro 2.8: Matriz de impacto / probabilidad 2.6. Seguimiento A continuaci´on se ha recogido brevemente el seguimiento real de los sprints realizados, as´ı como el contenido abordado/desarrollado entre reuniones. 2.6.1. Sprint 0: Estudio te´orico El primer sprint se ha planteado como una fase de estudio sobre las tecnolog´ıas relevantes para el proyecto, tanto a nivel te´orico como las implementaciones comerciales m´as actuales. Semanas 1 y 2 Respecto al estudio te´orico, se ha procedido a investigar sobre el funcionamiento general de los sistemas de dialogo hablado como se ha abordado en el Cap´ıtulo 3 Semanas 3 y 4 (1amitad) Se finaliz´o el estudio te´orico. Una vez realizado el estudio de los fundamentos te´oricos se procedi´o al an´alisis de las tecnolog´ıas comerciales existentes como se detalla en el Cap´ıtulo 4 De este estudio se concluyo que la plataforma id´onea para el proyecto que se plantea es Alexa de Amazon Semanas 4 (2amitad) y 5 Una vez decidida la plataforma sobre la que se iba a desarrollar el proyecto, se realizo un estudio exhaustivo de su funcionamiento como se puede ver en el Cap´ıtulo 5 Con la plataforma decidida y conociendo las capacidades de la misma se planteo, analiz´o y eligi´o el contenido del prototipo a desarrollar, como se ve en el Cap´ıtulo 6 2.6.2. Sprint 1: Primera skill Con el estudio realizado y las decisiones sobre el contenido del prototipo tomadas, el sprint 1 se plantea como fase de toma de contacto con la plataforma de desarrollo y comprobaci´on real de las capacidades tanto del desarrollador como de la plataforma. Semanas 6 y 7 La primera toma de contacto se realiza siguiendo la documentaci´on aportada por la propia plataforma de desarrollo, creando una skill de alexa a partir de una plantilla y siguiendo una gu´ıa. 8CAP´ ITULO 2. METODOLOG´ IA Y PLANIFICACI ´ ON Una vez entendido el funcionamiento de la plataforma de desarrollo, se realizaron m´as pruebas no abarcadas en la documentaci´on propia de la plataforma, con el fin de encontrar el l´ımite de las capacidades de la misma. 2.6.3. Sprint 2: UVa Informer El ´ultimo sprint se ha dedicado al desarrollo de la aplicaci´on planteada, as´ı como de la memoria actual. Dado que el tiempo que se hab´ıa planteado en un principio para la toma de contacto con la plataforma de desarrollo (el sprint 1 completo, aproximadamente 4 semanas), en la pr´actica a resultado menor, se ha procedido a iniciar el desarrollo del prototipo con antelaci´on. Semanas 8 y 9 Inicio del proceso de desarrollo del prototipo, dise˜no de la interfaz vocal y funciones auxiliares del c´odigo. Semana 10 Se ha encontrado un problema en la conexi´on de datos entre Alexa ( y el entorno de aws ) y las p´aginas web de la Universidad de Valladolid, debido a un problema de Cors (Cross-Origin Resource Sharing) que imped´ıa establecer cualquier tipo de conexi´on entre ambas. Se consigui´o solucionar dicho problema y continuar con el desarrollo. Semana 11 Se finaliza el prototipo funcional de la Alexa skill y se realiza una bater´ıa de pruebas. Semana 12 Elaboraci´on de la memoria del proyecto. Cap´ıtulo 3 Fundamentos te´oricos Desde la antig¨uedad el ser humano a tratado de interactuar con seres artificiales de manera natural,prueba de ello la encontramos en la mitolog´ıa (Los aut´omatas de Hefesto, Talos, Golem,...) pero no es hasta el siglo diecinueve cuando se logra realmente los primeros avances en el campo. A principios del siglo veinte se desarrollaron los primeros sistemas el´ectricos capaces de reproducir cualquier sonido, seguido por las primeras computadoras en los a˜nos cuarenta, y es ya en la d´ecada de los sesenta cuando se desarrollan los primeros sistemas basados en lenguaje como por ejemplo ELIZA [2] que operaba con una entrada por teclado. Con el paso de los a˜nos y la evoluci´on tecnol´ogica aparecen los primeros proyectos en el campo del reconocimiento vocal como es el proyecto ESPRIT SUNDIAL[3] o DARPA Spoken Language System (SLS) [4] 3.1. Sistemas de Di´alogo Hablado Entendemos como sistema de di´alogo hablado (Spoken Dialogue System [SDS])/agente conversacional a cualquier interfaz inform´atica con la que interactuamos mediante el lenguaje natural hablado, siguiendo un orden por turnos entre quien utiliza dicho sistema de dialogo, y la propia maquina. En base a su funcionamiento podemos clasificar los SDS en dos grandes grupos[5]: Task-oriented dialogue agents: Este tipo de sistema se enfoca en la realizaci´on de tareas concretas, desde crear eventos en un calendario, realizar llamadas, obtener informaci´on concreta o realizar reservas en diversos servicios. Necesita de respuestas muy concretas y enfocadas a la tarea que se desea resolver, y suelen desarrollarse dentro de un marco de acci´on muy bien definido. Chatbots: Estos sistemas est´an especializados en alcanzar conversaciones m´as largas imitando “chats” reales entre personas, en las que el usuario podr´ıa estar interactuando con otro usuario en lugar de con una m´aquina. Se puede deducir por lo tanto que su ´ambito se asimila m´as al del entretenimiento que al de soluci´on de problemas. 3.2. Arquitectura Dentro de cada gran clase existen diferentes arquitecturas que permiten alcanzar el objetivo de funcionamiento. Comenzaremos con los sistemas orientados a tareas. 9 16 CAP´ ITULO 3. FUNDAMENTOS TE ´ ORICOS Otra opci´on con la que contamos para poder tener en cuenta todas las sentencias correctas sin necesidad de definirlas con antelaci´on ser´ıa utilizar modelos de n-grama, ya que los modelos de n-grama permiten calcular la probabilidad de una secuencia de palabras como el producto de las probabilidades de cada palabra, asumiendo que la ocurrencia de cada palabra viene dada por las N−1 palabras previas. P(W) = P(w1, ..., wn) = N Y n=1 P(wn|w1, ..., wn−1) (3.4) 3.3.2. Comprensi´on del lenguaje Una vez hemos transcrito la entrada proporcionada por el usuario el siguiente paso consiste en entender que hemos recibido, en este componente entran en acci´on las diferentes arquitecturas que hemos explicado anteriormente. 3.3.3. Gesti´on de Di´alogo Con la entrada transcrita y procesada, debemos decidir como actuar. Al igual que con el componente anterior, el funcionamiento de este componente se ha explicado en la secci´on previa de arquitectura. 3.3.4. Comunicaci´on con el sistema externo Por lo general los SDS necesitan conectarse con alguna fuente de informaci´on (tipicamente una base de datos) y para ello existen diversas formas de conseguirlo. Este componente es el que se encarga precisamente de ello, la comunicaci´on con fuentes de informaci´on, y para ello no existe una estrategia, metodolog´ıa definida, dependiendo de como funcione nuestro SDS y la fuente de informaci´on a la que queramos engancharnos, deberemos adaptar un puente de comunicaci´on u otro. El uso m´as habitual que se le da a este componente es el de obtenci´on de los datos solicitados por el usuario para componer la respuesta, con los datos que se le han solicitado por ejemplo en un sistema de reserva de vuelos, se generar´a una query para obtener los datos de los vuelos que se enmarquen en sus preferencias, para poder solicitar al usuario que escoja el que necesita. 3.3.5. Generaci´on de respuestas Este componente aunque tiene la misma finalidad tanto para los chatbots como para los agentes orientados a tareas, funciona de distinta manera. Aunque dentro de cada apartado ya se defini´o su funcionamiento vamos a recordarlo brevemente. Task-oriented dialogue agents: Lo m´as habitual es que contemos con una plantilla de respuesta que se rellenar´a con los datos obtenidos en el componente anterior, aunque si bien es verdad, podemos incluir procesamiento con aprendizaje autom´atico para poder generar respuestas m´as parecidas al lenguaje humano y que se adapten mejor a las caracter´ısticas particulares de cada sentencia de entrada. Chatbots: Los chatbots como hemos reiterado ya en varias ocasiones, intentan imitar una interacci´on humana lo m´as cre´ıble posible, por y para ello se valen de t´ecnicas de aprendizaje autom´atico entrenadas sobre conversaciones reales para lograrlo, de esta manera adaptan cada salida hacia el usuario de manera particular. Como hemos dicho el funcionamiento m´as preciso ya se ha explicado en secciones previas. 3.3. COMPONENTES ESENCIALES 17 3.3.6. Salida vocal Una vez ya tenemos toda la informaci´on que queremos devolver, y hemos generado la estructura de respuesta, solo nos queda pasar dicha sentencia al medio hablado. Una de las maneras m´as simple consiste en almacenar grabaciones de voz de personas, consistentes en todas las palabras necesarias para generar las distintas respuestas, y despu´es componer palabra a palabra (grabaci´on a grabaci´on) la sentencia completa. Un sistema m´as avanzado ser´ıa grabar cada posible fonema para poder componer cualquier tipo de palabra posible y no estar limitados por el contexto (tanto a la hora de grabar como de componer). Como se puede observar existen m´ultiples de t´ecnicas de composici´on de voz, y con el avance de la tecnolog´ıa se ha ido superando la barrera de lo “rob´otico” para llegar a sistemas de voz m´as naturales y cre´ıbles. 18 CAP´ ITULO 3. FUNDAMENTOS TE ´ ORICOS Cap´ıtulo 4 Plataformas de desarrollo A continuaci´on se va a proceder a explicar una serie de conceptos necesarios para entender el desarrollo de la skill. Comenzaremos con un breve an´alisis de las diversas plataformas vocales del mercado, siguiendo con los pasos t´ıpicos en el desarrollo de una aplicaci´on vocal. Por ´ultimo enunciaremos las herramientas que se han utilizado a lo largo del proyecto. 4.1. An´alisis de plataformas existentes. Las principales plataformas que existen actualmente en desarrollo son las pertenecientes a las grandes compa˜n´ıas, como son: “Alexa”[8] de Amazon, “Google Assistant”[9] de Google, “Cortana”[10] de Microsoft, “Siri”[11] de Apple. 4.1.1. Siri Siri es considerado el primero de los asistentes virtuales comerciales, desarrollado actualmente por la empresa Apple, naci´o como una aplicaci´on comercial del proyecto CALO. CALO fue un proyecto de DARPA que buscaba crear un sistema aut´onomo de an´alisis y clasificaci´on de la informaci´on (CALO: Cognitive Assistant that Learns and Organizes), antes de que este fuese abandonado, 3 investigadores de SRI International crearon los primeros primeros prototipos de Siri, la cual estaba pensada para ser integrada todas las plataformas m´oviles, pero tras ser adquirida por Apple pas´o a ser de uso exclusivo para sus sistemas m´oviles. El planteamiento original de Siri consist´ıa en ayudar a los desarrolladores a la hora de generar ontolog´ıas para los SDS. Despu´es de ser adquirida por Apple, el enfoque de su desarrollo comenz´o a cambiar, pasando de ser un sistema de reglas puro a convertirse en un h´ıbrido entre chatbot y sistema de reglas. Siri sigue funcionando como asistente que devuelve la informaci´on solicitada o ejecuta tareas siguiendo una arquitectura basada en marcos, pero tambi´en es capaz de gestionar solicitudes que caen fuera de los dominios preestablecidos, Gracias a esto consigui´o adaptarse mejor a cualquier tipo de usuario. 4.1.2. Google Assistant Google Assistant (sucesor de Google Now) es un asistente virtual desarrollado principalmente para dispositivos m´oviles y dispositivos de dom´otica inteligente. A diferencia de su predecesor Google Assistant es capaz de participar en conversaciones bidireccionales, as´ı como interactuar con diversas aplicaciones o dispositivos del hogar. En sus ´ultimas versiones se ha podido ver como Google Assistant a evolucionado su capacidad conversacional llegando a cotas de autonom´ıa tales como poder concertar una cita en una peluquer´ıa v´ıa telef´onica con un interlocutor humano[12]. 19 20 CAP´ ITULO 4. PLATAFORMAS DE DESARROLLO 4.1.3. Cortana Cortana naci´o como el asistente virtual de la compa˜n´ıa Microsoft desarrollado para los sistemas operativos Windows y Windows phone, aunque debido a la descontinuaci´on de este ´ultimo su desarrollo se ha orientado a nuevos objetivos[13]. La principal v´ıa de desarrollo de Cortana est´a orientada a la suite de Office 365 de Microsoft ofreciendo una capacidad de reconocimiento del lenguaje que le permite responder a preguntas sobre los datos que la suite maneja, aunque no por ello carece de las funcionalidades m´as comunes en los asistentes virtuales, como son la capacidad de establecer recordatorios y notas, as´ı como interactuar con diversas aplicaciones, si bien es verdad que su rango de acci´on es menor en este aspecto en comparaci´on con los dem´as asistentes mencionados. 4.1.4. Alexa Amazon define Alexa como “el servicio de voz ubicado en la nube de Amazon disponible en los dispositivos de Amazon y dispositivos de terceros con Alexa integrada.[8]” Inicialmente Alexa solo se encontraba disponible en los dispositivos Echo (Exclusivos de Amazon), pero posteriormente se expandi´o su desarrollo a dispositivos m´oviles, televisores, manos-libres para veh´ıculos... Alexa se caracteriza por sus amplias capacidades de interacci´on con diversas aplicaciones, desde la reproducci´on de m´usica a la creaci´on de alarmas, listas de la compra, etc... Tambi´en es reconocida por su facilidad de desarrollo por parte de usuarios menos expertos gracias a su plataforma de desarrollo, y la amplia documentaci´on existente. Cap´ıtulo 5 Anatom´ıa de una skill Para poder entender las decisiones que se tomar´an posteriormente en el an´alisis es necesario entender y conocer como funciona y se desarrolla una skill para Alexa. 5.1. Proceso de vida de una skill Para comenzar a entender el proceso de desarrollo de una skill de amazon tenemos que conocer las distintas partes que componen dicho proceso. Por un lado tenemos la parte de reconocimiento vocal y respuesta y por otra el procesamiento de los datos. 5.1.1. Reconocimiento vocal A los distintos “programas” que ejecutamos con Alexa se les llama skills, existen diversos tipos de skills enfocadas a distintos usos del sistema, pero en la que nosotros nos vamos a enfocar son las “custom skills”. Las custom skills se caracterizan por permitir desarrollar pr´acticamente cualquier tipo de interacci´on sin restricciones previas. Cuando interactuamos con una skill, todo comienza por una palabra clave de arranque, que recibe el nombre de “wake word” (en este caso concreto la wake word es “alexa”, para google assistant ser´ıa “ok, google”), una vez pronunciada la wake word, alexa entiende que estamos interactuando con ella, y procede a escuchar el resto de la frase. Una vez hemos obtenido “la atenci´on” de nuestro asistente debemos indicarle que rutina/aplicaci´on de todas las disponibles queremos ejecutar, para ello deberemos referirnos al nombre de la skill o “Invocation name”. Dicho invocation name puede ser usado de 2 maneras distintas: Arranque & petici´on: pedimos al asistente que inicialice el servicio y quede a la espera de nuevas ordenes Ejemplo: Alexa inicia uvainformer. Petici´on directa: pedimos al asistente directamente los datos que necesitamos del servicio Ejemplo: Alexa pide a uvainformer... A partir de aqu´ı entramos en lo que es el grueso de nuestra skill, ya que es ahora cuando podremos especificar que informaci´on queremos, pero para ello deberemos utilizar una serie de formulaciones predefinidas en la skill. 21 22 CAP´ ITULO 5. ANATOM´ IA DE UNA SKILL 5.1.2. Procesamiento de datos Una vez Alexa a terminado con la parte del reconocimiento vocal, los datos que se han extra´ıdo se paquetizan y se procesan. El resultado de ese procesamiento es una cadena de texto que es devuelta a Alexa para ser enunciada con los datos solicitados. 5.2. Partes de una skill Todas las skills de Alexa se componen de las mismas partes. En algunas podremos editarlas todas mientras que en otras solo algunas de ellas. 5.2.1. Wake word Como ya se defini´o previamente, la wake word es la palabra que “despierta” a nuestro asistente, esta palabra viene ya definida y puede ser “Alexa”, “Amazon” o “Echo”, una vez se pronuncia el asistente comenzar´a a escuchar todo lo que se diga a continuaci´on. 5.2.2. Inicializaci´on Como hemos mencionado con anterioridad, las skills de alexa se pueden inicializar de dos maneras distintas: Inicializaci´on sin petici´on Podemos inicializar la skill de Alexa sin ninguna petici´on definida si utilizamos cualquiera de los siguientes modelos: <invocation name> <palabra de arranque><invocation name> Donde las palabras de arranque pueden ser: Empiece, lanza, abre, inicia, pon, comienza, usa. Por ejemplo: Alexa, lanza uvainformer. Inicializaci´on con petici´on Si queremos inicializar la skill y obtener informaci´on en una ´unica petici´on podemos utilizar un nuevo conjunto de palabras de arranque: Preg´untale a, p´ıdele a, dile a Por ejemplo: Alexa, p´ıdele a uvainformer datos sobre.... O utilizar algunas de las que ya hemos nombrado en conjunci´on con un nuevo grupo de palabras: Y, para, para que. 5.2. PARTES DE UNA SKILL 23 <palabra de arranque><invocation name><palabra de conexi´on><alguna acci´on> Por ejemplo: Alexa, inicia uvainformer y pide los datos de ... 5.2.3. Invocation Name El invocation name es el nombre por el cual se identifica la skill, no tiene por qu´e coincidir con el nombre que se la da a la skill (aunque suele ser lo habitual). Existen ciertas reglas a la hora de elegir el invocation name, entre ellas destacamos El nombre no puede contener ninguna de las wake words El nombre no puede contener ninguna de las palabras de inicializaci´on Los nombres compuestos por una ´unica palabra solo se permiten previa acreditaci´on de propiedad intelectual sobre dicha palabra Los nombres compuestos por dos palabras no podr´an utilizar un articulo definido o indefinido, ni una preposici´on como una de dichas palabras En los ejemplos realizados hasta ahora como invocation name hemos utilizado “uvainformer”, aunque siguiendo las reglas podemos descomponerlo en “uva informer”. 5.2.4. Intents Una skill no reconoce ´unicamente un solo tipo de pregunta o petici´on, al contrario, es capaz de reconocer tantos tipos de preguntas distintas como nosotros programemos. Cada una de esas preguntas o peticiones recibe el nombre de Intent. Cada intent que creemos se encargar´a de entender un tipo de petici´on distinta que haga el usuario, pongamos un ejemplo para que quede m´as claro: Tenemos una skill de una agencia de viajes podr´a ofrecer informaci´on sobre los paquetes vacacionales que tienes o sobre rutas simples de viajes. El usuario cuando vaya a solicitar informaci´on sobre los paquetes vacacionales no preguntar´a de la misma manera que sobre las rutas simples, ya que los paquetes vacacionales solo necesitan la informaci´on del destino deseado - Alexa, pide a uva viajes las ofertas en Italia Mientras que las rutas simples necesitar´an la informaci´on de origen y destino. - Alexa, inicia uva viajes y pide informaci´on para viajar de Valladolid a Palencia. Como hemos podido observar las dos peticiones no comparten nada m´as que la wake word y el invocation name. 5.2.5. Slots Cuando realizamos una petici´on de todas las palabras que componen la frase nos interesan ´unicamente unas pocas, esas pocas palabras que nos interesan son las que nos ofrecen la informaci´on relevante sobre la que el usuario est´a preguntando, y para poderlas tratar las encapsulamos en slots. Un slot recoge los posibles valores en una posici´on concreta de las frases y nos permite comprobar si esa palabra est´a dentro de las que esper´abamos e incluso asociarle un ID. 24 CAP´ ITULO 5. ANATOM´ IA DE UNA SKILL Sigamos con el ejemplo de la agencia de viajes. En la frase: Alexa, pide a uva viajes las ofertas en Italia, podemos pensar que la agencia no solo tiene ofertas, tambi´en tendr´a paquetes normales, hoteles, espect´aculos, etc... As´ı mismo no trabajar´a ´unicamente con Italia, habr´a una lista de pa´ıses disponibles. En este caso Italia corresponder´a al slot pa´ıs y Ofertas al slot producto, el slot de pa´ıs estar´a compuesto por un listado de pa´ıses de los cuales la agencia tiene informaci´on. 5.2.6. Utterances A cada forma distinta de invocar un mismo intent se le da el nombre de utterance. Cuando inicializamos un intent podemos utilizar distintos verbos, y no todos utilizan el mismo tipo formulaci´on para referirse a la misma idea, es decir, si nosotros decimos: Alexa, pide a uva viajes las {producto}de {pa´ıs} El intent estar´a compuesto por la frase: las {producto}de {pa´ıs}, pero tambi´en podemos solicitar la misma informaci´on de la siguiente manera: Alexa, inicia uva viajes y preg´untale en {pa´ıs}que {producto}hay. De manera que dentro del mismo intent tambi´en se recoger´a la frase: en {pa´ıs}que {producto} hay. Cada una de estas frases es una utterance. Es recomendable definir m´ultiples utterances para que concuerden con las palabras de inicializaci´on o que encajen con distintas formas de preguntar la informaci´on, de esta manera el usuario podr´a utilizar la skill de manera m´as sencilla y fluida. 5.3. Tipos de skill A la hora de crear una skill existen distintas maneras de hacerlo, Alexa nos ofrece por defecto una serie de plantillas que vamos a definir a continuaci´on. 5.3.1. Custom Este tipo de skill es la m´as amplia de todas, permite el desarrollo de todas las dem´as. Dentro de una custom skill podremos definir nuestros propios intents, as´ı como las utterances de los mismos. Tambi´en nos permitir´a programar todo el funcionamiento en la propia plataforma de desarroolo de Alexa 5.3.2. Flash Briefing Una flash briefing skill sirve para devolver noticias o contenido al usuario, esta skill solo nos permitir´a definir las fuentes de informaci´on y las utterances. 5.3. TIPOS DE SKILL 25 5.3.3. Smart Home Las Smart Home skills est´an enfocadas a la d´omotica, a trav´es de esta skill podremos interactuar con distintos dispositivos externos, pero hasta ah´ı llega su alcance. Deberemos proporcionarle nuestro propio endpoint y nos permitir´a definir las peticiones que reciba (esto no son intents, ya que est´an acotadas a funcionalidades de dispositivos existentes) as´ı como sus utterances. 5.3.4. Video Las skills de Video sirven para controlar el funcionamiento de aplicaciones de streaming es decir, esta skill podr´a conectarse con aplicaciones dentro de fire TV o dispositivos echo con pantalla. Tambi´en permite desarrollar skills para controlar dispositivos de entretenimiento, pero deber´a ser el fabricante del dispositivo quien desarrolle la skill. 32 CAP´ ITULO 7. DESARROLLO Figura 7.1: Diagrama conceptual de funcionamiento Figura 7.2: Diagrama de secuencia de un intent cualquiera 7.1. AN ´ ALISIS Y ARQUITECTURA 33 Figura 7.3: Panel de b´usqueda una b´usqueda por nombre, el funcionamiento interno de la p´agina consiste en una petici´on de tipo GET a una url en la que se incluyen los tags de los par´ametros de b´usqueda (Figura 7.4), as´ı como el texto introducido codificado para html (se puede apreciar en las dos primeras l´ıneas del apartado General de la Figura 7.4) Con la informaci´on que proporciona la consola, podemos extraer los par´ametros necesarios para ejecutar nuestras propias ordenes GET y POST, as´ı que procedemos a comprobarlo mediante una orden CURL/Fetch ejecutada desde un terminal (Figura 7.5). Si nos fijamos en el resultado que nos ofrece la interfaz web de directorio UVA a la b´usqueda Figura 7.6, podemos observar que hemos obtenido varios resultados, pero de esos resultados solo nos muestra el nombre junto con el cargo, mientras que el resultado ofrecido tanto por la consola de desarrollo de chrome, como el obtenido mediante la orden curl en terminal, nos muestra toda la informaci´on disponible Figura 7.7. Con esta informaci´on que podemos obtener en formato JSON, ya tenemos todo lo necesario de momento para poder desarrollar el intent de nuestra skill. 7.1.2. Intent 2: Horarios de tutor´ıas En esta segunda propuesta de aplicaci´on queremos obtener los horarios de tutor´ıas de cada profesor, dicha informaci´on est´a disponible de forma abierta y en formato html en la p´agina web de la Universidad de Valladolid, aunque no de manera directa. Dado que nuestra skill esta planteada como un sistema de marcos y huecos, tenemos que plantear que datos necesitamos para poder generar una respuesta adecuada. Lo primero ser´ıa el nombre del profesor en cuesti´on del que queremos conocer los horarios. Pero no nos basta solo con esto, ya que un mismo profesor puede dar clases en distintos grados, y tener asociadas distintas horas para cada grado. Esta estructura de profesor en grado es la que sigue la p´agina web de la Universidad de Valladolid para organizar la informaci´on, por lo que a parte del nombre del profesor, necesitamos tambi´en el grado en el que imparte clase. Con esta informaci´on vamos a poder realizar una b´usqueda en la p´agina web de la Universidad de Valladolid, donde en el apartado de Docencia >Grado >Oferta Formativa Grados >Alfab´etica se encuentran listados todos los grados que se imparten. Similar a la secci´on anterior vamos a realizar una petici´on a una p´agina web (https:// www.uva.es/export/sites/uva/2.docencia/2.01.grados/2.01.02.ofertaformativagrados/ 34 CAP´ ITULO 7. DESARROLLO Figura 7.4: Consola de desarrollo Figura 7.5: Orden CURL sobre directorio UVA 7.1. AN ´ ALISIS Y ARQUITECTURA 35 Figura 7.6: Resultado web de una b´usqueda en directorio UVA Figura 7.7: Respuesta a la orden GET realizada sobre directorio UVA 2.01.02.01.alfabetica/index.html), para poder obtener el listado de los grados. La respuesta a esta petici´on podemos verla tanto en la consola de desarrollo de chrome como en un terminal (mediante su correspondiente orden CURL/Fetch),y viene en la forma de una p´agina web en formato html como se ve en la Figura 7.8 Figura 7.8: P´agina web alfab´etica de la UVA como respuesta a petici´on GET Al igual que dentro de la p´agina web (Figura 7.9), dentro del archivo html vienen listados todos los grados disponibles utilizando la estructura que se muestra en la Figura 7.10 Dado que la estructura es com´un a todos los enlaces, pero los nombres de los grados son ´unicos, podemos utilizar estos, para obtener el enlace a la informaci´on concreta del grado. Ahora que tenemos el enlace vamos a repetir de nuevo el proceso, realizando una solicitud y obteniendo una p´agina web en formato html de vuelta. Lo que ahora queremos obtener es el equivalente a la tabla de horarios que se ve en Figura 7.11. Pero esa tabla no se encuentra en la p´agina web actual, si no que tiene su propia ruta, si buscamos la ruta de donde la 36 CAP´ ITULO 7. DESARROLLO Figura 7.9: P´agina web de la Universidad de Valladolid con el listado de grados Figura 7.10: Segmento en html que define el enlace al grado 7.2. DISE ˜ NO VOCAL 37 p´agina web carga la tabla, veremos que el archivo da igual en que grado entremos, se llama tutoria.htm, y que dicho archivo se puede obtener mediante una petici´on GET. Esa petici´on nos devolver´a la tabla de horarios de tutor´ıas en formato html, y ahora solo es cuesti´on de extraer la informaci´on que necesitamos. Figura 7.11: P´agina web de la Universidad de Valladolid con el listado de horarios de tutor´ıas 7.2. Dise˜no vocal En esta secci´on vamos a definir los intents y slots que se han creado para cada intent, ya que el proceso de creaci´on de los mismos se ha definido en el Ap´endice A. Todo el c´odigo de la skill que se est´a presentando aqu´ı, se puede encontrar en https://github.com/lvareo/ UVaInformer.git 7.2.1. Intent 1: Informaci´on de profesores Slots Siguiendo el an´alisis realizado en la secci´on anterior, todo lo que necesitamos saber es el nombre del profesor, por lo que el ´unico slot que definamos deber´a recoger el nombre. Dado 38 CAP´ ITULO 7. DESARROLLO que no tenemos un listado de todos los profesores de la universidad, vamos a hacer uso del slot predefinido de alexa: AMAZON.SearchQuery. Este slot recoge cualquier tipo de entrada, lo que nos permitir´a realizar las b´usquedas. Otra opci´on que vamos a marcar es que es un slot necesario, y que por lo tanto en caso de no suministrar el usuario un contenido para el mismo, tendremos que preguntar espec´ıficamente por este. En cuanto a los utterances vamos a tener de dos tipos, los propios del intent, y los asociados al slot, y comenzaremos definiendo estos ´ultimos. Lo primero ser´a definir las preguntas que haremos cuando el slot no haya sido rellenado con la informaci´on ofrecida, podemos para ello realizar preguntas del estilo: ¿Qu´e profesor est´as buscando? ¿De qu´e profesor quieres saber la informaci´on? A lo que el usuario como respuesta pueda dar: <Nombre > A<Nombre > Estoy buscando a <Nombre > Quiero la informaci´on de <Nombre > Es obvio que cuantas m´as variaciones aportemos mayor fluidez podr´a tener la interacci´on. Utterances Ahora pasaremos a los utterances propios del intent, para estos hay que tener en cuenta que no solo vamos a acceder directamente al mismo, si no que hay varios caminos para activarlo, por ello vamos a ir generando los intents en funci´on de los modos de acceso. Llamada directa Cuando activamos el intent de manera directa desde Alexa, el usuario realizar´a peticiones como “Alexa pide a Uva Informer la informaci´on de <Nombre >”, de donde extraemos que el utterance ser´a: la informaci´on de <Nombre >. Otras utterances asociadas a la llamada directa podr´ıan ser: datos sobre <Nombre > datos de <Nombre > la informaci´on sobre <Nombre > Arranque de skill Al iniciar la skill sin ejecutar ning´un intent concreto por defecto se ejecuta el LaunchRequest (que veremos m´as adelante en la Secci´on 7.3), esta petici´on corresponde con el texto de bienvenida a la skill, y dicho texto ofrece informaci´on sobre las capacidades de la misma con la siguiente frase: Hola, bienvenido a Uva Informer. Puedo ofrecerte informaci´on sobre profesores u horarios de tutor´ıa. ¿Cu´al te gustar´ıa probar? En base a esta sentencia el usuario podr´ıa responder de las siguientes maneras: informaci´on sobre profesores profesor profesores 7.2. DISE ˜ NO VOCAL 39 Interacci´on con skill iniciada La ´ultima manera de acceder al intent es cuando la skill ya se ha iniciado, y el usuario realiza una petici´on directa sin la necesidad de preguntar primero por el nombre de la skill, esto lleva a que emita comandos como: quiero la informaci´on de <Nombre > dame la informaci´on de <Nombre > Y con esto quedar´ıa cubierto para nuestro prototipo las utterances del primer intent, de la misma manera vamos a ver las del segundo. 7.2.2. Intent 2: Horarios de tutor´ıas Para este intent hemos visto en la secci´on anterior que vamos a necesitar dos tipos de datos, por un lado el nombre del grado, y por el otro el nombre del profesor. Como ambos slots admiten gran cantidad de respuestas y ajust´andonos al tiempo disponible para el desarrollo del proyecto, se ha decidido que ambos slots sean del tipo AMAZON.SearchQuery. Dado que ambos slots son imprescindibles para el correcto funcionamiento de la skill vamos a tener que definir utterances para los mismos como en el intent previo. Para el slot asociado a los grados, realizaremos preguntas como: ¿De qu´e grado necesitas la informaci´on? ¿Para qu´e grado est´as buscando informaci´on? y las respuestas esperadas por parte del usuario ser´an: para el grado en <grado > <grado > de <grado > para <grado > Por otro lado para preguntar por el nombre del profesor realizaremos preguntas como: ¿De qu´e profesor quieres saber el horario? ¿Para qu´e profesor quieres saber la informaci´on? y de nuevo las respuestas del usuario tomar´an la forma: De <Profesor > Para <Profesor > <Profesor > Una vez solucionada la parte correspondiente a los slots vamos a proceder con el intent en s´ı. Dado que necesitamos que ambos intents sean completados, y que hemos marcado la opci´on de slot filling en ambos, no podemos utilizarlos a la vez en las utterances (a parte de que no quedar´ıan muy naturales), por lo que la forma m´as natural de preguntar se ha reducido a usar de manera directa solo el slot de profesor. 40 CAP´ ITULO 7. DESARROLLO Llamada directa el horario de tutor´ıas qu´e horario de tutor´ıas tiene <Profesor > el horario de tutor´ıas de <Profesor > 7.2.3. Arranque de skill Recordemos que al iniciar la skill sin ejecutar ning´un intent Alexa nos contestar´a con: Hola, bienvenido a Uva Informer. Puedo ofrecerte informaci´on sobre profesores u horarios de tutor´ıa. ¿Cu´al te gustar´ıa probar? Por lo que las utterances asociadas a esta pregunta ser´an: tutor´ıas tutor´ıa horarios horario 7.2.4. Interacci´on con skill iniciada dame el horario de tutor´ıas de <Profesor > dame el horario de tutor´ıas quiero el horario de tutor´ıas de <Profesor > quiero el horario de tutor´ıas 7.3. Implementaci´on En esta secci´on se describir´a el proceso de implementaci´on del c´odigo backend que har´a funcionar nuestra skill. El c´odigo backend es el encargado de realizar las acciones asociadas a cada intento para poder proporcionar los datos o acciones solicitados por el usuario en dicho intento. Para ello, podr´a recuperar tambi´en los datos del dominio proporcionados en el intento a trav´es de los slots. La estructura de este c´odigo est´a predefinida por Alexa. Esencialmente, a cada intento se asocia un handler y otros al tratamiento de errores y de inicio y terminaci´on ordenada (ver Secci´on A.2 para m´as detalles en el caso de la aplicaci´on de aprendizaje). En el caso de la skill que estamos desarrollando se han creado una serie de archivos para agrupar distintas funciones en base a su funcionamiento aportando mayor modularidad al desarrollo. 7.3.1. Archivos auxiliares textUtils.js En este archivo se han agrupado todas las funciones que tiene que ver con la manipulaci´on de cadenas de texto y una funci´on para extraer los valores de los slots de el paquete que se recibe del servicio de voz de Alexa (ya que como se puede ver en el Ap´endice B la estructura del paquete es compleja.) 7.3. IMPLEMENTACI ´ ON 41 restApi.js En la primera secci´on de este cap´ıtulo se ha realizado un an´alisis del comportamiento que tendr´a cada intent, y el paso que m´as se ha repetido ha sido la realizaci´on de llamadas GET a distintas direcci´on web, por lo que se ha recogido en un solo archivo (este) todas las funciones que realizan dichas llamadas. subIndex.js Como la programaci´on que estamos realizando es as´ıncrona, podemos generar errores en las respuestas de Alexa si cuando llamamos al servicio de voz no hemos obtenido todav´ıa los datos esperados, esto se puede dar ya que en una ejecuci´on as´ıncrona no se espera a que finalice la ´ultima funci´on ejecutada antes de continuar con la siguiente. Para solucionar esto se ha optado por el uso de las instrucciones async/await y la ejecuci´on secuencial con promesas, de esta manera podremos esperar a tener los resultados antes de realizar la llamada al servicio de voz de Alexa. Dado que cada intent tiene su propia ejecuci´on, para mantener un poco de orden, estructura y limpieza en el c´odigo, se han separado las funciones secuenciales de cada intent en el archivo subIndex.js, que por lo tanto contiene el n´ucleo de ejecuci´on de los intents que hemos desarrollado. 7.3.2. Intent 1: Informaci´on de profesores Comenzamos explicando el funcionamiento de este primer intent por el manejador que se encuentra en fichero index.js Figura 7.12: TeacherHandler: C´odigo del manejador del intent Informaci´on de profesores 48 CAP´ ITULO 7. DESARROLLO en html, podemos identificar estructuras similares de c´odigo, y partir el c´odigo en bloques de dichas estructuras. Con esta idea en mente, la funci´on extractTimeTables primero a´ısla como hemos dicho la secci´on de la tabla referente al profesor, y despu´es extrae el contenido de las celdas respetando la estructura de la tabla, y es el contenido de dichas celdas lo que la funci´on devuelve como resultado. Figura 7.21: extractTimeTables: C´odigo de la funci´on que extrae la informaci´on de horarios de un profesor de la tabla general en formato html Ahora que tenemos la informaci´on de los horarios de tutor´ıas, as´ı como de la ubicaci´on de las mismas, es momento de darle formato para devolver la informaci´on al usuario (l´ıneas 77 a 104). Para ello nos valemos primero de la funci´on timteTableJSON de textUtils.js [Figura 7.22] que nos devuelve en formato json la informaci´on extra´ıda de la tabla en formato html, y despu´es en funci´on de la fecha actual (para comprobar si nos encontramos en el primer o segundo cuatrimestre) componemos la sentencia de respuesta para el usuario. Figura 7.22: timeTableJSON: C´odigo de la funci´on que da formato JSON a la informaci´on de horarios de profesores extra´ıda de la tabla html 7.4. Pruebas La propia plataforma de desarrollo nos permite realizar simulaciones de nuestra skill sin necesidad de contar con un dispositivo con el sistema Alexa. Gracias a esto podemos realizar las pruebas con relativa facilidad ya que no solo admite una entrada de voz, tambi´en nos permite introducir los utterances del usuario por texto, y nos devuelve por el mismo medio su respuesta. Como con la licencia de desarrollo gratuita y basada en lambda no se puede configurar un proceso autom´atico para realizar una bater´ıa de pruebas, estas se han realizado individualmente, comprobando el correcto funcionamiento de ambos intents y la correcta identificaci´on de todos los utterances. Estas pruebas se han realizado con m´ultiples variaciones en la entrada de informaci´on para certificar el correcto funcionamiento del prototipo desarrollado. 7.4. PRUEBAS 49 Una demostraci´on de las pruebas realizadas se puede encontrar en la siguiente carpeta compartida en OneDrive: https://bit.ly/2K8jPWK 50 CAP´ ITULO 7. DESARROLLO Cap´ıtulo 8 Conclusiones y trabajo futuro 8.1. Conclusiones Respecto a los objetivos planteados en un inicio, se puede concluir que todos han sido alcanzados. Se ha estudiado, comprendido y descrito las bases del funcionamiento de los sistemas conversacionales, sirviendo esta memoria como introducci´on a la materia de una manera sencilla. Gracias a los conocimientos adquiridos se ha podido realizar un primer prototipo de sistema conversacional sobre la plataforma Alexa de Amazon, y se ha podido implementar funcionalidad ´util de cara al alumnado de la Universidad de Valladolid, permitiendo consultar informaci´on sobre el profesorado y sobre los horarios de tutor´ıas, de manera que los alumnos puedan acceder f´acilmente a la informaci´on y de una manera intuitiva. 8.2. L´ıneas de trabajo futuro Durante el desarrollo del proyecto se han planteado distintas posibilidades para dotar de funcionalidad al prototipo, por lo que cualquiera de dichas posibilidades descartadas podr´ıa ser una nueva v´ıa de desarrollo. A continuaci´on se van a plantear distintas posibilidades para ampliar la funcionalidad del prototipo, as´ı como anotaciones que se consideran relevantes sobre dichas posibilidades nacidas del estudio ya realizado. Consulta de disponibilidad de libros en las bibliotecas de la Universidad de Valladolid. [Ser´ıa muy conveniente desarrollar un servicio RESTful para poder acceder de manera m´as sencilla a la informaci´on.] Crear en un servidor propio de la Universidad para alojar y ejecutar el backend de la skill.[Las capacidades gratuitas que ofrece Amazon por defecto limitan en gran medida las posibilidades de desarrollo.] Publicar la skill de manera abierta en la tienda de skills de Alexa de manera que cualquiera pueda utilizarla sin necesidad de importarla a su repositorio personal. Ampliar las capacidades de detecci´on de nombre del intent sobre horarios de tutor´ıas, de manera que permita utilizar nombres y apellidos simult´aneamente en la b´usqueda 51 52 CAP´ ITULO 8. CONCLUSIONES Y TRABAJO FUTURO Anexo A Tutorial: Creaci´on de una Alexa Skill Lo primero de todo vamos a necesitar una cuenta de desarrollado para Amazon Developer (https://developer.amazon.com/es/). Con la cuenta ya creada accederemos a la consola de desarrollo de Alexa (https://developer.amazon.com/alexa/console/ask). Dentro encontraremos un listado con las skills que hemos desarrollado, detallando el idioma en el que est´a disponible, la ´ultima fecha de modificaci´on, su estado, y una caja de opciones. Figura A.1: Interfaz principal de la consola de desarrollo de Alexa skills Para crear nuestra primera skill le daremos al bot´on azul de Create Skill situado en la esquina superior derecha del recuadro principal (como se ve en la Figura A.1). Lo primero que debemos decidir es el nombre que tendr´a nuestra skill, que no es lo mismo que el nombre por el que la invocaremos (invocation name). As´ı mismo tambi´en deberemos elegir en que idiomas vamos a desarrollar nuestra skill (ya que dependiendo del idioma podremos realizar unas acciones u otras). El siguiente paso es elegir que tipo de skill queremos desarrollar. En funci´on de nuestro objetivo elegiremos una opci´on u otra, pero ahora mismo vamos a seguir con la opci´on de custom skill, ya que es la menos restrictiva y nos permitir´a explorar m´as. Por ´ultimo vamos a elegir la manera en la que aportaremos el c´odigo backend de nuestra skill, as´ı como el lenguaje de programaci´on en el que la vamos a desarrollar. Amazon nos ofrece por defecto utilizar sus servicios de AWS Lambda, AWS CloudWatch y AWS S3 (c´odigo, log y almacenamiento respectivamente) incluidos en la capa gratuita de AWS, donde podemos elegir realizar el desarrollo en Node.js o Python. Por otro lado podemos aportar nosotros mismos una conexi´on a un servidor distinto a lo ofrecido por Amazon donde tengamos toda la parte de backend, pero para simplificar y agilizar vamos a elegir la opci´on de Node.js 53 54 ANEXO A. TUTORIAL: CREACI ´ ON DE UNA ALEXA SKILL Figura A.2: Selecci´on de nombre e idioma Figura A.3: Selecci´on de tipo de skill A.1. BUILD 55 ofertada por defecto. Figura A.4: Selecci´on de aprovisionamiento de backend Continuamos dando al bot´on azul de Create skill situado en la parte superior derecha de la p´agina. En la siguiente ventana tendremos que elegir si queremos desarrollar nuestra skill desde cero, a partir de una plantilla Figura A.5: Selecci´on de tipo de plantilla para el desarrollo de la skill O si por lo contrario queremos importar una skill desde un repositorio Git, desde la opci´on Import skill que se encuentra en la esquina superior derecha. Vamos a elegir la opci´on empezar desde cero para que no nos genere c´odigo innecesario. Continuamos pulsando el bot´on azul de Continue with template que se encuentra en la esquina superior derecha. Esto har´a que comience el desarrollo de la skill, ya que la plataforma de desarrollo comenzar´a a configurar autom´aticamente los componentes de la plantilla que hayamos seleccionado. A partir de aqu´ı vamos a explicar brevemente que podemos encontrar en las secciones m´as destacadas, ya que la manera de completarlas depende de la skill que se quiera desarrollar. A.1. Build Antes de empezar debemos saber que para aplicar cualquier cambio que hagamos deberemos darle al bot´on de Build Model, de lo contrario aunque hayamos guardado los cambios, estos no tendr´an efecto alguno. Figura A.6: Barra de herramientas del modelo. 56 ANEXO A. TUTORIAL: CREACI ´ ON DE UNA ALEXA SKILL A.1.1. Custom En la pesta˜na de Custom encontraremos una serie de gu´ıas sobre el desarrollo de skills escritas por el equipo de desarrollo de Alexa, tambi´en encontramos un check-list de los pasos necesarios para crear una skill de Alexa. A.1.2. Invocation En este apartado definiremos el nombre por el que la skill es invocada, siguiendo las normas descritas en Subsecci´on 5.2.3 A.1.3. Interaction Model Aqu´ı vamos a interactuar principalmente con el apartado de Intents, ya que el resto de apartados son demasiado avanzados para incluirlos en esta gu´ıa r´apida. Dentro de Intents veremos que contamos con cinco intents predefinidos, de los cuales cuatro son propios del sistema, ya que se encargan de la navegaci´on, cancelaci´on y parada de la skill. El quinto intent es un intent muy simple de ejemplo al m´as puro estilo hola mundo, que es el primer ejemplo que se pone a la hora de aprender un lenguaje de programaci´on. Si entramos dentro del intent HelloWorldIntent (Figura A.7) veremos que tenemos una serie de utterances ya definidas, estas frases son las que la skill espera que el usuario vocalice para ejecutar el intent. Figura A.7: Pantalla de desarrollo de HelloWorldIntent Tambi´en podemos observar que para este intent en concreto no contamos con ning´un slot definido, ya que no esperamos que ninguna de las utterances pueda aportar un dato relevante m´as all´a de la propia sentencia. A.2. CODE 57 A.1.4. Assets Dentro de esta pesta˜na es donde veremos los slots que hemos definido, como habl´abamos en la Subsecci´on 5.2.5, vamos a crear a modo de ejemplo un slot para los pa´ıses de una agencia de viajes. Para ello tenemos dos posibilidades, como podemos ver en la Figura A.8, podemos crear nuestro slot desde cero, o elegir uno predefinido de Alexa. Figura A.8: Pantalla de creaci´on de un slot Vamos a crear nuestro propio slot y lo llamaremos pa´ıses, como se puede ver en la Figura A.9 hemos definido dentro de nuestro slot dos pa´ıses, Francia e Italia, a los que tambi´en hemos asociado un ID, de esta manera cuando utilicemos nuestro slot en un intent, a nivel de c´odigo podremos utilizar el ID asociado. Figura A.9: Pantalla de definici´on de un slot A.2. Code Al igual que pasaba con Build, en code tenemos que comentar las opciones de guardado y despliegue antes de comenzar, para dejar muy claro que aunque guardemos los cambios en el c´odigo, si no lo desplegamos (bot´on deploy), estos no surtir´an efecto en la skill. Para comenzar vamos a hablar sobre los archivos que vienen por defecto con la skill 64 ANEXO B. TUTORIAL: AMPLIACI ´ ON DE LA SKILL qu´e rutas hay desde {origen}a{destino}el {fecha} De nuevo existen m´as variaciones de pregunta, pero no nos vamos a extender aqu´ı en ello. Con esto quedar´ıa cerrada la parte vocal de nuestro nuevo intent, as´ı que lo guardamos y lo compilamos. B.2. C´odigo A continuaci´on vamos a generar el c´odigo que lo har´a funcionar, pero no vamos a contemplar todo el funcionamiento, desarrollaremos a modo de ejemplo la respuesta para algunas utterances del intent y se deja el desarrollo del resto como trabajo personal para comprobar si se ha entendido la explicaci´on. Como el funcionamiento del c´odigo que Alexa nos ofrece por defecto en lambda ya se ha explicado en Ap´endice A, por lo que avanzaremos relativamente r´apido por esta secci´on. Lo primero que debemos hacer es crear el manejador de nuestro intent en el archivo index.js, para ello podemos tomar como ejemplo el manejador el intent Hello World, y sustituir el nombre del manejador y del intent que espera lo que resultar´ıa en un c´odigo similar al de la Figura B.4 Lo siguiente ser´a extraer los slots del paquete que recibimos de Alexa handlerInput, Este paquete contiene mucha informaci´on que para nosotros ahora mismo no es relevante, por lo que vamos a acotar el contenido del mismo creando una nueva variable llamada me y almacenando en esta el objeto handlerInput.requestEnvelope.request, el contenido de este objeto tiene una estructura similar a la de la Figura B.3. Esta estructura de ejemplo corresponde a un utterance que ha aportado informaci´on para los tres slots de los que disponemos, y para los slots de origen y destino se confirma que la informaci´on coincide con alguno de los valores que hemos definido anteriormente. Suponiendo que este esta es la petici´on que recibimos lo siguiente que deber´ıamos hacer es extraer el pa´ıs de origen y el de destino, as´ı como la fecha, para ello crearemos nuevas variables (origen, destino y fecha respectivamente) de forma que el c´odigo quedar´ıa como se ve en la Figura B.5 Ahora que ya tenemos los datos, podemos manejarlos como queramos, en este ejemplo que hemos desarrollado vamos a realizar un simple if-else que de como resultado que existen viajes de Francia a Italia los lunes y martes, y de Italia a Francia los jueves y viernes, y lo plasmamos en una cadena de texto que ser´a la que posteriormente enviemos a la interfaz de voz. El c´odigo resultante se puede ver en la Figura B.6 Por ´ultimo preparamos el paquete de respuesta y lo enviamos como se puede ver en la Figura B.7 Recordemos que hay que incluir el nombre de la funci´on en el manejador de exportaciones que se encuentra al final del archivo. Todo el c´odigo de la skill se puede encontrar en el siguiente repositorio: https://github. com/lvareo/AmpliacionHolaMundo.git B.2. C ´ ODIGO 65 Figura B.3: Estructura de las peticiones recibidas desde Alexa Figura B.4: Primera parte del c´odigo del manejador del intent Viajes Figura B.5: Segunda parte del c´odigo del manejador del intent Viajes 66 ANEXO B. TUTORIAL: AMPLIACI ´ ON DE LA SKILL Figura B.6: Tercera parte del c´odigo del manejador del intent Viajes Figura B.7: Cuarta parte del c´odigo del manejador del intent Viajes Bibliograf´ıa [1] Michael F McTear. Spoken dialogue technology: enabling the conversational user interface. ACM Computing Surveys (CSUR), 34(1):90–169, 2002. [2] Joseph Weizenbaum. Eliza—a computer program for the study of natural language communication between man and machine. Commun. ACM, 9(1):36–45, January 1966. [3] Jeremy Peckham. Speech understanding and dialogue over the telephone: an overview of the esprit sundial project. In Speech and Natural Language: Proceedings of a Workshop Held at Pacific Grove, California, February 19-22, 1991, 1991. [4] Stephanie Seneff. Robust parsing for spoken language systems. In icassp, pages 189–192. IEEE, 1992. [5] Daniel Jurafsky and James H. Martin. Speech and Language Processing. Draft available at https://web.stanford.edu/~jurafsky/slp3/, 2019. [6] Alan Ritter, Sam Clark, Oren Etzioni, et al. Named entity recognition in tweets: an experimental study. In Proceedings of the 2011 conference on empirical methods in natural language processing, pages 1524–1534, 2011. [7] Lifeng Shang, Zhengdong Lu, and Hang Li. Neural responding machine for short-text conversation. arXiv preprint arXiv:1503.02364, 2015. [8] Amazon alexa. https://developer.amazon.com/es-ES/alexa, Visitado por ´ultima vez el 12/11/2020. [9] Asistente de google. https://assistant.google.com/intl/es_es/, Visitado por ´ultima vez el 12/11/2020. [10] Microsoft cortana. https://www.microsoft.com/en-us/cortana, Visitado por ´ultima vez el 12/11/2020. [11] Siri. https://www.apple.com/siri/, Visitado por ´ultima vez el 12/11/2020. [12] Google duplex llega a espa˜na. https://bit.ly/2GWFS1c, Visitado por ´ultima vez el 12/11/2020. [13] Windows 10 mobile wikipedia. https://en.wikipedia.org/wiki/Windows_10_ Mobile, Visitado por ´ultima vez el 12/11/2020. [14] Daniel G Bobrow, Ronald M Kaplan, Martin Kay, Donald A Norman, Henry Thompson, and Terry Winograd. Gus, a frame-driven dialog system. Artificial intelligence, 8(2):155– 173, 1977. [15] D. Gibbon, R. Moore, and R. Winski. Handbook of Standards and Resources for Spoken Language Systems. Mouton de Gruyter, 1997. 67 68 BIBLIOGRAF´ IA [16] Alan Ritter, Colin Cherry, and William B Dolan. Data-driven response generation in social media. In Proceedings of the 2011 Conference on Empirical Methods in Natural Language Processing, pages 583–593, 2011. [17] Ram´on L´opez-C´ozar, Zoraida Callejas, David Griol, and Jose Quesada. Review of spoken dialogue systems. Loquens, 1:e012, 02 2015. [18] Jiwei Li, Michel Galley, Chris Brockett, Georgios P Spithourakis, Jianfeng Gao, and Bill Dolan. A persona-based neural conversation model. arXiv preprint arXiv:1603.06155, 2016. [19] Jiwei Li, Will Monroe, and Dan Jurafsky. A simple, fast diverse decoding algorithm for neural generation. arXiv preprint arXiv:1611.08562, 2016. [20] Sending email using amazon ses. https://docs.aws.amazon.com/ sdk-for-javascript/v2/developer-guide/ses-examples-sending-email. html,Visitado por ´ultima vez el 12/11/2020. [21] Sam Agnew. 5 ways to make http requests in node.js. https://www.twilio.com/blog/ 2017/08/http-requests-in-node-js.html,Visitado por ´ultima vez el 12/11/2020. [22] Nick Carneiro. Curl converter. https://curl.trillworks.com/,Visitado por ´ultima vez el 12/11/2020. [23] Matthew B. Hoy. Alexa, siri, cortana, and more: An introduction to voice assistants. Medical Reference Services Quarterly, 37(1):81–88, 2018. PMID: 29327988. [24] Cortana wikipedia. https://en.wikipedia.org/wiki/Cortana, Visitado por ´ultima vez el 12/11/2020.