diff --git a/apply_content.py b/apply_content.py index 2f9b9f4..0052b35 100644 --- a/apply_content.py +++ b/apply_content.py @@ -4,23 +4,25 @@ import re import os import shutil -from bs4 import BeautifulSoup, NavigableString -from latex2mathml.converter import convert as latex_to_mathml -from PIL import Image - -BASE_DIR = os.path.dirname(os.path.abspath(__file__)) -TEMPLATE_INPUT = os.path.join(BASE_DIR, 'instructions/plantilla_individual.htm') -TEMPLATE_OUTPUT = os.path.join(BASE_DIR, 'thesis_output/plantilla_individual.htm') -DOCS_DIR = os.path.join(BASE_DIR, 'docs') - -# Accept Fuente/Source lines with or without markdown bold -SOURCE_LINE_RE = re.compile(r'^\s*(?:\*{1,2})?(Fuente|Source):(?:\*{1,2})?\s*(.*)$', re.IGNORECASE) - -# Global counters for tables and figures -table_counter = 0 -figure_counter = 0 -anexo_table_counter = 0 -anexo_figure_counter = 0 +from bs4 import BeautifulSoup, NavigableString +from latex2mathml.converter import convert as latex_to_mathml +from PIL import Image + +BASE_DIR = os.path.dirname(os.path.abspath(__file__)) +TEMPLATE_INPUT = os.path.join(BASE_DIR, 'instructions/plantilla_individual.htm') +TEMPLATE_OUTPUT = os.path.join(BASE_DIR, 'thesis_output/plantilla_individual.htm') +DOCS_DIR = os.path.join(BASE_DIR, 'docs') + +# Accept Fuente/Source lines with or without markdown bold +SOURCE_LINE_RE = re.compile(r'^\s*(?:\*{1,2})?(Fuente|Source):(?:\*{1,2})?\s*(.*)$', re.IGNORECASE) +# Accept Leyenda lines with or without markdown bold +LEYENDA_LINE_RE = re.compile(r'^\s*(?:\*{1,2})?Leyenda:(?:\*{1,2})?\s*(.*)$', re.IGNORECASE) + +# Global counters for tables and figures +table_counter = 0 +figure_counter = 0 +anexo_table_counter = 0 +anexo_figure_counter = 0 # Global sequential counter for figure filenames (figura_1.png, figura_2.png, etc.) global_figure_index = 0 @@ -48,7 +50,7 @@ def md_to_html_para(text): text = re.sub(r'\[([^\]]+)\]\(([^)]+)\)', r'\1', text) return text -def convert_latex_formulas(text): +def convert_latex_formulas(text): """Convert LaTeX formulas to MathML for Word compatibility.""" # Block formulas $$...$$ def convert_block(match): @@ -69,22 +71,33 @@ def convert_latex_formulas(text): except: return match.group(0) - text = re.sub(r'\$([^$]+)\$', convert_inline, text) - return text - -def extract_source_from_line(line): - """Return source text if line is a Fuente/Source line, otherwise None.""" - match = SOURCE_LINE_RE.match(line.strip()) - if not match: - return None - return match.group(2).strip() - -def is_source_line(line): - """Check whether a line starts with Fuente:/Source: (optionally bold).""" - return SOURCE_LINE_RE.match(line.strip()) is not None - -def extract_table_title(lines, current_index): - """Look for table title in preceding lines (e.g., **Tabla 1.** *Title*).""" + text = re.sub(r'\$([^$]+)\$', convert_inline, text) + return text + +def extract_source_from_line(line): + """Return source text if line is a Fuente/Source line, otherwise None.""" + match = SOURCE_LINE_RE.match(line.strip()) + if not match: + return None + return match.group(2).strip() + +def is_source_line(line): + """Check whether a line starts with Fuente:/Source: (optionally bold).""" + return SOURCE_LINE_RE.match(line.strip()) is not None + +def extract_leyenda_from_line(line): + """Return leyenda text if line is a Leyenda line, otherwise None.""" + match = LEYENDA_LINE_RE.match(line.strip()) + if not match: + return None + return match.group(1).strip() + +def is_leyenda_line(line): + """Check whether a line starts with Leyenda: (optionally bold).""" + return LEYENDA_LINE_RE.match(line.strip()) is not None + +def extract_table_title(lines, current_index): + """Look for table title in preceding lines (e.g., **Tabla 1.** *Title*).""" # Check previous non-empty lines for table title for i in range(current_index - 1, max(0, current_index - 5), -1): line = lines[i].strip() @@ -172,8 +185,11 @@ def parse_md_to_html_blocks(md_content, is_anexo=False): bookmark_id = f"_Ref_Fig{fig_num}" # mso-pagination:keep-with-next ensures caption stays with figure image (correct MSO property) # For Anexo figures, use static text (no SEQ field) to prevent Word from overwriting A1, A2... + # Add TC field so Anexo figures appear in Table of Figures index + # Use \f c to match the TOC field identifier in the template if is_anexo: - html_blocks.append(f'''

Figura {fig_num}. {fig_title}

''') + tc_field = f'''''' + html_blocks.append(f'''{tc_field}

Figura {fig_num}. {fig_title}

''') else: html_blocks.append(f'''

Figura {fig_num}. {fig_title}

''') @@ -204,19 +220,27 @@ def parse_md_to_html_blocks(md_content, is_anexo=False): # Check if next non-empty line has custom Fuente custom_source = None + fig_leyenda = None lookahead = i + 1 while lookahead < len(lines) and not lines[lookahead].strip(): lookahead += 1 - if lookahead < len(lines): - next_line = lines[lookahead].strip() - if is_source_line(next_line): - # Extract custom source, removing markdown formatting - custom_source = extract_source_from_line(next_line) - # Ensure it ends with a period - if custom_source and not custom_source.endswith('.'): - custom_source += '.' - # Skip this line by advancing i past it - i = lookahead + if lookahead < len(lines): + next_line = lines[lookahead].strip() + if is_source_line(next_line): + # Extract custom source, removing markdown formatting + custom_source = extract_source_from_line(next_line) + # Ensure it ends with a period + if custom_source and not custom_source.endswith('.'): + custom_source += '.' + # Skip this line by advancing i past it + i = lookahead + # Check for Leyenda after source + leyenda_idx = i + 1 + while leyenda_idx < len(lines) and not lines[leyenda_idx].strip(): + leyenda_idx += 1 + if leyenda_idx < len(lines) and is_leyenda_line(lines[leyenda_idx]): + fig_leyenda = extract_leyenda_from_line(lines[leyenda_idx]) + i = leyenda_idx if custom_source: source_html = md_to_html_para(custom_source) @@ -224,6 +248,13 @@ def parse_md_to_html_blocks(md_content, is_anexo=False): else: html_blocks.append(f'''

Fuente: Elaboración propia.

''') + # Add leyenda if present (same style as Fuente, new line) + if fig_leyenda: + leyenda_html = md_to_html_para(fig_leyenda) + if not fig_leyenda.endswith('.'): + leyenda_html += '.' + html_blocks.append(f'''

Leyenda: {leyenda_html}

''') + html_blocks.append('

 

') i += 1 continue @@ -249,7 +280,7 @@ def parse_md_to_html_blocks(md_content, is_anexo=False): if line.startswith('####'): text = line.lstrip('#').strip() # Apply consistent styling like h2/h3, disable numbering for h4 - html_blocks.append(f'

{text}

') + html_blocks.append(f'

{text}

') i += 1 continue elif line.startswith('###'): @@ -314,11 +345,19 @@ def parse_md_to_html_blocks(md_content, is_anexo=False): # Look ahead for source (skip blank lines first) source_idx = i - while source_idx < len(lines) and not lines[source_idx].strip(): - source_idx += 1 - if source_idx < len(lines) and is_source_line(lines[source_idx]): - table_source = extract_source_from_line(lines[source_idx]) - i = source_idx + 1 + table_leyenda = None + while source_idx < len(lines) and not lines[source_idx].strip(): + source_idx += 1 + if source_idx < len(lines) and is_source_line(lines[source_idx]): + table_source = extract_source_from_line(lines[source_idx]) + i = source_idx + 1 + # Check for Leyenda after source (skip blank lines) + leyenda_idx = i + while leyenda_idx < len(lines) and not lines[leyenda_idx].strip(): + leyenda_idx += 1 + if leyenda_idx < len(lines) and is_leyenda_line(lines[leyenda_idx]): + table_leyenda = extract_leyenda_from_line(lines[leyenda_idx]) + i = leyenda_idx + 1 # Add table title with MsoCaption class and proper Word SEQ field for cross-reference # Format: "Tabla X." in bold, title in italic (per UNIR guidelines) @@ -334,8 +373,11 @@ def parse_md_to_html_blocks(md_content, is_anexo=False): clean_title = "Tabla de datos." # mso-pagination:keep-with-next ensures caption stays with table (correct MSO property) # For Anexo tables, use static text (no SEQ field) to prevent Word from overwriting A1, A2... + # Add TC field so Anexo tables appear in Table of Tables index + # Use \f t identifier - template TOC field will be modified to include this if is_anexo: - html_blocks.append(f'''

Tabla {table_num}. {clean_title}

''') + tc_field = f'''''' + html_blocks.append(f'''{tc_field}

Tabla {table_num}. {clean_title}

''') else: html_blocks.append(f'''

Tabla {table_num}. {clean_title}

