Paddle ocr, easyicr and doctr gpu support. (#4)

docs/metrics/metrics.md

@@ -0,0 +1,242 @@
+# Métricas de Rendimiento OCR
+
+**Fecha de Benchmark:** 2026-01-19
+**Dataset de Prueba:** 45 páginas (2 PDFs)
+
+## Especificaciones del Sistema
+
+| Componente | Especificación |
+|------------|----------------|
+| **Sistema Operativo** | Ubuntu 24.04.3 LTS (Noble) |
+| **Kernel** | 6.14.0-37-generic |
+| **CPU** | AMD Ryzen 7 5800H with Radeon Graphics |
+| **RAM** | 16 GB DDR4 |
+| **GPU** | NVIDIA GeForce RTX 3060 Laptop GPU |
+| **VRAM** | 5.66 GB |
+| **CUDA** | 12.4 |
+
+## Justificación de Ejecución Local vs Cloud
+
+### Costos de Cloud GPU
+
+| 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 |
+
+### Análisis de Costos para Este Proyecto
+
+| 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/debug (20 horas/mes) | 20 horas | ~$10.52 | ~$26.00 |
+
+### Ventajas de Ejecución Local
+
+1. **Costo cero de GPU**: La RTX 3060 ya está disponible en el equipo de desarrollo
+2. **Sin límites de tiempo**: AWS y Colab tienen timeouts de sesión
+3. **Acceso instantáneo**: Sin tiempo de aprovisionamiento de instancias
+4. **Almacenamiento local**: Dataset y resultados en disco sin costos de transferencia
+5. **Iteración rápida**: Reinicio inmediato de contenedores Docker
+
+### Conclusión
+
+Para un proyecto de investigación con múltiples iteraciones de ajuste de hiperparámetros y desarrollo, **la ejecución local ahorra ~$50-100/mes** comparado con cloud, además de ofrecer mayor flexibilidad y velocidad de iteración
+
+## Resumen Ejecutivo
+
+| 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 |
+
+> **Ganador:** PaddleOCR (Mobile) - Mejor precisión (7.76% CER) con velocidad competitiva.
+
+## Fases Experimentales
+
+Este documento presenta resultados de dos fases experimentales distintas realizadas durante el desarrollo del TFM. La primera fase corresponde a la optimización de hiperparámetros utilizando Ray Tune, ejecutada en CPU debido a las limitaciones de hardware iniciales. La segunda fase corresponde a la validación práctica con aceleración GPU para evaluar la viabilidad en escenarios de producción.
+
+**Tabla.** *Fases experimentales y sus características.*
+
+| Fase | Dataset | Hardware | Resultado Principal |
+|------|---------|----------|---------------------|
+| Optimización (CPU) | 24 páginas | CPU | CER: 7.78% → **1.49%** (80.9% mejora) |
+| Validación (GPU) | 45 páginas | RTX 3060 | CER: 7.76% baseline, 0.55s/página |
+
+*Fuente: Elaboración propia.*
+
+La fase de optimización representa el **resultado principal del TFM** (CER 1.49%, precisión 98.51%). La fase de validación GPU confirma la viabilidad práctica del enfoque, demostrando una aceleración de 126x respecto a CPU.
+
+## Comparación de Servicios OCR
+
+### Comparación de Precisión (CER - menor es mejor)
+
+```mermaid
+xychart-beta
+    title "Tasa de Error de Caracteres por Servicio"
+    x-axis ["PaddleOCR", "EasyOCR", "DocTR"]
+    y-axis "CER %" 0 --> 15
+    bar [7.76, 11.23, 12.06]
+```
+
+### Comparación de Velocidad (Tiempo por Página)
+
+```mermaid
+xychart-beta
+    title "Tiempo de Procesamiento por Página (segundos)"
+    x-axis ["DocTR", "PaddleOCR", "EasyOCR"]
+    y-axis "Segundos" 0 --> 2
+    bar [0.50, 0.58, 1.88]
+```
+
+### Flujo de Recomendación de Servicio
+
+```mermaid
+flowchart LR
+    A{Prioridad?}
+    A -->|Precisión| B[PaddleOCR]
+    A -->|Velocidad| C[DocTR]
+    A -->|Balance| B
+    B --> D["7.76% CER<br/>0.58s/página"]
+    C --> E["12.06% CER<br/>0.50s/página"]
+```
+
+### Hallazgos Clave
+
+1. **Mejor Precisión**: PaddleOCR logra las tasas de error más bajas (7.76% CER, 11.62% WER)
+2. **Mejor Velocidad**: DocTR es el más rápido (0.50s/página), pero 55% menos preciso que PaddleOCR
+3. **EasyOCR**: El más lento (3.8x más lento que PaddleOCR) con precisión intermedia
+4. **Eficiencia VRAM**: PaddleOCR Mobile usa solo 0.06 GB
+
+## Configuración de Modelos
+
+| Servicio | Detección | Reconocimiento | ¿Correcto para Español? |
+|----------|-----------|----------------|-------------------------|
+| **PaddleOCR** | PP-OCRv5_mobile_det | PP-OCRv5_mobile_rec | Sí |
+| **DocTR** | db_resnet50 | crnn_vgg16_bn | No (entrenado en inglés/francés) |
+| **EasyOCR** | CRAFT | latin_g2.pth | Sí |
+
+### Notas sobre Modelos
+
+- **PaddleOCR**: Modelos server más precisos disponibles pero requieren >5.3 GB VRAM (OOM en RTX 3060)
+- **DocTR**: Se probó modelo `parseq` como alternativa, resultó 2% peor CER y 2x más lento. El problema de diacríticos es de datos de entrenamiento, no de arquitectura
+- **EasyOCR**: Modelo `latin_g2.pth` es correcto. Los problemas son del detector CRAFT, no del reconocimiento
+
+> **Conclusión sobre Fine-tuning:** Para documentos en español, **usar PaddleOCR directamente**. El fine-tuning de DocTR/EasyOCR no se justifica dado que PaddleOCR ya ofrece 31-36% mejor precisión sin configuración adicional.
+
+## Análisis de Errores (del debugset)
+
+### PaddleOCR (Mejor - 7.76% CER)
+- **Fortalezas**: Preserva estructura de líneas, maneja bien acentos españoles
+- **Problemas**: Errores menores de espaciado, diferencias ocasionales de mayúsculas en acentos
+- **Mejorable**: Sí - el ajuste de hiperparámetros probablemente ayude
+
+### DocTR (Peor WER - 42.01%)
+- **Problema Crítico**: Colapsa todo el texto en líneas únicas (pierde estructura)
+- **Problema de Acentos**: Omite diacríticos ("Indice" vs "Índice")
+- **Mejorable**: Parcialmente - el problema de estructura puede ser a nivel de modelo
+
+### EasyOCR (36.36% WER)
+- **Problema Crítico**: Inserciones espurias de caracteres (";", "g", "0", "1")
+- **Pérdida de Estructura**: Saltos de línea no preservados
+- **Mejorable**: Sí - umbrales de detección demasiado sensibles
+
+## Comparación de Modelos PaddleOCR (RTX 3060)
+
+| Métrica | Modelos Server | Modelos Mobile | Ganador |
+|---------|----------------|----------------|---------|
+| **Tiempo** | 2.47s | 1.08s | Mobile (2.3x más rápido) |
+| **CER** | 1.82% | 1.42% | Mobile |
+| **WER** | 16.14% | 12.20% | Mobile |
+| **VRAM** | 5.3 GB (OOM en página 2) | 0.06 GB | Mobile |
+| **Multi-página** | No (OOM) | Sí | Mobile |
+
+> **Conclusión:** Se recomiendan los modelos Mobile - más rápidos, más precisos, caben en VRAM.
+
+## Rendimiento CPU vs GPU (PaddleOCR)
+
+Datos de `raytune_paddle_subproc_results_20251207_192320.csv` (CPU) vs RTX 3060 (GPU):
+
+| 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** |
+
+```mermaid
+xychart-beta
+    title "Tiempo de Procesamiento por Página: CPU vs GPU"
+    x-axis ["CPU", "GPU (RTX 3060)"]
+    y-axis "Segundos" 0 --> 80
+    bar [69.4, 0.55]
+```
+
+> **Conclusión:** GPU es esencial para uso práctico de OCR. El procesamiento en CPU es 126x más lento, haciéndolo impráctico para procesamiento por lotes.
+
+## Datos Crudos del Benchmark
+
+```json
+{
+  "timestamp": "2026-01-19T11:00:00.000000",
+  "platform": {
+    "gpu": "NVIDIA GeForce RTX 3060 Laptop GPU",
+    "vram": "5.66 GB",
+    "cuda": "12.4"
+  },
+  "services": {
+    "PaddleOCR_Mobile": {
+      "port": 8002,
+      "models": {"det": "PP-OCRv5_mobile_det", "rec": "PP-OCRv5_mobile_rec"},
+      "vram_used": "0.06 GB",
+      "results": {
+        "CER": 0.0776,
+        "WER": 0.1162,
+        "PAGES": 45,
+        "TIME_PER_PAGE": 0.58,
+        "TOTAL_TIME": 32.0
+      }
+    },
+    "DocTR": {
+      "port": 8003,
+      "models": {"det": "db_resnet50", "rec": "crnn_vgg16_bn"},
+      "vram_used": "~1 GB",
+      "results": {
+        "CER": 0.1206,
+        "WER": 0.4201,
+        "PAGES": 45,
+        "TIME_PER_PAGE": 0.50,
+        "TOTAL_TIME": 28.4
+      }
+    },
+    "EasyOCR": {
+      "port": 8002,
+      "languages": ["es", "en"],
+      "vram_used": "~2 GB",
+      "results": {
+        "CER": 0.1123,
+        "WER": 0.3636,
+        "PAGES": 45,
+        "TIME_PER_PAGE": 1.88,
+        "TOTAL_TIME": 88.5
+      }
+    }
+  }
+}
+```
+
+## Resultados de Ajuste de Hiperparámetros
+
+Resultados individuales de ajuste por servicio (64 muestras cada uno, páginas 5-10):
+
+- [Resultados de Ajuste PaddleOCR](metrics_paddle.md)
+- [Resultados de Ajuste DocTR](metrics_doctr.md)
+- [Resultados de Ajuste EasyOCR](metrics_easyocr.md)
+
+## Próximos Pasos
+
+1. ~~Ajuste de Hiperparámetros~~ - Completado (64 muestras por servicio)
+2. **Evaluación del Dataset Completo** - Ejecutar mejores configuraciones en las 45 páginas
+3. **Comparar** - Rendimiento base vs ajustado en dataset completo

docs/metrics/metrics_doctr.md

@@ -0,0 +1,180 @@
+# Resultados de Ajuste de Hiperparámetros DocTR
+
+**Fecha de Ajuste:** 2026-01-19
+**Plataforma:** NVIDIA RTX 3060 Laptop GPU
+**Muestras:** 64
+**Páginas de Prueba:** 5-10 (primer documento)
+
+### ¿Por Qué Solo 5 Páginas?
+
+Usamos solo 5 páginas (páginas 5-10) para el ajuste de hiperparámetros porque:
+
+1. **Velocidad**: 64 pruebas × 5 páginas = 320 evaluaciones de página. Con 45 páginas, serían 2,880 evaluaciones (~9x más tiempo)
+2. **Eficiencia de recursos**: Cada prueba toma ~2-20 segundos en GPU
+
+**Riesgo de Sobreajuste**: El ajuste de hiperparámetros en un subconjunto pequeño PUEDE causar sobreajuste. Nuestros resultados confirman esto:
+- Subconjunto de ajuste: **38% mejora** (7.43% CER)
+- Dataset completo: **0% mejora** (12.07% CER)
+
+La falta total de mejora en el dataset completo indica sobreajuste severo a las páginas 5-10, combinado con limitaciones a nivel de modelo (manejo de diacríticos, estructura de líneas) que los hiperparámetros no pueden corregir.
+
+## Evaluación del Dataset Completo (45 páginas)
+
+| Métrica | Base | Ajustado | Mejora |
+|---------|------|----------|--------|
+| **CER** | 12.06% | 12.07% | **0%** |
+| **WER** | 42.01% | 42.26% | **0%** |
+| Tiempo/Página | 0.33s | 0.34s | - |
+
+> **Nota:** El ajuste no generalizó al dataset completo. Los problemas de DocTR parecen ser a nivel de modelo (diacríticos, estructura de líneas).
+
+## Resultados del Subconjunto de Ajuste (páginas 5-10)
+
+| Métrica | Base | Ajustado | Mejora |
+|---------|------|----------|--------|
+| **CER** | 12.06% | **7.43%** | **38%** |
+| **WER** | 42.01% | **35.23%** | **16%** |
+
+> Nota: Las mejoras en el subconjunto de ajuste no se transfirieron al dataset completo.
+
+## Mejor Configuración Encontrada
+
+```json
+{
+  "assume_straight_pages": true,
+  "straighten_pages": false,
+  "preserve_aspect_ratio": false,
+  "symmetric_pad": false,
+  "disable_page_orientation": true,
+  "disable_crop_orientation": false,
+  "resolve_lines": true,
+  "resolve_blocks": false,
+  "paragraph_break": 0.0977
+}
+```
+
+## Hallazgos Clave
+
+1. **straighten_pages: false** - ¡Crítico! Configurarlo en true causa ~79% CER (catastrófico)
+2. **assume_straight_pages: true** - Funciona bien con escaneos de documentos rectos
+3. **resolve_lines: true** - Ayuda a mantener la estructura de líneas
+4. **disable_page_orientation: true** - Evita rotación innecesaria
+
+## Impacto de Parámetros
+
+Parámetros que mejoraron la precisión:
+- `straighten_pages=False` absolutamente crítico
+- `assume_straight_pages=True` en los mejores resultados
+- `resolve_lines=True` mantiene la estructura del texto
+
+Parámetros que perjudicaron la precisión:
+- `straighten_pages=True` catastróficamente malo (~79% CER)
+- `resolve_blocks=True` ligeramente peor que False
+
+## Limitaciones Conocidas
+
+Incluso con ajuste, DocTR todavía tiene problemas:
+- Omite diacríticos (tildes) - probablemente problema a nivel de modelo
+- Todavía tiene mayor WER que PaddleOCR debido a problemas de estructura
+
+## Evaluación del Dataset Completo
+
+**Estado:** Completado
+
+```bash
+curl -X POST http://localhost:8003/evaluate_full \
+  -H "Content-Type: application/json" \
+  -d '{
+    "pdf_folder": "/app/dataset",
+    "assume_straight_pages": true,
+    "straighten_pages": false,
+    "preserve_aspect_ratio": false,
+    "symmetric_pad": false,
+    "disable_page_orientation": true,
+    "disable_crop_orientation": false,
+    "resolve_lines": true,
+    "resolve_blocks": false,
+    "paragraph_break": 0.0977,
+    "save_output": true
+  }'
+```
+
+**Resultado:** CER 12.07%, WER 42.26%, 0.34s/página (sin mejora sobre la base)
+
+**Conclusión:** Los problemas de precisión de DocTR son a nivel de modelo, no ajustables por hiperparámetros.
+
+## Configuración del Modelo
+
+### Modelo Actual
+
+| Componente | Modelo | Estado |
+|------------|--------|--------|
+| Detección | `db_resnet50` | Correcto |
+| Reconocimiento | `crnn_vgg16_bn` | Mejor opción disponible |
+
+El modelo `crnn_vgg16_bn` fue entrenado principalmente con datasets en inglés y francés, lo que explica la pérdida sistemática de diacríticos españoles (á, é, í, ó, ú, ñ).
+
+### Prueba con Modelo Alternativo (parseq)
+
+Se probó el modelo `parseq` (transformer) como alternativa:
+
+| Métrica | crnn_vgg16_bn | parseq | Resultado |
+|---------|---------------|--------|-----------|
+| **CER** | 12.07% | 12.32% | **+2% peor** |
+| **WER** | 42.26% | 44.0% | **+4% peor** |
+| Tiempo/Página | 0.34s | 0.70s | 2x más lento |
+| Diacríticos | No | No | Sin mejora |
+
+**Conclusión:** El modelo `parseq` no mejora los diacríticos españoles y es más lento. Todos los modelos pre-entrenados de DocTR fueron entrenados principalmente en inglés/francés. Para español se requeriría **fine-tuning con corpus español**.
+
+### No Se Recomienda Cambio de Modelo
+
+Mantener `crnn_vgg16_bn` (más rápido, ligeramente mejor precisión). Los problemas de diacríticos son de **datos de entrenamiento**, no de arquitectura del modelo
+
+## Análisis de Errores del Debugset
+
+### Errores Observados
+
+| Ground Truth | DocTR | Tipo de Error |
+|--------------|-------|---------------|
+| `bibliográficas` | `bibliograficas` | Diacrítico omitido |
+| `sección` | `seccion` | Diacrítico omitido |
+| `Máster` | `Master` | Diacrítico omitido |
+| `información` | `informacion` | Diacrítico omitido |
+| `o amplían` | `O amplian` | Mayúscula incorrecta |
+| Líneas separadas | Todo en una línea | **Estructura perdida** |
+
+### Problemas Críticos
+
+1. **Pérdida total de estructura**: Todo el texto de la página se colapsa en una sola línea
+2. **Omisión sistemática de diacríticos**: TODOS los acentos españoles se pierden
+3. **Errores de capitalización**: `o` → `O` en medio de oraciones
+
+### ¿Fine-tuning Recomendado?
+
+**Sí, para diacríticos.** El modelo CRNN de DocTR fue entrenado principalmente con textos en inglés y francés, lo que explica la omisión sistemática de acentos españoles.
+
+| Problema | ¿Fine-tuning ayuda? | Explicación |
+|----------|---------------------|-------------|
+| Diacríticos | **Sí** | Entrenar con corpus español enseñaría al modelo los acentos |
+| Estructura de líneas | **No** | Problema arquitectural del modelo, no de entrenamiento |
+| Capitalización | **Parcial** | Podría mejorar con datos de entrenamiento adecuados |
+
+### Cómo Fine-Tunear DocTR
+
+```python
+from doctr.models import recognition_predictor
+from doctr.datasets import RecognitionDataset
+
+# Cargar dataset español
+train_set = RecognitionDataset(
+    img_folder="path/to/spanish/images",
+    labels_path="path/to/spanish/labels.json"
+)
+
+# Fine-tune el modelo de reconocimiento
+model = recognition_predictor(pretrained=True)
+# ... configurar entrenamiento
+```
+
+Documentación: https://mindee.github.io/doctr/using_doctr/custom_models_training.html

docs/metrics/metrics_easyocr.md

@@ -0,0 +1,182 @@
+# Resultados de Ajuste de Hiperparámetros EasyOCR
+
+**Fecha de Ajuste:** 2026-01-19
+**Plataforma:** NVIDIA RTX 3060 Laptop GPU
+**Muestras:** 64
+**Páginas de Prueba:** 5-10 (primer documento)
+
+### ¿Por Qué Solo 5 Páginas?
+
+Usamos solo 5 páginas (páginas 5-10) para el ajuste de hiperparámetros porque:
+
+1. **Velocidad**: 64 pruebas × 5 páginas = 320 evaluaciones de página. Con 45 páginas, serían 2,880 evaluaciones (~9x más tiempo)
+2. **Eficiencia de recursos**: Cada prueba toma ~10-20 segundos en GPU
+
+**Riesgo de Sobreajuste**: El ajuste de hiperparámetros en un subconjunto pequeño PUEDE causar sobreajuste. Nuestros resultados confirman esto:
+- Subconjunto de ajuste: **48% mejora** (5.83% CER)
+- Dataset completo: **0.8% mejora** (11.14% CER)
+
+La mejora mínima en el dataset completo indica que los hiperparámetros se sobreajustaron a las páginas 5-10. Los problemas de EasyOCR (detecciones espurias, pérdida de estructura) también pueden ser parcialmente a nivel de modelo.
+
+## Evaluación del Dataset Completo (45 páginas)
+
+| Métrica | Base | Ajustado | Mejora |
+|---------|------|----------|--------|
+| **CER** | 11.23% | 11.14% | **0.8%** |
+| **WER** | 36.36% | 36.85% | **-1.3%** |
+| Tiempo/Página | 1.84s | 1.94s | - |
+
+> **Nota:** El ajuste mostró mejora mínima en el dataset completo. Los problemas de EasyOCR pueden ser a nivel de modelo.
+
+## Resultados del Subconjunto de Ajuste (páginas 5-10)
+
+| Métrica | Base | Ajustado | Mejora |
+|---------|------|----------|--------|
+| **CER** | 11.23% | **5.83%** | **48%** |
+| **WER** | 36.36% | **26.33%** | **28%** |
+
+> Nota: Las grandes mejoras en el subconjunto de ajuste no se transfirieron al dataset completo.
+
+## Mejor Configuración Encontrada
+
+```json
+{
+  "text_threshold": 0.6647,
+  "low_text": 0.4247,
+  "link_threshold": 0.2184,
+  "slope_ths": 0.1629,
+  "ycenter_ths": 0.7994,
+  "height_ths": 0.6437,
+  "width_ths": 0.6065,
+  "add_margin": 0.1462,
+  "contrast_ths": 0.1671,
+  "adjust_contrast": 0.6416,
+  "decoder": "greedy",
+  "beamWidth": 7,
+  "min_size": 10
+}
+```
+
+## Hallazgos Clave
+
+1. **decoder: greedy** - Consistentemente mejor que beamsearch para este dataset
+2. **Mayor text_threshold (0.66)** - Reduce detecciones espurias
+3. **min_size: 10** - Filtra artefactos de ruido pequeños
+4. **Umbrales moderados** - Sensibilidad de detección balanceada
+
+## Impacto de Parámetros
+
+Parámetros que mejoraron la precisión:
+- `decoder="greedy"` consistentemente superó a beamsearch
+- Mayor `text_threshold` (0.6-0.8) redujo el ruido
+- `min_size >= 5` ayudó a filtrar artefactos
+
+Parámetros que perjudicaron la precisión:
+- `decoder="beamsearch"` causó ~35-40% CER en muchas pruebas
+- `text_threshold` muy bajo (<0.4) detectó demasiado ruido
+- `min_size` alto (>15) omitió algo de texto
+
+## Comparación con Problemas de Base
+
+Problemas originales identificados en el debugset:
+- Inserciones espurias de caracteres - **Mejorado** con umbrales más altos
+- Pérdida de estructura - Todavía presente pero menos severa
+
+## Evaluación del Dataset Completo
+
+**Estado:** Completado
+
+```bash
+curl -X POST http://localhost:8002/evaluate_full \
+  -H "Content-Type: application/json" \
+  -d '{
+    "pdf_folder": "/app/dataset",
+    "text_threshold": 0.6647,
+    "low_text": 0.4247,
+    "link_threshold": 0.2184,
+    "slope_ths": 0.1629,
+    "ycenter_ths": 0.7994,
+    "height_ths": 0.6437,
+    "width_ths": 0.6065,
+    "add_margin": 0.1462,
+    "contrast_ths": 0.1671,
+    "adjust_contrast": 0.6416,
+    "decoder": "greedy",
+    "beamWidth": 7,
+    "min_size": 10,
+    "save_output": true
+  }'
+```
+
+**Resultado:** CER 11.14%, WER 36.85%, 1.94s/página (mejora mínima)
+
+**Conclusión:** El ajuste de EasyOCR proporcionó mejora insignificante en el dataset completo.
+
+## Configuración del Modelo
+
+### Modelo Actual (Correcto para Español)
+
+| Componente | Modelo | Estado |
+|------------|--------|--------|
+| Detección | CRAFT | Correcto |
+| Reconocimiento | `latin_g2.pth` | Correcto para español |
+| Idiomas | `es,en` | Correcto |
+
+El modelo `latin_g2.pth` está optimizado para idiomas con escritura latina incluyendo español. **El modelo de reconocimiento es correcto** - los problemas observados (caracteres espurios `0`, `;`, `g`) son del **detector CRAFT**, no del modelo de reconocimiento.
+
+### No Se Requiere Cambio de Modelo
+
+A diferencia de DocTR, EasyOCR usa el modelo correcto para español. Los problemas son de detección (umbrales del CRAFT), no de reconocimiento.
+
+## Análisis de Errores del Debugset
+
+### Errores Observados
+
+| Ground Truth | EasyOCR | Tipo de Error |
+|--------------|---------|---------------|
+| `o figura` | `0 figura` | Letra `o` → número `0` |
+| `tabla o figura` | `tabla 0 figura` | Letra `o` → número `0` |
+| `grupal,` | `grupal;` | Coma → punto y coma |
+| `páginas,` | `páginas;` | Puntuación incorrecta |
+| (ninguno) | `g`, `1`, `2` | **Caracteres espurios insertados** |
+| Líneas separadas | Todo en una línea | **Estructura perdida** |
+
+### Problemas Críticos
+
+1. **Caracteres espurios**: El detector CRAFT inserta caracteres falsos (`g`, `1`, `2`, `;`) que no existen en el documento
+2. **Confusión letra/número**: Consistentemente confunde `o` con `0`
+3. **Puntuación incorrecta**: Reemplaza comas por punto y coma
+4. **Pérdida de estructura**: Todo el texto se colapsa en una línea
+
+### ¿Fine-tuning Recomendado?
+
+**Sí.** EasyOCR tiene problemas significativos que podrían mejorarse con fine-tuning:
+
+| Problema | ¿Fine-tuning ayuda? | Explicación |
+|----------|---------------------|-------------|
+| Caracteres espurios | **Sí** | El detector CRAFT puede entrenarse para reducir falsos positivos |
+| Confusión `o`/`0` | **Sí** | El modelo de reconocimiento aprendería del contexto español |
+| Puntuación | **Sí** | Corpus español enseñaría patrones de puntuación correctos |
+| Estructura | **Parcial** | Depende de parámetros de agrupación de texto |
+
+### Cómo Fine-Tunear EasyOCR
+
+EasyOCR permite fine-tuning del modelo de reconocimiento:
+
+```bash
+# 1. Preparar dataset en formato EasyOCR
+# Estructura: images/ + labels.txt (imagen<tab>texto)
+
+# 2. Entrenar modelo de reconocimiento
+python train.py \
+  --train_data ./train_data \
+  --valid_data ./valid_data \
+  --lang_list es en \
+  --saved_model ./custom_model
+```
+
+Documentación: https://github.com/JaidedAI/EasyOCR/blob/master/custom_model.md
+
+### Alternativa Recomendada
+
+Dado el CER de 11.14% y los problemas fundamentales de EasyOCR, se recomienda **usar PaddleOCR** (7.72% CER) en lugar de invertir esfuerzo en fine-tuning de EasyOCR

docs/metrics/metrics_paddle.md

@@ -0,0 +1,141 @@
+# Resultados de Ajuste de Hiperparámetros PaddleOCR
+
+> **Nota:** Los resultados de este documento corresponden a la fase de validación GPU con 45 páginas. El resultado oficial del TFM es **CER 1.49%** obtenido en la validación final de 24 páginas con la configuración optimizada (ver `docs/04_desarrollo_especifico.md`).
+
+**Fecha de Ajuste:** 2026-01-19
+**Plataforma:** NVIDIA RTX 3060 Laptop GPU
+**Muestras:** 64
+**Páginas de Prueba:** 5-10 (primer documento)
+
+### ¿Por Qué Solo 5 Páginas?
+
+Usamos solo 5 páginas (páginas 5-10) para el ajuste de hiperparámetros porque:
+
+1. **Velocidad**: 64 pruebas × 5 páginas = 320 evaluaciones de página. Con 45 páginas, serían 2,880 evaluaciones (~9x más tiempo)
+2. **Eficiencia de recursos**: Cada prueba toma ~3-10 segundos en GPU; el dataset completo tomaría ~1 hora por prueba en CPU
+
+**Riesgo de Sobreajuste**: El ajuste de hiperparámetros en un subconjunto pequeño PUEDE causar sobreajuste. Nuestros resultados confirman esto:
+- Subconjunto de ajuste: **90% mejora** (0.79% CER)
+- Dataset completo: **12.8% mejora** (7.72% CER)
+
+La diferencia dramática muestra que los hiperparámetros se sobreajustaron parcialmente a las páginas 5-10. Un subconjunto de ajuste más grande (ej. 15-20 páginas) podría producir parámetros que generalicen mejor, pero aumentaría el tiempo de ajuste proporcionalmente.
+
+## Evaluación del Dataset Completo (45 páginas)
+
+| Métrica | Base | Ajustado | Mejora |
+|---------|------|----------|--------|
+| **CER** | 8.85% | **7.72%** | **12.8%** |
+| **WER** | 13.05% | **11.40%** | **12.6%** |
+| Tiempo/Página | 0.51s | 0.55s | - |
+
+## Resultados del Subconjunto de Ajuste (páginas 5-10)
+
+| Métrica | Base | Ajustado | Mejora |
+|---------|------|----------|--------|
+| **CER** | 7.76% | **0.79%** | **90%** |
+| **WER** | 11.62% | **7.78%** | **33%** |
+
+> Nota: El subconjunto de ajuste mostró mayores mejoras, sugiriendo que algunos hiperparámetros son específicos de la página.
+
+## Mejor Configuración Encontrada
+
+```json
+{
+  "use_doc_orientation_classify": true,
+  "use_doc_unwarping": false,
+  "textline_orientation": true,
+  "text_det_thresh": 0.0462,
+  "text_det_box_thresh": 0.4862,
+  "text_det_unclip_ratio": 0.0,
+  "text_rec_score_thresh": 0.5658
+}
+```
+
+## Hallazgos Clave
+
+1. **textline_orientation: true** - Crítico para la precisión
+2. **use_doc_orientation_classify: true** - Ayuda con la detección de orientación de página
+3. **use_doc_unwarping: false** - El enderezamiento de documentos perjudica la precisión en este dataset
+4. **Bajo text_det_thresh (0.0462)** - Detección de texto más sensible ayuda
+5. **Mayor text_rec_score_thresh (0.5658)** - Filtra reconocimientos de baja confianza
+
+## Impacto de Parámetros
+
+Parámetros que mejoraron la precisión:
+- `textline_orientation=True` consistentemente en los mejores resultados
+- `use_doc_orientation_classify=True` en las mejores pruebas
+- Valores más bajos de `text_det_thresh` (0.04-0.10)
+
+Parámetros que perjudicaron la precisión:
+- `use_doc_unwarping=True` aumentó el CER significativamente
+- `text_det_box_thresh` muy bajo (<0.01) causó problemas
+
+## Evaluación del Dataset Completo
+
+**Estado:** Completado
+
+```bash
+curl -X POST http://localhost:8002/evaluate_full \
+  -H "Content-Type: application/json" \
+  -d '{
+    "pdf_folder": "/app/dataset",
+    "use_doc_orientation_classify": true,
+    "use_doc_unwarping": false,
+    "textline_orientation": true,
+    "text_det_thresh": 0.0462,
+    "text_det_box_thresh": 0.4862,
+    "text_det_unclip_ratio": 0.0,
+    "text_rec_score_thresh": 0.5658,
+    "save_output": true
+  }'
+```
+
+**Resultado:** CER 7.72%, WER 11.40%, 0.55s/página
+
+## Configuración del Modelo
+
+### Modelo Actual (Correcto para Español)
+
+| Componente | Modelo | Estado |
+|------------|--------|--------|
+| Detección | `PP-OCRv5_mobile_det` | Correcto |
+| Reconocimiento | `PP-OCRv5_mobile_rec` | Correcto |
+
+Los modelos PP-OCRv5 mobile soportan múltiples idiomas incluyendo español con buen manejo de diacríticos.
+
+### Nota sobre Modelos Server
+
+PaddleOCR ofrece modelos "server" más precisos:
+- `PP-OCRv5_server_det` + `PP-OCRv5_server_rec`
+- Requieren ~5.3 GB VRAM
+
+**Limitación:** En la RTX 3060 (5.66 GB VRAM) los modelos server causan **OOM (Out of Memory)** en la página 2. Los modelos mobile usados (7.72% CER) son la mejor opción práctica para este hardware.
+
+Para hardware con más VRAM (8+ GB), los modelos server podrían mejorar la precisión.
+
+## Análisis de Errores del Debugset
+
+### Errores Observados
+
+| Ground Truth | PaddleOCR | Tipo de Error |
+|--------------|-----------|---------------|
+| `bibliografía` | `bibliografia` | Acento omitido |
+| `amplían` | `amplian` | Acento omitido |
+| `, debes` | `， debes` | Coma Unicode china |
+| Líneas separadas | Footer fusionado | Estructura menor |
+
+### Fortalezas
+
+- **Preserva estructura de líneas**: Mantiene saltos de línea correctamente
+- **Buen manejo de español**: La mayoría de acentos se reconocen bien
+- **Bajo ruido**: No inserta caracteres espurios
+
+### ¿Fine-tuning Recomendado?
+
+**No.** Con 7.72% CER, PaddleOCR ya tiene excelente precisión para documentos españoles. Los errores observados son menores:
+
+- Acentos omitidos: ~5% de casos
+- Puntuación Unicode: Muy ocasional
+- Impacto en legibilidad: Mínimo
+
+El esfuerzo de fine-tuning no se justifica para ganancias marginales. Para casos de uso críticos donde se requiera <5% CER, considerar post-procesamiento con corrector ortográfico