Cómo está hecho

1Qué es y qué no es

Amanuensis es una familia de tres modelos. Amanuensis lee la página entera: renglones, zonas, notas al margen, tablas por celdas y orden de lectura, con un lector grande que elige según la escritura. Amanuensis Ligero es un lector diminuto para impreso latino que corre en cualquier CPU; con -r usa por dentro una variante aún menor, el lector Mínimo. Amanuensis Voz es un módulo aparte de voz a texto. Con -m auto, que es lo que hace el paquete por defecto, una sonda de medio segundo decide en cada página si la lee Ligero o el modelo grande.

El diseño parte de una restricción: un lector que reconoce no puede escribir lo que no está en la página. Los lectores son de clasificación temporal conexionista (CTC) [1]: para cada columna de la imagen dan una distribución sobre el alfabeto más un símbolo en blanco, y el texto sale de colapsar las repeticiones y quitar los blancos. No hay bucles de repetición ni párrafos inventados, y cada letra dudosa se puede marcar con su probabilidad en TEI, PAGE, ALTO, hOCR, HTML y JSON.

No es un convertidor general de PDF modernos a Markdown: no escribe fórmulas en LaTeX, las tablas complejas se le resisten y la letra a mano contemporánea la leen mejor los modelos de visión grandes (§ 9).

2El codificador y los lectores

El codificador

Todos los modelos de visión grandes parten del codificador de visión de EmbeddingGemma 2 [3], de Google, congelado y recortado a 14 capas. El lector toma los estados de las capas intermedias 8, 10, 12 y 14, normalizados y mezclados con pesos que se aprenden; la salida final del codificador, pensada para comparar documentos, no interviene. Un adaptador LoRA [2] lo ajusta a la lectura sin tocar sus pesos.

El LoRA va en las proyecciones de atención (q, k, v, o), en las del MLP (gate, up, down) de cada capa y en el incrustado de parches. En el lector histórico v2b96 tenía rango 32 en las capas 1 a 14: 7,96 millones de parámetros, 16 MB en fp16. El v3 conserva el rango 32; la ronda 5 se entrenó con rango 64 sobre una base ya interpolada, y el lector definitivo, que es la interpolación de dos adaptadores, se guarda con rango 128.

El lector grande

El renglón llega recortado y enderezado por su línea base, a 96 px de alto, y se trocea en parches de 16 px: seis filas por columna. La cabeza aplana las filas de cada columna, las lleva a 512 dimensiones, pasa una convolución de núcleo 5 y seis capas de transformador, multiplica por cuatro los fotogramas de cada columna (una columna de 16 px da cuatro fotogramas) y afina con dos capas más antes de la salida de 14 653 clases. Un selector por escritura manda el alfabeto latino al lector histórico y el árabe, el cirílico, el devanagari o el chino al multilingüe, que lee líneas de 64 px con unos 14 800 caracteres.

La pérdida es la de la CTC: la probabilidad de un texto y suma todas las alineaciones π que, colapsadas por ℬ, dan ese texto. En la lectura basta la decodificación voraz. El arrojo suma un sesgo al blanco antes de decidir, $(\mathrm{0,5}-a)\times 4$ sobre su log-probabilidad: por encima de 0,5 el lector calla menos letras en escaneos muy malos; por debajo, deja huecos antes que arriesgarse.

La cabeza se condiciona por la convención de transcripción, grafemática (como CATMuS [7], con los signos de MUFI [16] y sin desarrollar abreviaturas) o desarrollada, con un vector aprendido que al guardar se pliega en el sesgo. El paquete usa la grafemática.

Ligero y Mínimo

Los lectores pequeños tienen una arquitectura propia. El renglón entra a 40 px de alto y estrechado a 0,8 en horizontal; un tallo de tres convoluciones 2D reduce 8 veces el alto y 4 el ancho; siguen bloques 1D con convolución por canal de núcleo 9, expansión 2 y excitación, y dos capas de atención con máscara que ven el renglón entero. La salida es una CTC de 617 clases: el alfabeto latino moderno e histórico con MUFI. Ligero tiene 192 dimensiones y 12 bloques (3,5 millones de parámetros, 14 MB en fp32); Mínimo, 128 y 8 (1,07 millones, 4 MB). No se cuantizan: la int8 dinámica de ONNX Runtime estropeaba el lector (impreso moderno de 0,28 a 1,50 de error).

3Renglones y maquetación

Hay dos maquetaciones para las páginas que lee Ligero. La clásica es el detector Mínimo, la orientación, las columnas, el orden por grafo y la palabra partida (§ 4). La mínima es una red que da renglones curvos, zonas y orden, y ordena por continuidad. Ninguna gana en todo, y desde la versión 1.1.1 se elige página a página con la misma regla en el paquete, en la demo y en la app.

1. La página se lee primero con la maquetación clásica.
2. Si más del 10 % de sus renglones con texto salen con una confianza menor que 0,75, o si hay menos de 3, se vuelve a leer con la mínima.
3. En el modo rápido, que no endereza la página, la mínima ya no la gira con su clasificador de orientación: giraba 90 o 180° páginas que estaban derechas (18 de 324 en desarrollo).

