“Categorización De La Oferta Pública Mediante Técnicas Big Data”

Grado Universitario en Ingeniería Telemática 2018-2019

Trabajo Fin de Grado “Categorización de la Oferta Pública mediante Técnicas Big Data”

Olga Herranz Macías

Tutor Jerónimo Arenas García Leganés, 2019

Esta obra se encuentra sujeta a la licencia Creative Commons Reconocimiento - No Comercial - Sin Obra Derivada

RESUMEN

La contratación pública en España tiene un gran impacto económico tanto a nivel nacional como internacional. Es por eso que el Estado muestra interés por desarrollar mé- todos basados en las TIC que manejen la información sobre oferta pública y simplifiquen la manera en que ésta es publicada y consultada. Con este fin, el Gobierno de España pone a disposición del ciudadano la Plataforma de Contratación del Sector Público, un sitio web que recoge toda la información sobre con- tratación pública y sirve como punto de encuentro virtual entre organismos contratantes y entidades licitadoras. A diario se suben y actualizan multitud de licitaciones a la Plataforma de Contratación del Sector Público, haciendo que el sitio maneje un gran volumen de datos muy cambian- tes y en constante aumento. Si bien a priori parece que disponer de toda la información de contratación en un mismo lugar es la opción más cómoda en cuanto a acceso y almacenamiento, la cantidad de información es tal que resulta muy complicado analizarla manualmente y encontrar elementos de interés. Este proyecto busca subsanar esta limitación mediante el diseño de un sistema que analice las licitaciones publicadas en la Plataforma de Contratación del Sector Público con el objetivo de caracterizar la Contratación Pública en España. De esta manera, se determinan los tópicos más recurrentes en las ofertas que salen a concurso y, conociendo dichos tópicos, se podría definir al Sector Público actual. Para ello, el sistema utilizará técnicas de Procesamiento del Lenguaje Natural para extraer el contenido de las ofertas y, tras un estudio de varios modelos de tópicos, aplicará el que mejor se ajuste a los datos obtenidos para interpretar la información y obtener las temáticas más relevantes de la oferta pública. Palabras clave: Procesamiento del Lenguaje Natural, Modelado de tópicos, Contra- tación Pública, Aprendizaje automático Keywords: Natural Language Processing, Topic modeling, Public Procurement, Ma- chine Learning

iii

ABSTRACT

Public Procurement in Spain has a great economic impact both nationally and inter- nationally. Therefore, the Spanish Government is interested in developing ICT based mechanisms to deal with public tender’s related information and simplify the way in which it is published and inquired. With this in mind, the Spanish Government provides citizens with the Public Sector Procurement Platform, a website that collects all data regarding public procurement and acts as a virtual meeting point between contracting organizations and tendering entities. Lots of bids are published and updated daily on the Public Sector Procurement Plat- form, so the site handles a huge and rapidly increasing volume of changing information. Although having all procurement information in the same place seems to be the most convenient option in terms of storage and accessibility, the amount of data is so great that it is hard to analyze it manually and find elements of interest. In addition, Platform’s native bids search engine is based on fixed metadata values rather than on tenders’ con- tents themselves, and these search criteria are usually too wide to provide accurate results when users search for tenders adapted to their profiles. Hence, the most reliable data source that one could use to determine the specific subject of a bid is its technical specification document. However, it is hard for computers to inspect and understand texts due to the complexity of natural language; humans can do this, but on a much smaller scale than a computer. This project aims to fix this limitation by designing a system capable of analyzing bids published on the Public Sector Procurement Platform. This way, Public Procurement in Spain could be characterized by determining the most frequent topics appearing in public tenders. To achieve this, the aforementioned system should be able to analyze the text of the technical documents associated to the tenders published in the Public Sector Procurement Platform with Natural Language Processing techniques and, after studying several topic models, apply the model that better fits the training data in order to interpret the information and get the most relevant topics. Also, the proposed system must comply with European directives regarding e-administration, cost minimization and accessibility improvement to citizens. Hence, the use of free software will be preferred over licensed one. According to usability, the system should implement a visualization tool such that the characterization results can be easily interpreted at plain sight.

v The key fundamentals of this project are Natural Language Processing and topic modeling:

Natural Language Processing (NLP) is a subfield of computer science, artificial in- telligence and linguistics focused on finding computationally effective mechanisms that allows communication between humans and machines using natural language. Nowadays NLP systems are based on statistical methods of unsupervised learning capable of inferring linguistic structures from a training set of sample texts called corpus. NLP statistical systems use this patterns to make decissions. The generic architecture of NLP systems consists on language analysis at different levels. These analyzes are consistent with the levels of linguistic, i.e., phonologi- cal, lexical, syntactic, semantic, discursive and pragmatic analyzes. The analyzes performed will depend on the application of the specific system. In this case, the proposed system will consider lexical analysis for obtaining the training corpus and semantic analysis for topic modeling and Public Procurement characterizing.

Topic modeling is a mechanism used in machine learning and NLP for extracting semantic information from a corpus of unlabeled documents. This technique consi- ders that all documents in the training set are made up of a combination of topics, where each topic is defined by a set of semantically related words. This assumption aims to infer the latent topics of the training corpus by detecting recurrent patterns among words. This system uses Latent Dirichlet Allocation (LDA) as topic modeling algorithm. LDA is a generative model that assumes that all documents are mixtures of a known number of latent topics, where each topic is characterized by a probability distribution over words. This model infers the latent topics by using the words in the corpus as observed variables. LDA is a bag-of-words model, which means that the syntax of the documents is not important and will not be taken into account.

Now that the project’s fundamentals have been established, we proceed with the des- cription of the proposed system. The system is a software application developed in Python that processes the training set and coordinates the interaction among the system components for being able to characterize the Public Procurement in Spain. There are three main components in the application: a Python script for obtaining and processing the procurement training set from the Public Sector Procurement Platform, a Jupyter notebook implementing the topic modeling process and the visualization tool for interpreting the results visually, and a MySQL database storing procurement data used both in the script and in the notebook.

The Python script is meant to be executed from the command line and is responsible for creating and filling the database with procurement data, as well as extracting the

vi texts from bids’ technical specification documents. User interaction is implemented by means of a main menu that shows the different processes involved in corpus obtaining so that users can choose the task they want to execute. Although the menu allows to run the different tasks in the desired order, the logical sequence of processes is the following one:

1. Database creation or reconstruction: All tendering information is available on the Public Sector Procurement Platform as Atom feeds, where an Atom feed is just an XML file that contains a list of bids and their associate metadata in an structured form. The structure of these feeds is conveniently documented and it can be represented as a relational data model where each table corres- ponds to a certain element involved in tendering processes, so the system’s data model has been designed using this structure as main reference. Instead of creating the database structure by hand, the program can load the data model from a config file in order to create the database by itself. Incase the data model changes or the user wants to drop all database information, the program can destroy the current database and construct a new one. 2. Database filling: Right after the database structure has been successfully crea- ted or reconstructed, the program starts filling the database with tendering data. To do this, the feeds are downloaded and processed according to the structure of the XML files, using the aforementioned document as reference. Itis important to mention that the whole information contained in these feeds is stored in the database, although this application only requires bid identifiers, CPV codes and links to technical documents for characterizing the procurement data. 3. Text extraction: The text extraction process is the one that provides the raw training corpus. First of all, users have to select which documents they want to extract the text from. If the user does not want to extract text from the whole document set, he/she can insert a CPV in a new menu so that the program will only extract text from documents associated to bids corresponding to such co- de. All documents satisfying the chosen filter are downloaded and it is verified that they content any text. If so, they are processed to retrieve their texts with Apache Tika, using optical character recognition if needed. If the texts are in Spanish, they will be processed with lexical analysis mechanisms and stored in the database. The NLP processes involved in the lexical analysis are toke- nization, homogenization, lemmatization, part-of-speech tagging for keeping only names, adjectives, verbs and adverbs, N-gram detection and stopword removal. The technologies used for this processes are NLTK, TextBlob and LibrAIry.

Notice that each process depend on the previous one for working properly. In other words, text extraction can’t start if there is no information about documents in the

vii database, and the database can’t be filled with data if there is no database in thefirst place. Hence, the tasks must be run in the logical order at least once so that they can be executed afterwards in any order.

The Jupyter notebook uses the texts extracted from the technical documents as training corpus for topic modeling. It implements the following processes:

1. Corpus cleanup: Once the corpus is loaded from the database it is neces- sary to clean it up in order to discard semantically irrelevant and non-existing words in Spanish and to correct misspelled terms and expressions. If these words were kept in the corpus the resulting models would be inaccurate and incoherent. For instance, common words regarding tendering processes, first names, surnames and place names are considered as irrelevant and, therefore, they are removed from the corpus. 2. Topic modeling: The clean corpus is vectorized using the bag-of-word re- presentation and a number of topics is chosen by the user (note that in LDA models the number of topics is assumed to be known). The topic model is generated with these two parameters, corpus and number of topics. Models are generated with Mallet through its Gensim wrapper and they can be saved and loaded for later analyzing. 3. Visualization: Topic models generated by Gensim can be represented grap- hically in Jupyter notebooks by using PyLDAvis. PyLDAvis represents topics as “bubbles” placed in a 2-dimensional coordinate axis and shows the most relevant words defining each topic. In this graph a bubble size represents the marginal distribution of the topic and the distance between bubbles represents how the topics are related, so close topics will be semantically similar, and viceversa. These visualizations can be exported as html files for later analyzing.

The last task of this project is to use the developed system for finding the optimal topic model that characterizes Spanish’s Public Procurement. It is considered that the model is optimal when it has a number of topics such that most topics in the model represent a certain subject. In addition, the topics of the optimal model have to be different from each other, and the words defining different topics must be different as well. The optimal model will be found by experimenting with the corpus and the number of topics until the generated model is good enough to satisfy the mentioned criteria. This process basically consists of creating a set of model with different number of topics and analyzing them. In case none is good enough, irrelevant and fixable terms must be identified to consider them in the following cleanup process. One can generatea new model with more than 100 topics so it is easier to identify these kind of terms. This process must be done until the corpus is clean enough and there appears a model such that it satifies all acceptance criteria.

viii Although the system is capable of characterizing the whole procurement corpus, it was impossible to extract the text from the complete set of available documents on time because corpus obtaining involves heavy processing tasks such as OCR parsing. Instead, the training corpus will be only composed by documents associated to bids related to technology, telecommunications and IT. Thus, we will characterize only a limited section of the Public Procurement. The optimal model obtained after the experiments consists of 18 topics for a corpus of 10224 documents related to technology and telecommunications, where 15 topics represent well-defined subjects and the remaining 3 are generic. The identified subjects are the following ones:

1. Generic topic

2. Incident management

3. Generic topic

4. Data protection

5. Generic topic

6. Virtualization and backup

7. Hardware supply

8. Education and research

9. Content delivery over the Internet

10. Authentication and electronic certification

11. Cyber security

12. Mobile telephony and networks

13. Defence

14. Transportation and environment

15. Data collection and analysis

16. Software and licences

17. Responsibility and confidentiality

18. Health

ix This model has been considered optimal after a cleanup process of 6 iterations that allowed to detect 2457 irrelevant words and 384 equivalences. After the complete cleanup process the resulting vocabulary consisted on 17414 tokens. During the analysis it was observed that models with few topics were inaccurate, but the more topics the model had, the better it behaved. However, there was a point in which the nuber of topics was so high that models stopped being well-behaved to start being overfitted. Thus, the optimal number of topics had to be the one than set the inflexion point between the two fenomena. In the last iteration of the experimentation process the number of topics that satisfied this definition was 18, and that is why the selected optimal model has the mentioned features. According to the topics themselves, the obtained results reveal that technology services requested in public tenders coincide with some of the most popular IT fields at the moment, such as cyber security and data analysis. Hence, one can state that the Spanish Public Sector is interested in modernizing itself by applying these technologies for offe- ring better services to the citizen. This statement is reinforced by the existence of topics representing public services, such as health and education, which implies that part of the requested technology services goes to the improvement of these basic public services. Nonetheless, this conclusion can only be applied for this particular sector, so the same analysis should be done over the whole dataset to characterize the complete Public Pro- curement.

DEDICATORIA

A mi familia, por vuestros ánimos en forma de turra incansable para que terminara la carrera. A mis amigos, por no perder la esperanza en que terminaría algún día y volviera a salir a la calle, que según vosotros ver a un big foot era más fácil que quedar conmigo. A mis compañeros de Telefónica, por vuestros consejos, por los cafés llenos de salseo y por ser enormes profesionales, y mejores personas. A Jerónimo, porque has sido un tutor inmejorable y tu dedicación y tu disposición a ayudar no tienen precio. A Alex, por tu paciencia infinita, tu confianza, tu cariño y, en definitiva, por existir. Sin vosotros, no estaría aquí. Gracias

vii

ÍNDICE GENERAL

1. INTRODUCCIÓN...... 1 1.1. Motivación...... 1 1.2. Objetivos...... 3 1.3. Estructura del documento...... 4 2. ESTADO DEL ARTE...... 6 2.1. Procesamiento del Lenguaje Natural...... 6 2.1.1. Arquitectura genérica de los sistemas NLP...... 8 2.1.2. Aplicaciones...... 11 2.1.3. Herramientas para NLP...... 13 2.1.3.1. NLTK...... 13 2.1.3.2. TextBlob...... 14 2.1.3.3. Stanford CoreNLP...... 15 2.1.3.4. SpaCy...... 16 2.1.3.5. librAIry...... 18 2.2. Modelado de tópicos...... 19 2.2.1. Bag-of-Words...... 19 2.2.2. Latent Dirichlet Allocation...... 23 2.2.3. Herramientas para modelado de tópicos...... 25 2.2.3.1. Gensim...... 26 2.2.3.2. MALLET...... 27 3. SOLUCIÓN PROPUESTA...... 28 3.1. Tecnologías utilizadas...... 28 3.1.1. Python...... 28 3.1.2. MySQL...... 29 3.1.3. Apache Tika...... 30 3.1.4. PyLDAvis...... 31 3.1.5. Otras tecnologías...... 31

ix 3.2. Diseño...... 32 3.2.1. Script Python: Creación del corpus...... 34 3.2.1.1. Módulo principal...... 34 3.2.1.1.1. Inicialización de recursos...... 35 3.2.1.2. Construcción de la base de datos...... 36 3.2.1.2.1. Modelo de datos...... 36 3.2.1.2.2. Construcción de la estructura de tablas...... 39 3.2.1.2.3. Almacenamiento de datos de contratación...... 40 3.2.1.3. Extracción de texto...... 44 3.2.2. Modelado y visualización de tópicos...... 49 3.2.3. Módulos de ayuda...... 53 4. INTERPRETACIÓN DE LOS RESULTADOS...... 54 4.1. Consideraciones iniciales...... 54 4.2. Criterios de validación de resultados...... 55 4.3. Ajuste de modelos...... 56 4.4. Resultados finales...... 58 5. MARCO REGULADOR...... 68 6. MARCO SOCIO-ECONÓMICO...... 71 7. PRESUPUESTO Y PLANIFICACIÓN...... 73 7.1. Planificación temporal...... 73 7.1.1. Planificación inicial...... 73 7.1.2. Duración real...... 74 7.2. Presupuesto...... 74 7.2.1. Recursos humanos...... 75 7.2.2. Recursos materiales...... 76 7.2.3. Presupuesto final...... 77 8. CONCLUSIONES Y TRABAJOS FUTUROS...... 80 BIBLIOGRAFíA...... 83

ÍNDICE DE FIGURAS

1.1 Plataforma de Contratación del Sector Público ...... 2

2.1 Arquitectura general de sistemas NLP ...... 9 2.2 Tokenización ...... 9 2.3 Etiquetado gramatical ...... 10 2.4 Reducción de palabras a raíces ...... 10 2.5 Logo de NLTK ...... 13 2.6 Logo de TextBlob ...... 15 2.7 Logo de Stanford CoreNLP ...... 15 2.8 Funcionalidades de CoreNLP ...... 16 2.9 Logo de spaCy ...... 17 2.10 Logo de librAIry ...... 18 2.11 Representación gráfica del modelo LDA básico ...... 24 2.12 Representación gráfica del modelo LDA suavizado ...... 25 2.13 Logo de Gensim ...... 26 2.14 Logo de MALLET ...... 27

3.1 Logo de Python ...... 28 3.2 Logo de MySQL ...... 29 3.3 Logo de Apache Tika ...... 30 3.4 Logo de Jupyter ...... 31 3.5 Arquitectura básica de la solución ...... 32 3.6 Estructura de directorios y ficheros de la aplicación Python . . . . . 33 3.7 Menú inicial de opciones ...... 34 3.8 Diagrama de flujo: Menú principal del programa ...... 35 3.9 Modelo de datos ...... 37 3.10 Modelo de la tabla bids ...... 38 3.11 Diagrama de flujo: Creación y reconstrucción de base de datos . 40

xii 3.12 Diagrama de flujo: Lógica de inserción y actualización de licitaciones en base de datos ...... 43 3.13 Diagrama de flujo: Llenado de base de datos ...... 44 3.14 Ejemplo de jerarquía en clasificación CPV ...... 45 3.15 Menú principal de selección de códigos CPV ...... 46 3.16 Submenús de selección de códigos CPV ...... 46 3.17 Diagrama de flujo: Extracción de textos ...... 50 3.18 Ejemplo de modelo de tópicos representado con PyLDAvis ...... 52 3.19 Diagrama de flujo: Modelado de tópicos y visualización ...... 53

4.1 Ejemplo de tópico coherente ...... 56 4.2 Ejemplo de modelo de 100 tópicos ...... 57 4.3 Modelo de tópicos óptimo ...... 58 4.4 Modelo de 18 tópicos con corpus sin limpiar ...... 62 4.5 Modelo impreciso de 10 tópicos ...... 64 4.6 Modelo sobreajustado de 20 tópicos ...... 66

7.1 Diagramas de Gantt: Planificación inicial y duración real del proyecto . 79

xiii

ÍNDICE DE TABLAS

2.1 Obtención de lexemas por stemming ...... 10 2.2 Obtención de palabras primitivas por lematización ...... 11 2.3 Corpus de entrenamiento ...... 20 2.4 Vocabulario 1 ...... 21 2.5 Vocabulario 2 ...... 21 2.6 Vocabulario 3 ...... 22 2.7 Representación Bag-of-Words ...... 22

3.1 Contenido de tablas en modelo de datos ...... 39

4.1 Tópicos de caracterización del modelo óptimo ...... 59 4.2 Tópicos de caracterización de corpus sin limpiar ...... 63 4.3 Tópicos de caracterización de modelo impreciso de 10 tópicos ...... 65 4.4 Tópicos de caracterización de modelo sobreajustado de 20 tópicos . . . . 67

5.1 Licencias de software libre presentes en la solución ...... 69 5.2 Caracterísisticas de licencias de software libre ...... 70

7.1 Planificación inicial ...... 73 7.2 Planificación real ...... 75 7.3 Estimación de horas de trabajo ...... 76 7.4 Presupuesto final de recursos humanos ...... 76 7.5 Presupuesto de dispositivos hardware ...... 77 7.6 Presupuesto de costes indirectos ...... 77 7.7 Presupuesto final de recursos materiales ...... 77 7.8 Costes totales ...... 77 7.9 Presupuesto final ...... 78

8.1 Estimación de importe total por tópico ...... 81

1. INTRODUCCIÓN

1.1. Motivación

En las últimas décadas, el auge de Internet y el desarrollo de las Tecnologías de la Información y las Comunicaciones (TIC) ha marcado la dirección en la que avanzan nues- tras sociedades: las formas de comunicación han cambiado y siguen evolucionando cada vez más deprisa. Ahora, la distancia está más lejos que nunca de ser un problema para tener una conversación. Si consideramos que una conversación no es otra cosa que un intercambio de información entre personas, esta idea puede extrapolarse a los métodos de transmisión y recepción de la información. La presencia prácticamente obligatoria en nuestro día a día de dispositivos inteligentes nos pone al alcance de la mano la capacidad de generar y consumir cantidades ingentes de datos de todo tipo. Este cambio de tendencia ha obligado a muchas empresas e instituciones a digitalizarse para adaptarse a los nuevos tiempos, y no ha sido diferente para la Administración Pública. La integración de las TIC en la Administración Pública es uno de los puntos de acción más destacados dentro de la Agenda Digital desde que en 2005 la Comisión Europea puso sobre la mesa la importancia de contar con medios de relación con la ciudadanía eficientes y efectivos. Además, se sugirió que una administración electrónica de calidad permitiría reducir los costes económicos y/o sociales que las administraciones imponen a empresas y ciudadanos [1]. Con este objetivo, entra en vigor en 2015 el Plan de Transformación digital de la Administración General del Estado y sus Organismos Públicos, un plan es- tratégico orientado a sacar el máximo partido de las TIC en la Administración Pública. Estos planes plantean los hitos y pautas para realizar una transformación gradual hacia la Administración Digital que se estima será efectiva en 2020 [2]. Uno de los aspectos en los que una comunicación fluida entre administración y ad- ministrados juega un papel clave, debido al gran peso económico que implica, es la Con- tratación Pública. La Contratación Pública en España supone alrededor de un 20 % del Producto Interior Bruto (PIB), es decir, genera un 20 % de la riqueza nacional [3]. Por eso es tan importante que todos los potenciales ofertantes conozcan las licitaciones públicas, tengan acceso a los requisitos necesarios para participar en ellas, puedan presentar sus ofertas de forma telemática (evitando desplazamientos tediosos) y saber el resultado de dichas ofertas. Para cubrir esta necesidad, se creó la Plataforma de Contratación del Sector Público (Figura 1.11), un sitio web que sirviera como principal canal de difusión de licitaciones y actuara como intermediario directo entre contratantes y licitadores. Los organismos de contratación dependientes del Estado están obligados por Ley a publicar su Perfil del Con-