''') @@ -363,6 +405,14 @@ def parse_md_to_html_blocks(md_content, is_anexo=False): if not table_source.endswith('.'): source_html += '.' html_blocks.append(f'

Fuente: {source_html}

') + + # Add leyenda if present (same style as Fuente, new line) + if table_leyenda: + leyenda_html = md_to_html_para(table_leyenda) + if not table_leyenda.endswith('.'): + leyenda_html += '.' + html_blocks.append(f'

Leyenda: {leyenda_html}

') + html_blocks.append('

 

') continue @@ -376,24 +426,63 @@ def parse_md_to_html_blocks(md_content, is_anexo=False): html_blocks.append(f'

{md_to_html_para(quote_text)}

') continue - # Bullet list + # Bullet list (handle blank lines between items) if re.match(r'^[\-\*\+]\s', line): - while i < len(lines) and re.match(r'^[\-\*\+]\s', lines[i]): - item_text = lines[i][2:].strip() - item_text = convert_latex_formulas(item_text) - html_blocks.append(f'

·     {md_to_html_para(item_text)}

') - i += 1 + # Collect all bullet items first + bullet_items = [] + while i < len(lines): + # Skip blank lines + while i < len(lines) and not lines[i].strip(): + i += 1 + # Check if next non-blank line is a bullet item + if i < len(lines) and re.match(r'^[\-\*\+]\s', lines[i]): + item_text = lines[i][2:].strip() + item_text = convert_latex_formulas(item_text) + bullet_items.append(md_to_html_para(item_text)) + i += 1 + else: + break + # Output with proper First/Middle/Last classes + for idx, item in enumerate(bullet_items): + if len(bullet_items) == 1: + cls = 'MsoListParagraph' + elif idx == 0: + cls = 'MsoListParagraphCxSpFirst' + elif idx == len(bullet_items) - 1: + cls = 'MsoListParagraphCxSpLast' + else: + cls = 'MsoListParagraphCxSpMiddle' + html_blocks.append(f'

·     {item}

') continue - # Numbered list + # Numbered list (handle blank lines between items) if re.match(r'^\d+\.\s', line): - num = 1 - while i < len(lines) and re.match(r'^\d+\.\s', lines[i]): - item_text = re.sub(r'^\d+\.\s*', '', lines[i]).strip() - item_text = convert_latex_formulas(item_text) - html_blocks.append(f'

{num}.   {md_to_html_para(item_text)}

') - num += 1 - i += 1 + # Collect all numbered items first + numbered_items = [] + while i < len(lines): + # Skip blank lines + while i < len(lines) and not lines[i].strip(): + i += 1 + # Check if next non-blank line is a numbered item + if i < len(lines) and re.match(r'^\d+\.\s', lines[i]): + item_text = re.sub(r'^\d+\.\s*', '', lines[i]).strip() + item_text = convert_latex_formulas(item_text) + numbered_items.append(md_to_html_para(item_text)) + i += 1 + else: + break + # Output with proper First/Middle/Last classes + for idx, item in enumerate(numbered_items): + num = idx + 1 + if len(numbered_items) == 1: + cls = 'MsoListParagraph' + elif idx == 0: + cls = 'MsoListParagraphCxSpFirst' + elif idx == len(numbered_items) - 1: + cls = 'MsoListParagraphCxSpLast' + else: + cls = 'MsoListParagraphCxSpMiddle' + html_blocks.append(f'

{num}.   {item}

') continue # Skip lines that are just table/figure titles (they'll be handled with the table/figure) @@ -403,9 +492,12 @@ def parse_md_to_html_blocks(md_content, is_anexo=False): if line.strip().startswith('**Figura') or line.strip().startswith('*Figura'): i += 1 continue - if is_source_line(line): - i += 1 - continue + if is_source_line(line): + i += 1 + continue + if is_leyenda_line(line): + i += 1 + continue # Regular paragraph para_lines = [line] @@ -523,6 +615,17 @@ def main(): print("Reading template...") html_content = read_file(TEMPLATE_INPUT) + + # Modify the Table of Tables TOC field to include TC entries with \f t identifier + # Original: TOC \h \z \t "Tablas;1" \c "Tabla" + # Modified: TOC \f t \h \z \t "Tablas;1" \c "Tabla" + # Use regex to handle whitespace/HTML variations in the TOC field + html_content = re.sub( + r'(TOC\s+)(\\h\s+\\z\s+\\t\s*\n?\s*"Tablas;1")', + r'\1\\f t \2', + html_content + ) + soup = BeautifulSoup(html_content, 'html.parser') print("Reading docs content...") @@ -671,10 +774,10 @@ def main(): # Also remove surrounding caption and source prev_sib = table.find_previous_sibling() next_sib = table.find_next_sibling() - if prev_sib and 'Tabla 1. Ejemplo' in prev_sib.get_text(): - prev_sib.decompose() - if next_sib and SOURCE_LINE_RE.search(next_sib.get_text().strip()): - next_sib.decompose() + if prev_sib and 'Tabla 1. Ejemplo' in prev_sib.get_text(): + prev_sib.decompose() + if next_sib and SOURCE_LINE_RE.search(next_sib.get_text().strip()): + next_sib.decompose() table.decompose() print(" ✓ Removed template table example") break diff --git a/docs/00_resumen.md b/docs/00_resumen.md index e0f0c11..b3d37cd 100644 --- a/docs/00_resumen.md +++ b/docs/00_resumen.md @@ -6,7 +6,7 @@ Se realizó un estudio comparativo de tres soluciones OCR de código abierto: Ea Los resultados demuestran que la optimización de hiperparámetros logró mejoras significativas: el mejor trial individual alcanzó un CER de 0.79% (precisión del 99.21%), cumpliendo el objetivo de CER < 2%. Al validar la configuración optimizada sobre el dataset completo de 45 páginas, se obtuvo una mejora del 12.8% en CER (de 8.85% a 7.72%). El hallazgo más relevante fue que el parámetro `textline_orientation` (clasificación de orientación de línea de texto) tiene un impacto crítico en el rendimiento. Adicionalmente, se identificó que el umbral de detección (`text_det_thresh`) presenta una correlación positiva moderada (0.43) con el error, lo que indica que valores más bajos tienden a mejorar el rendimiento. -**Fuente:** [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md), [`src/results/correlations/paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv). +**Fuente:** [`metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md), [`paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv). Este trabajo demuestra que la optimización de hiperparámetros es una alternativa viable al fine-tuning, especialmente útil cuando se dispone de modelos preentrenados para el idioma objetivo. La infraestructura dockerizada desarrollada permite reproducir los experimentos y facilita la evaluación sistemática de configuraciones OCR. @@ -22,7 +22,7 @@ A comparative study of three open-source OCR solutions was conducted with EasyOC Results demonstrate that hyperparameter optimization achieved significant improvements. The best individual trial reached a CER of 0.79% (99.21% accuracy), meeting the CER < 2% objective. When validating the optimized configuration on the full 45-page dataset, a 12.8% CER improvement was obtained (from 8.85% to 7.72%). The most relevant finding was that the `textline_orientation` parameter (text line orientation classification) has a critical impact on performance. Additionally, the detection threshold (`text_det_thresh`) showed a moderate positive correlation (0.43) with error, indicating that lower values tend to improve performance. -Sources: [`docs/metrics/metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md), [`src/results/correlations/paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv). +Sources: [`metrics_paddle.md`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/docs/metrics/metrics_paddle.md), [`paddle_correlations.csv`](https://seryus.ddns.net/unir/MastersThesis/src/branch/main/src/results/correlations/paddle_correlations.csv). This work demonstrates that hyperparameter optimization is a viable alternative to fine-tuning, especially useful when pre-trained models for the target language are available. The dockerized infrastructure developed enables experiment reproducibility and facilitates systematic evaluation of OCR configurations. diff --git a/docs/compliance.md b/docs/compliance.md new file mode 100644 index 0000000..0f8af19 --- /dev/null +++ b/docs/compliance.md @@ -0,0 +1,157 @@ +# UNIR Style Compliance Checklist + +This document lists the UNIR TFE style requirements to verify before final submission. + +## Page Layout + +| Requirement | Specification | Check | +|-------------|---------------|-------| +| Page size | A4 | ☐ | +| Left margin | 3.0 cm | ☐ | +| Right margin | 2.0 cm | ☐ | +| Top margin | 2.5 cm | ☐ | +| Bottom margin | 2.5 cm | ☐ | +| Header | Student name + TFE title | ☐ | +| Footer | Page number | ☐ | + +## Typography + +| Element | Specification | Check | +|---------|---------------|-------| +| Body text | Calibri 12pt, justified, 1.5 line spacing | ☐ | +| Título 1 (H1) | Calibri Light 18pt, blue, numbered (1., 2., ...) | ☐ | +| Título 2 (H2) | Calibri Light 14pt, blue, numbered (1.1, 1.2, ...) | ☐ | +| Título 3 (H3) | Calibri Light 12pt, numbered (1.1.1, 1.1.2, ...) | ☐ | +| Título 4 (H4) | Calibri 12pt, bold, unnumbered | ☐ | +| Footnotes | Calibri 10pt, justified, single spacing | ☐ | +| Code blocks | Consolas 10pt | ☐ | + +## Document Structure + +| Section | Requirements | Check | +|---------|--------------|-------| +| Portada | Title, Author, Type, Director, Date | ☐ | +| Resumen | 150-300 words in Spanish + Palabras clave (3-5) | ☐ | +| Abstract | 150-300 words in English + Keywords (3-5) | ☐ | +| Índice de contenidos | Auto-generated, new page | ☐ | +| Índice de figuras | Auto-generated, new page | ☐ | +| Índice de tablas | Auto-generated, new page | ☐ | +| Cap. 1 Introducción | 1.1 Motivación, 1.2 Planteamiento, 1.3 Estructura | ☐ | +| Cap. 2 Contexto | 2.1 Contexto, 2.2 Estado del arte, 2.3 Conclusiones | ☐ | +| Cap. 3 Objetivos | 3.1 Objetivo general, 3.2 Específicos, 3.3 Metodología | ☐ | +| Cap. 4 Desarrollo | Structure depends on work type | ☐ | +| Cap. 5 Conclusiones | 5.1 Conclusiones, 5.2 Trabajo futuro | ☐ | +| Referencias | APA format, alphabetical order | ☐ | +| Anexos | Code repository URL, supplementary data | ☐ | + +## Tables + +| Requirement | Specification | Check | +|-------------|---------------|-------| +| Title position | Above the table | ☐ | +| Title format | **Tabla N.** *Descriptive title in italics.* | ☐ | +| Numbering | Sequential (1, 2, 3...), Anexo uses A1, A2... | ☐ | +| Border style | APA: horizontal lines only (top, header bottom, table bottom) | ☐ | +| Source position | Below the table, centered | ☐ | +| Source format | Fuente: Author, Year. or Fuente: Elaboración propia. | ☐ | +| Leyenda (if needed) | Below Fuente, same style (Piedefoto-tabla) | ☐ | +| In TOT index | All tables appear in Índice de tablas | ☐ | + +## Figures + +| Requirement | Specification | Check | +|-------------|---------------|-------| +| Title position | Above the figure | ☐ | +| Title format | **Figura N.** *Descriptive title in italics.* | ☐ | +| Numbering | Sequential (1, 2, 3...), Anexo uses A1, A2... | ☐ | +| Alignment | Centered | ☐ | +| Source position | Below the figure, centered | ☐ | +| Source format | Fuente: Author, Year. or Fuente: Elaboración propia. | ☐ | +| Leyenda (if needed) | Below Fuente, same style (Piedefoto-tabla) | ☐ | +| In TOF index | All figures appear in Índice de figuras | ☐ | + +## Lists + +| Requirement | Specification | Check | +|-------------|---------------|-------| +| Bullet lists | Indented 36pt, bullet symbol (·) | ☐ | +| Numbered lists | Indented 36pt, sequential numbers (1, 2, 3...) | ☐ | +| Spacing | Proper First/Middle/Last paragraph spacing | ☐ | + +## Citations and References + +| Requirement | Specification | Check | +|-------------|---------------|-------| +| Citation format | APA 7th edition | ☐ | +| Single author | (Author, Year) or Author (Year) | ☐ | +| Two authors | (Author1 & Author2, Year) | ☐ | +| Three+ authors | (Author1 et al., Year) | ☐ | +| Reference list | Alphabetical by first author surname | ☐ | +| Hanging indent | 36pt left margin, -36pt text indent | ☐ | +| DOI/URL | Include when available | ☐ | +| No Wikipedia | Wikipedia citations not allowed | ☐ | +| Source variety | Books, journals, conferences (not just URLs) | ☐ | + +## SMART Objectives + +All objectives must be SMART: + +| Criterion | Requirement | Check | +|-----------|-------------|-------| +| **S**pecific | Clearly defined, unambiguous | ☐ | +| **M**easurable | Quantifiable success metric (e.g., CER < 2%) | ☐ | +| **A**ttainable | Feasible with available resources | ☐ | +| **R**elevant | Demonstrable impact | ☐ | +| **T**ime-bound | Achievable within timeframe | ☐ | + +## Writing Style + +| Requirement | Check | +|-------------|-------| +| Each chapter starts with introductory paragraph | ☐ | +| Each paragraph has at least 3 sentences | ☐ | +| No two consecutive headings without text between them | ☐ | +| No superfluous phrases or repetition | ☐ | +| All concepts defined with pertinent citations | ☐ | +| Spelling checked (Word corrector) | ☐ | +| Logical flow between paragraphs | ☐ | + +## Final Checks + +| Requirement | Check | +|-------------|-------| +| All cited references appear in reference list | ☐ | +| All references in list are cited in text | ☐ | +| All figures/tables have numbers and titles | ☐ | +| Update all indices (Ctrl+A, F9 in Word) | ☐ | +| Page count: 50-90 pages (excl. cover, indices, annexes) | ☐ | +| Final format: PDF for deposit | ☐ | + +## Automated Checks (apply_content.py) + +The following are automatically handled by the generation scripts: + +- ✓ Table/Figure sequential numbering +- ✓ Anexo items use A1, A2... prefix +- ✓ TC fields for Anexo items (appear in indices) +- ✓ Piedefoto-tabla style for Fuente/Leyenda +- ✓ MsoCaption style for titles +- ✓ APA table borders (horizontal only) +- ✓ MsoBibliography style for references +- ✓ MsoQuote style for blockquotes +- ✓ List paragraph classes (First/Middle/Last) +- ✓ Bold H4 headings (unnumbered) + +## Color Palette (UNIR Theme) + +| Color | Hex | Usage | +|-------|-----|-------| +| Primary Blue | `#0098CD` | Headings, diagram borders | +| Light Blue BG | `#E6F4F9` | Diagram backgrounds | +| Dark Gray | `#404040` | Body text | +| Accent Blue | `#5B9BD5` | Table headers | +| Light Accent | `#9CC2E5` | Table borders | + +--- + +**Reference:** UNIR TFE Guidelines (`instructions/instrucciones.pdf`, `instructions/plantilla_individual.pdf`) diff --git a/thesis_output/plantilla_individual.htm b/thesis_output/plantilla_individual.htm index daaabfb..8c4d2b3 100644 --- a/thesis_output/plantilla_individual.htm +++ b/thesis_output/plantilla_individual.htm @@ -4152,7 +4152,7 @@ EN-US;mso-bidi-language:AR-SA'>
Resumen

El presente Trabajo Fin de Máster aborda la optimización de sistemas de Reconocimiento Óptico de Caracteres (OCR) basados en inteligencia artificial para documentos en español. El objetivo principal es identificar la configuración óptima de hiperparámetros que maximice la precisión del reconocimiento de texto sin requerir fine-tuning de los modelos base.

Se realizó un estudio comparativo de tres soluciones OCR de código abierto: EasyOCR, PaddleOCR (PP-OCRv5) y DocTR. Se evaluó su rendimiento mediante las métricas estándar CER (Character Error Rate) y WER (Word Error Rate) sobre un corpus de 45 páginas de documentos académicos en español. Tras identificar PaddleOCR como la solución más prometedora, se procedió a una optimización sistemática de hiperparámetros utilizando Ray Tune con el algoritmo de búsqueda Optuna, ejecutando 64 configuraciones diferentes con aceleración GPU (NVIDIA RTX 3060).

Los resultados demuestran que la optimización de hiperparámetros logró mejoras significativas: el mejor trial individual alcanzó un CER de 0.79% (precisión del 99.21%), cumpliendo el objetivo de CER < 2%. Al validar la configuración optimizada sobre el dataset completo de 45 páginas, se obtuvo una mejora del 12.8% en CER (de 8.85% a 7.72%). El hallazgo más relevante fue que el parámetro textline_orientation (clasificación de orientación de línea de texto) tiene un impacto crítico en el rendimiento. Adicionalmente, se identificó que el umbral de detección (text_det_thresh) presenta una correlación positiva moderada (0.43) con el error, lo que indica que valores más bajos tienden a mejorar el rendimiento.

-

Fuente: docs/metrics/metrics_paddle.md, src/results/correlations/paddle_correlations.csv.

+

Fuente: metrics_paddle.md, paddle_correlations.csv.

Este trabajo demuestra que la optimización de hiperparámetros es una alternativa viable al fine-tuning, especialmente útil cuando se dispone de modelos preentrenados para el idioma objetivo. La infraestructura dockerizada desarrollada permite reproducir los experimentos y facilita la evaluación sistemática de configuraciones OCR.

 

Palabras clave: OCR, Reconocimiento Óptico de Caracteres, PaddleOCR, Optimización de Hiperparámetros, Ray Tune, Procesamiento de Documentos, Inteligencia Artificial

@@ -4170,7 +4170,7 @@ EN-US;mso-bidi-language:AR-SA'>
Abstract

This Master's Thesis addresses the optimization of Artificial Intelligence-based Optical Character Recognition (OCR) systems for Spanish documents. The main objective is to identify the optimal hyperparameter configuration that maximizes text recognition accuracy without requiring fine-tuning of the base models.

A comparative study of three open-source OCR solutions was conducted with EasyOCR, PaddleOCR (PP-OCRv5), and DocTR. Their performance was evaluated using standard CER (Character Error Rate) and WER (Word Error Rate) metrics on a corpus of 45 pages of academic documents in Spanish. After identifying PaddleOCR as the most promising solution, systematic hyperparameter optimization was performed using Ray Tune with the Optuna search algorithm, executing 64 different configurations with GPU acceleration (NVIDIA RTX 3060).

Results demonstrate that hyperparameter optimization achieved significant improvements. The best individual trial reached a CER of 0.79% (99.21% accuracy), meeting the CER < 2% objective. When validating the optimized configuration on the full 45-page dataset, a 12.8% CER improvement was obtained (from 8.85% to 7.72%). The most relevant finding was that the textline_orientation parameter (text line orientation classification) has a critical impact on performance. Additionally, the detection threshold (text_det_thresh) showed a moderate positive correlation (0.43) with error, indicating that lower values tend to improve performance.

-

Sources: docs/metrics/metrics_paddle.md, src/results/correlations/paddle_correlations.csv.

+

Sources: metrics_paddle.md, paddle_correlations.csv.

This work demonstrates that hyperparameter optimization is a viable alternative to fine-tuning, especially useful when pre-trained models for the target language are available. The dockerized infrastructure developed enables experiment reproducibility and facilitates systematic evaluation of OCR configurations.

 

Keywords: OCR, Optical Character Recognition, PaddleOCR, Hyperparameter Optimization, Ray Tune, Document Processing, Artificial Intelligence

@@ -4500,7 +4500,7 @@ yellow;mso-highlight:yellow'>< Índice de tablas

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)

+

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

+

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

+

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.

@@ -4670,75 +4670,75 @@ _Toc14106979"> 

Métricas de Evaluación

La evaluación rigurosa de sistemas OCR requiere métricas estandarizadas que permitan comparaciones objetivas. Las métricas fundamentales se basan en la distancia de edición de Levenshtein.

-

Distancia de Levenshtein

+

Distancia de Levenshtein

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:

d(a,b)=min(inserciones+eliminaciones+sustituciones)

Esta métrica es fundamental para calcular tanto CER como WER.

-

Character Error Rate (CER)

+

Character Error Rate (CER)

El CER mide el error a nivel de carácter y se calcula como:

CER=S+D+IN

Donde:

-

·     S = número de sustituciones de caracteres

+

·     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

+

·     N = número total de caracteres en el texto de referencia

Un CER bajo indica que el sistema comete pocos errores a nivel de carácter. Para aplicaciones críticas se requiere un nivel de error muy reducido, mientras que en tareas de búsqueda o archivo pueden aceptarse errores mayores.

-

Word Error Rate (WER)

+

Word Error Rate (WER)

El WER mide el error a nivel de palabra, utilizando la misma fórmula pero considerando palabras como unidades:

WER=Sw+Dw+IwNw

El WER es generalmente mayor que el CER, ya que un solo error de carácter puede invalidar una palabra completa. Esta diferencia es relevante cuando se comparan sistemas que preservan caracteres pero pierden palabras completas.

-

Otras Métricas Complementarias

+

Otras Métricas Complementarias

Precisión 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, como lengua romance, presenta características específicas que impactan el rendimiento de los sistemas OCR:

-

Características Ortográficas

+

Características Ortográficas

Caracteres especiales: El español incluye caracteres no presentes en el alfabeto inglés básico:

-

·     La letra eñe (ñ, Ñ)

+

·     La letra eñe (ñ, Ñ)

·     Vocales acentuadas (á, é, í, ó, ú, Á, É, Í, Ó, Ú)

·     Diéresis sobre u (ü, Ü)

-

·     Signos de puntuación invertidos (¿, ¡)

+

·     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

+

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

+

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

+

·     Menor cantidad de datasets etiquetados de gran escala

·     Menos modelos preentrenados específicos para español

-

·     Documentación y tutoriales predominantemente en inglés

+

·     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

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 técnica:

-

·     Detector: CRAFT (Character Region Awareness for Text Detection)

+

·     Detector: CRAFT (Character Region Awareness for Text Detection)

·     Reconocedor: CRNN con backbone ResNet/VGG + BiLSTM + CTC

-

·     Modelos preentrenados: Disponibles para descarga automática

+

·     Modelos preentrenados: Disponibles para descarga automática

Características principales:

-

·     API simple de una línea para casos de uso básicos

+

·     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

+

·     Bajo consumo de memoria comparado con otras soluciones

Limitaciones identificadas:

-

·     Opciones de configuración limitadas (pocos hiperparámetros ajustables)

+

·     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

+

·     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

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 técnica:

El pipeline de PaddleOCR consta de tres módulos principales:

-

1.   Detector de texto (DB - Differentiable Binarization):

+

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

-

1.   Clasificador de orientación:

+

1.   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

-

1.   Reconocedor de texto (SVTR):

+

1.   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:

@@ -4755,32 +4755,32 @@ _Toc14106979">Fuente: Documentación oficial de PaddleOCR (PaddlePaddle, 2024).

 

Fortalezas de PaddleOCR:

-

·     Alta precisión en múltiples benchmarks

+

·     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)

+

·     Soporte para entrenamiento personalizado (fine-tuning)

Limitaciones:

-

·     Dependencia del framework PaddlePaddle (menos popular que PyTorch/TensorFlow)

+

·     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

+

·     Documentación en inglés menos completa que en chino

+

DocTR

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 técnica:

-

·     Detectores disponibles: DB (db_resnet50), LinkNet (linknet_resnet18)

+

·     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

+

·     Framework: TensorFlow 2.x o PyTorch

Características principales:

-

·     API Pythonic bien diseñada

+

·     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

+

·     Documentación orientada a investigación

Limitaciones identificadas:

-

·     Menor rendimiento en español comparado con PaddleOCR según pruebas preliminares

+

·     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

-

Comparativa Detallada de Soluciones

+

·     Menos opciones de modelos preentrenados para idiomas no ingleses

+

Comparativa Detallada de Soluciones

Tabla 9. Comparativa técnica de soluciones OCR de código abierto.

Aspecto

EasyOCR

PaddleOCR

DocTR

Framework

PyTorch

PaddlePaddle

TF/PyTorch

Detector

CRAFT

DB

DB/LinkNet

Reconocedor

CRNN

SVTR/CRNN

CRNN/SAR/ViTSTR

Idiomas

Multilingüe

Multilingüe

Limitado

Configurabilidad

Baja

Alta

Media

Documentación

Media

Alta (CN)

Alta (EN)

Actividad

Media

Alta

Media

Licencia

Apache 2.0

Apache 2.0

Apache 2.0

Fuente: Elaboración propia a partir de documentación oficial (2024).

@@ -4790,49 +4790,49 @@ _Toc14106979">Fuente: Elaboración propia a partir de documentación oficial.

 

Optimización de Hiperparámetros

-

Fundamentos Teóricos

+

Fundamentos Teóricos

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).

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

+

·     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)

+

·     Umbrales de decisión en tiempo de inferencia (relevante para este trabajo)

El problema de HPO puede formalizarse como:

λ*=argminλ∈Λℒ(Mλ,Dval)

Donde:

-

·     λ es un vector de hiperparámetros

+

·     λ es un vector de hiperparámetros

·     Λ es el espacio de búsqueda

·     Mλ es el modelo configurado con λ

·     ℒ es la función de pérdida

-

·     Dval es el conjunto de validación

-

Métodos de Optimización

+

·     Dval es el conjunto de validación

+

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 nk evaluaciones.

Ventajas:

-

·     Exhaustivo y reproducible

+

·     Exhaustivo y reproducible

·     Fácil de paralelizar

-

·     Garantiza encontrar el óptimo dentro de la rejilla

+

·     Garantiza encontrar el óptimo dentro de la rejilla

Desventajas:

-

·     Coste exponencial con el número de hiperparámetros

+

·     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

+

·     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

+

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

+

4.   Actualizar las observaciones y repetir

Los modelos sustitutos más comunes son:

-

·     Procesos Gaussianos (GP): Proporcionan incertidumbre bien calibrada pero escalan pobremente

+

·     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)

+

·     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|λ) directamente, TPE modela: @@ -4846,34 +4846,34 @@ Donde l y baja probabilidad bajo g tienen mayor Expected Improvement.

Ventajas de TPE:

-

·     Maneja naturalmente espacios condicionales (hiperparámetros que dependen de otros)

+

·     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

+

·     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

+

·     Ejecución paralela de múltiples trials

·     Distribución automática en clusters

-

·     Soporte para recursos heterogéneos (CPU/GPU)

+

·     Soporte para recursos heterogéneos (CPU/GPU)

Flexibilidad:

-

·     Integración con múltiples algoritmos de búsqueda (Optuna, HyperOpt, Ax, etc.)

+

·     Integración con múltiples algoritmos de búsqueda (Optuna, HyperOpt, Ax, etc.)

·     Schedulers avanzados (ASHA, PBT, BOHB)

-

·     Checkpointing y recuperación de fallos

+

·     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

+

·     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

+

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

+

4.   Acceder a las visualizaciones de Optuna

Figura 2. Ciclo de optimización con Ray Tune y Optuna

Ciclo de optimización con Ray Tune y Optuna

Fuente: Elaboración propia.

 

-

HPO en Sistemas OCR

+

HPO en Sistemas OCR

La aplicación de HPO a sistemas OCR ha sido explorada en varios contextos:

Optimización de preprocesamiento:

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.

@@ -4883,12 +4883,12 @@ Configuraciones con alta probabilidad bajo 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)

+

·     Entrenamiento de modelos (fine-tuning)

·     Preprocesamiento de imagen

-

·     Post-procesamiento lingüístico

+

·     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

+

Datasets Públicos

Los principales recursos para evaluación de OCR en español incluyen:

FUNSD-ES: Versión en español del Form Understanding in Noisy Scanned Documents dataset. Contiene formularios escaneados con anotaciones de texto y estructura.

MLT (ICDAR Multi-Language Text): Dataset multilingüe de las competiciones ICDAR que incluye muestras en español. Las ediciones recientes contienen texto en escenas naturales.

@@ -4897,15 +4897,15 @@ Configuraciones con alta probabilidad bajo

Dataset

Tipo

Idiomas

Tamaño

Uso principal

FUNSD-ES

Formularios

ES

Pequeño

Document understanding

MLT

Escenas

Multi (incl. ES)

Medio

Text detection

XFUND

Formularios

Multi (incl. ES)

Medio

Information extraction

Fuente: Elaboración propia a partir de repositorios oficiales.

 

-

Limitaciones de Recursos para Español

+

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

+

·     Menor cantidad de datasets etiquetados de gran escala

·     Menos benchmarks estandarizados

·     Menor representación en competiciones internacionales (ICDAR)

-

·     Pocos modelos preentrenados específicos

+

·     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.

Además, se priorizó un dataset propio aunque fuera de tamaño reducido porque el objetivo era evaluar texto académico en un formato sencillo y reproducible (texto plano con índice), sin tablas ni estructuras complejas. Ese perfil no está bien cubierto por datasets públicos centrados en formularios o escenas naturales, por lo que se optó por un corpus controlado y alineado con el dominio del TFM.

-

Trabajos Previos en OCR para Español

+

Trabajos Previos en OCR para Español

Los trabajos previos en OCR para español se han centrado principalmente en:

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).

Procesamiento de documentos de identidad: Sistemas OCR especializados para DNI, pasaportes y documentos oficiales españoles y latinoamericanos (Bulatov et al., 2020).

@@ -4948,59 +4948,59 @@ concretos y metodología de trabajoFuente: Elaboración propia.

 

Descripción de las fases:

-

·     Fase 1 - Preparación del Dataset: Conversión PDF a imágenes (300 DPI), extracción de ground truth con PyMuPDF

+

·     Fase 1 - Preparación del Dataset: Conversión PDF a imágenes (300 DPI), extracción de ground truth con PyMuPDF

·     Fase 2 - Benchmark Comparativo: Evaluación de EasyOCR, PaddleOCR, DocTR con métricas CER/WER

·     Fase 3 - Espacio de Búsqueda: Identificación de hiperparámetros y configuración de Ray Tune + Optuna

·     Fase 4 - Optimización: Ejecución de 64 trials con paralelización (2 concurrentes)

-

·     Fase 5 - Validación: Comparación baseline vs optimizado, análisis de correlaciones

+

·     Fase 5 - Validación: Comparación baseline vs optimizado, análisis de correlaciones

Fase 1: Preparación del Dataset

-

Fuente de Datos

+

Fuente de Datos

Se utilizaron documentos PDF académicos de UNIR (Universidad Internacional de La Rioja), específicamente las instrucciones para la elaboración del TFE del Máster en Inteligencia Artificial.

-

Proceso de Conversión

+

Proceso de Conversión

El script prepare_dataset.ipynb implementa:

-

1.   Conversión PDF a imágenes:

+

1.   Conversión PDF a imágenes:

- Biblioteca: PyMuPDF (fitz) - Resolución: 300 DPI - Formato de salida: PNG

-

1.   Extracción de texto de referencia:

+

1.   Extracción de texto de referencia:

- Método: page.get_text("dict") de PyMuPDF - Preservación de estructura de líneas - Tratamiento de texto vertical/marginal - Normalización de espacios y saltos de línea

-

Estructura del Dataset

+

Estructura del Dataset

Figura 4. Estructura del dataset de evaluación

Estructura del dataset de evaluación

Fuente: Elaboración propia.

 

-

Clase ImageTextDataset

+

Clase ImageTextDataset

Se implementó una clase Python para cargar pares imagen-texto que retorna tuplas (PIL.Image, str) desde carpetas pareadas. La implementación se encuentra en:

-

·     src/prepare_dataset.ipynb

+

·     src/prepare_dataset.ipynb

·     src/paddle_ocr/dataset_manager.py

·     src/easyocr_service/dataset_manager.py

-

·     src/doctr_service/dataset_manager.py

+

·     src/doctr_service/dataset_manager.py

Fase 2: Benchmark Comparativo

-

Modelos Evaluados

+

Modelos Evaluados

Tabla 14. Modelos OCR evaluados en el benchmark inicial.

Modelo

Versión

Configuración

EasyOCR

-

Idiomas: ['es', 'en']

PaddleOCR

PP-OCRv5

Modelos Mobile (limitación de VRAM)

DocTR

-

db_resnet50 + sar_resnet31

Fuente: docs/metrics/metrics.md.

 

-

Métricas de Evaluación

+

Métricas de Evaluación

Se utilizó la biblioteca jiwer para calcular CER y WER comparando el texto de referencia con la predicción del modelo OCR. La implementación se encuentra en:

-

·     src/paddle_ocr/paddle_ocr_tuning_rest.py

+

·     src/paddle_ocr/paddle_ocr_tuning_rest.py

·     src/easyocr_service/easyocr_tuning_rest.py

-

·     src/doctr_service/doctr_tuning_rest.py

+

·     src/doctr_service/doctr_tuning_rest.py

Fase 3: Espacio de Búsqueda

-

Hiperparámetros Seleccionados

+

Hiperparámetros Seleccionados

Tabla 15. Hiperparámetros seleccionados para optimización.

Parámetro

Tipo

Rango/Valores

Descripción

use_doc_orientation_classify

Booleano

[True, False]

Clasificación de orientación del documento

use_doc_unwarping

Booleano

[True, False]

Corrección de deformación del documento

textline_orientation

Booleano

[True, False]

Clasificación de orientación de línea de texto

text_det_thresh

Continuo

[0.0, 0.7]

Umbral de detección de píxeles de texto

text_det_box_thresh

Continuo

[0.0, 0.7]

Umbral de caja de detección

text_det_unclip_ratio

Fijo

0.0

Coeficiente de expansión (fijado)

text_rec_score_thresh

Continuo

[0.0, 0.7]

Umbral de confianza de reconocimiento

Fuente: Elaboración propia.

 

-

Configuración de Ray Tune

+

Configuración de Ray Tune

El espacio de búsqueda se definió utilizando tune.choice() para parámetros booleanos y tune.uniform() para parámetros continuos, con OptunaSearch como algoritmo de optimización configurado para minimizar CER en 64 trials. La implementación completa está disponible en src/raytune/raytune_ocr.py (ver Anexo A).

Fase 4: Ejecución de Optimización

-

Arquitectura de Ejecución

+

Arquitectura de Ejecución

Se implementó una arquitectura basada en contenedores Docker para aislar los servicios OCR y facilitar la reproducibilidad (ver sección 4.2.3 para detalles de la arquitectura).

-

Ejecución con Docker Compose

+

Ejecución con Docker Compose

Los servicios se orquestan mediante Docker Compose:

-

·     src/docker-compose.tuning.paddle.yml

+

·     src/docker-compose.tuning.paddle.yml

·     src/docker-compose.tuning.doctr.yml

·     src/docker-compose.tuning.easyocr.yml

-

·     src/docker-compose.tuning.yml

+

·     src/docker-compose.tuning.yml

# Iniciar servicio OCR
 docker compose -f docker-compose.tuning.doctr.yml up -d doctr-gpu
@@ -5020,23 +5020,23 @@ docker compose -f docker-compose.tuning.doctr.yml down
}

Fase 5: Validación

-

Protocolo de Validación

-

1.   Baseline: Ejecución con configuración por defecto de PaddleOCR

+

Protocolo de Validación

+

1.   Baseline: Ejecución con configuración por defecto de PaddleOCR

2.   Optimizado: Ejecución con mejor configuración encontrada

3.   Comparación: Evaluación sobre las 45 páginas del dataset completo

-

4.   Métricas reportadas: CER, WER, tiempo de procesamiento

+

4.   Métricas reportadas: CER, WER, tiempo de procesamiento

Entorno de Ejecución

-

Hardware

+

Hardware

Tabla 16. Especificaciones de hardware del entorno de desarrollo.

Componente

Especificación

CPU

AMD Ryzen 7 5800H

RAM

16 GB DDR4

GPU

NVIDIA RTX 3060 Laptop (5.66 GB VRAM)

Almacenamiento

SSD

Fuente: docs/metrics/metrics.md.

 

-

Software

+

Software

Tabla 17. Software utilizado en el entorno de desarrollo.

Componente

Versión

PaddlePaddle

3.2.2

PaddleOCR

3.3.2

Ray Tune

2.52.1

Optuna

4.7.0

DocTR (python-doctr)

>= 0.8.0

EasyOCR

>= 1.7.0

Fuente: src/paddle_ocr/requirements.txt, src/raytune/requirements.txt, src/doctr_service/requirements.txt, src/easyocr_service/requirements.txt.

 

-

Justificación de Ejecución Local vs Cloud

+

Justificación de Ejecución Local vs Cloud

La decisión de ejecutar los experimentos en hardware local en lugar de utilizar servicios cloud se fundamenta en un análisis de costos y beneficios operativos.

Tabla 18. Costos de GPU en plataformas cloud.

Plataforma

GPU

Costo/Hora

Costo Mensual

AWS EC2 g4dn.xlarge

NVIDIA T4 (16 GB)

$0.526

~$384

Google Colab Pro

T4/P100

~$1.30

$10 + CU extras

Google Colab Pro+

T4/V100/A100

~$1.30

$50 + CU extras

@@ -5048,17 +5048,17 @@ docker compose -f docker-compose.tuning.doctr.yml down

Fuente: Elaboración propia a partir de precios públicos. Ver Anexo A, sección de fuentes de precios cloud (enero 2026).

 

Las ventajas de la ejecución local incluyen:

-

1.   Costo cero de GPU: La RTX 3060 ya está disponible en el equipo de desarrollo

+

1.   Costo cero de GPU: La RTX 3060 ya está disponible en el equipo de desarrollo

2.   Sin límites de tiempo: AWS y Colab imponen timeouts de sesión que interrumpen experimentos largos

3.   Acceso instantáneo: Sin tiempo de aprovisionamiento de instancias cloud

4.   Almacenamiento local: Dataset y resultados en disco sin costos de transferencia

-

5.   Iteración rápida: Reinicio inmediato de contenedores Docker para depuración

+

5.   Iteración rápida: Reinicio inmediato de contenedores Docker para depuración

Para un proyecto de investigación con múltiples iteraciones de ajuste de hiperparámetros, la ejecución local reduce costos frente a servicios cloud. Este análisis se detalla en docs/metrics/metrics.md.)

Limitaciones Metodológicas

-

1.   Tamaño del dataset: El dataset contiene 45 páginas de documentos académicos UNIR. Resultados pueden no generalizar a otros formatos.

-

1.   Subconjunto de optimización: El ajuste de hiperparámetros se realizó sobre 5 páginas (páginas 5-10), lo que contribuyó al sobreajuste observado en la validación del dataset completo.

-

1.   Texto de referencia imperfecto: El texto de referencia extraído de PDF puede contener errores en documentos con diseños complejos.

-

1.   Parámetro fijo: text_det_unclip_ratio quedó fijado en 0.0 durante todo el experimento por decisión de diseño inicial.

+

1.   Tamaño del dataset: El dataset contiene 45 páginas de documentos académicos UNIR. Resultados pueden no generalizar a otros formatos.

+

2.   Subconjunto de optimización: El ajuste de hiperparámetros se realizó sobre 5 páginas (páginas 5-10), lo que contribuyó al sobreajuste observado en la validación del dataset completo.

+

3.   Texto de referencia imperfecto: El texto de referencia extraído de PDF puede contener errores en documentos con diseños complejos.

+

4.   Parámetro fijo: text_det_unclip_ratio quedó fijado en 0.0 durante todo el experimento por decisión de diseño inicial.

Síntesis del capítulo

Los objetivos y la metodología definidos en este capítulo establecen el marco para la experimentación. El objetivo general, alcanzar un CER inferior al 2% mediante optimización de hiperparámetros, se descompone en cinco objetivos específicos que abarcan desde la comparativa inicial de soluciones hasta la validación final de la configuración optimizada.

La metodología experimental en cinco fases garantiza un proceso sistemático y reproducible: preparación de un dataset de 45 páginas, benchmark comparativo de tres motores OCR, definición del espacio de búsqueda, ejecución de 64 trials con Ray Tune y Optuna, y validación de la configuración resultante. Las limitaciones metodológicas, como el tamaño del dataset, el subconjunto de optimización reducido y el texto de referencia automático, se reconocen explícitamente para contextualizar la interpretación de resultados.

@@ -5097,128 +5097,128 @@ color:#0098CD;mso-font-kerning:16.0pt;mso-bidi-font-weight:bold'>Fuente: docs/metrics/metrics.md.

 

Imágenes Docker disponibles en el registro del proyecto:

-

·     PaddleOCR: seryus.ddns.net/unir/paddle-ocr-gpu, seryus.ddns.net/unir/paddle-ocr-cpu

+

·     PaddleOCR: seryus.ddns.net/unir/paddle-ocr-gpu, seryus.ddns.net/unir/paddle-ocr-cpu

·     EasyOCR: seryus.ddns.net/unir/easyocr-gpu

-

·     DocTR: seryus.ddns.net/unir/doctr-gpu

+

·     DocTR: seryus.ddns.net/unir/doctr-gpu

Criterios de Éxito

Los criterios establecidos para evaluar las soluciones fueron:

-

1.   Precisión (CER < 5%): Error de caracteres aceptable para documentos académicos

+

1.   Precisión (CER < 5%): Error de caracteres aceptable para documentos académicos

2.   Configurabilidad: Disponibilidad de hiperparámetros ajustables

3.   Soporte para español: Modelos preentrenados que incluyan el idioma

4.   Documentación: Calidad de la documentación técnica

-

5.   Mantenimiento activo: Actualizaciones recientes y comunidad activa

+

5.   Mantenimiento activo: Actualizaciones recientes y comunidad activa

Configuración del Experimento

-

Dataset de Evaluación

+

Dataset de Evaluación

Se utilizó el documento "Instrucciones para la redacción y elaboración del TFE" del Máster Universitario en Inteligencia Artificial de UNIR, ubicado en la carpeta instructions/.

Tabla 21. Características del dataset de evaluación inicial.

Característica

Valor

Documento fuente

Instrucciones TFE UNIR

Número de páginas evaluadas

5 (benchmark inicial)

Formato

PDF digital (no escaneado)

Idioma principal

Español

Resolución de conversión

300 DPI

Formato de imagen

PNG

Fuente: docs/metrics/metrics.md.

 

-

Proceso de Conversión

+

Proceso de Conversión

La conversión del PDF a imágenes se realizó mediante PyMuPDF (fitz) a 300 DPI, resolución estándar para OCR que proporciona suficiente detalle para caracteres pequeños sin generar archivos excesivamente grandes. La implementación está disponible en src/prepare_dataset.ipynb.

-

Extracción del Ground Truth

+

Extracción del Ground Truth

El texto de referencia se extrajo directamente del PDF mediante PyMuPDF, preservando la estructura de líneas del documento original. Esta aproximación puede introducir errores en el orden de lectura cuando hay secciones con encabezados, listas o saltos de línea, por lo que se documenta junto al pipeline de preparación en src/prepare_dataset.ipynb. Para la comparación entre motores, las salidas se guardan en debugset/ al activar save_output=True, y el flujo de trabajo se describe en src/README.md y en los README de cada servicio: src/paddle_ocr/README.md, src/easyocr_service/README.md, src/doctr_service/README.md.

-

Configuración de los Modelos

+

Configuración de los Modelos

La configuración de cada modelo se detalla en los README de cada servicio y sus ficheros de dependencias:

-

·     EasyOCR: Configurado con soporte para español e inglés, permitiendo reconocer palabras en ambos idiomas que puedan aparecer en documentos académicos (referencias, términos técnicos).

+

·     EasyOCR: Configurado con soporte para español e inglés, permitiendo reconocer palabras en ambos idiomas que puedan aparecer en documentos académicos (referencias, términos técnicos).

·     PaddleOCR (PP-OCRv5): Se utilizaron los modelos Mobile, adecuados para la VRAM disponible. Los modelos Server se probaron y produjeron OOM en este hardware. La versión utilizada fue PaddleOCR 3.3.2.

-

·     DocTR: Se seleccionaron las arquitecturas db_resnet50 para detección y sar_resnet31 para reconocimiento, representando una configuración de alta precisión.

-

Métricas de Evaluación

+

·     DocTR: Se seleccionaron las arquitecturas db_resnet50 para detección y sar_resnet31 para reconocimiento, representando una configuración de alta precisión.

+

Métricas de Evaluación

Se utilizó la biblioteca jiwer para calcular CER y WER de manera estandarizada. La normalización a minúsculas y eliminación de espacios extremos asegura una comparación justa que no penaliza diferencias de capitalización. La implementación está disponible en src/paddle_ocr/paddle_ocr_tuning_rest.py, src/easyocr_service/easyocr_tuning_rest.py y src/doctr_service/doctr_tuning_rest.py.

Resultados del Benchmark

-

Resultados de PaddleOCR (Configuración Baseline)

+

Resultados de PaddleOCR (Configuración Baseline)

Durante el benchmark inicial se evaluó PaddleOCR con configuración por defecto en un subconjunto del dataset. Los resultados preliminares mostraron variabilidad significativa entre páginas, en función de los cambios de formato y de la estructura del texto.

Tabla 22. Variabilidad del error por tipo de contenido.

Tipo de contenido

Nivel de error

Observaciones

Texto corrido

Bajo

Mejor rendimiento

Texto con listas

Medio

Rendimiento intermedio

Índice y encabezados

Medio

Orden de lectura sensible

Encabezados + notas

Medio

Variación tipográfica

Fuente: Elaboración propia a partir del benchmark.

 

Observaciones del benchmark inicial:

-

1.   Las páginas con más cambios de formato y listados presentaron mayor error debido a la dificultad de ordenar correctamente las líneas de texto.

-

1.   La página con texto corrido continuo obtuvo el mejor resultado, demostrando la capacidad del modelo para texto estándar.

-

1.   El promedio general se situó en un rango medio de error, con margen de mejora.

-

1.   Los errores más frecuentes fueron: confusión de acentos, caracteres duplicados, y errores en signos de puntuación.

-

Comparativa de Modelos

+

1.   Las páginas con más cambios de formato y listados presentaron mayor error debido a la dificultad de ordenar correctamente las líneas de texto.

+

2.   La página con texto corrido continuo obtuvo el mejor resultado, demostrando la capacidad del modelo para texto estándar.

+

3.   El promedio general se situó en un rango medio de error, con margen de mejora.

+

4.   Los errores más frecuentes fueron: confusión de acentos, caracteres duplicados, y errores en signos de puntuación.

+

Comparativa de Modelos

Los tres modelos evaluados representan diferentes paradigmas de OCR:

Tabla 23. Comparativa de arquitecturas OCR evaluadas.

Modelo

Tipo

Componentes

Fortalezas Clave

EasyOCR

End-to-end (det + rec)

CRAFT + CRNN/Transformer

Ligero, fácil de usar, multilingüe

PaddleOCR

End-to-end (det + rec + cls)

DB + SVTR/CRNN

Soporte multilingüe robusto, pipeline configurable

DocTR

End-to-end (det + rec)

DB/LinkNet + CRNN/SAR/ViTSTR

Orientado a investigación, API limpia

Fuente: Documentación oficial de cada herramienta (JaidedAI, 2020; PaddlePaddle, 2024; Mindee, 2021).

 

-

Análisis Cualitativo de Errores

+

Análisis Cualitativo de Errores

Un análisis cualitativo de los errores producidos reveló patrones específicos:

Errores de acentuación:

-

·     información → informacion (pérdida de acento)

+

·     información → informacion (pérdida de acento)

·     más → mas (cambio de significado)

-

·     él → el (cambio de significado)

+

·     él → el (cambio de significado)

Errores de caracteres especiales:

-

·     año → ano (pérdida de eñe)

-

·     ¿Cómo → Como (pérdida de signos invertidos)

+

·     año → ano (pérdida de eñe)

+

·     ¿Cómo → Como (pérdida de signos invertidos)

Errores de duplicación:

-

·     titulación → titulacióon (carácter duplicado)

-

·     documento → doccumento (consonante duplicada)

+

·     titulación → titulacióon (carácter duplicado)

+

·     documento → doccumento (consonante duplicada)

Ejemplo de predicción de PaddleOCR para una página:

"Escribe siempre al menos un párrafo de introducción en cada capítulo o apartado, explicando de qué vas a tratar en esa sección. Evita que aparezcan dos encabezados de nivel consecutivos sin ningún texto entre medias. [...] En esta titulacióon se cita de acuerdo con la normativa Apa."

Errores identificados en este ejemplo:

-

·     titulacióon en lugar de titulación (carácter duplicado)

-

·     Apa en lugar de APA (capitalización)

+

·     titulacióon en lugar de titulación (carácter duplicado)

+

·     Apa en lugar de APA (capitalización)

Justificación de la Selección de PaddleOCR

-

Criterios de Selección

+

Criterios de Selección

La selección de PaddleOCR para la fase de optimización se basó en los siguientes criterios:

Tabla 24. Evaluación de criterios de selección (cualitativa).

Criterio

EasyOCR

PaddleOCR

DocTR

CER benchmark

Medio

Mejor

Medio

Configurabilidad

Baja

Alta

Media

Soporte español

Sí

Sí (dedicado)

Limitado

Documentación

Media

Alta

Alta

Mantenimiento

Medio

Alto

Medio

Fuente: Elaboración propia a partir del benchmark y la documentación de cada herramienta.

 

-

Hiperparámetros Disponibles en PaddleOCR

+

Hiperparámetros Disponibles en PaddleOCR

PaddleOCR expone múltiples hiperparámetros ajustables, clasificados por etapa del pipeline:

Detección:

-

·     text_det_thresh: Umbral de probabilidad para píxeles de texto

+

·     text_det_thresh: Umbral de probabilidad para píxeles de texto

·     text_det_box_thresh: Umbral de confianza para cajas detectadas

-

·     text_det_unclip_ratio: Factor de expansión de cajas

+

·     text_det_unclip_ratio: Factor de expansión de cajas

Reconocimiento:

-

·     text_rec_score_thresh: Umbral de confianza para resultados

+

·     text_rec_score_thresh: Umbral de confianza para resultados

Preprocesamiento:

-

·     use_textline_orientation: Clasificación de orientación de línea

+

·     use_textline_orientation: Clasificación de orientación de línea

·     use_doc_orientation_classify: Clasificación de orientación de documento

-

·     use_doc_unwarping: Corrección de deformación

+

·     use_doc_unwarping: Corrección de deformación

Esta riqueza de configuración permite explorar sistemáticamente el espacio de hiperparámetros mediante técnicas de optimización automática.

-

Decisión Final

+

Decisión Final

Se selecciona PaddleOCR (PP-OCRv5) para la fase de optimización debido a:

-

1.   Resultados iniciales prometedores: Rendimiento base competitivo con margen de mejora

+

1.   Resultados iniciales prometedores: Rendimiento base competitivo con margen de mejora

2.   Alta configurabilidad: Múltiples hiperparámetros ajustables en tiempo de inferencia

3.   Pipeline modular: Permite aislar el impacto de cada componente

4.   Soporte activo para español: Modelos específicos y actualizaciones frecuentes

-

5.   Documentación técnica: Descripción detallada de cada parámetro

+

5.   Documentación técnica: Descripción detallada de cada parámetro

Limitaciones del Benchmark

-

1.   Tamaño reducido: Solo 5 páginas evaluadas en el benchmark comparativo inicial. Esto limita la generalización de las conclusiones.

-

1.   Único tipo de documento: Documentos académicos de UNIR únicamente. Otros tipos de documentos (facturas, formularios, contratos) podrían presentar resultados diferentes.

-

1.   Ground truth automático: El texto de referencia se extrajo programáticamente del PDF, lo cual puede introducir errores en el orden de lectura cuando hay secciones con encabezados y saltos de línea.

-

1.   Referencia CPU separada: Los tiempos en CPU se midieron en un experimento independiente y solo se usan como comparación de rendimiento frente a GPU.

+

1.   Tamaño reducido: Solo 5 páginas evaluadas en el benchmark comparativo inicial. Esto limita la generalización de las conclusiones.

+

2.   Único tipo de documento: Documentos académicos de UNIR únicamente. Otros tipos de documentos (facturas, formularios, contratos) podrían presentar resultados diferentes.

+

3.   Ground truth automático: El texto de referencia se extrajo programáticamente del PDF, lo cual puede introducir errores en el orden de lectura cuando hay secciones con encabezados y saltos de línea.

+

4.   Referencia CPU separada: Los tiempos en CPU se midieron en un experimento independiente y solo se usan como comparación de rendimiento frente a GPU.

Síntesis del Benchmark

El benchmark comparativo ha permitido identificar PaddleOCR como la solución más prometedora para la fase de optimización, gracias a su combinación de rendimiento base competitivo, alta configurabilidad del pipeline y documentación técnica completa. Sin embargo, el análisis también reveló limitaciones importantes: el tamaño reducido del benchmark (5 páginas), la restricción a un único tipo de documento, y la extracción automática del ground truth que puede introducir errores en el orden de lectura cuando hay secciones con encabezados y saltos de línea. Estas limitaciones se tendrán en cuenta al interpretar los resultados de la fase de optimización.

Desarrollo de la comparativa: Optimización de hiperparámetros

Introducción

Una vez seleccionado PaddleOCR como motor base, el siguiente paso fue explorar sistemáticamente su espacio de configuración para identificar los hiperparámetros que maximizan el rendimiento en documentos académicos en español. Para ello se empleó Ray Tune con el algoritmo de búsqueda Optuna, una combinación que permite explorar eficientemente espacios de búsqueda mixtos (parámetros continuos y categóricos). Los experimentos se implementaron en src/run_tuning.py con apoyo de la librería src/raytune_ocr.py, almacenándose los resultados en src/results. Esta aproximación ofrece ventajas significativas frente al fine-tuning tradicional: no requiere datasets de entrenamiento etiquetados, no modifica los pesos del modelo preentrenado, y puede ejecutarse con hardware de consumo cuando se dispone de aceleración GPU.

Configuración del Experimento

-

Entorno de Ejecución

+

Entorno de Ejecución

El experimento se ejecutó en el siguiente entorno:

Tabla 25. Entorno de ejecución del experimento.

Componente

Versión/Especificación

Sistema operativo

Ubuntu 24.04.3 LTS

Python

3.12.3

PaddlePaddle

3.2.2

PaddleOCR

3.3.2

Ray

2.52.1

Optuna

4.7.0

CPU

AMD Ryzen 7 5800H

RAM

16 GB DDR4

GPU

NVIDIA RTX 3060 Laptop (5.66 GB VRAM)

Fuente: src/paddle_ocr/requirements.txt, src/raytune/requirements.txt, docs/metrics/metrics.md.

 

-

Arquitectura de Ejecución

+

Arquitectura de Ejecución

La arquitectura basada en contenedores Docker es fundamental para este proyecto debido a los conflictos de dependencias inherentes entre los diferentes componentes:

-

·     Conflictos entre motores OCR: PaddleOCR, DocTR y EasyOCR tienen dependencias mutuamente incompatibles (diferentes versiones de PyTorch/PaddlePaddle, OpenCV, etc.)

+

·     Conflictos entre motores OCR: PaddleOCR, DocTR y EasyOCR tienen dependencias mutuamente incompatibles (diferentes versiones de PyTorch/PaddlePaddle, OpenCV, etc.)

·     Incompatibilidades CUDA/cuDNN: Cada motor OCR requiere versiones específicas de CUDA y cuDNN que no pueden coexistir en un mismo entorno virtual

-

·     Aislamiento de Ray Tune: Ray Tune tiene sus propias dependencias que pueden entrar en conflicto con las librerías de inferencia OCR

+

·     Aislamiento de Ray Tune: Ray Tune tiene sus propias dependencias que pueden entrar en conflicto con las librerías de inferencia OCR

Esta arquitectura containerizada permite ejecutar cada componente en su entorno aislado óptimo, comunicándose vía API REST:

Figura 5. Arquitectura de ejecución con Docker Compose

Arquitectura de ejecución con Docker Compose

Fuente: Elaboración propia.

 

La arquitectura containerizada src/docker-compose.tuning.paddle.yml, src/docker-compose.tuning.doctr.yml, src/docker-compose.tuning.easyocr.yml, src/docker-compose.tuning.yml ofrece:

-

1.   Aislamiento de dependencias entre Ray Tune y los motores OCR

+

1.   Aislamiento de dependencias entre Ray Tune y los motores OCR

2.   Health checks automáticos para asegurar disponibilidad del servicio

3.   Comunicación vía API REST (endpoints /health y /evaluate)

-

4.   Soporte para GPU mediante nvidia-docker

+

4.   Soporte para GPU mediante nvidia-docker

# Iniciar servicio OCR con GPU
 docker compose -f docker-compose.tuning.doctr.yml up -d doctr-gpu
@@ -5239,41 +5239,41 @@ docker compose -f docker-compose.tuning.doctr.yml down
"TIME_PER_PAGE": 3.16 }
-

Infraestructura Docker

+

Infraestructura Docker

La infraestructura del proyecto se basa en contenedores Docker para garantizar reproducibilidad y aislamiento de dependencias. Se generaron seis imágenes Docker, cada una optimizada para su propósito específico.

Tabla 26. Imágenes Docker generadas para el proyecto.

Imagen

Propósito

Base

Puerto

seryus.ddns.net/unir/paddle-ocr-gpu

PaddleOCR con aceleración GPU

nvidia/cuda:12.4.1-cudnn-runtime

8002

seryus.ddns.net/unir/paddle-ocr-cpu

PaddleOCR para entornos sin GPU

python:3.11-slim

8002

seryus.ddns.net/unir/easyocr-gpu

EasyOCR con aceleración GPU

nvidia/cuda:13.0.2-cudnn-runtime

8002*

seryus.ddns.net/unir/doctr-gpu

DocTR con aceleración GPU

nvidia/cuda:13.0.2-cudnn-runtime

8003

seryus.ddns.net/unir/raytune

Orquestador Ray Tune

python:3.12-slim

-

Fuente: Elaboración propia. Dockerfiles disponibles en src/paddle_ocr, src/easyocr_service, src/doctr_service, src/raytune.

 

-

Arquitectura de Microservicios

+

Arquitectura de Microservicios

Figura 6. Arquitectura de microservicios para optimización OCR

Arquitectura de microservicios para optimización OCR

Fuente: Elaboración propia.

 

-

Estrategia de Build Multi-Stage

+

Estrategia de Build Multi-Stage

Los Dockerfiles utilizan una estrategia de build multi-stage para optimizar tiempos de construcción y tamaño de imágenes:

Figura 7. Estrategia de build multi-stage

Estrategia de build multi-stage

Fuente: Elaboración propia.

 

Ventajas de esta estrategia:

-

1.   Caché de dependencias: La etapa base (CUDA + dependencias) se cachea y reutiliza

+

1.   Caché de dependencias: La etapa base (CUDA + dependencias) se cachea y reutiliza

2.   Builds rápidos: Los cambios de código solo reconstruyen la etapa de deploy

-

3.   Imágenes optimizadas: Solo se incluyen los archivos necesarios para ejecución

-

Docker Compose Files

+

3.   Imágenes optimizadas: Solo se incluyen los archivos necesarios para ejecución

+

Docker Compose Files

El proyecto incluye múltiples archivos Docker Compose para diferentes escenarios de uso:

Tabla 27. Archivos Docker Compose del proyecto.

Archivo

Propósito

Servicios

src/docker-compose.tuning.yml

Optimización principal

RayTune + PaddleOCR + DocTR

src/docker-compose.tuning.easyocr.yml

Optimización EasyOCR

RayTune + EasyOCR

src/docker-compose.tuning.paddle.yml

Optimización PaddleOCR

RayTune + PaddleOCR

src/docker-compose.tuning.doctr.yml

Optimización DocTR

RayTune + DocTR

Fuente: src/docker-compose.tuning.yml, src/docker-compose.tuning.easyocr.yml, src/docker-compose.tuning.paddle.yml, src/docker-compose.tuning.doctr.yml.

 

Nota: EasyOCR y PaddleOCR utilizan el mismo puerto (8002). Debido a limitaciones de recursos GPU (VRAM insuficiente para ejecutar múltiples modelos OCR simultáneamente), solo se ejecuta un servicio a la vez durante los experimentos. Por esta razón, EasyOCR tiene su propio archivo Docker Compose separado.

-

Gestión de Volúmenes

+

Gestión de Volúmenes

Se utilizan volúmenes Docker nombrados para persistir los modelos descargados entre ejecuciones:

Tabla 28. Volúmenes Docker para caché de modelos.

Volumen

Servicio

Contenido

paddlex-model-cache

PaddleOCR

Modelos PP-OCRv5

easyocr-model-cache

EasyOCR

Modelos CRAFT + CRNN

doctr-model-cache

DocTR

Modelos db_resnet50 + crnn_vgg16_bn

Fuente: src/docker-compose.tuning.yml, src/docker-compose.tuning.easyocr.yml, src/docker-compose.tuning.paddle.yml, src/docker-compose.tuning.doctr.yml.

 

-

Health Checks y Monitorización

+

Health Checks y Monitorización

Todos los servicios implementan health checks para garantizar disponibilidad antes de iniciar la optimización:

healthcheck:
@@ -5284,15 +5284,15 @@ docker compose -f docker-compose.tuning.doctr.yml down
start_period: 60s # PaddleOCR: 60s, EasyOCR: 120s, DocTR: 180s

Los tiempos de start_period varían según el servicio debido al tiempo de carga de modelos:

-

·     PaddleOCR: 60 segundos (modelos más ligeros)

+

·     PaddleOCR: 60 segundos (modelos más ligeros)

·     EasyOCR: 120 segundos (carga de modelos CRAFT)

-

·     DocTR: 180 segundos (modelos ResNet más pesados)

-

Flujo de Ejecución Completo

+

·     DocTR: 180 segundos (modelos ResNet más pesados)

+

Flujo de Ejecución Completo

Figura 8. Flujo de ejecución de optimización con Ray Tune

Flujo de ejecución de optimización con Ray Tune

Fuente: Elaboración propia.

 

-

Reproducibilidad

+

Reproducibilidad

Para reproducir los experimentos:

# 1. Clonar repositorio
@@ -5316,28 +5316,28 @@ ls -la results/raytune_paddle_results_*.csv
 docker compose -f docker-compose.tuning.paddle.yml down

Los resultados de los experimentos están disponibles en:

-

·     src/results/raytune_paddle_results_20260119_122609.csv

+

·     src/results/raytune_paddle_results_20260119_122609.csv

·     src/results/raytune_easyocr_results_20260119_120204.csv

·     src/results/raytune_doctr_results_20260119_121445.csv

-

·     src/raytune_paddle_subproc_results_20251207_192320.csv

-

Dataset Extendido

+

·     src/raytune_paddle_subproc_results_20251207_192320.csv

+

Dataset Extendido

Para la fase de optimización se extendió el dataset:

Tabla 29. Características del dataset de optimización.

Característica

Valor

Páginas del dataset completo

45

Páginas por trial

5 (páginas 5-10)

Estructura

Carpetas img/ y txt/ pareadas

Resolución

300 DPI

Formato imagen

PNG

Fuente: docs/metrics/metrics.md, src/prepare_dataset.ipynb.

 

La clase ImageTextDataset gestiona la carga de pares imagen-texto desde la estructura de carpetas pareadas. La implementación está disponible en src/paddle_ocr/dataset_manager.py, src/easyocr_service/dataset_manager.py y src/doctr_service/dataset_manager.py.

-

Espacio de Búsqueda

+

Espacio de Búsqueda

El espacio de búsqueda se definió considerando los hiperparámetros más relevantes identificados en la documentación de PaddleOCR, utilizando tune.choice() para parámetros booleanos y tune.uniform() para umbrales continuos. La implementación está disponible en src/raytune/raytune_ocr.py (ver Anexo A).

Tabla 30. Descripción detallada del espacio de búsqueda.

Parámetro

Tipo

Rango

Descripción

use_doc_orientation_classify

Booleano

{True, False}

Clasificación de orientación del documento completo

use_doc_unwarping

Booleano

{True, False}

Corrección de deformación/curvatura

textline_orientation

Booleano

{True, False}

Clasificación de orientación por línea de texto

text_det_thresh

Continuo

[0.0, 0.7]

Umbral de probabilidad para píxeles de texto

text_det_box_thresh

Continuo

[0.0, 0.7]

Umbral de confianza para cajas detectadas

text_det_unclip_ratio

Fijo

0.0

Coeficiente de expansión (no explorado)

text_rec_score_thresh

Continuo

[0.0, 0.7]

Umbral de confianza de reconocimiento

Fuente: Documentación de PaddleOCR.

 

Justificación del espacio:

-

1.   Rango [0.0, 0.7] para umbrales: Se evitan valores extremos (>0.7) que podrían filtrar demasiado texto válido, y se incluye 0.0 para evaluar el impacto de desactivar el filtrado.

-

1.   text_det_unclip_ratio fijo: Por decisión de diseño inicial, este parámetro se mantuvo constante para reducir la dimensionalidad del espacio de búsqueda.

-

1.   Parámetros booleanos completos: Los tres parámetros de preprocesamiento se exploran completamente para identificar cuáles son necesarios para documentos digitales.

-

Configuración de Ray Tune

+

1.   Rango [0.0, 0.7] para umbrales: Se evitan valores extremos (>0.7) que podrían filtrar demasiado texto válido, y se incluye 0.0 para evaluar el impacto de desactivar el filtrado.

+

2.   text_det_unclip_ratio fijo: Por decisión de diseño inicial, este parámetro se mantuvo constante para reducir la dimensionalidad del espacio de búsqueda.

+

3.   Parámetros booleanos completos: Los tres parámetros de preprocesamiento se exploran completamente para identificar cuáles son necesarios para documentos digitales.

+

Configuración de Ray Tune

Se configuró Ray Tune con OptunaSearch como algoritmo de búsqueda, optimizando CER en 64 trials con 2 ejecuciones concurrentes. La implementación está disponible en src/raytune/raytune_ocr.py (ver Anexo A).

Tabla 31. Parámetros de configuración de Ray Tune.

Parámetro

Valor

Justificación

Métrica objetivo

CER

Métrica estándar para OCR

Modo

min

Minimizar tasa de error

Algoritmo

OptunaSearch (TPE)

Eficiente para espacios mixtos

Número de trials

64

Balance entre exploración y tiempo

Trials concurrentes

2

Limitado por memoria disponible

@@ -5346,23 +5346,23 @@ docker compose -f docker-compose.tuning.paddle.yml down

Elección de 64 trials:

El número de trials se eligió buscando un equilibrio entre exploración del espacio de búsqueda y tiempo total de ejecución.

Resultados de la Optimización

-

Ejecución del Experimento

+

Ejecución del Experimento

El experimento se ejecutó exitosamente con los siguientes resultados globales:

Tabla 32. Resumen de la ejecución del experimento (referencia CPU).

Métrica

Valor

Trials completados

64/64

Trials fallidos

0

Tiempo total (CPU)

6.2 horas

Tiempo medio por trial (CPU)

347.6 segundos

Páginas procesadas

320 (64 trials x 5 páginas)

Fuente: src/raytune_paddle_subproc_results_20251207_192320.csv.

 

-

Estadísticas Descriptivas

+

Estadísticas Descriptivas

Del archivo CSV de resultados src/results/raytune_paddle_results_20260119_122609.csv:

Tabla 33. Estadísticas descriptivas de los 64 trials.

Estadística

CER

WER

Tiempo/Página (s)

count

64

64

64

mean

2.30%

9.25%

0.84

std

2.20%

1.78%

0.53

min

0.79%

6.80%

0.56

50% (mediana)

0.87%

8.39%

0.59

max

7.30%

13.20%

2.22

Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

 

Observaciones:

-

1.   Baja varianza en CER: La desviación estándar (2.20%) es similar a la media (2.30%), indicando una distribución relativamente consistente sin valores extremos catastróficos.

-

1.   Mediana vs Media: La mediana del CER (0.87%) es menor que la media (2.30%), confirmando una distribución ligeramente sesgada hacia valores bajos.

-

1.   Velocidad GPU: El tiempo de ejecución promedio es de 0.84 s/página, lo que representa una aceleración significativa respecto a la ejecución en CPU (~69 s/página, 82x más rápido).

-

Distribución de Resultados

+

1.   Baja varianza en CER: La desviación estándar (2.20%) es similar a la media (2.30%), indicando una distribución relativamente consistente sin valores extremos catastróficos.

+

2.   Mediana vs Media: La mediana del CER (0.87%) es menor que la media (2.30%), confirmando una distribución ligeramente sesgada hacia valores bajos.

+

3.   Velocidad GPU: El tiempo de ejecución promedio es de 0.84 s/página, lo que representa una aceleración significativa respecto a la ejecución en CPU (~69 s/página, 82x más rápido).

+

Distribución de Resultados

Tabla 34. Distribución de trials por rango de CER.

Rango CER

Número de trials

Porcentaje

< 2%

43

67.2%

2% - 5%

10

15.6%

5% - 10%

11

17.2%

> 10%

0

0.0%

Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

@@ -5372,7 +5372,7 @@ docker compose -f docker-compose.tuning.paddle.yml down

Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

 

La mayoría de trials (67.2%) alcanzaron CER < 2%, cumpliendo el objetivo establecido. Ningún trial presentó fallos catastróficos (CER > 10%), demostrando la estabilidad de la optimización con GPU.

-

Mejor Configuración Encontrada

+

Mejor Configuración Encontrada

La configuración que minimizó el CER fue:

Best CER: 0.007884 (0.79%)
@@ -5391,7 +5391,7 @@ Configuración óptima:
 
Parámetro
Valor óptimo
Valor por defecto
Cambio
textline_orientation
True
False
Activado
use_doc_orientation_classify
True
False
Activado
use_doc_unwarping
False
False
Sin cambio
text_det_thresh
0.0462
0.3
-0.254
text_det_box_thresh
0.4862
0.6
-0.114
text_det_unclip_ratio
0.0
1.5
-1.5 (fijado)
text_rec_score_thresh
0.5658
0.5
+0.066

 
Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

 
 

-
Análisis de Correlación

+
Análisis de Correlación

 
Se calculó la correlación de Pearson entre los parámetros de configuración (codificados como 0/1 en el caso de booleanos) y las métricas de error:

 
Tabla 36. Correlación de parámetros con CER.

 
Parámetro
Correlación con CER
Interpretación
use_doc_unwarping
+0.879
Correlación alta positiva
use_doc_orientation_classify
-0.712
Correlación alta negativa
textline_orientation
-0.535
Correlación moderada negativa
text_det_thresh
+0.428
Correlación moderada positiva
text_det_box_thresh
+0.311
Correlación moderada positiva
text_rec_score_thresh
-0.268
Correlación moderada negativa
text_det_unclip_ratio
NaN
Varianza cero (valor fijo)

@@ -5404,26 +5404,26 @@ Configuración óptima:
 
Figura 10. Correlación de hiperparámetros con CER

 
Correlación de hiperparámetros con CER

 
Fuente: src/results/correlations/paddle_correlations.csv.

+
Leyenda: Valores positivos indican que aumentar el parámetro incrementa el CER. Los parámetros booleanos se codifican como 0/1 para el cálculo de la correlación. Abreviaturas: unwarp = use_doc_unwarping, orient_doc = use_doc_orientation_classify, orient_line = textline_orientation, det_thresh = text_det_thresh, box_thresh = text_det_box_thresh, rec_score = text_rec_score_thresh.

 
 

-
Leyenda: Valores positivos indican que aumentar el parámetro incrementa el CER. Los parámetros booleanos se codifican como 0/1 para el cálculo de la correlación. Abreviaturas: unwarp = use_doc_unwarping, orient_doc = use_doc_orientation_classify, orient_line = textline_orientation, det_thresh = text_det_thresh, box_thresh = text_det_box_thresh, rec_score = text_rec_score_thresh.

 
Hallazgo clave: use_doc_unwarping presenta la correlación positiva más alta con CER (0.879), lo que indica que activar este módulo incrementa el error en este dataset. En cambio, use_doc_orientation_classify y textline_orientation tienen correlación negativa, asociada a mejoras cuando están activados.

-
Impacto del Parámetro textline_orientation

+
Impacto del Parámetro textline_orientation

 
El parámetro booleano textline_orientation demostró tener el mayor impacto en el rendimiento:

 
Tabla 38. Impacto del parámetro textline_orientation.

 
textline_orientation
CER Medio
CER Std
WER Medio
N trials
True
1.74%
1.94%
8.75%
52
False
4.73%
1.37%
11.42%
12

 
Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

 
 

 
Interpretación:

-
1.   Reducción del CER: Con textline_orientation=True, el CER medio es 2.7 veces menor (1.74% vs 4.73%).

-
1.   Varianza: La desviación estándar es mayor cuando textline_orientation=True (1.94% vs 1.37%), aunque los valores medios siguen siendo mejores.

-
1.   Reducción del CER: 63.2% cuando se habilita la clasificación de orientación de línea.

+
1.   Reducción del CER: Con textline_orientation=True, el CER medio es 2.7 veces menor (1.74% vs 4.73%).

+
2.   Varianza: La desviación estándar es mayor cuando textline_orientation=True (1.94% vs 1.37%), aunque los valores medios siguen siendo mejores.

+
3.   Reducción del CER: 63.2% cuando se habilita la clasificación de orientación de línea.

 
Figura 11. Impacto de textline_orientation en CER

 
Impacto de textline_orientation en CER

 
Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

 
 

 
Explicación técnica:

 
El parámetro textline_orientation activa un clasificador que determina la orientación de cada línea de texto detectada. Para documentos con índice, encabezados y listas, este clasificador asegura que el texto se lea en el orden correcto, evitando la mezcla de líneas de diferentes secciones.

-
Análisis de Trials con Mayor CER

+
Análisis de Trials con Mayor CER

 
No se observaron fallos catastróficos (CER > 10%). El CER máximo fue 7.30%, por lo que el análisis se centra en los trials con peor desempeño relativo:

 
Tabla 39. Trials con mayor CER.

 
Trial ID
CER
text_det_thresh
textline_orientation
f699b826
7.30%
0.285
False
34bfaecf
7.29%
0.030
True
8c1998de
6.44%
0.369
True
8b33e2a2
6.41%
0.664
False

@@ -5431,14 +5431,14 @@ Configuración óptima:
 
 

 
Observación: Los peores resultados muestran variabilidad tanto en text_det_thresh como en textline_orientation, sin un patrón único dominante en este subconjunto de trials.

 
Comparación Baseline vs Optimizado

-
Evaluación sobre Dataset Completo

+
Evaluación sobre Dataset Completo

 
La configuración óptima identificada se evaluó sobre el dataset completo de 45 páginas, comparando con la configuración baseline (valores por defecto de PaddleOCR). Los parámetros optimizados más relevantes fueron: textline_orientation=True, use_doc_orientation_classify=True, text_det_thresh=0.0462, text_det_box_thresh=0.4862, y text_rec_score_thresh=0.5658.

 
Tabla 40. Comparación baseline vs optimizado (45 páginas).

 
Modelo
CER
Precisión Caracteres
WER
Precisión Palabras
PaddleOCR (Baseline)
8.85%
91.15%
13.05%
86.95%
PaddleOCR-HyperAdjust
7.72%
92.28%
11.40%
88.60%

 
Fuente: docs/metrics/metrics_paddle.md.

 
 

 
Nota sobre generalización: El mejor trial individual (5 páginas) alcanzó un CER de 0.79%, cumpliendo el objetivo de CER < 2%. Sin embargo, al aplicar la configuración al dataset completo de 45 páginas, el CER aumentó a 7.72%, evidenciando sobreajuste al subconjunto de entrenamiento. Esta diferencia es un hallazgo importante que se discute en la sección de análisis.

-
Métricas de Mejora

+
Métricas de Mejora

 
Tabla 41. Análisis cuantitativo de la mejora.

 
Forma de Medición
CER
WER
Valor baseline
8.85%
13.05%
Valor optimizado
7.72%
11.40%
Mejora absoluta
-1.13 pp
-1.65 pp
Reducción relativa del error
12.8%
12.6%
Factor de mejora
1.15x
1.14x
Mejor trial (5 páginas)
0.79%
7.78%

 
Fuente: docs/metrics/metrics_paddle.md.

@@ -5446,9 +5446,9 @@ Configuración óptima:
 
Figura 12. Reducción de errores: Baseline vs Optimizado (45 páginas)

 
Reducción de errores: Baseline vs Optimizado (45 páginas)

 
Fuente: docs/metrics/metrics_paddle.md.

+
Leyenda: CER = Character Error Rate, WER = Word Error Rate. Baseline = configuración por defecto de PaddleOCR. Optimizado = configuración encontrada por Ray Tune. Los valores corresponden al dataset completo de 45 páginas.

 
 

-
Leyenda: CER = Character Error Rate, WER = Word Error Rate. Baseline = configuración por defecto de PaddleOCR. Optimizado = configuración encontrada por Ray Tune. Los valores corresponden al dataset completo de 45 páginas.

-
Impacto Práctico

+
Impacto Práctico

 
La reducción de CER y WER implica menos correcciones manuales en el texto reconocido. En conjunto, los resultados muestran una mejora medible en precisión, aunque la generalización depende del tamaño y representatividad del subconjunto de optimización.

 
Tiempo de Ejecución

 
Tabla 42. Métricas de tiempo del experimento (GPU).

@@ -5456,9 +5456,9 @@ Configuración óptima:
 
Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

 
 

 
Observaciones:

-
1.   El tiempo por página (~0.84 segundos) corresponde a ejecución con GPU (RTX 3060).

+
1.   El tiempo por página (~0.84 segundos) corresponde a ejecución con GPU (RTX 3060).

 
2.   La variabilidad del tiempo es moderada (std = 0.53 s/página), con algunos trials más lentos debido a configuraciones con módulos de preprocesamiento activos.

-
3.   En comparación, la ejecución en CPU requiere ~69 segundos/página (82x más lento), lo que justifica el uso de GPU para optimización y producción.

+
3.   En comparación, la ejecución en CPU requiere ~69 segundos/página (82x más lento), lo que justifica el uso de GPU para optimización y producción.

 
Síntesis de la Optimización

 
Los 64 trials ejecutados con Ray Tune y aceleración GPU revelaron patrones claros en el comportamiento de PaddleOCR. El hallazgo más significativo es que los parámetros estructurales, textline_orientation y use_doc_orientation_classify, tienen mayor impacto que los umbrales numéricos. Al activarlos se reduce el CER medio de 4.73% a 1.74%. En cuanto a umbrales, valores bajos de text_det_thresh (aprox. 0.05) benefician el rendimiento, mientras que use_doc_unwarping resulta innecesario para PDFs digitales.

 
El mejor trial alcanzó un CER de 0.79%, cumpliendo el objetivo de CER < 2%. No obstante, la validación sobre el dataset completo de 45 páginas arrojó un CER de 7.72%, evidenciando sobreajuste al subconjunto de optimización de 5 páginas. Aun así, esto representa una mejora del 12.8% respecto al baseline (8.85%), demostrando el valor de la optimización sistemática incluso cuando la generalización es imperfecta.

@@ -5466,7 +5466,7 @@ Configuración óptima:
 
Introducción

 
Los resultados obtenidos en las secciones anteriores requieren un análisis que trascienda los números individuales para comprender su significado práctico. En esta sección se consolidan los hallazgos del benchmark comparativo y la optimización de hiperparámetros, evaluando hasta qué punto se han cumplido los objetivos planteados y qué limitaciones condicionan la generalización de las conclusiones.

 
Resumen Consolidado de Resultados

-
Progresión del Rendimiento

+
Progresión del Rendimiento

 
Tabla 43. Evolución del rendimiento a través del estudio.

 
Fase
Configuración
CER
Mejora vs baseline
Benchmark inicial
Baseline (5 páginas)
7.76%
-
Optimización (mejor trial)
Optimizada (5 páginas)
0.79%
89.8%
Validación final
Optimizada (45 páginas)
7.72%
12.8%

 
Fuente: docs/metrics/metrics_paddle.md.

@@ -5474,17 +5474,17 @@ Configuración óptima:
 
Figura 13. Evolución del CER a través del estudio

 
Evolución del CER a través del estudio

 
Fuente: docs/metrics/metrics_paddle.md.

+
Leyenda: El mejor trial alcanza CER 0.79% (objetivo cumplido). La validación sobre dataset completo muestra CER 7.72%, evidenciando sobreajuste al subconjunto de optimización.

 
 

-
Leyenda: El mejor trial alcanza CER 0.79% (objetivo cumplido). La validación sobre dataset completo muestra CER 7.72%, evidenciando sobreajuste al subconjunto de optimización.

 
El incremento del CER de 0.79% (5 páginas) a 7.72% (45 páginas) evidencia sobreajuste al subconjunto de optimización. Este fenómeno es esperado cuando se optimiza sobre un subconjunto pequeño y se valida sobre el dataset completo con mayor diversidad de secciones y estilos.

-
Comparación con Objetivo

+
Comparación con Objetivo

 
Tabla 44. Verificación del objetivo general.

 
Aspecto
Objetivo
Resultado (trial)
Resultado (full)
Cumplimiento
Métrica
CER
CER
CER
✓
Umbral
< 2%
0.79%
7.72%
Parcial
Método
Sin fine-tuning
Solo hiperparámetros
Solo hiperparámetros
✓
Hardware
GPU
RTX 3060
RTX 3060
✓

 
Fuente: docs/metrics/metrics_paddle.md.

 
 

 
Análisis del cumplimiento: El objetivo de CER < 2% se cumple en el mejor trial individual (0.79%), demostrando que la optimización de hiperparámetros puede alcanzar la precisión objetivo. Sin embargo, la validación sobre el dataset completo (7.72%) muestra que la generalización requiere trabajo adicional, como un subconjunto de optimización más representativo o técnicas de regularización.

 
Análisis Detallado de Hiperparámetros

-
Jerarquía de Importancia

+
Jerarquía de Importancia

 
Basándose en el análisis de los resultados de optimización:

 
Tabla 45. Ranking de importancia de hiperparámetros.

 
Rank
Parámetro
Pearson (CER)
Signo
Evidencia
1
use_doc_unwarping
0.879
Positivo
Correlación más alta con CER
2
use_doc_orientation_classify
-0.712
Negativo
Correlación alta con CER
3
textline_orientation
-0.535
Negativo
Correlación alta con CER
4
text_det_thresh
0.428
Positivo
Correlación moderada con CER
5
text_det_box_thresh
0.311
Positivo
Correlación moderada con CER
6
text_rec_score_thresh
-0.268
Negativo
Correlación moderada con CER

@@ -5493,36 +5493,36 @@ Configuración óptima:
 
Figura 14. Ranking de importancia de hiperparámetros

 
Ranking de importancia de hiperparámetros

 
Fuente: src/results/correlations/paddle_correlations.csv.

+
Leyenda: Impacto relativo basado en |Pearson| (CER), normalizado respecto al valor máximo.

 
 

-
Leyenda: Impacto relativo basado en |Pearson| (CER), normalizado respecto al valor máximo.

 
En términos de correlación lineal, use_doc_unwarping es el parámetro con mayor relación absoluta con el CER y su signo positivo indica que activarlo incrementa el error en este dataset. En cambio, use_doc_orientation_classify y textline_orientation presentan correlación negativa, lo que sugiere mejoras cuando están activados.

-
Análisis del Parámetro textline_orientation

+
Análisis del Parámetro textline_orientation

 
Por qué es tan importante:

 
El clasificador de orientación de línea resuelve un problema fundamental en documentos con secciones y cambios de formato: determinar el orden correcto de lectura. Sin este clasificador:

-
1.   Las líneas del índice pueden mezclarse con el cuerpo del texto

+
1.   Las líneas del índice pueden mezclarse con el cuerpo del texto

 
2.   Los encabezados pueden insertarse en posiciones incorrectas

-
3.   Las listas numeradas pueden leerse en orden incorrecto

+
3.   Las listas numeradas pueden leerse en orden incorrecto

 
Para documentos académicos que típicamente incluyen índice, listas y encabezados multinivel, este clasificador es esencial.

 
Recomendación: Siempre activar textline_orientation=True para documentos estructurados.

-
Análisis del Parámetro text_det_thresh

+
Análisis del Parámetro text_det_thresh

 
Comportamiento observado:

 
El análisis de correlación muestra que valores más bajos de text_det_thresh favorecen el rendimiento en este dataset. El valor óptimo encontrado en los trials fue 0.0462, lo que sugiere que una detección más sensible beneficia el resultado.

-
Análisis de Parámetros de Preprocesamiento

+
Análisis de Parámetros de Preprocesamiento

 
use_doc_orientation_classify:

 
En la configuración óptima GPU, este parámetro está activado (True), a diferencia de lo observado en experimentos anteriores. Esto sugiere que la clasificación de orientación del documento puede beneficiar incluso documentos digitales cuando se combina con textline_orientation=True.

 
use_doc_unwarping:

 
Este módulo permanece desactivado en la configuración óptima. Está diseñado para:

-
·     Documentos escaneados con rotación

+
·     Documentos escaneados con rotación

 
·     Fotografías de documentos con perspectiva

-
·     Documentos curvados o deformados

+
·     Documentos curvados o deformados

 
Para documentos PDF digitales como los evaluados, este módulo es innecesario y puede introducir artefactos.

 
Análisis de Casos de Fallo

-
Clasificación de Errores

+
Clasificación de Errores

 
Tabla 46. Tipología de errores observados.

 
Tipo de error
Frecuencia
Ejemplo
Causa probable
Pérdida de acentos
Alta
más → mas
Modelo de reconocimiento
Duplicación de caracteres
Media
titulación → titulacióon
Solapamiento de detecciones
Confusión de puntuación
Media
¿ → ?
Caracteres similares
Pérdida de eñe
Baja
año → ano
Modelo de reconocimiento
Texto desordenado
Variable
Mezcla de líneas
Fallo de orientación

 
Fuente: Análisis cualitativo.

 
 

-
Patrones de Fallo por Tipo de Contenido

+
Patrones de Fallo por Tipo de Contenido

 
Tabla 47. Tasa de error por tipo de contenido (cualitativa).

 
Tipo de contenido
Nivel de error
Factor de riesgo
Párrafos de texto
Bajo
Bajo
Listas numeradas
Medio
Medio
Índice y encabezados
Medio
Medio
Encabezados + pie de página
Medio
Medio
Texto con cambios tipográficos
Medio
Medio
Listas con numeración densa
Alto
Alto

 
Fuente: Estimación cualitativa.

@@ -5534,43 +5534,43 @@ Configuración óptima:
 
 

 
Nota sobre OE5: El objetivo de CER < 2% se cumple en el mejor trial individual (0.79%). La validación sobre el dataset completo (7.72%) muestra que la generalización requiere mayor trabajo, identificándose como línea de trabajo futuro.

 
Limitaciones del Estudio

-
Limitaciones de Generalización

-
1.   Tipo de documento único: Solo se evaluaron documentos académicos de UNIR. La configuración óptima puede no ser transferible a otros tipos de documentos (facturas, formularios, contratos).

-
1.   Idioma único: El estudio se centró en español. Otros idiomas con diferentes características ortográficas podrían requerir configuraciones diferentes.

-
1.   Formato único: Solo se evaluaron PDFs digitales. Documentos escaneados o fotografías de documentos podrían beneficiarse de diferentes configuraciones.

-
Limitaciones Metodológicas

-
1.   Ground truth automático: El texto de referencia se extrajo programáticamente del PDF, lo cual puede introducir errores en el orden de lectura cuando hay secciones con encabezados y saltos de línea.

-
1.   Tamaño del dataset: 45 páginas es un dataset limitado. Un dataset más amplio proporcionaría estimaciones más robustas.

-
1.   Parámetro fijo: text_det_unclip_ratio se mantuvo en 0.0 durante todo el experimento. Explorar este parámetro podría revelar mejoras adicionales.

-
1.   Subconjunto de ajuste limitado: El ajuste de hiperparámetros se realizó sobre 5 páginas (páginas 5-10), lo que contribuyó al sobreajuste observado en la validación del dataset completo.

-
Limitaciones de Validación

-
1.   Sin validación cruzada: No se realizó validación cruzada sobre diferentes subconjuntos del dataset.

-
1.   Sin test set independiente: El dataset de validación final se solapaba parcialmente con el de optimización.

+
Limitaciones de Generalización

+
1.   Tipo de documento único: Solo se evaluaron documentos académicos de UNIR. La configuración óptima puede no ser transferible a otros tipos de documentos (facturas, formularios, contratos).

+
2.   Idioma único: El estudio se centró en español. Otros idiomas con diferentes características ortográficas podrían requerir configuraciones diferentes.

+
3.   Formato único: Solo se evaluaron PDFs digitales. Documentos escaneados o fotografías de documentos podrían beneficiarse de diferentes configuraciones.

+
Limitaciones Metodológicas

+
1.   Ground truth automático: El texto de referencia se extrajo programáticamente del PDF, lo cual puede introducir errores en el orden de lectura cuando hay secciones con encabezados y saltos de línea.

+
2.   Tamaño del dataset: 45 páginas es un dataset limitado. Un dataset más amplio proporcionaría estimaciones más robustas.

+
3.   Parámetro fijo: text_det_unclip_ratio se mantuvo en 0.0 durante todo el experimento. Explorar este parámetro podría revelar mejoras adicionales.

+
4.   Subconjunto de ajuste limitado: El ajuste de hiperparámetros se realizó sobre 5 páginas (páginas 5-10), lo que contribuyó al sobreajuste observado en la validación del dataset completo.

+
Limitaciones de Validación

+
1.   Sin validación cruzada: No se realizó validación cruzada sobre diferentes subconjuntos del dataset.

+
2.   Sin test set independiente: El dataset de validación final se solapaba parcialmente con el de optimización.

 
Implicaciones Prácticas

-
Guía de Configuración Recomendada

+
Guía de Configuración Recomendada

 
Para documentos académicos en español similares a los evaluados:

 
Tabla 49. Configuración recomendada para PaddleOCR con GPU.

 
Parámetro
Valor
Prioridad
Justificación
textline_orientation
True
Obligatorio
Crítico para documentos con secciones
use_doc_orientation_classify
True
Recomendado
Mejora orientación de documento
text_det_thresh
0.05 (rango: 0.04-0.10)
Recomendado
Detección sensible beneficia resultados
text_det_box_thresh
0.49 (rango: 0.4-0.6)
Recomendado
Balance de confianza
text_rec_score_thresh
0.57 (rango: 0.5-0.7)
Opcional
Filtra reconocimientos poco confiables
use_doc_unwarping
False
No recomendado
Innecesario para PDFs digitales

 
Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

 
 

-
Cuándo Aplicar Esta Metodología

+
Cuándo Aplicar Esta Metodología

 
La optimización de hiperparámetros es recomendable cuando:

-
1.   GPU disponible: Acelera significativamente la exploración del espacio de hiperparámetros (82x más rápido que CPU).

-
1.   Modelo preentrenado adecuado: El modelo ya soporta el idioma objetivo (como PaddleOCR para español).

-
1.   Dominio específico: Se busca optimizar para un tipo de documento particular.

-
1.   Mejora incremental: El rendimiento baseline es aceptable pero mejorable.

-
1.   Sin datos de entrenamiento: No se dispone de datasets etiquetados para fine-tuning.

-
Cuándo NO Aplicar Esta Metodología

+
1.   GPU disponible: Acelera significativamente la exploración del espacio de hiperparámetros (82x más rápido que CPU).

+
2.   Modelo preentrenado adecuado: El modelo ya soporta el idioma objetivo (como PaddleOCR para español).

+
3.   Dominio específico: Se busca optimizar para un tipo de documento particular.

+
4.   Mejora incremental: El rendimiento baseline es aceptable pero mejorable.

+
5.   Sin datos de entrenamiento: No se dispone de datasets etiquetados para fine-tuning.

+
Cuándo NO Aplicar Esta Metodología

 
La optimización de hiperparámetros puede ser insuficiente cuando:

-
1.   Idioma no soportado: El modelo no incluye el idioma en su vocabulario.

-
1.   Escritura manuscrita: Requiere fine-tuning o modelos especializados.

-
1.   Documentos muy degradados: Escaneos de baja calidad o documentos históricos.

-
1.   Requisitos de CER muy bajo: Puede requerir fine-tuning para alcanzar precisiones muy altas.

+
1.   Idioma no soportado: El modelo no incluye el idioma en su vocabulario.

+
2.   Escritura manuscrita: Requiere fine-tuning o modelos especializados.

+
3.   Documentos muy degradados: Escaneos de baja calidad o documentos históricos.

+
4.   Requisitos de CER muy bajo: Puede requerir fine-tuning para alcanzar precisiones muy altas.

 
Síntesis del Capítulo

 
A lo largo de este capítulo se ha desarrollado el proceso completo de evaluación y optimización de sistemas OCR para documentos académicos en español. El benchmark comparativo inicial permitió seleccionar PaddleOCR como motor base gracias a su combinación de rendimiento y configurabilidad. La posterior optimización con Ray Tune y Optuna, ejecutada sobre 64 trials con aceleración GPU, identificó los parámetros críticos para maximizar el rendimiento: textline_orientation, use_doc_orientation_classify y text_det_thresh.

 
Los resultados cuantifican tanto los logros como las limitaciones del enfoque. El mejor trial individual alcanzó un CER de 0.79%, cumpliendo holgadamente el objetivo de CER < 2%. Sin embargo, la validación sobre el dataset completo de 45 páginas reveló un CER de 7.72%, lo que representa una mejora del 12.8% respecto al baseline (8.85%) pero evidencia sobreajuste al subconjunto de optimización. Esta observación es valiosa: indica que futuros trabajos deberían emplear subconjuntos de optimización más representativos o aplicar técnicas de regularización.

 
Desde el punto de vista práctico, la infraestructura dockerizada desarrollada y la aceleración GPU (82x más rápida que CPU) demuestran la viabilidad de esta metodología tanto para experimentación como para despliegue en producción.

-
·     src/run_tuning.py - Script principal de optimización

+
·     src/run_tuning.py - Script principal de optimización

 
·     src/raytune/requirements.txt - Dependencias del orquestador Ray Tune

 
·     src/paddle_ocr/requirements.txt - Dependencias del servicio PaddleOCR

 
·     src/easyocr_service/requirements.txt - Dependencias del servicio EasyOCR

@@ -5579,21 +5579,21 @@ Configuración óptima:
 
·     src/results/correlations/paddle_correlations.csv - Correlaciones de hiperparámetros (PaddleOCR)

 
·     src/results/raytune_easyocr_results_20260119_120204.csv - Resultados CSV de EasyOCR

 
·     src/results/raytune_doctr_results_20260119_121445.csv - Resultados CSV de DocTR

-
·     src/raytune_paddle_subproc_results_20251207_192320.csv - Referencia de tiempos en CPU para PaddleOCR

+
·     src/raytune_paddle_subproc_results_20251207_192320.csv - Referencia de tiempos en CPU para PaddleOCR

 
Imágenes Docker:

-
·     seryus.ddns.net/unir/paddle-ocr-gpu - PaddleOCR con soporte GPU

+
·     seryus.ddns.net/unir/paddle-ocr-gpu - PaddleOCR con soporte GPU

 
·     seryus.ddns.net/unir/easyocr-gpu - EasyOCR con soporte GPU

-
·     seryus.ddns.net/unir/doctr-gpu - DocTR con soporte GPU

+
·     seryus.ddns.net/unir/doctr-gpu - DocTR con soporte GPU

 
Comparativa de Rendimiento CPU vs GPU

 
Esta sección presenta la comparación de rendimiento entre ejecución en CPU y GPU, justificando la elección de GPU para el experimento principal y demostrando el impacto práctico de la aceleración por hardware.

-
Configuración del Entorno GPU

+
Configuración del Entorno GPU

 
Tabla 50. Especificaciones del entorno GPU utilizado.

 
Componente
Especificación
GPU
NVIDIA GeForce RTX 3060 Laptop
VRAM
5.66 GB
CUDA
12.4
Sistema Operativo
Ubuntu 24.04.3 LTS
Kernel
6.14.0-37-generic

 
Fuente: docs/metrics/metrics.md.

 
 

 
Nota: Los requisitos de entorno documentados por dependencias se detallan en docs/07_anexo_a.md, sección A.9.

 
Este hardware representa configuración típica de desarrollo, permitiendo evaluar el rendimiento en condiciones realistas de despliegue.

-
Comparación CPU vs GPU

+
Comparación CPU vs GPU

 
Se comparó el tiempo de procesamiento entre CPU y GPU utilizando los datos de src/raytune_paddle_subproc_results_20251207_192320.csv(CPU) y src/results/raytune_paddle_results_20260119_122609.csv(GPU).

 
Tabla 51. Rendimiento comparativo CPU vs GPU.

 
Métrica
CPU
GPU (RTX 3060)
Factor de Aceleración
Tiempo/Página (promedio)
69.4s
0.84s
82x
Dataset completo (45 páginas)
~52 min
~38 seg
82x
64 trials x 5 páginas
6.2 horas
~5.0 min
75x

@@ -5602,13 +5602,13 @@ Configuración óptima:
 
Figura 15. Tiempo de procesamiento: CPU vs GPU (segundos/página)

 
Tiempo de procesamiento: CPU vs GPU (segundos/página)

 
Fuente: src/raytune_paddle_subproc_results_20251207_192320.csv, src/results/raytune_paddle_results_20260119_122609.csv.

+
Leyenda: Aceleración de 82x con GPU. El procesamiento de una página pasa de 69.4s (CPU) a 0.84s (GPU).

 
 

-
Leyenda: Aceleración de 82x con GPU. El procesamiento de una página pasa de 69.4s (CPU) a 0.84s (GPU).

 
La aceleración de 82x obtenida con GPU transforma la viabilidad del enfoque:

-
·     Optimización en CPU (6.2 horas): Viable pero lento para iteraciones rápidas

+
·     Optimización en CPU (6.2 horas): Viable pero lento para iteraciones rápidas

 
·     Optimización en GPU (~5.0 minutos): Permite explorar más configuraciones y realizar múltiples experimentos

-
·     Producción con GPU (0.84s/página): Habilita procesamiento en tiempo real

-
Comparación de Modelos PaddleOCR

+
·     Producción con GPU (0.84s/página): Habilita procesamiento en tiempo real

+
Comparación de Modelos PaddleOCR

 
PaddleOCR ofrece dos variantes de modelos: Mobile (optimizados para dispositivos con recursos limitados) y Server (mayor precisión a costa de mayor consumo de memoria). Se evaluó la viabilidad de ambas variantes en el hardware disponible.

 
Tabla 52. Comparación de modelos Mobile vs Server en RTX 3060.

 
Modelo
VRAM Requerida
Resultado
Recomendación
PP-OCRv5 Mobile
0.06 GB
Funciona correctamente
✓ Recomendado
PP-OCRv5 Server
5.3 GB
OOM en página 2
✗ Requiere >8 GB VRAM

@@ -5699,32 +5699,32 @@ major-latin;mso-bidi-font-family:"Calibri Light";mso-bidi-theme-font:major-latin
 
Todo el código fuente y los datos utilizados en este trabajo están disponibles públicamente en el siguiente repositorio:

 
URL del repositorio: https://seryus.ddns.net/unir/MastersThesis

 
El repositorio incluye:

-
·     Servicios OCR dockerizados: PaddleOCR, DocTR, EasyOCR con soporte GPU

+
·     Servicios OCR dockerizados: PaddleOCR, DocTR, EasyOCR con soporte GPU

 
·     Scripts de evaluación: Herramientas para evaluar y comparar modelos OCR

 
·     Scripts de ajuste: Ray Tune con Optuna para optimización de hiperparámetros

 
·     Dataset: Imágenes y textos de referencia utilizados

-
·     Resultados: Archivos CSV con los resultados de los 64 trials por servicio

+
·     Resultados: Archivos CSV con los resultados de los 64 trials por servicio

 
A.2 Estructura del Repositorio

-
Figura A1. Estructura del repositorio MastersThesis

+
Figura A1. Estructura del repositorio MastersThesis

 
Estructura del repositorio MastersThesis

 
Fuente: Elaboración propia.

 
 

 
A.3 Requisitos de Software

 
Sistema de Desarrollo

-
Tabla A1. Especificaciones del sistema de desarrollo.

+
Tabla A1. Especificaciones del sistema de desarrollo.

 
Componente
Especificación
Sistema Operativo
Ubuntu 24.04.3 LTS
CPU
AMD Ryzen 7 5800H
RAM
16 GB DDR4
GPU
NVIDIA RTX 3060 Laptop (5.66 GB VRAM)
CUDA
12.4

 
Fuente: docs/metrics/metrics.md.

 
 

 
Dependencias

-
Tabla A2. Dependencias del proyecto.

+
Tabla A2. Dependencias del proyecto.

 
Componente
Versión
PaddlePaddle
3.2.2
PaddleOCR
3.3.2
Ray Tune
2.52.1
Optuna
4.7.0
DocTR (python-doctr)
>= 0.8.0
EasyOCR
>= 1.7.0
Docker
Requerido para contenedores
NVIDIA Container Toolkit
Requerido para GPU

 
Fuente: src/paddle_ocr/requirements.txt, src/raytune/requirements.txt, src/doctr_service/requirements.txt, src/easyocr_service/requirements.txt, src/README.md.

 
 

 
A.4 Instrucciones de Ejecución de Servicios OCR

 
PaddleOCR (Puerto 8002)

 
Imágenes Docker:

-
·     GPU: seryus.ddns.net/unir/paddle-ocr-gpu

-
·     CPU: seryus.ddns.net/unir/paddle-ocr-cpu

+
·     GPU: seryus.ddns.net/unir/paddle-ocr-gpu

+
·     CPU: seryus.ddns.net/unir/paddle-ocr-cpu

 

 
cd src/paddle_ocr
 
@@ -5807,7 +5807,7 @@ analyze_results(results, prefix='raytune_paddle', config_keys=PADDLE_OCR_CONFIG_
 "

 

 
Servicios y Puertos

-
Tabla A3. Servicios Docker y puertos.

+
Tabla A3. Servicios Docker y puertos.

 
Servicio
Puerto
Script de Ajuste
Nota
PaddleOCR
8002
paddle_ocr_payload
-
DocTR
8003
doctr_payload
-
EasyOCR
8002
easyocr_payload
Conflicto con PaddleOCR

 
Fuente: Elaboración propia.

 
 

@@ -5815,24 +5815,24 @@ analyze_results(results, prefix='raytune_paddle', config_keys=PADDLE_OCR_CONFIG_
 
A.7 Métricas de Rendimiento

 
Esta sección presenta los resultados completos de las evaluaciones comparativas y del ajuste de hiperparámetros realizado con Ray Tune sobre los tres servicios OCR evaluados.

 
Comparativa General de Servicios

-
Tabla A4. Comparativa de servicios OCR en dataset de 45 páginas (GPU RTX 3060).

+
Tabla A4. Comparativa de servicios OCR en dataset de 45 páginas (GPU RTX 3060).

 
Servicio
CER
WER
Tiempo/Página
Tiempo Total
VRAM
PaddleOCR (Mobile)
7.76%
11.62%
0.58s
32.0s
0.06 GB
EasyOCR
11.23%
36.36%
1.88s
88.5s
~2 GB
DocTR
12.06%
42.01%
0.50s
28.4s
~1 GB

 
Fuente: docs/metrics/metrics_paddle.md, docs/metrics/metrics_easyocr.md, docs/metrics/metrics_doctr.md.

 
 

 
Ganador: PaddleOCR (Mobile) - Mejor precisión (7.76% CER) con velocidad competitiva y mínimo consumo de VRAM.

 
Resultados de Ajuste de Hiperparámetros

 
Se ejecutaron 64 trials por servicio utilizando Ray Tune con Optuna sobre las páginas 5-10 del primer documento.

-
Tabla A5. Resultados del ajuste de hiperparámetros por servicio.

+
Tabla A5. Resultados del ajuste de hiperparámetros por servicio.

 
Servicio
CER Base
CER Ajustado
Mejora
Mejor Trial (5 páginas)
PaddleOCR
8.85%
7.72%
12.8%
0.79% ✓
DocTR
12.06%
12.07%
0%
7.43%
EasyOCR
11.23%
11.14%
0.8%
5.83%

 
Fuente: docs/metrics/metrics_paddle.md, docs/metrics/metrics_easyocr.md, docs/metrics/metrics_doctr.md.

 
 

 
Nota sobre sobreajuste: La diferencia entre los resultados del mejor trial (subconjunto de 5 páginas) y el dataset completo (45 páginas) indica sobreajuste parcial a las páginas de ajuste. Un subconjunto más amplio mejoraría la generalización.

 
Distribución de trials por rango de CER (PaddleOCR)

-
Tabla A6. Distribución de trials por rango de CER.

+
Tabla A6. Distribución de trials por rango de CER.

 
Rango CER
Número de trials
Porcentaje
< 2%
43
67.2%
2% - 5%
10
15.6%
5% - 10%
11
17.2%
> 10%
0
0.0%

 
Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

 
 

-
Figura A2. Distribución de trials por rango de CER (PaddleOCR)

+
Figura A2. Distribución de trials por rango de CER (PaddleOCR)

 
Distribución de trials por rango de CER (PaddleOCR)

 
Fuente: src/results/raytune_paddle_results_20260119_122609.csv.

 
 

@@ -5850,41 +5850,41 @@ analyze_results(results, prefix='raytune_paddle', config_keys=PADDLE_OCR_CONFIG_
 }

Hallazgos clave:

-

·     textline_orientation=true: Crítico para documentos con secciones y encabezados

+

·     textline_orientation=true: Crítico para documentos con secciones y encabezados

·     use_doc_orientation_classify=true: Mejora detección de orientación

·     use_doc_unwarping=false: Innecesario para PDFs digitales

-

·     text_det_thresh bajo (0.0462): Detección más sensible mejora resultados

+

·     text_det_thresh bajo (0.0462): Detección más sensible mejora resultados

Rendimiento CPU vs GPU

-

Tabla A7. Comparación de rendimiento CPU vs GPU (PaddleOCR).

+

Tabla A7. Comparación de rendimiento CPU vs GPU (PaddleOCR).

Métrica

CPU

GPU (RTX 3060)

Aceleración

Tiempo/Página

69.4s

0.84s

82x más rápido

45 páginas

~52 min

~38 seg

82x más rápido

Fuente: Datos de tiempo CPU de src/raytune_paddle_subproc_results_20251207_192320.csv y tiempos de GPU en trials de ajuste. Elaboración propia.

 

-

Figura A3. Tiempo de procesamiento: CPU vs GPU (segundos/página)

+

Figura A3. Tiempo de procesamiento: CPU vs GPU (segundos/página)

Tiempo de procesamiento: CPU vs GPU (segundos/página)

Fuente: src/raytune_paddle_subproc_results_20251207_192320.csv y src/results/raytune_paddle_results_20260119_122609.csv. Leyenda: Aceleración de 82x con GPU. El procesamiento de una página pasa de 69.4s (CPU) a 0.84s (GPU).

 

Análisis de Errores por Servicio

-

Tabla A8. Tipos de errores identificados por servicio OCR.

+

Tabla A8. Tipos de errores identificados por servicio OCR.

Servicio

Fortalezas

Debilidades

¿Fine-tuning recomendado?

PaddleOCR

Preserva estructura, buen manejo de español

Errores menores de acentos

No (ya excelente)

DocTR

Más rápido

Pierde estructura, omite TODOS los diacríticos

Sí (para diacríticos)

EasyOCR

Modelo correcto para español

Caracteres espurios, confunde o/0

Sí (problemas del detector)

Fuente: Análisis manual del debugset. Elaboración propia.

 

Archivos de Resultados

Los resultados crudos de los 64 trials por servicio están disponibles en el repositorio:

-

Tabla A9. Ubicación de archivos de resultados.

+

Tabla A9. Ubicación de archivos de resultados.

Servicio

Archivo CSV

PaddleOCR

src/results/raytune_paddle_results_20260119_122609.csv

DocTR

src/results/raytune_doctr_results_20260119_121445.csv

EasyOCR

src/results/raytune_easyocr_results_20260119_120204.csv

Fuente: Elaboración propia.

 

A.8 Fuentes de precios cloud

Las tablas de costos cloud se basan en las páginas oficiales de precios. Se consultaron en enero de 2026.

-

·     AWS EC2 g4dn.xlarge: https://aws.amazon.com/ec2/instance-types/g4/

+

·     AWS EC2 g4dn.xlarge: https://aws.amazon.com/ec2/instance-types/g4/

·     Google Colab Pro: https://colab.research.google.com/signup

-

·     Google Colab Pro+: https://colab.research.google.com/signup

+

·     Google Colab Pro+: https://colab.research.google.com/signup

A.9 Requisitos documentados por dependencias

Requisitos extraídos de la documentación oficial de las dependencias usadas:

-

·     DocTR: requiere Python 3.10 o superior.

-

·     DocTR Docker: imágenes basadas en CUDA 12.2, el host debe ser al menos 12.2.

-

·     PaddleOCR: soporte de inferencia con CUDA 12.

-

·     PaddleOCR: soporte de Python 3.12 en dependencias.

+

·     DocTR: requiere Python 3.10 o superior.

+

·     DocTR Docker: imágenes basadas en CUDA 12.2, el host debe ser al menos 12.2.

+

·     PaddleOCR: soporte de inferencia con CUDA 12.

+

·     PaddleOCR: soporte de Python 3.12 en dependencias.

A.10 Licencia

El código se distribuye bajo licencia MIT.