Versionado de un modelo entrenado: el artefacto junto con el código, los datos, los parámetros y el entorno que lo produjeron

Objetivo

Poder responder, para cualquier predicción servida en producción, qué modelo la generó, con qué código, datos y configuración se construyó, qué resultados obtuvo y cómo volver al modelo anterior. El versionado de datasets en sí se trata en el artículo sobre procedencia de datasets pequeños; este protocolo cubre el lado del modelo y sus vínculos.

Requisitos previos

Código bajo control de versiones, un dataset con un identificador estable (checksum, puntero de DVC o nombre de snapshot), una partición de prueba fija y un lugar donde almacenar artefactos con metadatos: un registro como el Model Registry de MLflow, que su documentación describe como un almacén centralizado con trazabilidad hasta la ejecución (run) que produjo el modelo, versionado y alias, o bien una estructura disciplinada de almacenamiento de objetos con un archivo de manifiesto.

Pasos

1. Entrenar únicamente desde un estado confirmado (committed); negarse a registrar un modelo construido a partir de un árbol de trabajo con cambios sin confirmar. Registrar el hash del commit.
2. Registrar el identificador del dataset, el identificador de la partición y el conjunto completo de hiperparámetros como parámetros de la ejecución.
3. Registrar las versiones exactas de las dependencias del entorno de entrenamiento. La guía de persistencia de scikit-learn señala que cargar un estimador con una versión distinta de scikit-learn genera un InconsistentVersionWarning, y que un modelo entrenado con versiones anteriores de la biblioteca y de sus dependencias puede requerir un nuevo entrenamiento en un entorno actualizado; por eso el entorno forma parte de la versión.
4. Evaluar sobre la partición de prueba fija y guardar las métricas junto con la ejecución; almacenar también el esquema de entrada y salida (una signature) para que el código de servicio pueda validar las solicitudes.
5. Serializar el modelo en un formato elegido según el contexto de servicio; la comparación de la guía indica que los formatos basados en pickle ejecutan código arbitrario al cargarse y presenta ONNX o skops como alternativas más seguras. Guardar el artefacto bajo un número de versión inmutable.
6. Promover mediante alias (champion, challenger), nunca sobrescribiendo el archivo que hay detrás de una versión existente; el servicio lee el alias y el rollback consiste en cambiar el alias.
7. Registrar la versión del modelo en cada predicción, de modo que el comportamiento en producción se pueda relacionar con el registro.

Resultado esperado

Cada predicción servida se resuelve en una versión, y cada versión en un commit, un dataset, unos parámetros, unas métricas y un entorno; el rollback requiere un solo cambio de alias.

Límites y base de verificación

El protocolo añade trabajo de registro a cada ejecución de entrenamiento y requiere almacenamiento para los artefactos. No hace que el entrenamiento sea determinista (véase la reproducibilidad de un experimento de ML). No se afirma nada sobre plazos ni resultados al seguirlo.