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

Chapter extension

Browse Source
This commit is contained in:
Sergio Jimenez Jimenez
2025-12-16 08:38:34 +01:00
parent 57df34ac5a
commit 551a9c9034
9 changed files with 1315 additions and 354 deletions
Download Patch File Download Diff File Expand all files Collapse all files

99
docs/01_introduccion.md
View File

@@ -4,36 +4,111 @@ Este capítulo presenta la motivación del trabajo, identificando el problema a
## 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. 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. 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 procesamiento de documentos en español presenta particularidades que complican el reconocimiento automático de texto. Los caracteres especiales (ñ, acentos), las variaciones tipográficas en documentos académicos y administrativos, y la presencia de elementos gráficos como tablas, encabezados y marcas de agua generan errores que pueden propagarse en aplicaciones downstream como la extracción de entidades nombradas o el análisis semántico.
### El contexto de la digitalización documental
Los modelos OCR basados en redes neuronales profundas, como los empleados en PaddleOCR, EasyOCR o DocTR, ofrecen un rendimiento impresionante en benchmarks estándar. No obstante, su adaptación a dominios específicos típicamente requiere fine-tuning con datos etiquetados del dominio objetivo y recursos computacionales significativos (GPUs de alta capacidad). Esta barrera técnica y económica excluye a muchos investigadores y organizaciones de beneficiarse plenamente de estas tecnologías.
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.
### 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.
La Tabla 1 resume los principales desafíos lingüísticos 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 |
*Tabla 1. Desafíos lingüísticos específicos del OCR en español. 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.
### 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.
La Tabla 2 ilustra los requisitos típicos para diferentes estrategias de mejora de 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** |
*Tabla 2. Comparación de estrategias de mejora de modelos OCR. Fuente: Elaboración propia.*
### 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.
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
El problema central que aborda este trabajo puede formularse de la siguiente manera:
> ¿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?
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:
1. **Selección de modelo base**: ¿Cuál de las soluciones OCR de código abierto disponibles (EasyOCR, PaddleOCR, DocTR) ofrece el mejor rendimiento base para documentos en español?
**PI1. Selección de modelo base**: ¿Cuál de las soluciones OCR de código abierto disponibles (EasyOCR, PaddleOCR, DocTR) ofrece el mejor rendimiento base para documentos en español?
2. **Impacto de hiperparámetros**: ¿Qué hiperparámetros del pipeline OCR tienen mayor influencia en las métricas de error (CER, WER)?
Esta pregunta es fundamental porque la elección del modelo base determinará el punto de partida para la optimización. Un modelo con mejor rendimiento inicial puede ofrecer mayor margen de mejora o, alternativamente, estar ya cerca de su límite de optimización.
3. **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?
**PI2. Impacto de hiperparámetros**: ¿Qué hiperparámetros del pipeline OCR tienen mayor influencia en las métricas de error (CER, WER)?
4. **Viabilidad práctica**: ¿Son los tiempos de inferencia y los recursos requeridos compatibles con un despliegue en entornos con recursos limitados?
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.
La relevancia de este problema radica en su aplicabilidad inmediata. Una metodología reproducible para optimizar OCR sin fine-tuning beneficiaría a:
**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?
- Investigadores que procesan grandes volúmenes de documentos académicos
- Instituciones educativas que digitalizan archivos históricos
- Pequeñas y medianas empresas que automatizan flujos documentales
- Desarrolladores que integran OCR en aplicaciones con restricciones de recursos
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.
**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:
| 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 |
*Tabla 3. Delimitación del alcance del trabajo. 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:
**Investigadores académicos**: Quienes procesan grandes volúmenes de documentos para análisis de contenido, revisiones sistemáticas de literatura, o estudios bibliométricos. Un OCR más preciso reduce el tiempo de corrección manual y mejora la calidad de los análisis downstream.
**Instituciones educativas**: Universidades y centros de investigación que digitalizan archivos históricos, actas administrativas, o materiales docentes. La preservación del patrimonio documental requiere transcripciones precisas.
**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

567
docs/02_contexto_estado_arte.md
View File

