Implantar MLOps en la empresa

Capítulo 1. MLOps: ¿Qué es y por qué lo necesitamos?

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

En la raíz de los sistemas ineficaces hay una red interconectada de decisiones incorrectas que se agravan con el tiempo. Es tentador buscar un remedio milagroso para un sistema que no funciona bien, pero esa estrategia rara vez, o nunca, da resultado. Considera el cuerpo humano; no escasean las soluciones rápidas que se venden para que estés sano, pero la solución a la longevidad de la salud requiere un enfoque sistemático.¹

Del mismo modo, no faltan consejos sobre "hacerse rico rápidamente". También en este caso, los datos entran en conflicto con lo que queremos oír. En Don't Trust Your Gut (HarperCollins, 2022), Seth Stephens-Davidowitz muestra que el 84% del 0,1% de los que más ganan reciben al menos algo de dinero por tener un negocio. Además, la edad media del fundador de una empresa es de unos 42 años, y algunas de las empresas con más éxito son inmobiliarias o concesionarios de automóviles. Difícilmente se trata de planes para hacerse rico rápidamente, sino de negocios que requieren una gran habilidad, pericia y sabiduría a través de la experiencia vital.

Las ciudades son otro ejemplo de sistemas complejos que no tienen soluciones milagrosas. WalletHub creó una lista de las ciudades mejor gestionadas de Estados Unidos, en la que San Francisco ocupaba el puesto 149 de 150, a pesar de tener muchas ventajas teóricas sobre otras ciudades, como un clima hermoso, ser sede de las principales empresas tecnológicas del mundo y un presupuesto para 2022-2023 de 14.000 millones de dólares para una población de 842.000 personas. Este presupuesto es similar al de todo el país de Panamá, con una población de 4,4 millones de personas. Como demuestra el caso de San Francisco, los ingresos o la belleza natural por sí solos no bastan para tener una ciudad bien gestionada; hace falta un plan integral: la ejecución y la estrategia importan. Ninguna solución por sí sola va a hacer o deshacer una ciudad. La encuesta de WalletHub señala amplios criterios para una ciudad bien gestionada, como infraestructura, economía, seguridad, salud, educación y estabilidad financiera.

Del mismo modo, con los MLOP, buscar una única respuesta para poner los modelos en producción, quizás obteniendo mejores datos o utilizando un marco específico de aprendizaje profundo, es tentador. En cambio, al igual que en estos otros ámbitos, es esencial contar con una estrategia integral basada en pruebas.

¿Qué es MLOps?

En , el núcleo de MLOps es la mejora continua de toda la actividad empresarial. La industria automovilística japonesa se refiere a este concepto como kaizen, que significa literalmente "mejora". Para construir sistemas de aprendizaje automático de producción, esto se manifiesta tanto en los aspectos perceptibles de la mejora de la precisión del modelo como en todo el ecosistema que lo sustenta.

Un gran ejemplo de uno de los componentes no evidentes del sistema de aprendizaje automático son los requisitos empresariales. Si la empresa necesita un modelo preciso para predecir cuánto inventario almacenar en el almacén, pero el equipo de ciencia de datos crea un sistema de visión por ordenador para hacer un seguimiento del inventario que ya está en el almacén, se resuelve el problema equivocado. Por muy preciso que sea el sistema de visión computerizada de seguimiento del inventario, la empresa pidió un requisito distinto, y el sistema no puede cumplir los objetivos de la organización como resultado.

¿Qué es MLOps? Un compuesto de Aprendizaje Automático (ML) y Operaciones (Ops), MLOps son los procesos y prácticas para diseñar, construir, habilitar y apoyar la implementación eficiente de modelos ML en producción, para mejorar continuamente la actividad empresarial. Al igual que DevOps, MLOps se basa en la automatización, la agilidad y la colaboración para mejorar la calidad. Si estás pensando en integración continua/entrega continua (CI/CD), no te equivocas. MLOps es compatible con CI/CD. Según Gartner, "MLOps pretende estandarizar la implementación y gestión de modelos de ML junto con la operacionalización de la canalización de ML. Admite el lanzamiento, la activación, el monitoreo, el seguimiento del rendimiento, la gestión, la reutilización, el mantenimiento y la gobernanza de los artefactos de ML".

MLOps en la empresa

Existen diferencias sustanciales entre una empresa emprendedora y una empresa incipiente. El experto en iniciativa empresarial Scott Shane escribió en The Illusions of Entrepreneurship (Yale University Press, 2010) que "sólo el 1% de las personas trabajan en empresas de menos de dos años, mientras que el 60% trabaja en empresas de más de diez años". La longevidad es una característica de la empresa emprendedora.

También afirma que "hacen falta 43 empresas de nueva creación para que, al cabo de diez años, sólo haya una empresa que emplee a alguien que no sea el fundador". En esencia, la empresa construye para la escala y la longevidad. En consecuencia, es esencial considerar tecnologías y servicios que apoyen estos atributos.

Nota

Las startups tienen ventajas tecnológicas para los usuarios, pero también tienen perfiles de riesgo diferentes para los inversores frente a los empleados. Los inversores de capital riesgo tienen una cartera de muchas empresas, lo que diversifica su riesgo. Según FundersClub, un fondo típico "contiene 135 millones" y está "repartido entre 30-85 startups". Mientras tanto, los empleados de las startups tienen su salario y su capital invertidos en una sola empresa.

