El presente capítulo constituye el núcleo técnico de este trabajo fin de máster. Siguiendo la estructura de "Comparativa de soluciones" establecida por las instrucciones de UNIR, se desarrollan tres fases interrelacionadas. Estas fases son tres: planteamiento y ejecución del benchmark comparativo, optimización de hiperparámetros mediante Ray Tune, y análisis e interpretación de los resultados.
Antes de abordar la optimización de hiperparámetros, era necesario seleccionar el motor OCR que serviría como base para la experimentación. Para ello, se realizó un estudio comparativo entre tres soluciones de código abierto representativas del estado del arte: EasyOCR, PaddleOCR y DocTR. Los experimentos, documentados en los informes de métricas y en los CSV de resultados del repositorio, permitieron identificar el modelo más prometedor para la fase de optimización posterior.
El reconocimiento óptico de caracteres en documentos académicos en español presenta desafíos específicos que la literatura no ha abordado en profundidad. A diferencia de los benchmarks estándar en inglés, los documentos académicos hispanohablantes combinan características ortográficas propias, como acentos, eñes, diéresis y signos de puntuación invertidos, con una estructura sencilla basada en índice y encabezados.
Los documentos académicos típicos incluyen texto corrido con índice, listas numeradas, encabezados multinivel y notas al pie, lo que complica la tarea de ordenación del texto reconocido. A esto se suma el uso de tipografía profesional con múltiples fuentes, tamaños y estilos (negrita, cursiva), que puede confundir a los modelos de reconocimiento. Aunque los PDFs digitales suelen tener alta calidad, pueden contener artefactos de compresión que degradan la legibilidad de caracteres pequeños o de bajo contraste.
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/`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/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/prepare_dataset.ipynb`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/prepare_dataset.ipynb).
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 el orden de lectura cuando hay secciones con encabezados, listas o saltos de línea, por lo que se documenta junto al pipeline de preparación en [`src/prepare_dataset.ipynb`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/prepare_dataset.ipynb). Para la comparación entre motores, las salidas se guardan en `debugset/` al activar `save_output=True`, y el flujo de trabajo se describe en [`src/README.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/README.md) y en los README de cada servicio: [`src/paddle_ocr/README.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/paddle_ocr/README.md), [`src/easyocr_service/README.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/easyocr_service/README.md), [`src/doctr_service/README.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/doctr_service/README.md).
- **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 Mobile, adecuados para la VRAM disponible. Los modelos Server se probaron y produjeron OOM en este hardware. La versión utilizada fue PaddleOCR 3.3.2.
- **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/paddle_ocr/paddle_ocr_tuning_rest.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/paddle_ocr/paddle_ocr_tuning_rest.py), [`src/easyocr_service/easyocr_tuning_rest.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/easyocr_service/easyocr_tuning_rest.py) y [`src/doctr_service/doctr_tuning_rest.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/doctr_service/doctr_tuning_rest.py).
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, en función de los cambios de formato y de la estructura del texto.
> "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 el orden de lectura cuando hay secciones con encabezados y saltos de línea.
4.**Referencia CPU separada**: Los tiempos en CPU se midieron en un experimento independiente y solo se usan como comparación de rendimiento frente a GPU.
El benchmark comparativo ha permitido identificar PaddleOCR como la solución más prometedora para la fase de optimización, gracias a su combinación de rendimiento base competitivo, alta configurabilidad del pipeline y documentación técnica completa. Sin embargo, el análisis también reveló limitaciones importantes: el tamaño reducido del benchmark (5 páginas), la restricción a un único tipo de documento, y la extracción automática del ground truth que puede introducir errores en el orden de lectura cuando hay secciones con encabezados y saltos de línea. Estas limitaciones se tendrán en cuenta al interpretar los resultados de la fase de optimización.
Fuente: [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md), [`src/results/*.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/*.csv), documentación oficial de PaddleOCR.
Una vez seleccionado PaddleOCR como motor base, el siguiente paso fue explorar sistemáticamente su espacio de configuración para identificar los hiperparámetros que maximizan el rendimiento en documentos académicos en español. Para ello se empleó Ray Tune con el algoritmo de búsqueda Optuna, una combinación que permite explorar eficientemente espacios de búsqueda mixtos (parámetros continuos y categóricos). Los experimentos se implementaron en [`src/run_tuning.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/run_tuning.py) con apoyo de la librería [`src/raytune_ocr.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune_ocr.py), almacenándose los resultados en [`src/results`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results). Esta aproximación ofrece ventajas significativas frente al fine-tuning tradicional: no requiere datasets de entrenamiento etiquetados, no modifica los pesos del modelo preentrenado, y puede ejecutarse con hardware de consumo cuando se dispone de aceleración GPU.
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 infraestructura del proyecto se basa en contenedores Docker para garantizar reproducibilidad y aislamiento de dependencias. Se generaron seis imágenes Docker, cada una optimizada para su propósito específico.
**Tabla 26.** *Imágenes Docker generadas para el proyecto.*
> **Nota:** EasyOCR y PaddleOCR utilizan el mismo puerto (8002). Debido a limitaciones de recursos GPU (VRAM insuficiente para ejecutar múltiples modelos OCR simultáneamente), solo se ejecuta un servicio a la vez durante los experimentos. Por esta razón, EasyOCR tiene su propio archivo Docker Compose separado.
##### Gestión de Volúmenes
Se utilizan volúmenes Docker nombrados para persistir los modelos descargados entre ejecuciones:
**Tabla 28.** *Volúmenes Docker para caché de modelos.*
La clase `ImageTextDataset` gestiona la carga de pares imagen-texto desde la estructura de carpetas pareadas. La implementación está disponible en [`src/paddle_ocr/dataset_manager.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/paddle_ocr/dataset_manager.py), [`src/easyocr_service/dataset_manager.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/easyocr_service/dataset_manager.py) y [`src/doctr_service/dataset_manager.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/doctr_service/dataset_manager.py).
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`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/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`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune/raytune_ocr.py) (ver Anexo A).
Del archivo CSV de resultados [`src/results/raytune_paddle_results_20260119_122609.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/raytune_paddle_results_20260119_122609.csv):
1.**Baja varianza en CER**: La desviación estándar (2.20%) es similar a la media (2.30%), indicando una distribución relativamente consistente sin valores extremos catastróficos.
2.**Mediana vs Media**: La mediana del CER (0.87%) es menor que la media (2.30%), confirmando una distribución ligeramente sesgada hacia valores bajos.
3.**Velocidad GPU**: El tiempo de ejecución promedio es de 0.84 s/página, lo que representa una aceleración significativa respecto a la ejecución en CPU (~69 s/página, 82x más rápido).
La mayoría de trials (67.2%) alcanzaron CER < 2%, cumpliendo el objetivo establecido. Ningún trial presentó fallos catastróficos (CER > 10%), demostrando la estabilidad de la optimización con GPU.
Leyenda: Valores positivos indican que aumentar el parámetro incrementa el CER. Los parámetros booleanos se codifican como 0/1 para el cálculo de la correlación. Abreviaturas: unwarp = `use_doc_unwarping`, orient_doc = `use_doc_orientation_classify`, orient_line = `textline_orientation`, det_thresh = `text_det_thresh`, box_thresh = `text_det_box_thresh`, rec_score = `text_rec_score_thresh`.
**Hallazgo clave**: `use_doc_unwarping` presenta la correlación positiva más alta con CER (0.879), lo que indica que activar este módulo incrementa el error en este dataset. En cambio, `use_doc_orientation_classify` y `textline_orientation` tienen correlación negativa, asociada a mejoras cuando están activados.
El parámetro `textline_orientation` activa un clasificador que determina la orientación de cada línea de texto detectada. Para documentos con índice, encabezados y listas, este clasificador asegura que el texto se lea en el orden correcto, evitando la mezcla de líneas de diferentes secciones.
No se observaron fallos catastróficos (CER > 10%). El CER máximo fue 7.30%, por lo que el análisis se centra en los trials con peor desempeño relativo:
Observación: Los peores resultados muestran variabilidad tanto en `text_det_thresh` como en `textline_orientation`, sin un patrón único dominante en este subconjunto de trials.
La configuración óptima identificada se evaluó sobre el dataset completo de 45 páginas, comparando con la configuración baseline (valores por defecto de PaddleOCR). Los parámetros optimizados más relevantes fueron: `textline_orientation=True`, `use_doc_orientation_classify=True`, `text_det_thresh=0.0462`, `text_det_box_thresh=0.4862`, y `text_rec_score_thresh=0.5658`.
> **Nota sobre generalización:** El mejor trial individual (5 páginas) alcanzó un CER de 0.79%, cumpliendo el objetivo de CER < 2%. Sin embargo, al aplicar la configuración al dataset completo de 45 páginas, el CER aumentó a 7.72%, evidenciando sobreajuste al subconjunto de entrenamiento. Esta diferencia es un hallazgo importante que se discute en la sección de análisis.
Leyenda: CER = Character Error Rate, WER = Word Error Rate. Baseline = configuración por defecto de PaddleOCR. Optimizado = configuración encontrada por Ray Tune. Los valores corresponden al dataset completo de 45 páginas.
La reducción de CER y WER implica menos correcciones manuales en el texto reconocido. En conjunto, los resultados muestran una mejora medible en precisión, aunque la generalización depende del tamaño y representatividad del subconjunto de optimización.
1. El tiempo por página (~0.84 segundos) corresponde a ejecución con GPU (RTX 3060).
2. La variabilidad del tiempo es moderada (std = 0.53 s/página), con algunos trials más lentos debido a configuraciones con módulos de preprocesamiento activos.
3. En comparación, la ejecución en CPU requiere ~69 segundos/página (82× más lento), lo que justifica el uso de GPU para optimización y producción.
Los 64 trials ejecutados con Ray Tune y aceleración GPU revelaron patrones claros en el comportamiento de PaddleOCR. El hallazgo más significativo es que los parámetros estructurales, `textline_orientation` y `use_doc_orientation_classify`, tienen mayor impacto que los umbrales numéricos. Al activarlos se reduce el CER medio de 4.73% a 1.74%. En cuanto a umbrales, valores bajos de `text_det_thresh` (aprox. 0.05) benefician el rendimiento, mientras que `use_doc_unwarping` resulta innecesario para PDFs digitales.
El mejor trial alcanzó un CER de 0.79%, cumpliendo el objetivo de CER < 2%. No obstante, la validación sobre el dataset completo de 45 páginas arrojó un CER de 7.72%, evidenciando sobreajuste al subconjunto de optimización de 5 páginas. Aun así, esto representa una mejora del 12.8% respecto al baseline (8.85%), demostrando el valor de la optimización sistemática incluso cuando la generalización es imperfecta.
Los resultados obtenidos en las secciones anteriores requieren un análisis que trascienda los números individuales para comprender su significado práctico. En esta sección se consolidan los hallazgos del benchmark comparativo y la optimización de hiperparámetros, evaluando hasta qué punto se han cumplido los objetivos planteados y qué limitaciones condicionan la generalización de las conclusiones.
Leyenda: El mejor trial alcanza CER 0.79% (objetivo cumplido). La validación sobre dataset completo muestra CER 7.72%, evidenciando sobreajuste al subconjunto de optimización.
El incremento del CER de 0.79% (5 páginas) a 7.72% (45 páginas) evidencia sobreajuste al subconjunto de optimización. Este fenómeno es esperado cuando se optimiza sobre un subconjunto pequeño y se valida sobre el dataset completo con mayor diversidad de secciones y estilos.
> **Análisis del cumplimiento:** El objetivo de CER < 2% se cumple en el mejor trial individual (0.79%), demostrando que la optimización de hiperparámetros puede alcanzar la precisión objetivo. Sin embargo, la validación sobre el dataset completo (7.72%) muestra que la generalización requiere trabajo adicional, como un subconjunto de optimización más representativo o técnicas de regularización.
Leyenda: Impacto relativo basado en |Pearson| (CER), normalizado respecto al valor máximo.
En términos de correlación lineal, `use_doc_unwarping` es el parámetro con mayor relación absoluta con el CER y su signo positivo indica que activarlo incrementa el error en este dataset. En cambio, `use_doc_orientation_classify` y `textline_orientation` presentan correlación negativa, lo que sugiere mejoras cuando están activados.
El clasificador de orientación de línea resuelve un problema fundamental en documentos con secciones y cambios de formato: determinar el orden correcto de lectura. Sin este clasificador:
El análisis de correlación muestra que valores más bajos de `text_det_thresh` favorecen el rendimiento en este dataset. El valor óptimo encontrado en los trials fue 0.0462, lo que sugiere que una detección más sensible beneficia el resultado.
En la configuración óptima GPU, este parámetro está **activado** (True), a diferencia de lo observado en experimentos anteriores. Esto sugiere que la clasificación de orientación del documento puede beneficiar incluso documentos digitales cuando se combina con `textline_orientation=True`.
> **Nota sobre OE5:** El objetivo de CER < 2% se cumple en el mejor trial individual (0.79%). La validación sobre el dataset completo (7.72%) muestra que la generalización requiere mayor trabajo, identificándose como línea de trabajo futuro.
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 el orden de lectura cuando hay secciones con encabezados y saltos de línea.
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.**Subconjunto de ajuste limitado**: El ajuste de hiperparámetros se realizó sobre 5 páginas (páginas 5-10), lo que contribuyó al sobreajuste observado en la validación del dataset completo.
A lo largo de este capítulo se ha desarrollado el proceso completo de evaluación y optimización de sistemas OCR para documentos académicos en español. El benchmark comparativo inicial permitió seleccionar PaddleOCR como motor base gracias a su combinación de rendimiento y configurabilidad. La posterior optimización con Ray Tune y Optuna, ejecutada sobre 64 trials con aceleración GPU, identificó los parámetros críticos para maximizar el rendimiento: `textline_orientation`, `use_doc_orientation_classify` y `text_det_thresh`.
Los resultados cuantifican tanto los logros como las limitaciones del enfoque. El mejor trial individual alcanzó un CER de 0.79%, cumpliendo holgadamente el objetivo de CER < 2%. Sin embargo, la validación sobre el dataset completo de 45 páginas reveló un CER de 7.72%, lo que representa una mejora del 12.8% respecto al baseline (8.85%) pero evidencia sobreajuste al subconjunto de optimización. Esta observación es valiosa: indica que futuros trabajos deberían emplear subconjuntos de optimización más representativos o aplicar técnicas de regularización.
Desde el punto de vista práctico, la infraestructura dockerizada desarrollada y la aceleración GPU (82× más rápida que CPU) demuestran la viabilidad de esta metodología tanto para experimentación como para despliegue en producción.
- [`src/run_tuning.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/run_tuning.py) - Script principal de optimización
- [`src/raytune/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune/requirements.txt) - Dependencias del orquestador Ray Tune
- [`src/paddle_ocr/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/paddle_ocr/requirements.txt) - Dependencias del servicio PaddleOCR
- [`src/easyocr_service/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/easyocr_service/requirements.txt) - Dependencias del servicio EasyOCR
- [`src/doctr_service/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/doctr_service/requirements.txt) - Dependencias del servicio DocTR
- [`src/results/raytune_paddle_results_20260119_122609.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/raytune_paddle_results_20260119_122609.csv) - Resultados CSV de PaddleOCR
- [`src/results/correlations/paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv) - Correlaciones de hiperparámetros (PaddleOCR)
- [`src/results/raytune_easyocr_results_20260119_120204.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/raytune_easyocr_results_20260119_120204.csv) - Resultados CSV de EasyOCR
- [`src/results/raytune_doctr_results_20260119_121445.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/raytune_doctr_results_20260119_121445.csv) - Resultados CSV de DocTR
- [`src/raytune_paddle_subproc_results_20251207_192320.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune_paddle_subproc_results_20251207_192320.csv) - Referencia de tiempos en CPU para PaddleOCR
Imágenes Docker:
- [`seryus.ddns.net/unir/paddle-ocr-gpu`](https://seryus.ddns.net/unir/-/packages/container/paddle-ocr-gpu/latest) - PaddleOCR con soporte GPU
- [`seryus.ddns.net/unir/easyocr-gpu`](https://seryus.ddns.net/unir/-/packages/container/easyocr-gpu/latest) - EasyOCR con soporte GPU
- [`seryus.ddns.net/unir/doctr-gpu`](https://seryus.ddns.net/unir/-/packages/container/doctr-gpu/latest) - DocTR con soporte GPU
Esta sección presenta la comparación de rendimiento entre ejecución en CPU y GPU, justificando la elección de GPU para el experimento principal y demostrando el impacto práctico de la aceleración por hardware.
Nota: Los requisitos de entorno documentados por dependencias se detallan en [`docs/07_anexo_a.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/07_anexo_a.md), sección A.9.
Se comparó el tiempo de procesamiento entre CPU y GPU utilizando los datos de [`src/raytune_paddle_subproc_results_20251207_192320.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune_paddle_subproc_results_20251207_192320.csv)(CPU) y [`src/results/raytune_paddle_results_20260119_122609.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/raytune_paddle_results_20260119_122609.csv)(GPU).
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.
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 82× 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 ~38 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 mejora la precisión (CER: 8.85% → 7.72% en dataset completo, 0.79% en mejor trial individual) y, combinada con aceleración GPU, resulta prácticamente aplicable en escenarios de producción real.
