La guía más detallada sobre MLOps: Parte 1

¡Hola Hackernoon! En este artículo, analizaré en detalle el concepto de MLOps. Además, lo haré de 3 formas. En primer lugar, teóricamente, a través del esquema MLOps más sensato. Luego, conceptualmente, a través de los artefactos que están integrados en el enfoque. Y finalmente, entendiendo MLOps como un sistema de información.

Entonces, comencemos.

¿Qué es MLOps?

Esta pregunta ha ocupado durante mucho tiempo la mente de muchos equipos de desarrollo de sistemas ML. En este artículo, por sistema de este tipo entenderé un sistema de información, uno o más componentes del cual contiene un modelo entrenado que realiza alguna parte de la lógica empresarial general.

Como cualquier otro componente del sistema, esta parte de la lógica empresarial debe actualizarse para satisfacer las cambiantes expectativas empresariales y de los clientes. MLOps tiene que ver con esta actualización periódica.

Definición y explicación de MLOps

Todavía no existe una definición única y acordada de MLOps. Muchos autores han intentado darlo, pero fue un desafío encontrar una descripción clara y sistemática al mismo tiempo.

Hay uno que podría considerarse tal:

MLOps es una disciplina de ingeniería que tiene como objetivo unificar el desarrollo (dev) de sistemas ML y la implementación (ops) de sistemas ML para estandarizar y optimizar la entrega continua de modelos de alto rendimiento en producción.

Resaltemos las partes críticas de la definición de MLOps:

• Disciplina de ingeniería
• Tiene como objetivo unificar los procesos de desarrollo e implementación de sistemas ML.
• Estandariza y optimiza la entrega continua de nuevas versiones.
• Modelos de alto rendimiento

Entonces, MLOps es una especie de DevOps para modelos ML.

Historia del surgimiento de MLOps

Es fácil creer que esta disciplina de ingeniería se originó en una gran empresa de TI. Por lo tanto, podemos confiar en la teoría de que MLOps, como enfoque significativo, se originó en Google, donde D. Sculley intentaba ahorrarse los nervios y el tiempo de las tareas mundanas relacionadas con la conversión de modelos de ML en extensiones. D. Sculley ahora es ampliamente conocido como "El padrino de MLOps": el podcast del mismo nombre es fácil de encontrar en línea.

D. Sculley empezó a considerar el trabajo con modelos desde el punto de vista de la deuda técnica del equipo. Sí, es posible lanzar nuevas versiones de modelos rápidamente, pero el costo de soporte del sistema resultante tendrá un impacto significativo en el presupuesto de la empresa.

Su trabajo dio como resultado el artículo "Deuda técnica oculta en los sistemas de aprendizaje automático " publicado en 2015 en la conferencia NeurIPS. La fecha de publicación de este artículo puede considerarse el punto de partida de la existencia de MLOps.

Niveles de madurez de MLOps: los modelos más conocidos

Como la mayoría de los procesos de TI, los MLOps tienen niveles de madurez. Ayudan a las empresas a comprender dónde se encuentran ahora y cómo pueden pasar al siguiente nivel (si existe tal objetivo). Además, los métodos generalmente aceptados para determinar el vencimiento le permiten determinar su lugar entre los competidores.

Modelo de madurez de GigaOm MLOps

El modelo mejor descrito y ampliamente comprensible es el de la empresa de análisis GigaOm . Es el más cercano a la Integración del modelo de madurez de capacidad (CMMI) de todos los modelos. Se trata de un conjunto de metodologías para mejorar los procesos organizacionales, que también consta de 5 niveles, del 0 al 4.

El modelo de GigaOm desglosa cada nivel de madurez a través de 5 categorías: estrategia, arquitectura, modelado, procesos y gobernanza.

Guiado por este modelo en las primeras etapas de la construcción de un sistema de aprendizaje automático, puede pensar con anticipación en aspectos esenciales y reducir las posibilidades de falla. Pasar de un nivel de madurez a uno superior presenta al equipo nuevos desafíos que quizás no se habían dado cuenta de que existían antes.