Utilizando el valor esperado para generar el valor real del capital con una probabilidad de 1/43, una empresa que ofrece una bonificación anual de 50.000 devuelve 200.000 al cuarto año. Una startup produce 4.651,16 $ en el cuarto año. Para la mayoría de la gente, por término medio, las startups son una decisión arriesgada si se juzgan sólo desde el punto de vista financiero. Sin embargo, pueden ofrecer una excelente recompensa a través de una oportunidad acelerada de aprender nuevas tecnologías o habilidades, con la ligera posibilidad de una gran retribución.

Por otro lado, si la vida de una startup es dinámica, debe elegir soluciones tecnológicas muy diferentes a las de la empresa. Si hay un 2,3% de posibilidades de que una startup siga existiendo dentro de 10 años, ¿por qué preocuparse de la dependencia de un proveedor o de la implementación de múltiples nubes? Sólo las startups con problemas matemáticos construyen lo que aún no necesitan.

Del mismo modo, si eres una empresa rentable que busca consolidar su éxito actual, plantéate mirar más allá de las soluciones que utilizan las startups. Otras métricas como la capacidad de contratación, el soporte empresarial, la continuidad del negocio y el precio se convierten en indicadores clave de rendimiento (KPI) fundamentales.

Comprender el ROI en las soluciones empresariales

El atractivo de una solución "gratuita" es que obtienes algo a cambio de nada. En la práctica, rara vez es así. La Figura 1-1 presenta tres escenarios. En el primer escenario, la solución no cuesta nada pero no aporta nada, por lo que el ROI es cero. En el segundo escenario, está en juego un alto valor, pero el coste supera al valor, lo que da lugar a un ROI negativo. En el tercer escenario, un valor de un millón con un coste de medio millón proporciona medio millón de valor.

La mejor elección no es gratuita, sino que es la solución que ofrece el mayor ROI, ya que este ROI aumenta la velocidad de la empresa rentable. Ampliemos aún más el concepto de ROI profundizando en las soluciones a medida, que en cierto sentido también son "gratuitas", ya que un empleado construyó la solución.

Figura 1-1. Evaluación del ROI de las soluciones de plataformas tecnológicas

En la Figura 1-2, un ingeniero auténticamente brillante convence a la dirección para que le permita construir un sistema a medida que resuelva un problema concreto para la empresa Fortune 100. El ingeniero no sólo entrega rápidamente, sino que el sistema supera las expectativas. Sería tentador pensar que se trata de una historia de éxito, pero en realidad es una historia de fracaso. Un año después, el brillante ingeniero recibe una oferta de trabajo de una empresa de un billón de dólares y se marcha. Unos tres meses después, el sistema se rompe, y nadie es lo bastante inteligente para arreglarlo. La empresa sustituye a regañadientes todo el sistema y vuelve a formar a la empresa en el nuevo sistema propietario.

Figura 1-2. Dilema del sistema a medida

El coste final para la organización es la falta de impulso por utilizar un sistema superior durante un año, junto con el tiempo de formación necesario para cambiar del sistema antiguo al nuevo. Así, una solución "gratuita" con un ROI positivo puede tener un ROI negativo a largo plazo para una organización. Este escenario no es sólo hipotético; puede que lo hayas visto tú mismo.²

En Engañados por el azar: The Hidden Role of Chance in Life and the Markets (Random House, 2008), Nassim Taleb afirma que "no importa la frecuencia con la que algo tiene éxito si el fracaso es demasiado costoso de soportar". Esta afirmación se aplica directamente a una empresa de éxito que quiera implantar MLOps. Asumir el tipo adecuado de riesgo estratégico es de vital importancia. En la siguiente sección, tratamos el concepto de riesgo con más detalle.

Comprender el riesgo y la incertidumbre en la empresa

No todos los riesgos son iguales, al igual que no toda la incertidumbre es igual. A diferencia de una startup, una empresa ha llegado a la fase de supervivencia. Hay algunos riesgos que las empresas no necesitan asumir. En su libro sobre la empresa, Good to Great (De lo bueno a lo excelente, Harper Business, 2011), Jim Collins se pregunta: "¿Cómo piensan de forma diferente sobre la tecnología las organizaciones que pasan de lo bueno a lo excelente?". Descubrió que, en todos los casos, una empresa "de buena a excelente" encontró la sofisticación tecnológica y se convirtió en pionera en la aplicación de la tecnología. Además, Collins afirma que la tecnología es un acelerador, no un creador, de impulso.

Nota

Mark Spitznagel aboga por considerar la media geométrica en la inversión financiera en Safe Haven (Wiley, 2021). Afirma: "El beneficio es finito. El riesgo es infinito". El porcentaje de tu riqueza que puedes perder es más importante que el valor absoluto de la riqueza que podrías perder al invertir. Este hecho se adapta bien a la empresa. ¿Por qué asumir un riesgo con pérdidas ilimitadas?

El punto clave de Collins sobre la tecnología se aplica directamente a los MLOps en la empresa. El propósito del aprendizaje automático es acelerar el valor empresarial que ya existe. La razón para utilizar el aprendizaje automático no es convertir a la organización en investigadores de aprendizaje automático que compitan con empresas especializadas en investigación; es acelerar las ventajas estratégicas de la organización mediante la tecnología.

El riesgo calculado de adoptar el aprendizaje automático como acelerador empresarial es aceptable si se hace de forma que permita a una organización limitar los inconvenientes de la gestión del cambio tecnológico. Existe un riesgo esencialmente ilimitado en que una empresa cree soluciones y plataformas de aprendizaje automático a medida cuando su fuerza principal está en algún otro sector, como la fabricación, la hostelería o los servicios financieros.

