Trabajo de Fin de Grado

UNIVERSITAT POLITÈCNICA DE CATALUNYA FACULTAD DE INFORMÁTICA DE BARCELONA

GRADO DE INGENIERÍA INFORMÁTICA ESPECIALIDAD DE COMPUTACIÓN

Trabajo de Fin de Grado

Análisis visual de métricas similitud de textos

Vicente Coves Beneyto

Director: Dr. Pere-Pau Vázquez Alcocer

Fecha de defensa: 29 de junio del 2021

Resumen

Hoy en día se envían más de cien mil correos cada minuto [1] y se publican en torno a 1,8 millones de artículos académicos [2]. Entre todo este caos, para poder analizar y extraer conclusiones se necesita encontrar orden, a través de técnicas eficientes y capaces de procesar esta cantidad masiva de documentos, para poder realizar búsquedas, comparaciones y recomendaciones pertinentes.

Para ello en este Trabajo de Fin de Grado se establece como objetivo el analizar visualmente las métricas de similitud de textos existentes, sobre todo pensado para documentos extensos, pues la mayor parte de investigación es a nivel de palabra o unas pocas frases.

El formato de representación de los documentos será el embedding, que es un vector de números decimales en un rango de -x a x, e indica con que intensidad el documento presenta una característica en concreto.

Palabras clave: métricas de similitud, similitud de textos, embeddings

Abstract

Nowadays more than one hundred thousand emails are sent every minute [1] and around 1.8 million academic papers. With all this chaos, in order to analyse and extract conclusions, one must find order through the use of efficient techniques, capable of ingesting a massive number of documents, to then perform searches, comparisons and relevant recommendations.

In this bachelor’s thesis the aim is to visually analyse the existing text similarity metrics, with focus on extensive documents, since there is little research on this, and most academic papers study similarity at a word or sentence level.

The format in which the documents will be represented is the embedding, which is a list of decimal numbers, within a range from -x to x, that indicates the intensity for a given characteristic within the document.

Key words: similarity metrics, text similarity, embeddings

Índice

1. Introducción ... 1

1.1. Contexto ... 1

1.2. Formulación del problema ... 2

1.3. Actores implicados ... 2

2. Estado del Arte ... 3

2.1. Modelos de NLP... 4

2.2. Métricas de similaridad ... 5

3. Alcance y Obstáculos ... 6

3.1. Objetivos y subobjetivos ... 7

3.2. Requerimientos ... 8

3.3. Obstáculos y riesgos... 8

4. Metodología de trabajo y herramientas de seguimiento ... 9

4.1 Herramientas ... 9

4.2. Seguimiento ... 10

5. Recursos... 11

5.1. Recursos humanos ... 11

5.2. Recursos materiales ... 11

6. Planificación temporal ... 12

6.1. Descripción de tareas ... 12

6.1.1. GP - Gestión del Proyecto ... 12

6.1.2. EC - Elaboración del corpus ... 14

6.1.3. EM - Embeddings ... 15

6.1.4. AV - Análisis visual ... 15

6.2. Seguimiento de la planificación ... 17

7. Análisis de métricas de similaridad ... 19

7.1. Elaboración del corpus ... 19

7.2. Embedding ... 21

7.2.1. Doc2Vec ... 21

7.2.2. MUSE ... 25

7.2.3. BERT ... 27

7.2.4. Embeddings finales ... 29

7.3. Análisis visual ... 30

7.3.1 t-SNE ... 32

7.3.2 UMAP ... 36

7.4. Elaboración del corpus NG20 ... 42

7.5. Embedding Doc2Vec ... 43

7.6. t-SNE ... 44

7.7. UMAP ... 46

7.8. Resultados ... 50

8. Conclusiones ... 52

8.1. Continuación del trabajo ... 52

8.3. Justificación de competencias técnicas ... 54

9. Diagrama Gantt ... 55

z10. Gestión del riesgo ... 56

z11. Gestión económica ... 57

z11.1. Presupuesto ... 57

z11.1.1. Coste roles ... 57

z11.1.2. Costes ... 57

z11.1.3. Contingencia ... 59

z11.1.5. Coste total ... 60

z11.2. Control de gestión ... 60

z12. Sostenibilidad ... 61

12.1. Autoevaluación ... 61

12.2. Dimensión Ambiental ... 62

12.3. Dimensión Económica ... 62

12.4. Dimensión Social ... 63

z13. Bibliografía ... 64

z14. Lista de imágenes ... 67

z15. Lista de tablas ... 68

1

1. Introducción

La similitud de textos pretende medir cómo de parecidos son dos documentos centrándonos en el significado (análisis semántico) y en la forma (análisis léxico). Para ello se utilizan word embeddings [3], que no es otra cosa que la representación de una palabra mediante un vector de números. Al proceso de aprendizaje de los embeddings se le llama entrenamiento, y la calidad de este tendrá un gran impacto en el resultado final al comparar textos. Es por esto que grandes empresas han dedicado muchos recursos y tiempo a entrenar con muchísima información los modelos, como es el caso de Word2Vec [4, p. 2], que Google publicó en 2013. Si condensamos de forma inteligente todos los word embeddings de un documento podremos obtener una representación del mismo, que se utiliza para comparar con otros documentos, y es la idea detrás de Doc2Vec [5] para obtener embeddings a nivel de documento.

Entre las múltiples aplicaciones están los detectores de plagio, clasificación de anuncios, categorización de películas o libros según la sinopsis o contraportada. También es útil en la elaboración automática de resúmenes, pues el objetivo de estos es que tengan un significado muy parecido al texto completo, pero con una extensión más reducida. Otro uso sería la búsqueda de párrafos/frases dentro de artículos en base a una descripción o directamente buscar artículos relacionados uno o varios en particular. Además, sirve para generar respuestas a preguntas de forma automática. Según el modelo utilizado se podría realizar una traducción automática, una característica muy valiosa en mundo globalizado y que facilita enormemente la escalabilidad de un servicio a otros países.

1.1. Contexto

El Grado de Ingeniería Informática consta de múltiples menciones a elegir, y este trabajo de fin de grado forma parte de la especialidad de Computación, más concretamente al tema de Computación Gráfica. El director del trabajo es Pere- Pau Vázquez, que forma parte del ViRVIG [6], un centro de investigación para la visualización, realidad virtual e interacción de gráficos.

2

1.2. Formulación del problema

En este trabajo se pretende comparar medidas de similitud de texto, y para ello se evaluarán unas concretas. En primer lugar está Doc2Vec [7], una técnica comúnmente usada para comparar documentos, y es muy escalable, pues es capaz de entrenar 1000 documentos en pocos segundos, y se usa a menudo con decenas de miles o incluso millones de documentos. Las otras dos a evaluar son famosos modelos de procesamiento del lenguaje natural [8]: BERT [9] y MUSE[10], que se adaptarán para permitir la comparación con documentos, algunos muy extensos. Con esto pretendemos aprovechar algunas de las ventajas que tienen estos modelos, como son la velocidad y precisión que han demostrado estos modelos, además de soporte de forma nativa para varias lenguas en el caso de MUSE.

Unos de los objetivos es encontrar o elaborar un corpus donde haya conjuntos de artículos parecidos, de esta forma se podrán evaluar la bondad de los modelos en función del agrupamiento de los conjuntos. Para ello, una vez se obtienen los embeddings de los 3 modelos anteriores, se compute un agrupamiento utilizando el algoritmo de k-means [11]. Para poder evaluar la calidad del agrupamiento se utilizará una herramienta de visualización, que nos permitirá pasar del espacio n-dimensional en que se encuentran los documentos a un espacio 2D.

