Implementación de una herramienta basada en PLN para la detección y anonimización de datos personales en documentos

Universidades de Burgos, León y Valladolid Máster Universitario Inteligencia de Negocio y Big Data en Entornos Seguros TFM del Máster Inteligencia de Negocio y Big Data en Entornos Seguros Implementación de una herramienta basada en PLN para la detección y anonimización de datos personales en documentos Presentado por José Manuel Simón Ramos en Universidad de Valladolid 2 de septiembre de 2021 Tutores: Aníbal Bregón Bregón Jorge Silvestre Vilches i Resumen En los últimos años, el avance en el campo del Aprendizaje Automático, unido a las mejoras del hardware, y al aumento del volumen de los datos, ha motivado la utilización de técnicas de aprendizaje que empleen estos datos para automatizar procesos o extraer conocimiento a partir de los mismos. Desde el punto de vista del campo del Procesamiento del Lenguaje Natural (PLN), la utilización de los datos para generar nuevos modelos se encuentra afectada debido a la existencia de información de carácter personal en los mismos. Esto, unido a la fuerte legislación vigente sobre la Protección de Datos, hace que las administraciones y organizaciones deban tener una mayor precaución y control a la hora de utilizar o compartir documentos en los que se aparezca información personal. El presente Trabajo Fin de Máster aborda la problemática de la detección y anonimización de entidades personales existentes en documentos administrativos (permisos, inspecciones, convenios, etc). En la línea con lo anterior, el proyecto plantea una propuesta genérica y eficiente de pipeline enfocada a la anonimización y generación de reemplazos para las entidades detectadas. Esta propuesta busca no solo poder ser empleada para detectar y anonimizar entidades en este tipo de documentos, sino que pretende ser una solución genérica para abordar la problemática de la detección y anonimización de entidades en cualquier tipo de documentos. Descriptores Aprendizaje Automático, Procesamiento del Lenguaje Natural, Anonimización, Python, Spacy, OCR. ii Abstract In recent years, progress in the area of Machine Learning, together with hardware improvements, and the increase in the volume of data, has motivated the use of learning techniques that use this data to automate processes or extract knowledge. From the point of view of Natural Language Processing (NLP), the use of data to generate new models is affected by the existence of personal information in them. This, combined with the strong legislation in force on Data Protection, means that administrations and organizations must be more cautious and have greater control when using or sharing documents which personal information appears. This Master Thesis addresses the problem of detection and anonymization of personal entities in administrative documents (permits, inspections, agreements, etc.). In addition, the project presents a generic and efficient proposal of pipeline focused on the anonymization and generation of replacements for the detected entities. This proposal aims not only to be used to detect and anonymize entities in this type of documents, but also to be a generic solution to address the problem of detecting and anonymizing entities in any type of documents. Keywords Machine Learning, Natural Language Processing, Anonymization, Python, Spacy, OCR. Índice General Índice General iii Índice de Figuras vi Índice de Tablas viii Índice de Código xi Parte I Introducción y Contexto del Proyecto 1 1 Introducción 3 1.1. Motivación ............................. 6 1.2. Objetivos .............................. 7 1.3. Herramientas Utilizadas . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Tecnologías Utilizadas . . . . . . . . . . . . . . . . . . . . . . . 9 1.5. Organización de la Memoria . . . . . . . . . . . . . . . . . . . . 11 2 Estimación y Presupuestos 13 2.1. Estimación ............................. 13 2.2. Presupuestos ............................ 21 2.3. Balance final del Proyecto . . . . . . . . . . . . . . . . . . . . . 23 2.3.1. Planificación Temporal . . . . . . . . . . . . . . . . . . . 23 2.3.2. Planificación Económica . . . . . . . . . . . . . . . . . . 24 3 Contexto de Desarrollo 25 3.1. Procesamiento del Lenguaje Natural . . . . . . . . . . . . . . . 25 3.1.1. Enfoques para el Procesamiento del Lenguaje Natural . 28 3.1.2. Desafíos del Procesamiento del Lenguaje Natural . . . . 29 3.1.3. Aplicaciones del Procesamiento del Lenguaje Natural . . 32 3.2. Reconocimiento de Entidades Nombradas . . . . . . . . . . . . 33 iii iv Índice General 3.2.1. Proceso de Creación de un Sistema de Reconocimiento de Entidades Nombradas . . . . . . . . . . . . . . . . . 35 3.2.2. Librerías orientadas al Reconocimiento de Entidades Nombradas ......................... 42 3.3. Spacy ................................ 47 3.3.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.2. Pipeline........................... 49 3.3.3. Displacy........................... 51 3.4. Anonimización de Documentos . . . . . . . . . . . . . . . . . . 52 3.5. Reconocimiento Óptico de Caracteres (OCR) . . . . . . . . . . 55 4 Estado del Arte 59 Parte II Implementación del Proyecto 65 5 Pipeline Desarrollado 67 6 Conjunto de Datos del Corpus 71 6.1. Preparación del Conjunto de Datos . . . . . . . . . . . . . . . . 77 7 Construcción del Modelo 81 7.1. Proceso de Entrenamiento . . . . . . . . . . . . . . . . . . . . . 82 7.2. Evaluación de los hiperparámetros . . . . . . . . . . . . . . . . 83 7.2.1. Evaluación de Resultados Globales . . . . . . . . . . . . 85 7.2.2. Evaluación de Resultados a nivel de Entidad . . . . . . 91 7.3. Mejora de los resultados utilizando Expresiones Regulares . . . 93 8 Sistema de Generación de los Reemplazos 99 8.1. Generación de reemplazos basados en Grafos . . . . . . . . . . 101 8.1.1. Creación del Grafo General . . . . . . . . . . . . . . . . 104 8.1.2. Obtención de reemplazos en grafos . . . . . . . . . . . . 107 8.2. Generación de reemplazos basados en Diccionarios . . . . . . . 109 9 Herramienta Software 117 9.1. Descripción de los Actores . . . . . . . . . . . . . . . . . . . . . 117 9.1.1. Requisitos de Usuario . . . . . . . . . . . . . . . . . . . 117 9.1.2. CasosdeUso........................118 9.2. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . 122 9.3. Diseño................................124 9.3.1. Arquitectura Lógica . . . . . . . . . . . . . . . . . . . . 124 9.3.2. Diseño de la Aplicación . . . . . . . . . . . . . . . . . . 125 9.4. Implementación de la herramienta . . . . . . . . . . . . . . . . 128 9.5. Pruebas de Caja Negra . . . . . . . . . . . . . . . . . . . . . . . 134 9.6. Evaluación del Rendimiento . . . . . . . . . . . . . . . . . . . . 135 Índice General v Parte III Conclusiones Finales 141 10 Conclusiones y Trabajo Futuro 143 10.1.Conclusiones ............................143 10.2.TrabajoFuturo...........................145 Parte IV Bibliografía 147 Bibliografía 149 Parte V Apéndices 153 Apéndice A Contenido Adjunto 155 Apéndice B Instalación y Versiones 159 B.1. Versiones de las herramientas utilizadas . . . . . . . . . . . . . 159 B.2. Instalación de la herramienta . . . . . . . . . . . . . . . . . . . 160 Apéndice C Manual de Usuario 163 Apéndice D Configuración de la Herramienta 167 Índice de Figuras 1.1. Evolución de las revisiones de artículos de Inteligencia Artificial. . 3 2.1. Diagrama de Gantt del proyecto. . . . . . . . . . . . . . . . . . . . 20 3.1. Ejemplo de Reconocimiento de Entidades Nombradas utilizando el modelo base de Spacy en castellano. . . . . . . . . . . . . . . . . . 34 3.2. Arquitectura de Spacy. . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3. Pipeline deSpacy. ........................... 51 3.4. Ejemplo de Visualización en Displacy en modo “Dependencia”. . . 52 3.5. Ejemplo de Visualización en Displacy en modo “Entidad”. . . . . . 52 3.6. Tipos de anonimización en función del estado del documento. . . . 53 3.7. Ejemplo segmentación mediante histogramas. . . . . . . . . . . . . 57 3.8. Ejemplo de normalización y segmentación de la imagen en formularios. 57 4.1. Flujo de detección y extracción de entidades del primer NER basado en heurísticas y en reglas escritas. . . . . . . . . . . . . . . . . . . 59 4.2. Tendencias de técnicas para la extracción de entidades nombradas entextos. ................................ 61 4.3. Tipos de técnicas para la anonimización de entidades nombradas entextos. ................................ 63 5.1. Estructura de componentes del pipeline desarrollado. . . . . . . . . 68 5.2. Desglose del flujo del “Componente Extracción de Texto”. . . . . . 68 5.3. Ejemplo de PDF anonimizado una vez finalizada la ejecución del pipeline.................................. 70 6.1. Estructura de los documentos utilizados. . . . . . . . . . . . . . . . 72 6.2. División de los datos en los subconjuntos de Entrenamiento, Validación yPrueba. ................................ 79 7.1. Flujo de entrenamiento de un modelo en Spacy. . . . . . . . . . . . 83 vi Índice de Figuras vii 7.2. Comparativa de la métrica F1 de los modelos enfocados a la Eficiencia. 89 7.3. Comparativa de la métrica F1 de los modelos enfocados a la Precisión. 89 7.4. Comparativa de las métricas de los modelos seleccionados. . . . . . 91 8.1. Estructura del flujo para la generación de los reemplazos. . . . . . 101 8.2. Ejemplo de entidades de un documento antes de realizar las conexiones. 102 8.3. Ejemplo de entidades del documento tras haber establecido las conexiones. ...............................104 8.4. Ejemplo reducido de la estructura del grafo general. . . . . . . . . 106 8.5. Ejemplo de búsquedas de isomorfismos de subgrafos. . . . . . . . . 107 8.6. Ejemplo de división de componentes para simplificar el grafo. . . . 109 8.7. Estructura del diccionario general implementado. . . . . . . . . . . 110 8.8. Flujo para la comprobación del tipo de entidad del DNI (DNI, NIE, CIF). ..................................114 8.9. Formato número IBAN. . . . . . . . . . . . . . . . . . . . . . . . . 115 9.1. Diagrama de Casos de Uso de la herramienta. . . . . . . . . . . . . 119 9.2. Arquitectura Lógica de la Herramienta. . . . . . . . . . . . . . . . 125 9.3. Desglose del tiempo de ejecución entre las distintas etapas del pipeline. 137 9.4. Desglose del tiempo de ejecución entre las distintas etapas del pipeline (sin tener en cuenta el proceso de OCR). . . . . . . . . . . 137 9.5. Incremento del tiempo de ejecución del pipeline en función del número de páginas del documento. . . . . . . . . . . . . . . . . . . 138 9.6. Incremento del tiempo de ejecución en la generación de los reemplazos en función del número de entidades del documento. . . . . . . . . . 139 9.7. Incremento del tiempo de ejecución en la detección de entidades (NER + RegEx) en función del número de entidades del documento. 140 A.1. Estructura de directorios de la entrega. . . . . . . . . . . . . . . . 156 A.2. Estructura de subdirectorios del directorio: /app...........157 B.1. Vista de Inicio de la Herramienta. . . . . . . . . . . . . . . . . . . 161 B.2. Estado de la ventana de la terminal tras el despliegue de la herramienta. .................................161 C.1. Herramienta: Examinar Documento para anonimizar. . . . . . . . 164 C.2. Herramienta: Cargar Documento y aplicar el modelo NER. . . . . 164 C.3. Herramienta: Anonimizar Documento. . . . . . . . . . . . . . . . . 165 C.4. Herramienta: Exportar Documento anonimizado. . . . . . . . . . . 166 C.5. Herramienta: Ejemplo del PDF anonimizado generado. . . . . . . . 166 Capítulo 1 Introducción En los últimos años, el interés y la popularidad de la Inteligencia Artificial ha sufrido un gran crecimiento, y se espera que este siga aumentando. Según el “Artificial Intelligence Index Report 2021” [38], elaborado por la Universidad de Stanford, las revisiones de artículos científicos, cuyo tema principal es la Inteligencia Artificial, ha pasado de ser de un 1,3% del total de los artículos científicos en el año 2012, a un 3,8% en el año 2019. Figura 1.1: Evolución de las revisiones de artículos de Inteligencia Artificial. Fuente: [38]. La digitalización y la generación masiva de datos procedentes de diversas fuentes (IoT, sensores, wearable, etc), unido al avance en la potencia del hardware de los equipos, han sido claves para impulsar esta rama de la Informática, cuyas expectativas de futuro son alentadoras. Gracias a ambos factores, actualmente es posible acceder de forma libre y gratuita a grandes colecciones de datos (a partir de ahora datasets) de gran calidad. Esto permite tanto estudiar el desempeño de las técnicas de Aprendizaje Automático actuales 3 4Capítulo 1. Introducción para un determinado caso de uso, como poder investigar nuevas soluciones que permitan afrontar una determinada problemática. Sin embargo, existe un problema (desde el punto de vista de la Inteligencia Artificial) asociado a los datos: la privacidad. Si bien es cierto que existe una gran cantidad de datasets disponibles de forma abierta, existen muchos datos que, debido a las políticas de privacidad que tienen las empresas o los países, no pueden hacerse públicos, limitando la aparición de nuevas propuestas o el enriquecimiento de las existentes. Desde la perspectiva del Procesamiento del Lenguaje Natural, PLN (Natural Language Procesing, NLP, en inglés), esta problemática es más notoria, ya que muchas de las aplicaciones que tienen las técnicas de PLN involucran documentos o textos en los que aparece información de carácter personal (limitando así su uso y difusión). Algunos ejemplos de estas técnicas son la extracción automática de datos en textos estructurados (por ejemplo formularios), la generación de texto (creación de chatbots para interactuar con una persona), o la identificación de menciones en documentos (obteniendo así menciones de un tipo concreto). En términos jurídicos, la utilización o difusión de documentos en cuyo contenido se encuentre información de carácter personal se encuentra enmarcada dentro del Reglamento Europeo de Protección de Datos 1 , también conocido como Reglamento General de Protección de Datos (RGPD). Este reglamento fue realizado por el Parlamento Europeo en combinación con el Consejo de la Unión Europea, siendo finalmente aprobado en abril de 2016 (aunque su aplicación no se realizó hasta mayo de 2018). El reglamento recoge como datos de carácter personal toda aquella información asociada a una persona identificada (cuya identidad es directamente conocida), o identificable (cuya entidad no se conoce directamente pero se puede obtener cruzando otras fuentes de datos). Algunos ejemplos de datos personales más importantes son: 1) Nombre y Apellido; 2) Dirección; 3) Números de Identificación (DNI, Pasaporte, etc); 4) Ingresos; 5) Direcciones IP; o 6) Datos clínicos (identificadores y datos personales de un individuo dentro del ámbito sanitario). Asimismo, desde el punto de vista de la administración pública española (sector en el que se encuentra enmarcado el presente proyecto), la detección y anonimización de las menciones personales en los documentos no se encuentra dentro de su flujo de trabajo habitual (por lo que a priori no es algo que afecte directamente a su funcionamiento). Sin embargo, cada vez es más habitual la divulgación de datos públicos por parte de las administraciones, fomentando así el desarrollo de nuevas propuestas que permitan extraer valor a partir de esos datos, o mejorar algún área concreta con la implementación de nuevas herramientas o sistemas. Algunos ayuntamientos como el de Segovia, el de 1 https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_es (Visitado el 29-06-2021). 5 Cáceres, el de Madrid, o el de Valladolid, disponen de portales web específicos para poder acceder a una gran variedad de datos de la ciudad 2,3 (puntos de interés turísticos, restaurantes, hoteles, instalaciones, etc). Dentro de la publicación de los datos existen dos retos principales, los cuáles serán abordados en el presente proyecto: Necesidad de llevar a cabo un tratamiento sobre los documentos antes de su publicación. Este tratamiento estaría destinado a satisfacer las restricciones sobre los datos personales impuestas por el RGPD (no difusión y/o utilización de los datos personales para otros fines que aquellos para los que se ha autorizado su obtención y uso de manera explícita). La automatización del proceso de detección y anonimización de los datos personales en los documentos. A pesar de que los datos a publicar se pueden anonimizar de forma manual, el gran volumen de información que ha de procesarse, unido a la aparición de errores a nivel humano, hace que la inversión de tiempo y de recursos humanos a utilizar sea inviable para realizar esta labor de forma manual. Por otro lado, atendiendo a la aplicación y contexto en el que se encuentra enmarcado el proyecto, este se sitúa dentro de las tareas de Reconocimiento de Entidades Nombradas (Named Entity Recognition, NER, en inglés), de textos escritos en castellano. Estas tareas se encuentran orientadas al reconocimiento y extracción de información en textos estructurados (Ver Apartado 3.2). Sin embargo, el caso de uso a resolver va más allá del propio reconocimiento de entidades personales, ya que aborda tareas de Reconocimiento Óptico de Caractéres (OCR) (Ver Apartado 3.5) para extraer el texto del que se quieren obtener las entidades personales, anonimización de las menciones utilizando mecanismos de reemplazo eficientes (Ver Apartado 8), y tareas de creación y manipulación de documentos PDF con el contenido del texto anonimizado (Ver Apartado 5). Es por ello por lo que propuestas como las presentadas en el presente proyecto son de gran utilidad a la hora de detectar, extraer y anonimizar este tipo de menciones en documentos administrativos semi-estructurados o desestructurados, permitiendo un mejor manejo de los datos, así como un procesamiento de forma automática de los mismos, disminuyendo la cantidad de errores a nivel humano, y aumentando la velocidad de procesamiento de los documentos. 2http://opendata.ayto-caceres.es (Visitado el 14-07-2021). 3 https://www.valladolid.es/es/temas/hacemos/open-data-datos-abiertos/catalogodatos (Visitado el 14-07-2021). 6Capítulo 1. Introducción En definitiva, se puede concluir con que el PLN es una de las ramas del Aprendizaje Automático más importantes en la actualidad. Sin embargo, la sensibilidad de los documentos necesarios para crear, validar y mejorar estos sistemas (debido a su contenido de carácter personal) hace que su uso o difusión se vean más restringidos que otro tipos de sistemas sin estas limitaciones. 1.1. Motivación Uno de los principales problemas que tienen las propuestas de Aprendizaje Automático enfocadas al Procesamiento de Lenguaje Natural viene dado por la privacidad de los datos necesarios para su creación, validación y mejora. La pérdida o filtración de datos personales pueden suponer grandes problemas para la empresa, administración o responsable afectados, suponiendo graves infracciones y multas debido a estos hechos. La implantación de mecanismos de Aprendizaje Automático que permitan detectar todos estos fragmentos de información permite tener un mayor control y gestión sobre estos. Además, esto permite realizar distintas acciones interesantes sobre los documentos, como extraer esas menciones para analizarlas, e incluso censurarlas o eliminarlas del documento, evitando así que se pueda relacionar con un individuo (anonimizar el documento). Este trabajo tiene los siguientes propósitos: 1) Detección y extracción de datos de naturaleza personal (menciones a personas), dentro de textos de carácter administrativo; y 2) Obtención de los textos de los documentos mediante el uso de OCR. Esto se debe a que un gran número de documentos se encuentran escaneados (por lo que no se puede obtener directamente el contenido del texto que aparece en él). Actualmente, el organismo público del que proceden los datos automatiza este proceso, por lo que cualquier avance o conclusión relativa a automatización será de gran utilidad para futuros proyectos. Por otra parte, unido a la automatización de la extracción de menciones personales, se va a abordar una de las aplicaciones que tienen este tipo de técnicas, la anonimización de los datos. En relación con esto, se desarrollará un sistema híbrido de anonimización genérico que permita sustituir las menciones personales detectadas por otras del mismo tipo, manteniendo la concordancia entre las mismas. Todo esto, en combinación con el manejo de documentos PDF permitirá generar un nuevo documento cuyas menciones del documento original estarán anonimizadas, y que será prácticamente indistinguible de un documento verdadero. Para ello se llevará a cabo el análisis y optimización de modelos y técnicas orientadas a la detección de entidades en textos, así como el estudio e implementación de diversas técnicas enfocadas a la generación de reemplazos. La propuesta presentada permitirá generar nuevas entidades para anonimizar un documento de una forma rápida y eficiente. Esta implementación se realizará 1.2. Objetivos 7 en forma de pipeline de componentes aislados, en el que cada componente realizará una acción concreta dentro del flujo. Además de esto, el desarrollo de este pipeline se hará de la forma más flexible posible. De este modo podrá ser utilizado para otro tipo de documentos, otro tipo de entidades diferentes a las propuestas, u otro contexto de aplicación. Todo ello sin la necesidad de realizar modificaciones significativas en el flujo de trabajo presentado. 1.2. Objetivos El presente Trabajo Fin de Máster afronta la problemática de detección y anonimización de entidades personales (nombres, apellidos, direcciones, matrículas de coche, etc) en textos de carácter administrativo (pagos al ayuntamiento, multas municipales, etc), así como su reemplazo por otras entidades del mismo tipo. Con todo esto, se generará un nuevo documento con valores realistas, pero sin ser identificativos de ninguna persona real. En esta línea de trabajo se identifican los siguientes objetivos y subojetivos: •OBJ-1: Obtención del corpus documental necesario para generar el modelo. - OBJ-1.1: Realización de un análisis exploratorio inicial de las entidades a detectar y de los documentos. - OBJ-1.2: Anotación de las entidades personales que aparecen en los documentos. •OBJ-2: Creación del pipeline para la detección de entidades y su anonimización. - OBJ-2.1: Comparativa entre los principales modelos de PLN orientados a la detección y extracción de entidades nombradas. - OBJ-2.2: Adaptación de técnicas de Reconocimiento Óptico de Caracteres (OCR) para la extracción del texto en documentos PDF. - OBJ-2.3: Implementación e incorporación de componentes adicionales al pipeline que complementen la detección de entidades del modelo. - OBJ-2.4: Desarrollo de mecanismos de reemplazo genéricos y eficientes para las entidades detectadas. •OBJ-3: Evaluación del pipeline de anonimización. •OBJ-4: Diseño e implementación de una herramienta orientada al usuario que permita anonimizar documentos a utilizando el pipeline desarrollado. 8Capítulo 1. Introducción •OBJ-5: Realización de la documentación técnica del proyecto. Con la finalización de los objetivos descritos anteriormente se pretende obtener una herramienta software (OBJ-4) que permita, a través de un documento dado, detectar las entidades de carácter personal que este contenga y generar un nuevo documento. Este nuevo documento mantendrá el contenido del documento original, a excepción de las entidades detectadas, las cuales habrán sido sustituidas por otras del mismo tipo durante su paso por el pipeline desarrollado (OBJ-2). Al mismo tiempo, se generará una memoria técnica (OBJ-5) en la que se plasmará todo el proceso de creación del modelo, la implementación de los mecanismos de reemplazo, evaluación de la herramienta, análisis software, etc, así como cualquier otra cuestión de interés relativa a su desarrollo. 1.3. Herramientas Utilizadas Para llevar a cabo la realización del proyecto se han utilizado las siguientes herramientas: Datasaur: Herramienta web diseñada para el etiquetado y exportación de datos de texto para diferentes propósitos en proyectos PLN. En el caso del proyecto, esta herramienta se ha empleado para etiquetar los distintos tipos de entidad que aparecen en los documentos procesados. No obstante, dispone de funcionalidad para realizar otro tipo de tareas como el etiquetado de dependencias entre palabras, el etiquetado de co-referencias, etc. GitLab: GitLab es un servicio web gratuito de código abierto enfocado a la gestión y control de versiones mediante Git. Este servicio fue lanzado en octubre de 2011, y además de la gestión de versiones con git permite la creación de grupos tanto a nivel de equipo como a nivel de repositorios, y la generación de wikis para cada uno de los repositorios. Jupyter Notebook: Jupyter Notebook es un proyecto de código abierto que fue creado en 2014 a partir del kernel IPython. Jupyter Notebook se encuentra implementada como una aplicación cliente-servidor que permite generar documentos web siguiendo un esquema de celdas ordenadas con entradas y salidas. Las celdas de los ficheros de Jupyter Notebook soportan lenguajes de programación como Python o R, así como lenguajes de marcado de texto como Markdown o Latex. Visual Studio Code: Editor de texto desarrollado por Microsoft y lanzado de forma oficial en al año 2016. Visual Studio Code proporciona un gran número de herramientas y extensiones que le permiten dar 1.4. Tecnologías Utilizadas 9 soporte a la mayoría de los lenguajes de programación, así como a distintos formatos de documentos, tales como Markdown (.md), Notebooks (.ipynb), o Latex (.tex). Además ofrece integración directa con Git, facilitando la gestión y control de versiones. 1.4. Tecnologías Utilizadas Las tecnologías que se han utilizado para desarrollar el proyecto han sido las siguientes: Python: Python es un lenguaje de programación multiparadigma lanzado en 1991. Actualmente, Python se encuentra administrado por la Python Software Foundation, bajo una licencia de código abierto. Además de esto, dispone de una gran comunidad detrás que no deja de desarrollar librerías que permiten extender su funcionalidad. Entre las muchas tareas que se pueden llevar a cabo con este lenguaje cabe destacar el desarrollo de aplicaciones web, desarrollo de juegos, análisis estadístico de datos, o creación y utilización de modelos basados en aprendizaje automático. Flask: Flask es un framework desarrollado por Armin Ronacher y escrito en Python que permite crear aplicaciones web de una forma rápida y sencilla. Se encuentra basado en la especificación WSGI Web Server Gateway Interface, y utiliza el motor de templates Jinja2, el cual permite situar distintos marcadores en las plantillas correspondientes a la página web cuyo contenido será generado y renderizado en tiempo de ejecución. FPDF: FPDF es una librería escrita en Python (aunque no es original, ya que fue desarrollada como un port 4 de la misma librería en PHP), que proporciona herramientas para generar documentos PDF. Git: Sistema de control de versiones que registra las modificaciones realizadas en los ficheros situados en un repositorio local. Esto permite generar distintos “puntos de control” sobre el código y mantener un registro de los distintos estados de este, pudiendo navegar entre las diferentes versiones que hayan tenido estos archivos. HTML y CSS: HTML y CSS son dos lenguajes de marcado y de diseño de texto respectivamente, que permiten crear estructuras de páginas web y darles estilo. Ambos lenguajes son considerados como unos pilares dentro del desarrollo de páginas web en el lado cliente, junto con JavaScript. Levenshtein: Python-Levenshtein es una librería desarrollada en Python que proporciona funcionalidad para obtener distintas métricas relacionadas con distancia y la similitud entre palabras. 4Adaptación de un programa a otra plataforma o lenguaje de programación. 10 Capítulo 1. Introducción Numpy: Numpy es una librería de código abierto escrita en Python que proporciona una gran colección de funciones matemáticas de alto nivel para realizar operaciones sobre matrices o vectores. Pandas: Pandas es una librería de código abierto para Python que permite tanto la manipulación como el análisis de datos. Para ello utiliza estructuras de datos propias (DataFrames). Esta librería es una de las más utilizadas en la actualidad, ya que permite realizar de una forma eficiente una gran variedad de acciones sobre los datos: inserciones, eliminaciones, filtrados, agrupaciones, obtención de métricas estadísticas, etc. Matplotlib y Seaborn: Matplotlib y Seaborn son dos librerías de alto nivel desarrolladas en Python enfocadas a la creación de gráficos. La principal ventaja que ofrecen ambas es que disponen de una integración directa con Pandas, lo que permite realizar visualizaciones de una forma rápida y sencilla en base a la estructura de los datos del DataFrame de Pandas. Networkx: Networkx es una librería de Python enfocada a la creación, manipulación y estudio de grafos. Además de ofrecer la funcionalidad básica para manejar estas estructuras, proporciona un gran número de funciones y algoritmos para realizar operaciones sobre los grafos: cálculo de caminos, obtención de componentes, extracción de subgrafos, etc. PDF2Image: Librería escrita y desarrollada en Python que permite transformar documentos en formato PDF a una imagen en distintos formatos (JPEG, JPG, PNG, etc). Pillow: Pillow es una librería gratuita de código abierto escrita en Python que permite abrir, modificar y guardar archivos en muchos formatos de imagen diferentes. Entre sus características se incluye la posibilidad de manipular la imagen a nivel de pixel, modificar la transparencia, nitidez, brillo, etc, y agregar texto a las imágenes, entre otras muchas funcionalidades más. Pytesseract: Pytesseract es una librería escrita en Python orientada al reconocimiento óptico de caracteres (OCR). Pytesseract utiliza el motor OCR Tesseract desarrollado en Java, actuando como wrapper entre Python y Java. Además dispone de soporte para un gran número de formatos de imagen comunes: JPEG, PNG, TIFF, GIF, etc. Spacy: Spacy es una librería de código abierto desarrollada en Python que ofrece una gran cantidad de opciones y funcionalidades para desarrollar proyectos enfocados al Procesamiento del Lenguaje Natural. Además de permitir crear modelos PLN desde cero, Spacy dispone de soporte nativo para más de 64 lenguajes diferentes. Por otra parte, Spacy proporciona 1.5. Organización de la Memoria 11 también distintos pipelines ya preentrenadas para realizar tareas básicas de PLN en 19 lenguajes. 1.5. Organización de la Memoria El presente documento se encuentra dividido y estructurado en capítulos en los que se abordan distintos aspectos de interés del proyecto. Los capítulos que conforman el documento, así como la temática de estos son: Capítulo 1. Introducción: En el Capítulo 1 se llevará a cabo una introducción del contexto en el que se engloba este proyecto, así como la motivación de este, y los objetivos que se pretenden lograr tras su finalización. Capítulo 2. Estimación y Presupuestos: En el Capítulo 2 se realiza la descripción de la metodología utilizada para realizar el proyecto. Además de esto, el capítulo aborda la estimación de tiempo y costes asociados a su desarrollo. Capítulo 3. Contexto de Desarrollo: A lo largo del Capítulo 3 se abordará el contexto en el que se encuentre desarrollado el proyecto. Por un lado, se tratará el tema del Procesamiento del Lenguaje Natural, así como sus características y aplicaciones mas habituales. Del mismo modo, se describirán las diferentes librerías y/o herramientas orientadas a la realización de proyectos utilizando esta rama del Aprendizaje Automático. Finalmente el capítulo concluye con la metodología para la extracción de textos a partir de imágenes, así como las principales características y estados de un documento desde el punto de vista de la anonimización. Capítulo 4. Estado del Arte: En el Capítulo 4 se llevará a cabo el estudio de anteriores propuestas relacionadas con la problemática a abordar en este proyecto. Capítulo 5. Pipeline Desarrollado: En el Capítulo 5 se realizará un breve recorrido sobre los diferentes componentes que conforman el pipeline desarrollado. Además de esto se describirán las principales características de estos, así como las consideraciones que se han tomado a la hora de implementarlo. Capítulo 6. Conjunto de Datos del Corpus: En el Capítulo 6 se realizará tanto la descripción, como el análisis de los documentos utilizados para entrenar el modelo de detección de entidades. Del mismo modo, se realizará la descripción, características y consideraciones de diseño de cada uno de los tipos de menciones a detectar. 18 Capítulo 2. Estimación y Presupuestos Tarea Descripción Dificultad T6.1 Desarrollo de la parte visual de la herramienta. 2 Puntos de Dificultad Implementar de la parte visual de la herramienta junto con los componentes de la vista que se utilizarán para interactuar con el pipeline desarrollado. T6.2 Desarrollo del método de extracción de textos de documentos. 2 Puntos de Dificultad Diseño de un método que permita extraer el texto a partir de un fichero PDF. T6.3 Integración del pipeline con la parte visual. 1 Punto de Dificultad Integración de la parte visual de la herramienta con la parte interna de la misma, es decir, conectar la vista con el pipeline de anonimización. Tabla 2.6: Desglose de las tareas asociadas a la Historia 6 del Proyecto. Tarea Descripción Dificultad T7.1 Documentación de la introducción y la descripción del proyecto. 3 Puntos de Dificultad Documentación de la parte relativa a la introducción y descripción del proyecto (motivación, objetivos, metodología, contexto, etc). T7.2 Documentación de la implementación del proyecto. 3 Puntos de Dificultad Documentación de la parte relativa a la implementación del proyecto. T7.3 Documentación de las conclusiones y anexos del proyecto. 1 Punto de Dificultad Documentación de las conclusiones obtenidas tras finalizar el proyecto, así como los apéndices necesarios para complementar la memoria técnica. Tabla 2.7: Desglose de las tareas asociadas a la Historia 7 del Proyecto. 2.1. Estimación 19 Para llevar a cabo el proyecto se han estimado un total de 45 Puntos de Dificultad a distribuir entre cada uno de los 4 bloques de tiempo en los que se divide el proyecto. Un punto importante que destacar es que a cada uno de estos bloques de tiempo se le ha asignado un total de 57 horas de trabajo efectivo, por lo que el total de horas efectivas en todos ellos equivale a las horas estipuladas para llevar a cabo el Trabajo Fin de Máster (57 horas · 4 bloques de tiempo = 228 horas). A pesar de que no existe una relación directa y objetiva entre Puntos de Dificultad y horas efectivas, es posible realizar una distribución de las tareas entre los distintos bloques de tiempo haciendo uso de esta medida. Para comenzar, se ha asignado al primer bloque de tiempo un conjunto de tareas por valor de 11 Puntos de Dificultad, dando inicio al primer bloque de tiempo del proyecto. Al finalizar cada bloque se lleva a cabo una comparativa entre los Puntos de Dificultad completados y los estimados, obteniendo así de forma aproximada el número de Puntos de Historia que se es capaz de abordar durante un bloque de tiempo. En la tabla 2.8 se muestra la distribución de las tareas entre los distintos bloques de tiempo. Del mismo modo, en la Figura 2.1 se presenta el diagrama de Gantt correspondiente a la planificación fijada para el proyecto. Cabe destacar que para simplificar tanto el análisis como las vistas, en esta planificación no se tomarán en cuenta ni las reuniones de seguimiento con los tutores, ni la realización del acto de defensa del proyecto. Bloque de Tiempo Inicio Fin Tareas Total Puntos de Dificultad Bloque de Tiempo #1 07/06/2021 20/06/2021 T1.1; T1.2; T1.3; T1.4; T4.1; T7.1 10 Bloque de Tiempo #2 21/06/2021 04/07/2021 T2.1; T2.2; T2.3; T3.1; T3.2 11 Bloque de Tiempo #3 05/07/2021 18/07/2021 T3.3; T4.2 T4.3; T4.4 12 Bloque de Tiempo #4 19/07/2021 01/08/2021 T5.1; T5.2; T6.1; T6.2; T6.3; T7.2; T7.3 12 Tabla 2.8: Distribución de tareas por bloques de tiempo. 20 Capítulo 2. Estimación y Presupuestos Figura 2.1: Diagrama de Gantt del proyecto. 2.2. Presupuestos 21 2.2. Presupuestos Una vez realizada la estimación y la planificación temporal del proyecto, se va a llevar a cabo una estimación de los costes asociados al mismo. En este presupuesto se van a incluir tanto los costes de las herramientas (hardware y software), así como los costes de los recursos humanos necesarios para su realización. Por un lado, desde el punto de vista del hardware, toda la implementación de la herramienta se ha llevado a cabo en un ordenador personal (Procesador I7-9850H, 64 bits, 16GB de RAM y 500GB SSD), por lo que hay que tener en cuenta su precio y su vida útil para obtener el coste asociado al proyecto. En cuanto al software utilizado, todas las herramientas son de código abierto, o software de pago con licencias gratuitas debido al rol de estudiante universitario, por lo que en ambos casos su coste ha sido nulo. Sin embargo, el entrenamiento y validación del modelo NER ha sido realizado sobre una máquina virtual proporcionada por el Departamento de Informática de la Universidad de Valladolid. Si bien es cierto que su uso no supone un coste directo en el proyecto, esta se tendrá en cuenta a la hora de realizar los presupuestos para que así estos sean más acordes a una situación real. No obstante, dado que no se conoce el coste de uso por hora de esta máquina virtual, se va a realizar el cálculo basándonos en una máquina virtual de Amazon Web Services (AWS) con unas especificaciones similares. Las especificaciones de la máquina virtual proporcionada por el Departamento de Informática son: Procesador 8 núcleos, 64 bits, 16GB de RAM y 30 GB de almacenamiento HDD. Unido a esto, para llevar a cabo todo el desarrollo del proyecto es necesaria una conexión a internet, así como el uso de dispositivos electrónicos, por lo que los costes asociados a ambos recursos se verán también reflejados en los presupuestos. Para ello se tomará el número de horas aproximadas que estos han sido utilizados, junto con su coste por hora. En la siguiente tabla (ver Tabla 2.9) se muestra el desglose de las herramientas hardware y software utilizadas, así como el coste asociado a cada una de ellas3,4: 3 El coste energético se ha calculado como la media de los costes por hora en España en los meses de junio y julio. 4 El coste de la máquina virtual se ha obtenido utilizando la calculadora de AWS para las instancias EC2 (alto rendimiento). 22 Capítulo 2. Estimación y Presupuestos Herramienta Coste (mes) Vida útil % de uso Coste Total Ordenador Personal 1.800e (coste total) 60 meses (5 años) 3,33% 59,94e Internet 30e2 meses 100% 60e Coste Energético 10,12e2 meses 100% 20,24e Máquina Virtual 58,66e0,46 meses (2 semanas) 25% 26,98e GitLab 0e- - 0e Visual Studio Code 0e- - 0e Anaconda 0e- - 0e Datasaur 0e- - 0e TOTAL 167,16e Tabla 2.9: Costes asociados a las herramientas y recursos hardware. Por otro lado, desde el punto de vista de los costes asociados a los recursos humanos, estos van a ser desglosados en función de los distintos roles que ha ido asumiendo el alumno a lo largo del desarrollo. Para realizar los cálculos de estos costes, se ha supuesto la dedicación habitual de un trabajador en una empresa en la actualidad (40 horas semanales o 160 horas al mes). En la Tabla 2.10 se muestran los distintos roles que el alumno ha tomado durante el desarrollo del proyecto, así como la dedicación en horas, y su coste asociado 5 : Rol Salario (mes) Horas Coste Total Jefe de Proyecto 3.292e30 617,25e Analista de Requisitos 2.545e48 763,50e Desarrollador Python 2.391e140 2.092,13e Desarrollador Web 1.583e10 98,94e TOTAL 3.571,82e Tabla 2.10: Costes asociados a los recursos humanos. Fuente: Linkedin Salary (Visitado 20-07-2021). Finalmente, teniendo en cuenta tanto los costes hardware y software, así como el coste de los recursos humanos, el coste total previsto para el proyecto es de 3.738,98 e , de los cuales 167,16 e se corresponden a los recursos hardware, y 3.571,82ea los recursos humanos. 5 El coste asociado a cada rol ha sido obtenido a partir de Linkedin Salary tomando como referencia el precio medio del puesto a nivel nacional. 2.3. Balance final del Proyecto 23 2.3. Balance final del Proyecto 2.3.1. Planificación Temporal Desde el punto de vista de la planificación temporal del proyecto, este se inició en la fecha prevista, y comenzó abordando las tareas T1.1, 1.2 y 1.3, orientadas a la obtención de los conocimientos necesarios para poder llevar a cabo el proyecto de forma satisfactoria. Estas tareas fueron finalizadas en el tiempo previsto, completando así la Historia de Proyecto H-01. Tras esto, se continuó en paralelo con las tareas 7.1 y 4.1, plasmando los conocimientos obtenidos en la documentación técnica del proyecto, y obteniendo los datos necesarios para poder generar las estructuras utilizadas posteriormente para generar los reemplazos. A pesar de que el bloque de tiempo contenía tareas por un valor de 10 Puntos de Dificultad, estas fueron finalizadas antes de acabar el bloque, por lo que se comenzó con la tarea T2.1 (correspondiente al siguiente bloque) y se aumentó el número de puntos de dificultad a abordar en los bloques posteriores. En el segundo bloque de trabajo se continuó con la tarea T2.1, y se completaron las tareas T2.2 y T2.3, finalizando así la Historia de Proyecto H-02 asociada a la obtención del conjunto de datos necesario para generar el modelo NER. Una vez se finalizaron estas tareas, se continuó con el desarrollo, y se realizaron las tareas T3.1 y T3.2, obteniendo un modelo NER optimizado para detectar las menciones en los documentos. Además de esto, al igual que ocurrió en el primer bloque de tiempo (y debido a que parte de una tarea ya había sido comenzada), se finalizaron las tareas asociadas a este bloque antes de lo planificado, por lo que se inició la tarea T3.3 correspondiente al siguiente bloque, y se volvió a aumentar el número de Puntos de Dificultad en los bloques sucesivos. En el tercer bloque de tiempo se finalizó lo que restaba de la tarea T3.3 y se abordaron las tareas T4.2, T4.3 y T4.4, dando fin a las Historias de Proyecto H-03 y H-04 (correspondientes a la creación de los componentes de detección de entidades y generación de reemplazos respectivamente). A diferencia de anteriores bloques, en este no hubo tanta diferencia entre la finalización de la última tarea con respecto al fin del bloque, por lo que se mantuvo el ritmo y no se añadieron más tareas a los siguientes bloques. Finalmente, en el último bloque se realizaron las tareas planificadas, concluyendo las Historias de Proyecto H-05, H-06 y H-07 (correspondientes a la integración de los componentes en la herramienta y a la redacción de la memoria del proyecto). A pesar de que este era el bloque con más tareas asociadas, estas fueron acabadas en el tiempo previsto, ya que muchas de ellas eran cortas y consistían en integrar las partes desarrolladas en tareas e historias anteriores. 24 Capítulo 2. Estimación y Presupuestos 2.3.2. Planificación Económica En cuanto a la planificación económica, dado que no ha habido ningún contratiempo en el desarrollo de la práctica, y todas las tareas han sido completadas en los tiempos fijados, esta no ha sufrido ninguna modificación frente a lo estimado anteriormente. Es por esto, por lo que los costes (tanto hardware como de recursos humanos) asociados al proyecto se mantienen exactamente igual: 3.738,98e. Capítulo 3 Contexto de Desarrollo 3.1. Procesamiento del Lenguaje Natural El Procesamiento del Lenguaje Natural, PLN (Natural Language Processing, NLP en inglés), es la rama de la Inteligencia Artificial que comprende las técnicas por las cuales se dota a una máquina de la capacidad para procesar, analizar, interpretar y representar texto escrito o hablado, como si fuese un ser humano [27]. El primer uso de este tipo de técnicas se remonta a la década de 1940, donde Weaver y Booth [13], [28] iniciaron un proyecto de PLN orientado a descifrar códigos enemigos durante la Segunda Guerra Mundial. Han pasado 80 años desde entonces y en la actualidad, se disponen de sistemas de PLN capaces de procesar, generar e interpretar tanto texto escrito como hablado. El método más representativo para simbolizar lo que sucede dentro de un sistema PLN es utilizar el modelo síncrono del lenguaje [21] (también conocido como “enfoque mediante niveles”). Este enfoque plantea la hipótesis de que el procesamiento del lenguaje humano se lleva a cabo de una forma estrictamente secuencial. Sin embargo, la investigación psicolingüística 1 sugiere que el procesamiento del lenguaje es un proceso mucho más dinámico, ya que un nivel puede interactuar con otro a pesar de que dichos niveles no se encuentren situados de manera contigua. Unido a esto, la introspección revela que el ser humano utiliza con frecuencia la información obtenida en niveles superiores de procesamiento para así ayudarse a entender la información situada en niveles inferiores [8]. Los distintos niveles del lenguaje ordenados de menor a mayor junto con su significado son los siguientes: Fonología: Es el nivel más bajo del lenguaje. Se encarga de la interpretación de los sonidos del habla de las palabras. Dentro de este nivel existen distintos tipos de reglas que se utilizan en el análisis fonológico: 1http://revistamito.com/que-es-la-psicolinguistica/ (Visitado el 30-06-2021). 25 26 Capítulo 3. Contexto de Desarrollo • Reglas Fonéticas: Son las reglas que describen los sonidos dentro de las palabras. Por ejemplo, en el caso del castellano, todas las palabras terminadas en consonante tienen el golpe de voz en la última sílaba (balón, ventilador, tambor, etc). • Reglas Fonémicas: Son las reglas que rigen las variaciones en la pronunciación cuando las palabras se pronuncian juntas. •Reglas Prosódicas: Son las reglas que determinan la fluctuación en el acento y en la entonación a lo largo de una oración. El conjunto de estas reglas es muy importante en sistemas de PLN capaces de interpretar texto hablado, ya que las ondas sonoras asociadas a la vocalización del texto son analizadas digitalmente y pueden ser comparadas mediante estas reglas, mejorando la capacidad de interpretación de los sistemas de PLN. Morfología: Este nivel se encarga de analizar la naturaleza de las componentes que conforman las palabras, siendo el morfema la unidad más pequeña e indivisible que posee significado gramatical. Por ejemplo, la palabra aterrizaje se puede dividir en dos morfemas y un lexema: siendo a- un morfema prefijo; -terr- un lexema que representa al sustantivo tierra (además de ser el núcleo de la palabra); y el morfema -izaje que es un sufijo que hace referencia a una “acción de algo”. Debido a que el significado de los morfemas es siempre el mismo en todas las palabras, el ser humano puede descomponer una palabra desconocida en sus morfemas para así comprender su significado. Volviendo al ejemplo anterior, si se descompone la palabra alunizaje, se puede ver como esta se encuentra constituida por un prefijo a-, un lexema -lun- (del sustantivo luna), y un morfema -izaje que es una acción de algo. A partir de esta descomposición, y sin saber el significado de la palabra, se puede deducir que esta hace referencia a una acción que se lleva a cabo en la luna. De manera análoga, un sistema de PLN es capaz de reconocer el significado de cada uno de los morfemas de una palabra, obteniendo así una mejor interpretación de las palabras. Léxico: En este nivel se interpreta el significado a través del análisis de cada una de las palabras que conforman el texto. En este nivel puede ser utilizado un léxico completo (conjunto de todas las palabras que conforman un lenguaje), o parcial (únicamente conformarlo aquellas palabras que se van a utilizar). Este léxico a su vez puede ser más complejo y, además de las palabras, puede contener también información sobre su clase semántica, los argumentos que toma, la definición de cada significado (para palabras polisémicas), etc. Dicho de otro modo, este léxico que se utiliza para analizar el significado de las palabras en este 3.1. Procesamiento del Lenguaje Natural 27 nivel es el equivalente al diccionario de la lengua que utilizan los seres humanos. Sintáctico: Este nivel se enfoca en analizar las palabras de una oración con el objetivo de descubrir la estructura gramatical de la oración. El resultado de este nivel consiste en una representación que muestra las relaciones de dependencia que existen entre las distintas palabras que conforman la oración. Semántico: Este es el nivel en el que la mayoría de las personas piensan que se determina el significado de un texto. Sin embargo, como se ha mostrado en las anteriores definiciones, todos los niveles contribuyen en mayor o menor medida a la obtención de ese significado. El procesamiento semántico determina los posibles significados que tiene una oración, ya que se enfoca en las interacciones de los significados entre las distintas palabras que conforman la oración. Además de esto, este nivel de procesamiento también incluye la desambiguación semántica de palabras polisémicas (palabras con más de un significado). Esta desambiguación permite seleccionar un único sentido-significado de la palabra a la hora de llevar a cabo la representación semántica de la oración. No obstante, para establecer este significado de entre todos los posibles, es necesario obtener información del resto de palabras que conforman la oración. Para ello, existen diferentes métodos como el análisis de frecuencias de cada uno de los significados dentro del corpus utilizado, análisis del contexto local de la palabra dentro de la oración, análisis del significado dentro del dominio en el que se encuentra el documento, etc. Discurso: Mientras que el léxico, la sintaxis y la semántica funcionan con unidades de palabras u oraciones, el nivel de discurso en un sistema PLN funciona a nivel de unidades de texto. Esto quiere decir que no interpreta textos como múltiples oraciones concatenadas entre sí y cuyo significado se analiza por separado para cada una de ellas. Más bien, el nivel de discurso se centra en obtener las propiedades del texto en su conjunto, obteniendo el significado de todo el texto al llevar a cabo las conexiones entre las distintas oraciones que lo componen. En este nivel se pueden producir varios tipos de procesamiento del discurso, sin embargo los dos más comunes son los siguientes: • Resolución de Anáforas: Consiste en la sustitución de palabras semánticamente vacías (como los pronombres), por la entidad apropiada a la que se está refiriendo. • Reconocimiento de la Estructura del Texto: Determina las funciones de las oraciones o fragmentos que conforman el texto, lo que permite generar una representación significativa del mismo. Por ejemplo un artículo científico se puede deconstruir en componentes 34 Capítulo 3. Contexto de Desarrollo directamente sin la necesidad de llevar a cabo todo el proceso de creación y entrenamiento. Además de esto, las tecnologías actuales permiten reentrenar este tipo de modelos para que sean capaces de identificar cualquier tipo de entidad, lo cuál es algo útil si se quieren identificar entidades no soportadas, o procesar textos en otro idioma. En la Figura 3.1 se puede ver como el modelo base de Spacy 6 en castellano es capaz de detectar personas, localizaciones y organizaciones, sin la necesidad de haber realizado ningún tipo de entrenamiento previo. Figura 3.1: Ejemplo de Reconocimiento de Entidades Nombradas utilizando el modelo base de Spacy en castellano. Dentro del Reconocimiento de Entidades Nombradas, existen diferentes tipos de modelos, en función del tipo de aprendizaje utilizado para llevar a cabo la tarea. Estos tipos de modelos [37] son: Modelos basados en Reglas: Este tipo de modelos es la aproximación más simple para el Reconocimiento de Entidades Nombradas. Su funcionamiento se basa en la aplicación de reglas y heurísticas definidas manualmente para detectar las entidades, por ejemplo “después de una palabra Calle oAvenida, las siguientes palabras que comiencen por mayúscula pertenecen al tipo de entidad LOCALIZACIÓN”. En el caso de tener el texto “¿Sabes como puedo llegar a la calle Amanecer?”, la regla descrita anteriormente asignaría la etiqueta LOCALIZACIÓN a Amanecer. Como se puede ver, la simplicidad de este tipo de modelos hace que no puedan ser utilizados en situaciones en las que la variedad sea muy elevada, o existan un gran número de entidades a detectar. El motivo de esto se debe a que la creación de reglas para un gran variedad de formas en las que se pueden encontrar las entidades en los textos es inviable. Modelos basados en Aprendizaje Supervisado: En este tipo de modelos, el aprendizaje se lleva a cabo comparando los resultados obtenidos por el modelo durante el entrenamiento, con el resultado esperado que se debería obtener. Es por esto, por lo que al igual que ocurre con los modelos de Aprendizaje Supervisado convencionales, es necesario disponer de un conjunto de datos etiquetado para poder entrenar el modelo. Sin embargo, existen diferencias entre los conjuntos de datos etiquetados para 6https://spacy.io (Visitado el 01-07-2021). 3.2. Reconocimiento de Entidades Nombradas 35 entrenar modelos de NER, y los conjuntos etiquetados para otras tareas de clasificación. Mientras que para tareas de clasificación convencionales el conjunto de datos se encuentra estructurado en instancias con los datos de entrada y su salida esperada, en el caso del NER se encuentra estructurado por palabras y la etiqueta correspondiente a la entidad a la que pertenece. Existen diferentes formatos de etiquetado para el NER (ver Apartado 3.2.1), sin embargo, el más habitual (y el que se utilizará en este proyecto) es el sistema de etiquetado IOB (Inside-Outside-Beginning, en inglés). Modelos basados en Aprendizaje Semi-Supervisado: Este tipo de modelos se encuentra en un punto intermedio entre el Aprendizaje Supervisado y el No Supervisado. En este tipo de modelos, el conjunto de datos de entrenamiento se encuentra formado por datos etiquetados (en menor proporción), y datos sin etiquetar (en mayor proporción). El objetivo que se persigue es que, a partir de los datos etiquetados, se puedan ir etiquetando correctamente textos sin etiquetar, aumentando así el conjunto de textos etiquetados y mejorando los resultados del modelo. La ventaja que tiene este tipo de modelos es que no es necesario llevar a cabo el etiquetado de la totalidad de los textos, eliminando así la tediosa labor del etiquetado (sobre todo cuando el conjunto de datos con el que se quiere trabajar es muy grande). Modelos basados en Aprendizaje No Supervisado: En este tipo de modelos, el conjunto de datos utilizado para generar el modelo final no se encuentra anotado. Esto hace que el modelo tenga que llevar a cabo un proceso de inferencia que le permita agrupar o clasificar las distintas palabras del texto, en el tipo de entidad que se corresponda. En el presente Trabajo Fin de Master se emplearán modelos basados en Aprendizaje Supervisado, por lo que será necesario llevar a cabo un paso previo de etiquetado de los datos que se utilizarán para crear el modelo. 3.2.1. Proceso de Creación de un Sistema de Reconocimiento de Entidades Nombradas Como se ha mencionado anteriormente, el modelo que se empleará para detectar las entidades de los textos es un modelo basado en Aprendizaje Automático Supervisado. Es por ello por lo que antes de comenzar con la división de los datos en subconjuntos, el entrenamiento, y la evaluación del modelo, es necesario llevar a cabo un paso previo. Este paso consiste en realizar un etiquetado de las entidades que se quieren detectar en los textos que se utilizarán para entrenar y evaluar el modelo. 36 Capítulo 3. Contexto de Desarrollo El proceso de etiquetado de datos consiste en asignar una etiqueta a cada una de las palabras del texto en función de la entidad a la que esta pertenezca. Existen diferentes formatos 7 para llevar a cabo este proceso de etiquetado. Los más habituales son los siguientes: IO: IO (Inside-Outside, en inglés) es el método más simple para el etiquetado de entidades nombradas. Este formato consiste en asignar a cada palabra del texto el tipo de entidad a la que pertenece. Además, de esto, se añade un prefijo 8 en función de si esta forma parte de una entidad (I), o si por el contrario se encuentra fuera de la entidad (O). IOB: El formato IOB (Inside-Outside-Beginning, en inglés) es el formato de etiquetado estándar en la actualidad. Fue inventado por Ramshaw y Marcus en 1995 y mejora la información que proporciona el formato IO. El formato IOB añade un nuevo prefijo (B) para hacer referencia a la primera palabra de cada una de las entidades existentes en el texto. Esto es una diferencia respecto al formato IO ya que, mientras en este todas las palabras de una entidad se denotaban con I, el formato IOB añade información sobre la primera palabra de cada entidad. Esto permite diferenciar entre entidades simples (una palabra) y compuestas (más de una palabra). BILOU: El formato BILOU (Beginning-Inside-Last-Outside-Unit_Len- ght), o BMEWO (Beginning-Middle-End-Whole-Outside), es una evolución del formato IOB. En este formato se añade el prefijo (L) a la última palabra de entidades con múltiples palabras (a diferencia del formato IOB, en el que se denotaba la primera palabra con el prefijo B y el resto con el prefijo I). Además de esto, se añade un nuevo prefijo (U) a las entidades con una única palabra. De este modo se consigue diferenciar al instante si una determinada entidad se encuentra conformada por una o más palabras, añadiendo un extra de información al documento etiquetado. En la siguiente tabla (ver Tabla 3.1) se muestra el etiquetado correspondiente a la frase “Luis Pérez Rodríguez compró un billete para viajar a España” en los distintos formatos presentados anteriormente. 7 https://lingpipe-blog.com/2009/10/14/coding-chunkers-as-taggers-io-bio-bmewo-and- bmewo/ (Visitado el 02-07-2021). 8 En el caso de que la palabra no forme parte de ninguna entidad a etiquetar, únicamente se le asigna el valor “O” (en lugar de la asignación “prefijo-tipo_entidad”). 3.2. Reconocimiento de Entidades Nombradas 37 Palabra IO IOB BILOU Luis I-PERSONA B-PERSONA B-PERSONA Pérez I-PERSONA I-PERSONA I-PERSONA Rodríguez I-PERSONA I-PERSONA L-PERSONA compró O O O un O O O billete O O O para O O O viajar O O O a O O O España I-PAIS B-PAIS U-PAIS Tabla 3.1: Ejemplo de etiquetado de una frase en los formatos IO, IOB y BILOU. Además de los formatos de etiquetado, existen también formatos de texto estructurados en los que se pueden representar las etiquetas de las palabras que conforman un texto. Estos formatos de texto se utilizan en combinación con los formatos de etiquetado, para entrenar los modelos de NER, o para llevar a cabo la visualización de las entidades en un texto. El motivo de esto se debe a que al ser formatos de texto estructurados, permite representar de una forma estándar las etiquetas de las palabras (posibilitando la automatización y la representatividad de estas características de una forma sencilla). Además de esto, los formatos de textos estructurados mejoran la legibilidad de las anotaciones, facilitando la labor de revisión o de modificación en caso de error. Los formatos de texto más habituales para representar las anotaciones son: TSV: El formato TSV (Tab Separated Values) es uno de los formatos más simples para representar las anotaciones. Este formato es muy similar al CSV (incluso puede ser el mismo dependiendo del separador utilizado), ya que cada palabra del texto se encuentra en una línea del fichero, y se utiliza el tabulador para separar la palabra con su etiqueta asociada. A diferencia del formato CSV, en el formato TSV siempre se utiliza el tabulador para separar la palabra y su etiqueta asociada. Este tipo de formato es el más simple pero a su vez es el menos legible de todos, dado que el tener una palabra en cada línea dificulta la lectura continua de las frases. JSON: El formato de texto JSON (JavaScript Object Notation) es uno de los formatos que permiten una mayor representatividad de la información de todos los componentes que conforman el texto, así como de su estructura. Esto se debe a que JSON es un formato que permite dividir los objetos de forma jerárquica y representar sus características de una forma anidada. Gracias a esto, se puede emular una estructura 38 Capítulo 3. Contexto de Desarrollo similar a la que tiene el texto original, dividiendo el texto en párrafos, los párrafos en oraciones, y las oraciones en palabras. Toda esta división se representa de forma anidada y aportando información de valor en cada uno de los niveles (identificador de la palabra, palabra, etiqueta asociada, etc). A continuación se muestra un ejemplo simple de la representación de las anotaciones en formato IOB y JSON (ver Código 3.1). { "id":0, "paragraphs":[ { "sentences":[ { "tokens":[ { "id":0, "orth":"Luis", "ner":"B-PERSONA" }, { "id":1, "orth":"Pérez", "ner":"I-PERSONA" }, { "id":2, "orth":"Rodríguez", "ner":"I-PERSONA" }, { "id":3, "orth":"compró", "ner":"O" }, ... Código 3.1: Representación del etiquetado de un texto en formato IOB y JSON. XML: El formato XML (eXtensible Markup Language) es un formato de etiquetado utilizado habitualmente para representar de forma visual las palabras del texto y su etiqueta asociada. Este tipo de formato (al igual que el HTML), es un formato de marcado mediante etiquetas, por 3.2. Reconocimiento de Entidades Nombradas 39 lo que es fácilmente legible y entendible. Este tipo de formatos suele ser utilizado a la hora de representar de forma gráfica las etiquetas que el modelo NER a asignado a un texto cualquiera. Es decir, este formato se utiliza para visualizar la inferencia del modelo en lugar de para entrenarlo. Ambos formatos (XML y HTML) son compatibles con los navegadores web y con otras librerías como CSS o JavaScript, lo que permite añadir características especiales en función de cada entidad. En el ejemplo de la Figura 3.1, el código fuente sin renderizar del texto mostrado (y de sus entidades), es un código HTML generado a partir de las entidades que el modelo ha asignado a cada una de las palabras del texto de entrada. A continuación se muestra un ejemplo en texto plano del formato de etiquetado XML (ver Código 3.2). <PERSONA> Luis Pérez Rodríguez </PERSONA> compró un billete para viajar a <PAIS> España </PAIS>.,→ Código 3.2: Representación del etiquetado de un texto en formato XML. 3.2.1.1. Evaluación de Sistemas de Reconocimiento de Entidades Nombradas Una vez se ha llevado a cabo el proceso de etiquetado sobre todos los textos que conformaran el corpus empleado para generar el modelo, es necesario realizar una división de los documentos en subconjuntos. Los subconjuntos generados se utilizarán para entrenar, validar y probar el desempeño del modelo con datos que este nunca “ha visto”. Este paso es idéntico al que se realiza en cualquier proyecto de esta índole, y el objetivo principal consiste en lograr que el modelo final implementado sea capaz de generalizar correctamente la problemática a tratar. No obstante, un punto muy importante a destacar es que los datos que se encuentren en cada uno de los subconjuntos han de ser lo más representativos posible del conjunto de datos inicial. De no ser así, el modelo construido estaría sesgado y únicamente funcionaría correctamente para unos casos muy concretos (mala generalización), en lugar de funcionar bien para todos o para la mayoría. Los subconjuntos en los que se divide el corpus, así como su utilidad son los siguientes: Entrenamiento: El conjunto de entrenamiento (Training Set) se encuentra formado por todos aquellos documentos que se emplearán para llevar a cabo el aprendizaje el modelo. Dicho de otro modo, serán los documentos que el modelo emplee para ajustar sus parámetros internos. Validación: El conjunto de validación (Validation Set) es un subconjunto que, al igual que el subconjunto de entrenamiento, se emplea durante la 40 Capítulo 3. Contexto de Desarrollo fase de aprendizaje del modelo para ajustar sus hiperparámetros. Otro uso que se le da a este conjunto es para comprobar si el funcionamiento del modelo es correcto, o si por el contrario existe un sobreajuste que puede empeorar su capacidad de generalización. En definitiva, el modelo es entrenado con los datos de entrenamiento, y se utiliza este conjunto para comprobar que su funcionamiento es correcto. Prueba: El conjunto de prueba (Test Set) es un conjunto totalmente independiente de los dos anteriores. El objetivo principal de este conjunto consiste en determinar qué tan bien es capaz el modelo de generalizar. Es por esto por lo que los documentos que se encuentren en este conjunto de datos no pueden ser utilizados en ninguna de las fases de aprendizaje del modelo, entendiendo como fase de aprendizaje aquellas fases en las que se producen modificaciones en los parámetros internos del modelo. Finalmente, una vez se ha creado y entrenado el modelo del NER, el paso final consiste en evaluar su desempeño. Es en este punto donde entra en juego el conjunto de prueba anteriormente definido. A pesar de trabajar con textos, el modelo generado no es más que un modelo de clasificación, cuya función consiste en asignar a cada una de las palabras del texto la etiqueta asociada a la entidad a la que pertenece. Es por esto por lo que las métricas de este modelo son las mismas que las utilizadas para evaluar modelos de clasificación. Todo modelo de clasificación realiza una clasificación sobre un conjunto de datos de acuerdo con la Tabla 3.2. Esta tabla, también conocida como matriz de confusión, se utiliza para obtener las métricas asociadas al modelo, permitiendo determinar cuantitativamente la eficacia del modelo. Clasificado Positivo Clasificado Negativo Ejemplo Positivo Verdadero Positivo (VP) Falso Negativo (FN) Ejemplo Negativo Falso Positivo (FP) Verdadero Negativo (VN) Tabla 3.2: Matriz de Confusión. Donde: Verdadero Positivo (VP): La palabra real lleva asociada una entidad y el tipo de dicha entidad es del mismo tipo que el predicho por el modelo. Ejemplo: Real →B-NOMBRE; Predicción →B-NOMBRE. Falso Positivo (FP): La palabra real no pertenece a ningún tipo de entidad, y el modelo le asigna una etiqueta de entidad. Ejemplo: Real → O; Predicción →B-NOMBRE. Falso Negativo (FN): La palabra real pertenece a una entidad, y el modelo la clasifica como si no perteneciente a ninguna. Ejemplo: Real → B-NOMBRE; Predicción →O. 3.2. Reconocimiento de Entidades Nombradas 41 Verdadero Negativo (VN): La palabra real no se encuentra asociada con ningún tipo de entidad, y el modelo predice que no pertenece a ninguna entidad. Ejemplo: Real →O; Predicción →O. Las métricas más habituales para evaluar el desempeño de un modelo, así como la forma de obtenerlas a partir de la matriz de confusión son: Precision: Representa la proporción de muestras que se han clasificado correctamente como positivas del total de ejemplos que se han clasificado como positivos. La fórmula para obtener la precision de un modelo a partir de la matriz de confusión es la siguiente: precision =V P V P +F P =clasificados correctamente como positivos todos los clasificados como positivos Donde lo ideal es que precision = 1 Recall: Representa la proporción de muestras que se han clasificado correctamente como positivas de la totalidad de los ejemplos positivos. La fórmula para obtener el recall de un modelo a partir de la matriz de confusión es la siguiente: recall =V P V P +F N =clasificados correctamente como positivos todos los positivos Donde lo ideal es que recall = 1 F1: El F1 o F1-Score es la métrica que representa el desempeño del modelo. Su cálculo viene dado a partir de las métricas precision yrecall y se obtiene a partir de la siguiente fórmula: F1=2·precision ·recall precision +recall Donde lo ideal es que F1 = 1 Un punto importante que destacar es que las métricas descritas están diseñadas para clasificadores binarios, es decir, clasificadores en los que únicamente hay dos clases posibles a predecir. Esto es algo prácticamente imposible en un modelo de NER, ya que por norma general, este deberá ser capaz de clasificar una palabra entre todas las entidades posibles para las que ha sido entrenado (casi siempre serán más de dos tipos de entidades). La solución a este problema pasa por transformar la evaluación de un modelo multiclase, 42 Capítulo 3. Contexto de Desarrollo a un modelo binario. Para ello, lo que se hace es obtener por separado las métricas de cada una de las entidades, de tal forma que la clasificación de esa clase pasa de ser multiclase a binaria. Por lo tanto, la evaluación se resume en calcular si una determinada instancia pertenece a la clase que se está evaluando o no. Teniendo esto en cuenta, el cálculo de la precision y del recall pasan de calcularse de la siguiente forma: precision =1 N N X N=1 precision para la entidad N recall =1 N N X N=1 recall para la entidad N F1 = 1 N N X N=1 F1para la entidad N Donde N = Tipos de entidades distintas que el modelo clasifica, y lo ideal continúa siendo que precision = 1 ;recall = 1; y F1 = 1. 3.2.2. Librerías orientadas al Reconocimiento de Entidades Nombradas A lo largo del apartado anterior se ha descrito el proceso necesario para llevar a cabo la creación y evaluación de un sistema NER. Sin embargo, el desarrollar soluciones ad-hoc desde cero, es un proceso complejo y costoso, por lo que utilizar herramientas y librerías que automaticen o faciliten el trabajo es un punto fundamental a la hora de elaborar un sistema NER. En este apartado se describirán a grandes rasgos algunas de las herramientas más populares tanto para el etiquetado de documentos, como para el entrenamiento y evaluación de los modelos, así como sus principales características. 3.2.2.1. Herramientas para etiquetado de documentos Dentro de las herramientas enfocadas a etiquetar los documentos que conformarán el Corpus de datos, así como exportar las anotaciones realizadas utilizando alguno de los formatos mencionados en el Apartado 3.2.1, las principales herramientas son: Prodigy: Prodigy 9 es una herramienta de anotación con interfaz web basada en Python, orientada a crear conjuntos de datos de entrenamiento y evaluación para modelos de Aprendizaje Automático. Estos conjuntos 9https://prodi.gy (Visitado el 02-07-2021). 3.2. Reconocimiento de Entidades Nombradas 43 de datos no se limitan únicamente a tareas de procesamiento de textos, si no que también se pueden generar datos para tareas de visión por computador, anotación de videos, audios, etc. Así mismo, Prodigy proporciona distintos flujos de trabajo en función de las necesidades del usuario: • Manual 100 %: En este flujo de trabajo se presentan los documentos en texto plano y se va realizando el etiquetado de estos de una forma totalmente manual (seleccionando un fragmento del texto e indicando su clase). • Manual con sugerencias por patrones: Este flujo de trabajo es similar al modo manual con la diferencia de que durante el etiquetado, Prodigy realiza sugerencias de etiquetado de entidades en función de los patrones que se han establecido previamente en su fichero de configuración. Esto permite que entidades con una estructura fija como números de teléfono, DNI, cuentas bancarias, etc, se etiqueten automáticamente, lo que facilita el proceso de etiquetado. • Manual con sugerencias del modelo: Este flujo de trabajo es idéntico al anterior con la diferencia de que en lugar de recibir las sugerencia a partir de patrones y reglas definidas previamente, las sugerencias se generan mediante un modelo NER previamente entrenado. Esto es útil cuando se dispone de un buen modelo y se quiere añadir soporte para un nuevo tipo de entidad. En este caso, el modelo se encargaría de detectar las entidades antiguas, y únicamente habría que etiquetar manualmente el nuevo tipo de entidad a soportar, o corregir las anotaciones del modelo (semisupervisado). • Utilizando Aprendizaje Activo: Este flujo de trabajo se utiliza para refinar un modelo ya existente. El modelo creado va realizando las sugerencias de las entidades, y estas se corrigen manualmente (en el caso de que estén mal). La diferencia entre este flujo de trabajo y el anterior, es que el modelo es entrenado teniendo en cuenta las correcciones realizadas, lo cuál hace que vaya aprendiendo a medida que se corrigen las sugerencias que este haya efectuado de forma errónea. De este modo se va realizando un aprendizaje continuo y activo a medida que se va corrigiendo el etiquetado que el modelo realiza sobre los textos. Una de las principales ventajas que tiene Prodigy frente al resto de herramientas es su integración con las funcionalidades de Spacy (ver Apartado 3.2.1). Esto permite por un lado que los datos etiquetados generados con esta herramienta sean totalmente compatibles con cualquier 50 Capítulo 3. Contexto de Desarrollo tagger: El tagger es el encargado de “escuchar” al tok2vec, e ir asignando a cada token que este genere la etiqueta correspondiente a su categoría gramatical (nombre, pronombre, verbo, adjetivo, etc). La asignación de una etiqueta u otra vendrá dada en función de las reglas definidas en attribute_ruler. parser: Al igual que ocurre con el tagger, el parser se encuentra “escuchando” al tok2vec a la espera de tokens para asignar a cada uno de ellos la etiqueta UPOS 16 (Universal POS Tags) correspondiente. Nuevamente, la asignación de una etiqueta u otra vendrá dada en función de las reglas definidas en attribute_ruler. attribute_ruler: El componente attribute_ruler define el conjunto de reglas que se utilizarán para asignar a un determinado token su etiqueta UPOS correspondiente. Este componente dispone de reglas definidas por defecto para una gran variedad de idiomas. No obstante, es posible añadir nuevas reglas en el caso de que fuese necesario. lemmatizer: El lemmatizer define el conjunto de reglas que se utilizarán para asignar a cada uno de los tokens la etiqueta correspondiente a su lema (forma base de una palabra). Al igual que ocurría con el attribute_ruler, este componente ya dispone de reglas predefinidas para una gran variedad de idiomas. No obstante, es posible añadir nuevas reglas en el caso de que fuera necesario. ner: El ner es el componente encargado de procesar los tokens y asignar a cada uno de ellos la categoría a la que este pertenece. Además de estos componentes, Spacy ofrece la posibilidad de añadir componentes personalizados a este Pipeline para mejorar o extender su funcionalidad. Alguno de los componentes extra que se pueden añadir son: EntityRuler: Este componente permite añadir etiquetas del tipo de entidad a los tokens del texto. Para ello utiliza reglas basadas en coincidencias de palabras o por coincidencias exactas de frases. Por ejemplo: “a todos los tokens “patata” en el texto, se les asignará la etiqueta de entidad “Hortaliza””. Matchers: Los Matchers son componentes que permiten asignar a un token (o conjunto de tokens) una etiqueta utilizando reglas basadas en sus atributos. Este componente va un paso más allá que el EntityRuler ya que permite asignar más de un tipo de etiqueta (no solo la etiqueta de categoría). Otra característica es que permite crear reglas más complejas 16https://universaldependencies.org/docs/u/pos/ (Visitado el 28-06-2021). 3.3. Spacy 51 Figura 3.3: Pipeline de Spacy. Fuente: https: // spacy. io/ api (Visitado el 29-06-2021). que la coincidencia exacta de tokens. Algunos ejemplos de reglas que soporta este componente son las asignaciones de etiquetas UPOS en base al lema del token, asignación de etiquetas de categoría utilizando expresiones regulares, o aplicar una combinación de condicionales: asignar una determinada etiqueta en base al texto, lema, longitud del token o cualquier otro atributo que este tenga. 3.3.3. Displacy Una de las funcionalidades que dispone Spacy es la posibilidad de crear visualizaciones de los textos (objetos Doc), y sus atributos o entidades. Estas visualizaciones son generadas utilizando el paquete Displacy 17 (el cual se encuentra incluido en la librería de Spacy). Displacy permite generar visualizaciones de dos tipos: Dependencia: En este tipo de visualizaciones se muestran los atributos asociados a los tokens del documento, así como las dependencias que existen entre ellos (ver Figura 3.4). Entidad: Este tipo de visualización muestra las distintas entidades que existen en el documento, así como su tipo y los tokens que pertenecen a ella (ver Figura 3.5). 17https://spacy.io/usage/visualizers (Visitado el 30-06-2021). 52 Capítulo 3. Contexto de Desarrollo Figura 3.4: Ejemplo de Visualización en Displacy en modo “Dependencia”. Figura 3.5: Ejemplo de Visualización en Displacy en modo “Entidad”. La gran ventaja de estas visualizaciones es que pueden ser generadas automáticamente a partir de los atributos y etiquetas de un documento, o bien pueden ser generadas en base a los atributos de un fichero JSON personalizado (Displacy interpretará ese JSON como un Doc con los atributos y etiquetas que se especifiquen en el propio JSON). Esta característica es interesante ya que permite generar visualizaciones sin la necesidad de tener que crear un objeto Doc y aplicar un Pipeline para predecir sus atributos y entidades. Otra característica que ofrece Displacy es la posibilidad de exportar las visualizaciones como imágenes o como código HTML. Esto permite que puedan ser utilizadas en la gran mayoría de aplicaciones (páginas webs, aplicaciones de escritorio, etc), además de disponer de soporte para cuadernos de Jupyter. 3.4. Anonimización de Documentos La anonimización o de-identificación 18 es un proceso en el cual se llevan a cabo un conjunto de técnicas y operaciones para evitar que se obtenga la identidad personal de alguien. En otras palabras, el objetivo principal de estas técnicas consiste en eliminar la asociación entre una persona y un texto [3]. Teniendo esto en cuenta, se pueden establecer tres tipos de identificación en función del estado en el que se encuentren los datos (ver Figura 3.6): Identificado: En esta categoría se encuentran aquellos documentos en cuyos datos se encuentra información directa (nombres, direcciones, identificaciones fiscales, etc) para poder identificar a una persona. No 18 https://www.truevault.com/resources/developer/what-is-data-de-identification (Visitado el 28-06-2021). 3.4. Anonimización de Documentos 53 obstante, en este punto hay que hacer una distinción entre identificado eidentificable. Una persona o individuo es identificable en un conjunto de datos siempre que sea razonable esperar que, con los datos disponibles de forma inmediata (nombres, direcciones, etc) o con otra información externa (metadatos del documento, procedencia, etc) sea posible identificarle de forma unívoca. Por otro lado, un individuo es identificado cuando se conocen (y se pueden asociar directamente) los datos del documento a dicho individuo. Es importante hacer esta distinción ya que no siempre el disponer de datos de carácter personal hace que sea posible identificar a un individuo. Pseudonimización: En esta categoría se encuentran aquellos documentos en los que los identificadores directos han sido sustituidos por pseudónimos o por identificadores falsos que impiden identificar al individuo de forma directa. No obstante, los identificadores indirectos no se ven afectados, por lo que una persona puede continuar siendo identificable tras realizar este procesamiento. La correspondencia entre las menciones originales y los pseudónimos utilizada puede ser almacenada para asegurar la reversibilidad del proceso. Anonimizado: En esta categoría se encuentran los documentos en los que se han eliminado tanto los identificadores directos como los indirectos. Esto añade un nivel más de seguridad que en el caso de la pseudonimización ya que al no disponer de ningún tipo de identificador, no se puede llegar a la identidad del individuo original. Figura 3.6: Tipos de anonimización en función del estado del documento. Fuente: [3]. Por norma general, el objetivo marcado consiste en transformar los documentos con un estado identificado, a un documento pseudo-anonimizado oanonimizado. La diferencia entre uno u otro dependerá en gran medida del uso que se le vaya a dar a los documentos resultantes. Por ejemplo, en un entorno jurídico puede ser más interesante sustituir las menciones personales por otras realistas para facilitar la comprensión del documento y distinguir entre los distintos tipos de menciones. Por lo tanto en este caso se utilizaría 54 Capítulo 3. Contexto de Desarrollo la pseudonimización. Del mismo modo, en el caso de documentos en los que lo importante es el qué en lugar del quién (por ejemplo en una resolución administrativa que afecta a un particular), se utilizaría la anonimización del documento. Dentro de este proceso de anonimización existen diferentes técnicas en función del resultado final que se desee. A continuación se indican las técnicas más habituales para pasar de un documento identificado a uno pseudo-anoni- mizado o anonimizado [22]: Eliminación de identificadores: Este tipo de técnicas es la más básica e intuitiva en materia de anonimización. Consiste en eliminar el identificador del documento anonimizado de tal forma que este no sea visible y no aparezca en el nuevo documento. La principal desventaja que tienen este tipo de técnicas es que al eliminar partes del documento sin sustituirlas por otras, dificulta la lectura y la interpretación del texto (ya que en lugares donde deberían aparecer identificadores no aparece nada). Por otro lado, una de las grandes ventajas es que en términos de ejecución es muy rápido, y en términos de computación es eficiente y fácil de implementar. Generación de mecanismos de reemplazo: Este tipo de técnicas tienen como objetivo el suplir la pérdida de legibilidad del documento anonimizado que sufren las técnicas de anonimización basadas en la eliminación de las menciones. Para ello lo que se hace es sustituir cada uno de los identificadores por caracteres, u otras entidades del mismo tipo que la original. Con esto se consigue tanto mantener la legibilidad del documento, como hacer que el mismo parezca más natural. Dentro de este tipo de reemplazos existen diferentes técnicas en función de la forma en la que se realice tanto la generación, como la aplicación de los reemplazos. Entre estas técnicas, las más habituales son: • Supresión: Consiste en sustituir el identificador a anonimizar por una secuencia de caracteres fija (*****,#####,—–, etc). • Reemplazo por el tipo de la entidad-identificador: Consiste en sustituir el identificador a anonimizar por el texto plano correspondiente al tipo de identificador al que pertenece (nombre, dirección, teléfono, etc). • Reemplazo por entidades-identificadores sintéticos: Este tipo de técnicas consiste en generar de forma artificial un identificador del mismo tipo que el que se quiere anonimizar y reemplazarlo por el original. La generación del nuevo identificador puede realizarse de diversas formas en función del formato que este tenga, por ejemplo en el caso de los números de teléfono, bastaría con generar un número 3.5. Reconocimiento Óptico de Caracteres (OCR) 55 aleatorio entre 600000000 y 699999999. Otra forma de generar estos reemplazos sintéticos es mediante diccionarios (estructuras de datos que contienen reemplazos ya definidos para unos determinados identificadores) u otra estructura similar. De este modo, si ahora se quiere generar un nombre sintético únicamente habría que ir a la estructura de datos correspondiente y tomar uno de los valores de nombres que se tienen almacenados. Dentro de la generación de reemplazos sintéticos, existen diferentes categorías en función del tipo de estructura de datos utilizada para generar los reemplazos: ◦ Estáticos: Los reemplazos almacenados en la estructura de datos empleada es siempre la misma. ◦ Dinámicos: Los reemplazos almacenados en la estructura de datos empleada varía a medida que se anonimizan documentos. En estos casos, se parte de un conjunto de reemplazos base y a medida que se van sustituyendo identificadores en el documento, se actualizan también en la propia estructura de datos. De este modo, a medida que se anonimizan los documentos, se va enriqueciendo el catálogo de reemplazos. En la siguiente tabla (ver Tabla 3.3) se muestra un ejemplo de anonimización de un texto utilizando las técnicas anteriormente descritas. Original Eliminación Supresión Hola mi nombre es Juan Sánchez García y mi número de teléfono es 623904582 Hola mi nombre es y mi número de teléfono es Hola mi nombre es **** ******* ****** y mi número de teléfono es ********* Original Tipo de Identificador Identificadores Sintéticos Hola mi nombre es Juan Sánchez García y mi número de teléfono es 623904582 Hola mi nombre es NOMBRE APELLIDO APELLIDO y mi número de teléfono es TELÉFONO Hola mi nombre es Paco Gómez Casas y mi número de teléfono es 674560147 Tabla 3.3: Ejemplos de anonimización de textos utilizando distintas técnicas. 3.5. Reconocimiento Óptico de Caracteres (OCR) El Reconocimiento Óptico de Caracteres (Optical Character Recognition, OCR, en inglés), es un proceso por el cual un software es capaz de detectar los 56 Capítulo 3. Contexto de Desarrollo caracteres que se encuentran en una imagen (fotografía o documento escaneado), de tal forma que estos sean reconocidos por un ordenador, pudiendo interactuar con estos posteriormente mediante software de visualización o editores de texto. El proceso que sigue un OCR para llevar a cabo la detección del texto en una imagen es el siguiente: 1) Preprocesamiento de la imagen: La primera etapa que se lleva a cabo es la de realizar un preprocesamiento de la imagen a tratar. Este proceso consiste en aplicar sobre la imagen distintos filtros que faciliten la extracción del texto en las etapas posteriores. Alguno de los filtros a aplicar son el reescalado de la imagen, la binarización (normalización de los píxeles), transformación a blanco y negro, etc. A pesar de que esta etapa no es obligatoria dentro del flujo del OCR, es altamente recomendable, ya que ayuda a mejorar el desempeño de las etapas posteriores, lo que se traduce en unos mejores resultados en el reconocimiento de los caracteres de la imagen. 2) Segmentación: Una vez se ha llevado a cabo todo el preprocesamiento de la imagen, el siguiente paso consiste en dividir la imagen en distintas zonas donde se encuentra situado el texto (ver Figura 3.8). Esta división se realiza en dos fases: Extracción de regiones de interés: En esta primera fase se lleva a cabo una división de la imagen en distintas áreas de donde se encuentra el texto a procesar. Estas áreas reciben el nombre de Regiones de Interés (Region Of Interest, ROI, en inglés). Por ejemplo, en el caso de un documento, la división de la imagen en regiones de interés pueden ser los distintos párrafos que lo conforman. Del mismo modo, en el caso de una imagen en la que aparezca la fachada de un restaurante, la región de interés puede ser la zona en la que aparece el cartel con el nombre del restaurante. El objetivo de esta fase consiste en reducir el espacio de búsqueda, limitándose únicamente a aquellas zonas de la imagen que contienen texto. División de caracteres: Una vez se han definido las distintas regiones de interés dentro de la imagen, el siguiente paso consiste en realizar una división de los caracteres dentro de esa región. Esta es la etapa más delicada y a la vez complicada, ya que una mala segmentación de los caracteres hace que estos no puedan ser reconocidos. En términos generales, la obtención de estos caracteres se realiza mediante el análisis de los píxeles, o métodos de proyección de histogramas (ver Figura 3.7), por lo que el hecho de haber preprocesado y normalizado la imagen toma un papel importante en esta etapa ya que ayuda a la detección de las zonas correspondientes a caracteres. 3.5. Reconocimiento Óptico de Caracteres (OCR) 57 Figura 3.7: Ejemplo segmentación mediante histogramas. Fuente: [31]. Existen casos como los formularios, en los que esta delimitación de los caracteres es sencilla (ya que cada uno se encuentra en una celda distinta, como ocurre en el ejemplo de la Figura 3.8). No obstante, en el caso de textos manuscritos, esta tarea puede ser muy compleja ya que no se dispone de esta división tan inmediata. Figura 3.8: Ejemplo de normalización y segmentación de la imagen en formularios. Fuente: [12]. 3) Reconocimiento del carácter: Finalmente, una vez se han obtenido los distintos caracteres del texto, el último paso consiste en identificar que carácter es. Esta identificación se lleva a cabo utilizando algoritmos de Aprendizaje Automático entrenados con grandes conjuntos de datos de caracteres. Alguno de los modelos utilizado para este tipo de tareas es el KNN (K-Nearest-Neighbors), los Árboles de Decisión, o las Redes Neuronales. No obstante, el avance en el campo del Deep Learning en materia de procesamiento de imágenes, ha hecho que estas propuestas sean las más utilizadas para este tipo de tareas. 58 Capítulo 3. Contexto de Desarrollo En la actualidad existen muchos y muy diversos usos de este tipo de tecnología. Alguno de estos usos son los siguientes: Automatización de la extracción de datos en formularios. Reconocimiento de señales de tráfico en vehículos autónomos. Traducción del texto que aparece en una imagen. Digitalización de documentos. Capítulo 4 Estado del Arte En los últimos años, el creciente interés en la privacidad ha propiciado el desarrollo de sistemas de protección de datos. Estos sistemas requieren de mecanismos que permitan tanto detectar las entidades personales en los textos, como clasificarlas según su tipo. Asimismo, la entrada en vigor de leyes enfocadas a la protección de datos, en especial el Reglamento General de Protección de Datos (RGPD), ha ampliado significativamente el alcance de estos sistemas de detección y clasificación de menciones personales en textos. La primera propuesta orientada a detectar entidades en textos se remonta al año 1991 en la 7ºConferencia IEEE en Aplicaciones de la Inteligencia Artificial. Esta propuesta [32] estaba enfocada a reconocer únicamente nombres de compañías en textos escritos basándose en heurísticas y en reglas escritas (ver Figura 4.1). No obstante, a pesar de su sencillez, era capaz de extraer correctamente el 97,5 % de las compañías en los textos de evaluación utilizados. Figura 4.1: Flujo de detección y extracción de entidades del primer NER basado en heurísticas y en reglas escritas. Fuente: [32]. 59 Capítulo 5 Pipeline Desarrollado Dado que el pipeline desarrollado para anonimizar los documentos se encuentra conformado por múltiples componentes con distintos propósitos, se va a realizar un paso previo de explicación de dichos componentes antes de profundizar en cada uno de ellos. La implementación del pipeline se ha desarrollado bajo una estructura basada en componentes. En esta estructura, cada uno de los componentes actúa como un sistema aislado e independiente del resto, cuyo objetivo se centra en recoger la entrada proporcionada por el componente anterior, realizar una tarea determinada, y enviar el resultado al siguiente componente. Todo este proceso se realiza de forma aislada, es decir, dentro de un componente únicamente puede fallar algo relacionado con la tarea que ha de llevar a cabo el componente. Gracias a esto se consigue mejorar tanto la mantenibilidad, como el aislamiento de los posibles fallos que puedan ocurrir en la herramienta, ya que si fallase un proceso en uno de los componentes, el error se encontraría dentro de él, y no habría que buscar en los componentes ejecutados previamente. Otras ventajas que ofrece la estructura de pipeline propuesta es la modularidad, y la actuación como modelo de caja negra: recibe una entrada, la procesa, y la envía al siguiente componente con el que está conectado. Además de esto, la disposición del flujo mediante este tipo de esquemas permite ampliar y reducir la funcionalidad de una forma más sencilla, dado que la única consideración que se ha de tener en cuenta es el formato de la entrada que esta va a recibir, así como mantener el formato de salida esperado por los otros componentes. Esta característica amplía las posibilidades que ofrece actualmente este pipeline, y lo convierte en una solución genérica y altamente adaptable a otros flujos, o a otros casos de uso en los que necesiten realizar distintas acciones y/o modificaciones sobre los documentos, o sobre las menciones detectadas. Los componentes que conforman el pipeline de anonimización desarrollado (ver Figura 5.1), junto con su objetivo son las siguientes: 67 68 Capítulo 5. Pipeline Desarrollado Figura 5.1: Estructura de componentes del pipeline desarrollado. Extracción de texto: El componente de extracción de texto es la primera etapa que se lleva a cabo del pipeline. Este componente recibe como entrada un documento en formato PDF y se encarga de leerlo, transformar cada una de las páginas del PDF a imagen y, aplicar un OCR a cada una de esas imágenes para obtener el texto. El texto obtenido a partir del PDF es utilizado para generar un documento de texto plano (.txt) que será la combinación de los textos obtenidos al aplicar el OCR a cada una de las páginas del PDF original. Todo este proceso se lleva a cabo utilizando las librerías de manejo de PDF Pillow,pdf2image y pytesseract (ver Apartado 1.3). Una vez generado el documento de texto plano, se envía el resultado al siguiente componente, el cual se encargará de detectar las menciones personales que existan en dicho documento de texto. En la siguiente figura (ver Figura 5.2) se muestra en detalle el flujo que sigue este componente: Figura 5.2: Desglose del flujo del “Componente Extracción de Texto”. Detección de menciones: El componente de detección de menciones se encarga de, a partir de un fichero de texto plano, generar un objeto de tipo Doc de Spacy y detectar las menciones que este pudiera contener. Esta detección de menciones se realiza en una primera instancia mediante el uso de expresiones regulares para detectar las menciones altamente 69 predecibles (ver Apartado 7.3), y en una segunda instancia mediante la aplicación del modelo NER entrenado con los documentos del subconjunto de entrenamiento (ver Apartado 7). Finalmente este componente genera un documento anotado que por un lado se utilizará para crear el nuevo documento (“Componente Normalizar Documento” + “Componente Generador PDF”), y por otro lado para obtener las menciones que se han de anonimizar (“Componente Anonimización”). Anonimización: Este componente se encarga de anonimizar las menciones que han sido detectadas por el componente “Detección de menciones”. Para ello, utiliza un enfoque híbrido: por un lado, para las menciones que guardan relación entre sí como las ciudades, provincias y códigos postales, se generará un grafo en el que se representen dichas relaciones entre las entidades. La estructura de este grafo se utilizará para obtener un subgrafo similar a partir de la base de conocimiento, logrando así que las nuevas menciones mantengan la misma jerarquía y relación que las originales (ver Apartado 8.1). Por otro lado, para el resto de las menciones se utilizará una anonimización basada en diccionarios, en el que la mención será sustituida por otra con las mismas características (tipo de mención y número de palabras) (ver Apartado 8.2). El resultado obtenido de este componente es una lista en la que se encuentran las menciones originales (detectadas por el componente de detección), y la mención por la cual se va a sustituir (obtenida en este componente). Normalización de Entidades: Este componente se encarga de comparar el formato de las menciones del documento original, con el de las nuevas menciones, haciendo que estas últimas tengan el mismo formato que las originales. El motivo de la introducción de este componente se debe a que, en muchos casos, hay menciones que se encuentran escritas con todas las letras en mayúsculas, todas en minúsculas, sólo la primera en mayúscula, etc. Por lo tanto, si se hace un reemplazo por las nuevas menciones sin tener esto en cuenta, pueden aparecer fragmentos en el documento que den pie a sospechar que el documento ha sido modificado (por ejemplo que haya un fragmento de texto con todas las letras en mayúsculas, en cuyo interior se encuentre un nombre de persona escrito en minúsculas). Para solucionar este problema, este componente se encarga de obtener el formato de la mención original (uppercase,lowercase o capitalize), y aplicar la misma transformación a la mención por la cual se va a sustituir, modificando así el listado de reemplazos obtenido en el “Componente de Anonimización”. El resultado de este componente se enviará al “Componente de Generación de PDF” para crear el documento final anonimizado. Generación del nuevo PDF: Este componente se encarga de tomar el texto del documento original y la información de las menciones 70 Capítulo 5. Pipeline Desarrollado normalizadas, para generar un nuevo texto a partir de ellas. En este nuevo texto las menciones originales ya han sido sustituidas por sus reemplazos normalizados correspondientes, dando lugar a un texto anonimizado. Una vez se dispone del texto anonimizado, se crea un archivo PDF vacío, se introducen los estilos de diseño de este (cabecera, imágenes, etc), y se escribe el texto anonimizado en él. Una vez se ha terminado de escribir el texto, se persiste el nuevo PDF en disco y se finaliza la ejecución del pipeline. En la siguiente figura (ver Figura 5.3) se muestra un fragmento de un documento anonimizado a través de este pipeline. Figura 5.3: Ejemplo de PDF anonimizado una vez finalizada la ejecución del pipeline. Capítulo 6 Conjunto de Datos del Corpus Los datos son una parte fundamental a la hora de entrenar y evaluar cualquier modelo de Aprendizaje Automático. Es por esto, por lo que realizar una buena elección y división de estos tiene una gran influencia en los resultados finales del modelo. Una buena elección del conjunto de datos tiene como objetivo tomar una muestra (cuanto más grande mejor) de ese conjunto de datos, de tal forma que los datos contenidos en dicha muestra sean variados y representativos del problema que se quiere resolver. El conjunto de datos utilizado para el presente trabajo se encuentra constituido por documentos en formato PDF pertenecientes a distintas áreas de una Administración Pública de carácter local (movilidad, turismo, servicios sociales, urbanismo, etc). En total se dispone de un conjunto de datos formado por 309 documentos de distinto tipo, clase y objeto (permisos de ocupación de vía pública, concesión de ayudas y subvenciones, permisos de obras, cédulas urbanísticas, inspecciones técnicas a inmuebles, etc). Todos los documentos que conforman el conjunto de datos tienen una estructura común, por lo que los elementos principales del mismo (firmas, nombres, área de la administración, etc) se encuentran situadas en la misma zona. Dentro de esta estructura se encuentran diferenciadas las siguientes zonas de interés (Ver Figura 6.1): Cabecera: Se corresponde con la parte superior del PDF. En ella se encuentran los metadatos del documento: firmas, códigos de verificación (CSV), área de la administración, cargo que ocupa, etc. El contenido de esta zona se encuentra delimitado por líneas discontinuas, lo que permite separar esta área del resto. Verificación del documento: Esta zona se encuentra situada en el margen izquierdo del documento. En ella se muestra, de forma vertical, 71 72 Capítulo 6. Conjunto de Datos del Corpus un mensaje indicando que el documento ha sido firmado, así como la forma de verificar la integridad del mismo. Además de esto, esta zona dispone de un código de barras para poder escanear la referencia del documento. Contenido: Esta zona se encuentra situada en la parte central del documento, y se corresponde con su contenido. Al igual que la cabecera, esta zona también se encuentra delimitada (en este caso por un borde sólido). Figura 6.1: Estructura de los documentos utilizados. Estos documentos han sido etiquetados de forma manual y serán utilizados para entrenar el modelo de Deep Learning encargado de detectar automáticamente estas entidades en los nuevos documentos. Las entidades que se van a detectar y anonimizar, así como sus características, particularidades y consideraciones que se han llevado a cabo para cada una son las siguientes: Nombre: En esta categoría se incluyen todos los nombres personales referentes a personas físicas (no se han tomado en cuenta nombres de empresa, organizaciones ni administraciones). En el caso de los nombres compuestos (formados por más de una palabra) como “José Manuel” o “Luis Alberto”, se unirán ambos en una única entidad en lugar de interpretarlas como entidades independientes y compuestas: <Nombre>José Manuel 73 </Nombre> en lugar de <Nombre>José</Nombre> <Nombre> Manuel</Nombre>. Apellido: En esta categoría se incluyen todos los apellidos (por separado) referentes a personas físicas. A diferencia de los nombres personales, en este caso de los apellidos se ha llevado a cabo una división en esta entidad, de tal forma que el primer apellido va separado del segundo: <Apellido>Simón</Apellido> <Apellido>Ramos</Apellido>, en lugar de <Apellido>Simón Ramos</Apellido>. Sin embargo, si uno de los dos apellidos es compuesto, se mantiene la forma de representarlo de los nombres (ambas partes del apellido compuesto en una misma entidad). El motivo de realizarlo de este modo se debe a que existen documentos en los que los apellidos no se encuentran posicionados de forma contigua en el texto una vez este ha sido procesado. Un ejemplo de esto se da en las tablas en las que existen diferentes columnas para cada entidad del nombre personal (columna nombre, columna primer apellido, columna segundo apellido). En estos casos los apellidos no estarían situados de forma contigua, sino que se encuentran separados por el carácter de separación de las celdas de la tabla. Para mantener la representatividad se ha optado por identificar de este modo los apellidos personales DNI: En esta categoría se encuentran comprendidas todas las menciones de números de identificación fiscal y personal de España en los documentos. Esto incluye los DNI (Documento Nacional de Identidad), los NIF (Número de Identificación Fiscal) y los CIF (Código de Identificación Fiscal). A pesar de que en el caso de los residentes en España el DNI y el NIF es el mismo (y el caso de uso que ocupa el proyecto se encuentra enmarcado dentro del contexto español), se ha decidido introducir ambos tipos ya que en el caso de que estos no coincidan, su posición y estructura en el documento es la misma. Por lo tanto, el tener en cuenta esta entidad proporciona información de gran interés desde el punto de vista de la estructura del documento. Además de esto, el hecho de que sean o no iguales no implica ninguna consideración especial dado que se trata de información de carácter personal y por tanto debe ser anonimizada. Dirección: En esta categoría se encuentran todas las referencias a direcciones postales en los documentos. Estas referencias únicamente comprenden el nombre de la dirección postal a la que se refieren, por lo que las partes “Calle”, “Avenida”, “Polígono”, etc, de la dirección y sus derivadas “C\”, “Av.”, etc no se incluyen en las menciones de esta categoría. Además de esto, tampoco se tienen en cuenta otros identificativos de la localización, como el número del piso, el portal, o la escalera. El motivo de esto se debe a que, a pesar de que aportan 74 Capítulo 6. Conjunto de Datos del Corpus información referente a la dirección, esa información no es significativa por sí misma, si no que es información complementaria a la dirección principal. Del mismo modo, la multitud de formas en las que se puede encontrar representada esta información en un documento, junto con la variedad de documentos utilizados dificulta su identificación de una forma correcta. Ciudad: En esta categoría se encuentran comprendidas todas las referencias a las ciudades y municipios de los documentos. Provincia: En esta categoría se engloban las menciones a las provincias que se encuentren en los documentos. CP: En esta categoría se engloban las menciones a los códigos postales de las ciudades y/o municipios que se encuentren en los documentos. Teléfono: En esta categoría se encuentran las referencias de números de teléfono (tanto móviles como fijos) en los documentos. Un punto importante que destacar es que se incluirán todos los números independientemente de su formato. Por ejemplo, algunos de los formatos de teléfono más habituales en documentos de carácter administrativo y que se contemplan en esta categoría son: 983-874-985 o 983 874 985. Referencias Catastrales: En esta categoría se incluyen todos aquellos identificadores de bienes inmuebles que se referencien en los documentos. Dentro de esta categoría se incluyen tanto las referencias catastrales urbanas (en las que se incluye información sobre la parcela, la hoja del plano y el inmueble, por ejemplo 872023 VH5797S 0001 WX), y las referencias catastrales rurales (en las que se incluye información sobre la provincia, el municipio y el sector de la parcela, por ejemplo 13 077 A 018 00039 0000 FP). Seguridad Social: En esta categoría se encuentran todas las menciones referentes a los números de la seguridad social. Este identificador está constituido por 12 dígitos, y contiene información asociada al centro donde se dio de alta el trabajador, el año de alta, el año de nacimiento del trabajador, etc. Cuenta Bancaria: En esta categoría se encuentran todas las referencias a números de cuenta bancaria que se referencien en los documentos. A diferencia de las direcciones, en el caso de las cuentas bancarias se va a incluir toda la referencia de esta, es decir se va a incluir tanto los dígitos correspondientes a la cuenta bancaria, como los dígitos correspondientes a la entidad, sucursal, así como los dígitos de control y el código de país (en este caso es: ES). 75 Email: En esta categoría se engloban todas las referencias a correos electrónicos que se encuentren en los documentos. Estos correos pueden ser de cualquier tipo y de cualquier dominio. Desde dominios habituales (Gmail, Outlook, Yahoo, etc), hasta dominios particulares de entidades, empresas o instituciones (alumnos.uva.es, inf.uva.es, etc). Matrícula: En esta categoría se incluyen las referencias a las matrículas de los vehículos realizadas en los documentos. CSV: El Código Seguro de Verificación (CSV), es un código que se utiliza para identificar de forma unívoca un documento electrónico. Además de esto, este identificador se encarga de garantizar la integridad del documento en el que se encuentra (evitando así que este pueda ser modificado). A pesar de que el código como tal no hace referencia a ninguna entidad personal, es necesario que este sea procesado por el modelo ya que, en el caso de no anonimizarlo, es posible llegar a otros documentos cuyas entidades personales no han sido anonimizadas. Es por esto, por lo que anonimizar esta entidad es de vital importancia ya que permite eliminar todas las relaciones que existen entre distintos documentos a través de este código. URL: En esta categoría se engloban todas las direcciones y enlaces web que se encuentren en los documentos. Para el caso de las url’s, se van a tener en cuenta todo tipo de referencias web siempre y cuando esta sea válida: protocolo (http,https) + host (google.com,facebook.com) + ruta (/login,/verificacion) + variables opcionales en peticiones GET (?variable1=valor1&variable2=valor2). Una característica importante que destacar sobre la identificación de estas entidades es que, en el caso de tener entidades compuestas (entidades formadas por más de una palabra), estas se considerarán como menciones únicas en lugar de como una combinación de varias menciones simples. Un ejemplo de esto es el ya descrito en el caso de las menciones de nombres personales (el nombre “José Manuel” se considera un único nombre en lugar de considerarse como la combinación del nombre “José” y el nombre “Manuel”). El motivo de representar las menciones compuestas como una única entidad, se debe a la premisa de que la información que aporta una entidad es la misma (independientemente del número de palabras que esta tenga). Este mismo supuesto se mantiene en otro tipos de documentos, como los formularios, en los que entidades compuestas (nombre, apellido, dirección, etc) se procesan como una única mención. Por otra parte, desde el punto de vista de la representatividad y la estructuración de la información en documentos administrativos (y en una gran mayoría de otros tipos de documentos), es mucho más habitual e intuitivo 82 Capítulo 7. Construcción del Modelo en la precisión reside en el tamaño del vocabulario (lo que se traduce en un menor número de vectores de representación de palabras). No obstante, esto hace que su velocidad en cuanto al entrenamiento sea muy alta, y el tamaño del pipeline final entrenado en disco sea muy bajo (en torno a los 13-15MB). Esta característica hace que pueda ser utilizada en una gran mayoría de sistemas al no necesitar de demasiados recursos para su funcionamiento. Dentro de todos los pipelines disponibles para el castellano, el orientado a la eficiencia es el es_core_news_sm2. Precisión: Este tipo de pipeline cuenta con los mismos componentes que el anterior. Sin embargo, este pipeline cuenta con un gran número de representaciones de vectores en palabras (concretamente cuenta con 500.000 palabras y vectores, además de un total de 300 dimensiones). Si bien es cierto que esto no es algo fundamental para su funcionamiento, le permite tomar en cuenta un mayor número de características para realizar la predicción, lo cual se traduce en un mejor desempeño final. No obstante, desde el punto de vista de la eficiencia, esta empeora respecto a la tipología anterior. El entrenamiento de los pipelines de este tipo es mucho más lento y costoso que los enfocados a la eficiencia, y el espacio en disco que ocupa cada uno de estos pipelines es muy superior a los anteriores (aproximadamente 550-650MB frente a los 5MB del los orientados para la eficiencia), lo cual es algo a tener en cuenta según qué tipo de caso de uso. Dentro de los pipelines que ofrece Spacy en castellano, el enfocado a la precisión es el es_core_news_lg3. Dado que en la problemática abordada en este trabajo no se cuenta con restricciones en cuanto a tamaño o tiempo de ejecución, se va a realizar el análisis de los hiperparámetros del modelo para ambas optimizaciones de pipelines. 7.1. Proceso de Entrenamiento El proceso que utiliza Spacy para entrenar el modelo es el mismo que el que se utiliza para entrenar cualquier modelo basado en redes neuronales 4 . Para llevar a cabo el entrenamiento, se realizan distintas iteraciones sobre los documentos que conforman el conjunto de datos de entrenamiento (cada una de las iteraciones completas a todo el conjunto de datos se le conoce como época). En cada época, para cada uno de los documentos se toma por un lado el texto, y por el otro lado las anotaciones asociadas al mismo, y se 2https://spacy.io/models/es#es_core_news_sm (Visitado el 14-07-2021). 3https://spacy.io/models/es#es_core_news_lg (Visitado el 14-07-2021). 4 https://machinelearningmastery.com/adam-optimization-algorithm-for-deep-learning/ (Visitado el 16-07-2021). 7.2. Evaluación de los hiperparámetros 83 aplica el modelo sobre el texto del documento, obteniendo así las predicciones del modelo para ese documento. Estas predicciones son comparadas con las anotaciones reales que se disponen y, en base a un algoritmo de optimización del gradiente (en este caso se utiliza el optimizador Adam [18]), se lleva a cabo una modificación en los parámetros internos de las neuronas que conforman la red (modificaciones en los pesos de las entradas de las neuronas). El objetivo es reducir la diferencia entre las anotaciones del modelo y las reales (lo cual se traduce en una mejor calidad de las predicciones). Este proceso es repetido hasta conseguir que exista una coincidencia exacta en todas las anotaciones de todos los documentos (conseguir un 100% de precisión), o hasta que se realice un número nde iteraciones (épocas) sobre todos los documentos del conjunto de datos. Finalmente, el modelo (junto con su configuración de hiperparámetros y neuronas) es exportado para su posterior uso. En el caso de Spacy, se exportan siempre dos modelos: por un lado se tiene el modelo que mejores resultados ha obtenido junto con su configuración (llamado model-best), y por otro lado se exporta el modelo correspondiente a la última época llevada a cabo (llamado model-last). La elección del mejor modelo la realiza Spacy de forma transparente en función de los pesos que se asigne a cada una de las métricas (precisión, recall, F1, etc)5. En la Figura 7.1 se muestra el flujo de ejecución que utiliza Spacy para entrenar los modelos: Figura 7.1: Flujo de entrenamiento de un modelo en Spacy. Fuente: spacy.io (Visitado el 30-06-2021). 7.2. Evaluación de los hiperparámetros En esta sección se llevará a cabo la descripción de los distintos hiperparámetros que se han modificado para optimizar la eficacia del modelo, así como 5 En este caso se ha asignado el 100 % del peso al F1, por lo que Spacy tomará como mejor modelo aquel con el mayor F1. 84 Capítulo 7. Construcción del Modelo los valores utilizados y los resultados obtenidos 6 . Los hiperparámetros que se han modificado son los siguientes: Hiperparámetros relativos al optimizador: Estos hiperparámetros son los que se utilizan a la hora de llevar a cabo la optimización del modelo. La buena elección de estos parámetros permite realizar de forma más efectiva las actualizaciones de los parámetros internos de las neuronas (pesos), lo que se traduce en una mayor y más rápida disminución del error del modelo (diferencia entre el resultado esperado y el resultado real). Entre los distintos hiperparámetros de este tipo los que se han modificado son los siguientes: • Learning Rate: El Learning Rate, también conocido como factor de aprendizaje, es un parámetro que representa en qué proporción se modificarán los pesos de las neuronas. A grandes rasgos, indica qué tan rápido aprende la red neuronal. • Beta 1: El valor Beta 1 ( β1 ) se corresponde con el factor de decaimiento inicial del optimizador. • Beta 2: El valor Beta 2 ( β2 ) se corresponde con el factor de decaimiento para el segundo instante del optimizador. Este parámetro se utiliza en combinación con β1 para estimar los primeros instantes del gradiente, dicho de otro modo, sirven para inicializar la componente relativa al gradiente en el algoritmo. • Épsilon: El valor de épsilon ( ϵ ) es un valor muy pequeño que se utiliza para prevenir que se produzcan divisiones por cero dentro del algoritmo, evitando así posibles errores. • Decay Factor: El factor de decaimiento determina el peso de los valores obtenidos en cada una de las iteraciones del algoritmo frente a los valores existentes. Hiperparámetros relativos al proceso de entrenamiento: Estos hiperparámetros determinan las características del entrenamiento, por ejemplo, el número de iteraciones que se van a realizar sobre el conjunto de datos, si los datos van a ser procesados en pequeños lotes (batches) en lugar de todos juntos, etc. Los parámetros de este tipo que se han modificado durante el entrenamiento son los siguientes: • Batch Size: Esta variable determina el número de documentos que se van a procesar antes de llevar a cabo el cálculo del error y la 6 Se ha fijado un valor de semilla (semilla = 23) para controlar la generación de los valores aleatorios que se producen en las distintas fases del entrenamiento. De este modo, todos los experimentos realizados pueden ser reproducidos, obteniendo así los mismos resultados que los presentados en este documento. 7.2. Evaluación de los hiperparámetros 85 optimización del modelo (en lugar de realizar esta optimización tras iterar sobre todos los documentos del conjunto de entrenamiento). En el caso de no especificar nada, se entiende que únicamente existe un lote (compuesto por todos los datos del conjunto de entrenamiento), y que la optimización no se llevará a cabo hasta haber iterado sobre todos ellos. • Dropout: El dropout es una técnica que se aplica durante el proceso de entrenamiento de una red neuronal para prevenir el sobreajuste. Esta técnica consiste en “omitir” neuronas de forma aleatoria en cada época del entrenamiento, y realizar el ajuste de los pesos sin tener en cuenta a dichas neuronas. La variable dropout determina la proporción de neuronas que se omitirán de forma aleatoria en cada una de las épocas del entrenamiento del modelo. En este punto cabe destacar que, los hiperparámetros correspondientes al optimizador tienen una fuerte dependencia entre sí, por lo que su modificación ha de realizarse en pequeños incrementos en lugar de grandes variaciones o la utilización de valores aleatorios. Todo esto, unido a la complejidad que tiene seleccionar unos buenos parámetros, hace que este proceso de “prueba y error” pueda ser demasiado largo. Para solventar esto, se ha tomado como referencia distintas combinaciones de hiperparámetros del optimizador que utilizan las principales librerías actuales orientadas al Deep Learning: TensorFlow 7 y Keras (ver Tabla 7.1). Librería Learning Rate Beta 1 (β1) Beta 2 (β2) Epsilon (ϵ) Decay Factor TensorFlow/Torch 0.001 0.9 0.999 10−8- Keras 0.001 0.9 0.999 10−80 Tabla 7.1: Valores de los hiperparámetros del optimizador en otras librerías de Deep Learning. Fuente: machinelearningmastery.com (Visitado el 02-07-2021). 7.2.1. Evaluación de Resultados Globales Una vez se han definido los distintos parámetros que se van a modificar para maximizar la eficacia del modelo, en esta sección se llevará a cabo la comparativa y análisis de los resultados obtenidos para las distintas pruebas realizadas. Cabe destacar que, al haber probado con tantas variaciones en los hiperparámetros, se va a llevar a cabo un filtro inicial para evitar profundizar en el análisis con configuraciones que no son adecuadas. Para ello, se llevará a cabo 7 En lo relativo al establecimiento de estos valores por defecto, también se ha tenido en cuenta la librería Torch. Sin embargo, dado que los valores que emplea son los mimos que los de TensorFlow se ha decidido mencionar únicamente esta. 86 Capítulo 7. Construcción del Modelo un primer estudio de todas las configuraciones en base a sus métricas generales (Precisión, Recall y F1). De este estudio, se tomarán las mejores configuraciones y sobre ellas se profundizará en el análisis (tratando las mismas métricas pero bajando al nivel de entidad). En las Tablas 7.2 y 7.3 se muestran las métricas globales de las distintas configuraciones de hiperparámetros utilizadas para los modelos optimizados para mejorar la eficiencia, y los modelos optimizados para mejorar la precisión. Del mismo modo en las Figuras 7.2 y 7.3 se muestra la comparativa entre la métrica F1 de las distintas configuraciones utilizadas. Para obtener estas métricas se han utilizado los documentos del subconjunto de datos de entrenamiento (procesados en batches). Al finalizar cada una de las épocas, el modelo resultante se aplica sobre los documentos del subconjunto de validación y prueba (generando así sus métricas asociadas). Del mismo modo, se calcula la tasa de error del modelo, la cuál será utilizada por el algoritmo de optimización (Adam) para modificar los parámetros internos del modelo, y así tratar de disminuir la tasa de error en épocas posteriores. 7.2. Evaluación de los hiperparámetros 87 ID Modelo Configuración Optimizador Batch Dropout Learning Rate Decay Factor Precision Recall F1 1TensorFlow 50 0,1 0,001 - 0,948 0,935 0,941 2TensorFlow 100 0,1 0,001 - 0,948 0,935 0,941 3Keras 50 0,1 0,001 0 0,955 0,928 0,941 4Keras 100 0,1 0,001 0 0,955 0,928 0,941 5TensorFlow 50 0,2 0,001 - 0,943 0,936 0,939 6TensorFlow 100 0,2 0,001 - 0,943 0,936 0,939 7Keras 50 0,2 0,001 0 0,953 0,930 0,942 8Keras 100 0,2 0,001 0 0,953 0,930 0,942 9TensorFlow 50 0,3 0,001 - 0,957 0,912 0,934 10 TensorFlow 100 0,3 0,001 - 0,957 0,912 0,934 11 Keras 50 0,3 0,001 0 0,961 0,918 0,939 12 Keras 100 0,3 0,001 0 0,961 0,918 0,939 13 TensorFlow 50 0,1 0,01 - 0,871 0,809 0,839 14 TensorFlow 100 0,1 0,01 - 0,871 0,809 0,839 15 Keras 50 0,1 0,01 0 0,870 0,864 0,867 16 Keras 100 0,1 0,01 0 0,870 0,864 0,867 17 TensorFlow 50 0,2 0,01 - 0,858 0,819 0,838 18 TensorFlow 100 0,2 0,01 - 0,858 0,819 0,838 19 Keras 50 0,2 0,01 0 0,926 0,728 0,815 20 Keras 100 0,2 0,01 0 0,926 0,728 0,815 21 TensorFlow 50 0,3 0,01 - 0,908 0,809 0,855 22 TensorFlow 100 0,3 0,01 - 0,908 0,809 0,855 23 Keras 50 0,3 0,01 0 0,892 0,764 0,823 24 Keras 100 0,3 0,01 0 0,892 0,764 0,823 Tabla 7.2: Resultados obtenidos para distintas configuraciones del modelo basado en la Eficiencia Verde (Mejor); Amarillo (Segundo Mejor); Rojo (Peor). 88 Capítulo 7. Construcción del Modelo ID Modelo Configuración Optimizador Batch Dropout Learning Rate Decay Factor Precisión Recall F1 1TensorFlow 50 0,1 0,001 - 0,940 0,948 0,944 2TensorFlow 100 0,1 0,001 - 0,940 0,948 0,944 3Keras 50 0,1 0,001 0 0,933 0,880 0,910 4Keras 100 0,1 0,001 0 0,933 0,880 0,910 5TensorFlow 50 0,2 0,001 - 0,933 0,899 0,916 6TensorFlow 100 0,2 0,001 - 0,933 0,899 0,916 7Keras 50 0,2 0,001 0 0,943 0,891 0,917 8Keras 100 0,2 0,001 0 0,943 0,891 0,917 9TensorFlow 50 0,3 0,001 - 0,931 0,888 0,909 10 TensorFlow 100 0,3 0,001 - 0,931 0,888 0,909 11 Keras 50 0,3 0,001 0 0,947 0,918 0,933 12 Keras 100 0,3 0,001 0 0,947 0,918 0,933 13 TensorFlow 50 0,1 0,01 - 0,809 0,737 0,771 14 TensorFlow 100 0,1 0,01 - 0,809 0,737 0,771 15 Keras 50 0,1 0,01 0 0,864 0,808 0,835 16 Keras 100 0,1 0,01 0 0,864 0,808 0,835 17 TensorFlow 50 0,2 0,01 - 0,886 0,751 0,813 18 TensorFlow 100 0,2 0,01 - 0,886 0,751 0,813 19 Keras 50 0,2 0,01 0 0,841 0,781 0,810 20 Keras 100 0,2 0,01 0 0,841 0,781 0,810 21 TensorFlow 50 0,3 0,01 - 0,849 0,720 0,779 22 TensorFlow 100 0,3 0,01 - 0,849 0,720 0,779 23 Keras 50 0,3 0,01 0 0,884 0,742 0,807 24 Keras 100 0,3 0,01 0 0,884 0,742 0,807 Tabla 7.3: Resultados obtenidos para distintas configuraciones del modelo basado en la Precisión Verde (Mejor); Amarillo (Segundo Mejor); Rojo (Peor). 7.2. Evaluación de los hiperparámetros 89 Figura 7.2: Comparativa de la métrica F1 de los modelos enfocados a la Eficiencia. Figura 7.3: Comparativa de la métrica F1 de los modelos enfocados a la Precisión. Conclusiones En base a los resultados obtenidos para las distintas configuraciones utilizadas, así como los diferentes modelos enfocados a la optimización de diferentes características, las conclusiones que se pueden sacar son las siguientes: Supresión de parámetros: Como se puede ver en los resultados anteriores, tanto para el caso de modelos enfocados en la eficiencia, como modelos enfocados en la precisión, el valor del parámetro batch size no afecta al desempeño del modelo (los resultados son siempre los mismos independientemente del valor que este parámetro tome). Teniendo esto en cuenta, este parámetro dejará de ser analizado en la memoria y se pasará a utilizar el valor por defecto (batch size = 50). 90 Capítulo 7. Construcción del Modelo Disminución de los resultados a medida que se aumenta el dropout: En todos los casos probados, los resultados globales obtenidos o bien se mantienen, o bien empeoran de forma sustancial a medida que se incrementa el valor de dropout. Teniendo esto en cuenta, a la hora de comparar entre dos modelos con resultados parejos, se priorizará aquel cuyo valor de dropout sea mayor. Esto se debe a que, en términos generales, un modelo al que se le ha aplicado un droput más fuerte durante su entrenamiento, tiende a generalizar mejor (ya que no sufrirá de tanto sobreajuste). Disminución de los resultados a medida que aumenta el factor de aprendizaje: Al igual que ocurre en el caso del dropout, los resultados obtenidos al aumentar el valor del factor de aprendizaje disminuyen de forma notoria en todos los casos probados. Una hipótesis de esta particularidad es que, al utilizar un valor tan elevado, la optimización no es tan buena como para valores más pequeños, ya que es posible que las modificaciones que hayan de realizarse sobre los parámetros de la red sean tan pequeñas y sutiles, que son imposibles de obtener al aumentar el factor de aprendizaje. Otro motivo de esto puede venir asociado a una disminución del sobreajuste por parte del modelo. Los modelos orientados a la eficiencia obtienen mejores resultados que los orientados a la precisión: Este resultado es muy interesante ya que no es algo directamente intuitivo a nivel teórico. El motivo de obtener mejores resultados en modelos enfocados a mejorar la eficiencia se debe a que la información extra que tienen los modelos enfocados a la precisión (vectores, relaciones entre palabras, etc), no es útil, o no se puede aprovechar del todo para resolver la situación que se está desarrollando. Posiblemente, en otros casos de uso, o casos de uso más complejos en los que haya que obtener las relaciones semánticas entre palabras, su tipología, u otras características, la información extra que ofrecen estos modelos orientados a la precisión pueda ser utilizada de una forma más eficaz, obteniendo unos mejores resultados finales. Sin embargo, para el caso de detección de entidades nombradas en este tipo de documentos, ese exceso de información que aporta un modelo frente a otro no es aprovechado al 100%. Por lo tanto, se puede concluir que la utilización de un modelo más complejo para un caso de uso simple empeora los resultados en la mayoría de las pruebas llevadas a cabo. Asímismo, podemos afirmar que para este caso de uso concreto, el modelo simple es capaz de generalizar mejor el problema que el modelo complejo. Las configuraciones del optimizador son muy similares: Finalmente, desde el punto de vista de las configuraciones del optimizador (TensorFlow vs Keras), los resultados obtenidos no permiten sacar unas conclusiones firmes sobre su eficacia. Existen situaciones en las que una 7.2. Evaluación de los hiperparámetros 91 configuración obtiene mejores resultados que la otra (Modelo 6 vs Modelo 7 o Modelo 22 vs Modelo 23). Por lo tanto, dado que el uso de unos parámetros u otros es prácticamente despreciable en términos de tiempos de ejecución, la elección de una configuración u otra se limitará a aquella que proporcione unos mejores resultados finales. Teniendo en cuenta estas conclusiones, se van a seleccionar los modelos: Modelo 7 (Eficiencia); y Modelo 1 (Precisión) (ver Figura 7.4) para continuar con el análisis y profundizar en los resultados de ambos a nivel de entidad. Figura 7.4: Comparativa de las métricas de los modelos seleccionados. 7.2.2. Evaluación de Resultados a nivel de Entidad Tras haber realizado un primer análisis probando distintas configuraciones de hiperparámetros y modelos, se han seleccionado los modelos: Modelo 7 (Eficiencia); y Modelo 1 (Precisión) para analizar a nivel de entidad. El objetivo de esta sección consiste en, teniendo en cuenta los resultados obtenidos anteriormente, y los resultados que se presentan a continuación, analizar y seleccionar el modelo que tenga un mejor desempeño. Este modelo será el que se utilice en la herramienta desarrollada, y será el núcleo principal de la detección de las menciones personales. En las Tablas 7.4 y 7.5, se muestran los resultados de ambos modelos a nivel global, así como para cada uno de los tipos de entidad a detectar por la herramienta: 98 Capítulo 7. Construcción del Modelo Sin embargo esta mejora no es visible desde el punto de vista de las métricas globales, ya que existe un sesgo en torno a la cantidad de entidades de cada tipo (ver Tabla 6.1). Dado que los tipos de menciones cuyas métricas han mejorado más con la aplicación de expresiones regulares son también las que tienen un menor número de apariciones en los documentos, todas las mejoras que se hagan sobre las mismas apenas son visibles en los resultados a nivel global. Esto también se puede comprobar en los resultados generales obtenidos al aplicar únicamente expresiones regulares (ver Tabla 7.8), cuyo F1 global es apenas del 4 %. Por lo tanto, teniendo todo esto en cuenta, se puede concluir que la introducción de expresiones regulares ha mejorado considerablemente los resultados del modelo, logrando detectar (con prácticamente un 100% de acierto) aquellas entidades con una estructura fija y predecible (referencias catastrales, emails, matrículas, etc), a pesar de que el modelo por sí solo no era capaz de detectarlas. Capítulo 8 Sistema de Generación de los Reemplazos Uno de los puntos más importantes del proyecto consiste en llevar a cabo la implementación del sistema de anonimizacion de los documentos. Este sistema de anonimización permite desligar cada uno de los documentos de las personas, entidades, instituciones, etc, que se mencionan en él. A pesar de que esta anonimizacion puede muy ser sencilla e inmediata (simplemente eliminando las entidades detectadas del documento), en este proyecto se va a implementar un sistema más complejo y realista, atendiendo a las características del documento (idioma) y al entorno en el que se encuentra enmarcado. Las características que tiene el sistema de generación de reemplazos implementado son: Robustez: El sistema es capaz de generar reemplazos de una forma genérica para cualquier combinación de entidades que se le presente. Además, en el caso de no poder encontrar reemplazos válidos (reemplazos que no se ajusten a las características del generador), el sistema genera una alternativa que continúa manteniendo la integridad del nuevo documento. Integridad: Los reemplazos generados mantienen la integridad del documento. Esto se traduce en que las nuevas entidades generadas mantienen la tipología (tipo de entidad) y estructura (número de palabras) de la entidad a la que reemplazan. Concordancia: En el caso de entidades que guarden una relación estrecha o fuerte (provincias, ciudades, códigos postales, etc), el sistema es capaz de generar los reemplazos de forma que se mantenga una concordancia entre ellas. De este modo, si en un documento hay que reemplazar una ciudad y su provincia, los reemplazos generados mantendrán esta relación, y la nueva provincia generada contendrá la nueva 99 100 Capítulo 8. Sistema de Generación de los Reemplazos ciudad. Además de esto, el sistema es capaz de manejar relaciones débiles como las calles y los números de teléfono, de tal forma que estos se ajustan a las nuevas provincias y ciudades generadas. Del mismo modo, en el caso de no poder garantizar la concordancia (debido a la vulneración de otros factores que se han de tener en cuenta como la robustez o la integridad), el sistema es capaz de mantener concordancias parciales entre las entidades afectadas. Acorde a la realidad: El nuevo documento generado que utiliza los reemplazos es lo más parecido posible al documento real del que parte. De este modo, puede pasar desapercibido y no parecer que haya sido alterado. Genericidad: El sistema es capaz de generar reemplazos para todo tipo de documentos independientemente de su tipología. Para que el sistema cumpla todas estas características se ha desarrollado un mecanismo de reemplazo híbrido. Por un lado, se procesan las entidades susceptibles de mantener relaciones entre sí (provincias, ciudades, etc), generando reemplazos correlacionados mediante búsqueda en grafos (ver Apartado 8.1). Una vez se han procesado las entidades relacionadas, se aplica un mecanismo de reemplazo basado en diccionarios para reemplazar las entidades que no tengan relación entre sí (nombres, apellidos, cuentas bancarias, etc) (ver Apartado 8.2). El mecanismo de generación de los reemplazos parte de una estructura de datos basada en diccionarios (o tablas hash, en función del lenguaje de programación), en el que cada documento tiene asociado un diccionario vacío. A medida que se van ejecutando los distintos mecanismos de reemplazo del sistema híbrido, este diccionario se va actualizando, creándose una entrada para cada entidad original cuyo valor será el reemplazo generado. Al finalizar el proceso, el diccionario tiene una entrada para cada una de las distintas entidades del documento junto con el valor (nueva entidad) por la que será reemplazada. Finalmente, se construye el documento final sustituyendo las entidades originales por su reemplazo correspondiente, todo ello según el valor que tenga la clave en el diccionario de reemplazos. En la Figura 8.1 se muestra el flujo de generación de los reemplazos para las entidades de un documento. 8.1. Generación de reemplazos basados en Grafos 101 Figura 8.1: Estructura del flujo para la generación de los reemplazos. 8.1. Generación de reemplazos basados en Grafos El primer mecanismo para la generación de reemplazos dentro del sistema híbrido implementado consiste en un sistema basado en grafos. Este sistema dispone de un grafo de conocimiento en el que se incluyen todas las provincias, ciudades y códigos postales a nivel nacional (a partir de ahora lo denominaremos grafo general). Cada uno de los valores únicos de estas entidades se traducirá en un nodo dentro del grafo, y sus relaciones se traducirán en aristas que conecten dichos nodos (ver Apartado 8.1.1). A partir de la información que ofrece el grafo general, se construye el grafo correspondiente a las entidades del documento (denominado grafo del documento). Para ello, se realizará una creación en dos fases: Fase 1: Creación de los nodos. En esta fase se toman todas las entidades del documento susceptibles de estar relacionadas entre sí (en este caso provincias, ciudades y códigos postales), y se crea un nodo dentro del grafo del documento para cada una de ellas (ver Figura 8.2). Sin embargo, como se mencionará en la Fase 2, el establecimiento de las conexiones entre los nodos del grafo del documento se lleva a cabo mediante una comparativa entre pares de nodos del grafo del documento y el grafo general. De este modo, si el par de nodos del grafo del documento se encuentran conectados en el grafo general, se establecerá una conexión entre los nodos en el grafo del documento. Esto implica que la comparativa entre nodos se lleva a cabo mediante una coincidencia exacta de ambas entidades, lo cual es un gran problema. Esto hace que, en el caso de que exista alguna variación de sintaxis o de formato entre las entidades, no se establecerá una relación entre entidades que realmente si que la tienen. Para el caso de los problemas de formato la solución es sencilla ya que se puede aplicar la misma transformación a todas las entidades (eliminación de acentos, transformación a mayúsculas o minúsculas, 102 Capítulo 8. Sistema de Generación de los Reemplazos Figura 8.2: Ejemplo de entidades de un documento antes de realizar las conexiones. etc) para que puedan ser comparadas y relacionadas. No obstante, esta solución presupone que no existen errores en cuanto a la escritura de la entidad en el documento original, algo que ni para este caso de uso (debido al OCR) ni para una solución genérica se puede presuponer (siempre pueden existir errores humanos). Sin embargo, una de las cosas que sí se puede suponer, es que las entidades que conforman el grafo general son correctas (tanto en sintaxis como en formato). Gracias a esto, se pueden emplear las entidades del grafo general como referencia de cara a la posterior comparativa con las entidades en los documentos. Partiendo de esa premisa, se ha planteado un paso previo de normalización de entidades mediante un enfoque basado en búsquedas por similitud, también denominada búsqueda difusa. Para ello, en lugar de crear un grafo asociado al documento, cuyos nodos sean exactamente las mismas entidades que las del documento original, se creará un grafo cuyos nodos serán las entidades del grafo general más similares a las del documento. Por ejemplo, en el caso planteado anteriormente (ver Figura 8.2), se puede ver cómo en el documento original aparece la entidad “Valladoli” y en el grafo general esta misma entidad se encuentra definida como “Valladolid”. Como con total seguridad la entidad “Valladolid” será la entidad del grafo general con una mayor similitud a la entidad del documento, el nodo que se cree en el grafo del documento será “Valladolid” (en lugar de “Valladoli”). De forma análoga ocurre lo mismo para los casos “Zegobia” → “Segovia”, o “La Lastriya” → “La Lastrilla”. Además de esto, para mantener la trazabilidad, todas estas transformaciones serán almacenadas para mantener la relación Entidad del documento ⇒Nodo del Grafo del Documento ⇒Reemplazo generado. 8.1. Generación de reemplazos basados en Grafos 103 La forma que se ha seguido para determinar si dos entidades (la entidad del documento y la entidad del grafo) son la misma, viene dada por el Ratio de similitud. Este ratio viene dado por la siguiente fórmula: Ratio =1−(levp1,p2(|p1|,|p2|)) max(|p1|,|p2|);Ratio ∈[0,1] Donde: • lev: Es el cómputo de la Distancia de Levenshtein 1 (menor número de inserciones, sustituciones o eliminaciones para obtener una palabra a partir de otra) entre ambas palabras (p1yp2). • max( p1 , p2 ): es el valor máximo de las longitudes de ambas palabras. Por otra parte, se ha establecido un valor umbral, de tal forma que si el mayor ratio de similitud entre una entidad en el documento, y su mayor coincidencia dentro del grafo general no supera dicho umbral, la entidad del documento se mantiene tal cual en el grafo (y se procesará como entidad aislada e independiente). De este modo se consigue no añadir un exceso de ruido ni a los nodos que conforman el grafo del documento, ni a sus relaciones. Gracias a la implementación mediante búsqueda difusa, se consigue mejorar la concordancia entre los reemplazos. Esto se debe a que, en el caso de haber continuado con métodos basados en coincidencias exactas, la concordancia entre entidades se vería afectada al no poder establecer relaciones entre entidades (o establecer un menor número de ellas). Por lo tanto, el sistema sería equivalente a realizar reemplazos de entidades por otras del mismo tipo, sin atender a las relaciones entre ellas. Fase 2: Establecimiento de las conexiones: Para cada par de nodos del grafo del documento, se comprueba si estos están conectados dentro del grafo general. En el caso de que lo estén, se creará una arista que una ambos nodos en el grafo del documento. Esta comprobación finalizará cuando se haya terminado de comparar todos los pares de nodos del grafo del documento. Debido al paso previo de normalización llevado a cabo en la Fase 1, se puede garantizar que todas las componentes del grafo del documento con más de un nodo se corresponden con un subgrafo dentro del grafo general. Por otra parte, en el caso de las componentes aisladas (con un único nodo), pueden corresponderse o no con subgrafos del grafo general2. 1 https://www.analyticslane.com/2020/06/17/la-distancia-de-levenshtein/ (Visitado el 19-07-2021). 2 Esto se debe al establecimiento de un valor umbral a la hora de calcular la similitud entre palabras en la Fase 1. En el caso de no establecerlo, todas las componentes del grafo 104 Capítulo 8. Sistema de Generación de los Reemplazos En cambio, a pesar de solventar el problema de los errores de sintaxis y/o formato de las entidades, esta propuesta sufre una alta dependencia del estado de la base de conocimiento con la que se crea el grafo general. Si bien es cierto que el funcionamiento del mecanismo no depende de este grafo (ya que en el caso de no poder asociar los nodos, las entidades se reemplazan por otras aleatorias del mismo tipo), una base de conocimiento escasa o alejada del caso de uso a tratar implica no poder establecer relaciones entre los nodos del grafo del documento. Esto se traduce en que el grafo del documento sea un grafo constituido por Ncomponentes simples, siendo Nel número de entidades distintas en el documento. A pesar de que este problema se soluciona sustituyendo cada entidad por otra del mismo tipo, añade un tiempo de ejecución innecesario, ralentizando el proceso, y añadiendo una carga de computación extra (dado que tiene que hacer todo el proceso de búsquedas en grafos descrito anteriormente). Por este motivo, es de gran importancia disponer de una buena base de conocimiento para así evitar este tipo de problemas. Finalmente, tras la consecución de ambas fases, se dispondrá de un grafo de entidades del documento que guardarán relación entre sí, así como las relaciones que existen entre ellas (ver Figura 8.3). Figura 8.3: Ejemplo de entidades del documento tras haber establecido las conexiones. 8.1.1. Creación del Grafo General El grafo general constituye el eje central del mecanismo de generación de reemplazos correlacionados. En él se encuentra toda la información tanto de del documento se corresponderían con subgrafos del grafo general (independientemente del número de nodos que la conformasen). 8.1. Generación de reemplazos basados en Grafos 105 las entidades que se utilizarán para reemplazar las entidades originales, así como sus características (número de palabras, tipo de entidad, etc). Una de las características que ofrece la librería de grafos utilizada (ver Apartado 1.3), es que el grafo internamente se encuentra representado e implementado como un diccionario. Esto implica que las consultas a los atributos y características de los nodos se lleven a cabo en un tiempo de ejecución constante ( O (1)). Además, asegura que no existan nodos de una misma entidad duplicados. La creación de este grafo se lleva a cabo a partir de un fichero de texto (en formato .csv), en el que se encuentra la base de conocimiento de forma estructurada que se empleará para crear este grafo 3 . Esta base de conocimiento ha sido obtenida combinando los datos de las provincias y municipios (Ver fila DIRECCIÓN en la Tabla 8.1), con el listado de códigos postales por municipio 4 . En el Código 8.4 se muestra un ejemplo de la estructura de registros del fichero utilizado para generar el grafo general. Del mismo modo, en la Figura 8.4 se muestra la representación de estos registros en forma de grafo, una vez han sido procesados. Provincia;Ciudad;CP Valladolid;Gomeznarro;47493 Valladolid;Honcalada;47219 Segovia;Languilla;40556 Segovia;Lastras De Cuellar;40352 Soria;Almazul;42126 Soria;Almenar;42130 Código 8.4: Estructura de los registros del fichero para generar el grafo general. 3 En este caso, el grafo contendrá únicamente información sobre Provincias, Ciudades y Códigos Postales, pero es extrapolable a cualquier otro tipo de relación de entidades. 4https://github.com/inigoflores/ds-codigos-postales-ine-es (Visitado el 02-07-2021). 106 Capítulo 8. Sistema de Generación de los Reemplazos Figura 8.4: Ejemplo reducido de la estructura del grafo general. Para cada uno de los registros del fichero de datos, se obtienen las entidades dividiendo por el separador utilizado (en este caso ;). Seguidamente, se crea un nodo para cada una de las entidades y se les asignan atributos internos para posteriormente poder operar con estos nodos (en el caso de que el nodo ya exista no se hace nada). Los atributos internos que se les asigna a cada nodo son los siguientes: n_tokens: Este atributo almacena el valor numérico, correspondiente al número de tokens (palabras) que tiene la entidad. tipo: Atributo numérico que se utiliza para representar tanto el tipo de entidad como su nivel de profundidad o importancia dentro de la jerarquía de nodos. Este atributo toma el valor 0 en el caso de ser una provincia; 1 en el caso de tratarse de una ciudad; y 2 en el caso de ser un código postal. Finalmente, una vez se han creado los nodos correspondientes a las entidades de ese registro, se unen entre sí siguiendo el orden en el que se encontraban en el fichero. Por ejemplo, si el orden del fichero es: provincia, ciudad, código postal; el nodo creado para esa provincia se une al nodo de esa ciudad, y así sucesivamente. Un punto que destacar desde el punto de vista de la implementación es que, dado que para mejorar el desempeño de este mecanismo se requiere de una base de conocimiento amplia, el proceso de leer y procesar el fichero con los datos, así como generar el grafo supone un tiempo de procesamiento y cómputo 8.1. Generación de reemplazos basados en Grafos 107 a tener en cuenta. Para evitar este coste computacional extra, además de para mejorar la eficiencia del sistema, el grafo generado se almacenará en disco en forma serializada una vez este haya sido creado. De este modo, se reduce tanto el tiempo de ejecución como la carga de procesamiento al no tener que generar siempre el grafo desde cero, haciendo que únicamente sea necesario generarlo una vez y cargarlo desde el disco en posteriores ejecuciones. 8.1.2. Obtención de reemplazos en grafos Una vez se dispone tanto del grafo general, como del grafo asociado al documento (nodos y conexiones entre los nodos), el método que se va a utilizar para obtener los reemplazos consiste en obtener del grafo general un subgrafo con la misma estructura que el grafo del documento (ver Figura 8.5). Este método es conocido dentro de la Teoría de Grafos como Problema de Isomorfismo de Subgrafos [5]. Figura 8.5: Ejemplo de búsquedas de isomorfismos de subgrafos. El principal problema que existe en cuanto a la utilización de este tipo de métodos es que se encuentra enmarcado dentro del conjunto de problemas NP-Complejos 5 . Esto quiere decir que su resolución no puede ser realizada ni representada de forma polinomial, por lo que el tiempo y coste necesario para su resolución puede ser muy elevado (algo que se quiere evitar). Además de esto, las restricciones impuestas a las nuevas entidades (número de palabras, tipo de entidad, etc) hace que esta búsqueda sea más compleja y costosa. Si bien es cierto que los grafos que se generan a partir de los documentos utilizados en este proyecto no presentan problema (no son excesivamente complejos, por lo que esta búsqueda es relativamente rápida (del orden de milisegundos (ver Apartado 9.6))), para un caso de uso genérico en el que puede haber una mayor complejidad de estructuras sí que suponen un problema. Dado 5http://es.knowledger.de/0078452/NPhard (Visitado el 18-07-2021). 114 Capítulo 8. Sistema de Generación de los Reemplazos Figura 8.8: Flujo para la comprobación del tipo de entidad del DNI (DNI, NIE, CIF). • Teléfono: Para el caso de los números de teléfono el proceso de generación del reemplazo es similar al ya presentado para los DNI’s. Para ello, se genera un número aleatorio de 9 dígitos y, en función del nuevo valor del prefijo obtenido mediante diccionarios, se sustituyen los nprimeros dígitos del nuevo teléfono por el nuevo prefijo. • Cuenta Bancaria: Para la generación de las cuentas bancarias, se ha decidido anonimizar únicamente una parte del número de cuenta. El motivo de esto se debe a que, como se puede ver en la Figura 8.9, el número IBAN contiene diversos identificadores comunes en su interior (identificador de la entidad bancaria, identificador de la sucursal, etc). Dado que estos identificadores son públicos y generalmente conocidos (182 BBVA, 49 Santander, 73 Open Bank, etc), el generar un nuevo IBAN a partir de un número aleatorio (como ocurre con los teléfonos o los DNI), hace que sea más evidente que este nuevo número es falso. Por lo tanto, en el caso de las cuentas bancarias se va a mantener toda la mención original, a excepción de los últimos diez dígitos (correspondientes al número de cuenta). A pesar de que el resto del IBAN se mantenga sin modificar, la generación de un número de cuenta aleatorio es suficiente para desvincular a una persona de un determinado número de cuenta. Además de esto, el nuevo número continuará siendo realista, e incluso puede llegar a ser falso (puede ser que el número de cuenta generado no exista en la sucursal de esa entidad bancaria). Sin embargo, al tener el resto de los identificadores sin modificar, es menos evidente el hecho de que ha habido una modificación en esta entidad. 8.2. Generación de reemplazos basados en Diccionarios 115 Figura 8.9: Formato número IBAN. Fuente: kelisto.es (Visitado el 12-07-2021). • CSV, Referencia Catastral, Seguridad Social y Matrícula: Para el caso de este tipo de entidades, el procedimiento a seguir para generar el reemplazo es el mismo. Para ello, se itera sobre los caracteres de la entidad antigua y se genera un carácter aleatorio en función de su tipo. Por ejemplo, si la entidad antigua es AB3 la nueva entidad se obtendría calculando una letra aleatoria entre la a y la z (correspondiente al carácter A), otra letra aleatoria (correspondiente al carácter B), y un número aleatorio entre el 0 y el 9 (correspondiente al carácter 3). Un punto importante que destacar es que, a pesar de que la explicación de la generación de los reemplazos en este tipo de entidades se ha tratado desde el punto de vista ideal (sin ningún carácter atípico o separador entre caracteres), este método mantiene el formato de la entidad antigua. Para ello, una vez generado el nuevo reemplazo, se le añaden los caracteres atípicos procedentes de la entidad original. Por ejemplo, en el caso de tener el siguiente DNI: 59.863.210-Y, la generación del nuevo reemplazo se realiza sin tener en cuenta ni los espacios ni los caracteres extra (.y-). Suponemos que el nuevo reemplazo para esa entidad que se ha obtenido y validado es: 90543256F. Una vez obtenido dicho reemplazo, se procesa para hacer que este mantenga el formato del original. Teniendo esto en cuenta, y continuando con el ejemplo descrito, la salida proporcionada por el método es: 90. 543.256-F. Capítulo 9 Herramienta Software 9.1. Descripción de los Actores En la primera sección de este capítulo se llevará a cabo la descripción de los distintos actores que interactúan con la herramienta software desarrollada. Cabe destacar que, al tratarse de una herramienta básica para interactuar con el pipeline desarrollado (no requiere de autenticación ni verificación de ningún tipo), únicamente va a tener un actor. El actor que conforma el usuario, así como sus características viene descrito en la Tabla 9.1: A-01 Usuario Versión 1.0 (17/07/2021). Descripción Este tipo de actor utilizará la herramienta software desarrollada para anonimizar referencias personales en documentos en formato PDF. Además podrá exportar los resultados finales a un nuevo fichero PDF. Comentarios No necesita de autenticación ni de verificación de acceso. Tabla 9.1: Descripción del Actor-01: Usuario. 9.1.1. Requisitos de Usuario En esta sección de presentarán los distintos requisitos de usuario que la herramienta software ha de satisfacer. En la Tabla 9.2 se muestran los distintos requisitos de usuario asociados al actor Usuario: 117 118 Capítulo 9. Herramienta Software ID Nombre RU-01 Un usuario puede cargar en la herramienta documentos en formato PDF. RU-02 Un usuario puede visualizar las menciones personales detectadas por el modelo NER en el documento cargado. RU-03 Un usuario puede anonimizar un documento en formato PDF cargado en la herramienta software. RU-04 Un usuario puede visualizar el resultado de la anonimización de las referencias personales . RU-05 Un usuario puede exportar el documento anonimizado a un nuevo documento PDF. Tabla 9.2: Requisitos de Usuario del Sistema. 9.1.2. Casos de Uso A lo largo de la presente sección se presentan los distintos casos de uso a satisfacer por la herramienta software, el requisito de usuario asociado y la especificación de estos. En la Tabla 9.3 se muestran los distintos casos de uso que se han obtenido a partir de los requisitos de usuario descritos en el Apartado 9.1.1: ID Requisito de Usuario Asociado Nombre CU-01 RU-01, RU-02 Cargar documento. CU-02 RU-03, RU-04 Anonimizar documento. CU-03 RU-05 Exportar documento anonimizado. Tabla 9.3: Casos de Uso de la Herramienta. Tras la definición de los casos de uso, así como los requisitos de usuario que satisfacen, se ha generado el Diagrama de Casos de Uso para el único actor que interactúa con la herramienta. De este modo se consigue plasmar de una forma visual, esquemática, simplificada y global la funcionalidad que ofrece la herramienta. En la Figura 9.1 se muestra el Diagrama de Casos de Uso de la herramienta: 9.1. Descripción de los Actores 119 Figura 9.1: Diagrama de Casos de Uso de la herramienta. 9.1.2.1. Especificación de los Casos de Uso En esta subsección se abordará la especificación de los casos de uso obtenidos a partir de los requisitos de usuario en el apartado anterior. A continuación se muestran las distintas especificaciones de los casos de uso asociados a la herramienta (ver Tablas 9.4 - 9.6): 120 Capítulo 9. Herramienta Software CU-01 Cargar Documento Versión 1.0 (17/07/2021). Actor Principal Usuario. Descripción El sistema permite al usuario cargar un fichero para anonimizar y visualizar las predicciones del modelo. Disparador El usuario solicita cargar el documento que quiere anonimizar Precondiciones El formato del fichero ha de ser PDF. Postcondiciones Ninguna. Flujo Normal 1. El usuario solicita cargar un nuevo documento para anonimizar. 2. El sistema solicita la selección del documento. 3. El usuario selecciona el documento a anonimizar. 4. El sistema carga el documento y aplica el modelo para obtener las predicciones. 5. El sistema muestra el contenido del documento y las predicciones del modelo. 6. El Caso de Uso finaliza satisfactoriamente. Flujo Alternativo 3a) El usuario cancela la acción de cargar un documento. - El Caso de Uso finaliza. Excepciones 4. El documento seleccionado no se encuentra en el formato esperado o se encuentra corrupto. - El sistema muestra un mensaje de error. - El Caso de Uso finaliza. Tabla 9.4: Especificación de Caso de Uso: CU-01: Cargar Documento. 9.1. Descripción de los Actores 121 CU-02 Anonimizar Documento Versión 1.0 (17/07/2021) Actor Principal Usuario Descripción El sistema permite al usuario anonimizar un documento cargado en la herramienta. Disparador El usuario solicita anonimizar el documento Precondiciones El CU-01: Cargar Documento ha de ser completado satisfactoriamente. Postcondiciones Ninguna Flujo Normal 1. El usuario solicita anonimizar un documento. 2. El sistema reemplaza las menciones personales detectadas en el documento por otras del mismo tipo manteniendo las propiedades del documento (ver Apartado 8). 3. El sistema muestra el contenido del nuevo documento y las menciones reemplazadas. 4. El Caso de Uso finaliza satisfactoriamente. Flujo Alternativo - Excepciones 2. Ocurre un error durante el proceso de anonimización. - El sistema muestra un mensaje de error. - El Caso de Uso finaliza. Tabla 9.5: Especificación de Caso de Uso: CU-02: Anonimizar Documento. 122 Capítulo 9. Herramienta Software CU-03 Exportar Documento Anonimizado Versión 1.0 (17/07/2021). Actor Principal Usuario. Descripción El sistema permite al usuario exportar un documen- to que haya sido anonimizado con la herramienta. Disparador El usuario solicita exportar un documento anonimizado. Precondiciones El CU-02: Anonimizar Documento ha de ser completado satisfactoriamente. Postcondiciones Ninguna. Flujo Normal 1. El usuario solicita exportar un documento anonimizado. 2. El sistema genera un archivo PDF con el contenido del documento anonimizado. 3. El Caso de Uso finaliza satisfactoriamente. Flujo Alternativo - Excepciones 2. Ocurre un error durante el proceso de exportación. - El sistema muestra un mensaje de error. - El Caso de Uso finaliza. Tabla 9.6: Especificación de Caso de Uso: CU-03: Exportar Documento Anonimizado. 9.2. Requisitos Funcionales En la siguiente sección se presentarán los distintos requisitos funcionales asociados a los casos de uso definidos anteriormente. Este tipo de requisitos son útiles ya que muestran el comportamiento que ha de tener el sistema a la hora de llevar a cabo diferentes acciones. A continuación se muestran los casos de uso del sistema, así como los sus requisitos funcionales asociados (ver Tablas 9.7 - 9.12). 9.2. Requisitos Funcionales 123 ID Nombre RF-01 El sistema habilitará la opción de cargar un documento en la herramienta. RF-02 El sistema solicitará al usuario la selección de un documento para cargar en la herramienta. RF-03 El sistema mostrará un mensaje de error en el caso de que no se haya podido realizar la carga correctamente. RF-04 El sistema mostrará un mensaje de confirmación cuando se termine de cargar satisfactoriamente el documento. Tabla 9.7: Requisitos Funcionales asociados al Caso de Uso: CU-01: Cargar Documento. ID Nombre RF-05 El sistema mostrará al usuario las predicciones realizadas por el modelo NER. RF-06 El sistema permitirá al usuario moverse a través de la vista de las predicciones. Tabla 9.8: Requisitos Funcionales asociados al Caso de Uso: CU-02: Visualizar las predicciones del modelo NER. ID Nombre RF-07 El sistema habilitará la opción de anonimizar documento. RF-08 El sistema comprobará que existe un documento previamente cargado en la herramienta. RF-09 El sistema mostrará un mensaje de error en el caso de que no se haya cargado ningún documento. RF-10 El sistema anonimizará el documento utilizando técnicas basadas en grafos y en diccionarios. RF-11 El sistema mostrará un error en el caso de que se produzca un fallo durante el proceso de anonimización. RF-12 El sistema mostrará un mensaje de confirmación cuando se termine de anonimizar correctamente el documento. Tabla 9.9: Requisitos Funcionales asociados al Caso de Uso: CU-03: Anonimizar Documento. 130 Capítulo 9. Herramienta Software 2) Clase ConversorPDF: Esta clase se ocupa de, a partir del archivo proporcionado por el usuario, validar que se encuentre en el formato adecuado y extraer su texto. Para ello, realiza una transformación del documento a imagen, y aplica a esta un OCR para extraer el texto. Finalmente, el texto obtenido de la imagen es exportado a un fichero de texto plano para su posterior uso. from PIL import Image import pytesseract ... class ConversorPDF(): def extraerTextoPDF(self, archivoPDF): paginas =convert_from_path(archivoPDF, 500) contador_paginas = 1 for pagina in paginas: # Exportamos la imagen a JPEG pagina.save(f"doc_{contador_paginas}.jpg", 'JPEG'),→ contador_paginas += 1 for iin range(1, contador_paginas): archivo_imagen =f"doc_{i}.jpg" fichero =open(f"doc_{i}.txt","w") # Aplicamos el OCR a la imagen cargada de la página del PDF,→ texto =pytesseract.image_to_string( Image.open( archivo_imagen )),→ # Se escribe el texto obtenido del OCR en el fichero de texto,→ fichero.write(texto) fichero.close() ... Código 9.6: Fragmento de la Clase ConvertirPDF. 9.4. Implementación de la herramienta 131 3) Clase NER: Esta clase se encarga de cargar tanto el modelo NER desarrollado, como el componente correspondiente a las expresiones regulares. Seguidamente, este modelo es aplicado sobre el contenido de un fichero de texto plano, generando una vista en formato HTML con las predicciones del modelo. Esta vista será la que se utilice en la página principal para visualizar las predicciones del modelo. import spacy from spacy.tokens import Doc, Span from src.RegexNER import REGEXComponent from spacy import displacy ... class NER(): def __init__(self): self.utils =Utils() self.configuracion = self.utils.cargarConfiguracion(),→ self.ruta_tmp = self.configuracion["META"]["tmp"],→ ... def obtenerPrediccionesNER(self): self.aplicarNER() self.exportarDocumentoYPredicciones() ... Código 9.7: Fragmento de la Clase NER. 4) Clase Anonimizador: Esta clase se encarga de orquestar el proceso de anonimización de la herramienta. Para ello inicializa el módulo de grafos y los diccionarios, y procesa cada una de las menciones detectadas en el documento en el orden establecido (menciones relacionadas → menciones no relacionadas). Una vez ha procesado todo, se encarga de generar el nuevo documento con las menciones anonimizadas. import spacy from spacy.tokens import Doc, Span from src.Grafos import Grafos ... class Anonimizador(): 132 Capítulo 9. Herramienta Software def __init__(self): self.utils =Utils() self.configuracion = self.utils.cargarConfiguracion(),→ ... def AnonimizarDocumento (self): self.MODULO_GRAFOS.GenerarReemplazos() self.reemplazos_grafo = self.MODULO_GRAFOS.reemplazos_entidades,→ self.obtenerReemplazos() self.validarReemplazos(self.lista_reemplazos) self.generarNuevoDoc() return self.generarVisualizacionDocumentos() ... Código 9.8: Fragmento de la Clase Anonimizacion. 5) Clase Grafos: Esta clase se encarga de inicializar el grafo general de reemplazos, obtener las relaciones existentes entre las entidades del documento y generar los reemplazos para este tipo de entidades. import networkx as nx import Levenshtein as lev ... class Grafos(): def __init__(self, doc): self.doc =doc self.reemplazos_entidades ={} ... def GenerarReemplazos(self): self.obtenerGrafoDocumento(self.doc) self.encontrarReemplazosEntidades() ... 9.4. Implementación de la herramienta 133 Código 9.9: Fragmento de la Clase Grafos. 6) Clase ExportarPDF: Esta clase toma el documento anonimizado que se ha generado previamente, y crea un nuevo documento en formato PDF con el contenido de este. from fpdf import FPDF from datetime import datetime ... class PDF(FPDF): def header(self): # Formato del encabezado del PDF ... class ExportarPDF(): ... def exportarPDF(): pdf =PDF() # Crea el fichero PDF pdf.add_page() # Añade una celda con el texto especificado pdf.cell(0,25, txt ="Documento Generado:", ln = 5, align ="C"),→ # Añade una celda múltiple (varias líneas) con el texto del documento anonimizado,→ pdf.multi_cell(0,6, doc.text, align ="J") # Se obtiene la fecha actual para utilizar como sufijo en el nombre del PDF,→ sufijo = datetime.now().strftime("%d_%m_%Y_%H_%M_%S"),→ # Se guarda el PDF generado pdf.output(f"Documento {sufijo}.pdf") ... Código 9.10: Fragmento de la Clase ExportarPDF. El código completo de la herramienta se encuentra añadido en el contenido adjunto (ver Apéndice A). 134 Capítulo 9. Herramienta Software 9.5. Pruebas de Caja Negra En esta sección se describe la realización de distintas pruebas de caja negra para comprobar que el comportamiento de la herramienta es el adecuado en distintos puntos críticos durante la ejecución. En Tablas 9.17 - 9.20 se muestran las distintas pruebas de caja negra que se han realizado sobre la herramienta. CN-01 Comprobación del formato del documento a anonimizar. Propósito Evitar que la aplicación deje de funcionar debido a que el formato del documento a anonimizar no es el esperado por la herramienta. Prerrequisitos El usuario solicita cargar un documento para anonimizarlo. Datos de Entrada Ruta del documento. Resultado Esperado Mensaje de error indicando que no se ha podido procesar el documento. Resultado Obtenido Mensaje de error debido a que el formato del documen- to no es el adecuado. Tabla 9.17: Prueba de Caja Negra: CN-01: Comprobación del formato del documento a anonimizar. CN-02 Comprobación del guardado de las estructuras de datos de reemplazo. Propósito Comprobar que la aplicación guarda correctamente las estructuras de datos para generar los reemplazos, evitando así que estas sean siempre generadas desde cero. Prerrequisitos El usuario solicita anonimizar un documento. Datos de Entrada Estructuras de datos (diccionario y grafo). Resultado Esperado Creación de un fichero binario con la estructura serializada. Resultado Obtenido Creación de los ficheros binarios correspondientes a las estructuras serializadas. Tabla 9.18: Prueba de Caja Negra: CN-02: Comprobación del guardado de las estructuras de datos de reemplazo. 9.6. Evaluación del Rendimiento 135 CN-03 Comprobación de la existencia de un documento cargado antes de realizar la anonimización. Propósito Comprobar que la aplicación dispone de un documento cargado previamente para poder iniciar su anonimización. Prerrequisitos El usuario solicita anonimizar un documento. Datos de Entrada Ninguno. Resultado Esperado Mensaje de error en el caso de que se haya cargado previamente un documento. Resultado Obtenido Mensaje de error al no haber cargado un documento antes de tratar de anonimizarlo. Tabla 9.19: Prueba de Caja Negra: CU-03: Comprobación de la existencia de un documento cargado antes de realizar la anonimización. CN-04 Las entidades que no pueden ser anonimizadas se mantienen en el documento final. Propósito Comprobar que el proceso de anonimización finaliza a pesar de la existencia de entidades para las que no se dispone de un reemplazo válido. Prerrequisitos El usuario solicita anonimizar un documento. Datos de Entrada Documento a anonimizar con las menciones detectadas. Resultado Esperado Las menciones que no han podido ser anonimizadas se mantienen en el documento final. Resultado Obtenido El documento final contiene menciones no anonimizadas al no disponer de reemplazos válidos en la base de conocimiento. Tabla 9.20: Prueba de Caja Negra: CU-04: Las entidades que no pueden ser anonimizadas se mantienen en el documento final. 9.6. Evaluación del Rendimiento Dado que en el pipeline implementado para llevar a cabo la anonimización de documentos es un pipeline en el que intervienen bastantes etapas (extracción del texto a partir de un PDF, detección de entidades mediante el modelo NER, generar las nuevas entidades, y exportar el documento), se va a realizar una evaluación del tiempo empleado en cada una de estas etapas. Para efectuar esta evaluación, se va a aplicar el pipeline desarrollado a distintos documentos de diversas características (distinto número de páginas, número de entidades, cantidad de palabras, etc). Además de observar el desempeño de la herramienta, esta prueba permite comprobar qué tan bien se desenvuelve en situaciones 136 Capítulo 9. Herramienta Software diversas (con documentos del mismo tipo pero con características distintas). Del mismo modo, esta prueba permite detectar los puntos débiles del pipeline, así como obtener los componentes que hacen que el desempeño global empeore. Un punto importante que destacar son las características hardware del equipo en el que se han realizado las pruebas de ejecución, ya que dependiendo de las características de este, los tiempos pueden variar considerablemente. La ejecución se ha realizado en un ordenador con sistema un operativo macOS Big Sur en su versión 11.5.1. Del mismo modo, las especificaciones técnicas del equipo son: Procesador I7-9850H, 64 bits, 16GB de RAM y 500GB SSD. En la siguiente tabla (ver Tabla 9.21) se muestra la comparativa del tiempo de procesamiento empleado (en segundos) para anonimizar distintos documentos, así como las características de estos: Test1 Test2 Test3 Test4 Test5 Test6 Test7 Paginas 1 2 3 5 7 11 15 Palabras 685 1.246 1.739 2.998 3.974 6.597 8.287 Entidades 25 50 78 159 237 636 758 Leer PDF 0,05 0,86 0,99 2,8 3,22 5,78 7,91 PDF a Imagen 0,03 0,65 1,004 1,65 2,20 3,64 4,79 Imagen a Texto 9,56 17,88 25,93 46,32 61,95 98,56 126,17 NER 0,16 0,19 0,18 0,25 0,34 0,51 0,58 Reemplazos (Grafo) 0,094 0,108 0,109 0,11 0,113 0,117 0,19 Reemplazos (Diccionario) 0 0 0 0,001 0,003 0,008 0,014 Crear PDF 0,035 0,04 0,037 0,04 0,048 0,053 0,055 Exportar PDF 0,307 0,347 0,392 0,496 0,512 0,514 0,586 TOTAL 10,24 20,08 28,64 51,67 68,36 109,19 140,29 TOTAL (PDF) 9,64 19,397 27,93 50,78 67,36 107,98 138,87 TOTAL Reemplazos 0,25 0,29 0,28 0,35 0,44 0,64 0,78 Tabla 9.21: Tiempos de ejecución de los componentes del pipeline desarrollado (en segundos) para distintos documentos. 9.6. Evaluación del Rendimiento 137 Figura 9.3: Desglose del tiempo de ejecución entre las distintas etapas del pipeline. Figura 9.4: Desglose del tiempo de ejecución entre las distintas etapas del pipeline (sin tener en cuenta el proceso de OCR). Conclusiones Tomando como referencia los resultados presentados en la Tabla 9.21, así como en la Figura 9.5, el tiempo de ejecución requerido para anonimizar los documentos aumenta rápidamente a medida que aumenta el número de páginas del documento. Sin embargo, si se profundiza más en los tiempos de las distintas etapas del proceso (ver Figuras 9.3 y 9.4), este aumento del tiempo viene dado por etapas no desarrolladas en el presente proyecto. Dichas etapas 138 Capítulo 9. Herramienta Software están relacionadas con la lectura de los archivos PDF, su conversión a imagen, y la extracción del texto en dichas imágenes. En términos medios, la consecución de las etapas de la herramienta no desarrolladas en este trabajo se corresponde con el 97,61% del tiempo total utilizado (frente al 2,39% de las etapas implementadas). Teniendo esto en cuenta, y enfocando el análisis únicamente a las etapas desarrolladas, la comparativa se va a llevar a cabo en base al número de entidades a anonimizar en lugar de al número de páginas del documento. Esto se debe a que, una vez el PDF haya sido procesado, la generación de los reemplazos se aplica únicamente a las entidades, por lo que si un documento tiene 15 páginas y solamente se dispone de una entidad, el proceso de anonimización se realiza muy rápido, y los resultados obtenidos haciendo el análisis de ese modo estarían sesgados. Figura 9.5: Incremento del tiempo de ejecución del pipeline en función del número de páginas del documento. 9.6. Evaluación del Rendimiento 139 Figura 9.6: Incremento del tiempo de ejecución en la generación de los reemplazos en función del número de entidades del documento. Como se puede ver en la Figura 9.6, si se atiende únicamente a la relación entre el tiempo, y la aplicación de las fases de generación de reemplazos (tanto por grafos como por diccionarios), los tiempos son similares independientemente del número de entidades. En especial, para el caso de los reemplazos mediante grafos, puede deberse a diversos motivos: 1) A pesar de que las entidades en el documento hayan aumentado, el número de entidades relacionadas (cuyos reemplazos se generan mediante grafos), no lo han hecho; 2) Debido a factores externos (como la dimensión de la base del conocimiento), se ha logrado relacionar un menor número de entidades entre sí, por lo que en términos prácticos se ha materializado en la generación de un grafo con un gran número de componentes aisladas; y 3) Debido a los mecanismos generados para reducir el tiempo de búsqueda de subgrafos isomorfos (ver Apartado 8.1.2). Por otra parte, desde el punto de vista de la obtención de reemplazos mediante diccionarios, los tiempos obtenidos son muy positivos ya que, a pesar del aumento en el número de entidades, el tiempo empleado para llevar a cabo esta etapa se mantiene en el orden de milisegundos. Esto se debe a la gran eficiencia con la que se generan este tipo de reemplazos. Finalmente, desde el punto de vista del procesamiento del texto, y la detección de entidades por parte del modelo NER y las expresiones regulares (ver Figura 9.7), se puede ver como los tiempos de detección son muy similares a pesar del aumento en el número de palabras de este. Esto, unido a lo ya mencionado anteriormente sobre la generación de los reemplazos, se traduce en que, en términos de escalabilidad, el principal cuello de botella que presenta la herramienta se encuentra asociado al manejo de los PDF’s (lectura, conversión