Usando Transkribus con manuscritos medievales (10): perfeccionando modelos con PyLaia (parte 1)

Terminé la última entrada describiendo el inusual comportamiento al entrenar dos modelos de transcripción en PyLaia, 7P y Lucidario B:

Progresión histórica de versiones de 7P y Lucidario B

Cuando las tasas de error en los sets de entrenamiento y de validación de un modelo HTR son demasiado altas, el modelo puede volverse a entrenar —que no es lo mismo que re-entrenarlo, algo que desaconsejo— para lograr nuevas iteraciones (versiones) que corrijan el problema. Una tasa elevada significa que las transcripciones hechas por el modelo serán poco confiables y requerirán muchas intervenciones correctivas (lo que derrota el propósito de la transcripción automatizada).

Cada nuevo entrenamiento ocurre sobre un texto base —la transcripción de folios considerados ground truth— más grande que el del entrenamiento anterior: la lógica es que a mayor cantidad de texto la máquina será capaz de desarrollar un modelo estadístico más confiable porque tendrá más y más variados ejemplos de la escritura que está aprendiendo.

Así, en la imagen anterior, del modelo 7P v. 0.1 al 7P v. 0.6 se ha pasado de 6736 palabras, distribuidas en 738 líneas (o 6 bifolios de cuatro columnas) a 29.172 palabras, distribuidas en 3056 líneas (o 26 bifolios de cuatro columnas). En teoría cada incremento debe lograr que el CER de entrenamiento y el CER de validación disminuyan, reflejando la mayor exactitud del modelo.

Hace algún tiempo había notado que no solo los CER de estos modelos eran demasiado elevados, sino que en los sucesivos entrenamientos los números no mejoraban, sino que empeoraban. Por ejemplo, entre Lucidario B 0.3 y 0.4 hay un incremento del CER de validación de 6.3% a 7.5% (1.2% más alto), y en la versión 0.5 este llega a 7.8% (1.5% más respecto a 0.3). En 7P v. 0.5 el CER de validación es de 3.61%, pero en 0.6 es 6.2% (2.59% más). El CER baja en 1.0 al 4%, pero en 1.1 llega al 5.9%. ¿Qué está pasando aquí?

Mi hipótesis al escribir la última entrada era que PyLaia era una máquina más sensible a los errores de transcripción que CITLab+, y que estos errores producían un efecto cascada que arruinaba los CER. Así que después de escribir la última entrada me puse a revisar meticulosamente las transcripciones usadas como set de entrenamiento. Me serví de dos herramientas desarrolladas para los corpus textuales del Hispanic Seminary of Medieval Studies, cuyo sistema de transcripción semipaleográfica empleo para las transcripciones. Se trata de un revisor de errores en el sistema de marcado (proofer) y el HSMS-App, un etiquetador morfológico y lematizador (que también detecta errores).

El proofer es un programa de 16-bits desarrollado en MS-DOS (que no funciona en las versiones modernas de Windows y es imposible de correr en una Mac como la que uso). Una solución es usar DOSBox, pero el HSMS-App solo funciona en Windows y quería evitar tener que usar un emulador de DOS para el proofer y otro de Windows para el HSMS-App. La solución fue bastante elegante (y nostálgica): instalar UTM, un aplicativo para Mac que permite crear máquinas virtuales (con cualquier arquitectura) sobre las que se puede instalar un sistema operativo. Al necesitar compatibilidad con programas de 16-bits (proofer) y 32-bits (HSMS-App), la mejor solución fue el último sistema operativo de Microsoft compatible ambas arquitecturas, Windows XP:

Resultado de revisión del proofer
HSMS-App

Para corregir el modelo Lucidario B di un paso más: releí y corregí línea por línea el texto de la transcripción base. Así me aseguraba de que todos los errores desaparecerían. Luego volví a entrenar los modelos en Transkribus.

Los resultados son 7P v. 1.0 y v. 1.1 (CER de validación de 4% y 5.9%) y Lucidario B 0.6 y 0.7 (CER de 7.5% y 7.01%). Es decir, un modelo que tiene un incremento de dos puntos porcentuales y otro que disminuye casi medio punto porcentual. Decididamente, algo andaba mal (y no eran los pequeños errores de transcripción que corregí en mi revisión con los aplicativos y la lectura línea por línea).

Volví a Transkribus y comencé a prestar atención al lugar en el que ocurrían los errores en los sets de validación. Rápidamente noté una tendencia, ilustrada en estas imágenes:

Folio de set de entrenamiento, 7P v. 1.0
Folio 45r, Lucidario B

Rápidamente recordé las líneas fantasma de las que había advertido al inicio de mis entradas sobre Transkribus (y que, negligentemente, había olvidado revisar). Por algún motivo la herramienta de reconocimiento de líneas de Transkribus —en la que había confiado excesivamente— no había hecho bien su tarea y los finales de muchas líneas en ambos manuscritos se cortaban antes de que el texto terminara, o se proyectaban antes del inicio del texto sobre espacio ocupado por decoraciones e iniciales.

En ambos casos los efectos eran los mismos. Al añadir texto a la página, convertirlo en ground truth y lanzar un entrenamiento de modelo, Transkribus intentaba encontrar coincidencias entre el texto que le había dado y el contenido visual de las líneas incompletas o contaminadas por elementos extraños. Cuando no podía lograr una correspondencia exacta, el modelo comenzaba a fallar y los CER se disparaban.

Para probar esta teoría, volví a entrenar los modelos tras corregir los errores en las líneas. El resultado parece confirmar que esto era lo que iba mal. Lucidario B 0.8 ve una disminución de 1.5% en el CER de validación respecto a su antecesor y 7P v. 1.2 baja 2.4%.

Lucidario B mantiene un CER en validación elevado, pero esto ya no se debe a problemas de transcripción o de segmentación del texto, sino a la heterogeneidad del manuscrito. Como se ve en la última imagen, la letra y la lengua del copista no es tan regular como una gótica redonda.

Todo varía: las abreviaturas tienen múltiples valores lo largo del texto para las mismas palabras (pro/pro, partida/partida, guisa/guisa, guardar/guardar/guardar/guardar), la forma de las letras cambia de línea a línea y a veces el mismo trazo puede tener distintos valores que no dependen del contexto (la r final, con el trazo alargado hacia la izquierda también puede ser un símbolo tironiano). A esto hay que añadir que el texto tiene usos dialectales leoneses que coexisten con formas más estándares del castellano medieval con la misma distribución estadística (fezieron/fezioron, apostoles/apostolos, angeles/angolos) y lo mismo ocurre con los verbos en tercera persona singular del pretérito, que pueden aparecer en forma plena (faze, dize) o en forma apocopada (faz, diz), con un trazo en la zeta que parece engañosamente una lineta para una e abreviada. Esta variabilidad hace necesario ampliar el texto base de entrenamiento (reportaré cómo va esta experiencia en futuras entradas).

Bueno, dejo las cosas aquí. En la próxima entrada volveré sobre el tema la collatio digital.


Imagen de miniatura: detalle de los modelos 7P y Lucidario B,
Transkribus Expert Client



Citar este post
Cossío Olavide, Mario (2024, 31 enero). Usando Transkribus con manuscritos medievales (10): perfeccionando modelos con PyLaia (parte 1). Lucidarios. Recuperado 22 de mayo de 2024, de https://doi.org/10.58079/vq0o

También te podría gustar...

Buscar en OpenEdition Search

Se le redirigirá a OpenEdition Search