1.3. Actores implicados

En definitiva, dada la gran variedad de usos generales que tiene, son numerosos los beneficiarios de esta técnica, desde empresas que gestionan un alto volumen de documentos hasta usuarios que simplemente usan internet y servicios de entretenimiento. Estos se beneficiarían de sistemas más inteligentes y verían resultados más pertinentes cuando hacen preguntas, buscan artículos, películas o libros. Esto es posible incluso aunque no coincida el idioma de los documentos, sin resultar en un deterioro en el resultado. [12]

3

2. Estado del Arte

Sobre la similitud de textos hay una gran variedad de trabajos, desde aquellos que se centran en comparar documentos extensos (este es el caso sobre el cual hay menos investigación) y la tarea es más de clasificación o búsqueda de información, pasando por párrafos o unas cuantas frases, hasta llegar a las palabras individuales. La cuestión es que todos están relacionados entre sí, y de la misma forma que en una frase algunas palabras tienen más peso que otras, en los documentos también hay párrafos o frases con un mayor peso semántico. Por tanto, es interesante estudiar las contribuciones en cada trabajo.

Multitud de estudios como el de Corley y Mihalcea en 2005 [13] se centran o bien a nivel de palabra o bien llegan hasta un par de frases, o incluso un párrafo breve. Consiguen unos resultados mejores a las técnicas tradicionales del momento, que se basaban en coincidencia léxica.

Probablemente dada la complejidad de textos de mayor extensión, nadie había creado bibliotecas ni estudios con los que comparar o mejorar resultados.

No fue hasta 2013 que un grupo de cinco investigadores de la Universidad de Memphis [14] decidieron tomar la iniciativa y crearon una biblioteca con múltiples algoritmos de similitud, así como bases de datos para textos de mayor longitud, tomando como fuente la Wikipedia al completo.

Además de la biblioteca en Java que hicieron pública, también crearon una interfaz gráfica para que usuarios no expertos puedan probar fácil y rápidamente distintos algoritmos. El programa permite no solo comparar grandes textos, sino frases o palabras, e incluso frases con documentos, que equivale a comprobar si el texto corto resume adecuadamente el texto completo. Es de agradecer que también han hecho una versión online y desde la web se puede descargar todos los recursos mencionados anteriormente, de modo que puede ser interesante comparar el algoritmo que mejor resultado obtuvieron para similitud con documentos. No obstante, ninguno de los trabajos, ni tan siquiera éste, lleva al terreno visual el análisis de los resultados, por tanto, me parece necesario el enfoque original de este TFG.

4

2.1. Modelos de Procesamiento del Lenguaje Natural (NLP)

Por otro lado, en el mundo de las Big Tech tenemos por parte del laboratorio de inteligencia artificial de Facebook a MUSE [10] (Multilingual Unsupervised and Supervised Embeddings). Destaca por su novedoso enfoque, que consiste en embeddings en varios idiomas tanto al entrenar como al evaluar.

Además, tiene una alta compatibilidad, pues se puede ejecutar tanto en GPU como CPU, y hay versiones para Python 2 y 3. Tiene soporte para fastText [15], una biblioteca de embeddings también desarrollada por Facebook, de modo que la integración y documentación serán puntos fuertes a tener en cuenta.

De modo similar, BERT fue creado y publicado por Jacob Devlin junto a otros compañeros de Google en 2018 [16]. BERT (Bidirectional Encoder Representations from Transformers) difieren de Word2Vec y GloVe (Global Vectors) [17] en un aspecto muy importante, y es el contexto. Word2vec y GloVe entrenan los embeddings sin contexto, de modo que la palabra “banco” en

“sentado en un banco” y “banco de peces” tendrá el mismo embedding, pues no tiene en cuenta las palabras que la preceden o suceden. BERT en cambio sí tiene contexto, y dentro de esta categoría podemos distinguir entre unidireccionales (ya sea mirar las k palabras a la izquierda o centrarse en la derecha) y bidireccionales, como es el caso de BERT. Adicionalmente, dentro de estas se caracteriza a BERT como profundamente bidireccional, pues no se limita a combinar trivialmente el contexto izquierdo y derecho, sino que utiliza una red neuronal profunda. Está disponible en varias versiones, según el tamaño de la red neuronal, versión solo con minúsculas, versión con soporte para varias lenguas, etc.

Por último, está Doc2Vec, y se usará la versión más reciente de Gensim [7], que es una biblioteca de código abierto para el modelado de aprendizaje no supervisado y procesamiento del lenguaje natural. El modelo Doc2Vec es capaz de entrenar su propio vocabulario con sus word embeddings tomando como fuente los propios documentos. Además, permite inferir embeddings de nuevos documentos con gran facilidad. También cuenta con varias técnicas de calcular los embeddings y múltiples hiperparámetros a ajustar. Fue creado en 2009 pero

5

recibe actualizaciones hasta el día de hoy, siendo la versión más reciente de mayo 2020. Está implementada en Python y Cython, y es ideal para la comparación y clasificación semántica de textos, por lo que es junto con BERT una de las herramientas más prometedoras.

2.2. Métricas de similitud

También es relevante conocer las distintas métricas de similitud que existen, y sirven para comparar las representaciones numéricas, ya sea a nivel de palabra, frase o texto.

En primer lugar, hay una técnica llamada similitud de Jaccard [18], que no necesita embeddings, sino que reduce a las palabras a su raíz, y compara el tamaño de la intersección entre el tamaño de la unión de los dos documentos.

Esto conlleva varios problemas, y es que si se utilizan sinónimos o palabras similares no es capaz de captar esa similitud. Además, a medida que se tratan textos más largos, la probabilidad de que hayas muchas palabras en común aumenta, aunque los temas sean totalmente distintos.

La siguiente métrica utiliza embeddings, y consiste en calcular el coseno del ángulo entre los dos vectores [19]. Una ventaja es que no importa la magnitud, sino únicamente la orientación del vector, y el resultado irá de -1 a 1. Cuanto mejor sea el embedding, más preciso será el resultado, por tanto, combinar está técnica con un embeddings de calidad es crucial. En este caso GloVe sería un gran candidato, y se creó en Standford [17] con la intención de combinar los puntos fuertes de técnicas anteriores, con lo cual los embeddings captan mejor el significado. También se puede aplicar este método, pero con embeddings de BERT, lo cual será interesante ya que este utiliza mucha información contextual, para calcular la representación.

6

Por último, tenemos una métrica que no requiere embeddings, sino que se basa en conocimiento, y pretende cuantificar la relación semántica entre palabras mediante una red semántica, como puede ser WordNet [20], creada por la Universidad de Princeton a mediados de los 80. Se agrupan sustantivos, verbos, adjetivos y adverbios en conjuntos de sinónimos cognitivos (synsets), y después se calcula la similitud como la probabilidad de encontrar el LCS (Least Common Subsumer), es decir el ancestro común más específico, en un corpus.

En cuanto a la tarea de la visualización, no basta con las herramientas de gráficos de Word, pues no estamos trabajando con objetos de 2 dimensiones, sino de n, dependiendo del modelo puede ser 50, 100, etc. Por tanto, debemos aplicar una técnica de reducción de dimensiones para visualizarlo en 2D o 3D. Para ello, t-SNE [21] y UMAP [22] son las 2 mejores, aunque como veremos en detalle más adelante, cada una tiene sus puntos fuertes y sus desventajas, y es fundamental conocerlos en ambos.

3. Alcance y Obstáculos

En todo proyecto que se digne es vital definir claramente el alcance y objetivo del mismo, pues el tiempo es un recurso limitado, por tanto, es conveniente enumerar los requisitos que debe cumplir el trabajo. A continuación,

