Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Databricks recomienda usar Modelos en Unity Catalog para mejorar la gobernanza, facilitar el uso compartido entre áreas de trabajo y entornos, y flujos de trabajo de MLOps más flexibles. Esta página le guiará por la migración de modelos en el Registro de modelos del área de trabajo al catálogo de Unity.
Introducción a los modelos en el catálogo de Unity
Los modelos en Unity Catalog extienden las ventajas de Unity Catalog a los modelos de aprendizaje automático, incluyendo control de acceso centralizado, auditoría, linaje, y el uso compartido y descubrimiento de modelos entre distintos espacios de trabajo. Los modelos del catálogo de Unity también proporcionan una mayor flexibilidad para administrar el ciclo de vida del modelo.
Al migrar modelos a Unity Catalog, algunos pasos del ciclo de vida del modelo se realizan de forma diferente:
- Los permisos del Registro de modelos de espacio de trabajo se reemplazan por permisos de Unity Catalog a nivel de cuenta. Vea Paso 2. Asigne permisos de Unity Catalog al modelo.
- Las fases se reemplazan por alias y etiquetas personalizados. En lugar de cuatro fases fijas, puede crear hasta 10 alias personalizados y reasignables. También puede establecer etiquetas para etiquetar modelos. Consulte el paso 4. Migrar metadatos del modelo.
- Los trabajos de implementación se usan para realizar la transición de modelos a lo largo de su ciclo de vida. Consulte el paso 6. (Opcional) Cree un trabajo de implementación.
Paso 1. Creación de un modelo en el catálogo de Unity
Consulte Entrenamiento y registro de modelos compatibles con el catálogo de Unity.
Paso 2. Asignación de permisos de Catálogo de Unity al modelo
Unity Catalog tiene un modelo de permisos unificado. Para obtener información sobre cómo asignar permisos a los modelos en el catálogo de Unity, consulte Control del acceso a los modelos.
En la tabla siguiente se muestra la relación entre los permisos del registro del modelo de área de trabajo y los privilegios en el catálogo de Unity. Además de los privilegios que se muestran en la tabla, todas las acciones también requieren USE CATALOG y USE SCHEMA privilegios.
| Registro del modelo de área de trabajo | Catálogo de Unity | Notas |
|---|---|---|
| Puede leer | EJECUTAR | |
| Puede editar | CREAR VERSIÓN DEL MODELO + APLICAR ETIQUETA | Los usuarios con estos privilegios no pueden editar la descripción de los modelos o versiones del modelo. |
| Puede administrar versiones de almacenamiento provisional | APPLY TAG + tarea de implementación | En el catálogo de Unity, los trabajos de implementación se usan para controlar el movimiento de las versiones del modelo a través de las fases del ciclo de vida. Para más información, consulte Trabajos de implementación de MLflow 3. |
| Puede administrar versiones de producción | APPLY TAG + tarea de implementación | En el catálogo de Unity, los trabajos de implementación se usan para controlar el movimiento de las versiones del modelo a través de las fases del ciclo de vida. Para más información, consulte Trabajos de implementación de MLflow 3. |
| Puede administrar | GESTIONAR |
Paso 3. Copiar versiones de modelos
Para copiar versiones del modelo, use copy_model_version() con el cliente > de MLflow = 3.4.0.
import mlflow
from mlflow import MLflowClient
# Registry must be set to workspace registry
mlflow.set_registry_uri("databricks")
client = MlflowClient(registry_uri="databricks")
src_model_uri = f"models:/my_wmr_model/1"
uc_migrated_copy = client.copy_model_version(
src_model_uri, "mycatalog.myschema.my_uc_model"
)
Si el modelo de destino no existe en el catálogo de Unity, se crea mediante esta llamada API.
Los modelos del catálogo de Unity requieren una firma. Si la versión del modelo de área de trabajo no tiene una firma, Databricks recomienda crear una siguiendo las instrucciones de la documentación de MLflow. Otra alternativa es usar la variable MLFLOW_SKIP_SIGNATURE_CHECK_FOR_UC_REGISTRY_MIGRATIONde entorno . Esta variable de entorno solo está disponible cuando se usa copy_model_version() y se requiere la versión 3.4.0 de MLflow o superior. Cuando esta variable de entorno se establece en "true", no se requiere una firma.
Para ver un script que puede usar para migrar todas las versiones de modelo de un modelo en el registro de modelos del área de trabajo a un modelo de catálogo de Unity de destino, consulte Migración de versiones del modelo del registro de modelos del área de trabajo al catálogo de Unity.
Paso 4. Migración de metadatos del modelo
En esta sección se describe cómo asignar los metadatos a nivel de registro del área de trabajo a los metadatos de modelo y versión de modelo del catálogo de Unity, como etapas, etiquetas y descripciones.
Etapas
El Registro de modelos de área de trabajo usó el concepto de "fases", como Staging y Production, para realizar un seguimiento del ciclo de vida del modelo. Puede buscar o invocar modelos por fase. En el catálogo de Unity, las fases se han reemplazado por alias para llamar a un modelo y por etiquetas para etiquetar modelos.
Para una migración sencilla de las fases del Registro de modelos de área de trabajo, puede usar directamente "Producción" y "Ensayo" o cualquier otro nombre de alias que prefiera. En el registro de modelos del espacio de trabajo, varias versiones de un modelo podrían estar en la misma fase, y se utilizó la versión más reciente cuando se hacía referencia a una versión del modelo. En el catálogo de Unity, se asigna un alias a una versión de modelo única.
Para una migración sencilla de etiquetas de fase, use etiquetas para etiquetar las versiones del modelo como "Producción", "Ensayo" o "Archivado". Usted también puede utilizar cualquier otra etiqueta. Para obtener más información sobre las etiquetas, consulta Etiquetas.
En el Gestionario de Modelos del Área de Trabajo, el ciclo de vida de una versión de modelo se seguía por etapas, y se requería la aprobación humana para una solicitud de transición. En el catálogo de Unity, un trabajo de implementación administra el ciclo de vida de una versión de modelo. Cada tarea del trabajo de implementación corresponde a una "fase". Los trabajos de implementación permiten personalizar el ciclo de vida del modelo y dar cabida a flujos de trabajo más complicados que el Registro de modelos del área de trabajo. Los trabajos de implementación todavía admiten aprobaciones humanas. Para más información, consulte Trabajos de implementación de MLflow 3.
Etiquetas
En el catálogo de Unity, creas etiquetas en el modelo o la versión del modelo.
Para buscar un modelo por etiqueta en el Explorador de catálogos, escriba la clave o el valor en el cuadro de búsqueda:
En el Explorador de catálogos, solo puede usar etiquetas para buscar modelos, no para las versiones del modelo. El cliente de MLflow no admite la búsqueda de modelos mediante etiquetas de catálogo de Unity. El catálogo de Unity permite como máximo 50 etiquetas por objeto.
Descripción y comentarios
Puede agregar descripciones al modelo y a la versión del modelo. El catálogo de Unity también proporciona la opción de una descripción generada por IA para el modelo.
Los modelos del catálogo de Unity no tienen una ubicación correspondiente para la información que se muestra en la sección Actividades de la página versión del modelo en el registro de modelos del área de trabajo. Si hay información en esa sección que desea transferir con la versión del modelo, cópiela en la sección Descripción de la página versión del modelo en el catálogo de Unity.
Paso 5. Actualización de todas las cargas de trabajo y puntos de conexión
Después de migrar modelos y versiones de modelos a Unity Catalog, actualice todos los trabajos, cuadernos y otras cargas de trabajo, incluyendo los endpoints de servicio de modelos, para usar las versiones en Unity Catalog.
Paso 6. (Opcional) Creación de un trabajo de implementación
Un trabajo de implementación se desencadena automáticamente cada vez que se crea una nueva versión del modelo y automatiza el flujo de trabajo de evaluación, aprobación e implementación. Para más información, consulte Trabajos de implementación de MLflow 3.
Puede establecer notificaciones para que se desencadenen en eventos como la creación o aprobación de una versión del modelo. Consulte Incorporación de notificaciones en un trabajo.
Si tenía notificaciones por correo electrónico configuradas para eventos en el Registro de modelos de área de trabajo, migrelas de la siguiente manera:
- Se creó una nueva versión del modelo: configure un trabajo de implementación que se desencadene cuando se crea una nueva versión del modelo y una notificación por correo electrónico cuando se desencadene el trabajo.
- Solicitud de transición de fase: las solicitudes de transición de fase corresponden a tareas de aprobación. Establezca una notificación por correo electrónico para el éxito o error de la tarea de aprobación.
- Transiciones de fase: las transiciones de fase corresponden a las tareas de trabajo. Establezca una notificación por correo electrónico para el éxito o error de la tarea.
- Nuevos comentarios: los comentarios no se admiten en el catálogo de Unity.
Si tenía webhooks configurados para eventos, puede implementarlos en Unity Catalog como desencadenantes de trabajos de eventos de modelo. Los desencadenadores de modelo permiten automatizar trabajos de Lakeflow en función de la creación de nuevos modelos, versiones de modelos o alias de modelo en el catálogo de Unity. Los desencadenadores de modelo se encuentran en versión preliminar privada. Póngase en contacto con su representante de Databricks para obtener más información.
Información adicional
Las páginas vinculadas a continuación describen cómo migrar flujos de trabajo (trabajos de entrenamiento de modelos y inferencia por lotes) del Registro de modelos de área de trabajo al catálogo de Unity.