1https://contrataciondelestado.es/wps/portal/plataforma

1 tratante en esta plataforma, que a su vez proporciona de forma gratuita todos los servicios necesarios para ello (art. 347 Ley de Contratos del Sector Público 9/2017, de 8 de noviembre [4]). Por otra parte, aunque el resto de organismos públicos pueden mantener su propio Perfil del Contratante, sí que deberán publicar en la Plataforma todas susconvo- catorias de licitaciones y el resultado de las mismas. En definitiva, la Plataforma maneja toda oferta pública que sale a concurso, tanto de la Administración estatal, autonómica y municipal, como de empresas públicas.

Fig. 1.1. Plataforma de Contratación del Sector Público

Es evidente que para cualquier usuario es cómodo poder disponer de toda esta in- formación en una misma web, pero esto supone que la Plataforma tenga una dimensión demasiado grande como para tratarse de forma manual. Por ejemplo, en el momento de la redacción de este documento había 15.984 Perfiles del Contratante alojados en la Pla- taforma y la cantidad de licitaciones publicadas ascendía a 273.382, y tanto el número de Perfiles como el de ofertas publicadas aumenta a diario. A pesar de utilizar una cantidad de datos difícil de manejar, la Plataforma ha establecido una estructura de metadatos a la que se ajustan todas las licitaciones publicadas en la Plataforma y que facilita tanto la búsqueda manual como el procesamiento automático de la información de contratación; pero la principal fuente de información que permite determinar la temática al detalle de un concurso público, más que la propia meta-información, reside en los pliegos asociados a cada oferta, concretamente en los pliegos de especifi- caciones técnicas. Sin embargo, los pliegos dependen ineludiblemente del lenguaje natural para describir los servicios que se quieren cubrir con una oferta. En consecuencia, la complejidad y matices intrínsecos del lenguaje hacen difícil a una máquina procesar el contenido de un documento para extraer una conclusión, cosa que a una escala más reducida sí que puede hacer un humano. Si bien la Plataforma dispone de buscadores y un recomendador de licitaciones propio basados en palabras clave y el valor de metadatos de las ofertas (como el número de expe- diente, el tipo de contrato o el código CPV, en inglés Common Procurement Vocabulary),

2 no se tiene en consideración el contenido de los pliegos. Estas condiciones de búsqueda suelen abarcar ámbitos demasiado genéricos y puede que no proporcionen resultados lo suficientemente precisos como para ajustarse a los intereses de los usuarios cuando buscan ofertas adaptadas a su perfil. Enmarcamos este proyecto en un intento por conciliar la precisión del análisis manual de textos con la capacidad de cómputo de un ordenador, proponiendo el desarrollo de un sistema más sofisticado de análisis de ofertas en base a su contenido específico.

1.2. Objetivos

El objetivo de este trabajo consiste en crear un sistema que, a partir de los datos recogidos en la Plataforma de Contratación del Sector Público, sea capaz de analizar el contenido de las ofertas para determinar las temáticas que mejor representen a la Contra- tación Pública en España, con la intención de tener una visión general de los servicios más demandados. Como mencionábamos anteriormente, la envergadura de la Plataforma hace posible generar un modelo más adecuado que si se dispusiera de un conjunto de datos más limitado, por lo que el sistema debe sacar partido de esta información de base para realizar un análisis de tópicos tan preciso como sea posible. Por otro lado, una de las principales directrices marcadas en la Agenda Digital implica que la solución debe ahorrar en costes de distinta naturaleza. Para conseguirlo, el sistema deberá funcionar correctamente en ordenadores de uso genérico y se dará prioridad a la utilización de software libre frente a software con licencia. Asimismo, se busca que el sistema sea flexible ante posibles cambios en la estructura de datos de la Plataforma y fácilmente actualizable, si bien este último requisito es más sencillo de cumplir si se utiliza software libre. En cuanto a usabilidad, el sistema debe mostrar los datos de manera visual y amigable para el usuario con el fin de mostrar información valiosa que puede servir como basea otras aplicaciones. Para alcanzar estos objetivos básicos, es necesario cumplir con una serie de objetivos secundarios que, a su vez, coinciden con las diferentes fases del desarrollo del proyecto:

1. Estudiar la dimensión y las distintas estructuras de datos de la Plataforma de Con- tratación del Sector Público.

2. Comparar distintos mecanismos de Web Scraping y extracción de texto de documentos de distinto formato para obtener los datos de entrenamiento a partir de las licitaciones publicadas en la Plataforma.

3. Generar una base de datos estructurados a partir de la información descargada de la Plataforma.

3 4. Preprocesar el conjunto de datos con técnicas de Procesamiento de Lenguaje Natu- ral para mantener únicamente la información relevante de cada documento.

5. Caracterizar las licitaciones mediante la inferencia de los tópicos o temáticas principales utilizando el modelo Latent Dirichlet Allocation (LDA) [5].

6. Desarrollar una herramienta de visualización que muestre los resultados de la ca- racterización de una forma clara y amigable para el usuario.

1.3. Estructura del documento

En este punto se describe brevemente cómo está organizado el documento. El documento consta de los siguientes capítulos:

1. Introducción Este capítulo presenta la razón de ser de este trabajo, las motivaciones que han im- pulsado a su desarrollo y los objetivos que se pretenden conseguir con su aplicación.

2. Estado del arte En este capítulo se ofrece una visión general de los fundamentos del trabajo, es decir, de procesamiento del lenguaje natural y modelado de tópicos. También se describen las distintas herramientas y tecnologías utilizadas en sistemas basados en dichos fundamentos o aplicaciones similares con la intención de estudiar sus carac- terísticas y su adecuación a los requisitos y metas establecidos para este trabajo.

3. Diseño de la solución Este capítulo desarrolla rigurosamente los distintos elementos concernientes a la implementación del propio código del sistema. Se hablará de las tecnologías utilizadas, la arquitectura del sistema completo y la estructura del código de la solución.

4. Interpretación de los resultados En este capítulo se discuten los resultados de la caracterización y se describen los mecanismos de ajuste y perfeccionamiento de la efectividad del sistema.

5. Marco regulador Este capítulo recoge información relativa a la legislación aplicable al trabajo.

6. Marco socio-económico En este capítulo se comenta el impacto socio-económico de la aplicación del sistema en un entorno real de producción y se discuten algunas posibles utilidades derivadas.

7. Presupuesto y planificación Este capítulo recoge el presupuesto de la ejecución del proyecto y muestra la plani- ficación de la misma.

4 8. Conclusiones y trabajos futuros Este capítulo sirve como cierre de la memoria. En él se expondrán los resultados alcanzados y su coherencia con los objetivos marcados inicialmente. Además, se comentarán las diferentes aplicaciones que puedan basarse en el trabajo realizado y se marcarán posibles trabajos derivados del mismo.

5 2. ESTADO DEL ARTE

Este capítulo introduce el procesamiento del lenguaje natural y el modelado de tópicos como los conceptos clave sobre los que se ha construido este proyecto. Además, se hace un repaso de las diferentes tecnologías disponibles para implementar soluciones basadas en estos fundamentos.

2.1. Procesamiento del Lenguaje Natural

El Procesamiento del Lenguaje Natural o Natural Language Processing (NLP) es una rama de las ciencias de la computación, inteligencia artificial y lingüística que se centra en la investigación de mecanismos eficaces computacionalmente para la comunicación entre personas y/o máquinas mediante lenguajes naturales [6]. Esta disciplina busca permitir a los ordenadores comprender, interpretar y manipular el lenguaje natural, ya sea oral o escrito, de forma automática con un nivel de entendimiento del lenguaje humano cercano al que poseen las personas. La investigación sobre NLP comenzó en torno a 1950 a partir del interés por el desarrollo de traductores automáticos y sistemas de recuperación de la información. Años después, Noam Chomsky, lingüista, filósofo y matemático, propuso la existencia de una Gramática Universal a la que se ceñían todas las lenguas (1957) [7] y postuló que con un juego reducido de reglas gramaticales y un conjunto finito de términos podían producirse un número infinito de frases mediante combinaciones entre términos y transformaciones sobre otras frases, introduciendo el concepto de Gramática Generativo-Transformacional (1965) [8]. Este paradigma del lenguaje como un conjunto de símbolos que se combinan en base a reglas gramaticales, junto con la suposición de que todas las lenguas tienen ca- racterísticas comunes, sentó las bases de los sistemas de procesamiento del lenguaje en sus comienzos. Estos primeros desarrollos se basaban en modelos lógicos en los que eran los lingüistas quienes definían a mano los patrones gramaticales que se debían reconocer para interpretar la información. No obstante, estos sistemas progresivamente fueron perdiendo popularidad. La década de los 80 vino marcada por una revolución estadística que orientó las in- vestigaciones en lingüística computacional al estudio de algoritmos de procesamiento del lenguaje basados en machine learning2. Este cambio vino condicionado, a su vez, por el aumento de la capacidad de cómputo como consecuencia de la Ley de Moore (1965) [10] y la disminución del predominio de las teorías lingüísticas de Chomsky, esto último debido, entre otras cosas, a que se demostró que las transformaciones propuestas por éste

2Machine learning, en español aprendizaje automático, es una rama de la inteligencia artificial basada en crear sistemas capaces de analizar datos para aprender de ellos, encontrar patrones y tomar decisiones con mínima intervención humana [9].

6 podían ser sustituidas por mecanismos computacionalmente más simples (Gazdar et al., 1985 [11]). Estos nuevos métodos consisten en modelos probabilísticos del lenguaje natural que prescinden de reglas gramaticales explícitas con la intención de aprenderlas a partir de una colección de datos de ejemplo, lo que en terminología de Procesamiento del Lenguaje Natural denominamos corpus, y que para el estudio del NLP será un conjunto de textos reales. Este corpus estará caracterizado por unos rasgos probabilísticos a los que se asignará un peso determinado, y en base a estos valores numéricos se generará una distribución de probabilidad sobre la que se tomarán decisiones. El motivo principal por el que la inferencia estadística revolucionó el desarrollo del NLP puede deducirse de las reflexiones de Mark Johnson (2009), traducidas al castellano [12]:

(Sobre los analizadores de lenguaje basados en gramáticas) “Tomando prestada ter- minología de la programación lógica (Lloyd, 1987), podríamos llamar a éste un enfoque cerrado: Cualquier análisis que no sea generado por la gramática se asume que es contrario a la gramática. Curiosamente, creo que los modelos probabilísticos utilizados en procesamiento es- tadístico generalmente hacen una asunción abierta sobre análisis lingüístico. Estos modelos probabilísticos prefieren unas estructuras determinadas sobre otras, pero los mecanismos de suavizado que utilizan estos métodos aseguran que todos los análisis posibles (...) reciben probabilidad positiva. En tal aproximación, los rasgos estadísticos identifican propiedades del análisis sintáctico que hacen que elanáli- sis sea más o menos probable, por lo que el modelo probabilístico puede preferirse, descartarse o ser ambivalente sobre cualquier rasgo lingüístico o construcción particular. Creo que una aproximación abierta es generalmente preferible como modelo de procesamiento sintáctico tanto para máquinas como para humanos. Opino que no es razonable presuponer que un sistema deba conocer todas las entradas léxicas y construcciones sintácticas del lenguaje que está analizando. Incluso si el sistema encuentra una palabra o estructura que no entiende, éste debería ser capaz de interpretar el resto de la frase. Los analizadores estadísticos son considerablemente más flexibles. Por ejemplo, las palabras desconocidas no presentan ningún problema fundamental para los analizadores estadísticos; en ausencia de información léxica específica sobre una palabra, estos sistemas automáticamente regresan a lainfor- mación general sobre palabras.”

De estas afirmaciones podemos extraer como principales ventajas de estos sistemas: la robustez frente a estructuras desconocidas y/o erróneas, muy presentes en el lenguaje natural; la focalización automática del análisis en las construcciones más frecuentes, y la posibilidad de mejorar la precisión del modelo simplemente aumentando el conjunto de datos de ejemplo. Por el contrario, los analizadores de lenguaje basados en reglas predefinidas destacan por ser poco flexibles para solventar estas limitaciones implícitas del lenguaje humano. Además, la manera de afinar estos sistemas no es trivial, y además

7 es poco escalable, puesto que supone añadir complejidad manualmente a las reglas ya definidas. Esta deriva del NLP hacia los métodos estadísticos perdura hasta la actualidad. En años recientes, el estudio del NLP se ha focalizado en algoritmos de aprendizaje no supervisados o semi-supervisados, que utilizan datos de entrenamiento no etiquetados y combinaciones de datos etiquetados con no etiquetados, respectivamente. Estos estudios han prosperado en una búsqueda por sacar provecho de la abundancia de texto no etiquetado presente en los formatos digitales. Además, el hecho de disponer de sistemas capaces de extraer conclusiones valiosas de fuentes no categorizadas implica ahorrar en costes asociados a la construcción de datos de entrenamiento correctamente etiquetados (A. Vlachos, 2011)[13].

2.1.1. Arquitectura genérica de los sistemas NLP

El lenguaje humano y su naturaleza han sido el principal reto para el desarrollo de este campo: para que un ordenador pueda procesar la información satisfactoriamente, ésta debe ser precisa y estar altamente estructurada, es decir, los ordenadores son capaces de interpretar lenguajes artificiales que se crean para ser comprendidos en contextos concre- tos. En contrapartida, el lenguaje natural suele ser ambiguo y poco estructurado, ya que la propia estructura lingüística puede depender de variables complejas como el contexto social, la polisemia, las connotaciones, la intención del hablante y las particularidades sintácticas y gramaticales propias de cada idioma y dialecto. En pocas palabras, para que el lenguaje sea correctamente procesado, la máquina debe ser capaz de resolver las ambi- güedades implícitas del lenguaje natural para poder relacionar cada elemento lingüístico con el concepto que representa. Para implementar un sistema NLP con éxito, se ha identificado una arquitectura ge- nérica basada en el análisis de los distintos niveles del lenguaje. Es importante tener en cuenta que el transcurso por todas las fases no es necesario y depende mucho de la apli- cación concreta del sistema (Figura 2.1).

8 Fig. 2.1. Arquitectura general de sistemas NLP

1. Análisis fonético: Se centra en la detección de las palabras tal y como son pronun- ciadas para generar el texto que sería procesado en pasos posteriores. Este análisis sólo tiene sentido en aplicaciones en las que se procesa lenguaje hablado.

2. Análisis léxico: Consiste en el análisis interno de las palabras que forman las oraciones para reconocer las unidades mínimas del lenguaje. El objetivo de esta fase reside en encontrar el significado léxico de los elementos del lenguaje y la categoría sintáctica de los mismos. Esta fase puede comprender los siguientes procesos:

a) Tokenización: Separación del texto en párrafos, oraciones y/o palabras (Figura 2.2).

Fig. 2.2. Tokenización

b) Etiquetado gramatical, part-of-speech tagging o POS tagging: Proceso de asignar cada palabra a su categoría gramatical en función de su contexto para facilitar la interpretación de su rol dentro de una oración y, por extensión, el análisis sintáctico (Figura 2.3).

9 Fig. 2.3. Etiquetado gramatical c) Detección de N-Gramas: Los N-gramas son grupos de N palabras que oca- sionalmente aparecen juntas y tienen un valor semántico inherente. Algunos ejemplos son ‘machine learning’ o ‘big data’. d) Reducción de las palabras a su lexema o raíz: El objetivo de este proceso es disponer de un término único bajo el que agrupar todas las palabras equiva- lentes semánticamente. Este sería el caso de palabras con distinta forma y las derivaciones a partir de palabras primitivas (Figura 2.4).

Fig. 2.4. Reducción de palabras a raíces

Este proceso puede realizarse de dos maneras: Stemming: Método de obtención de raíces (en inglés stems) mediante la eliminación de prefijos y sufijos. Este mecanismo es más rápido, peroes posible que los lexemas resultantes no compongan una palabra completa con significado (Tabla 2.1):

Palabra Raíz planeaba plan municipios municip educación educ programas program

Tabla 2.1. Obtención de lexemas por stemming

Lematización: Método de extracción de raíces basado en vocabularios y análisis morfológico de palabras para un idioma concreto. Si bien es un mecanismo más complejo, el resultado de la lematización es una palabra completa y con significado propio en el diccionario; una palabra primitiva. Para que la lematización sea correcta, debe haberse realizado un etiquetado gramatical previo para resolver ambigüedades, como por

10 ejemplo el caso de los verbos en participio, cuya palabra primitiva puede ser tanto un adjetivo como un verbo (Tabla 2.2):

Palabra Raíz planeaba planear municipios municipio educación educación programas programa

Tabla 2.2. Obtención de palabras primitivas por lematización

e) Detección de palabras especiales, como nombres propios o stopwords (palabras sin significado, como artículos, pronombres y preposiciones), que pueden ser irrelevantes para el sistema según su aplicación y, como tales, serían eliminadas en algún punto del procesado. Las palabras más frecuentes y los términos menos comunes del corpus también son susceptibles a ser descarta- dos en este paso.

3. Análisis sintáctico: Análisis de la estructura de las oraciones de acuerdo al modelo gramatical utilizado, bien lógico o estadístico. De esta fase se pretende determinar si una oración es gramaticalmente correcta para obtener una representación de la oración como una relación de dependencia entre las palabras que la componen.

4. Análisis semántico: Tras la eliminación de las ambigüedades léxico-sintácticas, se hace un análisis de las posibles interpretaciones de las oraciones a partir de los análisis previos con el objetivo de identificar el significado apropiado de las palabras dentro de la oración y de la oración en conjunto.

5. Análisis discursivo: Se examina el significado de las oraciones en cuanto que están relacionadas con otras frases o párrafos del mismo texto.

6. Análisis pragmático: Se realiza un análisis del contexto de uso para proporcionar una interpretación final del mensaje, centrándose en la interpretación del lenguaje figurado.

2.1.2. Aplicaciones

El NLP tiene un sinfín de aplicaciones en multitud de campos, no sólo para lingüística e informática. Esto se debe a que las automatización de tareas para soluciones NLP hace que esta información lingüística se maneje a mayor escala y con menor coste, pudiendose dedicar más recursos a otras tareas difícilmente automatizables. Entre sus aplicaciones más habituales, se destacan las siguientes [14]:

11 Traducción automática: La importancia de los traductores automáticos reside en la barrera que el multilingüismo supone para la comunicación. La traducción automá- tica está presente por todo Internet y suele ser lo suficientemente fiable como para ser aceptable para los internautas. No obstante, en caso de necesitarse una precisión sintáctica y semántica muy alta se necesitaría ineludiblemente de la intervención de un ser humano, siendo ésta la principal limitación de los traductores actuales.

Sistemas de búsqueda y recuperación de información: Estos sistemas se basan en la búsqueda de información presente en bases de datos, internet o intranets en base a criterios como palabras clave o metadatos para obtener información relevante. Un ejemplo de sistema de recuperación de datos son los buscadores de Internet, que además fueron la primera aplicación masiva del lenguaje natural en las TIC.

Sistemas conversacionales: Se trata de sistemas informáticos que son capaces de interpretar el lenguaje natural y mantener una conversación con un usuario, ya sea por vía escrita, como en el caso de los chatbots, integrados, por ejemplo, en servicios de atención al cliente o como herramientas de entretenimiento (Cleverbot3, SimSimi4); o por vía oral, como los asistentes capaces de reaccionar a comandos de voz, como Siri en los dispositivos Apple, Cortana en los dispositivos Windows, Google Assistant en los dispositivos Android o Alexa en dispositivos de Amazon.

Análisis de sentimientos o minería de opinión: Empleados para identificar infor- mación subjetiva de recursos digitales. Las empresas dan especial importancia a estos sistemas, puesto que integrados en la monitorización de distintas fuentes de opinión, como las redes sociales, pueden disponer de una visión fidedigna de la aceptación de sus productos y servicios. También son útiles para caracterizar diferentes comunidades de internautas y las relaciones entre ellos.

Análisis de tópicos: Consiste en el análisis de textos para encontrar sus temáticas principales. Estos sistemas implementan detección automática de tópicos para caracterizar al conjunto de textos a partir del análisis de un corpus y el establecimiento de relaciones entre conceptos que pueden definir una temática. Estos sistemas pueden servir de base a sistemas de recomendación.

Realización de resúmenes de textos: Se trata del análisis automático de textos para ofrecer la información más relevante de los mismos de forma breve. Estos mecanismos optimizan el tiempo de detección de material textual relevante, además de fomentar la visibilidad de contenido posiblemente desapercibido por el usuario.