@@ -6,16 +6,58 @@ Este capítulo presenta el marco teórico y tecnológico en el que se desarrolla
### 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. La tecnología OCR ha evolucionado significativamente desde sus orígenes en la década de 1950:
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:
- **Primera generación (1950-1970)**: Sistemas basados en plantillas que requerían fuentes específicas.
- **Segunda generación (1970-1990)**: Introducción de técnicas de extracción de características y clasificadores estadísticos.
- **Tercera generación (1990-2010)**: Modelos basados en Redes Neuronales Artificiales y Modelos Ocultos de Markov (HMM).
- **Cuarta generación (2010-presente)**: Arquitecturas de aprendizaje profundo que dominan el estado del arte.
#### Primera Generación (1950-1970): Sistemas basados en plantillas
Los primeros sistemas OCR surgieron en la década de 1950 con el objetivo de automatizar la lectura de documentos bancarios y postales. Estos sistemas utilizaban técnicas de correspondencia de plantillas (*template matching*), donde cada carácter de entrada se comparaba píxel a píxel con un conjunto predefinido de plantillas (Mori et al., 1992).
Las principales limitaciones de esta generación incluían:
- Dependencia de fuentes tipográficas específicas (OCR-A, OCR-B)
- Incapacidad para manejar variaciones en tamaño, rotación o estilo
- Alto coste computacional para la época
- Sensibilidad extrema al ruido y degradación de la imagen
A pesar de sus limitaciones, estos sistemas sentaron las bases para el desarrollo posterior del campo y demostraron la viabilidad comercial del reconocimiento automático de texto.
#### Segunda Generación (1970-1990): Extracción de características
La segunda generación introdujo técnicas más sofisticadas basadas en la extracción de características geométricas y estructurales de los caracteres. En lugar de comparar imágenes completas, estos sistemas extraían propiedades como:
- Número y posición de trazos
- Proporciones geométricas (altura, anchura, relación de aspecto)
- Momentos estadísticos de la distribución de píxeles
- Características topológicas (bucles, intersecciones, terminaciones)
Los clasificadores estadísticos, como el análisis discriminante lineal y los k-vecinos más cercanos (k-NN), se utilizaban para asignar cada vector de características a una clase de carácter (Trier et al., 1996). Esta aproximación permitió mayor robustez frente a variaciones tipográficas, aunque seguía requiriendo un diseño manual cuidadoso de las características a extraer.
#### Tercera Generación (1990-2010): Redes neuronales y modelos probabilísticos
La tercera generación marcó la introducción de técnicas de aprendizaje automático más avanzadas. Los Modelos Ocultos de Markov (HMM) se convirtieron en el estándar para el reconocimiento de secuencias de caracteres, especialmente en el reconocimiento de escritura manuscrita (Plamondon & Srihari, 2000).
Las Redes Neuronales Artificiales (ANN) también ganaron popularidad en esta época, con arquitecturas como el Perceptrón Multicapa (MLP) demostrando capacidades superiores de generalización. El trabajo seminal de LeCun et al. (1998) con las redes convolucionales (CNN) para el reconocimiento de dígitos manuscritos (dataset MNIST) estableció los fundamentos para la siguiente revolución.
Las características de esta generación incluían:
- Aprendizaje automático de características discriminativas
- Modelado probabilístico de secuencias de caracteres
- Mayor robustez frente a ruido y degradación
- Capacidad de incorporar conocimiento lingüístico mediante modelos de lenguaje
#### Cuarta Generación (2010-presente): Aprendizaje profundo
La cuarta y actual generación está dominada por arquitecturas de aprendizaje profundo que han superado ampliamente el rendimiento de los métodos tradicionales. Los avances clave incluyen:
**Redes Convolucionales Profundas (Deep CNNs)**: Arquitecturas como VGGNet, ResNet e Inception permiten la extracción automática de características jerárquicas a múltiples escalas, eliminando la necesidad de diseño manual de características (Krizhevsky et al., 2012).
**Redes Recurrentes (RNN/LSTM)**: Las redes Long Short-Term Memory (LSTM) permiten modelar dependencias a largo plazo en secuencias de caracteres, siendo fundamentales para el reconocimiento de texto de longitud variable (Graves et al., 2009).
**Mecanismos de Atención y Transformers**: La arquitectura Transformer (Vaswani et al., 2017) y sus variantes han revolucionado el procesamiento de secuencias, permitiendo capturar relaciones globales sin las limitaciones de las RNN. Modelos como TrOCR (Li et al., 2023) representan el estado del arte actual.
**Connectionist Temporal Classification (CTC)**: La función de pérdida CTC (Graves et al., 2006) permite entrenar modelos de reconocimiento de secuencias sin necesidad de alineamiento carácter por carácter, simplificando enormemente el proceso de entrenamiento.
### Pipeline Moderno de OCR
Los sistemas OCR modernos siguen típicamente un pipeline de dos etapas:
Los sistemas OCR modernos siguen típicamente un pipeline de dos etapas principales, precedidas opcionalmente por una fase de preprocesamiento:
```mermaid
---
@@ -46,124 +88,401 @@ flowchart LR
style D fill:#c8e6c9
```
1. **Detección de texto (Text Detection)**: Localización de regiones que contienen texto en la imagen. Las arquitecturas más utilizadas incluyen:
- EAST (Efficient and Accurate Scene Text Detector)
- CRAFT (Character Region Awareness for Text Detection)
- DB (Differentiable Binarization)
#### Etapa de Preprocesamiento
2. **Reconocimiento de texto (Text Recognition)**: Transcripción del contenido textual de las regiones detectadas. Las arquitecturas predominantes son:
- CRNN (Convolutional Recurrent Neural Network) con CTC loss
- Arquitecturas encoder-decoder con atención
- Transformers (ViTSTR, TrOCR)
Antes de la detección, muchos sistemas aplican técnicas de preprocesamiento para mejorar la calidad de la imagen de entrada:
- **Binarización**: Conversión a imagen binaria (blanco/negro) mediante técnicas como Otsu o Sauvola
- **Corrección de inclinación (deskewing)**: Alineamiento horizontal del texto
- **Eliminación de ruido**: Filtros morfológicos y de suavizado
- **Normalización de contraste**: Mejora de la legibilidad mediante ecualización de histograma
#### Etapa 1: Detección de Texto (Text Detection)
La detección de texto tiene como objetivo localizar todas las regiones de una imagen que contienen texto. Esta tarea es particularmente desafiante debido a la variabilidad en:
- Tamaño y orientación del texto
- Fondos complejos y oclusiones parciales
- Texto curvo o deformado
- Múltiples idiomas y scripts en una misma imagen
Las arquitecturas más utilizadas para detección de texto incluyen:
**EAST (Efficient and Accurate Scene Text Detector)**: Propuesto por Zhou et al. (2017), EAST es un detector de una sola etapa que predice directamente cuadriláteros rotados o polígonos que encierran el texto. Su arquitectura FCN (Fully Convolutional Network) permite procesamiento eficiente de imágenes de alta resolución.
**CRAFT (Character Region Awareness for Text Detection)**: Desarrollado por Baek et al. (2019), CRAFT detecta regiones de caracteres individuales y las agrupa en palabras mediante el análisis de mapas de afinidad. Esta aproximación bottom-up es especialmente efectiva para texto con espaciado irregular.
**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 1.** *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 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:
**CRNN (Convolutional Recurrent Neural Network)**: Propuesta por Shi et al. (2016), CRNN combina una CNN para extracción de características visuales con una RNN bidireccional (típicamente LSTM) para modelado de secuencias, entrenada con pérdida CTC. Esta arquitectura estableció el paradigma encoder-decoder que domina el campo.
La arquitectura CRNN consta de tres componentes:
1. **Capas convolucionales**: Extraen características visuales de la imagen de entrada
2. **Capas recurrentes**: Modelan las dependencias secuenciales entre características
3. **Capa de transcripción**: Convierte las predicciones de la RNN en secuencias de caracteres mediante CTC
**SVTR (Scene-Text Visual Transformer Recognition)**: Desarrollado por Du et al. (2022), SVTR aplica la arquitectura Transformer al reconocimiento de texto, utilizando parches de imagen como tokens de entrada. Esta aproximación elimina la necesidad de RNN y permite capturar dependencias globales de manera más eficiente.
**Arquitecturas con Atención**: Los modelos encoder-decoder con mecanismos de atención (Bahdanau et al., 2015) permiten al decodificador "enfocarse" en diferentes partes de la imagen mientras genera cada carácter. Esto es especialmente útil para texto largo o con layouts complejos.
**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 2.** *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 a partir de Shi et al. (2016), Du et al. (2022), Li et al. (2023).*
### Métricas de Evaluación
Las métricas estándar para evaluar sistemas OCR son:
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.
**Character Error Rate (CER)**: Se calcula como CER = (S + D + I) / N, donde S = sustituciones, D = eliminaciones, I = inserciones, N = caracteres de referencia.
#### Distancia de Levenshtein
**Word Error Rate (WER)**: Se calcula de forma análoga pero a nivel de palabras en lugar de caracteres.
La distancia de Levenshtein (Levenshtein, 1966) entre dos cadenas es el número mínimo de operaciones de edición (inserción, eliminación, sustitución) necesarias para transformar una cadena en otra. Formalmente, para dos cadenas *a* y *b*:
Un CER del 1% significa que 1 de cada 100 caracteres es erróneo. Para aplicaciones críticas como extracción de datos financieros o médicos, se requieren CER inferiores al 1%.
$$d(a,b) = \min(\text{inserciones} + \text{eliminaciones} + \text{sustituciones})$$
Esta métrica es fundamental para calcular tanto CER como WER.
#### Character Error Rate (CER)
El CER mide el error a nivel de carácter y se calcula como:
$$CER = \frac{S + D + I}{N}$$
Donde:
- S = número de sustituciones de caracteres
- 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
#### Word Error Rate (WER)
El WER mide el error a nivel de palabra, utilizando la misma fórmula pero considerando palabras como unidades:
$$WER = \frac{S_w + D_w + I_w}{N_w}$$
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.
#### 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.
**BLEU Score**: Adaptado de traducción automática, mide la similitud entre el texto predicho y la referencia considerando n-gramas.
### Particularidades del OCR para el Idioma Español
El español presenta características específicas que impactan el OCR:
El español, como lengua romance, presenta características específicas que impactan el rendimiento de los sistemas OCR:
- **Caracteres especiales**: ñ, á, é, í, ó, ú, ü, ¿, ¡
- **Diacríticos**: Los acentos pueden confundirse con ruido o artefactos
- **Longitud de palabras**: Palabras generalmente más largas que en inglés
- **Puntuación**: Signos de interrogación y exclamación invertidos
#### Características Ortográficas
**Caracteres especiales**: El español incluye caracteres no presentes en el alfabeto inglés básico:
- La letra eñe (ñ, Ñ)
- Vocales acentuadas (á, é, í, ó, ú, Á, É, Í, Ó, Ú)
- Diéresis sobre u (ü, Ü)
- Signos de puntuación invertidos (¿, ¡)
Estos caracteres requieren que los modelos OCR incluyan dichos símbolos en su vocabulario de salida y que el entrenamiento incluya suficientes ejemplos de cada uno.
**Diacríticos y acentos**: Los acentos gráficos del español son elementos pequeños que pueden confundirse fácilmente con ruido, artefactos de imagen o signos de puntuación. La distinción entre vocales acentuadas y no acentuadas es crucial para el significado (e.g., "él" vs "el", "más" vs "mas").
#### Características Lingüísticas
**Longitud de palabras**: Las palabras en español tienden a ser más largas que en inglés debido a la morfología flexiva rica (conjugaciones verbales, géneros, plurales). Esto puede aumentar la probabilidad de error acumulativo.
**Vocabulario**: El español tiene un vocabulario amplio con muchas variantes morfológicas de cada raíz. Los modelos de lenguaje utilizados para post-corrección deben contemplar esta diversidad.
#### Recursos y Datasets
Los recursos disponibles para OCR en español son significativamente menores que para inglés o chino:
- Menor cantidad de datasets etiquetados de gran escala
- Menos modelos preentrenados específicos para español
- Documentación y tutoriales predominantemente en inglés
Esta escasez de recursos específicos para español motiva la necesidad de técnicas de adaptación como la optimización de hiperparámetros explorada en este trabajo.
## Estado del arte
### Soluciones OCR de Código Abierto
En los últimos años han surgido varias soluciones OCR de código abierto que democratizan el acceso a esta tecnología. A continuación se analizan en detalle las tres principales alternativas evaluadas en este trabajo.
#### EasyOCR
EasyOCR es una biblioteca de OCR desarrollada por Jaided AI (2020) que soporta más de 80 idiomas. Sus características principales incluyen:
EasyOCR es una biblioteca de OCR desarrollada por Jaided AI (2020) con el objetivo de proporcionar una solución de fácil uso que soporte múltiples idiomas. Actualmente soporta más de 80 idiomas, incluyendo español.
- **Arquitectura**: Detector CRAFT + Reconocedor CRNN/Transformer
- **Fortalezas**: Facilidad de uso, soporte multilingüe amplio, bajo consumo de memoria
- **Limitaciones**: Menor precisión en documentos complejos, opciones de configuración limitadas
- **Caso de uso ideal**: Prototipado rápido y aplicaciones con restricciones de memoria
**Arquitectura técnica**:
- **Detector**: CRAFT (Character Region Awareness for Text Detection)
- **Reconocedor**: CRNN con backbone ResNet/VGG + BiLSTM + CTC
- **Modelos preentrenados**: Disponibles para descarga automática
**Características principales**:
- API simple de una línea para casos de uso básicos
- Soporte para GPU (CUDA) y CPU
- Reconocimiento de múltiples idiomas en una misma imagen
- Bajo consumo de memoria comparado con otras soluciones
**Limitaciones identificadas**:
- Opciones de configuración limitadas (pocos hiperparámetros ajustables)
- Menor precisión en documentos con layouts complejos
- Actualizaciones menos frecuentes que otras alternativas
- Documentación menos exhaustiva
**Caso de uso ideal**: Prototipado rápido, aplicaciones con restricciones de memoria, proyectos que requieren soporte multilingüe inmediato.
#### PaddleOCR
PaddleOCR es el sistema OCR desarrollado por Baidu como parte del ecosistema PaddlePaddle (2024). La versión PP-OCRv5, utilizada en este trabajo, representa el estado del arte en OCR industrial:
PaddleOCR es el sistema OCR desarrollado por Baidu como parte del ecosistema PaddlePaddle (2024). Representa una de las soluciones más completas y activamente mantenidas en el ecosistema de código abierto. La versión PP-OCRv5, utilizada en este trabajo, incorpora los últimos avances en el campo.
- **Arquitectura**:
- Detector: DB (Differentiable Binarization) con backbone ResNet (Liao et al., 2020)
- Reconocedor: SVTR (Scene-Text Visual Transformer Recognition)
- Clasificador de orientación opcional
**Arquitectura técnica**:
- **Hiperparámetros configurables**:
El pipeline de PaddleOCR consta de tres módulos principales:
**Tabla 1.** *Hiperparámetros configurables de PaddleOCR.*
1. **Detector de texto (DB - Differentiable Binarization)**:
- Backbone: ResNet18/ResNet50
- Neck: FPN (Feature Pyramid Network)
- Head: Segmentación con binarización diferenciable
- Salida: Polígonos que encierran regiones de texto
| Parámetro | Descripción | Valor por defecto |
|-----------|-------------|-------------------|
| `text_det_thresh` | Umbral de detección de píxeles | 0.3 |
| `text_det_box_thresh` | Umbral de caja de detección | 0.6 |
| `text_det_unclip_ratio` | Coeficiente de expansión | 1.5 |
| `text_rec_score_thresh` | Umbral de confianza de reconocimiento | 0.5 |
| `use_textline_orientation` | Clasificación de orientación | False |
| `use_doc_orientation_classify` | Clasificación de orientación de documento | False |
| `use_doc_unwarping` | Corrección de deformación | False |
2. **Clasificador de orientación**:
- Determina si el texto está rotado 0° o 180°
- Permite corrección automática de texto invertido
- Opcional pero recomendado para documentos escaneados
3. **Reconocedor de texto (SVTR)**:
- Encoder: Vision Transformer modificado
- Decoder: CTC o Attention-based
- Vocabulario: Configurable por idioma
**Hiperparámetros configurables**:
PaddleOCR expone numerosos hiperparámetros que permiten ajustar el comportamiento del sistema. Los más relevantes para este trabajo son:
**Tabla 3.** *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: Documentación oficial de PaddleOCR (PaddlePaddle, 2024).*
- **Fortalezas**: Alta precisión, pipeline altamente configurable, modelos específicos para servidor
- **Limitaciones**: Mayor complejidad de configuración, dependencia del framework PaddlePaddle
**Tabla 4.** *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: Documentación oficial de PaddleOCR (PaddlePaddle, 2024).*
**Tabla 5.** *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: Documentación oficial de PaddleOCR (PaddlePaddle, 2024).*
**Fortalezas de PaddleOCR**:
- Alta precisión en múltiples benchmarks
- Pipeline altamente configurable
- Modelos optimizados para servidor (mayor precisión) y móvil (mayor velocidad)
- Documentación exhaustiva (aunque principalmente en chino)
- Comunidad activa y actualizaciones frecuentes
- Soporte para entrenamiento personalizado (fine-tuning)
**Limitaciones**:
- Dependencia del framework PaddlePaddle (menos popular que PyTorch/TensorFlow)
- Curva de aprendizaje más pronunciada
- Documentación en inglés menos completa que en chino
#### DocTR
DocTR (Document Text Recognition) es una biblioteca desarrollada por Mindee (2021) orientada a la investigación:
DocTR (Document Text Recognition) es una biblioteca desarrollada por Mindee (2021), empresa especializada en procesamiento inteligente de documentos. Está orientada a la comunidad de investigación y ofrece una API limpia basada en TensorFlow/PyTorch.
- **Arquitectura**:
- Detectores: DB, LinkNet
- Reconocedores: CRNN, SAR, ViTSTR
**Arquitectura técnica**:
- **Detectores disponibles**: DB (db_resnet50), LinkNet (linknet_resnet18)
- **Reconocedores disponibles**: CRNN (crnn_vgg16_bn), SAR (sar_resnet31), ViTSTR (vitstr_small)
- **Framework**: TensorFlow 2.x o PyTorch
- **Fortalezas**: API limpia, orientación académica, salida estructurada de alto nivel
- **Limitaciones**: Menor rendimiento en español comparado con PaddleOCR
**Características principales**:
- API Pythonic bien diseñada
- Salida estructurada con información de confianza y geometría
- Integración nativa con Hugging Face Hub
- Documentación orientada a investigación
#### Comparativa de Arquitecturas
**Limitaciones identificadas**:
- Menor rendimiento en español comparado con PaddleOCR según pruebas preliminares
- Comunidad más pequeña
- Menos opciones de modelos preentrenados para idiomas no ingleses
**Tabla 2.** *Comparativa de soluciones OCR de código abierto.*
#### Comparativa Detallada de Soluciones
| 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, configurable |
| **DocTR** | End-to-end (det + rec) | DB/LinkNet + CRNN/SAR/ViTSTR | Orientado a investigación, API limpia |
**Tabla 6.** *Comparativa técnica de soluciones OCR de código abierto.*
*Fuente: Documentación oficial de cada herramienta (JaidedAI, 2020; PaddlePaddle, 2024; Mindee, 2021).*
| 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 a partir de documentación oficial (2024).*
**Tabla 7.** *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.*
### Optimización de Hiperparámetros
#### Fundamentos
#### Fundamentos Teóricos
La optimización de hiperparámetros (HPO) busca encontrar la configuración de parámetros que maximiza (o minimiza) una métrica objetivo (Feurer & Hutter, 2019). A diferencia de los parámetros del modelo (pesos), los hiperparámetros no se aprenden durante el entrenamiento.
La optimización de hiperparámetros (HPO, *Hyperparameter Optimization*) es el proceso de encontrar la configuración óptima de los parámetros que controlan el proceso de aprendizaje o inferencia de un modelo, pero que no se aprenden directamente de los datos (Feurer & Hutter, 2019).
Los métodos de HPO incluyen:
- **Grid Search**: Búsqueda exhaustiva en una rejilla predefinida
- **Random Search**: Muestreo aleatorio del espacio de búsqueda (Bergstra & Bengio, 2012)
- **Bayesian Optimization**: Modelado probabilístico de la función objetivo (Bergstra et al., 2011)
- **Algoritmos evolutivos**: Optimización inspirada en evolución biológica
A diferencia de los parámetros del modelo (como los pesos de una red neuronal), los hiperparámetros se establecen antes del entrenamiento e incluyen:
- Tasa de aprendizaje, tamaño de batch, número de épocas
- Arquitectura del modelo (número de capas, unidades por capa)
- Parámetros de regularización (dropout, weight decay)
- **Umbrales de decisión en tiempo de inferencia** (relevante para este trabajo)
#### Ray Tune y Optuna
El problema de HPO puede formalizarse como:
**Ray Tune** es un framework de optimización de hiperparámetros escalable (Liaw et al., 2018) que permite:
- Ejecución paralela de experimentos
- Early stopping de configuraciones poco prometedoras
- Integración con múltiples algoritmos de búsqueda
$$\lambda^* = \arg\min_{\lambda \in \Lambda} \mathcal{L}(M_\lambda, D_{val})$$
**Optuna** es una biblioteca de optimización bayesiana (Akiba et al., 2019) que implementa:
- Tree-structured Parzen Estimator (TPE)
- Pruning de trials no prometedores
- Visualización de resultados
Donde:
- $\lambda$ es un vector de hiperparámetros
- $\Lambda$ es el espacio de búsqueda
- $M_\lambda$ es el modelo configurado con $\lambda$
- $\mathcal{L}$ es la función de pérdida
- $D_{val}$ es el conjunto de validación
La combinación Ray Tune + Optuna permite búsquedas eficientes en espacios de alta dimensionalidad.
#### Métodos de Optimización
**Grid Search (Búsqueda en rejilla)**:
El método más simple consiste en evaluar todas las combinaciones posibles de valores discretizados de los hiperparámetros. Para $k$ hiperparámetros con $n$ valores cada uno, requiere $n^k$ evaluaciones.
Ventajas:
- Exhaustivo y reproducible
- Fácil de paralelizar
- Garantiza encontrar el óptimo dentro de la rejilla
Desventajas:
- Coste exponencial con el número de hiperparámetros
- Ineficiente si algunos hiperparámetros son más importantes que otros
- No aprovecha información de evaluaciones previas
**Random Search (Búsqueda aleatoria)**:
Propuesto por Bergstra & Bengio (2012), Random Search muestrea configuraciones aleatoriamente del espacio de búsqueda. Sorprendentemente, supera a Grid Search en muchos escenarios prácticos.
La intuición es que, cuando solo algunos hiperparámetros son importantes, Random Search explora más valores de estos parámetros críticos mientras Grid Search desperdicia evaluaciones variando parámetros irrelevantes.
**Optimización Bayesiana**:
La optimización bayesiana modela la función objetivo mediante un modelo probabilístico sustituto (*surrogate model*) y utiliza una función de adquisición para decidir qué configuración evaluar a continuación (Bergstra et al., 2011).
El proceso iterativo es:
1. Ajustar el modelo sustituto a las observaciones actuales
2. Optimizar la función de adquisición para seleccionar el siguiente punto
3. Evaluar la función objetivo en el punto seleccionado
4. Actualizar las observaciones y repetir
Los modelos sustitutos más comunes son:
- **Procesos Gaussianos (GP)**: Proporcionan incertidumbre bien calibrada pero escalan pobremente
- **Random Forests**: Manejan bien espacios de alta dimensión y variables categóricas
- **Tree-structured Parzen Estimator (TPE)**: Modela densidades en lugar de la función objetivo
#### Tree-structured Parzen Estimator (TPE)
TPE, propuesto por Bergstra et al. (2011) e implementado en Optuna, es particularmente efectivo para HPO. En lugar de modelar $p(y|\lambda)$ directamente, TPE modela:
$$p(\lambda|y) = \begin{cases} l(\lambda) & \text{si } y < y^* \\ g(\lambda) & \text{si } y \geq y^* \end{cases}$$
Donde $y^*$ es un umbral (típicamente el percentil 15-25 de las observaciones), $l(\lambda)$ es la densidad de hiperparámetros con buen rendimiento, y $g(\lambda)$ es la densidad de hiperparámetros con mal rendimiento.
La función de adquisición Expected Improvement se aproxima como:
$$EI(\lambda) \propto \frac{l(\lambda)}{g(\lambda)}$$
Configuraciones con alta probabilidad bajo $l$ y baja probabilidad bajo $g$ tienen mayor Expected Improvement.
**Ventajas de TPE**:
- Maneja naturalmente espacios condicionales (hiperparámetros que dependen de otros)
- Eficiente para espacios de alta dimensión
- No requiere derivadas de la función objetivo
- Implementación eficiente en Optuna
#### Ray Tune
Ray Tune (Liaw et al., 2018) es un framework de optimización de hiperparámetros escalable construido sobre Ray, un sistema de computación distribuida. Sus características principales incluyen:
**Escalabilidad**:
- Ejecución paralela de múltiples trials
- Distribución automática en clusters
- Soporte para recursos heterogéneos (CPU/GPU)
**Flexibilidad**:
- Integración con múltiples algoritmos de búsqueda (Optuna, HyperOpt, Ax, etc.)
- Schedulers avanzados (ASHA, PBT, BOHB)
- Checkpointing y recuperación de fallos
**Early Stopping**:
- ASHA (Asynchronous Successive Halving Algorithm): Termina trials poco prometedores
- PBT (Population-Based Training): Evoluciona hiperparámetros durante el entrenamiento
**Integración con Optuna**:
La combinación de Ray Tune con OptunaSearch permite:
1. Utilizar TPE como algoritmo de búsqueda
2. Paralelizar la evaluación de trials
3. Beneficiarse de la infraestructura de Ray para distribución
4. Acceder a las visualizaciones de Optuna
```mermaid
---
@@ -180,39 +499,97 @@ flowchart LR
#### HPO en Sistemas OCR
La aplicación de HPO a sistemas OCR ha sido explorada principalmente en el contexto de:
La aplicación de HPO a sistemas OCR ha sido explorada en varios contextos:
1. **Preprocesamiento de imagen**: Optimización de parámetros de binarización, filtrado y escalado (Liang et al., 2005)
**Optimización de preprocesamiento**:
2. **Arquitecturas de detección**: Ajuste de umbrales de confianza y NMS (Non-Maximum Suppression)
Liang et al. (2005) propusieron optimizar parámetros de binarización adaptativa para mejorar el OCR de documentos degradados. Los parámetros optimizados incluían tamaño de ventana, factor de corrección y umbral local.
3. **Post-procesamiento**: Optimización de corrección ortográfica y modelos de lenguaje
**Optimización de arquitectura**:
Sin embargo, existe un vacío en la literatura respecto a la optimización sistemática de los hiperparámetros de inferencia en pipelines OCR modernos como PaddleOCR, especialmente para idiomas diferentes del inglés y chino.
Breuel (2013) exploró la selección automática de arquitecturas de red para reconocimiento de texto manuscrito, optimizando número de capas, unidades y tipo de activación.
**Optimización de post-procesamiento**:
Schulz & Kuhn (2017) optimizaron parámetros de modelos de lenguaje para corrección de errores OCR, incluyendo pesos de interpolación entre modelos de caracteres y palabras.
**Vacío en la literatura**:
A pesar de estos trabajos, existe un vacío significativo respecto a la optimización sistemática de hiperparámetros de inferencia en pipelines OCR modernos como PaddleOCR. La mayoría de trabajos se centran en:
- Entrenamiento de modelos (fine-tuning)
- Preprocesamiento de imagen
- Post-procesamiento lingüístico
La optimización de umbrales de detección y reconocimiento en tiempo de inferencia ha recibido poca atención, especialmente para idiomas diferentes del inglés y chino.
### Datasets y Benchmarks para Español
#### Datasets Públicos
Los principales recursos para evaluación de OCR en español incluyen:
- **FUNSD-ES**: Versión en español del dataset de formularios
- **MLT (ICDAR)**: Multi-Language Text dataset con muestras en español
- **Documentos académicos**: Utilizados en este trabajo (instrucciones TFE de UNIR)
**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.
**XFUND**: Dataset de comprensión de formularios en múltiples idiomas, incluyendo español, con anotaciones de entidades y relaciones.
**Tabla 8.** *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 a partir de repositorios oficiales.*
#### Limitaciones de Recursos para Español
Comparado con inglés y chino, el español cuenta con:
- Menor cantidad de datasets etiquetados de gran escala
- Menos benchmarks estandarizados
- Menor representación en competiciones internacionales (ICDAR)
- Pocos modelos preentrenados específicos
Esta escasez de recursos específicos para español motivó la creación de un dataset propio basado en documentos académicos de UNIR para este trabajo.
#### Trabajos Previos en OCR para Español
Los trabajos previos en OCR para español se han centrado principalmente en:
1. Digitalización de archivos históricos (manuscritos coloniales)
2. Procesamiento de documentos de identidad
3. Reconocimiento de texto en escenas naturales
**Digitalización de archivos históricos**: Múltiples proyectos han abordado el reconocimiento de manuscritos coloniales y documentos históricos en español, utilizando técnicas de HTR (Handwritten Text Recognition) adaptadas (Romero et al., 2013).
La optimización de hiperparámetros para documentos académicos en español representa una contribución original de este trabajo.
**Procesamiento de documentos de identidad**: Sistemas OCR especializados para DNI, pasaportes y documentos oficiales españoles y latinoamericanos (Bulatov et al., 2020).
**Reconocimiento de texto en escenas**: Participaciones en competiciones ICDAR para detección y reconocimiento de texto en español en imágenes naturales.
**Tabla 9.** *Trabajos previos relevantes en OCR para español.*
| Trabajo | Enfoque | Contribución |
|---------|---------|--------------|
| Romero et al. (2013) | HTR histórico | Modelos HMM para manuscritos |
| Bulatov et al. (2020) | Documentos ID | Pipeline especializado |
| Fischer et al. (2012) | Multilingual | Transferencia entre idiomas |
*Fuente: Elaboración propia.*
La optimización de hiperparámetros para documentos académicos en español representa una contribución original de este trabajo, abordando un nicho no explorado en la literatura.
## Conclusiones del capítulo
Este capítulo ha presentado:
Este capítulo ha presentado el marco teórico y tecnológico necesario para contextualizar la contribución del presente trabajo:
1. Los fundamentos del OCR moderno y su pipeline de detección-reconocimiento
2. Las tres principales soluciones de código abierto: EasyOCR, PaddleOCR y DocTR
3. Los métodos de optimización de hiperparámetros, con énfasis en Ray Tune y Optuna
4. Las particularidades del OCR para el idioma español
1. **Evolución del OCR**: Se ha trazado la evolución desde los sistemas de plantillas hasta las arquitecturas de aprendizaje profundo actuales, destacando los avances clave en cada generación.
El estado del arte revela que, si bien existen soluciones OCR de alta calidad, su optimización para dominios específicos mediante ajuste de hiperparámetros (sin fine-tuning) ha recibido poca atención. Este trabajo contribuye a llenar ese vacío proponiendo una metodología reproducible para la optimización de PaddleOCR en documentos académicos en español.
2. **Pipeline moderno**: Se ha descrito el pipeline de dos etapas (detección + reconocimiento) utilizado por los sistemas OCR contemporáneos, detallando las arquitecturas más relevantes (DB, CRAFT, CRNN, SVTR, Transformer).
3. **Métricas de evaluación**: Se han definido formalmente las métricas CER y WER, estableciendo los umbrales de aceptabilidad para diferentes aplicaciones.
4. **Particularidades del español**: Se han identificado los desafíos específicos del OCR para español, incluyendo caracteres especiales, diacríticos y escasez de recursos.
5. **Soluciones de código abierto**: Se han analizado en profundidad EasyOCR, PaddleOCR y DocTR, justificando la selección de PaddleOCR para este trabajo por su alta configurabilidad.
6. **Optimización de hiperparámetros**: Se han presentado los fundamentos teóricos de HPO, con énfasis en TPE (Optuna) y Ray Tune, identificando el vacío en la literatura respecto a la optimización de hiperparámetros de inferencia en OCR.
El estado del arte revela que, si bien existen soluciones OCR de alta calidad, su optimización para dominios específicos mediante ajuste de hiperparámetros (sin fine-tuning) ha recibido poca atención en la literatura. Este trabajo contribuye a llenar ese vacío proponiendo una metodología reproducible para la optimización de PaddleOCR en documentos académicos en español.

992
docs/04_desarrollo_especifico.md
View File

File diff suppressed because it is too large Load Diff