README.md

@@ -113,6 +113,34 @@ MastersThesis/
 
 ---
 
+## Rendimiento GPU
+
+Se realizó una validación adicional con aceleración GPU para evaluar la viabilidad práctica del enfoque en escenarios de producción.
+
+**Tabla.** *Comparación de rendimiento CPU vs GPU.*
+
+| Métrica | CPU | GPU (RTX 3060) | Aceleración |
+|---------|-----|----------------|-------------|
+| Tiempo/Página | 69.4s | 0.55s | **126x** |
+| Dataset completo (45 páginas) | ~52 min | ~25 seg | **126x** |
+
+*Fuente: Elaboración propia.*
+
+### Recomendación de Modelos
+
+**Tabla.** *Comparación de modelos PaddleOCR en RTX 3060.*
+
+| Modelo | VRAM | Recomendación |
+|--------|------|---------------|
+| **PP-OCRv5 Mobile** | 0.06 GB | ✓ Recomendado |
+| PP-OCRv5 Server | 5.3 GB | ✗ Causa OOM en RTX 3060 |
+
+*Fuente: Elaboración propia.*
+
+**Conclusión:** Para hardware con VRAM limitada (≤6 GB), los modelos Mobile ofrecen el mejor balance entre precisión y recursos. La aceleración GPU hace viable el procesamiento en tiempo real.
+
+---
+
 ## Requisitos
 
 | Componente | Versión |
@@ -252,12 +280,13 @@ python3 apply_content.py
 
 ## Trabajo Pendiente para Completar el TFM
 
-### Contexto: Limitaciones de Hardware
+### Contexto: Hardware
 
-Este trabajo adoptó la estrategia de **optimización de hiperparámetros** en lugar de **fine-tuning** debido a:
+Este trabajo adoptó la estrategia de **optimización de hiperparámetros** en lugar de **fine-tuning** debido a que el fine-tuning de modelos OCR requiere datasets etiquetados extensos y tiempos de entrenamiento prohibitivos.
-- **Sin GPU dedicada**: Ejecución exclusivamente en CPU
+
-- **Tiempo de inferencia elevado**: ~69 segundos/página en CPU
+**Hardware utilizado:**
-- **Fine-tuning inviable**: Entrenar modelos de deep learning sin GPU requeriría tiempos prohibitivos
+- **Optimización (CPU)**: Los 64 trials de Ray Tune se ejecutaron en CPU (~69s/página)
+- **Validación (GPU)**: Se validó con RTX 3060 logrando 126x de aceleración (0.55s/página)
 
 La optimización de hiperparámetros demostró ser una **alternativa efectiva** al fine-tuning, logrando una reducción del 80.9% en el CER sin reentrenar el modelo.
 
@@ -278,7 +307,7 @@ La optimización de hiperparámetros demostró ser una **alternativa efectiva**
 #### 2. Experimentación Adicional (Prioridad Media)
 - [ ] **Explorar `text_det_unclip_ratio`**: Este parámetro quedó fijado en 0.0. Incluirlo en el espacio de búsqueda podría mejorar resultados
 - [ ] **Comparativa con fine-tuning** (si se obtiene acceso a GPU): Cuantificar la brecha de rendimiento entre optimización de hiperparámetros y fine-tuning real
-- [ ] **Evaluación con GPU**: Medir tiempos de inferencia con aceleración GPU para escenarios de producción
+- [x] **Evaluación con GPU**: Validado con RTX 3060 - 126x más rápido que CPU (0.55s/página vs 69.4s/página)
 
 #### 3. Documentación y Presentación (Prioridad Alta)
 - [ ] **Crear presentación**: Preparar slides para la defensa del TFM

apply_content.py

@@ -5,7 +5,7 @@ import re
 import os
 from bs4 import BeautifulSoup, NavigableString
 
-BASE_DIR = '/Users/sergio/Desktop/MastersThesis'
+BASE_DIR = os.path.dirname(os.path.abspath(__file__))
 TEMPLATE = os.path.join(BASE_DIR, 'thesis_output/plantilla_individual.htm')
 DOCS_DIR = os.path.join(BASE_DIR, 'docs')
 

