Universidad Internacional de La Rioja

Escuela Superior de Ingeniería y

Tecnología

Máster Universitario en Inteligencia artificial

Optimización de Hiperparámetros OCR con Ray Tune para Documentos Académicos en Español

Trabajo fin de estudio presentado por: | Sergio Jiménez Jiménez
Tipo de trabajo: | Desarrollo Software
Director/a: | Javier Rodrigo Villazón Terrazas
Fecha: | 06.10.2025

Resumen

El presente Trabajo Fin de Máster aborda la optimización de sistemas de Reconocimiento Óptico de Caracteres (OCR) basados en inteligencia artificial para documentos en español, específicamente en un entorno con recursos computacionales limitados donde el fine-tuning de modelos no es viable. El objetivo principal es identificar la configuración óptima de hiperparámetros que maximice la precisión del reconocimiento de texto sin requerir entrenamiento adicional de los modelos. Se realizó un estudio comparativo de tres soluciones OCR de código abierto: EasyOCR, PaddleOCR (PP-OCRv5) y DocTR, evaluando su rendimiento mediante las métricas estándar CER (Character Error Rate) y WER (Word Error Rate) sobre un corpus de documentos académicos en español. Tras identificar PaddleOCR como la solución más prometedora, se procedió a una optimización sistemática de hiperparámetros utilizando Ray Tune con el algoritmo de búsqueda Optuna, ejecutando 64 configuraciones diferentes. Los resultados demuestran que la optimización de hiperparámetros logró una mejora significativa del rendimiento: el CER se redujo de 7.78% a 1.49% (mejora del 80.9% en reducción de errores), alcanzando una precisión de caracteres del 98.51%. El hallazgo más relevante fue que el parámetro `textline_orientation` (clasificación de orientación de línea de texto) tiene un impacto crítico, reduciendo el CER en un 69.7% cuando está habilitado. Adicionalmente, se identificó que el umbral de detección de píxeles (`text_det_thresh`) presenta una correlación negativa fuerte (-0.52) con el error, siendo el parámetro continuo más influyente. Este trabajo demuestra que es posible obtener mejoras sustanciales en sistemas OCR mediante optimización de hiperparámetros, ofreciendo una alternativa práctica al fine-tuning cuando los recursos computacionales son limitados.

Palabras clave: OCR, Reconocimiento Óptico de Caracteres, PaddleOCR, Optimización de Hiperparámetros, Ray Tune, Procesamiento de Documentos, Inteligencia Artificial

Abstract

This Master's Thesis addresses the optimization of Artificial Intelligence-based Optical Character Recognition (OCR) systems for Spanish documents, specifically in a resource-constrained environment where model fine-tuning is not feasible. The main objective is to identify the optimal hyperparameter configuration that maximizes text recognition accuracy without requiring additional model training. A comparative study of three open-source OCR solutions was conducted: EasyOCR, PaddleOCR (PP-OCRv5), and DocTR, evaluating their performance using standard CER (Character Error Rate) and WER (Word Error Rate) metrics on a corpus of academic documents in Spanish. After identifying PaddleOCR as the most promising solution, systematic hyperparameter optimization was performed using Ray Tune with the Optuna search algorithm, executing 64 different configurations. Results demonstrate that hyperparameter optimization achieved significant performance improvement: CER was reduced from 7.78% to 1.49% (80.9% error reduction), achieving 98.51% character accuracy. The most relevant finding was that the `textline_orientation` parameter (text line orientation classification) has a critical impact, reducing CER by 69.7% when enabled. Additionally, the pixel detection threshold (`text_det_thresh`) was found to have a strong negative correlation (-0.52) with error, being the most influential continuous parameter. This work demonstrates that substantial improvements in OCR systems can be obtained through hyperparameter optimization, offering a practical alternative to fine-tuning when computational resources are limited.

Keywords: OCR, Optical Character Recognition, PaddleOCR, Hyperparameter Optimization, Ray Tune, Document Processing, Artificial Intelligence

Índice de contenidos

1. Introducción. 1

1.1. Motivación. 1

1.2. Planteamiento del trabajo. 3

1.3. Estructura del trabajo. 3

2. Contexto y estado del arte. 4

2.1. Contexto del problema. 4

2.2. Estado del arte. 4

2.3. Conclusiones. 5

3. Objetivos concretos y metodología de trabajo. 6

3.1. Objetivo general 6

3.2. Objetivos específicos. 7

3.3. Metodología del trabajo. 8

4. D esarrollo específico de la contribución. 9

5. Conclusiones y trabajo futuro. 13

5.1. Conclusiones. 13

5.2. Líneas de trabajo futuro. 13

Referencias bibliográficas. 14

Anexo A. Código fuente y datos analizados 15

Índice de figuras

Índice de tablas

# 1. Introducción

Este capítulo presenta la motivación del trabajo, identificando el problema a resolver y justificando su relevancia. Se plantea la pregunta de investigación central y se describe la estructura del documento.

## Motivación

El Reconocimiento Óptico de Caracteres (OCR) es una tecnología fundamental en la era de la digitalización documental. Su capacidad para convertir imágenes de texto en datos editables y procesables ha transformado sectores como la administración pública, el ámbito legal, la banca y la educación. Según estimaciones del sector, el mercado global de OCR alcanzó los 13.4 mil millones de dólares en 2023, con proyecciones de crecimiento continuo impulsado por la transformación digital empresarial (Grand View Research, 2023). Sin embargo, a pesar de los avances significativos impulsados por el aprendizaje profundo, la implementación práctica de sistemas OCR de alta precisión sigue presentando desafíos considerables.

### El contexto de la digitalización documental

La digitalización de documentos ha pasado de ser una opción a una necesidad estratégica para organizaciones de todos los tamaños. Los beneficios son múltiples: reducción del espacio físico de almacenamiento, facilidad de búsqueda y recuperación, preservación del patrimonio documental, y habilitación de flujos de trabajo automatizados. Sin embargo, la mera conversión de papel a imagen digital no aprovecha plenamente estas ventajas; es necesario extraer el texto contenido en los documentos para permitir su indexación, análisis y procesamiento automatizado.

El OCR actúa como puente entre el mundo físico del documento impreso y el mundo digital del texto procesable. Su precisión determina directamente la calidad de los procesos downstream: un error de reconocimiento en un nombre propio puede invalidar una búsqueda; un dígito mal reconocido en una factura puede causar discrepancias contables; una palabra mal interpretada en un contrato puede alterar su significado legal.

### Desafíos específicos del español

El procesamiento de documentos en español presenta particularidades que complican el reconocimiento automático de texto. Los caracteres especiales propios del idioma (la letra ñ, las vocales acentuadas á, é, í, ó, ú, la diéresis ü, y los signos de puntuación invertidos ¿ y ¡) no están presentes en muchos conjuntos de entrenamiento internacionales, lo que puede degradar el rendimiento de modelos preentrenados predominantemente en inglés.

La Tabla 1 resume los principales desafíos lingüísticos del OCR en español:

Tabla 1. Desafíos lingüísticos específicos del OCR en español.

Desafío | Descripción | Impacto en OCR
Caracteres especiales | ñ, á, é, í, ó, ú, ü, ¿, ¡ | Confusión con caracteres similares (n/ñ, a/á)
Palabras largas | Español permite compuestos largos | Mayor probabilidad de error por carácter
Abreviaturas | Dr., Sra., Ud., etc. | Puntos internos confunden segmentación
Nombres propios | Tildes en apellidos (García, Martínez) | Bases de datos sin soporte Unicode

Fuente: Elaboración propia.

Además de los aspectos lingüísticos, los documentos académicos y administrativos en español presentan características tipográficas que complican el reconocimiento: variaciones en fuentes entre encabezados, cuerpo y notas al pie; presencia de tablas con bordes y celdas; logotipos institucionales; marcas de agua; y elementos gráficos como firmas o sellos. Estos elementos generan ruido que puede propagarse en aplicaciones downstream como la extracción de entidades nombradas o el análisis semántico.

### La brecha entre investigación y práctica

Los modelos OCR basados en redes neuronales profundas, como los empleados en PaddleOCR, EasyOCR o DocTR, ofrecen un rendimiento impresionante en benchmarks estándar. PaddleOCR, por ejemplo, reporta tasas de precisión superiores al 97% en conjuntos de datos como ICDAR 2015 (Du et al., 2020). No obstante, estos resultados en condiciones controladas no siempre se trasladan a documentos del mundo real.

La adaptación de modelos preentrenados a dominios específicos típicamente requiere fine-tuning con datos etiquetados del dominio objetivo y recursos computacionales significativos. El fine-tuning de un modelo de reconocimiento de texto puede requerir decenas de miles de imágenes etiquetadas y días de entrenamiento en GPUs de alta capacidad. Esta barrera técnica y económica excluye a muchos investigadores y organizaciones de beneficiarse plenamente de estas tecnologías.

La Tabla 2 ilustra los requisitos típicos para diferentes estrategias de mejora de OCR:

Tabla 2. Comparación de estrategias de mejora de modelos OCR.

Estrategia | Datos requeridos | Hardware | Tiempo | Expertise
Fine-tuning completo | >10,000 imágenes etiquetadas | GPU (≥16GB VRAM) | Días-Semanas | Alto
Fine-tuning parcial | >1,000 imágenes etiquetadas | GPU (≥8GB VRAM) | Horas-Días | Medio-Alto
Transfer learning | >500 imágenes etiquetadas | GPU (≥8GB VRAM) | Horas | Medio
Optimización de hiperparámetros | <100 imágenes de validación | CPU suficiente | Horas | Bajo-Medio

Fuente: Elaboración propia.

### La oportunidad: optimización sin fine-tuning

La presente investigación surge de una necesidad práctica: optimizar un sistema OCR para documentos académicos en español sin disponer de recursos GPU para realizar fine-tuning. Esta restricción, lejos de ser una limitación excepcional, representa la realidad de muchos entornos académicos y empresariales donde el acceso a infraestructura de cómputo avanzada es limitado.

La hipótesis central de este trabajo es que los modelos OCR preentrenados contienen capacidades latentes que pueden activarse mediante la configuración adecuada de sus hiperparámetros de inferencia. Parámetros como los umbrales de detección de texto, las opciones de preprocesamiento de imagen, y los filtros de confianza de reconocimiento pueden tener un impacto significativo en el rendimiento final, y su optimización sistemática puede aproximarse a los beneficios del fine-tuning sin sus costes asociados.

Esta oportunidad se ve reforzada por la disponibilidad de frameworks modernos de optimización de hiperparámetros como Ray Tune (Liaw et al., 2018) y algoritmos de búsqueda eficientes como Optuna (Akiba et al., 2019), que permiten explorar espacios de configuración de manera sistemática y eficiente.

## Planteamiento del trabajo

### Formulación del problema

El problema central que aborda este trabajo puede formularse de la siguiente manera:

¿Es posible mejorar significativamente el rendimiento de modelos OCR preentrenados para documentos en español mediante la optimización sistemática de hiperparámetros, sin requerir fine-tuning ni recursos GPU?

Este planteamiento parte de una observación fundamental: los sistemas OCR modernos exponen múltiples parámetros configurables que afectan su comportamiento durante la inferencia. Estos parámetros incluyen umbrales de detección, opciones de preprocesamiento, y filtros de calidad. En la práctica habitual, estos parámetros se dejan en sus valores por defecto, asumiendo que fueron optimizados por los desarrolladores del modelo. Sin embargo, los valores por defecto representan compromisos generales que pueden no ser óptimos para dominios específicos.

### Preguntas de investigación

Este planteamiento se descompone en las siguientes cuestiones específicas:

PI1. Selección de modelo base: ¿Cuál de las soluciones OCR de código abierto disponibles (EasyOCR, PaddleOCR, DocTR) ofrece el mejor rendimiento base para documentos en español?

Esta pregunta es fundamental porque la elección del modelo base determinará el punto de partida para la optimización. Un modelo con mejor rendimiento inicial puede ofrecer mayor margen de mejora o, alternativamente, estar ya cerca de su límite de optimización.

PI2. Impacto de hiperparámetros: ¿Qué hiperparámetros del pipeline OCR tienen mayor influencia en las métricas de error (CER, WER)?

Identificar los parámetros más influyentes permite focalizar el esfuerzo de optimización y proporciona insights sobre el funcionamiento interno del sistema. Parámetros con alta correlación con las métricas de error son candidatos prioritarios para ajuste.

PI3. Optimización automatizada: ¿Puede un proceso de búsqueda automatizada de hiperparámetros (mediante Ray Tune/Optuna) encontrar configuraciones que superen significativamente los valores por defecto?

Esta pregunta evalúa la viabilidad práctica de la metodología propuesta. "Significativamente" se define operacionalmente como una reducción del CER de al menos 50% respecto al baseline, un umbral que representaría una mejora sustancial en la calidad del texto reconocido.

PI4. Viabilidad práctica: ¿Son los tiempos de inferencia y los recursos requeridos compatibles con un despliegue en entornos con recursos limitados?

Una solución técnicamente superior pero impracticable tiene valor limitado. Esta pregunta ancla la investigación en consideraciones del mundo real.

### Alcance y delimitación

Este trabajo se centra específicamente en:

Tabla 3. Delimitación del alcance del trabajo.

Aspecto | Dentro del alcance | Fuera del alcance
Tipo de documento | Documentos académicos digitales (PDF) | Documentos escaneados, manuscritos
Idioma | Español | Otros idiomas
Modelos | EasyOCR, PaddleOCR, DocTR | Soluciones comerciales (Google Cloud Vision, AWS Textract)
Método de mejora | Optimización de hiperparámetros | Fine-tuning, aumento de datos
Hardware | Ejecución en CPU | Aceleración GPU

Fuente: Elaboración propia.

### Relevancia y beneficiarios

La relevancia de este problema radica en su aplicabilidad inmediata. Una metodología reproducible para optimizar OCR sin fine-tuning beneficiaría a múltiples grupos:

Investigadores académicos: Quienes procesan grandes volúmenes de documentos para análisis de contenido, revisiones sistemáticas de literatura, o estudios bibliométricos. Un OCR más preciso reduce el tiempo de corrección manual y mejora la calidad de los análisis downstream.

Instituciones educativas: Universidades y centros de investigación que digitalizan archivos históricos, actas administrativas, o materiales docentes. La preservación del patrimonio documental requiere transcripciones precisas.

Pequeñas y medianas empresas: Organizaciones que automatizan flujos documentales (facturas, contratos, correspondencia) sin presupuesto para soluciones enterprise o infraestructura GPU.

Desarrolladores de software: Quienes integran OCR en aplicaciones con restricciones de recursos, como dispositivos móviles o servidores compartidos, y necesitan maximizar el rendimiento sin costes adicionales de hardware.