Fig. 1: WordNet Ejemplo. Fuente: Adaptado de [1]

7

se especifican los objetivos, requisitos y posibles obstáculos o riesgos que pueden surgir durante el proyecto.

3.1. Alcance: objetivos y subobjetivos

El objetivo fundamental es calcular distintas métricas de similitud de textos para varios conjuntos de textos, utilizando distintos modelos y técnicas, para complementarlo con un análisis visual mediante una gráfica interactiva. En base a esto distinguimos los siguientes subobjetivos:

1. En primer lugar, la obtención de datos y preprocesamiento, que consiste en seleccionar y descargar los textos a comparar y aplicar una serie de transformaciones a estos, cómo puede ser pasar a minúsculas, eliminar algunos signos de puntuación, etc. Estos pasos se deberán aplicar a cada conjunto de textos que se planea utilizar.

2. Después es el momento de la obtención de embeddings. Cabe mencionar que, según el modelo concreto, serán necesarios algunos ajustes, ya que BERT, a pesar de ser una herramienta muy potente, debido a que los embeddings que calcula tienen un límite de 512 tokens, para documentos extensos habría que combinar los múltiples embeddings. Como esto es precisamente lo que hace Doc2Vec (dentro de la librería Gensim), sería interesante combinar estas dos técnicas para sacarle el máximo partido a BERT.

3. Una vez tenemos los resultados, para saber en cuántas categorías los podemos agrupar, será necesario un algoritmo que grafica unas métricas, y de forma subjetiva seleccionaremos el número que en el gráfico parece ser el adecuado. Seguidamente utilizamos una herramienta de reducción de dimensiones, que nos permitirá visualizar los embeddings de los documentos en un plano 2d o 3d.

8

3.2. Requisitos

3.2.1. Requisitos funcionales

Los requisitos funcionales están explicados en el objetivo, y al no ser una aplicación que depende de otros servicios, no hay unas prácticas y estándares concretos a los que debe adherirse, ni unos requisitos concretos en la entrada y salida de datos o comportamiento de la aplicación. Además, las funcionalidades del código es producir entrada y salida sin interacción del usuario, exceptuando la selección de la entrada y la interacción con la visualización gráfica.

3.2.2. Requisitos no funcionales

Estos requisitos no son esenciales para el funcionamiento de la aplicación, pero sí son deseables, pues proporcionan una experiencia más agradable en general y es buena práctica:

1. Eficiencia: A lo largo del desarrollo será tenido en cuenta y se evaluarán distintas formas de proceder a fin de minimizar tiempo de ejecución, así como uso de memoria.

2. Reusabilidad: Para facilitar la reutilización de parte del código en otros proyectos es interesante utilizar o desarrollar algoritmos y modelos que gocen de alta compatibilidad.

3.3. Obstáculos y riesgos

Siempre habrá obstáculos diversos que deben ser discutidos previamente para poder tenerlos en cuenta, tanto en tiempo que podemos emplear para resolverlo, como en posibles alternativas. De este modo se minimiza el impacto que puede tener en el proyecto. A continuación, se exponen las principales dificultades:

1. Debido que algunas herramientas son muy recientes, como es el caso de BERT, es posible que haya pocos recursos de ayuda a la hora de resolver

9

errores de instalación o ejecución. Asimismo, también es probable que surjan errores de compatibilidad entre plataformas, lenguajes, bibliotecas o hardware, que con el paso del tiempo se pueden ir solventando.

2. A pesar de existir en algunos casos versiones ligeras de los modelos, es posible que los requisitos de memoria sean demasiado altos para ejecutar en mi portátil de 12GB de RAM, por tanto, es una consideración a tener en cuenta, pues es posible que este factor limite el tamaño de la entrada del problema. Una alternativa sería utilizar la nube para realizar el cómputo y exportar los datos a un equipo local, si bien habría que planear el coste en tiempo conlleva el aprendizaje y configuración de ese sistema, así como el coste financiero.

4. Metodología de trabajo y herramientas de seguimiento

Dada la naturaleza del trabajo, considero que la metodología ágil de desarrollo de software, ya que permite flexibilidad a la hora crear funcionalidades y evaluar si cumple con los requisitos o se debe descartar o modificar. Por tanto, se hará una división en ciclos cortos (en torno a una semana) en la que se diseña, implementa y evalúa una funcionalidad.

4.1 Herramientas

Para tener enumeradas las tareas a completar utilizaré Trello [23], donde hay un tablero virtual, listas, y tarjetas, de modo que se puede agrupar en una lista todas las tareas, cada una en una tarjeta, y cuando superan las 3 fases de desarrollo, pasan a la lista de completado.

Para control de versiones GitHub [24] es una buena herramienta, pues el repositorio es capaz de almacenar múltiples versiones de código, de modo que cada semana se guardan los cambios y es muy sencillo ver las diferencias entre versiones, identificando claramente el código añadido/eliminado, así como los archivos creados/eliminados.

10

Para la planificación del proyecto utilizaré GanttProject [25], en su última versión 3.0. De esta forma se ordenarán las tareas, donde cada una tendrá asignada una duración. Así podrá controlarse el tiempo empleado semanalmente y asegurar que se finaliza en el plazo de tiempo previsto. Además, el diagrama se mantiene actualizado con el tiempo que se ha dedicado y refleja los cambios en la planificación que se han acordado en las reuniones con el director del TFG.

Para organizar las referencias he utilizado Zotero [26], de esta forma garantizo que utilizo el mismo estilo para toda la bibliografía. Es una de las pocas herramientas gratuitas con una gran variedad de estilos de citación y extensiones para navegadores y Word, de modo que es muy cómodo y sencillo organizar las fuentes consultadas.

4.2. Seguimiento

Se establecerán reuniones semanales con el director del TFG para evaluar las tareas realizadas durante la semana. En función de los objetivos cumplidos se acordarán modificaciones a la planificación y/o a las tareas establecidas para la semana siguiente.

11

5. Recursos

5.1. Recursos humanos

A continuación, se especifican los roles necesarios para el trabajo de fin de grado:

Tabla. 1. Roles proyecto. Fuente: Elaboración propia

5.2. Recursos materiales

Para esta investigación se utilizará un portátil HP Pavilion para todas las tareas, es decir, documentación, redacción de memoria, diseño, implementación y prueba del código.

Identificador Rol Función

JP Jefe de proyecto

Jefe de proyecto. Su tarea consiste en planificar, organizar y dirigir la ejecución de los objetivos, cumpliendo los las fechas límite y el presupuesto establecido

I Investigador Es el encargado de diseñar la solución, especificando la funcionalidad, lenguajes de programación y demás requisitos relevantes

P Programador Programará la aplicación, cumpliendo con el diseño y teniendo en cuenta prácticas estándar del lenguaje de programación para facilitar la comprensión del código T Tester Su labor es poner a prueba el código, es decir asegurar que

las funciones son correctas y que los posibles errores se manejan adecuadamente

12

6. Planificación temporal

Dado que un TFG tiene una carga de trabajo correspondiente a 18 créditos, lo cual equivale a 540 horas, es crucial hacer una segmentación de las partes del trabajo, así como una estimación realista en horas. De este modo, se describirá en detalle cada tarea, que contará con una estimación justificada de su duración y se especificarán las dependencias entre ellas. Se representará en visualmente en un diagrama de Gantt. Esto nos permitirá seguir un plan de acción que servirá para asegurar la finalización del TFG en el plazo de tiempo establecido.

En este caso el comienzo del TFG es el 15/2/2021 y la fecha de finalización es el 5/6/21. Se intentará trabajar una media de 6 horas diarias de lunes a domingo.

