Embed Size (px)
Citation preview
ÍNDICE DE CONTENIDOS
1. Introducción y justificación del proyecto…………………………. 2
2. Objetivos………………………………………………………………... 4
3. Metodología…………………………………………………………….. 5
4. Herramientas y tecnologías………………………………………... 10
5. Estado de la cuestión……………………………………………….. 21
6. Arquitectura del sistema……………………………………………. 25
7. Experimentación……………………………………………………... 34
8. Conclusiones…………………………………………………………. 41
Referencias………………………………………………………………..43
Anexo I……………………………………………………………………..44
Anexo II…………………………………………………………………….44
1
1. Introducción y justificación del proyecto En muchas páginas web y aplicaciones los usuarios pueden realizar preguntas
sobre dudas a los encargados de éstas, lo cual puede resultar en muchos
usuarios enviando las mismas preguntas. Debido a esto se crearon los FAQ
(Frequently Asked Questions), conjuntos de las preguntas más comunes, de
forma que los usuarios no tuvieran que preguntar lo mismo una y otra vez, sino
simplemente buscar dicha pregunta en el apartado de FAQ.
Ahora bien, con esto los usuarios deben navegar de manera manual a través de
los FAQ para encontrar la pregunta deseada o alguna que se asemeje, lo cual es
un gasto de tiempo que puede no gustar a mucha gente. Por este motivo lo que
se plantea en este proyecto es el desarrollo de un sistema de búsqueda de
respuestas o sistema QA (Question-Answering system), un sistema de
recuperación de información que para una consulta del usuario en lenguaje
natural, localice automáticamente la o las preguntas del FAQ más similares y
ofrecerle la respuesta.
Para desarrollar un sistema de recuperación de información debemos usar
tecnologías de Procesamiento de Lenguaje Natural (PLN) para poder comparar
las preguntas introducidas por el usuario con aquellas que tenemos en el FAQ,
debido a que la gran mayoría de veces no estarán escritas exactamente igual.
Esto se debe a que, por ejemplo, una misma pregunta se puede reformular de
muchas formas distintas queriendo decir lo mismo, por lo que no basta con
comparar si la pregunta realizada es igual a alguna de las que tenemos en el
FAQ.
Para aclarar más, PLN es un campo de la informática, inteligencia artificial y
lingüística que estudia las interacciones entre los ordenadores y el lenguaje
humano. Se ocupa de investigar y diseñar mecanismos para la comunicación
entre personas y máquinas por medio de lenguajes naturales y que se puedan
realizar por medio de programas que simulen la comunicación.
2
A la hora de trabajar con lenguaje natural surgen varios problemas:
● Ambigüedad: una misma palabra puede tener varios significados y la
selección del correcto se debe deducir a partir del contexto de la oración.
Además, una oración puede no significar lo que realmente se está diciendo.
● Detección de separación entre las palabras
● El uso de sinónimos
● Recepción imperfecta de datos: acentos extranjeros, errores de escritura,
error en la lectura de textos mediante OCR...
Hoy en día se emplean estos sistemas de recuperación de información en muchos
lugares, aunque no sea para obtener la respuesta a una pregunta que se
encuentra en un FAQ. Buenos ejemplos son los motores de búsqueda como
Google o Bing, a los cuales realizamos una consulta y nos devuelven una serie de
webs como resultado que tienen relación con nuestra consulta.
Una vez explicado, esto es lo que se va a desarrollar: un sistema de recuperación
de información para tratar conjuntos de preguntas frecuentes aplicando
tecnologías de Procesamiento de Lenguaje Natural (PLN), además de un chatbot
como interfaz para facilitar la usabilidad del sistema.
3
2. Objetivos El objetivo principal es desarrollar un sistema de búsqueda de respuestas sobre
conjuntos de preguntas frecuentes con un chatbot que sirva como interfaz para su
uso. Para conseguir este objetivo es necesario completar los siguientes objetivos
parciales:
● Conocer los elementos fundamentales y el funcionamiento de los sistemas
de Recuperación de Información
● Estudiar el funcionamiento de Lucene como herramienta para el desarrollo
de sistemas de Recuperación de Información
● Definir una medida de ponderación que valore la similitud entre la consulta
del usuario y la lista de preguntas objetivo
● Desarrollar un Chatbot que sirva de interfaz con el sistema desarrollado
● Evaluar el rendimiento del sistema creado
4
3. Metodología En muchas ocasiones en la carrera nos repiten la importancia de trabajar en
equipo, de ahí las asignaturas donde nos enseñan metodologías ágiles como
Scrum para evitar problemas entre los miembros, ya que es lo que nos deparan
los futuros trabajos. Por ello, aunque no he empleado ninguna metodología en
concreto, si he trabajado con una propia para llevar una organización correcta ya
que sólo soy un miembro.
Lo primero de todo fue crear un tablero en Trello para ir apuntando todas las
tareas que tenía que hacer y poder organizarme correctamente. El tablero está
formado por 4 columnas o listas:
● Backlog (Mejoras): en esta columna tenemos tareas futuras que servirían
para mejorar el programa.
● Pendientes: tareas a realizar que aún no han sido empezadas.
● En marcha: tareas que están siendo realizadas ahora mismo.
● Completado: tareas que han sido completadas.
Figura 1. Captura del tablero de Trello
Además se ha empleado Git desde Github como sistema de control de versiones
para llevar un control de los cambios que se han ido realizando al programa. Tan
5
solo he tratado con 2 ramas: una rama de desarrollo que va cambiando de
nombre, donde subo los pequeños cambios que voy haciendo, y “master”, donde
se mergea la rama de desarrollo (la cual desaparece) cuando ha habido un
cambio importante y funciona correctamente.
Por lo que respecta al programa, el primer paso a realizar para el desarrollo del
proyecto es estudiar el funcionamiento de los sistemas de búsqueda de
respuestas. Gracias a este estudio comprendí que:
● La información en un FAQ está organizada en formato pregunta/respuesta.
● Todos los datos necesarios se encuentran en el par pregunta/respuesta.
● Para obtener un tiempo de respuesta aceptable es necesario realizar una
indexación offline del conjunto de documentos, y de esta manera se evita el
procesar en tiempo real cada uno de los documentos en busca de los datos
deseados.
Más adelante buscamos librerías de motor de búsqueda e indexación y dimos con
Apache Lucene, originalmente escrita en Java. Tuve que estudiar el
funcionamiento de Lucene ya que no lo había usado nunca antes, y empecé a
desarrollar una primera versión simple de un sistema de búsqueda de respuestas:
indexar un archivo con varias palabras en su interior con solo un campo de
información, sobre el cual se realizaría la búsqueda de una palabra exacta.
Además, sobre el campo se aplicaba una tokenización para dividir el texto por los
espacios (aunque de momento sólo era una palabra), se eliminaban los signos de
puntuación y se pasaba el texto a minúsculas, todo para mejorar la futura
búsqueda.
Tras esta primera versión se pensó en la manera correcta de organizar el
contenido de los archivos de FAQ de forma definitiva: un archivo JSON por cada
pregunta/respuesta. Esta opción no duró mucho, ya que había que abrir y cerrar
muchos archivos y no era eficiente, así que finalmente se decidió que un archivo
JSON fuera un FAQ con muchos pares pregunta/respuesta en su interior. Esto
6
llevó a la modificación de los documentos del índice: ahora tienen los campos
pregunta, respuesta.
Con estos nuevos FAQ noté un problema, cada vez que ejecutaba el programa e
indexaba, se volvían a indexar los FAQ aunque ya lo estuvieran, por lo que el
índice no paraba de crecer y ocupar espacio tontamente. La solución fue añadir
un campo nuevo en los documentos del índice con el nombre del archivo FAQ. De
esta manera antes de indexar el contenido de un archivo realizamos una
búsqueda con el campo del nombre del archivo, y si hay resultados (lo que
significa que ese archivo ya está indexado porque ha encontrado coincidencias)
ese archivo no se indexará.
Después hubo que buscar la manera de hacer búsquedas con varias palabras y
se encontró la clase de Lucene PhraseQuery, pero no era lo que se buscaba, ya
que con faltar 1 palabra de la consulta del usuario, el programa daba a la
pregunta del índice una puntuación de 0 y no la devolvía, y esto pasa casi
siempre ya que es difícil que el usuario escriba palabras y que todas estén en el
campo de la consulta.
Encontré la clase de Lucene FuzzyQuery que sirve para buscar sólo una
palabra, pero hace una búsqueda aproximada, la palabra no tiene porque ser
exacta, por lo que hay más posibilidades de que encuentre una pregunta que
contenga esa palabra o similares. En concreto la medida de similitud que emplea
está basada en el algoritmo Damerau-Levenshtein (alineamiento óptimo del string)
mediante el cual se tiene en cuenta la distancia de edición de las 2 cadenas a
comparar: esto significa que las 2 palabras comparadas pueden tener algunos
caracteres diferentes, ya sea por borrado, sustitución o añadido. La cantidad de
ediciones por defecto y más útil es de 2 diferencias, ya que una diferencia mayor
supondría cambiar mucho la palabra y daría resultados no muy correctos.
Encontré una forma de hacer FuzzyQuery sobre cada palabra de una frase, y
además no tenían porque aparecer todas en el texto del documento, que es lo
7
que estaba buscando. De esta forma la búsqueda mejoró considerablemente,
pues palabras como “casa” y “casas” serían devueltas ambas en la consulta de la
palabra “casa”, además de poder hacer esto con varias palabras, todas las de la
consulta.
Tras tener una versión que funcionaba bien, se empezó la creación del bot de
Telegram, y para ello tuve que estudiar cómo funciona la API de Telegram Bots.
La primera versión del bot recibía un mensaje de texto y devolvía todas las
respuestas encontradas (hasta un máximo de 10) cada una en un mensaje, por lo
que teníamos un chat lleno de texto dejando un aspecto visual muy cargado. Se
pensó en la manera de mostrar sólo la respuesta con más puntuación y después
de alguna manera mostrar de una en una las siguientes. Esto concluyó en el
envío de la primera respuesta y el almacenamiento en base de datos del resto de
respuestas devueltas por la consulta, y si el usuario escribe algo en concreto
(“/siguiente”) cogerá la siguiente respuesta de la base de datos y la devolverá.
El siguiente paso fue volver al sistema de recuperación de información y añadir
más filtros para procesar el texto a indexar y el texto de la consulta, a ambos se
les aplicarán los mismos.
El primero de todos fue añadir un filtro para la eliminación de palabras de paso o
stop words, que son palabras muy comunes que aparecen en casi todas las
consultas, palabras como artículos, preposiciones… Esto mejoró el sistema aún
más, se obtenían resultados mejores ya que esas palabras hacían variar la
puntuación de forma negativa, no son palabras que ayuden a distinguir la
pregunta correcta.
Después se incluyó el filtro de “stemming”, que procesa cada palabra y le quita
letras para dejarla en su palabra raíz. Al incluir este filtro se decidió hacer la
búsqueda sin query, por palabra exacta, y dio buenos resultados.
8
Tras algún pequeño cambio más se obtuvo la versión final del sistema de
recuperación de información que se explica en el punto “6. Arquitectura del
sistema”.
Por último, se llevaron a cabo pruebas con diferentes combinaciones de filtros y
búsquedas para ver cual obtenía mejores resultados. Desarrollado en el punto “7.
Experimentación”.
9
4. Herramientas y tecnologías Java
Como lenguaje de programación se ha empleado Java en todo el proyecto, el 1
cual es un lenguaje de programación de propósito general, concurrente, orientado
a objetos, que fue diseñado específicamente para tener tan pocas dependencias
de implementación como fuera posible. Su intención es permitir que los
desarrolladores de aplicaciones escriban el programa una vez y lo ejecuten en
cualquier dispositivo, lo que quiere decir que el código que es ejecutado en una
plataforma no tiene que ser recompilado para correr en otra. Java es, a partir de
2012, uno de los lenguajes de programación más populares en uso,
particularmente para aplicaciones de cliente-servidor de web, con unos diez
millones de usuarios reportados.
Su sintaxis deriva en gran medida de C y C++, pero tiene menos utilidades de
bajo nivel que cualquiera de ellos. Las aplicaciones de Java son compiladas a
bytecode (clase Java), que puede ejecutarse en cualquier máquina virtual Java
(JVM) sin importar la arquitectura del ordenador.
1 https://www.java.com/es/
10
MySQL
MySQL es un sistema de gestión de base de datos relacional de código abierto 2
basado en lenguaje de consulta estructurado (SQL), y es empleado en grandes
organizaciones como Google, Facebook, Twitter y Youtube.
Es bastante usado porque soporta gran cantidad de datos, es seguro y fácil de
usar. Otras características importantes son que está disponible en gran cantidad
de plataformas y sistemas o que permite replicar la base de datos.
MySQL es una base de datos muy rápida en lectura, lo que es ideal para
aplicaciones web porque el entorno es intensivo en lectura. Su popularidad como
aplicación web está muy ligada a PHP , que a menudo aparece en combinación 3
con MySQL.
Se ha elegido MySQL porque es una base de datos relacional y necesitamos
relacionar varias tablas entre ellas, además de ser el sistema de gestión de base
de datos que más hemos usado y estudiado a lo largo de la carrera.
2 https://www.mysql.com/ 3 http://www.php.net/
11
Telegram Bot API
Telegram es una aplicación de mensajería que permite enviar y recibir mensajes 4
de texto y multimedia como imágenes, vídeos, o mensajes de audio. Se puede
decir que Telegram es el competidor directo de WhatsApp , la app de mensajes 5
más conocida en todo el mundo, pues cuando salió parecía una copia directa de
éste. Ahora bien, a lo largo de los años Telegram ha ido evolucionando e
incluyendo funciones nuevas como stickers (son como emoticonos más grandes)
y gifs animados, funciones que más adelante WhatsApp ha integrado o están en
proceso.
Una de estas funciones que sólo tiene Telegram son los bots: aplicaciones de
terceros que se ejecutan dentro de Telegram y con las que el usuario puede
interactuar enviando mensajes y comandos. Los creadores controlan a los bots
haciendo peticiones HTTPS a la API de bots de Telegram (Telegram Bot Api ), 6
que es lo que hemos empleado para realizar el bot de nuestro proyecto.
4 https://web.telegram.org/ 5 https://www.whatsapp.com/?lang=es 6 https://core.telegram.org/bots/api
12
Git
Git es el sistema de control de versiones (SCV) más conocido y utilizado en todo 7
el mundo, incluso el grupo de programación del núcleo Linux usa Git para llevar el
control del proyecto.
Fue diseñado por Linus Torvalds pensando en la eficiencia y la confiabilidad del
mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número
de archivos de código fuente. Su propósito es llevar el registro de los cambios en
archivos y coordinar el trabajo que varias personas realizan sobre archivos
compartidos.
Se ha elegido Git como SCV porque a parte de ser el que más se ha empleado y
estudiado a lo largo de la carrera, es distribuido. Esto permite tener un repositorio
central compartido por el equipo de desarrollo, y después cada uno tiene una
copia local completa de este repositorio, lo que significa que no tenemos que
comunicarnos con el servidor hasta que debamos compartir cambios con otro
miembro del equipo, lo que lo hace rápido de usar. Además cada copia local
funciona como una copia de seguridad del repositorio central, por lo que
cualquiera podría volver a subirlo al servidor central en caso de algún problema.
7 https://git-scm.com/
13
Trello
Trello es un software de administración de proyectos con interfaz web. Se trata 8
de una plataforma en la nube que simula un tablero Kanban , por lo que 9
disponemos de un sistema de tarjetas que serán tareas a realizar en el proyecto.
Un tablero Kanban es una herramienta que te ayuda a visualizar el flujo de trabajo
para cualquier proyecto. Proporciona un alto nivel de transparencia, permitiendo a
todo el mundo comprender el estado de un proyecto con un solo vistazo. Está
formado por un sistema de tarjetas que pueden ser colocadas en columnas, que
son listas de tarjetas relacionadas entre ellas, como por ejemplo la columna “En
desarrollo” donde colocamos las tarjetas de las tareas que estén siendo
desarrolladas actualmente.
A las tarjetas se les pueden incluir archivos relacionados, indicar qué miembro del
equipo es el encargado, una prioridad e incluso subtareas.
Aunque no era tan necesario el uso de una herramienta de gestión de proyectos
porque el proyecto consta de una persona, ha ayudado a tener en un sitio todas
las tareas a realizar y tener una mejor visión de lo que falta y lo que está hecho.
Apache Lucene
Lucene es la parte más importante de este proyecto, pues es una librería de 10
motor de búsqueda e indexación de texto de alto rendimiento escrito en Java.
8 https://trello.com/ 9 https://kanbantool.com/es/ejemplos-de-tableros-kanban 10 http://lucene.apache.org/
14
También existen varios “ports” de la librería original de Java a otros lenguajes.
Nosotros usamos Apache Lucene Core, la librería original para Java.
Al ser la base del proyecto se va a explicar su funcionamiento con más detalle
para más adelante poder entender la arquitectura del sistema.
Existen una serie de conceptos asociados a Lucene como “documento” o “campo”
que es importante conocer para entender cómo funciona. En la siguiente tabla se
describen los más importantes:
Glosario de Lucene
Término Definición
Document
(documento)
Objeto de resultado de búsqueda retornable. Un documento
suele representar, por ejemplo: un archivo de un sistema de
archivos, la fila de una consulta a una base de datos o como en
nuestro caso, uno de los elementos de la lista que contiene un
archivo JSON.
Index (índice) Conjunto de documentos donde se realizan las búsquedas.
Field (campo) Propiedad, elemento de metadatos o atributo de un documento.
El nombre del campo puede ser el que sea. Ejemplo: título,
cuerpo...
Term (Término
o palabra)
Texto sobre el que se realiza la búsqueda, extraído de cada
campo indexado por medio de análisis (proceso de
tokenización y filtrado).
Query
(consulta)
Texto que el usuario quiere buscar, el que es comparado con
los documentos del índice y ver si coinciden
tf (term
frequency o
La cantidad de veces que una palabra aparece en cada
documento.
15
frecuencia de
término)
idf (inverse
document
frequency o
frecuencia
inversa de
documentos)
Factor que aumenta la importancia de palabras con poco term
frequency, a la vez que disminuye la de palabras que aparecen
mucho. Las palabras que aparecen menos veces son más
importantes para distinguir las búsquedas.
Índices
Lucene provee APIs para crear, abrir, leer, escribir y buscar un índice. Los
documentos contienen campos, que son los atributos de un documento que se
usan para realizar las búsquedas. Estos campos o “fields” pueden ser:
● Almacenados: almacena el texto sin más, no se analizará en las búsquedas
aunque se devolverá en los resultados. Suele servir para tener información
extra sobre los campos indexados.
● Indexados: el texto será analizado, por lo que las diferentes partes (suelen
ser las palabras) del texto van a poder ser analizadas por individual en las
búsquedas. Estos campos no son devueltos en los resultados de las
búsquedas.
● Combinación de ambos: un texto puede ser tanto indexado como
almacenado, en cuyo caso además de ser analizado, el contenido original
será devuelto en el resultado de las búsquedas.
El análisis de los campos indexados consiste en un proceso de tokenización y
filtrado de texto de los términos incluidos en el campo. Normalmente también se
incluyen procesos de normalización como la conversión a minúsculas. Además,
los tokens o palabras de los campos indexados almacenan bits adicionales de
metadatos para saber su posición respecto a la palabra anterior o su posición en
el campo. La información generada por el análisis sólo servirá para la posterior
16
búsqueda sobre ella y no será devuelta en el resultado, ya que en el resultado
sólo se devuelve el contenido original (sin analizar) de los campos que han sido
almacenados.
Algo muy importante para la búsqueda de Lucene es la estructura del índice, ya
que emplea un índice inverso. En este tipo de índice se mapean los términos o
palabras con los documentos donde aparecen, es decir, saber cuántas
ocurrencias hay de cada término además de en qué documentos aparecen. Con
el índice inverso se acelera el proceso de búsqueda cuando el usuario hace una
consulta, ya que se sabe los documentos que contienen esos términos desde el
principio y se descartan el resto.
En la Figura 1 podemos ver un ejemplo de un índice inverso: en la tabla de la
izquierda tenemos los textos (Text) con sus identificadores (ID), y a la derecha
nos encontramos con una tabla que es el índice inverso en la cual se puede ver
que cada palabra de los textos (Term) se ha colocado en una fila. Fijémonos en la
primera fila que tiene la palabra “baseball”, vemos que hay 2 columnas extras con
información de esa palabra:
● “Freq”: número total de veces que la palabra “baseball” aparece en todos
los textos de la tabla de la izquierda.
● “Document ids”: una lista con los identificadores de los textos donde
aparece la palabra “baseball” al menos una vez.
17
Figura 2. Ejemplo de índice inverso
Puntuación
A la hora de la búsqueda, los documentos son comparados con una consulta y
son calificados con una puntuación. El resultado de la búsqueda será un conjunto
de documentos que tienen alguna coincidencia, es decir, una puntuación mayor
de 0, ordenados por puntuación (a mayor puntuación mayor coincidencia).
Por defecto Lucene emplea la función de ranking Okapi BM25 para calcular las 11
puntuaciones de los documentos. Esta función emplea la técnica de “Bag of
words”, técnica consistente en considerar toda la consulta como una lista de
palabras sueltas que directamente se introducen en el recuperador de información
sin contemplar ningún tipo de extensión ni orden de importancia entre ellas, pero
sí que se tiene en cuenta la multiplicidad de cada palabra, la cantidad de veces
que aparece en el documento (cuántas más veces está más puntuación obtiene el
documento). Además también tiene en cuenta la rareza de palabras que aparecen
menos a lo largo de los documentos y les da algo más de puntuación, y da algo
más de puntuación a las coincidencias en documentos más cortos. La función
empleada por BM25 es la siguiente: dada una consulta Q que contiene las
palabras q1,....,qn la puntuación BM25 de un documento D es
11 https://es.wikipedia.org/wiki/Okapi_BM25
18
donde f(qi, D) es la frecuencia del término qi en el documento D, |D| es la longitud
del documento D en palabras, y avgdl es la media de longitud de los documentos
de la colección. k1 y b son parámetros libres que normalmente, en ausencia de
una optimización avanzada, tienen los valores por defecto entre 1.2 y 2, y 0.75
respectivamente. IDF(qi) es el peso de la frecuencia inversa del documento o IDF
(Inverse Document Frequency) del término de la consulta qi. El IDF da más peso a
aquellos términos que aparecen en menos documentos. Es decir, si un término
aparece en todos los documentos, tiene poco valor discriminatorio y por lo tanto
su IDF es bajo. Esta es su fórmula, donde N es el número total de documentos en
la colección y n(qi) el número de documentos que contienen la palabra qi:
Existen varias medidas de puntuación más, pero en este proyecto vamos a usar
Okapi BM25 y TFIDF (Term Frequency-Inverse Document Frequency). TFIDF es
algo más sencilla de entender y su fórmula es la siguiente:
Donde
● tf(t in d) es la frecuencia del término, definido como el número de veces que
el término t aparece en el documento d. Los documentos con más
ocurrencias de un término dado reciben mayor puntuación.
19
● idf(t) es la frecuencia inversa del documento. Este valor es el inverso del
número de documentos en los que aparece el término t, lo que implica que
términos más raros recibirán más puntuación.
● t.getBoost() se aplica en el tiempo de búsqueda y es un aumento del
término t en la consulta q. Esto significa que cuánto mayor sea mayor
relevancia va a tener la palabra, es decir, más puntuación recibe.
● norm(t,d) es un aumento en tiempo de indexación que depende
únicamente de la cantidad de términos del campo en el documento, lo que
quiere decir que campos más cortos contribuyen más a la puntuación.
20
5. Estado de la cuestión Los sistemas de recuperación de información (SRI) están presentes en muchos
lugares hoy en día. Estos sistemas reciben una consulta y devuelven una serie de
resultados relacionados con dicha consulta, y un claro ejemplo de ello son
buscadores como Google, el cual recibe un texto y devuelve una serie de webs
relacionadas.
Dentro de los sistemas de recuperación de información encontramos un tipo de
sistemas más concreto, el sistema de búsqueda de respuestas o QA
(Question-Answering). Este sistema funciona como un SRI, aunque en lugar de
devolver resultados dados o delimitados, extrae la respuesta concreta de dentro
de un texto y nos la devuelve. Por ejemplo: si consultamos “¿Cuándo nació
Steven Spielberg?”, un SRI nos devolvería una página web, archivo, etc. donde
dentro se encuentra la respuesta, mientras que un sistema de búsqueda de
respuestas nos devolvería directamente “Nació el 18 de diciembre de 1946”.
Algunos ejemplos de sistemas QA pueden ser los asistentes virtuales como
Google Assistant , Cortana y Siri . Aquí un ejemplo de lo que devuelve Cortana 12 13 14
al preguntarle el tiempo de mañana:
12 https://assistant.google.com/intl/es_es/ 13 https://www.microsoft.com/es-es/windows/cortana 14 https://www.apple.com/es/ios/siri/
21
Figura 3. Ejemplo de funcionamiento de Cortana
Esos asistentes virtuales son chatbots, programas informáticos con los que es
posible mantener una conversación, tanto si queremos pedirle algún tipo de
información o que lleve a cabo una acción. Los chatbots están cada vez más
presentes hoy en día debido a los avances tecnológicos en Inteligencia Artificial
(IA) para intentar simular conversaciones con una persona real.
Por lo que respecta a los FAQs, prácticamente todas las páginas web cuentan con
una para ayudar a los usuarios a utilizarla y resolver sus problemas. Algunos
ejemplos son Carrefour, el Corte Inglés o la Universidad de Alicante:
Figura 4. Preguntas frecuentes de la página de Carrefour
22
Figura 5. Preguntas frecuentes de la página de El Corte Inglés
Figura 6. Preguntas frecuentes de la página de la UA
Este proyecto no es un sistema QA a pesar de que obtiene respuestas, sino que
se trata de un sistema de recuperación de información sobre FAQs, pues
recupera una respuesta dada de un conjunto, no extrae la respuesta de un texto.
Existe un sistema similar a lo que será nuestro proyecto, FaqFinder, un sistema
de recuperación de información que usa archivos de preguntas frecuentes como
su base de conocimiento y que devuelve las respuestas existentes en esos
archivos en lugar de generar nuevas respuestas.
Las diferencias entre FaqFinder y nuestra proyecto es que nuestro proyecto:
● Tiene una implementación ajustada al castellano (FaqFinder es para inglés)
● Puede adaptarse fácilmente a distintos conjuntos de FAQs
23
● Se ha integrado con un chatbot para facilitar la interacción de los usuarios
con él
24
6. Arquitectura del sistema
Figura 7. Esquema de la arquitectura de nuestro sistema
En la imagen superior podemos ver la arquitectura del sistema de recuperación de
información con un chatbot de Telegram como interfaz para su uso.
Al iniciar el Sistema de Recuperación de Información se crea nuestro bot de
Telegram y se registra en la API para poder hacer uso de él. Además, se accede
al sistema de archivos para obtener la información de los archivos FAQ y crear el
índice donde estará toda la información de las preguntas y respuestas.
Los usuarios iniciarán un chat con nuestro chatbot llamado @FAQtfg_bot, con lo
que podrán enviar mensajes por el chat, los cuales irán al servidor de la API de
Telegram por medio de HTTPS. ¿Cómo recibe los mensajes el Sistema de
Recuperación de Información (SRI)? Emplea un sistema de Long Polling hacia la
API por medio del cual le hace una petición de nueva información, petición que la
25
API mantiene en espera hasta que tiene nueva información disponible para
enviarle. Cuando la API recibe información, es decir, un usuario ha enviado algún
mensaje, la manda al SRI que se encarga de procesar el mensaje.
Cuando el SRI recibe una consulta, busca en el índice (donde se han guardado ya
las FAQs sobre las que queremos buscar) las consultas más similares aplicando
la medida de ponderación Okapi BM25, comentada anteriormente en el punto de
“Herramientas y tecnologías”, y devuelve la respuesta asociada a la que mejor
puntuación haya obtenido en un mensaje a la API de Telegram indicando el
identificador del chat para que la API sepa dónde enviar el mensaje. Además
también se lee o modifica la Base de Datos (BD) MySQL dependiendo del
mensaje recibido.
Explicación detallada
Tras esta breve explicación, vamos a hacer una con más detalle sobre qué ocurre
a lo largo de la ejecución del programa del SRI.
En primer lugar tenemos el formato en el que se almacenan las preguntas y
respuestas en el/los FAQ. Un FAQ es un archivo en formato JSON en el cual
tenemos una lista de objetos, cada uno de ellos con 2 atributos: pregunta y
respuesta. Todos los FAQ estarán en una carpeta determinada de donde se
leerán para indexarlos.
Al iniciar el programa, la clase Main, se nos preguntará por terminal si deseamos
actualizar el índice, ya sea porque hemos añadido un nuevo FAQ o porque hemos
actualizado alguno de los que ya tenía el índice. Si elegimos actualizarlo por el
primer motivo llamaremos a la clase Indexer, la cual se encarga de crear el índice
de preguntas/respuestas a partir de los archivos JSON, indicando que sólo tiene
que abrir el índice y añadir documentos, mientras que si lo hacemos por el
segundo motivo, le indicaremos que borre el índice y cree uno nuevo para volver a
añadir los FAQs, ya que detectar qué preguntas de los FAQ están y no están ya
en el índice sería más costoso.
26
A parte de esa diferencia la clase Indexer actúa de la misma manera siempre.
En primer lugar se comprueba si en otra carpeta determinada existe ya un índice.
Si éste no existe creamos uno nuevo, y si ya existe lo abrimos, en ambos casos
mediante la clase IndexWriter para poder añadir más elementos al índice en
caso de ser necesario, además de aplicar la opción elegida de las explicadas
anteriormente. El siguiente paso tras tener un índice abierto, ya sea nuevo o ya
existente, es examinar la carpeta donde se encuentran los FAQ en busca de
nuevos archivos FAQ que aún no estén incluidos en el índice (los ya incluidos se
ignoran) para leerlos, obtener los datos necesarios e indexar las preguntas
incluidas en ellos en el índice mediante la clase IndexWriter.
Este índice contiene varios documentos, donde cada uno representa un par
pregunta/respuesta indexado con la siguiente información (fields o campos):
● Pregunta: almacenada con la clase TextField de la librería de Lucene.
● Respuesta: almacenada igual que la pregunta.
● Nombre del fichero: almacenado con la clase StringField de la librería
de Lucene.
● Ruta del fichero origen del par pregunta/respuesta (para saber el FAQ del
cual proviene): almacenada con la clase StringField de la librería de
Lucene.
Las diferencias entre TextField y StringField es que el campo de
TextField será indexado, al contrario que el StringField que solo será
almacenado. En todos los casos hemos decidido almacenar los datos de los
campos en el índice para así obtener su información como el resultado de las
búsquedas.
Ahora bien, al indexar los datos en el índice los campos indexados pasan por un
proceso de análisis para mejorar la posterior búsqueda sobre ellos. Esto se
consigue gracias a que el IndexWriter emplea un Analyzer, clase de Lucene
que sirve para analizar el texto indexado, lo que incluye un proceso de
tokenización (dividir el texto en partes) y el paso por una serie de filtros. En este
27
proyecto se ha creado un CustomAnalyzer, subclase que permite añadir los
filtros (subclases de TokenFilter) y tokenizers deseados, que han sido los
siguientes y en el siguiente orden (algo importante):
1. StandardTokenizer: tokenizer que divide el texto en tokens (palabras)
por medio de los espacios, además de eliminar los signos de puntuación
como puntos y comas, los cuales podrían quedarse pegados a las palabras
y entorpecer las búsquedas, ya que por ejemplo “casa” y “casa,” no serían
la misma palabra.
2. LowerCaseFilter: filtro que convierte en minúscula todos los tokens.
3. StopFilter: filtro que recibe un archivo con palabras que serán
eliminadas del texto, concreto las palabras que hay en [11]. Estas palabras
son llamadas “stop words”, las cuales son palabras que no son
consideradas importantes para la búsqueda porque son muy repetidas en
todas las búsquedas y podrían afectar a la puntuación de los documentos,
ya que no ayudan a distinguir las preguntas.Por ejemplo: artículos (la, el,
los), preposiciones (a, de, en)...
4. KeywordRepeatFilter: devuelve cada token (palabra) que recibe 2
veces, 1 como keyword y otra sin ser keyword. En el siguiente filtro se
explica el porqué.
5. SnowballFilter: filtro que aplica “stemming” a los tokens que recibe, lo
que elimina plurales y terminaciones, quedándonos así con las raíces de
las palabras. De esta forma al buscar “casas”, “casa” y “casita” las tratará
como la misma palabra porque la raíz de todas es “cas” y devolverá los
mismos resultados en los tres casos.
Al aplicar el “stem”, este filtro sólo devuelve el resultado del stem, por lo
que se pierde la palabra original. Esto se puede evitar si el token es un
keyword, de ahí el uso del filtro de KeywordRepeatFilter. El filtro de
Snowball no aplica el “stem” a los keyword, por lo que al recibir la misma
28
palabra como keyword y como no keyword, procesará la no keyword sólo,
quedándonos así con la palabra original sin modificar y la palabra resultado
del proceso de “stem”.
En cuanto al filtro, se trata de una versión de los stemmers Snowball, un
proyecto del repositorio de Github Tartarus Snowball que posee 15
“stemmers” para varios idiomas, entre ellos el español.
6. RemoveDuplicatesTokenFilter: filtro que elimina tokens que se
encuentran en la misma posición (la posición en el campo del documento) y
contienen el mismo texto. Este filtro se usa después del Snowball porque al
hacer “stem” sobre una palabra puede que el resultado sea el mismo que la
palabra original porque ya se trata de la palabra raíz y no se puede reducir
más. Al ocurrir esto, como hemos guardado tanto la palabra original como
el resultado del “stem”, tendremos dos veces la misma palabra en la misma
posición del campo, por lo que empleamos el
RemoveDuplicatesTokenFilter para eliminar una de ellas. Gracias a
este filtro junto con el KeywordRepeatFilter conseguiremos dar más
puntuación a las palabras específicas que a la raíz porque el token tiene
tanto la raíz como la original, lo que dará más puntuación.
Tras pasar por todos los filtros, el texto resultante será el usado más adelante por
la clase Searcher para realizar la búsqueda de preguntas en el índice.
Una vez tenemos el índice listo creamos nuestro bot de Telegram con la clase
FaqTfgBot y lo iniciamos, el cual será de tipo Long Polling como se ha
explicado anteriormente. Al iniciarlo creamos un IndexSearcher (clase de
Lucene para realizar búsquedas sobre un índice) en nuestra clase Searcher,
sobre el índice creado por el Indexer, de esta manera sólo tendremos una
instancia de Searcher a lo largo de la ejecución del programa, ya que crear un
Searcher cada vez que un usuario hace una consulta no es nada eficiente. Tras
esto nuestro bot ya está activo y los usuarios le pueden hacer consultas.
15 http://snowballstem.org/
29
Antes de explicar las interacciones del usuario con el bot, hay que entender un
poco como funciona cualquier bot de Telegram. Estos bots pueden recibir dos
tipos de mensajes: mensajes de texto normales o comandos. En cuanto a los
mensajes normales no hay nada que explicar, sólo es un texto sin nada especial,
pero los comandos son como mensajes predeterminados que empiezan con el
carácter “/” y pueden recibir argumentos, como por ejemplo “/get lista”. Estos
comandos tienen un apartado especial en el chat donde podemos ver todos de los
que dispone el bot en concreto junto con una explicación de lo que hacen.
Volviendo a nuestro programa, cuando un usuario envía un mensaje al chat del
bot, Telegram lo envía al SRI y éste último lo trata de diferente manera según el
tipo de mensaje:
● El primer caso es el comando que se envía automáticamente al iniciar un
bot de Telegram: “/start”. Al recibir este comando, nuestro bot va a acceder
a una base de datos (BD) MySQL y va a almacenar el identificador del chat
en una tabla llamada “chats”, si no está ya almacenado.
Figura 8. Uso del comando “/start” en el bot de Telegram
30
● Para el caso en el que los usuarios escriban un mensaje normal, que son
las consultas al índice de los FAQs, el bot hará una llamada al Searcher
para que realice la búsqueda de esta pregunta (más adelante se explicará
cómo funciona la búsqueda).
El Searcher nos va a devolver una lista de las preguntas, junto con sus
respuestas, que coincidan o sean lo más similares posibles a la que ha
realizado el usuario. El bot devolverá la pregunta (con su respuesta) con
mayor puntuación al usuario como un mensaje del bot, y el resto de
preguntas van a ser guardadas en la base de datos junto con el id del chat
al que corresponde la pregunta. Si en la BD ya había preguntas
relacionadas con ese chat, serán borradas y sustituidas por las nuevas, las
de la última consulta del usuario.
Figura 9. Ejemplo de pregunta al bot de Telegram
● ¿Por qué guardar los resultados de las búsquedas en una BD? Para el
caso en el que el usuario use el comando “/siguiente”. Este comando
31
obtiene de la BD y devuelve la siguiente respuesta con más puntuación de
la última consulta realizada por el usuario con un mensaje en el chat.
Cuando la respuesta es devuelta se borra de la base de datos para no
ocupar espacio. Sin embargo, si no quedan respuestas se informará al
usuario.
Figura 10. Uso del comando “/siguiente” en el bot de Telegram
Ya hemos visto como funciona todo el proceso, pero falta ver cómo realiza la
búsqueda el Searcher. Cuando se construye el Searcher creamos un
IndexSearcher sobre el índice, clase de Lucene que permite hacer búsquedas
sobre índices. El siguiente paso es tratar el texto escrito por el usuario antes de
usarlo para hacer una búsqueda, y para ello le aplicamos los filtros de un
Analyzer igual al de la clase Indexer explicada anteriormente, con lo que
conseguiremos que la consulta y las preguntas del índice tengan palabras iguales.
Tras los filtros, separamos el texto resultante por tokens o palabras para el
siguiente paso.
32
Para hacer la consulta al IndexSearcher debemos pasarle un elemento de la
clase Query (clase para crear consultas) de Lucene para que pueda funcionar
correctamente, y en este caso usamos su subclase SpanOrQuery. El
SpanOrQuery va a recibir un array de SpanQuery, donde cada elemento va a
ser un SpanTermQuery sobre una de las palabras de la pregunta hecha por el
usuario.
Esa es la estructura de la consulta, ahora vamos a analizarla:
● Cada SpanTermQuery es una consulta se va a hacer sobre un Term, una
palabra, y deben coincidir exactamente con alguna de las palabras del
índice para dar una puntuación mayor de 0. Por ejemplo, “Casa” y “casas”
no es lo mismo, deben ser iguales. Ahora bien, al haber aplicado los filtros
mencionados antes, casos como este ejemplo serían iguales.
● Los objetos SpanQuery pueden ser anidados dentro del SpanOrQuery
para hacer varias consultas, es decir, en este caso cada palabra de la
consulta del usuario.
● Por último SpanOrQuery realiza cada consulta del array de SpanQuery
y devuelve la suma de puntuaciones de éstas, y con encontrar sólo 1
coincidencia ya devolvería una puntuación mayor de 0 para ese
documento, de ahí el “or” de SpanOrQuery, no tienen porque estar todas
las palabras en el documento.
El resultado de una consulta es un objeto de tipo TopDocs de la librería de
Lucene que contiene los resultados de la consulta, es decir, los documentos
(pares pregunta/respuesta) que han obtenido alguna puntuación porque coinciden
en alguna medida con la pregunta hecha por el usuario, sólo con los campos que
fueron de tipo almacenado en el índice.
Cuánto mayor sea la puntuación de un documento, significa que es mejor la
coincidencia que ha encontrado y es más posible que sea la pregunta buscada.
33
7. Experimentación En este punto vamos a evaluar el sistema que se ha desarrollado utilizando un
conjunto de evaluación consistente, y para ello se ha decidido emplear el FAQ de
preguntas de la Universidad de Alicante
(https://web.ua.es/es/oia/preguntas/preguntas-mas-frecuentes.html), en concreto
las 50 primeras preguntas (se pueden encontrar en el Anexo II), para realizar una
evaluación del sistema con diferentes opciones. Estas preguntas han sido
reformuladas por 4 voluntarios para que a cada pregunta original tengamos una
alternativa, y para conseguir esto se les han mostrado las respuestas del FAQ y
se les ha informado brevemente sobre qué trata, pidiéndoles entonces que
formulen una pregunta que pudiera tener esa respuesta. Estas preguntas
alternativas son las que usaremos en las consultas para ver si el sistema de
recuperación de información nos devuelve la pregunta original.
Los resultados se han evaluado en todos los casos con el MRR (Mean Reciprocal
Rank), una medida estadística para evaluar cualquier proceso que produce una
lista de posibles respuestas a partir de consultas, ordenado por probabilidad de
exactitud. El rango recíproco de una sola respuesta es el multiplicativo inverso del
rango de la primera respuesta correcta. Por ejemplo, si realizamos una consulta y
la respuesta correcta está en la primera posición, su rango recíproco es 1, si
aparece en la segunda posición es ½, si aparece el tercero ⅓ y así
sucesivamente. El MRR será la media de los rangos recíprocos de las respuestas
a una serie de consultas, donde Q es la cantidad de consultas y ranki el la
posición del primer resultado correcto para la consulta número i.
En primer lugar se evaluaron los resultados de 2 diferentes medidas de
puntuación de los documentos a la hora de hacer una búsqueda: Okapi BM25 y
34
TFIDF, medidas que se explicaron en el punto 4 de herramientas y tecnologías en
el apartado de Lucene.
En ambos casos las características del indexador y el buscador eran iguales, para
ver la diferencia de rendimiento, y era una de las primeras versiones: todo
convertido a minúsculas, quitando signos de puntuación, búsqueda con fuzzy
query sobre el campo de la pregunta.
Gráfico 1. Comparativa de rendimiento entre Okapi y TF-IDF
Como se puede ver, el MRR en ambos casos es muy bajo, algo que es normal ya
que no hemos procesado mucho el texto indexado y de la consulta. Esta
comparación sirve para elegir una de las 2 puntuaciones como la base de nuestro
sistema de recuperación de información, y el Okapi BM25 ha obtenido mejores
resultados, motivo por el cual es el elegido para la versión final de proyecto.
El siguiente paso fue ir incluyendo filtros para tratar el texto e intentar mejorar la
búsqueda sobre él, además de varias maneras de realizar la búsqueda.
Vamos a ver un gráfico donde se han probado diferentes versiones del SRI con
estos diferentes y filtros y opciones. Se ha hecho del mismo modo que la prueba
de las medidas de puntuación: pasar 50 preguntas por cada una de las versiones
35
obteniendo el MRR. Además estamos realizando la búsqueda sólo en el campo
de la pregunta, es decir, que el texto de las respuestas no ha sido consultado.
La versión llamada “Final” que aparece en el gráfico es como la base, en el que se
basan el resto pero quitando o añadiendo lo que indica el nombre de la columna.
Por ejemplo, la versión “Sin stem” incluye todo lo que la versión “Final” pero
quitando el filtro de stemming. Ahora bien, ¿esta versión final que tiene?:
● Usa la medida de puntuación Okapi BM25
● Conversión a minúsculas
● Eliminación de stopwords o palabras de paso
● Stemming del texto para quedarnos con la raíz de las palabras
● Eliminación de signos de puntuación
● Búsqueda por palabra exacta (sin fuzzy)
Gráfico 2. Comparativa de rendimiento entre varias versiones del SRI, al buscar sólo en la
pregunta
Lo que se puede observar es que la versión “Final” que lo incluye todo tiene el
mejor rendimiento, y que ciertos elementos son más importantes que otros a la
hora de mejorar la búsqueda.
36
A pesar de que todas las versiones han obtenido resultados muy similares, la
diferencia entre la mejor (“Final”) y la peor (“Sin stem”) supone una mejora de
4.73%, lo cual no es mucho, pero es una mejora. Sin embargo, se ve que al
procesar más el texto, es decir, hacerlo pasar por filtros, ha mejorado mucho el
rendimiento respecto a la versión original que solo pasaba por el filtro de
minúsculas y de signos de puntuación, exactamente un 149.78% la versión
“Final”. Incluso el peor resultado, “Sin stem”, tiene una gran mejora de 138.50%
respecto a la versión original.
Al quitar el proceso de stemming, a pesar de contar con la eliminación de stop
words obtenemos el peor resultado, pues estamos buscando por palabra exacta y
es difícil que las palabras de la consulta sean exactamente iguales a las que hay
en el índice. Con esto podemos ver la importancia del stemming, un elemento
clave.
Ahora bien, al quitar el stem y usar fuzzy para la búsqueda obtenemos resultados
solo un poco inferiores a la versión final, lo que quiere decir que no es que stem
sea importante, sino que lo importante realmente es el uso de un filtro que trate de
igualar palabras que no son iguales, como es el caso de “casa” y “casas”.
Hemos comentado lo importantes que son el stemming y la búsqueda con fuzzy,
pero, ¿qué pasa al combinarlos? el MRR empeora con respecto a su uso por
individual de cada uno. Esto se debe a que al indexar el stemming nos deja con la
raíz de las palabras, y lo que hace la búsqueda fuzzy es una búsqueda
aproximada de la palabra, en concreto que tengan una distancia de edición menor
o igual a 2, por lo que al combinarlos cuando se realiza la búsqueda tenemos
palabras cortas, las raíces, y el fuzzy permite ediciones de estas palabras, lo que
implica que dé coincidencias en palabras que no tienen nada que ver, ya que las
ediciones en raíces de palabras pueden cambiar la palabra totalmente.
37
Si no quitamos las stop words el MRR también cae un poco a pesar de contar con
el stem, pues tenemos en el texto palabras que se repiten a menudo y afectan a
la puntuación, devolviendo así respuestas que no tienen que ver con la deseada.
En resumen, todos los elementos son importantes ya que cada uno mejora el
rendimiento en cierta medida, sin tener en cuenta la combinación de fuzzy y stem.
Por ese motivo la versión final que lo incluye todo tiene el mejor resultado.
Tras ver los resultados anteriores se decidió realizar las mismas pruebas pero
realizando la búsqueda en los campos de la pregunta y la respuesta al mismo
tiempo en lugar de sólo la pregunta.
Gráfico 3. Comparativa de rendimiento entre varias versiones del SRI, al buscar en pregunta más
respuesta
A diferencia de antes cuando buscábamos sólo en la pregunta, aquí el peor
resultado lo obtenemos al no quitar las palabras de paso debido a que ahora
tenemos mucho más texto que comparar y estas palabras aparecen mucho más,
provocando variaciones en las puntuaciones y haciendo que la eliminación de
stop words sea muy importante.
38
Otra diferencia importante es que ahora la versión “Final” supera por más
puntuación a “Sin stem, con fuzzy”. Esto ocurre porque al haber muchas palabras
el stem es más eficaz que el uso del fuzzy como búsqueda, ya que el buscar la
raíz exacta va a devolvernos más posiblemente el resultado esperado que una
edición aleatoria de la palabra, que es lo que busca fuzzy.
En general, los resultados buscando sólo en la pregunta son bastante mejores
que al buscar tanto en pregunta como en respuesta a la vez, y algunos ejemplos
son que la versión “Final” y la versión “Sin quitar stopwords” tienen un 14.98% y
un 37.29% menos de rendimiento respectivamente al buscar en pregunta más
respuesta que buscando sólo en la pregunta. Por estos motivos se descartó la
búsqueda conjunta de pregunta y respuesta para la versión definitiva del sistema
de recuperación de información.
Por último se realizó otra prueba que consistía en añadir algo a la versión final
que se ha comentado, pero a la de buscar sólo la pregunta (ya que tiene mejores
resultados). Se hizo que el stem no borrara la palabra original, si no que se
quedara tanto con la original como con la raíz a la hora de comparar cada
palabra. Con esto se consigue que en lugar de dar la misma puntuación a raíz y
original, se dé más puntuación a la palabra original en el caso de que la consulta
no sea la raíz, aunque siga dando coincidencia con la raíz. Por ejemplo: si
buscamos “casas”, ésta tendrá más puntuación si en la búsqueda se encuentra
con “casas” que con “casa”. Aquí tenemos un gráfico que demuestra la mejora.
39
Gráfico 4. Comparativa de rendimiento entre versión que puntúa igual a palabra raíz y la original, y
la versión que puntúa más la original
Aunque la mejora no es significativa, se decidió incluir esta opción en la versión
definitiva.
40
8. Conclusiones A lo largo del proceso de desarrollo he tenido que aprender a usar varias librerías
que nunca había usado como la de TelegramBots o la de Lucene. Esto es algo
que nunca había hecho, pues en todas las asignaturas cuando debíamos usar
alguna siempre nos hacían aunque fuera un pequeño tutorial de uso, y ha sido
interesante el tener que aprenderlo desde cero.
Gracias a este proyecto he aprendido qué son los sistemas de recuperación de
información y cómo funcionan. Siempre había tenido una pequeña idea de como
funcionan, pero no hasta este punto. También me ha gustado aprender a crear un
bot de Telegram porque es la aplicación de mensajería que uso principalmente y
hago uso de varios de estos bots.
Tras haber estado probando diferentes formas de indexación y búsqueda he
observado que siempre se puede mejorar añadiendo algún filtro más al texto,
aunque hay que tener cuidado de ciertas combinaciones que pueden hacer
empeorar el sistema, como la versión que combinaba stem y fuzzy. El sistema
desarrollado devuelve unos resultados aceptables tal y como está, ya que la
versión que ofrece un mejor valor de MRR tiene 0.8635 puntos siendo el posible
máximo de 1, y mejora un 149.78% respecto a la versión inicial. Esta versión final
contiene paso a minúsculas, eliminado de signos de puntuación, medida de
puntuación Okapi BM25, eliminado de stop words, proceso de stemming y
búsqueda por palabra exacta.
Posibles mejoras de la versión definitiva serían
● La clasificación de las preguntas por tipos para así reducir la lista de
documentos antes de empezar la búsqueda por el campo de la pregunta.
● Otra mejora podría ser realizar un diccionario de sinónimos, que muchas
veces causan problemas.
41
● Mejorar el formato de las respuestas que devuelve el bot de Telegram, ya
que al ser JSON el origen de todo, no permite poner listas, ni letras en
negrita o cursiva…
● mejorar el rendimiento del bot, que con muchos mensajes por minuto
puede ser muy lento
42
Referencias
[1] Salton, Gerard, and Michael J. McGill. "Introduction to modern information
retrieval." (1986).
[2] Kwok, Cody, Oren Etzioni, and Daniel S. Weld. "Scaling question answering to
the web." ACM Transactions on Information Systems (TOIS) 19.3 (2001): 242-262.
[3] Burke, Robin D., et al. "Question answering from frequently asked question
files: Experiences with the faq finder system." AI magazine 18.2 (1997): 57.
[4] https://core.telegram.org/bots
[5] https://en.wikipedia.org/wiki/Mean_reciprocal_rank
[6] https://lucidworks.com/2009/07/18/the-spanquery/
[7] https://dzone.com/refcardz/lucene?chapter=2
[8] https://lucene.apache.org/core/7_4_0/index.html
[9] https://github.com/rubenlagus/TelegramBots/wiki/Getting-Started
[10] https://es.wikipedia.org/wiki/B%C3%BAsqueda_de_respuestas
[11] https://github.com/stopwords-iso/stopwords-es
[12]https://stackoverflow.com/questions/18100233/lucene-fuzzy-search-on-a-phras
e-fuzzyquery-spanquery
43
Anexo I Este es el repositorio de Github donde he estado trabajando https://github.com/IvanMora16/ProyectoFAQ
Anexo II Las 50 preguntas empleadas para realizar las pruebas del punto de
“Experimentación”.
1
Original: ¿Cómo se puede obtener información sobre todas las actividades que se
organizan en la Universidad?
Alternativa: ¿Dónde puedo consultar la lista de actividades que se realizan en la
UA?
2
Original:¿Qué actividades culturales se desarrollan en la Universidad?
Alternativa: ¿Cuáles son las actividades culturales que se hacen en la
Universidad de Alicante?
3 Original:¿Con qué instalaciones y actividades deportivas cuenta la Universidad?
Alternativa: ¿Dónde me puedo informar de las actividades deportivas que hay?
4
Original:¿Qué actividades sociales y asistenciales me ofrece la Universidad?
Alternativa: ¿Dónde puedo asesorarme sobre el programa de voluntariado de la
UA?
5 Original:¿Qué tipo de actividades universitarias se reconocen como créditos?
Alternativa: ¿Qué actividades se pueden convalidar por créditos de libre elección?
6
Original:¿Dónde se puede obtener información sobre actividades que se realizan
o vayan a realizarse en otras universidades o centros?
Alternativa: Querría información sobre actividades que se desarrollen en otros
centros que no sean la UA
7 Original:¿Qué es la preinscripción?
Alternativa: ¿En qué consiste la preinscripción?
8 Original:¿Cómo, cuándo y dónde se solicita la admisión?
Alternativa: ¿Cuáles son los plazos para preinscribirme?
9 Original:¿Cuántas solicitudes de preinscripción se pueden presentar?
Alternativa: ¿Puedo presentar más de una solicitud de preinscripción?
44
10 Original:¿Dónde hay que presentar la solicitud de preinscripción?
Alternativa: ¿Dónde se realizan los trámites para preinscribirse?
11
Original: ¿Puede presentar la solicitud de preinscripción una persona distinta del
interesado?
Alternativa: ¿Una persona puede presentar la solicitud de preinscripción en lugar
de otra?
12 Original: ¿Cuál es el criterio para asignar las plazas universitarias?
Alternativa: ¿Cómo se decide la asignación de las plazas universitarias?
13 Original: ¿Qué son las "notas de corte"? ¿Cómo se pueden consultar?
Alternativa:¿En qué consisten las notas de corte y dónde pueden consultarse?
14 Original: ¿Qué son las listas de espera? ¿Cómo funcionan?
Alternativa: ¿De qué tratan las listas de espera?
15 Original: ¿Cómo se accede a la universidad desde los estudios de Bachillerato?
Alternativa: Si he estudiado bachillerato, ¿cómo se accede a la universidad?
16
Original: ¿Cómo se accede a la Universidad desde estudios de Formación
Profesional, Artes Plásticas y Diseño, y estudios superiores deportivos?
Alternativa: Si tengo estudios de Formación Profesional, Artes Plásticas y Diseño,
o estudios superiores deportivos, ¿cómo puedo acceder a la Universidad?
17 Original: ¿Cómo se consultan los resultados de preinscripción?
Alternativa: ¿Dónde puedo consultar la resolución de la preinscripción?
18
Original: ¿Qué hay que hacer una vez conocidos los resultados de
preinscripción?
Alternativa: He visto los resultados de la preinscripción, ¿qué hago ahora?
19
Original: ¿Cómo acceden a los estudios universitarios españoles los alumnos
procedentes de sistemas educativos de países de la Unión Europea y otros
países con convenio?
Alternativa: ¿Cómo pueden acceder los alumnos procedentes de sistemas
educativos de países de la Unión Europea y otro países del convenio a los
estudios universitarios españoles?
20
Original: ¿Cómo acceden a los estudios universitarios españoles los alumnos con
estudios extranjeros?
Alternativa: ¿Cómo se puede acceder a los estudios universitarios españoles con
estudios extranjeros?
21 Original: ¿Cómo se obtiene la admisión por traslado cuándo ya se han iniciado
45
otros o los mismos estudios de grado?
Alternativa: ¿Cómo consigo la admisión por traslado si ya he empezado otros o
los mismos estudios de grado?
22 Original: ¿Qué son los títulos de Máster Universitario Oficial?
Alternativa: ¿En qué consiste un Máster Universitario Oficial?
23 Original: ¿Cuáles son los requisitos para acceder a un Máster universitario oficial?
Alternativa: Requisitos para acceder a un Máster universitario
24 Original: ¿Cómo se solicita plaza en un Máster universitario oficial?
Alternativa: Pedir plaza en un Máster universitario oficial
25
Original: ¿Qué becas y ayudas se pueden solicitar para cursar estudios de
Postgrado Oficiales?
Alternativa: Becas y ayudas para cursar estudios de Postgrado Oficiales
26
Original: ¿Cómo acceden los titulados extranjeros a estudios de postgrado?
Alternativa: Si he obtenido un título en el extranjero, ¿cómo puedo acceder a un
estudio de postgrado?
27
Original: ¿Dónde se puede obtener información sobre alojamiento para estudiar
en la UA?
Alternativa: Querría información sobre alojamiento para estudiar en la UA
28 Original: ¿Se puede anular la matrícula? ¿Qué consecuencias tiene?
Alternativa: En caso de ser posible, ¿Qué puede pasar si se anula la matrícula?
29 Original: ¿Se tienen que comprar libros de texto?
Alternativa: ¿Es necesario comprar libros de texto?
30 Original: ¿Qué es y qué servicios ofrece la Biblioteca Universitaria (BUA)?
Alternativa: ¿Qué es y qué se puede hacer en la Biblioteca Universitaria (BUA)?
31
Original:¿Se puede acceder a las bibliotecas no siendo miembro de la
Universidad de Alicante?
Alternativa: Si no soy miembro de la Universidad de Alicante, ¿puedo utilizar las
bibliotecas?
32 Original: ¿Cómo se puede cambiar de estudios?
Alternativa: Si deseo cambiar de estudios, ¿cómo lo hago?
33
Original: ¿Cómo se pueden continuar en la Universidad de Alicante los estudios
iniciados en otra universidad?
Alternativa: He iniciado los estudios en otra universidad, ¿cómo puedo
continuarlos en la Universidad de Alicante?
46
34
Original: ¿Qué programa de movilidad permite cursar parte de los estudios en
otra universidad española?
Alternativa: ¿Con qué programa de movilidad es posible cursar parte de los
estudios en otra universidad española?
35 Original: ¿Qué es UACloud Campus Virtual?
Alternativa: ¿En qué consiste UACloud Campus Virtual?
36
Original: ¿Cómo se obtiene la clave de acceso a UACloud o cómo se renueva en
caso de olvido, confusión, etc?
Alternativa: ¿Cómo se puede obtener o recuperar la clave de acceso de
UACloud?
37
Original: ¿Cómo se puede consultar el expediente, exámenes y calificaciones?
¿Cómo se contacta con los/as profesores/as?
Alternativa: ¿Cómo puedo contactar con profesores/as?¿Y consultar el
expediente, exámenes y calificaciones?
38 Original: ¿Cuáles son los centros universitarios?
Alternativa: ¿Con qué centros universitarios cuenta la universidad?
39
Original: ¿Cuántas facultades y escuelas tiene la UA? ¿Qué títulos imparten?
Alternativa: ¿Número de facultades y escuelas de la UA?¿Títulos impartidos en
cada uno?
40
Original: ¿Qué son los departamentos universitarios? ¿Qué funciones y
organización tienen?
Alternativa: Departamentos universitarios, ¿qué son?¿qué hacen?¿cómo se
organizan?
41 Original: ¿Es obligatoria la asistencia a clase?
Alternativa: ¿La asistencia a clases es obligatoria?
42 Original: ¿Se puede asistir al grupo que se quiera, de mañana o de tarde?
Alternativa: ¿Puedo ir al grupo que quiera de mañana o tarde?
43 Original: ¿Se pueden recibir clases en valenciano?
Alternativa: ¿Podemos tener clases en valenciano?
44 Original: ¿Son obligatorias las clases en valenciano?
Alternativa: ¿Es obligatorio dar las clases en valenciano?
45 Original: ¿Qué es un crédito?
Alternativa: ¿Qué son los créditos?
46 Original: ¿Cuántos créditos tiene una carrera?
47
Alternativa: Cantidad de créditos de una carrera
47 Original: ¿Cómo se obtienen los créditos?
Alternativa: Formas de conseguir créditos
48 Original: ¿Qué son las materias básicas?
Alternativa: Descripción de materias básicas
49 Original: ¿Qué es una asignatura obligatoria?
Alternativa: Descripción de asignatura obligatoria
50 Original: ¿Qué es una asignatura optativa?
Alternativa: Descripción de asignatura optativa
48
