Prodigy + Docling + Scripts Personalizados: Una Auditoría Real de Stack Empresarial

Cómo se ve un stack real de preparación de datos de IA empresarial? No el diagrama en la diapositiva de arquitectura, sino la realidad del día a día de herramientas, scripts y soluciones improvisadas que un equipo de ML opera.

Esta es una auditoría de un stack representativo: Prodigy para anotación, Docling para parsing de documentos y scripts personalizados en Python para todo lo intermedio. Cada herramienta es bien considerada en su categoría. La fricción está en los espacios entre ellas.

El Stack

Prodigy (Explosion AI) — $390-$10,000/año

Prodigy es posiblemente la mejor herramienta de anotación para tareas de NLP. Es rápida, scriptable, se ejecuta localmente (importante para datos sensibles) y soporta active learning. Es la herramienta que los ingenieros de ML que han usado todo lo demás generalmente prefieren.

Lo que hace bien:

• Interfaz de anotación extremadamente eficiente (diseñada para velocidad)
• Se ejecuta completamente en local — sin dependencia de la nube, sin Docker requerido
• Active learning: sugiere etiquetas, aprende de correcciones
• API Python para personalización
• Soporta NLP (NER, clasificación de texto, spans) y tareas de CV

Lo que no hace:

• Sin parsing de documentos — espera texto como entrada, no PDFs
• Sin limpieza de datos ni scoring de calidad
• Sin rastro de auditoría para cumplimiento (diseñado para productividad, no gobernanza)
• Enfocado en usuario único — funciones de equipo requieren orquestación personalizada
• Sin exportación multi-formato (genera el formato interno de Prodigy)

Docling (IBM Research) — Gratuito/Open-Source

Docling es un parser de documentos sólido. Maneja PDFs, documentos Word y otros formatos con buena extracción de tablas y detección de layout.

Lo que hace bien:

• 97.9% de precisión en extracción de tablas (competitivo con herramientas comerciales)
• Parsing con conciencia de layout (encabezados, párrafos, listas, tablas)
• Múltiples formatos de salida (Markdown, JSON, texto)
• Open-source, mantenido activamente por IBM Research

Lo que no hace:

• Sin capacidad de etiquetado
• Sin limpieza de datos, deduplicación ni scoring de calidad
• Sin detección ni redacción de PII
• Sin rastro de auditoría
• Sin GUI — solo interfaz de línea de comandos

Scripts Personalizados en Python — "Gratis"

Todo entre Docling y Prodigy — y todo después de Prodigy — es código personalizado:

• docling_to_prodigy.py — convierte la salida de Docling al formato de entrada de Prodigy
• clean_extracted_text.py — deduplicación, filtrado de calidad, normalización
• pii_detection.py — detección de PII basada en regex y NER
• prodigy_export.py — exporta anotaciones de Prodigy a formato de entrenamiento
• quality_check.py — acuerdo inter-anotador, análisis de distribución de etiquetas
• prepare_training_data.py — formateo final para entrenamiento de modelo

Total: ~3,000-5,000 líneas de Python en 8-12 scripts

Los Puntos de Fricción

Punto de Fricción 1: Conversión de Formato Docling -> Prodigy

Docling genera documentos como objetos estructurados con secciones, tablas y metadatos. Prodigy espera un flujo de registros en formato JSONL con un campo text.

El script de conversión debe:

• Aplanar la estructura del documento en fragmentos del tamaño de anotación
• Decidir la estrategia de fragmentación (por página? por sección? por párrafo?)
• Preservar metadatos (archivo fuente, número de página, sección) como campos meta de Prodigy
• Manejar tablas (convertir a texto? markdown? omitir?)
• Manejar documentos multi-página (una tarea de Prodigy por página, o fusionar?)

Las decisiones en este convertidor no son técnicas, son específicas del dominio. Si fragmentar por sección o párrafo afecta la calidad de anotación. Si incluir tablas afecta la cobertura del modelo. Estas decisiones deberían ser tomadas por expertos de dominio, pero están codificadas en un script Python mantenido por un ingeniero de ML.