6.1. Descripción de tareas

En primer lugar, distinguimos entre las fases principales del trabajo, y para cada una se describirá en que consiste y cuál es el tiempo de realización estimado.

También se le asignará un nivel de riesgo a las tareas. Hay 3 niveles de riesgo, bajo, medio y alto. De este modo podemos tener en cuenta en la planificación la posibilidad de que algunas tareas requieran más tiempo de lo previsto.

6.1.1. GP - Gestión del Proyecto

Al empezar tenemos la gestión del proyecto, que engloba aquellas tareas de carácter organizativo o de introducción. Son una parte fundamental del trabajo, pues se introducen establecen las pautas a seguir y organiza los plazos y las tareas que se irán realizando.

13 GP.1 - Contexto y Alcance

Se establece el contexto del trabajo y cuáles son los objetivos a cumplir.

Tiempo estimado: 20 horas. Riesgo asociado: bajo.

GP.2 - Planificación Temporal

Consiste en describir las tareas y estimar el tiempo de ejecución. Además, se utilizan las dependencias entre tareas para crear un diagrama de Gantt.

Tiempo estimado 8 horas. Riesgo asociado: bajo.

GP.3 - Presupuesto y sostenibilidad

Se hace un presupuesto de los recursos necesarios para el proyecto teniendo en cuenta el tiempo empleado. También se valora el coste en términos de sostenibilidad. Esto tarea tiene más utilidad en proyectos comerciales, pues la empresa le interesa tanto la finalidad como los costes asociados. Al ser este un trabajo de investigación, no tiene mucha complejidad esta tarea. Tiempo estimado 8 horas. Riesgo asociado: bajo.

GP.4 - Memoria

Consiste en redactar toda la información referente a la gestión del proyecto, así como los detalles técnicos del trabajo, reflejando claramente los avances y obstáculos superados. Dado que es el documento por excelencia del TFG, debe estar en condiciones óptimas, y para ello se le dedicarán bastantes horas de revisión. Tiempo estimado: 65 horas. Riesgo asociado bajo.

GP.5 - Reuniones

Se incluyen las reuniones con el equipo de trabajo o con el director del proyecto. Sirven para evaluar el trabajo realizado, resolver dudas, sugerir mejoras, y planificar reuniones venideras. En la metodología ágil, se llevan a cabo reuniones frecuentes y de baja duración (suelen estar asociadas a los sprints).

Teniendo en cuenta 30 minutos semanales durante 15 semanas + 3 reuniones de hitos inicial, seguimiento y final se estima una duración de 10 horas. Riesgo asociado: bajo.

14 GP.6 - Presentación

Se incluye la preparación de la defensa de la memoria ante el tribunal evaluador del TFG. Dado que en varias asignaturas desde el primer curso hemos practicado las habilidades orales al presentar problemas y trabajos, estimo una duración de 6 horas. Riesgo asociado: bajo.

GP.7 - Documentación

Es una tarea que es imprescindible, y se ira realizando paralelamente al resto de tareas, pues cuanto más reciente el trabajo realizado más sencillo es explicar qué se ha hecho y por qué. Duración estimada: 60 horas. Riesgo asociado: bajo.

6.1.2. EC - Elaboración del corpus

Consiste en elaborar un corpus con 100-1000 documentos de una extensión considerable (> 1000 palabras). Una vez conseguidos, lo más seguro es que sean todos formato PDF, por tanto, hay que extraer el texto, al no ser trivial, definimos las 2 siguientes subtareas:

1. EC.1 - Encontrar documentos

En primer lugar, se debe conseguir en torno a 100- 1000 documentos que traten temas distintos. Tiempo estimado: 10 horas. Riesgo bajo.

2. EC.2 - Limpieza de documentos

Creación de script en Python para extraer el texto de los PDFs. Se probarán varias técnicas y se valorará la velocidad y calidad del resultado. Tiempo asociado: 15 horas. Riesgo bajo.

Entre las dos subtareas suman un tiempo de diseño es de 4 horas, de implementación 25 (10 + 15), y de pruebas 6 horas.

15

6.1.3. EM - Embeddings

EM.1 - Embedding Doc2Vec

Consiste en familiarizarse con la librería Gensim y probar distintos hiperparámetros en el Doc2Vec, que será la herramienta que nos permitirá obtener un embedding para cada documento de la entrada. Se tiene en cuenta el diseño con duración de 5 horas, implementación de 15 horas, y pruebas de 10 horas. Riesgo bajo.

EM.2 - Embedding BERT

Consiste en familiarizarse con el modelo BERT con el fin de calcular embeddings en bloques de 512, y luego combinarlos usando una técnica que sea rápida y de buenos resultados. Se estiman las siguientes duraciones; diseño: 6 horas; implementación: 30 horas: pruebas: 10 horas. Riesgo alto.

EM.3 - Embedding MUSE

Leer la documentación sobre MUSE para ser capaz de generar embeddings para documentos. Con MUSE tendría la capacidad de comparar documentos en distintos idiomas gracias a como han entrenado sus embeddings. No obstante, sospecho que esto puede causar problemas, de modo que le asocio un tiempo de un riesgo alto y se estiman las siguientes duraciones; diseño: 8 horas;

implementación: 40 horas: pruebas: 12 horas.

6.1.4. AV - Análisis visual

AV.1 Gráfico similitud

Generar métricas para los modelos y documentarse sobre las herramientas t-SNE y UMAP. Evaluar para que casos es mejor cada una, y conocer los hiperparámetros óptimos para la visualización. Al ser la primera vez que el autor las utiliza se le asigna un riesgo medio. Se estiman las siguientes duraciones;

diseño: 6 horas; implementación: 35 horas: pruebas: 8 horas.

16

Id Tarea Tiempo (horas) Dependencia Riesgo Rol

GP Gestión del Proyecto 177

GP.1 Contexto y Alcance 20 Bajo JP

GP.2 Planificación Temporal 8 GP.1 Bajo JP

GP.3 Presupuesto y sostenibilidad 8 GP.1 Bajo JP

GP.4 ^{Memoria 65 GP.1 Bajo JP}

GP.5 Reuniones 10 Bajo JP, I, P, T

GP.6 Presentación 6 GP.7 Bajo JP

GP.7 Documentación 60 GP.1 Bajo JP, I

EC Elaboración Corpus 35

EC.1 EC.1.1

Encontrar documentos Diseño

12

1 GP.2 Bajo I

EC.1.2 Implementación 10 EC.1.1 Bajo P

EC.1.3 Pruebas 1 EC.1.2 Bajo I, T

EC.2 EC.2.1

Limpiar documentos Diseño

23

3 EC.1.3 Bajo I

EC.2.2 Implementación 15 EC.2.1 Bajo P

EC.2.3 Pruebas 5 EC.2.2 Bajo I, T

EM Embeddings 146 EC.2.3, EC.1.3

EM.1 EM.1.1

Doc2Vec Diseño

40

5 Bajo I

EM.1.2 Implementación 15 EM.1.1 Bajo P

EM.1.3 Pruebas 10 EM.1.2 Bajo I, T

EM.2 EM.2.1

BERT Diseño

46

6 Alto I

EM.2.2 Implementación 30 EM.2.1 Bajo P

EM.2.3 Pruebas 10 EM.2.2 Bajo I, T

EM.3 EM.3.1

MUSE Diseño

60

8 Alto I

EM.3.2 Implementación 40 EM.3.1 Medio P

EM.3.3 Pruebas 12 EM.3.2 Bajo I, T

AV Análisis Visual 49 EM.1.3*

AV.1 Gráfico similitud 44

