De PDF a JSONL: Construyendo un Pipeline Empresarial de Preparacion de Datos para Entrenamiento de IA

El punto de partida mas comun para la preparacion de datos de IA empresarial es una carpeta — o un disco compartido, o un sistema de gestion documental — llena de PDFs. Reportes anuales. Manuales tecnicos. Notas clinicas. Contratos legales. Especificaciones de ingenieria. Decadas de conocimiento institucional encerrado dentro de un formato que fue disenado para lectura humana, no para aprendizaje automatico.

Pasar de esa carpeta de PDFs a un archivo JSONL listo para fine-tuning es un pipeline de cinco etapas. Cada etapa tiene modos de fallo que son faciles de pasar por alto si solo has procesado un punado de PDFs limpios y modernos. A escala empresarial — miles o cientos de miles de documentos, acumulados durante anos, producidos por diferentes equipos con diferente software — cada modo de fallo se convierte en un problema de confiabilidad.

Esta guia recorre el pipeline completo: que sucede en cada etapa, que puede salir mal, y que controles de calidad son necesarios antes de que la salida sea realmente utilizable.

Por Que los PDFs Son el Problema

Las estimaciones situan los datos no estructurados en el 80-90% del volumen total de datos empresariales. Los PDFs representan una porcion significativa de eso — son el formato de facto para documentos que necesitan verse consistentes entre sistemas y preservarse a lo largo del tiempo. Cada contrato, politica, especificacion tecnica, reporte de investigacion y presentacion regulatoria que tu organizacion ha producido o recibido en los ultimos 20 anos probablemente esta en un PDF.

El problema es que PDF es un formato de presentacion. Su estructura interna describe como la tinta debe aparecer en una pagina, no que significa el texto o como diferentes elementos de texto se relacionan entre si. Un renderizador de PDF puede mostrar un documento tecnico de multiples columnas de forma hermosa. Un extractor de texto ingenuo producira una mezcla ilegible de fragmentos de ambas columnas intercalados en el orden incorrecto.

Antes de que se pueda escribir un solo registro JSONL, debes resolver: orden de lectura, estructura de tablas, limites de secciones, imagenes incrustadas, encabezados y pies de pagina, notas al pie, expresiones matematicas, y la distincion entre texto del cuerpo y leyendas. Nada de esto se resuelve simplemente llamando a una libreria de extraccion de texto.

Etapa 1: Clasificar y Enrutar

No todos los PDFs son iguales. Antes de parsear, cada documento necesita clasificarse por tipo porque diferentes tipos requieren diferentes pipelines de procesamiento:

• PDFs nativos con texto seleccionable: El texto puede extraerse directamente. Aun requiere analisis de diseno para el orden de lectura.
• PDFs escaneados (solo imagen): Sin texto incrustado. Se requiere OCR en cada pagina.
• PDFs mixtos: Algunas paginas son nativas, algunas son escaneadas (comun cuando un documento ha sido reimpreso y reescaneado, o cuando se agregaron inserciones manualmente).
• PDFs de formularios: Campos interactivos, casillas de verificacion y datos de formularios estructurados requieren logica de extraccion diferente al texto fluido.

Clasificar erroneamente un PDF escaneado como nativo — y saltar el OCR — produce cero texto de salida o un archivo lleno de artefactos de codificacion. La clasificacion automatizada basada en analisis de imagen de pagina deberia ocurrir antes del enrutamiento al parser apropiado.

Etapa 2: Parsear y Extraer

Para PDFs nativos, la extraccion usa parseo con conciencia de diseno que reconstruye el orden de lectura a partir de las posiciones espaciales de los elementos de texto en la pagina. Los disenos de multiples columnas requieren que el extractor agrupe elementos de texto por columna antes de linearizarlos. Los encabezados, pies de pagina y numeros de pagina necesitan ser identificados y ya sea eliminados o etiquetados por separado.

