La Brecha de Preparación de Datos: Por Qué los Equipos de ML Pasan el 80% del Tiempo Antes de que Comience el Entrenamiento

La estadística ya es casi un cliché a estas alturas: los equipos de ML pasan del 60 al 80% de su tiempo en preparación de datos. Ha sido citada en encuestas, publicaciones de blog y conferencias durante más de una década. Y sin embargo — nada ha cambiado. El porcentaje no se ha movido.

Esta persistencia merece examinarse. ¿Son ineficientes los equipos de ML? ¿Están sobre-ingenieriando sus pipelines de datos? ¿O hay algo estructural en cómo la industria aborda la preparación de datos que garantiza este resultado?

La respuesta es estructural. Y la solución no son mejores ingenieros de ML — son herramientas específicas que aborden las causas raíz.

Por Qué el Porcentaje No Se Ha Movido

Causa 1: Herramientas Fragmentadas

El flujo de trabajo de preparación de datos en la mayoría de las empresas involucra de 3 a 7 herramientas desconectadas:

1. Parseo: Docling, Unstructured.io, Marker, o scripts personalizados
2. Limpieza: Scripts de Python usando Pandas, lógica de deduplicación personalizada
3. Etiquetado: Label Studio, Prodigy, o Argilla
4. Puntuación de calidad: Cleanlab, scripts de validación personalizados
5. Aumentación: Distilabel, generación sintética personalizada
6. Exportación: Otro script de Python para formatear la salida

Cada herramienta tiene su propio:

• Proceso de instalación y configuración
• Requisitos de formato de datos (entrada y salida)
• Curva de aprendizaje y documentación
• Ciclo de actualización (ocurren cambios que rompen cosas)
• Enfoque de logging (o falta del mismo)

La integración entre estas herramientas es código Python personalizado — los "scripts de pegamento" que nadie quiere escribir, nadie quiere mantener, y nadie quiere depurar cuando se rompen.

Esta fragmentación multiplica el esfuerzo en cada límite. La conversión de formatos, el manejo de errores, la validación de datos y la continuidad del registro de auditoría requieren tiempo de ingeniería que no mejora directamente la calidad de los datos.

Causa 2: Exclusión de Expertos de Dominio

Las personas que saben si los datos están correctamente etiquetados — médicos, abogados, ingenieros, contadores — típicamente no pueden usar herramientas de preparación de datos de ML. Label Studio requiere un despliegue Docker. Prodigy requiere Python. Cleanlab es una biblioteca de Python.

Esto crea un cuello de botella: los expertos de dominio tienen el conocimiento, los ingenieros de ML tienen el acceso a las herramientas, y la transferencia entre ellos degrada tanto la velocidad como la calidad.

El flujo típico: el ingeniero de ML extrae datos, los formatea para la herramienta de etiquetado, explica el esquema de etiquetado al experto de dominio (quien usa la herramienta bajo supervisión o proporciona etiquetas a través de una hoja de cálculo), el ingeniero de ML importa las etiquetas, ejecuta verificaciones de calidad e itera. Cada transferencia agrega latencia y potencial de error.

Si los expertos de dominio pudieran etiquetar datos directamente — sin Docker, Python ni un ingeniero de ML como intermediario — la fase de etiquetado tomaría una fracción del tiempo actual.

Causa 3: Sin Arquitectura de Registro de Auditoría

La mayoría de los pipelines de preparación de datos no tienen un registro de auditoría integrado. Cuando algo sale mal — datos mal etiquetados, registros faltantes, degradación de calidad — la depuración requiere rastrear manualmente a través de múltiples herramientas y scripts personalizados para encontrar dónde se originó el problema.

Sin registros de auditoría, los problemas de calidad se descubren tarde y son costosos de arreglar. Los equipos pasan tiempo reprocesando datos que ya fueron procesados incorrectamente. Re-etiquetan registros que se perdieron durante la limpieza. Re-ejecutan etapas completas del pipeline porque no pueden identificar qué registros específicos fueron afectados por un error.

En industrias reguladas, el registro de auditoría no es solo una conveniencia de depuración — es un requisito de cumplimiento. Los equipos en salud, legal y finanzas pasan tiempo adicional documentando manualmente los pasos de su pipeline para satisfacer requisitos regulatorios que un sistema integrado manejaría automáticamente.

Causa 4: La Preparación de Datos Se Trata como una Tarea Secundaria

En la mayoría de las organizaciones, la preparación de datos se trata como un paso preliminar en el camino hacia el "trabajo real" de entrenamiento de modelos. No tiene personal dedicado, presupuesto de herramientas dedicado ni gestión de proyectos dedicada.

Los ingenieros de ML son contratados para construir modelos. Son evaluados por el rendimiento del modelo. Están entusiasmados con las innovaciones de arquitectura y las técnicas de entrenamiento. La limpieza de datos es el trabajo poco glamuroso que tienen que hacer antes de poder hacer aquello para lo que fueron contratados.

Esta subvaloración estructural conduce a la subinversión:

• Los equipos no compran herramientas dedicadas de preparación de datos ("simplemente usaremos scripts de Python")
• El tiempo de expertos de dominio para etiquetado no se asigna formalmente
• Las métricas de calidad de datos no se rastrean ni reportan
• El mantenimiento del pipeline de datos no es responsabilidad principal de nadie

Causa 5: La Complejidad Es Irreducible (Pero Podría Gestionarse Mejor)

Parte del esfuerzo de preparación de datos es genuinamente irreducible:

• La diversidad de formatos de documentos es real — las empresas tienen docenas de formatos
• Los requisitos de experiencia de dominio son reales — solo los especialistas pueden etiquetar correctamente
• Los requisitos de cumplimiento son reales — los registros de auditoría y las protecciones de privacidad requieren esfuerzo
• La variación en la calidad de datos es real — los datos empresariales brutos tienen problemas genuinos de calidad

Pero la complejidad irreducible no significa que el enfoque actual sea óptimo. Mucho del 60-80% no se gasta en los problemas difíciles — se gasta en integración, conversión de formatos, mantenimiento de herramientas y trabajo alrededor de las limitaciones de las herramientas.

Qué Realmente Solucionaría Esto

La brecha de preparación de datos no se cerrará contratando más ingenieros de ML o trabajando más rápido. Se cerrará cuando se aborden los problemas estructurales:

1. Plataformas Unificadas

Reemplazar la cadena de 3 a 7 herramientas con una sola plataforma que maneje ingesta, limpieza, etiquetado, aumentación y exportación. No porque la capacidad individual de cada herramienta sea superada, sino porque el costo de integración es el mayor drenaje de eficiencia.

2. Acceso de Expertos de Dominio

Construir herramientas de preparación de datos que los expertos de dominio puedan usar directamente — aplicaciones de escritorio nativas con interfaces visuales, no bibliotecas de Python y contenedores Docker.

3. Registros de Auditoría Integrados

Hacer que el logging sea automático y completo. Cada transformación, cada etiqueta, cada decisión de calidad registrada sin esfuerzo de documentación manual.

4. La Preparación de Datos como Función de Primera Clase

Tratar la preparación de datos como una capacidad central, no un paso de preprocesamiento. Herramientas dedicadas, tiempo dedicado, métricas de calidad dedicadas.

Ertas Data Suite está construido sobre estos principios: una plataforma unificada que cubre las cinco etapas del pipeline, accesible para expertos de dominio a través de una interfaz de escritorio nativa, con registros de auditoría automáticos y documentación de cumplimiento. La estadística del 60-80% persiste porque las herramientas no han cambiado. Cuando las herramientas cambien, los números seguirán.