El modelo grande sigue con su maquetación v4 y su rama densa, y la sonda del modo auto con el detector Mínimo. La demo ya usa la regla y la app la incorpora en su próxima versión de pruebas.

La mínima gana con claridad en manuscritos, donde el detector Mínimo apenas encuentra renglones, en impreso antiguo, en prensa y en fotos. La clásica gana en impreso moderno de libro y de revista y en el texto de lectura: con zonas, el pulido de la estructura y la palabra partida no actúan, y la mínima repite renglones y deja folios sueltos. La regla se queda con lo mejor de cada una. El umbral se eligió en las páginas de desarrollo con validación cruzada a mitades (con tres semillas, la regla gana a la mínima en CER en las 12 pruebas y en FCA en 10), y se prefirió 0,10 a un umbral más bajo para que las páginas de los bancos de impreso moderno fueran enteras por la clásica. El examen sellado no se usó.

El coste es de tiempo: en Ligero, las páginas que no son de impreso moderno se leen dos veces, y en las de desarrollo la media pasa de 1,11 a 1,55 s por página; en el modo rápido, de 0,53 a 0,56.

El orden por grafo y las columnas de la 1.1 (§ 4) actúan en todas las páginas que van por la clásica: con la regla, la mayoría de las de impreso moderno en el paquete, en la demo y en la app.

El detector Mínimo

Es una U-Net de bloques residuales invertidos de 0,13 millones de parámetros que da, a paso 4, el mapa del núcleo de cada renglón y su región. Se entrenó solo con páginas de PDF nacidos digitales, con aumentos de escaneo, giro, curvatura y sombra; su F1 de cajas es 0,92 a 768 px. En manuscritos segmenta mal. En la demo y en la app, cuando cubre menos de la mitad de la tinta que encuentra un perfil de la página, los renglones se cortan por el perfil de la tinta.

LineasAR

Los renglones del modelo grande los da una U-Net ligera de 3,4 millones de parámetros sobre la página en gris, a lado 1280-2560, con salida a paso 2 (núcleo de renglón y alturas), que muestrea además sobre su rejilla los estados de las capas 6, 10 y 14 del codificador. Se entrenó con páginas de HTR-United, cBAD 2019 y 12 000 páginas sintéticas de alta resolución. En el protocolo oficial de cBAD 2019 [10] da P 0,891, R 0,931 y F 0,910 en 1432 páginas de prueba (Kraken blla, en las mismas páginas, 0,846).

La maquetación del modelo grande

La maquetación v4 comparte el codificador con un LoRA propio, que parte del adaptador del lector v3, y lleva cabezas de zonas (SegmOnto [14] y DocLayNet [15]), de tipo de renglón, de tablas en filas y columnas y de orden aprendido por pares. Se entrenó con XML de colecciones abiertas, páginas sintéticas y un consenso de maestros: Gemini Flash y dots.ocr maquetaron unas 30 000 páginas reales sin anotar, y solo se conservó como zona lo que ambos veían con IoU ≥ 0,5 (22 643 páginas, 132 911 zonas); lo que veía uno solo quedó como región sin pérdida. La versión del paquete es la «enfriada»: se reanudó en el paso 12 005 y se bajó el ritmo con un coseno hasta el paso 15 605.

El orden aprendido se entrenó con hasta 512 elementos por página y en prensa de 200 a 1300 renglones intercalaba columnas. La rama densa es un ajuste corto de la cabeza de orden con renglones detectados por LineasAR, que ordena por bloques y luego por renglones, y pasa LineasAR por teselas cuando el renglón mide menos de 16 px. Si la maquetación ve 200 renglones o más, la página se vuelve a pasar por ella. El umbral se fijó fuera del sellado; en el sellado de páginas v1, el error baja de 44,3 a 42,7 (prensa, de 68,7 a 61,6) y ningún grupo empeora.

La maquetación mínima

Es una red de 2,30 millones de parámetros (MobileNetV2 con un decodificador FPN) sobre la página en gris a lado 1024, más una red de orden de 0,18 millones. Da en un solo grafo los renglones curvos con su línea base (el mismo formato que LineasAR), el tipo de renglón, las zonas gruesas, la orientación de la página y los rasgos para el orden, que es jerárquico: primero los bloques y luego los renglones de cada uno. Se destiló de los maestros grandes sobre 12 706 páginas reales en una A100. En cBAD da F 0,724, frente a 0,459 del detector Mínimo y 0,908 de su maestro. Su recorte enderezado por la línea base es lo que salva las fotos de móvil (error de página de 59 a 16 con los mismos renglones), y su punto débil es el orden en impreso moderno a varias columnas.

La continuidad

Un modelo de n-gramas de caracteres (2,6 MB) elige entre varios órdenes candidatos el que da un texto más verosímil. Se usa con la maquetación mínima y en el modelo grande en páginas sin tablas.

