dmlls/jizt-tfg

Servicio de Resumen de Textos con AI en la Nube (versión TFG).

jizt-tfg's Issues

[Motor de Resumen] Refactorizar Motor de Resumen

Actualmente, el Motor de Resumen lleva a cabo las tareas de codificación y resumen del texto. Se ha considerado que estos dos procesos pueden independizarse para conformar dos microservicios separados dentro de la arquitectura del sistema, a fin de conseguir una mayor modularidad.

Implementar Post-procesador de Textos

Gestionar el post-procesado del texto generado por el motor de resumen con el fin de mejorar la presentación final del mismo al usuario. Esto puede incluir tareas como formatear correctamente el texto (p. ej. eliminando espacios innecesarios), eliminar frases inacabadas, recuperar las URLs del texto original, etc.

[Post-procesador] Entrenar truecase con volcado de Wikipedia

El modelo incluido por defecto en la librería truecase está entrenado con el corpus en inglés de NLTK. Entrenándolo con un volcado reciente de Wikipedia, se podría mejorar su precisión, especialmente en el caso de las entidades nombradas.

Implementar Pre-procesador de Textos

Gestionar el preprocesado de los textos para adaptar la entrada al motor de resúmenes con el fin de conseguir mejores resultados.

Formación Básica Amazon EC2, S3 y RDS.

Conocer más acerca de estos servicios proporcionados por Amazon Web Services (AWS).

[REST API] API Gateway

Implementar la API Gateway con Flask y Flask-RESTful.

[MVP] Event-driven architecture y Asincronismo

El objetivo de esta historia de usuario es implementar una primera versión reducida de la arquitectura dirijida por eventos (event-driven architecture), junto con la funcionalidad de asincronismo.

Para implementar la arquitectura event-driven, se empleará Kafka y Strimzi.

En esta arquitectura reducida solo se emplearán los microservicios Dispatcher y Pre-procesador. La figura incluida a continuación muestra qué parte de la arquitectura se va a implementar.

En un primer momento, no se utilizará una base de datos real, si no que se almacenarán los datos en memoria. La implementación de la base de datos queda pendiente para futuros epics.

Para más información, ver la Issue #67, donde se explica detalladamente la arquitectura completa.

[Kubernetes] Plugin CoreDNS

Para facilitar el descubrimiento de los de los servicios dentro del nodo Kubernetes, se va emplear el plugin CoreDNS. Este plugin facilita la labor de lookup en la tabla DNS, de forma que podemos saber la IP de un servicio específico a través de su nombre (el cual sabemos de antemano porque lo configuramos nosotros).

La tabla DNS tendría, por ejemplo, el siguiente aspecto:

Nombre del servicio	IP
dispatcher-service	10.102.219.82
text-preprocessor-service	10.103.134.72
encoder-service	10.104.202.94
summarizer-service	10.104.204.15
post-processor-service	10.105.120.11
...	...

Por lo tanto, si quisiéramos enviar una petición HTTP al servicio text-preprocessor-service, podríamos obtener su IP con el siguiente código (Python):

import socket
ip_txt_preprocessor_svc = socket.gethostbyname('text-preprocessor-service')

y enviar la petición a dicha IP.

Elección de licencia para el proyecto

[Formación] Apache Kafka y Strimzi

A la hora de hablar de arquitectura event-driven, una de las plataformas más populares es Apache Kafka. En nuestro caso lo emplearemos para poder implementar el asíncronismo en nuestra arquitectura, de forma que los diferentes microservicios se comuniquen mediante la publicación de mesajes.

Por otra parte, Strimzi simplifica la tarea de configuración y gestión de Apache Kafka en Kubernetes, por lo que también emplearemos este framework.

[MVP] Desplegar Kubernetes

Configurar la orquestración de los contenedores Docker mediante Kubernetes.

Primeros planteamientos de la Arquitectura de Microservicios

Generar un diseño preliminar de cómo se organizarán los diferentes microservicios que componen el sistema.

[Pre-procesador] Siglas con puntos