Modelo de madurez de Google MLOps

Vale la pena señalar que Google también tiene su modelo de niveles de madurez MLOps . Fue uno de los primeros en aparecer. Es conciso y consta de 3 niveles:

• Nivel 0: proceso manual
• Nivel 1: automatización del proceso de aprendizaje automático
• Nivel 2: automatización del proceso de CI/CD

Es difícil dejar de pensar que este modelo se parece a un manual de instrucciones para pintar un búho. Primero, haga todo a mano, ensamble las canalizaciones de ML y finalice los MLOps. Dicho esto, está bien descrito.

Modelo de madurez de Azure MLOps

Hoy en día, muchas grandes empresas que utilizan ML han compilado sus modelos de madurez. Azur Se incluye , que utiliza un enfoque similar para distinguir niveles. Sin embargo, hay más que los de Google:

• Nivel 0: sin operaciones MLO
• Nivel 1: DevOps pero no MLOps
• Nivel 2: Entrenamiento automatizado
• Nivel 3: Implementación automatizada del modelo
• Nivel 4: Operaciones automatizadas completas de MLOps

Todos los modelos destacados convergen aproximadamente en una cosa. En el nivel cero, tienen la ausencia de prácticas de LD. En el último nivel tienen la automatización de procesos MLOps. Siempre hay algo diferente en el medio relacionado con la automatización incremental de procesos. Azure tiene esta automatización del proceso de capacitación y luego la implementación del modelo.

Marco conceptual de MLOps

¿Cómo describe todos los procesos asociados con el concepto de MLOps? Sorprendentemente, tres alemanes, los autores del artículo " Operaciones de aprendizaje automático (MLOps): descripción general, definición y arquitectura " - incluso lograron resumirlos en un diagrama. Realizaron un estudio real y describieron el concepto de MLOps con gran detalle.

Puede resultar intimidante ya que tiene muchos elementos que interactúan entre sí. Sin embargo, en él se pueden encontrar muchas de las características de los niveles de madurez mencionados anteriormente. Al menos canalizaciones automatizadas, CI/CD, supervisión, registro de modelos, orquestación de flujo de trabajo y componente de servicio.

Analicemos este diagrama y hablemos de cada uno con más detalle.

Procesos centrales de MLOps

Las partes principales del esquema son bloques horizontales, dentro de los cuales se describen los aspectos procesales de MLOps (se les asignan las letras A, B, C y D). Cada uno de ellos está diseñado para resolver tareas específicas en el marco de garantizar el buen funcionamiento de los servicios de ML de la empresa. Para facilitar la comprensión del esquema, es mejor empezar fuera de orden.

Experimentación

Si una empresa cuenta con servicios de ML, los empleados trabajan en Jupyter. En muchas empresas, esta es la herramienta donde se centran todos los procesos de desarrollo de ML. Aquí es donde comienzan la mayoría de las tareas que requieren implementar prácticas MLOps.

Consideremos un ejemplo. La empresa A necesita automatizar una parte de algunos procesos mediante el aprendizaje automático (supongamos que existe el departamento y los especialistas correspondientes). Es poco probable que se conozca de antemano la forma de resolver el problema. Por lo tanto, los ejecutores deben estudiar el planteamiento del problema y probar posibles formas de realizarlo.

Para hacer esto, un ingeniero/desarrollador de ML escribe código para varias implementaciones de tareas y evalúa los resultados obtenidos según las métricas objetivo. Todo esto casi siempre se hace en Jupyter Lab. De esta forma, es necesario capturar mucha información importante manualmente y luego comparar las implementaciones entre sí.

Esta actividad se llama experimentación. Significa obtener un modelo de ML funcional, que se puede utilizar en el futuro para resolver problemas relevantes.

El bloque C que se muestra en el diagrama describe el proceso de realización de experimentos de ML.

Analizar los datos disponibles dentro del alcance de la tarea.

Muchas decisiones en el desarrollo de ML se toman en base al análisis de los datos disponibles en la empresa. No es posible entrenar un modelo con métricas de calidad objetivo sobre datos de baja calidad o datos que no existen.

