MLOps e implementación: trasladar el modelo del laboratorio a la producción

Ganancias:

• Capacidad para reconocer los desafíos especiales del ML relacionados con el paquete y el trío código-datos-modelo y presentar el modelo en línea o en lotes según las necesidades comerciales.
• Capacidad para implementar patrones de implementación gradual y de reversión (sombra, canario, A/B, reversión) y agregar un plan de reversión probado a cada implementación.
• Capacidad para mantener rastreable el vínculo de datos, código y métrica del modelo puesto en producción con CI/CD controlado por umbral de evaluación y registro de modelos.

Conseguir que un modelo alcance una precisión del 95% en el cuaderno es sólo la mitad de la historia. La otra mitad (a menudo la parte difícil) es hacer llegar ese modelo a usuarios reales de una manera confiable, escalable y mantenible. MLOps (Operaciones de aprendizaje automático: la disciplina de poner, operar y mantener modelos de ML en producción) combina las prácticas de DevOps de la ingeniería de software con los desafíos únicos del ML. En esta unidad, cubrimos los pasos para pasar el modelo a producción y cómo la inteligencia artificial ayuda en este proceso.

¿Por qué el ML es diferente del software normal?

En el software normal, el comportamiento está en el código; Si el código no cambia, el comportamiento no cambia. En ML, el comportamiento depende tanto del código, como de los datos y del modelo. Estas tres dimensiones crean los desafíos adicionales de MLOps:

• Deriva de datos: los datos en producción se alejan de los datos en entrenamiento con el tiempo; el modelo se vuelve obsoleto.
• Necesita versionar tres cosas: código, datos y modelo, las tres.
• Fallo silencioso: Un modelo puede fallar sin fallar, sin dar errores, simplemente produciendo predicciones incorrectas. Detectar esto requiere seguimiento.

Por eso existe una gran diferencia entre un "modelo funcional" y un "modelo listo para producción".

Embalaje y presentación del modelo.

El primer paso para poner el modelo en producción es empaquetarlo: el archivo del modelo, las bibliotecas necesarias, el código de preprocesamiento y la información de la versión juntos como un todo reproducible. La contenedorización (por ejemplo, Docker: colocar la aplicación en una caja aislada con todas sus dependencias) es estándar aquí; Elimina el problema "estaba funcionando en mi máquina".

Dos patrones básicos de servicio del modelo:

• En línea/en tiempo real (en línea): el modelo se encuentra detrás de una API y devuelve una predicción instantánea para cada solicitud entrante. La baja latencia es fundamental.
• Lote: el modelo procesa grandes conjuntos de datos periódicamente (por ejemplo, genera puntuaciones para todos los clientes por la noche). La latencia es irrelevante, la eficiencia es importante.

Cuál es el correcto depende de las necesidades del negocio: recomendación instantánea en línea, puntuación de riesgo mensual por lotes.

Consejo: "Tiempo real" es un costo, no el valor predeterminado. El lote es mucho más barato y sencillo si el resultado se utilizará en unas horas. ¿Realmente necesitas una respuesta instantánea? Pregunta eso primero.

Estrategias de distribución segura

Abrir un nuevo modelo directamente a todo el tráfico es arriesgado; Si está mal, todos se ven afectados. Patrones de distribución segura:

• Implementación en la sombra: el nuevo modelo recibe tráfico de producción, pero sus predicciones no se muestran al usuario, solo se registran. Se compara con el modelo anterior para ver si es seguro en datos reales.
• Implementación canary: el nuevo modelo se implementa primero en un pequeño porcentaje del tráfico (por ejemplo, 5 %); Si no hay problema se aumenta progresivamente.
• Pruebas A/B: se presentan dos modelos al usuario real en paralelo y se comparan métricas comerciales (conversión, clics).
• Revertir: capacidad de volver rápidamente a la versión anterior si el nuevo modelo resulta ser malo. Cada implementación debe tener un plan de reversión.

Precaución: Una implementación sin un plan de reversión no está completa. Poder volver a la versión anterior en cuestión de minutos protege al usuario cuando el nuevo modelo se comporta inesperadamente en producción. Pruebe esto antes de la implementación.

Enfoque débil / Enfoque fuerte

Débil: "El modelo fue bueno en las pruebas, lo lanzamos y lo abrimos a todos".

Güçlü: "Conservamos el modelo en contenedores, lo etiquetamos como una versión. Primero, lo ejecutamos en modo sombra con tráfico de producción durante 3 días, comparando las predicciones con el modelo anterior; la desviación era aceptable. Luego lo abrimos con un 5% canary, monitoreamos las métricas de rendimiento y la latencia. Cuando no hubo problemas, lo aumentamos gradualmente hasta el 100%. Habíamos probado el comando de reversión de antemano".

La diferencia: el enfoque fuerte es gradual, mesurado y reversible. El riesgo es limitado en cada paso.

CI/CD y automatización

CI/CD (Integración continua/Implementación continua: proceso de prueba y publicación automática de cambios de código) en ML cubre no solo el código sino también los datos y los pasos del modelo. Una buena canalización de CI/CD de ML: ejecuta pruebas cuando el código cambia, realiza validación de datos, vuelve a entrenar el modelo (si es necesario), verifica los umbrales de evaluación y solo avanza en la implementación si los umbrales se mantienen. El principio de “la capacitación es automática, la implementación se basa en un umbral” evita que el modelo incorrecto se filtre silenciosamente en la producción.

La IA es muy útil a la hora de configurar estos canales: redacción de borradores de archivos de configuración (YAML), casos de prueba y scripts de implementación. Pero usted determina los umbrales de distribución (cualquier métrica que exceda el valor publicado) y la política de reversión; Estas son decisiones de riesgo empresarial.

Infraestructura de reproducibilidad

