Model Registry

Un registro de modelos es un catálogo versionado de modelos de aprendizaje automático entrenados. Cada entrada almacena un artefacto del modelo, como un archivo de pesos del modelo, junto con los metadatos necesarios para confiar en él: la ejecución de entrenamiento que lo produjo, la versión de los datos, métricas de evaluación como la precisión media (mAP), el esquema de entrada y salida, el propietario y el estado de aprobación. Las canalizaciones de despliegue y las aplicaciones consultan el registro para obtener una versión concreta o la versión que tenga actualmente la etiqueta de producción, en lugar de pasarse archivos de pesos, de modo que cada lanzamiento y cada reversión hacen referencia a un modelo concreto y registrado. En las operaciones de aprendizaje automático (MLOps), el registro se sitúa entre el seguimiento de experimentos y el despliegue de modelos. Entre los registros más utilizados se encuentran el registro de modelos de MLflow, el registro de modelos de Amazon SageMaker, el registro de modelos de Vertex AI y el registro de Weights & Biases.

Cómo funciona un registro de modelos#

Un modelo registrado es un nombre, como defect-detector, que contiene una secuencia de versiones. Una vez registrada, cada versión es inmutable, así que los pesos nuevos siempre se convierten en una versión nueva y la versión 7 siempre representa los mismos bytes. Por lo general, una versión registra:

• Linaje: El ID de ejecución, la confirmación de código, la versión del conjunto de datos y el modelo principal que la generaron.
• Resultados de evaluación: Métricas de validación, además de la latencia y la memoria medidas en cada dispositivo de destino.
• Firma: El esquema esperado de entrada y salida, para que una llamada que envíe una forma incorrecta falle de inmediato.
• Ficha del modelo: Documentación sobre el uso previsto, los datos de entrenamiento y las limitaciones conocidas.
• Estado: Etiquetas y alias que indican la situación de la versión.

Ultralytics Platform conserva este tipo de registro para cada ejecución de entrenamiento de YOLO que aloja: la página del modelo enumera el modelo principal, la versión fijada del conjunto de datos, la confirmación de Git, la versión de ultralytics, los hiperparámetros, las métricas finales y un comando reproducible yolo train; además, un campo de metadatos personalizados acepta un objeto JSON para el seguimiento de publicaciones o la gobernanza.

Los registros más antiguos hacían pasar cada versión por fases fijas, como Staging, Production y Archived. MLflow dejó de utilizar las fases en la versión 2.9.0 y las sustituyó por alias, es decir, punteros con nombre modificables, como @champion, que un equipo puede cambiar de una versión a otra. Amazon SageMaker registra para cada versión el estado de aprobación PendingManualApproval, Approved o Rejected. Promocionar un modelo significa cambiar su alias, y revertirlo significa devolver el alias a su estado anterior:

Los registros también controlan quién puede cambiar cada cosa. Los científicos de datos pueden registrar versiones, los revisores designados cambian el alias de producción y cada modificación queda registrada en un registro de auditoría. Los equipos suelen conectar estos eventos con procesos automatizados, de modo que la aprobación de una versión inicia la canalización de implementación y una alerta de supervisión del modelo sobre la deriva de datos inicia el reentrenamiento que registra la siguiente versión candidata.

El registro de MLflow muestra el patrón en unas pocas líneas. Este script entrena un pequeño clasificador de scikit-learn, lo registra, asigna el alias champion a la nueva versión y carga el modelo mediante el alias, tal como el código de serving de modelos encuentra el modelo de producción actual:

import mlflow
from mlflow import MlflowClient
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression

# Keep runs and registered model versions in a local SQLite file
mlflow.set_tracking_uri("sqlite:///mlflow.db")
X, y = load_iris(return_X_y=True)

# Log a trained model inside a run, then register it as a new version
with mlflow.start_run():
    model = LogisticRegression(max_iter=200).fit(X, y)
    info = mlflow.sklearn.log_model(model, name="model")
version = mlflow.register_model(info.model_uri, "iris-classifier")

# Point the "champion" alias at this version; applications load the alias
MlflowClient().set_registered_model_alias("iris-classifier", "champion", version.version)
champion = mlflow.pyfunc.load_model("models:/iris-classifier@champion")
print(f"version {version.version}:", champion.predict(X[:3]))

Con una base de datos nueva, el script muestra version 1: [0 0 0], la versión registrada y sus clases predichas para las tres primeras flores. Si vuelves a ejecutarlo, registra la versión 2, y el mismo URI models:/iris-classifier@champion sigue el alias hasta esa versión sin que tengas que modificar el código de carga.

Registro de modelos y herramientas relacionadas#

• Seguimiento de experimentos: Registra todas las ejecuciones de entrenamiento, incluidas las muchas que nunca se utilizan. El registro conserva los pocos candidatos que merece la pena implementar y vincula cada versión con su ejecución.
• Almacenamiento de objetos: Los buckets, como Amazon S3, contienen los archivos. Un registro añade versiones, metadatos y control de acceso, y a menudo solo guarda un puntero al archivo del bucket.
• Almacén de características: Versiona y sirve las características de entrada que consumen los modelos; los modelos se guardan en el registro.
• Registro de contenedores: Almacena las imágenes de Docker que ejecutan los modelos, por lo que una implementación suele especificar una etiqueta de imagen y una versión del modelo.
• Hugging Face Hub: Aloja modelos públicos y privados en repositorios de Git con historial de confirmaciones y una ficha del modelo en la página principal de cada repositorio, por lo que funciona como registro de modelos de pesos abiertos.