Describe el error:
Cuando la cadena de entrada contiene siglas con puntos (p. ej. "U.K. o "U.S.A.", "B.C.", etc.), el texto procesado contiene un espacio entre las letras de la sigla (i.e., "U. K.", "U. S. A", "B. C.", etc.).

Pasos para reproduccir:
Introducir una cadena de entrada con una sigla que contenga puntos.

Resultados esperados:
Las sigla en la cadena de salida deberían mantenerse intactas.

Resultados obtenidos:
Las siglas en la cadena de salida contienen espacios entre las letras.

Información adicional:
El error no aparece si las siglas están en minúsculas (p. ej. "u.k.", "u.s.a.", etc.).

[Post-procesador de Textos] Implementar servicio

Implementar el post-procesado del texto, la lógica del productor y el consumidor de Kafka, y dockerizar el servicio.

Pruebas unitarias Motor de Resumen

Diseñar logo e imagen del proyecto

Diseño de un logo e imagen (colores, fuentes, etc.) para el proyecto. Se trata de una tarea preliminar y la idea es que la imagen del proyecto vaya creciendo junto a este, por lo cual esta tarea se trata de una primera aproximación, sujeta a futuros cambios.

[Encoder] Refactorizar constructor

Sección de código actual que debería ser refactorizado:
Actualmente, el constructor de la clase SplitterTokenizer
https://github.com/dmlls/jizt/blob/77daf04459ae8a00b9de30535beb9234fa9d5db2/src/text_summarization.py#L58
toma directamente el tokenizador como parámetro.

Propuesta de refactorización:
Se propone, en vez de pasar el tokenizador como objeto, pasar únicamente una str indicando el modelo a emplear.

Por ejemplo: SplitterTokenizer("bart-base").

El modelo pasado como str debe estar incluido dentro de los modelos implementeados por Hugging Face, concretamente los modelos Bart y T5.

Motivos para la refactorización:
De esta forma, se descarga al código exterior a la clase de la responsabilidad de instanciar el tokenizador, logrando una mayor simplicidad y abstracción.

Formación básica acerca de Flask

Pequeña introducción a Flask: ¿qué es?, ¿cómo funciona?, instalación, uso básico, etc.

Elegir herramienta de gestión de proyectos

Curso "Stanford CS224N: NLP with Deep Learning"

Visualizar la serie de vídeos correspondiente al curso "Stanford CS224N: NLP with Deep Learning".

Tiempo estimado: 25 horas.

[Google Cloud] Crear un Persistent Disk y cargar modelos

Los Persistent Disks de Google Cloud proporcionan almacenamiento en bloque fiable y de alto rendimiento para instancias de máquinas virtuales. Nuestros modelos serán almacenados en este componente, y serán accedidos a través de volúmenes persistentes desde los microservicios de codificación y motor de resumen orquestrados por Kubernetes.

Por el momento, se empleará el modelo T5-large tanto como para la codificación del texto, como para su resumen. Este modelo consta de 770 millones de parámetros con 24 capas.

Crear una landing page para el proyecto

[Formación básica] API REST con Flask

Los distintos microservicios se comunicarán mediante peticiones REST. Una buena herramienta para implementar APIs REST en Python es Flask.

Implementar Motor de Resumen

Haciendo uso de la librería transformers de Hugging Face. En un principio, se emplearán los modelos T5 de Google, y Bart de Facebook.

Más información acerca de la librería transformers aquí.

Escribir el "About" del repositorio

[MVP] Arquitectura básica

A fin de "atacar" el desafío de montar la arquitectura de microservicios completa, se comenzará por implementar una arquitectura muy básica, que únicamente lleve a cabo la tarea de pre-procesado del texto. La siguiente ilustración muestra la implementación concreta de esta arquitectura básica.

---

---

El objetivo de esta historia de usuario es conseguir implementar un Producto Mínimo Viable (MVP) que funcione bajo unas condiciones lo más parecidas a las de la arquitectura final, especialmente en lo que respecta a los siguientes puntos:

• Cada microservicio deberá implementar una API REST que permita la comunicación con otros microservicios.
• Cada microservicio deberá estar "contenedorizado". Se emplearán contenedores Docker.
• La orquestración de los diferentes contenedores se llevará a cabo mediante Kubernetes.

El objetivo es conseguir implementar el MPV de manera rápida, adquiriendo durante dicha implementación experiencia y lecciones valiosas, a través de un fuerte enfoque ensayo-error, para el futuro desarrollo final de la arquitectura completa.

Añadir versionado

Añadir la versión a los scripts existentes. Versión inicial: v0.1.

Escoger un cloud provider para alojar la arquitectura

Realizar una pequeña búsqueda de servicios de computación en la nube y contratar el más apropiado para alojar nuestro modelo generador de resúmenes, así como el resto de componentes necesarios (pre y post-pocesador de texto, driver para Twitter, etc.).

Diseñar la estructura del tablero Kanban

Establecer las columnas de las que dispondrá nuestro tablero Kanban.

[Kubernetes] Helm

Helm es un popular package manager para Kubernetes. Una de sus principales puntos fuertes son los llamados "Charts", los cuales permiten definir plantillas que configuran el despliegue de los diferentes componentes de Kubernetes.

En nuestro caso, el uso de Helm Charts es ventajoso no solo porque permite "encapsular" toda nuestra arquitectura en un único paquete, de forma que cualquier usuario podría desplegarla con tan solo un comando, sino también por el hecho de que los diferentes microservicios que componen jizt tienen una configuración muy parecida. A través de los Helm Charts, podemos definir una plantilla base para todos los microservicios, de forma que reducimos la duplicación de código y facilitamos la mantenibilidad del código.

Más información en la documentación oficial de Helm.

Elegir metodología de desarrollo software

Formación Básica acerca de Arquitectura de Microservicios

Elección de nombre para el proyecto

Dockerizar Dispatcher y Pre-procesador de Textos

Pruebas unitarias Pre-procesador de Textos

[Bug] Pre-procesador: punto final

Si la última frase del texto no acaba en punto ".", el preprocesador lo añade automáticamente. Sin embargo, la útlima frase podría acabar en "!" o "?" y ser correcta. En estos casos, el preprocesador seguiría añadiendo el punto, de forma que la útlima frase acabaría en "!." o "?.", lo cual no cumple con las reglas gramaticales.

Añadir en readme logo Ministerio

Añadir al final del Readme el logo del Ministerio de Educación y Formación Profesional por la concesión de la Beca de colaboración con el Departamento de Ingeniería Informática de la UBU.

[REST API] Dispatcher y Pre-procesador de textos

Implementar la API REST para el dispatcher y el pre-procesador de textos con Flask y Flask_RESTful.

[Kubernetes] Gestión de los modelos de generación de resúmenes

Los modelos de codificación y resumen de texto pueden llegar a tener un gran tamaño (del orden de GBs). Dado que los diferentes pods correspondientes a un modelo, p. ej. T5-large, van a utilizar todos ese mismo modelo, parece contraproducente que cada pod tenga su propia copia del mismo.

Una posible opción a explorar son los volúmenes de Kubernetes, que permiten establecer un espacio de memoria externo a los contenedores (p. ej., en el propio disco del servidor) al que pueden acceder de forma compartida (requiere una correcta configuración).

[Pre-procesador] Cambio de NLTK a blingfire

Tras un pequeño test, se ha comprobado que la función text_to_sentences incluido en la librería blingfire de Microsoft obtiene mejores resultados que sent_tokenize de NLTK.

Tareas:

• Cambiar el algoritmo de división de frases.
• Evaluar las diferencias de tiempo entre blingfire y NLTK.

Organizar Labels

Añadir, eliminar o editar Labels para ajustarlas a las necesidades del proyecto.

Actualizar README

[Formación básica] Flask + Docker

Formación básica sobre la integración de Flask en Docker.

[Doc] Ajustar los docstrings a Sphinx

Más inforamación sobre Sphinx.

Formación Básica Microservicios, Docker y Kubernetes

Elegir framework de testing para Python

[MVP] Implementar Kafka Topics

Como se indica en la Issue #67, en la que se describe la arquitectura event-driven de jizt, dentro del framework de Kafka existen los topics a donde los productores envían sus mensajes, y de los cuales los consumidores los consumen.

Se puede encontrar más información sobre los topics de Kafka en su sitio web.

Recordando, nuestra arquitectura tiene el siguiente aspecto:

En el anterior diagrama, los topics estarían incluidos dentro del Kafka Broker:

• Text pre-processing: topic al cual produce el Dispatcher comenzando el procesado del texto, y del cual consume el Pre-procesador de textos.
• Text encoding: topic al cual produce el Pre-procesador de textos, y del cual consume el Codificador.
• Text summarization: topic al cual produce el Codificador, y del cual consume el Motor de resumen.
• Text post-processing: topic al cual produce el Motor de resumen, y del cual consume el Post-procesador de textos.
• Ready: topic al cual produce el Post-procesador de textos.

El Dispatcher, por su parte, consumiría de todos los anteriores topics a fin de actualizar el estado del job en cuestión.

Formación básica acerca de Docker

Pequeña introducción a Docker: ¿qué es?, ¿cómo funciona?, instalación, uso básico, etc.

Pruebas unitarias Post-procesador de Textos

[Hugging Face] Guardado y carga de los modelos

Investigar cómo llevar a cabo el guardado y la carga de los modelos preentrenados de Hugging Face.