Los equipos de producción de aprendizaje automático (ML) luchan por rastrear el linaje completo de un modelo a través de los datos y el código que lo entrenó, la versión exacta del conjunto de datos que consumió y las métricas del experimento que justificaron su implementación. Sin esta trazabilidad, preguntas como "¿qué datos entrenaron el modelo actualmente en producción?" o "¿podemos reproducir el modelo que implementamos hace seis meses?" se convierten en investigaciones de varios días a través de registros dispersos, cuadernos y depósitos de Amazon Simple Storage Service (Amazon S3). Esta brecha es especialmente aguda en las industrias reguladas. Por ejemplo, atención médica, servicios financieros, vehículos autónomos, donde los requisitos de auditoría exigen que se vinculen los modelos implementados con sus datos de capacitación precisos, y donde es posible que sea necesario excluir registros individuales de capacitación futura a pedido.
En esta publicación, mostramos cómo combinar tres herramientas para cerrar esta brecha:
Analizamos dos patrones implementables, linaje a nivel de conjunto de datos y linaje a nivel de registro, que puede ejecutar de un extremo a otro en su propia cuenta de AWS utilizando los cuadernos complementarios.
Descripción general de la solución
La arquitectura integra DVC, SageMaker AI y la aplicación SageMaker AI MLflow en un único flujo de trabajo donde se puede rastrear cada modelo hasta sus datos de entrenamiento exactos.
Cada herramienta juega un papel distinto:
Función de la herramienta Qué almacena DVC Versiones de datos y artefactos Metarchivos .dvc ligeros en Git; datos reales en Amazon S3 Amazon SageMaker AI Computación escalable para procesamiento, capacitación y alojamiento Modelo y orquestación de trabajos de procesamiento/capacitación Alojamiento de la aplicación MLflow de Amazon SageMaker AI Seguimiento de experimentos, registro de modelos, linaje Parámetros, métricas, artefactos, modelos registrados
Los datos fluyen a través de cuatro etapas:
Un trabajo de procesamiento de IA de SageMaker preprocesa los datos sin procesar y versiona el conjunto de datos procesados con DVC, enviando los datos a S3 y los metadatos a un repositorio Git. Un trabajo de SageMaker AI Training clona el repositorio DVC en una etiqueta Git específica, ejecuta dvc pull para recuperar el conjunto de datos versionado exacto, entrena el modelo y registra todo en MLflow. Cada ejecución de entrenamiento de MLflow registra data_git_commit_id, que es el hash de confirmación de DVC que apunta al conjunto de datos exacto en Amazon S3. El modelo entrenado se registra en el Registro de modelos de MLflow y se puede implementar en un punto final de SageMaker AI.
Esto crea una cadena de trazabilidad completa: Modelo de producción → Ejecución de MLflow → Confirmación de DVC → Conjunto de datos exacto en Amazon S3.
Requisitos previos
Debe tener los siguientes requisitos previos para seguir esta publicación:
Una cuenta de AWS con permisos para Amazon SageMaker (procesamiento, capacitación, aplicaciones MLflow, puntos finales), Amazon S3, AWS CodeCommit y AWS Identity Access Management (IAM). Python 3.11 o Python 3.12. El SDK de SageMaker Python v3.4.0 o posterior.
El repositorio complementario incluye un archivo require.txt con todas las dependencias. Si se ejecuta fuera de SageMaker Studio, su función de IAM debe tener una relación de confianza que permita a sagemaker.amazonaws.com asumirla.
Nota sobre los proveedores de Git: los cuadernos utilizan AWS CodeCommit como backend de Git para los metadatos de DVC. Sin embargo, DVC funciona con otros proveedores de Git (GitHub, GitLab, Bitbucket). Todo lo que necesita hacer es reemplazar la URL de origen de adición remota de git y configurar las credenciales apropiadas. Por ejemplo, almacenando tokens en AWS Secrets Manager y recuperándolos en tiempo de ejecución o utilizando AWS CodeConnections. El requisito clave es que su función de ejecución de SageMaker AI pueda acceder al repositorio de Git o tenga permisos para usar AWS CodeConnections.
Cómo funcionan juntos DVC y SageMaker AI MLflow
La idea clave detrás de esta arquitectura es que DVC y MLflow resuelven cada uno la mitad del problema del linaje y juntos cierran el círculo.
DVC (Control de versiones de datos) es una herramienta de código abierto y gratuita que amplía Git para manejar grandes conjuntos de datos y artefactos de aprendizaje automático. Git por sí solo no puede administrar archivos binarios grandes porque los repositorios se vuelven inflados y lentos, y sistemas como GitHub bloquean archivos de más de 100 MB. DVC aborda esto a través de la codificación: rastrea metarchivos .dvc livianos en Git (punteros direccionables por contenido) mientras que los datos reales residen en un almacenamiento remoto como Amazon S3. Esto le brinda una semántica de control de versiones similar a la de Git (ramificación, etiquetado, diferenciación) para conjuntos de datos que pueden tener un tamaño de gigabytes o terabytes, sin inflar su repositorio.
Eficiencia de almacenamiento:
DVC utiliza almacenamiento direccionable por contenido (hashes MD5), por lo que almacena solo archivos nuevos o modificados en lugar de duplicar conjuntos de datos completos. Los archivos con contenidos idénticos se almacenan solo una vez en la caché de DVC, incluso si aparecen con nombres diferentes o en diferentes versiones de conjuntos de datos. Por ejemplo, agregar 1000 imágenes nuevas a un conjunto de datos existente solo carga esos archivos nuevos en S3. Los archivos sin cambios no se vuelven a cargar. Sin embargo, si un paso de preprocesamiento modifica archivos existentes, los archivos afectados obtienen nuevos hashes y se almacenan como objetos nuevos.
Más allá del control de versiones de datos, DVC también admite canalizaciones de datos reproducibles, gestión de experimentos y puede servir como un registro de datos para compartir conjuntos de datos entre equipos. En esta arquitectura, utilizamos DVC específicamente por su capacidad de control de versiones de datos. Cada vez que versionas un conjunto de datos con dvc add y confirmas el archivo .dvc resultante, creas una confirmación de Git que se asigna a un estado de conjunto de datos específico. Etiquetar ese compromiso le brinda una referencia estable a la que puede regresar con git checkout && dvc pull. Para profundizar en las capacidades de control de versiones de DVC, consulte la guía Versiones de datos y modelos.
La aplicación SageMaker AI MLflow es un servicio de AWS totalmente administrado que se ofrece dentro de SageMaker AI Studio, para administrar el ciclo de vida de ML de extremo a extremo y de IA generativa. Sus capacidades principales incluyen seguimiento de experimentos (parámetros de registro, métricas y artefactos para cada ejecución de capacitación), un registro de modelos con gestión de versiones y etapas del ciclo de vida, evaluación de modelos e integraciones de implementación. En la arquitectura de esta publicación, utilizamos MLflow para el seguimiento completo del experimento, incluidos los resultados de DVC y el registro de modelos. Al registrar el hash de confirmación de DVC como parámetro (data_git_commit_id) en cada ejecución de entrenamiento, creamos el puente: los modelos en el registro de MLflow se pueden rastrear hasta la etiqueta Git exacta, que se asigna al conjunto de datos exacto en S3.
Si bien DVC puede manejar tanto el control de versiones de datos como el seguimiento de experimentos por sí solo, MLflow ofrece un registro de modelos más maduro con control de versiones de modelos, alias para la gestión del ciclo de vida e integraciones de implementación. Al utilizar DVC para el control de versiones de datos y MLflow para la gestión del ciclo de vida del modelo, obtenemos una clara separación de preocupaciones: DVC posee el linaje de datos a entrenamiento, MLflow posee el linaje de entrenamiento a implementación y el hash de confirmación de Git los une.
Patrón uno: linaje a nivel de conjunto de datos (fundamental)
Antes de construir la integración, es esencial comprender cómo el control de versiones del conjunto de datos de DVC y el seguimiento de ejecución de MLflow se complementan entre sí para formar un linaje completo. El cuaderno fundamental demuestra el patrón central simulando un escenario común: comenzar con datos etiquetados limitados y expandirse con el tiempo.
El flujo de trabajo
El cuaderno ejecuta dos experimentos utilizando el conjunto de datos de clasificación de imágenes CIFAR-10:
v1.0: Procesar y entrenar con el 5 % de los datos (~2250 imágenes de entrenamiento) v2.0: Procesar y entrenar con el 10 % de los datos (~4500 imágenes de entrenamiento)
Para cada versión, se ejecuta el mismo proceso de dos pasos:
Paso 1: Trabajo de procesamiento: un trabajo de procesamiento de SageMaker descarga CIFAR-10, toma muestras de la fracción configurada, la divide en conjuntos de entrenamiento/validación/prueba, guarda imágenes en formato ImageFolder y versiona el resultado con DVC. El conjunto de datos procesado se envía a S3 mediante dvc push y los metadatos de Git (incluida una etiqueta única como v1.0-02-24-26_1430) se envían a CodeCommit.
El trabajo de procesamiento recibe la URL del repositorio DVC y la URI de seguimiento de MLflow como variables de entorno:
Dentro del script de procesamiento, después del preprocesamiento, el conjunto de datos se versiona con DVC y el hash de confirmación se registra en MLflow:
Paso 2: Trabajo de capacitación: un trabajo de capacitación de IA de SageMaker clona el repositorio DVC en la etiqueta exacta del Paso 1, ejecuta dvc pull para descargar el conjunto de datos versionado y ajusta un modelo MobileNetV3-Small previamente entrenado. El script de entrenamiento registra los parámetros (incluido el hash de confirmación de DVC), las métricas por época y el modelo entrenado en MLflow. El modelo se registra automáticamente en el Registro de modelos de MLflow.
El puente de linaje crítico (registrar el hash de confirmación de DVC en MLflow) ocurre en el script de entrenamiento:
Lo que ves en MLflow
Una vez completados ambos experimentos, la interfaz de usuario de MLflow muestra ambas ejecuciones una al lado de la otra, como se muestra en la siguiente captura de pantalla. En el experimento de MLflow, puedes comparar:
Curvas de precisión de entrenamiento y validación entre versiones de datos. Los hiperparámetros y la versión de datos exactos para cada ejecución. El data_git_commit_id que vincula cada modelo a su conjunto de datos DVC.
Al seleccionar una ejecución, se muestran todos los detalles, las curvas de pérdida, los parámetros y el enlace de confirmación de DVC al conjunto de datos exacto en S3, como se muestra en la siguiente captura de pantalla.
Finalmente, los modelos entrenados de inteligencia artificial y aprendizaje automático (AI/ML) se registran automáticamente en el Registro de modelos de MLflow con un historial de versiones y enlaces a la ejecución de entrenamiento que los produjo, como se muestra en la siguiente captura de pantalla. Además, con la aplicación SageMaker AI MLflow integrada con SageMaker AI Model Registry, MLflow registra automáticamente el modelo registrado en SageMaker AI Model Registry.
Implementando el modelo
El cuaderno implementa el modelo recomendado (v2.0, entrenado con más datos) desde MLflow Model Registry en un punto final de SageMaker AI en tiempo real mediante ModelBuilder. Después de la implementación, puede invocar el punto final con bytes de imagen sin procesar y recuperar predicciones de clase. El código completo de implementación e inferencia se encuentra en el cuaderno.
¿Qué responde este patrón?
Con el linaje a nivel de conjunto de datos, puede responder:
"¿Qué versión del conjunto de datos entrenó este modelo?" — Busque data_git_commit_id en la ejecución de MLflow "¿Puedo reproducir los datos de entrenamiento de este modelo?" — Ejecute git checkout && dvc pull para restaurar el conjunto de datos exacto "¿Por qué cambió el rendimiento del modelo?" — Compare ejecuciones en MLflow y rastree cada una hasta su versión de datos
Lo que no responde sin trabajo adicional: "¿Estaba el registro X en los datos de entrenamiento de este modelo?" Necesitaría extraer el conjunto de datos completo y buscarlo. Ahí es donde entra en juego el patrón dos.
Patrón dos: linaje a nivel de registro (cumplimiento de la atención médica)
El patrón 2 se basa directamente en el enfoque a nivel de conjunto de datos, agregando trazabilidad a nivel de registro/paciente a través de manifiestos y registros de consentimiento. El ejemplo del cuaderno de cumplimiento de atención sanitaria amplía el patrón fundamental para entornos regulados en los que es necesario rastrear registros individuales, no solo conjuntos de datos, a lo largo del ciclo de vida del aprendizaje automático.
La adición clave: un manifiesto
La diferencia es manifiesta. Un manifiesto es un CSV estructurado que enumera cada registro individual en cada versión del conjunto de datos:
Este manifiesto se guarda dentro del directorio del conjunto de datos con versión DVC y se registra como un artefacto de MLflow en cada ejecución de entrenamiento. Esto hace que los registros individuales se puedan consultar directamente desde MLflow sin extraer el conjunto de datos completo de DVC.
El registro de consentimiento
El flujo de trabajo está impulsado por un registro de consentimiento, que es un archivo CSV que enumera a cada paciente y su estado de consentimiento. En producción, esto sería una base de datos con compromisos transaccionales, su propio registro de auditoría y desencadenantes potencialmente impulsados por eventos para iniciar la recapacitación. El enfoque CSV aquí está simplificado con fines de demostración, pero el patrón de integración es el mismo: el trabajo de procesamiento lee el registro y solo incluye registros con consentimiento activo.
El código de procesamiento es idempotente. No conoce ni le importan las opciones de exclusión voluntaria, filtra por consent_status == "activo" y procesa lo que quede. Una exclusión voluntaria es un cambio de entrada que produce un conjunto de datos nuevo y limpio cuando se vuelve a ejecutar la misma canalización.
El flujo de trabajo de exclusión voluntaria
El cuaderno demuestra un ciclo completo de exclusión voluntaria:
v1.0 – Línea de base: procesar y capacitar a todos los pacientes que hayan dado su consentimiento. El manifiesto enumera los análisis de paciencia. El modelo se registra en MLflow con el manifiesto como artefacto. Evento de exclusión voluntaria: el paciente PAT-00023 solicita optar por no participar. Su estado de consentimiento se actualiza para ser revocado en el registro y el registro actualizado se carga en S3. v2.0: conjunto de datos limpio: el mismo trabajo de procesamiento se ejecuta con el registro actualizado. Las imágenes de PAT-00023 se excluyen automáticamente. DVC versiona el nuevo conjunto de datos (137 pacientes). El modelo se vuelve a entrenar y se registra como una nueva versión en MLflow. Verificación de auditoría: consulte MLflow para confirmar que PAT-00023 aparece solo en el modelo v1.0 y no está presente en los modelos entrenados después de la fecha de exclusión voluntaria.
Consultas de auditoría
El módulo complementario utils/audit_queries.py proporciona tres funciones de consulta que funcionan mediante la descarga de artefactos de manifiesto de MLflow:
find_models_with_patient("PAT-00023"): busca en las ejecuciones de capacitación un ID de paciente. Devuelve solo la ejecución v1.0. verificar_paciente_excluded_after_date("PAT-00023", "2025-06-01"): verifica los modelos entrenados después de una fecha y confirma que el paciente está ausente. Devuelve APROBADO o FALLADO con detalles. get_patients_in_model(run_id): enumera las ID de los pacientes en los datos de entrenamiento de un modelo específico.
Estas consultas no requieren una verificación de DVC: operan completamente en artefactos de MLflow, lo que las hace lo suficientemente rápidas para respuestas de auditoría interactivas.
Nota de producción: Las consultas anteriores descargan el artefacto manifest.csv de cada ejecución de entrenamiento y lo escanean. Esto funciona para algunas ejecuciones pero no escala. En producción, considere escribir tuplas (record_id, run_id, data_version) en Amazon DynamoDB en el momento del entrenamiento, apuntar a Amazon Athena al prefijo del artefacto MLflow en S3 o utilizar un AWS Lambda posterior al entrenamiento para completar un índice.
¿Qué responde este patrón?
Más allá de todo lo que proporciona el patrón fundamental, el linaje a nivel de registro responde:
"¿Qué modelos se entrenaron utilizando las exploraciones del paciente X?" — Consulta instantánea en ejecuciones de MLflow “Verifique que el paciente X haya sido excluido de todos los modelos después de su fecha de exclusión voluntaria” — Auditoría automatizada de aprobación/rechazo “Enumere todos los registros en los datos de entrenamiento del modelo Y” — Descargue el artefacto del manifiesto
Si bien esta demostración utiliza terminología de atención médica, el patrón se aplica a otros dominios que requieren trazabilidad a nivel de registro: servicios financieros, moderación de contenido (contenido enviado por el usuario) u otros sistemas de aprendizaje automático sujetos a solicitudes de eliminación de datos.
Mejores prácticas y gobernanza
La cadena de trazabilidad de tres capas
El flujo de trabajo integrado crea trazabilidad en tres niveles:
Capa Git + DVC: cada versión del conjunto de datos es una etiqueta Git que apunta a una confirmación de DVC. Al ejecutar git checkout && dvc pull se restauran los datos procesados exactos. Capa MLflow: cada ejecución de entrenamiento registra data_git_commit_id, vinculando el modelo a su versión de datos DVC. El manifiesto a nivel de registro (cuando se utiliza) hace que los registros individuales sean consultables. Capa de registro de modelo: cada versión de modelo registrada se vincula a su ejecución de entrenamiento, que a su vez se vincula a su versión de datos.
Consideraciones de seguridad para entornos regulados
DVC y MLflow proporcionan trazabilidad y seguimiento de experimentos, pero por sí solos no son a prueba de manipulaciones. Para implementaciones reguladas (HIPAA, FDA 21 CFR Parte 11, GDPR), aplique controles a nivel de infraestructura:
Bloqueo de objetos S3 (modo de cumplimiento) en controles remotos de DVC y almacenes de artefactos de MLflow para evitar la modificación o eliminación de datos versionados y artefactos de modelo. AWS CloudTrail para un registro independiente y de solo anexos del acceso a la infraestructura de almacenamiento y capacitación. Políticas de IAM que imponen el acceso con privilegios mínimos a los depósitos de producción, los servidores de seguimiento de MLflow y los repositorios de Git. Cifrado en reposo mediante AWS Key Management Service (AWS KMS) para los depósitos de S3 que almacenan datos de DVC y artefactos de MLflow.
Acelerar la iteración
Al ejecutar experimentos repetidos (como el flujo v1.0 → v2.0), dos funciones de SageMaker AI ayudan a agilizar el proceso:
Grupos cálidos administrados por SageMaker: mantenga las instancias de capacitación calientes entre trabajos para que las ejecuciones de capacitación consecutivas reutilicen la infraestructura ya aprovisionada. Agregue keep_alive_period_in_segundos a su configuración de Compute para habilitarlo. Tenga en cuenta que los grupos cálidos se aplican únicamente a trabajos de capacitación, no a trabajos de procesamiento. Canalizaciones de IA de SageMaker: organice el flujo de trabajo de procesamiento → capacitación → registro como una canalización única y repetible. Las canalizaciones manejan dependencias de pasos, pasan artefactos entre pasos automáticamente y se pueden activar mediante programación (por ejemplo, cuando un paciente opta por no participar y se actualiza el manifiesto).
Limpieza
Para evitar cargos continuos, elimine los recursos creados durante el tutorial: el punto final de SageMaker AI, la aplicación MLflow (opcional), el repositorio de AWS CodeCommit y los datos de S3. Los cuadernos incluyen celdas de limpieza con los comandos exactos. El principal generador de costos es el punto final en tiempo real de SageMaker AI. Asegúrese de eliminarlo inmediatamente después de la prueba.
Conclusión
En esta publicación, demostramos cómo crear un flujo de trabajo MLOps de extremo a extremo que combina DVC para control de versiones de datos, Amazon SageMaker AI para capacitación y orquestación escalables y aplicaciones SageMaker AI MLflow para seguimiento de experimentos y registro de modelos. Los resultados clave:
Reproducibilidad total: los modelos se pueden rastrear hasta sus datos de entrenamiento exactos a través de hashes de confirmación de DVC almacenados en MLflow. Linaje a nivel de registro: el patrón de manifiesto permite consultar qué registros individuales entrenaron un modelo determinado. Esto es fundamental para el cumplimiento de la exclusión voluntaria y las respuestas de auditoría. Alineación de cumplimiento sin estado: el patrón de registro de consentimiento maneja la exclusión de registros sin cambiar el código de procesamiento. Una exclusión voluntaria es un cambio de entrada que fluye a través del mismo canal. Comparación de experimentos: MLflow proporciona una comparación en paralelo de modelos entrenados con diferentes versiones de datos, con seguimiento completo de parámetros y métricas.
Los dos cuadernos del repositorio complementario de GitHub se pueden implementar tal cual. El patrón fundamental se adapta a los equipos que necesitan trazabilidad a nivel de conjunto de datos. El patrón de cumplimiento sanitario lo extiende a entornos regulados que requieren pistas de auditoría a nivel de registros. Ambos comparten el mismo código y arquitectura de entrenamiento de IA de SageMaker.
Si bien los cuadernos demuestran un flujo de trabajo interactivo, el mismo patrón se integra directamente en procesos automatizados. SageMaker AI Pipelines puede organizar los pasos de procesamiento y capacitación, con el etiquetado DVC y el registro de MLflow sucediendo de manera idéntica dentro de cada trabajo. La cadena de linaje sigue siendo la misma ya sea que se active desde una computadora portátil o desde un SageMaker AI Pipeline.
Sobre los autores
Manuwai Korber
Manuwai Korber es un arquitecto de soluciones especializado en IA/ML en AWS con experiencia en ingeniería de ML. Ayuda a los clientes a diseñar sistemas de IA/ML de nivel de producción durante todo el ciclo de vida del modelo, desde la experimentación, la capacitación y el ajuste hasta el servicio y la implementación de producción. Además, crear aplicaciones impulsadas por GenAI y sistemas de IA agentes.
Paolo Di Francesco
Paolo Di Francesco es arquitecto senior de soluciones en Amazon Web Services (AWS). Es Doctor en Ingeniería de Telecomunicaciones y tiene experiencia en ingeniería de software. Le apasiona el aprendizaje automático y actualmente se centra en utilizar su experiencia para ayudar a los clientes a alcanzar sus objetivos en AWS, en debates sobre MLOps. Fuera del trabajo, le gusta jugar al fútbol y leer.
Sandeep Raveesh
Sandeep Raveesh es arquitecto de soluciones especializado en GenAI en AWS. Trabaja con el cliente a lo largo de su recorrido AIOps a través de la capacitación de modelos, la generación aumentada de recuperación (RAG), los agentes GenAI y la ampliación de los casos de uso de GenAI. También se centra en estrategias de comercialización que ayudan a AWS a crear y alinear productos para resolver los desafíos de la industria en el espacio de la IA generativa. Puedes encontrar a Sandeep en LinkedIn.
Nick McCarthy
Nick McCarthy es arquitecto senior de soluciones especializado en IA generativa en el equipo de Amazon Bedrock, centrado en la personalización de modelos. Ha trabajado con clientes de AWS en una amplia gama de industrias, incluidas la atención médica, las finanzas, los deportes, las telecomunicaciones y la energía, ayudándolos a acelerar los resultados comerciales mediante el uso de la inteligencia artificial y el aprendizaje automático. Fuera del trabajo, a Nick le encanta viajar, explorar nuevas cocinas y leer sobre ciencia y tecnología. Tiene una Licenciatura en Física y una Maestría en Aprendizaje Automático.