MLOps para empresas: del modelo piloto a producción

MLOps para empresas: del modelo piloto a producción

MLOps es el conjunto de prácticas que permite sacar un modelo de aprendizaje automático del cuaderno de un científico de datos y mantenerlo fiable cuando interactúa con usuarios y datos reales. En una empresa, implica disponer de datos y modelos versionados, canalizaciones automatizadas, lanzamientos controlados, supervisión y una asignación clara de responsabilidades. AWS lo describe como un conjunto de prácticas que automatizan y simplifican los flujos de trabajo y las implementaciones de ML, unificando el desarrollo de ML con la implementación y las operaciones de los sistemas de ML.

A la mayoría de las empresas no les cuesta crear un modelo prometedor. Lo difícil es ponerlo en producción, supervisarlo, volver a entrenarlo y explicarlo a los auditores. Esta guía aborda cómo es un ciclo de vida de ML en producción, cómo evaluar su nivel de madurez, qué prácticas son más importantes y cómo elegir un enfoque sin adquirir más plataforma de la que necesita.

Conclusiones principales

• MLOps aplica la disciplina de la ingeniería de software al ML, pero también debe gestionar los cambios en los datos y en los modelos, no solo los cambios en el código.
• Considere la madurez como una escalera. La mayoría de los equipos obtiene más beneficios de automatizar primero el entrenamiento y la implementación que de adoptar una plataforma completa desde el primer día.
• La seguridad, los registros de auditoría y los planes de reversión deben formar parte de la canalización desde el principio, no de una revisión al final.
• Elija las herramientas según su tipo (código abierto, nube gestionada o híbridas) y teniendo en cuenta la nube que ya utiliza, las competencias del equipo y sus necesidades de cumplimiento normativo.
• Empiece con un modelo importante para el negocio, haga que su recorrido hasta producción sea repetible y, después, reutilice ese recorrido.

Índice

• Qué significa MLOps para una empresa
• El ciclo de vida del ML en producción, paso a paso
• ¿En qué punto se encuentra? Evaluación de la madurez de MLOps
• Prácticas recomendadas de MLOps que funcionan en producción
• Comparación de los enfoques de las plataformas de MLOps
• Cómo elegir un enfoque adecuado para su empresa
• El argumento empresarial para hacerlo bien
• Cómo podemos ayudarle
• Preguntas frecuentes
• Fuentes

Qué significa MLOps para una empresa

Un servicio web convencional debe ser resiliente y soportar la carga. Un modelo se enfrenta a esos problemas y a otros adicionales. La Guía para profesionales sobre MLOps de Google señala que implementar un modelo también implica preocuparse por los cambios en los datos, los cambios en el modelo y los usuarios que intentan manipular el sistema en su beneficio. El código que no ha cambiado puede seguir generando predicciones peores el próximo trimestre porque el mundo ha cambiado.

Por eso, una canalización de DevOps estándar es necesaria, pero no suficiente. La misma guía enumera los beneficios de estandarizar el proceso: ciclos de desarrollo más cortos, mejor colaboración, mayor fiabilidad y seguridad, una gobernanza más ágil y un mejor rendimiento de la inversión en proyectos de ML.

A escala empresarial, aparecen rápidamente tres presiones:

• Muchos modelos y muchos equipos. Sin estándares compartidos, cada equipo crea su propia ruta de implementación y nadie puede responder qué versión del modelo está en ejecución y dónde.
• Datos regulados o sensibles. Alguien debe demostrar de dónde proceden los datos de entrenamiento y quién aprobó un lanzamiento.
• Responsabilidad operativa. Un modelo que se degrada silenciosamente es un problema empresarial, no un problema de ciencia de datos. Alguien de guardia debe asumir la responsabilidad.

MIT Technology Review MIT Technology Review presenta el valor fundamental como la automatización de los pasos repetibles, desde el desarrollo y la formación hasta la implementación y la operación, lo que reduce el riesgo y libera a los desarrolladores del trabajo rutinario. El mismo artículo cita un estudio de McKinsey de 2021 según el cual las empresas que logran ampliar la IA con éxito pueden añadir hasta un 20 por ciento a sus beneficios antes de intereses e impuestos.

El ciclo de vida del aprendizaje automático en producción, paso a paso

Todos los principales proveedores de servicios en la nube publican una arquitectura de referencia, y todas convergen en la misma estructura. La arquitectura de MLOps v2 de Microsoft avanza desde el patrimonio de datos y la administración, pasando por el desarrollo de modelos y los registros, hasta la preparación y las pruebas, la implementación en producción y la supervisión. Los activadores pueden volver a entrenar un modelo y devolverlo a la preparación o al desarrollo.