docs/04_desarrollo_especifico.md

@@ -1068,3 +1068,67 @@ Este capítulo ha presentado el desarrollo completo de la contribución:
 **Fuentes de datos:**
 - `src/raytune_paddle_subproc_results_20251207_192320.csv`: Resultados de 64 trials
 - `src/paddle_ocr_fine_tune_unir_raytune.ipynb`: Notebook principal del experimento
+
+### Validación con Aceleración GPU
+
+Para evaluar la viabilidad práctica del enfoque optimizado en escenarios de producción, se realizó una validación adicional utilizando aceleración GPU. Esta fase complementa los experimentos en CPU presentados anteriormente y demuestra la aplicabilidad del método cuando se dispone de hardware con capacidad de procesamiento paralelo.
+
+#### Configuración del Entorno GPU
+
+**Tabla 36.** *Especificaciones del entorno de validación GPU.*
+
+| Componente | Especificación |
+|------------|----------------|
+| GPU | NVIDIA GeForce RTX 3060 Laptop |
+| VRAM | 5.66 GB |
+| CUDA | 12.4 |
+| Sistema Operativo | Ubuntu 24.04.3 LTS |
+| Kernel | 6.14.0-37-generic |
+
+*Fuente: Elaboración propia.*
+
+El entorno de validación representa hardware de consumo típico para desarrollo de aplicaciones de machine learning, permitiendo evaluar el rendimiento en condiciones realistas de despliegue.
+
+#### Comparación CPU vs GPU
+
+Se evaluó el tiempo de procesamiento utilizando la configuración optimizada identificada en la fase anterior, comparando el rendimiento entre CPU y GPU.
+
+**Tabla 37.** *Rendimiento comparativo CPU vs GPU.*
+
+| Métrica | CPU | GPU (RTX 3060) | Factor de Aceleración |
+|---------|-----|----------------|----------------------|
+| Tiempo/Página | 69.4s | 0.55s | **126x** |
+| Dataset completo (45 páginas) | ~52 min | ~25 seg | **126x** |
+
+*Fuente: Elaboración propia a partir de experimentos.*
+
+La aceleración de 126x obtenida con GPU transforma la aplicabilidad práctica del sistema. Mientras que el procesamiento en CPU limita el uso a escenarios de procesamiento por lotes sin restricciones de tiempo, la velocidad con GPU habilita casos de uso interactivos y de tiempo real.
+
+#### Comparación de Modelos PaddleOCR
+
+PaddleOCR ofrece dos variantes de modelos: Mobile (optimizados para dispositivos con recursos limitados) y Server (mayor precisión a costa de mayor consumo de memoria). Se evaluó la viabilidad de ambas variantes en el hardware disponible.
+
+**Tabla 38.** *Comparación de modelos Mobile vs Server en RTX 3060.*
+
+| 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.*
+
+Los modelos Server, a pesar de ofrecer potencialmente mayor precisión, resultan inviables en hardware con VRAM limitada (≤6 GB) debido a errores de memoria (Out of Memory). Los modelos Mobile, con un consumo de memoria 88 veces menor, funcionan de manera estable y ofrecen rendimiento suficiente para el caso de uso evaluado.
+
+#### Conclusiones de la Validación GPU
+
+La validación con aceleración GPU permite extraer las siguientes conclusiones:
+
+1. **Aceleración significativa**: La GPU proporciona una aceleración de 126x sobre CPU, haciendo viable el procesamiento en tiempo real para aplicaciones interactivas.
+
+2. **Modelos Mobile recomendados**: Para hardware con VRAM limitada (≤6 GB), los modelos Mobile de PP-OCRv5 ofrecen el mejor balance entre precisión y recursos, funcionando de manera estable sin errores de memoria.
+
+3. **Viabilidad práctica**: Con GPU, el procesamiento de un documento completo (45 páginas) toma menos de 30 segundos, validando la aplicabilidad en entornos de producción donde el tiempo de respuesta es crítico.
+
+4. **Escalabilidad**: La arquitectura de microservicios dockerizados utilizada para la validación GPU facilita el despliegue horizontal, permitiendo escalar el procesamiento según demanda.
+
+Esta validación demuestra que la configuración optimizada mediante Ray Tune no solo mejora la precisión (CER: 7.78% → 1.49%) sino que, combinada con aceleración GPU, resulta prácticamente aplicable en escenarios de producción real.