Existen muchas opciones para acelerar el avance tecnológico en la empresa, incluido el uso de modelos preentrenados como Hugging Face o TensorFlow Hub, API de visión informática como AWS Rekognition, o soluciones AutoML de código abierto como Ludwig o marcos de orquestación de MLOps como MLRun. Las empresas que adoptan MLOps con un enfoque de uso del nivel adecuado de abstracción se dan a sí mismas una ventaja "de buena a buena" sobre las organizaciones que "contratan a 15 científicos de datos" que hacen "investigación". En este último ejemplo, suele ocurrir que tras años de investigación, en el mejor de los casos no se hace nada, pero en el peor, una solución pésima crea un resultado peor que no hacer nada.

El economista Frank Knight articula claramente la diferencia entre riesgo e incertidumbre: la recompensa por asumir un riesgo conocido es muy distinta de la de un riesgo inconmensurable e imposible de calcular. Esta forma de riesgo, denominada incertidumbre knightiana, debe su nombre a Knight. Una empresa que se dedique al aprendizaje automático debe considerar en profundidad qué riesgo está asumiendo: ¿un riesgo normal que se puede conocer, o se está embarcando en un camino con incertidumbre knightiana? En casi todos los casos, es mejor asumir riesgos conocibles en el aprendizaje automático y la IA, ya que la tecnología no es la creadora del crecimiento, sino el acelerador.

Sabiendo que la aceleración es la visión crucial de las grandes empresas que utilizan la tecnología, veamos algunas de las diferencias en la aceleración tecnológica entre MLOps y DevOps.

MLOps frente a DevOps

Sin DevOps, no puedes hacer MLOps. DevOps es un componente básico para hacer MLOps, y no hay sustituto. DevOps es una metodología para lanzar software de forma ágil, mejorando constantemente la calidad tanto de los resultados empresariales como del propio software. Un profesional de DevOps de alto nivel tiene mucho en común con un chef gourmet. El chef tiene un profundo conocimiento de los ingredientes y años de experiencia práctica creando comidas hermosas y deliciosas, y puede hacer estas comidas de forma industrializada y repetible. La repetición permite a un restaurante permanecer abierto y obtener beneficios.

Del mismo modo, con DevOps, un experto en la materia tiene conocimientos detallados sobre cómo crear software y desplegarlo de forma repetible y de alta calidad. Uno de los mayores retos para los expertos en ciencia de datos en la transición a MLOps es la falta de experiencia en DevOps. No hay sustituto para la experiencia; muchos profesionales de la ciencia de datos e investigadores del aprendizaje automático deberían adquirir experiencia construyendo e implementando software con la metodología DevOps para obtener los conocimientos básicos y la experiencia necesarios para ser un experto en MLOps.

Nota