## Estructura del trabajo

El presente documento se organiza en los siguientes capítulos:

Capítulo 2 - Contexto y Estado del Arte: Se presenta una revisión de las tecnologías OCR basadas en aprendizaje profundo, incluyendo las arquitecturas de detección y reconocimiento de texto, así como los trabajos previos en optimización de estos sistemas.

Capítulo 3 - Objetivos y Metodología: Se definen los objetivos SMART del trabajo y se describe la metodología experimental seguida, incluyendo la preparación del dataset, las métricas de evaluación y el proceso de optimización con Ray Tune.

Capítulo 4 - Desarrollo Específico de la Contribución: Este capítulo presenta el desarrollo completo del estudio comparativo y la optimización de hiperparámetros de sistemas OCR, estructurado en tres secciones: (4.1) planteamiento de la comparativa con la evaluación de EasyOCR, PaddleOCR y DocTR; (4.2) desarrollo de la comparativa con la optimización de hiperparámetros mediante Ray Tune; y (4.3) discusión y análisis de resultados.

Capítulo 5 - Conclusiones y Trabajo Futuro: Se resumen las contribuciones del trabajo, se discute el grado de cumplimiento de los objetivos y se proponen líneas de trabajo futuro.

Anexos: Se incluye el enlace al repositorio de código fuente y datos, así como tablas completas de resultados experimentales.

# 2. Contexto y estado del arte

Este capítulo presenta el marco teórico y tecnológico en el que se desarrolla el presente trabajo. Se revisan los fundamentos del Reconocimiento Óptico de Caracteres (OCR), la evolución de las técnicas basadas en aprendizaje profundo, las principales soluciones de código abierto disponibles y los trabajos previos relacionados con la optimización de sistemas OCR.

## Contexto del problema

### Definición y Evolución Histórica del OCR

El Reconocimiento Óptico de Caracteres (OCR) es el proceso de conversión de imágenes de texto manuscrito, mecanografiado o impreso en texto codificado digitalmente. Esta tecnología permite la digitalización masiva de documentos, facilitando su búsqueda, edición y almacenamiento electrónico. La tecnología OCR ha evolucionado significativamente desde sus orígenes en la década de 1950, atravesando cuatro generaciones claramente diferenciadas:

#### Primera Generación (1950-1970): Sistemas basados en plantillas

Los primeros sistemas OCR surgieron en la década de 1950 con el objetivo de automatizar la lectura de documentos bancarios y postales. Estos sistemas utilizaban técnicas de correspondencia de plantillas (template matching), donde cada carácter de entrada se comparaba píxel a píxel con un conjunto predefinido de plantillas (Mori et al., 1992).

Las principales limitaciones de esta generación incluían:

· Dependencia de fuentes tipográficas específicas (OCR-A, OCR-B)

· Incapacidad para manejar variaciones en tamaño, rotación o estilo

· Alto coste computacional para la época

· Sensibilidad extrema al ruido y degradación de la imagen

A pesar de sus limitaciones, estos sistemas sentaron las bases para el desarrollo posterior del campo y demostraron la viabilidad comercial del reconocimiento automático de texto.

#### Segunda Generación (1970-1990): Extracción de características

La segunda generación introdujo técnicas más sofisticadas basadas en la extracción de características geométricas y estructurales de los caracteres. En lugar de comparar imágenes completas, estos sistemas extraían propiedades como:

· Número y posición de trazos

· Proporciones geométricas (altura, anchura, relación de aspecto)

· Momentos estadísticos de la distribución de píxeles

· Características topológicas (bucles, intersecciones, terminaciones)

Los clasificadores estadísticos, como el análisis discriminante lineal y los k-vecinos más cercanos (k-NN), se utilizaban para asignar cada vector de características a una clase de carácter (Trier et al., 1996). Esta aproximación permitió mayor robustez frente a variaciones tipográficas, aunque seguía requiriendo un diseño manual cuidadoso de las características a extraer.

#### Tercera Generación (1990-2010): Redes neuronales y modelos probabilísticos

La tercera generación marcó la introducción de técnicas de aprendizaje automático más avanzadas. Los Modelos Ocultos de Markov (HMM) se convirtieron en el estándar para el reconocimiento de secuencias de caracteres, especialmente en el reconocimiento de escritura manuscrita (Plamondon & Srihari, 2000).

Las Redes Neuronales Artificiales (ANN) también ganaron popularidad en esta época, con arquitecturas como el Perceptrón Multicapa (MLP) demostrando capacidades superiores de generalización. El trabajo seminal de LeCun et al. (1998) con las redes convolucionales (CNN) para el reconocimiento de dígitos manuscritos (dataset MNIST) estableció los fundamentos para la siguiente revolución.

Las características de esta generación incluían:

· Aprendizaje automático de características discriminativas

· Modelado probabilístico de secuencias de caracteres

· Mayor robustez frente a ruido y degradación

· Capacidad de incorporar conocimiento lingüístico mediante modelos de lenguaje

#### Cuarta Generación (2010-presente): Aprendizaje profundo

La cuarta y actual generación está dominada por arquitecturas de aprendizaje profundo que han superado ampliamente el rendimiento de los métodos tradicionales. Los avances clave incluyen:

Redes Convolucionales Profundas (Deep CNNs): Arquitecturas como VGGNet, ResNet e Inception permiten la extracción automática de características jerárquicas a múltiples escalas, eliminando la necesidad de diseño manual de características (Krizhevsky et al., 2012).

Redes Recurrentes (RNN/LSTM): Las redes Long Short-Term Memory (LSTM) permiten modelar dependencias a largo plazo en secuencias de caracteres, siendo fundamentales para el reconocimiento de texto de longitud variable (Graves et al., 2009).

Mecanismos de Atención y Transformers: La arquitectura Transformer (Vaswani et al., 2017) y sus variantes han revolucionado el procesamiento de secuencias, permitiendo capturar relaciones globales sin las limitaciones de las RNN. Modelos como TrOCR (Li et al., 2023) representan el estado del arte actual.

Connectionist Temporal Classification (CTC): La función de pérdida CTC (Graves et al., 2006) permite entrenar modelos de reconocimiento de secuencias sin necesidad de alineamiento carácter por carácter, simplificando enormemente el proceso de entrenamiento.

### Pipeline Moderno de OCR

Los sistemas OCR modernos siguen típicamente un pipeline de dos etapas principales, precedidas opcionalmente por una fase de preprocesamiento:

Figura 1. Pipeline de un sistema OCR moderno

Fuente: Elaboración propia.

#### Etapa de Preprocesamiento

Antes de la detección, muchos sistemas aplican técnicas de preprocesamiento para mejorar la calidad de la imagen de entrada:

· Binarización: Conversión a imagen binaria (blanco/negro) mediante técnicas como Otsu o Sauvola

· Corrección de inclinación (deskewing): Alineamiento horizontal del texto

· Eliminación de ruido: Filtros morfológicos y de suavizado

· Normalización de contraste: Mejora de la legibilidad mediante ecualización de histograma

#### Etapa 1: Detección de Texto (Text Detection)

La detección de texto tiene como objetivo localizar todas las regiones de una imagen que contienen texto. Esta tarea es particularmente desafiante debido a la variabilidad en:

· Tamaño y orientación del texto

· Fondos complejos y oclusiones parciales

· Texto curvo o deformado

· Múltiples idiomas y scripts en una misma imagen

Las arquitecturas más utilizadas para detección de texto incluyen:

EAST (Efficient and Accurate Scene Text Detector): Propuesto por Zhou et al. (2017), EAST es un detector de una sola etapa que predice directamente cuadriláteros rotados o polígonos que encierran el texto. Su arquitectura FCN (Fully Convolutional Network) permite procesamiento eficiente de imágenes de alta resolución.

CRAFT (Character Region Awareness for Text Detection): Desarrollado por Baek et al. (2019), CRAFT detecta regiones de caracteres individuales y las agrupa en palabras mediante el análisis de mapas de afinidad. Esta aproximación bottom-up es especialmente efectiva para texto con espaciado irregular.

DB (Differentiable Binarization): Propuesto por Liao et al. (2020), DB introduce una operación de binarización diferenciable que permite entrenar end-to-end un detector de texto basado en segmentación. Esta arquitectura es la utilizada por PaddleOCR y destaca por su velocidad y precisión.

Tabla 4. Comparativa de arquitecturas de detección de texto.

Arquitectura | Tipo | Salida | Fortalezas | Limitaciones
EAST | Single-shot | Cuadriláteros rotados | Rápido, simple | Dificultad con texto curvo
CRAFT | Bottom-up | Polígonos de palabra | Robusto a espaciado | Mayor coste computacional
DB | Segmentación | Polígonos arbitrarios | Rápido, preciso | Sensible a parámetros

Fuente: Elaboración propia.

#### Etapa 2: Reconocimiento de Texto (Text Recognition)

Una vez detectadas las regiones de texto, la etapa de reconocimiento transcribe el contenido visual a texto digital. Las arquitecturas predominantes son:

CRNN (Convolutional Recurrent Neural Network): Propuesta por Shi et al. (2016), CRNN combina una CNN para extracción de características visuales con una RNN bidireccional (típicamente LSTM) para modelado de secuencias, entrenada con pérdida CTC. Esta arquitectura estableció el paradigma encoder-decoder que domina el campo.

La arquitectura CRNN consta de tres componentes:

1. Capas convolucionales: Extraen características visuales de la imagen de entrada

2. Capas recurrentes: Modelan las dependencias secuenciales entre características

3. Capa de transcripción: Convierte las predicciones de la RNN en secuencias de caracteres mediante CTC

SVTR (Scene-Text Visual Transformer Recognition): Desarrollado por Du et al. (2022), SVTR aplica la arquitectura Transformer al reconocimiento de texto, utilizando parches de imagen como tokens de entrada. Esta aproximación elimina la necesidad de RNN y permite capturar dependencias globales de manera más eficiente.

Arquitecturas con Atención: Los modelos encoder-decoder con mecanismos de atención (Bahdanau et al., 2015) permiten al decodificador "enfocarse" en diferentes partes de la imagen mientras genera cada carácter. Esto es especialmente útil para texto largo o con layouts complejos.

TrOCR (Transformer-based OCR): Propuesto por Li et al. (2023), TrOCR utiliza un Vision Transformer (ViT) como encoder y un Transformer de lenguaje como decoder, logrando resultados estado del arte en múltiples benchmarks.

Tabla 5. Comparativa de arquitecturas de reconocimiento de texto.

Arquitectura | Encoder | Decoder | Pérdida | Características
CRNN | CNN | BiLSTM | CTC | Rápido, robusto
SVTR | ViT | Linear | CTC | Sin recurrencia
Attention-based | CNN | LSTM+Attn | Cross-entropy | Flexible longitud
TrOCR | ViT | Transformer | Cross-entropy | Estado del arte

Fuente: Elaboración propia.

### Métricas de Evaluación

La evaluación rigurosa de sistemas OCR requiere métricas estandarizadas que permitan comparaciones objetivas. Las métricas fundamentales se basan en la distancia de edición de Levenshtein.

#### Distancia de Levenshtein

La distancia de Levenshtein (Levenshtein, 1966) entre dos cadenas es el número mínimo de operaciones de edición (inserción, eliminación, sustitución) necesarias para transformar una cadena en otra. Formalmente, para dos cadenas a y b:

$$d(a,b) = \min(\text{inserciones} + \text{eliminaciones} + \text{sustituciones})$$

Esta métrica es fundamental para calcular tanto CER como WER.

#### Character Error Rate (CER)

El CER mide el error a nivel de carácter y se calcula como:

$$CER = \frac{S + D + I}{N}$$

Donde:

· S = número de sustituciones de caracteres

· D = número de eliminaciones de caracteres

· I = número de inserciones de caracteres

· N = número total de caracteres en el texto de referencia

Un CER del 1% indica que, en promedio, 1 de cada 100 caracteres contiene un error. Para aplicaciones críticas como:

· Documentos financieros: Se requiere CER < 0.1%

· Documentos médicos: Se requiere CER < 0.5%

· Documentos académicos: CER < 2% es aceptable

· Búsqueda y archivo: CER < 5% puede ser suficiente

#### Word Error Rate (WER)

El WER mide el error a nivel de palabra, utilizando la misma fórmula pero considerando palabras como unidades:

$$WER = \frac{S_w + D_w + I_w}{N_w}$$

El WER es generalmente mayor que el CER, ya que un solo error de carácter puede invalidar una palabra completa. La relación típica es WER ≈ 2-3 × CER para texto en español.

#### Otras Métricas Complementarias

Precision y Recall a nivel de palabra: Útiles cuando se evalúa la capacidad del sistema para detectar palabras específicas.

Bag-of-Words Accuracy: Mide la proporción de palabras correctamente reconocidas independientemente de su orden.

BLEU Score: Adaptado de traducción automática, mide la similitud entre el texto predicho y la referencia considerando n-gramas.

### Particularidades del OCR para el Idioma Español

El español, como lengua romance, presenta características específicas que impactan el rendimiento de los sistemas OCR:

#### Características Ortográficas

Caracteres especiales: El español incluye caracteres no presentes en el alfabeto inglés básico:

· La letra eñe (ñ, Ñ)

· Vocales acentuadas (á, é, í, ó, ú, Á, É, Í, Ó, Ú)

· Diéresis sobre u (ü, Ü)

· Signos de puntuación invertidos (¿, ¡)

Estos caracteres requieren que los modelos OCR incluyan dichos símbolos en su vocabulario de salida y que el entrenamiento incluya suficientes ejemplos de cada uno.

Diacríticos y acentos: Los acentos gráficos del español son elementos pequeños que pueden confundirse fácilmente con ruido, artefactos de imagen o signos de puntuación. La distinción entre vocales acentuadas y no acentuadas es crucial para el significado (e.g., "él" vs "el", "más" vs "mas").

#### Características Lingüísticas

Longitud de palabras: Las palabras en español tienden a ser más largas que en inglés debido a la morfología flexiva rica (conjugaciones verbales, géneros, plurales). Esto puede aumentar la probabilidad de error acumulativo.

Vocabulario: El español tiene un vocabulario amplio con muchas variantes morfológicas de cada raíz. Los modelos de lenguaje utilizados para post-corrección deben contemplar esta diversidad.

#### Recursos y Datasets

Los recursos disponibles para OCR en español son significativamente menores que para inglés o chino:

· Menor cantidad de datasets etiquetados de gran escala

· Menos modelos preentrenados específicos para español

· Documentación y tutoriales predominantemente en inglés

Esta escasez de recursos específicos para español motiva la necesidad de técnicas de adaptación como la optimización de hiperparámetros explorada en este trabajo.

## Estado del arte

### Soluciones OCR de Código Abierto

