Procesamiento por Lotes de Archivos de Documentos Grandes On-Premise: Guía de Optimización de Rendimiento

Los archivos de documentos empresariales se miden en cientos de gigabytes a terabytes. Un bufete de abogados mediano podría tener 500 GB de PDFs de contratos. Un sistema hospitalario podría tener 2 TB de registros clínicos. Una empresa de construcción podría tener 300 GB de planos de ingeniería y especificaciones.

Procesar estos archivos a través de un pipeline de preparación de datos — ingesta, OCR, limpieza, etiquetado, exportación — toma horas a días, no minutos. La diferencia entre un pipeline bien optimizado y uno ingenuo puede ser de 3-5x en tiempo total de procesamiento. Esta guía cubre las estrategias de optimización de rendimiento que importan en la práctica.

El Patrón de Procesamiento Nocturno

Antes de optimizar, vale la pena reconocer el patrón de flujo de trabajo dominante para procesamiento por lotes grandes: iniciar el trabajo por la noche, revisar resultados por la mañana.

Este patrón funciona porque:

La preparación de datos es una tarea periódica, no un servicio en tiempo real
Nadie está esperando respuesta interactiva durante el procesamiento por lotes
Los trabajos de larga duración se benefician de cómputo ininterrumpido (sin cargas de trabajo competidoras)
Los resultados necesitan revisión humana de todos modos — y los humanos revisan durante horario laboral

El objetivo de la optimización de rendimiento no es hacer que un trabajo de 12 horas termine en 12 minutos. Es hacer que un trabajo de 48 horas termine en 12 horas para que se complete durante la noche en lugar de abarcar un fin de semana.

Estrategias de Ingesta Paralela

La ingesta de documentos es la primera etapa del pipeline y frecuentemente la más limitada por I/O. Las optimizaciones clave:

Paralelismo a Nivel de Archivo

Procesa múltiples archivos concurrentemente. Cada archivo es independiente — parsear un PDF no depende de parsear el documento Word anterior.

Paralelismo óptimo: Iguala el número de operaciones de archivo concurrentes a tu rendimiento de almacenamiento, no a tus núcleos de CPU. En NVMe SSD, 8-16 lecturas de archivo concurrentes típicamente saturan la unidad. En HDD, incluso 2-4 lecturas concurrentes causan contención de búsqueda que ralentiza todo.

Tipo de Almacenamiento	Archivos Paralelos Recomendados	Notas
NVMe SSD	8-16	Limitado por velocidad de parseo de CPU
SATA SSD	4-8	Limitado por ancho de banda secuencial
HDD	1-2	I/O aleatorio mata el paralelismo
Red (NFS/SMB)	4-8	Limitado por ancho de banda y latencia de red

Ordenar Archivos por Tamaño

Procesa los archivos grandes primero. Esto evita el problema de "cola larga" donde el pipeline está inactivo excepto por un hilo procesando un solo archivo masivo al final.

Una estrategia simple: ordena la lista de archivos por tamaño descendente, luego procesa en paralelo. El primer lote toma los archivos más grandes, y los lotes subsiguientes llenan con archivos más pequeños.

Pre-Filtrado por Tipo de Archivo

No todos los archivos en un archivo necesitan procesamiento. Filtros comunes:

Omitir archivos por debajo de un tamaño mínimo (por ejemplo, menos de 1 KB — probablemente vacíos o archivos stub)
Omitir tipos que no son documentos (.exe, .dll, .tmp)
Omitir duplicados por hash de archivo antes del parseo

Pre-filtrar un archivo de 500 GB frecuentemente elimina 5-15% de los archivos, ahorrando tiempo de parseo en contenido que no producirá datos útiles.

Gestión de Memoria para PDFs Grandes

Los PDFs son el tipo de documento más común en archivos empresariales y el más problemático para la memoria.

Por qué los PDFs Consumen Memoria

Un PDF de 200 páginas con imágenes embebidas puede descomprimirse a 500 MB-2 GB en memoria durante el parseo. El formato PDF usa compresión interna (Flate, JPEG2000) y referencias de objetos que requieren que toda la estructura del archivo se mantenga en memoria para acceso aleatorio.