Para reproducir el comportamiento de un modelo en producción, se utiliza el registro de modelos: un registro que mantiene qué modelo fue entrenado con qué datos y código, y qué métricas recibió. Para cada modelo de producción, se debe poder rastrear lo siguiente: versión de los datos de entrenamiento, versión del código (git commit), hiperparámetros, puntuaciones de evaluación y fecha de implementación. Cuando surge un problema, debería poder responder la pregunta "¿qué modelo produjo esta predicción, con qué datos?" en cuestión de minutos. Profundizaremos en esto en la unidad 11.

tres mini casos

Caso 1: problema detectado por la distribución de sombras. Un modelo de recomendación superó al anterior en las pruebas. Se descubrió que ejecutarlo con tráfico de producción en modo sombra generaba recomendaciones muy deficientes para un segmento particular de usuarios (nuevos usuarios); los datos de prueba no eran representativos de este segmento. El modelo se arregló sin siquiera mostrarse al usuario. Si se abriera directamente, la nueva experiencia del usuario se vería alterada.

Caso 2 - Distribución irrevocable. Un equipo implementó un nuevo modelo de precios para todo el tráfico, sin planes de reversión. El modelo puso inesperadamente un precio muy barato a algunos productos. Volver a la versión anterior llevó horas porque el proceso no estaba listo. Hubo una grave pérdida de ingresos. Posteriormente, se agregaron pruebas de reversión obligatorias a cada implementación.

Caso 3: Deriva silenciosa de datos. Durante meses apareció un patrón de fraude sin errores. Pero las tácticas de los estafadores cambiaron (derivación de datos) y el retiro del modelo disminuyó silenciosamente. Nadie se dio cuenta porque no había ningún seguimiento. Una vez que se estableció un panel de monitoreo de la distribución del pronóstico, la deriva se hizo visible temprano. Cubriremos el monitoreo en la unidad 8.

Plantillas copiables

Escriba un borrador del plan de implementación para este modelo. Modelo: [qué hace], uso: [¿en línea o por lotes?] Debe incluir:1) Empaquetado (contenedor, control de versiones)2) Estrategia de implementación incremental (sombra/canario/A-B) y por qué3) Métricas para rastrear (negocio + técnico + latencia)4) Plan de reversión y cómo probar5) Umbrales de implementación (qué métrica debe exceder qué valor)

Verifique esta canalización de CI/CD de ML: 1) ¿Está la validación de datos en la línea? 2) ¿Puede continuar la implementación sin mantener el umbral de evaluación (no debería)? 3) ¿La reversión es automática? 4) ¿Se realiza un seguimiento de los datos, el código y las métricas en el registro del modelo? Configuración de Pline: [config]

Ayúdame a decidir si la presentación en línea o por lotes es adecuada para este modelo. ¿Cuánto tiempo se utilizará el resultado: [instante / minuto / hora / día] Volumen de solicitudes esperado: [número] ¿Existe una restricción de demora: [ms] ¿Cuál recomendaría en términos de costo y complejidad y por qué?

Escriba un procedimiento de reversión para este modelo.- ¿Qué métrica/umbral desencadena un rendimiento deficiente?- ¿Cuáles son los pasos de reversión?- ¿Cuánto tiempo debe tomar la reversión (objetivo)?- ¿Cómo pruebo este procedimiento antes de la producción?

Tabla de patrones de presentación

criterio

En línea (tiempo real)

lote

retraso

Crítico (ms)

insignificante

Uso

Se requiere respuesta instantánea

Puntuación periódica

Costo

alto

bajo

complejidad

alto

bajo

ejemplo

Recomendación en vivo, estafa

Puntuación de riesgo mensual

Errores comunes

• Distribuir sin un plan de recuperación. El modelo incorrecto afecta a todo el usuario.
• Apertura directa al 100% de tráfico. Limite el riesgo con una distribución escalonada.
• No establecer seguimiento. El modelo produce errores silenciosamente, sin error.
• Presentación redundante en tiempo real. Si bien el procesamiento por lotes es suficiente, el costo y la complejidad aumentan.
• No vincular versiones de código de datos de modelo. No se puede reproducir el problema.
• Lanzamiento automático sin umbral de distribución. El modelo malo se cuela silenciosamente.

En resumen

Mover el modelo a producción es una tarea de ingeniería diferente y, a menudo, más difícil que entrenarlo. El aprendizaje automático requiere disciplina adicional porque depende del trío código-datos-modelo: empaquetado y control de versiones, patrón de entrega (en línea/por lotes) que se adapta a las necesidades del negocio, implementación gradual y reversible, CI/CD con umbral controlado y registro de modelo. La inteligencia artificial es una poderosa ayuda para generar el código y la configuración de esta infraestructura; pero los umbrales de distribución, la política de recuperación y las decisiones de riesgo son suyas. Una distribución sin un plan de reversión no está completa.

Tarea de aplicación

Coloque en un contenedor (Docker) un modelo y etiquételo como versión. Decida si ofrecerá en línea o por lotes según las necesidades de su negocio y escriba su justificación. Documente un plan de implementación por fases (en la sombra o controlado) y un procedimiento de reversión probado. Asegúrese de registrar la versión de los datos, la confirmación del código y las puntuaciones de evaluación en el registro del modelo.

lista de verificación

• [ ] El modelo está empaquetado y versionado (contenedor + etiqueta).
• [ ] El patrón de presentación (en línea/por lotes) se eligió según las necesidades del negocio.
• [] Se implementó una estrategia de implementación por etapas (sombra/canario).
• [] Procedimiento de reversión escrito y probado.
• [] CI/CD no avanza en la implementación antes de que se alcance el umbral de evaluación.
• [] El registro del modelo contiene el enlace datos+código+métrica.