4Orden de lectura

El perceptrón por pares

El orden ligero es un perceptrón de tres capas de 64 sobre 28 rasgos geométricos de cada pareja de renglones (posiciones, desplazamientos, solapes, renglones entre medias en cada columna, separadores), con una puntuación antisimétrica y decodificación por inserciones. Se entrenó con las cajas que da el detector Mínimo en unas 12 000 páginas de PDF nacidos digitales, con el orden del PDF como referencia, en 30 segundos de CPU. Acierta el 95,7 % de los pares en validación y tarda 1,7 ms por página. Su defecto: intercala renglones de columnas que están a la misma altura.

El grafo disperso

El orden por grafo sigue la idea de Wang, Fujii y Bissacco [4], que no publicaron código ni pesos, hecha a nuestra medida. Cada renglón es un nodo y se une a sus 8 vecinos por hueco entre cajas, medido en cuerpos de letra, y al primero que tiene arriba, abajo, a la izquierda y a la derecha, en los dos sentidos. Ve solo la geometría: 14 rasgos por nodo (caja, centro, tamaño en página y en cuerpos, renglones en su fila y a su izquierda, puesto en su columna) y 12 por arista (desplazamientos, huecos, solapes y razones de tamaño). Nunca ve la imagen ni el texto.

Son cuatro capas de paso de mensajes condicionado por la arista, con d = 64. En cada una, el mensaje de j a i actualiza la arista y el nodo suma la media de lo que le llega:

Dos cabezas leen el grafo: una puntúa cada arista dirigida como «j sigue a i» y otra, factorizada y antisimétrica, puntúa cada par como «i va antes que j», $s(i,j)=g(i,j)-g(j,i)$. La decodificación agrupa y ordena: forma cadenas de sucesores de forma voraz, con una entrada y una salida por renglón y sin ciclos, y ordena las cadenas con la media de s entre sus renglones y una búsqueda por inserciones.

Se entrenó en la CPU de un Mac en 45 minutos, con 41 000 páginas y 2,1 millones de renglones: cajas detectadas de impreso moderno con el orden del PDF, prensa real con orden anotado (con peso 10), páginas sintéticas de libro, estructura y fotos de móvil, y SegmOnto y cBAD. Los aumentos imitan al detector: renglones perdidos, partidos en dos trozos, cajas con ruido, y la entrada siempre barajada, porque el orden de los ficheros es el de lectura y la red lo aprendería del índice.

En la vía clásica, el grafo actúa por defecto en las páginas a dos columnas o más (en una revista de teatro a tres columnas, el error de palabras frente a una referencia de Gemini baja de 12,6 a 6,2 %) y el perceptrón en las demás. Usarlo en todas las páginas empeoraba un libro a una columna con nombres de personaje al margen (de 4,32 a 4,87 %). Con la regla por página, llega a todas las páginas que se leen con la clásica; en las que pasan a la mínima y en el modelo grande solo actúa si se pide con AMANUENSIS_ORDEN=gcn.

Columnas y palabra partida

Antes del orden, la vía clásica reconoce las columnas por los comienzos de renglón alineados (al menos 4 y el 15 % de los renglones largos, a 8 cuerpos o más entre sí, para que las sangrías no cuenten), une los trozos de un renglón que el detector partió si hay tinta entre ellos y parte las cajas que cruzan el canal por su franja blanca. Después de leer, un bloque que acaba en palabra partida («comba-») se pone detrás del que la completa («te»), pero solo si la palabra resultante es diez veces más frecuente que su rival, si el bloque empieza arriba de una columna y si no sigue ya a la palabra que lo completa.

Por qué falló a 2,9 grados

La app encontró una página de revista a tres columnas que, enderezada a 2,2° en lugar de 2,4°, pasaba del 11,7 al 22,7 % de error de palabras. El grafo no tenía la culpa: con esas cajas ordenaba bien. Era la regla de la palabra partida, que movía un trozo de renglón mal leído detrás de un «ac-» del final de la página porque «ac» + «ción» da «acción»; con las condiciones del párrafo anterior, el peor caso entre 1,9 y 2,9° bajó del 35,4 al 15,2 %.

Leyendo la página girada sin enderezar, a 2,9° quedaba otro fallo, esta vez del grafo: la cabecera de la tercera columna, troceada por un subrayado a lápiz, se partía en dos cadenas y la primera se colocaba delante de la segunda columna. El arreglo fue una pareja de modelos. El segundo se entrenó con las cajas, ya partidas, giradas en el 75 % de las páginas (normal de σ = 1°, recortada a ±2°). Solo, ganaba a 2,9° pero rompía las guardas en páginas derechas; a partes iguales con el original, una página de los bancos empeoraba. Con pesos 2/3 y 1/3 sobre los logits del sucesor y sobre la matriz de pares, la validación sube de 97,20 a 97,26 % de pares y de 60,2 a 60,8 % de páginas perfectas, los seis bancos de orden quedan igual y el caso de 2,9° baja del 26,4 al 15,3 %.

