Compartir vía


Operaciones de aprendizaje automático

En este artículo se describen tres arquitecturas de Azure para las operaciones de aprendizaje automático que tienen canalizaciones de integración continua y entrega continua (CI/CD) y reentrenamiento de canalizaciones. Las arquitecturas son para estas aplicaciones de inteligencia artificial:

  • Aprendizaje automático clásico
  • Computer Vision (CV)
  • Procesamiento del lenguaje natural

Estas arquitecturas son el producto del proyecto MLOps v2. Incorporan procedimientos recomendados que los arquitectos de soluciones han identificado durante el desarrollo de varias soluciones de aprendizaje automático. El resultado se puede implementar, es repetible y fácil de mantener. Las tres arquitecturas usan Azure Machine Learning Service.

Para obtener una implementación con plantillas de implementación de ejemplo para MLOps v2, consulte Acelerador de soluciones de Azure MLOps v2.

Posibles casos de uso

  • Aprendizaje automático clásico: la previsión de series temporales, la regresión y la clasificación en datos estructurados tabulares son los casos de uso más comunes de esta categoría. Algunos ejemplos son:

    • Clasificación binaria y de varias etiquetas.

    • Regresión lineal, polinómica, contraída, de lazo, cuantil y bayesiana.

    • ARIMA, autorregresiva, SARIMA, VAR, SES, LSTM.

  • CV: el marco MLOps de este artículo se centra principalmente en los casos de uso de CV de segmentación y clasificación de imágenes.

  • Procesamiento de lenguaje natural: puede usar este marco de MLOps para implementar:

    • Reconocimiento de entidades con nombre:

    • Clasificación de textos

    • Generación de texto

    • análisis de opiniones

    • Traducción

    • Respuesta a preguntas

    • Resumen

    • Detección de frases

    • Detección de idiomas

    • Etiquetado de categorías gramaticales

En este artículo no se describen las simulaciones de IA, el aprendizaje de refuerzo profundo y otras formas de inteligencia artificial.

Arquitectura

El patrón de arquitectura de MLOps v2 tiene cuatro componentes modulares principales, o fases, del ciclo de vida de MLOps:

  • Patrimonio de datos
  • Administración y configuración
  • Desarrollo de modelos o fase de bucle interno
  • Implementación del modelo o la fase del bucle externo

Los componentes anteriores, las conexiones entre ellos y los roles típicos implicados son estándar en todas las arquitecturas de escenario de MLOps v2. Las variaciones en los detalles de cada componente dependen del escenario.

La arquitectura base de MLOps v2 para Machine Learning es el escenario de aprendizaje automático clásico para datos tabulares. Las arquitecturas CV y NLP se basan en esta arquitectura base y la modifican.

MLOps v2 trata las siguientes arquitecturas que se describen en este artículo:

Arquitectura de aprendizaje automático clásico