La guía de Google Cloud sobre entrega continua y automatización divide el trabajo en seis etapas. Son las siguientes, en términos sencillos:

1. Desarrollo y experimentación. Los científicos de datos prueban características, algoritmos y parámetros. El resultado es el código fuente de la canalización, no solo un cuaderno.
2. Integración continua de la canalización. Los cambios en el código de la canalización se compilan y prueban automáticamente.
3. Entrega continua de la canalización. La propia canalización se implementa en el entorno de destino.
4. Activación automatizada. El entrenamiento se ejecuta según un calendario, cuando hay datos nuevos o ante una señal de rendimiento.
5. Entrega continua del modelo. El modelo entrenado se ofrece como un servicio de predicción.
6. Supervisión. Las estadísticas en tiempo real sobre el rendimiento del modelo se incorporan al siguiente ciclo.

Un marco académico sobre la gestión del ciclo de vida de los modelos empresariales añade un punto útil: el aprendizaje automático en producción es iterativo y está impulsado por eventos, en lugar de ser secuencial y terminal. El último paso no es «implementar». Es supervisar, aprender, volver a entrenar o retirar. Planifique también la retirada, porque un modelo sin responsable que nadie se atreve a desconectar es una carga.

Qué documentar antes de una versión

La guía de Google sobre la puesta en producción es refrescantemente práctica. Para la implementación, los equipos deberían dejar por escrito:

• las aprobaciones necesarias para iniciar la implementación
• cómo poner un modelo en producción
• dónde se implementa primero (entornos de preparación o canary)
• qué hacer si una implementación falla
• cómo revertir un modelo que ya está en producción

Si hoy su equipo no puede responder a esos cinco puntos para su modelo más importante, ya ha encontrado su primer proyecto de MLOps.

¿Dónde se encuentra? Una evaluación de madurez de MLOps

Los modelos de madurez le ayudan a elegir el siguiente paso en lugar del destino final. El Modelo de madurez de MLOps de Microsoft define cinco niveles:

AWS ofrece una progresión similar en su hoja de ruta de fundamentos de MLOps: Inicial, Repetible, Fiable y Escalable. En esa hoja de ruta, la fase Repetible incorpora canalizaciones automatizadas y un registro de modelos; la fase Fiable añade pruebas automáticas en un entorno de preproducción aislado, con aprobaciones manuales para la promoción; y la fase Escalable utiliza plantillas para reducir el tiempo de desarrollo de semanas a días.

Dos observaciones sinceras del sector. Primero, no todos los modelos necesitan alcanzar el nivel 4. Un modelo de previsión trimestral que un equipo financiero revisa manualmente puede funcionar bien en el nivel 2, mientras que un modelo de detección de fraude que puntúa transacciones en tiempo real debería aspirar a un nivel superior. Segundo, saltarse niveles rara vez funciona. El reentrenamiento automatizado sobre datos no trazables solo automatiza la confusión.

Prácticas recomendadas de MLOps que funcionan en producción

Las prácticas recomendadas solo son útiles cuando cambian lo que hace el equipo el lunes. Estas son las más importantes para las empresas, agrupadas según la pregunta a la que responden.

¿Podemos lanzar y revertir cambios de forma segura?

• Versione los datos, el código y los modelos conjuntamente, para que cualquier predicción pueda rastrearse hasta los artefactos exactos que la produjeron.
• Promueva los modelos a través de entornos de preproducción y canario, con una persona aprobadora identificada para producción.
• Mantenga una vía de reversión probada. Revertir un modelo debería ser tan habitual como revertir una versión de una aplicación.
• Utilice un enfoque basado en listas de comprobación. La lista de comprobación de MLOps de AWS abarca nueve áreas: gestión de datos, experimentación, observabilidad, canalizaciones, integración continua, supervisión, despliegue, entrenamiento y gobernanza. Funciona bien como evaluación de carencias antes de adquirir cualquier solución.

¿Es seguro?

Las canalizaciones de modelos amplían la superficie de ataque de formas que las revisiones de seguridad de aplicaciones tradicionales pueden pasar por alto. El informe técnico MLSecOps de OpenSSF advierte de que un MLOps no protegido deja los sistemas expuestos al envenenamiento de datos, a ataques adversariales contra los modelos y a vulnerabilidades en bibliotecas de código abierto. Recomienda proteger las canalizaciones desde la fase de planificación y considerar la seguridad una responsabilidad compartida entre desarrolladores de ML, profesionales de seguridad y equipos de operaciones. Sus controles incluyen herramientas seguras, gestión de parches y controles de acceso basados en el principio de mínimo privilegio.