Por tanto, es importante averiguar qué datos hemos obtenido y qué podemos hacer con ellos. Para hacer esto, por ejemplo, podemos:

• Realizar un estudio ADHoc usando Jupyter o Superset
• EDA estándar (análisis de datos exploratorios)

Sólo se puede obtener una mejor comprensión de los datos cuando se combina con un análisis semántico y estructural.

Sin embargo, sólo en ocasiones la preparación de datos está bajo el control del equipo del proyecto. En este caso, se aseguran dificultades adicionales. A veces, en esta etapa, queda claro que no tiene sentido seguir desarrollando el proyecto porque los datos no son adecuados para el trabajo.

Formación de un conjunto de datos de calidad.

Cuando hay confianza en los datos disponibles, es necesario pensar en las reglas de preprocesamiento. Incluso si hay un gran conjunto de datos adecuados, no hay garantía de que no contengan omisiones, valores distorsionados, etc. Cabe mencionar el término "calidad de los datos de entrada" y la conocida frase "basura que entra - basura que sale". aquí.

No importa qué tan bueno se utilice un modelo, producirá malos resultados con datos de baja calidad. En la práctica, muchos recursos del proyecto se gastan en crear un conjunto de datos de alta calidad.

Entrenamiento y validación del modelo ML

Después de la etapa anterior, tiene sentido considerar las métricas del modelo entrenado al realizar experimentos. En el marco del bloque considerado, el experimento consiste en vincular el entrenamiento y la validación del modelo ML.

El experimento consiste en el esquema clásico de entrenar la versión deseada del modelo con el conjunto seleccionado de hiperparámetros en el conjunto de datos preparado. Para ello, el conjunto de datos en sí se divide en muestras de entrenamiento, prueba y validación:

• Los dos primeros se utilizan para seleccionar el conjunto óptimo de hiperparámetros.
• El tercero es la verificación final y confirmación de que el modelo entrenado en el conjunto de hiperparámetros seleccionado se comporta adecuadamente en datos desconocidos que no participaron en el proceso de selección y entrenamiento de hiperparámetros.

Puede leer más sobre muestras de validación en Este artículo .

Guardar código e hiperparámetros en un repositorio

Si las métricas de aprendizaje del modelo son buenas, el código del modelo y los parámetros seleccionados se almacenan en un repositorio corporativo.

El objetivo fundamental del proceso de experimentación es la ingeniería de modelos, lo que implica la selección del mejor algoritmo y la selección del mejor ajuste de hiperparámetros.

La dificultad de realizar experimentos es que el desarrollador necesita verificar muchas combinaciones de parámetros de operación del modelo ML. Y no estamos hablando de diferentes variantes del aparato matemático utilizado.

En general, requiere trabajo. ¿Y qué hacer si no se logran las métricas deseadas en el marco de combinaciones de parámetros del modelo?

Ingeniería de características

Si no se pueden lograr las métricas deseadas de la operación del modelo ML, puede intentar ampliar la descripción de las características de los objetos del conjunto de datos con nuevas características. Gracias a ellos, el contexto del modelo se ampliará y, por tanto, las métricas deseadas podrán mejorar.

Las nuevas características pueden incluir:

• Para datos tabulares: transformaciones arbitrarias de atributos de objetos ya existentes, por ejemplo, X^2, SQRT(X), Log(x), X1*X2, etc.
• Según el área temática: índice de masa corporal, número de pagos de préstamos vencidos durante un año, etc.

Veamos la parte del diagrama que se relaciona con la ingeniería de funciones.

El bloque B1 tiene como objetivo formar un conjunto de requisitos para transformar los datos fuente disponibles y obtener características de ellos. El cálculo de los componentes en sí se realiza a partir de estos datos preprocesados y limpios de acuerdo con las "fórmulas" ingresadas por el desarrollador de ML.

Es fundamental decir que trabajar con funciones es iterativo. Al aplicar un conjunto de características, puede surgir una nueva idea, materializada en otro conjunto de características, y así sucesivamente, hasta el infinito. Esto se muestra explícitamente en el diagrama como un circuito de retroalimentación.