Diagrama que muestra la arquitectura de aprendizaje automático clásico.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo para la arquitectura de aprendizaje automático clásico

  1. Patrimonio de datos

    Este componente muestra el patrimonio de datos de la organización y los posibles orígenes de datos y destinos para un proyecto de ciencia de datos. Los ingenieros de datos son los propietarios principales de este componente del ciclo de vida de MLOps v2. Las plataformas de datos de Azure de este diagrama no son exhaustivas ni prescriptivas. Una marca de verificación verde indica los orígenes de datos y los destinos que representan procedimientos recomendados basados en el caso de uso del cliente.

  2. Administración y configuración

    Este componente es el primer paso de la implementación del acelerador de MLOps v2. Consta de todas las tareas relacionadas con la creación y administración de recursos y roles asociados al proyecto. Por ejemplo, el equipo de infraestructura podría:

    1. Crear repositorios de código fuente del proyecto.
    2. Usar Bicep o Terraform para crear áreas de trabajo de Machine Learning.
    3. Crear o modificar conjuntos de datos y recursos de proceso para el desarrollo y la implementación de modelos.
    4. Definir usuarios del equipo del proyecto, sus roles y controles de acceso a otros recursos.
    5. Crear canalizaciones de CI/CD.
    6. Crear componentes de supervisión para recopilar y crear alertas para las métricas de modelo e infraestructura.

    El rol principal asociado a esta fase es el equipo de infraestructura, pero una organización también podría tener ingenieros de datos, ingenieros de aprendizaje automático o científicos de datos.

  3. Desarrollo de modelos (fase de bucle interno)

    La fase de bucle interno consta de un flujo de trabajo de ciencia de datos iterativo que actúa dentro de un área de trabajo de Machine Learning dedicada y segura. En el diagrama anterior se muestra un flujo de trabajo típico. El proceso comienza con la ingesta de datos, se mueve a través del análisis exploratorio de datos, experimentación, desarrollo y evaluación del modelo y, a continuación, registra un modelo para su uso en producción. Este componente modular, tal y como se implementa en el acelerador de MLOps v2, es independiente y adaptable al proceso que usa el equipo de ciencia de datos para desarrollar modelos.

    Entre los roles asociados a esta fase se incluyen científicos de datos e ingenieros de aprendizaje automático.

  4. Registros de Machine Learning

    Después de que el equipo de ciencia de datos desarrolle un modelo que se pueda implementar en producción, el modelo se registra en el registro del área de trabajo de Machine Learning. Las canalizaciones de CI que se desencadenan, ya sea automáticamente mediante el registro del modelo o por la intervención humana en el bucle controlada, promueven el modelo y cualquier otra dependencia del modelo a su fase de implementación.

    Los roles asociados a esta fase suelen ser ingenieros de aprendizaje automático.

  5. Implementación de modelos (fase de bucle externo)

    La fase de implementación del modelo, o bucle externo, consta de almacenamiento provisional y pruebas de preproducción, implementación en producción y supervisión del modelo, los datos y la infraestructura. Cuando el modelo cumple los criterios de la organización y el caso de uso, las canalizaciones de CD promueven el modelo y los recursos relacionados mediante la producción, la supervisión y el posible reentrenamiento.

    Los roles asociados a esta fase son principalmente ingenieros de aprendizaje automático.

  6. Almacenamiento provisional y prueba

    La fase de almacenamiento provisional y prueba varía según las prácticas del cliente. Esta fase normalmente incluye operaciones como el reentrenamiento y las pruebas del modelo candidato sobre datos de producción, las implementaciones de prueba para el rendimiento del punto de conexión, las comprobaciones de calidad de datos, las pruebas unitarias y las comprobaciones de inteligencia artificial responsable para el modelo y el sesgo de datos. Esta fase tiene lugar en una o varias áreas de trabajo de Machine Learning dedicadas y seguras.

  7. Implementación en producción

    Después de que un modelo supere la fase de almacenamiento provisional y prueba, los ingenieros de aprendizaje automático pueden usar la aprobación controlada por intervención humana en el bucle para promoverla a producción. Las opciones de implementación del modelo incluyen un punto de conexión por lotes administrado para escenarios de lote o un punto de conexión en línea administrado o una implementación de Kubernetes que usa Azure Arc para escenarios en línea casi en tiempo real. La fase de producción suele tener lugar en una o varias áreas de trabajo de Machine Learning dedicadas y seguras.

  8. Supervisión

    Los ingenieros de aprendizaje automático supervisan los componentes en las fases de almacenamiento provisional, pruebas y producción para recopilar métricas relacionadas con los cambios en el rendimiento del modelo, los datos y la infraestructura. Pueden usar esas métricas para tomar medidas. La supervisión de modelos y datos puede incluir la comprobación del modelo y el desfase de datos, el rendimiento del modelo con los datos nuevos y los problemas de la inteligencia artificial responsable. La supervisión de la infraestructura puede identificar la respuesta lenta del punto de conexión, la capacidad de proceso inadecuada o los problemas de red.

  9. Supervisión de datos y modelos: eventos y acciones

    En función de los criterios del modelo y datos, como los umbrales de métricas o las programaciones, los desencadenadores automatizados y las notificaciones pueden implementar las acciones adecuadas que se deben realizar. Por ejemplo, un desencadenador podría volver a entrenar un modelo para usar nuevos datos de producción y, a continuación, volver a realizar bucles en las fases de almacenamiento provisional y prueba de una evaluación de preproducción. O bien, un problema con el modelo o los datos podría desencadenar una acción que necesita un bucle invertido en la fase de desarrollo del modelo en la que los científicos de datos pueden investigar el problema y desarrollar potencialmente un modelo nuevo.

  10. Supervisión de la infraestructura: eventos y acciones

    En función de los criterios de la infraestructura, como el retraso de respuesta del punto de conexión o un proceso insuficiente para la implementación, los desencadenadores automatizados y las notificaciones pueden implementar las acciones adecuadas que se deben realizar. Los desencadenadores automáticos y las notificaciones podrían desencadenar un bucle invertido en la fase de instalación y administración en el que el equipo de infraestructura puede investigar el problema y volver a configurar los recursos de proceso y red.

Arquitectura de CV de aprendizaje automático

Diagrama que muestra la arquitectura de visión de proceso.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo para la arquitectura de CV

