unir/MastersThesis
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

deliberable_04_01_2026
All checks were successful
build_docker / essential (push) Successful in 1s
Details
build_docker / build_paddle_ocr (push) Successful in 5m12s
Details
build_docker / build_paddle_ocr_gpu (push) Successful in 20m54s
Details
build_docker / build_easyocr (push) Successful in 18m19s
Details
build_docker / build_doctr (push) Successful in 19m49s
Details
build_docker / build_easyocr_gpu (push) Successful in 24m6s
Details
build_docker / build_raytune (push) Successful in 4m10s
Details
build_docker / build_doctr_gpu (push) Successful in 16m26s
Details

Browse Source 
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Sergio Jimenez Jimenez
2026-02-04 18:43:22 +01:00
parent 9ee2490097
commit d746a3c73f
55 changed files with 2273 additions and 1720 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/metrics/metrics.md
View File

@@ -29,7 +29,7 @@
| Tarea | Tiempo GPU | Costo AWS | Costo Colab Pro |
|-------|------------|-----------|-----------------|
| Ajuste hiperparámetros (64×3 trials) | ~3 horas | ~$1.58 | ~$3.90 |
| Ajuste hiperparámetros (64x3 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 |
@@ -68,7 +68,7 @@ Este documento presenta resultados de dos fases experimentales distintas realiza
*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.
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. La aceleración respecto a CPU se estima en 82x cuando se compara el tiempo medio por página de los trials de ajuste en CPU y GPU.
## Comparación de Servicios OCR
@@ -180,13 +180,12 @@ flowchart LR
## Rendimiento CPU vs GPU (PaddleOCR)
Datos de `raytune_paddle_subproc_results_20251207_192320.csv` (CPU) vs RTX 3060 (GPU):
Datos de tiempos de los trials de ajuste en CPU (`raytune_paddle_subproc_results_20251207_192320.csv`) frente a GPU (RTX 3060):
| 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** |
| **Tiempo/Página** | 69.4s | 0.84s | **82x más rápido** |
| **45 páginas** | ~52 min | ~38 seg | **82x más rápido** |
```mermaid
---
@@ -204,10 +203,10 @@ 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]
bar [69.4, 0.84]
```
> **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.
> **Conclusión:** GPU es esencial para uso práctico de OCR. En los trials de ajuste, el procesamiento en CPU es 82x más lento.
## Datos Crudos del Benchmark

362
docs/metrics/metrics_doctr.md
View File

@@ -1,180 +1,182 @@
# 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
# 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 x 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.
*Fuente: [https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/raytune_doctr_results_20260119_121445.csv*](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/raytune_doctr_results_20260119_121445.csv*)
## 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](https://mindee.github.io/doctr/using_doctr/custom_models_training.html)

366
docs/metrics/metrics_easyocr.md
View File

@@ -1,182 +1,184 @@
# 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
# 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 x 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.
*Fuente: [https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/raytune_easyocr_results_20260119_120204.csv*](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/raytune_easyocr_results_20260119_120204.csv*)
## 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](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

288
docs/metrics/metrics_paddle.md
View File

@@ -1,143 +1,145 @@
# Resultados de Ajuste de Hiperparámetros PaddleOCR
> **Resultados principales del TFM:**
> - Mejor trial (5 páginas): **CER 0.79%** ✓ cumple objetivo CER < 2%
> - Dataset completo (45 páginas): **CER 7.72%** (mejora del 12.8% respecto a baseline)
**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
# Resultados de Ajuste de Hiperparámetros PaddleOCR
> **Resultados principales del TFM:**
> - Mejor trial (5 páginas): **CER 0.79%** ✓ cumple objetivo CER < 2%
> - Dataset completo (45 páginas): **CER 7.72%** (mejora del 12.8% respecto a baseline)
**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 x 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.
*Fuente: [https://seryus.ddns.net/unir/MastersThesis/src/branch/main/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*)
## 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