[Dispatcher] Diseño E/R de la BD

Como se indica en #67, el Dispatcher hará uso de una base de datos con dos objetivos fundamentales:

Detectar cuándo un resumen ya ha sido generado, a fin de no volver a generarlo de nuevo, lo cual es un proceso que puede dilatarse en el tiempo (varios segundos). En caso de que el resumen de un determinado texto ya exista, se recuperará de la base de datos, siendo la respuesta instantánea.
Almacenar información valiosa con el fin de llevar a cabo futuras evaluaciones de los resúmenes. Por ejemplo, se podría evaluar y comparar la calidad de los resúmenes generados por los diferentes modelos.

Como SGBD hemos escogido PostgreSQL, debido a su relativamente sencillo despliegue en Kubernetes a través de postgres-operator, y a su reconocido prestigio como SGBD.

El modelo E/R para nuestra base de datos es simple por el momento. No obstante, existe un detalle que da lugar a varias posibles implementaciones. Se trata de los parámetros del resumen, los cuales no son fijos: podrían variar entre los diferentes modelos, familias de modelos, o simplemente de quién lo implemente.

Esto da lugar principalmente a tres posibles diseños.

1. Parámetros separados en otra tabla

Este enfoque consistiría en extraer los parámetros en una tabla diferente a la tabla de los resúmenes. Esta tabla externa contendría los parámetros concretos de una determinada implementación. Por ejemplo, en nuestro caso, por el momento únicamente tendríamos la tabla hugging_face_params:

dispatcher-db-0 0 7

En cuanto a la explicación de algunos de los campos/tablas que aparecen en el diagrama:

source: es la tabla que almacena el texto fuente de los resúmenes, es decir, el texto a resumir. Este texto puede ser arbitrariamente largo, por lo que tiene sentido recogerlo en una tabla aparte, para evitar duplicaciones en el caso de que se generen varios resúmenes de él con diferentes modelos/parámetros.
Los diferentes modelos, recogidos en la tabla model, se agrupan en familias, model_family. Ejemplos de familias serían T5 o BART, cada una de ellas agrupando diferentes modelos: t5-small, t5-base, t5-large..., y bart-base, bart-large, bart-large-cnn..., respectivamente. Las familias de modelos tienen además un autor o autores, es decir, quién las ha inventado. Estos autores puede que formen parte de una organización, universidad o empresa. Por ejemplo, en el caso de T5, los autores serían Colin Raffel et al., y la organización Google.
La tabla de vendor indica de quién procecede la implementación de un determinado modelo. Por ejemplo, Hugging Face.
Los campos see se utilizarán para almacenar links de referencia. Esto podría ser útil a fin de mostrar al usuario mensajes como: "Para más información, visita la página web de Hugging Face".

La principal desventaja de esta implementación es que el diseño de las tablas de parámetros depende de factores externos, concretamente de la implementación que empleemos. Esto conlleva que si el día de mañana dicha implementación cambiase, tendríamos que adaptar nuestro diseño. Es decir, aumenta la dependencia del mismo

Otra posible desventaja sería que potencialmente podrían existir un elevado número de tablas de parámetros, lo que dificultaría la mantenibilidad.

2. Todos los parámetros en una tabla, campos no relevantes a null

Una segunda opción sería introducir todos los parámetros de las diferentes implementaciones en la propia tabla summary. Los parámetros que no se correspondiesen con el modelo con el que se ha generado el resumen, quedarían a null.

Este diseño sigue estando fuertemente ligado a las implementaciones externas. Además, puede ser más propenso a errores, ya que de toda la lista de parámetros debemos saber cuáles son los relevantes para cada resumen. Asimismo, la mantenibilidad puede ser tediosa por las mismas razones que en el caso anterior.

3. Campo único con tipo de datos JSON

La tercera opción pasaría por introducir todos los parámetros en único campo. Los SGBD modernos ofrecen el tipo de datos JSON, que incluso permite realizar consultas basadas en las claves/valores de los propios documentos.

Siguiendo este diseño, el modelo E/R quedaría:

dispatcher-db-0 0 9

Este diseño resuelve, en principio, los principales incovenientes que encontrábamos en las anteriores opciones:

La dependencia de la implementacion externa es mínima. En el caso de que se produjera un cambio en cualquiera de las implementaciones externas, los resúmenes que hubieran sido generados con la anterior implementación conservarían los anteriores parámetros, y aquellos que se generaran posteriormente contendrían ya los nuevos.
El diseño se simplifica, facilitando el mantenimiento dado que no tenemos que encargarnos de actualizar las tablas de parámetros.

dmlls / jizt-tfg