La arquitectura de CV de Machine Learning se basa en la arquitectura de aprendizaje automático clásica, pero tiene modificaciones que son específicas de los escenarios de CV supervisados.

  1. Patrimonio de datos

    Este componente muestra el patrimonio de datos de la organización y los posibles orígenes de datos y destinos para un proyecto de ciencia de datos. Los ingenieros de datos son los propietarios principales de este componente del ciclo de vida de MLOps v2. Las plataformas de datos de Azure de este diagrama no son exhaustivas ni prescriptivas. Las imágenes para escenarios de CV pueden provenir de diversos orígenes de datos. Para mejorar la eficacia al desarrollar e implementar modelos de CV con Machine Learning, se recomienda Azure Blob Storage y Azure Data Lake Storage.

  2. Administración y configuración

    Este componente es el primer paso de la implementación del acelerador de MLOps v2. Consta de todas las tareas relacionadas con la creación y administración de recursos y roles asociados al proyecto. En escenarios de CV, la administración y la configuración del entorno de MLOps v2 es en gran medida la misma que para el aprendizaje automático clásico, pero incluye un paso adicional. El equipo de infraestructura usa la característica de etiquetado de Machine Learning u otra herramienta para crear proyectos de anotación y etiquetado de imágenes.

  3. Desarrollo de modelos (fase de bucle interno)

    La fase de bucle interno consta de un flujo de trabajo de ciencia de datos iterativo realizado dentro de un área de trabajo de Machine Learning dedicada y segura. La principal diferencia entre este flujo de trabajo y el escenario de aprendizaje automático clásico es que el etiquetado y la anotación de imágenes son un componente clave de este bucle de desarrollo.

  4. Registros de Machine Learning

    Después de que el equipo de ciencia de datos desarrolle un modelo que se pueda implementar en producción, el modelo se registra en el registro del área de trabajo de Machine Learning. Las canalizaciones de CI que se desencadenan automáticamente mediante el registro del modelo o por la intervención humana en el bucle controlada promueven el modelo y cualquier otra dependencia del modelo a su fase de implementación.

  5. Implementación de modelos (fase de bucle externo)

    La fase de implementación del modelo, o bucle externo, consta de almacenamiento provisional y pruebas de preproducción, implementación en producción y supervisión del modelo, los datos y la infraestructura. Cuando el modelo cumple los criterios de la organización y el caso de uso, las canalizaciones de CD promueven el modelo y los recursos relacionados mediante la producción, la supervisión y el posible reentrenamiento.

  6. Almacenamiento provisional y prueba

    La fase de almacenamiento provisional y prueba varía según las prácticas del cliente. Esta fase normalmente incluye operaciones como las implementaciones de prueba para el rendimiento del punto de conexión, las comprobaciones de calidad de datos, las pruebas unitarias y las comprobaciones de inteligencia artificial responsable para el modelo y el sesgo de datos. En el caso de los escenarios de CV, los ingenieros de aprendizaje automático no necesitan volver a entrenar el modelo candidato con datos de producción debido a limitaciones de tiempo y recursos. En su lugar, el equipo de ciencia de datos puede usar datos de producción para el desarrollo de modelos. El modelo candidato registrado desde el bucle de desarrollo se evalúa para producción. Esta fase tiene lugar en una o varias áreas de trabajo de Machine Learning dedicadas y seguras.

  7. Implementación en producción

    Después de que un modelo supere la fase de almacenamiento provisional y prueba, los ingenieros de aprendizaje automático pueden usar la aprobación controlada por intervención humana en el bucle para promoverla a producción. Las opciones de implementación del modelo incluyen un punto de conexión por lotes administrado para escenarios de lote o un punto de conexión en línea administrado o una implementación de Kubernetes que usa Azure Arc para escenarios en línea casi en tiempo real. La fase de producción suele tener lugar en una o varias áreas de trabajo de Machine Learning dedicadas y seguras.

  8. Supervisión

    Los ingenieros de aprendizaje automático supervisan los componentes en las fases de almacenamiento provisional, pruebas y producción para recopilar métricas relacionadas con los cambios en el rendimiento del modelo, los datos y la infraestructura. Pueden usar esas métricas para tomar medidas. La supervisión de modelos y datos puede incluir la comprobación del rendimiento del modelo con nuevas imágenes. La supervisión de la infraestructura puede identificar la respuesta lenta del punto de conexión, la capacidad de proceso inadecuada o los problemas de red.

  9. Supervisión de datos y modelos: eventos y acciones

    Las fases de supervisión de datos y modelos, y eventos y acciones de MLOps para el procesamiento del lenguaje natural son las diferencias clave con respecto al aprendizaje automático clásico. Normalmente, el reentrenamiento automatizado no se realiza en escenarios de CV cuando se detecta una degradación del rendimiento del modelo con las nuevas imágenes. En este caso, es necesario un proceso de intervención humana en el bucle para revisar y anotar nuevos datos de texto para el modelo que no funciona correctamente. La siguiente acción suele ser volver al bucle de desarrollo del modelo para actualizar el modelo con nuevas imágenes.

  10. Supervisión de la infraestructura: eventos y acciones

    En función de los criterios de la infraestructura, como el retraso de respuesta del punto de conexión o un proceso insuficiente para la implementación, los desencadenadores automatizados y las notificaciones pueden implementar las acciones adecuadas que se deben realizar. Los desencadenadores automáticos y las notificaciones podrían desencadenar un bucle invertido en la fase de instalación y administración en el que el equipo de infraestructura puede investigar el problema y volver a configurar el entorno y los recursos de proceso y red.

Arquitectura de procesamiento de lenguaje natural de aprendizaje automático

Diagrama de la arquitectura de procesamiento del lenguaje natural.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo de la arquitectura de procesamiento del lenguaje natural