docs/05_conclusiones_trabajo_futuro.md

@@ -69,7 +69,7 @@ El objetivo principal del trabajo era alcanzar un CER inferior al 2% en document
 
 3. **Ground truth automático**: La extracción automática del texto de referencia puede introducir errores en layouts complejos.
 
-4. **Ejecución en CPU**: Los tiempos de procesamiento (~69s/página) limitan la aplicabilidad en escenarios de alto volumen.
+4. **Validación en entorno limitado**: Aunque se validó con GPU (126x más rápido que CPU, 0.55s/página), los experimentos se realizaron en hardware de consumo (RTX 3060). Hardware empresarial podría ofrecer mejor rendimiento.
 
 5. **Parámetro no explorado**: `text_det_unclip_ratio` permaneció fijo en 0.0 durante todo el experimento.
 
@@ -83,8 +83,6 @@ El objetivo principal del trabajo era alcanzar un CER inferior al 2% en document
 
 3. **Dataset ampliado**: Construir un corpus más amplio y diverso de documentos en español.
 
-4. **Evaluación con GPU**: Medir tiempos de inferencia con aceleración GPU.
-
 ### Líneas de Investigación
 
 1. **Transfer learning de hiperparámetros**: Investigar si las configuraciones óptimas para un tipo de documento transfieren a otros dominios.

docs/metrics/metrics.md

@@ -55,6 +55,21 @@ Para un proyecto de investigación con múltiples iteraciones de ajuste de hiper
 
 > **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)
@@ -96,6 +111,22 @@ flowchart LR
 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)

docs/metrics/metrics_doctr.md

@@ -102,3 +102,79 @@ curl -X POST http://localhost:8003/evaluate_full \
 **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

@@ -111,3 +111,72 @@ curl -X POST http://localhost:8002/evaluate_full \
 **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

@@ -1,5 +1,7 @@
 # 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
@@ -89,3 +91,51 @@ curl -X POST http://localhost:8002/evaluate_full \
 ```
 
 **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

generate_mermaid_figures.py

@@ -6,7 +6,7 @@ import re
 import subprocess
 import json
 
-BASE_DIR = '/Users/sergio/Desktop/MastersThesis'
+BASE_DIR = os.path.dirname(os.path.abspath(__file__))
 DOCS_DIR = os.path.join(BASE_DIR, 'docs')
 OUTPUT_DIR = os.path.join(BASE_DIR, 'thesis_output/figures')
 MMDC = os.path.join(BASE_DIR, 'node_modules/.bin/mmdc')

thesis_output/figures/figures_manifest.json

@@ -1,47 +1 @@
-[
+[]
-  {
-    "file": "figura_1.png",
-    "title": "Pipeline de un sistema OCR moderno",
-    "index": 1
-  },
-  {
-    "file": "figura_2.png",
-    "title": "Ciclo de optimización con Ray Tune y Optuna",
-    "index": 2
-  },
-  {
-    "file": "figura_3.png",
-    "title": "Fases de la metodología experimental",
-    "index": 3
-  },
-  {
-    "file": "figura_4.png",
-    "title": "Estructura del dataset de evaluación",
-    "index": 4
-  },
-  {
-    "file": "figura_5.png",
-    "title": "Arquitectura de ejecución con subprocesos",
-    "index": 5
-  },
-  {
-    "file": "figura_6.png",
-    "title": "Arquitectura de ejecución con subprocesos",
-    "index": 6
-  },
-  {
-    "file": "figura_7.png",
-    "title": "Impacto de textline_orientation en CER",
-    "index": 7
-  },
-  {
-    "file": "figura_8.png",
-    "title": "Comparación Baseline vs Optimizado (24 páginas)",
-    "index": 8
-  },
-  {
-    "file": "figura_9.png",
-    "title": "Estructura del repositorio del proyecto",
-    "index": 9
-  }
-]