AV.1.1 Diseño 6 Medio I

AV.1.2 Implementación 35 AV.1.1 Bajo P

AV.1.3 Pruebas 8 AV.1.2 Bajo I, T

- Total ^{407 -}

Tabla. 2. Planificación de tareas. Fuente: Elaboración propia

17

*Con haber terminado uno de los embeddings (el que antes termina es EM.1) ya puedo comenzar con AV.

6.2. Seguimiento de la planificación

A continuación, se describen las variaciones que ha habido en las actividades planificadas, y que consecuencias han tenido en el proyecto, ya sea en incremento de tiempo, uso de otras herramientas, o nuevas funcionalidades.

6.2.1. Elaboración del corpus

Para el análisis de documentos se necesita que estén en formato texto, por tanto, se debe convertir los pdf. Inicialmente tenía un módulo pensado, PyPDF2, pues ya tenía experiencia y tuve buenos resultados en otros proyectos. No obstante, hubo varios casos de fallo al convertir a texto, y tardaba un tiempo considerable. Comentándolo con el director, sugirió usar Apache Tika, y tras resolver extraños errores con el .jar, el resultado fue mejor y más veloz. Aun así, no era perfecto, de modo que investigué más y encontré dos módulos más, Fitz y PdfMiner.six, siendo el último el más preciso pero el más lento, y Fitz el más rápido y bastante buen resultado. Dado que solo iba a convertir a texto una vez, consideré importante obtener los mejores resultados, por lo que para cada documento aplico los 4 métodos y después compruebo cual tiene un mayor porcentaje de palabras válidas. Además, añadí una funcionalidad de selección, de modo que es posible utilizar los documentos que tengan al menos p% de palabras válidas, o como máximo ‘k’ documentos.

6.2.2. Embedding BERT

En un principio se planteó utilizar Doc2Vec modificando los word embeddings que se utilizan para generar el embedding de párrafo y después el de documento de forma que el de palabra sea sustituido por una implementación de BERT. No obstante, esto no ha resultado posible debido a que se ha desactivado la opción de cambiar los word embeddings desde hace varias versiones, y se desaconseja esta práctica con Doc2Vec al no ofrecer ventajas en espacio y

18

precisión, ya que los word embeddings de Doc2Vec se entrenan con el propio corpus.

Esto ha implicado un sobrecoste en tiempo y dinero, y se ha estudiado los puntos fuertes de BERT para obtener los mejores resultados al generar los embeddings. Principalmente, BERT es capaz de obtener unos embeddings de alta calidad en cuanto a información contextual, con el límite de 512 palabras. Por tanto, no me terminaba de convencer el generar embeddings cada 512 palabras del documento (con un intercalado de las primeras 50 o 100 del anterior párrafo para no perder un posible contexto), cuando estamos hablando de textos de cerca de 10000 palabras. Además, el tiempo de ejecución sería órdenes de magnitud mayor, y dado que el tamaño del embedding ya es más de 4 veces el Doc2Vec quería hacer una comparación más equilibrada en recursos computacionales. Por tanto, la implementación final consiste en coger las primeras 312 palabras y las últimas 200. Con la idea de que la introducción y la conclusión engloben el significado del documento.

6.2.3. Pruebas embedding

Para comprobar la calidad de los embeddings la idea era utilizar KMeans para crear ‘k’ grupos, donde k va de 1 a 50, y graficando la suma de distancias al cuadrado entre los elementos y el centro de su grupo vemos como mejora la solución al aumentar el número de grupos. No obstante, con tantos documentos y grupos no es trivial seleccionar el punto óptimo de grupos, conocido como

‘elbow’ o ‘knee’. Es por esto que se investigó una forma programática de determinar este hiperparámetro. Afortunadamente no fue necesario programar esta funcionalidad desde 0, sino que se utilizó un módulo llamado kneed. Esto supuso un sobrecoste en tiempo, si bien mejoró la selección de grupos notablemente.

6.2.4. Metodología y software

No ha sido necesario modificar la metodología de trabajo, puesto que ha funcionado adecuadamente la planteada al inicio del trabajo. En cuanto a software utilizado no se han encontrado obstáculos que hayan impedido su uso.

19 6.2.5. Estado de seguimiento

Actualmente se han completado las fases EC, EM, AV-1.1 y AV-1.2. El proyecto está bastante avanzado y dado que la documentación ha sido una tarea que se ha realizado en paralelo al resto, solo quedan las pruebas del Análisis Visual y terminar la memoria.

7. Análisis de métricas de similitud

En este apartado se detallará el desarrollo del trabajo, justificando las elecciones de los hiperparámetros y decisiones importantes que se han ido tomando a lo largo del proyecto. En primer lugar, está la selección del corpus.

7.1. Elaboración del corpus

En una de las reuniones con mi director del TFG me proporcionó un conjunto de 835 trabajos de investigación en inglés en formato PDF. En un principio tenía planteado usar un módulo de Python para extraer el texto, pero por motivos de calidad y tiempo de ejecución acabé utilizando 4 (Apache Tika, PyPDF2, PdfMiner.Six y Fitz) y decidí quedarme con el que más palabras válidas (existen en diccionario inglés) extraía para cada documento.

En cuanto al preprocesado de documentos, según el embedding era necesario un proceso distinto de modo, ya que BERT tiene su propio tokenizador, mientras que Doc2Vec también tiene su propio método de preprocesado, y afortunadamente, el resultado de este es compatible con el formato de entrada para MUSE, ya que convierte a minúsculas, elimina caracteres no alfabéticos y las

‘stopwords’, pues estos aparecen abundantemente y apenas aportan significado útil a la hora de clasificar y hacer grupos.

Con la finalidad de ver si la calidad de los documentos afectaba a resultados creé un par de módulos más con la idea hacer seleccionar de forma sencilla unos documentos en función de varias características. El proceso de selección está compuesto por dos pasos:

20