La arquitectura de procesamiento del lenguaje natural de Machine Learning se basa en la arquitectura de aprendizaje automático clásica, pero tiene algunas modificaciones que son específicas de los escenarios de NLP.

  1. Patrimonio de datos

    Este componente muestra el patrimonio de datos de la organización y los posibles orígenes de datos y destinos para un proyecto de ciencia de datos. Los ingenieros de datos son los propietarios principales de este componente del ciclo de vida de MLOps v2. Las plataformas de datos de Azure de este diagrama no son exhaustivas ni prescriptivas. Una marca de verificación verde indica los orígenes y destinos que representan procedimientos recomendados basados en el caso de uso del cliente.

  2. Administración y configuración

    Este componente es el primer paso de la implementación del acelerador de MLOps v2. Consta de todas las tareas relacionadas con la creación y administración de recursos y roles asociados al proyecto. En escenarios de procesamiento del lenguaje natural, la administración y la configuración del entorno de MLOps v2 es en gran medida igual que para el aprendizaje automático clásico, pero con un paso adicional: la creación de proyectos de etiquetado y anotación de imágenes mediante la característica de etiquetado de Machine Learning u otra herramienta.

  3. Desarrollo de modelos (fase de bucle interno)

    La fase de bucle interno consta de un flujo de trabajo de ciencia de datos iterativo realizado dentro de un área de trabajo de Machine Learning dedicada y segura. El bucle de desarrollo de modelos NLP típico difiere del escenario de aprendizaje automático clásico en el sentido en que los pasos de desarrollo típicos para este escenario incluyen anotadores para oraciones y tokenización, normalización e inserciones de datos de texto.

  4. Registros de Machine Learning

    Después de que el equipo de ciencia de datos desarrolle un modelo que se pueda implementar en producción, el modelo se registra en el registro del área de trabajo de Machine Learning. Las canalizaciones de CI que se desencadenan automáticamente mediante el registro del modelo o por la intervención humana en el bucle controlada promueven el modelo y cualquier otra dependencia del modelo a su fase de implementación.

  5. Implementación de modelos (fase de bucle externo)

    La fase de implementación del modelo, o bucle externo, consta de almacenamiento provisional y pruebas de preproducción, implementación en producción y supervisión del modelo, los datos y la infraestructura. Cuando el modelo cumple los criterios de la organización y el caso de uso, las canalizaciones de CD promueven el modelo y los recursos relacionados mediante la producción, la supervisión y el posible reentrenamiento.

  6. Almacenamiento provisional y prueba

    La fase de almacenamiento provisional y prueba varía según las prácticas del cliente. Esta fase normalmente incluye operaciones como el reentrenamiento y las pruebas del modelo candidato sobre datos de producción, las implementaciones de prueba para el rendimiento del punto de conexión, las comprobaciones de calidad de datos, las pruebas unitarias y las comprobaciones de inteligencia artificial responsable para el modelo y el sesgo de datos. Esta fase tiene lugar en una o varias áreas de trabajo de Machine Learning dedicadas y seguras.

  7. Implementación en producción

    Después de que un modelo supere la fase de almacenamiento provisional y prueba, los ingenieros de aprendizaje automático pueden usar la aprobación controlada por intervención humana en el bucle para promoverla a producción. Las opciones de implementación del modelo incluyen un punto de conexión por lotes administrado para escenarios de lote o un punto de conexión en línea administrado o una implementación de Kubernetes que usa Azure Arc para escenarios en línea casi en tiempo real. La fase de producción suele tener lugar en una o varias áreas de trabajo de Machine Learning dedicadas y seguras.

  8. Supervisión

    Los ingenieros de aprendizaje automático supervisan los componentes en las fases de almacenamiento provisional, pruebas y producción para recopilar métricas relacionadas con los cambios en el rendimiento del modelo, los datos y la infraestructura. Pueden usar esas métricas para tomar medidas. La supervisión de modelos y datos puede incluir la comprobación del modelo y el desfase de datos, el rendimiento del modelo con datos de texto nuevos y los problemas de la inteligencia artificial responsable. La supervisión de la infraestructura puede identificar problemas como la respuesta lenta del punto de conexión, la capacidad de proceso inadecuada y problemas de red.

  9. Supervisión de datos y modelos: eventos y acciones

    Como sucede con la arquitectura de CV, las fases de supervisión de datos y modelos, y eventos y acciones de MLOps para el procesamiento del lenguaje natural son las diferencias clave con respecto al aprendizaje automático clásico. Normalmente, el reentrenamiento automatizado no se realiza en escenarios de procesamiento del lenguaje natural cuando se detecta una degradación del rendimiento del modelo con el texto nuevo. En este caso, es necesario un proceso de intervención humana en el bucle para revisar y anotar nuevos datos de texto para el modelo que no funciona correctamente. A menudo, la siguiente acción es volver al bucle de desarrollo del modelo para actualizar el modelo con los nuevos datos de texto.

  10. Supervisión de la infraestructura: eventos y acciones

    En función de los criterios de la infraestructura, como el retraso de respuesta del punto de conexión o un proceso insuficiente para la implementación, los desencadenadores automatizados y las notificaciones pueden implementar las acciones adecuadas que se deben realizar. Los desencadenadores automáticos y las notificaciones podrían desencadenar un bucle invertido en la fase de instalación y administración en el que el equipo de infraestructura puede investigar el problema y volver a configurar los recursos de proceso y red.

Componentes

  • Machine Learning es un servicio en la nube que puede utilizar para entrenar, puntuar, implementar y administrar modelos de aprendizaje automático a escala.

  • Azure Pipelines es un sistema de compilación y prueba basado en Azure DevOps y que se usa para las canalizaciones de compilación y versión. Azure Pipelines divide estas canalizaciones en pasos lógicos denominados tareas.

  • GitHub es una plataforma de hospedaje de código para el control de versiones, la colaboración y los flujos de trabajo de CI/CD.

  • Azure Arc es una plataforma que usa Azure Resource Manager para administrar recursos de Azure y recursos locales. Los recursos pueden incluir máquinas virtuales, clústeres de Kubernetes y bases de datos.

  • Kubernetes es un sistema de código abierto que puede usar para automatizar la implementación, el escalado y la administración de aplicaciones contenedorizadas.

  • Azure Data Lake Storage es un sistema de archivos compatible con Hadoop. Tiene un espacio de nombres jerárquico integrado y la escala y economía masivas de Blob Storage.

  • Azure Synapse Analytics es un servicio de análisis ilimitado que combina la integración de datos, el almacenamiento de datos empresariales y el análisis de macrodatos.

  • Azure Event Hubs es un servicio que ingiere los flujos de datos que generan las aplicaciones cliente. Después, ingiere y almacena los datos de streaming, que conservan la secuencia de los eventos recibidos. Los clientes pueden conectarse a los puntos de conexión del centro para recuperar mensajes para su procesamiento. Esta arquitectura usa la integración de Data Lake Storage.