Corrección automática de textos: Permiten la corrección ortográfica y gramatical de los textos, verificando que los componentes del mismo tengan sentido dentro de un contexto concreto.

3https://www.cleverbot.com/ 4www.simsimi.com

12 2.1.3. Herramientas para NLP

En esta sección se revisan las características de las tecnologías NLP más relevantes para este proyecto puesto que el número de herramientas disponibles es muy elevado. De entre las soluciones que no serán descritas se listan las siguientes tecnologías:

Apache OpenNLP5

Flair6

NLP Architect by Intel7

AllenNLP8

FreeLing9

Amazon Comprehend10

Google Cloud Natural Languages11

2.1.3.1. NLTK

NLTK12, por sus siglas Natural Language Toolkit (Figura 2.5), es uno de los principales recursos para trabajar con lenguaje natural en Python13. Desarrollado por Steven Bird y Edward Looper, y principalmente orientado para trabajar con textos en inglés, proporciona un gran número de corpus e integración con recursos léxicos como WordNet que permiten su aplicación en otros idiomas, así como librerías, funciones para realizar tareas básicas relacionadas con el NLP y wrappers para otras librerías NLP [15].

Fig. 2.5. Logo de NLTK

Estas son algunas de las funcionalidades que ofrece NLTK:

5opennlp.apache.org 6https://github.com/zalandoresearch/flair 7http://nlp_architect.nervanasys.com/ 8https://allennlp.org/ 9http://nlp.lsi.upc.edu/freeling/index.php/node/1 10https://aws.amazon.com/es/comprehend/ 11https://cloud.google.com/natural-language/?hl=es 12www.nltk.org 13https://www.python.org/

13 Disponibilidad de corpus de entrenamiento y diccionarios en varios idiomas

Soporte con Wordnet y recursos léxicos (sinonimia, antonimia)

Tokenización y segmentación de textos

Stemmers y lematizadores para varios idiomas

Etiquetado gramatical

Detección de N-gramas

Análisis sintáctico

Clasificación de textos

Reconocimiento de entidades nombradas (NER o Named Entity Recognition)

Corrección de textos en base a diccionarios

Traducción automática

NLTK está destinado a apoyar la investigación en NLP y se utiliza con éxito como herramienta de enseñanza, aprendizaje individual y como plataforma de construcción de sistemas de investigación. Sin embargo, sus características la han hecho apropiada para utilizarse en otras disciplinas como la lingüística, la ingeniería y la industria. Otra de las cualidades que hace que esta librería tenga una gran aceptación es la documentación, cuya calidad reside en la enseñanza práctica guiada de la programación orientada al procesamiento de lenguaje natural. Está disponible en un volumen publicado por los propios desarrolladores (2009 [15]) y la información contenida aparece complementada con tuto- riales online, wikis y foros de discusión abiertos para la comunidad. NLTK está disponible para Windows, Mac OS X y Linux, y es una plataforma gra- tuíta de software libre basada en las aportaciones voluntarias de la propia comunidad. Es compatible con las versiones Python 2.7 o de Python 3.4 en adelante, por lo que puede ser utilizado en cualquier intérprete de Python consistente con estas versiones.

2.1.3.2. TextBlob

TextBlob14 (Figura 2.6) es una librería para Python desarrollada por Steven Loria que proporciona una API sencilla para acceder a distintas funcionalidades básicas de NLP. Está montado sobre NLTK y Pattern15 16, por lo que las funcionalidades, requisitos y licencias de TextBlob son muy similares a las proporcionadas por dichas librerías. Cabe

14https://textblob.readthedocs.io/en/dev/ 15https://www.clips.uantwerpen.be/pages/pattern 16Pattern es un módulo Python para minería de opinión

14 destacar que la principal tarea para la que la comunidad NLP recurre a TextBlob es para realizar análisis de sentimientos.

Fig. 2.6. Logo de TextBlob

Sin embargo, TextBlob proporciona una interfaz intuitiva que suaviza la curva de aprendizaje, simplifica el procesamiento de texto mediante la sustitución de tipos dedatos complejos por strings y mejora considerablemente la eficiencia con respecto a NLTK, por lo que puede utilizarse como herramienta escalable para prototipado de modelos NLP en las mismas aplicaciones en las que NLTK es popular.

2.1.3.3. Stanford CoreNLP

Stanford CoreNLP17 (Figura 2.7) es un paquete Java18 desarrollado por la Universidad de Stanford que contiene distintas herramientas para procesamiento de lenguaje natural [16]. Se creó con la intención de poder realizar análisis lingüístico de textos en pocas líneas de código y su diseño se ha centrado en que sea altamente flexible y extensible, pudiendose utilizar tanto para aplicaciones de comprensión del lenguaje textual a alto nivel o para dominios específicos.

Fig. 2.7. Logo de Stanford CoreNLP

En primera instancia, esta librería se concibió para analizar texto en inglés, pero el equipo de desarrollo ha implementado modelos para realizar operaciones sobre texto en

17https://stanfordnlp.github.io/CoreNLP/ 18https://www.java.com/

15 árabe, chino, francés, alemán y español; así como la posibilidad de integrarse con modelos desarrollados por terceros que dan soporte a otros idiomas; actualmente otros desarrolladores han integrado sus modelos de procesamiento de italiano, portugués y sueco. En la Figura 2.8 se muestran las funcionalidades básicas de Stanford CoreNLP y su integración con distintas lenguas [17]:

Fig. 2.8. Funcionalidades de CoreNLP

Stanford CoreNLP está escrito en Java y, como tal, únicamente se necesita tener Java instalado en cualquier sistema operativo para trabajar con esta dependencia. Además de programáticamente utilizando Java, se puede interactuar con esta librería desde la consola de comandos, desde su propia API, APIs de terceros y desde un servicio web. También puede utilizarse con otros lenguajes de programación como Python y JavaScript.

2.1.3.4. SpaCy

SpaCy19 (Figura 2.9) es una biblioteca de procesamiento de lenguaje natural para Pyt- hon desarrollada por Matthew Honnibal. Al contrario que NLTK y TextBlob, que como mencionábamos en puntos anteriores se concibieron como herramientas de aprendizaje e investigación de la programación orientada al procesamiento del lenguaje, se diseñó para la implementación práctica de sistemas listos para usarse en entornos de producción.

19https://spacy.io/

16 Fig. 2.9. Logo de spaCy

Esta herramienta está desarrollada en Python y CPython con la intención de optimizar la gestión de la memoria y el tiempo de procesamiento, queriendo hacer de spaCy una librería de potencia industrial para que pueda ser utilizada en sistemas a gran escala. En contrapartida, la programación con spaCy es más rígida, pero esta menor flexibilidad contribuye a cumplir con las decisiones de diseño y mejorar el rendimiento. Adicional- mente soporta flujos de deep learning que permiten la conexión con modelos estadísticos entrenados por otras herramientas machine learning del ecosistema Python. Éstas son algunas de las características de spaCy:

Modelos de redes neuronales

Soporte para más de 49 lenguas

Tokenización

Lematización

Etiquetado gramatical

Segmentación de oraciones

Reconocimiento de entidades

Análisis sintáctico

Integración para deep learning

Modelos vectoriales pre-entrenados

Visualizadores nativos

SpaCy está disponible para Windows, Mac OS X y Linux, y es una librería gratuita de software libre. Es compatible con las versiones Python 2.7 y de Python 3.5 en adelante, por lo que puede ser utilizado en cualquier intérprete de Python consistente con estas versiones.

17 2.1.3.5. librAIry

LibrAIry20 (Figura 2.10) es un framework desarrollado por Carlos Badenes-Olmedo, José Luis Redondo-García y Oscar Corcho que aglutina distintas herramientas de minería de textos, disponibles en distintas tecnologías e idiomas, y proporciona la posibilidad de que éstas operen en un mismo flujo de trabajo de manera distribuida, aislada y conalto rendimiento. Más que una herramienta en sí misma, librAIry se diseñó para que otras herramientas de procesamiento del lenguaje natural pudieran cooperar y coexistir en un mismo ecosistema para aprovechar sus características al máximo. De la misma manera, librAIry busca actuar como arquitectura única que permite la interoperabilidad entre herramientas de distinto soporte y/o lenguaje de programación, así como la coexistencia de distintas soluciones de almacenamiento en base de datos [18].

Fig. 2.10. Logo de librAIry

LibrAIry se sirve de una cola AMQP para coordinar los eventos de las diferentes plataformas involucradas en el flujo de trabajo, una API para permitir la interacción con el usuario, soporte para bases de datos y una serie de módulos. Aunque este framework sea mayoritariamente utilizado para análisis semántico de textos, destacamos la existencia de módulos para tareas de procesamiento del lenguaje natural con soporte para español, inglés, alemán, francés y portugués. Estos módulos permiten realizar las siguientes tareas:

Etiquetado gramatical

Lematización

Identificador de N-gramas

Soporte con Wikipedia21

LibrAIry y todos sus módulos están programados en Java, pero se han empaquetado como contenedores Docker22 y están disponibles en Docker-Hub23, por lo que el único requisito para poder utilizar esta plataforma es tener Docker y Docker-Compose instalados en el sistema.

20http://librairy.github.io/ 21https://es.wikipedia.org/ 22https://www.docker.com/ 23https://hub.docker.com/

18 2.2. Modelado de tópicos

El modelado de tópicos o topic modelling es un mecanismo utilizado en machine learning y NLP para la extracción de información semántica de un corpus de documentos no etiquetados. Esta información semántica se obtiene mediante la identificación de patrones de términos recurrentes que generan distintos tópicos. Los modelos de tópicos parten de la premisa de que todos los documentos del corpus están compuestos por una com- binación de temáticas o tópicos. Los tópicos, por su parte, constan de agrupaciones de palabras similares y con relaciones de significado entre ellas. Estas agrupaciones depa- labras, trasladadas al ámbito matemático, resultan en distribuciones de probabilidad que permiten determinar a qué tópicos hace referencia el contenido de un documento y en qué proporción [19]. De entre todos los algoritmos de modelado de tópicos se ha elegido el modelo Latent Dirichlet Allocation (LDA), por lo que esta sección se dedica a desglosarlo en detalle.

2.2.1. Bag-of-Words

En secciones previas se comentaba la importancia de las palabras como elemento principal para los modelos de tópicos. Una consecuencia directa de ello es que los modelos de tópicos se consideran modelos BoW, ya que realizan un análisis del lenguaje sin tener en cuenta el orden de las palabras, la gramática o la sintaxis. Para definir qué es un modelo BoW, se recurre a la siguiente declaración de Yoav Goldberg (2017), traducida al castellano [20]:

“Un procedimiento muy común para extracción de características de oraciones y documentos es el enfoque de bolsa de palabras o bag-of-words (BoW). En esta téc- nica, miramos el histograma de palabras del texto, es decir, consideramos que cada palabra cuenta como una característica propia.”

La intuición detrás de este tipo de modelo es la de que los documentos con contenido similar estarán compuestos por palabras similares y, en consecuencia, que se puede comprender el significado del documento mediante el análisis de los términos delosque consta. Con los modelos BoW se consigue tener una representación matemática de cada documento del corpus como una lista de palabras en la que cada palabra tiene un peso asignado que determina la relevancia del término, y sobre estos pesos se realizará el análisis de tó- picos. En los modelos BoW el peso de cada palabra en un documento es simplemente el número de apariciones. Antes de nada, es necesario presentar el diseño del modelo bag-of-words que va a utilizarse con los siguientes parámetros:

19 Vocabulario: Asumiendo que ya se dispone de un corpus de entrenamiento, deben definirse los métodos con los que se pretende obtener la lista de palabras con lasque alimentar el modelo de tópicos, puesto que en función de la aplicación puede ser interesante disponer de un vocabulario u otro. En la Sección 2.1.1 se habla de distintos procesos relativos al análisis léxico que están muy relacionados con las distintas fases de procesamiento de texto con las que se puede obtener un vocabulario para el corpus. Aplicado a modelado de tópicos, las distintas tareas de preparación del corpus para la obtención del vocabulario pueden ser las siguientes:

1. Tokenización y homogeneización: Con la tokenización se parte el texto en sus componentes principales. Dichas partes normalmente son palabras pero tam- bién pueden ser expresiones regulares de interés. La homogeneización es el proceso por el que se descarta la puntuación del texto y se ignora la diferencia entre mayúsculas y minúsculas. Cuando se realiza este proceso se dispone de una lista, o “bolsa”, de palabras. 2. Etiquetado gramatical o part-of-speech tagging para generar vocabularios úni- camente con palabras de categorías gramaticales determinadas. 3. Detección de N-gramas para considerar palabras que suelen ocurrir juntas como un único término del vocabulario. 4. Stemming o lematización, para reducir palabras derivadas a un término único. 5. Eliminación de stopwords, palabras muy frecuentes y poco frecuentes.

A continuación, se muestran varios ejemplos para generar vocabularios en función de las distintas tareas de preprocesado de textos que se utilicen sobre el corpus. En la Tabla 2.3 se considera un corpus sencillo de ejemplo donde cada documento es una frase popular en el mundo de los videojuegos. Aplicando tokenización y homogeneización, el vocabulario resultante sería el que se muestra en la Tabla 2.4:

ID Texto Referencia D1 Soy lo que los dioses han hecho de mí God of War (2005) D2 Nada es verdad, todo está permitido Assasins Creed (2007) D3 Te has encontrado con un destino terrible, The Legend of Zelda: ¿verdad? Majora’s Mask (2000) D4 Toda mentira contiene la verdad, y toda Sukoiden 2 (1998) verdad contiene una mentira

Tabla 2.3. Corpus de entrenamiento

20 Vocabulario 1 soy lo que los dioses han hecho de mí nada es verdad todo está permitido te has encontrado con un destino terrible toda mentira contiene y una 27 palabras

Tabla 2.4. Vocabulario 1

Aplicando etiquetado gramatical y un posterior proceso de lematización a la lista de palabras de la Tabla 2.4, obtendríamos el siguiente vocabulario formado solamente por palabras primitivas (Tabla 2.5):

Vocabulario 2 ser lo que dios haber hacer de mí nada verdad todo estar permitido te encontrar con un destino terrible mentira contener y 22 palabras

Tabla 2.5. Vocabulario 2

Como puede apreciarse, se ha disminuido el número de palabras del vocabulario debido a que las formas verbales se han reducido a su infinitivo (‘soy’ y ‘es’ se representan con el término ‘ser’) y los términos en femenino y plural se presentan en masculino singular (‘un’ y ‘una’ se representan con ‘un’). Si se eliminasen las stopwords del vocabulario de la Tabla 2.5 para mantener únicamente los términos con significado propio, podría resultar el vocabulario de la Tabla 2.6:

21 Vocabulario 3 ser dios haber hacer nada verdad todo permitir encontrar destino terrible mentira contener 13 palabras

Tabla 2.6. Vocabulario 3

Asignación de pesos: Una vez se dispone de la "bolsa de palabras", hay que determinar el criterio de asignación de relevancia de las palabras del vocabulario para la representación vectorial de cada documento. Hay dos representaciones principales:

• Representación BoW: El peso de un término dentro de un documento es el número de veces que aparece en él. En la Tabla 2.7 se muestra la representa- ción BoW de los documentos de la Tabla 2.3 utilizando el vocabulario 3 de la Tabla 2.6:

ser dios haber hacer nada verdad todo permitir encontrar destino terrible mentira contener D1 1 1 1 1 0 0 0 0 0 0 0 0 0 D2 1 0 0 0 1 1 1 1 0 0 0 0 0 D3 0 0 1 0 0 0 0 0 1 1 1 0 0 D4 0 0 0 0 0 2 2 0 0 0 0 2 2

Tabla 2.7. Representación Bag-of-Words

• TF-IDF (Term frequency - Inverse document frequency): Representación ma- temática que calcula el peso de un término en un documento en base al produc- to de la frecuencia del término (term frequency o TF) y la frecuencia inversa de documento (inverse document frequency o IDF). El valor tf-idf aumenta con la frecuencia de aparición de una palabra en un documento y disminuye cuando se trata de una palabra común que aparece en muchos documentos.

TF − IDFi j = TFi j × IDFi j (2.1)

ni j ni j TFi j = ∑ = (2.2) N nik |di| IDF j = log (2.3) k n j

donde:

◦ ni j es el número de veces que aparece el término t j en el documento di. ◦ N es el número total de documentos.

◦ n j es el número de documentos que contienen el término t j.

22 2.2.2. Latent Dirichlet Allocation

Latent Dirichilet Allocation (LDA) es un modelo probabilístico generativo para colecciones de datos discretos tales como colecciones de texto. Se trata de un modelo ba- yesiano jerárquico de varios niveles que considera que los documentos de una colección se generan en base a una combinación finita de tópicos latentes, donde cada tópico está caracterizado por una distribución probabilística de palabras. Estas distribuciones de palabras se infieren empleando las palabras presentes en el corpus como variables observadas [5]. LDA asume que los documentos del corpus se crean de la siguiente manera:

1. Se elige el número de palabras que contendrá el documento, N. Esta cantidad puede elegirse, por ejemplo, considerando a N ∼ Poisson(ξ), pero este planteamiento no es crítico para el desarrollo matemático del modelo y de ser necesario pueden utilizarse otras distribuciones que proporcionen distribuciones de longitud de documentos más realistas.

2. Se elige una distribución de tópicos para el documento a partir de un conjunto de tó- picos k, que se considera un valor conocido. Para LDA, se asume que la distribución de tópicos es una de las posibles salidas de una distribución a priori de Dirichlet.

θ ∼ Dir(α)

Los distintos valores de α condicionan la distribución de tópicos en los documentos, puesto que para valores de α menores que 1 los documentos tenderán a componerse de pocos tópicos dominantes, y viceversa.

3. Para cada una de las N palabras wn del documento, se realizan los siguientes pasos:

a) Se elige un tópico zn a partir de la distribución multinomial de tópicos obtenida en el paso 2.

zn ∼ Multinomial(θ)

b) Se elige la palabra wn del documento en base a la distribución multinomial de palabras para el tópico escogido en el paso anterior, es decir, desde la siguiente

probabilidad condicionada en el tópico zn:

p(wn|zn, β)

donde β representa la distribución de palabras para cada tópico. En esta ver- sión básica se asume que β tiene un valor fijo que deberá estimarse.

23 Fig. 2.11. Representación gráfica del modelo LDA básico (Figura tomada de [5])

La Figura 2.11 muestra visualmente las dependencias entre los distintos parámetros del modelo LDA básico. En esta imagen se pueden apreciar los tres niveles de los que consta el modelo:

Los parámetros α y β son parámetros a nivel de corpus, es decir, que se muestrean una sola vez a la hora de generar un corpus de documentos.

Las variables θd son variables a nivel de documento, muestreadas una vez para cada documento.

Las variables zdn y wdn son variables a nivel de palabra y se muestrean una vez por cada palabra para cada documento.

El proceso generativo en LDA corresponde a la siguiente función de distribución con- junta de variables ocultas y observadas: ⎛ ⎞ ∏K ∏D ⎜∏N ⎟ ⎜ | | ⎟ p(β1:K, θ1:D, z1:D, w1:D) = p(βi) p(θd) ⎝⎜ p(d,n θd)p(wd,n β1:K, zd,n)⎠⎟ (2.4) i=1 d=1 n=1 donde K representa el número de tópicos y D representa el número de documentos. De esta distribución se puede extraer la expresión objetivo de este modelo, que es la distribución condicional de la estructura de tópicos dados los documentos observados:

p(β1:K, θ1:D, z1:D, w1:D) p(β1:K, θ1:D, z1:D|w1:D) = (2.5) p(w1:D) donde el denominador es la probabilidad de encontrar el corpus observado bajo algún modelo de tópicos. Para calcularlo, bastaría con sumar las distribuciones conjuntas de cada estructura de tópicos oculta posible. Sin embargo, la naturaleza exponencial del número de estructuras de tópicos posibles hace que la inferencia exacta de esta expresión sea intratable de calcu- lar. No obstante, el modelo LDA puede servirse de algoritmos de estimación aproximada, que pueden ser incluso aproximación de Laplace, aproximación variacional24 y métodos

24Los métodos variacionales se utilizan para aproximar integrales irrealizables como las que aparecen con frecuencia en inferencia bayesiana y machine learning.

24 de cadena de Markov Monte Carlo. En el caso del modelo básico que se presentaba en la Figura 2.11, esta estimación se lleva a cabo con un algoritmo EM25 variacional. Es común que para corpus y vocabularios muy extensos surja un problema serio de dispersión debido a la alta probabilidad de que un documento nuevo contenga palabras que no aparezca en ningún otro documento de la colección. Con el enfoque básico, la estimación por máxima verosimilitud de los parámetros multinomiales asignaría las pro- babilidades de estas palabras a cero y, por extensión, probabilidad nula para nuevos documentos. Para subsanarlo, se presenta el modelo de la Figura 2.12, donde las distribuciones de palabras se generan con una distribución intercambiable de Dirichlet26. β ∼ Dir(η) El valor del parámetro η condiciona las distribuciones resultantes, puesto que para valores de η menores que 1 las distribuciones de palabras por tópico se concentrarán en una pocas palabras, y viceversa. El mecanismo de inferencia para este modelo suavizado sigue siendo un procedimien- to EM variacional como el empleado en el modelo básico, pero en esta ocasión estará extendido para considerar las modificaciones introducidas. Cabe destacar que desde quela creación del modelo LDA el modelo básico ha ido cayendo en desuso en favor del modelo suavizado, hasta llegar al punto de que el modelo suavizado actualmente se considera el modelo LDA básico.

