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. El objetivo principal es identificar la configuración óptima de hiperparámetros que maximice la precisión del reconocimiento de texto sin requerir fine-tuning de los modelos base. -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 45 páginas 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 con aceleración GPU (NVIDIA RTX 3060). +Se realizó un estudio comparativo de tres soluciones OCR de código abierto: EasyOCR, PaddleOCR (PP-OCRv5) y DocTR. Se evaluó su rendimiento mediante las métricas estándar CER (Character Error Rate) y WER (Word Error Rate) sobre un corpus de 45 páginas 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 con aceleración GPU (NVIDIA RTX 3060). -Los resultados demuestran que la optimización de hiperparámetros logró mejoras significativas: el mejor trial individual alcanzó un CER de 0.79% (precisión del 99.21%), cumpliendo el objetivo de CER < 2%. Al validar la configuración optimizada sobre el dataset completo de 45 páginas, se obtuvo una mejora del 12.8% en CER (de 8.85% a 7.72%). 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 en el rendimiento. Adicionalmente, se identificó que el umbral de detección (`text_det_thresh`) presenta una correlación negativa moderada (-0.52) con el error. +Los resultados demuestran que la optimización de hiperparámetros logró mejoras significativas: el mejor trial individual alcanzó un CER de 0.79% (precisión del 99.21%), cumpliendo el objetivo de CER < 2%. Al validar la configuración optimizada sobre el dataset completo de 45 páginas, se obtuvo una mejora del 12.8% en CER (de 8.85% a 7.72%). 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 en el rendimiento. Adicionalmente, se identificó que el umbral de detección (`text_det_thresh`) presenta una correlación positiva moderada (0.43) con el error, lo que indica que valores más bajos tienden a mejorar el rendimiento. + +Fuente: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md), [`src/results/correlations/paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv). Este trabajo demuestra que la optimización de hiperparámetros es una alternativa viable al fine-tuning, especialmente útil cuando se dispone de modelos preentrenados para el idioma objetivo. La infraestructura dockerizada desarrollada permite reproducir los experimentos y facilita la evaluación sistemática de configuraciones OCR.
Abstract
This Master's Thesis addresses the optimization of Artificial Intelligence-based Optical Character Recognition (OCR) systems for Spanish documents. The main objective is to identify the optimal hyperparameter configuration that maximizes text recognition accuracy without requiring fine-tuning of the base models. -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 45 pages 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 with GPU acceleration (NVIDIA RTX 3060). +A comparative study of three open-source OCR solutions was conducted with EasyOCR, PaddleOCR (PP-OCRv5), and DocTR. Their performance was evaluated using standard CER (Character Error Rate) and WER (Word Error Rate) metrics on a corpus of 45 pages 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 with GPU acceleration (NVIDIA RTX 3060). -Results demonstrate that hyperparameter optimization achieved significant improvements: the best individual trial reached a CER of 0.79% (99.21% accuracy), meeting the CER < 2% objective. When validating the optimized configuration on the full 45-page dataset, a 12.8% CER improvement was obtained (from 8.85% to 7.72%). The most relevant finding was that the `textline_orientation` parameter (text line orientation classification) has a critical impact on performance. Additionally, the detection threshold (`text_det_thresh`) was found to have a moderate negative correlation (-0.52) with error. +Results demonstrate that hyperparameter optimization achieved significant improvements. The best individual trial reached a CER of 0.79% (99.21% accuracy), meeting the CER < 2% objective. When validating the optimized configuration on the full 45-page dataset, a 12.8% CER improvement was obtained (from 8.85% to 7.72%). The most relevant finding was that the `textline_orientation` parameter (text line orientation classification) has a critical impact on performance. Additionally, the detection threshold (`text_det_thresh`) showed a moderate positive correlation (0.43) with error, indicating that lower values tend to improve performance. + +Sources: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md), [`src/results/correlations/paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv). This work demonstrates that hyperparameter optimization is a viable alternative to fine-tuning, especially useful when pre-trained models for the target language are available. The dockerized infrastructure developed enables experiment reproducibility and facilitates systematic evaluation of OCR configurations.
1. Introducción
¿Es posible mejorar significativamente un sistema OCR sin reentrenarlo? Esta pregunta, aparentemente simple, encierra un desafío práctico que afecta a investigadores, instituciones educativas y empresas que necesitan digitalizar documentos pero carecen de los recursos para realizar fine-tuning de modelos neuronales. A lo largo de este capítulo se desarrolla la motivación del trabajo, se identifica el problema a resolver y se plantean las preguntas de investigación que guiarán el desarrollo experimental.
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 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. La expansión de la transformación digital empresarial ha impulsado su adopción, aunque 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.
+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.
+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 ¿, ¡) 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.
+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.
+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 índices, listas numeradas y cambios frecuentes de estilo; y saltos de línea que rompen la continuidad del texto. 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.
+Los modelos OCR basados en redes neuronales profundas, como los empleados en PaddleOCR, EasyOCR o DocTR, ofrecen un rendimiento competitivo en benchmarks estándar. 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. 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.
+Estrategia | Datos requeridos | Hardware | Tiempo | Expertise |
Fine-tuning completo | Miles de imágenes etiquetadas | GPU de alta memoria | Días o semanas | Alto |
Fine-tuning parcial | Cientos o miles de imágenes etiquetadas | GPU dedicada | Horas o días | Medio-Alto |
Transfer learning | Centenas de imágenes etiquetadas | GPU dedicada | Horas | Medio |
Optimización de hiperparámetros | Subconjunto de validación | CPU o GPU (CUDA 12.2+ en Docker DocTR) | Horas | Bajo-Medio |
Fuente: [`docs/07_anexo_a.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/07_anexo_a.md), sección A.9..
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.
+La presente investigación surge de una necesidad práctica: optimizar un sistema OCR para documentos académicos en español sin disponer de infraestructura de entrenamiento dedicada para 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 cómputo avanzado 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. 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
Las observaciones anteriores conducen a formular el problema central de este trabajo:
-¿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?
+¿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 y con recursos computacionales de consumo?
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:
@@ -4575,14 +4579,14 @@ mso-bidi-font-family:"Calibri Light";mso-bidi-theme-font:major-latin'>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.
+Esta pregunta evalúa la viabilidad práctica de la metodología propuesta. "Significativamente" se define como una mejora sustancial respecto al baseline, con impacto observable 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.
+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 | GPU de consumo y CPU para referencia de tiempos | Infraestructura multi-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:
@@ -4591,15 +4595,15 @@ mso-bidi-font-family:"Calibri Light";mso-bidi-theme-font:major-latin'>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 documento sigue una estructura que refleja el proceso investigador. Tras esta introducción, el Capítulo 2 sitúa el trabajo en su contexto técnico, revisando las tecnologías OCR basadas en aprendizaje profundo —desde las arquitecturas de detección hasta los modelos de reconocimiento— y los trabajos previos en optimización de estos sistemas.
-El Capítulo 3 traduce las preguntas de investigación en objetivos concretos siguiendo la metodología SMART, y describe con detalle el enfoque experimental: preparación del dataset, métricas de evaluación y configuración del proceso de optimización con Ray Tune y Optuna.
-El núcleo del trabajo se desarrolla en el Capítulo 4, que presenta el estudio comparativo y la optimización de hiperparámetros estructurados en tres fases: planteamiento de la comparativa con evaluación de EasyOCR, PaddleOCR y DocTR; desarrollo de la optimización mediante 64 trials con Ray Tune; y análisis crítico de los resultados obtenidos.
+El documento sigue una estructura que refleja el proceso investigador. Tras esta introducción, el Capítulo 2 sitúa el trabajo en su contexto técnico y revisa las tecnologías OCR basadas en aprendizaje profundo. Se describen las arquitecturas de detección, los modelos de reconocimiento y los trabajos previos en optimización de estos sistemas.
+El Capítulo 3 traduce las preguntas de investigación en objetivos concretos, siguiendo la metodología SMART. Además, describe con detalle el enfoque experimental: preparación del dataset, métricas de evaluación y configuración del proceso de optimización con Ray Tune y Optuna.
+El núcleo del trabajo se desarrolla en el Capítulo 4, que presenta el estudio comparativo y la optimización de hiperparámetros en tres fases: planteamiento de la comparativa con evaluación de EasyOCR, PaddleOCR y DocTR; desarrollo de la optimización mediante 64 trials con Ray Tune; y análisis crítico de los resultados obtenidos.
Finalmente, el Capítulo 5 sintetiza las contribuciones, evalúa el grado de cumplimiento de los objetivos y propone líneas de trabajo futuro. Los Anexos proporcionan acceso al repositorio de código fuente y datos, así como tablas detalladas de resultados experimentales.
2.
Contexto
y estado del arte
Para comprender el alcance y las decisiones tomadas en este trabajo, es necesario situarlo en su contexto tecnológico. El Reconocimiento Óptico de Caracteres ha recorrido un largo camino desde los primeros sistemas de plantillas de los años 50 hasta las sofisticadas arquitecturas de aprendizaje profundo actuales. A lo largo de este capítulo se revisan los fundamentos técnicos del OCR moderno, se analizan las principales soluciones de código abierto y se identifican los vacíos en la literatura que motivan la contribución de este trabajo.
+_Toc14106979">Para comprender el alcance y las decisiones tomadas en este trabajo, es necesario situarlo en su contexto tecnológico. El Reconocimiento Óptico de Caracteres ha recorrido un largo camino desde los primeros sistemas de plantillas de los años 50 hasta las sofisticadas arquitecturas de aprendizaje profundo actuales. A lo largo de este capítulo se revisan los fundamentos técnicos del OCR moderno. Se analizan las principales soluciones de código abierto y se identifican los vacíos en la literatura que motivan la contribución de este trabajo.
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:
@@ -4656,7 +4660,7 @@ _Toc14106979">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.
+Fuente: Elaboración propia a partir de Zhou et al. (2017), Baek et al. (2019), Liao et al. (2020)..
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:
@@ -4670,7 +4674,7 @@ _Toc14106979">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.
+Fuente: Elaboración propia a partir de Shi et al. (2016), Du et al. (2022), Li et al. (2023)..
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.
@@ -4686,15 +4690,11 @@ _Toc14106979">· 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
+Un CER bajo indica que el sistema comete pocos errores a nivel de carácter. Para aplicaciones críticas se requiere un nivel de error muy reducido, mientras que en tareas de búsqueda o archivo pueden aceptarse errores mayores.
Word Error Rate (WER)
El WER mide el error a nivel de palabra, utilizando la misma fórmula pero considerando palabras como unidades:
-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.
+El WER es generalmente mayor que el CER, ya que un solo error de carácter puede invalidar una palabra completa. Esta diferencia es relevante cuando se comparan sistemas que preservan caracteres pero pierden palabras completas.
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.
@@ -4752,15 +4752,15 @@ _Toc14106979">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.
+Fuente: Documentación oficial de PaddleOCR (PaddlePaddle, 2024)..
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.
+Fuente: Documentación oficial de PaddleOCR (PaddlePaddle, 2024)..
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.
+Fuente: Documentación oficial de PaddleOCR (PaddlePaddle, 2024)..
Fortalezas de PaddleOCR:
· Alta precisión en múltiples benchmarks
@@ -4790,12 +4790,12 @@ _Toc14106979">· Menos opciones de modelos preentrenados para idiomas no inglesesComparativa 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.
+Aspecto | EasyOCR | PaddleOCR | DocTR |
Framework | PyTorch | PaddlePaddle | TF/PyTorch |
Detector | CRAFT | DB | DB/LinkNet |
Reconocedor | CRNN | SVTR/CRNN | CRNN/SAR/ViTSTR |
Idiomas | Multilingüe | Multilingüe | Limitado |
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 a partir de documentación oficial (2024)..
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.
+Aspecto | EasyOCR | PaddleOCR | DocTR |
Instalación | pip install | pip install | pip install |
Complejidad de uso | Baja | Media | Media |
GPU requerida | Opcional | Opcional | Opcional |
Requisitos de memoria | Bajos | Medios | Medios |
Fuente: Elaboración propia a partir de documentación oficial..
Optimización de Hiperparámetros
Fundamentos Teóricos
@@ -4899,11 +4899,11 @@ Configuraciones con alta probabilidad bajoLos 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.
+MLT (ICDAR Multi-Language Text): Dataset multilingüe de las competiciones ICDAR que incluye muestras en español. Las ediciones recientes 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.
+Dataset | Tipo | Idiomas | Tamaño | Uso principal |
FUNSD-ES | Formularios | ES | Pequeño | Document understanding |
MLT | Escenas | Multi (incl. ES) | Medio | Text detection |
XFUND | Formularios | Multi (incl. ES) | Medio | Information extraction |
Fuente: Elaboración propia a partir de repositorios oficiales..
Limitaciones de Recursos para Español
Comparado con inglés y chino, el español cuenta con:
@@ -4912,6 +4912,7 @@ Configuraciones con alta probabilidad bajo 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
-La metodología se estructura en cinco fases secuenciales, cada una de las cuales produce resultados que alimentan la siguiente. Desde la preparación del dataset hasta la validación final, el proceso sigue un diseño experimental que permite reproducir y verificar cada paso.
+La metodología se estructura en cinco fases secuenciales, cada una de las cuales produce resultados que alimentan la siguiente. Desde la preparación del dataset hasta la validación final, el proceso sigue un diseño experimental. Esto permite reproducir y verificar cada paso.
Figura 3. Fases de la metodología experimental
Fuente: Elaboración propia.
@@ -4976,28 +4977,28 @@ concretos y metodología de trabajoFuente: Elaboración propia.Clase ImageTextDataset
-Se implementó una clase Python para cargar pares imagen-texto que retorna tuplas (PIL.Image, str) desde carpetas pareadas. La implementación completa está disponible en src/ocr_benchmark_notebook.ipynb (ver Anexo A).
+Se implementó una clase Python para cargar pares imagen-texto que retorna tuplas (PIL.Image, str) desde carpetas pareadas. La implementación se encuentra en src/prepare_dataset.ipynb y en src/paddle_ocr/dataset_manager.py, src/easyocr_service/dataset_manager.py, src/doctr_service/dataset_manager.py.)
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.
+Modelo | Versión | Configuración |
EasyOCR | - | Idiomas: ['es', 'en'] |
PaddleOCR | PP-OCRv5 | Modelos Mobile (limitación de VRAM) |
DocTR | - | db_resnet50 + sar_resnet31 |
Fuente: [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md)..
Métricas de Evaluación
-Se utilizó la biblioteca jiwer para calcular CER y WER comparando el texto de referencia con la predicción del modelo OCR. La implementación está disponible en src/ocr_benchmark_notebook.ipynb (ver Anexo A).
+Se utilizó la biblioteca jiwer para calcular CER y WER comparando el texto de referencia con la predicción del modelo OCR. La implementación se encuentra en src/paddle_ocr/paddle_ocr_tuning_rest.py, src/easyocr_service/easyocr_tuning_rest.py y src/doctr_service/doctr_tuning_rest.py.)
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.
+Fuente: Elaboración propia..
Configuración de Ray Tune
-El espacio de búsqueda se definió utilizando tune.choice() para parámetros booleanos y tune.uniform() para parámetros continuos, con OptunaSearch como algoritmo de optimización configurado para minimizar CER en 64 trials. La implementación completa está disponible en src/raytune/raytune_ocr.py (ver Anexo A).
+El espacio de búsqueda se definió utilizando tune.choice() para parámetros booleanos y tune.uniform() para parámetros continuos, con OptunaSearch como algoritmo de optimización configurado para minimizar CER en 64 trials. La implementación completa está disponible en src/raytune/raytune_ocr.py (ver Anexo A).
Fase 4: Ejecución de Optimización
Arquitectura de Ejecución
Se implementó una arquitectura basada en contenedores Docker para aislar los servicios OCR y facilitar la reproducibilidad (ver sección 4.2.3 para detalles de la arquitectura).
Ejecución con Docker Compose
-Los servicios se orquestan mediante Docker Compose (src/docker-compose.tuning.*.yml):
+Los servicios se orquestan mediante Docker Compose (src/docker-compose.tuning.paddle.yml, src/docker-compose.tuning.doctr.yml, src/docker-compose.tuning.easyocr.yml, src/docker-compose.tuning.yml):
# Iniciar servicio OCR docker compose -f docker-compose.tuning.doctr.yml up -d doctr-gpu @@ -5008,14 +5009,12 @@ docker compose -f docker-compose.tuning.doctr.yml run raytune --service doctr -- # Detener servicios docker compose -f docker-compose.tuning.doctr.yml down
El servicio OCR expone una API REST que retorna métricas en formato JSON:
+El servicio OCR expone una API REST que retorna métricas en formato JSON. Ejemplo real de un trial con mejor CER:
{
- "CER": 0.0149,
- "WER": 0.0762,
- "TIME": 15.8,
- "PAGES": 5,
- "TIME_PER_PAGE": 3.16
+ "CER": 0.007884,
+ "WER": 0.077848,
+ "TIME_PER_PAGE": 0.5895
}
Fase 5: Validación
@@ -5028,23 +5027,23 @@ docker compose -f docker-compose.tuning.doctr.yml downHardware
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.
+Fuente: [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md)..
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.
+Tabla 17. Software utilizado en el entorno de desarrollo.
+Componente | Versión |
PaddlePaddle | 3.2.2 |
PaddleOCR | 3.3.2 |
Ray Tune | 2.52.1 |
Optuna | 4.7.0 |
DocTR (python-doctr) | >= 0.8.0 |
EasyOCR | >= 1.7.0 |
Fuente: [`src/paddle_ocr/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/paddle_ocr/requirements.txt), [`src/raytune/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune/requirements.txt), [`src/doctr_service/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/doctr_service/requirements.txt), [`src/easyocr_service/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/easyocr_service/requirements.txt)..
Justificación de Ejecución Local vs Cloud
La decisión de ejecutar los experimentos en hardware local en lugar de utilizar servicios cloud se fundamenta en un análisis de costos y beneficios operativos.
Tabla 18. Costos de GPU en plataformas cloud.
Plataforma | GPU | Costo/Hora | Costo Mensual |
AWS EC2 g4dn.xlarge | NVIDIA T4 (16 GB) | $0.526 | ~$384 |
Google Colab Pro | T4/P100 | ~$1.30 | $10 + CU extras |
Google Colab Pro+ | T4/V100/A100 | ~$1.30 | $50 + CU extras |
Fuente: Elaboración propia.
+Fuente: Precios públicos de AWS y Google Cloud. Ver Anexo A, sección de fuentes de precios cloud (enero 2026)..
Para las tareas específicas de este proyecto, los costos estimados en cloud serían:
Tabla 19. Análisis de costos del proyecto en plataformas cloud.
Tarea | Tiempo GPU | Costo AWS | Costo Colab Pro |
Ajuste hiperparámetros (64×3 trials) | ~3 horas | ~$1.58 | ~$3.90 |
Evaluación completa (45 páginas) | ~5 min | ~$0.04 | ~$0.11 |
Desarrollo y depuración (20 horas/mes) | 20 horas | ~$10.52 | ~$26.00 |
Fuente: Elaboración propia.
+Fuente: Elaboración propia a partir de precios públicos. Ver Anexo A, sección de fuentes de precios cloud (enero 2026)..
Las ventajas de la ejecución local incluyen:
1. Costo cero de GPU: La RTX 3060 ya está disponible en el equipo de desarrollo
@@ -5052,15 +5051,15 @@ docker compose -f docker-compose.tuning.doctr.yml down3. Acceso instantáneo: Sin tiempo de aprovisionamiento de instancias cloud
4. Almacenamiento local: Dataset y resultados en disco sin costos de transferencia
5. Iteración rápida: Reinicio inmediato de contenedores Docker para depuración
-Para un proyecto de investigación con múltiples iteraciones de ajuste de hiperparámetros, la ejecución local ahorra aproximadamente $50-100 mensuales comparado con servicios cloud, además de ofrecer mayor flexibilidad en la velocidad de iteración durante el desarrollo.
+Para un proyecto de investigación con múltiples iteraciones de ajuste de hiperparámetros, la ejecución local reduce costos frente a servicios cloud. Este análisis se detalla en docs/metrics/metrics.md.)
Limitaciones Metodológicas
1. Tamaño del dataset: El dataset contiene 45 páginas de documentos académicos UNIR. Resultados pueden no generalizar a otros formatos.
1. Subconjunto de optimización: 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.
1. Texto de referencia imperfecto: El texto de referencia extraído de PDF puede contener errores en documentos con diseños 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.
Síntesis del capítulo
-Los objetivos y la metodología definidos en este capítulo establecen el marco para la experimentación. El objetivo general —alcanzar un CER inferior al 2% mediante optimización de hiperparámetros— se descompone en cinco objetivos específicos que abarcan desde la comparativa inicial de soluciones hasta la validación final de la configuración optimizada.
-La metodología experimental en cinco fases garantiza un proceso sistemático y reproducible: preparación de un dataset de 45 páginas, benchmark comparativo de tres motores OCR, definición del espacio de búsqueda, ejecución de 64 trials con Ray Tune y Optuna, y validación de la configuración resultante. Las limitaciones metodológicas —tamaño del dataset, subconjunto de optimización reducido, texto de referencia automático— se reconocen explícitamente para contextualizar la interpretación de resultados.
+Los objetivos y la metodología definidos en este capítulo establecen el marco para la experimentación. El objetivo general, alcanzar un CER inferior al 2% mediante optimización de hiperparámetros, se descompone en cinco objetivos específicos que abarcan desde la comparativa inicial de soluciones hasta la validación final de la configuración optimizada.
+La metodología experimental en cinco fases garantiza un proceso sistemático y reproducible: preparación de un dataset de 45 páginas, benchmark comparativo de tres motores OCR, definición del espacio de búsqueda, ejecución de 64 trials con Ray Tune y Optuna, y validación de la configuración resultante. Las limitaciones metodológicas, como el tamaño del dataset, el subconjunto de optimización reducido y el texto de referencia automático, se reconocen explícitamente para contextualizar la interpretación de resultados.
El capítulo siguiente pone en práctica esta metodología, presentando el desarrollo experimental completo con sus resultados y análisis.
arrollo
específico de la contribución
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: el planteamiento y ejecución del benchmark comparativo, el proceso de optimización de hiperparámetros mediante Ray Tune, y finalmente el análisis e interpretación de los resultados obtenidos.
+color:#0098CD;mso-font-kerning:16.0pt;mso-bidi-font-weight:bold'>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.
Planteamiento de la comparativa
Introducción
-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 el notebook ocr_benchmark_notebook.ipynb del repositorio, permitieron identificar el modelo más prometedor para la fase de optimización posterior.
+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.
Identificación del Problema
-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 —acentos, eñes, diéresis y signos de puntuación invertidos— con layouts estructuralmente complejos.
-Los documentos académicos típicos incluyen texto corrido entremezclado con tablas, listas numeradas, encabezados multinivel y notas al pie, lo que complica significativamente 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.
+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.
Alternativas Evaluadas
Se seleccionaron tres soluciones OCR de código abierto representativas del estado del arte:
Tabla 20. 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.
+Fuente: [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md)..
Imágenes Docker disponibles en el registro del proyecto:
+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
@@ -5108,39 +5107,39 @@ color:#0098CD;mso-font-kerning:16.0pt;mso-bidi-font-weight:bold'>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/.
+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 21. 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.
+Fuente: [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md)..
Proceso de Conversión
-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).
+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.
Extracción del Ground Truth
-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).
+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. 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 y en los README de cada servicio: src/paddle_ocr/README.md, src/easyocr_service/README.md, src/doctr_service/README.md.
Configuración de los Modelos
-La configuración de cada modelo se detalla en src/ocr_benchmark_notebook.ipynb (ver Anexo A):
+La configuración de cada modelo se detalla en los README de cada servicio y sus ficheros de dependencias:
· 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.
+· 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.
Métricas de Evaluació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).
+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, src/easyocr_service/easyocr_tuning_rest.py y src/doctr_service/doctr_tuning_rest.py.
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 22. 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.
+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.
+Tabla 22. Variabilidad del error por tipo de contenido.
+Tipo de contenido | Nivel de error | Observaciones |
Texto corrido | Bajo | Mejor rendimiento |
Texto con listas | Medio | Rendimiento intermedio |
Índice y encabezados | Medio | Orden de lectura sensible |
Encabezados + notas | Medio | Variación tipográfica |
Fuente: Elaboración propia a partir del benchmark..
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. Las páginas con más cambios de formato y listados 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, demostrando la capacidad del modelo para texto estándar.
+1. El promedio general se situó en un rango medio de error, 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 23. 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.
+Fuente: Documentación oficial de cada herramienta (JaidedAI, 2020; PaddlePaddle, 2024; Mindee, 2021)..
Análisis Cualitativo de Errores
Un análisis cualitativo de los errores producidos reveló patrones específicos:
@@ -5162,9 +5161,9 @@ color:#0098CD;mso-font-kerning:16.0pt;mso-bidi-font-weight:bold'>Criterios de Selección
La selección de PaddleOCR para la fase de optimización se basó en los siguientes criterios:
-Tabla 24. 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.
+Tabla 24. Evaluación de criterios de selección (cualitativa).
+Criterio | EasyOCR | PaddleOCR | DocTR |
CER benchmark | Medio | Mejor | Medio |
Configurabilidad | Baja | Alta | Media |
Soporte español | Sí | Sí (dedicado) | Limitado |
Documentación | Media | Alta | Alta |
Mantenimiento | Medio | Alto | Medio |
Fuente: Elaboración propia a partir del benchmark y la documentación de cada herramienta..
Hiperparámetros Disponibles en PaddleOCR
PaddleOCR expone múltiples hiperparámetros ajustables, clasificados por etapa del pipeline:
@@ -5181,29 +5180,27 @@ color:#0098CD;mso-font-kerning:16.0pt;mso-bidi-font-weight:bold'>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
+1. Resultados iniciales prometedores: Rendimiento base competitivo con margen de mejora
+2. Alta configurabilidad: Múltiples 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.
+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.
+1. 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.
Síntesis del Benchmark
-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 aceptable (~5-6% CER), 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 layouts complejos. Estas limitaciones se tendrán en cuenta al interpretar los resultados de la fase de optimización.
-Fuentes de datos: ocr_benchmark_notebook.ipynb y documentación oficial de PaddleOCR.
+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.
Desarrollo de la comparativa: Optimización de hiperparámetros
Introducción
-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 con apoyo de la librería src/raytune_ocr.py, almacenándose los resultados en 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.
+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 con apoyo de la librería src/raytune_ocr.py, almacenándose los resultados en 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.
Configuración del Experimento
Entorno de Ejecución
El experimento se ejecutó en el siguiente entorno:
Tabla 25. 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.
+Fuente: [`src/paddle_ocr/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/paddle_ocr/requirements.txt), [`src/raytune/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune/requirements.txt), [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md)..
Arquitectura de Ejecución
La arquitectura basada en contenedores Docker es fundamental para este proyecto debido a los conflictos de dependencias inherentes entre los diferentes componentes:
@@ -5215,7 +5212,7 @@ color:#0098CD;mso-font-kerning:16.0pt;mso-bidi-font-weight:bold'>
Fuente: Elaboración propia.
La arquitectura containerizada (src/docker-compose.tuning.*.yml) ofrece:
+La arquitectura containerizada src/docker-compose.tuning.paddle.yml))))), src/docker-compose.tuning.doctr.yml, src/docker-compose.tuning.easyocr.yml, src/docker-compose.tuning.ymlofrece:
1. Aislamiento de dependencias entre Ray Tune y los motores OCR
2. Health checks automáticos para asegurar disponibilidad del servicio
3. Comunicación via API REST (endpoints /health y /evaluate)
@@ -5244,7 +5241,7 @@ docker compose -f docker-compose.tuning.doctr.yml downLa 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.
Imagen | Propósito | Base | Puerto |
PaddleOCR con aceleración GPU | nvidia/cuda:12.4.1-cudnn-runtime | 8002 | |
PaddleOCR para entornos sin GPU | python:3.11-slim | 8002 | |
EasyOCR con aceleración GPU | nvidia/cuda:13.0.2-cudnn-runtime | 8002* | |
DocTR con aceleración GPU | nvidia/cuda:13.0.2-cudnn-runtime | 8003 | |
Orquestador Ray Tune | python:3.12-slim | - |
Fuente: Elaboración propia.
+Fuente: Elaboración propia. Dockerfiles disponibles en [`src/paddle_ocr`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/paddle_ocr), [`src/easyocr_service`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/easyocr_service), [`src/doctr_service`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/doctr_service), [`src/raytune`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune)..
Arquitectura de Microservicios
Figura 6. Arquitectura de microservicios para optimización OCR
@@ -5259,20 +5256,20 @@ docker compose -f docker-compose.tuning.doctr.yml downVentajas de esta estrategia:
1. Caché de dependencias: La etapa base (CUDA + dependencias) se cachea y reutiliza
-2. Builds rápidos: Los cambios de código solo reconstruyen la etapa de deploy (~10 segundos)
+2. Builds rápidos: Los cambios de código solo reconstruyen la etapa de deploy
3. Imágenes optimizadas: Solo se incluyen los archivos necesarios para ejecución
Docker Compose Files
El proyecto incluye múltiples archivos Docker Compose para diferentes escenarios de uso:
Tabla 27. Archivos Docker Compose del proyecto.
-Archivo | Propósito | Servicios |
Optimización principal | RayTune + PaddleOCR + DocTR | |
Optimización EasyOCR | RayTune + EasyOCR | |
Optimización PaddleOCR | RayTune + PaddleOCR | |
Optimización DocTR | RayTune + DocTR |
Fuente: Elaboración propia.
+Archivo | Propósito | Servicios |
Optimización principal | RayTune + PaddleOCR + DocTR | |
Optimización EasyOCR | RayTune + EasyOCR | |
Optimización PaddleOCR | RayTune + PaddleOCR | |
Optimización DocTR | RayTune + DocTR |
Fuente: [`src/docker-compose.tuning.yml`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/docker-compose.tuning.yml), [`src/docker-compose.tuning.easyocr.yml`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/docker-compose.tuning.easyocr.yml), [`src/docker-compose.tuning.paddle.yml`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/docker-compose.tuning.paddle.yml), [`src/docker-compose.tuning.doctr.yml`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/docker-compose.tuning.doctr.yml)..
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.
-Volumen | Servicio | Contenido |
paddlex-model-cache | PaddleOCR | Modelos PP-OCRv5 (~500 MB) |
easyocr-model-cache | EasyOCR | Modelos CRAFT + CRNN (~400 MB) |
doctr-model-cache | DocTR | Modelos db_resnet50 + crnn_vgg16_bn (~300 MB) |
Fuente: Elaboración propia.
+Volumen | Servicio | Contenido |
paddlex-model-cache | PaddleOCR | Modelos PP-OCRv5 |
easyocr-model-cache | EasyOCR | Modelos CRAFT + CRNN |
doctr-model-cache | DocTR | Modelos db_resnet50 + crnn_vgg16_bn |
Fuente: [`src/docker-compose.tuning.yml`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/docker-compose.tuning.yml), [`src/docker-compose.tuning.easyocr.yml`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/docker-compose.tuning.easyocr.yml), [`src/docker-compose.tuning.paddle.yml`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/docker-compose.tuning.paddle.yml), [`src/docker-compose.tuning.doctr.yml`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/docker-compose.tuning.doctr.yml)..
Health Checks y Monitorización
Todos los servicios implementan health checks para garantizar disponibilidad antes de iniciar la optimización:
@@ -5290,7 +5287,7 @@ docker compose -f docker-compose.tuning.doctr.yml down· DocTR: 180 segundos (modelos ResNet más pesados)
Flujo de Ejecución Completo
Figura 8. Flujo de ejecución de optimización con Ray Tune
-
Fuente: Elaboración propia.
Reproducibilidad
@@ -5317,63 +5314,60 @@ ls -la results/raytune_paddle_results_*.csv docker compose -f docker-compose.tuning.paddle.yml downLos resultados de los experimentos están disponibles en:
-· src/results/raytune_paddle_results_20260119_122609.csv
-· src/results/raytune_easyocr_results_20260119_120204.csv
-· src/results/raytune_doctr_results_20260119_121445.csv
+· src/results/raytune_paddle_results_20260119_122609.csv
+· src/results/raytune_easyocr_results_20260119_120204.csv
+· src/results/raytune_doctr_results_20260119_121445.csv
+· src/raytune_paddle_subproc_results_20251207_192320.csv
Dataset Extendido
Para la fase de optimización se extendió el dataset:
Tabla 29. 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.
+Característica | Valor |
Páginas del dataset completo | 45 |
Páginas por trial | 5 (páginas 5-10) |
Estructura | Carpetas img/ y txt/ pareadas |
Resolución | 300 DPI |
Formato imagen | PNG |
Fuente: [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md), [`src/prepare_dataset.ipynb`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/prepare_dataset.ipynb)..
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).
+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, src/easyocr_service/dataset_manager.py y src/doctr_service/dataset_manager.py.
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, 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).
+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).
Tabla 30. 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.
+Fuente: Documentación de PaddleOCR..
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
-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).
+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).
Tabla 31. 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.
+Fuente: [`src/raytune/raytune_ocr.py`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune/raytune_ocr.py)..
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
+Elección de 64 trials:
+El número de trials se eligió buscando un equilibrio entre exploración del espacio de búsqueda y tiempo total de ejecución.
Resultados de la Optimización
Ejecución del Experimento
El experimento se ejecutó exitosamente con los siguientes resultados globales:
-Tabla 32. 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.
+Tabla 32. Resumen de la ejecución del experimento (referencia CPU).
+Métrica | Valor |
Trials completados | 64/64 |
Trials fallidos | 0 |
Tiempo total (CPU) | 6.2 horas |
Tiempo medio por trial (CPU) | 347.6 segundos |
Páginas procesadas | 320 (64 trials × 5 páginas) |
Fuente: [`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)..
Estadísticas Descriptivas
-Del archivo CSV de resultados (src/results/raytune_paddle_results_20260119_122609.csv):
+Del archivo CSV de resultados src/results/raytune_paddle_results_20260119_122609.csv:
Tabla 33. Estadísticas descriptivas de los 64 trials.
Estadística | CER | WER | Tiempo/Página (s) |
count | 64 | 64 | 64 |
mean | 2.30% | 9.25% | 0.84 |
std | 2.20% | 1.78% | 0.53 |
min | 0.79% | 6.80% | 0.56 |
50% (mediana) | 0.87% | 8.39% | 0.59 |
max | 7.30% | 13.20% | 2.22 |
Fuente: Elaboración propia.
+Fuente: [`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)..
Observaciones:
+Observaciones:
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.
1. 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.
1. 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).
Distribución de Resultados
Tabla 34. Distribución de trials por rango de CER.
Rango CER | Número de trials | Porcentaje |
< 2% | 43 | 67.2% |
2% - 5% | 10 | 15.6% |
5% - 10% | 11 | 17.2% |
> 10% | 0 | 0.0% |
Fuente: Elaboración propia.
+Fuente: [`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)..
Figura 9. Distribución de trials por rango de CER
Fuente: Elaboración propia.
+Fuente: src/results/raytune_paddle_results_20260119_122609.csv.
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.
Mejor Configuración Encontrada
@@ -5393,143 +5387,124 @@ Configuración óptima:Tabla 35. Configuración óptima identificada.
Parámetro | Valor óptimo | Valor por defecto | Cambio |
textline_orientation | True | False | Activado |
use_doc_orientation_classify | True | False | Activado |
use_doc_unwarping | False | False | Sin cambio |
text_det_thresh | 0.0462 | 0.3 | -0.254 |
text_det_box_thresh | 0.4862 | 0.6 | -0.114 |
text_det_unclip_ratio | 0.0 | 1.5 | -1.5 (fijado) |
text_rec_score_thresh | 0.5658 | 0.5 | +0.066 |
Fuente: Elaboración propia.
+Fuente: [`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)..
Análisis de Correlación
-Se calculó la correlación de Pearson entre los parámetros continuos y las métricas de error:
+Se calculó la correlación de Pearson entre los parámetros de configuración (codificados como 0/1 en el caso de booleanos) y las métricas de error:
Tabla 36. 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.
+Parámetro | Correlación con CER | Interpretación |
use_doc_unwarping | +0.879 | Correlación alta positiva |
use_doc_orientation_classify | -0.712 | Correlación alta negativa |
textline_orientation | -0.535 | Correlación moderada negativa |
text_det_thresh | +0.428 | Correlación moderada positiva |
text_det_box_thresh | +0.311 | Correlación moderada positiva |
text_rec_score_thresh | -0.268 | Correlación moderada negativa |
text_det_unclip_ratio | NaN | Varianza cero (valor fijo) |
Fuente: [`src/results/correlations/paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv)..
Tabla 37. 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.
+Parámetro | Correlación con WER | Interpretación |
use_doc_unwarping | +0.744 | Correlación alta positiva |
use_doc_orientation_classify | -0.602 | Correlación alta negativa |
textline_orientation | -0.591 | Correlación moderada negativa |
text_det_thresh | +0.399 | Correlación moderada positiva |
text_det_box_thresh | +0.256 | Correlación moderada positiva |
text_rec_score_thresh | -0.080 | Correlación débil negativa |
text_det_unclip_ratio | NaN | Varianza cero (valor fijo) |
Fuente: [`src/results/correlations/paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv)..
Figura 10. Correlación de hiperparámetros con CER
Fuente: Elaboración propia.
+Fuente: src/results/correlations/paddle_correlations.csv.
Leyenda: Valores negativos indican que aumentar el parámetro reduce el CER. El parámetro text_det_thresh tiene la correlación más fuerte (-0.52).
-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.
+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.
Impacto del Parámetro textline_orientation
El parámetro booleano textline_orientation demostró tener el mayor impacto en el rendimiento:
Tabla 38. 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.
+textline_orientation | CER Medio | CER Std | WER Medio | N trials |
True | 1.74% | 1.94% | 8.75% | 52 |
False | 4.73% | 1.37% | 11.42% | 12 |
Fuente: [`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)..
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.
+Interpretación:
+1. Reducción del CER: Con textline_orientation=True, el CER medio es 2.7 veces menor (1.74% vs 4.73%).
+1. Varianza: La desviación estándar es mayor cuando textline_orientation=True (1.94% vs 1.37%), aunque los valores medios siguen siendo mejores.
+1. Reducción del CER: 63.2% cuando se habilita la clasificación de orientación de línea.
Figura 11. Impacto de textline_orientation en CER
Fuente: Elaboración propia.
+Fuente: src/results/raytune_paddle_results_20260119_122609.csv.
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 39. 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.
+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 í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.
+Análisis de Trials con Mayor CER
+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:
+Tabla 39. Trials con mayor CER.
+Trial ID | CER | text_det_thresh | textline_orientation |
f699b826 | 7.30% | 0.285 | False |
34bfaecf | 7.29% | 0.030 | True |
8c1998de | 6.44% | 0.369 | True |
8b33e2a2 | 6.41% | 0.664 | False |
Fuente: [`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)..
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.
+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.
Comparación Baseline vs Optimizado
Evaluación sobre Dataset Completo
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.
Tabla 40. Comparación baseline vs optimizado (45 páginas).
Modelo | CER | Precisión Caracteres | WER | Precisión Palabras |
PaddleOCR (Baseline) | 8.85% | 91.15% | 13.05% | 86.95% |
PaddleOCR-HyperAdjust | 7.72% | 92.28% | 11.40% | 88.60% |
Fuente: Elaboración propia.
+Fuente: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md)..
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.
Métricas de Mejora
Tabla 41. Análisis cuantitativo de la mejora.
Forma de Medición | CER | WER |
Valor baseline | 8.85% | 13.05% |
Valor optimizado | 7.72% | 11.40% |
Mejora absoluta | -1.13 pp | -1.65 pp |
Reducción relativa del error | 12.8% | 12.6% |
Factor de mejora | 1.15× | 1.14× |
Mejor trial (5 páginas) | 0.79% | 7.78% |
Fuente: Elaboración propia.
+Fuente: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md)..
Figura 12. Reducción de errores: Baseline vs Optimizado (45 páginas)
Fuente: Elaboración propia.
+Fuente: docs/metrics/metrics_paddle.md.
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.
+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.
Impacto Práctico
-En un documento típico de 10,000 caracteres:
-Tabla 42. En un documento típico de 10,000 caracteres
-Configuración | Caracteres con error | Palabras con error* |
Baseline | ~885 | ~196 |
Optimizada (full dataset) | ~772 | ~171 |
Optimizada (mejor trial) | ~79 | ~117 |
Reducción (full dataset) | 113 menos | 25 menos |
Fuente: Elaboración propia.
-*Asumiendo longitud media de palabra = 6.6 caracteres en español.
-Interpretación:
-"La optimización de hiperparámetros logró una mejora del 12.8% en el CER sobre el dataset completo de 45 páginas. Aunque esta mejora es más modesta que la observada en los trials individuales (donde se alcanzó 0.79% CER), demuestra el valor de la optimización sistemática. La diferencia entre el mejor trial (0.79%) y el resultado en dataset completo (7.72%) revela un fenómeno de sobreajuste al subconjunto de 5 páginas usado para evaluación."
+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.
Tiempo de Ejecución
-Tabla 43. Métricas de tiempo del experimento (GPU).
-Métrica | Valor |
Tiempo total del experimento | ~1.5 horas |
Tiempo medio por trial | ~4.2 segundos |
Tiempo medio por página | 0.84 segundos |
Variabilidad (std) | 0.53 segundos/página |
Páginas procesadas totales | 320 |
Fuente: Elaboración propia.
+Tabla 42. Métricas de tiempo del experimento (GPU).
+Métrica | Valor |
Tiempo total del experimento | ~5.0 minutos |
Tiempo medio por trial | 4.64 segundos |
Tiempo medio por página | 0.84 segundos |
Variabilidad (std) | 0.53 segundos/página |
Páginas procesadas totales | 320 |
Fuente: [`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)..
Observaciones:
+Observaciones:
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.
Síntesis de la Optimizació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: activarlos reduce el CER medio de 12.40% a 3.76%. En cuanto a umbrales, valores bajos de text_det_thresh (~0.05) benefician el rendimiento, mientras que use_doc_unwarping resulta innecesario para PDFs digitales.
+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.
-Fuentes de datos: src/run_tuning.py, src/raytune_ocr.py, src/results/raytune_paddle_results_20260119_122609.csv.
Discusión y análisis de resultados
Introducción
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.
Resumen Consolidado de Resultados
Progresión del Rendimiento
-Tabla 44. Evolución del rendimiento a través del estudio.
-Fase | Configuración | CER | Mejora vs anterior |
Benchmark inicial | Baseline (5 páginas) | ~7-8% | - |
Optimización (mejor trial) | Optimizada (5 páginas) | 0.79% | ~90% vs baseline |
Validación final | Optimizada (45 páginas) | 7.72% | 12.8% vs baseline |
Fuente: Elaboración propia.
+Tabla 43. Evolución del rendimiento a través del estudio.
+Fase | Configuración | CER | Mejora vs baseline |
Benchmark inicial | Baseline (5 páginas) | 7.76% | - |
Optimización (mejor trial) | Optimizada (5 páginas) | 0.79% | 89.8% |
Validación final | Optimizada (45 páginas) | 7.72% | 12.8% |
Fuente: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md)..
Figura 13. Evolución del CER a través del estudio
Fuente: Elaboración propia.
+Fuente: docs/metrics/metrics_paddle.md.
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 layouts.
+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.
Comparación con Objetivo
-Tabla 45. Verificación del objetivo general.
+Tabla 44. Verificación del objetivo general.
Aspecto | Objetivo | Resultado (trial) | Resultado (full) | Cumplimiento |
Métrica | CER | CER | CER | ✓ |
Umbral | < 2% | 0.79% | 7.72% | Parcial |
Método | Sin fine-tuning | Solo hiperparámetros | Solo hiperparámetros | ✓ |
Hardware | GPU | RTX 3060 | RTX 3060 | ✓ |
Fuente: Elaboración propia.
+Fuente: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md)..
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.
Análisis Detallado de Hiperparámetros
Jerarquía de Importancia
Basándose en el análisis de los resultados de optimización:
-Tabla 46. Ranking de importancia de hiperparámetros.
-Rank | Parámetro | Impacto | Evidencia |
1 | textline_orientation | Crítico | Presente en todos los mejores trials |
2 | use_doc_orientation_classify | Alto | Activado en configuración óptima |
3 | text_det_thresh | Alto | Valor óptimo bajo (0.0462) |
4 | text_det_box_thresh | Medio | Moderado (0.4862) |
5 | text_rec_score_thresh | Medio | Moderado (0.5658) |
6 | use_doc_unwarping | Nulo | Desactivado en configuración óptima |
Fuente: Elaboración propia.
+Tabla 45. Ranking de importancia de hiperparámetros.
+Rank | Parámetro | Pearson (CER) | Signo | Evidencia |
1 | use_doc_unwarping | 0.879 | Positivo | Correlación más alta con CER |
2 | use_doc_orientation_classify | -0.712 | Negativo | Correlación alta con CER |
3 | textline_orientation | -0.535 | Negativo | Correlación alta con CER |
4 | text_det_thresh | 0.428 | Positivo | Correlación moderada con CER |
5 | text_det_box_thresh | 0.311 | Positivo | Correlación moderada con CER |
6 | text_rec_score_thresh | -0.268 | Negativo | Correlación moderada con CER |
Fuente: [`src/results/correlations/paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv)..
Figura 14. Ranking de importancia de hiperparámetros
Fuente: Elaboración propia.
+Fuente: src/results/correlations/paddle_correlations.csv.
Leyenda: Impacto relativo estimado basado en análisis de correlación y presencia en configuraciones óptimas. textline_orientation es el parámetro más crítico.
+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.
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.
+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:
+1. Las líneas del índice pueden mezclarse con el cuerpo del texto
+2. Los encabezados pueden insertarse en posiciones incorrectas
+3. Las listas numeradas pueden leerse en orden incorrecto
+Para documentos académicos que típicamente incluyen índice, 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 47. Comportamiento observado
-Rango | CER típico | Comportamiento |
0.0 - 0.1 | 1-3% | Detecta más texto, incluyendo bordes |
0.1 - 0.3 | 2-5% | Rendimiento variable |
0.3 - 0.5 | 3-7% | Balance precisión/recall |
0.5 - 0.7 | 4-7% | Más conservador |
Fuente: Elaboración propia.
-Interpretación:
-· En ejecución GPU con modelos Mobile, valores bajos de text_det_thresh funcionan bien
-· El valor óptimo (0.0462) indica que una detección más sensible beneficia el rendimiento
-· A diferencia de CPU, no se observaron fallos catastróficos con valores bajos
-Valor óptimo encontrado: 0.0462
+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.
Análisis de Parámetros de Preprocesamiento
use_doc_orientation_classify:
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.
@@ -5541,19 +5516,19 @@ Configuración óptima:Para documentos PDF digitales como los evaluados, este módulo es innecesario y puede introducir artefactos.
Análisis de Casos de Fallo
Clasificación de Errores
-Tabla 48. Tipología de errores observados.
+Tabla 46. 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.
+Fuente: Análisis cualitativo..
Patrones de Fallo por Tipo de Contenido
-Tabla 49. 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.
+Tabla 47. Tasa de error por tipo de contenido (cualitativa).
+Tipo de contenido | Nivel de error | Factor de riesgo |
Párrafos de texto | Bajo | Bajo |
Listas numeradas | Medio | Medio |
Índice y encabezados | Medio | Medio |
Encabezados + pie de página | Medio | Medio |
Texto con cambios tipográficos | Medio | Medio |
Listas con numeración densa | Alto | Alto |
Fuente: Estimación cualitativa..
Comparación con Objetivos Específicos
-Tabla 50. Cumplimiento de objetivos específicos.
+Tabla 48. 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 | 45 páginas con ground truth | ✓ Cumplido |
OE3 | Identificar hiperparámetros críticos | textline_orientation, use_doc_orientation_classify, text_det_thresh identificados | ✓ Cumplido |
OE4 | Optimizar con Ray Tune (≥50 trials) | 64 trials ejecutados con GPU | ✓ Cumplido |
OE5 | Validar configuración optimizada | CER: 8.85% → 7.72% (dataset), 0.79% (mejor trial) | ✓ Parcial |
Fuente: Elaboración propia.
+Fuente: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md), [`src/results/correlations/paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv), [`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)..
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.
Limitaciones del Estudio
@@ -5562,7 +5537,7 @@ Configuración óptima: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. 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.
1. Tamaño del dataset: 45 páginas es un dataset limitado. 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. 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.
@@ -5572,9 +5547,9 @@ Configuración óptima:Implicaciones Prácticas
Guía de Configuración Recomendada
Para documentos académicos en español similares a los evaluados:
-Tabla 51. Configuración recomendada para PaddleOCR con GPU.
-Parámetro | Valor | Prioridad | Justificación |
textline_orientation | True | Obligatorio | Crítico para layouts complejos |
use_doc_orientation_classify | True | Recomendado | Mejora orientación de documento |
text_det_thresh | 0.05 (rango: 0.04-0.10) | Recomendado | Detección sensible beneficia resultados |
text_det_box_thresh | 0.49 (rango: 0.4-0.6) | Recomendado | Balance de confianza |
text_rec_score_thresh | 0.57 (rango: 0.5-0.7) | Opcional | Filtra reconocimientos poco confiables |
use_doc_unwarping | False | No recomendado | Innecesario para PDFs digitales |
Fuente: Elaboración propia.
+Tabla 49. Configuración recomendada para PaddleOCR con GPU.
+Parámetro | Valor | Prioridad | Justificación |
textline_orientation | True | Obligatorio | Crítico para documentos con secciones |
use_doc_orientation_classify | True | Recomendado | Mejora orientación de documento |
text_det_thresh | 0.05 (rango: 0.04-0.10) | Recomendado | Detección sensible beneficia resultados |
text_det_box_thresh | 0.49 (rango: 0.4-0.6) | Recomendado | Balance de confianza |
text_rec_score_thresh | 0.57 (rango: 0.5-0.7) | Opcional | Filtra reconocimientos poco confiables |
use_doc_unwarping | False | No recomendado | Innecesario para PDFs digitales |
Fuente: [`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)..
Cuándo Aplicar Esta Metodología
La optimización de hiperparámetros es recomendable cuando:
@@ -5588,55 +5563,61 @@ Configuración óptima: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.
+1. Requisitos de CER muy bajo: Puede requerir fine-tuning para alcanzar precisiones muy altas.
Síntesis del Capítulo
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.
-Fuentes de datos:
-· src/run_tuning.py: Script principal de optimización
-· src/results/raytune_paddle_results_20260119_122609.csv: Resultados CSV de PaddleOCR
-· src/results/raytune_easyocr_results_20260119_120204.csv: Resultados CSV de EasyOCR
-· src/results/raytune_doctr_results_20260119_121445.csv: Resultados CSV de DocTR
-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
+· src/run_tuning.py - Script principal de optimización
+· src/raytune/requirements.txt - Dependencias del orquestador Ray Tune
+· src/paddle_ocr/requirements.txt - Dependencias del servicio PaddleOCR
+· src/easyocr_service/requirements.txt - Dependencias del servicio EasyOCR
+· src/doctr_service/requirements.txt - Dependencias del servicio DocTR
+· src/results/raytune_paddle_results_20260119_122609.csv - Resultados CSV de PaddleOCR
+· src/results/correlations/paddle_correlations.csv - Correlaciones de hiperparámetros (PaddleOCR)
+· src/results/raytune_easyocr_results_20260119_120204.csv - Resultados CSV de EasyOCR
+· src/results/raytune_doctr_results_20260119_121445.csv - Resultados CSV de DocTR
+· 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 - PaddleOCR con soporte GPU
+· seryus.ddns.net/unir/easyocr-gpu - EasyOCR con soporte GPU
+· seryus.ddns.net/unir/doctr-gpu - DocTR con soporte GPU
Comparativa de Rendimiento CPU vs 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.
Configuración del Entorno GPU
-Tabla 52. Especificaciones del entorno GPU utilizado.
+Tabla 50. Especificaciones del entorno GPU utilizado.
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.
+Fuente: [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md)..
Nota: Los requisitos de entorno documentados por dependencias se detallan en docs/07_anexo_a.md, sección A.9.
Este hardware representa configuración típica de desarrollo, permitiendo evaluar el rendimiento en condiciones realistas de despliegue.
Comparación CPU vs GPU
-Se comparó el tiempo de procesamiento entre CPU y GPU utilizando los datos de src/raytune_paddle_subproc_results_20251207_192320.csv (CPU) y src/results/raytune_paddle_results_20260119_122609.csv (GPU).
-Tabla 53. Rendimiento comparativo CPU vs GPU.
-Métrica | CPU | GPU (RTX 3060) | Factor de Aceleración |
Tiempo/Página (promedio) | 69.4s | 0.84s | 82x |
Dataset completo (45 páginas) | ~52 min | ~38 seg | 82x |
64 trials × 5 páginas | ~6.4 horas | ~1.5 horas | 4.3x |
Fuente: Elaboración propia.
+Se comparó el tiempo de procesamiento entre CPU y GPU utilizando los datos de src/raytune_paddle_subproc_results_20251207_192320.csv(CPU) y src/results/raytune_paddle_results_20260119_122609.csv(GPU).
+Tabla 51. Rendimiento comparativo CPU vs GPU.
+Métrica | CPU | GPU (RTX 3060) | Factor de Aceleración |
Tiempo/Página (promedio) | 69.4s | 0.84s | 82x |
Dataset completo (45 páginas) | ~52 min | ~38 seg | 82x |
64 trials × 5 páginas | 6.2 horas | ~5.0 min | 75x |
Fuente: [`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), [`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)..
Figura 15. Tiempo de procesamiento: CPU vs GPU (segundos/página)
Fuente: Elaboración propia.
+Fuente: src/raytune_paddle_subproc_results_20251207_192320.csv, src/results/raytune_paddle_results_20260119_122609.csv.
Leyenda: Aceleración de 82× con GPU. El procesamiento de una página pasa de 69.4s (CPU) a 0.84s (GPU).
+Leyenda: Aceleración de 82× con GPU. El procesamiento de una página pasa de 69.4s (CPU) a 0.84s (GPU).
La aceleración de 82× obtenida con GPU transforma la viabilidad del enfoque:
-· Optimización en CPU (6.4 horas): Viable pero lento para iteraciones rápidas
-· Optimización en GPU (1.5 horas): Permite explorar más configuraciones y realizar múltiples experimentos
+· Optimización en CPU (6.2 horas): Viable pero lento para iteraciones rápidas
+· Optimización en GPU (~5.0 minutos): Permite explorar más configuraciones y realizar múltiples experimentos
· Producción con GPU (0.84s/página): Habilita procesamiento en 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 54. Comparación de modelos Mobile vs Server en RTX 3060.
+Tabla 52. 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.
+Fuente: [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md)..
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.
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. 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.
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 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.
5. @@ -5646,36 +5627,36 @@ y trabajo futuro
A lo largo
Los resultados obtenidos confirman que la optimización sistemática de hiperparámetros constituye una alternativa viable al fine-tuning para mejorar sistemas OCR preentrenados. La infraestructura dockerizada con aceleración GPU desarrollada en este trabajo no solo facilita la experimentación reproducible, sino que reduce drásticamente los tiempos de ejecución, haciendo viable la exploración exhaustiva de espacios de configuración. El objetivo principal del trabajo era alcanzar un CER inferior al 2% en documentos académicos en español. Los resultados obtenidos se resumen a continuación: Tabla 55. Cumplimiento del objetivo de CER. Tabla 53. Cumplimiento del objetivo de CER. Métrica Objetivo Mejor Trial Dataset Completo Cumplimiento CER < 2% 0.79% 7.72% ✓ Parcial Fuente: Elaboración propia. Fuente: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md).. Nota: El objetivo de CER < 2% se cumple en el mejor trial individual (0.79%, 5 páginas). La validación sobre el conjunto de datos completo (45 páginas) muestra un CER de 7.72%, evidenciando sobreajuste al subconjunto de optimización. Esta diferencia se analiza en detalle en el Capítulo 4. La evaluación comparativa de soluciones OCR (OE1) reveló diferencias significativas entre las tres alternativas analizadas. De las tres soluciones de código abierto evaluadas —EasyOCR, PaddleOCR (PP-OCRv5) y DocTR—, PaddleOCR demostró el mejor rendimiento base para documentos en español. Además, su arquitectura modular y la amplia configurabilidad de su pipeline lo convierten en el candidato idóneo para optimización mediante ajuste de hiperparámetros. En cuanto a la preparación del conjunto de datos (OE2), se construyó un corpus estructurado con 45 páginas de documentos académicos de UNIR. La implementación de la clase ImageTextDataset permite cargar de forma eficiente pares imagen-texto, mientras que el texto de referencia se extrajo automáticamente del PDF original mediante PyMuPDF, garantizando así la consistencia entre las imágenes y sus transcripciones esperadas. El análisis de hiperparámetros (OE3) arrojó resultados particularmente reveladores. El parámetro textline_orientation emergió como el factor más influyente, resultando crítico para obtener buenos resultados en documentos con diseños complejos. Asimismo, use_doc_orientation_classify demostró un impacto positivo en la configuración con GPU. Por otra parte, el umbral text_det_thresh presenta una correlación negativa moderada (-0.52) con el CER, lo que indica que valores más bajos tienden a mejorar el rendimiento, aunque con un límite inferior por debajo del cual el sistema falla catastróficamente. Cabe destacar que use_doc_unwarping no aporta mejora alguna en documentos digitales, ya que estos no presentan las deformaciones físicas para las que fue diseñado este módulo. La experimentación con Ray Tune (OE4) se completó satisfactoriamente mediante 64 trials ejecutados con el algoritmo OptunaSearch y aceleración GPU. El tiempo total del experimento —aproximadamente 1.5 horas con una GPU RTX 3060— demuestra la viabilidad práctica de esta aproximación. La arquitectura basada en contenedores Docker resultó esencial para superar las incompatibilidades entre Ray y los motores OCR, al tiempo que garantiza la portabilidad y reproducibilidad de los experimentos. La evaluación comparativa de soluciones OCR (OE1) reveló diferencias significativas entre las tres alternativas analizadas. De las tres soluciones de código abierto evaluadas, EasyOCR, PaddleOCR (PP-OCRv5) y DocTR, PaddleOCR demostró el mejor rendimiento base para documentos en español. Además, su arquitectura modular y la amplia configurabilidad de su pipeline lo convierten en el candidato idóneo para optimización mediante ajuste de hiperparámetros. En cuanto a la preparación del conjunto de datos (OE2), se construyó un corpus estructurado con 45 páginas de documentos académicos de UNIR. La implementación de la clase ImageTextDataset permite cargar de forma eficiente pares imagen-texto. El texto de referencia se extrajo automáticamente del PDF original mediante PyMuPDF, garantizando así la consistencia entre las imágenes y sus transcripciones esperadas. El análisis de hiperparámetros (OE3) arrojó resultados particularmente reveladores. El parámetro textline_orientation emergió como el factor más influyente, resultando crítico para obtener buenos resultados en documentos con diseños complejos. Asimismo, use_doc_orientation_classify demostró un impacto positivo en la configuración con GPU. Por otra parte, el umbral text_det_thresh presenta una correlación positiva moderada (0.43) con el CER, lo que indica que valores más bajos tienden a mejorar el rendimiento. Cabe destacar que use_doc_unwarping no aporta mejora alguna en documentos digitales, ya que estos no presentan las deformaciones físicas para las que fue diseñado este módulo. La experimentación con Ray Tune (OE4) se completó satisfactoriamente mediante 64 trials ejecutados con el algoritmo OptunaSearch y aceleración GPU. El tiempo total del experimento, en torno a 5 minutos con una GPU RTX 3060, demuestra la viabilidad práctica de esta aproximación. La arquitectura basada en contenedores Docker resultó esencial para superar las incompatibilidades entre Ray y los motores OCR, al tiempo que garantiza la portabilidad y reproducibilidad de los experimentos. Finalmente, la validación de la configuración óptima (OE5) se realizó sobre el conjunto de datos completo de 45 páginas. El mejor trial individual alcanzó un CER de 0.79%, equivalente a una precisión del 99.21%. Sin embargo, la evaluación sobre el conjunto de datos completo arrojó un CER de 7.72%, lo que representa una mejora del 12.8% respecto al baseline (8.85%), pero queda lejos del resultado del mejor trial. Esta diferencia revela un sobreajuste al subconjunto de optimización de 5 páginas, un fenómeno que se analiza en detalle en la sección de limitaciones. El hallazgo más significativo de este trabajo es que las decisiones arquitectónicas tienen mayor impacto que los umbrales numéricos. Un único parámetro booleano —textline_orientation— influye más en el rendimiento final que todos los umbrales continuos combinados. Este resultado sugiere que, al optimizar sistemas OCR, conviene priorizar la exploración de configuraciones estructurales antes de ajustar finamente los valores numéricos. No obstante, los umbrales presentan límites operativos que deben respetarse. Valores de text_det_thresh inferiores a 0.1 provocan fallos catastróficos, con tasas de error que superan el 40%. Este comportamiento indica la existencia de regiones del espacio de hiperparámetros que deben evitarse, lo cual tiene implicaciones para el diseño de espacios de búsqueda en futuros experimentos. Otro hallazgo relevante es la innecesariedad de ciertos módulos para documentos digitales. Los PDF generados directamente desde procesadores de texto no presentan las deformaciones físicas —arrugas, curvaturas, rotaciones— para las que fueron diseñados los módulos de corrección. En estos casos, desactivar use_doc_unwarping no solo simplifica el pipeline, sino que puede mejorar el rendimiento al evitar procesamientos innecesarios. El hallazgo más significativo de este trabajo es que las decisiones arquitectónicas tienen mayor impacto que los umbrales numéricos. Un único parámetro booleano, textline_orientation, influye más en el rendimiento final que todos los umbrales continuos combinados. Este resultado sugiere que, al optimizar sistemas OCR, conviene priorizar la exploración de configuraciones estructurales antes de ajustar finamente los valores numéricos. No obstante, los umbrales presentan límites operativos que deben respetarse. En este estudio no se observaron fallos catastróficos (CER > 10%), pero los peores trials alcanzaron CER de hasta 7.30%, lo que indica que ciertas combinaciones de umbrales degradan el rendimiento. Este comportamiento sugiere la necesidad de acotar el espacio de búsqueda en futuros experimentos. Otro hallazgo relevante es la innecesariedad de ciertos módulos para documentos digitales. Los PDF generados directamente desde procesadores de texto no presentan deformaciones físicas, como arrugas, curvaturas o rotaciones, para las que fueron diseñados los módulos de corrección. En estos casos, desactivar use_doc_unwarping no solo simplifica el pipeline, sino que puede mejorar el rendimiento al evitar procesamientos innecesarios. Finalmente, los resultados demuestran que es posible mejorar modelos preentrenados mediante ajuste exclusivo de hiperparámetros de inferencia, sin necesidad de reentrenamiento. Sin embargo, esta aproximación requiere validación cuidadosa, ya que las configuraciones optimizadas sobre subconjuntos pequeños pueden no generalizar a conjuntos de datos más amplios o diversos. La principal contribución de este trabajo es una metodología reproducible para la optimización de hiperparámetros OCR. El proceso completo —desde la preparación del conjunto de datos hasta la validación de la configuración óptima— queda documentado y es replicable mediante las herramientas Ray Tune y Optuna. La principal contribución de este trabajo es una metodología reproducible para la optimización de hiperparámetros OCR. El proceso completo, desde la preparación del conjunto de datos hasta la validación de la configuración óptima, queda documentado y es replicable mediante las herramientas Ray Tune y Optuna. En segundo lugar, el análisis sistemático de los hiperparámetros de PaddleOCR constituye una contribución al conocimiento disponible sobre este motor OCR. Mediante el cálculo de correlaciones y análisis comparativo, se cuantifica el impacto de cada parámetro configurable, información que puede orientar futuros trabajos de optimización. Como resultado práctico, se aporta una configuración validada específicamente para documentos académicos en español. Aunque la generalización a otros tipos de documentos requiere validación adicional, esta configuración representa un punto de partida sólido para aplicaciones en el ámbito hispanohablante. Por último, todo el código fuente, las imágenes Docker y los datos experimentales están disponibles públicamente en el repositorio del proyecto, facilitando así la reproducción, verificación y extensión de este trabajo por parte de otros investigadores. Es necesario reconocer varias limitaciones que condicionan el alcance de las conclusiones presentadas. En primer lugar, todos los experimentos se realizaron sobre un único tipo de documento: textos académicos de UNIR. La generalización a otros formatos —facturas, formularios, documentos manuscritos— requeriría validación adicional con conjuntos de datos específicos. Es necesario reconocer varias limitaciones que condicionan el alcance de las conclusiones presentadas. En primer lugar, todos los experimentos se realizaron sobre un único tipo de documento, textos académicos de UNIR. La generalización a otros formatos, como facturas, formularios o documentos manuscritos, requeriría validación adicional con conjuntos de datos específicos. El tamaño del corpus constituye otra limitación relevante. Con 45 páginas, el conjunto de datos es modesto para extraer conclusiones estadísticamente robustas. Además, el subconjunto de optimización de tan solo 5 páginas resultó insuficiente para evitar el sobreajuste, como evidencia la brecha entre el CER del mejor trial (0.79%) y el resultado sobre el conjunto completo (7.72%). Desde el punto de vista metodológico, la extracción automática del texto de referencia mediante PyMuPDF puede introducir errores en documentos con diseños complejos, donde el orden de lectura no es evidente. Asimismo, el parámetro text_det_unclip_ratio permaneció fijo en 0.0 durante todo el experimento, dejando inexplorada una dimensión potencialmente relevante del espacio de hiperparámetros. Por último, aunque la GPU RTX 3060 utilizada proporcionó una aceleración de 82× respecto a la ejecución en CPU, se trata de hardware de consumo. Equipamiento empresarial con mayor capacidad de VRAM permitiría ejecutar múltiples servicios OCR simultáneamente y explorar espacios de búsqueda más amplios en menos tiempo. Las limitaciones identificadas sugieren varias extensiones que podrían abordarse a corto plazo. La más urgente es la validación cruzada de la configuración óptima en otros tipos de documentos en español, como facturas, formularios administrativos o textos manuscritos. Esta validación revelaría el grado de transferibilidad de los hallazgos actuales. Para abordar el problema del sobreajuste, futuros experimentos deberían utilizar un subconjunto de optimización más amplio. Un conjunto de 15-20 páginas representativas reduciría la varianza y mejoraría la generalización de las configuraciones encontradas. Complementariamente, sería conveniente construir un corpus más amplio y diverso de documentos en español, incluyendo diferentes tipografías, diseños y calidades de imagen. Para abordar el problema del sobreajuste, futuros experimentos deberían utilizar un subconjunto de optimización más amplio. Un conjunto más representativo reduciría la varianza y mejoraría la generalización de las configuraciones encontradas. Complementariamente, sería conveniente construir un corpus más amplio y diverso de documentos en español, incluyendo diferentes tipografías, diseños y calidades de imagen. Desde el punto de vista técnico, queda pendiente la exploración del parámetro text_det_unclip_ratio, que permaneció fijo en este trabajo. Incluirlo en el espacio de búsqueda podría revelar interacciones con otros parámetros actualmente desconocidas. En un horizonte más amplio, surgen varias líneas de investigación prometedoras. Una de las más interesantes es el estudio del transfer learning de hiperparámetros: ¿las configuraciones óptimas para documentos académicos transfieren a otros dominios, o cada tipo de documento requiere optimización específica? La respuesta a esta pregunta tiene implicaciones prácticas significativas.Conclusiones Generales
Cumplimiento de los Objetivos Específicos
-Hallazgos Clave
-Contribuciones del Trabajo
-Limitaciones del Trabajo
-Líneas de trabajo futuro
Extensiones Inmediatas
Líneas de Investigación
A lo largo
En síntesis, este trabajo ha demostrado que la optimización de hiperparámetros representa una alternativa viable al fine-tuning para mejorar sistemas OCR, especialmente cuando se dispone de modelos preentrenados para el idioma objetivo y recursos limitados de tiempo o datos etiquetados. La metodología propuesta cumple los requisitos de reproducibilidad científica: los experimentos pueden replicarse, los resultados son cuantificables y las conclusiones son aplicables a escenarios reales de procesamiento documental. Sin embargo, la experiencia también ha puesto de manifiesto la importancia de diseñar cuidadosamente los experimentos de optimización. Aunque el objetivo de CER inferior al 2% se alcanzó en el mejor trial individual (0.79%), la validación sobre el conjunto de datos completo (7.72%) revela que el tamaño y representatividad del subconjunto de optimización son factores críticos que no deben subestimarse. La infraestructura dockerizada desarrollada constituye una aportación práctica que trasciende los resultados numéricos. Al encapsular los motores OCR en contenedores independientes, se resuelven problemas de compatibilidad entre dependencias y se garantiza que cualquier investigador pueda reproducir exactamente las condiciones experimentales. La aceleración de 82× proporcionada por GPU transforma lo que sería un experimento de días en uno de horas, haciendo viable la exploración exhaustiva de espacios de hiperparámetros con hardware de consumo. La infraestructura dockerizada desarrollada constituye una aportación práctica que trasciende los resultados numéricos. Al encapsular los motores OCR en contenedores independientes, se resuelven problemas de compatibilidad entre dependencias y se garantiza que cualquier investigador pueda reproducir exactamente las condiciones experimentales. La aceleración de 82× proporcionada por GPU transforma lo que sería un experimento de horas en uno de minutos, haciendo viable la exploración exhaustiva de espacios de hiperparámetros con hardware de consumo. El código fuente, las imágenes Docker y los datos experimentales están disponibles públicamente en el repositorio del proyecto. Esta apertura busca facilitar no solo la reproducción de los resultados, sino también la extensión de este trabajo hacia nuevos tipos de documentos, idiomas o motores OCR. 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 · Resultados: Archivos CSV con los resultados de los 64 trials por servicio Figura 16. Estructura del repositorio MastersThesis Fuente: Elaboración propia. Tabla 56. Descripción de directorios principales. Directorio Contenido docs/ Capítulos del TFM en Markdown (estructura UNIR) docs/metrics/ Métricas de rendimiento por servicio OCR src/paddle_ocr/ Servicio PaddleOCR dockerizado src/doctr_service/ Servicio DocTR dockerizado src/easyocr_service/ Servicio EasyOCR dockerizado src/raytune/ Scripts de optimización Ray Tune src/results/ CSVs con resultados de 64 trials por servicio thesis_output/ Documento TFM generado + figuras PNG instructions/ Plantilla e instrucciones UNIR oficiales Fuente: Elaboración propia. Tabla 54. Descripción de directorios principales. Directorio Contenido Capítulos del TFM en Markdown (estructura UNIR) Métricas de rendimiento por servicio OCR Servicio PaddleOCR dockerizado Servicio DocTR dockerizado Servicio EasyOCR dockerizado Scripts de optimización Ray Tune CSVs con resultados de 64 trials por servicio Correlaciones de hiperparámetros por servicio Documento TFM generado + figuras PNG Plantilla e instrucciones UNIR oficiales Fuente: [Repositorio del proyecto](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/).. Tabla 57. Especificaciones del sistema de desarrollo. Tabla 55. 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. Fuente: [`docs/metrics/metrics.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics.md).. Tabla 58. 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. Tabla 56. Dependencias del proyecto. Componente Versión PaddlePaddle 3.2.2 PaddleOCR 3.3.2 Ray Tune 2.52.1 Optuna 4.7.0 DocTR (python-doctr) >= 0.8.0 EasyOCR >= 1.7.0 Docker Requerido para contenedores NVIDIA Container Toolkit Requerido para GPU Fuente: [`src/paddle_ocr/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/paddle_ocr/requirements.txt), [`src/raytune/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/raytune/requirements.txt), [`src/doctr_service/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/doctr_service/requirements.txt), [`src/easyocr_service/requirements.txt`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/easyocr_service/requirements.txt), [`src/README.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/README.md).. Imágenes Docker: · GPU: seryus.ddns.net/unir/paddle-ocr-gpu Imagen Docker: seryus.ddns.net/unir/doctr-gpu Imagen Docker: seryus.ddns.net/unir/doctr-gpu(https://seryus.ddns.net/unir/-/packages/container/doctr-gpu/latest) Nota: EasyOCR utiliza el mismo puerto (8002) que PaddleOCR. No se pueden ejecutar simultáneamente. Por esta razón, existe un archivo docker-compose separado para EasyOCR. Imagen Docker: seryus.ddns.net/unir/easyocr-gpu Imagen Docker: seryus.ddns.net/unir/easyocr-gpu(https://seryus.ddns.net/unir/-/packages/container/easyocr-gpu/latest) Tabla 59. Servicios Docker y puertos. Tabla 57. Servicios Docker y puertos. Servicio Puerto Script de Ajuste Nota PaddleOCR 8002 paddle_ocr_payload - DocTR 8003 doctr_payload - EasyOCR 8002 easyocr_payload Conflicto con PaddleOCR Fuente: Elaboración propia. Fuente: Elaboración propia.. Nota: Debido a limitaciones de recursos GPU (VRAM insuficiente para ejecutar múltiples modelos OCR simultáneamente), solo se ejecuta un servicio a la vez. PaddleOCR y EasyOCR comparten el puerto 8002. Para cambiar de servicio, detener el actual con docker compose down. Esta sección presenta los resultados completos de las evaluaciones comparativas y del ajuste de hiperparámetros realizado con Ray Tune sobre los tres servicios OCR evaluados. Tabla 60. Comparativa de servicios OCR en dataset de 45 páginas (GPU RTX 3060). Tabla 58. Comparativa de servicios OCR en dataset de 45 páginas (GPU RTX 3060). Servicio CER WER Tiempo/Página Tiempo Total VRAM PaddleOCR (Mobile) 7.76% 11.62% 0.58s 32.0s 0.06 GB EasyOCR 11.23% 36.36% 1.88s 88.5s ~2 GB DocTR 12.06% 42.01% 0.50s 28.4s ~1 GB Fuente: Elaboración propia. Fuente: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md), [`docs/metrics/metrics_easyocr.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_easyocr.md), [`docs/metrics/metrics_doctr.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_doctr.md).. Ganador: PaddleOCR (Mobile) - Mejor precisión (7.76% CER) con velocidad competitiva y mínimo consumo de VRAM. Se ejecutaron 64 trials por servicio utilizando Ray Tune con Optuna sobre las páginas 5-10 del primer documento. Tabla 61. Resultados del ajuste de hiperparámetros por servicio. Tabla 59. Resultados del ajuste de hiperparámetros por servicio. Servicio CER Base CER Ajustado Mejora Mejor Trial (5 páginas) PaddleOCR 8.85% 7.72% 12.8% 0.79% ✓ DocTR 12.06% 12.07% 0% 7.43% EasyOCR 11.23% 11.14% 0.8% 5.83% Fuente: Elaboración propia. Fuente: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md), [`docs/metrics/metrics_easyocr.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_easyocr.md), [`docs/metrics/metrics_doctr.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_doctr.md).. Nota sobre sobreajuste: La diferencia entre los resultados del mejor trial (subconjunto de 5 páginas) y el dataset completo (45 páginas) indica sobreajuste parcial a las páginas de ajuste. Un subconjunto más amplio mejoraría la generalización. Tabla 60. Distribución de trials por rango de CER. Rango CER Número de trials Porcentaje < 2% 43 67.2% 2% - 5% 10 15.6% 5% - 10% 11 17.2% > 10% 0 0.0% Fuente: [`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).. Figura 17. Distribución de trials por rango de CER (PaddleOCR) Fuente: src/results/raytune_paddle_results_20260119_122609.csv. Nota sobre sobreajuste: La diferencia entre los resultados del mejor trial (subconjunto de 5 páginas) y el dataset completo (45 páginas) indica sobreajuste parcial a las páginas de ajuste. Un subconjunto más grande (15-20 páginas) mejoraría la generalización. La siguiente configuración logró el mejor rendimiento en el ajuste de hiperparámetros: Hallazgos clave: · textline_orientation=true: Crítico para documentos con layouts mixtos · textline_orientation=true: Crítico para documentos con secciones y encabezados · use_doc_orientation_classify=true: Mejora detección de orientación · use_doc_unwarping=false: Innecesario para PDFs digitales · text_det_thresh bajo (0.0462): Detección más sensible mejora resultados Tabla 62. Comparación de rendimiento CPU vs GPU (PaddleOCR). Métrica CPU GPU (RTX 3060) Aceleración Tiempo/Página 69.4s 0.55s 126x más rápido Mejor CER 1.15% 0.79% GPU mejor 45 páginas ~52 min ~25 seg 126x más rápido Fuente: Elaboración propia. Tabla 61. Comparación de rendimiento CPU vs GPU (PaddleOCR). Métrica CPU GPU (RTX 3060) Aceleración Tiempo/Página 69.4s 0.84s 82x más rápido 45 páginas ~52 min ~38 seg 82x más rápido Fuente: Datos de tiempo CPU 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) y tiempos de GPU en trials de ajuste. Elaboración propia.. Figura 18. Tiempo de procesamiento: CPU vs GPU (segundos/página) Fuente: src/raytune_paddle_subproc_results_20251207_192320.csv y src/results/raytune_paddle_results_20260119_122609.csv. Leyenda: Aceleración de 82× con GPU. El procesamiento de una página pasa de 69.4s (CPU) a 0.84s (GPU). Tabla 63. Tipos de errores identificados por servicio OCR. Servicio Fortalezas Debilidades ¿Fine-tuning recomendado? PaddleOCR Preserva estructura, buen manejo de español Errores menores de acentos (~5%) No (ya excelente) DocTR Más rápido Pierde estructura, omite TODOS los diacríticos Sí (para diacríticos) EasyOCR Modelo correcto para español Caracteres espurios, confunde o/0 Sí (problemas del detector) Fuente: Elaboración propia. Tabla 62. Tipos de errores identificados por servicio OCR. Servicio Fortalezas Debilidades ¿Fine-tuning recomendado? PaddleOCR Preserva estructura, buen manejo de español Errores menores de acentos No (ya excelente) DocTR Más rápido Pierde estructura, omite TODOS los diacríticos Sí (para diacríticos) EasyOCR Modelo correcto para español Caracteres espurios, confunde o/0 Sí (problemas del detector) Fuente: Análisis manual del debugset. Elaboración propia.. Los resultados crudos de los 64 trials por servicio están disponibles en el repositorio: Tabla 64. Ubicación de archivos de resultados. Servicio Archivo CSV PaddleOCR DocTR EasyOCR Fuente: Elaboración propia. Tabla 63. Ubicación de archivos de resultados. Servicio Archivo CSV PaddleOCR DocTR EasyOCR Fuente: Elaboración propia.. Las tablas de costos cloud se basan en las páginas oficiales de precios. Se consultaron en enero de 2026. · AWS EC2 g4dn.xlarge: https://aws.amazon.com/ec2/instance-types/g4/ · Google Colab Pro: https://colab.research.google.com/signup · Google Colab Pro+: https://colab.research.google.com/signup Requisitos extraidos de la documentacion oficial de las dependencias usadas: · DocTR: requiere Python 3.10 o superior. · DocTR Docker: imagenes basadas en CUDA 12.2, el host debe ser al menos 12.2. · PaddleOCR: soporte de inferencia con CUDA 12. · PaddleOCR: soporte de Python 3.12 en dependencias. El código se distribuye bajo licencia MIT.Reflexión Final
A.2 Estructura del Repositorio
A.3 Requisitos de Software
Sistema de Desarrollo
-Dependencias
-Dependencias
+A.4 Instrucciones de Ejecución de Servicios OCR
+A.4 Instrucciones de Ejecución de Servicios OCR
PaddleOCR (Puerto 8002)
DocTR (Puerto 8003)
-cd src/doctr_service
@@ -5770,7 +5753,7 @@ docker compose up -d
EasyOCR (Puerto 8002)
cd src/easyocr_service
@@ -5833,26 +5816,35 @@ analyze_results(results, prefix='raytune_paddle', config_keys=PADDLE_OCR_CONFIG_
"
Servicios y Puertos
-A.7 Métricas de Rendimiento
Comparativa General de Servicios
-Resultados de Ajuste de Hiperparámetros
Distribución de trials por rango de CER (PaddleOCR)
+
Configuración Óptima PaddleOCR
Rendimiento CPU vs GPU
-
Análisis de Errores por Servicio
-Archivos de Resultados
A.8 Licencia
+A.8 Fuentes de precios cloud
+A.9 Requisitos documentados por dependencias
+A.10 Licencia