Otras consideraciones

El patrón de arquitectura de MLOps v2 anterior tiene varios componentes críticos, incluido el control de acceso basado en roles (RBAC) que se alinea con las partes interesadas del negocio, la administración eficaz de paquetes y mecanismos de supervisión sólidos. Estos componentes contribuyen colectivamente a la correcta implementación y administración de flujos de trabajo de aprendizaje automático.

RBAC basado en personas

Es fundamental administrar el acceso a los datos y recursos de aprendizaje automático. RBAC proporciona un marco sólido para ayudarle a administrar quién puede realizar acciones específicas y acceder a áreas específicas dentro de la solución. Diseñe la estrategia de segmentación de identidades para alinearse con el ciclo de vida de los modelos de aprendizaje automático en Machine Learning y las personas incluidas en el proceso. Cada persona tiene un conjunto específico de responsabilidades que se reflejan en sus roles de RBAC y pertenencia a grupos.

Personas de ejemplo

Para admitir la segmentación adecuada en una carga de trabajo de aprendizaje automático, tenga en cuenta las siguientes personas comunes que informan al diseño del grupo RBAC basado en identidades.

Científico de datos e ingeniero de aprendizaje automático

Los científicos de datos e ingenieros de aprendizaje automático realizan diversas actividades de aprendizaje automático y ciencia de datos en el ciclo de vida de desarrollo de software de un proyecto. Sus tareas incluyen el análisis exploratorio de datos y el preprocesamiento de datos. Los científicos de datos e ingenieros de aprendizaje automático son responsables de entrenar, evaluar e implementar modelos. Las responsabilidades de estos roles también incluyen actividades de corrección de interrupción para modelos, paquetes y datos de Machine Learning. Estas tareas están fuera del ámbito del equipo de soporte técnico de la plataforma.

Tipo: Persona
Específico del proyecto:

Analista de datos

Los analistas de datos proporcionan la entrada necesaria para las actividades de ciencia de datos, como ejecutar consultas SQL para inteligencia empresarial. Las responsabilidades de este rol incluyen trabajar con datos, realizar análisis de datos y admitir el desarrollo de modelos y la implementación de modelos.

Tipo: Persona
Específico del proyecto:

Evaluador de modelos

Los evaluadores de modelos realizan pruebas en entornos de ensayo y pruebas. Este rol proporciona segregación funcional de los procesos de CI/CD.

Tipo: Persona
Específico del proyecto:

Partes interesadas del negocio

Las partes interesadas del negocio están asociadas al proyecto, como un administrador de marketing.

Tipo: Persona
Específico del proyecto:

Jefe de proyecto o responsable de ciencia de datos

El responsable de ciencia de datos es un rol de administración de proyectos para el área de trabajo de Machine Learning. Este rol también realiza actividades de corrección de interrupción para los paquetes y modelos de Machine Learning.

Tipo: Persona
Específico del proyecto:

Jefe de proyecto o producto (propietario de la empresa)

Las partes interesadas del negocio son responsables del área de trabajo de Machine Learning según la propiedad de los datos.

Tipo: Persona
Específico del proyecto:

Soporte técnico de la plataforma

El soporte técnico de la plataforma es el personal de soporte técnico responsable de las actividades de corrección de interrupción en toda la plataforma. Este rol abarca la infraestructura o el servicio, pero no los modelos, paquetes o datos de Machine Learning. Estos componentes permanecen bajo el rol científico de datos o ingeniero de aprendizaje automático y son responsabilidad del jefe de proyecto.

Tipo: Persona
Específico del proyecto: No

Usuario final del modelo

Los usuarios finales del modelo son los consumidores finales del modelo de aprendizaje automático.

Tipo: Persona o proceso
Específico del proyecto:

Procesos de CI/CD

Los procesos de CI/CD liberan o revierten los cambios en entornos de plataforma.

Tipo: Proceso
Específico del proyecto: No

Área de trabajo de Machine Learning

Las áreas de trabajo de Machine Learning usan identidades administradas para interactuar con otras partes de Azure. Esta persona representa los distintos servicios que componen una implementación de Machine Learning. Estos servicios interactúan con otras partes de la plataforma, como el área de trabajo de desarrollo que se conecta con el almacén de datos de desarrollo.

Tipo: Proceso
Específico del proyecto: No

Supervisión de procesos

Los procesos de supervisión son procesos de cálculo que supervisan y alertan en función de las actividades de la plataforma.

Tipo: Proceso
Específico del proyecto: No

Procesos de gobernanza de datos

Los procesos de gobernanza de datos examinan el proyecto de aprendizaje automático y los almacenes de datos para la gobernanza de datos.

Tipo: Proceso
Específico del proyecto: No

Pertenencia al grupo de Microsoft Entra

Al implementar RBAC, los grupos de Microsoft Entra proporcionan una manera flexible y escalable de administrar los permisos de acceso en distintas personas. Puede usar grupos de Microsoft Entra para administrar usuarios que necesitan el mismo acceso y permisos a los recursos, como aplicaciones y servicios potencialmente restringidos. En lugar de agregar permisos especiales a usuarios individuales, puedes crear un grupo que aplique los permisos especiales a cada miembro de ese grupo.