5Geometría de la página

Orientación

Primero se aplica la orientación EXIF de las fotos. Después se busca el ángulo libre, módulo 90°, por la nitidez del perfil de tinta en una miniatura, y se afina con la dirección media de las líneas base detectadas. El eje (renglones horizontales o verticales) lo decide el detector en 0° y en 90°: gana el giro con más renglones largos, rectos y paralelos. Entre 0° y 180° decide la asimetría de los renglones latinos, griegos y cirílicos, que tienen más ascendentes que descendentes y una línea base plana; si no es clara, decide una lectura de prueba.

La medida final de la 1.0 encontró que esta orientación giraba por error alrededor del 10 % de las páginas del examen v2, casi todas de otras escrituras y fotos reales. La política vigente es prudente: con una confianza de lectura de 0,9 o más en la página tal cual no se prueba ningún giro, y un giro de 90, 180 o 270° solo se acepta si el lector lee la página girada con una confianza media de 0,75 o más y al menos 0,1 por encima de la página tal cual. Los umbrales se eligieron en DEV: ningún giro de más en 323 páginas derechas.

Enderezado

El ángulo grueso lo puede ganar el perfil que no es el de los renglones: los bordes rectos del escáner dan un pico nítido en 0° aunque el texto esté torcido. Por eso manda el pico del perfil de los renglones cuando está a 2° o más del elegido y es 1,25 veces más nítido. Hasta 5° se gira sin ampliar el lienzo. Por debajo de 2° no se corrige: el detector Mínimo lee bien la página algo torcida, y enderezar entera una hoja combada junta renglones.

Renglones curvos

En la fotocopia de un libro abierto los renglones suben hacia el lomo y la caja recta corta en diagonal dos renglones. El rectificado sigue la tinta del renglón tira a tira, cada tira cerca de la anterior, ajusta una curva suave a su centro y rehace el recorte columna a columna. Si el renglón se desvía más de 0,15 cuerpos, se relee enderezado y gana la lectura más segura. En una fotocopia curvada fue la mayor mejora (error de palabras de 4,08 a 2,44 %).

Doble página

Un libro abierto escaneado en una sola imagen apaisada (ancho entre alto de 1,2 o más) se busca partir por el canal. La medida es el número de cambios entre tinta y papel por columna: alto donde hay texto y casi nulo en el canal, sea blanco o la sombra del lomo. El canal se busca en la franja central (del 38 al 62 % del ancho) y tiene que bajar del 15 % de los cambios de la hoja más pobre.

Una página sola escaneada de lado también es apaisada, y un blanco entre párrafos a media altura parece un canal. La regla que lo distingue compara, en cada mitad, la nitidez del perfil de filas con la del de columnas (media del cuadrado de la diferencia entre vecinos, dividida por la media del perfil al cuadrado). Si la mejor mitad queda por debajo de 0,75, los renglones van en vertical y no se parte. Con ella se partieron las 32 dobles páginas de los bancos y ninguna de las 11 páginas giradas.

6Después de leer

Después de leer, la página se pule sin tocar el modelo y sin inventar: cada cambio tiene que salir de la geometría, de las series del propio documento o de lo que el lector vio con su probabilidad.

Texto de lectura y texto fiel

Markdown, texto y HTML salen por defecto como texto de lectura: sin folios, cabeceras corrientes, signaturas ni restos del escaneo, con las notas al final. El mobiliario se reconoce por su posición (en el 12 % de arriba o de abajo), por la letra espaciada y por repetirse en el documento. Un párrafo sigue en el renglón siguiente si el anterior llega al margen (el 90 % del ancho del percentil 75) o acaba en guion, y el siguiente empieza en minúscula; así se unen también entre páginas y entre las dos hojas de una doble página. El verso se reconoce porque los renglones son casi todos cortos y desiguales, y sale renglón a renglón. Con --fiel, la página tal cual, con el mobiliario en comentarios; TEI, PAGE, ALTO, hOCR y JSON lo conservan siempre.

Series y signos

Las series se deducen del documento: un «m)» entre «II)» y «IV)» es «III)», un «1.» entre 1.4.2 y 1.6 es 1.5, los ejemplos «(n)» son correlativos, los números de verso crecen con los renglones y los nombres de personaje al margen se corrigen por el más frecuente. Las comillas que el lector ve pero calla, porque el blanco les gana por poco, se escriben si pasan del 8 % de probabilidad en su hueco (donde no hay ninguna, la probabilidad es prácticamente cero); la que le falta a una pareja se pone donde más probabilidad tiene. La raya media y la larga se deciden midiendo el trazo en la imagen con los anchos del propio documento, porque la raya larga de un libro mide lo que la media de otro.

Corrección léxica guiada por la CTC

Una palabra dudosa que no está en el léxico solo se cambia por una candidata que exista y que el lector vea casi igual de bien en su tramo de fotogramas. Las candidatas salen del haz de la CTC sobre esos fotogramas, de una edición, de dos confusiones típicas de OCR (u por ti, n por ri, m por rn) y de las variantes de tilde. La puntuación es:

donde f es la frecuencia de la candidata. Además, el corrector aprende las confusiones sistemáticas de cada libro (una letra leída siempre igual de mal en al menos cuatro palabras distintas y el 5 % de las que la tienen) y para ellas no exige el acuerdo de la CTC; y lo que el documento lee con seguridad dos veces o más protege el vocabulario técnico (autoléxico). La lengua se detecta en cada página con las 120 palabras funcionales de cada léxico, y en cada renglón por su entorno. Las lenguas sin léxico y los textos antiguos (con ſ y compañía) solo se corrigen con el autoléxico.

Los léxicos son de las 31 lenguas: suman las frecuencias de los subtítulos de OpenSubtitles (FrequencyWords [21]) y, en 14 lenguas, las de la Wikipedia (wikipedia-word-frequency [22]), cada fuente llevada a mil millones de palabras, con 800 000 formas como mucho y una higiene que descarta las faltas de los subtítulos. El japonés no se corrige palabra a palabra porque no separa palabras con espacios.

7La voz

Amanuensis Voz parte del codificador de audio de EmbeddingGemma 2: un Conformer de 12 capas de 1024 dimensiones, con submuestreo de 4 (una ficha cada 40 ms) y 305,6 millones de parámetros. Es causal: atiende por bloques de 12 fichas con 12 de contexto a la izquierda y ninguno a la derecha. La cabeza, por eso, es bidireccional: 8 bloques de transformador con atención local y convolución (44 millones de parámetros), con una CTC intermedia de peso 0,3, dos salidas de 16 384 piezas (texto plano y texto con mayúsculas y puntuación) y una cabeza de idioma. El codificador lleva un LoRA de rango 32 en las 12 capas, fundido en los pesos al exportar. Los tiempos de cada palabra salen de la alineación de la CTC.

Los datos son abiertos: YODAS-Granary y YODAS2 manual (CC BY 3.0), Common Voice 17 (CC0), Multilingual LibriSpeech (CC BY 4.0), VoxPopuli (CC0), el entrenamiento de FLEURS [20] (CC BY 4.0) y el corpus de euskera de HiTZ (CC BY 4.0). Se prepararon 28 740 horas en 40 lenguas, y la tirada principal, 16 horas en cuatro RTX 4090, vio unas 21 000 (0,7 épocas). Los modelos de lengua son KenLM [19] de 4-gramas en 37 lenguas, de Common Voice y la Wikipedia; chino, japonés y tailandés no tienen modelo de palabras. El paquete, en 8 bits con calibración estática (481 MB), da la misma WER que PyTorch (10,13 frente a 10,12 con modelo de lengua) y corre entre 37 y 45 veces más deprisa que el tiempo real en la CPU de un Mac.

Gana en euskera, gallego y catalán de Common Voice y en lenguas que Whisper [17] lee mal (bielorruso, georgiano, maltés, suajili, tamil). En las lenguas grandes, español incluido, Whisper y Parakeet [18] son claramente mejores. Sin modelo de lengua la WER sube entre un 35 y un 45 % relativo, y el codificador causal pierde sílabas en el habla rápida.

8Entrenamiento

Datos de los lectores de texto

Las rondas del lector v3 añadieron más datos, que se describen en el registro del proyecto y todavía no en la ficha: líneas medievales de CoMMA [8] (CC BY 4.0) releídas por el lector anterior y aceptadas solo con acuerdo y confianza altos; unos 24 000 objetos manuscritos españoles con licencia abierta cosechados por Europeana; unas 20 000 líneas de cursiva documental hispánica etiquetadas por Gemini y filtradas por acuerdo; casi dos millones de líneas multilingües de fábrica, sintéticas y de PDF; y letra a mano contemporánea, sintética (800 000 líneas con 248 tipos manuscritos OFL en 9 lenguas) y real con licencia abierta. Los conjuntos de letra a mano no comerciales (IAM y otros) solo entraron en una variante que se descartó.

Datos sintéticos

Las líneas históricas se dibujan al vuelo dentro del cargador de datos, sin ocupar disco, con 88 tipos libres (góticas, romanas antiguas, humanísticas, letra de escribano de los siglos XVIII y XIX) y Junicode para los signos de MUFI que falten. Los textos son obras de Gutenberg (latín, castellano antiguo, catalán, portugués, italiano y francés) y transcripciones de manuscritos, con un «envejecimiento» opcional que introduce ſ, u por v, ç, abreviaturas con tilde y signos como ꝑ, ꝓ o ⁊. La validación sintética usa obras distintas, y se quita de la reserva todo texto que comparta un 5-grama con los exámenes. A las líneas se les aplica deformación elástica, inclinación, ondulación de la línea base, tinta desvaída o corrida, traspaso del reverso, manchas y tono de pergamino. El mecanografiado sale de siete tipos de máquina libres, y las fotos de móvil y los escaneos malos (fotocopia, fax, microfilm, baja resolución) son aumentos sobre líneas reales.

Recetas y rondas

El lector histórico v2b96 fijó la receta: líneas a 96 px, LoRA de rango 32 en las capas 1 a 14 y el incrustado de parches, cabeza de 512 condicionada por la convención, media exponencial de pesos (0,999) y torch.compile por capa; 16 000 pasos en una A100. Subir de 32 a 64 y a 96 px bajó el error de validación en manuscritos de 24,9 a 15,3 y a 13,9; el LoRA frente a entrenar solo la cabeza, unos 6 puntos. Antes del v3 se probaron cuatro variantes durante 2000 pasos: el alto de 128 ganaba un 3 % relativo a 1,67 veces el coste, y ni el rango 64 ni una cabeza mayor desde cero ganaban.

El v3 se entrenó 40 000 pasos desde v2b96 en cuatro A100, con lote de 4 × 64 y ritmos de 8·10⁻⁴ en la cabeza y 3·10⁻⁴ en el LoRA, y con CoMMA incorporado en la segunda fase. Después vinieron rondas cortas de ajuste: la ronda 2 (6000 pasos, manos hispánicas y letra contemporánea abierta) mejoró la letra moderna pero empeoró el latín medieval de CMMHWR; la ronda 3 (2000 pasos desde la 2, con el impreso moderno latino al 15 % como mínimo y un aumento de baja resolución extrema) dio la mejor media sola, con la misma pérdida medieval.

La salida fue interpolar pesos sin entrenar. La base es la media, al 50 %, del v3 y la ronda 3: conserva el CMMHWR del v3 y casi toda la mejora de la ronda 3.

La ronda 4, con las líneas hispánicas de Gemini en convención desarrollada, empeoró otra vez lo medieval, y el diagnóstico encontró la causa: al arrancar desde una base, el vector de la convención «desarrollada» se creaba a cero, y lo desarrollado se aprendía en los pesos compartidos y contaminaba la salida grafemática (los signos de abreviatura del ibérico medieval caían de 884 en la referencia a 279). La ronda 5 hereda ese vector de la base: con los mismos datos, el ibérico queda en 8,99. El lector definitivo es la media al 50 % de la base y la ronda 5.

Destilación a Ligero y Mínimo

Ligero y Mínimo son alumnos del lector grande, con la misma mezcla de datos y las mismas convenciones, y se entrenan a la vez con los mismos lotes. La primera versión hizo 80 000 pasos de 256 líneas; la segunda se re-destiló con pseudoetiquetas del v3 sobre CoMMA, 30 000 pasos con una guardia: no se guarda ningún punto de control cuya CER de impreso moderno empeore más de un 2 %. La tercera, la de la 1.0, añadió impreso «de la vida real» (fotos de móvil, fotocopias, fax, microfilm, baja resolución), mecanografiado sintético y facsímiles escaneados, con guardias de impreso moderno, manuscritos, mecanografiado, baja resolución y foto. Su maestro fue la ronda 2 y no el lector definitivo, porque la destilación se lanzó antes de elegirlo.

Cómputo

9Evaluación

El examen sellado

El examen de líneas tiene 15 537 líneas en 43 categorías y ocho grupos (impreso moderno y antiguo, manuscrito medieval y moderno, letra a mano de los siglos XX y XXI, prensa, formularios y escaneos degradados), de 51 fuentes, ninguna con más del 10 % de las líneas; aparte, el bloque de CMMHWR, con 6933 líneas: 22 470 en total. Las decisiones se tomaron en un examen de desarrollo de 1870 líneas y 114 páginas; el sellado solo se abre para medir. Hay además dos exámenes de páginas: el v1, de 654 páginas, y el v2, de 565 páginas en diez maquetaciones, con geometría de renglones, zonas y orden, seleccionadas por una regla fija sin mirar resultados.

Los datos se cruzan con los exámenes por documento, por 5-gramas de texto, por sha1 de texto y de imagen y por huella perceptual. Antes de publicar la 1.0, una auditoría cruzó con todos los bancos el linaje entero de las piezas publicadas: 104 ficheros de datos y 12 mezclas, 60,6 GB. Aparecieron 43 líneas del sellado ya vistas (0,19 %), y las cifras se dan sin ellas (la media del lector grande pasa de 14,76 a 14,78). Las pruebas oficiales de CATMuS Modern, Tridis y Esposalles, y el 90 % de la de CATMuS Medieval, habían entrado en el entrenamiento por conversores que repartían por su cuenta en lugar de usar la partición oficial: sobre ellas no se da ninguna cifra.

Las cifras de página usan dos métricas: el CER clásico, que compara la página entera como una cadena y castiga mucho el orden (un renglón fuera de sitio cuesta dos veces su longitud), y una aproximación de la FCA [5], independiente del orden. Las de la tabla siguiente son del paquete tal como se publicó, no de la cadena de laboratorio.

Bancos estándar

En CMMHWR [11], con nuestros recortes de renglón, Amanuensis quedaría hacia el tercer o cuarto puesto de la tarea 1 y por delante de Kraken en las tres tareas; el PP-OCRv6 que Kiessling ajustó a CATMuS [6] le gana en francés, latín y español, y Amanuensis lo supera en checo.

En documentos modernos de página entera, Amanuensis queda muy por detrás: en OmniDocBench [12] su puntuación es de al menos 37,0 (no escribe LaTeX, así que la parte de fórmulas cuenta como cero), frente a 78-96 de los sistemas publicados; en olmOCR-Bench [13], 37,5 frente a 72-82. En renglones, LineasAR quedaría tercero o cuarto en cBAD 2019, por detrás del ganador (0,931) y de Orli de Kiessling (0,934).

Lo que hace mal

• Orden en prensa y tablas. Es la mayor pérdida de página. En la prensa del examen v1, 61,6 de CER con la rama densa frente a 52,5 de Tesseract, aunque lee mejor (FCA 17,5 frente a 24,4 en el v2).
• Letra a mano actual. Gemma 4 E4B, 7,36 en líneas, frente a 14,9; en IAM, 14,8 frente a 2-3 de los especialistas, que entrenan con IAM.
• Kurrent alemán (READ 2016): 31,5 frente a 3,9-4,8.
• Recibos y fotos de móvil reales: FCA 51,6 frente a 20,2 de Gemma 4 E4B.
• Otras escrituras de página: 67,7, empate con Tesseract, con renglones flojos.
• El paquete frente al laboratorio: en el examen v2, FCA 35,0 frente a 30,5 de la cadena PyTorch, sobre todo por giros equivocados de la orientación y por la prensa.
• Ligero: no sirve para manuscritos (50 en medieval), otras escrituras ni prensa de punta a punta.
• Gemini 3.8 Flash, en una muestra de 108 páginas del v2: FCA 22,6 frente a 27,2, y mucho mejor en orden.

10Velocidad y despliegue

El paquete

El paquete de Python no usa PyTorch: solo ONNX Runtime [23]. El modelo grande va en 8 bits por pesos (MatMulNBits, bloques de 32), que en un banco de 320 líneas da el mismo error que fp32 (6,549); la int8 estática calibrada pierde algo y solo rinde en x86. En el Mac, el lector y la maquetación van en Core ML: un ML Program fp16 multifunción con una función por cubo de ancho de renglón, en la GPU, porque los cubos grandes no compilaban para el Neural Engine. En 13 páginas variadas, el CER frente a la transcripción de referencia es 34,98 con ONNX y 34,99 con ONNX y Core ML; en un banco de 320 líneas, 6,11 frente a 6,06 de PyTorch.

La demo del navegador

La demo corre en un trabajador con ONNX Runtime Web: Ligero y Mínimo en WebAssembly con cuatro hilos (con las cabeceras COOP y COEP), y los lectores grandes de la versión anterior (el histórico y el multilingüe) en WebGPU con pesos de 4 bits, o en WebAssembly con 8 bits. Todo lo de la 1.1 que tiene sentido en el navegador está portado a TypeScript con paridad exacta frente a Python, comprobada con volcados de páginas reales: la lectura voraz con los signos (641 de 641 renglones), el orden por grafo (49 de 49 permutaciones), las columnas, el rectificado, las rayas y las salidas Markdown y texto, byte a byte. Los léxicos se sirven ya construidos, uno por lengua y solo los de las lenguas que aparecen en la página.

La app

La app de iPhone y Android lee con Ligero 3 o Mínimo 3, con los pesos dentro de la app y sin red. Su motor está escrito en Rust sobre ONNX Runtime en CPU y se enlaza con la misma copia de ONNX Runtime que trae la app. Core ML no sirve aquí porque no admite las formas variables de los renglones, y XNNPACK iba más lento. Queda de reserva un motor en un WebView oculto con el TypeScript de la demo. Para que todas las plataformas lean lo mismo, la decodificación y la reducción de la imagen también se hacen en Rust: antes, cada sistema recomprimía la foto a su manera y cambiaba entre el 10 y el 64 % de los píxeles. Con la entrada unificada, las 9 páginas de prueba dan en el simulador los mismos renglones que el motor de referencia.

11Licencias

El código es Apache 2.0. Los pesos de Amanuensis y de Ligero son de uso no comercial porque parte de sus datos de entrenamiento lo es: los incunables castellanos de HSMS y las escrituras notariales de OHG tienen licencia CC BY-NC 4.0, y toda la maquetación del modelo grande hereda el LoRA del lector v3, que se entrenó con ellos. El modelo de continuidad (continuidad.npz) también es de uso no comercial, por HSMS. Con un lector entrenado sin datos no comerciales, el lector grande podría pasar a Apache 2.0; la maquetación seguiría siendo no comercial mientras su adaptador parta del v3.

Son Apache 2.0 los pesos de Amanuensis Voz, del detector Mínimo, del orden ligero y del orden por grafo. Los modelos de lengua de la voz, los perfiles de lengua y los léxicos son CC BY-SA 4.0. El codificador de partida es el de EmbeddingGemma 2, con los términos de Google. Todas las licencias y la atribución completa.

Referencias

1. A. Graves, S. Fernández, F. Gomez y J. Schmidhuber (2006). «Connectionist Temporal Classification: Labelling Unsegmented Sequence Data with Recurrent Neural Networks». ICML 2006. www.cs.toronto.edu/~graves/icml_2006.pdf
2. E. J. Hu et al. (2021). «LoRA: Low-Rank Adaptation of Large Language Models». arXiv 2106.09685. arxiv.org/abs/2106.09685
3. Google. EmbeddingGemma 2, ficha del modelo. huggingface.co/google/embeddinggemma-2
4. C. Wang, Y. Fujii y A. Bissacco (2023). «Text Reading Order in Uncontrolled Conditions by Sparse Graph Segmentation». arXiv 2305.02577. arxiv.org/abs/2305.02577
5. C. Clausner, S. Pletschacher y A. Antonacopoulos (2020). «Flexible Character Accuracy Measure for Reading-Order-Independent Evaluation». Pattern Recognition Letters 131. doi.org/10.1016/j.patrec.2020.02.001
6. B. Kiessling (2026). «A Free Lunch? Adapting PP-OCRv6 for Historical Text Recognition». arXiv 2609.20064. arxiv.org/abs/2609.20064
7. T. Clérice et al. CATMuS Medieval: un conjunto de datos de manuscritos medievales latinos y romances. huggingface.co/datasets/CATMuS/medieval
8. CoMMA: corpus de manuscritos medievales con líneas y transcripción automática (CC BY 4.0). huggingface.co/comma-project
9. L. Quirós, L. Serrano, V. Bosch et al. (2018). «Oficio de Hipotecas de Girona. A dataset of Spanish notarial deeds (18th Century)». Zenodo 1322666. zenodo.org/records/1322666
10. M. Diem, F. Kleber, R. Sablatnig y B. Gatos (2019). «cBAD: ICDAR2019 Competition on Baseline Detection». ICDAR 2019. doi.org/10.1109/ICDAR.2019.00255
11. CMMHWR 2026 (ICDAR 2026), tarea 1: reconocimiento multilingüe de manuscritos medievales, en Codabench (competiciones 15093-15095). www.codabench.org/competitions/15093
12. OmniDocBench: banco de análisis de documentos de página entera. github.com/opendatalab/OmniDocBench
13. J. Poznanski et al. (2025). olmOCR 2 y olmOCR-Bench. arXiv 2510.19817. arxiv.org/abs/2510.19817
14. SegmOnto: vocabulario controlado para la maquetación de documentos históricos. segmonto.github.io
15. B. Pfitzmann et al. (2022). «DocLayNet: A Large Human-Annotated Dataset for Document-Layout Analysis». KDD 2022. arxiv.org/abs/2206.01062
16. Medieval Unicode Font Initiative (MUFI). mufi.info
17. A. Radford et al. (2022). «Robust Speech Recognition via Large-Scale Weak Supervision». arXiv 2212.04356. arxiv.org/abs/2212.04356
18. NVIDIA. Parakeet TDT 0.6B v3, ficha del modelo. huggingface.co/nvidia/parakeet-tdt-0.6b-v3
19. K. Heafield (2011). «KenLM: Faster and Smaller Language Model Queries». WMT 2011. kheafield.com/code/kenlm
20. A. Conneau et al. (2022). «FLEURS: Few-shot Learning Evaluation of Universal Representations of Speech». arXiv 2205.12446. arxiv.org/abs/2205.12446
21. H. Dave. FrequencyWords: listas de frecuencias de OpenSubtitles 2018 (contenido CC BY-SA 4.0). github.com/hermitdave/FrequencyWords
22. I. Semenov. wikipedia-word-frequency (texto de la Wikipedia, CC BY-SA 4.0). github.com/IlyaSemenov/wikipedia-word-frequency
23. Microsoft. ONNX Runtime y ONNX Runtime Web. onnxruntime.ai
24. Datalab. Indra OCR (usado solo como rival). github.com/datalab-to/indra

Cómo citarlo

Si usas Amanuensis en un trabajo, cita el informe y, si hace falta, la versión del código.

@techreport{saorin2026amanuensis,
  author      = {Saorín Ferrer, José Luis},
  title       = {Amanuensis: lectura de documentos históricos
                 y de voz sobre EmbeddingGemma 2},
  institution = {amanuensis.joseluissaorin.com},
  type        = {Informe técnico},
  year        = {2026},
  month       = oct,
  note        = {Versión 1.1.1},
  url         = {https://amanuensis.joseluissaorin.com/tecnica/}
}

@software{saorin2026amanuensis_codigo,
  author  = {Saorín Ferrer, José Luis},
  title   = {Amanuensis},
  version = {1.1.1},
  year    = {2026},
  license = {Apache-2.0},
  url     = {https://github.com/joseluissaorin/amanuensis}
}