Los PDFs escaneados son peores: cada página es una imagen a resolución completa (típicamente 300 DPI, 2550x3300 píxeles, color de 24 bits = ~24 MB sin comprimir por página). Un PDF escaneado de 200 páginas se descomprime a ~4.8 GB.

Estrategias de Mitigación

Procesamiento a nivel de página: En lugar de cargar el PDF completo en memoria, procesa una página (o un pequeño lote de páginas) a la vez. La mayoría de las bibliotecas de PDF soportan extracción de rango de páginas sin cargar el documento completo.

Límites de memoria por worker: Establece un techo de memoria para cada worker de procesamiento. Si un solo PDF excede el límite, procésalo secuencialmente (una página a la vez) en lugar de en paralelo. Esto previene que un solo documento grande consuma toda la RAM disponible y cause crashes por falta de memoria.

Extracción por streaming: Para PDFs de solo texto (no escaneados), usa un parser de streaming que extraiga texto sin descomprimir completamente los objetos embebidos. PyMuPDF (fitz) soporta este enfoque y usa significativamente menos memoria que pdfplumber o PyPDF2 para extracción de texto.

Presupuesto Práctico de Memoria

Archivos Concurrentes	Tamaño Promedio	RAM Pico por Worker	RAM Total Necesaria
8	10 MB (PDF texto)	~200 MB	~1.6 GB
8	50 MB (PDF mixto)	~500 MB	~4 GB
4	200 MB (PDF escaneado)	~2 GB	~8 GB
2	500 MB+ (escaneo grande)	~4 GB	~8 GB

Agrega 8-16 GB para el SO, aplicación y LLM (si corre concurrentemente). Un sistema con 64 GB de RAM maneja cómodamente la mayoría de los escenarios de ingesta paralela.

Optimización de I/O

SSD vs. HDD: Los Números

Esta comparación vale la pena repetir porque la diferencia de rendimiento es marcada:

Operación	NVMe SSD	SATA SSD	HDD
Lectura secuencial	3,500-7,000 MB/s	500-550 MB/s	100-200 MB/s
Lectura aleatoria (4K)	500K-1M IOPS	50K-100K IOPS	100-200 IOPS
Latencia	~10 μs	~50 μs	~5,000 μs

Para preparación de datos, los IOPS de lectura aleatoria importan tanto como el rendimiento secuencial. Parsear documentos implica buscar diferentes posiciones dentro de archivos, cargar metadatos, leer objetos embebidos — todos patrones de acceso aleatorio.

Un ejemplo concreto: Ingestar 100,000 documentos mixtos (10 GB total) desde diferentes almacenamientos:

Almacenamiento	Tiempo Estimado de Ingesta
NVMe SSD	8-15 minutos
SATA SSD	25-45 minutos
HDD	3-6 horas
NFS sobre Gigabit Ethernet	1-3 horas

Configuración RAID

Para el nivel de producción (archivos de multi-TB):

RAID 0 (striping): Duplica el rendimiento de lectura distribuyendo datos entre dos unidades. Sin redundancia — una falla de una sola unidad pierde todo. Aceptable para datos intermedios de procesamiento que pueden regenerarse.

RAID 1 (mirroring): Sin mejora de rendimiento pero proporciona redundancia. Usar para datos fuente que no pueden reemplazarse fácilmente.

RAID 10 (stripe de mirrors): Tanto rendimiento como redundancia. Cuatro unidades mínimo. Mejor opción cuando importan tanto velocidad como seguridad de datos.

Para NVMe, RAID es menos necesario — una sola unidad NVMe Gen4 ya proporciona más rendimiento del que la mayoría de los pipelines de preparación de datos pueden saturar. RAID se vuelve relevante en el nivel HDD o cuando la capacidad total en una sola unidad es insuficiente.

Mejores Prácticas de Almacenamiento en Red

Si los datos fuente viven en almacenamiento de red (NAS, SAN, NFS):

Copia a SSD local antes de procesar. La latencia de red en cada lectura de archivo se acumula a lo largo de millones de operaciones.
Si copiar no es práctico, monta con opciones apropiadas: noatime (omitir actualizaciones de tiempo de acceso), rsize=1048576,wsize=1048576 (buffers grandes de lectura/escritura para NFS), y deshabilitar bloqueos de caché del lado del cliente.
Acepta que el almacenamiento de red será el cuello de botella. Planifica en consecuencia — duplica o triplica tus estimaciones de tiempo vs. SSD local.