El bloque B2 describe el proceso inmediato de agregar nuevas características a los datos.

Conectarse y recuperar fuentes de datos son operaciones técnicas que pueden resultar bastante complicadas. Para simplificar la explicación, asumiré que hay varias fuentes a las que el equipo tiene acceso y herramientas para descargar datos de estas fuentes (al menos scripts de Python).

Limpieza y transformación de datos. Esta etapa casi coincide con un paso similar en el bloque de experimentos (C): preparación de datos. Ya en los primeros experimentos se comprende qué datos y en qué formato se necesitan para entrenar modelos de ML. Sólo queda generar y probar nuevas funciones correctamente, pero el proceso de preparación de datos para este fin debe automatizarse lo más posible.

Cálculo de nuevas características. Como se señaló anteriormente, estas acciones pueden consistir en simplemente transformar algunos elementos de una tupla de datos. Otra opción es ejecutar una canalización de procesamiento grande separada para agregar una única característica a la misma tupla de datos. De cualquier manera, hay un conjunto de acciones que se ejecutan de forma secuencial.

Sumando el resultado. El resultado de las acciones anteriores se agrega al conjunto de datos. La mayoría de las veces, las funciones se agregan al conjunto de datos por lotes para reducir la carga de la base de datos. Pero en ocasiones es necesario hacerlo sobre la marcha (streaming) para acelerar la ejecución de las tareas empresariales.

Es fundamental utilizar las funciones obtenidas de la manera más eficiente posible: guardarlas y reutilizarlas en tareas de otros desarrolladores de ML de la empresa. El esquema cuenta con una tienda de funciones para este propósito. Debería estar disponible dentro de la empresa, administrarse por separado y tener versiones de todas las funciones que incluye. La tienda de funciones tiene 2 partes: en línea (para secuencias de comandos en streaming) y fuera de línea (para secuencias de comandos por lotes).

Flujo de trabajo de aprendizaje automático automatizado

Al comienzo del artículo, indiqué que por sistema ML me refiero a un sistema de información, uno o más componentes del cual contiene un modelo entrenado que realiza alguna parte de la lógica empresarial general. Cuanto mejor sea el modelo de ML obtenido gracias al desarrollo, mayor será el efecto de su funcionamiento. Un modelo entrenado procesa el flujo entrante de solicitudes y proporciona algunas predicciones en respuesta, automatizando así algunas partes del análisis o proceso de toma de decisiones.

El proceso de utilizar un modelo para generar predicciones se llama inferencia y entrenar un modelo se llama entrenamiento. Gartner puede obtener una explicación clara de la diferencia entre los dos. Aquí practicaré con gatos.

Para el funcionamiento eficiente de un sistema de ML de producción, es vital estar atento a las métricas de inferencia del modelo. Tan pronto como comiencen a caer, se debe volver a entrenar el modelo o reemplazarlo por uno nuevo. En la mayoría de los casos, esto ocurre debido a cambios en los datos de entrada (desviación de datos). Por ejemplo, hay un problema empresarial en el que el modelo puede reconocer cupcakes en las fotografías y se le proporciona esto como entrada. Los perros chihuahua del ejemplo son para mantener el equilibrio:

El modelo del conjunto de datos original no sabe nada sobre los perros chihuahua, por lo que predice incorrectamente. Por tanto, es necesario cambiar el conjunto de datos y realizar nuevos experimentos. El nuevo modelo debería estar en producción lo antes posible. Nadie prohíbe a los usuarios subir imágenes de perros chihuahua, pero obtendrán resultados incorrectos.

Ahora veamos más ejemplos del mundo real. Consideremos el desarrollo de un sistema de recomendación para un mercado.

En función del historial de compras del usuario, compras de usuarios similares y otros parámetros, un modelo o conjunto de modelos genera un bloque con recomendaciones. Contiene productos cuyos ingresos por compras se cuentan y rastrean periódicamente.