Puedes aprender más sobre DevOps en Python for DevOps (O'Reilly), de Noah Gift, Kennedy Behrman, Alfredo Deza y Grig Gheorghiu.

Sin embargo, existen diferencias evidentes entre el DevOps tradicional y el MLOps. Una diferencia clara es el concepto de deriva de datos; cuando un modelo se entrena con datos, puede perder utilidad gradualmente a medida que cambian los datos subyacentes. Un tremendo ejemplo teórico de este concepto proviene de Nassim Taleb en Fooled by Randomness (Random House, 2021), donde describe cómo un "niño travieso", como se muestra en la Figura 1-3, podría perturbar la comprensión de la distribución subyacente de bolas rojas frente a negras en un contenedor.

Figura 1-3. Problema de deriva de datos del "niño travieso".

En una condición estática, cuantas más bolas se saquen de un recipiente, más segura puede estar una persona de la distribución subyacente de bolas rojas frente a negras. En una condición dinámica, si las bolas cambian constantemente, entonces un modelo entrenado en una versión de datos más antigua no será preciso. Este ejemplo capta uno de los muchos elementos únicos específicos de MLOps que no se encuentran en DevOps.

La conclusión es que DevOps es una base necesaria para MLOps, pero los requisitos adicionales de MLOps, como la deriva de datos, no aparecen en DevOps tradicional.

Nota

Microsoft señala: "La desviación de los datos es una de las principales razones por las que la precisión de los modelos se degrada con el tiempo".

¿Qué no es MLOps?

Una forma de entender mejor los MLOps es definir lo que no son. He aquí algunos antipatrones comunes de MLOps:

Contratar un equipo de científicos de datos y esperar lo mejor

Quizá el más común de los antipatrones de los MLOps sea contratar a un equipo de científicos de datos y esperar que aparezca una solución excelente. Sin un apoyo organizativo que comprenda los MLOps y una infraestructura tecnológica que los respalde, no habrá un resultado ideal.

Construir sólo soluciones de aprendizaje automático a medida

Un problema fundamental de construir sólo soluciones a medida es que pueden no ser necesarias para los objetivos empresariales de una organización. Entrenar un modelo de aprendizaje automático a medida con datos propios para una empresa de conducción autónoma es esencial para obtener una ventaja competitiva. Entrenar un modelo similar para una empresa de reparto de Fortune 500 podría ser un experimento costoso que no aportara ningún valor real al negocio.

Desestimar la importancia de DevOps

Los equipos que trabajan en silos no están siguiendo las buenas prácticas de DevOps. Por ejemplo, no es práctico tener un equipo de ciencia de datos en Texas que construya modelos en R y luego se los pase al equipo de DevOps del distrito financiero de San Francisco para que los introduzca en la pila de software en Python.

En última instancia, MLOps requiere una mentalidad que dé prioridad al negocio y a la producción. El objetivo del aprendizaje automático es acelerar el valor empresarial. Esto significa que los equipos que construyen soluciones deben ser ágiles en su enfoque para resolver los problemas del aprendizaje automático.

Definiciones dominantes de MLOps

Un reto en tecnología es separar la estrategia de marketing de la estrategia tecnológica. En el caso de MLOps, no se trata de una estrategia de marketing, sino de una solución específica a un grave problema de la empresa. La cuestión es que los modelos no llegan a la producción; si lo hacen, son frágiles y se desmoronan cuando se enfrentan a las complejidades del mundo real. Varias encuestas muestran que entre el 50 y el 70% de las organizaciones no han conseguido poner en producción pilotos o modelos de IA.

Una vez identificada la enfermedad, busquemos la cura. La cura debe abordar las siguientes cuestiones clave (entre otras):

• Tiempo de implementación y desarrollo del modelo

• Colaboración entre diferentes equipos

• Excelencia operativa de los sistemas de ML

• Gobernanza de datos

• Aumento del ROI de la empresa que implementa el modelo

Una forma minimalista de definir MLOps es que apoya el desarrollo del ML como DevOps apoya el desarrollo del software.

¿Qué es la ingeniería ML?

Una forma de definir la ingeniería de ML es fijarse en las certificaciones populares. El Ingeniero Profesional de Aprendizaje Automático de Google explica los siguientes criterios para un ingeniero profesional de ML:

Problemas del marco ML

El modelo a elegir depende de las limitaciones de la empresa y del contexto. Por ejemplo, una empresa puede decidir clasificar las cajas enviadas dañadas frente a los paquetes entregados con éxito. En ese contexto, un modelo de clasificación sería más apropiado que un modelo de regresión.

Arquitecto de soluciones ML

Un ingeniero de ML desarrolla una solución para resolver el problema correctamente planteado utilizando el aprendizaje automático junto con otros miembros del equipo.

Diseñar sistemas de preparación y tratamiento de datos

Dos pasos fundamentales en la preparación y el tratamiento de los datos son la construcción del conjunto de datos y su posterior transformación.

Desarrollar modelos ML

En el proceso de modelado detallado interviene un equipo o una persona que crea un modelo correctamente adaptado al encuadre inicial del modelo.

Automatizar y orquestar canalizaciones ML

Un pipeline sirve para crear un proceso de LD reproducible y mantenible.

Monitorizar, optimizar y mantener

Es mejor ser proactivo que reactivo en la construcción de sistemas complejos. El monitoreo de edificios permite un enfoque proactivo del mantenimiento de los sistemas de ML.

El objetivo de la ingeniería de ML es crear modelos de ML de alta calidad que resuelvan problemas empresariales específicos y, al mismo tiempo, generen retorno de la inversión.

Nota

Varios libros de O'Reilly tratan de la ingeniería del aprendizaje automático, como Data Science on the Google Cloud Platform, Machine Learning Design Patterns y Practical MLOps.

MLOps e Incentivos Empresariales

Un problema clásico en la escuela de negocios es el de los incentivos, descrito a menudo como "¿quién movió el queso?". Este escenario se refiere a una rata en un laberinto que se mueve dependiendo de dónde esté el queso. Del mismo modo, hay dos incentivos comunes que merece la pena discutir en MLOps: las externalidades negativas y la contratación de científicos de datos sin tener en cuenta el ROI:

Externalidades negativas

Las externalidades negativas, como una empresa que obtiene beneficios vertiendo residuos tóxicos en un río en lugar de la eliminación adecuada, más cara, son ejemplos clásicos de los problemas fundamentales del capitalismo. En el aprendizaje automático, las externalidades negativas podrían ser algoritmos sesgados que envían a un inocente a la cárcel o deniegan un crédito a una persona por motivos de raza, religión, origen nacional y otras categorías. Incluso un sesgo creado involuntariamente en un modelo sigue siendo ilegal (por ejemplo, denegar un crédito basándose en la edad). Las empresas que no miran hacia el futuro podrían exponerse a un riesgo existencial si el sesgo del sistema contra las solicitudes de personas mayores, por ejemplo, se introdujera accidentalmente en un modelo de aprendizaje automático.

Contratar científicos de datos sin tener en cuenta el ROI

Últimamente se ha puesto de moda contratar a científicos de datos sin tener en cuenta el problema que están resolviendo. Como ya hemos comentado, esta estrategia en última instancia no funciona porque los modelos no están en producción en la mayoría de las organizaciones que hacen IA y ML.

MLOps en la nube

La metodología MLOps aprovecha varias ventajas críticas de la computación en nube. En primer lugar, la nube es un recurso elástico que permite tanto el uso eficiente de la computación y el almacenamiento como la capacidad de escalar para satisfacer casi cualquier demanda. Esta capacidad significa que la computación en nube tiene acceso bajo demanda a recursos esencialmente infinitos.

En segundo lugar, la nube tiene un efecto de red en el sentido de que las tecnologías en la nube se benefician de la integración de otras tecnologías en la nube. Un gran ejemplo es AWS Lambda, una tecnología sin servidor. AWS Lambda es un servicio valioso para crear aplicaciones, no por lo que hace por sí solo, sino por la profunda integración con otros servicios de AWS como AWS Step Functions, Amazon SageMaker o AWS S3. Para cualquier plataforma activa en la nube, puedes suponer que la red integrada de servicios refuerza aún más sus capacidades a medida que la plataforma desarrolla más funciones.

En tercer lugar, todos los proveedores de la nube tienen plataformas de MLOps. AWS tiene SageMaker, Azure tiene Azure Machine Learning, y Google tiene Vertex AI. Incluso nubes nicho más pequeñas, como Alibaba Cloud, tienen su Plataforma de Aprendizaje Automático para IA. Al utilizar una plataforma en la nube, una organización probablemente utilizará algunas de las ofertas de la plataforma nativa de ML y potencialmente la aumentará con soluciones personalizadas y de terceros.

En cuarto lugar, todos los proveedores de la nube tienen Entornos de Desarrollo en la Nube. Una tendencia significativa es el uso de una combinación de entornos CloudShell ligeros, como AWS CloudShell, opciones más pesadas de entornos de desarrollo interactivo (IDE) completos, como AWS Cloud9, y entornos de bloc de notas, tanto gratuitos, como SageMaker Studio Lab o Google Colab, como aquellos con una rica integración IDE, como SageMaker Studio.

Por último, dependiendo de lo que haga una empresa, puede que no tenga otra opción que utilizar la computación en nube. Algunos componentes de la computación en nube son un requisito indispensable para las organizaciones especializadas en crear soluciones de aprendizaje profundo a medida, porque el aprendizaje profundo requiere amplias capacidades de almacenamiento y computación.

Además de los proveedores de la nube pública, otros actores ofrecen soluciones MLOps en la nube (véase más adelante en esta sección). Estos proveedores pueden operar en la nube pública o en nubes privadas. La ventaja de recurrir a un proveedor más pequeño es el nivel de personalización que ofrece a sus clientes. Además, un proveedor de MLOps tendrá una experiencia más profunda en MLOps, ya que ese es su único objetivo. Los proveedores integrados suelen garantizar funciones más relevantes y muchas más integraciones. Por último, al elegir un proveedor agnóstico de un proveedor de nube concreto, tú, como cliente, tampoco estás vinculado a él. En su lugar, puedes utilizar el proveedor en varias nubes o en la infraestructura adicional que puedas tener (véase más adelante en esta sección).

Nota

Un recurso útil para el análisis de proveedores de aprendizaje automático es la AI Infrastructure Alliance (AIIA). Esta organización proporciona a los científicos e ingenieros de datos claridad e información sobre las herramientas de IA/ML para construir plataformas empresariales robustas, escalables y de extremo a extremo. Un recurso es un panorama completo de MLOps que traza un mapa de todos los actores del sector. Este documento incluye un panorama actualizado de MLOps que trazará un mapa de las soluciones empresariales y de código abierto para MLOps. El nuevo panorama abarcará múltiples categorías y cientos de empresas, al tiempo que detallará las capacidades de cada solución de proveedor.

En la Figura 1-4, observa un patrón típico entre todas las nubes en el que hay un conjunto de entornos de desarrollo en la nube, sistemas de almacenamiento flexibles, sistemas de computación elástica, servicios gestionados sin servidor y en contenedores, e integración de proveedores externos.

Figura 1-4. Panorama de los MLOps en la nube

Aquí tienes más detalles sobre estas categorías:

Entornos de desarrollo en la nube

Por lo general, las herramientas centradas en el desarrollador, como los shells en la nube y los IDE, están en un extremo, y las herramientas centradas en el aprendizaje automático, en el otro. Las herramientas de consulta de almacenamiento como Google BigQuery, Amazon Athena o Azure Databricks Integration están en el medio.

Plataformas MLOps que funcionan en la nube

Las plataformas MLOps están construidas específicamente para ejecutar MLOps para empresas en la nube o en cualquier entorno. Soluciones como Iguazio, Valohai, DataRobot, Azure Databricks y Outerbounds, y muchas otras, ofrecen una amplia variedad de soluciones MLOps para la empresa.

Sistemas de almacenamiento elástico y sistemas informáticos elásticos

Los sistemas de aprendizaje profundo prosperan con los grandes datos y las capacidades de cálculo flexibles de las GPU, las CPU y los circuitos integrados específicos de la aplicación (ASIC) del Acelerador de IA, como las Unidades de Procesamiento Tensorial (TPU). Como resultado, las plataformas MLOps, tanto nativas como de terceros, utilizan en gran medida esta capacidad elástica para proporcionar soluciones gestionadas.

Servicios gestionados sin servidor y en contenedores

Las plataformas en la nube evolucionan hacia más soluciones sin servidor, como AWS Lambda o las funciones de Google Cloud, y haciasoluciones con contenedores totalmente gestionadas, como Google Cloud Run o AWS Fargate. Estos servicios gestionados, a su vez, tienen una profunda integración en la plataforma, lo que mejora la propuesta de valor de la plataforma en la nube a través de un efecto de red.

Integraciones con otros proveedores

Una plataforma en la nube no puede tener la mezcla exacta de todo y con la calidad adecuada. Una visita a un gran almacén ofrece una gran variedad de productos a un precio razonable. Sin embargo, puede que no tengan la auténtica comida gourmet que te gusta o las características exactas de los electrodomésticos que necesitas. Al igual que ese gran almacén, un proveedor en la nube no puede profundizar en todo. Por eso, las integraciones de terceros se encargan de estos casos de uso especializados o avanzados.

Una vez cubiertos los aspectos comunes de la computación en nube para los MLOP, pasemos a hablar con más detalle de los entornos en nube.

Entornos clave de desarrollo en la nube

Una de las mejores novedades de Microsoft es GitHub Codespaces, un entorno de desarrollo basado en la nube con muchas funciones personalizables y un lugar estupendo para practicar MLOps. En particular, lo útil de este entorno es la profunda integración con GitHub y la posibilidad de personalizarlo con un tiempo de ejecución especializado. Por último, la sinergia con GitHub Actions permite una gran historia de CI/CD.

Nota

Aprende más sobre GitHub Codespaces con los siguientes vídeos:

• "Construir con el Ecosistema GitHub: Copiloto, Codespaces y Acciones de GitHub"

• "Espacios de código GitHub y archivos de puntos personalizados"

• "Compilar Python desde cero con GitHub Codespaces"

• "GitHub Copilot Driven: Python DevOps de Funciones a Entrega Continua de Microservicios en AWS"

• "Curso GitHub Codespaces"

Google dispone de tres sabores diferentes de desarrollos basados en la nube: Cuadernos Colab, Google Cloud Shell y Google Cloud Shell Editor.

La Figura 1-5 muestra un editor completo disponible para Google Cloud Platform (GCP).

Figura 1-5. Editor de Google Cloud Shell

En la Figura 1-6, los documentos de la API se integran con el entorno de desarrollo.

Figura 1-6. API del editor de Google Cloud Shell

En la Figura 1-7, el terminal muestra una vista estándar de la experiencia utilizando el shell de la nube.

Figura 1-7. Terminal de Google Cloud Shell

Nota

Aprende más sobre los cuadernos Colab en los siguientes vídeos:

• "Ciencia de datos en tu primer día con Python"

• "Python para la ciencia de datos con Colab y pandas en un videocurso de una hora"

• "¿Qué son los cuadernos Google Colab y cómo compartirlos para proyectos de ciencia de datos?"

Por último, la plataforma AWS dispone de entornos shell en la nube, como se muestra en la Figura 1-8.

Nota

Una forma rápida de aprender sobre múltiples nubes simultáneamente es configurando una integración continua multicloud. Puedes aprender a configurarlo con el vídeo "GitHub Actions Hello World All Cloud and Codespaces".

Figura 1-8. Terminal de AWS Cloud Shell

Todo esto nos lleva al concepto de la ventaja del espacio de trabajo del desarrollador en la nube, como se muestra en la Figura 1-9. Un ordenador portátil o una estación de trabajo son caros y no deterministas debido al software preinstalado y, por definición, no son el objetivo de la implementación. Un espacio de trabajo en la nube tiene muchas ventajas increíbles, como la potencia, la disponibilidad, la precarga y la profunda integración con herramientas avanzadas.

Figura 1-9. Ventajas del espacio de trabajo del desarrollador en la nube

Nota

Puedes obtener más información sobre la ventaja del espacio de trabajo para desarrolladores en la nube en el vídeo"52 semanas de AWS-La serie completa" o en YouTube.

Los actores clave de la computación en nube

¿Conoces a alguien que quiera ganar 200.000 $ o más al año? Según la Encuesta sobre Salarios en la Nube 2022 de Mike Loukides (O'Reilly), el salario medio de los profesionales certificados en AWS, Azure y GCP supera los 200.000 dólares.

Los datos de Statista corroboran esta afirmación, como se muestra en la Figura 1-10. En el segundo trimestre de 2022, había tres actores clave en el mercado mundial. AWS tenía cerca del 33% de la cuota de mercado, Azure cerca del 21% y Google Cloud cerca del 10%. Combinados, estos tres proveedores controlaban dos tercios de un mercado que genera casi 200.000 millones de dólares en ingresos. Los ingresos por servicios aumentaron un 37% respecto al año pasado.

Figura 1-10. Mercado de la computación en nube

Una estrategia razonable para una organización que desee utilizar la computación en nube es utilizar la plataforma de los mayores proveedores. El efecto Matthew³ que dice "los ricos se hacen más ricos y los pobres más pobres", se aplica a la computación en nube por varias razones:

Empleados y proveedores disponibles para contratar

Aprovechar las plataformas en la nube más destacadas hace más accesible la contratación de empleados y la búsqueda de proveedores que trabajen con la plataforma.

Material de formación disponible

La disponibilidad de material de formación para las plataformas más destacadas facilita la formación de los empleados.

Servicios disponibles

Las plataformas más grandes pueden contratar a más ingenieros de software y jefes de producto, lo que significa que puedes contar con una continuidad de nuevas funciones y mantenimiento en su plataforma.

Coste del servicio

Los proveedores más importantes son los que más se benefician de las economías de escala. Pueden aprovechar las ventajas de los precios comprando al por mayor y trasladándolas luego al cliente.

Nota

Puedes estudiar para las certificaciones de la nube de AWS viendo el "Curso profesional de arquitecto de soluciones de AWS" y el "Curso en vídeo de profesional de la nube certificado por AWS" de Noah Gift.

Ahora que ya conoces a los principales proveedores de computación en nube, vamos a hablar de cómo ve cada proveedor el mundo de la computación en nube en relación con los MLOps.

La visión de AWS de la computación en nube en relación con MLOps

El mejor lugar para obtener un resumen de alto nivel de la computación en nube de AWS es el documento Overview of Amazon Web Services AWS Whitepaper. En concreto, mencionan seis ventajas de la computación en nube:

Cambia gasto fijo por gasto variable

Evitar grandes gastos de capital fomenta la agilidad y la eficacia.

Benefíciate de enormes economías de escala

A medida que bajan los precios para el proveedor, bajan para el cliente, lo que permite fijar precios más bajos que si el cliente comprara el mismo producto. Del mismo modo, los servicios gestionados en la plataforma tendrán un calendario constante de nuevas funciones.

Deja de adivinar la capacidad

No es necesario preaprovisionar recursos, ya que los sistemas se construyen con una capacidad elástica para escalar según sea necesario.

Aumenta la velocidad y la agilidad

Centrarse en la ventaja comparativa de una organización y no construir TI no esenciales para el negocio permite a una organización avanzar más rápido.

Deja de gastar dinero dirigiendo y manteniendo centros de datos

El ahorro de costes se acumula con la externalización de este componente de TI.

Globalízate en minutos

Globalizarse es un problema muy difícil que desaparece con AWS gracias a sus ofertas integrales.

Nota

Puedes obtener más información sobre AWS en Developing on AWS with C# (O'Reilly), de Noah Gift y James Charlesworth.

Estas características se integran en última instancia en la oferta principal de MLOps de Amazon SageMaker en la Figura 1-11, ya que el ciclo de vida del proyecto va desde la preparación a la construcción, pasando por la formación y, finalmente, la implementación y administración de la solución. En el centro del flujo de trabajo está la estrecha integración con las herramientas para desarrolladores de Studio y RStudio.

Figura 1-11. Flujo de trabajo de Amazon SageMaker MLOps

Nota

En el vídeo "Amazon SageMaker Studio Labs: Primeras impresiones", puedes ver un recorrido completo de SageMaker Studio Lab.

Una vez completada la visión AWS de los MLOps, veamos a continuación Azure.

Visión Azure de la computación en nube en relación con MLOps

Microsoft Azure ve el mundo de los MLOps como una forma de "escalar eficientemente desde una prueba de concepto o proyecto piloto a una carga de trabajo de aprendizaje automático en producción". Como se muestra en la Figura 1-12, el ciclo de vida del modelo incluye formación, empaquetado, validación, implementación, monitoreo y reentrenamiento.

Figura 1-12. Azure MLOps

A continuación, veamos cómo ve Google los MLOP.

La visión de GCP de la computación en nube en relación con MLOps

Un lugar ideal para observar cómo ve Google el mundo es echando un vistazo al curso intensivo de Producción de Sistemas ML. Uno de los puntos que señala la empresa es lo diminuta que es la parte de modelado del problema, como se muestra en la Figura 1-13. En cambio, la combinación de otras tareas, como la recopilación de datos, la infraestructura de servicio y el monitoreo, ocupan mucho más espacio del problema.

Figura 1-13. Vista de Google de MLOps

En última instancia, esto nos lleva al modo en que la plataforma Vertex AI de Google gestiona el flujo de trabajo de MLOps, que se muestra en la Figura 1-14. Se produce el proceso de desarrollo de ML, incluido el encuadre del modelo para el problema empresarial. La fase de procesamiento de datos conduce a un proceso de entrenamiento operacionalizado que puede ampliarse según sea necesario. A continuación, se produce la implementación del modelo, junto con la orquestación del flujo de trabajo y la organización de los artefactos. El modelo incluye el monitoreo en el proceso de implementación.

Figura 1-14. Vista de Google de MLOps

Aunque los proveedores de nubes públicas ofrecen sus propias soluciones, a veces las empresas pueden necesitar una solución más adaptada a sus necesidades específicas. Veamos otras dos opciones de implementación: la implementación en las instalaciones y la implementación en la nube híbrida.

MLOps On-Premises

En algunos casos de uso, las empresas no pueden utilizar la nube pública. Las restricciones empresariales, como la necesidad de proteger datos sensibles o tener que cumplir normativas estrictas (por ejemplo, normativas de privacidad sobre localización de datos), exigen una solución MLOps que pueda funcionar in situ. Muchas soluciones MLOps ofrecen la posibilidad de implementarlas en la nube o en las instalaciones. El único inconveniente de este enfoque es que las soluciones locales exigen que la empresa proporcione los servidores y equipos que soporten la intensa potencia informática necesaria para ejecutar algoritmos de ML a escala. También tendrán que actualizar y mantener la infraestructura.

Por otra parte, una implementación in situ requerirá casi con toda seguridad algún tipo de personalización. Esta instalación da a las empresas más control sobre el producto, y pueden hacer peticiones específicas para adaptarlo a sus necesidades. Más concretamente, si la solución desplegada es de una startup, estarán atentos y trabajarán duro para garantizar la satisfacción y la adopción. Si es un producto de código abierto, las empresas no sólo pueden aprovechar el poder de desarrollo de la comunidad, sino también entrar con sus propios desarrolladores y juguetear con el producto para asegurarse de que se adapta a sus necesidades.

MLOps en entornos híbridos

Al igual que ocurre con la implementación local, algunas empresas pueden preferir una implementación en la nube híbrida. Esto implica la implementación en la(s) nube(es) pública(s), en las instalaciones, y quizás incluso en una nube privada o en dispositivos de perímetro. Naturalmente, esto hace que las cosas sean mucho más complejas, ya que la solución MLOps debe permitir la separación total de la ruta de datos de la ruta de control y debe ser suministrada por una entidad altamente disponible y escalable que orqueste, rastree y gestione las canalizaciones de ML a través de tipos de implementaciones de infraestructura. Para que no lo olvidemos, esto tiene que ocurrir a alta velocidad y con un rendimiento óptimo. Por último, lo ideal es que la solución proporcione una única pila de desarrollo e implementación para los ingenieros en todos los tipos de infraestructura.

Encontrar un proveedor o una solución de código abierto que cumpla todos estos requisitos puede no ser sencillo, pero como ya se ha dicho, tu mejor apuesta son las startups o las soluciones OSS maduras que puedan personalizarse según las necesidades específicas de tu infraestructura.

Estrategia empresarial de MLOps

Una vez completada una visión general de alto nivel de las cuestiones críticas implicadas en los MLOps, es hora de pasar a la estrategia, como se muestra en la Figura 1-15. Hay cuatro categorías clave a tener en cuenta al implantar una estrategia de MLOps: la nube, la formación y el talento, el proveedor y el enfoque ejecutivo en el ROI.

Figura 1-15. Estrategia empresarial MLOps

Analicemos cada una de estas cuatro categorías:

Nube

No hay una respuesta perfecta sobre qué plataforma en la nube utilizar. Cualquier plataforma central ofrecerá las ventajas de las economías de escala. Lo que es esencial en una estrategia de MLOps es ser consciente de cómo encaja una plataforma en la nube en los objetivos únicos de cada organización y cómo se alinea con otros componentes estratégicos como la contratación o la integración de proveedores externos.

Formación y talento

A menudo, las organizaciones se fijan sólo en la potencia de la nueva tecnología y no tienen en cuenta el componente de formación y talento que conlleva su uso. En casi todos los casos, una organización debe utilizar una tecnología menos potente si la contratación y la formación son mejores con una solución menos potente. Este hecho significa que la difusión de la tecnología es crucial a la hora de implantar una nueva tecnología. En última instancia, la última tecnología está muerta a su llegada si no puedes contratar o formar a tu personal.

Vendedor

Una cuestión que a menudo se pasa por alto en el uso de la computación en nube es que suele ser necesario complementarla con proveedores especializados que ayuden a una organización a alcanzar sus objetivos con la tecnología. Estas elecciones estratégicas pueden conducir a un mejor retorno de la inversión tanto para la nube como para las estrategias empresariales. Algunos ejemplos son el uso de tecnología de proveedores especializados en Hadoop, Kubernetes o modelos preformados. Los proveedores serán únicos para cada organización y sus objetivos empresariales.

Nota

En "Enterprise MLOps Interviews", el director general de Outerbounds y autor de Metaflow, Ville Tuulos, menciona que, aunque todas las empresas utilizan la capa base de la nube, por ejemplo el almacenamiento y las bases de datos, a menudo necesitan aumentar con proveedores las capas superiores.

Enfoque ejecutivo en el ROI

En última instancia, las tres categorías anteriores no significan nada si el enfoque ejecutivo no se centra en el ROI. El propósito de la tecnología es impulsar el valor empresarial a largo plazo, lo que significa que los problemas necesitan un alcance preciso.

Conclusión

Este capítulo sienta las bases para comprender la crisis de las empresas que ponen en producción el aprendizaje automático y la IA. Desde un enfoque de sentido común, la idea de "contratar simplemente a más científicos de datos" para aumentar el ROI es tan sensata como "contratar simplemente a más ingenieros de software" para que un proyecto de software tradicional vaya más rápido. En el caso de la empresa de software convencional, si no hay producto, objetivo ni supervisión, contratar a más desarrolladores aumenta el gasto de capital de la organización sin ningún valor añadido.

En lugar de este escenario, MLOps pretende añadir una metodología que se base en las lecciones exitosas de DevOps, a la vez que maneja las características únicas del aprendizaje automático. Por último, a nivel empresarial, en última instancia la ciencia de datos se reduce al ROI. La tecnología es un acelerador del valor para la mayoría de las organizaciones, no el valor. Las organizaciones que crean hambre de ROI pueden adoptar rápidamente la mentalidad MLOps.

Preguntas de debate sobre el pensamiento crítico

• Hay muchos métodos para implementar modelos de aprendizaje automático en la producción, como los modelos preentrenados, las API, AutoML y el entrenamiento a medida. ¿Cuáles son los pros y los contras de cada uno de estos enfoques?

• ¿Qué estrategias podría aplicar una empresa para atraer nuevos talentos de ingeniería de aprendizaje automático y formar y reciclar a los actuales?

• Si tu organización no realiza actualmente ningún DevOps, un componente fundacional necesario para los MLOps, ¿cómo podrían iniciar un primer proyecto DevOps para probar conceptos como CI/CD e infraestructura como código (IaC)?

• Si tu organización no dispone de grandes cantidades de datos propios, ¿cómo puede utilizar de todos modos el aprendizaje automático para obtener una ventaja competitiva?

• ¿Cuál es la estrategia de nube de tu organización: nube única, nube múltiple, nube híbrida, nube privada u otra? ¿Cómo ayuda esto a tu organización a alcanzar sus objetivos de MLOps?

Ejercicios

• Ve a un sitio popular de alojamiento de modelos, como TensorFlow Hub o Hugging Face, e implementa uno de sus modelos en tu plataforma en la nube favorita.

• Elige un entorno de desarrollo basado en la nube como GitHub Codespaces, Amazon SageMaker Studio Lab o Google Colab y explora la interfaz con vistas a construir un proyecto de ingeniería de aprendizaje automático.

• Utiliza un marco de aplicaciones de aprendizaje automático como Gradio o Streamlit para crear una aplicación sencilla de aprendizaje automático.

• Haz una lluvia de ideas sobre varios problemas organizativos que podrían beneficiarse del uso del aprendizaje automático y construye un prototipo sencillo utilizando una tecnología MLOps.

• Convierte un proyecto Kaggle en un proyecto MLOps descargando el conjunto de datos y codificando una tecnología MLOps para servir predicciones.

¹ El Dr. Luks resume la estrategia sistemática basada en la evidencia: "Crea un déficit calórico y mantente delgado. Duerme. Come comida de verdad. Muévete a menudo, durante todo el día. Empuja y tira de cosas pesadas. Socializa. Ten un sentido del propósito".

² En Principios de Macroeconomía (McGraw Hill, 2009), Ben S. Bernanke comparte la historia de cómo un chef con talento podría extraer todo el beneficio de los restaurantes en un escenario de competencia perfecta, ya que se marcharían continuamente por un salario más alto en un restaurante de la competencia, eliminando en última instancia todo el beneficio para el propietario.

³ Los sociólogos Robert K. Merton y Harriet Zuckerman acuñaron por primera vez este término.