En el ámbito de los contenedores, las directrices de AKS para MLOps de Microsoft recomiendan analizar las imágenes de contenedores de modelos de código abierto para detectar vulnerabilidades conocidas y mantener registros de auditoría de los datos ingeridos y de los cambios en los modelos. Las mismas directrices señalan la compatibilidad con marcos como SOC 2, HIPAA y GDPR cuando sean aplicables a su caso.

¿Podemos explicarlo y gobernarlo?

La gobernanza falla cuando es un documento en lugar de un paso de la canalización. Intégrela en el proceso:

• un registro de modelos que documente el responsable, el linaje de los datos de entrenamiento, los resultados de la evaluación y el estado de aprobación
• comprobaciones automatizadas que bloqueen la promoción cuando no se alcancen los umbrales de evaluación
• revisiones programadas de los modelos supervisados, con una persona designada como responsable de cada uno
• un procedimiento de retirada, para que los modelos no permanezcan activos una vez finalizada su finalidad

Si sus modelos influyen en decisiones sobre personas o están expuestos a usuarios de la UE, es posible que la normativa le sea aplicable. Nuestros propios análisis sobre la gobernanza de la IA agéntica y la preparación para la Ley de IA de la UE explican cómo los controles deben mantenerse al ritmo de las decisiones automatizadas. Solicite a su asesor jurídico que confirme qué obligaciones se aplican a sus sistemas concretos.

Comparación de los enfoques para plataformas MLOps

No existe una única plataforma que sea la mejor, y normalmente un análisis comparativo función por función no es el primer paso adecuado. Empiece por las capacidades que toda empresa necesita y, después, pregúntese qué enfoque las proporciona con la menor carga operativa para su equipo. Las capacidades fundamentales son el seguimiento de experimentos, el control de versiones de modelos, la orquestación de canalizaciones, el servicio de modelos y la supervisión.

Los enfoques se dividen en tres grandes tipos:

El error más habitual es considerar que «gratis» significa «barato». Las herramientas de código abierto no tienen cuota de licencia, pero usted sigue teniendo que gestionar clústeres, aplicar parches a los componentes y contar con personal que los conozca. El error contrario es suponer que un servicio gestionado elimina la necesidad de ingeniería: usted sigue diseñando las canalizaciones, las pruebas y las puertas de aprobación. Los precios de los servicios gestionados cambian con frecuencia, así que confirme las tarifas vigentes en la propia página de precios de cada proveedor antes de elaborar un caso de negocio.

Cómo elegir un enfoque adecuado para su empresa

Le sugerimos seguir estos pasos en orden.

1. Haga un inventario de lo que existe. Enumere sus modelos, quién es su propietario, dónde se ejecutan y cómo se implementan actualmente. La mayoría de las empresas descubren más modelos no oficiales de los esperados.
2. Tome como referencia su nube y la concentración de sus datos. Si sus datos se encuentran en una única nube, los servicios nativos de esa nube suelen reducir el trabajo de integración. Trasladar grandes conjuntos de datos es un proyecto independiente.
3. Adapte las herramientas a las competencias del equipo. Una plataforma que requiere conocimientos de Kubernetes es una mala elección para un equipo que no los tiene ni cuenta con un plan para contratar personal que los tenga.
4. Enumere los controles imprescindibles. Los registros de auditoría, el control de acceso, la residencia de los datos y los flujos de trabajo de aprobación proceden del cumplimiento normativo y la seguridad, no de la lista de funciones del proveedor.
5. Elija un modelo de alto valor como piloto. Construya de principio a fin su recorrido hasta producción, mida el tiempo de lanzamiento y la tasa de incidentes, y convierta después ese recorrido en una plantilla que puedan reutilizar otros equipos.
6. Compruebe la interoperabilidad. Prefiera componentes con formatos y API abiertos, para que sustituir una pieza más adelante no implique reconstruirlo todo.
7. Calcule el coste total de propiedad. Incluya la infraestructura, las licencias, el tiempo de ingeniería y el coste de la indisponibilidad del modelo.

Un piloto también le proporciona algo poco habitual en las decisiones sobre plataformas: pruebas de su propio entorno en lugar de una demostración del proveedor.

El argumento empresarial para hacerlo bien

El retorno de MLOps se manifiesta en varios aspectos que los responsables ya supervisan: menor tiempo desde la aprobación de una idea hasta su puesta en producción, menos incidentes causados por modelos degradados, menos herramientas duplicadas y mayor facilidad para las auditorías. Las herramientas duplicadas son el aspecto menos visible. Cuando cada equipo ensambla su propia pila, el coste oculto de ejecutar varias plataformas desconectadas aumenta por las licencias, el trabajo de integración y los cambios de contexto. Un recorrido compartido y basado en plantillas hasta producción es la forma en que las empresas evitan ese problema.

Para los responsables de tecnología, también cambia la conversación con el negocio. En lugar de decir «el modelo está casi listo», puede informar sobre la frecuencia de lanzamiento, el tiempo necesario para revertir cambios y el estado supervisado del modelo.

Cómo podemos ayudar

En Ridiculous Engineering, los clientes trabajan directamente con ingenieros sénior, desde el análisis inicial hasta la mejora a largo plazo. Si está convirtiendo pilotos en sistemas de producción, nuestros servicios de desarrollo y automatización de IA abarcan soluciones de IA personalizadas y la automatización que las rodea, y nuestro asesoramiento y soporte para la entrega de software puede ayudarle a evaluar en qué punto se encuentra su proceso actual de entrega. También puede leer nuestro análisis anterior sobre la industrialización de la IA y MLOps. El trabajo de IA personalizada se define de forma individual, con precios bajo petición, así que solicite un presupuesto con una breve descripción de su primer modelo y analizaremos el recorrido adecuado, dimensionado a sus necesidades.

Preguntas frecuentes

¿Cuál es la diferencia entre MLOps y DevOps?

DevOps automatiza la creación, las pruebas y la publicación del código de las aplicaciones. MLOps hace eso y también gestiona los datos, el entrenamiento, las versiones de los modelos y el rendimiento posterior a la publicación, porque un modelo puede degradarse sin que cambie el código. Normalmente, los equipos amplían sus prácticas existentes de CI/CD en lugar de sustituirlas.

¿Por dónde debería empezar una empresa con MLOps?

Elija un modelo importante para el negocio y documente cómo llega actualmente a producción. Después, cierre las brechas más importantes: control de versiones para datos y modelos, pruebas automatizadas, un entorno de preparación y un plan de reversión. Reutilice ese recorrido para el siguiente modelo.

¿Necesitamos una plataforma de MLOps específica?

No siempre. Algunos equipos avanzan mucho con su sistema de CI/CD existente y unas pocas herramientas especializadas para el seguimiento, el registro y la supervisión. Una plataforma más completa tiene sentido cuando muchos equipos y modelos necesitan estándares y una gobernanza compartidos.

¿Cómo contribuye MLOps a la seguridad y el cumplimiento normativo?

Hace que los controles sean reproducibles. Los registros de auditoría, el acceso con privilegios mínimos, el análisis de vulnerabilidades de los contenedores de modelos y las barreras de aprobación se ejecutan dentro del flujo de trabajo, en lugar de depender de revisiones manuales. Las normativas aplicables, como HIPAA o RGPD, dependen de sus datos y deben confirmarse con su equipo de cumplimiento normativo.

¿Cuánto se tarda en alcanzar una práctica madura de MLOps?

Depende de su punto de partida, del número de modelos y del equipo. Los modelos de madurez describen una progresión por niveles, y la mayoría de las organizaciones los recorren paso a paso a lo largo de proyectos sucesivos, en lugar de hacerlo mediante un único programa.

Fuentes

• ¿Qué es MLOps? (AWS)
• Un marco para la entrega continua y la automatización del ML: Guía para profesionales sobre MLOps (Google)
• Las operaciones de aprendizaje automático ofrecen agilidad e impulsan la innovación (MIT Technology Review)
• Operaciones de aprendizaje automático, versión 2 (Azure Architecture Center)
• Modelo de madurez de MLOps (Azure Architecture Center)
• MLOps: canalizaciones de entrega continua y automatización (Google Cloud)
• Gestión del ciclo de vida de modelos de aprendizaje automático empresariales (IJISAE)
• Puesta en producción (Google for Developers)
• Hoja de ruta de fundamentos de MLOps para empresas (AWS)
• Lista de comprobación de MLOps de AWS (AWS Prescriptive Guidance)
• Libro blanco de MLSecOps de OpenSSF
• Prácticas recomendadas de MLOps en AKS (Microsoft Learn)

Recomendado

• Por qué la IA empresarial fracasa después de la demostración
• IA empresarial: cómo escapar del purgatorio de los proyectos piloto
• IA empresarial: cómo escapar del purgatorio de los proyectos piloto
• MLOps: IA industrializada para mejorar las estrategias empresariales con Ridiculous Engineering