Versionado de Datasets en la Práctica: Git para Datos de Entrenamiento
Versionas tu código. Versionas tus modelos. ¿Pero versionas tus datos de entrenamiento? El versionado de datasets — diffs, ramas y rollbacks para datasets — es cómo los equipos de IA maduros mantienen la reproducibilidad.
Versionas tu código con Git. Versionas tus modelos con registros de modelos. Pero cuando alguien pregunta "¿qué datos entrenaron el modelo que está actualmente en producción?" — la respuesta típica es un silencio incómodo, seguido de alguien revisando un hilo de Slack de hace cuatro meses.
Esta brecha no es solo inconveniente. Es un fallo de reproducibilidad, depuración y cumplimiento que le cuesta a los equipos semanas de retrabajo cada vez que algo sale mal.
El versionado de datasets — aplicar los mismos conceptos de rama, diff, etiqueta y rollback del versionado de código a los datos de entrenamiento — es cómo los equipos de IA maduros cierran esta brecha. Así es cómo se ve en la práctica.
Por Qué Importa el Versionado de Datasets
Cuatro problemas desaparecen cuando versionas tus datos de entrenamiento correctamente.
Reproducibilidad
"Recrea el dataset exacto que entrenó el modelo v2.3." Sin versionado, esta solicitud desencadena una investigación forense: qué scripts corrieron, qué filtros se aplicaron, qué etiquetas eran las actuales en ese momento, qué datos se excluyeron. Con versionado, es un solo comando de checkout.
La reproducibilidad no es académica. Cuando un modelo se comporta inesperadamente en producción, el primer paso de depuración es inspeccionar los datos de entrenamiento. Si no puedes recrear ese dataset exactamente, estás depurando a ciegas.
Depuración
El modelo v3.1 rinde 8% peor que v3.0 en un tipo específico de documento. ¿Qué cambió? Si tienes datasets versionados, puedes hacer diff de las dos versiones y ver exactamente qué ejemplos se agregaron, eliminaron o modificaron entre ellas. Sin versionado, la investigación toma días y frecuentemente termina con "no estamos seguros."
En un caso que hemos visto, un equipo pasó dos semanas investigando una regresión de rendimiento que resultó ser causada por 47 ejemplos mal etiquetados que se agregaron entre versiones del dataset. Con diff apropiado, lo habrían encontrado en 20 minutos.
Cumplimiento
El EU AI Act requiere que las organizaciones documenten los datos usados para entrenar sistemas de IA. El Artículo 10 específicamente exige gobernanza de datos cubriendo "las elecciones de diseño relevantes, procesos de recolección de datos, operaciones de preparación de datos como anotación, limpieza de datos y enriquecimiento de datos." El derecho de explicación del GDPR crea requisitos similares.
El versionado de datasets proporciona el rastro de auditoría que los reguladores esperan: qué datos se usaron, cuándo se recopilaron, cómo se transformaron, y qué modelo se entrenó con qué versión. Sin esto, demostrar cumplimiento requiere reconstruir la historia a partir de fragmentos — un proceso que los auditores ven con escepticismo justificado.
Rollback
Tu equipo actualizó las guías de etiquetado y re-etiquetó 2,000 ejemplos. El modelo reentrenado rinde peor. Con versionado de datasets, vuelves a la versión anterior del dataset y reentrenar. Sin él, intentas deshacer los cambios de etiquetado manualmente — un proceso que introduce nuevos errores.
La capacidad de rollback convierte los errores de preparación de datos de catástrofes en contratiempos menores. Los equipos que pueden hacer rollback experimentan más libremente, lo que lleva a mejores datasets más rápido.
Enfoques Actuales para Versionado de Datasets
Varias herramientas implementan versionado de datasets, cada una con diferentes compromisos.
DVC (Data Version Control)
La herramienta más ampliamente adoptada. DVC extiende Git con soporte de archivos grandes — rastrear archivos de datos con DVC mientras rastrear los metadatos (hashes, definiciones de pipeline) con Git. Los datos se almacenan en almacenamiento remoto (S3, GCS, Azure Blob) mientras Git almacena archivos puntero ligeros.
Fortalezas: Flujo de trabajo nativo de Git, comunidad fuerte, funciona con cualquier backend de almacenamiento. Debilidades: Requiere proficiencia en línea de comandos, hacer diff de datasets grandes es lento, sin visualización incorporada de cambios en datasets.
lakeFS
Operaciones tipo Git directamente sobre data lakes. lakeFS proporciona branching, committing y merging para datos almacenados en almacenamiento de objetos. Funciona en la capa de almacenamiento, por lo que es transparente para herramientas que leen desde endpoints compatibles con S3.
Fortalezas: Escalable a petabytes, branching sin copia (las ramas no duplican datos), funciona con herramientas existentes de data lake. Debilidades: Requiere configuración de infraestructura, optimizado para data lakes en lugar de datasets estructurados.
Pachyderm
Combina versionado de datos con orquestación de pipelines. Cada transformación de datos se versiona automáticamente, creando un grafo completo de linaje desde datos crudos hasta salida procesada.
Fortalezas: Rastreo automático de linaje, versionado consciente de pipelines, nativo de Kubernetes. Debilidades: Requisitos de infraestructura más pesados, curva de aprendizaje más pronunciada, excesivo para equipos que solo necesitan versionado.
Versionado Manual (Carpetas con Timestamp)
El enfoque con el que la mayoría de los equipos empiezan: dataset_v1/, dataset_v2/, dataset_20260115/. Simple de entender, fácil de implementar.
Debilidades: Sin capacidad de diff, sin branching, sin resolución de conflictos de merge, ineficiente en almacenamiento (copias completas), las convenciones de nomenclatura colapsan a escala, sin metadatos sobre qué cambió o por qué. Este enfoque funciona para 3-5 versiones. Falla a más de 20.
Qué Versionar
No todos los artefactos de datos necesitan el mismo nivel de rigor de versionado. Aquí hay un orden de prioridad:
Siempre versionar:
- Datos etiquetados — la entrada directa al entrenamiento del modelo. Cada cambio importa.
- Configuraciones de exportación — las configuraciones que determinan cómo los datos etiquetados se convierten en datos de entrenamiento (formato, divisiones, reglas de filtrado).
- Guías de etiquetado — el documento que define qué significa cada etiqueta. Los cambios aquí invalidan etiquetas previas.
Versionar cuando sea práctico:
- Datos limpios — post-procesamiento, pre-etiquetado. Útil para depurar el pipeline de limpieza.
- Datos crudos — los documentos originales antes de cualquier procesamiento. Importante para cumplimiento, pero los datos crudos frecuentemente son grandes y cambian con poca frecuencia.
Versionar si los recursos lo permiten:
- Datos aumentados — ejemplos sintéticos, salidas de aumento de datos. Estos pueden regenerarse desde el pipeline de aumento, por lo que el versionado es menos crítico si el pipeline en sí está versionado.
El Flujo de Trabajo de Versionado
Un flujo de trabajo práctico de versionado de datasets refleja el modelo de branching de Git que los equipos de desarrollo ya conocen.
Rama Principal
La rama main contiene el dataset de producción actual — el dataset que entrenó el modelo actualmente en producción. Esta rama está protegida: sin modificaciones directas. Todos los cambios llegan a través de solicitudes de merge.
Ramas de Experimento
Cuando un miembro del equipo quiere modificar el dataset — agregar nuevos ejemplos, re-etiquetar existentes, eliminar entradas problemáticas — crea una rama. Esta rama es una copia aislada (o en implementaciones eficientes, una referencia copy-on-write) donde se pueden hacer cambios sin afectar el dataset de producción.
Las ramas de experimento son baratas. Los equipos deberían crearlas libremente: add-medical-terminology, relabel-contract-clauses, remove-duplicate-invoices. Cada rama documenta su intención en su nombre.
Revisión y Merge
Antes de hacer merge de una rama de dataset a main, el equipo revisa el diff. Preguntas clave:
- ¿Cuántos ejemplos se agregaron, modificaron o eliminaron?
- ¿Los cambios desplazan la distribución de clases significativamente?
- ¿Las métricas de calidad (acuerdo inter-anotador, cumplimiento de formato) cumplen los umbrales?
- ¿Un experto de dominio ha revisado los cambios?
Esta revisión detecta problemas antes de que contaminen el dataset de producción. Es el equivalente de datos de la revisión de código — y es igualmente importante.
Etiquetado de Releases
Cuando un dataset se usa para entrenar un modelo, etiquétalo con la versión del modelo: model-v3.1-dataset. Esto crea un punto de referencia permanente e inmutable. Seis meses después, cualquiera puede hacer checkout exactamente del dataset que entrenó v3.1.
Las etiquetas deben incluir metadatos: número de ejemplos, resumen de distribución de clases, puntajes de calidad y la fecha de la corrida de entrenamiento.
Capacidades de Diff
La característica más valiosa del versionado de datasets es la capacidad de hacer diff de dos versiones. A diferencia de los diffs de código (que comparan líneas de texto), los diffs de datasets necesitan capturar:
Cambios a nivel de fila: Qué ejemplos se agregaron, eliminaron o modificaron entre versiones. Para un dataset con 5,000 ejemplos, saber que se agregaron 47 y se re-etiquetaron 12 es inmediatamente útil.
Cambios de etiquetas: Específicamente qué etiquetas cambiaron y cómo. ¿Los ejemplos se movieron de categoría A a categoría B? ¿Hubo un re-etiquetado sistemático? Esto ayuda a identificar si los cambios de etiquetas fueron intencionales (actualización de guías) o accidentales (error del anotador).
Shifts de distribución: ¿Cómo cambió la distribución general del dataset? Si la clase A pasó del 30% al 15% del dataset, ese es un shift significativo que afectará el comportamiento del modelo. Los diffs de distribución deben señalarse automáticamente durante la revisión.
Cambios de esquema: ¿Cambió el formato de salida? ¿Se agregaron nuevos campos? Esto detecta inconsistencias de formato que romperían el entrenamiento.
Estrategias de Almacenamiento
El versionado ingenuo — almacenar una copia completa del dataset para cada versión — es desperdicio. Un dataset de 10GB con 50 versiones consumiría 500GB.
Codificación delta almacena solo los cambios entre versiones. La versión 1 se almacena completa; la versión 2 almacena solo las filas que se agregaron, modificaron o eliminaron. Esto reduce el almacenamiento en 80-95% para datasets típicos donde cada versión cambia menos del 20% de los datos.
Almacenamiento dirigido por contenido (usado por DVC y Git LFS) almacena cada chunk de archivo único una vez y lo referencia por hash. Los chunks idénticos entre versiones se almacenan solo una vez.
Almacenamiento remoto mantiene datos en almacenamiento en la nube (S3, GCS) o almacenamiento conectado a red mientras mantiene solo metadatos y punteros localmente. Esto es esencial para datasets de más de 10GB.
Integración con Entrenamiento de Modelos
El versionado de datasets entrega su valor completo cuando se integra con el entrenamiento de modelos. Los puntos de integración:
Metadatos de entrenamiento: Cada corrida de entrenamiento registra la versión del dataset (etiqueta o hash de commit) que usó. Este es un solo campo en la configuración de entrenamiento, pero habilita trazabilidad completa.
Validación automatizada: Antes de que el entrenamiento comience, el pipeline valida que la versión del dataset exista, pase verificaciones de calidad y coincida con el esquema esperado. Esto previene entrenar con datasets corruptos o incompletos.
Corridas de comparación: Entrena dos modelos con dos versiones de dataset con hiperparámetros idénticos. La diferencia de rendimiento es atribuible enteramente a cambios en los datos. Así es cómo mides el impacto de mejoras en los datos.
Rastreo de linaje: Desde un modelo en producción, rastrea hasta la versión del dataset, luego hasta las sesiones de etiquetado individuales que contribuyeron a él. Linaje completo desde predicción hasta datos fuente.
Ertas Data Suite implementa versionado de datasets con capacidades completas de diff, flujos de trabajo de branch-and-merge y rastreo automático de linaje desde ejemplos etiquetados hasta datasets exportados. Cada cambio se rastrea con quién lo hizo, cuándo y por qué — proporcionando el rastro de auditoría que la reproducibilidad y el cumplimiento requieren. Todos los datos permanecen en tu infraestructura, con codificación delta eficiente en almacenamiento que mantiene el versionado práctico incluso para datasets grandes.
Your data is the bottleneck — not your models.
Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.
Lectura Adicional
- What Is Data Lineage for Enterprise AI? — Entendiendo el linaje de datos de extremo a extremo y por qué importa para la gobernanza de IA.
- Data Lineage Reports as Enterprise AI Deliverables — Cómo producir informes de linaje que satisfagan requisitos de cumplimiento y stakeholders.
- AI Model Versioning, Rollback, and Drift — El complemento del lado del modelo al versionado de datasets — gestionar versiones de modelos junto con versiones de datos.
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading
Preparing Tool-Calling Datasets for Enterprise AI Agents: An On-Premise Workflow
AI agents need tool-calling training data to reliably select and invoke the right tools. Here's how to prepare function-calling datasets from enterprise documents — entirely on-premise.
DPO and Preference Data: Preparing Alignment Datasets On-Premise
DPO alignment requires chosen/rejected response pairs. For enterprises with sensitive data, this preparation must happen on-premise. Here's the complete workflow for building preference datasets without data egress.
From Documents to Agent Knowledge Bases: The Complete Data Pipeline
Enterprise AI agents are only as good as their knowledge base. Here's the end-to-end pipeline for converting unstructured documents into structured, agent-ready knowledge — from PDF ingestion to retrieval-optimized chunks.