Algo sucede y las necesidades de los clientes cambian. En consecuencia, sus recomendaciones ya no son relevantes. La demanda de los productos recomendados cae. Todo esto conduce a una disminución de los ingresos.

Los siguientes directivos gritan y exigen que todo esté restablecido mañana, lo que no conduce a nada. ¿Por qué? No hay datos suficientes sobre las preferencias de los nuevos clientes, por lo que ni siquiera se puede fabricar un modelo nuevo. Puede tomar algunos algoritmos básicos de generación de recomendaciones (filtrado colaborativo basado en elementos) y agregarlos a producción. De esta manera, las recomendaciones funcionarán de alguna manera, pero se trata sólo de una solución temporal.

Idealmente, el proceso debería configurarse de tal manera que el proceso de reentrenamiento o experimentación con diferentes modelos se inicie en función de métricas sin que los gerentes les digan que lo hagan. Y el mejor eventualmente reemplazaría al actual en producción. En el diagrama, este es el canal de flujo de trabajo de aprendizaje automático automatizado (bloque D), que se inicia mediante activadores en alguna herramienta de orquestación.

Esta es la sección más cargada del plan. Varios componentes clave de terceros participan en el funcionamiento del bloque D:

• El componente del orquestador de flujo de trabajo, que es responsable de iniciar la canalización en un horario o evento específico.
• Feature Store, del cual se toman datos sobre las características necesarias para el modelo.
• Registro de modelos y almacén de metadatos de ML, donde se colocan los modelos y sus métricas, obtenidos tras el trabajo del Pipeline lanzado.

La estructura del bloque en sí combina las etapas de los bloques de experimentación y desarrollo de características (B2). No es de extrañar, teniendo en cuenta que estos son los procesos que deben automatizarse. Las principales diferencias están en las 2 últimas etapas:

• Modelo de exportación
• Empujar al registro de modelos

Los pasos restantes son idénticos a los descritos anteriormente.

Por separado, quiero mencionar los artefactos de servicio que requiere el orquestador para ejecutar canalizaciones de reentrenamiento de modelos. Este es el código que se almacena en el repositorio y se ejecuta en servidores seleccionados. Está versionado y actualizado siguiendo todas las reglas del desarrollo de software. Este código implementa las canalizaciones de reentrenamiento del modelo y el resultado depende de su corrección.

La mayoría de las veces, se ejecutan varias herramientas de aprendizaje automático dentro del código, dentro de las cuales tiene lugar la ejecución de los pasos de las canalizaciones, por ejemplo:

• El orquestador de flujo de aire ejecuta el código para ejecutar las etapas de las tuberías.
• Feast descarga datos sobre las características del conjunto de datos cuando se le ordena
• Luego, ClearML crea un nuevo conjunto de datos y ejecuta un experimento con el conjunto necesario de métricas de rendimiento del modelo, que toma de su propio repositorio.
• Una vez completada la investigación, ClearML guarda el modelo y sus métricas de rendimiento en el almacenamiento.

Vale la pena señalar aquí que, en general, es imposible automatizar experimentos. Por supuesto, es posible agregar el concepto AutoML al proceso. Sin embargo, actualmente no existe ninguna solución reconocida que pueda usarse con los mismos resultados para cualquier tema del experimento.

En el caso general, AutoML funciona así:

1. De alguna manera genera un conjunto de muchas combinaciones de parámetros de operación del modelo.
2. Ejecuta un experimento para cada combinación resultante. Corrige métricas para cada experimento en función de cuál se selecciona el mejor modelo.
3. AutoML realiza todas las manipulaciones que haría un científico de datos junior/intermedio en un círculo de tareas más o menos estándar.

Se ha abordado un poco la automatización. A continuación, debemos organizar la entrega de una nueva versión del modelo a producción.

Modelos de servicio y seguimiento.

Se requiere el modelo ML para generar predicciones. Pero el modelo ML en sí es un archivo, por lo que no se puede generar tan rápidamente. A menudo se puede encontrar una solución de este tipo en Internet: un equipo toma FastAPI y escribe un contenedor de Python alrededor del modelo para que pueda "seguir los predicados".