Para PDFs escaneados, la calidad del OCR depende de la calidad del escaneo, la claridad de la fuente y la orientacion de la pagina. Problemas comunes:

• Paginas torcidas (documento colocado ligeramente inclinado en un escaner) producen texto rotado que los motores de OCR leen mal
• Escaneos de baja resolucion (menos de 200 DPI) producen errores a nivel de caracter que se acumulan en errores a nivel de palabra
• Anotaciones manuscritas mezcladas con texto impreso requieren manejo separado
• Sellos, firmas y superposiciones de formularios oscurecen el texto subyacente

Las tablas requieren atencion particular. Una tabla en un PDF no tiene estructura de celdas explicita — es simplemente texto posicionado en una cuadricula. Extraer una tabla correctamente requiere detectar lineas de cuadricula (o espacio en blanco entre celdas), asociar texto con celdas, preservar relaciones fila-columna, y manejar celdas fusionadas y encabezados multi-nivel.

Para un dataset empresarial, la falla en la extraccion de tablas no es un problema menor. Si tus documentos son especificaciones de ingenieria, reportes financieros o tablas de resultados clinicos, una fraccion significativa de la informacion vive en tablas — y si el extractor las aplana en texto no estructurado, esa informacion se pierde o se corrompe.

Etapa 3: Limpiar y Normalizar

La salida del parseo es texto extraido en bruto, que de manera confiable contiene:

• Artefactos de codificacion: Errores de OCR que producen caracteres ilegibles (fi en lugar de fi, * renderizado como a*, comillas curvas renderizadas como a).
• Contaminacion de encabezado/pie: Encabezados repetidos y numeros de pagina que se extrajeron como texto del cuerpo, apareciendo repetidamente a lo largo del documento.
• Artefactos de separacion silabica: Palabras con guion al final de linea que el extractor dejo como infor-\nmacion en lugar de informacion.
• Irregularidades de espaciado: Lineas en blanco excesivas, espaciado de parrafo inconsistente, y espacio en blanco al inicio/final.
• Cuasi-duplicados: La misma seccion apareciendo multiples veces porque fue referenciada en un apendice, o porque un documento revisado comparte el 90% de su contenido con el original.

La deduplicacion merece atencion especial. Los archivos documentales empresariales no estan cuidadosamente curados. Estan acumulados. La misma plantilla de contrato aparece 300 veces con variaciones menores. La misma especificacion tecnica tiene 12 versiones revisadas. Si entrenas con un dataset donde el 30% del contenido es cuasi-duplicado, el modelo aprendera a reproducir ese contenido con confianza exagerada, y el tamano aparente del conjunto de entrenamiento sera enganosamente grande.

La deteccion de cuasi-duplicados requiere comparar huellas digitales de documentos (MinHash, SimHash o similaridad basada en embeddings) en lugar de coincidencia exacta de cadenas, porque dos cuasi-duplicados nunca son identicos caracter por caracter.

Para industrias reguladas, esta etapa tambien incluye la deteccion y redaccion de PII y PHI. Nombres, direcciones, numeros de telefono, direcciones de correo electronico, numeros de identificacion gubernamental, numeros de cuenta, y (para salud) numeros de registro medico, codigos de diagnostico e identificadores de pacientes deben detectarse y redactarse antes de que los datos se usen para entrenamiento.

Etapa 4: Estructurar para el Formato Objetivo

JSONL es un formato, no un esquema. Lo que va dentro de cada objeto JSON depende enteramente de lo que estas entrenando.

Para fine-tuning de instrucciones, cada registro necesita un prompt y una completacion:

{"prompt": "Summarize the following contract clause: [text]", "completion": "The clause establishes..."}

Para fine-tuning de chat, cada registro es una conversacion:

{"messages": [{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]}

Para DPO (Direct Preference Optimization), cada registro necesita una respuesta elegida y una rechazada:

{"prompt": "...", "chosen": "...", "rejected": "..."}

Para pipelines RAG, los datos no son un JSONL de pares de entrenamiento — es texto fragmentado con metadatos, formateado para ingestion en un almacen vectorial:

{"text": "...", "source": "document_id", "page": 12, "section": "Section 4.2"}

La eleccion de formato debe hacerse antes de que comience el etiquetado, porque la estrategia de etiquetado cambia segun el formato. Los equipos que etiquetan datos sin conocer el formato objetivo frecuentemente tienen que re-etiquetar cuando se dan cuenta de que el formato es incorrecto.

Etapa 5: Validar Antes de Exportar

La validacion antes de la exportacion final detecta problemas que son invisibles hasta que el entrenamiento falla o un modelo se comporta inesperadamente.

Verificaciones minimas de validacion:

• Validacion de esquema: Cada registro en el JSONL se ajusta a la estructura de campos y tipos esperados
• Distribucion de longitud: Registros que son demasiado cortos (menos de 50 tokens) o demasiado largos (mayor que la ventana de contexto) para la configuracion de entrenamiento
• Distribucion de etiquetas: Para tareas de clasificacion, distribucion de clases a traves del dataset — un desequilibrio significativo producira un modelo que funciona bien en clases mayoritarias y mal en clases minoritarias
• Pasada de deduplicacion: Una verificacion final para asegurar que ningun cuasi-duplicado se filtro
• Completitud de redaccion: Una auditoria de muestra de la cobertura de deteccion de PII/PHI, especialmente en campos no cubiertos por patrones estandar (identificadores personalizados, nombres informales)

Un benchmark aproximado: para un corpus de PDFs nativos, espera 2-8 horas de tiempo de procesamiento por cada 1,000 documentos a traves de las etapas 1-3 dependiendo de la complejidad del documento. Para PDFs escaneados, multiplica eso por 3-5x dependiendo de la dificultad del OCR. El tiempo de etiquetado (etapa 4) esta determinado en gran parte por la complejidad de la tarea de anotacion y la disponibilidad de expertos de dominio — presupuesta 2-10 minutos por registro etiquetado para anotacion compleja.

Lo Que Sale Mal a Escala Empresarial

Los problemas que son manejables a pequena escala se convierten en problemas de confiabilidad a gran escala:

• Una tasa de error de OCR del 0.5% a traves de 100 documentos son 50 caracteres malos. A traves de 100,000 documentos, son potencialmente miles de registros corruptos.
• Un sistema de deteccion de cuasi-duplicados que falla en el 5% de los duplicados deja ruido aceptable en un dataset pequeno. A escala, produce sobre-representacion sistematica de contenido comun.
• Un sistema de redaccion de PII que detecta el 95% de los identificadores en validacion puede fallar en el 5% — un numero que representa riesgo real de exposicion cuando el dataset contiene registros medicos o financieros.

El otro problema de escala es el herramental. La mayoria de las herramientas de parseo, limpieza y formateo de PDFs estan disenadas para experimentacion y ejecuciones pequenas. No manejan 400,000 documentos con gracia, no producen registros de auditoria, y no exponen metricas de calidad en una forma que te permita monitorear la calidad de salida del pipeline a lo largo del tiempo.

Ertas Data Suite maneja este pipeline de forma nativa — parsear, limpiar, deduplicar, redactar PII, etiquetar y exportar a JSONL desde un solo proyecto — con registro de auditoria completo de cada transformacion, sin que ningun dato salga de la maquina.

---

Lecturas Relacionadas

• Como Convertir Documentos Empresariales No Estructurados en Datos de Entrenamiento de IA — Cubre toda la gama de formatos de documentos empresariales mas alla de los PDFs.
• Las Cinco Etapas de un Pipeline de Datos de IA Empresarial — Un desglose estructurado de cada etapa del pipeline con puntos de fallo comunes.
• La Guia Empresarial para la Preparacion de Datos de IA — El panorama completo de la preparacion de datos empresariales, desde archivos en bruto hasta datasets listos para entrenamiento.