Seguimiento de Progreso y Reanudabilidad

Los trabajos por lotes de larga duración fallan. Los discos se llenan, ocurren interrupciones de energía, el software crash en un archivo malformado. Un pipeline que no puede reanudar desde donde se quedó desperdicia horas de trabajo completado.

Reanudabilidad Basada en Checkpoints

El enfoque mínimo viable: mantener un registro de archivos completados. Cuando el pipeline reinicia, lee el registro y omite archivos ya procesados.

# Formato simple de registro de checkpoint
timestamp | filepath | status | duration_ms
2026-03-11T22:15:03 | /data/contracts/2024-Q1/contract_0001.pdf | completed | 1250
2026-03-11T22:15:04 | /data/contracts/2024-Q1/contract_0002.pdf | completed | 890
2026-03-11T22:15:05 | /data/contracts/2024-Q1/contract_0003.pdf | error:corrupt_pdf | 45

Detalles clave de implementación:

Escribe checkpoints sincrónicamente (flush a disco) después de cada archivo. Las escrituras asíncronas arriesgan perder datos de checkpoint si el proceso crash.
Registra errores con suficiente contexto para investigar después — el tipo de error, la ruta del archivo y la etapa del pipeline.
Almacena checkpoints separados de los datos de salida para que sobrevivan la limpieza del directorio de salida.

Reporte de Progreso

Para trabajos por lotes corriendo durante la noche, el reporte de progreso importa más que los dashboards en tiempo real. Lo esencial:

Total de archivos / archivos procesados / archivos restantes: Saber dónde estás.
Rendimiento actual (archivos/minuto): Conocer tu velocidad.
Tiempo estimado restante: Saber cuándo terminará.
Conteo de errores: Saber si algo está saliendo mal a escala (unos pocos errores en 100K archivos es normal; 10,000 errores significa un problema sistemático).

Escribe el progreso a un archivo de registro que pueda verificarse sin interrumpir el proceso. Una línea simple como [2026-03-11 03:45:12] Progreso: 45,230 / 100,000 archivos (45.2%) | 23.5 archivos/min | ETA: 38.8 horas | Errores: 12 es más útil que un dashboard elaborado que nadie mira a las 3 AM.

Manejo de Errores para Archivos Corruptos

Los archivos de documentos empresariales contienen archivos corruptos. Siempre. Modos de falla comunes:

PDFs truncados: El archivo fue interrumpido durante la subida o copia. El parser lee el encabezado, luego encuentra un EOF inesperado.
Archivos encriptados/protegidos con contraseña: El parser puede detectar la bandera de encriptación pero no puede extraer contenido.
XML malformado (en DOCX/XLSX): Documentos de Office corruptos con estructuras XML inválidas.
Archivos de cero bytes: Presentes en el archivo pero sin datos.
Formatos no soportados: Archivos con extensiones engañosas (un .pdf que en realidad es un TIFF).

Estrategia de Manejo de Errores

Captura por archivo: Nunca dejes que un solo archivo corrupto crashee todo el pipeline. Envuelve el procesamiento de cada archivo en manejo de errores.
Registra y omite: Registra el error y pasa al siguiente archivo. Acumula errores para revisión post-ejecución.
Cuarentena: Mueve o vincula archivos fallidos a un directorio separado para inspección manual.
Establece umbrales: Si la tasa de error excede un umbral (por ejemplo, mayor a 5% de archivos), pausa el pipeline y alerta. Una tasa de error alta generalmente indica un problema sistemático — parser incorrecto, problema de codificación de caracteres, o fuente corrupta.

Optimizando Cuellos de Botella Comunes

Cuello de Botella: OCR Demasiado Lento

OCR es típicamente la etapa más lenta. Opciones de optimización:

Cambiar a OCR acelerado por GPU: Si estás corriendo Tesseract solo-CPU, cambiar a PaddleOCR o Surya con GPU puede mejorar el rendimiento 5-10x.
Reducir resolución de OCR: Procesar a 200 DPI en lugar de 300 DPI aproximadamente duplica el rendimiento con pérdida modesta de precisión para texto impreso estándar.
Omitir OCR donde sea innecesario: Si un PDF tiene capas de texto extraíbles, usa extracción de texto en lugar de OCR. Muchos PDFs "escaneados" en realidad ya tienen una capa de texto OCR embebida.
Procesamiento de páginas por lotes: Procesa múltiples páginas por llamada de inferencia GPU en lugar de una a la vez.

Cuello de Botella: Etiquetado LLM Demasiado Lento

Reducir tamaño de modelo: Cambia de 14B a 7B. Acepta el compromiso de precisión si la calidad de etiquetado permanece por encima de tu umbral.
Aumentar cuantización: Mueve de Q8 a Q4_K_M. Mejora aproximada de rendimiento: 40-60%.
Reducir ventana de contexto: Si estás usando 16K de contexto pero los documentos promedian 2K tokens, baja a 4K de contexto.
Aumentar solicitudes paralelas: Si la VRAM lo permite, corre 2-4 solicitudes de inferencia concurrentes.

Cuello de Botella: Agotamiento de Memoria

Reducir paralelismo: Procesa menos archivos concurrentemente. Intercambiando velocidad por estabilidad.
Procesar por tipo de archivo: Maneja PDFs escaneados grandes separadamente de documentos de texto pequeños, con diferentes configuraciones de paralelismo para cada uno.
Aumentar espacio swap: Una medida temporal, no una solución. Hacer swap a SSD es 100x más lento que RAM pero previene crashes.

Cuello de Botella: Espacio en Disco

Procesar en oleadas: Ingesta un lote, procésalo a través de todas las etapas, exporta, luego limpia archivos intermedios antes del siguiente lote.
Comprimir datos intermedios: Compresión gzip o zstd en salidas intermedias intercambia CPU por espacio en disco.
Monitorear uso de disco proactivamente: Un error de disco lleno en la hora 10 de un trabajo de 12 horas es evitable con monitoreo.

Monitoreando Trabajos por Lotes de Larga Duración

Para trabajos corriendo durante la noche o el fin de semana:

Registro a archivo: Escribe registros estructurados que incluyan marcas de tiempo, métricas de rendimiento y conteos de errores. Revisa el archivo de registro antes de dormir y a primera hora de la mañana.

Monitoreo de procesos: Usa herramientas básicas del SO — htop para CPU y memoria, nvidia-smi para utilización de GPU, iostat para I/O de disco. Si la utilización de GPU cae a 0% mientras el trabajo está corriendo, algo se ha estancado.

Alertas (opcional): Para trabajos corriendo en un servidor dedicado, un script simple que verifica la viveza del proceso y envía una notificación (email, Slack) en caso de falla vale los 10 minutos para configurarlo.

Aplicación Práctica

Ertas Data Suite maneja el procesamiento por lotes con seguimiento de progreso incorporado, manejo de errores por archivo y reanudabilidad automática. La aplicación mantiene un diario de procesamiento que registra el estado de cada archivo a través de cada etapa del pipeline. Si el proceso se interrumpe — corte de energía, crash de aplicación, o pausa intencional — reiniciar retoma exactamente donde se quedó.

Para proveedores de servicios procesando archivos de documentos de clientes, el patrón de procesamiento nocturno combinado con reanudabilidad significa que puedes entregar resultados en un cronograma predecible. Inicia el trabajo por lotes cuando sales de la oficina, verifica el registro de progreso remotamente si es necesario, y revisa resultados a la mañana siguiente. Las estrategias de optimización de rendimiento en esta guía te ayudan a obtener esos resultados en una sola ejecución nocturna en lugar de tres.

El Panorama General

El rendimiento del procesamiento por lotes afecta directamente los cronogramas y costos de los compromisos. Un pipeline bien optimizado que procesa un archivo de 500 GB en 8 horas (una ejecución nocturna) entrega resultados en dos días — un día para correr, un día para revisar. Un pipeline mal optimizado que toma 48 horas empuja el mismo entregable a una semana.

Para más sobre las decisiones de infraestructura que afectan el rendimiento del procesamiento por lotes, consulta Arquitectura de Runtime On-Premise para Preparación de Datos de IA Empresarial y Dimensionamiento de Hardware para Preparación de Datos On-Premise.