Desde el momento en que se recibe el archivo del modelo ML, hay varias formas en que las cosas pueden desarrollarse. El equipo puede ir:

• Escriba todo el código para crear un servicio RESTfull
• Implementar todo el envoltorio a su alrededor.
• Constrúyalo todo en una imagen de Docker
• Y luego, en algún lugar de esa imagen, vas a construir un contenedor.
• Escalelo de alguna manera
• Organizar la recopilación de métricas.
• Configurar alertas
• Configurar reglas para implementar nuevas versiones del modelo
• Muchas otras cosas

Es una tarea que requiere mucha mano de obra hacer esto para todos los modelos y mantener toda la base del código en el futuro. Para hacerlo más fácil, aparecieron herramientas de servicio especiales, que introdujeron 3 nuevas entidades:

• Instancia/servicio de inferencia
• Servidor de inferencia
• Motor de servicio

Una Instancia de Inferencia, o Servicio de Inferencia , es un modelo de ML específico preparado para recibir consultas y generar predicciones de respuestas. Una entidad de este tipo puede representar un suben un clúster de Kubernetes con un contenedor con el modelo de aprendizaje automático necesario y las herramientas técnicas para ejecutarlo.

El servidor de inferencia es el creador de instancias/servicios de inferencia. Hay muchas implementaciones de Inference Server. Cada uno puede trabajar con marcos de aprendizaje automático específicos, convirtiendo los modelos entrenados en ellos en modelos listos para usar para procesar consultas de entrada y generar predicciones.

El Serving Engine realiza las funciones de gestión principales. Determina qué servidor de inferencia se utilizará, cuántas copias de la instancia de inferencia resultante se deben iniciar y cómo escalarlas.

En el esquema que estamos considerando no existen tales detalles sobre los componentes del servicio del modelo, pero se describen aspectos similares:

• Componente CI/CD, que despliega modelos listos para ejecutarse en producción (puede considerarse como una de las versiones de Serving Engine)
• Model Serving, dentro de la infraestructura de la que dispone, organiza el esquema de generación de predicción para modelos ML, tanto para escenarios streaming como por lotes (puede considerarse como una de las versiones de Inference Server)

Para ver un ejemplo de una pila completa para Serving, podemos consultar la pila de Seldon:

• Seldon Core es el motor de servicio
• Seldon ML Server es el servidor de inferencia, que prepara el acceso al modelo mediante REST o gRPC.
• Seldon MLServer Custom Runtime es la instancia de inferencia, una instancia de shell para cualquier modelo de ML cuyo ejemplo debe ejecutarse para generar predicciones.

Incluso existe un protocolo estandarizado para implementar Serving, cuyo soporte es obligatorio de facto en todas estas herramientas. Se llama Protocolo de inferencia V2 y ha sido desarrollado por varios actores destacados del mercado: KServe, Seldon y Nvidia Triton.

Servir versus implementar

En varios artículos, puede encontrar referencias a las herramientas para servir e implementar como una sola entidad. Sin embargo, es fundamental comprender la diferencia en el propósito de ambos. Este es un tema discutible, pero este artículo lo expresará de esta manera:

• Servicio: la creación de un modelo API y la posibilidad de obtener predicciones a partir de él. Al final, obtienes una única instancia de servicio con un modelo en su interior.
• Implementar: distribuir la instancia de servicio en la cantidad necesaria para procesar las solicitudes entrantes (se puede representar como un conjunto de réplicas en la implementación de Kubernetes).

Se pueden utilizar muchas estrategias para implementar modelos , pero no son específicas de ML. Por cierto, la versión paga de Seldon admite varias de las estrategias, por lo que puedes seleccionar esta pila y disfrutar de cómo funciona todo.

Recuerde que se debe realizar un seguimiento de las métricas de rendimiento del modelo. De lo contrario, no podrá resolver los problemas a tiempo. Cómo exactamente realizar un seguimiento de las métricas es la gran pregunta. Arize AI ha construido todo un negocio sobre esta base, pero nadie ha cancelado Grafana y VictoriaMetrics.

Inicio del proyecto

