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.
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.
2.**Caracteres específicos del español**: Acentos (á, é, í, ó, ú), eñe (ñ), diéresis (ü) y signos de puntuación invertidos (¿, ¡).
3.**Formato formal**: Tipografía profesional con múltiples fuentes, tamaños y estilos (negrita, cursiva).
4.**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 10.** *Soluciones OCR evaluadas en el benchmark comparativo.*
| Solución | Desarrollador | Versión | Justificación de selecció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/`.
La conversión del PDF a imágenes se realizó mediante PyMuPDF (fitz) a 300 DPI, resolución estándar para OCR que proporciona suficiente detalle para caracteres pequeños sin generar archivos excesivamente grandes. La implementación está disponible en `src/ocr_benchmark_notebook.ipynb` (ver Anexo A).
El texto de referencia se extrajo directamente del PDF mediante PyMuPDF, preservando la estructura de líneas del documento original. Esta aproximación puede introducir errores en layouts muy complejos (tablas anidadas, texto en columnas). La implementación está disponible en `src/ocr_benchmark_notebook.ipynb` (ver Anexo A).
- **EasyOCR**: Configurado con 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)**: Se utilizaron los modelos "server" (PP-OCRv5_server_det y PP-OCRv5_server_rec) que ofrecen mayor precisión a costa de mayor tiempo de inferencia. La versión utilizada fue PaddleOCR 3.2.0.
- **DocTR**: Se seleccionaron las arquitecturas db_resnet50 para detección y sar_resnet31 para reconocimiento, representando una configuración de alta precisión.
Se utilizó la biblioteca `jiwer` para calcular CER y WER de manera estandarizada. La normalización a minúsculas y eliminación de espacios extremos asegura una comparación justa que no penaliza diferencias de capitalización. La implementación está disponible en `src/ocr_benchmark_notebook.ipynb` (ver Anexo A).
#### 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.
> "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."
1.**Tamaño reducido**: Solo 5 páginas evaluadas en el benchmark comparativo inicial. Esto limita la generalización de las conclusiones.
2.**Único tipo de documento**: Documentos académicos de UNIR únicamente. Otros tipos de documentos (facturas, formularios, contratos) podrían presentar resultados diferentes.
3.**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.
4.**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.
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`](https://github.com/seryus/MastersThesis/blob/main/src/run_tuning.py) con la librería de utilidades [`src/raytune_ocr.py`](https://github.com/seryus/MastersThesis/blob/main/src/raytune_ocr.py), y los resultados se almacenaron en [`src/results/`](https://github.com/seryus/MastersThesis/tree/main/src/results).
La arquitectura basada en contenedores Docker es fundamental para este proyecto debido a los conflictos de dependencias inherentes entre los diferentes componentes:
- **Conflictos entre motores OCR**: PaddleOCR, DocTR y EasyOCR tienen dependencias mutuamente incompatibles (diferentes versiones de PyTorch/PaddlePaddle, OpenCV, etc.)
- **Incompatibilidades CUDA/cuDNN**: Cada motor OCR requiere versiones específicas de CUDA y cuDNN que no pueden coexistir en un mismo entorno virtual
- **Aislamiento de Ray Tune**: Ray Tune tiene sus propias dependencias que pueden entrar en conflicto con las librerías de inferencia OCR
Esta arquitectura containerizada permite ejecutar cada componente en su entorno aislado óptimo, comunicándose via API REST:
La clase `ImageTextDataset` gestiona la carga de pares imagen-texto desde la estructura de carpetas pareadas. La implementación está disponible en el repositorio (ver Anexo A).
El espacio de búsqueda se definió considerando los hiperparámetros más relevantes identificados en la documentación de PaddleOCR, utilizando `tune.choice()` para parámetros booleanos y `tune.uniform()` para umbrales continuos. La implementación está disponible en `src/raytune/raytune_ocr.py` (ver Anexo A).
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.
2.**`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.
3.**Parámetros booleanos completos**: Los tres parámetros de preprocesamiento se exploran completamente para identificar cuáles son necesarios para documentos digitales.
Se configuró Ray Tune con OptunaSearch como algoritmo de búsqueda, optimizando CER en 64 trials con 2 ejecuciones concurrentes. La implementación está disponible en `src/raytune/raytune_ocr.py` (ver Anexo A).
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.
2.**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.
3.**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 21.** *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 a partir del CSV de resultados.*
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%).
*Fuente: Análisis de [`src/results/`](https://github.com/seryus/MastersThesis/tree/main/src/results) generados por [`src/run_tuning.py`](https://github.com/seryus/MastersThesis/blob/main/src/run_tuning.py).*
*Fuente: Análisis de [`src/results/`](https://github.com/seryus/MastersThesis/tree/main/src/results) generados por [`src/run_tuning.py`](https://github.com/seryus/MastersThesis/blob/main/src/run_tuning.py).*
*Fuente: Análisis de [`src/results/`](https://github.com/seryus/MastersThesis/tree/main/src/results) generados por [`src/run_tuning.py`](https://github.com/seryus/MastersThesis/blob/main/src/run_tuning.py).*
**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.
*Fuente: Análisis de [`src/results/`](https://github.com/seryus/MastersThesis/tree/main/src/results) generados por [`src/run_tuning.py`](https://github.com/seryus/MastersThesis/blob/main/src/run_tuning.py).*
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:
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".
2.**Desactivación de orientación**: Sin el clasificador de orientación, las líneas de texto pueden mezclarse incorrectamente, especialmente en tablas.
3.**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.
La configuración óptima identificada se evaluó sobre el dataset completo de 24 páginas, comparando con la configuración baseline (valores por defecto de PaddleOCR). Los parámetros optimizados más relevantes fueron: `textline_orientation=True`, `text_det_thresh=0.4690`, `text_det_box_thresh=0.5412`, y `text_rec_score_thresh=0.6350`.
*Fuente: Validación final. Código en [`src/run_tuning.py`](https://github.com/seryus/MastersThesis/blob/main/src/run_tuning.py), resultados en [`src/results/`](https://github.com/seryus/MastersThesis/tree/main/src/results).*
*Leyenda: CER = Character Error Rate, WER = Word Error Rate. Baseline = configuración por defecto de PaddleOCR. Optimizado = configuración encontrada por Ray Tune.*
*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%."
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.
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:
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 33.** *Tipología de errores observados.*
| Tipo de error | Frecuencia | Ejemplo | Causa probable |
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).
2.**Idioma único**: El estudio se centró en español. Otros idiomas con diferentes características ortográficas podrían requerir configuraciones diferentes.
3.**Formato único**: Solo se evaluaron PDFs digitales. Documentos escaneados o fotografías de documentos podrían beneficiarse de diferentes configuraciones.
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.
2.**Tamaño del dataset**: 24 páginas es un dataset pequeño. Un dataset más amplio proporcionaría estimaciones más robustas.
3.**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.
4.**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.
2.**Sin test set independiente**: El dataset de validación final se solapaba parcialmente con el de optimización.
- [`src/run_tuning.py`](https://github.com/seryus/MastersThesis/blob/main/src/run_tuning.py): Script principal de optimización
- [`src/results/`](https://github.com/seryus/MastersThesis/tree/main/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 36.** *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 37.** *Rendimiento comparativo CPU vs GPU.*
| Métrica | CPU | GPU (RTX 3060) | Factor de Aceleración |
| Dataset completo (45 páginas) | ~52 min | ~25 seg | **126x** |
*Fuente: Elaboración propia a partir de experimentos.*
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 38.** *Comparación de modelos Mobile vs Server en RTX 3060.*
| 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.
2.**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.
3.**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.
4.**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.