Fig. 2.12. Representación gráfica del modelo LDA suavizado (Figura tomada de [5])

2.2.3. Herramientas para modelado de tópicos

En esta sección se revisan las características de algunas tecnologías para modelado de tópicos puesto que el número de herramientas disponibles es muy elevado. De entre las soluciones que no serán descritas se listan las siguientes tecnologías:

Stanford Topic Modeling Toolbox27

25El algoritmo EM o esperanza-maximización se utiliza para encontrar estimadores de máxima verosimilitud de parámetros en modelos probabilísticos que dependen de variables no observables [21]. 26Una distribución intercambiable de Dirichlet es simplemente una Dirichlet donde todas las componentes del vector α son η. 27https://nlp.stanford.edu/software/tmt/tmt-0.4/

25 BigARTM28

LibrAIry29

WORDSTAT30

2.2.3.1. Gensim

Gensim31 (Figura 2.13) es una librería NLP para Python desarrollada por Radim Rehu- rek especializada en modelado de tópicos no supervisado y análisis semántico de textos. Su diseño se centra en hacer de gensim una herramienta robusta, eficiente y escalable. Con este fin, esta librería es capaz de procesar corpus a gran escala utilizando algoritmos de entrenamiento incrementales online para que el procesamiento de textos no tenga lugar exclusivamente en memoria. Además, los algoritmos core de gensim utilizan rutinas matemáticas altamente optimizadas y disponen de una versión distribuida para lanzarse en clusters de máquinas para estar dotado con capacidad de alto rendimiento [22].

Fig. 2.13. Logo de Gensim

Gensim incluye implementación para las siguientes técnicas de topic modeling:

Latent Semantic Analysis

Non-negative Matrix Factorization, NMF o factorización matricial no negativa

Latent Dirichlet Allocation

Técnicas de embeddings de palabras y documentos.

Gensim es una librería open source cuyo soporte y mantenimiento se realiza mediante contribuciones de la comunidad. Está escrito puramente en Python y puede usarse en toda plataforma compatible con Python y NumPy32.

28http://bigartm.org/ 29http://librairy.github.io/ 30https://provalisresearch.com/products/content-analysis-software/ 31https://radimrehurek.com/gensim/index.html 32https://www.numpy.org/

26 2.2.3.2. MALLET

MALLET33 (Figura 2.14) es un paquete Java para NLP estadístico desarrollado por Andrew McCallum con la ayuda de estudiantes graduados y plantilla de la Universidad de Massachusetts en Amherst y la Universidad de Pennsylvania. Incluye herramientas sofisticadas para clasificación de documentos, modelado de tópicos y análisis semántico de textos y palabras, análisis de grupos, extracción de información y otras aplicaciones de machine learning aplicadas a textos.

Fig. 2.14. Logo de MALLET

A continuación se listan los algoritmos que implementa MALLET:

Latent Dirichlet Allocation

Modelado de tópicos multilingüe

Pachinko Allocation Model (PAM)

Tag-Weighted Topic Model

Algoritmos word2vec

MALLET es capaz de realizar las tareas de modelado de forma muy rápida y eficiente gracias a la implementación de mecanismos escalables de muestreo de Gibbs, optimiza- ción de hiperparámetros del modelo generativo LDA y potentes herramientas de inferencia de tópicos sobre nuevos documentos disponiendo de modelos previamente entrenados [23]. MALLET está desarrollado en Java y, como tal, únicamente se necesita tener Java instalado en cualquier sistema operativo para trabajar con esta dependencia. Además de programáticamente utilizando Java, se puede interactuar con esta librería desde la consola de comandos y con wrappers desde otros lenguajes de programación y módulos de topic modeling, como por ejemplo desde Gensim utilizando Python.

33http://mallet.cs.umass.edu/

27 3. SOLUCIÓN PROPUESTA

Para cumplir con los objetivos de este proyecto se ha optado por desarrollar un sistema software que gestione el flujo de tratamiento de información desde la obtención de losdatos de la Plataforma de Contratación del Sector Público hasta su análisis y caracterización, pasando por distintos procesos de estructuración y procesamiento de datos textuales.

3.1. Tecnologías utilizadas

Este apartado se reserva para hacer un repaso de las tecnologías utilizadas y los motivos de su utilización en la solución propuesta.

3.1.1. Python

Python13 (Figura 3.1) es un lenguaje de programación de alto nivel, interpretado, mul- tipropósito, multiparadigma y multiplataforma creado por Guido van Rossum a finales de los años 80. Se diseñó para que la implementación fuera rápida y sencilla, poniendo foco en que el código sea claramente legible e interpretable y en que el aprendizaje sea amigable, fácil y rápido [24].

Fig. 3.1. Logo de Python

Python es un lenguaje de tipado dinámico y gestión automática de la memoria que puede ser utilizado tanto en proyectos pequeños como a gran escala, siendo estos a su vez fácilmente ampliables. Asimismo, Python soporta distintos paradigmas de programación tales como la programación orientada a objetos, programación imperativa y programación funcional, por lo que puede adaptarse mejor al estilo de cada desarrollador. Además de la flexibilidad que aporta como lenguaje multiparadigma, Python dispone de una rica librería estándar e infinidad de librerías de terceros que permiten su integración con aplicaciones ajenas y otros lenguajes de programación, rasgo que hace a este lenguaje muy apropiado para realizar casi cualquier tarea. Con respecto a este proyecto, se ha elegido Python como lenguaje de programación por la facilidad que supone para el aprendizaje y la codificación, la flexibilidad en el estilo del código y la potente capacidad de integración con otros sistemas y herramientas. Sobre

28 este último punto, las librerías son particularmente importantes en este trabajo porque, como mencionamos en secciones anteriores, existen multitud de herramientas para NLP y topic modeling compatibles con Python, además de numerosas integraciones con otras aplicaciones básicas como gestores de bases de datos, herramientas de web scraping34 y herramientas de extracción de texto. Si bien Python 2 sigue muy presente en muchos sistemas, se ha elegido desarrollar el trabajo en Python 3 sin retrocompatibilidad porque pronto dejará de darse soporte a Python 2. En concreto, se ha utilizando la última versión estable, la versión 3.7.3, para disponer de las características más recientes del lenguaje y el mejor rendimiento posible para el programa.

3.1.2. MySQL

MySQL35 es un sistema de gestión de bases de datos relacional, multihilo y multiusua- rio basado en SQL; desarrollado inicialmente por la empresa MySQL AB y actualmente perteneciente a Oracle Corporation36. Gracias a su rendimiento, fiabilidad, escalabilidad y facilidad de uso se considera a MySQL la base de datos de código abierto más popular del mundo. Este título se ve afianzado por su uso extendido como base de datos líder en aplicaciones web e incluso es utilizado por gigantes como Google37, Facebook38 o Wikipedia39 [25].

Fig. 3.2. Logo de MySQL

MySQL funciona sobre múltiples plataformas, incluyendo Windows, Linux y Mac OS X, y existen varias interfaces de programación de aplicaciones que permiten el acceso a bases de datos MySQL desde diversos lenguajes de programación como Java, C y Python, entre otros. La estructura de datos de licitaciones en la Plataforma de Contratación del Sector Pú- blico sigue un esquema fijo y resulta sencillo extraporlarla al modelo de datos relacional, basado en tablas y relaciones entre ellas. Por este motivo, además de por ser multiplataforma, de alto rendimiento y fácil de gestionar desde Python, se ha escogido MySQL

34Técnicas para extracción de información de sitios web 35https://www.mysql.com/ 36https://www.oracle.com/es/index.html 37https://www.google.com/ 38https://www.facebook.com/ 39https://www.wikipedia.org/

29 como gestor de base de datos para este trabajo. Como librería de control de bases de datos MySQL se utiliza PyMySQL40 por estar completamente programada en Python, ser fácil de instalar y compatible con Python 3.

3.1.3. Apache Tika

Apache Tika41 (Figura 3.3) es un framework de detección y análisis de contenido textual programado en Java y administrado por Apache Software Foundation42. Permite extraer texto y metadatos de más de 1400 formatos de fichero distintos utilizando una única interfaz. También es capaz de identificar el lenguaje en el que está escrito untexto y traducir textos de un idioma a otro. Dada su potencia y versatilidad, y aunque está escrito en Java, se utiliza mucho con otros lenguajes a través de herramientas por línea de comandos y servidores RESTful. Asimismo, al estar programado en Java, también es multiplataforma.

Fig. 3.3. Logo de Apache Tika

Si bien la información de licitaciones de la Plataforma de Contratación del Sector Público sí tiene un esquema determinado, hasta la fecha no se ha fijado un formato de fichero estándar en el que deban subirse los pliegos de especificación técnica. Esmás,aún con el mismo formato los métodos de extracción de texto pueden diferir de un documento a otro. Un ejemplo claro que se ha observado en la Plataforma de este caso son los ficheros escaneados a partir de pliegos en papel, para los que se requiere un análisis óptico del texto que lo digitalice. Dado que es de estos pliegos de donde se pretende extraer el dato con el que alimentar el modelo de tópicos, Apache Tika resulta particularmente útil para hacer que estas limitaciones respecto a los formatos no sean un problema, ya que permite homogeneizar el análisis de fuentes textuales muy heterogéneas, incluso de aquellas de texto no digital debido a su integración con Tesseract OCR43. En consecuencia, este trabajo hace uso de Apache Tika a través de su librería Python para centralizar la extracción del texto de los pliegos técnicos.

40https://github.com/PyMySQL/PyMySQL 41https://tika.apache.org/ 42https://www.apache.org/ 43https://github.com/tesseract-ocr/. Herramienta de reconocimiento óptico de caracteres

30 3.1.4. PyLDAvis

PyLDAvis44 es una librería Python para visualización interactiva de modelos de tópi- cos desarrollada por Ben Mabey. Surge como una adaptación del paquete LDAvis45 para R, desarrollado por Carson Sievert y Kenny Shirley. Este paquete está orientado a ayudar a la interpretación de los tópicos resultantes de un modelo LDA aplicado a un corpus de textos. Para ello, extrae la información del modelo y genera una visualización web interactiva de los tópicos. PyLDAvis está preparado para interpretar y representar gráficamente modelos LDA entrenados por Gensim, Scikit-learn46 y GraphLab47. Este trabajo hará uso de esta librería por su capacidad de visualización específica de los modelos de tópicos generados por Gensim, dado que esta última será la herramienta de modelado de tópicos que se va a utilizar. Adicionalmente, y aunque pueda implementarse la visualización desde el código del programa, pyLDAvis está diseñado para utilizarse desde un notebook Jupyter48 (Figura 3.4). Por este motivo, la parte de visualización de tópicos se ha codificado en un notebook para sacar el máximo partido a PyLDAvis y disfrutar de una visualización más dinámica.

Fig. 3.4. Logo de Jupyter

3.1.5. Otras tecnologías

Se reserva esta sección para mencionar el uso en este proyecto de herramientas NLP y de modelado de tópicos que ya se han definido con rigor en secciones previas:

NLTK (Sección 2.5) como herramienta para tokenizar textos y obtener la lista de stopwords.

44https://github.com/bmabey/pyLDAvis 45https://github.com/cpsievert/LDAvis 46https://scikit-learn.org/stable/ 47https://turi.com/ 48https://jupyter.org/. Aplicación web open-source para crear y compartir documentos con código inser- tado, ecuaciones y visualizacion de datos.

31 TextBlob (Sección 2.6) como detector de idioma.

LibrAIry (Sección 2.10) para lematización, etiquetado gramatical y detección de N- gramas, ya que esta herramienta proporciona el soporte más completo para analizar textos en español.

Gensim (Sección 2.2.3.1) y Mallet (Sección 2.2.3.2) para realizar la caracteriza- ción por tópicos mediante un modelo LDA. En concreto, se utilizará Gensim con el wrapper de Mallet, ya que los experimentos realizados con ambas implementaciones daban tópicos más interpretables y con mayores valores de coherencia con los modelos generados con Mallet.

3.2. Diseño

En la Figura 3.5 se presenta un esquema de la arquitectura básica del sistema, mostrando la secuencia de tareas que constituyen el flujo de datos, identificando el componente al que pertenecen y las tecnologías involucradas en cada una.

Fig. 3.5. Arquitectura básica de la solución

32 El software del sistema propuesto esta completamente escrito en Python y consta de dos partes bien diferenciadas:

Script encargado de las tareas de recopilación y tratamiento de los datos de con- tratación para generar el corpus. Toma como entrada los Atom que contienen la información de contratación y genera una base de datos.

Notebook dedicado al entrenamiento de los modelos de tópicos y la visualización de estos. Opera a partir de la base de datos y produce como salida una representación del modelo de tópicos entrenado.

Tanto el programa como el notebook se han escrito utilizando el paradigma de progra- mación imperativa basada en módulos que agrupan funciones similares. Para este sistema se ha considerado que las funciones similares son aquellas involucradas en una tarea determinada del flujo del programa. Con este criterio en mente, el código se ha configurado en una estructura de directorios tal que cada directorio representa una tarea específica del flujo de datos mostrado en la Figura 3.5. En cada directorio se encuentran unoovarios módulos que implementan las funciones necesarias para realizar la tarea pertinente. La Figura 3.6 muestra la estructura de directorios y ficheros de la aplicación:

PCSP_categorizer main.py PCSP’s topic visualizer.ipynb setup config.py config.json database_generator atom_parser.py bid_crawler.py processed_zips.txt text_extractor format_parser.py text_extractor.py vocabulary_generator text_cleaner.py topic_modeler model_generator.py helpers helpers.py BaseDMsql.py

Fig. 3.6. Estructura de directorios y ficheros de la aplicación Python

En adelante, se describen las decisiones de diseño y la funcionalidad de cada componente del sistema en sendos apartados.

33 3.2.1. Script Python: Creación del corpus

Este primer elemento del sistema es un programa o script pensado para ser ejecutado desde línea de comandos. Centraliza todas las tareas de preparación del corpus, incluyendo la generación del modelo de datos, el llenado de la base de datos y el control de las interacciones entre las distintas herramientas involucradas. Los siguientes epígrafes describen su funcionalidad en orden lógico de ejecución, manteniendo a la vez la coherencia con la estructura de directorios y módulos mostrada en la Figura 3.6.

3.2.1.1. Módulo principal

Este módulo actúa como punto de entrada al script y está codificado en el fichero main.py. En este punto se realiza la inicialización de recursos (ver Subsección 3.2.1.1.1) y se muestra un menú de opciones mediante el que el usuario puede seleccionar la fase del programa que desea ejecutar. De esta forma, las distintas fases del programa están desacopladas entre sí, permitiendo realizar una de ellas individualmente y retomar otra en otro momento.

Fig. 3.7. Menú inicial de opciones

La Figura 3.7 muestra el menú de opciones descrito; en ella se aprecia que la nume- ración de las opciones es consistente con el orden de tareas mostrado en la Figura 3.5. Si bien el menú está concebido para poder realizar las acciones en el orden deseado, estas deben ejecutarse en la secuencia inicial al menos una vez, puesto que en un primer momento las distintas fases tienen dependencia directa con las fases anteriores. En otras palabras, no podremos llenar la base de datos por primera vez sin haber generado antes el modelo de datos, al igual que no podremos recuperar texto de los pliegos si carecemos de documentos originales. La lógica de este menú principal puede resumirse en el diagrama de flujo de la Figura 3.8:

34 Fig. 3.8. Diagrama de flujo: Menú principal del programa

3.2.1.1.1. Inicialización de recursos

Para acondicionar el entorno del sistema se crea el directorio setup con un fichero de configuración en formato JSON con variables de configuración y un script Pythonque carga estas variables en memoria e inicializa otros recursos de utilidad, como ficheros de log. Algunos elementos que se pueden encontrar en el fichero de configuración son los pa- rámetros de conexión con la base de datos, el modelo de datos, variables de configuración para la fase de extracción de textos, listados personalizados de palabras para la etapa de pre-procesamiento de texto previa al modelado de tópicos o rutas a diversos recursos del sistema. Es importante adaptar los valores recogidos en este fichero a las necesidades de la máquina específica que ejecuta el programa, en especial las rutas y los parámetros de conexión con la base de datos.

35 3.2.1.2. Construcción de la base de datos

Esta es la primera fase del programa y se basa en la obtención, la estructuración y el almacenamiento de la información de licitaciones existente en la Plataforma de Contra- tación del Sector Público para constituir el conjunto de datos de partida con los que se realizará la caracterización. Este apartado se reserva para explicar las distintas acciones de las que consta esta fase.

3.2.1.2.1. Modelo de datos

En etapas previas a la implementación de la aplicación, se comienza por analizar el sitio web de la Plataforma de Contratación del Sector Público para estudiar la información de licitaciones y los distintos métodos de extracción de la misma con la intención de obtener una estructura para el modelo de la base de datos. Para satisfacer las obligaciones en cuanto a publicación de licitaciones establecida en la Ley de Contratos del Sector Público (art. 63 LCSP 9/2017, de 8 de noviembre [4]), la Plataforma incorpora un apartado denominado “Datos abiertos” que redirige una página web perteneciente al Portal Institucional del Ministerio de Hacienda49 donde se encuentran todas las licitaciones publicadas en la Plataforma desde el 1 de enero de 2014, y los contratos menores desde el 1 de enero de 2018. Esta información sobre contratos públi- cos se actualiza diariamente y está expuesta en forma de feeds Atom50. La información de cada licitación recogida en los feeds sigue el esquema estandarizado establecido por la Subdirección General de Coordinación de la Contratación Electrónica para facilitar el procesamiento automatizado de los datos de contratación. Dicho esquema, convenientemente documentado y disponible on-line junto con los feeds [26], ha sido la fuente principal para realizar el modelo de datos relacional para la aplicación propuesta, que se muestra en la Figura 3.9. Cabe resaltar que la tabla bids de la Figura 3.9 no representa la estructura real de la tabla contenedora de los datos de licitaciones, sino un esquema genérico e incompleto, pues su envergadura hace imposible su encuadre en el diagrama del modelo completo. Por lo tanto, se ha elegido representarlo aparte en la Figura 3.10. Adicionalmente, se adjunta la Tabla 3.1 mostrando la correspondencia entre las tablas del modelo y la información que recogen.

49http://www.hacienda.gob.es/es-ES/GobiernoAbierto/Datos %20Abiertos/Paginas/licitaciones _plataforma_contratacion.aspx 50Ficheros de redifusión de información en formato XML que contienen listas de contenido estructurado.

36 37

Fig. 3.9. Modelo de datos Fig. 3.10. Modelo de la tabla bids

38 Tabla Contenido bids Datos de licitaciones bid_cpv_codes Clasificación CPV de licitaciones docs Pliegos técnicos, administrativos y otros documentos texts Textos extraídos admission_conditions Condiciones de admisión de solicitudes evaluation_criteria Criterios de evaluación de solicitudes awarding_conditions Condiciones de adjudicación contract_extensions Extensiones de contrato contract_mods Modificaciones de contrato events Eventos asociados al proceso de adjudicación lots Lotes ofertados con el contrato lot_cpv_codes Clasificación CPV de lotes orgs Organismos involucrados publications Datos de publicación de licitaciones required_business_classifications Clasificación empresarial requerida para adjudicación required_guarantees Garantías requeridas para adjudicación winners Información de adjudicación de ofertas

Tabla 3.1. Contenido de tablas en modelo de datos

3.2.1.2.2. Construcción de la estructura de tablas

Una vez definido el modelo de datos, se opta por automatizar la creación de lastablas que lo componen en la base de datos desde dentro de la aplicación. Como paso previo para ello es necesario “traducir” la estructura de tablas del modelo a formato JSON para incluirla en el fichero de configuración y así cargarla al empezar el programa como variable del sistema. La opción 1 del menú, codificada en el módulo principal, se encarga de leer el modelo cargado y realizar las consultas SQL pertinentes para crear las tablas con la especificación de campos, tipos y claves establecidos. Esta misma opción también cubre el caso en que el modelo ya haya sido creado en la base de datos y este se quiera modificar; o simplemente se desee descartar todos los datos almacenados. En este caso se eliminarían las tablas de la base de datos y se crearían de nuevo acorde al fichero de configuración. En ambos casos de uso se procede automáticamente con el llenado de la base de datos una vez se han creado las tablas (ver Figura 3.8). La lógica descrita se representa en la Figura 3.11 y debe entenderse como inscrita en la acción “Crear/reconstruir base de datos” del diagrama de flujo de la Figura 3.8:

39 Fig. 3.11. Diagrama de flujo: Creación y reconstrucción de base de datos

3.2.1.2.3. Almacenamiento de datos de contratación

La opción 2 del menú principal sirve para lanzar el llenado de la base de datos con la información de contratación. Esta funcionalidad está codificada en los módulos del directorio database_generator. Como se comenta en secciones previas, la información de contratación que pretende almacenarse es pública y accesible en forma de feeds Atom cuyo contenido atiende a un esquema específico documentado. Conociendo el lugar y la estructura de losdatos contenidos en estos ficheros, se define la siguiente secuencia de actividades para obtener y guardar la información deseada:

1. Obtención de feeds: Se realiza web scraping con la librería Python BeautifulSoup51 para navegar por el sitio de publicación y recuperar las URLs donde están alojados los feeds. En dicha sección, las URLs obtenidas dirigen a recursos de dos tipos:

Ficheros en formato Atom, que representan el feed actual que se actualiza a diario. Cada fichero Atom contiene, entre otros elementos, una entrada por licitación y un vínculo al siguiente feed, que contendrá entradas más antiguas. Ficheros comprimidos en formato ZIP que contienen ficheros Atom históri- cos correspondientes a un periodo de publicación determinado. Se consideran como históricos a los ficheros Atom del mes anterior al actual, por loque se encontrarán ficheros históricos con información mensual agregada desde enero de 2019. Los feeds con datos anteriores al año actual se agregarán for- mando ficheros ZIP con información anual, existiendo un fichero paracada año desde 2012 hasta 2018.

Asimismo, las URLs contienen la fecha de publicación del feed e identifican distintos tipos de feed en función del tipo de contrato al que hacen referencia sus entradas. Se distinguen tres tipos de contrato:

Licitaciones publicadas en los perfiles del contratante alojados en la PCSP.

51https://www.crummy.com/software/BeautifulSoup/

40 Licitaciones publicadas en la Plataforma por organismos que no tienen su perfil del contratante alojado en la PCSP mediante mecanismos de agregación. Contratos menores publicados en los perfiles del contratante alojados enla PCSP.

Finalmente, se obtiene una lista de URLs en la que para cada tipo de contrato hay referencias a un único Atom con la información actual que enlaza con ficheros más antiguos y un conjunto de ficheros comprimidos con información histórica. De aquí en adelante, el procesamiento posterior a la descarga de estos recursos se realizará en tres hilos concurrentes. Cada uno de estos hilos procesará únicamente las URLs de un tipo determinado de contrato. Además, dado que las URLs contienen sellos temporales de publicación, estas se procesan en orden cronológico, de la más reciente a la más antigua por motivos que se explicarán un poco más adelante.

2. Carga de feeds: En esta fase se realiza una petición HTTP GET para descargar el contenido de cada URL y se prepara para la extracción de información de contrata- ción. Se resalta que la descarga es directamente en memoria, sin almacenar ningún feed o fichero comprimido en disco. Dado que los ficheros Atom están en formato XML, basta con cargar el contenido del feed en un objeto Python que represente el árbol XML y así poder navegar por sus nodos; en este caso se ha optado por utilizar la librería Python lxml52. Para los ficheros históricos primero se extraen los ficheros Atom que contienen yseitera sobre cada uno de ellos para cargarlos como árbol XML.

3. Procesamiento de feeds: Con los feeds cargados como XML se procede al análisis de sus nodos y la obtención de los datos de contratación. Dicho procesamiento no es más que la iteración por cada una de las entradas del feed siguiendo la estructura del XML definida en la documentación de referencia [26] para construir los objetos que, finalmente, constituirán los registros que sein- sertarán en la tabla correspondiente de la base de datos. A continuación, se remarcan las siguientes consideraciones con las que se ha implementado este proceso:

Los feeds contienen hasta 500 entradas con datos de publicación de licitaciones en orden cronológico, donde cada licitación tiene una URI como identificador único, un sello temporal de publicación e información sobre el contrato, entre la que se encuentran los enlaces a los pliegos, la clasificación CPV, la organización contratante, los criterios de adjudicación o los resultados del proceso de adjudicación del contrato. Aunque la mínima información necesaria para generar el corpus son los enlaces a los pliegos técnicos, se guardará la información completa de cada licitación para realizar otros análisis de interés basados en otros parámetros de las ofertas o facilitar trabajos futuros.

52https://lxml.de/

41 Adicionalmente a las entradas de actualización de licitaciones, se incluye un número indefinido de entradas que corresponden a licitaciones que han dejado de estar disponibles desde la PCSP y reflejan la fecha y la hora de eliminación del contrato en la Plataforma. Siguiendo el criterio explicado en la conside- ración anterior, esta fecha de eliminación también podría ser relevante para otros análisis y, como tal, también se guarda. En el conjunto de feeds una misma licitación puede aparecer tantas veces como modificaciones se hayan producido en dicha licitación. En la Sección 3.2.1.2.1 queda claro que la información de licitaciones se guardará en la tabla bids y que dicha tabla tiene una clave primaria correspondiente a la URI única de cada licitación. Por lo tanto, no es posible insertar más de una entrada por concurso en bids y para mantener al día los datos de las licitaciones guarda- das en la base de datos sus registros correspondientes deben ir actualizándose cuando sea oportuno. Además, si este fenómeno no se gestiona de ninguna manera puede llevar a la sobreescritura de registros de la base de datos con información obsoleta. Como solución a esta cuestión, antes de proceder con el análisis de la licitación completa se realizan una serie de comprobaciones para determinar si los datos que están siendo procesados son nuevos, actualizan la información de alguna licitación o están obsoletos. En la Figura 3.12 se muestran las casuísticas de inserción, actualización y descarte de entradas en función del resultado de estas comprobaciones: De esta manera, únicamente se actualizarán los registros cuando la informa- ción sea, en efecto, más actual que la presente en la base de datos, a la vez que se agilizan los tiempos de procesamientos de los feeds al ignorar las entradas obsoletas antes de analizarlas por completo. Este es el motivo por el que es importante ordenar los feeds al comenzar el procedimiento de llenado de la base de datos para trabajar con los más recientes en primer lugar. Los elementos a insertar o actualizar en la base de datos se van guardando en una lista hasta que se procesa el feed en su totalidad, momento en el que se introducen todos los registros de la lista en la base de datos con una única consulta SQL por tabla para optimizar los tiempos de escritura en disco.

En el caso de los ficheros históricos, este proceso debe realizarse con todos ycada uno de los feeds que contienen, desde los más recientes a los más antiguos. Dado que los ficheros históricos son estáticos, una vez almacenados no tendría sentido volver a procesarlos en otra operación de llenado, pues esta información ya es- taría almacenada en disco o se habría sobrescrito con información más reciente. Para ahorrar tiempo de descarga, carga y procesamiento, cuando se guardan todos los datos de un fichero histórico, su URL queda registrada en el fichero databa- se_generator/processed_zips.txt. Todas las URLs en este fichero serán ignoradas en la etapa de obtención de feeds. En el caso de los ficheros Atom correspondientes a la información actual, tras guar-

42 Fig. 3.12. Diagrama de flujo: Lógica de inserción y actualización de licitaciones en basede datos

dar sus propias entradas se obtiene el vínculo al siguiente feed para repetir el procedimiento. En lo sucesivo, este procedimiento se repetiría con todos los Atom enla- zados hasta que se encuentre un vínculo que referencie a un feed histórico o del mes anterior al actual (recordemos que estas URLs identifican la fecha de publicación del feed). Así se evita procesar la misma información más de una vez, ya que los ficheros del mes anterior ya están contenidos en ficheros históricos y se procesarán como tales más adelante.

4. Eliminación de posibles duplicados: A este punto se llega cuando los tres hilos han finalizado su ejecución y se han unido al hilo principal del programa. Comose puede comprobar en el modelo de datos (Figura 3.9), la única tabla con clave primaria es bids, motivo por el cual esta es la única tabla para la que se han implementado lógicas de actualización de registros. Al actualizar una licitación se insertan nuevos registros en las demás tablas que pueden resultar en registros duplicados, pues ninguna de ellas dispone de clave primaria que identifique los registros susceptibles a ser actualizados. Este último paso elimina dichos registros duplicados para com- pactar el tamaño de la base de datos replicando la estructura de tablas sin clave primaria e introduciendo en ella los registros únicos.

43 A continuación se muestra la Figura 3.13 con la representación gráfica de los procedimientos descritos. El contenido de este diagrama debe considerarse como el flujo de procesos internos de la acción “Llenar base de datos” del diagrama de flujo de la Figura 3.8.

Fig. 3.13. Diagrama de flujo: Llenado de base de datos

3.2.1.3. Extracción de texto

En el momento en que la base de datos contiene información sobre licitaciones y sus documentos asociados se puede ejecutar la opción 3 del menú. La funcionalidad imple- mentada para esta opción se sirve de la información de pliegos almacenada en disco para recuperar los documentos originales y generar el corpus de entrenamiento con sus conte-

44 nidos textuales. Al elegir dicha opción, se genera un nuevo menú de opciones mediante el cual se puede elegir si extraer el texto del conjunto total de pliegos técnicos o solo los asociados a licitaciones con una clasificación CPV particular. Los códigos CPV establecen un sistema de clasificación específico que se utiliza en Contratación Pública para identificar eltipo de trabajo ofertado en una licitación. Se trata de códigos numéricos de 8 dígitos correspondientes a un enunciado que describen los servicios objeto del contrato. Estos códigos están diseñados para poder subdividirse, y así aportar más precisión sobre el servicio ofertado, lo que se traduce en una jerarquía de códigos, donde los códigos en las partes más altas de la jerarquía representan servicios más genéricos que los de las partes inferiores [27]. En la Figura 3.14 se muestra un ejemplo de código CPV con su jerarquía subyacente utilizando una estructura de árbol:

48000000 PAQUETES DE SOFTWARE Y SISTEMAS DE INFORMACIÓN 48100000 PAQUETES DE SOFTWARE ESPECÍFICO DE UN SECTOR ECONÓMICO 48110000 PAQUETES DE SOFTWARE DE PUNTOS DE VENTA 48120000 PAQUETES DE SOFTWARE DE CONTROL DE VUELOS 48121000 PAQUETES DE SOFTWARE DE CONTROL DEL TRANSITO AÉREO 48130000 PAQUETES DE SOFTWARE DE APOYO EN TIERRA Y DE ENSAYOS PARA LA AVIACIÓN 48131000 PAQUETES DE SOFTWARE DE APOYO EN TIERRA PARA LA AVIACIÓN 48132000 PAQUETES DE SOFTWARE DE ENSAYOS PARA LA AVIACIÓN ... 48200000 PAQUETES DE SOFTWARE DE CONEXIÓN EN RED, INTERNET E INTRANET ... 48300000 PAQUETES DE SOFTWARE DE CREACIÓN DE DOCUMENTOS, DIBUJO, TRATAMIENTO DE IMÁGENES, PLANIFICACIÓN Y PRODUCTIVIDAD ......

Fig. 3.14. Ejemplo de jerarquía en clasificación CPV

Los códigos CPV mostrados en el menú corresponden a los CPV asociados a licitaciones presentes en la base de datos que contienen documentos técnicos y cuyos textos no han sido extraídos, motivo por el cual este menú se genera dinámicamente en función de los datos almacenados. En consecuencia, puede que no todos los códigos CPV que existen aparezcan como opción seleccionable. En las Figuras 3.15 y 3.16 se muestra un ejemplo de interacción con el menú de opciones descrito para realizar la extracción de texto sobre los documentos asociados a un CPV.

45 Fig. 3.15. Menú principal de selección de códigos CPV

Fig. 3.16. Submenús de selección de códigos CPV

46 Cuando se ha seleccionado el filtro de licitaciones deseado, se cargan en memoria todos los enlaces a los pliegos técnicos no procesados que satisfacen el criterio de clasifi- cación establecido y comienza la extracción de textos para el corpus. Para cada enlace se aplica el siguiente procedimiento, codificado en los módulos del directorio text_extractor:

1. Filtro por dominio: No todos los pliegos técnicos están disponibles mediante enlaces referentes al mismo dominio. En consecuencia, el enlace en cuestión, según su dominio, puede no dirigir directamente al documento, sino que puede mostrar una página web de salto al pliego o un formulario. Esta heterogeneidad de dominios y diseño de páginas web supone una limitación en esta fase puesto que es necesario implementar diferentes mecanismos de obtención de documentos para cada dominio conflictivo. Se ha elegido definir una lista de dominios en la que seidentifica cuáles serán ignorados y cuáles tienen un mecanismo adaptado a su estructura con el que conseguir los pliegos.

2. Descarga del recurso: Al superar los filtros de dominio se realiza la petición HTTP para descargar el recurso en memoria. En caso de que la descarga finalice con códi- go HTTP 400, se elimina el registro de la tabla docs de la base de datos que contiene el enlace con el que estamos trabajando al ser una URL inservible.

3. Filtro por Content-Type: Al no existir un formato específico en el que publicar los pliegos es necesario recurrir a la cabecera Content-Type del recurso HTTP descar- gado para conocer de qué tipo es antes de proceder con el análisis del mismo, pues ciertos formatos carecen de lenguaje natural textual y es conveniente ignorarlos. De manera análoga a la criba de dominios previamente realizada, se coteja el Content- Type del recurso con los contenidos en una lista que identifica cuáles pueden ser procesados por Tika para recuperar su contenido textual y cuáles no. Los valores contenidos en dicha lista son modificables desde el fichero de configuración del sistema.

4. Obtención del documento a partir del recurso: Esta etapa es opcional y solo transcurren por ella los recursos identificados como html en la etapa anterior yque, además, están asociados con alguno de los dominios conflictivos (los recursos html que no esten asociados con un dominio conflictivo se analizarán como documentos de texto normales). Se realizan los procedimientos pertinentes para obtener el pliego según la estructura de las páginas web del dominio en cuestión. Una vez obtenido el documento, se filtra por Content-Type para determinar si puede ser procesado por Tika.

5. Extracción de texto: En esta fase se realiza la extracción de contenido textual de los documentos utilizando Apache Tika a través de su librería Python. Normalmente el procesamiento básico del parser de Tika es suficiente para todos los documentos que llegan a este punto, en su mayoría documentos PDF. Sin embar-

47 go, los documentos PDF generados a partir de pliegos escaneados deben procesarse con un OCR para poder obtener algún resultado. Gracias a su integración con Tesse- ract OCR, es posible realizar este análisis modificando la configuración del parser de Tika. La integración TikaOCR permite el análisis de PDFs con imágenes escaneadas utilizando dos estrategias de procesamiento [28]:

Renderizar cada página del PDF y aplicar el OCR sobre la página completa. Extraer las imágenes insertadas en el documento como si se tratara de imáge- nes adjuntas y aplicar el OCR sobre cada una de ellas de manera individual.

Tras un estudio del rendimiento de TikaOCR con ambas estrategias para establecer cual se adaptaba mejor los pliegos, se observó que para ciertos documentos no era posible recuperar su texto. En unas ocasiones la extracción solo era posible con una de las estrategias, y en otras no era posible con ninguna de las dos. Para recuperar el máximo número de documentos procesados se determinó que el procedimiento de extracción de texto con OCR se haría en dos pasos utilizando una estrategia en cada uno:

a) En primer lugar se procesa el documento con el parser de Tika utilizando la estrategia de renderizado de páginas completas porque este suele ser el que más veces falla, pero en caso de éxito es típicamente más rápido. b) Si la primera estrategia falla o no proporciona texto alguno, el documento se procesa con la otra. Si bien esta estratégica normalmente proporciona tiempos de extracción más elevados, es capaz de recuperar el texto donde la otra no pudo.

6. Procesamiento NLP de texto extraído: En esta fase se prepara el texto antes de almacenarlo en la base de datos. Tras eliminar los signos de puntuación del texto y asegurar que todas la palabras del texto están separadas por un único espacio, este se pasa por un detector de idioma para descartar los textos que no estén en español. A los textos que superen el filtro de idioma se les aplicarán los siguientes procesos NLP:

a) Lematización, etiquetado gramatical y detección de N-gramas53. Se filtrará por categoría gramatical para mantener nombres, adjetivos, verbos y adver- bios. b) Eliminación de stopwords. Además de la lista de stopwords proporcionada por NLTK, se ha decidido eliminar también a las palabras con menos de tres letras, los valores numéricos y las palabras que contienen números junto con las letras por no considerarse que aporten información sobre la temática de los documentos.

53LibAIry realiza las tres operaciones a la vez

48 Estas funciones NLP están implementadas en los módulos del directorio vocabu- lary_generator.

7. Almacenamiento de texto limpio en base de datos: Una vez se dispone de un texto pre-procesado, se comprobará que su longitud no excede los 50000 caracteres, longitud máxima seleccionada para encajar en un registro de la tabla texts. De sobrepasar este límite, se dividirá el texto en mitades hasta que la longitud de cada sección pueda encajar en sendos registros. Realizadas estas operaciones, se almacena el texto creando un registro en la tabla texts, o varios si el texto ha sido seccionado.

La Figura 3.17 representa gráficamente el proceso de extracción de textos explicado. Igual que en secciones anteriores, el contenido de este diagrama debe considerarse como el flujo de procesos involucrado en la acción “Recuperar texto de pliegos” del diagrama de flujo de la Figura 3.8.

3.2.2. Modelado y visualización de tópicos

La parte de modelado y visualización están codificadas en el fichero PCSP’s topic visualizer.ipynb como notebook Jupyter. Este notebook se sirve de las funciones codificadas en los módulos del directorio topic_modeling para entrenar modelos de tópicos, e implementa la representación gráfica de los modelos generados. En primer lugar, se utilizan los textos extraídos de los pliegos como corpus para entrenar un modelo LDA de N tópicos, donde N es un número de tópicos introducido por el usuario. El procedimiento específico para entrenar el modelo es el siguiente:

1. Generación de vocabulario: El vocabulario es la lista de tokens que hay en todos los documentos. Para generarlo, se cargan los textos de la tabla texts de la base de datos y se realiza un segundo proceso de limpieza del vocabulario, que consta de los siguientes procedimientos:

a) Tokenización: Los textos cargados son cadenas completas donde los tokens están separados por espacios porque se eliminó la puntuación del texto antes de guardarlo en disco. Simplemente se utilizan los espacios como separadores del texto para obtener su lista de tokens. b) Normalización de tokens: Transformación de tokens a letra minúscula y eli- minación de tildes. Se mantiene la letra ñ. c) Eliminación de palabras irrelevantes: Aunque el texto ya ha sufrido una primera limpieza de palabras irrelevantes y stopwords previa al almacenamiento en base de datos, hay palabras que en esta aplicación no aportan ninguna infor- mación relevante. Entre ellas se consideran la jerga propia de la contratación pública, los nombres propios de personas y lugares, los nombres de los meses

49 Fig. 3.17. Diagrama de flujo: Extracción de textos

50 y días de la semana, los apellidos y las siglas y acrónimos ambiguos, entre otras. Descartando estas palabras genéricas del corpus se mejora la precisión del modelo. Para identificarlas y eliminarlas se define una lista de palabras irrelevantes modificable a mano desde el fichero de configuración del sistema. El dinamismo de esta lista, y la de equivalencias que se describe a continua- ción, hace que este proceso deba realizarse al generar el modelo y no en el momento de guardar el texto en la base de datos. d) Aplicación de equivalencias: La utilización intensiva de OCR para la obten- ción de textos puede ocasionar el reconocimiento incorrecto de palabras y/o caracteres. Además, es común que la lematización no sea 100 % precisa y se generen términos erróneos. Cuando las palabras incorrectas son fácilmente asociables a una palabra completa, se incluye en una lista de correspondencia de palabras para sustituir el token erróneo por su palabra correcta. También consideramos en esta lista de equivalencias a aquellos N-gramas que corresponden a tokens diferentes que hacen referencia al mismo concepto, como ocurre con los tokens “bigdata” y “big_data”. También suele ocurrir que se capturen N-gramas diferentes para el plural y el singular, como lo que ocurre con los tokens “base_de_datos” y “bases_de_datos”, fenómeno que hace conveniente considerar estos casos en las listas de equivalencias. La lista de equivalencias, al igual que la lista de palabras irrelevantes, es accesible y modificable manualmente desde el fichero de configuración del sistema.

2. Filtrado de tokens: Sobre el diccionario obtenido se descartan las palabras más comunes y las más raras del corpus. En esta aplicación se considera que un token es poco frecuente si aparece en menos de 10 documentos para intentar filtrar las palabras mal capturadas por el OCR. Análogamente, se estima que una palabra es demasiado común como para aportar al significado semántico de un texto si aparece en más del 70 % de documentos del corpus. Ambos valores han sido fijados tras un proceso de experimentación con ambos parámetros.

3. Representación BoW del corpus: Se calcula con Gensim, ya que esta es la repre- sentación de la que parte el modelo LDA.

4. Selección del número de tópicos del modelo LDA. Esta cifra la introduce el usuario directamente en el código del notebook para generar modelos a su antojo.

5. Entrenamiento del modelo LDA con el número de tópicos seleccionados. El modelo se genera con MALLET a través de su wrapper para Gensim utilizando el vocabulario limpio, el corpus en representación BoW y el número de tópicos seleccionado. Cuando se ha generado el modelo con MALLET, este debe ser transformado al formato de modelos LDA de Gensim para poder visualizarlo con PyLDAvis. Este modelo puede guardarse en el directorio models para visualizarse más adelante. Cada modelo guardado identifica el número de documentos del corpus y el número de tópicos con los que se ha generado.

51 Para la parte de visualización, se puede generar un nuevo modelo utilizando el procedimiento descrito o cargar algún modelo entrenado previamente que haya sido guardado. PyLDAvis básicamente toma el modelo elegido y lo procesa para graficarlo. La represen- tación gráfica generada es navegable y también puede exportarse a un fichero htmlquese guarda en el directorio models para consultarla cuando se desee. La Figura 3.18 representa un modelo de ejemplo que se interpreta de la siguiente manera:

Cada círculo representa un tópico.

El tamaño del círculo representa la distribución marginal del tópico.

La distancia entre círculos representa la distancia entre tópicos. Los tópicos más cercanos están más relacionados semánticamente, y viceversa.

A la derecha se muestran las palabras más relevantes del tópico seleccionado. Cada palabra va seguida de una doble barra, donde la barra azul representa la frecuencia del término en el corpus y la roja, la frecuencia del término en el tópico seleccionado.

Fig. 3.18. Ejemplo de modelo de tópicos representado con PyLDAvis

Cabe señalar que, si bien según las características de los notebooks Jupyter el usuario puede ejecutar las instrucciones o bloques de código en el orden que considere, en la Figura 3.19 se muestra el flujo coherente de ejecución para esta parte del sistema.

52 Fig. 3.19. Diagrama de flujo: Modelado de tópicos y visualización

3.2.3. Módulos de ayuda

Se ha reservado el directorio helpers para albergar módulos con recursos y funciones que pueden ser utilizadas desde distintos puntos del sistema. En estos módulos se encuentran los objetos de conexión con la base de datos y las funciones de lectura y escritura para la misma, así como funciones de ayuda que implementan procedimientos repetitivos útiles en distintas etapas del sistema.

53 4. INTERPRETACIÓN DE LOS RESULTADOS

Este capítulo se dedica a analizar las resultados proporcionados por el sistema implementado. También se describen los criterios de validez de los resultados y las técnicas de ajuste de parámetros del sistema.

4.1. Consideraciones iniciales

Antes de proceder con la interpretación de los resultados es importante destacar que estos no reflejan la caracterización del corpus completo, sino únicamente de una parte de los datos de entrenamiento. Esto es debido a la imposibilidad de recuperar el texto de la totalidad de los documentos referenciados en la base de datos. A continuación se listan los motivos de este fenómeno:

Un alto porcentaje de los pliegos son documentos PDF constituidos por imágenes digitalizadas, por lo que deben ser procesados por OCR, y en ocasiones más de una vez. Esto deriva en unos tiempos de extracción de textos muy elevados al ser el reconocimiento de caracteres un proceso computacionalmente pesado.

Los procesos de lematización, etiquetado gramatical y detección de N-gramas dan resultados satisfactorios pero también son costosos en el tiempo.

Para ajustarnos a las fechas de entrega establecidas y teniendo en consideración las limitaciones mencionadas, se tomó la determinación de acotar el dominio de caracteri- zación por tópicos a una sección del corpus determinada, sin olvidar que el sistema está preparado para abarcar la caracterización del corpus de contratación completo si se dispusiera del tiempo suficiente para obtener todos los textos de los pliegos técnicos. Para solventar este problema se optó por entrenar los modelos de tópicos con un corpus de textos de temática similar, y en este caso se considera que los pliegos similares a priori serán aquellos asociados a licitaciones clasificadas con el mismo código CPV (o con códigos emparentados en la misma jerarquía). Con esta idea en mente, se escogen para acotar el dominio de clasificación del sistema los códigos CPV asociados con la informática, la tecnología y las comunicaciones por considerarse los más relevantes en cuanto a su relación con la titulación cursada (códi- gos 48000000 y 72000000 y sus jerarquías subyacente). Actualmente este filtro por CPV proporciona un corpus de 10224 documentos.

54 4.2. Criterios de validación de resultados

El otro factor a tener en cuenta para la interpretación de los resultados es el están- dar de calidad al que deben adaptarse para considerarse válidos y concluir con que la caracterización es buena. Se estima que el corpus de pliegos sobre informática y comunicaciones consta al menos de 10000 documentos, tamaño para el que típicamente se consideran modelos de entre 10 y 20 tópicos. El número exacto de tópicos se obtendrá experimentalmente mediante la observación de modelos generados con parámetros diferentes hasta dar con una cantidad de tópicos para la que el modelo sea coherente. Se considerará que un modelo es coherente cuando:

La mayoría de tópicos están compuestos por palabras relacionadas semánticamente que permiten determinar con facilidad la temática a la que hacen referencia.

Los tópicos que hacen referencia a distintas temáticas estarán compuestos por palabras diferentes.

Existen pocos tópicos con la misma temática o con una temática indefinida.

Se hará uso de las representaciones proporcionadas por PyLDAvis para analizar los modelos y su adecuación a los criterios establecidos. El estudio gráfico consiste bási- camente en comprobar que los tópicos están separados entre sí, es decir, que no están concentrados en ciertos puntos del espacio de representación. Además, se comprueban las palabras que componen cada tópico para asegurar que son coherentes semánticamente las unas con las otras y que unidas pueden representar una temática. Este proceso se repite variando el número de tópicos hasta encontrar el modelo cuyos tópicos estén mejor distribuidos y definidos. Cabe destacar, no obstante, que se considerará preferible unmodelo cuyos tópicos representen temáticas bien definidas aunque su distribución espacial no sea la óptima. La Figura 4.1 muestra un modelo de tópicos generado con Gensim y graficado con PyLDAvis donde puede apreciarse que los tópicos están distribuidos por todo el espacio y hay pocos tópicos solapados. Por otra parte, puede apreciarse que el tópico seleccionado, el 12, está compuesto por palabras que en conjunto hacen referencia a la telefonía móvil y servicios asociados, por lo que consideramos que es un tópico bien definido. Para determinar si este modelo es válido, habría que comprobar la coherencia entre las palabras que componen el resto de tópicos y asegurar que los tópicos compuestos por palabras diferentes corresponden a temáticas distintas.

55 Fig. 4.1. Ejemplo de tópico coherente

Es común que en otras aplicaciones del modelo LDA se utilicen medidas de coherencia de tópicos en lugar de técnicas manuales para determinar si un modelo es bueno o malo. Para este proyecto se ha elegido obviar estos mecanismos en favor de la capacidad de síntesis humana del lenguaje debido a que, aparte de que la mayoría de herramientas disponibles están diseñadas para analizar modelos con palabras en inglés, es frecuente que las medidas de coherencia calculadas sean directamente contra-intuitivas con la apre- ciación humana [29].

4.3. Ajuste de modelos

En las primeras pruebas de validación de modelos es muy frecuente que ningún nú- mero de tópicos entre los umbrales establecidos proporcione resultados satisfactorios. En estos casos suele coincidir con que es complicado asociar los tópicos a temáticas, es decir, que están formados por palabras que están poco o nada relacionadas semánticamente entre ellas. Este fenómeno se produce porque el corpus no se ha limpiado lo suficiente, lo que implica que hay palabras irrelevantes, incorrectas o mal reconocidas en los procesos de obtención de textos que están alterando la efectividad de los modelos. En este punto en- tran en juego las listas de palabras irrelevantes y equivalencias presentes en el fichero de configuración del sistema. Como ya se ha mencionado, estas listas se utilizan parala limpieza del corpus previa al modelado y pueden actualizarse a voluntad.

56 Para mejorar la limpieza del corpus se ha realizado el siguiente proceso tantas veces como ha sido preciso hasta que los resultados se adecuaran a los criterios de validación anteriormente descritos:

1. Generar modelo con más de 100 tópicos sobre el corpus. Esto se hace porque con tales modelos es muy sencillo encontrar tópicos compuestos por palabras irrelevantes, incompletas o que no existen en español y, por lo tanto, están contaminando los modelos que se desea obtener. En definitiva, de esta forma es más fácil detectar los tokens que generan malos modelos. La Figura 4.2 representa un modelo de 100 tópicos generado para el proceso de limpieza del corpus. El tópico 74, como puede apreciarse, está compuesto por términos que no existen en castellano, muchos de ellos fácilmente identificables como palabras incompletas o mal deletreadas. Estas palabras incorrectas serían incluidas en las listas mencionadas para ser ignoradas en futuros análisis.

Fig. 4.2. Ejemplo de modelo de 100 tópicos

2. Anotar palabras a ignorar y/o corregir en las listas de palabras irrelevantes y equivalencias para no tenerlas en cuenta en los próximos modelos generados.

3. Generar y analizar modelos con una cantidad de tópicos dentro del rango deseable, en este caso 11 modelos de tópicos, empezando por 10 tópicos y finalizando por 20. En este proceso de análisis también pueden detectarse palabras muy genéricas que no aportan a la temática del tópico y es conveniente incluir en las listas de palabras a ignorar y equivalencias.

57 4.4. Resultados finales

Tras una limpieza exhaustiva del corpus con los mecanismos descritos en la sección anterior y un análisis de modelos en busca del número de tópicos óptimo, se ha llegado a un modelo que se adapta razonablemente bien a los criterios de aceptación descritos. En este caso se ha llegado a un modelo de 18 tópicos que se muestra completo en la Figura 4.3; las temáticas asociadas a cada tópico del modelo y las palabras más relevantes de cada uno se muestran en la Tabla 4.1.

Fig. 4.3. Modelo de tópicos óptimo

58 Tópico Temática Palabras más relevantes 1 Tópico genérico entorno, equipo, prueba, funcional, herramienta 2 Gestión de inci- incidencia, resolución, problema, atención, priori- dencias dad 3 Tópico genérico usuario, modulo, funcionalidad, integración, im- plantación 4 Protección de da- seguridad, tratamiento, protección, carácter, datos tos personales 5 Tópico genérico resolución, modelo, indicar, relación, carácter 6 Virtualización servidor, infraestructura, virtual, backup, monito- y copias de rización seguridad 7 Suministro de instalación, equipo, suministro, material, equipa- equipos miento 8 Educación e in- universidad, formación, curso, investigación, vestigación alumno 9 Difusión de con- contenido, web, portal, video, red social tenido a través de internet 10 Autenticación certificado, autenticidad, comprobar, integridad, y certificación firmar electrónica 11 Seguridad infor- verificación, código, seguro, rediris, análisis mática 12 Telefonía y redes red, comunicación, linea, móvil, terminal móviles 13 Defensa defensa, oficial, ejercito, seguridad, control 14 Transportes y puerto, vehículo, transporte, medio ambiente, esta- medio ambiente ción 15 Recopilación y cuestionario, encuesta, base de datos, muestra, es- análisis de datos tadístico 16 Software y licen- licencia, producto, software, actualización, sus- cias cripción 17 Responsabilidad apuesta, lotería, confidencial, propiedad intelec- y confidenciali- tual, seguridad dad 18 Sanidad salud, hospital, paciente, sanitario, sanidad

Tabla 4.1. Tópicos de caracterización del modelo óptimo

Como se mencionaba anteriormente, el corpus de entrenamiento empleado consta de 10224 documentos asociados a los códigos CPV 48000000 y 72000000, relacionados con

59 la informática y las telecomunicaciones. En los primeros experimentos con el corpus en crudo y en versiones del mismo con distinto nivel de limpieza se observó que los modelos generados estaban constituidos por tópicos imprecisos y demasiado genéricos, como estaba previsto por los motivos señalados en secciones anteriores. En consecuencia, fue necesaria la repetición del mecanismo de limpieza y análisis descrito un total de 6 veces para conseguir el modelo aceptado que se muestra en la Figura 4.3. El proceso de limpieza completo ha permitido identificar un total de 2457 palabras irrelevantes y384 equivalencias, y tras su eliminación del vocabulario inicial, de 154604 palabras, y el filtrado posterior de términos demasiado comunes y muy poco frecuentes se ha llegado a un vocabulario final de 17414 tokens. La Figura 4.4 y la Tabla 4.2 muestran el modelode18 tópicos generado en el primer experimento con el corpus inalterado para ejemplificar la importancia de la limpieza de los datos de entrenamiento a la hora de entrenar modelos de tópicos. Comparado con el modelo elegido, este tiene peor disposición espacial, como se puede apreciarse por la mayor cantidad de tópicos solapados. Por otra parte, se puede observar que casi la mitad de los tópicos del modelo son genéricos, aparte de que hay tópicos diferentes que hacen referencia al mismo tema (tópicos 7 y 12) y tópicos que combinan dos temáticas no relacionadas que bien podrían estar separadas en tópicos distintos (tópico 13). Además, los tópicos aparecen compuestos por palabras demasiado genéricas en un corpus de ámbito tecnológico. Respecto al por qué de la elección del modelo de 18 tópicos sobre los otros generados en la última iteración del proceso de limpieza y análisis, se observó que los modelos con pocos tópicos generaban tópicos demasiado ambiguos. A medida que el número de tópi- cos iba aumentando, los modelos presentaban características más favorables hasta llegar a un número de tópicos que, una vez rebasado, proporcionaba modelos sobreajustados o overfitted que daban lugar a tópicos repetidos. En este caso, como se ha visto, el número de tópicos que marca el punto de inflexión entre modelos ambiguos y sobreajustados es 18. Como ejemplos de este fenómeno se adjuntan la Figura 4.5 y la Tabla 4.3, donde aparece el modelo de 10 tópicos generado en la última iteración del análisis de modelos. La Figura 4.6 y la Tabla 4.4 muestran a su homólogo de 20 tópicos. Aunque su disposición espacial puede considerarse aceptable al haber tópicos distribuidos en los 4 cuadrantes de la gráfica, puede apreciarse que el modelo de 10 tópicos de la Figura 4.5 consta de tópicos que hacen referencia a más de un tema (tópicos 6, 7 y 9) y 3 tópicos genéricos (tópicos 1, 3 y 5): más de la mitad de los tópicos del modelo son ambiguos, por lo que no se satisfacen los criterios de aceptación descritos. De manera análoga puede analizarse el modelo de 20 tópicos de la Figura 4.6. Espa- cialmente puede considerarse bien distribuido y, además, proporciona tópicos asociados a temáticas no identificadas por modelos de menos tópicos (tópico 8). Sin embargo, elso- breajuste produce que haya tópicos repetidos como resultado del desdoblamiento de los mismos (tópicos 5 y 14), además de que en este caso ha habido tópicos que en lugar de desdoblarse se han fusionado (tópico 15).

60 Volviendo al modelo considerado óptimo (Figura 4.3, Tabla 4.1), se puede comprobar que los tópicos están distribuidos por el espacio disponible sin que exista mucho solapamiento entre ellos, por lo que el criterio visual se satisface. Por otra parte, tras analizar los términos que componen los tópicos se obtienen 15 tópicos con temática bien definida y 3 de temática genérica. Respecto a los tópicos gené- ricos, suele ser de esperar que existan tópicos cuyas palabras no estén lo suficientemente relacionadas como para definir una temática específica. Al haber un número reducido de tópicos genéricos frente a la cantidad de tópicos bien representados se satisface otro de los criterios de aceptación de modelos. Finalmente, respecto al contenido semántico de cada tópico, puede apreciarse que las temáticas identificadas son muy diferentes entre sí a pesar de haber utilizado uncorpus limitado a un sector específico. Destacamos, sin embargo, la presencia de varios tópicos relacionados con la seguridad informática (tópicos 4, 10, 11 y 17), que aún haciendo referencia a una misma disciplina se han podido configurar como tópicos diferentes bien definidos gracias a su composición de palabras. En consecuencia, el último criteriode validación de modelos también se satisface. Es por esto que el modelo elegido se adapta a todos los criterios especificados y se considera óptimo para el corpus utilizado. Respecto a la interpretación que puede sa- carse del mismo, se destaca la presencia de la seguridad, la virtualización de equipos, la telefonía móvil, la difusión de contenido a través de la web y el análisis de datos en prácti- camente todos los modelos de tópicos generados durante el estudio de resultados. Dichas disciplinas están presentes tanto en el día a día, como es el caso de la telefonía móvil, la seguridad y la difusión de contenido, como en el mundo laboral, donde la virtualiza- ción, la seguridad y el análisis de datos son conocimientos ampliamente demandados y muy valorados en los profesionales del sector informático. De esto podemos deducir que, respecto a tecnología, el Sector Público está demandando soluciones tecnológicas que actualmente están en auge y, en consecuencia, buscan no quedarse estancados en el pasado para proporcionar mejores servicios al ciudadano. Esta afirmación se ve afianzada por la presencia de tópicos dedicados a educación, sanidad, defensa y transporte, lo que implica que parte de los servicios tecnológicos que se solicitan en las licitaciones van destinados a la mejora y modernización de servicios públicos básicos.

61 Fig. 4.4. Modelo de 18 tópicos con corpus sin limpiar

62 Tópico Temática Palabras más relevantes 1 Gestión de inci- incidencia, nivel, tiempo, usuario, equipo dencias 2 Tópico genérico desarrollo, entorno, funcional, prueba, integración 3 Tópico genérico declaración, condición, teléfono, fecha, carácter 4 Tópico genérico usuario, permitir, universidad, acceso, formación 5 Virtualización servidor, red, infraestructura, configuración, alma- y copias de cenamiento seguridad 6 Protección de da- tratamiento, de seguridad, carácter, protección, ac- tos ceso 7 Seguridad infor- análisis, informe, de seguridad, herramienta, equi- mática po 8 Tópico genérico equipo, experiencia, conocimiento, informático, apoyo 9 Tópico genérico electrónico, permitir, informático, registro, fecha, copia 10 Suministro de equipo, control, material, equipamiento, repara- equipos ción 11 Difusión de con- contenido, web, portal, desarrollo, diseño tenido a través de internet 12 Seguridad infor- verificación, código, fecha, seguro, observación mática 13 Telefonía y reco- móvil, linea, terminal, campo, fichero pilación y análisis de datos 14 Tópico genérico correo, equipo, tecnología, universal, producto 15 Transportes y puerto, vehículo, portuario, transporte, autoridad medio ambiente 16 Software y licen- licencia, producto, software, actualización, enter- cias prise 17 Sanidad salud, hospital, paciente, sanitario, integración 18 Tópico genérico condición, venta, medio, aeropuerto, informar

Tabla 4.2. Tópicos de caracterización de corpus sin limpiar

63 Fig. 4.5. Modelo impreciso de 10 tópicos

64 Tópico Temática Palabras más relevantes 1 Tópico genérico equipo, entorno, incidencia, conocimiento, herramienta 2 Hardware y co- equipo, servidor, incidencia, red, instalación pias de seguridad 3 Tópico genérico electrónico, usuario, módulo, registro, integración 4 Protección de da- seguridad, correo, tratamiento, carácter, protección tos 5 Tópico genérico carácter, teléfono, electrónico, resolución, relación 6 Educación y difu- contenido, web, universidad, usuario, portal sión de contenido a través de internet 7 Suministro de instalación, equipo, material, suministro, puerto equipos y transporte 8 Recopilación y fichero, campo, formato, base de datos, cuestiona- análisis de datos rio 9 Seguridad infor- verificación, código, seguro, móvil, linea mática y telefonía móvil 10 Software y licen- licencia, software, producto, actualización, oracle cias

Tabla 4.3. Tópicos de caracterización de modelo impreciso de 10 tópicos

65 Fig. 4.6. Ejemplo: Modelo sobreajustado de 20 tópicos

66 Tópico Temática Palabras más relevantes 1 Tópico genérico equipo, conocimiento, calidad, indicador, recurso 2 Tópico genérico entorno, prueba, funcional, integración, usuario 3 Tópico genérico resolución, modelo, indicar, electrónico, universal 4 Gestión de inci- incidencia, resolución, problema, prioridad, aten- dencias ción 5 Seguridad infor- seguridad, análisis, informe, herramienta, implan- mática tación 6 Protección de da- seguridad, tratamiento, carácter, protección, acce- tos so 7 Virtualización servidor, infraestructura, virtual, monitorización, y copias de backup seguridad 8 Contabilidad nómina, contable, ingreso, calculo, contabilidad 9 Autenticación registro, certificado, autenticidad, acceso, compro- y certificación bar electrónica 10 Suministro de instalación, equipo, material, obra, equipamiento equipos 11 Difusión de con- contenido, web, portal, diseño, video tenido a través de internet 12 Responsabilidad apuesta, lotería, responsabilidad, protección, con- y confidenciali- fidencialidad dad 13 Telefonía y redes red, comunicación, acceso, linea, móvil móviles 14 Seguridad infor- verificación, código, seguro, rediris, análisis mática 15 Sanidad y recopi- sanidad, hospital, paciente, encuesta, base de datos lación y análisis de datos 16 Software y licen- licencia, producto, software, renovación, suscrip- cias ción 17 Tópico genérico campo, fichero, digitalización, venta, formato 18 Transporte y me- puerto, geográfico, transporte, medio ambiente, dio ambiente mapa 19 Educación, inves- universidad, curso, formación, empleo, investiga- tigación y cultura ción 20 Defensa oficial, defensa, logístico, ejército, armado

Tabla 4.4. Tópicos de caracterización de modelo sobreajustado de 20 tópicos 67 5. MARCO REGULADOR

En este capítulo se abordan distintos aspectos de la legislación aplicable a la imple- mentación de esta solución en un entorno de producción, así como los estándares técnicos y licencias a los que están sujetas las herramientas utilizadas en el desarrollo del proyecto. Respecto a la legislación aplicable, la más relevante en este trabajo es la relativa a protección de datos personales. Todos los datos tratados por el sistema son recabados de la Plataforma de Contratación del Sector Público, donde dichos datos son publicados por los Órganos de Contratación para dar publicidad sobre las licitaciones y toda la información relativa que se estime relevante. Desde el apartado “Protección de datos” de la Plataforma puede leerse:

“La responsabilidad de los datos de carácter personal incluidos en el perfil del contratante por los Órganos de Contratación o de Asistencia a la Contratación, corresponde al Órgano que realiza la publicación tanto de los anuncios, como de todos aquellos documentos a los que se refiere el artículo 63 de la Ley9/2017, de 8 de noviembre, de Contratos del Sector Público.”

En otras palabras, la responsabilidad sobre los datos tratados que pudieran ser de ca- rácter personal reside en los Órganos que los han hecho públicos. Además, las técnicas de procesamiento del corpus de caracterización están diseñadas explícitamente para descartar los datos personales en la medida de lo posible, por lo que en ningún caso se estaría trabajando con datos protegidos por la Ley Orgánica 3/2018, de 5 de diciembre, de Pro- tección de Datos Personales y garantía de los derechos digitales [30]. Aparte de las cuestiones de protección de datos, el trabajo debe cumplir las condiciones y términos de uso de las herramientas software utilizadas, que se discuten a continua- ción. Se presenta la Tabla 5.1, que muestra las tecnologías utilizadas y sus licencias de software libre asociadas, y la Tabla 5.2, que ilustra las características de cada licencia involucrada:

68 Licencia Software Apache License v2.0 NLTK

LibrAIry

Apache Tika

Tesseract OCR

Mallet

MIT License TextBlob

pyMySQL

BeautifulSoup

GNU GPL Sistema Operativo Linux Ubuntu 18.04

MySQL

GNU LGPL Gensim

BSD PyLDAvis

Lxml

Jupyter

Python Software Foundation License Lenguaje de programación Python

Tabla 5.1. Licencias de software libre presentes en la solución

69 Licencia Permisos Limitaciones Condiciones Apache License v2.0 Uso comercial

Modificación Uso bajo marca propia Notificar cambio de estado

Distribución Responsabilidad Incluir nota de licencia y copyright Uso patentado Garantías

Uso privado

MIT License Uso comercial Responsabilidad Incluir nota de licencia y copyright Modificación Garantías

Distribución

Uso privado

GNU GPL Uso comercial Responsabilidad Notificar cambio de estado

Modificación Garantías Incluir nota de licencia y copyright Distribución Misma licencia Uso patentado Revelar fuente Uso privado

GNU LGPL Uso comercial Responsabilidad Notificar cambio de estado

Modificación Garantías Incluir nota de licencia y copyright Distribución Misma licencia, salvo mo- Uso patentado dificación en librería Uso privado Revelar fuente

BSD Uso comercial Responsabilidad Incluir nota de licencia y copyright Modificación Garantías

Distribución

Uso privado

Python Software Foundation License Uso comercial Responsabilidad Incluir nota de licencia y copyright Modificación Garantías

Distribución

Uso privado

Tabla 5.2. Caracterísisticas de licencias de software libre

La totalidad de las herramientas utilizadas son de software libre y han sido utilizadas con su funcionalidad tal cual es, sin modificarla. Como software de estas características, su utilización es gratuita y libre en aplicaciones de terceros, y a la vista de las anteriores tablas se concluye que no se ha violado ningún término ni condición de uso.

70 6. MARCO SOCIO-ECONÓMICO

El contenido de este capitulo se reserva para discutir las distintas implicaciones de carácter socio-económico derivadas de la implantación del proyecto desarrollado en un entorno profesional de producción. Hoy en día, la tecnología es una parte indispensable en casi todos los aspectos de nues- tras vidas y es importante que siga desarrollándose para intentar satisfacer las crecientes necesidades de unos usuarios cada vez más exigentes. La masificación de dispositivos conectados que generan datos constantemente hace posible conocer a los consumidores. Además, gracias al auge de las redes sociales y su papel como “tablón de anuncios” este conocimiento de los usuarios es más profundo y detallado, puesto que pueden extraerse conclusiones analizando cómo éstos interactúan en estos medios de forma natural, haciendo uso del lenguaje para ello. En definitiva, se generan infinidad de datos constantemente y muchos de ellos contienen información lingüística. Por lo tanto, las entidades interesadas en ofrecer un servicio pueden hacer uso de esta información para reorientar en qué invierten y asegurar así que sus inversiones propor- cionarán beneficios a futuro al satisfacer necesidades reales. Muchas entidades privadas han sabido ver el potencial de la interpretación de estos datos y, en muchos casos, ha sido la clave de su éxito. De manera análoga, el procesamiento automático del que es capaz la tecnología reporta grandes beneficios respecto de estos objetivos, puesto que la infor- mación relevante se obtiene más rápidamente y la toma de decisiones estratégicas es más ágil, aparte de que se ahorra en costes de análisis manual. El Gobierno de España, por su parte, también parece ser consciente de la importancia del análisis de datos, en especial de análisis del lenguaje, y los beneficios derivados de su utilización. Para desarrollar este campo se ha puesto en marcha el Plan de Impulso de las Tecnologías del Lenguaje54 con el objetivo de fomentar el desarrollo del procesamiento del lenguaje natural, la traducción automática y los sistemas conversacionales en España, especialmente en lengua española y lenguas cooficiales. Este Plan pone foco en la Ad- ministración Electrónica como motor de la industria del lenguaje para recopilar datos de interés y dedicarlos en la inversión directa en mejoras para el Sector Público. En el ámbito de la Contratación Pública Electrónica, donde se enmarca este proyecto, el análisis de datos lingüísticos de contratación y la automatización de tratamiento de datos reporta resultados valiosos a varios niveles. A nivel social, se mejoraría la transparencia de los Gobiernos para con los ciudadanos, pues conociendo cómo se configura el mercado de contratación se podrían tomar decisiones respecto a inversión de gasto público basadas en datos reales y adaptadas a las condiciones del mercado. Por otra parte, la digitalización de la Contratación Pública favo-

54https://www.plantl.gob.es/Paginas/index.aspx

71 rece a todas las partes involucradas, tanto a organizaciones contratantes como a entidades licitadoras, al simplificar los procesos y las cargas burocráticas propios de la Contratación ordinaria; esto se traduce en una disminución de los costes asociados a los procesos de contratación. Además, para las partes licitadoras se fomenta un entorno de competencia sana al mejorar el acceso a las ofertas por parte de entidades grandes y pequeñas. Esto último propicia un mayor interés por la innovación por parte de los participantes en los concursos públicos. A nivel económico, la automatización de procesos de tratamiento y análisis de datos suponen una disminución de costes de diversa naturaleza respecto al análisis manual de información. Por una parte, se reducen drásticamente los costes económicos y temporales derivados de disponer de operadores que analicen los datos manualmente. Por otro lado, la utilización de máquinas supone una mejora considerable de la eficiencia en estas tareas, minimizando los tiempos de análisis y maximizando la cantidad de datos analizados. Este ahorro permite optimizar los grandes beneficios económicos que reporta la Contratación Pública, que recordemos que supone aproximadamente un 20 % del Producto Interior Bruto en España. En definitiva, la aplicación de este proyecto en su contexto inicial, la Contratación electrónica, reportaría beneficios tanto a nivel social como a nivel económico. A suvez, el tipo de proyecto y la clase de análisis que se hace en él hacen que pueda encajar dentro de los objetivos marcados por el Plan de Impulso de las Tecnologías del Lenguaje y, por lo tanto, resulta una propuesta consistente con la Agenda Digital española. Sus resultados podrían aplicarse de las siguientes maneras (entre otras) y podrían reportar beneficios tanto a entidades públicas como privadas que busquen suministrar algún servicio para el Sector Público:

Podría usarse por empresas para que puedan localizar licitaciones de su interés.

La Administración Pública podría buscar ejecutores potenciales de los contratos que realiza.

Los gestores de compra pública podría extraer información adicional de seguimien- to de los procesos de adjudicación, de ejecución presupuestaria, sobre distribución geográfica o sobre temáticas en las licitaciones.

. No obstante, los fundamentos del trabajo y los resultados del mismo pueden ser adaptados a otros entornos empresariales para multitud de aplicaciones con un impacto similar.

72 7. PRESUPUESTO Y PLANIFICACIÓN

Este capítulo se reserva para desglosar el presupuesto asociado a la realización del proyecto y la planificación temporal de la elaboración del mismo.

7.1. Planificación temporal

Este apartado se dedica a mostrar la planificación temporal de las tareas de las que consta el proyecto. Se considerará la planificación inicial y se contrastará con los tiempos reales de ejecución, indicando los motivos de las posibles desviaciones entre ambas.

7.1.1. Planificación inicial

La fecha de comienzo del proyecto se fijó para septiembre de 2018 y se estimó su finalización para junio de 2019, fecha que coincide con la entrega de la memoriadel proyecto para la segunda sesión de defensa para el curso 2018/19 (17 de junio de 2019). La Tabla 7.1 plantea la planificación temporal por tareas en este intervalo de tiempo. Cabe destacar que la planificación de tareas considera una baja disponibilidad temporal surgida de la situación de compaginar la elaboración del Trabajo de Fin de Grado con una jornada laboral completa y tiempos elevados en desplazamientos.

Tarea Fecha inicio Fecha fin Horas de trabajo Planteamiento del trabajo, objetivos y planificación inicial 14/09/18 20/09/18 8 horas Formación en fundamentos teóricos y tecnologías 21/09/18 14/10/18 40 horas Diseño del sistema 15/10/18 28/10/18 12 horas Estudio de métodos de obtención de datos de entrenamiento 29/10/18 04/11/18 8 horas Análisis de dato en crudo y diseño del modelo de datos 05/11/18 18/11/18 16 horas Desarrollo de código de obtención, estructuración y alma- 19/11/18 31/01/19 200 horas cenamiento de datos de entrenamiento Estudio de métodos de extracción de texto 01/02/19 10/02/19 12 horas Desarrollo de código de extracción de textos 11/02/19 14/04/19 180 horas Desarrollo de código para tareas NLP 15/04/19 16/04/19 16 horas Desarrollo de código para modelado de tópicos 17/04/19 17/04/19 4 horas Desarrollo de código de visualización de modelos 17/04/19 17/04/19 4 horas Pruebas y ajuste de variables de caracterización por tópicos 18/04/19 15/05/19 80 horas Documentación 01/02/19 17/06/19 200 horas Seguimiento y revisión de entregables 14/09/18 17/06/19 40 horas

Tabla 7.1. Planificación inicial

73 7.1.2. Duración real

El desarrollo del proyecto fluyó acorde a la planificación sin desviaciones destacables hasta que a finales de febrero de 2019 la Plataforma incluyó el apartado “Datos abiertos” en su página web. Hasta ese momento, la obtención de los datos de contratación solo podía hacerse mediante web scraping basado en mecanismos de automatización de nave- gadores web capaces de renderizar código JavaScript55 utilizando las vistas del detalle de las licitaciones como recursos a analizar, y este fue el enfoque con que se implementaron las tareas de construcción y llenado de la base de datos en primera instancia. La inclusión de los datos de contratación como ficheros XML con estructura fija suponía una mejora sustancial de la calidad de los datos, el rendimiento y la rapidez de ejecución de las tareas de obtención del corpus de contratación con respecto a la primera aproximación, por lo que se optó por replantear completamente el modelo de datos y los métodos de extracción de información de la Plataforma en detrimento de la planificación inicial. Esta alteración del diseño derivaría en un retraso de aproximadamente 200 horas de trabajo, cantidad correspondiente a la realización duplicada de las tareas de análisis de dato en crudo, construcción del modelo relacional e implementación de las nuevas lógicas de obtención de licitaciones. Esta decisión implicó la imposibilidad de ceñirse a la fecha límite establecida para aplazarla a septiembre de 2019, momento de entrega de la memoria para la última sesión de defensa de Trabajos de Fin de Grado (23 de septiembre de 2019). La Tabla 7.2 muestra la duración real de la ejecución del proyecto derivada del mencionado suceso. Para mostrar gráficamente las duración y el solapamiento de las tarea en las planifi- caciones inicial y final se recurre a la Figura 7.1, donde se pueden ver sendos diagramas de Gantt. El diagrama superior representa la planificación inicial y el inferior, la real. Los colores utilizados para señalar cada tarea se interpretan de la siguiente manera:

Azul: Tarea planificada originalmente.

Verde: Tarea resuelta según planificación inicial.

Rojo: Tareas inesperadas o no resueltas según planificación inicial.

7.2. Presupuesto

Para la elaboración del presupuesto se consideran los costes en recursos humanos y aspectos materiales, desarrollados en sendos apartados.

55https://www.javascript.com/

74 Tarea Fecha inicio Fecha fin Horas de trabajo Planteamiento del trabajo, objetivos y planificación inicial 14/09/18 20/09/18 8 horas Formación en fundamentos teóricos y tecnologías 21/09/18 14/10/18 40 horas Diseño del sistema 15/10/18 28/10/18 12 horas Estudio de métodos de obtención de datos de entrenamiento 29/10/18 04/11/18 8 horas Análisis de dato en crudo y diseño del modelo de datos 05/11/18 18/11/18 16 horas Desarrollo de código de obtención, estructuración y alma- 19/11/18 31/01/19 200 horas cenamiento de datos de entrenamiento Estudio de métodos de extracción de texto 01/02/19 10/02/19 12 horas Desarrollo de código de extracción de textos 11/02/19 16/06/19 180 horas Estudio de métodos de obtención de datos de entrenamiento 23/02/19 24/02/19 8 horas Análisis de dato en crudo y diseño del modelo de datos 25/02/19 28/02/19 16 horas Desarrollo de código de obtención, estructuración y alma- 01/03/19 14/04/19 200 horas cenamiento de datos de entrenamiento Desarrollo de código para tareas NLP 17/06/19 23/06/19 16 horas Desarrollo de código para modelado de tópicos 24/06/19 26/06/19 4 horas Desarrollo de código de visualización de modelos 27/06/19 30/06/19 4 horas Pruebas y ajuste de variables de caracterización por tópicos 01/07/19 31/08/19 80 horas Documentación 01/02/19 23/09/19 200 horas Seguimiento y revisión de entregables 14/09/18 23/09/19 40 horas

Tabla 7.2. Planificación real

7.2.1. Recursos humanos

Esta parte del presupuesto aborda los costes asociados a la remuneración del trabajo de los profesionales involucrados en el proyecto. En este caso, se consideran los servicios de un desarrollador junior para la parte de diseño e implementación y un analista senior para tareas de gestión. En primer lugar, se debe identificar el perfil profesional encargado de cada tarea planificada. Esta información se plasma en la Tabla 7.3. Se hace uso de las estimaciones de planificación inicial (Tabla 7.1) porque se considera que la circunstancia que produjo el retraso de la ejecución respecto de la planificación fue muy fortuita y es difícil que vuelva a ocurrir en un futuro cercano; las estructuras estandarizadas de datos de contratación y sus métodos de redifusión se han hecho públicos y accesibles recientemente y es improbable que dejen de estar vigentes en los meses venideros.

75 Tarea Profesional Horas de trabajo responsable Planteamiento del trabajo, objetivos y planificación inicial Analista 8 horas Formación en fundamentos teóricos y tecnologías Desarrollador 40 horas Diseño del sistema Desarrollador 12 horas Estudio de métodos de obtención de datos de entrenamiento Desarrollador 8 horas Análisis de dato en crudo y diseño del modelo de datos Desarrollador 16 horas Desarrollo de código de obtención, estructuración y alma- Desarrollador 200 horas cenamiento de datos de entrenamiento Estudio de métodos de extracción de texto Desarrollador 12 horas Desarrollo de código de extracción de textos Desarrollador 180 horas Desarrollo de código para tareas NLP Desarrollador 16 horas Desarrollo de código para modelado de tópicos Desarrollador 4 horas Desarrollo de código de visualización de modelos Desarrollador 4 horas Pruebas y ajuste de variables de caracterización por tópicos Desarrollador 80 horas Documentación Desarrollador 200 horas Seguimiento y revisión de entregables Analista 40 horas Total - 820 horas

Tabla 7.3. Estimación de horas de trabajo

Una vez estimados los tiempos de trabajo para cada profesional involucrado, se presenta la Tabla 7.4 con el presupuesto final. Los salarios brutos anuales reflejados endicha tabla se han elegido como representación del sueldo medio que actualmente se está pa- gando por estos perfiles profesionales.

Perfil profesional Horas trabajadas Salario bruto anual Salario bruto por hora Salario a percibir Analista senior 48 horas 40000 e 20.83 e/hora 999.84 e Desarrollador junior 772 horas 25000 e 13.02 e/hora 10051.44 e Total - - - 11051.28 e

Tabla 7.4. Presupuesto final de recursos humanos

7.2.2. Recursos materiales

Esta parte del presupuesto aborda los costes de los elementos materiales utilizados en el proyecto. Se tendrán en cuenta los costes en elementos hardware, herramientas software, material fungible de oficina y costes indirectos. En la Tabla 7.5 se muestra el presupuesto de los dispositivos hardware con lo que se ha trabajado y la Tabla 7.6 resume los costes indirectos derivados de la realización del proyecto.

76 Elemento Coste Ordenador portátil 500 e Monitor 127 e Total 627 e

Tabla 7.5. Presupuesto de dispositivos hardware

Elemento Coste Electricidad 100 e ADSL 290 e Total 390 e

Tabla 7.6. Presupuesto de costes indirectos

Todas la herramientas software y programas utilizados son de uso gratuito y su coste total es de 0 e, motivo por el cual se obvia la elaboración de un presupuesto específico para estos elementos. Combinando la información de costes de las Tablas 7.5 y 7.6 y añadiendo los costes en material de oficina, el presupuesto resultante es el siguiente (Tabla 7.7):

Elemento Coste Dispositivos hardware 627 e Herramientas software 0 e Material fungible de oficina 300 e Costes indirectos 390 e Total 1317 e

Tabla 7.7. Presupuesto final de recursos materiales

7.2.3. Presupuesto final

Se combinan los costes en recursos humanos y recursos materiales mostrados en las Tablas 7.4 y 7.7 para presentar el coste total de la elaboración del proyecto en la Tabla 7.8. A partir de estos costes, se establece el presupuesto final en la Tabla 7.9, impuestos incluidos. Concepto Importe Recursos humanos 11051.28 e Recursos materiales 1327 e Total 12368.28 e

Tabla 7.8. Costes totales

77 Concepto Importe Total sin IVA (20 %) 12368.28 e IVA (21 %) 2597.34 e Total 14965.62 e

Tabla 7.9. Presupuesto final

Se concluye con que la elaboración del proyecto supone un coste estimado que as- ciende a la cantidad de 14965.62 e.

78 Fig. 7.1. Diagramas de Gantt: Planificación inicial y duración real del proyecto 79 8. CONCLUSIONES Y TRABAJOS FUTUROS

A la vista del trabajo realizado y los resultados que proporciona se puede declarar que los objetivos establecidos al inicio de su desarrollo han sido satisfechos: se ha logrado implementar un sistema completo capaz de capturar, estructurar, limpiar y categorizar los datos de contratación de la Plataforma de Contratación del Sector Público. El sistema se ha diseñado manteniendo las distintas fases del procesamiento de datos en bloques aislados, por lo que cualquier modificación de una funcionalidad puede ser fácilmente llevada a la práctica sin repercutir en los demás componentes. Este rasgo es potenciado por la utilización de software libre y gratuito, lo que a su vez permite hacer uso del sistema con el 100 % de sus funcionalidades e incluso seguir contribuyendo a su desarrollo sin restricciones por costes en licencias. El desarrollo del sistema ha fluido por las fases primeramente definidas en la sección de objetivos como metas secundarias para la consecución del objetivo principal: Tras en estudio previo de las estructuras de datos de contratación y las diferentes herramientas con las que se podrían obtener se ha sido capaz de crear y poblar una base de datos de contra- tación, obtener y procesar los pliegos técnicos para generar un corpus de entrenamiento, y entrenar y visualizar modelos de tópicos entrenados con dicho corpus. Respecto a los resultados de la caracterización en sí, se presenta la Tabla 8.1 con una estimación del importe total asociado a cada tópico detectado en el modelo para ejemplificar el gran impacto económico que supone la Contratación Pública enEspaña incluso estando en esta aplicación limitada a un único sector. En dicha Tabla se puede apreciar que la Contratación Pública limitada al sector tec- nológico genera una riqueza de 4629248358,9 euros. Por su parte, los servicios que más riqueza generan son la ciber seguridad en sus distintas vertientes (protección de datos, certificación, confidencialidad, ...), el software y la telefonía móvil. Respecto a servicios públicos, destaca la fuerte inversión en sanidad sobre el resto de servicios públicos presentes en la caracterización. A la vista de estos resultados, queda claro que, en general, los servicios relacionados con la informática y las comunicaciones que los organismos de contratación están demandado en las licitaciones y que más riqueza generan son disciplinas tecnológicas punteras con las que se pretende modernizar al Sector Público para mejorar los servicios al ciudadano. No obstante, estas conclusiones solo aplican al sector informático y no tendrían por qué representar al Sector Público en su totalidad, por lo que sería preciso descargar el corpus completo y experimentar con él para extraer el modelo que sí sea capaz de caracterizar la Contratación al completo. En cuanto al planteamiento de una continuación del proyecto a partir del punto actual, se consideran tanto mejoras como trabajos futuros. Entre las mejoras, destacamos las