En este patrón de arquitectura, puede acoplar estos grupos con una configuración del área de trabajo de Machine Learning, como un proyecto, un equipo o un departamento. Puede asociar usuarios a grupos específicos para definir directivas de acceso específicas. Las directivas conceden o restringen permisos a varias áreas de trabajo de Machine Learning en función de las funciones de trabajo, los requisitos del proyecto u otros criterios. Por ejemplo, puede tener un grupo que conceda a todos los científicos de datos acceso a un área de trabajo de desarrollo para un caso de uso específico.

RBAC de identidad

Tenga en cuenta cómo puede usar los siguientes roles RBAC de Azure integrados para aplicar RBAC a entornos de producción y preproducción. Para la arquitectura de este artículo, los entornos de producción incluyen entornos de ensayo, pruebas y producción. Los entornos de preproducción incluyen entornos de desarrollo. Los siguientes roles de RBAC se basan en las personas descritas anteriormente en este artículo.

Roles estándar

Roles específicos de los componentes

Estas abreviaturas de roles de RBAC de Azure corresponden a las tablas siguientes.

Entorno de producción
Rol Área de trabajo de Machine Learning Azure Key Vault Container Registry Cuenta de Azure Storage Azure DevOps Azure Artifacts Área de trabajo de Log Analytics Azure Monitor
Científico de datos R LAR MR
Analista de datos
Evaluador de modelos
Partes interesadas del negocio MR
Jefe de proyecto (responsable de ciencia de datos) R R, KVR R LAR MR
Jefe de proyecto/producto MR
Soporte técnico de la plataforma O O, KVA DOPCA O O O
Usuario final del modelo
Procesos de CI/CD O O, KVA AcrPush DOPCA O O O
Área de trabajo de Machine Learning R C C
Supervisión de procesos R LAR MR
Procesos de gobernanza de datos R R R R R
Entorno de preproducción
Rol Área de trabajo de Machine Learning Key Vault Container Registry Cuenta de almacenamiento Azure DevOps Azure Artifacts Área de trabajo de Log Analytics Azure Monitor
Científico de datos ADS R, KVA C C C C LAC MC
Analista de datos R C LAR MC
Evaluador de modelos R R, KVR R R R R LAR MR
Partes interesadas del negocio R R R R R
Jefe de proyecto (responsable de ciencia de datos) C C, KVA C C C C LAC MC
Jefe de proyecto/producto R R MR
Soporte técnico de la plataforma O O, KVA O O DOPCA O O O
Usuario final del modelo
Procesos de CI/CD O O, KVA AcrPush O DOPCA O O O
Área de trabajo de Machine Learning R, KVR C C
Supervisión de procesos R R R R R R LAC
Procesos de gobernanza de datos R R R

Nota:

Cada persona conserva el acceso durante la duración del proyecto, excepto el soporte técnico de la plataforma, que tiene acceso temporal o Just-In-Time a Microsoft Entra Privileged Identity Management (PIM).

RBAC desempeña un papel fundamental en la protección y optimización de los flujos de trabajo de MLOps. RBAC restringe el acceso basado en roles asignados y evita que los usuarios no autorizados accedan a datos confidenciales, lo que mitiga los riesgos de seguridad. Los datos confidenciales incluyen datos o modelos de entrenamiento e infraestructura crítica, como canalizaciones de producción. Puede usar RBAC para garantizar el cumplimiento de las normativas de privacidad de datos. RBAC también proporciona un registro claro de acceso y permisos, que simplifica la auditoría, facilita la identificación de brechas de seguridad y realiza un seguimiento de la actividad del usuario.

Administración de paquetes

Las dependencias de varios paquetes, bibliotecas y archivos binarios son comunes a lo largo del ciclo de vida de MLOps. Estas dependencias, a menudo desarrolladas por la comunidad y en rápida evolución, requieren el conocimiento de expertos en la materia para su correcta utilización y comprensión. Debe asegurarse de que las personas adecuadas tengan acceso seguro a diversos recursos, como paquetes y bibliotecas, pero también debe evitar vulnerabilidades. Los científicos de datos detectan este problema cuando ensamblan bloques de creación especializados para soluciones de aprendizaje automático. Los enfoques tradicionales de administración de software son costosos e ineficaces. Otros enfoques proporcionan más valor.

Para administrar estas dependencias, puede usar un proceso de administración de paquetes seguro, de autoservicio y basado en el patrón de cuarentena. Puede diseñar este proceso para permitir a los científicos de datos autoservicio de una lista seleccionada de paquetes y asegurarse de que los paquetes son seguros y compatibles con los estándares de la organización.

Este enfoque incluye tres repositorios de paquetes de aprendizaje automático estándar del sector: Registro de artefactos Microsoft, Índice de paquetes de Python (PyPI) y Conda. La lista segura permite el autoservicio desde áreas de trabajo individuales de Machine Learning. A continuación, use un proceso de prueba automatizado durante la implementación para examinar los contenedores de soluciones resultantes. Los fallos salen de forma elegante del proceso de implementación y quitan el contenedor. El diagrama y el flujo de proceso siguientes muestran este proceso:

Diagrama que muestra el enfoque seguro del paquete de Machine Learning.

