Las cinco etapas de un pipeline de datos de IA empresarial: Ingestión, Limpieza, Etiquetado, Aumento, Exportación

La mayoría de los equipos de IA empresarial pueden nombrar las etapas de un pipeline de datos. Menos tienen una imagen clara de qué produce realmente cada etapa, cuáles son los modos de falla comunes y por qué el enfoque estándar de múltiples herramientas crea problemas compuestos a lo largo de todo el pipeline.

Este artículo desglosa cada una de las cinco etapas — Ingestión, Limpieza, Etiquetado, Aumento, Exportación — con atención específica a qué sale mal en cada una y por qué las transiciones entre etapas son donde se pierde la mayor parte del tiempo.

Etapa 1: Ingestión

Qué es: Parsear archivos fuente crudos en texto estructurado (o datos estructurados) que las etapas posteriores pueden procesar.

Qué consume: Archivos crudos — PDFs, documentos de Word, libros de Excel, imágenes, exportaciones CAD, transcripciones de audio.

Qué produce: Texto extraído organizado en documentos, secciones, párrafos, tablas y metadatos. Aún sin limpiar. Aún sin etiquetar. Pero legible por una máquina.

Qué sucede en esta etapa

Diferentes formatos de archivo requieren diferentes enfoques de parseo:

Dónde se atascan los equipos

El problema más consistente es subestimar la dificultad del OCR en documentos escaneados. Los equipos que solo han trabajado con PDFs nativos esperan que la extracción de texto sea rápida y limpia. Los PDFs escaneados de archivos — especialmente archivos antiguos — pueden tener problemas de calidad de escaneo (inclinación, baja resolución, tinta desvanecida) que elevan las tasas de error del OCR muy por encima de lo aceptable para datos de entrenamiento. El ciclo de depuración — descubrir los errores de extracción, ajustar los parámetros del OCR, re-ejecutar, validar — toma significativamente más tiempo que la extracción en sí.

La extracción de tablas es el segundo punto problemático importante. Las tablas extraídas incorrectamente producen registros de entrenamiento que son estructuralmente válidos (pasan las verificaciones de esquema) pero semánticamente incorrectos (los valores de las columnas están asignados a los encabezados equivocados). Estos errores son difíciles de detectar automáticamente y se propagan silenciosamente a los datos de entrenamiento.

Etapa 2: Limpieza

Qué es: Eliminar errores, duplicados y datos sensibles; puntuar la calidad de los registros; registrar cada transformación.

Qué consume: Texto extraído de la Etapa 1.

Qué produce: Texto limpio, deduplicado con datos sensibles redactados y un registro de transformaciones documentando cada cambio.

Qué sucede en esta etapa

Normalización de codificación. El OCR y la extracción de PDF introducen artefactos de codificación — caracteres distorsionados, Unicode incorrecto, caracteres específicos de Windows renderizados como símbolos. La normalización convierte todo el texto a codificación consistente, resuelve sustituciones comunes y elimina caracteres no imprimibles.

Deduplicación. Los archivos de documentos empresariales contienen contenido casi duplicado a tasas altas — a menudo 15-30% de los documentos. Los casi-duplicados provienen de: archivos adjuntos de email enviados múltiples veces, revisiones de documentos que difieren en solo unas líneas, documentos basados en plantillas donde solo cambian nombres y fechas, y prácticas de copiar y pegar donde secciones se reproducen en múltiples documentos.

La deduplicación exacta (coincidencia de hash) detecta copias idénticas. La detección de casi-duplicados requiere medidas de similitud: MinHash o SimHash para coincidencia aproximada rápida, o similitud de embeddings para casi-duplicados semánticos. Sin este paso, los datos de entrenamiento parecen más grandes de lo que son, y el modelo aprende a reproducir contenido común con exceso de confianza.

Detección y redacción de PII/PHI. La coincidencia automatizada de patrones y el reconocimiento de entidades nombradas identifican: nombres, direcciones de email, números de teléfono, direcciones físicas, IDs gubernamentales (SSN, números de pasaporte), números de cuentas financieras y — para datos de salud — identificadores de pacientes, códigos de diagnóstico y números de registros clínicos. Cada redacción se registra con el tipo de identificador detectado, la posición en el documento y la marca de tiempo.

Puntuación de calidad. Los registros se puntúan en: longitud (demasiado cortos para ser significativos, o demasiado largos para la ventana de contexto del modelo), coherencia (distorsión aparente del OCR que produce texto sin sentido), idioma (registros en idiomas inesperados) y completitud estructural (registros sin campos requeridos para el formato objetivo).

Dónde se atascan los equipos

La detección de PII tiene un trade-off de precisión-exhaustividad que debe gestionarse explícitamente. Alta exhaustividad (detectar todo) produce sobre-redacción — señalando nombres de empresas, nombres de productos y términos técnicos como identificadores personales. Alta precisión (solo señalar identificadores obvios) pasa por alto los menos evidentes. El punto operativo correcto depende de la sensibilidad de los datos y los requisitos de cumplimiento posteriores, y requiere validación contra una muestra del corpus real — no solo contra un dataset de referencia.

El otro problema común es tratar la deduplicación como opcional. Equipo tras equipo en las llamadas de descubrimiento describe datasets que tomaron meses en etiquetar, solo para descubrir después que el 20-30% de los registros etiquetados eran casi-duplicados. El trabajo de etiquetado no se desperdicia, pero el tamaño efectivo del dataset es mucho menor de lo esperado, y la distribución de etiquetas está sesgada hacia el contenido sobrerepresentado.

Etapa 3: Etiquetado

Qué es: Asignar significado semántico a los datos limpios — etiquetas de entidades, etiquetas de clasificación, cuadros delimitadores, pares de pregunta-respuesta.

Qué consume: Texto o imágenes limpios y deduplicados de la Etapa 2.

Qué produce: Registros anotados listos para entrenamiento, con etiquetas que reflejan el juicio de expertos del dominio.

Qué sucede en esta etapa

Diferentes tareas de IA requieren diferentes tipos de anotación:

El problema del experto de dominio

El etiquetado es donde la brecha entre las herramientas de ML y la realidad empresarial es más visible.

Considera: un hospital quiere entrenar un modelo para extraer información de medicamentos de notas clínicas. Las anotaciones deben ser clínicamente precisas — nombres de medicamentos, dosis, vías de administración y contraindicaciones etiquetados correctamente según los estándares clínicos. Las personas con la experiencia para hacer esto correctamente son los clínicos.

Las herramientas de anotación estándar (Label Studio, Prodigy, CVAT) están construidas para ingenieros de ML. Requieren instalación, configuración, a menudo entornos Docker o Python, y comodidad con interfaces técnicas. Lograr que un grupo de médicos las use productivamente requiere entrenamiento extenso o un ingeniero de ML sentado junto a cada médico como traductor.

El resultado es que el etiquetado sucede lentamente (porque los ingenieros de ML lo hacen sin experiencia en el dominio) o de manera costosa (porque los expertos del dominio no pueden acceder a las herramientas de forma independiente). El acceso de expertos del dominio a herramientas de etiquetado que no requieran configuración técnica es una restricción genuina, no algo agradable de tener.

Dónde se atascan los equipos

Consistencia de etiquetas. Sin calibración, múltiples anotadores aplican etiquetas de manera diferente. Un clínico etiqueta "metformina 500mg" como un par medicamento-dosis. Otro lo etiqueta como una sola entidad de medicamento. Un tercero lo divide en tres entidades separadas. El dataset resultante tiene semántica de etiquetas inconsistente que produce un modelo con predicciones inconsistentes. El acuerdo entre anotadores debe medirse y calibrarse antes de las rondas de etiquetado a escala.

Subestimación de escala. Un corpus de 5,000 documentos podría requerir 50,000 spans de entidades etiquetados. A 3 minutos por documento para anotación cuidadosa, eso son 250 horas de tiempo de experto del dominio. Este número raramente está en el plan del proyecto.

Etapa 4: Aumento

Qué es: Generar ejemplos de entrenamiento adicionales — ya sea a partir de datos existentes o mediante generación sintética usando un LLM local.

Qué consume: Datos etiquetados de la Etapa 3.

Qué produce: Un dataset expandido con ejemplos aumentados, todos rastreables hasta su fuente.

Qué sucede en esta etapa

El aumento aborda dos problemas comunes de datos:

Desequilibrio de clases. Los datasets empresariales reales no están balanceados. Las notas clínicas mencionan condiciones comunes mucho más que las raras. Los contratos legales contienen cláusulas estándar mucho más que las inusuales. Un modelo entrenado con datos desequilibrados aprende a predecir las clases mayoritarias y tiene bajo rendimiento en las clases minoritarias que pueden ser exactamente las que más importan.

