Logo Studenta

Odiseo_cuando_crear_un_chatbot_es_cosa_de_ninos_Verdu_Verdu_Jonathan

¡Este material tiene más páginas!

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

Continuar navegando