1. Ejecutar calcReport.py – Esto examina cada fichero de texto, que habrá como mucho 4 (uno por conversor de pdf a txt), y cálcula la métrica, que en este caso es la mencionada anteriormente, número de palabras que pertenecen al diccionario (el diccionario es un fichero de texto, y para otro idioma es cuestión de descargar las palabras de internet y cambiar una línea de código. Esto genera un informe con las métricas y los nombres de los documentos. Además, para cada documento hace una copia del .txt con mejor métrica de las 4 posibles y lo ubica en una carpeta ‘best’.

2. Ejecutar bestSelector.py. Tiene 2 opciones de selección, por cantidad de documentos y por calidad de métrica.

Debido a la limitación de BERT, cuyo límite de tokens es 512, y sumado al hecho de que los documentos que el fichero de texto tiene menos de 1000 palabras válidas una vez se ha tokenizado, al hacer una inspección manual, la mayoría tiene mucho menos texto que el pdf original, es decir, la conversión pdf a texto ha sido de baja calidad. Además, esto implica que tenemos una muestra muy pequeña del documento original, y según la sección del documento a la que pertenece puede variar en gran medida el resultado. Por estos motivos se ha realizado una selección con parámetro VALID_WORDS = 1000, y se ha verificado mediante un muestreo de 20 documentos que el texto extraído es aceptable. Esto da como resultado 747 documentos.

Fig. 2: hiperparámetros de bestSelector.py. Fuente: Elaboración propia.

21

7.2. Embedding

7.2.1 Doc2Vec

Para conseguir el máximo rendimiento debemos entender como calcula Doc2Vec los embeddings, y como afectan los hiperparámetros al modelo. A continuación, se usarán de forma intercambiable la palabra párrafo (por respeto al autor) y documento. En primer lugar, hay dos métodos de entrenar el embedding de un documento: Modelo de Memoria Distruibida de Vectores de Párrafo (PV-DM) y una versión Bolsa de Palabras de Vectores de Párrafo (PV- DBOW).

PV-DM funciona tomando aleatoriamente un segmento contiguo de palabras y prediciendo una palabra interna (que no sea ni la primera ni la última) utilizando como entrada el resto de palabras del contexto y el embedding del documento. Por ejemplo, en la figura inferior la secuencia sería [the, cat, sat, on], y la palabra a predecir ‘on’, para ello tiene un contexto, que en este caso son las 3 palabras anteriores. Se permite especificar como combinar los embeddings de las palabras del contexto y del párrafo.

Por otro lado, PV-DBOW ignora el contexto de las palabras en la entrada. Lo que ocurre es que se fuerza al modelo a predecir palabras aleatoriamente seleccionadas dentro de un documento. Cabe destacar que este método también resulta en un menor

tamaño, pues basta con almacenar los pesos de la red neuronal, mientras que en el anterior se necesita adicionalmente los embeddings de palabras. Además, aquí no importa el orden de las palabras, en PV-DM sí.

Fig. 3: Estructura PV-DM. Fuente: [3]

22 PV-DBOW puede

ser muy útil cuando no es tan importante el orden de las palabras, por ejemplo, cuando se clasifican listas de elementos: en “manzana, mango y limón” se puede cambiar el orden sin alterar el resultado, mientras que, en nuestro

caso concreto, para captar el significado de las frases es importante el orden de las palabras, por tanto, se utilizará el Doc2Vec con PV-DM, por lo que se establece el hiperparámetro dm=1.

A continuación, están los hiperparámetros más importantes, que tienen un gran impacto directo en el tamaño, tiempo de ejecución y calidad del modelo. Son vector_size y epochs, que determinan el tamaño del embedding de documentos y el número de iteraciones de entreno del modelo respectivamente.

En la documentación oficial de la librería no hay mención a como ajustarlos, aunque investigando online he encontrado un consenso en que, a mayor cantidad de documentos, más iteraciones, y también cuanto más breves estos documentos, más iteraciones.

En cuanto al embedding, depende del nivel de detalle que necesitamos a la hora de diferenciar y clasificar los documentos, y se recomienda que a mayor longitud/cantidad o variedad de documentos, mayor sea el vector_size, no obstante, no hay consenso sobre ninguna fórmula para determinar el número exacto. Aun así, es importante conocer los efectos de los extremos en el caso de vector_size. Si el valor es excesivamente alto, puede resultar en overfitting, y el modelo no será capaz de realizar inferencias de calidad con documentos nuevos.

Si por el contrario es muy bajo, no será capaz de diferenciar los documentos por falta comparaciones.

Es por esto que para el tfg se probarán múltiples valores para ambos hiperparámetros y se mirará una métrica comentaremos a continuación para seleccionar el más adecuado.

Fig. 4: Estructura PV-DBOW. Fuente: [3]

23

La métrica consiste en calcular mediante KMeans un agrupamiento con k grupos, donde k itera de 1 a 50. Para cada k se calcula la suma de distancias al cuadrado entre los centros y sus vecinos del mismo cluster. Esto se gráfica y se determina el elbow, que no es más que la k para la cual la reducción en la métrica para k+1 es notablemente inferior. En este ejemplo de internet resulta sencillo detectar el punto óptimo. No obstante, en nuestro caso, no es trivial encontrarlo, por lo que se recurrió a una detección programática. Debido a la naturaleza del corpus, cuyos trabajos están asociados a departamentos de investigación, se espera que el elbow no esté muy alejado del número de departamentos.

Puesto que Doc2Vec recomienda mantener la vector_size entre 100 y 300, se usarán 50, 100, 200, 300 para vector_size y 2, 5, 10, 25 para epochs. Teniendo en cuenta que por defecto vector_size = 100 y epochs = 10, exploramos valores superiores e inferiores en las pruebas.

Fig. 5 Ejemplo de Elbow sencillo. Fuente: [2]

24

En esta tabla de gráficas se aprecia como con vector de 50, hay una alta variabilidad al aumentar ligeramente las iteraciones: de 2 a 5 el Elbow prácticamente se duplica (de 9 a 17). Por tanto, se descarta VS 50. Si miramos las últimas dos columnas, donde tenemos 10 y 25 iteraciones, vemos que la línea tiene más ruido que con iteraciones <= 5, sobre todo para clusters > 20. Tampoco se considera aceptable 2 iteraciones, y como queda 5 iteraciones y VS =100, 200, y 300, para los cuales tenemos el mismo Elbow, prevalece el de menor tamaño, 100. Finalmente, los hiperparámetros seleccionados son VS = 100 y EP = 5.

Fig. 6 Elbow de Doc2Vec para varias iteraciones (EP) y tamaños del vector (VS). Fuente:

Elaboración propia.

Doc2Vec Elbow

25

7.2.2 MUSE

MUSE tiene un punto fuerte frente a los demás embeddings, y es que se ha entrenado con artículos de Wikipedia en 30 idiomas. Esto hace posible y fácil el comparar documentos de distintos idiomas de forma nativa, lo cual siempre dará mejores resultados que utilizar algún traductor y después comparar. No obstante, en esta tarea el corpus está todo en inglés por lo que el resultado, no pone a prueba el punto fuerte de MUSE, sino solo la calidad de sus embeddings, y en caso de ser alta, se puede esperar buenos resultados al realizar la misma tarea con documentos en varias lenguas. En cuanto al tamaño de los embeddings, MUSE utiliza vectores de longitud 300.

Para obtener embeddings de palabra primero se carga el modelo, que pesa 600 MB, y tarda 24 segundos, lo cual me parecía bastante. De modo que investigué y encontré alguien que opinaba como yo, y se propuso mejorar el tiempo de carga, y ya de paso el espacio ocupado. Su versión [27] utilizaba flotantes de 16 bits en vez de 64, y guardaba el modelo en formato binario en lugar de modo texto, consiguiendo una reducción en espacio del 80% (ahora 117 MB).

El tiempo de carga se redujo de 24 s a 0.21 s, siendo más de 100 veces más rápido.

En la siguiente gráfica se observa la distribución de error relativo:

26

El error en los nuevos embeddings es mínimo, y el creador comprobó que sus resultados fueron idénticos en una tarea de clasificación usando los dos modelos. Sin duda ha valido la pena el tiempo invertido en investigar si había una forma más eficiente de llevar a cabo esta tarea.

El último paso es combinar los word embeddings de MUSE en uno solo que represente el documento. Se consideraron varias opciones: concatenación, promedio y concatenación de max y min. En primera instancia se descartó la concatenación porque implica documentos con embeddings de distinto tamaño.

Por otro lado, el max y el min, (que se calcula a nivel de elementos del vector), según un estudio [28] no muestra apenas diferencia con la media, pero tiene el doble de tamaño, por tanto, se descarta. Finalmente queda aplicar el promedio de los embeddings de palabra. Cabe destacar que es posible aplicar un mayor peso a las palabras con mayor frecuencia en un documento y menor en el corpus. Esta técnica se conoce como TF-IDF (Term Frequency - Inverse Document Frequency), y en el mismo estudio se aprecia como los resultados mejoran un 2%.

No obstante, tiene una desventaja, y es que si se amplía el corpus sería necesario procesar de nuevo todos los documentos para calcular las frecuencias. Además, si calculamos el embedding de un documento ajeno al corpus, aquellas palabras

Fig. 7 Distribución del error absoluto con flotante de 16 bits. Fuente: [4].

27

no presentes en el corpus, carecerán de frecuencias en corpus, y o bien no contribuirán al embedding con su peso adecuado o bien será necesario recalcular todo de nuevo. Teniendo en cuenta esto se usará el promedio de los embeddings de MUSE para generar la representación del documento.

7.2.3. BERT

BERT, como ya se explicó al principio, no genera unos embeddings para cada palabra, sino que como su nombre indica (Bidirectional Encoder Represenatitions from Transformers), utiliza el contexto en ambas direcciones que rodea a una palabra para generar su embedding, de forma que ‘banco’ tenga representaciones muy distintas en ‘ingresó dinero en el banco’ y ‘un banco de atunes’, mientras que ‘ingresó dinero en el banco’ y ‘hubo un atraco en el banco’

la diferencia será menor. En este aspecto es muy potente, aunque tiene una limitación en cuanto a la entrada, y es que solo es capaz de generar embeddings para un máximo de 512 tokens (el 1 y el 512 están reservados), por tanto, para documentos no cabe en una ejecución.

Se han considerado las siguientes soluciones alternativas:

1. Dividir los documentos en bloques de 510 caracteres y combinar los embeddings haciendo un promedio, como se hizo para MUSE.

2. Tomar una muestra de 510 caracteres descartando el resto.

a. Muestra del principio b. Muestra del final

c. Muestra de k del principio y 510-k del final

En este estudio sobre cómo ajustar BERT para clasificación de textos [29] vemos en la siguiente figura el error en una tarea de clasificación de textos los resultados para distintos métodos. Se evalúan dos corpus, el IMDB que contiene 50,000 reseñas de películas con una media de longitud de 292

Fig. 8: % de error para corpus IMDB y Noticias Sogou de China. Fuente: [5]

28

tokens, y el Sogou, compuesto por 60,000 artículos de noticias con caracteres chinos, y una media de longitud de 737 tokens. El promedio obtiene peores resultados que las 3 alternativas que descartan el excedente para el corpus de IMDB, y con el de Sogou solo supera a la muestra del final. El claro ganador en ambos casos es el que muestrea del principio y del final, y los autores utilizan los k=128 primeros caracteres del principio y 382 del final. No obstante, este parámetro les ha funcionado para sus documentos, pero no tiene por qué coincidir en este trabajo, por tanto, se probará con k=128, 250, 382, y para determinar cuál se elige se seguirá el mismo procedimiento que con el Doc2Vec, es decir el Elbow cercano al número de grupos de investigación (que es 19 para nuestro corpus).

A continuación, se muestran los resultados del Elbow para las distintas combinaciones de muestro del principio y final.

De estas gráficas se puede observar resultados parecidos, y de no ser por el bache que hay en cluster=10 para first 256 y 384, probablemente el Elbow sería 9 o 10.

No obstante, recordando que el número de departamentos es 19, y si contamos los que tienen mínimo 10 documentos entonces hay 12 departamentos, me parece que el Elbow más apropiado es 12 o 13. Se utilizará el start=256 cuyo Fig. 9: BERT Elbow para distintos k=[128, 256, 384]. Fuente: Elaboración propia.

29

número de clusters es 13, ya que es más cercano al número de departamentos total.

7.2.4 Embeddings finales

Tras seleccionar los hiperparámetros en Doc2Vec y BERT, tenemos los siguientes Elbow, junto con MUSE que carece de hiperparámetros.

Si bien el Elbow de MUSE es bajo, no lo es de forma excesiva, y es de esperar que al hacer el promedio de embeddings de todo el documento, cuando estos son largos, las diferencias tienden a difuminarse, no obstante, más adelante se verá a calidad de los clusters para cada uno. Esto se aprecia en el eje y, pues en MUSE las distancias son 3 órdenes de magnitud menores que BERT y Doc2Vec.

Fig. 10: Elbow final Doc2Vec, MUSE, BERT. Fuente: Elaboración propia.

30

7.3. Análisis visual

Para reducir los embeddings a dos dimensiones principalmente se considera UMAP y t-SNE. A continuación, examinan los puntos fuertes de cada uno y que hiperparámetros se utilizan para obtener una visualización adecuada.

En primer lugar, UMAP utiliza una inicialización determinista, pues usa un grafo Laplaciano [30], mientras que t-SNE implementa una inicialización aleatoria [31]. Esto implica la necesidad de realizar múltiples ejecuciones con t- SNE y seleccionar aquella con resultados aceptables.

Por otro lado, veamos como se comparan a la hora de preservar la proximidad local y global para cada método. El resultado depende directamente de la función de coste, pues ambas construyen un grafo con n_componentes dimensiones, que es lo más parecido posible estructuralmente al grafo original en n dimensiones. Para el caso de UMAP la función de coste es entropía cruzada (CE), y para t-SNE se utiliza divergencia de Kullback-Leibler (KL). En las siguientes figuras se muestra el coste para UMAP y t-SNE para las distancias entre puntos en dimensiones de entrada, X, y para dimensiones reducidas, Y.

Fig. 11: Coste de divergencia de KL – función de coste de t-SNE. Fuente: [6]

31

Para preservar las distancias globales debería haber un coste alto cuando X es alto e Y bajo, y viceversa. Se observa claramente como en t-SNE no hay penalización para puntos alejados en dimensiones altas, pero cercanos en bajas dimensiones. Mientras que en UMAP es el caso opuesto: hay una elevada penalización cuando se reduce las distancias en bajas dimensiones a puntos distantes en dimensiones altas. La única forma de preservar una mejor estructura

global es utilizar hiperparámetros superiores a los recomendados en la documentación (de 5 a 50): No obstante, esto supone un esfuerzo computacional adicional, y de nuevo, no hay certeza de alcanzar los resultados globales que UMAP garantiza gracias s u función de coste. Además de que los requisitos en computacionales no son únicamente temporales, sino también de memoria, donde con 1.3 millones de puntos y dotado de 512 TB de RAM fueron insuficientes para alcanzar perplejidad 500. Por suerte para este trabajo los datos manejados son órdenes de magnitud inferior y no se ha materializado estos problemas.

Fig. 12: Coste de Entropía Cruzada – función de coste de UMAP. Fuente: [6].

32

7.3.1 t-SNE

En t-SNE fundamentalmente tenemos 3 hiperparámetros esenciales a probar

1.

2.

3.

Como ambos reducen a 2 dimensiones, el hiperparámetro n_componentes

= 2 y no requiere pruebas. Por defecto la perplejidad vale 30, y se recomiendo valores entre 5 y 50, y mayores valores pueden ser necesarios para muchos puntos. Se probarán los valores siguientes: [2, 5, 15, 30, 50, 100].

El número máximo de iteraciones es 1000 por defecto, aunque viendo que llegan al límite y en la iteración 950-1000 se reduce el error de manera importante, considero importante aumentarlo a 5000, para dar tiempo a que converja, de modo que la gráfica anterior y todas en adelante para t-SNE serán con máximo de 5000 iteraciones.

Finalmente, la métrica por defecto para ambas técnicas es la ‘euclídea’ y es posible seleccionar otras, pasar unas distancias precalculadas, e incluso una función. Las métricas a analizar son la euclídea y el coseno.

33

Fig. 13: t-SNE euclídea, perp. = [2, 5, 15, 30, 50, 100] – Doc2Vec, MUSE, BERT. Fuente: Elaboración propia.

34

Tras graficar para diversas perplejidades se considera perplejidades 5 y 15 como las más adecuadas, ya que valores superiores tienden a esparcir los clusters sin ofrecer más claridad, sobre todo en Doc2Vec y algo menos en BERT. Con valores inferiores a 5 no se aprecia agrupamiento alguno. Se aprecian más elementos desconectados de su cluster, comparando el MUSE de 30 con 15, se nota también como el grupo rosa se divide en 2. A continuación se muestra la gráfica para perplejidad 10, con el fin de mantener el buen agrupamiento de BERT y MUSE conseguir un resultado mejor en Doc2Vec. Se utiliza perp=10 de ahora en adelante para la métrica=’euclídea’.

Por último, se prueba la métrica = coseno con las perplejidades 5, 10, 15, 30, es decir, descartando 2, 50, 100, y añadiendo 10, pues se ha visto que ha ofrecido buenos resultados.

Fig. 14: t-SNE euclídea, perp. = 10 – Doc2Vec, MUSE, BERT. Fuente: Elaboración propia.

35

Los resultados son similares con la métrica coseno, con perplejidad 10 parece dar buen agrupamiento, sobre todo en MUSE, aunque para BERT y Doc2Vec hay varios clústeres adyacentes.

Fig. 15: t-SNE ‘coseno’ para diversos núm. vecinos. – Doc2Vec, MUSE, BERT. Fuente: Elaboración propia.

36

7.3.2 UMAP

En UMAP se centra el análisis en 3 hiperhiperparámetros:

1.

2.

3.

El número de vecinos por defecto es 15, y se estudiarán valores entre 2 y 200. Min_dist es 0.1 por defecto, y se probarán valores de 0.0 a 0.99. La métrica es equivalente al caso de t-SNE, y entre muchas están la euclídea y el coseno.

37

Fig. 16: UMAP euclídea para vecinos = [2, 25, 50, 100, 150, 200]. – Doc2Vec, MUSE, BERT. Fuente:

Elaboración propia.

38

Se descarta vecinos 2 por ser una nube uniforme y mezclada. Vecinos 150 y 200 parecen iguales y no muestran mejoría respecto a vecinos 100, por tanto, se descartan. Quedan vecino 25, 50, y 100, y se aprecia en vecinos 25 como MUSE tiene el cluster amarillo partido en 2 y en vecinos 50 se une. Para Doc2Vec y BERT apenas hay cambios, por lo que se utiliza vecinos=50.

Ahora queda determinar el hiperparámetro min_dist, con los valores siguientes: [0.0, 0.01, 0.15, 0.5, 0.9]. Se muestra en la gráfica anterior y de nuevo los extremos no tienen buena pinta: se descartan los valores 0.0, 0.9, 0.5, y se mostrará otra gráfica con valores entre 0.01 y 0.15. Además, dado que MUSE aparece notablemente más condensado que BERT y Doc2Vec se ha examinado el rango de los elementos en el vector de embeddings, y este es el resultado:

Doc2Vec min = -7.674 max = 6.801 rango = 14.475 MUSE min = -0.174 max = 0.154 rango = 0.328 BERT min = -2.180 max = 2.603 rango = 4.783

Viendo que en Doc2Vec y BERT el rango es 45 y 14 veces el de MUSE, es comprensible que la distancia entre los embeddings esté en distintos órdenes de magnitud. Para solucionar esto hay 2 métodos.

El primero sería normalizar los embeddings para que el rango sea de -1 a 1 en los 3 casos, y después pasarlos por UMAP. La segunda opción es determinar el min_dist para cada embedding por separado. Para normalizar y preservar el significado es importante escalar todos los números por igual, por tanto, en vez de ajustar los negativos y positivos según el negativo más bajo y el positivo más alto, se coge el máximo en valor absoluto de los 2 y se escala consecuentemente:

Doc2Vec min = -1.0 max = 0.886 rango = 1.886 MUSE min = -1.0 max = 0.884 rango = 1.885 BERT min = -0.837 max = 1.0 rango = 1.837

Los nuevos rangos son muy similares. Ahora se muestra la gráfica para las distancias con vecinos =50.

Fig. 17: Normalización de embedding. Fuente: Elaboración propia.

39

A pesar de tener los embedding normalizados, cuando min_dist < 0.3 MUSE se junta más que BERT y Doc2Vec. Por este motivo se selecciona un min_dist distinto para MUSE. Se ha explorado otros hiperparámetros (spread, local_connectivity) con el fin de obtener una visualización de BERT y Doc2Vec con clusters más definidos y separados entre sí, pero no ha habido éxito.

Finalmente, min_dist para Doc2Vec=0.08, MUSE=0.3, BERT=0.08.

Fig. 18: UMAP euclídea - test min_dist – embeddings normalizados. Fuente: Elaboración

40

De nuevo se grafica con los mejores vecinos =25, 50, 100 y las distancias seleccionadas empíricamente.

Los resultados de Doc2Vec y BERT dejan mucho que desear, y en cuanto al hiperparámetro vecinos el 25 parece dar resultados similares, aunque en Doc2Vec aumenta ligeramente la separación entre algunos clusters (véase el azul claro de la parte inferior, y el naranja de la zona derecha).

Fig. 19: UMAP euclídea - test vecinos – embeddings normalizados. Fuente: Elaboración propia.

41

Para la métrica coseno se procede a testear los hiperparámetros 25, 50, 100, con las mismas min_dist seleccionadas previamente. Se determina neigh=25, ya que el resto de ejemplos parece formarse más aglomeración como BERT en vecinos 50 o MUSE vecinos 100, o esparcirse sin mostrar buena separación entre clusters como Doc2Vec vecinos = 100.

De la gráfica anterior se observa como MUSE se condensa más que los demás a pesar de la normalización y de un min_dist superior. Aún así, es el único capaz de distinguir el cluster azul oscuro. A diferencia de la métrica euclídea, aquí parece haber algo más de separación entre clusters para Doc2Vec, por lo demás, es similar, y se fija vecinos = 50.

Fig. 20: UMAP ‘coseno’, vecinos = [25, 50, 100] – embeddings normalizados. Fuente: Elaboración propia.

42

7.4. Elaboración del corpus NG20

Ahora se muestran los resultados que se obtienen con un corpus mejor preparado, y directamente en formato texto, que tiene una etiqueta asignada a cada artículo. Denominado News Group 20 (NG20), contiene 18000 artículos de grupos de noticias, y hay 20 categorías disjuntas.

El 90% de los documentos tiene menos de 1599 palabras. Por tanto, se opta por descartar los más extensos y los extremadamente cortos. Más concretamente se limita la extensión a 510 tokens, con el fin de que BERT capture todo el significado del documento, y se impone un límite inferior de 150 tokens. Esto da un total de 1667 documentos etiquetados.

Se procede de igual forma que el anterior experimento, con la excepción de que el Elbow no determina el número de clusters para t-SNE y UMAP, sino que sirve un propósito meramente informativo, pues cuanto más cerca esté del número de categorías (20), mejor.

No obstante, se ha establecido un mínimo de documentos por categoría de 50, con el fin de no tener grupos insignificantes, teniendo en cuenta que hay +1600 documentos.

En total hay 13 categorías distribuidas de la siguiente manera

Fig. 21: Número de documentos por categoría Fuente: Elaboración propia.

Número de documentos por categoría – corpus

43

7.5. Embedding Doc2Vec

Los resultados son curiosos, pues para 2, 10, y 25 iteraciones, no varía el Elbow con distintos tamaños de vectores. No obstante, el único con 25 iteraciones es el único momento en que se detecta un Elbow cercano a 13, sin importar demasiado el tamaño del vector, por ello no parece beneficioso utilizar VS=300, sino que se usará VS=100, y 25 iteraciones.

Fig. 22: Doc2Vec Elbow - corpus ng20. Fuente: Elaboración propia.