El aumento genera ejemplos adicionales para las clases subrepresentadas — paráfrasis de ejemplos existentes, ejemplos sintéticos generados por un LLM local usando los ejemplos existentes como plantillas, o retrotraducción (traducir a otro idioma, traducir de vuelta, produciendo una variación natural).

Volumen insuficiente. El fine-tuning de un modelo de lenguaje para una tarea especializada típicamente requiere 1,000-10,000 ejemplos etiquetados de alta calidad. Si el corpus real solo contiene 300 documentos relevantes, la generación sintética usando un LLM local — con los ejemplos etiquetados existentes como prompt — puede expandir el dataset a la escala requerida sin recolectar datos reales adicionales.

La restricción crítica: sin egreso de datos

Para empresas reguladas, el aumento usando APIs de LLM en la nube no es viable. Enviar notas clínicas etiquetadas, documentos legales o registros financieros a una API externa para generar variantes sintéticas expone los mismos datos sensibles de los documentos fuente. El aumento debe ejecutarse on-premise, usando un LLM alojado localmente — Llama 3, Mistral, Qwen u modelos similares que pueden ejecutarse en hardware empresarial sin conectividad a internet.

Dónde se atascan los equipos

La calidad de los datos sintéticos es tan buena como la estrategia de prompting y la calidad de los ejemplos fuente usados como plantillas. La generación sintética ingenua produce ejemplos que son superficialmente similares a los datos de entrenamiento pero pierden los casos extremos y variaciones que hacen un modelo robusto. La revisión humana de los ejemplos sintéticos antes de incluirlos en el conjunto de entrenamiento es necesaria, no opcional.

Etapa 5: Exportación

Qué es: Convertir el dataset preparado, etiquetado y aumentado de la representación interna al formato exacto requerido por el framework de entrenamiento objetivo.

Qué consume: El dataset preparado y etiquetado completo.

Qué produce: Archivos listos para entrenamiento en el formato objetivo — JSONL, texto fragmentado, anotaciones YOLO/COCO, CSV.

Qué sucede en esta etapa

Diferentes usos posteriores requieren diferentes formatos de exportación:

Un pipeline bien diseñado puede exportar múltiples formatos desde un solo proyecto preparado — sin re-etiquetar. Esto importa cuando un dataset se usará tanto para fine-tuning (JSONL) como para RAG (texto fragmentado), o cuando un dataset de VC necesita exportarse tanto en formato YOLO como COCO para diferentes frameworks de entrenamiento.

Dónde se atascan los equipos

Fallas de validación de formato. JSONL que no se carga en el framework de entrenamiento por problemas de codificación, discrepancias en nombres de campos o errores de esquema descubiertos solo cuando se intenta el entrenamiento. Un paso de validación contra el esquema real del framework de entrenamiento — antes de declarar la exportación completa — previene estas sorpresas.

La capa faltante

Cada etapa tiene herramientas dedicadas: Docling o Unstructured.io para ingestión, Cleanlab para puntuación de calidad, Label Studio o CVAT para anotación, Distilabel para aumento, scripts personalizados para exportación. El problema es que estas herramientas no comparten un modelo de datos, no comparten controles de acceso y no comparten un registro.

Cuando los datos se mueven de la Etapa 1 a la Etapa 2 a la Etapa 3, el linaje se rompe. No hay un registro único que diga: este ejemplo de entrenamiento vino de la página 14 del documento X, fue redactado por el operador Y en el tiempo T, fue etiquetado por el operador Z y fue aumentado por el método M. Sin ese registro, el rastro de auditoría requerido por el Artículo 10 del EU AI Act y HIPAA no existe.

Construir ese rastro de auditoría sobre un stack de herramientas fragmentado requiere ingeniería de integración significativa — y tiene que reconstruirse para cada proyecto que use una combinación diferente de herramientas.

Ertas Data Suite cubre las cinco etapas en una sola aplicación con un modelo de proyecto compartido y un registro de auditoría unificado, eliminando la carga de integración y produciendo linaje completo como subproducto de la operación normal.

---

Lecturas relacionadas

• The Enterprise Guide to AI Data Preparation — El panorama estratégico completo de la preparación de datos empresarial, desde archivos crudos hasta datasets listos para entrenamiento.
• What Is Data Lineage — and Why Enterprise AI Teams Can't Ignore It — Por qué el rastro de auditoría entre etapas importa para cumplimiento y depuración.
• How Long Does Enterprise AI Data Preparation Actually Take? — Cronogramas realistas para cada etapa, con benchmarks por tipo de dato y volumen.