Flujo del proceso

  1. Los científicos de datos que trabajan en un área de trabajo de Machine Learning que tiene una configuración de red pueden autoadministrar paquetes de aprendizaje automático a petición de los repositorios de paquetes de aprendizaje automático. Se requiere un proceso de excepción para todo lo demás mediante el patrón de almacenamiento privado, que se inicializa y mantiene mediante una función centralizada.

  2. Machine Learning ofrece soluciones de aprendizaje automático como contenedores de Docker. A medida que se desarrollan estas soluciones, se cargan en Container Registry. Microsoft Defender para contenedores genera evaluaciones de vulnerabilidades para la imagen de contenedor.

  3. La implementación de soluciones se produce a través de un proceso de CI/CD. Microsoft Defender para DevOps se usa en toda la pila para proporcionar protección contra amenazas y administración de la posición de seguridad.

  4. El contenedor de soluciones solo se implementa si pasa cada uno de los procesos de seguridad. Si el contenedor de soluciones produce un error en un proceso de seguridad, se produce un error en la implementación con notificaciones de error y seguimientos de auditoría completos. El contenedor de soluciones se descarta.

El flujo de proceso anterior proporciona un proceso seguro, de autoservicio y de administración de paquetes para los científicos de datos y garantiza que los paquetes sean seguros y conformes con los estándares de la organización. Para equilibrar la innovación y la seguridad, puede conceder a los científicos de datos acceso de autoservicio a paquetes de aprendizaje automático comunes, bibliotecas y archivos binarios en entornos de preproducción. Requiera excepciones para paquetes menos comunes. Esta estrategia garantiza que los científicos de datos puedan seguir siendo productivos durante el desarrollo, lo que evita un cuello de botella importante durante la entrega.

Para simplificar los procesos de versión, contenedorice los entornos de uso en entornos de producción. Los entornos contenedorizados reducen el trabajo activo y garantizan la seguridad continua a través del examen de vulnerabilidades. Este flujo de proceso proporciona un enfoque repetible que puede usar en los casos de uso para el tiempo de entrega. Reduce el coste general para compilar e implementar soluciones de aprendizaje automático dentro de su empresa.

Supervisión

En MLOps, la supervisión es fundamental para mantener el estado y el rendimiento de los sistemas de aprendizaje automático y garantizar que los modelos sigan siendo eficaces y estén alineados con los objetivos empresariales. La supervisión admite controles de gobernanza, seguridad y costes durante la fase de bucle interno. Además, proporciona observabilidad en el rendimiento, la degradación del modelo y el uso al implementar soluciones durante la fase del bucle externo. Las actividades de supervisión son relevantes para personas como Científico de datos, partes interesadas del negocio, jefes de proyecto, responsables de proyecto, soporte técnico de plataforma, procesos de CI/CD y procesos de supervisión.

Elija la plataforma de supervisión y comprobación en función de la configuración del área de trabajo de Machine Learning, como un proyecto, un equipo o un departamento.

Rendimiento del modelo

Supervise el rendimiento del modelo para detectar a tiempo los problemas y la degradación del rendimiento. Realice un seguimiento del rendimiento para asegurarse de que los modelos sigan siendo precisos, confiables y alineados con los objetivos empresariales.

Desfase de datos

El desfase de datos realiza un seguimiento de los cambios en la distribución de los datos de entrada de un modelo comparándolo con los datos de entrenamiento del modelo o con los datos de producción anteriores recientes. Estos cambios son el resultado de los cambios en la dinámica del mercado, los cambios de transformación de características o los cambios de datos ascendentes. Estos cambios pueden degradar el rendimiento del modelo, por lo que es importante supervisar el desfase para garantizar la corrección oportuna. Para realizar una comparación, la refactorización del desfase de datos requiere conjuntos de datos y salidas de producción recientes.

Entorno: Producción
Facilitación de Azure: Aprendizaje automático – Supervisión de modelo

Desfase de predicción

El desfase de predicción realiza un seguimiento de los cambios en la distribución de los resultados de predicción de un modelo comparándolos con datos de validación, etiquetados por prueba o de producción reciente. Para realizar una comparación, la refactorización del desfase de datos requiere conjuntos de datos y salidas de producción recientes.

Entorno: Producción
Facilitación de Azure: Aprendizaje automático – Supervisión de modelo

Resource

Use varias métricas de punto de conexión de servicio de modelos para indicar la calidad y el rendimiento, como el uso de CPU o memoria. Este enfoque le ayuda a aprender de producción para ayudar a impulsar futuras inversiones o cambios.

Entorno: Todo
Facilitación de Azure: Supervisión - Métricas de puntos de conexión en línea

Métricas de uso

Supervise el uso de puntos de conexión para asegurarse de que cumple los indicadores clave clave de rendimiento específicos de la organización o de la carga de trabajo, realice un seguimiento de los patrones de uso y diagnostique y corrija los problemas que experimentan los usuarios.

Solicitudes de cliente

Realice un seguimiento del número de solicitudes de cliente al punto de conexión del modelo para comprender el perfil de uso activo de los puntos de conexión, lo que puede afectar a los esfuerzos de escalado o optimización de costes.

Entorno: Producción
Facilitación de Azure: Supervisión - Métricas de puntos de conexión en línea, como RequestsPerMinute. Notas:

  • Puede alinear umbrales aceptables con el ajuste de tamaño de camiseta o las anomalías que se adaptan a las necesidades de la carga de trabajo.
  • Retire los modelos que ya no están en uso de producción.
Retrasos de limitación

Los retrasos de limitación son ralentizaciones en la solicitud y respuesta de las transferencias de datos. La limitación se produce en el nivel de Resource Manager y en el nivel de servicio. Realice un seguimiento de las métricas en ambos niveles.

Entorno: Producción
Facilitación de Azure:

Notas: alinee los umbrales aceptables con los objetivos de nivel de servicio (SLO) o los acuerdos de nivel de servicio (SLA) de la carga de trabajo y los requisitos no funcionales de la solución (NFR).

Errores generados

Realice un seguimiento de los errores de código de respuesta para ayudar a medir la confiabilidad del servicio y garantizar la detección temprana de problemas de servicio. Por ejemplo, un aumento repentino en 500 respuestas de error del servidor podría indicar un problema crítico que necesita atención inmediata.

Entorno: Producción
Facilitación de Azure: Machine Learning - Habilite los registros de tráfico del punto de conexión en línea para comprobar la información sobre la solicitud. Por ejemplo, puede comprobar el recuento de XRequestId mediante ModelStatusCode o ModelStatusReason. Puede usar un área de trabajo de Log Analytics para procesar los registros.
Notas:

  • Todos los códigos de respuesta HTTP del intervalo 400 y 500 se clasifican como un error.

Optimización de costos

La administración y optimización de costes en un entorno en la nube son cruciales porque ayudan a las cargas de trabajo a controlar los gastos, asignar recursos de forma eficaz y maximizar el valor de sus servicios en la nube.

Área de trabajo y proceso

Cuando los gastos operativos mensuales alcanzan o superan una cantidad predefinida, genere alertas para notificar a las partes interesadas pertinentes, como los responsables del proyecto o los jefes de proyecto, en función de los límites de configuración del área de trabajo. Puede determinar la configuración del área de trabajo en función de los límites relacionados con el proyecto, el equipo o el departamento.

Entorno: Todo
Facilitación de Azure: Microsoft Cost Management: - Alertas de presupuesto
Notas:

  • Establezca umbrales de presupuesto en función de las NFR iniciales y las estimaciones de costes.
  • Use varios niveles de umbral. Varios niveles de umbral garantizan que las partes interesadas obtengan una advertencia adecuada antes de que se supere el presupuesto. Estas partes interesadas pueden incluir responsables del negocio, jefes o responsables de proyecto en función de la organización o la carga de trabajo.
  • Las alertas de presupuesto coherentes también podrían ser un desencadenador para que la refactorización admita una mayor demanda.
Obsolescencia del área de trabajo

Si un área de trabajo de Machine Learning no muestra signos de uso activo en función del uso de proceso asociado para el caso de uso previsto, un responsable del proyecto podría retirar el área de trabajo si ya no es necesaria para un proyecto determinado.

Entorno: Preproducción
Facilitación de Azure:

Notas:

  • Los núcleos activos deben ser igual a cero con la agregación del recuento.
  • Alinee los umbrales de fecha con la programación del proyecto.

Seguridad

Supervise para detectar desviaciones de los controles de seguridad y las líneas base adecuadas para asegurarse de que las áreas de trabajo de Machine Learning son compatibles con las directivas de seguridad de la organización. Puede usar una combinación de directivas predefinidas y definidas por el personal.

Entorno: Todo
Facilitación de Azure: Azure Policy para Machine Learning

Seguridad de los puntos de conexión

Para obtener visibilidad de las API críticas para la empresa, implemente la supervisión de seguridad dirigida de todos los puntos de conexión de Machine Learning. Puede investigar y mejorar la posición de seguridad de una API, priorizar las correcciones de vulnerabilidades y detectar rápidamente amenazas activas en tiempo real.

Entorno: Producción
Facilitación de Azure: Microsoft Defender para API ofrece una amplia cobertura de protección, detección y respuesta del ciclo de vida para las API. Notas: Defender para API ofrece seguridad para las API publicadas en Azure API Management. Puede incorporar Defender para API en el portal de Microsoft Defender for Cloud o en la instancia de API Management de Azure Portal. Debe integrar puntos de conexión en línea de Machine Learning con API Management.

Implementación y supervisión

La supervisión de la implementación garantiza que todos los puntos de conexión que cree se adhieren a las directivas de la organización o carga de trabajo y que están libres de vulnerabilidades. Este proceso requiere que aplique directivas de cumplimiento en los recursos de Azure antes y después de la implementación, proporcione seguridad continua a través del examen de vulnerabilidades y asegúrese de que el servicio cumple los SLO mientras está en funcionamiento.

Estándares y gobernanza

Supervise para detectar desviaciones de los estándares adecuados y asegúrese de que la carga de trabajo cumple los límites de protección.

Entorno: Todo
Facilitación de Azure:

  • Asignación y ciclo de vida de directivas administradas a través de Azure Pipelines para tratar la directiva como código.
  • PSRule para Azure proporciona un marco de pruebas para la infraestructura de Azure como código.
  • Puede usar Enterprise Azure Policy como código en directivas de implementación de sistema basadas en CI/CD, conjuntos de directivas, asignaciones, exenciones de directivas y asignaciones de roles.

Notas: Para obtener más información, consulte Guía de Azure para el cumplimiento normativo de Machine Learning.

Examen de seguridad

Implemente exámenes de seguridad automatizados como parte de los procesos de integración e implementación automatizados.

Entorno: Todo
Facilitación de Azure: Defender para DevOps
Notas: Puede usar aplicaciones de Azure Marketplace para ampliar este proceso para los módulos de pruebas de seguridad que no son de Microsoft.

Servicio continuo

Supervise el servicio continuo de una API para la optimización del rendimiento, la seguridad y el uso de recursos. Garantice la detección oportuna de errores, la resolución eficaz de problemas y el cumplimiento de los estándares.

Entorno: Producción
Facilitación de Azure:

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes