Fundamentos del procesamiento de documentos: OCR, DPI y paralelismo

Por Walter Milstein

Antes de implementar arquitecturas de procesamiento masivo, es fundamental comprender los conceptos subyacentes. Este artículo presenta los fundamentos técnicos en dos áreas: procesamiento de imágenes de documentos para extracción de texto, y estrategias de computación paralela para ejecución escalable.

Procesamiento de imágenes de documentos

Reconocimiento Óptico de Caracteres (OCR)

OCR es el proceso de convertir imágenes que contienen texto en secuencias de caracteres legibles por máquina. Los sistemas modernos de OCR operan a través de un pipeline: adquisición de imagen, preprocesamiento, detección de texto, reconocimiento de caracteres y post-procesamiento.

Los motores basados en deep learning como PaddleOCR implementan arquitecturas como SVTR LCNet, logrando precisión state-of-the-art en alfabetos latinos mediante redes neuronales entrenables end-to-end.

Rasterización: el cuello de botella oculto

Los documentos PDF requieren conversión a representaciones de píxeles antes del procesamiento OCR. Los pipelines tradicionales usan librerías como Poppler para rasterizar PDFs en archivos de imagen intermedios (PNG, JPEG), que luego se cargan para procesamiento.

Este enfoque introduce overhead significativo: operaciones de I/O de archivos, escrituras a disco y lecturas subsecuentes consumen tiempo sustancial. En nuestros experimentos, la rasterización sola representa el 22% del tiempo total de procesamiento—un cuello de botella oculto que muchas implementaciones pasan por alto.

Acceso directo a documentos con PyMuPDF

PyMuPDF (fitz) proporciona un enfoque alternativo mediante acceso directo a pixmap. En lugar de generar archivos intermedios, PyMuPDF extrae datos de píxeles directamente de las páginas PDF hacia arrays NumPy mapeados en memoria.

Este enfoque zero-copy elimina el I/O de archivos por completo, reduciendo la etapa de rasterización de minutos a segundos. La optimización es particularmente impactante para escenarios de alto throughput donde miles de páginas deben procesarse.

Resolución (DPI) como palanca de control

La resolución de imagen, medida en puntos por pulgada (DPI), impacta directamente tanto la calidad como el tiempo de procesamiento. Una página renderizada a 300 DPI contiene aproximadamente 8.7 megapíxeles, mientras que la misma página a 100 DPI contiene solo 0.97 megapíxeles—una reducción de 9x en volumen de datos.

Esta diferencia se propaga a través de todo el pipeline: menos datos significa preprocesamiento más rápido, inferencia de red neuronal más rápida, y menor presión de memoria. El trade-off es precisión: menor resolución pierde detalles finos, afectando el reconocimiento de fuentes pequeñas y caracteres especiales.

Técnicas de preprocesamiento

Las imágenes crudas frecuentemente requieren mejora antes del OCR:

CLAHE (Contrast Limited Adaptive Histogram Equalization): Mejora el contraste local en imágenes con iluminación desigual operando en regiones pequeñas en lugar de la imagen completa.

Método de Otsu: Proporciona selección automática de umbral para binarización, convirtiendo imágenes en escala de grises a blanco y negro mediante análisis estadístico de distribuciones de intensidad de píxeles.

Estas técnicas mejoran la precisión de reconocimiento con overhead computacional mínimo. Notablemente, operaciones costosas como denoising y sharpening pueden omitirse cuando se prioriza velocidad, ya que su mejora marginal de calidad raramente justifica su costo computacional.

Post-procesamiento y reconstrucción de texto

La salida de OCR típicamente contiene errores: palabras rotas, caracteres mal reconocidos y artefactos de formato. Los algoritmos de fuzzy matching abordan esto comparando texto extraído contra diccionarios de referencia usando métricas de similitud.

Distancia de Levenshtein: Mide las ediciones mínimas (inserciones, eliminaciones, sustituciones) requeridas para transformar una cadena en otra.

Similitud Jaro-Winkler: Pondera más los matches de prefijo, efectiva para errores de OCR que tienden a ocurrir a mitad de palabra.