80 Tópico Temática Importe estimado 1 Tópico genérico 569167045.00 e 2 Gestión de incidencias 255992429.41 e 3 Tópico genérico 149081925.47 e 4 Protección de datos 582989743.82 e 5 Tópico genérico 468764264.45 e 6 Virtualización y copias de seguridad 89659466.90 e 7 Suministro de equipos 257236190.29 e 8 Educación e investigación 50340251.20 e 9 Difusión de contenido a través de internet 118429533.13 e 10 Autenticación y certificación electrónica 335079970.02 e 11 Seguridad informática 118289047.93 e 12 Telefonía y redes móviles 261457356.73 e 13 Defensa 113435209.25 e 14 Transportes y medio ambiente 87922480.48 e 15 Recopilación y análisis de datos 68808206.33 e 16 Software y licencias 723824085.61 e 17 Responsabilidad y confidencialidad 127882436.28 e 18 Sanidad 250888716.60 e Total - 4629248358,9 e

Tabla 8.1. Estimación de importe total por tópico siguientes:

Adaptación del código a la programación orientada a objetos para mejorar el mantenimiento del sistema.

Repasar la implementación de las fases del programa que realicen actividades de cómputo pesado para tratar de mejorar el rendimiento y, de esta forma, poder lograr resultados similares a los obtenidos de manera más rápida. Dentro de esta línea de mejora entrarían la paralelización de procedimientos de descarga y preprocesado de textos.

Mejorar los criterios de selección de documentos a descargar. Podría plantearse permitir filtrar por más de un CPV o permitir filtros por fecha, importe ocualquier otro campo.

Visor mixto entre tópicos y metadatos asociados a las licitaciones, ya que estos datos están siendo almacenados y podrían extraerse conclusiones valiosas de ellos.

De entre los posibles trabajos futuros que pueden derivarse del sistema, se mencionan los que se estima que pueden resultar de más ayuda a los usuarios de la Plataforma de Contratación del Sector Público:

81 Como principal trabajo se propone el análisis completo del corpus de contratación para poder caracterizarlo en su totalidad.

Puede ampliarse la funcionalidad del sistema para que pueda analizar pliegos en otros idiomas o implementarse mecanismos de obtención de pliegos adaptados a dominios no considerados en la versión actual.

De cara a otros análisis de los datos de contratación, la caracterización por temáticas del Sector Público podría complementarse con otras variables como la localización geográfica y los importes de adjudicación. Estas variables podrían proporcionar in- formación relevante sobre Contratación, pudiendo determinar qué sectores están más demandados según la región y cuáles generan más riqueza. Esta extensión de funcionalidad no implicaría costes elevados de implementación gracias a que el sistema está preparado para almacenar toda la información disponible de licitaciones y no sólo la mínima indispensable para el análisis por temática.

La caracterización podría implementarse como base en un sistema de recomenda- ción de licitaciones que sugiera ofertas a los usuarios en función de su actividad en la Plataforma. Gracias a este sistema, las entidades licitadoras encontrarían ofertas mejor adaptadas a los servicios que suelen ofrecer, optimizando los procesos de búsqueda y análisis de licitaciones.

Se podría complementar la caracterización con los resultados de adjudicación de licitaciones para implementar un sistema que recomiende candidatos a los organismos contratantes en base al historial de adjudicatarios de una temática determinada. De esta forma, los organismos públicos encontrarían licitadores apropiados para trabajos determinados basándose en datos reales, fomentando la igualdad de oportunidades entre los candidatos y agilizando los procesos de adjudicación.

Se podría considerar la integración del sistema en plataformas de computación en la nube, como Amazon Web Services (AWS)56, Google Cloud Platform (GCP)57 o Microsoft Azure58. Estas plataformas proporcionan capacidades de cómputo muy competentes, actualmente están en auge y son muy demandadas en el sector infor- mático, lo que podría suponer un gran avance para la digitalización de la Contrata- ción Pública.

56https://aws.amazon.com/es/ 57https://cloud.google.com/ 58https://azure.microsoft.com/es-es/

82 BIBLIOGRAFÍA

[1] O. de Contratación Pública, Planes específicos de la Agenda Digital para España. [En línea]. Disponible en: http://www.agendadigital.gob.es/planes- actuaciones / Bibliotecaplanesconsolidados / Planes - Especificos - ADpE.pdf (Acceso: 19-03-2019). [2] PAe, Estrategias. [En línea]. Disponible en: https://administracionelectronica. gob.es/pae_Home/pae_Estrategias.html (Acceso: 19-03-2019). [3] O. de Contratación Pública, ¿Qué es el ObCP? [En línea]. Disponible en: http: //www.obcp.es (Acceso: 19-03-2019). [4] España, ‘Ley 9/2017 de 8 de noviembre, de Contratos del Sector Público’, BOE, n.o 272, [En línea]. Disponible en: https://www.boe.es/eli/es/l/2017/11/ 08/9/con (Acceso: 16-07-2019). [5] D. M. Blei, A. Y. Ng y M. I. Jordan, ‘Latent Dirichlet Allocation’, J. Mach. Learn. Res., vol. 3, pp. 993-1022, mar. de 2003. [En línea]. Disponible en: http://www. jmlr.org/papers/volume3/blei03a/blei03a.pdf. [6] Wikipedia, Procesamiento de lenguajes naturales. [En línea]. Disponible en: https: //es.wikipedia.org/wiki/Procesamiento_de_lenguajes_naturales (Acceso: 05-04-2019). [7] N. Chomsky, Syntactic Structures. Berlin: Mouton & CO, 1957. [8] ——, Aspects of the Theory of Syntax. Cambridge, Massachussetts: MIT Press, 1965. [9] SAS, Aprendizaje automático: Qué es y por qué es importante. [En línea]. Dispo- nible en: https://www.sas.com/es_es/insights/analytics/machine- learning.html (Acceso: 21-05-2019). [10] G. Moore, ‘Cramming more components onto integrated circuits’, Electronics, vol. 38, n.o 8, p. 144, Abril de 1965. [11] G. G. et all, Generalized Phrase Structure Grammar. Oxford: Basil Blackwell, 1985. [12] M. Johnson, ‘How the statistical revolution changes (computational) linguistics’, Brown University, 2009. [En línea]. Disponible en: https://pdfs.semanticscholar. org/e87a/e72b4ce149adecb1579125d84fab603b9548.pdf (Acceso: 14-04-2019). [13] A. Vlachos, ‘Evaluating unsupervised learning for natural language processing tasks’, University of Wisconsin-Madison, 2011. [En línea]. Disponible en: https: //aclweb.org/anthology/W11-2205 (Acceso: 15-04-2019).

83 [14] A. Moreno, Aplicaciones del Procesamiento del Lenguaje Natural. [En línea]. Dis- ponible en: http : / / www . iic . uam . es / inteligencia / aplicaciones - procesamiento-lenguaje-natural/ (Acceso: 17-04-2019). [15] S. Bird, E. Klein y E. Loper, Natural language processing with Python. Analyzing text with the Natural Language Toolkit. Sebastopol, California: O’Reilly Media, 2009. [En línea]. Disponible en: http://www.nltk.org/book/. [16] C. D. Manning et al., ‘The Stanford CoreNLP Natural Language Processing Tool- kit’, en Association for Computational Linguistics (ACL) System Demonstrations, 2014, pp. 55-60. [En línea]. Disponible en: http://www.aclweb.org/anthology/ P/P14/P14-5010. [17] Using Stanford CoreNLP on other human languages. [En línea]. Disponible en: https://stanfordnlp.github.io/CoreNLP/human- languages.html# models-for-other-languages (Acceso: 18-04-2019). [18] C. Badenes-Olmedo, J. L. Redondo-Garcia y O. Corcho, ‘Distributing Text Mining Tasks with librAIry’, en Proceedings of the 2017 ACM Symposium on Document Engineering, ép. DocEng ’17, ACM, 2017, pp. 63-66. doi: 10.1145/3103010. 3121040. [En línea]. Disponible en: http://doi.acm.org/10.1145/3103010. 3121040. [19] M. Steyvers y T. Griffiths, ‘Probabilistic Topic Models’, T. Landauer, D. McNama- ra, S. Dennis y W. Kintsch, eds., 2006. [En línea]. Disponible en: http://173. 236.226.255/tom/papers/SteyversGriffiths.pdf. [20] Y. Goldberg y G. Hirst, Neural Network Methods in Natural Language Processing. Morgan & Claypool Publishers, 2017. [21] A. P. Dempster, N. M. Laird y D. B. Rubin, ‘Maximum likelihood from incomple- te data via the EM algorithm’, Journal of the Royal Statistical Society, Series B, vol. 39, n.o 1, pp. 1-38, 1977. [22]R. Reh˚uˇ rekˇ y P. Sojka, ‘Software Framework for Topic Modelling with Large Cor- pora’, English, en Proceedings of the LREC 2010 Workshop on New Challenges for NLP Frameworks, http://is.muni.cz/publication/884893/en, Valletta, Malta: ELRA, mayo de 2010, pp. 45-50. [23] A. K. McCallum, ‘MALLET: A Machine Learning for Language Toolkit’, 2002, [En línea]. Disponible en: http://mallet.cs.umass.edu. [24] P. S. Foundation, Python Language Reference, version 3.7.1. [En línea]. Disponible en: https://docs.python.org/3/ (Acceso: 06-06-2019). [25] O. Corporation, MySQL | The Most Popular Open-Source Database | Oracle. [En línea]. Disponible en: https://www.oracle.com/mysql/ (Acceso: 10-06-2019).

84 [26] S. G. de Coordinación de la Contratación Electrónica, ‘Formato de sindicación y re- utilización de datos sobre licitaciones publicadas en la Plataforma de Contratación del Sector Público’, Dirección General del Patrimonio del Estado, 2018. [En línea]. Disponible en: http://www.hacienda.gob.es/Documentacion/Publico/D. G.%5C%20PATRIMONIO/Plataforma%5C_Contratacion/especificacion% 5C_mecanismo%5C_sindicacion.pdf (Acceso: 20-02-2019). [27] J. C. de Contratación Pública del Estado, ‘VOCABULARIO COMÚN DE CON- TRATOS PÚBLICOS’, Ministerio de Hacienda, 2008. [En línea]. Disponible en: http : / / www . hacienda . gob . es / Documentacion / Publico / D . G . %5C % 20PATRIMONIO/Junta%5C%20Consultiva/Reglamento%5C%20CPV/cpv%5C% 20principal.pdf (Acceso: 30-06-2019). [28] A. S. Foundation, PDFParser (Apache PDFBox) - TIKA. [En línea]. Disponible en: https://cwiki.apache.org/confluence/pages/viewpage.action? pageId=109454066 (Acceso: 30-06-2019). [29] J. Chang, S. Gerrish, C. Wang, J. L. Boyd-Graber y D. M. Blei, ‘Reading tea lea- ves: How humans interpret topic models’, Advances in neural information processing systems, pp. 288-296, 2009. [En línea]. Disponible en: https://pdfs. semanticscholar.org/3a99/da22b1658695d95a764169e030cc40e2fb95. pdf. [30] España, ‘Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Perso- nales y garantía de los derechos digitales.’, BOE, n.o 294, [En línea]. Disponible en: https://www.boe.es/eli/es/lo/2018/12/05/3 (Acceso: 29-07-2019). [31] Cómo escribir un Trabajo Fin de Grado. [En línea]. Disponible en: http : / / personales.upv.es/fjabad/pfc/comoEscribir.pdf (Acceso: 20-03-2019). [32] E. P. Superior, ‘Matriz de Evaluación de Trabajo Fin de Grado’, Universidad Carlos III de Madrid. Escuela Politécnica Superior, 2018. [33] S. A. Jaén, ‘Diseño e implementación de un sistema para el análisis y categoriza- ción en Twitter mediante técnicas de clasificación automática de textos’, Univer- sidad Carlos III de Madrid. Escuela Politécnica Superior, 2013. [En línea]. Dis- ponible en: https://e-archivo.uc3m.es/handle/10016/18085 (Acceso: 20-03-2019). [34] J. G. Barroso, ‘Desarrollo de Heurísticas en Planificación Automática mediante PDBs’, Universidad Carlos III de Madrid. Escuela Politécnica Superior, 2018. [35] España, ‘Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el texto refundido de la Ley de Propiedad Intelectual, regularizando, aclarando y armonizando las disposiciones legales vigentes sobre la materia.’, BOE, n.o 97, [En línea]. Disponible en: https://www.boe.es/eli/es/rdlg/1996/04/12/1/ con (Acceso: 30-07-2019).

85 [36] U. C. I. de Madrid, Derechos de explotación. [En línea]. Disponible en: https:// www.uc3m.es/ss/Satellite/Biblioteca/es/TextoMixta/1371214019341/ Derechos_de_explotacion (Acceso: 30-07-2019).

86 ANEXO A. INSTRUCCIONES DE DESPLIEGUE

En este primer apéndice se muestran las instrucciones de despliegue y ejecución de la aplicación desarrollada. Se cubre la preparación del equipo y la instalación de herramientas y librerías necesarias.

Sistemas operativos compatibles

El sistema se ha probado en los sistemas operativos Windows 10 y Ubuntu Linux 18.04. No se descarta que haya compatibilidad con otros sistemas operativos como Mac OS X o con otras distribuciones de Linux y Windows, pero al no existir la certeza total de ello se recomienda trabajar con alguno de los sistemas compatibles. En especial se recomienda trabajar con Linux para simplificar la instalación de requisitos y el despliegue del código.

Requisitos

Todo equipo compatible en el que se desee utilizar la aplicación deberá tener insta- ladas y configuradas las herramientas en las versiones correspondientes para evitar problemas de compatibilidad. Dichas tecnologías y sus versiones se muestran en la siguiente tabla:

Programa Versión Anaconda Python 3.7 (Opcional) 2019.07 Docker Cualquier versión Git Cualquier versión Java SE Development Kit (JDK) 8 Python 3.7.3 MALLET 2.0.8 MySQL Server 5.7 Tesseract OCR 4.0.0

Requisitos de despliegue

Despliegue

Para desplegar el código en la máquina destino deben seguirse los siguientes pasos:

1. Preparar servidor MySQL y crear la base de datos vacía.

87 2. Descargar el código clonando en local la rama master del repositorio GitHub59 donde está alojado en el directorio deseado.

3. Crear un entorno virtual Python 3.7 dedicado al proyecto para albergar las dependencias en las versiones correspondientes y así aislar el entorno de ejecución del programa del sistema principal.

4. Instalar las librerías Python necesarias en el entorno virtual creado. Todas ellas y sus versiones están recogidas en el fichero requirements.txt. Su contenido se resume en la siguiente tabla:

Librería Versión bs4 0.0.1 gensim 3.8.0 iso8601 0.1.12 lxml 4.3.3 nltk 3.4.3 pandas 0.24.2 pymysql 0.9.3 rarfile 3.0 textblob 0.15.3 tika 1.19 Unidecode 1.0.23 pyldavis 2.1.2 jupyter 1.0.0 numpy 1.16.4

Librerías Python necesarias

5. Descargar el código de LibrAIry desde su repositorio oficial60o desde Dockerhub61 y levantar la aplicación con Docker.

6. Preparar fichero de configuración del sistema, adaptándolo a la máquina.

Habiendo realizado estos pasos, y siempre desde dentro del entorno virtual, ya se puede lanzar tanto el script de obtención del corpus como el notebook de modelado y visualización de tópicos.

59https://github.com/olgahm/TFG 60https://github.com/librairy 61https://hub.docker.com/r/librairy/site

88 ANEXO B. IMPLEMENTACIONES PREVIAS

Este anexo se dedica a describir las lógicas de obtención del corpus que fueron des- cartadas en favor del procesamiento de los datos de contratación en formato XML. Antes de existir la sección “Datos abiertos” en la Plataforma de Contratación del Sec- tor Público la única manera de extraer la información de licitaciones era utilizar herramientas de web scraping que obtuvieran los datos de contratación analizando la estructura de la propia web. En primer lugar, se analizó el diseño de la Plataforma para determinar cuál era la mejor herramienta con la que hacer la extracción de datos. A priori, se consideraron las siguientes tecnologías compatibles con Python:

Scrapy62: Se trata de una herramienta que permite realizar web scraping de forma automatizada y rápida de grandes cantidades de contenido web. Es una herramienta muy potente y escalable cuando se trata de extraer información de páginas web estáticas donde el contenido que se desea extraer reside en las etiquetas html de su código fuente. Sin embargo, no es capaz de cargar código en JavaScript ni interactuar con los sitios a través de formularios.

Selenium63: Es un entorno de pruebas de software basado en web. Si bien no se trata de una herramienta diseñada exclusivamente para web scraping, su alta capacidad de renderización de código JavaScript y de interacción con las webs hacen de Selenium una herramienta interesante para extraer información de sitios web. No obstante, para webs que hacen un uso intensivo de código procesado en el lado del cliente puede resultar una solución muy lenta, ya que Selenium internamente automatiza un navegador web para cargar páginas con estas características y esto implica un procesamiento pesado.

Este estudio previo concluyó con que para ver la totalidad de las licitaciones publicadas era necesario interactuar con la Plataforma a través de formularios de búsqueda. Estos formularios no dirigen directamente a la licitación solicitada, sino a una página generada dinámicamente mediante la ejecución de código JavaScript en el lado del cliente. Estas páginas dinámicas muestran el detalle de la licitación y, a su vez, contienen un enlace a la versión estática del recurso mostrado. El uso intensivo de JavaScript con el que trabaja la Plataforma hizo que fuera necesario utilizar Selenium para poder navegar por el sitio a pesar de su lentitud. Sin embargo, como cada recurso dinámico contenía un enlace a una versión estática de sí mismo, es decir, a una página web en cuyo código fuente sí estuvieran los datos de interés, se optó por

62https://scrapy.org/ 63https://www.seleniumhq.org/

89 utilizar Scrapy para procesar estas páginas estáticas y así poder disfrutar de su potencia al extraer la información e intentar compensar el tiempo consumido en la obtención del recurso estático con Selenium. El procedimiento de extracción de datos era el siguiente:

1. Obtención de listado de recursos estáticos: Utilizando Selenium, se navega por el formulario de búsqueda de licitaciones. Lanzando la búsqueda sin especificar ningún criterio, aparece una tabla con el listado de licitaciones. Por cada licitación mostrada, se accede a la página dinámica con el detalle de la oferta y se recupera en enlace a la página estática.

2. Procesamiento de vista de detalle de licitaciones: Una vez se dispone de un listado con las direcciones a las vistas estáticas con el detalle de las licitaciones, se utiliza Scrapy para analizar la estructura de su código fuente y recuperar los datos de las licitaciones. Cabe destacar que el detalle de unas ofertas puede no contener la misma información que el detalle de otras, por lo que en este punto es imposible conocer a priori los campos del modelo de datos, además del identificador obliga- torio del contrato o el enlace a sus pliegos. Por este motivo, el modelo de datos no estaba preestablecido e iba modificándose cuando se encontraba un campo nuevo en el detalle de las licitaciones.

3. Obtención de pliegos: Se utiliza Scrapy para acceder a los pliegos técnicos, des- cargarlos y almacenarlos en disco.

La figura presente en la siguiente página muestra el diagrama de flujo de losproce- dimientos descritos. El contenido de este diagrama sería el inscrito en la acción “Llenar base de datos” del diagrama de flujo de la Figura 3.8. Este procedimiento tiene unas limitaciones muy evidentes en cuanto a eficiencia y calidad de los datos obtenidos. Los problemas de eficiencia vienen derivados por la naturaleza de las herramientas utilizadas y por la constante modificación del modelo de datos. Respecto a la calidad de los datos, con esta aproximación no era posible acceder a toda la información de las licitaciones, pues no se muestra en su totalidad en las vistas de la web. Por otra parte, este modelo está sujeto a la estructura de la web, por lo que si en algún momento esta cambiase por algún motivo el sistema completo resultaría completamente inservible. Es por ello que al surgir la posibilidad de utilizar otra manera más óptima de extraer más datos de contratación de mejor calidad se decidió descartar esta solución aunque supusiera retrasar la entrega del proyecto.

90 Diagrama de flujo: Proceso descartado de llenado de base de datos