Punto de Fricción 2: Pipeline de Calidad Manual

Entre la extracción de Docling y la anotación de Prodigy, los datos necesitan limpieza:

• Deduplicación (mismo documento en múltiples carpetas)
• Filtrado de calidad (confianza de OCR por debajo del umbral -> señalar o excluir)
• Detección y redacción de PII (antes de que los anotadores vean los datos)
• Normalización (problemas de encoding, espacios en blanco, caracteres especiales)

Son 1,000-2,000 líneas de Python personalizado que nadie quiere escribir, nadie quiere mantener y nadie ha probado exhaustivamente.

Punto de Fricción 3: Brechas en el Rastro de Auditoría

Para industrias reguladas, el rastro de auditoría se ve así:

• Docling: Registra eventos de parsing (si el logging está configurado)
• Scripts personalizados: Registran lo que el desarrollador recordó registrar (generalmente: nada útil)
• Prodigy: Registra eventos de anotación con marcas de tiempo e IDs de sesión

Qué falta:

• Cuándo se ejecutó la conversión de formato? Por quién?
• Cuál era la configuración de detección de PII? Qué se redactó?
• Qué versión de cada script se usó?
• Cómo se establecieron los umbrales de calidad? Quién los aprobó?

Estas brechas son riesgos de cumplimiento bajo el EU AI Act y regulaciones similares.

Punto de Fricción 4: El Factor Bus

En la mayoría de empresas que usan este stack, un ingeniero de ML entiende el pipeline completo. Escribió los scripts, configuró las herramientas y maneja los casos extremos que surgen durante el procesamiento.

Si esa persona se va:

• Los scripts personalizados tienen documentación mínima
• La configuración de Prodigy tiene convenciones no documentadas
• El manejo de casos extremos es conocimiento tribal
• El siguiente ingeniero necesita 4-8 semanas para entender el pipeline

Esto no es un defecto de Prodigy ni de Docling, son herramientas individuales con buena documentación. El riesgo del factor bus está en la capa de integración personalizada que las conecta.

Punto de Fricción 5: Exclusión de Expertos de Dominio

Prodigy es excelente para ingenieros de ML. Es una herramienta Python-first con interfaz de línea de comandos:

prodigy ner.manual my_dataset blank:en ./data.jsonl --label PERSON,ORG,DATE

Un abogado o doctor que necesita etiquetar datos específicos de dominio no puede usar esto sin que un ingeniero de ML configure y ejecute la sesión. Esto crea una dependencia que limita el throughput de etiquetado.

Qué Cambia una Plataforma Unificada

Los puntos de fricción anteriores no son causados por herramientas malas, son causados por los límites entre herramientas. Cada herramienta es individualmente fuerte pero no fue diseñada para trabajar con las otras.

Una plataforma unificada como Ertas Data Suite elimina estos límites:

• El parsing de documentos alimenta directamente la limpieza (sin conversión de formato)
• La limpieza alimenta directamente el etiquetado (sin scripts personalizados)
• El etiquetado incluye revisión de calidad (sin pipeline de calidad separado)
• La exportación genera documentación de cumplimiento (sin brechas en el rastro de auditoría)
• Los expertos de dominio usan la misma interfaz que los ingenieros de ML (sin barrera de accesibilidad)

La compensación: pierdes la velocidad de anotación específicamente excelente de Prodigy y la extracción de tablas específicamente excelente de Docling. Ganas continuidad del pipeline, completitud del rastro de auditoría y accesibilidad para expertos de dominio.

Para pipelines de producción empresarial en industrias reguladas, los beneficios a nivel de pipeline típicamente superan las compensaciones a nivel de herramienta. Para investigación y experimentación, las herramientas individuales pueden seguir siendo la mejor opción.

El stack es bueno. Los espacios entre las herramientas son donde vive el costo.