Teniendo en cuenta todo lo escrito anteriormente, resulta que el comando ML:

• Genera conjuntos de datos
• Realiza experimentos con ellos en modelos ML.
• Desarrolla nuevas funciones para ampliar los conjuntos de datos y mejorar la calidad de los modelos.
• Guarda los mejores modelos en el Registro de modelos para su reutilización futura
• Personaliza el servicio y la implementación de modelos.
• Personaliza el seguimiento de los modelos en producción y el reentrenamiento automático de los modelos actuales o la creación de nuevos modelos.

Parece costoso y sólo a veces justificado. Por lo tanto, hay un bloque de Inicio de Proyecto MLOps (A) separado en el diagrama responsable del establecimiento racional de objetivos.

Un ejemplo del razonamiento del director de TI puede demostrar la forma de pensar en este caso. Un gerente de proyecto inspirado se acerca a él y le solicita la instalación de una nueva plataforma para construir un sistema ML. Si ambos actúan en el mejor interés de la empresa, el director de TI realizará preguntas aclaratorias:

• ¿Qué problema empresarial vas a resolver con el nuevo sistema ML?
• ¿Por qué decidiste que el nuevo sistema ML debería resolver este problema?
• ¿Sería más fácil y económico cambiar procesos o contratar más gente en soporte técnico?
• ¿Dónde puede ver un análisis comparativo de los componentes del sistema ML que formaron la base de su selección actual?
• ¿Cómo ayudará la arquitectura del sistema ML elegida a resolver un problema empresarial?
• ¿Está seguro de que ML tiene el aparato matemático necesario para resolver el problema identificado?
• ¿Cuál es el planteamiento del problema para la solución?
• ¿De dónde obtendrás los datos para entrenar los modelos? ¿Sabes qué datos necesitas para preparar los modelos?
• ¿Ha examinado ya los datos disponibles?
• ¿Es la calidad de los datos suficiente para resolver el modelo?

El director de TI dejará de ser profesor en una universidad, pero ahorrará dinero a la empresa. Si se han respondido todas las preguntas, existe una necesidad real de un sistema de aprendizaje automático.

Siguiente pregunta: ¿Necesito hacer MLOps en él?

Depende del problema. Si necesita encontrar una solución única, por ejemplo, PoC (prueba de concepto), no necesita MLOps. Si es esencial procesar muchas solicitudes entrantes, entonces se requiere MLOps. En esencia, el enfoque es similar a la optimización de cualquier proceso corporativo.

Para justificar ante la gerencia la necesidad de MLOps, es necesario preparar respuestas a las preguntas:

• ¿Qué va a mejorar?
• ¿Cuánto dinero ahorraremos?
• ¿Necesitamos ampliar nuestro personal?
• ¿Qué necesitamos comprar?
• ¿Dónde adquirir experiencia?

Lo siguiente que debe hacer es volver a realizar el examen de director de TI.

Los desafíos continúan porque el equipo también debe estar convencido de la necesidad de cambiar sus procesos de trabajo y su pila tecnológica. A veces, esto es más difícil que pedir un presupuesto a la dirección.

Para convencer al equipo, conviene preparar respuestas a las preguntas:

• ¿Por qué la antigua forma de trabajar ya no es posible?
• ¿Cuál es el propósito del cambio?
• ¿Cuál será la pila de tecnología?
• ¿Qué y de quién aprender?
• ¿Cómo ayudará la empresa a implementar los cambios?
• ¿Cuánto tiempo se tarda en realizar el cambio?
• ¿Qué pasa con aquellos que no lo logran?

Como puedes ver, este proceso no es sencillo.

Pequeña conclusión

He terminado aquí con un estudio detallado del esquema MLOps. Sin embargo, estos son sólo aspectos teóricos. La implementación práctica siempre revela detalles adicionales que pueden cambiar muchas cosas.

En el próximo artículo, discutiré:

• Artefactos MLOps
• MLOps como sistema de información
• Código abierto para MLOps: Kubeflow frente a MLflow frente a Pachyderm

¡Gracias por su atención!