En los últimos años han surgido varias soluciones OCR de código abierto que democratizan el acceso a esta tecnología. A continuación se analizan en detalle las tres principales alternativas evaluadas en este trabajo.

#### EasyOCR

EasyOCR es una biblioteca de OCR desarrollada por Jaided AI (2020) con el objetivo de proporcionar una solución de fácil uso que soporte múltiples idiomas. Actualmente soporta más de 80 idiomas, incluyendo español.

Arquitectura técnica:

· Detector: CRAFT (Character Region Awareness for Text Detection)

· Reconocedor: CRNN con backbone ResNet/VGG + BiLSTM + CTC

· Modelos preentrenados: Disponibles para descarga automática

Características principales:

· API simple de una línea para casos de uso básicos

· Soporte para GPU (CUDA) y CPU

· Reconocimiento de múltiples idiomas en una misma imagen

· Bajo consumo de memoria comparado con otras soluciones

Limitaciones identificadas:

· Opciones de configuración limitadas (pocos hiperparámetros ajustables)

· Menor precisión en documentos con layouts complejos

· Actualizaciones menos frecuentes que otras alternativas

· Documentación menos exhaustiva

Caso de uso ideal: Prototipado rápido, aplicaciones con restricciones de memoria, proyectos que requieren soporte multilingüe inmediato.

#### PaddleOCR

PaddleOCR es el sistema OCR desarrollado por Baidu como parte del ecosistema PaddlePaddle (2024). Representa una de las soluciones más completas y activamente mantenidas en el ecosistema de código abierto. La versión PP-OCRv5, utilizada en este trabajo, incorpora los últimos avances en el campo.

Arquitectura técnica:

El pipeline de PaddleOCR consta de tres módulos principales:

1. Detector de texto (DB - Differentiable Binarization):

- Backbone: ResNet18/ResNet50 - Neck: FPN (Feature Pyramid Network) - Head: Segmentación con binarización diferenciable - Salida: Polígonos que encierran regiones de texto

1. Clasificador de orientación:

- Determina si el texto está rotado 0° o 180° - Permite corrección automática de texto invertido - Opcional pero recomendado para documentos escaneados

1. Reconocedor de texto (SVTR):

- Encoder: Vision Transformer modificado - Decoder: CTC o Attention-based - Vocabulario: Configurable por idioma

Hiperparámetros configurables:

PaddleOCR expone numerosos hiperparámetros que permiten ajustar el comportamiento del sistema. Los más relevantes para este trabajo son:

Tabla 6. Hiperparámetros de detección de PaddleOCR.

Parámetro | Descripción | Rango | Defecto
text_det_thresh | Umbral de probabilidad para píxeles de texto | [0.0, 1.0] | 0.3
text_det_box_thresh | Umbral de confianza para cajas detectadas | [0.0, 1.0] | 0.6
text_det_unclip_ratio | Factor de expansión de cajas detectadas | [0.0, 3.0] | 1.5
text_det_limit_side_len | Tamaño máximo del lado de imagen | [320, 2560] | 960

Fuente: Elaboración propia.

Tabla 7. Hiperparámetros de reconocimiento de PaddleOCR.

Parámetro | Descripción | Rango | Defecto
text_rec_score_thresh | Umbral de confianza para resultados | [0.0, 1.0] | 0.5
use_textline_orientation | Activar clasificación de orientación de línea | {True, False} | False
rec_batch_size | Tamaño de batch para reconocimiento | [1, 64] | 6

Fuente: Elaboración propia.

Tabla 8. Hiperparámetros de preprocesamiento de PaddleOCR.

Parámetro | Descripción | Impacto
use_doc_orientation_classify | Clasificación de orientación del documento | Alto para documentos escaneados
use_doc_unwarping | Corrección de deformación/curvatura | Alto para fotos de documentos
use_angle_cls | Clasificador de ángulo 0°/180° | Medio para documentos rotados

Fuente: Elaboración propia.

Fortalezas de PaddleOCR:

· Alta precisión en múltiples benchmarks

· Pipeline altamente configurable

· Modelos optimizados para servidor (mayor precisión) y móvil (mayor velocidad)

· Documentación exhaustiva (aunque principalmente en chino)

· Comunidad activa y actualizaciones frecuentes

· Soporte para entrenamiento personalizado (fine-tuning)

Limitaciones:

· Dependencia del framework PaddlePaddle (menos popular que PyTorch/TensorFlow)

· Curva de aprendizaje más pronunciada

· Documentación en inglés menos completa que en chino

#### DocTR

DocTR (Document Text Recognition) es una biblioteca desarrollada por Mindee (2021), empresa especializada en procesamiento inteligente de documentos. Está orientada a la comunidad de investigación y ofrece una API limpia basada en TensorFlow/PyTorch.

Arquitectura técnica:

· Detectores disponibles: DB (db_resnet50), LinkNet (linknet_resnet18)

· Reconocedores disponibles: CRNN (crnn_vgg16_bn), SAR (sar_resnet31), ViTSTR (vitstr_small)

· Framework: TensorFlow 2.x o PyTorch

Características principales:

· API Pythonic bien diseñada

· Salida estructurada con información de confianza y geometría

· Integración nativa con Hugging Face Hub

· Documentación orientada a investigación

Limitaciones identificadas:

· Menor rendimiento en español comparado con PaddleOCR según pruebas preliminares

· Comunidad más pequeña

· Menos opciones de modelos preentrenados para idiomas no ingleses

#### Comparativa Detallada de Soluciones

Tabla 9. Comparativa técnica de soluciones OCR de código abierto.

Aspecto | EasyOCR | PaddleOCR | DocTR
Framework | PyTorch | PaddlePaddle | TF/PyTorch
Detector | CRAFT | DB | DB/LinkNet
Reconocedor | CRNN | SVTR/CRNN | CRNN/SAR/ViTSTR
Idiomas | 80+ | 80+ | 9
Configurabilidad | Baja | Alta | Media
Documentación | Media | Alta (CN) | Alta (EN)
Actividad | Media | Alta | Media
Licencia | Apache 2.0 | Apache 2.0 | Apache 2.0

Fuente: Elaboración propia.

Tabla 10. Comparativa de facilidad de uso.

Aspecto | EasyOCR | PaddleOCR | DocTR
Instalación | pip install | pip install | pip install
Líneas para OCR básico | 3 | 5 | 6
GPU requerida | Opcional | Opcional | Opcional
Memoria mínima | 2 GB | 4 GB | 4 GB

Fuente: Elaboración propia.

### Optimización de Hiperparámetros

#### Fundamentos Teóricos

La optimización de hiperparámetros (HPO, Hyperparameter Optimization) es el proceso de encontrar la configuración óptima de los parámetros que controlan el proceso de aprendizaje o inferencia de un modelo, pero que no se aprenden directamente de los datos (Feurer & Hutter, 2019).

A diferencia de los parámetros del modelo (como los pesos de una red neuronal), los hiperparámetros se establecen antes del entrenamiento e incluyen:

· Tasa de aprendizaje, tamaño de batch, número de épocas

· Arquitectura del modelo (número de capas, unidades por capa)

· Parámetros de regularización (dropout, weight decay)

· Umbrales de decisión en tiempo de inferencia (relevante para este trabajo)

El problema de HPO puede formalizarse como:

$$\lambda^* = \arg\min_{\lambda \in \Lambda} \mathcal{L}(M_\lambda, D_{val})$$

Donde:

· $\lambda$ es un vector de hiperparámetros

· $\Lambda$ es el espacio de búsqueda

· $M_\lambda$ es el modelo configurado con $\lambda$

· $\mathcal{L}$ es la función de pérdida

· $D_{val}$ es el conjunto de validación

#### Métodos de Optimización

Grid Search (Búsqueda en rejilla):

El método más simple consiste en evaluar todas las combinaciones posibles de valores discretizados de los hiperparámetros. Para $k$ hiperparámetros con $n$ valores cada uno, requiere $n^k$ evaluaciones.

Ventajas:

· Exhaustivo y reproducible

· Fácil de paralelizar

· Garantiza encontrar el óptimo dentro de la rejilla

Desventajas:

· Coste exponencial con el número de hiperparámetros

· Ineficiente si algunos hiperparámetros son más importantes que otros

· No aprovecha información de evaluaciones previas

Random Search (Búsqueda aleatoria):

Propuesto por Bergstra & Bengio (2012), Random Search muestrea configuraciones aleatoriamente del espacio de búsqueda. Sorprendentemente, supera a Grid Search en muchos escenarios prácticos.

La intuición es que, cuando solo algunos hiperparámetros son importantes, Random Search explora más valores de estos parámetros críticos mientras Grid Search desperdicia evaluaciones variando parámetros irrelevantes.

Optimización Bayesiana:

La optimización bayesiana modela la función objetivo mediante un modelo probabilístico sustituto (surrogate model) y utiliza una función de adquisición para decidir qué configuración evaluar a continuación (Bergstra et al., 2011).

El proceso iterativo es:

1. Ajustar el modelo sustituto a las observaciones actuales

2. Optimizar la función de adquisición para seleccionar el siguiente punto

3. Evaluar la función objetivo en el punto seleccionado

4. Actualizar las observaciones y repetir

Los modelos sustitutos más comunes son:

· Procesos Gaussianos (GP): Proporcionan incertidumbre bien calibrada pero escalan pobremente

· Random Forests: Manejan bien espacios de alta dimensión y variables categóricas

· Tree-structured Parzen Estimator (TPE): Modela densidades en lugar de la función objetivo

#### Tree-structured Parzen Estimator (TPE)

TPE, propuesto por Bergstra et al. (2011) e implementado en Optuna, es particularmente efectivo para HPO. En lugar de modelar $p(y|\lambda)$ directamente, TPE modela:

$$p(\lambda|y) = \begin{cases} l(\lambda) & \text{si } y < y^ \\ g(\lambda) & \text{si } y \geq y^ \end{cases}$$

Donde $y^*$ es un umbral (típicamente el percentil 15-25 de las observaciones), $l(\lambda)$ es la densidad de hiperparámetros con buen rendimiento, y $g(\lambda)$ es la densidad de hiperparámetros con mal rendimiento.

La función de adquisición Expected Improvement se aproxima como:

$$EI(\lambda) \propto \frac{l(\lambda)}{g(\lambda)}$$

Configuraciones con alta probabilidad bajo $l$ y baja probabilidad bajo $g$ tienen mayor Expected Improvement.

Ventajas de TPE:

· Maneja naturalmente espacios condicionales (hiperparámetros que dependen de otros)

· Eficiente para espacios de alta dimensión

· No requiere derivadas de la función objetivo

· Implementación eficiente en Optuna

#### Ray Tune

Ray Tune (Liaw et al., 2018) es un framework de optimización de hiperparámetros escalable construido sobre Ray, un sistema de computación distribuida. Sus características principales incluyen:

Escalabilidad:

· Ejecución paralela de múltiples trials

· Distribución automática en clusters

· Soporte para recursos heterogéneos (CPU/GPU)

Flexibilidad:

· Integración con múltiples algoritmos de búsqueda (Optuna, HyperOpt, Ax, etc.)

· Schedulers avanzados (ASHA, PBT, BOHB)

· Checkpointing y recuperación de fallos

Early Stopping:

· ASHA (Asynchronous Successive Halving Algorithm): Termina trials poco prometedores

· PBT (Population-Based Training): Evoluciona hiperparámetros durante el entrenamiento

Integración con Optuna:

La combinación de Ray Tune con OptunaSearch permite:

1. Utilizar TPE como algoritmo de búsqueda

2. Paralelizar la evaluación de trials

3. Beneficiarse de la infraestructura de Ray para distribución

4. Acceder a las visualizaciones de Optuna

Figura 2. Ciclo de optimización con Ray Tune y Optuna

Fuente: Elaboración propia.

#### HPO en Sistemas OCR

La aplicación de HPO a sistemas OCR ha sido explorada en varios contextos:

Optimización de preprocesamiento:

Liang et al. (2005) propusieron optimizar parámetros de binarización adaptativa para mejorar el OCR de documentos degradados. Los parámetros optimizados incluían tamaño de ventana, factor de corrección y umbral local.

Optimización de arquitectura:

Breuel (2013) exploró la selección automática de arquitecturas de red para reconocimiento de texto manuscrito, optimizando número de capas, unidades y tipo de activación.

Optimización de post-procesamiento:

Schulz & Kuhn (2017) optimizaron parámetros de modelos de lenguaje para corrección de errores OCR, incluyendo pesos de interpolación entre modelos de caracteres y palabras.

Vacío en la literatura:

A pesar de estos trabajos, existe un vacío significativo respecto a la optimización sistemática de hiperparámetros de inferencia en pipelines OCR modernos como PaddleOCR. La mayoría de trabajos se centran en:

· Entrenamiento de modelos (fine-tuning)

· Preprocesamiento de imagen

· Post-procesamiento lingüístico

La optimización de umbrales de detección y reconocimiento en tiempo de inferencia ha recibido poca atención, especialmente para idiomas diferentes del inglés y chino.

### Datasets y Benchmarks para Español

#### Datasets Públicos

Los principales recursos para evaluación de OCR en español incluyen:

FUNSD-ES: Versión en español del Form Understanding in Noisy Scanned Documents dataset. Contiene formularios escaneados con anotaciones de texto y estructura.

MLT (ICDAR Multi-Language Text): Dataset multilingüe de las competiciones ICDAR que incluye muestras en español. Las ediciones 2017 y 2019 contienen texto en escenas naturales.

XFUND: Dataset de comprensión de formularios en múltiples idiomas, incluyendo español, con anotaciones de entidades y relaciones.

Tabla 11. Datasets públicos con contenido en español.

Dataset | Tipo | Idiomas | Tamaño | Uso principal
FUNSD-ES | Formularios | ES | ~200 docs | Document understanding
MLT 2019 | Escenas | Multi (incl. ES) | 10K imgs | Text detection
XFUND | Formularios | 7 (incl. ES) | 1.4K docs | Information extraction

Fuente: Elaboración propia.

#### Limitaciones de Recursos para Español

Comparado con inglés y chino, el español cuenta con:

· Menor cantidad de datasets etiquetados de gran escala

· Menos benchmarks estandarizados

· Menor representación en competiciones internacionales (ICDAR)

· Pocos modelos preentrenados específicos

Esta escasez de recursos específicos para español motivó la creación de un dataset propio basado en documentos académicos de UNIR para este trabajo.

#### Trabajos Previos en OCR para Español

Los trabajos previos en OCR para español se han centrado principalmente en:

Digitalización de archivos históricos: Múltiples proyectos han abordado el reconocimiento de manuscritos coloniales y documentos históricos en español, utilizando técnicas de HTR (Handwritten Text Recognition) adaptadas (Romero et al., 2013).

Procesamiento de documentos de identidad: Sistemas OCR especializados para DNI, pasaportes y documentos oficiales españoles y latinoamericanos (Bulatov et al., 2020).

Reconocimiento de texto en escenas: Participaciones en competiciones ICDAR para detección y reconocimiento de texto en español en imágenes naturales.

Tabla 12. Trabajos previos relevantes en OCR para español.

Trabajo | Enfoque | Contribución
Romero et al. (2013) | HTR histórico | Modelos HMM para manuscritos
Bulatov et al. (2020) | Documentos ID | Pipeline especializado
Fischer et al. (2012) | Multilingual | Transferencia entre idiomas

Fuente: Elaboración propia.

La optimización de hiperparámetros para documentos académicos en español representa una contribución original de este trabajo, abordando un nicho no explorado en la literatura.

## Conclusiones del capítulo

Este capítulo ha presentado el marco teórico y tecnológico necesario para contextualizar la contribución del presente trabajo:

1. Evolución del OCR: Se ha trazado la evolución desde los sistemas de plantillas hasta las arquitecturas de aprendizaje profundo actuales, destacando los avances clave en cada generación.

1. Pipeline moderno: Se ha descrito el pipeline de dos etapas (detección + reconocimiento) utilizado por los sistemas OCR contemporáneos, detallando las arquitecturas más relevantes (DB, CRAFT, CRNN, SVTR, Transformer).

1. Métricas de evaluación: Se han definido formalmente las métricas CER y WER, estableciendo los umbrales de aceptabilidad para diferentes aplicaciones.

1. Particularidades del español: Se han identificado los desafíos específicos del OCR para español, incluyendo caracteres especiales, diacríticos y escasez de recursos.

1. Soluciones de código abierto: Se han analizado en profundidad EasyOCR, PaddleOCR y DocTR, justificando la selección de PaddleOCR para este trabajo por su alta configurabilidad.

1. Optimización de hiperparámetros: Se han presentado los fundamentos teóricos de HPO, con énfasis en TPE (Optuna) y Ray Tune, identificando el vacío en la literatura respecto a la optimización de hiperparámetros de inferencia en OCR.

El estado del arte revela que, si bien existen soluciones OCR de alta calidad, su optimización para dominios específicos mediante ajuste de hiperparámetros (sin fine-tuning) ha recibido poca atención en la literatura. Este trabajo contribuye a llenar ese vacío proponiendo una metodología reproducible para la optimización de PaddleOCR en documentos académicos en español.

# 3. Objetivos concretos y metodología de trabajo

Este capítulo establece los objetivos del trabajo siguiendo la metodología SMART (Doran, 1981) y describe la metodología experimental empleada para alcanzarlos. Se define un objetivo general y cinco objetivos específicos, todos ellos medibles y verificables.

## Objetivo general

Optimizar el rendimiento de PaddleOCR para documentos académicos en español mediante ajuste de hiperparámetros, alcanzando un CER inferior al 2% sin requerir fine-tuning del modelo ni recursos GPU dedicados.

### Justificación SMART del Objetivo General

Tabla 13. Justificación SMART del objetivo general.

Criterio | Cumplimiento
Específico (S) | Se define claramente qué se quiere lograr: optimizar PaddleOCR mediante ajuste de hiperparámetros para documentos en español
Medible (M) | Se establece una métrica cuantificable: CER < 2%
Alcanzable (A) | Es viable dado que: (1) PaddleOCR permite configuración de hiperparámetros, (2) Ray Tune posibilita búsqueda automatizada, (3) No se requiere GPU
Relevante (R) | El impacto es demostrable: mejora la extracción de texto en documentos académicos sin costes adicionales de infraestructura
Temporal (T) | El plazo es un cuatrimestre, correspondiente al TFM

Fuente: Elaboración propia.

## Objetivos específicos

### OE1: Comparar soluciones OCR de código abierto

Evaluar el rendimiento base de EasyOCR, PaddleOCR y DocTR en documentos académicos en español, utilizando CER y WER como métricas, para seleccionar el modelo más prometedor.

### OE2: Preparar un dataset de evaluación

Construir un dataset estructurado de imágenes de documentos académicos en español con su texto de referencia (ground truth) extraído del PDF original.

### OE3: Identificar hiperparámetros críticos

Analizar la correlación entre los hiperparámetros de PaddleOCR y las métricas de error para identificar los parámetros con mayor impacto en el rendimiento.

### OE4: Optimizar hiperparámetros con Ray Tune

Ejecutar una búsqueda automatizada de hiperparámetros utilizando Ray Tune con Optuna, evaluando al menos 50 configuraciones diferentes.

### OE5: Validar la configuración optimizada

Comparar el rendimiento de la configuración baseline versus la configuración optimizada sobre el dataset completo, documentando la mejora obtenida.

## Metodología del trabajo

### Visión General

Figura 3. Fases de la metodología experimental

Fuente: Elaboración propia.

Descripción de las fases:

· Fase 1 - Preparación del Dataset: Conversión PDF a imágenes (300 DPI), extracción de ground truth con PyMuPDF

· Fase 2 - Benchmark Comparativo: Evaluación de EasyOCR, PaddleOCR, DocTR con métricas CER/WER

· Fase 3 - Espacio de Búsqueda: Identificación de hiperparámetros y configuración de Ray Tune + Optuna

· Fase 4 - Optimización: Ejecución de 64 trials con paralelización (2 concurrentes)

· Fase 5 - Validación: Comparación baseline vs optimizado, análisis de correlaciones

### Fase 1: Preparación del Dataset

#### Fuente de Datos

Se utilizaron documentos PDF académicos de UNIR (Universidad Internacional de La Rioja), específicamente las instrucciones para la elaboración del TFE del Máster en Inteligencia Artificial.

#### Proceso de Conversión

El script prepare_dataset.ipynb implementa:

1. Conversión PDF a imágenes:

- Biblioteca: PyMuPDF (fitz) - Resolución: 300 DPI - Formato de salida: PNG

1. Extracción de texto de referencia:

- Método: page.get_text("dict") de PyMuPDF - Preservación de estructura de líneas - Tratamiento de texto vertical/marginal - Normalización de espacios y saltos de línea

#### Estructura del Dataset

Figura 4. Estructura del dataset de evaluación

Fuente: Elaboración propia.

#### Clase ImageTextDataset

Se implementó una clase Python para cargar pares imagen-texto:

    class ImageTextDataset:
        def __init__(self, root):
            # Carga pares (imagen, texto) de carpetas pareadas

        def __getitem__(self, idx):
            # Retorna (PIL.Image, str)

### Fase 2: Benchmark Comparativo

#### Modelos Evaluados

Tabla 14. Modelos OCR evaluados en el benchmark inicial.

Modelo | Versión | Configuración
EasyOCR | - | Idiomas: ['es', 'en']
PaddleOCR | PP-OCRv5 | Modelos server_det + server_rec
DocTR | - | db_resnet50 + sar_resnet31

Fuente: Elaboración propia.

#### Métricas de Evaluación

Se utilizó la biblioteca jiwer para calcular:

    from jiwer import wer, cer

    def evaluate_text(reference, prediction):
        return {
            'WER': wer(reference, prediction),
            'CER': cer(reference, prediction)
        }

### Fase 3: Espacio de Búsqueda

#### Hiperparámetros Seleccionados

Tabla 15. Hiperparámetros seleccionados para optimización.

Parámetro | Tipo | Rango/Valores | Descripción
use_doc_orientation_classify | Booleano | [True, False] | Clasificación de orientación del documento
use_doc_unwarping | Booleano | [True, False] | Corrección de deformación del documento
textline_orientation | Booleano | [True, False] | Clasificación de orientación de línea de texto
text_det_thresh | Continuo | [0.0, 0.7] | Umbral de detección de píxeles de texto
text_det_box_thresh | Continuo | [0.0, 0.7] | Umbral de caja de detección
text_det_unclip_ratio | Fijo | 0.0 | Coeficiente de expansión (fijado)
text_rec_score_thresh | Continuo | [0.0, 0.7] | Umbral de confianza de reconocimiento

Fuente: Elaboración propia.

#### Configuración de Ray Tune

    from ray import tune
    from ray.tune.search.optuna import OptunaSearch

    search_space = {
        "use_doc_orientation_classify": tune.choice([True, False]),
        "use_doc_unwarping": tune.choice([True, False]),
        "textline_orientation": tune.choice([True, False]),
        "text_det_thresh": tune.uniform(0.0, 0.7),
        "text_det_box_thresh": tune.uniform(0.0, 0.7),
        "text_det_unclip_ratio": tune.choice([0.0]),
        "text_rec_score_thresh": tune.uniform(0.0, 0.7),
    }

    tuner = tune.Tuner(
        trainable_paddle_ocr,
        tune_config=tune.TuneConfig(
            metric="CER",
            mode="min",
            search_alg=OptunaSearch(),
            num_samples=64,
            max_concurrent_trials=2
        )
    )

### Fase 4: Ejecución de Optimización

#### Arquitectura de Ejecución

Debido a incompatibilidades entre Ray y PaddleOCR en el mismo proceso, se implementó una arquitectura basada en subprocesos:

Figura 5. Arquitectura de ejecución con subprocesos

Fuente: Elaboración propia.

#### Script de Evaluación (paddle_ocr_tuning.py)

El script recibe hiperparámetros por línea de comandos:

    python paddle_ocr_tuning.py \
        --pdf-folder ./dataset \
        --textline-orientation True \
        --text-det-box-thresh 0.5 \
        --text-det-thresh 0.4 \
        --text-rec-score-thresh 0.6

Y retorna métricas en formato JSON:

    {
        "CER": 0.0125,
        "WER": 0.1040,
        "TIME": 331.09,
        "PAGES": 5,
        "TIME_PER_PAGE": 66.12
    }

### Fase 5: Validación

#### Protocolo de Validación

1. Baseline: Ejecución con configuración por defecto de PaddleOCR

2. Optimizado: Ejecución con mejor configuración encontrada

3. Comparación: Evaluación sobre las 24 páginas del dataset completo

4. Métricas reportadas: CER, WER, tiempo de procesamiento

### Entorno de Ejecución

#### Hardware

Tabla 16. Especificaciones de hardware del entorno de desarrollo.

Componente | Especificación
CPU | AMD Ryzen 7 5800H
RAM | 16 GB DDR4
GPU | NVIDIA RTX 3060 Laptop (5.66 GB VRAM)
Almacenamiento | SSD

Fuente: Elaboración propia.

#### Software

Tabla 17. Versiones de software utilizadas.

Componente | Versión
Sistema Operativo | Ubuntu 24.04.3 LTS
Python | 3.12.3
PaddleOCR | 3.3.2
PaddlePaddle | 3.2.2
Ray | 2.52.1
Optuna | 4.7.0

Fuente: Elaboración propia.

### Limitaciones Metodológicas

1. Tamaño del dataset: El dataset contiene 24 páginas de un único tipo de documento. Resultados pueden no generalizar a otros formatos.

1. Ejecución en CPU: Los tiempos de procesamiento (~70s/página) serían significativamente menores con GPU.

1. Ground truth imperfecto: El texto de referencia extraído de PDF puede contener errores en documentos con layouts complejos.

1. Parámetro fijo: text_det_unclip_ratio quedó fijado en 0.0 durante todo el experimento por decisión de diseño inicial.

## Resumen del capítulo

Este capítulo ha establecido:

1. Un objetivo general SMART: alcanzar CER < 2% mediante optimización de hiperparámetros

2. Cinco objetivos específicos medibles y alcanzables

3. Una metodología experimental en cinco fases claramente definidas

4. El espacio de búsqueda de hiperparámetros y la configuración de Ray Tune

5. Las limitaciones reconocidas del enfoque

El siguiente capítulo presenta el desarrollo específico de la contribución, incluyendo el benchmark comparativo de soluciones OCR, la optimización de hiperparámetros y el análisis de resultados.

4. D es arrollo específico de la contribución

Este capítulo presenta el desarrollo completo del estudio comparativo y la optimización de hiperparámetros de sistemas OCR. Se estructura según el tipo de trabajo "Comparativa de soluciones" establecido por las instrucciones de UNIR: planteamiento de la comparativa, desarrollo de la comparativa, y discusión y análisis de resultados.

## Planteamiento de la comparativa

### Introducción

Esta sección presenta los resultados del estudio comparativo realizado entre tres soluciones OCR de código abierto: EasyOCR, PaddleOCR y DocTR. Los experimentos fueron documentados en el notebook ocr_benchmark_notebook.ipynb del repositorio. El objetivo es identificar el modelo base más prometedor para la posterior fase de optimización de hiperparámetros.

### Identificación del Problema

El reconocimiento óptico de caracteres (OCR) en documentos académicos en español presenta desafíos específicos que no han sido ampliamente abordados en la literatura:

1. Layouts complejos: Los documentos académicos combinan texto corrido, tablas, listas numeradas, encabezados multinivel y notas al pie.

1. Caracteres específicos del español: Acentos (á, é, í, ó, ú), eñe (ñ), diéresis (ü) y signos de puntuación invertidos (¿, ¡).

1. Formato formal: Tipografía profesional con múltiples fuentes, tamaños y estilos (negrita, cursiva).

1. Calidad variable: Documentos digitales de alta calidad pero con posibles artefactos de compresión PDF.

### Alternativas Evaluadas

Se seleccionaron tres soluciones OCR de código abierto representativas del estado del arte:

Tabla 18. Soluciones OCR evaluadas en el benchmark comparativo.

Solución | Desarrollador | Versión | Justificación de selección
EasyOCR | Jaided AI | Última estable | Popularidad, facilidad de uso
PaddleOCR | Baidu | PP-OCRv5 | Estado del arte industrial
DocTR | Mindee | Última estable | Orientación académica

Fuente: Elaboración propia.

Imágenes Docker disponibles en el registro del proyecto:

· PaddleOCR: seryus.ddns.net/unir/paddle-ocr-gpu, seryus.ddns.net/unir/paddle-ocr-cpu

· EasyOCR: seryus.ddns.net/unir/easyocr-gpu

· DocTR: seryus.ddns.net/unir/doctr-gpu

### Criterios de Éxito

Los criterios establecidos para evaluar las soluciones fueron:

1. Precisión (CER < 5%): Error de caracteres aceptable para documentos académicos

2. Configurabilidad: Disponibilidad de hiperparámetros ajustables

3. Soporte para español: Modelos preentrenados que incluyan el idioma

4. Documentación: Calidad de la documentación técnica

5. Mantenimiento activo: Actualizaciones recientes y comunidad activa

### Configuración del Experimento

#### Dataset de Evaluación

Se utilizó el documento "Instrucciones para la redacción y elaboración del TFE" del Máster Universitario en Inteligencia Artificial de UNIR, ubicado en la carpeta instructions/.

Tabla 19. Características del dataset de evaluación inicial.

Característica | Valor
Documento fuente | Instrucciones TFE UNIR
Número de páginas evaluadas | 5 (benchmark inicial)
Formato | PDF digital (no escaneado)
Idioma principal | Español
Resolución de conversión | 300 DPI
Formato de imagen | PNG

Fuente: Elaboración propia.

#### Proceso de Conversión

La conversión del PDF a imágenes se realizó mediante PyMuPDF (fitz):

    import fitz  # PyMuPDF

    def pdf_to_images(pdf_path, output_dir, dpi=300):
        doc = fitz.open(pdf_path)
        for page_num, page in enumerate(doc):
            # Matriz de transformación para 300 DPI
            mat = fitz.Matrix(dpi/72, dpi/72)
            pix = page.get_pixmap(matrix=mat)
            pix.save(f"{output_dir}/page_{page_num:04d}.png")

La resolución de 300 DPI fue seleccionada como estándar para OCR de documentos, proporcionando suficiente detalle para caracteres pequeños sin generar archivos excesivamente grandes.

#### Extracción del Ground Truth

El texto de referencia se extrajo directamente del PDF mediante PyMuPDF:

    def extract_text(pdf_path):
        doc = fitz.open(pdf_path)
        text = ""
        for page in doc:
            blocks = page.get_text("dict")["blocks"]
            for block in blocks:
                if "lines" in block:
                    for line in block["lines"]:
                        for span in line["spans"]:
                            text += span["text"]
                        text += "\n"
        return text

Esta aproximación preserva la estructura de líneas del documento original, aunque puede introducir errores en layouts muy complejos (tablas anidadas, texto en columnas).

#### Configuración de los Modelos

Según el código en ocr_benchmark_notebook.ipynb:

EasyOCR:

    import easyocr

    easyocr_reader = easyocr.Reader(['es', 'en'])  # Spanish and English
    results = easyocr_reader.readtext(image_path)
    text = ' '.join([r[1] for r in results])

La configuración incluye soporte para español e inglés, permitiendo reconocer palabras en ambos idiomas que puedan aparecer en documentos académicos (referencias, términos técnicos).

PaddleOCR (PP-OCRv5):

    from paddleocr import PaddleOCR

    paddleocr_model = PaddleOCR(
        text_detection_model_name="PP-OCRv5_server_det",
        text_recognition_model_name="PP-OCRv5_server_rec",
        use_doc_orientation_classify=False,
        use_doc_unwarping=False,
        use_textline_orientation=True,
    )

    result = paddleocr_model.predict(image_path)
    text = '\n'.join([line['rec_texts'][0] for line in result[0]['rec_res']])

Se utilizaron los modelos "server" que ofrecen mayor precisión a costa de mayor tiempo de inferencia. La versión utilizada fue PaddleOCR 3.2.0.

DocTR:

    from doctr.models import ocr_predictor

    doctr_model = ocr_predictor(
        det_arch="db_resnet50",
        reco_arch="sar_resnet31",
        pretrained=True
    )

    result = doctr_model([image])
    text = result.render()

Se seleccionaron las arquitecturas db_resnet50 para detección y sar_resnet31 para reconocimiento, representando una configuración de alta precisión.

#### Métricas de Evaluación

Se utilizó la biblioteca jiwer para calcular CER y WER de manera estandarizada:

    from jiwer import wer, cer

    def evaluate_text(reference, prediction):
        """
        Calcula métricas de error entre texto de referencia y predicción.

        Args:
            reference: Texto ground truth
            prediction: Texto predicho por el OCR

        Returns:
            dict con WER y CER
        """
        # Normalización básica
        ref_clean = reference.lower().strip()
        pred_clean = prediction.lower().strip()

        return {
            'WER': wer(ref_clean, pred_clean),
            'CER': cer(ref_clean, pred_clean)
        }

La normalización a minúsculas y eliminación de espacios extremos asegura una comparación justa que no penaliza diferencias de capitalización.

### Resultados del Benchmark

#### Resultados de PaddleOCR (Configuración Baseline)

Durante el benchmark inicial se evaluó PaddleOCR con configuración por defecto en un subconjunto del dataset. Los resultados preliminares mostraron variabilidad significativa entre páginas, con CER entre 1.54% y 6.40% dependiendo de la complejidad del layout.

Tabla 20. Variabilidad del CER por tipo de contenido.

Tipo de contenido | CER aproximado | Observaciones
Texto corrido | ~1.5-2% | Mejor rendimiento
Texto con listas | ~3-4% | Rendimiento medio
Tablas | ~5-6% | Mayor dificultad
Encabezados + notas | ~4-5% | Layouts mixtos

Fuente: Elaboración propia.

Observaciones del benchmark inicial:

1. Las páginas con tablas y layouts complejos presentaron mayor error debido a la dificultad de ordenar correctamente las líneas de texto.

1. La página con texto corrido continuo obtuvo el mejor resultado (CER ~1.5%), demostrando la capacidad del modelo para texto estándar.

1. El promedio general se situó en CER ~5-6%, superando el umbral de aceptabilidad para documentos académicos pero con margen de mejora.

1. Los errores más frecuentes fueron: confusión de acentos, caracteres duplicados, y errores en signos de puntuación.

#### Comparativa de Modelos

Los tres modelos evaluados representan diferentes paradigmas de OCR:

Tabla 21. Comparativa de arquitecturas OCR evaluadas.

Modelo | Tipo | Componentes | Fortalezas Clave
EasyOCR | End-to-end (det + rec) | CRAFT + CRNN/Transformer | Ligero, fácil de usar, multilingüe
PaddleOCR | End-to-end (det + rec + cls) | DB + SVTR/CRNN | Soporte multilingüe robusto, pipeline configurable
DocTR | End-to-end (det + rec) | DB/LinkNet + CRNN/SAR/ViTSTR | Orientado a investigación, API limpia

Fuente: Elaboración propia.

#### Análisis Cualitativo de Errores

Un análisis cualitativo de los errores producidos reveló patrones específicos:

Errores de acentuación:

· información → informacion (pérdida de acento)

· más → mas (cambio de significado)

· él → el (cambio de significado)

Errores de caracteres especiales:

· año → ano (pérdida de eñe)

· ¿Cómo → Como (pérdida de signos invertidos)

Errores de duplicación:

· titulación → titulacióon (carácter duplicado)

· documento → doccumento (consonante duplicada)

Ejemplo de predicción de PaddleOCR para una página:

"Escribe siempre al menos un párrafo de introducción en cada capítulo o apartado, explicando de qué vas a tratar en esa sección. Evita que aparezcan dos encabezados de nivel consecutivos sin ningún texto entre medias. [...] En esta titulacióon se cita de acuerdo con la normativa Apa."

Errores identificados en este ejemplo:

· titulacióon en lugar de titulación (carácter duplicado)

· Apa en lugar de APA (capitalización)

### Justificación de la Selección de PaddleOCR

#### Criterios de Selección

La selección de PaddleOCR para la fase de optimización se basó en los siguientes criterios:

Tabla 22. Evaluación de criterios de selección.

Criterio | EasyOCR | PaddleOCR | DocTR
CER benchmark | ~6-8% | ~5-6% | ~7-9%
Configurabilidad | Baja (3 params) | Alta (>10 params) | Media (5 params)
Soporte español | Sí | Sí (dedicado) | Limitado
Documentación | Media | Alta | Alta
Mantenimiento | Medio | Alto | Medio

Fuente: Elaboración propia.

#### Hiperparámetros Disponibles en PaddleOCR

PaddleOCR expone múltiples hiperparámetros ajustables, clasificados por etapa del pipeline:

Detección:

· text_det_thresh: Umbral de probabilidad para píxeles de texto

· text_det_box_thresh: Umbral de confianza para cajas detectadas

· text_det_unclip_ratio: Factor de expansión de cajas

Reconocimiento:

· text_rec_score_thresh: Umbral de confianza para resultados

Preprocesamiento:

· use_textline_orientation: Clasificación de orientación de línea

· use_doc_orientation_classify: Clasificación de orientación de documento

· use_doc_unwarping: Corrección de deformación

Esta riqueza de configuración permite explorar sistemáticamente el espacio de hiperparámetros mediante técnicas de optimización automática.

#### Decisión Final

Se selecciona PaddleOCR (PP-OCRv5) para la fase de optimización debido a:

1. Resultados iniciales prometedores: CER ~5% en configuración por defecto, con potencial de mejora

2. Alta configurabilidad: Más de 10 hiperparámetros ajustables en tiempo de inferencia

3. Pipeline modular: Permite aislar el impacto de cada componente

4. Soporte activo para español: Modelos específicos y actualizaciones frecuentes

5. Documentación técnica: Descripción detallada de cada parámetro

### Limitaciones del Benchmark

1. Tamaño reducido: Solo 5 páginas evaluadas en el benchmark comparativo inicial. Esto limita la generalización de las conclusiones.

1. Único tipo de documento: Documentos académicos de UNIR únicamente. Otros tipos de documentos (facturas, formularios, contratos) podrían presentar resultados diferentes.

1. Ground truth automático: El texto de referencia se extrajo programáticamente del PDF, lo cual puede introducir errores en layouts complejos donde el orden de lectura no es evidente.

1. Ejecución en CPU: Todos los experimentos se realizaron en CPU, limitando la exploración de configuraciones que podrían beneficiarse de aceleración GPU.

### Resumen de la Sección

Esta sección ha presentado:

1. La identificación del problema y los criterios de éxito establecidos

2. La configuración detallada del benchmark con tres soluciones OCR

3. Los resultados cuantitativos y cualitativos obtenidos

4. La justificación de la selección de PaddleOCR para optimización

5. Las limitaciones reconocidas del benchmark

Fuentes de datos utilizadas:

· ocr_benchmark_notebook.ipynb: Código del benchmark

· Documentación oficial de PaddleOCR

## Desarrollo de la comparativa: Optimización de hiperparámetros

### Introducción

Esta sección describe el proceso de optimización de hiperparámetros de PaddleOCR utilizando Ray Tune con el algoritmo de búsqueda Optuna. Los experimentos fueron implementados en src/run_tuning.py con la librería de utilidades src/raytune_ocr.py, y los resultados se almacenaron en src/results/.

La optimización de hiperparámetros representa una alternativa al fine-tuning tradicional que no requiere:

· Acceso a GPU dedicada

· Dataset de entrenamiento etiquetado

· Modificación de los pesos del modelo

### Configuración del Experimento

#### Entorno de Ejecución

El experimento se ejecutó en el siguiente entorno:

Tabla 23. Entorno de ejecución del experimento.

Componente | Versión/Especificación
Sistema operativo | Ubuntu 24.04.3 LTS
Python | 3.12.3
PaddlePaddle | 3.2.2
PaddleOCR | 3.3.2
Ray | 2.52.1
Optuna | 4.7.0
CPU | AMD Ryzen 7 5800H
RAM | 16 GB DDR4
GPU | NVIDIA RTX 3060 Laptop (5.66 GB VRAM)

Fuente: Elaboración propia.

#### Arquitectura de Ejecución

Debido a incompatibilidades entre Ray y PaddleOCR cuando se ejecutan en el mismo proceso, se implementó una arquitectura basada en subprocesos:

Figura 6. Arquitectura de ejecución con subprocesos

Fuente: Elaboración propia.

El script src/paddle_ocr_tuning.py actúa como wrapper que:

1. Recibe hiperparámetros por línea de comandos

2. Inicializa PaddleOCR con la configuración especificada

3. Evalúa sobre el dataset

4. Retorna métricas en formato JSON

    python paddle_ocr_tuning.py \
        --pdf-folder ./dataset \
        --textline-orientation True \
        --text-det-box-thresh 0.5 \
        --text-det-thresh 0.4 \
        --text-rec-score-thresh 0.6

Salida:

    {
        "CER": 0.0125,
        "WER": 0.1040,
        "TIME": 331.09,
        "PAGES": 5,
        "TIME_PER_PAGE": 66.12
    }

#### Dataset Extendido

Para la fase de optimización se extendió el dataset:

Tabla 24. Características del dataset de optimización.

Característica | Valor
Páginas totales | 24
Páginas por trial | 5 (páginas 5-10)
Estructura | Carpetas img/ y txt/ pareadas
Resolución | 300 DPI
Formato imagen | PNG

Fuente: Elaboración propia.

La clase ImageTextDataset en src/dataset_manager.py gestiona la carga de pares imagen-texto:

    class ImageTextDataset:
        def __init__(self, root):
            """
            Carga pares (imagen, texto) de carpetas pareadas.

            Estructura esperada:
            root/
              0/
                img/
                  page_0001.png
                txt/
                  page_0001.txt
            """
            self.pairs = []
            for doc_folder in sorted(os.listdir(root)):
                img_folder = os.path.join(root, doc_folder, 'img')
                txt_folder = os.path.join(root, doc_folder, 'txt')
                # Cargar pares...

        def __getitem__(self, idx):
            img_path, txt_path = self.pairs[idx]
            return PIL.Image.open(img_path), open(txt_path).read()

#### Espacio de Búsqueda

El espacio de búsqueda se definió considerando los hiperparámetros más relevantes identificados en la documentación de PaddleOCR:

    from ray import tune
    from ray.tune.search.optuna import OptunaSearch

    search_space = {
        # Parámetros booleanos
        "use_doc_orientation_classify": tune.choice([True, False]),
        "use_doc_unwarping": tune.choice([True, False]),
        "textline_orientation": tune.choice([True, False]),

        # Parámetros continuos (umbrales)
        "text_det_thresh": tune.uniform(0.0, 0.7),
        "text_det_box_thresh": tune.uniform(0.0, 0.7),
        "text_det_unclip_ratio": tune.choice([0.0]),  # Fijado
        "text_rec_score_thresh": tune.uniform(0.0, 0.7),
    }

Tabla 25. Descripción detallada del espacio de búsqueda.

Parámetro | Tipo | Rango | Descripción
use_doc_orientation_classify | Booleano | {True, False} | Clasificación de orientación del documento completo
use_doc_unwarping | Booleano | {True, False} | Corrección de deformación/curvatura
textline_orientation | Booleano | {True, False} | Clasificación de orientación por línea de texto
text_det_thresh | Continuo | [0.0, 0.7] | Umbral de probabilidad para píxeles de texto
text_det_box_thresh | Continuo | [0.0, 0.7] | Umbral de confianza para cajas detectadas
text_det_unclip_ratio | Fijo | 0.0 | Coeficiente de expansión (no explorado)
text_rec_score_thresh | Continuo | [0.0, 0.7] | Umbral de confianza de reconocimiento

Fuente: Elaboración propia.

Justificación del espacio:

1. Rango [0.0, 0.7] para umbrales: Se evitan valores extremos (>0.7) que podrían filtrar demasiado texto válido, y se incluye 0.0 para evaluar el impacto de desactivar el filtrado.

1. text_det_unclip_ratio fijo: Por decisión de diseño inicial, este parámetro se mantuvo constante para reducir la dimensionalidad del espacio de búsqueda.

1. Parámetros booleanos completos: Los tres parámetros de preprocesamiento se exploran completamente para identificar cuáles son necesarios para documentos digitales.

#### Configuración de Ray Tune

    tuner = tune.Tuner(
        trainable_paddle_ocr,
        tune_config=tune.TuneConfig(
            metric="CER",
            mode="min",
            search_alg=OptunaSearch(),
            num_samples=64,
            max_concurrent_trials=2
        ),
        run_config=air.RunConfig(
            verbose=2,
            log_to_file=False
        ),
        param_space=search_space
    )

Tabla 26. Parámetros de configuración de Ray Tune.

Parámetro | Valor | Justificación
Métrica objetivo | CER | Métrica estándar para OCR
Modo | min | Minimizar tasa de error
Algoritmo | OptunaSearch (TPE) | Eficiente para espacios mixtos
Número de trials | 64 | Balance entre exploración y tiempo
Trials concurrentes | 2 | Limitado por memoria disponible

Fuente: Elaboración propia.

Elección de 64 trials:

El número de trials se eligió considerando:

· Espacio de búsqueda de 7 dimensiones (3 booleanas + 4 continuas)

· Tiempo estimado por trial: ~6 minutos

· Tiempo total objetivo: <8 horas

· Regla empírica: 10× dimensiones = 70 trials mínimo recomendado

### Resultados de la Optimización

#### Ejecución del Experimento

El experimento se ejecutó exitosamente con los siguientes resultados globales:

Tabla 27. Resumen de la ejecución del experimento.

Métrica | Valor
Trials completados | 64/64
Trials fallidos | 0
Tiempo total | ~6.4 horas
Tiempo medio por trial | 367.72 segundos
Páginas procesadas | 320 (64 trials × 5 páginas)

Fuente: Elaboración propia.

#### Estadísticas Descriptivas

Del archivo CSV de resultados (raytune_paddle_subproc_results_20251207_192320.csv):

Tabla 28. Estadísticas descriptivas de los 64 trials.

Estadística | CER | WER | Tiempo (s) | Tiempo/Página (s)
count | 64 | 64 | 64 | 64
mean | 5.25% | 14.28% | 347.61 | 69.42
std | 11.03% | 10.75% | 7.88 | 1.57
min | 1.15% | 9.89% | 320.97 | 64.10
25% | 1.20% | 10.04% | 344.24 | 68.76
50% (mediana) | 1.23% | 10.20% | 346.42 | 69.19
75% | 4.03% | 13.20% | 350.14 | 69.93
max | 51.61% | 59.45% | 368.57 | 73.63

Fuente: Elaboración propia.

Observaciones:

1. Alta varianza en CER: La desviación estándar (11.03%) es mayor que la media (5.25%), indicando una distribución muy dispersa con algunos valores extremos.

1. Mediana vs Media: La mediana del CER (1.23%) es mucho menor que la media (5.25%), confirmando una distribución sesgada hacia valores bajos con outliers altos.

1. Tiempo consistente: El tiempo de ejecución es muy estable (std = 1.57 s/página), indicando que las configuraciones de hiperparámetros no afectan significativamente el tiempo de inferencia.

#### Distribución de Resultados

Tabla 29. Distribución de trials por rango de CER.

Rango CER | Número de trials | Porcentaje
< 2% | 43 | 67.2%
2% - 5% | 7 | 10.9%
5% - 10% | 2 | 3.1%
10% - 20% | 5 | 7.8%
> 20% | 7 | 10.9%

Fuente: Elaboración propia.

La mayoría de trials (67.2%) alcanzaron CER < 2%, cumpliendo el objetivo establecido. Sin embargo, un 10.9% de trials presentaron fallos catastróficos (CER > 20%).

#### Mejor Configuración Encontrada

La configuración que minimizó el CER fue:

    Best CER: 0.011535 (1.15%)
    Best WER: 0.098902 (9.89%)

    Configuración óptima:
      textline_orientation: True
      use_doc_orientation_classify: False
      use_doc_unwarping: False
      text_det_thresh: 0.4690
      text_det_box_thresh: 0.5412
      text_det_unclip_ratio: 0.0
      text_rec_score_thresh: 0.6350

Tabla 30. Configuración óptima identificada.

Parámetro | Valor óptimo | Valor por defecto | Cambio
textline_orientation | True | False | Activado
use_doc_orientation_classify | False | False | Sin cambio
use_doc_unwarping | False | False | Sin cambio
text_det_thresh | 0.4690 | 0.3 | +0.169
text_det_box_thresh | 0.5412 | 0.6 | -0.059
text_det_unclip_ratio | 0.0 | 1.5 | -1.5 (fijado)
text_rec_score_thresh | 0.6350 | 0.5 | +0.135

Fuente: Elaboración propia.

#### Análisis de Correlación

Se calculó la correlación de Pearson entre los parámetros continuos y las métricas de error:

Tabla 31. Correlación de parámetros con CER.

Parámetro | Correlación con CER | Interpretación
text_det_thresh | -0.523 | Correlación moderada negativa
text_det_box_thresh | +0.226 | Correlación débil positiva
text_rec_score_thresh | -0.161 | Correlación débil negativa
text_det_unclip_ratio | NaN | Varianza cero (valor fijo)

Fuente: Elaboración propia.

Tabla 32. Correlación de parámetros con WER.

Parámetro | Correlación con WER | Interpretación
text_det_thresh | -0.521 | Correlación moderada negativa
text_det_box_thresh | +0.227 | Correlación débil positiva
text_rec_score_thresh | -0.173 | Correlación débil negativa

Fuente: Elaboración propia.

Hallazgo clave: El parámetro text_det_thresh muestra la correlación más fuerte (-0.52 con ambas métricas), indicando que valores más altos de este umbral tienden a reducir el error. Este umbral controla qué píxeles se consideran "texto" en el mapa de probabilidad del detector.

#### Impacto del Parámetro textline_orientation

El parámetro booleano textline_orientation demostró tener el mayor impacto en el rendimiento:

Tabla 33. Impacto del parámetro textline_orientation.

textline_orientation | CER Medio | CER Std | WER Medio | N trials
True | 3.76% | 7.12% | 12.73% | 32
False | 12.40% | 14.93% | 21.71% | 32

Fuente: Elaboración propia.

Interpretación:

1. Reducción del CER: Con textline_orientation=True, el CER medio es 3.3 veces menor (3.76% vs 12.40%).

1. Menor varianza: La desviación estándar también se reduce significativamente (7.12% vs 14.93%), indicando resultados más consistentes.

1. Reducción del CER: 69.7% cuando se habilita la clasificación de orientación de línea.

Figura 7. Impacto de textline_orientation en CER

Fuente: Elaboración propia.

Explicación técnica:

El parámetro textline_orientation activa un clasificador que determina la orientación de cada línea de texto detectada. Para documentos con layouts mixtos (tablas, encabezados laterales, direcciones postales), este clasificador asegura que el texto se lea en el orden correcto, evitando la mezcla de líneas de diferentes columnas o secciones.

#### Análisis de Fallos Catastróficos

Los trials con CER muy alto (>20%) presentaron patrones específicos:

Tabla 34. Características de trials con fallos catastróficos.

Trial | CER | text_det_thresh | textline_orientation | Diagnóstico
#47 | 51.61% | 0.017 | True | Umbral muy bajo
#23 | 43.29% | 0.042 | False | Umbral bajo + sin orientación
#12 | 38.76% | 0.089 | False | Umbral bajo + sin orientación
#56 | 35.12% | 0.023 | False | Umbral muy bajo + sin orientación

Fuente: Elaboración propia.

Diagnóstico:

1. Umbral de detección muy bajo (text_det_thresh < 0.1): Genera exceso de falsos positivos en la detección, incluyendo artefactos, manchas y ruido como "texto".

1. Desactivación de orientación: Sin el clasificador de orientación, las líneas de texto pueden mezclarse incorrectamente, especialmente en tablas.

1. Combinación fatal: La peor combinación es umbral bajo + sin orientación, que produce textos completamente desordenados y con inserciones de ruido.

Recomendación: Evitar text_det_thresh < 0.1 en cualquier configuración.

### Comparación Baseline vs Optimizado

#### Evaluación sobre Dataset Completo

La configuración óptima identificada se evaluó sobre el dataset completo de 24 páginas, comparando con la configuración baseline:

Configuración Baseline:

    baseline_config = {
        "textline_orientation": False,  # Valor por defecto
        "use_doc_orientation_classify": False,
        "use_doc_unwarping": False,
        "text_det_thresh": 0.3,  # Valor por defecto
        "text_det_box_thresh": 0.6,  # Valor por defecto
        "text_det_unclip_ratio": 1.5,  # Valor por defecto
        "text_rec_score_thresh": 0.5,  # Valor por defecto
    }

Configuración Optimizada:

    optimized_config = {
        "textline_orientation": True,
        "use_doc_orientation_classify": False,
        "use_doc_unwarping": False,
        "text_det_thresh": 0.4690,
        "text_det_box_thresh": 0.5412,
        "text_det_unclip_ratio": 0.0,
        "text_rec_score_thresh": 0.6350,
    }

Tabla 35. Comparación baseline vs optimizado (24 páginas).

Modelo | CER | Precisión Caracteres | WER | Precisión Palabras
PaddleOCR (Baseline) | 7.78% | 92.22% | 14.94% | 85.06%
PaddleOCR-HyperAdjust | 1.49% | 98.51% | 7.62% | 92.38%

Fuente: Elaboración propia.

#### Métricas de Mejora

Tabla 36. Análisis cuantitativo de la mejora.

Forma de Medición | CER | WER
Valor baseline | 7.78% | 14.94%
Valor optimizado | 1.49% | 7.62%
Mejora absoluta | -6.29 pp | -7.32 pp
Reducción relativa del error | 80.9% | 49.0%
Factor de mejora | 5.2× | 2.0×

Fuente: Elaboración propia.

Figura 8. Comparación Baseline vs Optimizado (24 páginas)

Fuente: Elaboración propia.

#### Impacto Práctico

En un documento típico de 10,000 caracteres:

Tabla 37. En un documento típico de 10,000 caracteres

Configuración | Caracteres con error | Palabras con error*
Baseline | ~778 | ~225
Optimizada | ~149 | ~115
Reducción | 629 menos | 110 menos

Fuente: Elaboración propia.

*Asumiendo longitud media de palabra = 6.6 caracteres en español.

Interpretación del notebook:

"La optimización de hiperparámetros mejoró la precisión de caracteres de 92.2% a 98.5%, una ganancia de 6.3 puntos porcentuales. Aunque el baseline ya ofrecía resultados aceptables, la configuración optimizada reduce los errores residuales en un 80.9%."

### Tiempo de Ejecución

Tabla 38. Métricas de tiempo del experimento.

Métrica | Valor
Tiempo total del experimento | ~6.4 horas
Tiempo medio por trial | 347.61 segundos (~5.8 min)
Tiempo medio por página | 69.42 segundos
Variabilidad (std) | 1.57 segundos/página
Páginas procesadas totales | 320

Fuente: Elaboración propia.

Observaciones:

1. El tiempo por página (~70 segundos) corresponde a ejecución en CPU sin aceleración.

2. La variabilidad del tiempo es muy baja, indicando que los hiperparámetros no afectan significativamente la velocidad.

3. Con GPU, los tiempos serían 10-50× menores según benchmarks de PaddleOCR.

### Resumen de la Sección

Esta sección ha presentado:

1. Configuración del experimento: Arquitectura de subprocesos, dataset extendido, espacio de búsqueda de 7 dimensiones

1. Resultados estadísticos:

- CER medio: 5.25% (std: 11.03%) - CER mínimo: 1.15% - 67.2% de trials con CER < 2%

1. Hallazgos clave:

- textline_orientation=True reduce CER en 69.7% - text_det_thresh tiene correlación -0.52 con CER - Valores de text_det_thresh < 0.1 causan fallos catastróficos

1. Mejora final: CER reducido de 7.78% a 1.49% (reducción del 80.9%)

Fuentes de datos:

· src/run_tuning.py: Script principal de optimización

· src/raytune_ocr.py: Librería de utilidades Ray Tune

· src/results/: Resultados CSV de los trials

## Discusión y análisis de resultados

### Introducción

Esta sección presenta un análisis consolidado de los resultados obtenidos en las fases de benchmark comparativo y optimización de hiperparámetros. Se discuten las implicaciones prácticas, se evalúa el cumplimiento de los objetivos planteados y se identifican las limitaciones del estudio.

### Resumen Consolidado de Resultados

#### Progresión del Rendimiento

Tabla 39. Evolución del rendimiento a través del estudio.

Fase | Configuración | CER | Mejora vs anterior
Benchmark inicial | Baseline (5 páginas) | ~5-6% | -
Optimización (mejor trial) | Optimizada (5 páginas) | 1.15% | ~80%
Validación final | Optimizada (24 páginas) | 1.49% | -

Fuente: Elaboración propia.

El incremento del CER de 1.15% (5 páginas) a 1.49% (24 páginas) es esperado debido a la mayor diversidad de layouts en el dataset completo.

#### Comparación con Objetivo

Tabla 40. Verificación del objetivo general.

Aspecto | Objetivo | Resultado | Cumplimiento
Métrica | CER | CER | ✓
Umbral | < 2% | 1.49% | ✓
Método | Sin fine-tuning | Solo hiperparámetros | ✓
Hardware | Sin GPU | CPU only | ✓

Fuente: Elaboración propia.

### Análisis Detallado de Hiperparámetros

#### Jerarquía de Importancia

Basándose en el análisis de correlación y el impacto observado:

Tabla 41. Ranking de importancia de hiperparámetros.

Rank | Parámetro | Impacto | Evidencia
1 | textline_orientation | Crítico | Reduce CER 69.7%
2 | text_det_thresh | Alto | Correlación -0.52
3 | text_rec_score_thresh | Medio | Correlación -0.16
4 | text_det_box_thresh | Bajo | Correlación +0.23
5 | use_doc_orientation_classify | Nulo | Sin mejora
6 | use_doc_unwarping | Nulo | Sin mejora

Fuente: Elaboración propia.

#### Análisis del Parámetro textline_orientation

Por qué es tan importante:

El clasificador de orientación de línea resuelve un problema fundamental en documentos con layouts complejos: determinar el orden correcto de lectura. Sin este clasificador:

1. Las líneas de una tabla pueden mezclarse con texto adyacente

2. Los encabezados laterales pueden insertarse en posiciones incorrectas

3. El texto en columnas puede leerse en orden incorrecto

Para documentos académicos que típicamente incluyen tablas, listas y encabezados multinivel, este clasificador es esencial.

Recomendación: Siempre activar textline_orientation=True para documentos estructurados.

#### Análisis del Parámetro text_det_thresh

Comportamiento observado:

Tabla 42. Comportamiento observado

Rango | CER típico | Comportamiento
0.0 - 0.1 | >20% | Fallos catastróficos
0.1 - 0.3 | 5-15% | Rendimiento pobre
0.3 - 0.5 | 1-5% | Rendimiento óptimo
0.5 - 0.7 | 2-8% | Rendimiento aceptable

Fuente: Elaboración propia.

Interpretación:

· Valores muy bajos (< 0.1) incluyen ruido y artefactos como "texto"

· Valores muy altos (> 0.6) filtran texto legítimo de bajo contraste

· El rango óptimo (0.3-0.5) balancea precisión y recall de detección

Valor óptimo encontrado: 0.4690

#### Parámetros sin Impacto Significativo

use_doc_orientation_classify y use_doc_unwarping:

Estos módulos están diseñados para:

· Documentos escaneados con rotación

· Fotografías de documentos con perspectiva

· Documentos curvados o deformados

Para documentos PDF digitales como los evaluados, estos módulos son innecesarios e incluso pueden introducir artefactos. Su desactivación reduce el tiempo de procesamiento sin pérdida de precisión.

### Análisis de Casos de Fallo

#### Clasificación de Errores

Tabla 43. Tipología de errores observados.

Tipo de error | Frecuencia | Ejemplo | Causa probable
Pérdida de acentos | Alta | más → mas | Modelo de reconocimiento
Duplicación de caracteres | Media | titulación → titulacióon | Solapamiento de detecciones
Confusión de puntuación | Media | ¿ → ? | Caracteres similares
Pérdida de eñe | Baja | año → ano | Modelo de reconocimiento
Texto desordenado | Variable | Mezcla de líneas | Fallo de orientación

Fuente: Elaboración propia.

#### Patrones de Fallo por Tipo de Contenido

Tabla 44. Tasa de error por tipo de contenido.

Tipo de contenido | CER estimado | Factor de riesgo
Párrafos de texto | ~1% | Bajo
Listas numeradas | ~2% | Medio
Tablas simples | ~3% | Medio
Encabezados + pie de página | ~2% | Medio
Tablas complejas | ~5% | Alto
Texto en columnas | ~4% | Alto

Fuente: Elaboración propia.

### Comparación con Objetivos Específicos

Tabla 45. Cumplimiento de objetivos específicos.

Objetivo | Descripción | Resultado | Estado
OE1 | Comparar soluciones OCR | EasyOCR, PaddleOCR, DocTR evaluados; PaddleOCR seleccionado | ✓ Cumplido
OE2 | Preparar dataset de evaluación | 24 páginas con ground truth | ✓ Cumplido
OE3 | Identificar hiperparámetros críticos | textline_orientation y text_det_thresh identificados | ✓ Cumplido
OE4 | Optimizar con Ray Tune (≥50 trials) | 64 trials ejecutados | ✓ Cumplido
OE5 | Validar configuración optimizada | CER: 7.78% → 1.49% documentado | ✓ Cumplido

Fuente: Elaboración propia.

### Limitaciones del Estudio

#### Limitaciones de Generalización

1. Tipo de documento único: Solo se evaluaron documentos académicos de UNIR. La configuración óptima puede no ser transferible a otros tipos de documentos (facturas, formularios, contratos).

1. Idioma único: El estudio se centró en español. Otros idiomas con diferentes características ortográficas podrían requerir configuraciones diferentes.

1. Formato único: Solo se evaluaron PDFs digitales. Documentos escaneados o fotografías de documentos podrían beneficiarse de diferentes configuraciones.

#### Limitaciones Metodológicas

1. Ground truth automático: El texto de referencia se extrajo programáticamente del PDF, lo cual puede introducir errores en layouts complejos donde el orden de lectura no es evidente.

1. Tamaño del dataset: 24 páginas es un dataset pequeño. Un dataset más amplio proporcionaría estimaciones más robustas.

1. Parámetro fijo: text_det_unclip_ratio se mantuvo en 0.0 durante todo el experimento. Explorar este parámetro podría revelar mejoras adicionales.

1. Ejecución en CPU: Los tiempos reportados corresponden a ejecución en CPU. El comportamiento con GPU podría diferir.

#### Limitaciones de Validación

1. Sin validación cruzada: No se realizó validación cruzada sobre diferentes subconjuntos del dataset.

1. Sin test set independiente: El dataset de validación final se solapaba parcialmente con el de optimización.

### Implicaciones Prácticas

#### Guía de Configuración Recomendada

Para documentos académicos en español similares a los evaluados:

Configuración recomendada:

    config_recomendada = {
        # OBLIGATORIO
        "textline_orientation": True,

        # RECOMENDADO
        "text_det_thresh": 0.45,  # Rango: 0.4-0.5
        "text_rec_score_thresh": 0.6,  # Rango: 0.5-0.7

        # OPCIONAL
        "text_det_box_thresh": 0.55,  # Rango: 0.5-0.6

        # NO RECOMENDADO para PDFs digitales
        "use_doc_orientation_classify": False,
        "use_doc_unwarping": False,
    }

#### Cuándo Aplicar Esta Metodología

La optimización de hiperparámetros es recomendable cuando:

1. Sin GPU disponible: El fine-tuning requiere GPU; la optimización de hiperparámetros no.

1. Modelo preentrenado adecuado: El modelo ya soporta el idioma objetivo.

1. Dominio específico: Se busca optimizar para un tipo de documento particular.

1. Mejora incremental: El rendimiento baseline es aceptable pero mejorable.

#### Cuándo NO Aplicar Esta Metodología

La optimización de hiperparámetros puede ser insuficiente cuando:

1. Idioma no soportado: El modelo no incluye el idioma en su vocabulario.

1. Escritura manuscrita: Requiere fine-tuning o modelos especializados.

1. Documentos muy degradados: Escaneos de baja calidad o documentos históricos.

1. Requisitos de CER < 0.5%: Puede requerir fine-tuning para alcanzar precisiones muy altas.

### Resumen del Capítulo

Este capítulo ha presentado el desarrollo completo de la contribución:

Planteamiento de la comparativa:

· Evaluación de EasyOCR, PaddleOCR y DocTR

· Selección de PaddleOCR por su configurabilidad

Desarrollo de la comparativa:

· 64 trials de Ray Tune con Optuna

· Identificación de textline_orientation y text_det_thresh como críticos

· CER mínimo alcanzado: 1.15%

Discusión y análisis:

· Mejora del CER de 7.78% a 1.49% (reducción del 80.9%)

· Cumplimiento de todos los objetivos específicos

· Identificación de limitaciones y recomendaciones prácticas

Resultado principal: Se logró alcanzar el objetivo de CER < 2% mediante optimización de hiperparámetros, sin requerir fine-tuning ni recursos GPU.

Fuentes de datos:

· src/run_tuning.py: Script principal de optimización

· src/results/: Resultados CSV de los trials

Imágenes Docker:

· seryus.ddns.net/unir/paddle-ocr-gpu: PaddleOCR con soporte GPU

· seryus.ddns.net/unir/easyocr-gpu: EasyOCR con soporte GPU

· seryus.ddns.net/unir/doctr-gpu: DocTR con soporte GPU

### Validación con Aceleración GPU

Para evaluar la viabilidad práctica del enfoque optimizado en escenarios de producción, se realizó una validación adicional utilizando aceleración GPU. Esta fase complementa los experimentos en CPU presentados anteriormente y demuestra la aplicabilidad del método cuando se dispone de hardware con capacidad de procesamiento paralelo.

#### Configuración del Entorno GPU

Tabla 46. Especificaciones del entorno de validación GPU.

Componente | Especificación
GPU | NVIDIA GeForce RTX 3060 Laptop
VRAM | 5.66 GB
CUDA | 12.4
Sistema Operativo | Ubuntu 24.04.3 LTS
Kernel | 6.14.0-37-generic

Fuente: Elaboración propia.

El entorno de validación representa hardware de consumo típico para desarrollo de aplicaciones de machine learning, permitiendo evaluar el rendimiento en condiciones realistas de despliegue.

#### Comparación CPU vs GPU

Se evaluó el tiempo de procesamiento utilizando la configuración optimizada identificada en la fase anterior, comparando el rendimiento entre CPU y GPU.

Tabla 47. Rendimiento comparativo CPU vs GPU.

Métrica | CPU | GPU (RTX 3060) | Factor de Aceleración
Tiempo/Página | 69.4s | 0.55s | 126x
Dataset completo (45 páginas) | ~52 min | ~25 seg | 126x

Fuente: Elaboración propia.

La aceleración de 126x obtenida con GPU transforma la aplicabilidad práctica del sistema. Mientras que el procesamiento en CPU limita el uso a escenarios de procesamiento por lotes sin restricciones de tiempo, la velocidad con GPU habilita casos de uso interactivos y de tiempo real.

#### Comparación de Modelos PaddleOCR

PaddleOCR ofrece dos variantes de modelos: Mobile (optimizados para dispositivos con recursos limitados) y Server (mayor precisión a costa de mayor consumo de memoria). Se evaluó la viabilidad de ambas variantes en el hardware disponible.

Tabla 48. Comparación de modelos Mobile vs Server en RTX 3060.

Modelo | VRAM Requerida | Resultado | Recomendación
PP-OCRv5 Mobile | 0.06 GB | Funciona correctamente | ✓ Recomendado
PP-OCRv5 Server | 5.3 GB | OOM en página 2 | ✗ Requiere >8 GB VRAM

Fuente: Elaboración propia.

Los modelos Server, a pesar de ofrecer potencialmente mayor precisión, resultan inviables en hardware con VRAM limitada (≤6 GB) debido a errores de memoria (Out of Memory). Los modelos Mobile, con un consumo de memoria 88 veces menor, funcionan de manera estable y ofrecen rendimiento suficiente para el caso de uso evaluado.

#### Conclusiones de la Validación GPU

La validación con aceleración GPU permite extraer las siguientes conclusiones:

1. Aceleración significativa: La GPU proporciona una aceleración de 126x sobre CPU, haciendo viable el procesamiento en tiempo real para aplicaciones interactivas.

1. Modelos Mobile recomendados: Para hardware con VRAM limitada (≤6 GB), los modelos Mobile de PP-OCRv5 ofrecen el mejor balance entre precisión y recursos, funcionando de manera estable sin errores de memoria.

1. Viabilidad práctica: Con GPU, el procesamiento de un documento completo (45 páginas) toma menos de 30 segundos, validando la aplicabilidad en entornos de producción donde el tiempo de respuesta es crítico.

1. Escalabilidad: La arquitectura de microservicios dockerizados utilizada para la validación GPU facilita el despliegue horizontal, permitiendo escalar el procesamiento según demanda.

Esta validación demuestra que la configuración optimizada mediante Ray Tune no solo mejora la precisión (CER: 7.78% → 1.49%) sino que, combinada con aceleración GPU, resulta prácticamente aplicable en escenarios de producción real.

# 5. Conclusiones y trabajo futuro

Este capítulo resume las principales conclusiones del trabajo, evalúa el grado de cumplimiento de los objetivos planteados y propone líneas de trabajo futuro que permitirían ampliar y profundizar los resultados obtenidos.

## Conclusiones

### Conclusiones Generales

Este Trabajo Fin de Máster ha demostrado que es posible mejorar significativamente el rendimiento de sistemas OCR preentrenados mediante optimización sistemática de hiperparámetros, sin requerir fine-tuning ni recursos GPU dedicados.

El objetivo principal del trabajo era alcanzar un CER inferior al 2% en documentos académicos en español. Los resultados obtenidos confirman el cumplimiento de este objetivo:

Tabla 49. Cumplimiento del objetivo de CER.

Métrica | Objetivo | Resultado
CER | < 2% | 1.49%

Fuente: Elaboración propia.

### Conclusiones Específicas

Respecto a OE1 (Comparativa de soluciones OCR):

· Se evaluaron tres soluciones OCR de código abierto: EasyOCR, PaddleOCR (PP-OCRv5) y DocTR

· PaddleOCR demostró el mejor rendimiento base para documentos en español

· La configurabilidad del pipeline de PaddleOCR lo hace idóneo para optimización

Respecto a OE2 (Preparación del dataset):

· Se construyó un dataset estructurado con 24 páginas de documentos académicos

· La clase ImageTextDataset facilita la carga de pares imagen-texto

· El ground truth se extrajo automáticamente del PDF mediante PyMuPDF

Respecto a OE3 (Identificación de hiperparámetros críticos):

· El parámetro textline_orientation es el más influyente: reduce el CER en un 69.7% cuando está habilitado

· El umbral text_det_thresh presenta la correlación más fuerte (-0.52) con el CER

· Los parámetros de corrección de documento (use_doc_orientation_classify, use_doc_unwarping) no aportan mejora en documentos digitales

Respecto a OE4 (Optimización con Ray Tune):

· Se ejecutaron 64 trials con el algoritmo OptunaSearch

· El tiempo total del experimento fue aproximadamente 6 horas (en CPU)

· La arquitectura basada en subprocesos permitió superar incompatibilidades entre Ray y PaddleOCR

Respecto a OE5 (Validación de la configuración):

· Se validó la configuración óptima sobre el dataset completo de 24 páginas

· La mejora obtenida fue del 80.9% en reducción del CER (7.78% → 1.49%)

· La precisión de caracteres alcanzó el 98.51%

### Hallazgos Clave

1. Arquitectura sobre umbrales: Un único parámetro booleano (textline_orientation) tiene más impacto que todos los umbrales continuos combinados.

1. Umbrales mínimos efectivos: Valores de text_det_thresh < 0.1 causan fallos catastróficos (CER >40%).

1. Simplicidad para documentos digitales: Para documentos PDF digitales (no escaneados), los módulos de corrección de orientación y deformación son innecesarios.

1. Optimización sin fine-tuning: Se puede mejorar significativamente el rendimiento de modelos preentrenados mediante ajuste de hiperparámetros de inferencia.

### Contribuciones del Trabajo

1. Metodología reproducible: Se documenta un proceso completo de optimización de hiperparámetros OCR con Ray Tune + Optuna.

1. Análisis de hiperparámetros de PaddleOCR: Se cuantifica el impacto de cada parámetro configurable mediante correlaciones y análisis comparativo.

1. Configuración óptima para español: Se proporciona una configuración validada para documentos académicos en español.

1. Código fuente: Todo el código está disponible en el repositorio GitHub para reproducción y extensión.

### Limitaciones del Trabajo

1. Tipo de documento único: Los experimentos se realizaron únicamente sobre documentos académicos de UNIR. La generalización a otros tipos de documentos requiere validación adicional.

1. Tamaño del dataset: 24 páginas es un corpus limitado para conclusiones estadísticamente robustas.

1. Ground truth automático: La extracción automática del texto de referencia puede introducir errores en layouts complejos.

1. Validación en entorno limitado: Aunque se validó con GPU (126x más rápido que CPU, 0.55s/página), los experimentos se realizaron en hardware de consumo (RTX 3060). Hardware empresarial podría ofrecer mejor rendimiento.

1. Parámetro no explorado: text_det_unclip_ratio permaneció fijo en 0.0 durante todo el experimento.

## Líneas de trabajo futuro

### Extensiones Inmediatas

1. Validación cruzada: Evaluar la configuración óptima en otros tipos de documentos en español (facturas, formularios, textos manuscritos).

1. Exploración de text_det_unclip_ratio: Incluir este parámetro en el espacio de búsqueda.

1. Dataset ampliado: Construir un corpus más amplio y diverso de documentos en español.

### Líneas de Investigación

1. Transfer learning de hiperparámetros: Investigar si las configuraciones óptimas para un tipo de documento transfieren a otros dominios.

1. Optimización multi-objetivo: Considerar simultáneamente CER, WER y tiempo de inferencia como objetivos.

1. AutoML para OCR: Aplicar técnicas de AutoML más avanzadas (Neural Architecture Search, meta-learning).

1. Comparación con fine-tuning: Cuantificar la brecha de rendimiento entre optimización de hiperparámetros y fine-tuning real.

### Aplicaciones Prácticas

1. Herramienta de configuración automática: Desarrollar una herramienta que determine automáticamente la configuración óptima para un nuevo tipo de documento.

1. Integración en pipelines de producción: Implementar la configuración optimizada en sistemas reales de procesamiento documental.

1. Benchmark público: Publicar un benchmark de OCR para documentos en español que facilite la comparación de soluciones.

### Reflexión Final

Este trabajo demuestra que, en un contexto de recursos limitados donde el fine-tuning de modelos de deep learning no es viable, la optimización de hiperparámetros representa una alternativa práctica y efectiva para mejorar sistemas OCR.

La metodología propuesta es reproducible, los resultados son cuantificables, y las conclusiones son aplicables a escenarios reales de procesamiento documental. La reducción del CER del 7.78% al 1.49% representa una mejora sustancial que puede tener impacto directo en aplicaciones downstream como extracción de información, análisis semántico y búsqueda de documentos.

El código fuente y los datos experimentales están disponibles públicamente para facilitar la reproducción y extensión de este trabajo.

Referencias bibliográficas

Akiba, T., Sano, S., Yanase, T., Ohta, T., & Koyama, M. (2019). Optuna: A next-generation hyperparameter optimization framework. Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining, 2623-2631. https://doi.org/10.1145/3292500.3330701

Baek, Y., Lee, B., Han, D., Yun, S., & Lee, H. (2019). Character region awareness for text detection. Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, 9365-9374. https://doi.org/10.1109/CVPR.2019.00959

Bergstra, J., & Bengio, Y. (2012). Random search for hyper-parameter optimization. Journal of Machine Learning Research, 13(1), 281-305. https://jmlr.org/papers/v13/bergstra12a.html

Bergstra, J., Bardenet, R., Bengio, Y., & Kégl, B. (2011). Algorithms for hyper-parameter optimization. Advances in Neural Information Processing Systems, 24, 2546-2554. https://papers.nips.cc/paper/2011/hash/86e8f7ab32cfd12577bc2619bc635690-Abstract.html

Cohen, J. (1988). Statistical power analysis for the behavioral sciences (2nd ed.). Lawrence Erlbaum Associates.

Doran, G. T. (1981). There's a S.M.A.R.T. way to write management's goals and objectives. Management Review, 70(11), 35-36.

Du, Y., Li, C., Guo, R., Yin, X., Liu, W., Zhou, J., Bai, Y., Yu, Z., Yang, Y., Dang, Q., & Wang, H. (2020). PP-OCR: A practical ultra lightweight OCR system. arXiv preprint arXiv:2009.09941. https://arxiv.org/abs/2009.09941

Du, Y., Li, C., Guo, R., Cui, C., Liu, W., Zhou, J., Lu, B., Yang, Y., Liu, Q., Hu, X., Yu, D., & Wang, H. (2023). PP-OCRv4: Mobile scene text detection and recognition. arXiv preprint arXiv:2310.05930. https://arxiv.org/abs/2310.05930

Feurer, M., & Hutter, F. (2019). Hyperparameter optimization. In F. Hutter, L. Kotthoff, & J. Vanschoren (Eds.), Automated machine learning: Methods, systems, challenges (pp. 3-33). Springer. https://doi.org/10.1007/978-3-030-05318-5_1

He, P., Huang, W., Qiao, Y., Loy, C. C., & Tang, X. (2016). Reading scene text in deep convolutional sequences. Proceedings of the AAAI Conference on Artificial Intelligence, 30(1), 3501-3508. https://doi.org/10.1609/aaai.v30i1.10291

JaidedAI. (2020). EasyOCR: Ready-to-use OCR with 80+ supported languages. GitHub. https://github.com/JaidedAI/EasyOCR

Liang, J., Doermann, D., & Li, H. (2005). Camera-based analysis of text and documents: A survey. International Journal of Document Analysis and Recognition, 7(2), 84-104. https://doi.org/10.1007/s10032-004-0138-z

Liao, M., Wan, Z., Yao, C., Chen, K., & Bai, X. (2020). Real-time scene text detection with differentiable binarization. Proceedings of the AAAI Conference on Artificial Intelligence, 34(07), 11474-11481. https://doi.org/10.1609/aaai.v34i07.6812

Liaw, R., Liang, E., Nishihara, R., Moritz, P., Gonzalez, J. E., & Stoica, I. (2018). Tune: A research platform for distributed model selection and training. arXiv preprint arXiv:1807.05118. https://arxiv.org/abs/1807.05118

Mindee. (2021). DocTR: Document Text Recognition. GitHub. https://github.com/mindee/doctr

Moritz, P., Nishihara, R., Wang, S., Tumanov, A., Liaw, R., Liang, E., Elibol, M., Yang, Z., Paul, W., Jordan, M. I., & Stoica, I. (2018). Ray: A distributed framework for emerging AI applications. 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), 561-577. https://www.usenix.org/conference/osdi18/presentation/moritz

Morris, A. C., Maier, V., & Green, P. D. (2004). From WER and RIL to MER and WIL: Improved evaluation measures for connected speech recognition. Eighth International Conference on Spoken Language Processing. https://doi.org/10.21437/Interspeech.2004-668

PaddlePaddle. (2024). PaddleOCR: Awesome multilingual OCR toolkits based on PaddlePaddle. GitHub. https://github.com/PaddlePaddle/PaddleOCR

Pearson, K. (1895). Notes on regression and inheritance in the case of two parents. Proceedings of the Royal Society of London, 58, 240-242. https://doi.org/10.1098/rspl.1895.0041

PyMuPDF. (2024). PyMuPDF documentation. https://pymupdf.readthedocs.io/

Shi, B., Bai, X., & Yao, C. (2016). An end-to-end trainable neural network for image-based sequence recognition and its application to scene text recognition. IEEE Transactions on Pattern Analysis and Machine Intelligence, 39(11), 2298-2304. https://doi.org/10.1109/TPAMI.2016.2646371

Smith, R. (2007). An overview of the Tesseract OCR engine. Ninth International Conference on Document Analysis and Recognition (ICDAR 2007), 2, 629-633. https://doi.org/10.1109/ICDAR.2007.4376991

Zhou, X., Yao, C., Wen, H., Wang, Y., Zhou, S., He, W., & Liang, J. (2017). EAST: An efficient and accurate scene text detector. Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, 5551-5560. https://doi.org/10.1109/CVPR.2017.283

Zoph, B., & Le, Q. V. (2017). Neural architecture search with reinforcement learning. International Conference on Learning Representations (ICLR). https://arxiv.org/abs/1611.01578

Anexo A. Código fuente y datos analizados

## A.1 Repositorio del Proyecto

El código fuente completo y los datos utilizados en este trabajo están disponibles en el siguiente repositorio:

URL del repositorio: https://github.com/seryus/MastersThesis

El repositorio incluye:

· Servicios OCR dockerizados: PaddleOCR, DocTR, EasyOCR con soporte GPU

· Scripts de evaluación: Herramientas para evaluar y comparar modelos OCR

· Scripts de ajuste: Ray Tune con Optuna para optimización de hiperparámetros

· Dataset: Imágenes y textos de referencia utilizados

· Resultados: Archivos CSV con los resultados de los 64 trials por servicio

## A.2 Estructura del Repositorio

    MastersThesis/
    ├── docs/                           # Documentación de la tesis
    │   └── metrics/                    # Métricas de rendimiento OCR
    │       ├── metrics.md              # Resumen comparativo
    │       ├── metrics_paddle.md       # Resultados PaddleOCR
    │       ├── metrics_doctr.md        # Resultados DocTR
    │       └── metrics_easyocr.md      # Resultados EasyOCR
    ├── src/
    │   ├── paddle_ocr/                 # Servicio PaddleOCR
    │   │   ├── Dockerfile.gpu          # Imagen Docker GPU
    │   │   ├── Dockerfile.cpu          # Imagen Docker CPU
    │   │   ├── docker-compose.yml      # Configuración Docker
    │   │   └── main.py                 # API FastAPI
    │   ├── doctr_service/              # Servicio DocTR
    │   │   ├── Dockerfile.gpu
    │   │   ├── docker-compose.yml
    │   │   └── main.py
    │   ├── easyocr_service/            # Servicio EasyOCR
    │   │   ├── Dockerfile.gpu
    │   │   ├── docker-compose.yml
    │   │   └── main.py
    │   ├── dataset/                    # Dataset de evaluación
    │   ├── raytune_ocr.py              # Utilidades compartidas Ray Tune
    │   └── results/                    # Resultados de ajuste CSV
    └── .gitea/workflows/ci.yaml        # Pipeline CI/CD

## A.3 Requisitos de Software

### Sistema de Desarrollo

Tabla 50. Especificaciones del sistema de desarrollo.

Componente | Especificación
Sistema Operativo | Ubuntu 24.04.3 LTS
CPU | AMD Ryzen 7 5800H
RAM | 16 GB DDR4
GPU | NVIDIA RTX 3060 Laptop (5.66 GB VRAM)
CUDA | 12.4

Fuente: Elaboración propia.

### Dependencias

Tabla 51. Dependencias del proyecto.

Componente | Versión
Python | 3.12.3
Docker | 29.1.5
NVIDIA Container Toolkit | Requerido para GPU
Ray | 2.52.1
Optuna | 4.7.0

Fuente: Elaboración propia.

## A.4 Instrucciones de Ejecución de Servicios OCR

### PaddleOCR (Puerto 8002)

Imágenes Docker:

· GPU: seryus.ddns.net/unir/paddle-ocr-gpu

· CPU: seryus.ddns.net/unir/paddle-ocr-cpu

    cd src/paddle_ocr

    # GPU (recomendado)
    docker compose up -d

    # CPU (más lento, 126x)
    docker compose -f docker-compose.cpu-registry.yml up -d

### DocTR (Puerto 8003)

Imagen Docker: seryus.ddns.net/unir/doctr-gpu

    cd src/doctr_service

    # GPU
    docker compose up -d

### EasyOCR (Puerto 8002)

Imagen Docker: seryus.ddns.net/unir/easyocr-gpu

    cd src/easyocr_service

    # GPU
    docker compose up -d

### Verificar Estado del Servicio

    # Verificar salud del servicio
    curl http://localhost:8002/health

    # Respuesta esperada:
    # {"status": "ok", "model_loaded": true, "gpu_name": "NVIDIA GeForce RTX 3060"}

## A.5 Uso de la API OCR

### Evaluar Dataset Completo

    # PaddleOCR - Evaluación completa
    curl -X POST http://localhost:8002/evaluate_full \
      -H "Content-Type: application/json" \
      -d '{
        "pdf_folder": "/app/dataset",
        "save_output": true
      }'

### Evaluar con Hiperparámetros Optimizados

    # PaddleOCR con configuración óptima
    curl -X POST http://localhost:8002/evaluate_full \
      -H "Content-Type: application/json" \
      -d '{
        "pdf_folder": "/app/dataset",
        "use_doc_orientation_classify": true,
        "use_doc_unwarping": false,
        "textline_orientation": true,
        "text_det_thresh": 0.0462,
        "text_det_box_thresh": 0.4862,
        "text_det_unclip_ratio": 0.0,
        "text_rec_score_thresh": 0.5658,
        "save_output": true
      }'

## A.6 Ajuste de Hiperparámetros con Ray Tune

### Ejecutar Ajuste

    cd src

    # Activar entorno virtual
    source ../.venv/bin/activate

    # PaddleOCR (64 muestras)
    python -c "
    from raytune_ocr import *

    ports = [8002]
    check_workers(ports, 'PaddleOCR')
    trainable = create_trainable(ports, paddle_ocr_payload)
    results = run_tuner(trainable, PADDLE_OCR_SEARCH_SPACE, num_samples=64)
    analyze_results(results, prefix='raytune_paddle', config_keys=PADDLE_OCR_CONFIG_KEYS)
    "

### Servicios y Puertos

Tabla 52. Servicios Docker y puertos.

Servicio | Puerto | Script de Ajuste
PaddleOCR | 8002 | paddle_ocr_payload
DocTR | 8003 | doctr_payload
EasyOCR | 8002 | easyocr_payload

Fuente: Elaboración propia.

## A.7 Métricas de Rendimiento

Los resultados detallados de las evaluaciones y ajustes de hiperparámetros se encuentran en:

· Métricas Generales - Comparativa de los tres servicios

· PaddleOCR - Mejor precisión (7.76% CER baseline, 1.49% optimizado)

· DocTR - Más rápido (0.50s/página)

· EasyOCR - Balance intermedio

### Resumen de Resultados

Tabla 53. Resumen de resultados del benchmark por servicio.

Servicio | CER Base | CER Ajustado | Mejora
PaddleOCR | 8.85% | 7.72% | 12.8%
DocTR | 12.06% | 12.07% | 0%
EasyOCR | 11.23% | 11.14% | 0.8%

Fuente: Elaboración propia.

## A.8 Licencia

El código se distribuye bajo licencia MIT.