Esta etapa de reconstrucción puede recuperar parcialmente la calidad perdida por escaneo de baja resolución, reduciendo la brecha de precisión entre extracciones de 100 DPI y 300 DPI mientras mantiene la ventaja computacional de 9x de menor resolución.

Estrategias de computación paralela

Paralelismo de dos niveles

Escalar OCR a volúmenes empresariales requiere ejecución paralela en múltiples niveles:

Paralelismo distribuido: Distribuye trabajo a través de múltiples máquinas, habilitando escalado horizontal más allá de los límites de un solo nodo.

Paralelismo local: Maximiza throughput dentro de cada nodo utilizando todos los cores de CPU y recursos GPU disponibles.

La combinación de ambos niveles—orquestación distribuida con optimización local—logra speedups multiplicativos.

Ray como dispatcher puro

Ray es un framework open-source para aplicaciones Python distribuidas. Aunque Ray soporta computaciones distribuidas complejas, nuestra arquitectura lo emplea exclusivamente como dispatcher stateless y balanceador de carga.

El coordinador recibe solicitudes de trabajo, divide el corpus en batches balanceados (particionados por conteo de páginas, no de archivos, para balanceo real de carga), despacha batches a workers disponibles, y agrega resultados al completarse. Críticamente, Ray no realiza inferencia OCR directamente—solo orquesta la distribución de trabajo.

Esta separación de responsabilidades minimiza el overhead de Ray mientras proporciona tolerancia a fallos, reinicio automático de workers, y escalado transparente.

Paralelismo local con ProcessPoolExecutor

El Global Interpreter Lock (GIL) de Python previene la ejecución verdaderamente paralela en programas multithreaded. ProcessPoolExecutor del módulo concurrent.futures evita esta limitación spawneando procesos Python independientes, cada uno con su propio intérprete y espacio de memoria.

Para cargas de trabajo OCR, esto habilita 32 procesos worker ejecutándose simultáneamente en una máquina de 32 cores, cada uno capaz de acceso GPU independiente.

Estrategia de batching GPU

La inferencia de redes neuronales logra máxima eficiencia mediante batching—agrupando múltiples inputs en operaciones GPU únicas. PaddleOCR expone dos parámetros críticos: tamaño de batch de detección (imágenes procesadas simultáneamente para detección de regiones de texto) y tamaño de batch de reconocimiento (regiones de texto procesadas simultáneamente para reconocimiento de caracteres).

Los valores óptimos dependen de la memoria GPU disponible y deben ajustarse experimentalmente. Batches más pequeños reducen latencia pero desperdician ciclos GPU; batches más grandes mejoran throughput pero aumentan presión de memoria y latencia.

Contención GPU y sweet spots

Cuando múltiples procesos comparten una sola GPU, emerge contención: los procesos hacen cola para acceso GPU, serializando lo que debería ser ejecución paralela. La eficiencia alcanza su pico en cierto número de procesos por GPU, con rendimientos decrecientes más allá de este umbral.

Agregar más workers CPU más allá del punto óptimo no proporciona beneficio y puede degradar rendimiento debido a overhead de context switching y saturación de ancho de banda de memoria.

Tolerancia a fallos y recuperación

El procesamiento distribuido debe manejar fallos gracefully. Ray proporciona tolerancia a fallos automática: si un worker crashea o hace timeout, el framework detecta el fallo, reinicia el actor, y reasigna el batch fallido.

Esta capacidad es esencial para procesar corpus grandes donde fallos transitorios (errores de out-of-memory, glitches de hardware, timeouts de red) son estadísticamente inevitables.

Resumen

Los conceptos presentados en este artículo forman la base técnica de las arquitecturas de procesamiento masivo. La combinación de acceso directo a documentos (eliminando el cuello de botella de rasterización), resolución optimizada (100 DPI para velocidad), y paralelismo de dos niveles (distribuido + local) permite alcanzar throughputs empresariales con hardware de consumidor.

En el próximo artículo, profundizaremos en la Arquitectura 1: el pipeline distribuido con Ray que prioriza tolerancia a fallos y monitoreo para entornos de producción.

Próximo artículo: Arquitectura 1 - Pipeline distribuido con Ray: tolerancia a fallos para producción